vLLM 发布 AgentX 智能体服务优化方案与实测结果

TL;DR：智能体工作负载正成为 vLLM 流量的主要来源。其多轮会话、长上下文和大量前缀复用，要求在整个服务栈上进行优化。本文介绍 vLLM 的协同方案：KV 缓存管理、并行与引擎优化，以及预填充/解码分离的方法论。

在 AgentX（SemiAnalysis 的公开智能体基准）上实测，vLLM 在 DeepSeek V4 Pro 上达到每 GPU 秒最高 130K 总 token，在 MiniMax M3 上达到最高每秒 376 token 的交互性。在 DeepSeek V4 Pro、MiniMax M3 和 Kimi K3 上，vLLM 相比 Opus 5 API 定价带来 14.6 倍至 106 倍的服务成本优势（见 性能）。

刻画智能体工作负载：再看一次

自我们 5 月发布第一篇关于服务智能体工作负载的文章以来，智能体流量占比持续增长。截至 2026 年 6 月，OpenAI 报告称，在企业客户中，Codex 生成的输出 token 占 Codex 与 ChatGPT 合计输出 token 的 64%。

不断增长的 token 消耗从两个维度给服务基础设施带来压力：成本和延迟。成本效率决定了固定硬件预算下能容纳多少并发智能体；延迟决定了每个智能体完成其推理和工具使用循环的速度。因此，优化智能体服务意味着整体改善延迟-成本前沿。

为了在代表性流量下评估这一前沿，SemiAnalysis 最近发布了 AgentX，这是一个基于真实智能体编码轨迹构建的公开基准。这些轨迹具体展示了服务系统必须应对的工作负载特征：

• 长时间运行的多轮会话。每个会话中位数为 43 轮。
• 长上下文与短输出。输入中位数为 142K token，输出中位数为 444 token。
• 大量前缀复用。前缀缓存命中率超过 96%。
• 子智能体密集的流量。44% 的会话包含至少一个子智能体，这些会话中子智能体展开数的中位数为四个。

这些统计数据源于智能体会话的构建方式。每一轮都会将最新的工具结果追加到累积上下文中，并将整个内容发回模型，因此输入持续增长，而每一轮只新增一小段预填充，且请求中几乎全部都是引擎已经见过的前缀。子智能体要么从该上下文分叉，要么全新开始，其结果会在最终答案之前合并回父级。图 2 展示了一个这样的会话：使用滑块从第一轮逐步走到最终答案，看看每个请求中有多少是复用的前缀，多少是新的预填充。

服务智能体工作负载的挑战

这些工作负载特征给高效服务带来了三个挑战。

1. 前缀缓存压力。多轮会话的每一轮都会重放到目前为止的完整对话。为了让许多会话同时运行，引擎必须在轮次之间卸载 KV 缓存。在大规模场景下，这变得更加困难，因为 KV 缓存管理、前缀缓存和卸载必须在 GPU、预填充/解码分离实例和副本之间高效协作。
2. 执行效率。Agentic 工作负载具有长上下文和严格的延迟要求，因此引擎必须在更短时间内处理更多 token，并为每个 token 做更多工作。这需要针对新的请求形态调整并行策略、kernel、调度、投机解码以及其他引擎优化。
3. 找到合适的 P/D 比例。上下文长度和缓存命中率在不同会话和子代理之间差异巨大，路由必须高效地平衡缓存亲和性与各 rank 之间的负载。这些因素使得找到吞吐最优的 P/D 比例变得困难，而该比例还会随并发度变化。

vLLM 的方法：全栈优化

图 3 总结了这三个平面。本节其余部分将从数据平面开始逐一介绍。

数据平面：让 KV 缓存保持热态并靠近计算

混合 KV 缓存管理：一个持续演进的基础

自 PagedAttention 以来，KV 缓存管理一直是 vLLM 的核心，而长上下文的 agentic 工作负载对 KV 缓存容量施加了更大压力。现代混合模型将滑动窗口注意力、线性注意力与全注意力相结合，其缓存块在大小和生命周期上各不相同，进一步增加了分配的复杂性。

