模型serving与策略编排集成教程 - 第1节
1.1 模型服务的定义
模型服务（Model Serving）是指将训练完成的机器学习或深度学习模型部署到生产环境中，对外提供稳定、低延迟、高并发的推理预测能力的过程。它是连接模型开发与业务应用的桥梁，也是 AI 系统落地的最关键一环。
从技术架构角度看，模型服务包含以下核心要素：
- 模型加载与生命周期管理：将模型文件（如 .pt、.h5、.onnx）加载到内存或显存，管理热加载、版本切换与卸载。
- 推理引擎：执行前向计算，通常依赖 TensorRT、ONNX Runtime、OpenVINO 等加速库。
- 请求预处理与后处理：对输入数据进行格式转换、归一化、Tokenization，对输出进行解码、阈值过滤、排序。
- 服务接口：通过 HTTP/REST、gRPC、WebSocket 等协议暴露推理能力。
- 资源调度与弹性伸缩：根据请求量动态分配 GPU/CPU 资源，支持自动扩缩容。
关键认知： 模型服务不是简单的“模型加载 + API 封装”，而是涉及资源管理、请求批处理、容错降级、版本灰度、监控告警的系统工程。
1.2 模型服务在 AI 系统中的核心作用
在完整的 AI 系统中，模型服务处于承上启下的枢纽位置。下图展示了模型服务在典型 AI 系统架构中的位置与交互关系：
模型服务的核心作用可以归纳为以下四点：
| 作用维度 | 具体说明 | 典型场景 |
|---|---|---|
| 推理加速 | 利用算子融合、量化、动态批处理等技术降低单次推理延迟 | 实时推荐、在线翻译 |
| 资源隔离 | 多模型共享 GPU 时通过显存隔离和调度避免相互干扰 | 多租户 SaaS 平台 |
| 版本管理 | 支持多版本模型同时在线，按流量比例分发请求 | A/B 测试、模型灰度 |
| 弹性伸缩 | 根据请求量自动扩缩容器实例，平衡成本与性能 | 电商大促、流量波峰 |
1.3 模型服务与传统 Web 服务的区别
虽然模型服务通常也基于 HTTP/gRPC 对外暴露接口，但其内部机制与传统的 Web 服务存在本质差异。下表从多个维度进行对比：
| 对比维度 | 传统 Web 服务 | 模型服务 |
|---|---|---|
| 核心负载 | CPU 密集型（字符串处理、数据库查询） | GPU 密集型（矩阵运算、张量计算） |
| 状态管理 | 无状态为主，易于水平扩展 | 有状态（模型加载到显存），扩缩容需重新加载 |
| 启动时间 | 秒级（应用启动 + 连接池初始化） | 分钟级（模型文件加载 + 引擎编译 + 显存预热） |
| 批处理 | 通常单请求单响应 | 支持动态批处理，合并多个请求一次推理 |
| 资源需求 | CPU、内存、网络带宽 | GPU 显存、CUDA 核心、NVLink 带宽 |
| 版本策略 | 滚动更新，新版本替换旧版本 | 多版本共存，按流量比例分发 |
| 失败处理 | 重试、熔断、降级 | 降级到规则引擎或缓存结果，避免冷启动 |
常见误区： 很多团队将模型服务当作普通 Web 服务开发，使用 Flask/FastAPI 直接加载模型。这种做法在原型阶段可行，但在生产环境中会面临显存泄漏、请求排队超时、GPU 利用率低等问题。生产级模型服务需要专门的推理框架（如 Triton Inference Server、TorchServe、MLflow Serving）来管理模型生命周期和资源调度。
下图从请求处理流程的角度，直观对比传统 Web 服务与模型服务的内部差异：
1.4 模型服务的典型架构模式
根据业务场景的不同，模型服务通常采用以下三种架构模式：
- 单体推理服务：模型与 Web 框架耦合在同一进程中，适合小流量、低并发场景。
- 模型服务 + 业务网关：模型服务独立部署，通过 API 网关进行路由、限流和鉴权，适合中等规模。
- 推理微服务网格：多模型独立部署，通过服务网格（如 Istio）进行流量管理和灰度发布，适合大规模生产环境。
选型建议： 初创团队或原型阶段可使用单体推理服务快速验证；当模型数量超过 5 个或 QPS 超过 1000 时，建议切换到独立模型服务架构；当需要多模型组合推理（如特征模型 + 主模型 + 排序模型）时，推理微服务网格是更优选择。