1. Model Serving 概述
1.1 Model Serving 的定义
Model Serving（模型服务）是指将训练完成的机器学习模型部署到生产环境中，通过标准接口（如 HTTP/REST、gRPC）对外提供实时或批量推理能力的过程。它不仅仅是模型文件的加载与运行，还涉及请求管理、资源调度、版本控制、监控告警等系统工程。
核心认知：Model Serving 是连接“模型开发”与“业务应用”的桥梁。一个模型在离线训练中达到 99% 的准确率，若无法在生产环境中稳定、低延迟地提供服务，其业务价值将归零。
1.2 典型架构：客户端 — 服务端 — 模型仓库
现代 Model Serving 系统普遍采用三层解耦架构，各层职责清晰，便于独立扩展与运维。
| 层级 | 组件 | 核心职责 | 典型技术 |
|---|---|---|---|
| 客户端层 | 应用 / API 网关 | 发起推理请求、预处理输入、解析响应 | Python SDK、Java Client、Nginx |
| 服务端层 | 推理引擎 / 调度器 | 请求排队、模型加载、批处理、资源分配 | Triton Inference Server、TorchServe、Seldon Core |
| 模型仓库层 | 对象存储 / 版本管理 | 存储模型文件、管理版本、支持热加载 | S3、MinIO、MLflow Model Registry |
1.3 性能调优的重要性
在生产环境中，模型推理性能直接决定用户体验与运营成本。未经调优的 Model Serving 系统常面临以下问题：
- 响应超时：单次推理延迟过高，导致客户端请求堆积，最终触发上游熔断。
- 资源浪费：GPU 利用率不足 20%，大量算力闲置，但用户仍感受到高延迟。
- 吞吐瓶颈：无法应对流量突发，QPS 在峰值时断崖式下跌。
- 成本失控：为满足 SLA 盲目增加实例，导致部署成本线性增长。
常见误区：很多团队只关注模型本身的推理速度（如毫秒级），却忽略了请求排队、网络传输、模型加载、资源争抢等环节的累积开销。性能调优必须从端到端视角出发。
1.4 核心性能指标
衡量 Model Serving 系统性能的三大核心指标构成“不可能三角”，调优的本质是在三者之间寻找业务可接受的平衡点。
| 指标 | 定义 | 常用单位 | 业务影响 |
|---|---|---|---|
| 延迟 (Latency) | 从客户端发送请求到收到完整响应的总耗时 | 毫秒 (ms) | 直接影响用户体验，通常要求 P99 < 200ms |
| 吞吐量 (Throughput) | 单位时间内系统成功处理的请求数量 | QPS / RPS | 决定系统容量与并发处理能力 |
| 资源利用率 (Utilization) | GPU/CPU/内存等资源在推理过程中的实际使用比例 | 百分比 (%) | 直接影响部署成本与能效比 |
1.5 指标间的关系与权衡
在实际调优中，三个指标并非独立变化，而是存在明确的制约关系：
- 延迟 vs 吞吐量：增大批处理大小（batch size）可提升吞吐量，但会线性增加单次请求的排队等待时间，导致 P99 延迟上升。
- 延迟 vs 资源利用率：预留过多资源可保证低延迟，但利用率下降；反之，满载运行可提高利用率，但请求争抢资源会导致延迟抖动。
- 吞吐量 vs 资源利用率：两者通常呈正相关，但存在边际递减效应——当利用率超过 80% 后，吞吐量增长趋缓，延迟却急剧恶化。
调优目标示例：某推荐系统要求 P99 延迟 ≤ 100ms，在此约束下最大化吞吐量，同时将 GPU 利用率维持在 60%~80% 之间。这通常需要结合动态批处理、模型量化、请求优先级调度等多项技术。
1.6 性能调优的通用方法论
本课程将遵循以下四步调优框架，贯穿后续所有章节：
- 基准测试与瓶颈定位：使用压测工具（如 Locust、wrk）建立性能基线，通过 Profiling 工具（如 Nsight、PyTorch Profiler）定位瓶颈。
- 单点优化：针对瓶颈环节（如模型推理、数据预处理、网络传输）进行专项优化。
- 系统级调优：调整批处理策略、并发模型、资源分配等全局参数。
- 持续监控与迭代：部署后通过指标监控（如 Prometheus + Grafana）持续跟踪，根据业务流量变化动态调整。