经验博文

「推理」这门生意，正在从单机走向集群：llm-d 1.0 今天发布

Google、IBM、Red Hat 联手把 vLLM、SGLang 装进 Kubernetes，1.0 专治 Agent 时代的推理账单

原作者: AI Price Memory

3 次浏览

0 次复制

适用模型: 通用

今天，PyTorch 大会（北美，圣何塞）上，Google Cloud 宣布 llm-d 1.0 正式发布：开源、Kubernetes 原生，专做分布式 LLM 推理。背后是 Google、Red Hat、IBM 三家牵头，500 多位贡献者、25 个以上组织参与，挂在 CNCF Sandbox 下面。

它管的是另一件事：模型跑起来贵不贵、稳不稳。vLLM、SGLang 这些单机推理引擎，被它装进 Kubernetes 集群统一调度，对外只留一个入口。

在我看来，这件事的信号意义大于技术细节。Agent 流量正在改写推理的成本结构，谁先把"跑模型"这件事做便宜、做稳，谁就在下一轮 API 价格战里多一张牌。

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

llm-d 1.0 到底是什么

打个比方。以前你跑模型，是一台机器上起一个 vLLM，前面挂个普通负载均衡，请求轮着分发。现在 llm-d 做的，是把一整个集群的模型服务器变成一个"协调好的服务池"：一个 router（路由器）管所有请求进来，一个 KV 缓存索引管所有上下文，一个流量控制策略管所有优先级。

发起阵容值得看一眼。Google、Red Hat、IBM 是主要维护者，最初和 CoreWeave、NVIDIA 一起立的项，后来 AMD、思科、Hugging Face、英特尔、Mistral 都加入了贡献者名单。它刻意连接两个开源社区：PyTorch 那边（vLLM、SGLang 在这层跑模型），Kubernetes 这边（生产环境跑分布式系统）。说白了，就是不想让任何一家云厂商或硬件厂商把推理层锁死。

发布会 keynote 上，Google 直接拉了 1000 个沙盒 Agent，在 GKE 的 Agent Substrate 上同时打一个 llm-d 入口，后面混布着 vLLM 和 SGLang，底下是 TPU 和 GPU 混用。缓存感知路由把每个 Agent 的多步调用钉在已经持有它上下文的副本上，流量控制把突发的 Agent 循环排队，交互式请求照样快。这场面，以前得自己写一堆胶水代码，现在是开箱的。

为什么偏偏是现在：流量变了

Google 博客里有一段话说得很实在：一年前，推理流量 mostly 是聊天，一问一答；现在，流量转向多步骤 Agent 和 RL（强化学习）rollout——到处调工具、共享很长的前缀、突发式到达。

单机推理，或者挂个普通轮询负载均衡，在这种流量面前有三种死法。副本们重复计算同一个 prompt，显存里塞满重复的状态，一个突发 Agent 循环就能把交互用户的请求全卡住。你今天用 Agent 觉得"有时候特别慢"，大概率就是撞上了这类问题。

llm-d 1.0 与 TorchTPU 架构：GKE 上的多节点 llm-d 编排与单节点 TorchTPU 模型引擎

1.0 加了什么：生产就绪的几件套

0.x 时代的 llm-d 更多是展示"单项技术行不行"，1.0 的主题是"能不能当生产业务跑"。IBM 研究院的 Carlos Costa（项目联合创始人）原话：稳定 API、多租户抢资源不互相饿死、升级不中断业务。翻译一下：以前是 demo，现在是 SLA。

能力	它干什么	解决什么问题
多租户流量控制	按优先级和公平性做流量调度，扛不住时有控制地 shedding（ shed 掉低优先级）	延迟敏感的请求和突发的 Agent 任务共享集群，互不饿死
Router 高可用	热备 + 安全的滚动升级	路由器本身升级不再掉线
DisaggregatedSet	把 prefill、decode 当一个逻辑单元管，滚动升级时两边版本 lockstep 对齐	prefill 吃计算、decode 吃内存，分开跑各管各扩缩，升级不错位
Agent 感知服务	会话状态插件、会话亲和、按轮次优先级调度、Responses API 原生状态	Agent 多轮对话复用上下文，不用每轮重算
异步推理处理器	从 Pub/Sub、Redis 队列拉请求，和实时流量一起跑，严格优先级车道	后台任务吃闲置算力，不抢交互用户
时间分片	RL 训练里加速器闲置 40%-60% 的空档，插进去跑异步推理	综合利用率从约 40% 拉到 70% 以上

另外还有几处工程向的更新：router 配置 API 毕业到 v1，Responses API 支持 previous_response_id，拓扑感知的加速器指南（DRA/DRANET），集成了 ai-dynamo/modelexpress 做权重的 P2P 加载，附带 llm-d-api-extensions 和诊断工具 llm-d-pd-utils，废弃了自家的 llm-d-rocm 容器构建。模型服务端镜像同时带 vLLM 和 SGLang，覆盖多种加速器。

请求在集群里的走法，大致长这样：

提示词 / 指令

用户/Agent 请求
   │
   ▼
