取消请求为何仍救不了过载的 LLM 引擎？重试留下了什么

导语

大模型服务出现超时后，客户端或代理通常会自动重试。直觉上，只要把用户已经放弃的请求取消掉，推理引擎就能释放资源并恢复吞吐。但一篇发表于 arXiv 的研究指出，问题并没有这么简单：重试请求可能在取消生效前已经消耗了大量计算，随后又继续把调度器推入拥塞状态。

核心发现

研究人员在 vLLM 上使用三种开源模型进行过载实验，并对其中一种模型记录调度轨迹，将每次客户端尝试与其在引擎中创建的执行关联起来。实验结论主要有三点：

• 取消单独使用无法恢复服务。 在开启重试的实验中，取消机制没有在任何一次运行中恢复服务。过载结束后新到达的请求，最终只有 12% 至 38% 被交付。
• 取消往往来得太晚。 vLLM 实际运行的重试通常在超时前不到半秒才开始进行 prefilling。即使之后执行被中止，它已经完成了所需提示词计算量的 79% 至 85%。
• 监控指标可能低估真实浪费。 vLLM 的提示词 token 计数器漏记了约三分之一至一半已经计算的提示词 token，单看该指标可能错误判断系统负载和取消收益。

研究还比较了两类控制手段。重试预算通过限制重试数量让服务恢复，但代价是过载期间的许多调用没有被交付。请求合并则把针对同一调用的重复尝试合并起来；在没有被取消机制提前中止运行中执行的情况下，它能够交付从过载开始之后的全部调用，不过部分请求会较晚完成。

意义与影响

这项工作重新定义了“取消成功”的衡量方式。接口层面返回了取消，并不意味着 GPU 计算已经停止；同样，系统恢复空闲，也不代表用户请求得到了结果。评估过载控制时，至少应同时观察重试新增了多少实际执行、执行已经消耗了多少 token，以及客户端最终收到多少响应。

对 LLM 服务运营者而言，单纯增加取消传播并不能替代重试治理。更可靠的设计可能需要在客户端、代理和引擎之间共同限制重试，并尽早识别重复请求、合并相同工作，同时建立能覆盖已执行 token 的资源指标。研究并未宣称某一种方案适用于所有部署，但它清楚表明：恢复能力取决于执行层和交付层，而不仅是请求是否被标记为取消。

来源：arXiv