vLLM 的混合 KV 缓存管理器用一个简单的核心理念应对这种复杂性：以统一的内存页作为基本分配单元，通过一个共享块池进行管理（图 4）。

共享池让 vLLM 能够按需动态重新分配内存，而不是按注意力类型静态划分容量。这一点很重要，因为全注意力的 KV 随序列长度增长，而滑动窗口和循环状态遵循不同的生命周期和扩展规律。因此，最佳划分会随并发度、上下文长度和前缀复用模式而变化。

随着新架构暴露出碎片化和传输效率低下的问题，这一抽象仍在持续演进。例如，DeepSeek V4 最初的 KV 缓存布局将不同的缓存类型碎片化为三个大小桶，并分配了 92 个独立张量。如图 5 所示，这种碎片化在填充上浪费内存，并且对 P/D 传输和 KV 缓存卸载效率低下。

新的 packed KV 缓存布局 则将每个块的所有缓存组和层存储在一个连续的后备分配中，而不是 92 个碎片化的分配。这减少了描述符和 P/D 传输开销，并且在启用 FP4 索引器时允许使用更小的分配单元，节省了约 10% 的 KV 缓存内存。

分层 KV 缓存卸载：具有智能保留策略的分布式 KV 缓存池

为了在 GPU 内存容量之外以及跨每个引擎保留前缀缓存，vLLM 集成了 Mooncake Store 作为分布式 KV 缓存池，其设计已在我们之前的博客中介绍。此后采用率稳步增长，我们持续为 agentic 工作负载推出新功能，并在容量、效率和保留方面进行性能改进。

模型架构对等性。 KV 缓存卸载在 vLLM 中依然是一等公民，全面支持新的模型架构，包括稀疏注意力、压缩注意力和线性注意力。同时，其他引擎功能保持完整且高性能，包括异步调度、P/D 分离、推测解码和并行。

分层 KV 缓存卸载。 vLLM 支持分布式 KV 缓存池的分层存储，通过磁盘和额外的纯 CPU 节点进一步扩展容量。这通过 vLLM 的 Mooncake Store standalone-store 模式实现，该模式让外部 Mooncake 客户端拥有 CPU 池和磁盘层，并将 vLLM 工作节点变为纯请求方。通过在每个节点上启动独立的 Mooncake 客户端，我们可以用 CPU 内存和磁盘自由扩展 KV 缓存池。我们还将分布式共享 KV 缓存池与 Dynamo 和 llm-d 等路由器集成，这简化了路由策略，因为请求可以在任何实例上获得缓存命中。

性能优化。 混合模型必须为每种注意力类型分别构建键并执行查找，这会成倍增加 CPU 开销。我们通过更高效的数据结构、异步查找、将工作移出调度器关键路径以及并行发送和接收操作来降低这一成本。实现细节见 PR#46188、PR#45444、PR#45659 和 PR#47317。

会话感知的前缀缓存保留。 对于同时具有线性层或滑动窗口层与全注意力的混合模型，前缀复用需要在复用边界处保留线性状态或滑动窗口缓存。在每个 token 处保留这些快照成本高昂，因此我们结合了两种互补策略：

1. 基于间隔的保留 自动在每一轮保留提示末尾的缓存/线性状态。后续轮次和分叉的子代理通常会重放并扩展前一轮的上下文，因此可以复用缓存的上下文。

   然而，共享前缀通常在一轮内结束，因此基于间隔的保留可能无法保留检查点。为了捕获这种复用，我们引入了第二种策略：

2. Marconi 风格的选择性保留 在第二次观察到某个前缀时保留检查点。当请求遇到之前观察到的前缀但没有保留的检查点时，vLLM 会重新计算缺失的状态并在该边界处保存检查点。后续共享该前缀的请求便可以复用它。

这些策略共同在大规模代理工作负载上保持了高缓存命中率，同时避免了过多的存储开销。我们的 vLLM Kimi K3 博客 深入解释了技术细节。

