llm-d 1.0 于 2026 年 10 月 20 日在北美 PyTorch 大会上正式亮相，IBM Research 在官方博客中宣布了这一版本。这个 Kubernetes 原生分布式推理项目由 Red Hat、IBM 与 Google 牵头维护，三家与 CoreWeave、NVIDIA 在 2025 年共同发起该项目，AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI 等此后陆续加入贡献。1.0 的看点不在某一项跑分又快了多少，而在于它把推理服务从能跑通推到了能长期运营。
补齐的是运维短板，不是单项性能
llm-d 此前为人熟知的五项技术——前缀缓存感知路由、KV 缓存卸载、批处理优化、预填充与解码分离、宽专家并行——在 1.0 里都没有变，变的是它们之上的那层运营成熟度：稳定的 API、多租户服务质量管理、零停机升级，以及让不同优先级的负载共享同一套基础设施时不互相拖垮的流控机制。项目联合创始人、IBM Research 杰出工程师 Carlos Costa 的说法是，1.0 要让 llm-d 能像其他关键服务一样被运维，而不是只在演示里跑出漂亮数字。
同一个入口，人和智能体的请求分开照顾
企业级推理服务面对的流量正在变样：同一个端点后面，既有等着秒回的代码助手用户，也有一阵一阵突发调用、中间还要停下来用工具的智能体。1.0 的流控与公平调度会在需求高峰时明确决定谁先拿到资源，并让多轮请求尽量固定在同一副本上，使前缀缓存保持热度。IBM 给出的测试数字是，在一项智能体编程负载中，前缀感知路由抓住了 97% 的可用缓存复用；在另一项自托管演示中，3000 个软件工程智能体并发运行的成本只有同等托管服务的五分之一到十分之一。
对自建推理的团队，这意味着多一个中立选项
llm-d 不替代 vLLM、SGLang 这类推理引擎，而是站在它们之上补分布式路由和运营能力，项目目前托管在 CNCF 沙盒中。对已经把模型部署在自有 Kubernetes 集群上的团队，1.0 降低的是把开源权重模型跑成生产服务时的工程门槛，算力花在哪、缓存命中多少开始变得可管理。边界也要说清：它仍然要求团队具备 Kubernetes 运维能力，托管在云厂商现成推理服务上、且用量不大的团队，未必能从这套自建栈里省回成本。
