3. 推理服务概述

在讨论大规模 GPU 集群的推理服务性能优化之前，必须先厘清推理（Inference）与训练（Training）在系统层面的本质差异。许多性能优化的误判，都源于将训练场景的直觉直接套用到推理场景。本章从三个维度展开：推理与训练的系统性区别、推理服务的典型架构分层、以及衡量推理服务质量的核心性能指标。

3.1 推理与训练的系统性区别

训练的目标是收敛，推理的目标是稳定地满足业务请求。这一根本差异决定了它们在资源调度、容错策略、数据流形态上的不同设计。

维度 训练（Training） 推理（Inference）
目标 最小化损失函数，达到模型精度 在满足延迟/吞吐约束下，输出预测结果
数据流 海量样本反复迭代，批处理（Batch）大且固定 在线请求到达，Batch 动态组合，受流量影响
计算模式 前向 + 反向传播，计算密集，可容忍长时间运行 仅前向传播，计算相对轻量，但对时延敏感
容错策略 检查点（Checkpoint）保存，失败后回滚重训 请求级超时、重试、降级，不能整体回滚
资源特征 长期占用 GPU，利用率优先，可排队等待 需要预留资源应对峰值，利用率与延迟互相制约
批处理策略 固定 batch size，追求吞吐最大化 动态 batching，需权衡等待时间与吞吐

一个典型的误区是：认为推理服务只要把训练好的模型加载到 GPU 上就能直接对外服务。实际上，训练时模型权重是静态的，而推理服务需要处理并发请求、动态批处理、模型版本切换、GPU 显存碎片等一系列工程问题。训练集群可以接受任务排队，但推理服务面对的是实时用户请求，排队超过阈值就意味着 SLA 违约。

3.2 推理服务架构分层

一个生产级推理服务通常分为四个逻辑层，每一层都有独立的性能瓶颈和优化空间。

3.2.1 接入层（Ingress）

负责接收外部请求，进行鉴权、限流、协议转换。这一层通常是 CPU 密集，瓶颈在 HTTP 解析和序列化。常见的优化手段包括：使用 gRPC 替代 HTTP/1.1、连接复用、请求压缩。

3.2.2 调度与批处理层（Scheduler & Batcher）

这是推理服务区别于训练的核心层。调度器将多个请求动态组合成 batch，送入 GPU 执行。关键参数包括：max_batch_size、max_queue_delay（最大排队等待时间）、preferred_batch_size。调度策略直接影响 GPU 利用率和请求延迟的平衡。

# 以 Triton Inference Server 为例的调度配置片段
dynamic_batching {
  preferred_batch_size: [4, 8, 16]
  max_queue_delay_microseconds: 500
}

上述配置表示：优先凑齐 4、8、16 的 batch 再执行，但如果等待超过 500 微秒，即使 batch 未满也立即执行。这种机制避免了“为了凑 batch 而无限等待”的延迟陷阱。

3.2.3 模型执行层（Model Executor）

实际运行模型前向推理的引擎，可以是 TensorRT、ONNX Runtime、PyTorch 等。这一层的性能取决于算子融合、精度校准（FP16/INT8）、显存复用等。执行层通常与 GPU 硬件绑定，是性能优化的主战场。

3.2.4 后处理与返回层（Post-processing）

对模型输出进行解码、过滤、排序等操作。在 NLP 场景中，后处理可能包含 解码和文本生成；在 CV 场景中可能包含 NMS（非极大值抑制）。这一层容易被忽略，但在某些场景下（如生成式模型）其耗时占比可达 30% 以上。

3.3 核心性能指标

推理服务的性能评估不能只看单一数字，需要从延迟、吞吐量、利用率三个维度综合衡量，且三者之间存在相互制约关系。

3.3.1 延迟（Latency）

延迟是单个请求从发出到收到完整响应的时间。但实际工程中，我们更关注分位数延迟而非平均值。P99 延迟（99% 的请求延迟低于该值）比平均延迟更能反映用户体验，因为长尾延迟往往由资源争抢、GC 暂停、网络抖动引起。

实践建议：监控延迟时，至少同时观察 P50、P95、P99 三个分位数。如果 P99 远高于 P50（例如 5 倍以上），说明系统存在明显的排队或资源争抢现象，需要检查批处理策略或 GPU 利用率是否过高。