执行平面：快速生成 token

模型特定的并行

现代推理系统暴露了多个并行轴，例如张量并行（TP）、数据并行（DP）、专家并行（EP）、流水线并行（PP）和上下文并行（CP）。

然而，最优并行取决于模型架构、硬件拓扑、工作负载模式和延迟 SLO。在本节中，我们研究了 NVIDIA GB 系列和 B 系列 GPU 及其 AMD 对应产品上的两个代表性模型，并讨论了我们的优化和发现。

Kimi K3

Kimi K3 采用多头潜在注意力（MLA）和 Kimi Delta Attention（KDA）。由于 MLA 将 KV 压缩到单个潜在空间且只有一个头，普通的张量并行（TP）——它会在各 rank 间复制该潜在缓存——效率并不高。

作为 TP 的替代方案，我们发现 解码上下文并行（DCP） 能带来显著的性能提升，它沿序列维度对缓存进行分片，使每个 rank 只保留 1/N 的 KV 状态。具体来说，DCP 为智能体工作负载带来两项好处（图 6）：

• 更低的解码延迟。MLA 注意力受内存带宽限制，其开销随上下文长度增长。随着智能体前缀增长，注意力在每步解码中所占比例越来越大，而将其分片到各 rank 上可缩短该步骤。
• 更高的吞吐量和 KV 容量。避免 KV 缓存复制使引擎能够保持更多序列在途运行，而不会因 KV 准入而停滞，从而实现更高的吞吐量。

DCP 的代价是额外的通信：KV 缓存按序列分片，因此每个 MLA 解码层在注意力之前需要一次查询收集，之后需要一次部分输出归约。

我们精心优化了 DCP 计算路径，以绕过 NCCL 操作并避免这些开销。我们使用对称内存缓冲区，对等 GPU 可以直接从中加载和存储。查询被直接多播到注意力内核所消费的缓冲区中。然后每个 GPU 将其部分注意力输出和对数求和指数（LSE）统计直接写入其对等方的接收槽中，每个 rank 在本地用在线 softmax 合并结果。这些 GPU 到 GPU 的写入与计算融合到同一内核中（图 7），与默认的 DCP8 实现相比，每层延迟降低约 13%。

更大的扩展域可能会改变最佳策略。例如，在 NVL72 级系统上，宽 EP 配合数据并行（DEP）可以比 DCP 扩展得更好，并在相同的解码延迟 SLO 下提供更高的吞吐量（图 8）。在更大规模的多节点 DCP 尺寸下，分片注意力的通信成本超过了它节省的计算量。DEP 将请求及其 KV 缓存分配给不同的数据并行 rank，避免了 DCP 的注意力集合通信，同时将 MoE 专家分片到各 rank 上。

DeepSeek V4

DeepSeek V4 同样具有在 TP 下会被复制的 MLA 风格 KV 缓存，导致内存使用效率低下。此外，其压缩稀疏注意力使 TP 头分片在计算上效率低下，原因有三：

• 压缩器路径对每个压缩位置只产生一个共享的 KV 表示，而非独立的逐头状态。因此 TP 无法沿 KV 头维度分片计算，每个 rank 都会重复压缩器的工作。
• 索引器虽然有 64 个头，但每个 token 只产生一个全局 top-k 选择。因此当前的 TP 路径在每个 rank 上复制完整的索引器，避免了 top-k 之前的稠密分数归约，但重复了工作。
• Sparse MLA 的瓶颈主要在于扫描和收集 top-k KV 缓存条目，而非注意力计算本身。TP 会在每个 rank 上重复大量这种内存受限的工作，却只分摊了更廉价的分头计算。

在实践中，prefill 上下文并行（PCP）在长 prefill 场景下表现最佳，而数据与专家并行（DEP）则在更广泛的服务条件下都能良好工作。

