并发推理的四大挑战：显存竞争、锁冲突、CPU-GPU同步开销、请求排队延迟
好，咱们直接切入正题。并发推理，说白了就是让GPU同时处理多个推理请求。听起来很美好对吧？但实际一跑，你会发现各种坑。我最早做多路并发时，以为把batch size调大就完事了，结果显存直接爆掉，服务挂了半小时。嗯，今天就把这些坑一个个说清楚。
1. 显存竞争：谁抢到了谁用
显存是GPU上最宝贵的资源。多个推理请求同时进来，每个都要占一块显存。如果管理不好，就会出现「你抢我的，我抢你的」的混乱局面。
核心问题：显存分配和释放的时机不可控，导致碎片化和超额分配。
我在项目中遇到过这样一个场景：8个并发请求，每个需要2GB显存，但GPU总共只有16GB。按理说刚好够，但实际跑起来却OOM了。为什么？因为显存释放有延迟，上一个请求还没释放完，下一个已经分配了。
解决方案其实就两个方向：
- 预分配池化：启动时就分配好固定大小的显存块，请求来了直接复用
- 动态调度：根据当前显存使用量，动态调整并发数
我的习惯：一般用预分配池化，虽然浪费一点显存，但胜在稳定。动态调度适合显存波动大的场景。
2. 锁冲突：多线程的噩梦
显存池本身需要加锁保护。多个线程同时申请显存，锁就成了瓶颈。你想想看，一个线程在分配显存，其他所有线程都得等着。这跟单线程有什么区别？
我曾经调试过一个服务，并发数从4提升到8，吞吐量反而下降了。查了半天，发现是显存池的锁竞争太激烈。每个请求都要申请两次显存（输入和输出），锁的等待时间比计算时间还长。
常见的优化手段：
- 分段锁：把显存池分成多个区域，每个区域有自己的锁
- 无锁队列：用CAS操作替代互斥锁，适合小对象分配
- 线程本地缓存：每个线程预分配一小块显存，减少全局锁的访问
注意：无锁编程虽然性能好，但调试难度极大。我建议先从分段锁入手，简单有效。
3. CPU-GPU同步开销：看不见的杀手
很多人只关注GPU计算时间，忽略了CPU和GPU之间的同步开销。每次cudaMemcpy或者cudaLaunchKernel，背后都有一堆同步操作。
举个例子：
// 糟糕的做法：频繁同步
cudaMemcpy(d_input, h_input, size, cudaMemcpyHostToDevice);
cudaStreamSynchronize(stream); // 等待拷贝完成
kernel<<<grid, block, 0, stream>>>(d_input, d_output);
cudaStreamSynchronize(stream); // 等待计算完成
cudaMemcpy(h_output, d_output, size, cudaMemcpyDeviceToHost);
cudaStreamSynchronize(stream); // 等待拷贝完成这段代码里，三次同步操作，每次都要等GPU干完活。如果并发请求多，这些等待时间会叠加，造成严重的排队延迟。
我建议的做法是：
- 使用多个CUDA流，让拷贝和计算重叠
- 用cudaEvent做异步通知，而不是同步等待
- 尽量用pinned memory，减少拷贝开销
关键点：CPU-GPU同步的开销，往往比GPU计算本身还大。优化同步策略，比优化kernel更有效。
4. 请求排队延迟：谁先谁后
并发推理必然涉及排队。请求来了，是先进先出？还是优先级调度？排队策略直接影响响应时间。
我记得有一次线上告警，某个用户的请求延迟从10ms飙到了500ms。查日志发现，是因为一个大模型请求占用了GPU，后面所有小请求都在排队。这就是典型的「长尾效应」。
常见的排队策略：
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| FIFO | 公平，实现简单 | 长请求阻塞短请求 | 请求大小均匀 |
| 优先级队列 | 保证高优请求 | 低优请求可能饿死 | 有SLA要求 |
| 多级反馈队列 | 兼顾公平和优先级 | 实现复杂 | 请求大小差异大 |
| 时间片轮转 | 避免长请求独占 | 上下文切换开销 | 实时性要求高 |
我的经验：如果请求大小差异很大，用多级反馈队列。如果请求大小差不多，FIFO就够用了。别过度设计。
核心逻辑框架图
这四个挑战不是孤立的。显存竞争会导致锁冲突加剧，锁冲突又会让CPU-GPU同步更频繁，最终反映在请求排队延迟上。我建议你从显存池入手，先把资源管理好，再逐步优化其他环节。
一句话总结：并发推理的优化，本质上是资源调度和同步策略的平衡。没有银弹，只有针对场景的取舍。
想要更多资料，联系可可