Announcing llm-d 1.0: Open distributed inference for agents on Google Cloud TPUs and GPUs

llm-d 1.0，用于分布式推理的开源堆栈 | Google Cloud 博客

AI 基础设施

发布 llm-d 1.0：Google Cloud TPUs 和 GPUs 上代理的开源分布式推理

2026 年 10 月 21 日

##### Mark Lohmeyer

AI 与计算基础设施副总裁兼总经理

##### Sean Horgan

产品经理

#### 一个面向 Google Cloud 的开源、Kubernetes 原生服务堆栈，具备缓存感知路由、多租户流量控制、分层 KV 缓存和高可用性，适用于生产环境

##### 11 月 4 日：Agentic Data Cloud 活动

加入我们的产品负责人，共同构建您的代理未来

注册

今天在 PyTorch 大会上，我们发布了 llm-d 1.0，这是一个用于分布式大语言模型（LLM）推理的开源、Kubernetes 原生堆栈。由 Google 与 Red Hat、IBM 等公司共同发起，我们在 Cloud Native Computing Foundation（CNCF）沙盒项目中与来自 25 家组织的 500 多位贡献者合作，将两个重要社区整合在一起：PyTorch（vLLM 和 SGLang 用于模型服务）以及 Kubernetes（分布式系统在生产环境中运行和扩展）。

llm-d 1.0 的发布正值代理技术正在改变推理本质的时期。一年前，大多数推理流量是聊天：一个提示输入，一个响应输出。如今，工作负载正在转向多步骤代理和强化学习（RL）演进，这些演进会通过工具扩散、共享长前缀，并以突发流量形式到达。在单台机器上或通过通用的轮询负载均衡器进行服务，很快就会崩溃。副本会重复计算相同的提示，加速器内存会因重复状态而填满，一个突发代理循环可能会阻塞交互式用户。

llm-d 通过将模型服务器集群转变为协调的服务池，为运行自身模型的团队解决了这些问题。在 PyTorch 大会主题演讲中，我们展示了在 GKE 上的 Agent Substrate 上运行的 1,000 个沙盒代理，它们通过 llm-d 端点访问 vLLM、SGLang 以及 Google Cloud TPUs 和 GPUs 的混合舰队。随着流量在以下三个阶段扩展，缓存感知路由和分层 KV 缓存确保每个代理的步骤保留在持有其上下文的副本上，而流量控制则排队处理突发代理循环，使交互式请求保持快速。

图 1：llm-d 1.0 中分布式推理从轮询负载均衡到缓存感知路由、分层 KV 缓存和优先级流量控制的演进

1.0 提供的功能

llm-d 已经实现了前缀感知和负载感知路由、KV 缓存卸载、预填充/解码分离、跨 Google Cloud TPUs 和 GPUs 的宽专家并行性和批量推理。这些功能提供了：

• 多租户服务质量。通过 llm-d 流量控制实现优先级和公平性感知路由，帮助延迟敏感请求和突发代理工作负载共享舰队以满足服务水平目标（SLOs），而不会相互影响。

• 稳定的基础。v1 API 和经过多个云平台和加速器类型验证的强化请求路径。

• 更安全的升级。路由器高可用性和零停机更新，以及 DisaggregatedSet，它可协调预填充/解码感知的滚动更新，而不会丢失上下文或中断活动会话。

• 代理感知服务。会话感知路由、回合优先级调度和原生 Responses API 状态，帮助代理在回合之间重用上下文。

• 扩展的 TPU 集成。原生 PyTorch 模型服务，通过 TorchTPU 协作时间切片提高 Google Cloud TPU 队列的吞吐量和利用率。

组件设计旨在让您将其组合成定制的生产环境。保留您的引擎、模型和集群，仅采用所需的推理组件和配置。

llm-d 的内部机制

在以下领域，Google 工程师与 llm-d 社区合作，将上游 Kubernetes 原语、PyTorch 推理引擎和加速器感知调度整合为可组合的堆栈。

图 2：Google Kubernetes Engine 和 Google TPUs 上的多节点 llm-d 编排和单节点 TorchTPU 模型引擎

一个端点，多种加速器