llm-d Router ── 缓存感知路由：谁手里有这段前缀的 KV 缓存，就发给谁
   │           流量控制：突发排队，交互优先
   ├─ prefill 池（计算密集，多副本横向扩）
   ├─ decode 池（内存密集，独立扩缩）
   └─ KV 缓存分层：HBM → 主机内存 → SSD / Managed Lustre
引擎层：vLLM / SGLang（可混布）
硬件层：GPU / TPU / XPU / CPU（可混用）

成绩单：官方晒的数字，先打个折看

Google 这次晒了不少生产数据。我先说明：都是厂商口径，看看量级，别当精确承诺。

场景	数据
Ironwood TPU 上的代码 Agent 任务	前缀感知路由 + 主机内存卸载，首 token 时间（TTFT）中位数降 85% 以上，吞吐 2.4 倍（对比普通 K8s Service）
Gemini 平台（原 Vertex AI）生产流量	前缀缓存命中率 35%→70%，代码 Agent 的 TTFT 降 35% 以上，突发聊天流量的 P95 TTFT 降 50% 以上
17000 节点多区域 GKE，MoE 模型	三集群吞吐 2.9 倍，成功率 99.9%，路由开销不到 1%
A3 Mega 集群 70B 模型	KV 缓存多层卸载到 Managed Lustre，5 万 token 提示的 TTFT 改善约 40%，端到端延迟降 30%，GPU 小时需求降近 60%
Snap 生产环境	前缀缓存命中率 75%-80%
Zenteiq 合成数据生成	总吞吐 4 倍以上，每 1000 张 TPU v6e 每天生成 token 从 14.7 亿涨到 59.7 亿
IBM 研究院（量子纠错硬件设计）	开源模型 + llm-d，效率优势 11.8 倍（Ruchir Puri，IBM 研究院首席科学家）

Mistral 的推理工程师也出来站了台，说靠 llm-d 的前缀缓存路由、流量控制和分离式服务，他们能在商业分级里执行严格的优先级带——池子满了自动 hold 住或 shed 低优先级请求，付费流量的延迟 SLA 不破。注意 Mistral 也是 llm-d 的贡献者，这话有立场，但逻辑成立：卖 API 的人，最怕的就是突发流量把高价值客户拖下水。

跟你我有什么关系：推理成本的下限又被撬了一下

说点实际的。这东西离普通聊天用户有点远，但离这个站的读者很近。

如果你在跑中转、做 API 聚合，或者自己搭了推理服务，llm-d 1.0 这类项目直接决定你的成本结构。Agent 流量里，前缀重复率极高（系统提示词、工具定义、历史轮次），缓存命中率每涨 10 个点，都是真金白银。Snap 跑到 75%-80% 的命中率，意味着同样硬件能多接近一倍的请求。成本下来，API 售价才有下探空间——别忘了，Gemini 4 Argon 正在拿半价抢企业客户，DeepSeek 的第三方渠道已经把价格打到官价零头，推理侧的每一分优化都会变成价格战的弹药。

如果你是纯 API 用户，短期感知不强，长期会受益：服务商的推理成本降了，涨价的压力就小。以及，硬件中立这件事值得记住。llm-d 跑在 GPU、TPU、XPU、CPU 上行为一致，部署一次到处扩。同一天，Google 还把 TorchTPU 开源了——PyTorch 原生跑 TPU，vLLM（Inferact 做的后端）、SGLang（RadixArk 做的后端，RadixAttention 复用 KV 缓存）都接上了，Hugging Face 那边传个 device_map="tpu" 就能把开源权重部署到 TPU。TPU 不再是"Google 家的私房菜"，这是给所有想摆脱 NVIDIA 依赖的人递的梯子。

还有一个趋势信号：推理栈的优化目标，正式从"聊天"切到"Agent"了。会话亲和、按轮次调度、异步队列、RL 闲置算力复用——每一项都是 Agent-shaped 流量的形状。你在选型推理方案时，可以照着这个清单问供应商：前缀缓存命中率多少？突发流量下 P95 延迟多少？答不上来的，基本还在用聊天时代的架构。

Prism（prism.llm-d.ai）也值得提一嘴：llm-d 的开源 benchmark 看板，配标准化的 llm-d-benchmark recipe 和 inference-perf 负载。调优分布式推理最怕"各说各话"，有个公共尺子是好事，自己集群跑完也能上传对比。

一句话总结：模型越来越聪明是上半场，llm-d 1.0 宣告下半场开哨——比拼的是谁能把推理跑得更便宜、更稳，Agent 时代的第一批红利，会先落到把基础设施吃透的人手里。

来源

Google Cloud Blog（官方）: llm-d 1.0, an open source stack for distributed inference — https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference
SiliconANGLE: IBM-backed llm-d framework adds controls for running AI models in-house — https://siliconangle.com/2026/10/20/ibm-backed-llm-d-framework-adds-controls-for-running-ai-models-in-house/
Unite.AI: Llm-D 1.0 Debuts at PyTorch Conference with Production Inference Stack — https://www.unite.ai/llm-d-1-0-debuts-at-pytorch-conference-with-production-inference-stack/
Google Cloud Blog（官方）: TorchTPU is now open source — https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus
llm-d 官网 — https://llm-d.ai