PCP 对提示序列（query 张量）进行分片，将压缩器和索引器的工作分配到各个 rank，同时为 sparse MLA 提供更宽、更高效的 head-local 形状。对于 32K 的提示，PCP8 相比 TP8 实现了 2.65× 的 prefill 加速，大幅降低了 TTFT。然而，它仍然会在各 rank 间复制解码侧状态，因此最适合专用的 prefill worker。

DCP 对 DeepSeek V4 的效果不如对 Kimi K3 那样好，因为 V4 的模型架构更为复杂（参见惨痛教训）。

DEP 则改为将请求和解码 token 分配到数据并行 rank 上，并让注意力路径完全本地化。这使得 DEP 成为我们大多数 DeepSeek V4 配置的默认选择。

在两个层级上调度混合智能体流量

智能体服务混合了频繁的仅追加请求（这些请求复用长前缀，只需短 prefill）与偶发的、跨越数万 token 的长新 prefill。这带来了两个调度问题：在实例内部，一个长 prefill 可能阻塞短的交互轮次；在 DEP 各 rank 之间，prefill 放置不均会造成负载失衡。我们用两个互补的调度控制来解决这些问题。

打破队头阻塞

默认情况下，vLLM 的分块 prefill 调度器按先进先出顺序运行。一个长 prefill 可能一步步占用整个 token 预算，而排在同一 rank 上的短轮次在长 prefill 完成之前根本无法被调度。这就是所谓的队头阻塞；图 9 在某个 rank 队列的会话视图中展示了这一点。

我们用一条简单的调度策略来解决这个问题：使用 --long-prefill-token-threshold 来限制单个请求每步可调度的 token 数。在 512 token 的阈值下，长 prefill 会为短轮次留出空间，使其能加入同一批次并更早开始解码。在 B300 上运行 DeepSeek V4 Pro 时，这将每 GPU 秒的总 token 数（TPGS）最多提升 93%，并将 P90 交互性改善约 2.3×。代价是长请求自身的 TTFT 更高，因此对 TTFT 敏感的部署应使用更大的阈值。

对齐 DEP prefill 调度节奏

DEP 引入了第二种低效：MoE 的 all-to-all 通信迫使各 rank 同步推进，因此某个 rank 处理 prefill 工作会拖慢整个组。当 prefill 在不同 rank 的不同步数到达时，这一代价会被反复付出。

为缓解这种失衡，我们将 --prefill-schedule-interval 设置为每 N 个引擎步才接纳一次 prefill 工作，使用一个在数据并行各 rank 间对齐的计数器。这会将 prefill 工作集中到各 rank 相同的步数上，并提高其余步数中完全用于解码的比例。图 10 展示了 DEP8 组中的这种节奏。

使用最优 P/D 分离配置进行扩展

仅优化单个引擎不足以找到分布式部署的最佳延迟-成本点，更多的 GPU 或分离也不会自动改善前沿。预填充和解码阶段必须速率匹配。

我们使用标准化的两阶段速率匹配方法，该方法可由智能体工作流自动化：

阶段 1：饱和分析。 分别对仅预填充和仅解码部署进行基准测试，扫描并行策略（例如 TP 与宽 EP）和部署规模（8、16 或 32 个 GPU），不断增加并发直到吞吐量饱和。输出是一个饱和表：每个（并行度、规模）配置的最大预填充/解码 req/s。

阶段 2：P/D 扫描。 从每个配置的阶段 1 饱和点推导 P/D 比率，然后在组合的分离部署上扫描并发，以收集整个运行范围内的指标。

闭环：模型专用内核与社区贡献

智能体工作负载还将内核瓶颈转向长上下文注意力、推测解码和通信。这里我们重点介绍几项具有实测端到端影响的更改。我们的所有内核均完全开源，其中一些已被其他开源引擎采用。

对于 MiniMax M3，CuteDSL 长上下文索引器将报告的 GB300 索引器延迟改善了约 3% 到 31%，具体取决于形状。上游的 MSA top-k 路径将最坏情况内核性能提升高达 4 倍，AgentX 端到端吞吐量提升约 7%；推测验证路径在报告的测试中将中等批量解码性能提升约 20%。

