推理服务基础：定义、架构与性能指标
2.1 什么是推理服务
推理服务（Inference Service）是将训练完成的机器学习模型部署到生产环境，对外提供实时或批量预测能力的软件系统。与训练阶段不同，推理服务面对的是持续到达的请求流量，需要在满足延迟、吞吐和资源约束的前提下，稳定地完成模型前向计算并返回结果。推理服务不是简单的“模型加载 + HTTP 接口”，而是一个包含请求接收、预处理、模型执行、后处理、结果返回、监控告警等环节的完整工程系统。
一个典型的推理服务生命周期包含以下环节：
- 模型导出：将训练框架（PyTorch、TensorFlow）的权重转换为推理引擎可加载的格式（如 ONNX、TorchScript、TensorRT Engine）。
- 服务封装：定义输入输出 Schema，实现预处理（图像缩放、文本 Tokenize）与后处理（Softmax、NMS）。
- 引擎加载：将模型加载到 GPU/CPU 显存或内存，完成算子图优化与显存预分配。
- 服务暴露：通过 HTTP/gRPC 协议暴露预测接口，支持健康检查、指标上报。
- 弹性伸缩：根据流量动态调整副本数，或利用 GPU 批处理（Dynamic Batching）提升吞吐。
2.2 推理服务架构分层
推理服务的架构可以抽象为四个层次，每一层都可能成为性能瓶颈。下图展示了从客户端到 GPU 计算资源的完整链路，以及各层的关键组件与交互关系。
各层职责与性能关注点如下：
| 架构层 | 核心组件 | 主要性能瓶颈 |
|---|---|---|
| 客户端层 | App、Web、内部服务 | 网络延迟、请求超时设置、重试策略 |
| 网关路由层 | LB、API Gateway、限流 | 连接数限制、转发开销、队列堆积 |
| 推理引擎层 | 请求队列、预处理、模型执行、后处理 | Batch 策略、框架调度、GPU Kernel 效率 |
| 资源监控层 | GPU/CPU、显存、监控系统 | 显存带宽、SM 占用率、资源碎片 |
2.3 三大核心性能指标
推理服务的性能评估围绕三个核心维度展开：延迟（Latency）、吞吐量（Throughput）和资源利用率（Resource Utilization）。三者相互制约，调优的本质是在它们之间寻找业务可接受的最优平衡点。
2.3.1 延迟（Latency）
延迟指从客户端发送请求到收到完整响应所经历的时间，通常以毫秒（ms）为单位。在工程实践中，需要区分以下几种延迟概念：
- 端到端延迟：客户端发起请求到收到响应的总时间，包含网络传输、网关转发、排队、推理计算等所有环节。
- 服务端延迟：请求到达服务端到响应离开服务端的时间，通常通过中间件埋点统计。
- 纯推理延迟：模型前向计算消耗的时间，可通过 Profiling 工具单独测量。
- P99/P95 延迟：99%/95% 请求的延迟低于该值，比平均延迟更能反映长尾问题。
延迟的测量需要关注分布而非仅看平均值。例如，某服务平均延迟 50ms，但 P99 延迟达到 800ms，说明存在严重的尾延迟问题，可能由 GC 暂停、GPU 争用或网络抖动引起。
2.3.2 吞吐量（Throughput）
吞吐量指单位时间内服务能处理的请求数量，常用指标为 QPS（Queries Per Second）或 RPS（Requests Per Second）。吞吐量的上限取决于系统瓶颈资源——可能是 GPU 计算能力、显存带宽、CPU 预处理能力或网络带宽。提升吞吐量的常用手段包括：
- 动态批处理（Dynamic Batching）：将多个请求合并为一个 Batch 执行，摊薄 Kernel 启动开销。
- 并发执行：多模型实例并行处理不同请求。
- 异步推理：将请求放入队列后立即返回，由后台线程池消费。
- 模型优化：量化（INT8/FP16）、剪枝、算子融合。
2.3.3 资源利用率（Resource Utilization）
资源利用率衡量推理服务对硬件资源的有效使用程度。对于 GPU 推理服务，关键指标包括：
| 指标 | 含义 | 健康参考范围 |
|---|---|---|
| GPU 利用率（SM 占用） | 流式多处理器处于活跃状态的时间占比 | 70% ~ 95% |
| 显存占用率 | 已用显存 / 总显存 | 60% ~ 90% |
| GPU 显存带宽利用率 | 实际带宽 / 峰值带宽 | 50% ~ 80% |
| CPU 利用率 | 预处理/后处理消耗的 CPU 资源 | < 70%（避免 CPU 瓶颈） |
2.4 性能指标间的权衡关系
延迟、吞吐和资源利用率之间存在经典的权衡关系。增大 Batch Size 可以提升吞吐量和 GPU 利用率，但单个请求的排队时间变长，导致延迟上升。反之，追求极低延迟（如 Batch Size = 1）会牺牲吞吐量和资源效率。下图展示了这一权衡关系及调优方向：
在实际调优中，通常先确定业务的延迟上限（SLA），再在该约束下最大化吞吐量和资源利用率。例如，某推荐系统要求 P99 延迟 < 100ms，那么调优过程就是寻找满足该延迟约束的最大 Batch Size 和最优并发数。
2.5 案例：图像分类服务的性能画像
假设我们部署了一个基于 ResNet-50 的图像分类服务，使用单张 NVIDIA A10 GPU，初始配置为 Batch Size = 1，并发请求数 = 4。通过监控工具采集到以下数据：
指标项 当前值 参考范围
--------------------------------------------------------
QPS 85 -
P99 延迟 45 ms < 100 ms
GPU 利用率 32% 70% ~ 95%
显存占用 4.2 GB / 24 GB
CPU 利用率 55% < 70%
GPU 带宽利用率 28% 50% ~ 80%从数据可以看出，GPU 利用率和带宽利用率均偏低，说明计算资源未被充分利用。通过逐步增大 Batch Size 到 8，并开启动态批处理，QPS 提升至 320，GPU 利用率达到 78%，P99 延迟为 85ms，仍在 SLA 范围内。这个案例展示了典型的“先看资源利用率，再调批处理”的调优路径。