异步连续批处理解锁GPU满载，推理吞吐提升22%

背景

在大模型推理场景中，连续批处理（continuous batching）已经成为提升 GPU 利用率的主流手段。它通过紧凑地组织请求，避免因 padding 带来的算力浪费。然而，传统实现仍采用同步调度：CPU 完成批次准备后才将数据送入 GPU，GPU 计算结束后再返回 CPU，二者交替空转，导致 GPU 空闲时间约占总运行时间的四分之一。

同步批处理的瓶颈

CPU‑GPU 交替等待：CPU 在准备输入、采样、状态更新时 GPU 处于空闲；GPU 在前向计算时 CPU 只能等待。
时间统计：在 8K token、batch‑size 32、8B 模型的实验中，总耗时 300.6 s，其中 24.0% 为 GPU 空闲。
潜在提升：若完全消除 CPU 阻塞，理论上可将耗时压至约 228 s，提升约 24%。

异步批处理实现

1. 引入 CUDA 流

使用三个非默认流分别负责 H2D 传输、计算、D2H 传输，避免默认流的全局同步特性。

2. 通过 CUDA 事件控制依赖

在 H2D 流记录 h2d_done 事件；计算流在此事件完成前保持等待。
计算完成后记录 compute_done，D2H 流在该事件完成后才启动输出拷贝。
CPU 只在最末的 d2h_done 事件上同步一次，随后即可开始下一批次准备。

3. 双缓冲防止数据竞争

为输入/输出分别准备两套张量（Slot A、Slot B），CPU 在准备 Batch N+1 时使用另一套缓冲区，避免 H2D 与在算的 H2D 产生写冲突。

4. Carry‑over 机制

当同一请求跨批出现时，用占位 token（0）构建 Batch N+1 的输入，在 Batch N 计算完成后通过简短的张量加法将真实 token 写入，占用的计算成本可忽略。

性能评估

在相同实验条件下，异步实现的关键指标如下：

GPU 活跃比例 99.4%（原 76.0%）
总生成时间 234.5 s，比同步方案快 22%
CPU 与 GPU 大部分时间并行执行，只有极少数同步点仍需阻塞。

"不需要改动模型或新增 kernel，单靠调度即可实现显著加速。"——Hugging Face 团队

结论与展望

通过 CUDA 流‑事件的细粒度调度，连续批处理从同步模式转为异步模式，实现了几乎满载的 GPU 利用率，并在实际推理任务中获得两位数的吞吐提升。该方案已合并至 transformers 库的 continuous_batching.py 与 ContinuousBatchingAsyncIOs 类，用户可直接复用。未来工作将聚焦于请求分片、解码专用 kernel 以及更细致的编译优化，以进一步突破 16K+ 长文本生成的性能瓶颈。

本文基于 Hugging Face 官方博客，内容为技术实现的客观概述。