什么是在线推理
在线推理(Online Inference)是指AI模型实时响应用户请求的推理模式。在这种模式下,系统需要在用户提交请求后尽快返回结果,通常要求响应延迟在毫秒到秒级范围内。
在线推理的典型特征包括:
- 实时性要求高:用户期待即时响应,系统需要快速处理单个或少量请求
- 交互式场景:用户与系统进行实时交互,如聊天对话、实时翻译、语音识别等
- 低延迟优先:优化目标是降低单个请求的响应时间(
Latency) - 资源常驻:服务需要持续运行,保持模型加载在内存中以随时响应请求
常见的在线推理应用场景包括:
- 智能客服对话系统
- 实时语音转文字服务
- 在线图像识别和分类
- 实时推荐系统
- 大语言模型(
LLM)对话服务
然而,在线推理也面临一些挑战:
- 资源利用率不高:为了保证低延迟,系统通常需要预留大量计算资源,但在请求量较低时这些资源处于空闲状态
- 资源维持成本高:需要维持
7x24小时的服务,GPU等昂贵资源长期占用 - 不适合批量处理:对于需要处理大规模数据集的场景(如每日用户画像更新、内容审核、数据标注等),在线推理模式效率低下
- 无法充分利用批处理优化:在线推理为了低延迟,通常使用较小的
Batch Size,无法发挥GPU等硬件的并行计算能力
什么是离线批量推理
为了解决在线推理在处理大规模数据时的效率和成本问题,离线批量推理(Offline Batch Inference,简称离线跑批)应运而生。
离线批量推理是指对大规模数据集进行非实时的批量处理和推理的模式。与在线推理不同,离线批量推理不要求实时响应,而是将大量数据打包成批次,通过充分利用硬件并行计算能力,以更高的吞吐量完成推理任务。
离线批量推理的核心特点:
- 批量处理:一次性处理成百上千甚至上百万条数据记录
- 高吞吐量:优化目标是单位时间内处理更多数据,而非单个请求的响应速度
- 弹性调度:可以根据业务需求灵活调度计算资源,任务完成后释放资源
- 成本优化:通过批量处理和资源复用,大幅降低单条数据的推理成本
- 非实时性:通常在业务低峰期执行,结果可以延迟几小时甚至几天返回
离线批量推理解决的核心痛点:
- 降低推理成本:通过大批量处理,充分发挥
GPU的并行计算能力,降低单条数据的处理成本 - 提高资源利用率:任务执行时集中使用资源,完成后释放,避免资源长期空闲
- 适合大规模数据处理:能够高效处理TB甚至PB级别的数据集
- 灵活的时间窗口:不受实时性约束,可以在计算资源充裕或电价较低的时段执行
离线批量推理的应用场景
离线批量推理在诸多业务场景中发挥着重要作用:
内容审核与过滤
对平台上每日新增的海量用户生成内容(图片、视频、文本)进行审核,检测违规、暴力、色情等不良内容。
- 数据规模:短视频平台每天可能新增数百万条视频
- 处理方式:在业务低峰期集中处理当天或前一天的内容
- 时效要求:通常要求24小时内完成审核即可
用户画像与推荐系统
定期更新用户兴趣标签、行为偏好、购买倾向等特征,为推荐系统提供数据支持。
- 数据规模:数亿用户的行为数据需要定期分析
- 处理方式:每日或每周执行批量特征提取和更新
- 时效要求:T+1日更新即可满足大多数推荐场景
数据标注与增强
使用预训练模型对大规模无标注数据进行自动标注,或对现有数据进行增强处理。
- 数据规模:训练数据集通常包含数百万到数亿条样本
- 处理方式:批量生成标注结果,供后续人工审核或模型训练使用
- 时效要求:作为离线训练流程的一部分,无实时性要求
金融风控与反欺诈
对历史交易数据进行批量风险评估,识别异常交易模式和潜在欺诈行为。
- 数据规模:每日数百万笔交易记录
- 处理方式:夜间批量分析,生成风险报告
- 时效要求:次日提供分析结果即可
医疗影像分析
对大规模医疗影像数据库进行批量分析,辅助疾病筛查和诊断。
- 数据规模:医院积累的数十万到数百万份影像资料
- 处理方式:定期批量处理,生成初步诊断报告
- 时效要求:非急诊场景,几天内完成即可
视频理解与摘要生成
对视频库中的内容进行批量分析,提取关键帧、生成标签、自动生成摘要等。
- 数据规模:视频平台的海量视频内容
- 处理方式:新上传视频的批量处理,或对存量视频的重新分析
- 时效要求:通常不要求实时处理
大语言模型批量生成任务
使用LLM对大规模文本数据进行批量处理,如翻译、摘要、问答对生成等。
- 数据规模:数百万条文本记录
- 处理方式:充分利用模型的批处理能力,提高
GPU利用率 - 时效要求:作为数据处理流程的一环,无实时要求
在线推理与离线批量推理的区别
下表从多个维度对比了在线推理和离线批量推理的差异:
| 维度 | 在线推理(Online Inference) | 离线批量推理(Offline Batch Inference) |
|---|---|---|
| 响应延迟要求 | 极低(毫秒到秒级),用户期待即时响应 | 无严格要求(小时到天级),结果可延迟返回 |
| 吞吐量优先级 | 低,优先保证单个请求的低延迟 | 高,优化单位时间内处理的数据总量 |
| 数据处理方式 | 单条或小批量实时处理 | 大批量集中处理(可达数百万条) |
| Batch Size | 小(通常1-32),受延迟限制 | 大(可达数百到数千),充分利用硬件并行能力 |
| 资源调度策略 | 常驻服务,7x24小时运行 | 弹性调度,任务完成后释放资源 |
| 资源利用率 | 较低,为保证低延迟预留资源 | 高,批量处理时GPU接近满载运行 |
| 成本模型 | 按服务时长计费,成本较高 | 按任务量计费,单条数据成本低 |
| 典型应用 | 聊天对话、实时翻译、在线客服、实时推荐 | 内容审核、用户画像更新、数据标注、定期报告生成 |
| 服务可用性 | 高可用,需要监控和自动恢复 | 任务式,失败可重试 |
| 并发处理能力 | 需要处理高并发请求 | 顺序或并行处理固定数据集 |
| 硬件优化方向 | 低延迟优化(如快速内存访问、低通信延迟) | 高吞吐优化(如大内存、高带宽、多卡并行) |
| 监控指标 | P99/P95 Latency、QPS、TTFT、TPOT | 吞吐量(Throughput)、总处理时间、成功率 |
| 扩展策略 | 横向扩展副本数,负载均衡 | 增加批处理任务的并行度,分布式数据处理 |
| 典型执行时间 | 持续在线服务 | 定时任务(如每日凌晨执行)或按需触发 |
如何实现离线批量推理
实现离线批量推理需要考虑数据处理、模型加载、批量推理执行和结果存储等环节。以下是常用的工具和框架:
推理框架
| 框架名称 | 特点与优势 | 适用场景 |
|---|---|---|
| TensorFlow Serving / TorchServe | 主流在线推理框架,支持批量推理模式,可设置较大的batch_size和max_batch_delay来优化吞吐量 | 适合已使用TensorFlow或PyTorch训练的模型,需要在线和离线推理混合部署的场景 |
| NVIDIA Triton Inference Server | 支持多种后端(TensorFlow、PyTorch、ONNX、TensorRT等),支持动态批处理(Dynamic Batching),可充分利用GPU资源 | 企业级多模型服务场景,需要统一推理平台管理多种模型框架 |
| vLLM | 专为大语言模型设计的高性能推理引擎,通过PagedAttention技术优化显存使用,支持大批量推理和高吞吐 | LLM批量推理场景,如文本生成、翻译、摘要等任务 |
| TensorRT-LLM | NVIDIA针对LLM推理的优化框架,支持高吞吐量批量推理,提供多种量化和优化策略,可配合Triton使用 | 需要极致性能的LLM推理场景,特别是NVIDIA GPU环境 |
| ONNX Runtime | 跨平台推理引擎,支持多种硬件加速器,提供批处理优化和量化支持 | 需要跨平台部署或使用多种硬件加速器的场景 |
批处理编排工具
| 工具/框架 | 核心能力 | 适用场景 |
|---|---|---|
| Apache Spark | 分布式数据处理框架,支持大规模数据集分片和并行处理,原生支持Python和Scala | 需要处理PB级数据集,已有Hadoop/Spark生态的企业,数据和推理任务紧密耦合的场景 |
| Ray | 分布式计算框架,提供Ray Serve用于模型服务和Ray Data用于数据处理,支持动态资源调度 | 需要灵活资源调度的Python为主的ML工作流,支持在线和离线推理混合部署 |
| Kubernetes + KubeFlow | 使用Kubernetes的Job/CronJob调度批量任务,KubeFlow提供ML工作流编排和Pipeline管理 | 云原生环境,需要标准化容器部署和完整MLOps流程的企业 |
| Apache Airflow / Prefect | 工作流编排和调度工具,支持复杂DAG定义、任务依赖管理和失败重试 | 复杂数据处理和推理流程,需要精细化任务依赖管理和调度的场景 |
| AWS Batch / Azure Batch / Google Cloud Batch | 云厂商提供的批处理服务,自动管理计算资源,按需扩缩容,与云生态深度集成 | 云上部署,希望减少运维复杂度,利用Spot实例降低成本的场景 |
实现示例(伪代码)
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
# 加载模型和tokenizer
model = AutoModelForCausalLM.from_pretrained("model_name")
tokenizer = AutoTokenizer.from_pretrained("model_name")
model.to("cuda")
model.eval()
# 读取待处理的数据集
data = load_dataset_from_storage() # 从对象存储或数据库读取
# 批量推理配置
batch_size = 256 # 根据GPU显存调整
results = []
# 分批处理数据
for i in range(0, len(data), batch_size):
batch = data[i:i + batch_size]
# 数据预处理
inputs = tokenizer(batch, padding=True, truncation=True, return_tensors="pt")
inputs = inputs.to("cuda")
# 批量推理
with torch.no_grad():
outputs = model.generate(**inputs, max_length=512)
# 结果解码
batch_results = tokenizer.batch_decode(outputs, skip_special_tokens=True)
results.extend(batch_results)
# 定期保存检查点
if i % 10000 == 0:
save_checkpoint(results)
# 保存最终结果
save_results_to_storage(results)
总结
离线批量推理作为AI推理服务的重要组成部分,在处理大规模数据集时具有显著的成本和效率优势。通过合理选择推理框架、优化批处理配置、实施分布式并行等技术手段,可以在保证推理质量的前提下,大幅降低推理成本、提高资源利用率。
在实际业务中,在线推理和离线批量推理往往结合使用:在线推理满足实时交互需求,离线批量推理处理大规模定期任务,二者互补,共同构建高效的AI推理服务体系。