跳转至正文

llm-d 0.3: 为可扩展推理提供更宽广的坦途

·阅读时长 10 分钟
Robert Shaw
Robert Shaw
红帽（Red Hat）工程总监
Clayton Coleman
Clayton Coleman
Google 杰出工程师
Carlos Costa
Carlos Costa
IBM 杰出工程师

在我们的 0.2 版本中，我们引入了首批“明径”（well-lit paths），即在 Kubernetes 上扩展推理规模的经过测试的蓝图。随着 0.3 版本的发布，我们加倍履行使命：为部署高性能、硬件无关、易于运维且可大规模扩展的推理提供一条快车道。

此版本交付了：

  • 扩展的硬件支持，现已包括 Google TPU 和 Intel 支持
  • 针对解耦（disaggregation）验证了 TCP 和基于 RoCE 的 RDMA
  • 基于预测延迟的均衡预览版，在长预填充（long-prefill）工作负载中将 P90 延迟提升高达 3 倍
  • 宽专家并行 (EP) 扩展，在 H200 GPU 上实现每秒每 GPU 2.2k token
  • 推理网关 (IGW v1.0) 的正式发布（GA）。

综上所述，这些结果重新定义了推理的运行范畴。llm-d 使集群在扩容前能以更高负载运行，从每个 GPU 中提取更多价值，同时仍能满足严格的延迟目标。其结果是一个不仅为速度而建，而且为可预测、高成本效益的规模化而建的控制平面。

致力使命​

llm-d 的使命是成为一个硬件无关、与上游对齐的推理控制平面。0.3 版本迈出了决定性的一步，不仅扩大了平台覆盖范围，还降低了采用和实验的门槛。

更广泛的硬件支持​

llm-d 的支持现已扩展到更多的加速器系列：NVIDIA、Google TPU 和 Intel XPU。TPU 构建件已在云环境中经过测试，Intel XPU 构建版本也已与 NVIDIA 一起在 CI 运行器中运行。

解耦支持（Disaggregation support）现在更具可移植性。在 0.3 版本中，TCP 和 RoCE 上的 RDMA 已被验证为 prefill/decode 分离的传输方式。这使解耦超出了专门的 InfiniBand 网络结构，为在主流云网络环境中实现可复现的部署开辟了道路。

简化多种基础设施下的用户体验​

推理大语言模型非常复杂——但我们的文档和配置应当保持简单。快速入门已简化并重命名为“指南”，选项更精简，并针对关键决策提供了更多背景信息。这些指南现位于主仓库中，作为针对常见场景不断增长的文档的一部分进行实时维护。由于 llm-d 旨在揭示关键权衡并展示有用模式，我们将每份指南的关键先决条件（集群配置、客户端设置和网关选择）拆分为独立章节，并用更好的分步说明取代了原有的一体化安装脚本。

随着更多集群供应商整合进 llm-d，我们扩展了基础设施文档，增加了特定供应商的故障排除、配置和测试。此版本增加了 CoreWeave、Digital Ocean、Google Kubernetes Engine 和 OpenShift 的文档与操作步骤。

指南现在包含精心筛选的推理网关（Inference Gateway）安装和静态 manifest，以提高清晰度，并为基准测试扫描提供 overlay。RBAC 模式已重构为命名空间作用域，以实现更平滑的多租户管理。

为什么这很重要：在 0.3 版本中，进行智能调度或解耦实验就像运行一份文档指南一样简单。控制平面变得更加透明、可复现且具扩展性，且独立于您运行的平台。

照亮康庄大道 (Well-lit paths)​

我们在 0.2 版本中引入的康庄大道——Wide-EP、智能调度、解耦——现在变得更加清晰且更具复现性。

Wide-EP 性能​

Wide-EP 路径通过在专家（experts）之间实现并行化以最大化吞吐量。在 H200 集群的社区基准测试中，该路径已达到 每张 H200 GPU 2.2k tokens/s。

prefill throughputdecode throughput

这一结果反映了在类似生产环境的设置下多节点部署的持续吞吐量。早期的结果在每张 GPU 1.5k tokens/s 左右波动；跃升至 2.2k 证实了内核优化（silu-mul-quant 融合、Cutlass QKV 内核、TP 注意力机制缺陷修复）以及针对解码增加的双批次重叠（Dual Batch Overlap, DBO）正在产生复合收益。

