推理层迎来"Kubernetes 时刻"：llm-d 1.0 发布，3000 个 coding agent 的账单能打下来吗

2026 年 10 月 20 日，开源分布式推理框架 llm-d 发布了 1.0 版本。官方博客的标题很有野心："llm-d v1.0: State-of-the-art inference, ready for Day 2"（最先进的推理，为 Day 2 而来）。发布时间点卡得很准：PyTorch Conference North America（10 月 20–21 日，San Jose）开幕当天，项目方把 1.0 当作大会的开场礼物扔了出来。

如果你没听说过 llm-d，一句话介绍：它是一个跑在 Kubernetes 上的开源推理"控制平面"，坐在 vLLM、SGLang 这些推理引擎之上，负责决定"每个请求该发到哪台机器、KV 缓存怎么复用、预处理和解码怎么拆开跑"。项目由 IBM、Red Hat、Google 联合主导创办，CoreWeave 和 NVIDIA 是创始方，AMD、思科、Hugging Face、英特尔、Mistral 都是贡献方，现在是 CNCF 沙箱项目。一年半时间，从几个人的想法长成了 500 多位贡献者、25+ 组织的"分布式推理开放标准"——这是官方博客自己的说法。

1.0 的核心命题只有一句话，官方博客把它放在了最显眼的位置："Serving a frontier model fast is no longer the hard part. Running it reliably, for many tenants, through upgrades, under real load, is."（把前沿模型跑得快不再是难事；难的是让它可靠地跑起来——为多个租户、穿越版本升级、扛住真实负载。）翻译成大白话：Day 1 是"跑起来"，Day 2 是"不出事地跑下去"。1.0 就是 Day 2 的版本。

一、1.0 到底带来了什么：四个 Day 2 能力

第一，多租户 QoS（服务质量）。一个共享推理集群里，延迟敏感的在线请求和"动不动就爆发"的 agent 负载挤在一起，谁先谁后？1.0 在路由器里做了集中式流控：每个请求按"公平 ID（租户/工作负载）+ 优先级带"分类进不同的队列，先按优先级调度，再在同优先级内跨租户公平轮转。过载时做"无悔调度"——请求宁可排在路由器里等，也不塞进已经过载的后端队列，这样一个租户的突发不会炸掉所有人的延迟；还有一个概率性准入控制器，容量不够时优雅地降载（load shedding），而不是直接崩。结果是：同一个 endpoint 后面，高级租户的延迟在负载下依然被保护，普通和批处理流量去吸收波动。

第二，零停机运维。路由器（Endpoint Picker）支持热备， active 实例挂了 standby 立刻接管，路由不中断。更关键的是 DisaggregatedSet：把预处理（prefill）池和解码（decode）池当成一个逻辑单元来管理，升级时两边"锁步"滚动，请求只会被路由到"两边都已升级完且版本兼容"的 prefill/decode 对上。以前做 P/D 拆分部署，升级要另起一套集群再手动切流；现在可以原地滚动升级不断流。用官方的话说：disaggregation 不再只是一种性能技巧，而是一种"可以运营的东西"。

第三，稳定的 v1 配置 API。配置接口毕业到 v1，成为版本化的稳定面——平台团队可以把它当作标准来构建，不用每个版本追 breaking change。这对"把 llm-d 当底座"的厂商（比如 Red Hat AI、GKE）是定心丸。

第四，agent 感知的服务能力。这是 1.0 里和 vibe 开发者关系最直接的一块。Agent 负载的特点是：多轮对话复用巨量上下文，算力大头花在"处理上下文"而不是"生成最后那几个 token"上。1.0 对此有三招：会话感知路由——把多轮对话钉在已经持有其 KV 缓存的副本上，一个 session-state-producer 插件给请求打会话标签，路由器把后续轮次送回同一台后端，亲和性一直保持到副本饱和再 rebalancing；轮次优先级调度——路由器理解一个请求在整轮对话中的位置，让活跃的 agent 循环保持响应，而不是把每一轮都当成孤立请求；原生 Responses API 状态——支持 previous_response_id，服务端替你扛住跨轮上下文，agent 不用每次重发完整历史，栈也不用重复计算。对 agent 构建者来说：延迟更低、成本更低，而且不用改应用代码。

