Stanford CS25: Serving Transformers - Lessons from the Trenches

Executive Summary

在大规模部署 transformer 模型时，需要从关注模型能力转向优化生产推理的“乏味基础设施”。核心挑战在于 prefill（输入处理）阶段与 decode（令牌生成）阶段之间的差距，decode 阶段通常受内存带宽限制，导致硬件利用率低下。通过定义明确的工作负载（使用服务水平目标 SLO），根据效率与能力的界限选择模型，并采用投机解码、量化等激进优化技术，才能在生产推理中取得成功。

Defining Inference Workloads and SLOs

有效的推理工程始于对工作负载的清晰定义，这决定了硬件和软件架构。工作负载大致分为三类原型：

• Chatbot Plus: 人机交互系统（如 ChatGPT、Claude），主要指标是交互性，以每位用户每秒输出的 token 数衡量。
• Background Agents: 在秒或分钟尺度上完成复杂任务的系统（如编码代理），主要指标是最后一个 token 的耗时。
• Data Processors: 高吞吐、突发性的工作负载（如文档索引），主要指标是整体吞吐量，常以每美元产生的 mega‑token 计。

Key Performance Metrics

为管理这些工作负载，工程师必须跟踪每个副本的特定指标，以决定如何扩展系统：

• Time to First Token (TTFT): 用户看到首个输出字节前的延迟。
• Inter-token Latency: 连续 token 之间的间隔时间。
• Queries Per Second (QPS): 请求量，通常具有强季节性和波动性。
• Prefix Reuse: 输入 token 重叠的频率，可通过 KV 缓存降低计算成本。

Model Selection: Efficiency vs. Capability Bounds

模型选择取决于任务是受效率限制还是受能力限制：

Efficiency-Bound Workloads

在这些任务中，所需的智能水平相对较低且易于实现，成本成为主要驱动因素。这类工作负载通常使用开源模型（如 Mistral、Gemma），并常在单 GPU 副本上运行，以最大化性价比。

Capability-Bound Workloads

这些任务需要最高可用的智能水平，当前唯一的解决方案是规模化。这类模型（如前沿专有模型）体积庞大，需要每个副本多 GPU，甚至多节点。它们通常在多代理系统中充当协调者，管理更小的、受效率限制的子代理。

The Inference Stack: Engines and Hardware

Inference Engines

推理引擎由 token 化服务器进程、CPU 调度器以及 GPU 执行组成。调度器的主要职责是确保 GPU 永不空闲。当前领先的开源引擎包括：

• vLLM: 采用开放治理，广受采用。
• SGLang: 高性能导向，拥有激进的优化。
• TensorRT-LLM: NVIDIA 提供的 C++ 编译运行时，针对小模型和小批量最优。

Hardware Constraints

生产推理主要使用 NVIDIA 数据中心 GPU（SXM 形态），因为其高带宽内存（HBM）。decode 阶段严重受内存带宽限制；虽然 Tensor Core 每字节可执行数千次运算，decode 阶段却只执行少量运算。因此 HBM 与高速互连（NVLink）对避免计算单元空闲至关重要。

Deployment and Robustness at Scale

部署成千上万的 GPU 会带来显著的可靠性和成本挑战：

• Hardware Failure: H100 GPU 的平均故障间隔只有几天到几周。系统必须具备冗余设计，确保硬件故障不导致系统整体失效。
• Cold Start and Scaling: 为了在不浪费空闲 GPU 资源的前提下应对流量波动，系统需要快速启动副本。这通过惰性加载文件系统、多层云缓存以及 checkpoint‑restore 技术（如 CRIU）实现，避免数分钟的 JIT 编译和 CUDA graph 捕获时间。

Performance Optimization Techniques

优化应遵循层级结构：先从高影响的算法改动入手，再到主机端工程，最后是低层内核工作。

Speculative Decoding

投机解码旨在缓解 decode 阶段的内存带宽瓶颈。一个小的“草稿”模型预测接下来的若干 token，随后更大的目标模型在一次前向传播中验证这些预测。此技术可实现 2×‑8× 的加速，尤其在使用特定应用的草稿模型时效果显著。

Quantization

降低精度（例如从 FP8 降至 FP4）在内存受限和计算受限场景下均能提供线性加速，因为它减少了传输的字节数并提升了每秒运算次数。然而，这需要通过“vibe check”与正式评估来谨慎验证，因为量化可能在长序列上因误差累积而导致性能下降。

Host-Side Optimization

在编写自定义 CUDA 内核之前，工程师应使用 py-spy 等工具定位 Python 层的瓶颈。简单的改动，如在字典中缓存指针而不是每次重新创建张量，能够带来显著收益（例如在多模态推理中提升约 10%），且无需修改 GPU 端代码。

Observability and Debugging

可观测性被定义为仅凭日志即可调试系统的能力。关键实践包括：

• Logging Token IDs: 仅记录字符串不足以调试细微的 tokenizer 与聊天模板错误，必须记录 token ID。
• Monitoring Power Draw: GPU 功耗和温度是“免费”指标，可指示主机端瓶颈（例如 GPU 实际功耗为 2 kW 而非 3 kW，说明 CPU 未能充分供给工作负载）。
• Evaluating Tails: P95 与 P99 延迟至关重要，因为它们代表用户的“卡顿”体验，即使中位数（P50）延迟很低。

---

SUMMARY:

Modal 的 Charles Frye 讨论了在大规模服务 transformer 模型时的工程挑战，重点在于 prefill 与 decode 阶段的关键区别以及硬件利用率的优化。

TITLE:

Stanford CS25: Serving Transformers - Lessons from the Trenches