llm-d 0.2: 我们的首条坦途（小心树根！）

我们的 0.2 版本在推进三条“明径”方面取得了进展，以加速在 Kubernetes 上部署大规模推理：更好的负载均衡、通过解构实现更低延迟，以及为 DeepSeek-R1 等超大型混合专家模型 (MoE) 提供原生 vLLM 支持。

我们还增强了部署和基准测试工具，吸收了现实世界基础设施部署的经验，并解决了关键的反模式。此版本为 llm-d 用户、贡献者、研究人员和运维人员在经过测试且可重复的场景中提供了更清晰的高效使用指南。

通往生产环境的新路径

在此版本中，我们专注于提供一套清晰且可复现的场景，供团队依赖，并在真实硬件和模型上进行了端到端测试。

我们的部署方案已在 H200 节点等最新 GPU 上，针对 Llama-3、Llama-4 和 DeepSeek-R1 等模型进行了测试和基准评估。我们提供部署指南和性能分析，帮助团队了解何时 P/D 分离（Prefill/Decode 分离）最为有利，以及在何处会出现权衡。

我们定义并改进了构成此版本基础的三条“明路”（Well-lit paths）：

• 基于任何 vLLM 部署的智能推理调度：支持精确的前缀缓存感知路由，无需额外基础设施；开箱即用的负载感知调度，可实现更好的尾延迟且“即装即用”；全新的可配置调度配置文件系统，使团队能够立即获得延迟优化，同时仍可针对其工作负载和基础设施定制调度行为。
• P/D 解耦（Disaggregation）：支持将 Prefill（预填充）和 Decode（解码）工作负载分离，以提高长上下文场景下的延迟表现和 GPU 利用率。
• 针对 DeepSeek R1 的宽专家并行 (EP/DP)：支持使用 MoE（混合专家）模型的专家并行和数据并行模式进行大规模多节点部署。这包括利用 NIXL+UCX 进行节点间通信的优化部署，通过修复和改进来降低延迟，并演示了如何使用 LeaderWorkerSet 进行 Kubernetes 原生推理编排。

所有这些场景都是可复现的：我们提供参考硬件规格、工作负载和基准测试工具链支持，以便他人能够轻松评估、复现和扩展这些基准测试。这也反映了我们部署工具和基准测试框架的改进，即一套全新的“机制”，允许用户一致地设置、测试和分析这些场景。

虽然这是我们的第一个版本，仍有一些不完善之处，但我们的目标是继续细化和拓宽这些路径以加速采用。请就下一步的发展方向提供反馈！

关键使能变化与技术里程碑

llm-d 0.2 基于我们特别兴趣小组 (SIG) 的进展，交付了以下关键功能：

模块化部署器重构

我们将部署器重构为以 Helm 为中心的模块化结构，将基础设施、模型服务和推理网关的 Chart 进行分离。这些 Chart 现在是我们文档的核心，包含对 Kubernetes 版本、网络和 GPU 硬件的明确先决条件要求。此次重构不仅让初学者和高级用户更容易部署 llm-d，还使我们能够直接在最终用户环境中使用，通过模块化和灵活性将机器学习理论转化为用户的生产实践。

针对 MoE 部署的 P/D 解耦与 DP/EP

预填充/解码 (P/D) 解耦以及多节点 DP/EP MoE 部署的路径现在定义得更加清晰且经过测试。这项工作集成并优化了 vLLM 0.10.0 的关键算子改进，包括用于专家并行计算的 DeepGEMM 和 CUTLASS，以及 PPLX 和 DeepEP 算子，还包括针对多节点场景的节点内和节点间通信的修复与优化。我们现在包括：

• Kubernetes 原生部署方案，现已支持每个 DP 秩（rank）对应一个 API 服务器，实现每个 Pod 一个 rank 的放置，增强了可扩展性和控制力。
• Helm Chart 已更新，支持用于多节点设置的 LeaderWorkerSet (LWS) 以及直接的每个 DP rank 一个 Pod 的部署。
• 通过启用 DeepEP 高效使用 cuda_ipc，优化了节点内通信。
• 增强了 NIXL+UCX 性能，通过修复和优化显著降低了节点间通信开销，特别是在长上下文工作负载下。

这些经过验证的场景由基准测试基线和通过快速入门提供的示例部署提供支持，为“目前哪些方案有效”提供了更清晰的指导。作为“明路”的一部分，我们也识别了一些局限性，包括响应大小方面的已知边缘情况以及需要进一步工作的故障模式。