上面这张架构图把 1.0 的核心部件摆在了一起：最上是网关，中间是 llm-d-router（路由智能：前缀缓存感知 + 多租户流控 + 会话感知），下面是拆开的 prefill 池和 decode 池（由 DisaggregatedSet 统一管理、协同升级），旁边是 KV 缓存分层（GPU HBM → 主机内存 → 存储之间搬运），最底下是 vLLM / SGLang 引擎。记住这个分层逻辑：llm-d 不碰模型推理本身，它只做"控制平面"——决定请求去哪、缓存怎么复用、池子怎么升降级。引擎负责"算"，llm-d 负责"调度"。

二、0.x 到 1.0：先解决"跑得快"，再解决"跑得稳"

理解 1.0，先要理解 0.x 干了什么。官方博客把 0.x 系列的目标概括为一个词：reach（覆盖面）——让推理基础设施不被锁定在某一家厂商、某一朵云、某一个引擎上。这个阶段 llm-d 交付的是一组"性能技巧"：前缀感知路由（prefix-aware routing：把请求送到已经缓存了相同前缀的机器上）、KV 缓存卸载（KV cache offloading：把显存放不下的 KV 缓存搬到主机内存和存储上）、预处理/解码拆分（prefill/decode disaggregation：把"理解输入"和"生成输出"这两个阶段拆到不同的 GPU 池上，各自独立扩缩容）、大专家并行（wide expert parallelism：MoE 模型的专家分布到多卡多机上）。

这些技巧在 0.x 时代证明了自己：Google Cloud 用它把 Vertex AI 的首 token 时间砍了 35% 以上、缓存命中率翻倍；AWS 在 SageMaker HyperPod 上跑出比标准 vLLM 高 70% 的 token/秒；特斯拉和 Red Hat 在 AMD MI300X 上把 Llama 3.1 70B 的输出吞吐干到 3 倍。但官方博客很诚实地承认：这些都是 Day 1 的胜利——"把模型跑得快"。而生产环境的真正难题在 Day 2："Getting a model to serve fast is Day 1. Keeping it serving, for many tenants, through upgrades, under unpredictable load, is Day 2, and it is where most inference stacks show their seams."（让模型跑得快是 Day 1；让它持续地跑——为多个租户、穿越升级、扛住不可预测的负载——是 Day 2，也是大多数推理栈露馅的地方。）

Day 2 难在哪？官方博客列了五条，每一条都是运维同学的血泪：第一，流量是混合的——延迟敏感的在线请求旁边，挨着动不动就爆发、复用巨量上下文、还会并行开工的 agent 负载；第二，优先级会打架——过载时必须有人让路，高级租户的延迟要被保护，普通流量去吸收波动；第三，升级不能停机——任何组件的替换和故障转移都不能丢请求，缓存还得是热的；第四，P/D 拆分让部件数量翻倍——预处理池和解码池要一起往前滚，一个没对齐就出事；第五，agent 流量 mostly 花在上下文上——栈如果不理解会话和轮次，就会一遍遍重复计算相同的工作。1.0 的四个能力（多租户流控、零停机运维、v1 API、agent 感知）正好一一对应这五条。这是一种很扎实的版本规划：不是堆功能，而是把生产环境排障时最痛的五个点逐个吃掉。

还有两个 1.0 的技术细节值得单拎出来说。第一，流控的"无悔调度"（no-regret scheduling）：过载时请求宁可排在路由器里等，也不提交给已经过载的后端队列。这个设计很反直觉——通常的做法是"尽快把请求交出去"，但 llm-d 的选择是"路由器比后端更清楚全局水位"。类比一下：与其让 10 个人挤进已经满员的电梯，不如让他们在电梯口排队，电梯口的人至少能看到所有楼层。这是一种"中心化智能"的胜利，也是控制平面存在的全部理由。

