推理成本打到 1/11，这 500 人把 llm-d 送进了 CNCF

llm-d 1.0 在 2026 年 11 月 13 日正式发布。500 多位贡献者，来自 25 个以上组织，创始方是 Red Hat、IBM、Google Cloud、CoreWeave 和 NVIDIA，现在由 CNCF 治理。

听着挺热闹。但如果你只是在自己电脑上跑个开源模型玩一玩，这篇对你帮助不大，可以先划走。

因为它管的是训练完成之后那一段，也就是分布式推理的编排机制。目标也很直白：让大模型推理可靠，并且便宜到能天天跑生产。

真正难受的是中间那批人。模型能跑，一上量就贵；一并发就抖；一升级就断。这篇是写给他们看的。

先泼盆冷水：1.0 只是把地基浇完了

1.0 这个版本号容易让人误会。它不代表这套东西突然什么都会了，只代表底层那几件事终于稳到可以承诺。

它之前就是一个开源项目，工具箱里已经有货。1.0 的意义在于，把分布式推理从”能凑合跑起来”，往”敢上生产”推了一步。

说白了，这不是一个大版本的功能狂欢，是一个基础设施项目在向你交付稳定性。你要是期待读到什么颠覆式的新范式，大概率会失望。

但稳定这件事本身，恰恰是推理成本能不能降下来的前提。这一层不稳，上面所有省钱的手段都是纸上的。

说白了：agent 把瓶颈从算力搬到了上下文

要理解 1.0 为什么长这样，得先接受一个反常识的事实。

agent 类负载的流量结构，和聊天完全不是一回事。它会反复复用同一份上下文，多轮、多任务并行地跑。

结果呢，管理上下文消耗的资源，可能比生成输出还多。压力一下子从”算力够不够”，变成延迟、吞吐、内存、成本四头一起挤。

这就是 prefix-cache 与缓存感知路由存在的理由。同一个 bot 把同一段上下文读一百遍，想便宜地服务它，靠的只有一件事：不重复计算。

便宜的本质从来不是算得更快，是算得更少。

拆开看：1.0 补的是四块承重墙

在 1.0 之前，这个项目的工具箱里已经摆了不少东西：prefix-cache 与前缀感知路由、负载感知路由、KV cache 卸载、prefill 与 decode 分离、专家并行、批处理与异步推理。

模型服务端也不挑，vLLM 和 SGLang 都能接。这些能力拼起来能跑，但撑不住生产。

1.0 新增的四项，补的正好是承重墙：

• 多租户 QoS：共享同一个 GPU 池混跑时，延迟敏感的请求不会被别的任务挤掉。
• 零停机运维：升级、维护期间的流量怎么摆，有了明确的机制。
• 稳定配置 API：配置不再跟着版本乱飘，运维能排期了。
• agent-aware serving：直接把 agent 类负载当成一等公民来服务。

agent-aware serving 这一条最容易被低估。前三条是修内功，这一条是把”agent 会怎么用模型”写进了设计前提。

顺带说一句，如果你想先在单机上把开源模型跑通，再看编排层，Xinference 那种一条命令起服务的路子更省事。等并发和跨节点的问题冒出来了，llm-d 这一层才开始有意义。

踩过的坑：装完不生效，八成卡在这四处

llm-d 支持在 Kubernetes 上做分布式推理编排，也支持 vLLM、SGLang 作为模型服务端。具体安装命令以官方仓库 README 为准，这里不抄，抄错一行比不写更坑。

下面四个坑讲的是机制，不是某个具体报错。踩进去的共同表现是：东西装了，指标没动。

坑1：只在一个模型服务端内部做路由

现象：路由开了，延迟没降，GPU 利用率也没上去。

根因：前缀感知路由的价值，是让请求落到”缓存里已经有这段前缀”的那张卡上。路由范围如果被限制在单个实例内部，它只能在本地副本之间挑，跨节点的缓存复用根本不会发生。

解法：把路由层放到模型服务端之上，让带同一份系统提示词的请求能打到持有对应 KV cache 的副本；同时让服务端的前缀缓存与路由层共用同一套前缀标识。