推理调度器可扩展性

llm-d-inference-scheduler 现在具有更强的可扩展性，并与最新的上游推理网关（Inference Gateway）代码库保持一致。它完全可配置，支持基于标签选择器（label selector）的灵活过滤，以启用各种模型服务器拓扑，包括基于 LWS 的部署。我们改进了前缀感知调度的用户体验，允许在网关处现有的“预估前缀追踪”与新的“精确前缀缓存追踪”之间进行简单的配置切换，后者直接从 vLLM 读取 KV 事件以获得更高的命中率。

我们的 Helm Chart 现在支持开箱即用的调度器配置部署，方便研究人员和运维人员在不修改核心组件的情况下，迭代自定义调度和路由策略。在内部，测试和开发工作流程已更新以提高速度和质量，此版本还包含许多错误修复。

改进的基准测试套件

我们的基准测试套件已显著成熟。它现在支持测试任何预部署的 llm-d 工作负载，兼容多个负载生成器，并包含自动分析和绘图生成功能，以便更容易地解释性能数据。

在此版本中，我们进行了多次扫描以表征吞吐量和扩展性，展示了 P/D 解耦对长上下文工作负载的益处。场景涵盖了代表性的工作负载形态（输入/输出比为 10:1 和 100:1），并探索了各种并行方案和 P/D 解耦比例。对于每种设置，我们都在不断增加的并发级别下测量吞吐量扩展性（每用户每秒 token 数和每 GPU 每秒 token 数）。这些结果提供了有无 P/D 分离（仅负载感知）的直接对比，突显了 llm-d 优化带来显著收益的场景。

图 1：在双 8×H200 IB 节点上 Llama-Scout 的帕累托曲线，对比了单体 (4tp4) 和 P/D 解耦 (4ptp2–2dtp4) 拓扑。

上图显示了在具有 Infiniband 网络的 2 个 8xH200 节点上运行 Llama‑Scout 的标准帕累托曲线，对比了标准 4tp4 拓扑与解耦的 4ptp2-2dtp4 配置（保持 GPU 总数不变）。X 轴测量每个用户观察到的延迟，Y 轴测量每张 GPU 的总吞吐量。图上的每个点代表一个特定的并发数。

虽然在极低或极高的用户输出速度下，两种配置的表现相似，但在中等并发水平（特别是 64-128 个并发请求左右）下，解耦设置提供了显著更高的单 GPU 吞吐量，此时预填充和解码阶段之间的竞争往往占主导地位。这证实了解耦不仅能增加吞吐量，还能暴露饱和点并释放因阶段干扰而损失的余量。这些见解对于自动扩缩容、角色分配以及未来由预测器驱动和 SLO 感知的调度至关重要。

这些结果遵循了先前报道的广泛趋势 [1, 2]：解耦服务在中等并发条件下始终能提供最大收益，特别是对于预填充密集型流量和大型模型。我们的结果证实了这一趋势，在中等吞吐量下显示出改进的吞吐量和更清晰的饱和动态，有力地验证了我们的架构方向。通过将预填充和解码阶段解耦，我们不仅提升了原始性能，还揭示了静态单体系统所掩盖的扩展限制。这为动态拓扑自适应、预测器告知的路由以及由工作负载实时行为驱动的自动扩缩容策略奠定了基础。这些是我们即将发布的版本的重点优先事项。

镜像改进

多架构支持、更小的镜像体积和强化的配置确保了可靠的开箱即用体验。

我们的经验教训与社区分享

以下是我们在 llm-d 进展过程中学到的一些关键教训：

• “信手拈来”的优化也很重要。 针对性的优化，如减少预填充和解码工作节点之间的 KV 缓存传输开销，以及精细化前缀感知调度，在吞吐量和尾延迟方面带来了显著收益。这些快速见效的方案仅需极小的改动，但为后续版本中计划的更深层次架构改进铺平了道路。
• 使用尖端库并非易事。 许多与分布式推理相关的关键库尚不成熟。通过我们在“明路”中的应用实验以及与生态系统伙伴的紧密合作，我们在真实环境条件下改进了广大社区所依赖的许多关键基础设施。
• 建立在经过验证的路径上。 这验证了 llm-d 存在的意义：帮助用户避免自行发现这些问题，提供可复现的部署、性能基线和扩展性。llm-d 专注于构建这些路径，因此我们的用户无需孤立地去解决这些复杂的挑战。
• 社区至关重要。 通过与 NVIDIA Dynamo 社区密切合作，我们解决了长上下文工作负载下的 NIXL/UCX 性能开销问题，带来了显著改进并积极向上游贡献代码。

