llm-d 1.0 发布:Kubernetes 原生分布式推理服务走向生产就绪
IBM、Red Hat 和 Google 等主导的开源推理项目 llm-d 在 PyTorch Conference North America 上发布 1.0 版本,这是一个 Kubernetes 原生的分布式推理服务框架,支持任意模型、任意加速器和任意云。
IBM Research:AI·2026-10-20 20:00· 41 分钟前精选AI 评分60
llm-d 1.0 hardens open-source AI inference for production
AI 导读
IBM、Red Hat 和 Google 等主导的开源推理项目 llm-d 在 PyTorch Conference North America 上发布 llm-d 1.0,这是一个 Kubernetes 原生的分布式推理服务框架,支持任意模型、任意加速器和任意云。
推荐理由
原文给出 llm-d 1.0 的具体能力变化和实测成本数据,读者可据此评估自建推理基础设施是否划算。
今天在北美 PyTorch 大会上,llm-d 项目贡献者宣布推出 llm-d 1.0,这是开源 AI 基础设施的一个重要里程碑。作为一个 Kubernetes 原生的分布式推理服务网络,llm-d 使得在任何云上、任何加速器上为任何模型部署推理栈成为可能。
此次发布标志着 llm-d 已不再局限于展示单项性能技术,而是准备好支撑生产环境的现实需求:在多种工作负载下保持持续效率,同时在需求不断增长的情况下平衡各项服务优先级。随着推理成本上升,llm-d 旨在帮助企业将模型部署引入内部,并让 AI 投资获得回报。
这项工作由一个不断壮大的开源社区共同开发,成员包括硬件提供商、模型开发者、云平台和企业用户。作为 llm-d 的首席维护者,Red Hat、IBM 和 Google 帮助将先进的推理技术转化为企业可规模化运营的协同系统。这三家公司去年与 CoreWeave 和 NVIDIA 共同创立了 llm-d,AMD、Cisco、Hugging Face、Intel、Lambda 和 Mistral AI 等行业领导者也陆续作为贡献者加入。
其成果是为那些希望获得前沿级推理性能、又不想完全依赖某一家专有模型提供商、云或硬件平台的组织,提供了一个厂商中立的替代方案。
“llm-d 已为第 2 天运维做好准备,”IBM Research 杰出工程师、llm-d 联合创始人兼首席维护者 Carlos Costa 表示。“llm-d 一直在为生产工作负载提供最先进的推理性能。1.0 带来的是成熟度,使其能像任何其他关键服务一样运行:稳定的 API、多个优先级相互竞争的租户共享同一基础设施,以及不中断业务的升级。这正是我们构建 llm-d 1.0 的目的。”
完整的生产栈
自 llm-d 发布以来,项目一直聚焦于改进 AI 推理的五种重要方法:前缀缓存感知路由,将请求导向可能已持有其共享上下文的基础设施;KV 缓存卸载,通过在 GPU、CPU 和存储资源之间移动缓存信息来延长其有效寿命;批推理优化,将工作分组以便基础设施更高效地处理;预填充/解码分离,将读取提示词的工作与生成响应的工作分开;以及宽专家并行,将大型混合专家模型分布到众多加速器上。
这些理念对 1.0 版本而言并不新鲜。新鲜的是围绕它们的集成程度和运维成熟度。
在 1.0 版本中,llm-d 已成熟为一个能够支持第 2 天运维的栈:即 AI 服务部署之后必须发生的一切。这包括服务具有竞争优先级的工作负载、管理不同的性能需求、保持效率、优先处理重要服务,以及让系统长期保持可靠。基准测试可以表明某项功能提升了吞吐量,但生产系统必须在流量变化、硬件故障、软件更新或不同用户争夺同一资源时仍持续提供这种性能。llm-d 1.0 的目标就是让各项技术在这些更不可预测的条件下协同工作。
一个端点,多种工作类型
llm-d 1.0 在已经让 llm-d 成为强大分布式推理工具的核心技术创新基础上进一步扩展,增强了对多租户服务质量、零停机运维和智能体感知服务的支持,以在常见的第 2 天生产运维中保持持续性能。企业 AI 服务可能通过同一端点接收来自人员和自主智能体的请求,但这些工作负载的行为方式不同。使用编码助手的人期望快速得到答案。智能体可能发送大量突发请求,在使用工具时暂停,然后返回进行下一轮模型调用。
借助流控,llm-d 1.0 可以管理工作负载是共享同一硬件还是跨越多种加速器时的竞争优先级。流控、公平性和优先级排序有助于防止突发工作负载压垮对延迟敏感的服务。在需求很高时,系统可以更审慎地决定哪些请求应优先获得资源。请求还可以在多个轮次中保持绑定到适当的基础设施。这可以保持其前缀缓存处于热状态,提高先前处理过的上下文被复用而不是重新计算的机会。
这对对话式助手很重要,但对智能体尤其有价值。智能体在执行任务时经常回到相同的代码、文档、指令和对话历史。前缀缓存感知路由会将每一轮发送到已经持有相关上下文的副本,而 KV 缓存卸载有助于在 GPU 内存受限时保留更多可复用信息。这就是生产就绪在实践中的样子:通过理解到达模型的工作并相应地管理基础设施,更有效、更具成本效益地提供模型服务。
以更好的基础设施提升 AI 投资回报率
这种对生产的关注直接关系到 AI 的经济性。随着 AI 进入日常业务运营,推理已成为一项经常性支出。智能体系统可能会增加这项支出,因为单个任务可能涉及多轮推理、工具使用、评估和修订。如果每一步都需要模型重新阅读相同材料,你就是在为系统已经完成的工作反复付费。
在最近一次智能体编码工作负载测试中,llm-d 的前缀感知路由器捕获了97% 的可用缓存复用。通过避免重复计算并更高效地利用现有硬件,这类技术可以降低大规模提供 AI 服务的成本。在另一项近期演示中,IBM 和 Red Hat 在自托管部署上同时运行了 3,000 个软件工程智能体,成本比以服务形式提供同一开放模型的实际价格低 5 到 10 倍。
当组织运营自己的基础设施时,基础设施就成为可管理的成本结构的一部分。通过将开放权重模型与开放服务栈相结合,llm-d 为组织提供了另一种选择,用以控制 AI 使用量、基础设施支出和业务价值之间的关系。
连接开源 AI 生态系统
llm-d 可与 vLLM 或 SGLang 等推理引擎配合使用,增加将模型服务器转变为生产服务所需的分布式路由和运维能力。
这也让 llm-d 在更广泛的开源生态系统中扮演了重要角色。PyTorch 与开发 AI 模型和应用的人群密切相关。而作为沙箱项目托管 llm-d的云原生计算基金会(CNCF),则更侧重于在生产环境中部署和运行系统。llm-d 项目是连接这两个世界的桥梁。
“llm-d 通过将 Kubernetes 原生编排直接引入 vLLM 和现代推理引擎,统一了 PyTorch 与 CNCF 生态系统,”Red Hat 首席技术官办公室副总裁 Stephen Watt 表示。“它提供高性能的分布式推理,并具备企业所需的可靠性和规模——这一切都运行在企业已经熟悉的运营模式之内。”
IBM 对 llm-d 的贡献体现了其一贯的做法:将能够改进计算的理念转化为组织可在现实世界中使用的开放技术。
借助 llm-d 1.0,这项工作帮助打造出一个推理栈,它不仅性能出色,还能在 AI 成为关键基础设施时持续稳定运行。开源 AI 推理已准备好投入生产环境进行运营、治理和优化。
来源:IBM Research:AI · research.ibm.com
来源:RadarAI · aihot.news