第二，拓扑感知的加速器调度（topology-aware scheduling）：通过 DRA（动态资源分配）把"设备和网络位置"纳入调度考量，让紧耦合的并行计算落在真正"离得近"的加速器上（比如 GB200 NVL72 机架内的跨节点 NVLink fabric）。这句话翻译成人话就是：调度器不仅知道"哪台机器有空"，还知道"哪两台机器离得近、带宽大"。对大模型并行推理来说，"放错位置"的代价是实打实的通信延迟——调度器开始理解物理拓扑，意味着 llm-d 从"逻辑调度"进化到了"物理感知调度"。

三、谁在用：从 JetBrains 到特斯拉的生产级名单

1.0 敢叫"ready for Day 2"，底气来自一份生产环境名单，全部出自官方博客（厂商自述口径，引用时注意）：

• IBM Research：在 llm-d 上自建托管前沿开放模型，给 coding agent 和芯片设计 agent 用——3000 个 coding agent 并发跑在 544 块 NVIDIA H100 上，前缀缓存命中率约 98%，每百万 token 成本约 0.11 美元，比专有方案低约 11.5 倍；
• Google Cloud：GKE Inference Gateway 建在 llm-d 的 Endpoint Picker 上，Vertex AI 生产环境首 token 时间降 35% 以上，前缀缓存命中率从 35% 翻到 70%，正在把 llm-d 1.0 集成进 GKE（覆盖 TPU 和 NVIDIA GPU）；
• JetBrains：Junie（AI coding agent）背后跑的就是 llm-d，用调度器的预测延迟路由在高 agent 负载下保持响应快；
• AWS：SageMaker HyperPod 上跑 P/D 拆分推理，前缀缓存感知路由 + NIXL，token/秒比标准 vLLM 高 70%；
• DigitalOcean：分布式推理栈建在 llm-d 上，万亿参数的 Kimi K3 模型横跨 AMD 和 NVIDIA 硬件 serving；
• 特斯拉 × Red Hat：Llama 3.1 70B 跑在 AMD MI300X 上，前缀缓存感知路由带来 3 倍输出 token/秒、首 token 时间减半；
• Mistral AI：区域推理服务的一部分流量跑在 llm-d 上；Red Hat：Red Hat AI 内置 llm-d，已在 OpenShift GA，还上了 Azure 和 CoreWeave 的托管 K8s。

这份名单的信息量在于它的"异构性"：云厂商（Google、AWS、DigitalOcean、OCI）、芯片厂商（NVIDIA、AMD、Intel、Google TPU）、模型厂商（Mistral）、工具厂商（JetBrains、Red Hat）全在同一张桌子上。官方博客的原话是："Different clouds, different accelerators, different engines, one stack."（不同的云、不同的加速器、不同的引擎，同一套栈。）这正是"any model, any accelerator, any cloud"这个创始愿景的落地形态。

还有一层治理意义：CNCF 沙箱身份意味着 llm-d 的路线图不再由某一家厂商说了算。对比一下：当年 Kubernetes 如果留在 Google 内部，今天的多云世界会是什么样？推理层正在走同样的路——IBM、Red Hat、Google、NVIDIA、CoreWeave 把共建的成果放进中立基金会，等于向全行业承诺：这套控制平面不会变成某家云的"私有护城河"。对中小团队来说，这是比任何功能都重要的定心丸：你今天基于 llm-d 做的投入，不会因为某家厂商的战略转向而作废。

硬件覆盖也值得单列：NVIDIA 侧 Hopper（H100/H200）、Blackwell（B200）、Grace Blackwell（GB200 NVL72/GB300）全覆盖，Vera Rubin 在路上；AMD 侧 MI355X + AINIC；Google TPU 侧原生 PyTorch serving（TPU 7x 上 agent coding 负载，首 token 时间降 85% 以上、吞吐 2.4 倍）；Intel 侧 Xeon 与 GPU 全家桶。连 Rebellions、Iluvatar、MetaX 这些小众加速器都有社区贡献的 well-lit path。控制平面与加速器解耦之后，"支持新硬件"变成"写一条 thin native path"的事——这是 1.0 架构上最漂亮的一笔。

