1. 模型 Serving 概述
模型 Serving（模型服务）是机器学习工程化落地的最后一公里，它将训练好的模型封装为可对外提供推理能力的在线服务接口。在 MLOps 全生命周期中，Serving 处于模型训练与业务应用之间的桥梁位置，直接决定了模型能否稳定、高效、安全地产生业务价值。
1.1 模型 Serving 的定义
模型 Serving 是指将训练完成的机器学习模型部署到生产环境，通过标准协议（如 HTTP/gRPC）接收推理请求，执行模型前向计算，并返回预测结果的过程。其核心职责包括：
- 模型加载与生命周期管理：从存储系统加载模型文件，管理版本切换与热更新。
- 推理请求处理：解析输入数据，执行特征预处理、模型推理、后处理。
- 资源调度与弹性伸缩：根据请求量动态分配 GPU/CPU 资源，保障延迟与吞吐量。
- 监控与可观测性：采集推理延迟、QPS、错误率等指标，支持链路追踪与日志。
关键认知：模型 Serving 不是简单的“模型文件 + Web 服务器”，而是包含模型版本管理、请求路由、批处理、缓存、降级熔断等能力的系统工程。
1.2 在 MLOps 中的位置
MLOps 将机器学习生命周期划分为数据工程、模型开发、模型部署、监控运维四大阶段。模型 Serving 位于模型部署阶段的核心位置，向上承接模型训练产出的模型制品，向下对接业务系统与监控体系。
1.3 模型 Serving 与模型训练的区别
模型训练与模型 Serving 在目标、环境、性能要求、技术栈等方面存在显著差异。理解这些区别是设计可靠 Serving 系统的基础。
| 对比维度 | 模型训练 | 模型 Serving |
|---|---|---|
| 核心目标 | 最小化损失函数，提升模型精度 | 最小化推理延迟，保障服务可用性 |
| 数据形态 | 批量数据（Batch），全量数据集 | 单条或小批量请求（Online） |
| 计算资源 | GPU 集群，高吞吐训练卡 | GPU/CPU 混合，低延迟推理卡 |
| 框架依赖 | PyTorch/TensorFlow 训练框架 | Triton/TF Serving/ONNX Runtime |
| 版本管理 | 实验版本、Checkpoint 管理 | 生产版本、灰度发布、回滚 |
| 性能指标 | 训练吞吐（样本/秒）、收敛速度 | P99 延迟、QPS、错误率 |
| 容错要求 | 任务失败可重跑，容忍中断 | 高可用，单点故障自动切换 |
实践要点：训练阶段追求模型精度，Serving 阶段追求服务稳定性。训练代码通常使用 float32 精度，而 Serving 可量化至 int8 以换取更低延迟。训练环境允许动态图调试，Serving 环境必须使用静态图或编译优化后的推理引擎。
1.4 Serving 系统的核心架构
一个生产级的模型 Serving 系统通常包含以下组件：
- 网关层：负责请求路由、认证鉴权、限流熔断。
- 推理引擎：执行模型加载与计算，支持多模型并发。
- 模型仓库：存储模型制品，支持版本管理与热加载。
- 监控告警：采集指标、日志、链路追踪数据。
- 弹性伸缩：基于负载自动扩缩容实例。
1.5 本章小结
- 模型 Serving 是 MLOps 中模型部署阶段的核心，负责将模型转化为在线推理服务。
- 与模型训练相比，Serving 更关注延迟、吞吐、可用性等运维指标。
- 生产级 Serving 系统需要网关、推理引擎、模型仓库、监控等组件协同工作。
- 回测与灰度是 Serving 上线前的关键质量保障手段，将在后续章节深入展开。