071、图像处理微服务响应慢？GPU 共享池、模型预加载与请求动态调度方案

071、图像处理微服务响应慢？GPU 共享池、模型预加载与请求动态调度方案

一、从一次线上事故说起

凌晨两点，告警电话响了。监控显示某图像增强服务的P99延迟从80ms飙升到2.3秒，用户上传的图片在队列里排队超过10秒才出结果。我登录上去一看，GPU利用率只有30%，但每个请求都在等——等模型加载，等显存分配，等别的请求释放资源。

这种“GPU闲着，请求却堵着”的诡异现象，在图像处理微服务里太常见了。问题根源往往不是模型推理慢，而是资源调度和模型生命周期管理出了问题。今天这篇笔记，就聊聊我们怎么用GPU共享池、模型预加载和动态调度，把P99延迟压回150ms以内。

二、GPU共享池：别让显存碎片化杀死并发

2.1 踩过的坑：每个请求独占一个CUDA context

早期架构很粗暴：每个请求进来，torch.cuda.set_device()，加载模型，推理，释放。结果呢？显存碎片化严重，频繁创建销毁CUDA context导致延迟抖动。更坑的是，不同模型对显存需求不同，有的模型吃4GB，有的吃1.5GB，分配策略不对，GPU利用率直接崩盘。

别这样写：

# 每个请求都自己搞一套，别学我