四、为什么重要：账单正在从训练转向推理

先讲一个数字故事。IBM 的人在报道里说了句大实话："the real bill is inference, not training"（真正的账单是推理，不是训练）。训练是一次性的、可以计划的；推理是持续的、随用量线性增长的。当 coding agent 从"偶尔帮你补全一行"变成"3000 个并发、7×24 跑"，推理账单就从"成本项"变成了"生死线"。llm-d 1.0 回答的正是这个问题：agent 时代，推理不再是"把模型 serve 起来"的技术活，而是"把每一分钱花在刀刃上"的运营活。

再讲"Kubernetes 时刻"这个类比。Kubernetes 出现之前，每个公司自己管服务器、自己写部署脚本；Kubernetes 之后，"容器编排"变成了一个开放、中立、大家共建的层。今天的推理层正处在同样的位置：vLLM/SGLang 解决了"单机跑得快"，但"多机、多租户、多硬件、不断升级地跑"这件事，每家还在重复造轮子。llm-d 想做的就是推理层的 Kubernetes——把"调度、路由、缓存、升级"这些脏活累活沉淀成共享的控制平面。IBM、Red Hat、Google、NVIDIA、CoreWeave 联手把它捐进 CNCF 沙箱，和当年 Google 把 Kubernetes 捐给 CNCF 的剧本如出一辙：谁也不想让推理层变成某一家云的私有领地。

第三个判断是关于 agent 负载的。官方博客里有一句很关键的话："Agentic traffic spends most of its compute on context rather than final tokens"（agent 流量的算力大头花在上下文上，而不是最终 token 上）。这意味着传统"按 token 计费"的成本模型正在失效——你以为你在为"生成的代码"付钱，实际上你在为"重复传输和重复计算的上下文"付钱。会话感知路由、KV 缓存分层、previous_response_id 这些 1.0 能力的共同指向，就是把"上下文复用率"这个指标打上去。98% 的前缀缓存命中率（IBM 的数字）意味着什么？意味着 100 次请求里 98 次不用重新算前缀——账单里水分最多的那部分被拧干了。

最后一句判断：llm-d 1.0 最大的新闻不是某个功能，而是"推理工程"这个工种的正式确立。以前，跑模型是算法工程师的副业；以后，"让 3000 个 agent 的推理又稳又便宜"会是一个独立的岗位方向，有自己的工具链（llm-d）、自己的核心指标（缓存命中率、TTFT、每百万 token 成本）、自己的升级仪式（零停机滚动）。Kubernetes 当年把"运维"变成了一个职业，llm-d 正在对"推理运维"做同样的事。对 vibe 开发者来说，这意味着：你不需要成为推理工程师，但你需要知道这个工种存在——当你的 agent 产品开始为推理账单头疼时，你知道该招什么样的人、用什么样的栈。

五、给 vibe 开发者的成本账：自建推理 vs 调 API

这篇的读者最关心的问题一定是：这跟我有什么关系？我又没有 544 块 H100。关系在于"成本账"本身——llm-d 1.0 把"自建推理"这件事的门槛往下拽了一大截，而自建 vs 调 API 的盈亏平衡点，正在向中小团队移动。

先算一笔账。IBM 的官方数字：自建 llm-d，每百万 token 约 0.11 美元，比"专有方案"低约 11.5 倍（厂商自测，引用请标注）。假设你的产品每天烧 1 亿 token（一个中等规模的 agent 产品很容易达到）：调 API 按每百万 token 1 美元算，一天 100 美元，一年 3.65 万美元；自建按 0.11 美元算，一年 4000 美元出头。差了一个数量级。当然，自建的账不能只算 token——还要加上 GPU 租赁/折旧、K8s 运维人力、llm-d 本身的学习成本。但 1.0 的意义恰恰在于压缩后两项：v1 稳定 API、零停机升级、多租户 QoS 开箱即用，运维人力的边际成本在下降。