对于 Kimi K3，GEMM 和 reduce-scatter 融合改善了序列并行通信，而潜在尾部 MoE 融合将端到端延迟降低约 5%。

对于 DeepSeek V4，社区贡献改进了 MXFP4 MoE 和 HCA 压缩（#43584 和 #44230），添加了多流 C4A，并改进了基于聚类的 top-k。

性能：智能体优先且可公开验证

我们通过在 SemiAnalysis AgentX 上的独立验证证明 vLLM 是智能体优先的，这是一个基于 300 万美元真实世界智能体编码轨迹构建的开放数据集，具有 100 万上下文，运行在超过 1000 个芯片和约 2 兆瓦算力的公共基准基础设施上。

图 11 以 Kimi K3 仪表板为例；基准测试及其所有结果均可在 AgentX 仪表板上公开访问。我们强烈建议探索其他模型和配置的帕累托结果。

在本文中，我们重点关注三个开放前沿模型的结果：DeepSeek V4 Pro、MiniMax M3 和 Kimi K3。对于每个模型，我们报告在保持 P90 交互性高于每用户每秒 50 个 token（一个常见且严苛的延迟 SLO）的情况下，吞吐量最高的 vLLM 配置。下表总结了关键结果。

¹ 每 GPU-秒总 token 数 (TPGS) 统计输入、输出和缓存 token。详细分解可通过各模型的链接查看。

DeepSeek V4 Pro 代表高吞吐、高性价比的场景。一个 12 芯片 GB300 P/D 部署可服务 256 个并发 agent 会话，同时在 P90 下维持 58.3 tokens/s/用户。在此运行点上，它每 GPU-秒处理 83K 总 token。

MiniMax M3 将交互性进一步推高。仅用 2 台 B300，它就在 P90 下维持 74.2 tokens/s/用户，并交付 70K 总 TPGS。

Kimi K3 是最大的开放前沿模型之一，为前沿智能提供了有力论据。它拥有 2.8 万亿参数，对传统单服务器部署而言过于庞大，但 16 台 GB300 可在 P90 下维持 62.7 tokens/s/用户，同时处理 11.8K 总 TPGS。

除了性能之外，成本是与用户日常使用和 token 经济学最相关的指标。下表将三个开放模型的服务成本与 Opus 5 进行对比。

² Opus 5 的计算采用缓存输入 × $0.50/M + 未缓存输入 × $5/M + 输出 × $25/M。它假设理论缓存命中率达到完美，并排除了缓存写入费用和长上下文定价溢价，这对 Opus 是保守且有利的。该比较针对服务成本，而非模型质量。

成本优势来自 agentic 流量的决定性特征：在理论缓存命中率超过 96% 的情况下，vLLM 能有效复用前缀，并将这种复用转化为三个模型的服务效率，设置与上表相同。

对于 DeepSeek V4 Pro，服务所测工作负载在 GB300 基础设施 TCO 下每小时成本约为 $28。用 Opus 5 处理相同 token 量将花费约 $2,926，即使对每个理论上可复用的 token 都应用缓存读取价格也是如此。B300 上的 MiniMax M3 显示出 85× 的成本优势，而 GB300 上的 Kimi K3 尽管模型规模大得多，仍便宜 14.6×。

这些是截至今日的数字；仪表盘实时在线，人人可访问。AgentX harness 已在 SemiAnalysisAI/agentx-harness 公开，上述每个结果都链接到其在 InferenceX 仪表盘上的运行，便于复现。

苦涩的教训：我们在哪里失败，以及学到了什么

每个失败的想法都会缩小搜索空间。我们观察到若干案例，看似合理的直觉未能通过端到端测量。我们仍在改进这些功能，但希望分享目前学到的东西。

流水线并行 (PP) 不适合热 agentic 轮次

PP，包括 分块流水线并行 (CPP)，在长而全新的提示上表现良好。大型预填充提供了足够的工作来保持流水线各阶段忙碌，吞吐量可以近乎线性扩展，且通信成本很低。