为什么这很重要：在这样的吞吐量水平下，运营商可以将工作负载整合到更少的节点上，减少给定 QPS 所需的副本数量，并降低单位 token 的成本。

推理网关 v1.0 正式版 (GA)​

在 v0.2 中，我们为推理调度领域带来了许多新特性。在 v0.3 中，推理网关 (IGW) 达到 v1.0 正式版，使智能路由成为 llm-d 中稳定的原语。

Different strategies for balancing
图：在逐步上升的 QPS 速率下测得的 TTFT、TPoT 和吞吐量的三面板对比，比较了负载感知、前缀感知以及前缀+负载感知调度。查看我们的博客 KV-Cache Wins You Can See 了解更多详情。

IGW 与 llm-d 调度器紧密集成，支持负载（KV-cache 利用率和队列长度）和前缀缓存感知调度。基准测试表明，增加前缀感知评分器可实现接近 100% 的 KV 缓存命中率，并且与之前仅基于负载的路由方法相比，显著降低了 TTFT。对于集群级吞吐量，这意味着在更低的延迟分布下实现持续 >60k tokens/s。它还证明了结合前缀和负载感知评分器的重要性，以确保在利用缓存命中的同时不会使副本过载。

为什么这很重要：这是对拥塞做出反应的推理系统与主动将请求引导至缓存复用和并发平衡最佳位置的推理系统之间的区别。对于运营商来说，这意味着更少的缓存缺失、更低的延迟峰值以及可预测的扩展。

基于预测延迟的调度​

我们引入了一种创新的实验性调度评分器，旨在优化延迟。该预测器将输入长度、处理中 (in-flight) 的 token 和并发量整合到一个统一的成本模型中，以预测可用服务器上每个请求的 TTFT 和 TPOT。系统会主动在 25–75% 的饱和度窗口内平衡请求，这是大多数集群运行的区间，也是反应式调度器表现不佳的地方。

Tail latency improvements with predicted latency scheduling 图：在不断增加的 QPS 速率（6 台服务器）下测得的 TTFT 和 TPOT 尾部延迟，针对 4:1 的 ISL:OSL 比例，比较了预测延迟调度与前缀+负载感知调度。

第一张图表显示，在处理平衡的 ISL:OSL工作负载时，新评分器略微改善了尾部延迟。与手动调整的负载和前缀感知评分器相比，它的另一个主要优势是通过自动从摄取的特征中学习阈值来简化配置。这种固有的适应性使其对流量模式的变化更具韧性，并允许更轻松地集成新的调度信号。

随后的图表说明，随着工作负载向更密集的前置填充（prefill）分布转变，新评分器提供了更出色的性能。这是因为与取决于不可预测输出长度的解码时间相比，它能更精确地预测与已知请求长度绑定的前置填充持续时间。

Strong latency improvement for extreme prefill / decode ratios图：在增加的 QPS 速率（6 台服务器）下测得的 TTFT 和 TPOT 尾部延迟，针对 400:1 的 ISL:OSL 比例，比较了预测延迟调度与前缀+负载感知调度。

通过更好的延迟预测，新方法还通过在饱和发生前（而非发生后）更有效地检测饱和，增强了可舍弃工作负载的 SLO 达成能力。

Better saturation anticipation when accelerators are almost full 图：SLO 达成能力（1 台服务器），针对平衡的 ~1:1 ISL:OSL 比例，比较了预测延迟调度与负载感知调度及舍弃机制。

为什么这很重要

  • 用户体验到更稳定、更低的尾部延迟：这对于交互式工作负载至关重要。
  • 运营商可以在扩容前让 GPU 更接近饱和状态，从而降低成本。
  • SLO 从反应式护栏进化为主动调节响应性与稳定性的拨盘。
  • 这为直接响应 SLO 目标的闭环自动扩缩容奠定了基础。

对于模型即服务 (MaaS) 提供商而言，这些提升不仅仅是学术性的，它们直接转化为客户感知的更低波动性和昂贵加速器更高的利用率。

KV 解耦与聊天补全 (Chat Completions)​