那么，谁适合认真考虑自建？三个信号：第一，token 量大且稳定——用量越大，自建的单位成本优势越明显，这是简单的规模经济；第二，负载是 agent 型的多轮对话——会话感知路由和 KV 缓存分层对这种负载的优化最狠，API 计费可不跟你谈缓存命中率；第三，团队里有人能 hold 住 K8s——llm-d 是 K8s 原生的（虽然 1.0 也在解耦，但生产部署的主场仍是 K8s），没有容器编排经验的团队，自建的运维坑可能吃掉成本优势。

谁不适合？一句话：用量小、波动大、团队没运维。早期产品、demo 阶段、token 月烧几千万以下的，老老实实调 API——API 的真正价值不是"便宜"，是"零运维、零启动成本、按秒计费"。llm-d 1.0 没有改变这个结论，它改变的是结论的边界：以前"自建"前面要加"大厂"两个字，现在一个有 K8s 经验的 5 人小团队也可以认真算这笔账了。

把两种路线的差异摆成一张表，更直观（数字为本文示例演算，基于官方自述口径，实际以你的账单为准）：

	调 API（托管推理）	自建（llm-d + 自有 GPU）
每百万 token 边际成本	约 $0.5–2（看模型与档位）	约 $0.11（IBM 官方自测，H100 集群）
启动成本	零，开箱即用	高：GPU + K8s + 学习曲线
运维人力	零（云厂商扛）	需要有人 hold 住 K8s 与 llm-d
用量波动	按秒计费，天然弹性	低谷时 GPU 空转烧钱
缓存优化红利	归厂商，你享受不到	98% 前缀缓存命中直接进你的口袋
数据主权	数据出境，看厂商脸色	模型跑在自己机器上，审计透明
锁定风险	被某家 API 的定价与政策锁定	开源中立栈，迁移成本低

决策清单（四问）：第一问，你的月 token 量是否超过 10 亿？没过，API 的"零运维"价值大概率超过自建的单价优势。第二问，负载里多轮 agent 对话占比高吗？越高，自建的缓存红利越大——API 可不会把 98% 缓存命中率的省钱分给你。第三问，团队有没有 K8s 运维经验？没有的话，自建第一年的"学费"（踩坑、半夜 on-call）可能吃掉全部成本优势。第四问，有没有合规/数据主权硬要求？有，自建不是选择题，是必答题，llm-d 这类中立栈是标准答案之一。

还有一个容易被忽略的角度：数据主权。DigitalOcean 拿 llm-d 跑 Serverless Inference，Mistral 拿它做区域推理服务——"sovereign on-prem"（主权本地部署）是官方博客反复提的词。对处理敏感数据的产品（医疗、金融、政务），"模型必须跑在我的机器上"不是可选项，是合规要求。llm-d 这类中立开源栈的价值在于：它让你不被任何一家云的专有推理服务锁定，迁移成本低，审计透明。

六、诚实口径

本文事实主体来自 llm-d.ai 官方博客 2026 年 10 月 20 日文章《llm-d v1.0: State-of-the-art inference, ready for Day 2》（已亲开全文核实）与 neoteo.com 的发布说明。生产环境数字（IBM 3000 agent / 98% 缓存命中 / $0.11 per M tokens / 11.5×、Google TTFT -35%、AWS +70% 等）均为各厂商自述口径，引自官方博客，引用时请注意这是"厂商自测数字"而非独立第三方评测。创始与贡献方名单、CNCF 沙箱身份综合自官方博客与 SiliconANGLE 10 月 20 日首报。成本对比中的"1/5–1/10"为媒体报道口径，官方博客给出的是 IBM 自建 vs 专有方案约 11.5 倍——两者都是"自建显著便宜"的同一结论，不同口径请勿混用。运维提醒：DisaggregatedSet 部署需要 LeaderWorkerSet v0.11.1 或更新版本（官方发布说明明确的前置依赖），升级前请核对 release notes。自建 vs API 的成本测算为本文作者的示例演算，不是投资建议；真实成本取决于你的负载特征、硬件价格与团队运维能力。