llm-d 1.0 把开源大模型推理服务推到了可以正式扛生产流量的位置。2026 年 10 月 20 日，IBM Research 在官方博客宣布，llm-d 在北美 PyTorch 大会上发布 1.0 版，这个 Kubernetes 原生的分布式推理框架主打任意模型、任意加速器、任意云都能部署。项目由 IBM、Red Hat 和 Google 担任主要维护者，三家去年与 CoreWeave、英伟达共同创立了该项目，AMD、Cisco、Hugging Face、Intel、Lambda 和 Mistral AI 等后来也加入贡献。
1.0 补的不是性能，而是运维
前缀缓存感知路由、KV 缓存卸载、批量推理优化、预填充与解码分离、宽专家并行，这五项提速技术 llm-d 之前就已经有了，1.0 新增的是把它们装进日常运维的能力：稳定的 API、多租户共用同一套基础设施时按优先级分配资源、升级过程不停机。项目维护者的说法是，推理服务要能像其他关键业务系统一样运行，流量忽高忽低、硬件出故障、多组用户抢资源时都不能掉链子。这也是它与单个推理引擎的分工：llm-d 不替代 vLLM 或 SGLang，而是在它们之上补分布式路由和运营层，目前是 CNCF 的沙盒项目。
智能体流量为什么需要单独照顾
1.0 专门强化了对智能体负载的支持，原因在于智能体和真人提问的节奏完全不同：真人要的是快答，智能体却会突然打出一大批请求，中途停下来调用工具，过一会儿再回来接着问。llm-d 1.0 的流量控制会给不同优先级排队，防止突发流量挤垮延迟敏感的服务；多轮请求还会被固定到合适的副本上，让之前处理过的上下文留在缓存里，不必每轮重新计算。
成本账：官方给了两个参照数字
IBM 给出的两个演示数据值得记一下：在一个智能体编程负载测试中，llm-d 的前缀感知路由抓住了 97% 可复用的缓存；在另一个演示里，IBM 与 Red Hat 在自托管部署上同时跑了 3000 个软件工程智能体，花费只有按服务方式运行同一个开源模型的实际价格的五分之一到十分之一。这些是官方演示口径，还不是独立评测，但方向很清楚：当智能体把推理调用量成倍放大后，推理基础设施本身正在变成企业 AI 成本里最值得抠的一块。接下来要看的是 1.0 在真实企业集群里的稳定性口碑，以及它和各家推理引擎版本节奏的配合。