KV 路径在 v0.3 中也趋于成熟。同步分词（Synchronous tokenization）稳定了高可用部署中的高效缓存，而精确的前缀缓存感知评分器显著减少了实例间的 KV 缓存重复，并限制了前缀缓存过期压力的影响，显著降低了 TTFT（在我们的基准测试中降低了 57 倍）并使吞吐量翻倍。

该基准测试模拟了一个为 150 个企业客户提供服务的 B2B SaaS 平台，每个客户都有自己的 6,000 token 上下文，并在 5 个并发用户（共 750 个）之间共享。在持续负载下，缓存需求超过了单个实例的容量，迫使进行分布式调度——这测试了系统避免缓存抖动（thrashing）的能力。
Precise prefix caching
图：在高要求基准测试中，随 QPS 速率递增测得的 TTFT、TPoT 和吞吐量三面板图。

Total computational work saved
图：在基准测试过程中，通过集群内有效的 KV 缓存利用所节省的总计算工作量（每秒 token 数）。

为什么这很重要：精确的前缀缓存感知路由提供的更强缓存亲和性保证，在无需使用粗粒度会话保持（sticky sessions）或高昂运维开销的情况下，保持了低延迟。现实世界的聊天补全工作负载可以保持会话保持的高缓存命中率，同时获得基于利用率的平衡，减少热点和产能闲置。

可观测性与基准测试​

这些性能和调度提升的背后，是更强大的可见性和可复现性基础。

  • 可观测性：网关指标现已通过 ServiceMonitor 暴露，文档中发布了 PromQL 查询和 Grafana 仪表板。
  • 基准测试：v0.30 RC1 支持 CI/CD 中的所有“康庄大道”场景。Inference-perf 已通过饱和度测试、追踪重放和更精确的调度进行了强化。

为什么这很重要：运营商现在可以在上线前验证配置，实时监控延迟合规性，并及早发现回归。这确保了“康庄大道”不仅是概念，而且是可复现且生产就绪的。

今天你能得到什么？​

在 v0.3 中，您可以运行、实验并依赖以下内容：

  • 跨平台的硬件支持，涵盖 NVIDIA、Intel XPU 和 Google TPU。
  • 简化的安装流程，提供精选指南、overlay、静态 manifest 和容量规划器。
  • Wide-EP 吞吐量（在多节点 H200 集群上达到每张 GPU 2.2k tokens/s）。
  • 推理网关 v1.0 正式版，具有缓存感知路由和稳定的 API。
  • 自适应 SLO 预测器（预览版），在长前置填充工作负载中显示出高达 3 倍的 P90 延迟提升。
  • KV 解耦，支持同步分词、精确评分器和聊天补全。
  • 基于 TCP 和 RDMA/RoCE 的解耦，扩展到了 InfiniBand 网络之外。
  • 带有 ServiceMonitor 和 Grafana 仪表板的可观测性工具。

接下来的计划？​

虽然 v0.3 稳定了现有的“康庄大道”，但社区也在为未来的道路奠定基础：

  • vLLM 中的原生 CPU 卸载：异步 KV 传输 API 和 CPU 缓冲区传输正在评审中，通过 KV 事件实现调度器感知的 CPU 内存缓存溢出。
  • 延迟解码和异步协议：正在进行设计工作，以实现更精细的调度控制，并在 vLLM 中开发更底层的“tokens in / tokens out”服务引擎，用于大规模多模态服务。
  • 公共性能数据库：基于基准测试套件，提供跨平台透明、可复现的性能数据。
  • 自动扩缩容孵化：WVA 自动扩缩容组件已与 Kubernetes HPA 集成；展示了缩容至零的能力。下一步包括将自动扩缩容决策直接与自适应 SLO 挂钩。

如果您有希望我们关注的领域，请在我们的 0.4 版本追踪议题中提出建议。

社区与近期活动​

llm-d 的力量源于其社区。v0.3 反映了越来越多贡献者和合作者的努力。感谢每一位提供帮助的人！

即将到来的亮点包括 llm-d 会议、All Things Open（2025年10月12-14日）、PyTorch 大会（2025年10月22-23日）、AMD AI 开发者日（10月20日）和 Kubecon 2025（11月10-14日）。您可以在我们的社区活动页面关注这些及其他活动。

在 GitHub 上参与贡献，参加我们的社区会议（东部时间周三中午 12:30），加入特别兴趣小组（SIG），与我们一起建设！