vLLM如何面向Agent工作负载重做推理服务栈

导语：推理优化的对象变了

传统在线推理往往围绕单轮请求、相对稳定的上下文和连续输出进行优化。智能体应用则呈现出另一种形态：模型需要在多轮工具调用、代码执行和子代理协作中反复推进，每一轮都可能把新的工具结果追加到既有上下文。输入越来越长，新增输出却很短，服务系统因此不能只看生成速度，还要处理上下文复用、缓存容量和请求调度之间的关系。

vLLM在一篇面向AgentX基准的技术文章中，介绍了针对这类负载的全栈优化思路。文章披露的测试覆盖DeepSeek V4 Pro、MiniMax M3和Kimi K3，并以SemiAnalysis的公开AgentX代码代理轨迹作为工作负载参考。

AgentX揭示的三个服务难题

• 缓存压力更集中。 AgentX会话中位数为43轮，输入中位数约142K token，而输出中位数只有444 token。超过96%的前缀缓存命中率说明，大部分上下文并非首次计算，但这些KV状态仍需要在GPU、CPU、磁盘或不同服务实例之间保存和搬运。
• 子代理增加了拓扑复杂度。 约44%的会话包含至少一个子代理；这类任务可能从父会话分叉，再把结果合并回主流程，导致缓存亲和性和资源调度更难统一。
• 吞吐与交互延迟需要同时优化。 智能体要快速完成多次思考和工具调用，单纯追求总吞吐可能牺牲单个会话的推进速度，单纯追求低延迟又可能降低硬件利用率。

vLLM的三层方案

在数据层，vLLM继续围绕PagedAttention演进KV缓存管理。针对同时使用滑动窗口、线性注意力和全注意力的混合模型，它采用统一内存页和共享块池，让不同类型的缓存按需求动态使用容量，而不是预先静态切分。对于DeepSeek V4，文章还介绍了将原本分散的缓存布局打包到连续分配中的做法，以减少填充浪费、描述符开销和P/D传输负担；启用FP4索引器时，缓存内存占用可进一步降低约10%。

当GPU容量不足时，vLLM借助Mooncake Store构建分布式共享KV缓存池，并支持CPU内存和磁盘等层级。独立存储模式可以把缓存池扩展到额外的CPU节点和磁盘，路由器也可与Dynamo、llm-d等组件集成，让请求不必严格绑定单一实例才能命中缓存。与此同时，vLLM针对混合模型的多类型缓存查找，采用异步查询、改进数据结构以及并行收发等方式，降低调度关键路径上的CPU开销。

在执行层，优化重点包括模型适配的并行策略、内核、异步调度和推测解码。控制层则需要根据上下文长度、缓存命中率、并发度和实例负载，寻找更合适的Prefill/Decode比例。由于这些变量会持续变化，固定的P/D配置很难在所有场景中保持最优。

性能结果意味着什么

文章称，在AgentX测试中，vLLM在DeepSeek V4 Pro上达到最高每GPU每秒13万总token，在MiniMax M3上达到最高每秒376 token的交互速度；不同模型和配置相对Opus 5 API定价的服务成本优势为14.6倍至106倍。这里的结果应理解为特定硬件、模型、并发和服务配置下的基准表现，而不是所有部署环境的普遍保证。

更重要的信号是，智能体推理正在把服务系统从“生成引擎”推向“上下文基础设施”。缓存是否靠近计算、子代理之间如何共享状态、P/D实例怎样动态配比，都会直接影响每个智能体完成任务的时间和成本。对于部署方而言，未来的评估指标也需要从单请求吞吐扩展到长会话交互延迟、缓存复用率、跨节点传输成本和总拥有成本。

来源：vLLM Blog