当AI模型回答问题或完成任务时，它执行的是推理过程——即使用训练好的模型，针对某些输入生成相应的输出。然而，大规模实现这一过程远比听起来复杂。在单个GPU上运行一个大语言模型是一件事，而同时为成千上万甚至数百万用户和AI智能体提供模型服务则完全是另一回事。
不同请求到达时具有不同的优先级和长度，对计算资源的需求也各不相同。有些用户希望简单查询能立即得到响应，而另一些用户提交的大型任务则可以在后台运行。智能体流量带来了新的模式：智能体可能发送一连串相关请求，暂停去调用工具，然后带着几乎相同的上下文返回。与此同时，系统必须高效利用昂贵的加速器，同时避免产生长队列或重复执行相同的计算。
这一挑战类似于空中交通管制。一个繁忙的机场不能简单地把每架到达的飞机送到第一个空闲跑道。塔台的管制员必须考虑飞机的位置、目的地、大小和燃油需求，以及系统中已有的交通流量。如果管制员的工作仅是让每条跑道保持繁忙，这个挑战或许很简单，但机场不是停车场，不是每架飞机都能被同等对待。
分布式推理在大语言模型推理中扮演着类似的协调角色，它工作在vLLM和SGLang等模型服务器之上的一个层级，负责编排和优化真实世界的流量。这些服务引擎能在单台服务器上高效运行模型，而分布式推理服务框架则负责协调集群中的多组模型服务器。其路由器可以在决定请求发往何处之前，综合考虑队列深度、缓存可用性和服务器角色等因素。
为了理解分布式推理如何运作，我们将研究六项值得关注的技术创新——前缀缓存感知路由、KV缓存卸载、流量控制、批量推理优化、预填充/解码分离，以及宽域专家并行。我们还将了解这些技术如何在开源、基于Kubernetes构建的推理框架llm-d中协同工作。
前缀缓存感知路由：将工作发送到已有上下文所在之处
当语言模型读取提示词时，它会生成单词及其相互关系的内部表示，并将大部分中间状态存储在键值缓存（即KV缓存）中。如果后续请求以相同文本开头，甚至只是部分相同文本，模型可能能够复用已存储的计算结果，而不必重新处理共享的文本部分。例如，如果已有提示词是"堪萨斯州的首府是什么？"，之后你又问"加利福尼亚州的首府是什么？"，那么"...的首府是什么"这部分的KV缓存就会被复用。
这种复用机会在实际工作负载中经常出现。聊天机器人在每次对话开始时都会收到相同的系统指令。编程助手会反复查看同一个代码仓库。智能体在测试不同解决方案时，可能会反复查看此前步骤的长记录。在这些情况下，提示词的大部分内容在各轮之间保持不变。
传统的负载均衡器可能会将下一个请求发送给看起来最空闲的服务器，而不管该服务器的缓存中是否包含相关上下文。结果就是，模型必须重新读取另一台服务器早已处理过的内容。
前缀缓存感知路由则会提出两个问题：哪台服务器已经持有该提示词前缀的最大部分，哪台服务器有足够的容量来处理该请求？llm-d路由器利用缓存信息和运行状况，对可用的模型服务器进行评分并选择合适的目标。系统既有一种近似实现方式，包含一个记录最近路由决策的轻量级索引，也有一种基于模型服务器实际Token数据和缓存状态更新的精确实现方式。
如果一架飞机的乘客、行李和地面工作人员已经在某个登机口等候，把飞机送到另一个登机口就会引入不必要的工作。同样，分布式推理系统也会尝试把请求发送到已经包含所需上下文的模型服务器上。这样做的收益是减少冗余的预填充计算、降低延迟，并提高吞吐量。
在llm-d团队近期的一次演示中，前缀感知路由在测试的工作负载中捕获了97%的可用复用机会。更广泛地说，该技术对于智能体系统尤其有用，因为它们的请求通常共享长指令、源材料、对话历史和工具输出。
llm-d于2025年5月推出，由IBM研究院、红帽、谷歌云、英伟达和CoreWeave作为创始成员共同发起。多家创始合作伙伴从一开始便参与其中，包括AMD、思科、Hugging Face、英特尔、Lambda和Mistral AI等行业领导者，以及加州大学伯克利分校和芝加哥大学的学术支持者。
如今，IBM研究院、红帽和谷歌云继续引领llm-d的发展，其合作伙伴和贡献者社区也已大幅壮大。2026年3月，创始成员将llm-d捐赠给云原生计算基金会，作为一个沙箱项目，以推进在任何云端、任何加速器上为任何模型部署推理栈的使命。
KV缓存卸载：扩展模型的工作记忆
当缓存信息保持可用时，缓存感知路由的价值最大。问题在于，尽管加速器内存速度很快，但其空间很容易被长提示词、众多并发用户和长时间的智能体会话占满。
当空间不足时，模型服务器可能会清除较旧的KV缓存条目。如果后续请求需要这些内容，模型就必须重新计算，浪费加速器周期去重建片刻之前就已存在的上下文。
分布式推理通过KV缓存卸载来解决这一问题。它不再将加速器内存视为缓存上下文唯一可存放的地方，而是根据工作负载需求选择卸载目标。最急需使用的条目可以保留在高带宽的加速器内存中，而其他条目则可以转移到容量更大但速度较慢的层级，例如CPU内存、本地固态存储或共享文件系统。缓存索引会跟踪存储内容及其位置，使路由层能够将卸载的数据纳入决策考量。
从CPU内存或存储中检索缓存信息，比直接从加速器内存读取要慢，但比重新计算整个提示词要快得多、成本也低得多。因此，卸载机制将系统的有效缓存容量扩展到了超出加速器物理内存的范围。
这对于具有长而可复用上下文以及众多并发会话的工作负载最为重要。在前文提到的同一次llm-d演示中，对于128个并发请求，GPU内存提供了约90%到92%的可复用预填充前缀，而CPU卸载则帮助保留了超出GPU容量的前缀。在另一次演示中，CPU卸载帮助系统在一个由智能体驱动的长时间基准测试中，保持了高吞吐量和较短的首个Token生成时间。由于卸载发生在预填充阶段，且向较慢层级的写入是异步进行的，这些收益并不会拖慢Token生成速度。
流量控制：决定何时移动、移动什么
路由解决的是请求应发往何处的问题。但在负载压力下，系统还需要决定哪些请求先处理、哪些需要等待。当大量流量突然同时到达时，若对每个请求一视同仁，可能导致一个对延迟敏感的查询被卡在一堆低优先级任务的积压之后。
空中交通管制员面临同样的问题，并通过交通流量管理来解决。当需求超过容量时，他们会对起飞进行调度、对到达进行排序，并让低优先级的航班在地面等待，这样一架即将最终进近的满载客机就不会被一趟完全可以再等几分钟的货运航班耽误。
分布式推理需要同样的纪律性。llm-d的流量控制机制管理请求进入系统时的准入和排序方式，确保用户之间的公平性以及工作负载之间的优先级。对延迟敏感的交互式流量可以得到保护，而突发性或可延迟的工作则会按照剩余容量进行节流调度。这样可以防止某个"吵闹"的租户或智能体活动的突然激增，拖累其他所有人的响应时间。
这一点在智能体流量中尤为重要，因为这类流量本质上是不均匀的：智能体可能先闲置一段时间，然后突然发出一连串相关请求，接着又暂停去调用某个工具。流量控制机制能够吸收这种不规律性，将突发流量平滑成有序的数据流，而不是让其压垮整个集群。
批量推理优化：在不堵塞系统的前提下填补闲置产能
并非每个推理请求都需要立即得到答案。研究评估、文档处理、合成数据生成和大规模测试可能涉及成千上万甚至数百万个提示词，这些任务可以随着时间逐步完成。
这些批量任务可以利用原本可能闲置的产能来提高硬件利用率，就像把货运航班安排到闲置跑道上一样。但如果处理不当，批量任务可能会淹没系统，拖延交互式流量。批量工作负载不应该让用户在使用编程助手或客服响应时无谓地等待。
llm-d通过两个互补的组件支持批量和离线推理。批量网关提供与OpenAI兼容的接口，用于提交、跟踪和管理批量推理任务。一个异步处理器可以从消息队列（包括Redis和谷歌Pub/Sub）中拉取单个请求，并将其分派给llm-d路由器。
这种设计将任务管理与请求分配分离开来。批量层决定工作如何进入系统，而路由器仍然决定每个单独的请求应该在哪里运行。批量任务依赖流量控制机制，根据当前负载来调节其进入系统的节奏，而不是将整个任务一次性全部释放到集群中。
这样的结果是批量处理速度更快，共享基础设施的使用也更有序。企业可以在保护高优先级应用响应能力的同时，让加速器保持高效产出。
预填充/解码分离：区分两种不同类型的工作
生成大语言模型的回复涉及两个计算阶段。在预填充阶段，模型处理输入提示词并构建KV缓存。当提示词包含数万个Token时，这一阶段可能涉及大量的并行计算。在解码阶段，模型逐个生成响应Token。解码是顺序进行的，对内存访问和通信延迟高度敏感，这对硬件提出的要求与预填充阶段不同。
传统的服务系统可能会在同一组加速器上运行这两个阶段，这简化了部署，但会导致不同类型的工作负载相互争抢资源。大型预填充任务可能会打断或延迟稳定的Token生成，而为响应式解码配置的硬件，可能并不适合处理超长提示词。
预填充/解码分离使分布式推理系统能够将这两个阶段分配给专门的工作节点，并对它们进行独立扩展。路由器会选择一个预填充节点和一个解码节点，然后协调两者之间KV缓存状态的传输。
这种分离使基础设施更具适应性。以长文档为主的工作负载可能需要更多的预填充容量。支持大量活跃对话的服务可能需要更多的解码容量。运维人员可以针对实际存在压力的地方增加资源，而不必扩展整个服务集群。
分离还减少了两个阶段之间的相互干扰。提示词处理可以针对吞吐量进行优化，而生成过程则可以针对Token的稳定输出进行优化。预填充/解码分离使这两个阶段能够独立扩展，从而提高了面对多变工作负载时的效率。
宽域专家并行：将庞大模型分布到整个集群中
当今一些最大规模的大语言模型采用了混合专家（MoE）架构。MoE模型并非对每个Token都应用模型的全部部分，而是包含许多被称为"专家"的专门神经网络。一种路由机制会为每个Token仅选择一小部分专家。
这种方法减少了每个请求所需的计算量，但并没有消除存储模型全部权重的需求。大型MoE模型可能需要数百GB的内存仅用于保存全部权重，这就使得可用于KV缓存和其他推理部分的加速器内存变少。
传统的张量并行通过将单个模型运算分散到多个GPU上来解决内存问题，这可能需要GPU之间频繁通信。对于采用某些注意力机制的模型，这种方式还可能导致同一份KV缓存数据产生多个副本，从而降低了用于长上下文和并发用户的可用容量。
宽域专家并行则采用了不同的方法。它将模型的各个专家分布到多个GPU上，必要时还会分布到多台物理服务器上。当模型确定某个Token应由哪些专家处理时，系统只会将该Token发送给持有所选专家的GPU。这些专家执行计算后，结果再返回原始处理路径。由于这种通信是稀疏的，GPU之间只交换所选专家所需的信息，而不需要持续同步每一次模型运算。
用空中交通管制的话来说，系统并不需要机场里的每个专业人员都为每架飞机服务，而是将每项任务分配给实际所需的少数专业人员。这种技术的一个显著优势是内存效率。将专家权重分散到更多的加速器上，能为每个GPU留出更多内存用于KV缓存。
这种效果可能相当显著。在IBM和红帽今年进行的一次演示中，宽域布局每个GPU存储的专家权重约为65.1 GiB，而所检验的张量并行布局则为89.5 GiB。在相同硬件条件下，宽域配置提供的KV缓存容量是张量并行配置的3到9倍，具体取决于拓扑结构。
如此一来，宽域专家并行帮助像llm-d这样的分布式推理系统能够服务极其庞大的MoE模型，同时为长提示词和大量活跃会话保留足够空间。它还与预填充/解码分离形成互补：一个按阶段划分推理，另一个则将模型的专家分布到整个集群中。两者结合使用，使llm-d能够更紧密地让硬件组织方式匹配模型结构和工作负载需求。
协调整个推理系统
正如机场的空中交通管制员、地面工作人员和飞行员系统一样，每个元素单独来看都很有价值，但没有哪一个能单独支撑整个运作。
前缀缓存感知路由确定可复用上下文存在于何处。KV缓存卸载在多层级内存和存储之间保留更多上下文。流量控制管理传入请求，为并发用户维持容量。批量推理控制大量后台工作进入系统的方式。预填充/解码分离将推理中性质根本不同的两个阶段，分配给各自适合的资源。而宽域专家并行则将庞大模型物理分布到各集群中，以最大限度地利用加速器内存。
这些技术共同作用，将大语言模型服务从一堆孤立的模型服务器，转变为一个协调统一的分布式系统。随着AI从简单的聊天应用，迈向维持长上下文、调用工具、与其他智能体协作并产生不规律突发流量的智能体时代，这种区别变得愈发重要。
空中交通管制的类比终究有其局限，但其核心启示依然成立：性能取决于协调，而不仅仅是原始产能。多建跑道并不会自动让机场变得高效，增加加速器也不会自动让推理变得快速或经济。系统还需要知道工作应该发往何处，哪些内容可以复用，哪些任务可以等待，以及哪些资源最适合推理的每个阶段。
这正是分布式推理所要承担的角色。
Q&A
Q1：分布式推理具体解决了什么问题？
A：分布式推理解决的是大规模AI模型服务中的协调问题。当成千上万用户和智能体同时发起请求时，系统需要高效利用加速器资源，避免重复计算和长队列，分布式推理通过路由、缓存管理、流量控制等多种技术实现这种协调。
Q2：llm-d是什么？由哪些公司参与开发？
A：llm-d是一个开源、基于Kubernetes构建的推理框架，于2025年5月由IBM研究院、红帽、谷歌云、英伟达和CoreWeave等公司共同发起，AMD、思科、英特尔等公司也参与其中。2026年3月，llm-d被捐赠给云原生计算基金会作为沙箱项目。
Q3：宽域专家并行相比传统张量并行有什么优势？
A：宽域专家并行将模型专家分布到多个GPU和服务器，仅为每个Token激活所需专家，通信更稀疏。相比传统张量并行，它能大幅节省每个GPU的内存占用，在实际演示中，KV缓存容量可提升3到9倍。
