LLM推論の余白は、モデルの外側に残っている

GPUを増やす前に、まだ詰められる待ち時間があるのではないでしょうか。

Hugging Face の記事 Unlocking asynchronicity in continuous batching は、LLM 推論における continuous batching の次の改善点を扱っています。
要点は、バッチを詰めるだけでは不十分で、CPU のバッチ準備と GPU の計算が交互に待つ同期構造が残ることです。
記事では、CUDA streams と CUDA events を使って CPU と GPU の仕事を重ね、GPU 稼働率を 76.0% から 99.4% へ、生成時間を 300.6 秒から 234.5 秒へ短縮したと説明しています。

この話の面白さは、性能改善の主役が新しいモデルでも、新しいカーネルでもない点にあります。改善対象は、計算そのものではなく、計算に入る前後の段取りです。

同期的な continuous batching では、CPU が次のバッチを準備している間、GPU は待ちます。GPU が forward pass を実行している間、CPU も待ちます。1回ごとの待ちは小さく見えても、トークン生成のループではそれが何百、何千回も積み上がります。高価な GPU を使っているほど、この「何もしていない時間」はそのままコストになります。

非同期化は、この待ち時間を消すための設計変更です。CPU はバッチ N を GPU に投げたあと、GPU の完了をただ待つのではなく、次のバッチ N+1 の準備を始めます。一方で GPU 側では、H2D 転送、compute、D2H 転送を別々の stream に分け、event で順序だけを保証します。つまり、全体を直列の手順として見るのではなく、依存関係のある作業グラフとして扱うわけです。

これは推論基盤を作る側にとって、かなり実用的な示唆があります。LLM の高速化というと、量子化、speculative decoding、専用カーネル、より強いアクセラレータに目が向きがちです。しかし実運用では、モデルの外側にあるスケジューリング、メモリ転送、状態更新の設計も、同じくらい効いてきます。

特に continuous batching を採用している環境では、「バッチが埋まっているか」だけでなく、「CPU と GPU が同時に仕事をしているか」を見る必要があります。GPU 使用率が高く見えても、ステップ間に細かい空白が残っていれば、長い生成や高並列のワークロードでは大きな差になります。

もちろん非同期化は無料ではありません。バッファの二重化、race condition の回避、carry-over の処理、CUDA graph のメモリ管理など、実装は複雑になります。それでも、記事が示す 22% の短縮は、既存モデルを変えずに得られる改善としては大きいものです。

判断軸は明確です。推論量が小さい段階では、この複雑さは過剰かもしれません。しかし GPU コストが支配的になり、長文生成や RL 向けの 16K+ 生成が増えるなら、非同期 continuous batching は「最適化の細部」ではなく、基盤設計の選択肢になります。LLM 推論の伸びしろは、モデルの中だけでなく、CPU と GPU の間の待ち時間にも残っています。

関連記事

参考文献

Unlocking asynchronicity in continuous batching