CNCF 旗下 llm-d 发布 1.0：多租户 QoS、零停机升级、Agent 感知路由，官方称上下文密集型负载成本可降 5 到 10 倍

先把发布主体和时间写清楚。2026 年 10 月 20 日，IBM 新闻室在圣何塞发出公告：llm-d 项目贡献者宣布 1.0 版本发布。这个项目 2025 年由 Red Hat、IBM、Google Cloud、CoreWeave 与 NVIDIA 共同发起，现在由云原生计算基金会（CNCF）治理。所以这是一条开源基础设施的里程碑，不是某家公司的独占产品发布。

为什么这个问题现在才被当成大问题。官方给的理由很直白：很多企业把 AI 推上生产后才发现，规模化跑推理跟造模型一样难、一样贵。Agent 型负载会持续访问并复用大量上下文，支撑并行 Agent 又会带来不可预测的突发流量；而管理这些上下文的开销，常常比生成最终输出本身还大。这句话翻译成人话就是：你以为在买算力，其实一部分钱花在重复计算同一段历史对话上。

1.0 加了四类能力，官方逐条写明的。第一是多租户服务质量：带优先级与公平性感知的流控，让延迟敏感的请求和突发的 Agent 负载在同一集群里共存，不互相饿死。第二是零停机运维：路由层高可用加热备、滚动更新，并且把 prefill 与 decode 副本当成一个逻辑单元统一管理与滚动升级——这一点是分离式服务（disaggregated serving）从论文走到生产的关键。第三是稳定基础：v1 配置 API 加硬化过的请求路径，且已在多云与多种加速器上验证。第四是 Agent 感知服务：会话感知路由把多轮对话留在其缓存上下文附近，轮次优先级调度与原生 Responses API 状态支持让 Agent 跨轮复用上下文、减少重算。

生态规模给到了具体数字：项目现在有 500 名以上贡献者，来自 25 个以上组织；底层同时支持多个模型服务器，公告点名了 vLLM 与 SGLang。这句话的意义是它没有要求你换模型服务器——它站在 vLLM、SGLang 之上做路由与调度，而不是另起一套运行时。对已经在用 vLLM 的团队来说，迁移成本的决定因素就在这里。

官方给的性能数字要看清口径。公告称近期演示显示，上下文密集型 Agent 负载最高可降 5 到 10 倍成本，输出吞吐可达 3 倍，且原文在这两个数字后都带了脚注编号，说明有具体出处而非泛指。另有两个自查案例：IBM Research 在量子纠错硬件探索中，用开放前沿模型加 llm-d，推理成本比全专有配置低 11.5 倍，前缀缓存命中率约 98%，混合服务成本约每百万 token 0.11 美元；另一个演示是把约 7530 亿参数的开源权重模型 GLM 5.2 部署在常见 NVIDIA GPU 上，在数百个并行 Agent 会话下峰值输出超过每分钟 660 万 token。

为什么「前缀缓存命中 98%」这个数字比 5 到 10 倍更值得看。它解释成本的来源：Agent 场景里同一段系统提示、同一份文档、同一串工具说明会被反复送进模型，如果服务端能命中缓存，就不用每次重算。换句话说，省钱的不是更快的芯片，而是不再重复劳动。这也解释了为什么 1.0 把会话感知路由放在显眼位置——路由乱跳，缓存就废了。

边界与不做的推断。第一，5 到 10 倍、3 倍、11.5 倍全部是项目方与厂商自述的演示结果，公告没有给出可独立复现的第三方跑分，本文按「官方口径」引用，不当成中立结论。第二，这些数字都带具体负载前提（上下文密集型、Agent 会话、特定模型与硬件），换成你自己的负载不会自动成立。第三，1.0 之后的真正考验是 Day 2：多租户下谁先被限流、滚动升级时缓存怎么保住、出故障时怎么定位到具体是路由还是模型服务器。第四，本文不推断这套东西会让「AI 推理变便宜」成为普遍事实，它只是把可控的旋钮交到运维手上。