llm-d 1.0 发布，推理框架补上多租户与零停机运维
llm-d 1.0 于 10 月 20 日发布，为自建推理集群补上多租户与零停机升级；PD 分离需 LeaderWorkerSet v0.11.1 以上。
llm-d 是一个以 Kubernetes 为底座的分布式大模型推理框架。它不替代 vLLM、SGLang 这类模型服务引擎，而是在它们之上负责路由、调度和滚动升级。10 月 20 日，项目发布 1.0.0 版本，GitHub 发布页记录的时间是 2026 年 10 月 20 日 02:30（UTC）。1.0 的重点不在新算法，而在把前缀感知路由、KV 缓存卸载、预填充与解码分离（PD 分离）整理成能长期运行的服务：多租户流量控制、路由器热备、零停机滚动升级，以及面向智能体的会话亲和。
要点
- 版本与许可：1.0.0 在 GitHub 标为最新版本，许可证是 Apache-2.0。项目博客称，贡献者超过 500 人，来自 25 个以上组织。
- 运维能力：多租户流量控制默认仍是先到先服务，要显式开启；路由器的热备实例在主实例失败或被替换时接管调度；DisaggregatedSet 把预填充与解码副本当作一个单元滚动升级。
- 升级门槛：PD 分离指南要求 LeaderWorkerSet v0.11.1 或更新版本，并开启 DisaggregatedSet；llm-d-rocm 镜像的构建已经弃用。
背景
llm-d 的维护方是 Red Hat、IBM 和 Google，IBM 的文章还把 CoreWeave 与 NVIDIA 列为共同创立方。2026 年 3 月，IBM Research、Red Hat 与 Google Cloud 在 KubeCon Europe 宣布把 llm-d 捐给 CNCF 作为 sandbox 项目，所以这个身份不是 1.0 的新消息。
1.0 也不是在推出新技术。IBM 的文章写道，这些思路在 1.0 之前就有了，新的是整合程度与运维成熟度；SiliconANGLE 也说，这些技术此前已经可用。本文因此把 1.0 写作“增强与整合”，而不是“新增”。
英文搜索建议里就有 “llm-d vs vllm”，可见 llm-d 与 vLLM 的关系是常见疑问。llm-d 把 vLLM 或 SGLang 当作模型服务器，在外面加上分布式路由和运维能力。同一天，DeepSeek 公开的推理框架 DeepInfer 在 README 里写明只提供离线推理，在线服务需要的 KV 缓存系统与副本间的负载均衡都不在这次发布里（我们当天的报道有完整说明）。
事实部分
llm-d 1.0 的变化，发布说明分成几块。多租户 QoS 用优先级与公平感知的流量控制，按租户或工作负载分队列；过载时，概率性准入控制器有序卸载部分请求，而不是硬失败。
零停机运维靠两项改动：路由器 Endpoint Picker 的热备实例，以及 DisaggregatedSet 的 rollout screener。后者是 Alpha 插件，需在 EPP 配置中显式启用。滚动期间，它每次请求只选一个版本，按 Ready Pod 数量加权分流，某个版本只有在每个必需角色都有 Ready Pod 之后才接流量。官方安全升级文档引用的一次参考运行（DeepSeek-V2-Lite，H200）显示，不启用它时有 61% 的请求跨版本配对。
智能体方面，session-state-producer 插件让后续轮次尽量回到同一个后端，直到它饱和；Responses API 支持 previous_response_id，服务端可以跨轮次保存上下文。
下表是发布说明中与运维最相关的组件版本：
| 组件 | 1.0.0 | 上一版本 |
|---|---|---|
| 路由器 Endpoint Picker（llm-d-router-endpoint-picker） | v1.0.0 | v0.11.0 |
| PD 分离 sidecar（llm-d-router-disagg-sidecar） | v1.0.0 | v0.11.0 |
| LeaderWorkerSet（含 DisaggregatedSet） | v1.0.0 | v0.11.0 |
| llm-d-rocm 镜像 | 已弃用 | v0.10.0 |
表中数据取自 GitHub 发布说明的组件表，发布于 2026 年 10 月 20 日。
发布说明还把各组件的版本号对齐，目标是之后的主版本和次版本都这样做。AMD ROCm 用户要注意：llm-d-rocm 镜像已弃用，项目会迁到上游 vLLM 镜像；过渡期间，vLLM v0.32.0-rc.2 的 ROCm 镜像被放进了 llm-d 自己的镜像仓库，以防被垃圾回收。
各方说法
维护方的说法基本一致。IBM Research 的 Carlos Costa（llm-d 共同创立者、主要维护者）说，1.0 增加的是让它像其他关键服务一样运行的成熟度：稳定的 API、多租户竞争优先级，以及不中断服务的升级。
我们能读到全文的独立英文报道只有 SiliconANGLE 一篇，作者是 Paul Gillin。文中的数字都注明来自 IBM，我们没有看到独立验证。它引用 IBM 研究院首席科学家 Ruchir Puri 的邮件，写到 “11.8X efficiency advantage”。这是效率优势，不是 10 月 13 日 IBM 文章里 11.5 倍的成本差，本文不把两者合并。
Google Cloud 的一篇文章（UTC 时间 10 月 20 日发布，页面标注为 10 月 21 日）给出厂商数字：在 TPU 7x（Ironwood）上跑 agentic coding 负载，前缀感知路由加主机内存卸载让 TTFT 中位数下降 85% 以上，总吞吐相对普通 Kubernetes Service 提高到 2.4 倍。文章没有写明模型与时长。另一组 TPU 推理数字见我们的 Inferact 报道，负载不同。
社区讨论很少。Hacker News 上以 llm-d 1.0 为主题的两条提交，各只有 1 分、0 条评论，没有找到有实质内容的独立批评。
数字怎么读
这里的数字都由厂商或维护方给出，彼此不能直接比较。下表列出每个数字的测试条件。
| 数字 | 来源与日期 | 文中写明的条件 | 文中没有写的 |
|---|---|---|---|
| 97% 缓存复用 | IBM，10 月 20 日 | 一次 agentic coding 负载测试 | 硬件、模型、时长 |
| 97% 缓存复用（图注） | llm-d 基准，7 月 22 日 | H200 上的 GLM-5.2-FP8，16 张 GPU 的 DEP8 1P1D，只纳入能放进 14.2 万 token 上下文的会话，并发 64；预填充 GPU 命中率 91.4%，可复用前缀上限 93.9% | 是否与 IBM 的 97% 为同一次测试 |
| 每 token 成本低 5 到 10 倍 | IBM，9 月 8 日 | 544 张 H100 上自托管 GLM-5.2（约 7530 亿参数的 MoE，约 390 亿激活），按当前云租金口径，对比同等商业 API 价格；3000 个并发编码 agent 时输出约每分钟 660 万 token，接近服务上限 | 租金、利用率与计算过程 |
| 11.5 倍成本差 | IBM，10 月 13 日 | 量子纠错译码器的硬件优化，同一搜索预算（100 个假设）；全闭源 299 美元，全开源 26 美元；加速比为开源 52 倍（HLS 估算）、闭源 204 倍；每种配置只跑一次搜索 | 硬件与模型名；成本只计模型推理 |
10 月 20 日的 IBM 文章说，IBM 与 Red Hat 让 3000 个软件工程 agent 并发运行，成本比按服务价格调用同一开源模型低 5 到 10 倍。它没有给出测试条件，也没有说明是否为 9 月 8 日那次运行。项目博客把 98% 命中率、0.11 美元与 11.5 倍写在同一句里，那一句还提到 3000 个 agent，但这三个数字都来自芯片设计负载。
7 月 22 日的基准还给出 GPU 租金口径的价格：假设 H200 每 GPU 小时 2.71 美元，两种 64 张 GPU 的布局分别对应每百万输入 token 0.05 到 0.08 美元、每百万输出 token 1.92 到 3.55 美元。原文这句话最关键：“These figures cover GPU rental only, not the full cost of operating an API service.”（这些数字只覆盖 GPU 租赁，不包括运营 API 服务的全部成本。）
编辑判断
对在自家 GPU 集群上跑推理、多个团队或大量智能体共用一个端点的平台团队，llm-d 1.0 的变化是实在的：租户隔离、路由器热备和 PD 分离池的滚动升级，此前都得自己拼。只调用托管 API 的团队，这次没有直接影响。
升级前要查三件事。一是 LeaderWorkerSet 的版本，发布说明写道：“almost all guides will break without v0.11.1+”。二是 llm-d-rocm 镜像，还在用它的团队要规划迁到上游 vLLM 镜像。三是流量控制，它默认不改变行为，多租户的好处要显式配置。
成本数字和“零停机”都只有项目或 IBM 自己的说法，见上表；滚动升级依赖的 rollout screener 还是 Alpha 插件。“零停机”是项目的用语，我们没有找到独立的升级测试。发布说明的开头还写着，目标“not all of that was accomplished”，即并非全部达成。
文档之间还有一处不一致。项目 README 的更新记录里，2026 年 2 月的 v0.5 写的是 “active-active HA”；而 1.0 的博客把 active-active 路由器列为下一步，并把 1.0 的路由器描述为热备。我们没能确定 1.0 实际交付的是哪一种，依赖路由器高可用的团队应先在 GitHub 上确认。
怎么试
最短的路径是 llm-d 的官方 Quickstart，对应 v1.0 的 Standalone 模式。需要 kubectl、helm 和一个 Kubernetes 集群，默认的模型服务使用 NVIDIA GPU。先克隆仓库并切到 release-1.0 分支：
git clone https://github.com/llm-d/llm-d.git && cd llm-d && git checkout release-1.0
export REPO_ROOT=$(realpath $(git rev-parse --show-toplevel))
source ${REPO_ROOT}/guides/env.sh
export GUIDE_NAME="quickstart" NAMESPACE=llm-d-quickstart
接着安装 Gateway API Inference Extension 的 CRD，创建 Hugging Face token 的 secret，用 helm 部署路由器（自带 Envoy 代理），再用 kubectl apply -k 部署 vLLM 模型服务。默认是两个 Qwen/Qwen3-32B 副本；文档也给出了 CPU 上的替代配置，例如 Llama-3.2-3B-Instruct。这不是一分钟能跑完的流程：模型权重下载要几分钟，文档原文写的是 “may take several minutes”。
接下来
llm-d 博客列出的下一步包括：active-active 路由器配置、推理请求的故障转移与迁移、托管 Kubernetes 上更完整的 vLLM 大规模专家并行覆盖、多模态与音频服务，以及和 ArgoCD 等 GitOps 控制面的深度集成。博客把它们写成进行中的工作，不是已经交付的功能。