3.3.2 吞吐量（Throughput）

吞吐量是单位时间内系统能处理的请求数，通常以 QPS（Queries Per Second）或 tokens/s（生成式模型）衡量。吞吐量与延迟存在倒挂关系：当系统接近饱和时，吞吐量继续上升，但延迟会急剧恶化。因此，吞吐量的评估必须与延迟约束绑定，例如“在 P99 延迟小于 100ms 的前提下，最大 QPS 为 5000”。

3.3.3 利用率（Utilization）

利用率包括 GPU 计算利用率、显存利用率、带宽利用率。但需要注意：GPU 利用率高并不等于性能好。如果利用率高是因为请求排队等待执行，那么利用率虚高而实际吞吐并未提升。更合理的指标是“有效利用率”——即 GPU 实际执行计算的时间占比，而非任务在 GPU 上排队的时间占比。

# 通过 nvidia-smi 观察 GPU 利用率
nvidia-smi --query-gpu=index,utilization.gpu,memory.used --format=csv -l 1

# 输出示例
# 0, 98%, 15360 MiB
# 1, 45%, 8192 MiB

上述输出中，GPU 0 利用率 98% 看似健康，但如果此时请求延迟飙升，说明 GPU 0 可能已经过载，请求在排队。而 GPU 1 利用率 45%，可能还有余量，但需要检查是否因为 batch 太小导致计算效率低下。

3.4 性能指标间的权衡与典型案例

在实际部署中，三个指标往往无法同时最优。以下是一个典型的在线推荐系统推理服务的案例：

  • 场景：电商推荐服务，要求 P99 延迟 < 50ms，日均请求量 1 亿次。
  • 初始配置：单 GPU 部署，动态批处理最大 batch 为 32，最大排队延迟 2ms。
  • 问题：高峰期 P99 延迟飙升至 200ms，但 GPU 利用率仅 60%。

排查过程如下：

  1. 首先检查批处理统计，发现平均 batch 大小仅为 6，远低于配置的 32。原因是请求到达间隔不均匀，2ms 的排队窗口内凑不齐大 batch。
  2. 进一步分析发现，模型执行时间仅 8ms，但请求在调度队列中的平均等待时间高达 40ms。瓶颈不在 GPU 计算，而在调度策略过于保守。
  3. 调整策略：将 max_queue_delay 从 2ms 提升到 8ms，同时将 preferred_batch_size 调整为 [8, 16]。这样允许请求等待更长时间以凑成更大的 batch，虽然单请求等待时间增加，但 GPU 利用率提升至 85%，整体吞吐提升 40%。
  4. 最终效果：P99 延迟稳定在 45ms，满足 SLA，同时 GPU 利用率提升。
关键教训：不要盲目追求 GPU 利用率最大化。在本案例中，如果继续增大 batch 或延长排队时间，虽然利用率可能达到 95% 以上，但 P99 延迟会突破 50ms 的 SLA 红线。利用率是手段，延迟和吞吐才是最终目标。合理的做法是设定延迟上限，然后在该约束下最大化吞吐。

3.5 常见误区与复盘

在推理服务的性能评估与优化中，以下误区反复出现：

  • 误区一：用平均延迟评估服务质量。平均延迟掩盖了长尾问题，一个 P99 延迟 500ms 的系统平均延迟可能只有 50ms，但用户体验已经严重受损。
  • 误区二：忽略批处理对延迟的影响。动态批处理虽然提升吞吐，但每个请求的等待时间会随 batch 目标增大而增加。必须设置合理的最大排队延迟。
  • 误区三：将 GPU 利用率等同于系统性能。利用率高可能是由于请求堆积，而非计算效率高。应结合队列长度和请求等待时间一起分析。
  • 误区四：只关注模型计算时间，忽略前后处理。在生成式模型（如 LLM）中， 解码和采样后处理可能占据端到端延迟的很大比例。

正确的评估流程应当是：先明确业务 SLA（延迟分位数、吞吐目标），再通过压测工具（如 wrk、ghz、locust）模拟真实流量，采集延迟分布、吞吐量、GPU 利用率、队列深度等多维数据，最后针对瓶颈层进行定向优化。优化后必须回归验证，确保延迟分位数和吞吐量同时满足要求，而非只改善单一指标。

← 上一章 📖 返回目录 下一章 →