1. 推理服务概述
大家好，我是你们的讲师。今天咱们聊聊推理服务——这个在AI落地中绕不开的话题。
说实话，我见过不少团队，模型训练得漂漂亮亮，一到上线就抓瞎。为什么？因为训练和推理，根本是两码事。你想想看，训练时你可以用A100慢慢跑，batch size调大点，精度用float32，没人催你。但推理呢？用户点一下按钮，你必须在几百毫秒内给出结果，还得稳定、还得省钱。
嗯，这就是推理服务要解决的问题。
什么是推理服务
推理服务，说白了就是把训练好的模型部署到生产环境，对外提供API接口，让业务系统能调用它做预测。
它不只是一个模型文件加一个HTTP服务那么简单。一个成熟的推理服务，至少得管这几件事：
- 模型加载与管理——模型放哪、怎么加载、要不要热更新
- 请求处理——接收输入、做预处理、跑模型、后处理、返回结果
- 资源调度——GPU显存怎么分、并发请求怎么排队、要不要做批处理
- 监控与日志——延迟、吞吐量、错误率，这些都得盯着
- 版本管理——模型迭代了，怎么平滑切换，怎么回滚
核心要点：推理服务不是"把模型跑起来"就完事了，而是"让模型在生产环境稳定、高效、可运维地跑起来"。
推理服务与训练的区别
我刚开始带团队时，有个同事直接把训练代码改了个端口就当推理服务上线了。结果呢？显存爆了、延迟飙了、用户投诉了。后来我让他把训练和推理的区别列了个表，贴在工位上——
| 维度 | 训练 | 推理 |
|---|---|---|
| 目标 | 找到最优参数 | 快速、稳定地预测 |
| 精度需求 | 高精度（float32/16） | 可接受精度下尽量低精度（int8/FP8） |
| 延迟要求 | 不敏感，几小时都行 | 敏感，通常要求毫秒级 |
| 吞吐量 | 单次大batch | 高并发、小batch或动态batch |
| 硬件利用 | 尽量占满GPU | 平衡延迟与利用率 |
| 框架依赖 | PyTorch/TF完整框架 | 可优化、可剪裁、可转ONNX/TensorRT |
| 运维需求 | 低，实验环境即可 | 高，需要监控、扩缩容、版本管理 |
你看，从精度到延迟，从框架到运维，几乎每个维度都在"反着来"。所以千万别拿训练代码直接当推理服务用——我曾经吃过这个亏，那次事故让我加了三天班。
常见的推理框架对比
市面上推理框架不少，我挑三个最有代表性的聊聊：Triton Inference Server、TorchServe、BentoML。这三个我都用过，各有各的脾气。
Triton Inference Server
NVIDIA出品，业界标杆。我最早接触Triton是在一个视频理解项目里，模型又大又杂，有PyTorch的、有TensorRT的、还有自定义算子。Triton的多框架支持让我省了不少事——一个服务端，同时管着不同框架的模型，互不干扰。
它最厉害的是动态批处理和并发模型执行。你想想看，如果每个请求都单独跑一次模型，GPU利用率低得可怜。Triton会自动攒一批请求，凑够一定数量或等够一定时间，再一起送进GPU。吞吐量能翻好几倍。
不过，Triton的配置有点繁琐。你得写模型配置文件，定义输入输出格式、batch策略、优化选项。我第一次配的时候，光一个模型就折腾了大半天。
TorchServe
PyTorch官方出品，跟PyTorch生态无缝衔接。如果你团队全是PyTorch栈，TorchServe上手最快——模型导出、打包、部署，一条龙。
我记得有个小团队，模型迭代特别快，一周发两三个版本。TorchServe的模型版本管理和RESTful API让他们很舒服，改个版本号就能切换，不用改代码。
但TorchServe的性能优化不如Triton。它不支持动态批处理，也不支持多框架混布。如果你的场景对延迟和吞吐要求不高，或者模型比较单一，TorchServe够用。否则，还是得看Triton。
BentoML
BentoML走的是"开发者体验"路线。它把模型、预处理、后处理、依赖环境打包成一个Bento，然后一键部署成REST API或gRPC服务。
我个人很喜欢BentoML的Python原生体验。你写一个Python类，定义好输入输出，加几个装饰器，服务就搭好了。对于快速原型验证，BentoML简直是神器。
但BentoML的生产级特性相对弱一些。它的动态批处理是后来才加的，多GPU支持也不如Triton成熟。如果你做的是中小规模服务，或者团队以Python工程师为主，BentoML很合适。大规模生产环境，还是Triton更稳。
三框架对比一览
| 特性 | Triton | TorchServe | BentoML |
|---|---|---|---|
| 框架支持 | 多框架（PyTorch/TF/ONNX/TensorRT/自定义） | 仅PyTorch | 多框架（PyTorch/TF/ONNX/Scikit-learn等） |
| 动态批处理 | 原生支持，成熟 | 不支持 | 支持，但较新 |
| 性能优化 | 最强（TensorRT集成、并发模型执行） | 一般 | 中等 |
| 上手难度 | 较高（配置多） | 低（PyTorch用户友好） | 低（Python原生） |
| 生产运维 | 强（监控、扩缩容、版本管理） | 中等 | 中等 |
| 适用场景 | 大规模、高性能、多模型混布 | PyTorch单一模型、快速部署 | 快速原型、中小规模、Python团队 |
我的建议：如果你刚开始做推理服务，从BentoML或TorchServe入手，先跑通流程。等业务量上来了，再迁移到Triton做性能优化。别一上来就搞Triton，配置能把人劝退。
推理服务的核心流程
不管用哪个框架，推理服务的基本流程都差不多。我画了张图，帮你理清思路——
流程看着简单，但每个环节都有坑。我举几个例子——
- 预处理太慢：有一次，我的模型推理只用了5ms，但图片解码用了50ms。后来我把解码挪到客户端做，延迟直接降了10倍。
- 后处理没优化：NMS（非极大值抑制）在CPU上跑很慢，换成GPU实现后，吞吐量翻了一倍。
- 动态批处理没开：默认单请求推理，GPU利用率只有10%。开了动态批处理后，利用率飙到80%。
避坑指南：我曾经在一个OCR服务里，预处理用了PIL的resize，后处理用了Python的for循环。结果模型推理只占20%的时间，剩下80%全耗在前后处理上。后来我把预处理换成OpenCV，后处理用numpy向量化，整体延迟降了60%。记住——推理服务的瓶颈往往不在模型，而在数据流。
小结
这一章我们聊了推理服务是什么、它跟训练的区别、三个主流框架的对比，以及核心流程。说白了，推理服务就是把模型从"实验室"搬到"生产线"的过程。框架选型没有银弹——Triton适合大厂、TorchServe适合PyTorch团队、BentoML适合快速迭代。选哪个，取决于你的团队、场景和资源。