直接用Flask/FastAPI处理高并发模型请求会卡死，因Python GIL和同步框架限制导致显存与线程耗尽；单次推理>200ms且QPS>2时必须异步解耦，Celery+Redis需规范配置模型加载、缓存TTL及状态查询链路。
为什么直接用 Flask/FastAPI 处理高并发模型请求会卡死
因为 Python 的 GIL 和同步 Web 框架默认每个请求都占一个工作线程/协程，模型推理（尤其是 PyTorch/TensorFlow）常需数百 MB 显存 + 秒级计算，一旦并发超 3–5 路，就会出现 ConnectionTimeout、503 Service Unavailable 或 Redis 连接池耗尽——这不是代码写得不好，是同步阻塞模型天然扛不住。
关键判断：只要模型单次推理 > 200ms，且预估 QPS > 2，就必须异步解耦，不能靠加 gunicorn worker 数硬扛。
Celery + Redis 最小可行配置避坑点
Celery 不是“加个装饰器就异步”，Redis 也不是配个 URL 就能缓存。常见错误包括：
-
broker_url写成redis://localhost:6379/0却没开 Redis 服务，报错ConnectionRefusedError: [Errno 111] Connection refused - 用
task.ignore_result = True却忘了前端要轮询状态，结果用户提交后页面一直转圈 - 在 Celery task 里直接 import 模型（如
torch.load("model.pth")），导致每个 task 启动都重新加载，OOM 或显存泄漏 - Redis 默认 maxmemory 为 0（不限制），模型输出缓存不设 TTL，几天后 Redis 内存爆满，
OOM command not allowed when used memory > 'maxmemory'
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把模型加载提到 Celery worker 启动时（放在
celery.py的on_worker_ready钩子里），而非每次@app.task里 - 用
result_backend = "redis://localhost:6379/1"和 broker 分开 DB，避免任务元数据和业务缓存互相挤占 - 所有缓存 key 必须带前缀和 TTL，例如
redis_client.setex(f"pred:{task_id}", 3600, json.dumps(result))
如何让 FastAPI 请求快速返回 task_id 并支持状态查询
用户不需要等模型跑完才看到响应，但需要明确知道“有没有被接收”“现在什么状态”“结果在哪”。这不是加个 background_tasks 就能解决的——它只适合毫秒级清理，不提供状态追踪。
正确链路是：FastAPI 接收请求 → 触发 Celery task → 立即返回 {"task_id": "xxx"} → 前端用该 ID 轮询 /task/{task_id} 接口查状态。
示例关键片段：
@app.post("/predict")
def predict(payload: PredictRequest):
task = predict_task.delay(payload.image_b64) # 注意：.delay() 才进队列
return {"task_id": task.id}
<p>@app.get("/task/{task_id}")
def get_task_status(task_id: str):
task = predict_task.AsyncResult(task_id)
if task.state == "PENDING":
return {"status": "pending", "message": "queued"}
elif task.state == "SUCCESS":</p><h1>从 Redis 取结果，不是 task.result（可能已被序列化丢弃）</h1><pre class='brush:python;toolbar:false;'> result = redis_client.get(f"pred:{task_id}")
return {"status": "success", "result": json.loads(result)}
else:
return {"status": task.state, "error": str(task.info)}注意：task.result 是 Celery 自己序列化的返回值，若 task 返回大对象（如 base64 图片），容易撑爆 Redis 的 result backend；更稳做法是 task 只存 key，结果由你手动写入 Redis 并控制生命周期。
模型输出缓存该缓什么、不该缓什么
缓存不是越多越好。实测发现以下缓存策略最有效：
- 缓输入指纹：对图像做
hashlib.sha256(image_bytes).hexdigest()，缓存 key 用f"cache:{sha256}"，相同图秒回，省 GPU - 缓中间特征（如 CLIP embedding）比缓最终分类结果更有扩展性，后续加新分类器不用重算
- 绝不缓原始 tensor 或
.pt文件——序列化开销大、版本难兼容；统一转成numpy.ndarray.tolist()或 base64 字符串 - 对实时性要求高的场景（如风控），缓存 TTL 设为 60 秒；对离线分析类（如报表生成），可设 24 小时，但必须配
redis_client.scan(match="cache:*")定期清理过期键
最容易被忽略的是缓存穿透：恶意请求大量不存在的 task_id 或图片 hash，导致后端反复查模型。加一层布隆过滤器（pybloom_live）或用 Redis 的 EXISTS + SETNX 组合做轻量级存在性校验，比直接打到模型层成本低两个数量级。
