vLLM过载实验揭示：仅传播取消无法遏制重试风暴

摘要：研究在vLLM上复现大模型服务过载与客户端重试场景，发现请求即使降至容量以下，引擎也可能因重试新增执行而无法恢复。开启重试后，单靠取消传播未能恢复任何一次实验，过载后请求的交付率仅为12%至38%。调度轨迹显示，重试通常在超时前不足0.5秒启动Prefill，被取消的执行已消耗79%至85%的已计算Prompt Token，而vLLM计数器还漏记了三分之一至一半。请求合并可交付全部请求，但必须避免取消误杀正在服务的合并执行。

---

核心发现：取消请求不等于回收执行资源

这项针对vLLM的过载实验聚焦一个容易被忽略的事实：LLM服务接收到的调用量下降，并不意味着GPU正在执行的请求量同步下降。客户端或代理在超时后重试，而服务端可能仍在为已经离开的调用者计算Prefill或Decode。重试因此形成正反馈：新增请求延长队列，队列增长触发更多超时，超时又产生更多重试。

实验中，启用重试后，单纯向服务端传播取消信号没有在任何一次运行中恢复服务；过载发生后新到达的调用中，仅有12%至38%最终获得交付。这个结果说明，客户端断开或取消只是停止“等待结果”，并不能等价于撤销已经进入vLLM调度器的执行。

为什么会形成重试放大

可将一次请求的执行与交付拆成两个独立状态：

• 执行状态：请求已进入vLLM，可能占用GPU并消耗调度时间片；
• 交付状态：生成结果成功返回客户端。

取消通常只影响客户端等待和响应投递，不一定回收执行状态。重试则创建一个新的执行实例。若旧执行尚未退出，新执行会与旧执行争抢批处理槽位和KV Cache资源。

从排队论角度看，客户端超时时间若短于系统在高负载下的尾延迟，重试间隔会与队列恢复时间发生耦合。外部到达率即使回落到服务能力以下，只要内部尚存大量“幽灵执行”，有效负载仍然高于容量。服务无法通过简单的请求率监控判断真实压力。

调度轨迹揭示的浪费窗口

论文的跟踪结果显示，被vLLM实际调度的重试通常在超时前不足0.5秒进入Prefill。这意味着，一个即将超时的调用已经触发了新的昂贵执行，随后客户端放弃等待，服务端再把结果丢弃。

更严重的是，被vLLM取消的执行已经计算了79%至85%的Prompt Token。对于长Prompt、短输出请求，Prefill通常是主要成本；一次“失败重试”并不廉价，反而可能重复支付大部分输入计算成本。

研究还发现，vLLM的Prompt Token计数器遗漏了三分之一至一半实际计算的Prompt Token。若调度器依据该计数器估算输入长度、缓存命中或资源消耗，过载控制可能低估真实工作量。仅依据名义Token数进行限流，可能低估KV Cache压力与Prefill工作量。

取消为什么失效

取消机制通常受两个条件限制。

第一，取消只能在引擎检查取消状态的边界生效。如果Prefill阶段缺少检查点，或者批处理调度粒度较粗，请求无法在算子执行之间立即停止。GPU执行具有批量并行性，已经提交的CUDA Kernel也不会因为一个请求被取消而回滚。

第二，请求合并与取消之间存在冲突。当多个调用共享同一个Prefill执行时，取消其中一个调用可能终止整个共享执行，使其他仍在等待的客户端一起失败。因此，引擎不能简单地把“任一订阅者离开”解释为“共享计算立即作废”。

这也解释了为什么取消看起来合理，生产效果却有限：它减少了无效结果交付，却没有可靠减少已启动的GPU工作。

重试预算与请求合并的权衡

重试预算通过限制重试数量，使服务恢复，但代价是部分过载调用最终未被交付。它本质上是显式牺牲部分请求，换取队列退出和系统稳定。对于可以降级、异步处理或由用户重新提交的业务，这比无限重试更容易控制尾部延迟。

请求合并则让具有相同或兼容Prompt的调用共享一次Prefill。论文中，从过载开始进入的请求全部得到交付，虽然部分结果到达较晚。该策略的收益来自减少重复输入计算，而不是单纯丢弃重试。

不过，请求合并要求系统具备前缀缓存、哈希匹配或语义路由能力，并需处理共享执行的生命周期。聚合等待窗口过短会降低合并率，过长则增加首个客户端延迟；窗口和最终响应对象之间还需定义明确的取消语义。

评测方法与局限

论文使用三个开放模型构造过载实验，并对其中一个模型的调度轨迹进行逐客户端尝试跟踪。这种设计不仅观察最终成功率，还区分“客户端收到多少响应”和“引擎实际执行了多少计算”，这是评估过载控制的重要改进。

结果仍受特定因素限制：实验集中于vLLM，模型、Prompt长度、批量大小、超时配置和客户端重试策略都可能影响结论；请求合并的具体实现也未代表所有推理引擎。论文摘要未提供多硬件集群、不同长上下文分布或真实多租户流量下的复现数据，因此不能直接推断所有LLM服务都会得到相同的12%至38%交付率。

开发者部署建议

过载控制应同时记录客户端结果与引擎执行，而不是只监控HTTP失败率：

1. 拆分成功率指标：分别统计到达数、执行数、取消数、合并数、成功交付数和最终丢弃数。
2. 采用有上限的重试预算：结合总尝试次数、总耗时和并发预算，避免各层代理独立重试形成乘法放大。
3. 传播取消，但不要把取消当作唯一恢复机制：服务端需要提供可抢占边界，客户端仍需限制重试。
4. 保护共享执行：取消订阅关系时，只移除对应等待者；若所有订阅者均离开，再终止共享Prefill。
5. 校准Prompt Token统计：结合调度器实际输入、缓存命中和前缀长度核算真实Prefill成本。
6. 评估重试新增执行量：系统恢复不能只看请求到达率，还要检查GPU时间、批处理槽位和KV Cache占用是否回落。

结论

vLLM过载实验揭示了“取消”与“停止浪费”之间的差距。真正有效的恢复机制，必须限制失败请求制造的新执行，同时让仍在等待的调用共享或复用已经完成的工作。对生产推理服务而言，重试预算、请求合并和可观测性应被视为一个联合控制环，而不是彼此独立的容错功能。

---

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

—— 完 ——

主题标签： #vLLM 关注 #重试风暴 关注 #请求合并 关注 #取消传播 关注 #过载控制 关注