continuous batchingとは？LLM推論が2〜3倍速くなる仕組みと導入判断

GPUの請求書を見て、使った時間の割に処理できた量が少ない。そう感じているなら、原因はモデルでもGPUの型番でもなく、リクエストの並べ方かもしれません。

高価なH100を借りて、実際の稼働率が30%台。よくある話です。GPUは「動いている」のに「働いていない」。この空白を埋めるのがcontinuous batching（連続バッチング)です。

continuous batchingとは？GPUの空席をゼロに近づける仕組み

continuous batchingとは、LLM（大規模言語モデル）の推論で、処理の途中でも終わった枠に新しいリクエストを差し込み続けるスケジューリング方式です。

バスで例えるとわかりやすいはず。従来の方式は「定員が埋まるまで待って出発し、全員が降りるまで次の便を出さない」観光バス。continuous batchingは「停留所ごとに降りた分だけ乗せる」路線バスです。

席が空いた瞬間に次の人が乗る。だから座席が遊びません。

技術的にいうと、スケジューリングの判断単位をリクエストから反復（イテレーション）へ下ろしたということ。モデルが1回の順伝播、つまり1トークンぶんの計算を終えるたびに、スケジューラが「誰が終わったか」「誰を新しく入れられるか」を判定し直します。

この設計は2026年時点で、主要な推論エンジンの標準機能になっています。特別なことをしなくても、素のまま使えば有効になっている。むしろ問題は、有効になっているのに効果が出ていないケースのほうです。

その理由は後半で1つずつ潰していきます。

静的バッチングの何が問題なのか？

静的バッチングは、バッチ内の全リクエストが完了するまで枠を解放しません。出力の長さがバラバラなLLMでは、これが致命的な無駄を生みます。

4件のリクエストを1バッチにまとめた場面を考えてください。1件目は20トークンで終わる短い返答、4件目は800トークンの長文生成。

静的バッチングでは、1件目が終わったあとも、その席は800トークン目まで空席のまま確保され続けます。GPUはその空席ぶんも律儀に計算を回します。中身がないのに。

これが「GPU利用率が上がらない」現象の正体です。

つまり、動的バッチングは「集め方」を賢くしただけで、待ち時間の構造そのものは静的バッチングと同じということ。continuous batchingだけが構造を変えています。

出力長のばらつきが大きいほど、この差は開きます。チャットボットのように「はい」から数千文字までが混ざる用途は、まさに最悪ケース。

反復ごとにスケジュールし直すと、中で何が起きるのか

スケジューラは1回の順伝播ごとに起動し、完了したシーケンスを外して待機列から次を入れます。席の入れ替えが常時発生している状態です。

時間軸で並べると差が見えます。4つの実行枠があり、A〜Dが処理中だとします。Dが早く終われば、次の反復ではもうHが座っている。Bが終わればEが入る。

つまり、どの時刻を切り取っても4枠すべてが埋まっている。これが静的バッチングとの決定的な違いです。

新しいリクエストは、前のリクエストの完了を待たずに入り込めます。待機列の滞留時間が短くなるので、平均の応答時間も一緒に改善する。スループットと遅延が同時に良くなる、珍しいタイプの最適化です。

ただし「同時に良くなる」のは、後述する2つの罠を踏まなかった場合に限ります。

どれくらい速くなる？用途によって伸びしろが違う

スループットの改善幅は一律ではありません。遅延の許容度が緩いほど大きく、厳しいほど小さくなります。

用途別の目安を整理します。数字は「1件ずつ順番に処理する場合」との比較です。

つまり、バッチ処理寄りの用途ほど投資対効果が跳ね上がるということ。夜間に大量の文書を要約する、社内データを一括で分類する。こうした処理は3〜5分の1のコストで済む計算になります。

一般的な報告としては、反復単位のスケジューリングによって2〜3倍のスループット向上が得られるとされています。vLLMの公式アカウントが2026年1月に示した例では、H100 1枚でQwen 3 8Bを動かし、非同期スケジューリングとバッチサイズの調整によってGPU利用率100%に到達したケースが紹介されていました。

ここで注意したいのは、100%という数字が「何の指標か」です。GPU利用率は「計算器が動いていた時間の割合」であって、「有効な計算をしていた割合」ではありません。空席のまま回っていても利用率は上がります。

見るべきは1秒あたりの生成トークン数。指標の選び方については後半で詳しく扱います。

prefillとdecodeで、性質がまったく違う

