vLLM过载实验揭示：仅取消请求无法扭转重试风暴

摘要：论文在 vLLM 上复现大模型服务过载场景，发现客户端与代理层自动重试会持续制造额外执行；即使请求量已低于服务容量，单纯传播取消也未能在任何实验中恢复服务，过载后仅有12%至38%的调用获得交付。调度轨迹显示，重试通常在超时前不足0.5秒启动，随后被中止的执行已消耗79%至85%的提示词Token，而现有计数器还漏记约三分之一至一半的计算量。请求合并可交付全部调用，但若既有执行已被取消，结果仍会恶化。研究据此指出，过载治理必须同时约束重试执行量并衡量客户端实际收到的响应。

---

核心发现

在带自动重试的 vLLM 服务中，过载恢复失败的主要原因不只是“请求太多”，而是客户端重试会不断把已超时的调用重新送入调度器。论文在三个开放模型上开展过载实验，并结合其中一次实验的调度轨迹，将每次客户端尝试映射到 vLLM 内部执行。

结果显示：

• 启用重试后，单纯传播取消没有在任何一组实验中恢复服务；
• 过载后到达的调用中，仅有 12%–38% 最终获得交付；
• 重试执行通常在调用超时前不足 0.5 秒 开始 prefill；
• 后来被取消的执行已经消耗了引擎所计算提示词 Token 的 79%–85%；
• vLLM 的提示词 Token 计数器漏记了全部已计算提示词 Token 的约 三分之一至一半；
• 重试预算可以阻断重试风暴并恢复服务，但会丢弃大量调用；
• 请求合并能交付过载后的全部调用，部分请求延迟完成，前提是没有提前取消仍在运行的执行。

因此，衡量过载控制不能只看入口 QPS、活跃请求数或是否返回取消信号，而应追踪两个端到端指标：重试增加了多少次无效执行，以及客户端最终收到多少有效响应。

为什么传播取消不够

典型的 LLM API 调用链路包含客户端、网关或代理，以及推理引擎。客户端在超时后发起重试，代理可能再次转发同一请求，vLLM 则将这些尝试映射为内部 request execution。

取消看似可以回收无效工作，但执行系统存在几个关键时序：

1. 客户端超时后，原请求可能仍处于排队、prefill 或 decode 阶段；
2. 重试请求在超时窗口结束前已经进入调度器，并可能抢占队列位置、KV Cache 与计算槽；
3. 取消到达时，先前执行通常已经完成大量提示词预填充；
4. 取消只能停止当前执行，无法自动撤销重试已经制造的排队压力。

换言之，取消解决的是“停止一次执行”，重试解决的是“重新制造一次执行”。如果客户端没有严格区分原始请求与重试请求，也没有在超时后停止继续施压，那么取消只是回收部分正在运行的计算，不能阻止替代请求进入系统。

论文的轨迹数据进一步揭示了成本放大效应。某次重试仅在不足半秒前启动 prefill，说明这些请求不是长期滞留的僵尸任务，而是在超时边界附近迅速进入执行阶段。由于大模型 prefill 的计算量与输入长度近似成正比，较长的提示词会让一次“已经来不及完成”的执行消耗大量 GPU 时间和 KV Cache。

Token 统计偏差会遮蔽真实浪费

论文发现，vLLM 记录的提示词 Token 数与调度轨迹中的实际计算量存在显著差距，遗漏幅度约为三分之一至一半。这会直接影响运维决策：

• 基于 Token 统计估算过载损失时，可能低估被取消执行消耗的 prefill 计算；
• 依据缓存命中率或平均输入长度判断系统压力时，可能得到错误的容量模型；
• 对比吞吐、TTFT 与有效请求率时，分子和分母使用的计数口径不一致；
• 自动扩缩容控制器可能被低估的 Token 速率误导，错误判断集群仍然有余量。

因此，服务团队需要统一“客户端提交 Token”“引擎接收 Token”“实际进入 prefill 的 Token”以及“最终用于生成输出的有效 Token”四类口径。仅依赖引擎现有计数器，不足以完整描述重试风暴造成的资源浪费。

