推理系统概述
date
Dec 19, 2024
slug
infer-sys
status
Published
tags
AI-Infra
summary
type
Post
推理系统介绍
训练和推理服务的区别

训练任务:一般配置较大的批尺寸追求较大的吞吐,将模型训练达到指定的准确度或错误率。
推理任务:执行7x24的服务,受限于响应延迟,配置更小批尺寸,模型稳定一般不再被训练。
训练过程通过设计合适AI模型结构以及损失函数和优化算法,将数据集以Mini-batch反复进行前向计算并计算损失,反向计算梯度利用优化函数来更新模型,使得损失函数最小。训练过程最重要是梯度计算和反向传播。
推理是在训练好的模型结构和参数基础上,一次前向传播得到模型输出过程。相对于训练,推理不涉及梯度和损失优化。最终目标是将训练好的模型部署生产环境中。

推理相比训练的新特点与挑战
- 模型被部署为长期运行的服务
- 推理有更苛刻的资源约束
- 推理不需要反向传播梯度下降
- 部署的设备型号更加多样

推理系统优化目标与约束
在线推荐系统的服务需求
例如某在线新闻APP公司希望部署内容个性化推荐服务并期望该服务能满足以下需求:
- 低延迟 互联网上推荐文章延迟(<100毫秒)
- 高吞吐 突发新闻驱动的暴增人群的吞吐量需求
- 扩展性 扩展到不断增长的庞大的用户群体
- 准确度 随着新闻和读者兴趣的变化提供准确的预测

推理系统不仅要满足应用场景的需求,还要面对由不同模型训练框架和多样推理硬件带来的部署环境多样性,这使得部署优化和维护变得复杂且易出错。

推理系统优化目标
低延迟(Latency):满足服务等级协议的延迟
吞吐量(Throughputs):暴增负载的吞吐量需求
高效率(Efficiency):高效率且低功耗使用GPU,CPU
灵活性(Flexibility):支持多种框架,提供构建不同应用的灵活性
扩展性(Scalability):扩展支持不断增长的用户或设备
Flexibility 灵活


推理系统要面对很多问题例如:框架多样性,硬件多样性,服务系统的多样性
框架多样性:
- 大多数框架都是为训练设计和优化
- 开发人员将必要的软件组件拼凑在一起
- 跨多个不断发展的框架集成和推理需求
硬件多样性
- 多种部署硬件的支持
服务系统需要灵活性:
- 支持加载不同AI框架的模型
- AI框架推陈出新和版本不断迭代
- 与不同语言接口和不同逻辑的应用结合
解决方法:
- 深度学习模型开放协议:跨框架模型转换
- 接口抽象:提供不同框架的通用抽象
- 容器:运行时环境依赖与资源隔离
- RPC:跨语言,跨进程通信
Latency 延迟
推理延迟:延迟是用户给出查询后呈现推理结果消耗的时间;必须快速且同时满足有限的尾部延迟
需要低延迟:服务水平协议(SLA):Sub-second级别延迟
低延迟挑战:交互式APP低延迟需求与训练AI框架目标不一致;大模型更准确,但浮点运算量更大;Sub-second级别延迟约束制数据Batch Size;模型融合容易引起长尾延迟

Throughputs 吞吐量
需要高吞吐的目的:
- 突发的请求数量暴增
- 不断扩展的用户和设备
达到高吞吐的策略:
- 充分利用AI芯片能力 1)批处理请求;2)指令级运算;
- 支持动态Shape和自适应批尺寸Batch Size
- 多模型装箱使用加速器
- 容器扩展副本部署
Efficiency效率
需要高效的原因:
- 内存、ALU数量等资源约束
- 移动端有极高的功耗约束
- 云端有预算的约束
高效率策略:
- 模型压缩
- 高效使用AI推理芯片
- 装箱(bin-packing)使用加速器
Scalability扩展性
扩展性原因:
- 应对用户与请求的增长
- 提升推理系统吞吐量
推理系统 VS. 推理引擎


推理流程全景
部署态区别

推理系统一般可以部署在云或者边缘。云端部署的推理系统更像传统Web服务,在边缘侧部署的模型更像手机应用和IOT应用系统。
部署态:Cloud云端

云端提供了更强大的计算能力、更大的内存空间,并且电力供应充足,以满足模型的高功耗需求。此外,云端与训练平台的紧密集成使得用户能够更容易地使用最新版本的模型,同时在安全性和隐私保护方面也更加可靠。与边缘计算相比,云端可以实现更高的推理吞吐量。然而,用户的请求需要通过网络传输到数据中心进行处理后再返回,这意味着用户需要依赖服务提供商的软硬件资源。
Cloud云端特点:
- 对功耗、温度、Model Size没有严格限制
- 有用于训练和推理的强大硬件支持
- 集中的数据管理有利于模型训练
- 模型更容易在云端得到保护
- 深度学习模型的执行平台和AI框架统一
Cloud云端问题:
- 云上提供所有人工智能服务成本高昂
- 推理服务对网络依赖度高
- 数据隐私问题
- 数据传输成本
- 很难定制化模型
部署态:Edge端侧

