PyTorch推理请求超时与取消处理实战

在GPU算力平台进行推理部署时，客户端超时并不代表服务器已经停止计算。如果请求断开后后台任务仍继续排队、预处理和占用GPU，流量高峰会出现"用户已放弃，算力仍被消耗"的情况。本文从超时分层、队列截止时间、取消标记和结果回收入手，构建可控的PyTorch推理链路。

一、问题背景

一次模型请求通常经过网关、Web服务、任务队列、GPU执行和结果返回。每层都可能设置不同超时。GPU算子一旦提交，并不总能在中途安全打断，因此取消设计的重点是：尽早丢弃尚未执行的请求、避免返回无用结果，并保证资源最终释放。

大模型训练关注长任务容错，在线深度学习服务则更关心毫秒到秒级截止时间。使用GPU服务器租用或AI算力平台时，应把队列时间纳入延迟，而不是只测模型前向。

二、环境准备

准备异步Web框架、PyTorch模型、压测脚本和唯一请求ID。记录网关、应用与客户端超时设置。润云智算提供GPU资源及镜像环境，可从官网了解当前服务信息；本文不假定具体网络或显卡参数。

三、实操步骤

1. 统一超时预算

假设端到端预算为两秒，可拆分为排队、预处理、GPU执行和返回时间。外层超时应略大于内层，避免网关先断开而应用仍不知情。将预算写入配置，不要散落在代码常量中。

python 复制代码

REQUEST_TIMEOUT = 2.0
QUEUE_BUDGET = 0.3

2. 为任务记录截止时间

python 复制代码

import asyncio, time
from dataclasses import dataclass

@dataclass
class Job:
    request_id: str
    payload: object
    deadline: float
    future: asyncio.Future

使用单调时钟计算剩余预算，避免系统时间调整影响判断。请求进入队列时就确定截止时间。

3. 出队前丢弃过期任务

python 复制代码

async def take_valid(queue):
    while True:
        job = await queue.get()
        if time.monotonic() >= job.deadline:
            if not job.future.done():
                job.future.set_exception(asyncio.TimeoutError())
            continue
        return job

动态批处理时也要在组批前过滤过期任务，避免它们占用批次位置和显存。

4. 处理客户端取消

应用收到断开或协程取消后，应标记Future并停止尚未开始的预处理：

python 复制代码

try:
    result = await asyncio.wait_for(job.future, timeout=remaining)
except (asyncio.TimeoutError, asyncio.CancelledError):
    job.future.cancel()
    raise

不要在取消时直接终止共享GPU进程，否则可能影响同批其他请求。已经提交的批次可以完成，但结果写回前必须检查状态。

5. 安全分发批量结果

python 复制代码

for job, output in zip(jobs, outputs):
    if job.future.cancelled() or job.future.done():
        continue
    job.future.set_result(output.cpu())

异常时同样要逐个设置错误，避免调用方永久等待。临时文件、输入缓存和CPU对象应放在finally中清理。

6. 做超时场景压测

分别模拟正常请求、慢预处理、队列拥塞和客户端提前断开，记录成功率、超时率、过期任务数、队列长度、P95延迟与GPU利用率。更换GPU算力平台后，用相同并发和输入复测。润云智算实例也应验证流量恢复后队列能否回落。

四、常见问题与解决方案

1、客户端断开后GPU为何还在运行？

已提交的GPU工作通常不会因HTTP连接断开自动取消，应尽量在提交前过滤。

2、超时设置越短越好吗？

不是。过短会增加无效失败，应依据业务目标和实测分布设置。

3、Future取消后显存会立即释放吗？

不一定，GPU批次和张量引用仍可能存活，需完成生命周期管理。

4、多级超时如何配置？

内层先到期、外层留少量返回余量，并为每层记录清晰错误码。

五、总结

请求超时治理的核心是统一预算、携带截止时间、提前过滤、谨慎处理已提交GPU任务，并保证结果与资源最终回收。对推理部署而言，吞吐之外还要关注无效计算比例。完善取消链路后，GPU算力平台才能在突发流量下保持稳定；大模型训练所用的长任务策略不能直接替代在线超时设计。

FAQ

Q1：能否强制中断单个CUDA算子？

在线服务中通常不应依赖这种方式，优先在排队和组批阶段取消。

Q2：如何识别无效计算？

统计已超时但仍进入GPU的请求数及其耗时占比。

Q3：超时请求要重试吗？

仅对幂等请求按策略重试，并设置次数和退避，避免放大拥塞。

Q4：队列满时如何处理？

快速返回过载响应，让上游限流或稍后重试，不要无限排队。