1. 模型 Serving 概述
模型 Serving（模型服务）是机器学习模型从训练环境走向生产环境的最后一道桥梁。它负责将训练好的模型加载到内存中，对外暴露标准化的推理接口（如 HTTP/gRPC），接收请求数据并返回预测结果。在 AI 生产系统中，Serving 层直接决定了模型能否被业务系统稳定、低延迟地调用。
1.1 模型 Serving 在 AI 生产中的位置
在完整的 AI 生产链路中，模型 Serving 处于“模型训练”与“业务应用”之间的核心枢纽位置。下图展示了典型 AI 生产系统的分层架构：
关键认知：模型 Serving 不是简单的“模型加载 + API 封装”。在生产环境中，它需要处理流量波动、模型热更新、多版本路由、特征对齐、延迟约束、资源隔离等复杂工程问题。
1.2 Serving 与训练的核心区别
模型训练和模型 Serving 在目标、环境、性能要求、资源特征等方面存在本质差异。下表从多个维度进行对比：
| 对比维度 | 模型训练 (Training) | 模型 Serving (Inference) |
|---|---|---|
| 核心目标 | 最小化损失函数，提升模型精度 | 最小化响应延迟，最大化吞吐量 |
| 计算模式 | 批量迭代，前向 + 反向传播 | 单次前向推理，无反向传播 |
| 硬件偏好 | GPU 集群，高显存，大算力 | CPU/GPU/TPU 混合，低功耗，高并发 |
| 数据形态 | 大规模离线数据集，全量特征 | 单条或小批量实时请求，在线特征 |
| 延迟要求 | 无严格延迟约束，小时级可接受 | 毫秒级（通常 < 100ms） |
| 版本管理 | 实验版本，Checkpoint 快照 | 生产版本，灰度发布，回滚机制 |
| 资源弹性 | 固定资源池，任务调度 | 弹性伸缩，按流量动态扩缩 |
| 监控重点 | Loss 曲线、梯度范数、收敛速度 | P99 延迟、QPS、错误率、内存泄漏 |
实践建议：在从训练转向 Serving 时，需要将模型导出为标准化格式（如 ONNX、TorchScript、SavedModel），并做量化、剪枝、算子融合等推理优化。训练时的高精度浮点（FP32）在 Serving 阶段常被替换为 FP16 或 INT8，以换取更低的延迟。
1.3 典型 Serving 架构概览
一个生产级的模型 Serving 系统通常包含多个协作组件。下图展示了一种常见的微服务化 Serving 架构：
上述架构中各组件职责如下：
- 客户端：发起推理请求的业务系统，如风控决策引擎、推荐系统、实时搜索等。
- 负载均衡：将请求分发到多个 Serving 实例，实现流量均摊与故障转移。
- API 网关：统一入口，负责鉴权、限流、请求格式转换、协议适配（HTTP/gRPC）。
- Serving 实例：实际运行推理引擎的进程，每个实例加载一个或多个模型版本，执行前向计算。
- 模型仓库：存储模型文件（如 .onnx、.pt、.pb），支持版本管理和热加载。
- 监控 & 日志：采集延迟、QPS、错误率、资源利用率等指标，用于告警和容量规划。
常见陷阱：许多团队在初期将模型 Serving 简化为“在 Flask 里加载模型并暴露 API”。这种做法在低并发场景下可行，但面对每秒数千次请求时，会暴露出线程安全、内存泄漏、模型热更新困难、缺乏健康检查等问题。生产环境应优先使用成熟的 Serving 框架（如 Triton Inference Server、TorchServe、TensorFlow Serving、BentoML）。
1.4 低延迟因子评分场景的特殊性
本课程聚焦的“低延迟因子评分”场景（如信用评分、风控评分、广告点击率预估）对 Serving 层有额外的苛刻要求：
- 严格延迟预算：通常要求 P99 延迟 < 20ms，部分场景甚至 < 5ms。
- 高并发峰值：双十一、秒杀等场景下 QPS 可能瞬间飙升 10 倍以上。
- 特征实时计算：评分依赖的因子需要从实时流中计算，不能依赖离线预计算。
- 模型快速迭代：风控规则和评分模型需要小时级更新，不能中断服务。
- 可解释性要求：评分结果需要输出每个因子的贡献度，便于业务人员审核。