LLMの推論は2つの段階に分かれます。この2つは計算の性質が正反対で、混ぜて扱うと事故ります。

prefill（プリフィル）は、入力されたプロンプト全体を一気に読み込む段階。数千トークンの入力を並列で処理するので、GPUの計算器を目いっぱい使います。計算が律速です。

decode（デコード）は、答えを1トークンずつ吐き出す段階。1回の計算量は小さいのに、モデルの重みを毎回メモリから読み出す必要があります。メモリ帯域が律速です。

ここで何が起きるか。

長いプロンプトのprefillが走っている間、同じバッチで返答を出力中の他のリクエストは、計算器を奪われて足止めを食らいます。ユーザー側からは「文字がスラスラ出ていたのに急に止まった」ように見える。

つまり、continuous batchingを入れただけでは、この段差は解消されないということ。「新規リクエストが入るたびに既存ユーザーの出力が詰まる」のは仕様どおりの挙動です。

対策は次の章。

chunked prefillで「途中で止まる」を防ぐ

chunked prefill（チャンク化プリフィル）は、長いプロンプトの読み込みを細かく分割し、decodeの合間に少しずつ処理する手法です。

1回の反復で「decodeを主、prefillを従」として混ぜる。8,000トークンの入力を一息に処理するのではなく、512トークンずつ16回に分けて、その隙間で他のユーザーの出力を進める。

結果として、最初の1文字が出るまでの時間はわずかに伸びます。代わりに、出力中のユーザーが体験する「詰まり」が消える。

トレードオフの整理です。

• 全体のスループットは、両者を混在させたほうが安定して高くなる
• 個々の最初の1文字までの時間は、chunked prefillのほうがわずかに遅い
• 出力の滑らかさは、chunked prefillが明確に優位

長文入力を扱うRAG（社内資料を読ませて答えさせる仕組み）では、この設定の有無で体感がまるで変わります。検索して見つけた資料を丸ごとプロンプトに詰め込む構成では、入力が数千トークンになるのが普通。そのたびに他のユーザーの画面が固まっていたら、使いものになりません。

検索とAIの組み合わせを実務でどう回すかは、Feloの使い方まとめを読むと、入力が長くなるユースケースの実像がつかめます。

メモリが本当の律速になる理由

同時に何件処理できるかを決めるのは、計算能力ではなくKVキャッシュ用のメモリ容量です。ここを理解しないとチューニングが空回りします。

KVキャッシュとは、生成済みトークンの中間計算結果を保持しておく領域のこと。同じ計算を繰り返さないための貯金箱です。これがリクエストごとに、しかも生成が進むほど膨らんでいきます。

問題は、必要量が事前にわからないこと。返答が20トークンで終わるか2,000トークンまで伸びるかは、生成してみないと確定しません。

昔の実装は「最大長ぶんを先に確保」していました。実際には5%しか使わないのに、100%ぶん押さえる。メモリが足りるはずがない。

これを解決したのがPagedAttention（ページドアテンション）です。OSの仮想メモリと同じ発想で、KVキャッシュを小さな固定サイズのブロックに分けて必要になったぶんだけ割り当てます。

断片化が減れば、同じGPUに座らせられるリクエスト数が増える。同時実行数が増えれば、continuous batchingの効果も伸びる。この2つはセットで効く仕組みです。

ここまでの整理: continuous batchingは「席の入れ替えを速くする」仕組み、PagedAttentionは「席そのものを増やす」仕組み。前者だけ入れてもメモリが詰まっていれば同時実行数は伸びず、効果は頭打ちになります。

主要な推論エンジンをどう選ぶか

自前でモデルを動かす場合、エンジンの選択が実装コストを大きく左右します。既製品をそのまま使うなら難易度は低め。

代表的な選択肢を用途で分けます。

つまり、チューニングの余地を求めるならvLLMかTensorRT-LLM、検証だけならローカル系、運用を丸ごと外したいならAPIという整理になります。

ローカル実行系の2つは、そもそも同時リクエストがほとんど発生しない前提のツール。どちらを選ぶべきかはLM StudioとOllamaの比較で用途別に分かれます。

実装の複雑さは、既製エンジンを素のまま使うなら低い。最大バッチサイズ、最大系列長、メモリ配分といった項目を詰め始めると中程度、というのが実感に近い評価です。

モデル管理まで含めた開発基盤の選び方は、Hugging FaceとWeights & Biasesの比較やVertex AIとWeights & Biasesの比較が参考になります。

