Llm-D 1.0 携生产级推理栈亮相 PyTorch 大会

据 IBM Research 发布的公告，llm-d 项目的贡献者于 2026 年 10 月 20 日在 PyTorch Conference North America 宣布推出 llm-d 1.0。这是一套原生适配 Kubernetes 的分布式推理服务栈。IBM 表示，此次发布推动 llm-d 从展示单项性能技术迈向更进一步，旨在帮助组织将模型部署转为自行运营，以应对不断上涨的推理成本。

llm-d 旨在让用户能够在任何云环境中，借助任何加速器部署适用于任何模型的推理栈。Red Hat、IBM 和 Google 是该项目的主要维护者，并与 CoreWeave 和 NVIDIA 共同创立了 llm-d；AMD、Cisco、Hugging Face、Intel、Lambda 和 Mistral AI 则已作为贡献者加入。云原生计算基金会（CNCF）将 llm-d 托管为沙箱项目。IBM 将其描述为一种不受供应商绑定的替代方案，适合希望获得其所称的前沿级推理性能、又不想完全依赖某一家专有模型提供商、云服务商或硬件平台的组织。

IBM Research 杰出工程师、llm-d 联合创始人兼首席维护者 Carlos Costa 表示，1.0 版让 llm-d 成熟到足以像其他关键服务一样投入运行。他指出，这一版本具备稳定的 API，支持多个优先级各异的租户共享同一基础设施，并且升级不会中断运营。

1.0 版新增内容

该项目于 2026 年 10 月 20 日在 GitHub 上发布的 v1.0.0 版发布说明带有签名且经过验证的标签，重点介绍了多租户服务质量：支持优先级感知和公平性感知的流量控制，并可受控地卸载负载，其中包括概率准入机制、程序感知公平性和轮次优先级评分。借助这些功能，对延迟敏感的请求和突发性代理工作负载可以共享同一资源集群，在负载过高时也不会相互挤占、导致某一方得不到服务。流量控制配置现已统一收敛到单一的 flowControl 字段下。

为实现零停机运维，路由器新增了通过热备实现的高可用能力，并支持安全的滚动更新；DisaggregatedSet 控制器则将预填充和解码副本作为一个逻辑单元管理，支持协调发布、同步升级、以 Pod 快照作为就绪条件，以及原生版本路由。路由器配置 API 升级为 v1，Responses API 支持 previous_response_id，端点选择器的请求路径也经过加固，以提升可靠性、性能和可扩展性。此外还提供了针对 DRA 和 DRANET 的拓扑感知型加速器指南。

面向代理的服务能力新增了会话状态生成器插件和动态会话亲和性，使多轮对话能够贴近其缓存上下文；同时，轮次优先级调度和 Responses API 状态可帮助代理在不同轮次间复用上下文。此次发布将项目各组件统一到 v1.0.0，并补充了生态系统组件，包括与 ai-dynamo/modelexpress 的集成，以支持模型权重的点对点加载、llm-d-api-extensions 软件包，以及 llm-d-pd-utils 诊断工具；同时弃用了项目自行构建的 llm-d-rocm 容器镜像。模型服务器镜像包含适用于各类加速器的 vLLM 和 SGLang 构建版本；预填充/解码分离指南现要求使用 LeaderWorkerSet v0.11.1 或更高版本，并启用 DisaggregatedSet API。

核心技术与流量控制

自项目启动以来，团队一直专注于五种提升推理性能的方法：前缀缓存感知路由，将请求导向可能已缓存其共享上下文的基础设施；KV 缓存卸载，在 GPU、CPU 和存储资源之间转移缓存信息；批量推理优化；预填充/解码分离，将读取提示词与生成响应的过程拆开；以及大规模专家并行，将大型混合专家模型分布到众多加速器上。这些技术在 1.0 版发布之前就已存在；据 IBM 介绍，此次的新内容是围绕这些技术实现了集成，并提升了其运维成熟度，还建立了面向 Day 2 运维的规范，以便在流量变化、硬件故障、软件更新或不同用户争用相同资源时维持性能。

在 1.0 版中，流量控制、公平性和优先级机制旨在防止突发性工作负载压垮对延迟敏感的服务，无论这些工作负载共享同一硬件，还是分布在不同类型的加速器上；此外，请求可在多轮对话期间持续固定到适当的基础设施上，从而保持前缀缓存处于热状态。llm-d 可与 vLLM 或 SGLang 等推理引擎协同工作，并在其上增加分布式路由和运维能力。Red Hat 首席技术官办公室副总裁 Stephen Watt 表示，llm-d 将 PyTorch 和 CNCF 生态系统整合起来，把原生适配 Kubernetes 的编排能力直接带给 vLLM 和现代推理引擎。

已展示的成果与公布的成本

在一篇于2026年7月22日发布的基准测试文章中，该项目对 GLM-5.2 的智能体式服务进行了测量。文章将其描述为一款拥有 744B 个参数、包含 39B 个活跃参数和 78 层的混合专家模型。工作负载分析基于 219 次生产环境中的 Claude Code 会话：主代理请求的输入 token 数中位数为 195K，返回 317 个输出 token；主代理的轮次中有 96% 重用了至少 90% 的输入。文章称，前缀感知路由利用了该工作负载所能实现的 96–97% 缓存复用率。按假设的 H200 租用费率每 GPU 小时 2.71 美元计算，文章估算，在两种由 64 块 GPU 组成的部署配置下，自托管服务每百万个输入 token 的成本为 0.05 至 0.08 美元，每百万个输出 token 的成本为 1.92 至 3.55 美元。作者指出，这些数字仅计入 GPU 租用费用，并假设负载持续稳定。

在另一项演示中，IBM 和 Red Hat 使用 544 块 NVIDIA H100 GPU 部署了 GLM-5.2。IBM Research 的报告将其描述为一款拥有约 7530 亿个参数、约 39 亿个活跃参数的开放权重模型。IBM 报告称，该部署在峰值时每分钟可处理超过 660 万个输出 token，同时支持多达 3,000 个并发编码智能体，且未发生抢占；在 2,500 个智能体的运行配置下，系统持续达到每分钟 7,612 个请求。IBM 表示，按当前云端租用费率计算，使用 llm-d 在 H100 GPU 上自托管 GLM-5.2，每个 token 的成本比同等商业 API 定价低 5 至 10 倍。Red Hat 推理工程团队的高级首席机器学习工程师 Maroon Ayoub 表示：“在不发生抢占的情况下为数千个并发智能体提供服务，让运营者有了一条可信的路径，能够将基准测试结果转化为生产环境部署。”

根据同一份报告，在这些结果背后，解耦数据平面完成了 620 万次 KV 缓存传输，每次传输平均为 2.71 GiB，且传输失败次数为零；所有基准测试也都在没有任何服务错误的情况下完成。