llm-d 1.0 发布：Red Hat、IBM、Google 主导的 Kubernetes 原生开源分布式推理栈进入生产可用，按厂商口径自托管 3,000 个编码 Agent 比商用 API 便宜 5–10 倍

核心背景与行业痛点

推理流量正在从「一问一答」的聊天变成多步 Agent 和强化学习 rollout：每一步都要重发很长的上下文，请求成批突发。放在单机或普通轮询负载均衡后面，副本会反复重算相同的 prompt，显存被重复状态占满，一个突发的 Agent 循环就能拖慢交互用户。llm-d 要解决的正是自托管模型团队的这层「集群级」推理调度问题。

架构亮点与底层机制

llm-d 不替代推理引擎，而是架在 vLLM、SGLang 之上：路由器跟踪哪个副本持有哪段前缀缓存，结合负载和预测延迟选副本；KV 缓存可从显存卸载到主机内存再到 SSD；prefill 与 decode 拆成独立池，大型 MoE 用宽专家并行。1.0 的重点是「Day 2 运维」：flow control 按优先级与公平性排队和限流，路由热备与零停机升级，DisaggregatedSet 让 prefill/decode 同步滚动升级，配置 API 升到 v1，并加入会话感知路由和 Responses API 状态。

权威 Benchmark 与实测跑分对比

以下均为项目方/厂商口径，非第三方评测：GLM 5.2 部署峰值每分钟 660 万输出 token、3,000 个并发编码 Agent，成本比商用 API 低 5–10 倍；Ironwood TPU 上首 token 延迟中位数降超 85%、吞吐 2.4 倍；IBM 称路由拿到 97% 可复用缓存。GitHub 发布说明也承认并非所有既定目标都已完成。

开发者实战落地与开箱指南

1. 已有 vLLM 部署的团队，可先只在前面加 llm-d 的前缀感知路由，再逐步开启 flow control、KV 卸载和 prefill/decode 拆分。
2. GKE 用户可直接用 Google 提供的验证版 Helm chart，或用托管的 GKE Inference Gateway 运行路由器。
3. 用项目的 Prism 看板和 llm-d-benchmark 配方，在自己集群上复现吞吐、延迟和成本曲线后再定方案。