自前GPUとAPI、どちらを選ぶべき？

判断基準は1つだけ。GPUを常時どれだけ埋められるかです。

continuous batchingは「同時にリクエストがある」ことで初めて効きます。逆にいうと、1日のうち数時間しか使わないGPUを借りても、空席を埋める相手がいません。24時間ぶんの料金を払って、数時間ぶんの仕事しかしない。

自前運用が正当化されるのは、次の条件が揃ったときです。

• 同時リクエストが常時2件以上ある
• モデルを固定でき、頻繁に切り替えない
• データを外に出せない、あるいは出したくない
• 月間の推論量が読めていて、変動が小さい

1つでも欠けるなら、GroqやTogether AIのような推論特化のAPIを使ったほうが、総額は確実に安く収まります。この2社の違いはGroqとTogether AIの比較にまとめました。

サーバーレスGPUという中間解もあります。Modalのように使った時間だけ課金される形式なら、負荷の波が大きいサービスでも無駄が出にくい。ただし起動の待ち時間が発生するので、常時アクセスがある用途には向きません。

推論基盤の選定は、月々のGPU支出という形で経営に直結します。AI関連のコストがどこで膨らんでいるかを定期的に洗う仕組みは、社内監査向けAIツールの整理の考え方がそのまま流用できます。

エンジニア向けのモデル運用の全体像は、LLMカテゴリとインフラカテゴリに関連ツールをまとめています。

調整すべき設定はどこにあるのか

デフォルト設定は「無難だが最適ではない」値になっています。トラフィックの形に合わせて動かすべき項目は限られます。

主要な設定項目と、動かしたときの副作用を並べます。

つまり、すべての項目が「スループットと個別の遅延」のシーソーになっているということ。片方を取れば片方が落ちる。

現実的な進め方は、小さい値から始めて上げていくこと。最大同時シーケンス数を段階的に増やし、1トークンあたりの生成時間が許容ラインを超えた1つ手前で止める。これがいちばん外しません。

いきなり大きな値を入れると、メモリ不足でプロセスが落ちるか、KVキャッシュの追い出しが多発して逆に遅くなります。後者は数字だけ見ても原因がわからないので厄介。

設定を触る前に、現状の数字を取っておくこと。比較対象がないチューニングは、当てずっぽうと変わりません。

導入前後で測るべき指標と、つまずきやすい4点

平均値だけを見た改善報告は、ほぼ確実に読者を裏切ります。見るべきは分布の裾です。

最低限そろえたい指標を挙げます。

つまり、スループットが2倍になってもp99のTTFTが3倍になっていたら、それは改悪だということ。1つの数字で語らないのが鉄則です。

よくつまずくのが次の4つ。

• 平均だけ見てp99を見ない — 一部のユーザーだけが極端に待たされる状態を見逃す
• 同時実行数を上げすぎる — メモリ不足で落ちるか、キャッシュの追い出しで遅くなる
• 長文プロンプトの混在を想定していない — 検証時は短文ばかりで、本番で初めて詰まる
• 本番と違う形のトラフィックで測る — 均一な長さのリクエストで測ったベンチマークは、実運用の役に立たない

4つ目が一番多い失敗です。検証用のスクリプトは、たいてい同じ長さのプロンプトを同じ間隔で投げます。現実のトラフィックは長さも到着間隔もバラバラ。continuous batchingの効果はこのバラつきがあってこそ出るので、揃ったデータで測ると本来の伸びも見えません。

処理の並列化という発想自体は、テキスト生成に限りません。画像生成でも同じ理屈でGPUの空きを埋めます。ワークフロー構築の考え方はComfyUIとStable Diffusionの比較に近く、生成系ツールの選び方はイラスト生成ツールの比較や画像生成カテゴリにまとめています。

大規模に配信する側の設計思想を知りたいなら、Meta AIの解説で、億単位のユーザーを抱えるサービスがどう推論を捌いているかの輪郭がつかめます。

関連する比較・代替を見る

推論基盤まわりの選定で、迷いやすい組み合わせを挙げます。

• GroqとTogether AIの比較 — 推論特化APIの二択。速度重視かモデルの幅重視か
• LM StudioとOllamaの比較 — ローカル実行の定番2つ。GUIかCLIかで分かれます
• Hugging FaceとWeights & Biasesの比較 — モデル配布と実験管理、役割の違い
• Vertex AIとWeights & Biasesの比較 — マネージド基盤と可視化ツールの住み分け
• Difyとn8nの比較 — 推論の上に載せるアプリ層の選択
• Groqの代替を探す — 低遅延推論の他の選択肢
• Ollamaの代替を探す — ローカル実行の乗り換え先

