分布式推理服务是AI流量的空中交通管制塔，而智能体工作流使其比以往任何时候都更加必要。
当AI模型回答问题或完成任务时，它执行的是推理，即使用训练好的模型根据某些输入生成输出。然而，大规模地做到这一点比听起来更具挑战性。在GPU上运行一个大语言模型是一回事，同时将该模型服务于数千甚至数百万用户和AI智能体则完全是另一回事。
请求以不同的优先级和长度到达，具有各自独特的计算需求。一些用户期望对简单查询立即得到响应，而另一些用户提交可以在后台运行的大型任务。AI智能体流量增加了一种新模式：智能体可能发送一批相关请求，暂停以调用工具，然后带着几乎相同的上下文返回。与此同时，系统必须高效利用昂贵的加速器，同时不产生长队列或重复执行相同的计算。
这一挑战类似于空中交通管制。一个繁忙的机场不能简单地将每架到达的飞机引导到第一个可用的跑道。塔台管制员必须考虑飞机的位置、目的地、大小和燃油需求，以及系统中已有的交通流量。如果所有空中交通管制员要做的只是让每条跑道保持繁忙，挑战可能很简单，但机场不是停车场，并非每架飞机都能以相同方式对待。
分布式推理对LLM推理扮演着类似的协调角色，在vLLM和SGLang等模型服务器之上工作，负责编排和优化真实世界的流量。这些服务引擎在单个服务器上高效运行模型，而分布式推理服务框架则协调集群中的多组模型服务器。其路由器可以在决定请求应发往何处之前，考虑队列深度、缓存可用性和服务器角色。
为了理解分布式推理的工作原理，我们将探讨六项值得注意的技术创新——前缀缓存感知路由、KV缓存卸载、流控制、批量推理优化、预填充/解码分离，以及宽专家并行。我们还将了解它们如何在llm-d中协同工作，这是一个开源的、Kubernetes原生的推理框架。
前缀缓存感知路由：将工作发送到上下文已存在的地方
KV缓存卸载：扩展模型的工作记忆
流控制：决定什么移动以及何时移动
批量推理优化：在不堵塞系统的情况下填充空闲容量
预填充/解码分离：分离两种不同类型的工作
宽专家并行：将巨型模型分散到整个集群
协调整个推理系统
前缀缓存感知路由：将工作发送到上下文已存在的地方
当语言模型读取提示时，它会生成词语及其关系的内部表示，并将大部分中间状态存储在键值缓存（即KV缓存）中。如果后续请求以相同的文本开头，甚至是相同文本的部分内容，模型可能能够重用已存储的计算，而不是重新处理共享文本。例如，如果现有提示是“What is the capital of Kansas?”，之后你问“What is the capital of California?”，那么“what is the capital of”部分的KV缓存就会被重用。
这种机会在实际工作负载中频繁出现。聊天机器人在每次对话开始时接收相同的系统指令。编程助手反复检查同一个代码仓库。AI智能体在测试不同解决方案时可能重新查看之前步骤的长记录。在每种情况下，提示的大部分内容在轮次之间保持不变。
传统的负载均衡器可能会将下一个请求发送到看起来最不繁忙的服务器，无论其缓存是否包含相关上下文。结果，模型必须重新读取另一台服务器已经处理过的材料。
前缀缓存感知路由则提出两个问题：哪台服务器已经持有该提示前缀的最大部分，以及哪台服务器有足够容量来处理该请求？llm-d路由器使用缓存信息和运行状况对可用的模型服务器进行评分，并选择合适的目的地。它既有包含近期路由决策轻量级索引的近似实现，也有基于实际token数据和来自模型服务器的缓存状态更新的精确实现。
如果一架飞机已经让乘客、行李和地勤人员在某个登机口等待，却将其调往另一个登机口，就会带来不必要的工作。同样，分布式推理系统会尽量将请求发送到已经包含所需上下文的模型服务器。其收益是减少冗余的预填充计算、降低延迟并提高吞吐量。
在 llm-d 背后的团队最近的一次演示中，前缀感知路由在测试工作负载中捕获了 97% 的可用复用。更广泛地说，这项技术对智能体系统尤其有用，因为它们的请求通常共享长指令、源材料、对话历史和工具输出。
llm-d 于 2025 年 5 月启动，由创始成员 IBM Research、Red Hat、Google Cloud、NVIDIA 和 CoreWeave 协作推进。多个创始合作伙伴也从一开始就参与其中，包括 AMD、Cisco、Hugging Face、Intel、Lambda 和 Mistral AI 等行业领导者，以及加州大学伯克利分校和芝加哥大学的学术支持者。
IBM Research、Red Hat 和 Google Cloud 今天继续领导 llm-d 的开发，其合作伙伴和贡献者社区也已大幅增长。2026 年 3 月，创始方将 llm-d 捐赠给云原生计算基金会，作为沙箱项目，以进一步推进其使命：在任何云中、任何加速器上部署任何模型的推理栈。
KV-cache 卸载：扩展模型的工作记忆
缓存感知路由在缓存信息仍然可用时最有价值。问题在于，尽管加速器内存速度很快，但其空间可能会被长提示、大量并发用户和延长的智能体会话迅速填满。
当空间不足时，模型服务器可能会驱逐较旧的 KV-cache 条目。如果后续请求需要这些材料，模型必须重新计算，从而浪费加速器周期来重建片刻之前还存在的上下文。
分布式推理通过 KV-cache 卸载来解决这个问题。它不再将加速器内存视为缓存上下文唯一可存在的位置，而是根据工作负载需求选择卸载目标。最立即有用的条目可以保留在高带宽加速器内存中，而其他条目可以移动到更大但更慢的层级，例如 CPU 内存、本地固态存储或共享文件系统。缓存索引会跟踪存储了什么以及存储在哪里，使路由层能够将卸载的数据纳入其决策。
从 CPU 内存或存储中检索缓存信息比直接从加速器内存读取更慢，但比重新计算整个提示要快得多，也便宜得多。因此，卸载将系统的有效缓存容量扩展到其加速器上可用物理内存之外。
这对具有长且可复用上下文以及大量并发会话的工作负载最为重要。在上一节提到的同一个 llm-d 演示中，对于 128 个并发请求，GPU（图形处理器） 内存提供了约 90% 到 92% 的可复用预填充前缀，而 CPU 卸载有助于保留超出 GPU 容量的前缀。在另一个演示中，CPU 卸载帮助系统在一个长时间的智能体驱动基准测试中维持高吞吐量和低首 token 时间。由于卸载在预填充期间运行，并且对较慢层级的写入是异步进行的，因此这些收益不会减慢 token 生成。
流控制：决定什么移动以及何时移动
路由回答了请求应该去哪里。但在负载下，系统还必须决定哪些请求先移动——以及哪些请求等待。当流量突发同时到达时，对所有请求一视同仁意味着延迟敏感的查询可能会被困在低优先级工作的积压之后。
空中交通管制员面临同样的问题，并通过交通流量管理来解决。当需求超过容量时，他们会限制起飞、安排到达顺序，并将优先级较低的交通留在地面等待，这样一架满载的客机在最后进近时就不会因为一架本可以轻松等待几分钟的货运航班而延误。
分布式推理需要同样的纪律。llm-d 的流控管理请求进入系统时的准入和排序方式，在用户之间执行公平性，在工作负载之间执行优先级。对延迟敏感的交互式流量可以得到保护，而突发性或可延迟的工作则按照剩余容量进行节奏控制。这可以防止单个嘈杂的租户或智能体活动的突然激增降低其他所有人的响应时间。
这在智能体流量场景下尤为重要，因为这种流量本质上是不均匀的：一个智能体可能闲置不动，然后突然发出一批相关请求，接着暂停去调用工具。流控可以吸收这种不规则性，将突发流量平滑为有序的请求流，而不是让它们压垮集群。
批处理推理优化：在不堵塞系统的情况下利用闲置容量
并非每个推理请求都需要立即得到回答。研究评估、文档处理、合成数据生成和大规模测试可能涉及数千或数百万个提示，这些提示可以在一段时间内逐步完成。
这些批处理作业可以通过利用原本可能闲置的容量来提高硬件利用率，就像将航空货运路由到未使用的跑道一样。如果处理不当，批处理作业可能会淹没系统并延迟交互式流量。批处理工作负载不应让用户不必要地等待编码助手或客户服务响应。
llm-d 通过两个互补组件支持批处理和离线推理。Batch Gateway 提供兼容 OpenAI 的接口，用于提交、跟踪和管理批处理推理作业。异步处理器可以从消息队列（包括 Redis 和 Google Pub/Sub）中拉取单个请求，并将其分发到 llm-d 路由器。
这种设计将作业管理与请求放置分离。批处理层决定工作如何进入系统，而路由器仍然决定每个单独的请求应该在哪里运行。批处理作业依靠流控根据当前负载来控制其进入速度，而不是一次性将整个作业释放到集群中。
其结果是更快的批处理速度，以及更有序地使用共享基础设施。组织可以保持加速器的高效运转，同时保护高优先级应用程序的响应能力。
预填充/解码分离：将两种不同类型的工作分开
生成 LLM（大语言模型） 响应涉及两个计算阶段。在预填充（prefill）阶段，模型处理输入提示并构建 KV 缓存。这一阶段可能涉及大量并行计算，尤其是当提示包含数万个 token 时。在解码（decode）阶段，模型一次生成一个 token 的响应。解码是顺序进行的，对内存访问和通信延迟高度敏感，对硬件的需求与预填充不同。
传统的服务系统可能会在同一组加速器上运行这两个阶段，这简化了部署，但会在不同类型的工作负载之间产生竞争。大型预填充作业可能会中断或延迟稳定的 token 生成，而为快速解码配置的硬件可能不适合处理超长提示。
预填充/解码分离允许分布式推理系统将各阶段分配给专门的工作节点，并独立扩展它们。路由器选择一个预填充端点和一解码端点，然后协调它们之间生成的 KV-cache 状态的传输。
这种分离使基础设施更具适应性。以长文档为主的工作负载可能需要更多的预填充容量。支持大量活跃对话的服务可能需要更多的解码容量。运维人员无需扩展整个服务集群，而是可以在实际存在压力的地方添加资源。
分离还减少了各阶段之间的干扰。提示处理可以针对吞吐量进行优化，而生成则可以针对令牌的稳定交付进行优化。预填充/解码分离允许两个阶段独立扩展，从而提高可变工作负载的效率。
宽专家并行：将巨型模型分散到整个集群
当今一些最大的语言模型使用混合专家（MoE）架构。MoE 模型不是将模型的每个部分都应用于每个令牌，而是包含许多专门的神经网络，称为专家。路由机制为每个令牌仅选择一小部分专家。
这种方法减少了每个请求所需的计算量，但并未消除存储模型全套权重的需求。大型 MoE 模型仅保存所有 权重就可能需要数百 GB 的内存，从而留给 KV cache 和推理其他部分的加速器内存更少。
传统的张量并行通过将单个模型操作划分到多个 GPU 上来解决内存问题，但这可能需要 GPU 之间频繁通信。对于使用某些注意力机制的模型，它还可能创建相同 KV-cache 数据的多个副本，从而减少可用于长上下文和并发用户的容量。
宽专家并行采用了不同的方法。它将模型的专家分布到多个 GPU 上，并在必要时分布到物理服务器上。当模型确定哪些专家应处理某个令牌时，系统仅将该令牌发送到持有所选专家的 GPU。这些专家执行计算，结果返回到原始处理路径。由于这种通信是稀疏的，GPU 交换的是所选专家所需的信息，而不是持续同步每个模型操作。
用空中交通来比喻，系统并不要求机场的每位专家都处理每架飞机。它将每项任务引导到实际需要的一小部分专家。内存效率是这项技术的一个显著优势。将专家权重分散到更广泛的加速器组中，可为每个 GPU 上的 KV cache 留出更多内存。
效果可能非常显著。在 IBM 和 Red Hat 今年的一项演示中，宽布局每个 GPU 存储了约 65.1 GiB 的专家权重，而所检查的张量并行布局为 89.5 GiB。在相同的硬件上，宽配置提供了三到九倍的 KV-cache 容量，具体取决于拓扑结构。
通过这种方式，宽专家并行帮助像 llm-d 这样的分布式推理系统服务超大型 MoE 模型，同时为长提示和大量活跃会话保留空间。它还与预填充/解码分离相辅相成：一个按阶段划分推理，另一个将模型的专家分布到整个集群。两者结合使用，使 llm-d 能够将硬件的组织方式更紧密地匹配模型的结构和工作负载的需求。
协调整个推理系统
正如机场的空中交通管制员、地勤人员和飞行机组系统一样，每个要素本身都很有价值，但无法独立运行整个运营。
前缀缓存感知路由（Prefix-cache-aware routing）识别可复用上下文的所在位置。KV 缓存卸载（KV-cache offloading）在内存和存储的层级结构中保留更多此类上下文。流控（Flow control）管理传入请求，以维持并发用户的容量。批量推理（Batch inference）控制大量后台工作如何进入系统。预填充/解码分离（Prefill/decode disaggregation）将推理的根本不同阶段发送到各自适合的资源。而宽专家并行（wide expert parallelism）将大模型物理分布到多个集群，以充分利用加速器内存。
它们共同将 LLM 服务从一组孤立的模型服务器转变为一个协调的分布式系统。随着 AI 从简单聊天迈向能够维护长上下文、调用工具、与其他智能体协作并产生不规则流量突发的智能体，这一区别变得愈发重要。
空中交通管制的类比只能说明到一定程度，但其核心教训依然成立：性能取决于协调，而不仅仅是原始容量。修建更多跑道并不会自动使机场高效，增加更多加速器也不会自动使推理变得快速或经济。系统还需要知道工作应该去哪里、什么可以复用、哪些任务可以等待，以及哪些资源最适合每个阶段。
这正是分布式推理旨在填补的角色。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：IBM Research Blog
原文作者：Peter Hess；如有侵权，请联系管理员删除。