边缘侧设备资源更紧张且功耗受电池约束,需要更加在意资源的使用和执行的效率。用户的响应只需要在自身设备完成,且不需消耗服务提供商的资源。
Edge端侧挑战:
- 严格约束功耗、热量、模型尺寸小于设备内存
- 硬件算力对推理服务来说不足
- 数据分散且难以训练
- 模型在边缘更容易受到攻击
- DNN平台多样,无通用解决方案
Edge端侧:
- 应用层算法优化:考虑到移动端部署的苛刻资源约束条件下,提供针对移动端部署的AI模型
- 高效率模型设计:通过模型压缩的量化、剪枝、蒸馏、神经网络结构搜索(NAS)等技术,减少模型尺寸
- 移动端框架推理引擎:TensorFlow Lite,MNN,TensorRT,ONNX Runtime,MindSpore Lite等推理引擎推出
- 移动端芯片:提供高效低功耗芯片支持,如Google Edge TPU,NVIDIA Jetson,Huawei Ascend310系列
端侧部署技术难点分析

部署难点:
- 部署维护成本高,难落地
- 模型适配、迁移难,重复开发
- 预测性能差,硬件成本高
- 高精度模型体积大,性能差
云测部署和推理方式


功能模块 | 描述 |
请求与响应处理 | 系统必须高效地序列化和反序列化请求,并快速执行后端处理,以满足较低的响应延迟要求。与传统Web服务相比,推理系统经常需要处理大型非结构化数据,因此需要高效的数据传输、序列化、压缩和解压缩技术。 |
请求调度 | 系统可以根据后端资源利用率动态调整批尺寸和模型资源分配,以提升资源利用率和吞吐量。对于加速器加速的推理,还需考虑主存与加速器内存间的数据拷贝,通过调度或预取策略在计算间歇做好数据准备。 |
推理引擎执行 | 推理引擎将请求映射到模型作为输入,并在运行时调度深度学习模型的内核进行多阶段处理。在异构硬件或多样化环境中,利用编译器进行代码生成与内核算子优化,自动化转换模型为特定平台的高效机器码。 |
模型版本管理 | 云端算法工程师负责迭代模型版本,并遵循协议确保更新和回滚的顺利执行。新模型根据计划或条件自动上线,优化推理服务。若新模型线上测试效果不佳,启用回滚机制恢复到稳定版本。 |
健康监控 | 云端服务系统应是可观测的,以便服务端工程师监控、报警和修复服务,保证服务稳定性和SLA。 |
推理硬件 | 在边缘端等场景面对多样硬件、驱动和开发库时,通过编译器进行代码生成让模型跨设备高效运行,并实现性能优化。 |
边缘部署和推理方式

方式一:边缘设备计算
将模型部署在设备端,聚焦于降低延迟:
- 端侧模型结构设计
- 通过模型量化、剪枝等压缩手段
- 针对神经网络的专用芯片ASIC设计

方式二:安全计算 + 卸载到云端
模型部署于数据中心,边缘侧将请求发送到云端,云端推理返回结果,相当于将计算卸载到云端:
- 利用云端运行提升模型安全性
- 适合部署端侧无法部署的大模型
- 完全卸载到云端有可能违背实时性的需求

方式三:边缘设备 + 云端服务器
利用AI模型结构特点,将一部分层切(或者其Student模型)分放在设备端进行计算,其他放置在云端。
这种方式一定程度上能够比方式2降低延迟,由于其利用了边缘设备的算力,但是与云端通信和计算还是会带来额外开销。

方式四:分布式计算
从分布式系统角度抽象问题,AI计算在多个辅助边缘设备上切片:
- 切片策略根据设备计算能力,内存约束
- 通过细粒度的切片策略,将模型切片部署其他边缘设备
- 运行对计算模型进行调度,并通过输入数据通过负载均衡策略进行调度

方式五:跨设备OffLoading
决策时需权衡功耗、准确度、延迟和输入尺寸等因素,可选择当前流行的模型,或通过知识蒸馏、模型层的混合匹配来构建。
例如,将高性能模型部署在边缘服务器,而将低性能模型部署在设备端。

推理系统架构

推理、部署、服务化
术语 | 定义 |
推理(Inference) | 对于训练(Training)而言的推理,即模型前向计算,也就是对于给出的输入数据计算得到模型的输出结果;相对预测(Prediction)的推理,是统计学领域的范畴。 |
部署(Deployment) | 训练得到的模型主要目的还是为了更有效地解决实际中的问题,因此部署是一个非常重要的阶段。模型部署的课题也非常多,包括但不仅限于:移植、压缩、加速等。 |
服务化(Serving) | 模型的部署方式是多样的:封装成一个SDK,集成到APP或者服务中;封装成一个Web服务,对外暴露接口(HTTP(S),RPC等协议)。 |

Triton

Triton推理服务器(NVIDIA Triton Inference Server)是英伟达等公司推出的开源推理框架,为用户提供部署在云和边缘推理上的解决方案。