三种过载控制策略的权衡

1. 取消传播

取消适合回收客户端已经明确放弃的请求，尤其是长生成任务。它的问题是收益高度依赖取消到达时机：如果工作已经进入 prefill，绝大部分算力已经消耗；如果重试继续产生，系统仍会陷入高准入率与低完成率并存的状态。

部署时应同时传播请求标识和重试关系，确保客户端、代理与引擎能够识别同一个逻辑调用中的多次尝试。只向引擎发送取消信号、却让代理继续自动重试，无法构成完整的过载控制。

2. 重试预算

为客户端或代理设置总尝试次数、累计尝试时间或并发重试预算，可以限制重试放大。论文中，该策略通过丢弃部分重试恢复了服务，但大量过载调用没有被交付。

这是一种明确的可用性折中：牺牲部分请求成功率，换取队列和 GPU 资源的可控性。预算过紧会降低恢复后的正常请求准入，过松则失去限流意义。更合理的策略应按请求优先级、剩余服务时间与当前队列长度动态调整，而不是采用固定次数。

3. 请求合并

请求合并把多个逻辑上相同的调用映射到共享执行，再向各等待者分发结果。在论文中，它保住了过载后的全部调用，虽然部分响应明显变晚。

这一策略适合提示词和生成参数完全相同的幂等或可合并请求，例如共享前缀缓存能够覆盖的请求。不过，它存在两个重要边界：

• 语义前提：合并的请求必须确实可以共享同一输出，不能仅因提示词文本接近就强行合并；
• 时序前提：如果取消信号已经中止原执行，新的等待者可能失去本可复用的计算结果。

因此，请求合并应与取消策略联合设计。对可取消调用，取消到达后是终止共享执行、重新调度，还是保留执行完成并丢弃单个等待者，需要依据业务 SLA 决定。

对 vLLM 运维与评测的启示

过载实验不应仅使用“入口请求低于理论容量”作为恢复标准。建议同时记录以下指标：

• 有效完成率：客户端成功收到响应的逻辑调用数，而非 HTTP 请求数；
• 重试放大系数：客户端尝试总数与原始逻辑调用数之比；
• 无效执行成本：取消执行已消耗的 prompt token、GPU 时间和 KV Cache 占用；
• 取消收益：取消到达前已经完成的计算比例；
• 尾部延迟：合并请求、排队请求与被丢弃请求应分别统计；
• 恢复时间：从负载回落到阈值以下，到成功率稳定恢复所需时间。

现有计数偏差还意味着基准测试应优先采用调度器 trace 或执行级 instrumentation，而不是只读取 API 汇总指标。尤其是比较取消、重试预算和请求合并时，必须统一请求语义、客户端超时、代理重试策略、模型长度、batch 构成及硬件配置，否则指标差异可能主要来自实验负载而非控制机制本身。

生产部署建议

针对使用 vLLM 的生产系统，可以采用四层防护：

1. 在代理层限制重试：设置最大尝试次数、退避抖动和每客户端并发重试上限，并优先重试尚未进入计算的连接失败，而不是重试已经进入 prefill 的请求。
2. 区分逻辑请求与执行尝试：让取消能够覆盖同一逻辑调用的全部待处理尝试，防止旧请求取消后又出现新执行。
3. 谨慎启用请求合并：仅对参数严格一致的请求合并，并确保取消协议不会提前摧毁仍可复用的执行。
4. 建立执行级监控：同时追踪入口 QPS、prefill token、执行尝试数、成功完成数与实际 GPU 消耗，修正现有 Token 统计遗漏。

论文的价值不在于提出新的调度算法，而在于把生产事故中常见的“重试—超时—取消”链路转化为可测量的系统行为。它也提醒团队：过载恢复不是单个引擎内部的问题，而是客户端、代理与推理调度器共同组成的闭环控制问题。

---

消息来源：ArXiv AI (cs.AI) (2026-11-10)

—— 完 ——

主题标签： #vLLM 关注 #推理调度 关注 #过载控制 关注 #请求重试 关注 #请求合并 关注