1. 从一次线上事故说起为什么并发控制是GPU推理服务的生死线去年冬天我帮一个团队收拾过一个烂摊子。他们用 FastAPI 包了一个视觉推理模型部署到一台 24G 显存的卡上接口压测的时候一切正常单请求延迟 80msQPS 跑到 30 都没问题。结果上线第二天运营那边搞了个批量任务前端没做节流几十个请求同时打进来服务直接卡死日志里刷满了CUDA out of memory进程被系统 OOM Killer 干掉整个推理服务雪崩了将近十分钟。这个场景我相信做过 GPU 推理服务的人都遇到过。问题的根子不在于模型太大也不在于卡太差而在于并发控制没做。FastAPI 默认是异步框架请求进来之后如果直接丢给 GPU 去跑多个请求会同时抢占显存和计算单元显存碎片化加上峰值叠加溢出是迟早的事。这篇内容就是围绕这个核心问题展开的怎么在 FastAPI 里给 GPU 推理加上一层靠谱的并发控制让请求量上来的时候服务不崩、显存不炸、延迟可控。我会从整体架构设计讲到具体的信号量、队列、批处理实现再讲到显存监控和故障排查全部是我自己在实际项目里跑过的方案。适合正在做 AI 服务部署的后端工程师、算法工程师也适合刚接触 FastAPI 想把它用到推理场景的开发者。哪怕你之前没写过并发控制跟着思路走也能落地。2. 整体设计思路先搞清楚瓶颈在哪再决定怎么控2.1 GPU 推理的瓶颈到底在哪一层很多人一上来就问“FastAPI 怎么限制并发”但这个问题问得太早了。你得先搞清楚你的推理服务瓶颈在哪是显存、是算力、还是 CPU 预处理。不同瓶颈对应的控制策略完全不一样。我一般把 GPU 推理服务的资源消耗拆成三块来看。第一块是显存占用这部分包括模型权重本身、推理时的中间激活值、以及 CUDA 上下文和缓存。模型权重是固定的比如一个 7B 的模型 FP16 大概占 14G这部分不会随并发变化。真正随并发涨的是中间激活值和 KV Cache尤其是大语言模型每个并发请求都要占一份 KV Cache这才是显存溢出的主因。第二块是算力占用也就是 SM流多处理器的利用率。GPU 的计算单元是有限的多个请求同时跑会互相抢 SM导致每个请求的延迟都变长。这时候你会发现单请求延迟从 80ms 涨到 300ms但吞吐量并没有线性提升因为算力已经饱和了。第三块是显存碎片。这个最隐蔽。频繁地分配和释放显存会导致显存池里出现很多不连续的小块明明总空闲显存还有 5G但就是分配不出一个连续的 2G 块照样 OOM。这个问题在长时间运行的服务里特别常见。提示判断瓶颈的简单方法——用nvidia-smi看显存占用和 GPU 利用率。如果显存快满了但利用率不高瓶颈在显存如果利用率长期 90% 以上瓶颈在算力如果两者都不高但延迟很高瓶颈可能在 CPU 预处理或数据传输。2.2 三种并发控制策略的取舍搞清楚瓶颈之后控制策略就有方向了。我实际用过三种方案各有适用场景。第一种是信号量限流。用asyncio.Semaphore控制同时进入推理的请求数量。比如设成 4就最多 4 个请求同时跑推理第 5 个请求在门口等着。这个方案最简单代码量最少适合显存是主要瓶颈的场景。缺点是等待的请求会占着连接如果并发量特别大连接池会被占满。第二种是请求队列加固定 worker。请求进来先丢进队列后台固定几个 worker 从队列里取任务执行。这个方案的好处是请求和执