エンジニア向けの開発ツールはコーディング支援カテゴリ、Cursorとの比較もあわせてどうぞ。

AI PICKS編集部の判定

同時リクエストが常時発生する環境なら、continuous batchingは一択です。導入コストが実質ゼロなのに、スループットが2〜3倍。ここまで費用対効果が明確な最適化は他に見当たりません。主要な推論エンジンでは既定で有効なので、「入れるかどうか」を検討する段階はもう終わっています。

一方で、期待しすぎている人も多い印象。厳しい低遅延要件があるサービスでは1.2〜1.5倍が上限で、そこから先はハードウェアかモデルを変えるしかありません。1人でローカルLLMを回しているだけなら、正直イマイチどころか効果ゼロです。

現実の作業として重いのは、仕組みの導入ではなく計測です。本番と同じ形のトラフィックを再現し、p99まで含めて数字を取る。ここを飛ばしたチューニングは、平均値だけ良くなって一部ユーザーの体験を壊す結果になりがち。

判断は単純です。GPUを常時埋められるなら自前運用で効果を取りにいく。埋められないなら推論APIに預けたほうが安い。GPUの稼働率という数字ひとつで、答えは出ます。

よくある質問（FAQ）

Q. continuous batchingと動的バッチングは何が違いますか？

スケジュールの判断単位が違います。動的バッチングは一定時間リクエストを集めてから一括で流す方式で、バッチが完了するまで枠は解放されません。continuous batchingは1トークン生成するたびに判定し、終わった枠へ即座に次を入れます。待ち時間の構造そのものが別物です。

Q. 自分で実装する必要はありますか？

ありません。主要な推論エンジンには標準で組み込まれており、素のまま起動すれば有効になっています。自作するのは、独自のスケジューリング要件がある場合だけ。まず既製エンジンで数字を取ってから考えるべきです。

Q. 遅延は悪化しませんか？

設定次第です。同時実行数を欲張ると、1件あたりの生成速度が落ちてp99が跳ねます。逆に控えめな設定なら、待機列の滞留が短くなるぶん平均の応答時間はむしろ改善します。上げすぎない、が答え。

Q. ローカルでLLMを動かしている場合も効果がありますか？

ほぼありません。効果は同時リクエストがあって初めて出るもので、1人が1件ずつ投げる使い方では埋める空席が存在しないからです。ローカル環境の高速化は、量子化やGPUの増強といった別の手を検討してください。

Q. GPU利用率が100%なら最適化は完了ですか？

いいえ。GPU利用率は「計算器が動いていた時間の割合」であって、有効な計算をしていた割合ではありません。空席のまま回っていても数値は上がります。判断は1秒あたりの生成トークン数で行ってください。

Q. どのくらいのトラフィックから導入を検討すべきですか？

同時リクエストが常時2件以上ある状態が最低ライン。それ以下なら、GPUを借りる固定費のほうが重くのしかかります。月間の推論量が読めないうちは、従量課金の推論APIから始めるのが安全です。

Q. 長いプロンプトを扱うサービスで注意点はありますか？

chunked prefillの設定を確認してください。数千トークンの入力を一括処理すると、その間だけ他のユーザーの出力が止まります。社内資料を読ませる構成では入力が長くなりがちなので、分割処理を有効にしておくと体感が安定します。

Q. 効果が出ているかを判断する最短の方法は？

導入前後で、本番と同じ長さのばらつきを持つリクエストを流し、1秒あたりの生成トークン数とp99のTTFTを並べて比較すること。片方だけを見た比較は、ほぼ確実に判断を誤ります。

推論の速度改善に手を付けたなら、その上で動くアプリ層の設計も見直しどきです。次に読むならDifyとn8nの比較。せっかく速くした推論を、どう業務フローに載せるかの具体案が見つかります。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• Groq — 公式サイト（AI PICKSの詳細）
• Together AI — 公式サイト（AI PICKSの詳細）
• Modal — 公式サイト（AI PICKSの詳細）
• Gemini Enterprise Agent Platform（旧Vertex AI） — 公式サイト（AI PICKSの詳細）
• Ollama — 公式サイト（AI PICKSの詳細）