代理舰队不是一个单一的工作负载。交互式轮次需要低延迟，后台循环和强化学习（RL）部署需要高吞吐量，需求每分钟都会波动。llm-d 将您的加速器池置于一个端点后，整个舰队前面仅有一个路由器、一个 KV 缓存索引和一个流量控制策略。代理调用单一 API；路由器为每一步选择副本，并在已持有上下文的副本上保持会话上下文。增加容量、混合加速器代际或将模型迁移到不同池只需平台变更，无需重写代理。TorchTPU 将 Google Cloud TPUs 引入该舰队，在上游 vLLM 和 SGLang 中原生运行 PyTorch 模型，无需模型重写。更多内容请参见 llm-d 在 Google Kubernetes Engine (GKE) TPU 上的指南。

记住上下文的路由

llm-d 路由器基于 Gateway API Inference 构建，这是 Kubernetes 项目中用于推理优化路由的组件。在 GKE 上，GKE Inference Gateway 作为托管服务运行 llm-d 路由器，简化安装和管理，并扩展跨区域的路由。路由器跟踪持有每个缓存前缀的副本，并在选择时根据负载和预测延迟进行加权。当加速器内存耗尽时，llm-d 不会丢弃数据，而是使用 vLLM 的 OffloadingConnector、Mooncake 或 SGLang 的 HiCache 将 KV 缓存转移到主机内存，再转移到 SSD 或 Google Cloud 管理的 Lustre。这种设置有助于防止在混合 TPU 和 GPU 队列上处理重载、多轮和长上下文对话时出现前缀驱逐风暴。

在 Ironwood TPU（TPU 7x）上的代理编码工作负载中，基于前缀的路由加上主机内存卸载将首次生成令牌（TTFT）的中位数时间缩短了 85% 以上，总吞吐量比普通 Kubernetes 服务提高了 2.4 倍（截至 2026 年 10 月，数据来源）。

安全升级的解耦

预填充计算密集，解码内存受限，因此在相同副本上运行两者会使彼此等待。llm-d 将预填充、解码和多模态编码作为独立池运行，广泛的专业并行性将大专家混合模型分布到多个节点。在 1.0 版本中，基于 LeaderWorkerSet（我们启动的 Kubernetes 多主机推理 API）构建的 DisaggregatedSet 将这些池作为单一单元进行管理。滚动更新在匹配版本上同时迁移预填充和解码，每个阶段可独立扩展。更多内容请参见 解耦推理指南。

与实时推理并行运行的异步推理

对于容忍延迟的流量，llm-d 1.0 引入了 llm-d-async-processor，该组件从 Google Cloud Pub/Sub 或 Redis 等队列中拉取请求，并与实时流量并行路由。通过队列和池调度网关，处理器会检查可用容量并严格执行优先级通道和配额限制，使后台任务在空闲容量中运行而不会影响交互用户。

利用空闲 RL 资源提升利用率

在 RL 训练过程中，加速器在 rollout 生成或权重更新期间经常有 40% 到 60% 的空闲时间。llm-d 现在支持 Google Cloud TPU 和 GPU 的时间切片技术，将异步推理插入到这些空闲周期中，使加速器整体利用率从约 40% 的基准水平提升至 70% 以上（来源）。

值得信赖的基准测试

在路由器、KV 缓存层级和预填充/解码池之间调整分布式推理堆栈，需要在真实多轮负载下进行可重复的测量。Prism 是 llm-d 的开源分析仪表板，用于探索 llm-d 明确路径上的已发布基准测试，其背后有标准化的 llm-d-benchmark 测试方案和 inference-perf 工作负载支持。您可以查看数字背后的精确配置，或上传来自您集群的运行结果，将吞吐量、延迟和成本曲线进行并排对比。

在 Google Cloud 上运行 llm-d 1.0

llm-d 基于您可能已经在运行的 Kubernetes 组件构建：Gateway API、LeaderWorkerSet、动态资源分配、Prometheus 和 OpenTelemetry。在 Google Cloud 上运行 llm-d 可以通过托管基础设施将这些组件整合：

• GKE 推理网关 是以网关模式运行的 llm-d 路由器，这是一个托管的 GKE 网关，处理 L7 代理和负载均衡，并在每次请求时调用 llm-d 端点选择器，简化安装和管理，无需您自行运行代理。更重要的是，GKE 推理网关是通过全局故障转移和 Model Armor 安全检查实现 llm-d 在集群和区域之间扩展的方式。

