llm-d 0.4: 在各类加速器上实现 SOTA 性能
llm-d 的使命是在任何加速器和云端提供达到 SOTA 推理性能的最快路径。在我们的 0.3 版本 中，我们为大型混合专家模型（MoE）实现了广泛的专家并行（EP），以提供极高的输出 Token 吞吐量——这是强化学习的关键推动因素——并增加了对多个非 GPU 加速器系列的初步支持。
本版本带来了对专家并行吞吐量的补充：提升生产服务的端到端请求延迟。通过推测解码（speculative decoding）和针对延迟敏感型工作负载的 vLLM 优化，我们将 DeepSeek 的单 Token 延迟降低了高达 50%。我们增加了对 Google TPU 和 Intel XPU 的动态解耦服务支持，以便在流量不可预测时进一步降低首 Token 延迟（TTFT）；同时，我们新的前缀缓存卸载“坦途”指南可帮助您利用 CPU 内存和高性能远程存储来提高命中率并降低尾部延迟。对于部署了多个模型的使用者，我们的工作负载自动扩缩器预览版会根据实时服务器容量和流量进行调整，以减少模型部署排队请求的时间，从而减轻在有限加速器容量上运行多个模型的运维负担。
这些通过我们的 坦途（well-lit paths） 呈现的开源推理栈优化，确保您能在现实场景中的前沿开源模型上达到 SOTA 级的延迟水平。
大型 MoE 的 SOTA 低延迟服务
虽然之前的版本专注于吞吐量，但 v0.4 交付了保证超低延迟所需的特性，特别是针对要求苛刻的宽专家并行 MoE 模型。
我们在 vLLM 中集成了针对 MoE 模型的高级低延迟优化，并观察到 DeepSeek V3.1 在 H200 GPU 上的单 Token 延迟降低了 40% 以上。
- 推测解码 (Speculative decoding)：在低并发时利用未充分使用的算力运行较小的“草稿”模型并预测下一个有效 Token——正确的预测验证成本更低，从而降低了每个输出 Token 的延迟。我们还测试并改进了多项 MoE 特定优化，包括 DeepSeek 的原生 MTP 支持。我们启动了 speculators 开源项目，以扩大流行模型对推测解码的支持，并不断在我们的 Hugging Face Hub 中添加新架构。
- 异步调度： 在 vLLM 中集成异步调度可以实现计算和 CPU 调度操作的更高效重叠，确保系统在保持低延迟的同时维持高请求率。
- Block-FP8 内核优化： 融合关键的逐元素操作，将共享专家计算与分组专家路由重叠，并选择更高效的内核。
关于延迟调优的建议和权衡将成为 llm-d 下一版本中的一条“坦途”指南。
扩展硬件选择
社区 持续集成对各种加速器 和 提供商 的支持，使 llm-d 成为权威的硬件无关控制平面。
- 通过 DCN 实现 Google TPU 解耦： 我们将最新的 vLLM + TPU 架构与我们的 llama3-70b 动态解耦方案 集成，支持通过数据中心 TCP 进行高性能 KV 缓存传输，并允许根据 Prefill 负载按需扩展 Prefill 实例。
- Intel XPU 集成： 为智能调度和解耦“坦途”提供 初步支持 和验证。
- AWS EFA 支持： 以 NIXL libfabric 库的形式在 llm-d CUDA 镜像中添加了对 AWS Elastic Fabric Adapters (EFA) 的支持，以在 AWS 加速器集群上实现低延迟通信，完整 EFA 支持将在未来版本中推出。
扩展坦途指南
新增前缀缓存卸载坦途指南
对于长上下文或高并发的多轮工作负载，GPU 显存是瓶颈。为了解决这个问题，我们建议在 llm-d v0.4 中将 分层前缀缓存卸载 (tiered prefix-cache offloading) 作为标准实践。
我们在一条新的“坦途”下规范了 vLLM 原生 CPU 卸载 和 LMCache 连接器，允许系统透明地利用通常未被充分利用的主机 CPU RAM 作为 KV 缓存的二级存储层。llm-d 不会在显存填满时丢弃上下文，而是允许您将块交换到 CPU 并在需要时检索它们。
在我们的 用户指南基准测试 中，当 KV 缓存工作集超过可用 HBM 容量时，启用 CPU 卸载使 平均首 Token 延迟 (TTFT) 降低了 25%，并将 总吞吐量提高了 21%。
| HBM < KVCache < HBM + CPU RAM | 平均 TTFT (秒) | P90 TTFT (秒) | 平均端到端延迟 (秒) | P90 端到端延迟 (秒) | 总吞吐量 (token/秒) |
|---|---|---|---|---|---|
| 基准 vLLM | 9.0 | 20.9 | 37.8 | 49.7 | 38534.8 |
| vLLM + 100GB CPU 卸载 | 6.7 (-25.6%) | 20.2 (-3.3%) | 30.9 (-18.3%) | 44.2 (-11.1%) | 46751.0 (+21.3%) |
| vLLM + 100GB LMCache CPU 卸载 | 6.5 (-27.8%) | 18.8 (-10.0%) | 30.8 (-18.5%) | 43.0 (-13.5%) | 46910.6 (+21.7%) |
表：高性能模式 比较了当 KVCache 大小大于可用 HBM 时，基准 vLLM 与使用 CPU 卸载连接器的 vLLM 性能。)
通过将 CPU 内存视为 GPU 的活动扩展，运营商可以在现有硬件上运行更大的模型或更高的并发，显著提升“单美元 Token 数”价值。这为更深层次的分层策略奠定了基础，包括即将推出的分布式存储卸载指南。
增强的智能调度
为了补充新的卸载功能，我们更新了 智能推理调度 坦途指南，以充分利用分层存储架构。
- 层感知精度： 前缀缓存亲和性现在考虑了新缓存层的成本动态。我们通过 可配置的加权评分 实现了细粒度的 KV 缓存跟踪（例如，GPU 命中的权重高于 CPU 命中）。这允许路由器计算 KV 检索的最有效路径，平衡驻留在 GPU 的数据的高价值与 CPU 层的可用容量。
借鉴广泛的基准测试数据，我们还改进了 面向负载的分发 评分器，强调：
- 饱和稳定性： 我们引入了
no-hit-lru-scorer。该评分器智能地分发“冷”请求（形成新前缀缓存轨迹的种子），以防止缓存形成期间出现热点。这消除了波动的等待队列，使集群能够 在具有前缀重用机会的工作负载中，在相同硬件上以更高的并发维持稳定性。
对于具有 前缀重用机会 的工作负载，这种改进的放置逻辑将 P99 首 Token 延迟 (TTFT) 降低了一半（18.3s -> 8s），同时在峰值并发下保持稳定。
基准测试对比：在 16 个 NVIDIA H100 GPU 上运行 8 个 Qwen-32B，在 50 QPS 下使用 5500:1000 ISL/OSL 请求，共享 150 个唯一前缀。v0.4 调度器（下方）消除了 v0.3 中出现的等待队列波动，使 P99 TTFT 降低了 50%。
llm-d v0.3 中冷前缀缓存请求的高排队情况
llm-d v0.4 中冷前缀缓存请求排队情况显著减少
针对依赖前缀缓存的工作负载配置适当评分的最佳实践和基准测试计划在我们的下一个版本中推出。
基准测试与验证
为了帮助社区了解分布式推理中的权衡，我们正在简化对坦途指南的基准测试。llm-d-benchmark 提供了使用“实验设计”方法进行性能表征所需的所有工具，确保结果可重现且标准化。
- 全面自动化： 我们现在在多种场景下，使用支持的测试框架（如 inference-perf, guidellm, vllm-benchmark 和 inferenceMAX），全面自动化 llm-d 坦途指南的设置和执行。
- 灵活执行： 新指南涵盖了自动化栈设置、针对现有栈运行以及交互式基准测试。
- 数据驱动的洞察： 基准测试数据以 标准化报告格式 收集。我们的“配置浏览器”允许您解析这些数据，以可视化帕累托曲线，并针对您的特定 SLO 找到最佳部署参数。
提高效率
引入工作负载变体自动扩缩器（实验性）
工作负载变体自动扩缩器 (WVA) 使用基于饱和度的响应式优化器，该优化器根据每个副本的指标（如队列长度和 KV 缓存利用率）运行，以识别饱和副本并计算非饱和副本上的剩余容量。它依赖于与推理调度器类似的信号，但具有更大的安全裕度以避免波动。这种方法对于性能参数不确定的工作负载非常稳健，并允许根据观察到的负载进行扩展以防止队列溢出。
基于饱和度的扩缩
基于饱和度的扩缩是 v0.4 版本的默认自动扩缩方法，建议用于大多数工作负载，包括混合状态空间模型 (HSSM)、MoE 和扩散 (diffusion) 架构。
- 工作原理： 根据观察到的指标（到达率 vs 容量）进行响应式扩缩。
- 优势： 不需要复杂的性能参数和调优，具有鲁棒性，且对特定架构的性能差异不敏感。
- 局限性： 仅是响应式的，当非饱和副本的平均观测剩余容量低于静态配置的阈值时进行扩缩，且成本效率可能低于准确的预测性扩缩。扩缩以每次一个副本的增量进行。
未来的版本将通过 SLO 驱动的主动自适应优化器来增强 WVA，该优化器不仅对每秒查询数 (QPS) 做出反应，还会对不断变化的流量模式做出反应，在易用性和性能之间取得平衡。在本版本发布之后，我们计划发布一篇关于自动扩缩的详细博客，包括性能评估和路线图。
让操作更简单
Chat 的生产就绪性
- Chat Completion API 支持： 已合并并测试了对 OpenAI 兼容的
/v1/chat/completionsAPI 的全面支持，简化了所有对话式和智能体 (agentic) 工作负载的运营部署。
重大变更
作为与 Kubernetes Gateway API 推理扩展 (GAIE) 最佳实践保持一致的重构工作的一部分，我们宣布所有使用 Helm chart 的部署都将面临一项重大变更：设置推理调度器配置标志的方法已从数组格式更改为映射 (map) 格式。如果您正在升级到 v0.4，请立即查看最新的 Helm chart values.yaml 文件并更新您的覆盖配置。此更改对于将配置与代码解耦并启用未来的高级调度功能是必要的。
下一步是什么？
0.5 版本将继续在更广泛的场景和模型上增加加速器支持，并更加关注针对特定用例（如多轮对话或强化学习）的调优。如果有对您很重要的用例，请在我们的 0.5 路线图议题 中提出建议，或在社区会议中提出！
社区与近期活动
在社区的推动下，llm-d 持续进化。v0.4 版本吸收了来自各方贡献者的反馈和代码，巩固了我们作为权威硬件无关控制平面的地位。我们对所有参与者深表感谢。
请关注即将举行的社区活动更新。您可以在我们的 社区活动页面 上关注这些活动及其他动态。