坑2：prefix-cache 命中率死活上不去

现象：缓存开了，命中率还是个位数。

根因：前缀缓存比的是开头那一段。prompt 开头只要塞了时间戳、随机 ID、会话 ID，或者工具返回的 JSON 字段顺序不稳定，第一屏就不一样了，后面再长也白搭。

解法：稳定内容前移，易变内容后移。系统提示词、工具定义、few-shot 放最前面；用户输入、时间戳、随机量放最后。这是工程约束，跟模型能力无关。

坑3：把 agent 负载当普通请求做负载均衡

现象：机器数量没少，吞吐上不去，长尾很难看。

根因：轮询式均衡会把同一份上下文的请求撒到所有副本上，每个副本都得重新做一遍 prefill，缓存全废，显存还被重复占着。

解法：按缓存亲和性路由，而不是按请求数均衡。让同一份上下文尽量收敛到同一批副本，KV cache 卸载和 prefill 与 decode 分离才有发挥空间。

坑4：多租户不做 QoS，池子就开始抖

现象：一个池子混跑几个业务，大 batch 一进来，延迟敏感的那个开始超时。

根因：共享 GPU 池默认是先到先服务、谁大谁先占。没有隔离层的时候，批处理任务能瞬间把队列塞满，长尾抖动就成了常态。

解法：用 1.0 的多租户 QoS 给租户分级，延迟敏感的走独立配额，批处理与异步推理丢进低优先级通道。这也是升级到 1.0 最硬的理由之一。

看数据：11.5 倍和 3000 个 agent 是怎么来的

先说 IBM Research 公布的那组。他们拿开源前沿模型配 llm-d 去探索量子纠错硬件，推理成本比全闭源方案低 11.5 倍。

同一份公布里，prefix-cache 命中率约 98%，混合服务的成本压到约 0.11 美元每百万 token。

0.11 这个数字值得多看一眼。它说明在上下文高度复用的场景里，成本曲线不是缓坡，是断崖。

另一组来自项目方的演示更狠。llm-d 在 NVIDIA GPU 上部署了 GLM 5.2，一个约 7530 亿参数的开源权重模型。

在并行数百会话的 agentic 基准上，峰值超过 660 万输出 token 每分钟，服务最多 3000 个并发 coding agent，零抢占。

零抢占这三个字比 660 万更值钱。它意味着高并发下没有请求被踢出去重试，这才是能上生产的信号。

项目贡献者的口径是，按当前云租赁价格，这套部署的每 token 成本比同类商业 API 定价低 5 到 10 倍，省得最多的部分出现在输入密集型流量上。

输入密集型，恰好就是 agent 负载的典型特征。前面铺垫那么久的上下文复用，在这里对上了账。

更实际的信号是已经有人在生产上跑了：DigitalOcean、JetBrains 的 Junie Lite、Roblox。

给个判断：这三类团队现在就该认真看它

省得你纠结，直接给一组 if/then。

if 你的账单里有三成以上花在重复的输入 token 上，then 你缺的不是显卡，是缓存感知的路由。

反过来，如果你只是本地验证想法，一天几千次请求，那痛点在显存不在编排，llm-d 帮不上你。这种时候先看 Strata 那种把显存、内存、固态三层调度压进单机的思路，更实在。

如果你已经有 Kubernetes 集群、多个模型服务端、多个业务方共享同一批 GPU，并且开始出现”延迟偶发抖动、账单按不住”的信号，那就该认真看它了。

还有一个信号更直接：主力负载是 agent、RAG、长文档反复读同一份材料。这时候压垮你的不是流量，是重复计算。

开头我说这篇对大部分人没用。现在补上后半句：对大部分人没用，是因为大部分人的量还没到需要编排的程度。

但量总会到的。到那天，决定你成本的就一件事：同一份上下文，你让它算了几次。

省下来的从来不只是钱，是你还能继续跑下去的资格。

关注圈圈，持续带你玩转 AI 工具。