随着AI智能体能力的不断提升，它们对推理基础设施提出了新的要求。与传统聊天机器人不同，编程助手等智能体系统需要反复处理大量上下文，在多次交互中重复利用信息，并调用并行子智能体，从而产生不可预测的活动激增。这类工作负载的主要特点是读取和管理上下文，而非生成文本，这给延迟、内存、吞吐量和成本都带来了挑战。
llm-d项目由IBM研究院、红帽和谷歌牵头，并有其他行业领导者共同参与，该项目推出了一个开源框架，旨在帮助大规模服务大语言模型，应对这些新型AI工作负载带来的挑战。llm-d正在满足企业AI领域出现的一项需求：随着每Token成本不断上升，以及保护专有数据的需求日益增长，企业越来越希望在自有基础设施上部署开放模型。目前，llm-d框架已证明其有能力处理当今的智能体流量。
在近期一次使用基准工作负载的演示中，llm-d项目展示了其开源推理平台能够在H200 GPU上高效地为智能体工作负载服务大型混合专家模型。许多机构都面临同样的挑战：如何在现有GPU集群上扩展智能体工作负载。此次演示的目标是证明，这在企业和云端GPU集群中常见的H100加速器上同样可以实现。
团队使用llm-d，在544块英伟达H100 GPU上部署了GLM-5.2，这是一个约7530亿参数的开放权重混合专家模型（约390亿活跃参数）。选择该模型是为了展示当前平台运营商可能部署的实际场景。在具有数百个并发智能体会话、高上下文重用率的工作负载测试中（代表生产环境的流量模式），该部署在智能体基准测试中峰值实现了每分钟超过660万个输出Token，可同时支持最多3000个并发编程智能体，且零抢占。
按当前云端租赁价格计算，使用llm-d在H100上自托管GLM-5.2的单Token成本比同等商用API定价低5至10倍，在智能体工作负载常见的输入密集型流量模式中，节省幅度最大。IBM研究院杰出工程师、llm-d维护者Carlos Costa表示："我们希望证明，一个自托管的开放权重模型可以在长上下文智能体工作负载下，以具有竞争力的交互吞吐量运行真实的智能体工作负载，而且使用的是大多数机构已经拥有的GPU。llm-d已经证明它能够大规模处理这类工作负载。我们希望在常见的上一代GPU集群上，针对这种规模的模型缩小差距，而这正是我们此次所展示的内容。"
理解智能体流量
在此前的研究中，来自219个真实Claude Code会话的数据表明，为智能体工作负载提供服务需要与传统聊天机器人推理不同的方法。编程智能体大部分时间都用于反复读取和处理大量上下文，而生成长回复所占的时间相对较少。这些上下文通常包含整个软件代码库——是一项重复且繁重的工作。研究中的请求中位数携带约19.5万个Token，但仅生成317个Token，这意味着计算挑战主要集中在处理输入上下文，而非生成文本。
基于此次演示，llm-d团队总结出智能体工作负载的三个特征：极长的上下文、对早期轮次信息的大量重用，以及来自子智能体的并行活动突发。分析发现，相同信息会被反复处理：96%的主智能体请求逐字重用了先前请求至少90%的输入内容。相比之下，高效系统应缓存并重用之前的计算结果，而非从头重新计算。研究还表明，超过一半的请求是以并发子智能体任务组的形式到达的，且没有提前通知，这会造成工作负载的突然激增，服务系统必须在不牺牲响应能力的前提下应对这种情况。
llm-d如何提供帮助
llm-d结合了六项能力，以减少重复的上下文处理、在负载下保持缓存重用，并独立扩展预填充和解码容量。
由于智能体服务中的大量计算都用于重新处理系统已经处理过的上下文，前缀感知路由会将每个请求定向到已保存其缓存上下文的服务器，使系统重用先前的计算结果，而非从头开始。在CyberGym智能体基准测试中，从优化的近似路由切换到精确前缀匹配后，吞吐量提升了79%，首Token生成时间降低了67%。分层键值（KV）缓存管理将工作缓存扩展到CPU内存，使有用的前缀在GPU内存压力下得以保留，而非被清除后重新计算。当最佳缓存匹配位于另一台服务器上时，点对点（P2P）KV缓存共享会从该对等节点直接获取，而非在本地重新计算前缀。这些能力共同作用，减少了首Token生成时间，并通过避免重复的预填充工作来保留GPU容量，即便请求在服务器之间迁移时也是如此。
一个7530亿参数的模型无法容纳于单台服务器。llm-d通过采用数据并行注意力机制的广域专家并行来解决这一问题，该方法将模型分布到多个节点上，同时避免了张量并行方式在GLM-5.2多头潜在注意力机制下所需的KV缓存复制。随后，预填充/解码分离将上下文处理与Token生成拆分为独立的资源池，各自针对其工作负载进行调优，并根据需求进行扩展。两个资源池通过英伟达的NIXL零拷贝传输库进行通信，在整个基准测试过程中未出现任何传输失败。这使运营商能够将模型部署到现有的H100节点集群中，并根据工作负载需求的变化，独立扩展上下文处理和Token生成能力。
最后，多Token预测（MTP）在每次前向传播中生成多个输出Token，显著提升了高并发下的输出吞吐量。由于MTP建立在其他优化措施之上，其收益会不断叠加。
Costa表示："llm-d不仅仅是一堆功能的集合，而是关于所有这些功能在生产环境中协同工作，运行在任何机构都能够部署的基础设施之上。这就是它们整合在一起时的效果。"
大规模服务已就绪
团队在544块H100 GPU上以分离拓扑结构部署了GLM-5.2，分别设置了独立的预填充组和解码组。该部署支持一项满足关键业务需求的内部工作负载，涉及数百至数千个并发智能体，处理具有高上下文重用率的长上下文多轮任务。该系统专为处理持续的大规模生产流量而构建。
为了确定系统的极限并在受控条件下验证每项能力，团队在内部工作负载的同时运行了结构化基准测试。每项基准测试都使用全新的前缀和种子，以防止先前的缓存状态影响结果。
AutomationBench通过将并发编程智能体数量从2000个扩展到3000个来测试原始并发能力。在2500个智能体这一舒适运行点上，该部署维持了每分钟7612个请求，峰值输入吞吐量为每分钟1.3489亿个Token，峰值输出为每分钟605万个Token，且全程零抢占。在3000个智能体时，输出达到每分钟660万个Token，随后接近系统的服务极限，但未出现抢占或故障。
另外，CyberGym评估了长上下文智能体完成任务的能力：400个并发智能体，每个智能体在10轮交互中处理37.6万字符的上下文。在完整路由方案下，全部400个智能体轨迹在248秒内完成，速率为每分钟967.7个请求，首Token生成时间的第90百分位为17.59秒，队列等待时间的第90百分位仅为1.11秒。本地前缀命中率达到73.18%，高于近似路由下的44.46%。
AgentX测试了128个并发智能体在约15分钟内处理约19.5万Token上下文的交互吞吐量。该基准测试完成了7251个请求，速率为每秒7.7个请求，首Token生成时间的第90百分位为5.77秒。测试过程中，168个请求触发了对另一工作节点上可重用KV缓存块的P2P查找。
在这些结果背后，分离式数据平面处理了全部工作负载。NIXL完成了620万次KV缓存传输，平均每次传输2.71 GiB，在集群第90百分位维持约580 Gb/s的传输速率，且零传输失败。每个成功请求对应近一次传输的比例表明，几乎所有流量都经过了分离的预填充/解码流水线。CPU层缓存吸收了2.53 PiB的提示块存储，并向GPU恢复了2.16 PiB，平均每次恢复耗时79.6毫秒。所有基准测试均以零服务错误完成。
在测得的缓存分解数据中，该技术栈从缓存中提供了85.2%的输入Token，将未缓存的预填充比例降低至14.8%，为新上下文和生成任务留出了更多GPU容量。
红帽团队成员、推理工程高级首席机器学习工程师Maroon Ayoub表示："我们追求的不是单一的峰值吞吐量数字。我们想了解这种规模的开放模型能否支撑起定义智能体系统特征的长上下文、重用和突发流量。在不出现抢占的情况下服务数千个并发智能体，为运营商提供了一条从基准测试结果通往生产部署的可靠路径。"
这对平台运营商意味着什么
llm-d等技术使已经拥有GPU基础设施的机构也能够触及前沿级开放模型服务能力。以往要以具有竞争力的吞吐量服务这种规模的模型，往往需要更新一代的硬件或完全托管的API端点。这次演示表明，只要拥有合适的软件技术栈，广泛部署的H100基础设施同样能够交付出色的结果，为拥有大规模H100集群的运营商提供了一条无需等待下一代加速器、即可自托管服务长上下文智能体工作负载的路径。
Costa表示："拥有大规模H100集群的运营商看到这些数据后，会发现在自有基础设施上服务前沿规模模型是一条可行的路径。智能体推理是一个系统性问题。收益来自于避免冗余工作、路由至正确的缓存、独立扩展预填充和解码能力，而不仅仅是原始的GPU吞吐量。"
IBM研究院高级技术人员Nili Guy表示："这些结果并非H100基础设施能够交付性能的上限。它们为我们提供了一个坚实的基准，开放服务技术栈的每一次改进都会拓展同一集群所能支撑的能力上限。这正是llm-d的机遇所在：软件层面的改进能够不断放大运营商现有硬件的价值。"
团队将继续以开放的方式推进llm-d的发展，将大规模内部部署中积累的经验应用于解决社区中的实际痛点。深入理解这些系统在持续智能体流量下的运行表现，将指引项目下一步的建设方向。
llm-d是一个开源项目，也是云原生计算基金会（CNCF）沙箱项目，由IBM研究院、红帽、谷歌以及不断壮大的贡献者和采用者社区共同参与建设。该项目提供部署指南、经过验证的配置方案以及多平台支持。欲了解详情，请访问llm-d.ai。
Q&A
Q1：llm-d是什么？它主要用来做什么？
A：llm-d是由IBM研究院、红帽和谷歌等共同推动的开源推理框架，用于大规模部署和服务大语言模型，特别适合处理AI智能体这类需要频繁读取和重用大量上下文的复杂工作负载。
Q2：使用llm-d部署GLM-5.2模型能节省多少成本？
A：按当前云端租赁价格计算，使用llm-d在H100 GPU上自托管GLM-5.2的单Token成本比同等商用API定价低5至10倍，在智能体工作负载常见的输入密集型流量场景中节省幅度最大。
Q3：llm-d通过哪些技术手段提升了智能体工作负载的处理效率？
A：llm-d结合了六项关键能力，包括前缀感知路由、分层KV缓存管理、点对点缓存共享、广域专家并行、预填充/解码分离以及多Token预测，共同减少重复计算、保持缓存重用，并支持独立扩展处理能力。
