Torchserve工作流处理超14个异步请求时卡顿失败求助

在单GPU机器上运行包含串联双模型流水线的Torchserve容器时，发送超过14个Python异步请求到流水线端点，会出现长时间卡顿后失败，报错信息：

Number of consecutive unsuccessful inference 1

但直接向流水线中的任意单个模型发送异步请求时，即使是1000个请求也能正常处理完成。怀疑是Torchserve配置或流水线编排存在问题，已提供请求代码、流水线配置、处理脚本、全局配置及Torchserve日志。

1. 调整流水线资源配置参数 #

Torchserve默认配置未适配双模型串联的资源需求，需针对性修改config.properties：

• model_threads：单个模型的推理线程数，双模型串联时实际占用线程数为model_threads * 2，过高会导致GPU上下文切换过载。建议先调至4-8（根据GPU显存和核心数适配）。
• async_inference_threads：控制异步请求的线程池大小，默认值偏小无法承载大量异步请求，建议设置为32或更高。
• async_queue_size：异步请求的最大排队数，默认值可能导致超过14个请求后队列溢出，建议设为1000以上。
• async_inference_timeout：若流水线推理耗时较长，默认超时会导致请求被判定失败，建议延长至300秒（或根据实际推理耗时调整）。

2. 优化流水线Handler逻辑 #

检查自定义处理脚本是否存在资源泄漏或阻塞问题：

• 每轮推理结束后显式调用torch.cuda.empty_cache()，释放临时GPU张量，避免显存持续占用导致后续请求无法分配资源。
• 确保模型初始化（如model.eval()）在Handler的initialize方法中完成，不要放在推理逻辑中重复执行，避免同步阻塞。
• 排查请求流转逻辑，确认每个异步请求能正确在两个模型间传递，无环节积压。

3. 监控GPU资源占用 #

使用nvidia-smi实时查看GPU显存和利用率：

• 若发送超14个请求时显存占满，说明双模型串联后的显存开销超出单GPU承载：
  • 对模型进行FP16量化，降低单模型显存占用。
  • 调整流水线的批量处理参数，避免单请求占用过多显存。

4. 深挖日志中的根本错误 #

"Number of consecutive unsuccessful inference 1"是表层报错，需从日志中查找更早的具体错误：

• 检查是否存在CUDA显存不足、推理超时、模型加载异常等日志信息，这些才是失败的根本原因。
• 开启调试日志：在config.properties中设置log_level=DEBUG，重启服务后重新测试，获取更详细的推理过程日志，定位阻塞或失败环节。

内容的提问来源于stack exchange，提问作者Benny Koren