llm-d 1.0发布：17000节点吞吐提升2.9倍，首token延迟砍掉85%

一句话结论：llm-d 1.0 是谷歌云开源的 Kubernetes 原生分布式推理栈首个稳定版，把 vLLM、SGLang 的模型服务器收进同一个资源池，用前缀感知路由把 17000 节点三集群的吞吐拉高 2.9 倍，首 token 延迟中位数在 Ironwood TPU 上压掉 85% 以上。

2026 年 10 月 20 日，谷歌云在 PyTorch Conference 北美场发布 llm-d 1.0。这个项目由谷歌云、红帽、IBM 共同发起，2026 年 3 月进入 CNCF 沙盒，目前有 500 多名贡献者来自 25 家以上组织，许可证是 Apache 2.0。

这次发的是 1.0 稳定版，意味着 v1 API 冻结、路由层有高可用保障、支持零停机升级。对自建推理的团队来说，一个开源推理栈从「实验项目」走到「可以押生产」的节点，通常比再快 10% 的吞吐更有价值。

llm-d 要解决的是智能体带来的推理形态变化

过去两年推理优化的主战场是单轮对话。请求短、并发平稳、把 vLLM 挂个负载均衡器就能扛住，瓶颈常常在单卡显存放不下模型权重。

智能体把这件事彻底改了。一个典型的编码智能体要连着做几十步：读文件、调工具、改代码、再读。每个步骤都把上一步的完整上下文再送一遍模型，前缀高度雷同。如果轮询路由，缓存命中率低得可怜，前缀每跳一次机器就要重算一遍 prefill，等于把同一段长上下文反复烧掉。

llm-d 的思路是把一堆独立的模型服务器看成一个服务池。路由器记录每个副本当前缓存了哪些前缀，再结合副本负载与预测延迟打分挑机器，让智能体的每一步都落在上下文已经在那里的副本上。路由层直接建在 Kubernetes Gateway API 的推理扩展之上，不另造一套网关标准。

这是一条长期搜索词常驻的技术主线。我们此前写过 商汤大装置日均 6 万亿 Token，PD 分离把异构集群吞吐拉高 5 倍，讲的是同一件事的另一面：把 prefill 和 decode 拆到不同资源池分别调度。llm-d 把它做成了默认架构的一部分。

缓存感知路由与分层 KV 卸载是怎么配合的

前缀感知路由解决「别跳错机器」，分层 KV 卸载解决「机器上放不下」。llm-d 1.0 在加速器显存吃满之后，把 KV 缓存依次落到主机内存、SSD，最后到 Google Cloud 托管的 Lustre。同时 prefill 与 decode 被拆成两个独立池运行，前者吃算力，后者吃带宽，各自按不同特征独立扩缩。

prefill、decode 与多模态编码由 DisaggregatedSet 统一管理，它构建在 LeaderWorkerSet 之上，可以在滚动更新时感知 P/D 结构并保留已有上下文，避免升级过程中把正在跑的会话打断。

1.0 还加了一个容易被忽略的组件 llm-d-async-processor。它从 Pub/Sub 或 Redis 这类队列里拉请求，用队列门控和池派发门控开出优先级通道，让后台批处理在集群饱和时不会把交互式用户饿死。智能体场景里后台任务和前台对话混在同一个集群是常态，这条通道的作用比想象的大。

还有一个绕不开的现实约束：冷启动。拉起一个 70B 检查点要几分钟，等副本就绪流量高峰已经过去。llm-d 的应对包括节点本地模型缓存与预拉镜像、权重流式分发，以及用 llm-compressor 压缩检查点来减少搬运量。这部分能力在 1.0 里被称为快速模型启动。

官方基准数据：六组数字看懂这次升级

下面这组数字全部来自谷歌云官方发布与采用方公开数据。需要注意的是这些是自报数据，测试条件由各方掌握，但横向对比的量级差异足够说明问题。

两组数字最值得单独拎出来。第一组是 17000 节点跨三个集群的压测，成功率 99.9%、路由开销低于 1%，说明在真实多区域规模下引入路由层没有带来明显的额外故障率。第二组是 A3 Mega 上 70B 模型跑 5 万 token 长提示的场景，GPU 小时数减少近 60%，这是成本口径的收益，落到账单上比性能提升更直接。对照 NVIDIA 下代 Groq LPU 放弃 SRAM：3D 堆叠 DRAM 能解决大模型推理的存储墙吗 里讨论的算力芯片存储层次问题，缓存外置这条路目前是最现实的解法。

与 Dynamo、AIBrix 的横向对比

llm-d 1.0 的对比对象主要是同为 Apache 2.0 许可的两个开源服务层：英伟达的 Dynamo 与字节发起的 AIBrix。三者其实不在同一层硬碰硬，但选型时确实会被放在一起比较。