• 基于推理信号的自动扩展。KEDA 和水平 Pod 自动扩展器（HPA）根据队列深度、饱和度和预测延迟对池进行扩展，而 Kueue 则在共享加速器上执行每模型配额限制。

• 混合加速器节点池。Google Cloud TPU 和 GPU 池运行在相同的 llm-d 端点后，通过经过验证的 Helm 图表部署。

• 跨层级的 KV 缓存卸载。Google Cloud 管理的 Lustre 提供了一个共享远程层级，位于本地 TPU 和 GPU HBM 以及主机 CPU 内存之下，使长上下文工作负载无需耗尽加速器内存即可运行。

在生产环境中的应用

该 GKE llm-d 堆栈承载着生产流量，并已在舰队规模上进行了测试：

• Gemini 平台（原 Vertex AI）通过 GKE 推理网关为生产流量提供服务，使前缀缓存命中率从 35% 提高到 70%，使代码代理的 TTFT（首次令牌延迟）减少超过 35%，在突发聊天流量下 P95 TTFT 减少超过 50%（来源）。

• 在一项跨 17,000 个节点的多区域 GKE 部署的已发布基准测试中，该部署在美国和欧洲运行了一个专家混合模型，多集群 GKE 推理网关和 llm-d 路由器在三个集群中实现了 2.9 倍的吞吐量扩展，成功率达到 99.9%，路由开销低于 1%（来源）。

• 在一项针对A3 Mega集群的公开基准测试中，该集群运行着一个700亿参数的模型，llm-d通过将多连接器KV缓存卸载至Google Cloud Managed Lustre以及主机CPU内存，相比仅使用CPU内存卸载的方式，实现了TTFT（首次令牌生成时间）约40%的提升，端到端延迟减少了30%，同时将GPU小时需求降低了近60%（来源）。

在Google Cloud上运行llm-d的组织正在以不同方式应用这些能力，例如通过前缀感知路由提高缓存命中率、提供与现有服务网格兼容的开放接口，以及通过流量控制在流量激增时保障优先级队列的低延迟。

“在Snap，我们正在将llm-d集成到生产AI基础设施中，以实现大规模高性能推理。通过采用前缀缓存感知路由，我们实现了高达75-80%的前缀缓存命中率。我们赞赏llm-d的开源特性，因为它使我们能够与基于Envoy的服务网格无缝集成。” ——Snap Inc. 软件工程高级经理Vinay Kola

“在ZenteiQ，我们使用由llm-d驱动的GKE推理网关来加速主权科学基础模型的合成数据生成。通过利用负载感知和前缀缓存感知路由，我们实现了聚合推理吞吐量超过4倍的提升，使每日生成的令牌容量从每1000个TPU v6e加速器14.7亿个令牌提升至59.7亿个令牌。llm-d与GKE集成的开源基础架构使我们能够高效地在大规模场景下服务多个模型家族，而无需开发和维护自定义推理调度器。” ——Zenteiq.ai创始人Sashikumaar Ganesan教授

“在交互式应用和高流量API上部署前沿模型意味着需要处理剧烈的流量激增，同时避免突发工作负载影响优先客户的服务延迟。通过llm-d的前缀缓存感知路由、流量控制和解耦服务支持，我们可以在商业层级上强制实施严格的优先级分组，当资源池饱和时自动保留或丢弃低优先级请求，确保付费流量满足我们的延迟SLO（服务等级协议）。Mistral是开源软件的坚定支持者，我们将继续为llm-d和DisaggregatedSet项目做出贡献。” ——Mistral推理工程师及llm-d贡献者Mathis Felardos、Lucas Fernandes-Martins、Nikhil Thomas

正在部署自身模型的团队一直在寻找一个可拆解并适配其基础设施的开放堆栈，需要生产环境所需的缓存感知路由、流量控制和升级控制。llm-d 1.0为他们提供了这些能力，并拥有一个可以共同构建的社区。

入门指南

• 在PyTorch大会期间，前往Google Cloud展位查看llm-d与TPU的完整演示。
• 使用经过验证的Helm图表在GKE上部署llm-d 1.0。参见[llm-d在GKE上的文档](链接)。
• 从现有vLLM部署前的前缀感知路由开始，然后添加流量控制、KV缓存卸载（SGlang、vLLM）和解耦服务。
• 在Prism上比较结果并在GitHub上提交贡献。

发布分类：

• AI基础设施
• 容器与Kubernetes
• GKE
• 开源