然而，大多数智能体轮次已经缓存了系统提示和之前的轮次，每个新请求可能只增加几百或几千个 token。没有足够的新计算来高效填充流水线，而流水线气泡会消耗掉大部分潜在收益。

教训并不是 PP 无效。它对于冷启动、计算密集的预填充是有效的，但它不应成为主导智能体会话的、前缀密集的热轮次的默认选择。

解码上下文并行（DCP）无法干净地迁移到 DeepSeek V4

如前所示，DCP 对纯 MLA 模型（例如 DeepSeek R1、Kimi K2.5 和 K2.7）以及混合 MLA 模型（例如 Kimi K3）效果良好。然而，由于 DeepSeek V4 的注意力栈更为复杂，为其实现类似的收益要困难得多。压缩稀疏注意力和高度压缩注意力包含一个索引器、一个额外的压缩器以及主注意力操作。上下文并行必须对所有这些子层进行分区和协调，引入了大量的通信和实现复杂性。

我们在将通信与计算重叠以及优化相应内核方面投入了大量精力。即使有了这些改进，DCP 也只是追平了 DEP，而未能超越它。这一结果强化了执行平面部分的一个更广泛的观点：并行必须遵循模型架构。对一种潜在注意力模型有效的策略，可能无法推广到另一种。

负载均衡并不能保证更好的性能

在聚合式 DEP 部署中，我们观察到各 rank 之间的 KV 缓存使用存在严重不均衡。自然的应对方式是根据队列深度、运行中的 token 数或当前 KV 利用率来均衡请求。

然而，在我们使用 AgentX 进行的实验中，所有这些策略的表现都不如简单的会话感知粘性路由。原因在于缓存局部性：许多智能体会话的轮次间延迟很短，因此下一轮次经常在其前缀仍驻留在前一个 GPU 上时到达。将会话迁移到负载较低的 rank 会迫使系统检索 KV 缓存，即使前缀已保存在分布式 KV 缓存池中。该传输是异步的并与计算重叠，但并非没有代价。预取的块会暂时占用 GPU KV 缓存容量，减少目标 rank 可接纳的序列数量。因此，系统可能在处理更少并发请求的同时实现更均衡的队列。

对于轮次间延迟较短的工作负载，保持会话局部性比完美均衡瞬时负载更有价值。路由决策必须考虑每个 worker 上已驻留的状态，而不仅仅是排队的工作量。

前路：计划中的优化与未来工作

下一步是让智能体结构在整个服务栈中显式化。以下是每一层的一些示例。

在控制平面中，我们可以让首轮请求的路由更加显式——这类请求往往需要长时间的新预填充来填满前缀缓存——以及第 2 轮及以后的请求，它们获得高缓存复用和相对较短的追加预填充。这种分离避免了队头阻塞，并让我们能够在两侧以不同方式配置引擎设置和并行，例如使用 PCP 和 CPP，以最大化双方的效率。

在执行平面和数据平面，我们正在与社区合作以支持：

• Agent 提示。Agentic 框架或运行环境可以在请求中携带提示，例如会话结构、潜在分支点和缓存位置、工具调用延迟或会话生命周期。我们的第一步是通过标准化 API 消费这些提示，然后利用它们指导引擎进行调度、缓存淘汰策略和其他优化。
• 可编程 KV 缓存。不同的工作负载需要不同的放置、保留、复制和淘汰策略。可编程接口可以让用户控制 KV 缓存的预取、淘汰或软固定，以匹配其工作负载模式。
• 基于会话的 KV 缓存管理。轮次之间的间隙创造了一个机会，可以将保留的 KV 状态迁移到可能为下一轮提供服务的 worker。在这个空闲间隔期间进行预取可以隐藏传输延迟并减少冷恢复。

致谢

这项工作由 Inferact 牵头，并得到了 vLLM 社区的大力支持。我们感谢 SemiAnalysis 开发并运营开放的 AgentX 基准测试，并使其方法论和结果可复现。我们还感谢 NVIDIA 和 AMD 在整个工作中给予的密切合作和支持。