真正的差异在硬件生态这一行。llm-d 是三个里唯一把 Google TPU 作为一等目标写进支持的，英伟达主导的 Dynamo 与 TPU 路线天然不合，字节的 AIBrix 走的是异构 GPU 加引擎无关的通用路线。如果你的集群主体是 TPU，llm-d 几乎是唯一现成的开源选择。Dynamo 在英伟达自家硬件上的深度集成仍然领先，它在 Qwen3-Coder 480B 上拿到过 2 倍的首 token 延迟改善。

这三者更像是可以叠加的关系而非互斥。CoreWeave 把 llm-d 和 Dynamo 一起跑，英伟达也向 llm-d 贡献了 Dynamo 的部分组件。Mistral 的推理工程师公开表示会用 llm-d 的前缀感知路由与流量控制来给不同商业档位划优先级带宽，并持续回馈代码。

谁在真实生产环境里用它

官方发布里点名了几家采用方，数据比厂商自测更有参考价值。

Snap 的软件工程高级经理 Vinay Kola 表示，他们把 llm-d 集成进生产 AI 基础设施，借助前缀缓存感知路由实现了 75% 到 80% 的前缀缓存命中率，同时兼容了基于 Envoy 的服务网格。

ZenteiQ 的创始人 Ganesan 表示，用 GKE Inference Gateway 加 llm-d 路由做负载感知与前缀缓存感知调度后，聚合推理吞吐提升超过 4 倍，每 1000 张 TPU v6e 的日生成 token 容量从 14.7 亿涨到 59.7 亿。

IBM 的演示场景是 3000 个并发编码智能体，成本比直接调用 API 低 5 到 10 倍。另外 llm-d 项目提供了 Prism 开放基准看板，可以在自己的集群上跑同一套配方做对比，避免只能被动接受官方数字。

推理成本这一侧我们写过 Cloudflare 发布 Clairic：文档提取 AI 让代理链路快 3 倍、成本降一半，和 谷歌开源 TorchTPU：PyTorch 零改动迁移 TPU，llm-d 1.0 里也顺带提到了 TorchTPU 的作用，它让上游 vLLM 与 SGLang 不改模型就能原生跑在 TPU 上。

部署路径与仍然存在的短板

在 Google Kubernetes Engine 上，GKE Inference Gateway 把 llm-d 路由器作为托管服务运行，可以跨集群跨区域扩展并支持全局故障转移。扩缩容用 KEDA 与 HPA 按队列深度和预测延迟驱动，Kueue 负责按模型执行配额，验证过的 Helm chart 可以把 TPU 与 GPU 池挂到同一个统一端点后面。

谷歌云给的推进顺序是分阶段的：先把前缀感知路由放在已有的 vLLM 部署前面，观察命中率变化；再加流量控制做优先级隔离；然后逐层加 KV 卸载与 P/D 分离。组件之间可以组合，团队可以保留自己的引擎、模型和集群，只采纳需要的服务部分。

短板也有。第一，RL 时间分片把加速器占用率从约 40% 提到 70% 以上，仍留下大约 30% 的空闲周期，利用率远没榨干。第二，本次所有数字都是自报数据，缺少第三方在相同配方下的复现。第三，路由层引入了新的复杂度，评分函数里前缀亲和与负载的权衡需要调，纯前缀亲和会造热点，同前缀全打到同一副本上。生产环境还需要格外注意这一点。

常见问题

llm-d 是什么？和 vLLM、SGLang 是什么关系？

llm-d 是构建在 Kubernetes 之上的分布式推理服务层，vLLM 和 SGLang 是它底下驱动的推理引擎。它本身不做模型推理，职责是把这些引擎组织成统一资源池，负责路由、缓存卸载、P/D 分离与流量控制。所以装了 llm-d 仍然需要 vLLM 或 SGLang。

什么样的团队适合上 llm-d 1.0？

已经自建 vLLM 集群、同时跑多个模型、并且有智能体或多轮长上下文负载的团队最受益。数据很直接：前缀缓存命中率从 35% 提到 70%，意味着同样硬件能少烧一半的 prefill。如果你的负载是短单轮问答，收益会小得多。

llm-d、Dynamo、AIBrix 该怎么选？

集群主力是 TPU 就选 llm-d，这是它独有的支持。全 NVIDIA 硬件且追求极限性能的场景，Dynamo 的硬件集成更深。多引擎加异构 GPU 加 LoRA 调度需求，AIBrix 的控制面更完整。三者许可证相同，也可以叠加使用。

小结

llm-d 1.0 真正的意义不在某一个基准数字，而在它把智能体负载需要的几件事固化进了稳定版本：前缀感知路由、分层 KV 卸载、P/D 分离、优先级通道、跨区域故障转移。对照 DeepSeek 开源推理框架 DeepInfer：GPU 占用减 35%、成本降 28% 这类从模型侧动刀的开源方案，llm-d 走的是从服务侧提效的路线，两条路线的成本收益可以叠加。

如果你正在为智能体集群的推理成本发愁，先去看自己的前缀缓存命中率。这个数字超过 70%，说明路由层没什么可捞的；低于 40%，那大概率就是 llm-d 这类缓存感知路由的主战场。