我们的调查

在我们的第一次社区调查中，我们邀请用户分享他们的部署需求和挑战，以帮助塑造 llm-d 项目的未来，并更好地了解当今团队是如何提供 LLM 服务的。我们收到了来自平台工程师、业务主管和数据从业者等广泛且多元群体的反馈，反映了各种各样的工作负载、架构和运营成熟度。

对话式 AI (82.9%) 和实时应用 (56.1%) 是最常见的工作负载，近一半的受访者同时支持 4-10 个模型。硬件选择呈现多元化图景：85% 使用 NVIDIA GPU，29% 运行 AMD GPU，27% 仅在 CPU 上部署（这是一个令人惊讶的信号）。模型偏好显示 Llama (73%)、Qwen (63%) 和 Mistral (56%) 处于领先地位。然而，尽管活动频繁，SLO 成熟度仍处于起步阶段：46% 的人表示没有正式的 SLO，39% 的人仍在定义中，这表明许多团队处于探索或早期生产阶段。明确的一点是，对路由、缓存、可观测性和灵活性等运营功能的需求强劲，这标志着随着团队规模扩大，易用性和可管理性是首要任务。点击此处查看调查结果的完整摘要。

你今天可以获得什么

今天，llm-d 0.2 提供：

• 模块化 Helm Chart 和清晰的部署工作流。
• 对 P/D、DP/EP、pod-per-rank 以及异构 GPU (H200, B200) 的验证支持。
• 可复现的性能基线，现已支持 MoE。
• 路由和调度器可扩展性的新基础。
• 一个对开发人员和研究人员友好的平台，包含经过测试的示例，详细指南也即将发布。

一个不断发展的社区

llm-d 最棒的部分是看着社区围绕它成长。我们很高兴已有超过 700 人加入了我们的 Slack 频道，该项目在 GitHub 上已获得超过 1,400 个 Star。这不仅仅是数字，更是推动项目前进的积极协作精神。

大部分工作发生在我们七个特别兴趣小组 (SIG) 中，每个小组专注于一个关键领域：

• 推理调度器 (Inference Scheduler) – 开发更智能的路由和负载均衡策略，包括 KV 缓存感知调度。
• P/D 解耦 (P/D Disaggregation) – 推进阶段分离策略以提高资源利用效率。
• KV 解耦 (KV Disaggregation) – 推进并优化分布式 KV 缓存管理。
• 安装 (Installation) – 简化在 Kubernetes 上的部署，从单节点设置到大型多节点集群。
• 基准测试 (Benchmarking) – 构建工具以自动化性能验证，使场景更易于复现和扩展。
• 自动扩缩容 (Autoscaling) – 根据工作负载需求动态调整资源。
• 可观测性 (Observability) – 提供对系统性能和健康状况的深度可见性。

我们还与 vLLM、Dynamo 和 LMCache 等其他优秀的开源社区合作。每个小组都是开放的，我们非常欢迎你的加入。无论你是想贡献代码、分享想法，还是只是旁听，都非常欢迎。你可以在我们的社区页面上找到每个 SIG 的详细信息，包括其负责人和会议时间。

下一步计划：

展望未来，我们的社区将专注于以下关键领域：

• 核心优化
  • 上游基于 TCP 的请求分发
  • 解耦协议精细化，包括可能移除 Sidecar
  • CPU 缓存卸载以扩展内存容量
  • 直接将 KV 事件感知融入路由决策
  • SLO 驱动的调度架构，以实现可预测的性能
• 基准测试增强
  • 扩展的可复现性指南。
  • 核心场景的完整性能验证。
• 开发人员体验改进
  • 扩展推理网关和调度器可扩展性的示例。
  • 中心化的 Helm Chart 和扩展文档。

查看我们的 路线图 Issue 了解后续动态并发表你的看法！

加入 llm-d 社区！

我们欢迎探索调度、自动扩缩容和路由优化挑战的研究人员。你的贡献弥足珍贵！

社区参与是我们成功的关键：

• 参加我们的社区会议 (每周三 12:30pm ET)

在 GitHub 上做贡献，参加社区会议，加入 SIG，与我们一起构建！