llm-d 1.0 今天在 PyTorch Conference 上发布，是一个开源的、Kubernetes 原生的分布式 LLM 推理栈。项目由 Google 联合 Red Hat、IBM 等发起，是 CNCF Sandbox 项目，社区超过 500 名贡献者，来自 25 个组织。它把 PyTorch 生态（vLLM、SGLang 服务模型）和 Kubernetes 生态（分布式系统生产级运行与扩展）连接在一起。

发布背景是 agent 正在改变推理流量形态。一年前多数推理是单轮聊天，现在转向多步 agent 和强化学习（RL）rollout：请求跨工具扇出、共享长前缀、突发到达。在单机上或普通轮询负载均衡后面服务这类流量会很快出问题——副本重复计算相同 prompt，加速器内存被重复状态占满，一个突发 agent 循环就能让交互用户卡顿。llm-d 把一组模型服务器变成协同服务池，演示中 1000 个沙箱 agent 跑在 Agent Substrate on GKE，通过单个 llm-d 端点打到混合的 vLLM、SGLang 和 Google Cloud TPU/GPU 集群。缓存感知路由和分层 KV cache 让每个 agent 的步骤落在已持有其上下文的副本上，流控把突发的 agent 循环排队，保证交互请求快速响应。

1.0 提供的能力包括前缀和负载感知路由、KV cache offloading、prefill/decode 分离、wide expert parallelism 和 TPU/GPU 批处理。具体收益：多租户 QoS，通过 llm-d flow control 让延迟敏感请求和突发 agent 负载共享集群并满足 SLO；v1 API 和经过加固的请求路径提供稳定基础；路由器高可用和零停机更新，配合 DisaggregatedSet 做 prefill/decode 感知的滚动更新，不丢上下文；Session-aware 路由、turn 优先级调度和原生 Responses API 状态支持 agent 跨轮次复用上下文；TorchTPU 协作式时间切片提升 Google Cloud TPU 集群吞吐和利用率。所有组件可组合，用户可以保留自己的引擎、模型和集群，只采用需要的服务组件。

架构上，llm-d 把加速器池放在单个端点后面，由一个 router、一个 KV cache 索引和一个 flow-control 策略管理。router 基于 Kubernetes Gateway API Inference，跟踪每个缓存前缀所在的副本，并综合负载和预测延迟选择副本。加速器内存满时，通过 vLLM 的 OffloadingConnector、Mooncake 或 SGLang 的 HiCache 把 KV cache 移到宿主机内存，再到 SSD 或 Google Cloud Managed Lustre。在 Ironwood TPU（TPU 7x）上的 agentic coding workload，前缀感知路由加主机内存 offload 让中位 TTFT 降低超过 85%，总吞吐提升 2.4 倍（对比普通 Kubernetes Service）。

prefill 是计算密集型，decode 是内存密集型，llm-d 把它们和多模态 encode 分成独立池，并用 wide expert parallelism 把大规模 MoE 模型跨节点扩展。1.0 中的 DisaggregatedSet 基于 LeaderWorkerSet，统一管理这些池，滚动更新时 prefill 和 decode 按匹配版本一起升级，各阶段独立伸缩。llm-d 1.0 还引入 llm-d-async-processor，从 Google Cloud Pub/Sub、Redis 等队列拉请求，与实时流量一起路由，通过队列和池调度门保证优先级和配额，让后台任务只利用 slack 容量。

RL 训练中加速器常有 40% 到 60% 时间空闲（rollout 生成或权重更新期），llm-d 支持 TPU 和 GPU 时间切片，把异步推理插进这些空闲周期，把平均占空比从约 40% 提升到 70% 以上。

可复现基准方面，Prism 是 llm-d 的开源分析仪表板，基于标准化 llm-d-benchmark recipes 和 inference-perf workloads，可以查看具体配置，也可以上传自己集群的运行结果对比吞吐、延迟和成本。

在 Google Cloud 上运行 llm-d 基于已有 Kubernetes 组件：Gateway API、LeaderWorkerSet、Dynamic Resource Allocation、Prometheus、OpenTelemetry。GKE Inference Gateway 是 llm-d router 的托管 Gateway 模式，处理 L7 代理和负载均衡，支持跨集群和区域扩展、全球故障转移和 Model Armor 安全检查。KEDA 和 HPA 根据队列深度、饱和度和预测延迟伸缩，Kueue 强制每模型配额。TPU 和 GPU 节点池可以在同一 llm-d 端点后面混合部署。

生产实测数据：Gemini 平台（前 Vertex AI）通过 GKE Inference Gateway 服务生产流量，前缀缓存命中率从 35% 翻倍到 70%，coding agent 的 TTFT 降低超 35%，突发聊天流量下 P95 TTFT 降低超 50%。在 17,000 节点的多区域 GKE 部署中，服务一个 MoE 模型，多集群 GKE Inference Gateway + llm-d router 跨三个集群吞吐扩了 2.9 倍，成功率 99.9%，路由开销小于 1%。在 A3 Mega 集群服务 70B 参数模型，llm-d 多连接 KV cache offloading 到 Managed Lustre + Host CPU RAM，相比仅 CPU RAM，50k token prompt 的 TTFT 改善约 40%，端到端延迟降低 30%，GPU 小时需求减少近 60%。

用户方面：Snap 已集成 llm-d，用前缀缓存感知路由实现 75-80% 的缓存命中率，并因开源可融入 Envoy 服务网格。ZenteiQ 用 GKE Inference Gateway，负载感知和前缀缓存感知路由带来超过 4 倍的聚合推理吞吐，每 1000 个 TPU v6e 每日生成 token 从 14.7 亿提升到 59.7 亿。Mistral 的推理工程师表示会继续向 llm-d 和 DisaggregatedSet 贡献代码。

llm-d 1.0 的组件设计可拆卸，适合自己服务模型的团队。官方建议先用前缀感知路由接在现有 vLLM 前，再加流控、KV cache offload 和分离，用 Prism 对比结果。部署可通过 GKE 上的验证 Helm charts 完成。