AREX Feed Article
llm-d 1.0 发布：多租户 QoS 与不中断升级写进正式版，IBM 称芯片设计 agent 运行成本为全 Opus 5 方案的 1/11.5
10 月 20 日，在 PyTorch Conference 上，llm-d 项目贡献者，并称其达到生产就绪。这个由 Red Hat、IBM、Google Cloud、CoreWeave 和 NVIDIA 于 2025 年、现由 CNCF 治理的 Kubernetes 原生推理栈，在 1.0 里补上了多租户服务质量（QoS）、不中断升级、稳定的 v1 配置 API 和 agent-aware serving，针对的是服务上线之后的日常运行。
IBM Research 的给出了一个成本对比：为量子纠错码设计解码器硬件时，agent 要在 100 个假设的预算内反复改写、综合并验证电路；全部使用 Claude Opus 5 的配置约为 300 美元，全部使用 z.AI GLM-5.3 的配置约为 26 美元，前者约为后者的 11.5 倍。中，IBM Research 首席科学家 Ruchir Puri 把这组对比描述为 24 小时的 agent 运行。
1.0 把多租户、升级和会话状态写进路由与 API
llm-d 把一组模型服务器变成一个协调的服务池：路由器根据前缀缓存命中和负载挑选副本，KV 缓存（键值缓存）可以在加速器内存、CPU 内存和存储之间分层，prefill（预填充）与 decode（解码）可以拆到不同的池子里。项目在发布博客里说，0.x 阶段解决的是广度问题：同一套路由和调度层要跑在 NVIDIA、AMD、Intel GPU 和 Google TPU 上，支持 vLLM 与 SGLang，创始时提出的「任何模型、任何加速器、任何云」已经变成可部署的目标。
「1.0 增加的是把它当作其他关键服务来运行的成熟度：稳定的 API、多个优先级互相竞争的租户共享同一套基础设施，以及不打断业务运行的升级。」llm-d 联合创始人、IBM Research 杰出工程师 Carlos Costa 在里说。
多租户服务质量落在路由器的流控上。路由器用由公平 ID（租户或工作负载）和优先级带组成的 flow key 给请求分类，分别排队；调度时先看优先级，再在同一优先级带内按租户轮转。系统饱和时，路由器把请求留在自己的队列里，而不是塞进已经过载的后端队列。另有一个概率式准入控制器，在需求超过容量时渐进限流。这些策略收拢到单一的 flowControl 配置接口下，默认行为仍是先来先服务，已有部署不主动改配置就不会变。
不中断升级处理的是分离式部署带来的复杂度。路由器配有热备实例，活跃实例被替换或故障时由热备接管调度；DisaggregatedSet 把 prefill 和 decode 副本当作一个逻辑单元管理，用底层 Pod 的快照判断就绪，并做版本感知路由：只有两侧都完成滚动、版本兼容，请求才会被送到这一对副本上。项目称，这让分离式部署可以原地做同步升级，而不必另起一套集群再人工切换。
配置 API 升到 v1，Endpoint Picker 的请求路径在可靠性、性能和规模上做了硬化，并在多种云和加速器上验证；agent-aware serving 则针对多轮调用的上下文：session-aware routing 把同一会话固定在已经持有其 KV 缓存的副本上，副本写满后再重新平衡，turn-priority scheduling 让路由器知道请求处在一轮对话的哪一步，服务端也原生支持 Responses API 的状态（包括 previous_response_id），agent 不必每轮重发完整历史。
一个 fork、一个打包版本，和 3,000 个并发 agent
DigitalOcean 的 Serverless Inference 和 Managed Agents 建立在 llm-d 上。据 TechTarget 报道，它用的是自己的 fork 分支。该公司 AI 工程高级副总裁 Salman Paracha 对 TechTarget 说：「我们认为没有 llm-d 就无法达到分布式规模，所以对我们来说首先是能力问题，我们要把 token 量铺到非常大的 GPU 集群上。」他接着解释，分发这些 token 负载是提高缓存命中率的关键，命中率提高后，每秒 token 数和 QoS 才能改善。在 Red Hat 的新闻稿里，Paracha 说这套软件支撑的服务已处理「数万亿 token」。
据 TechTarget 报道，Red Hat 把 llm-d 连同节点级的 vLLM 推理引擎一起打包进 Red Hat AI。按 llm-d 发布博客的说法，这套栈在 OpenShift 以及包括 Microsoft Azure、CoreWeave 在内的托管 Kubernetes 上可用。Google 的 GKE Inference Gateway 构建在 llm-d 的 Endpoint Picker 上。称，Gemini 平台通过它承载生产流量，前缀缓存命中率从 35% 提高到 70%，编码 agent 的首 token 时间缩短 35% 以上，突发聊天流量下的 P95 首 token 时间缩短 50% 以上。Google 称，1.0 正在被集成进 GKE，覆盖 TPU 与 NVIDIA GPU 产品线。
据项目方公布的数据，IBM Research 的自建部署在 544 块 NVIDIA H100 上最多同时运行 3,000 个并发编码 agent，前缀缓存命中率约 98%，每百万 token 成本约 0.11 美元。llm-d 博客给出的贡献者规模是 25 个以上组织的 500 多人；Google 的发布博客称它为 CNCF 沙箱项目。
便宜配置的加速倍数更低，计价口径也不同
IBM Research 那篇论文的任务，是为 [[144,12,12]] 双变量自行车码的 Relay-BP 解码器做硬件设计空间探索。研究者把多个 agent 并行提出方案、再按综合与验证结果筛选的流程称为 agent 工厂：worker（执行任务的 agent）提出架构改动，拿正确性检查和高层次综合（HLS）的结果当反馈，决定下一轮往哪里改。
论文比较三组配置：Opus 5 同时担任协调者和 worker、Opus 5 协调加 GLM-5.3 worker、GLM-5.3 同时担任两者。在 100 个假设的预算下，三组分别消耗 2.159 亿、1.975 亿和 2.409 亿 token，成本分别为 299.45、105.25 和 25.95 美元。按 HLS 估算的延迟，三组找到的最好设计相对未改动的参考设计分别快 204 倍、126 倍和 52 倍。把 GLM-5.3 的搜索预算扩大到 200 个假设，最好结果提升到 60.4 倍，论文称边际收益已经递减。
省钱的配置也是加速幅度最小的配置。论文的结论是：全专有配置延迟最低；全开源配置用约 26 美元换来 52 倍加速；混合配置把协调留给 Opus 5、执行交给 GLM-5.3，成本约为全专有配置的 1/2.8，加速 126 倍。TechTarget 把这组结果概括为便宜模型「跟上」了闭源前沿模型；论文自己的说法是「相近的延迟-面积探索权衡」，而两者在延迟优化幅度上是 52 倍对 204 倍。
计价口径也不一样。论文对 Opus 5 按 Claude API 的标准输入、输出和缓存读取价格计价，GLM-5.3 则部署在自建集群上，按每百万 token 0.1077 美元的混合服务成本估算。一边是 API 标价，一边是自建集群的服务成本，两者并不在同一个计价基础上。
背书名单，和「支持不等于承诺」
据 TechTarget 报道，为 1.0 公开背书的还有 AMD、Cohere、JetBrains、Mistral 和 Roblox。NVIDIA 负责 AI 框架工程的副总裁 Ujval Kapasi 在 Red Hat 新闻稿里说，把 llm-d 带到 Vera Rubin 会帮助企业在下一代加速基础设施上构建和扩展先进 AI 应用。CoreWeave 的说法是，客户可以在 CoreWeave Kubernetes Service 上把 llm-d 与 NVIDIA Dynamo 并列运行，自行选择适合工作负载的服务栈。
Moor Insights & Strategy 分析师 Jason Andersen 对 TechTarget 说，企业最可能从云厂商或软件厂商那里以打包形式获得 llm-d。他同时提醒，厂商支持未必等于投入：CoreWeave 把 llm-d 作为云上的一个选项，尚未把它做成产品的核心部分；NVIDIA 把 Dynamo 的 NIXL 数据传输和 KV 缓存管理组件贡献给了 llm-d，但两个开源编排工具的功能重叠明显。「他们基本上只是在说，你在我们这儿部署、用起来，我们没意见。」Andersen 说。
他还点名希望看到 VMware 参与进来，理由是 VMware 相当认真地对待私有数据中心软件与 Kubernetes 的集成。
「任何加速器」还差一层内核
llm-d 的创始愿景是「任何模型、任何加速器、任何云」。Google 把 TorchTPU 接了进来，PyTorch 模型可以原生跑在上游 vLLM 和 SGLang 里，不必重写模型；TPU 与 GPU 队列可以挂在同一个 llm-d 端点后面，TorchTPU 的协同时间切片用来提高 TPU 队列的吞吐和利用率。
跨芯片迁移仍受限于内核层。Paracha 对 TechTarget 说，模型的内核与 TPU、NVIDIA 或 AMD 各自提供的东西绑得很紧，vLLM、SGLang 这类组件又是为高内存带宽或高计算场景设计的，「今天还不能随意互换」。Puri 也对跨架构搬运工作负载的可行性表示怀疑。
Andersen 的看法乐观一些：Google 让 llm-d 同时调度 TPU 和 NVIDIA GPU，可能是这种可移植性的起点；如果 Google 能说「从 NVIDIA 迁到我们的 TPU 更容易了」，它就有很大动力把这件事做成。
但「任何加速器」目前更像是把多种硬件挂在同一个端点后面；让同一份工作负载在它们之间自由迁移，是另一件事。跨芯片的那层内核适配，不在这次 1.0 的更新清单里。