Continuous Batching とは何ですか？

リクエストを固定サイズのバッチで束ねて全リクエストの終了を待つ「静的バッチ」に対して、トークン生成の各イテレーションで完了したリクエストを離脱させ、待機列から新しいリクエストを即座に合流させる方式です。Iteration-level scheduling とも呼ばれ、単一リクエストのレイテンシを大きく損なわずに GPU の稼働率を維持できます。リクエスト到着がバースト的になる実運用ほど効きます。

PagedAttention とは何ですか？

KV キャッシュを固定サイズのページ（ブロック）に分割して管理する仕組みで、OS の仮想メモリの paging を GPU 上の KV キャッシュに適用したものです。従来の実装ではリクエストごとに最大コンテキスト分の KV キャッシュを事前確保する必要があり、実際に使う量が少なくても VRAM が予約されて断片化が進みました。PagedAttention は必要になったときに必要なページだけを非連続な GPU メモリブロックに割り当てるため、KV キャッシュの利用効率が高まり、同時接続数を増やしても VRAM 断片化でスループットが崩れません。vLLM 論文（Fan Yin et al. 2023 SOSP）が発祥です。

Continuous Batching と PagedAttention はどのランタイムで使えますか？

vLLM は初期からこの 2 つを主軸に設計されており、両方に対応しています。SGLang は PagedAttention 相当のページ管理に加えて RadixAttention（プレフィックス共有）を上乗せしています。TensorRT-LLM は同種の in-flight batching と NVIDIA 特化の最適化を持ちます。Hugging Face TGI も continuous batching を実装しています。個人利用向けの Ollama や llama.cpp は既定では 1 並列運用のため、これらの技術の恩恵は限定的です。

Ollama / llama.cpp で本格サービングに移す必要はありますか？

自分一人がチャット用途で使うだけなら Ollama / LM Studio で十分です。Continuous Batching と PagedAttention が効くのは、同時接続数が増えたときに GPU の稼働率を維持しつつ VRAM 断片化を避けるためで、単一リクエストのレイテンシに大きな差は出ません。社内で複数人が同時に叩く・エージェントが並列にツール呼び出しを走らせる・夜間バッチで数千件のプロンプトを一気に回すといった段階になって初めて vLLM / SGLang / TensorRT-LLM への移行価値が立ちます。

KV キャッシュの断片化とは何が問題ですか？

従来の実装では 1 リクエストごとに最大コンテキスト長ぶんの KV キャッシュを事前確保していたため、実際に短いプロンプトで済むリクエストでも VRAM が予約され、他のリクエストが入れなくなる状況が起きました。長いリクエストと短いリクエストが混在するとメモリ利用率が落ち、公開資料では利用効率が 20〜40% 程度に留まるケースが示されています。PagedAttention はページ単位で必要な分だけ確保するため、公開ベンチではメモリロスが 4% 未満まで抑えられ、同一 VRAM でより多くの同時接続を捌けるようになります。

Continuous Batching / PagedAttention とは 2026年版：vLLM がローカルLLMサービングを速くする仕組みを KV キャッシュから理解する

Continuous Batching / PagedAttention とは 2026：vLLM がローカルLLMサービングを速くする仕組みを KV キャッシュから理解する

結論：Continuous Batching は「バッチが揃うまで待たない」スケジューリング、PagedAttention は「KV キャッシュをページ単位で必要になった分だけ確保する」メモリ管理です。この 2 つが vLLM / SGLang / TensorRT-LLM を Ollama から一歩進めた本格サービングエンジンに押し上げている中核技術で、公開ベンチでは KV キャッシュのメモリロスを 4% 未満まで抑え、同時接続数が増えても VRAM 断片化でスループットが崩れなくなります。単一ユーザーのチャット用途では差は出にくく、社内 API・並列エージェント・RAG バッチのように「同時に何本のリクエストを捌けるか」が問われる場面で効きます。

vLLM や SGLang の紹介記事を読むと「Continuous Batching で 2 倍速い」「PagedAttention で KV キャッシュが効率化」という言葉が並びますが、静的バッチと何がどう違うのか、なぜ Ollama では感じない差が本格サービングだと出るのかは、仕組みまで踏み込まないと腹落ちしません。

この記事は、ローカルLLM をチャット用途から一歩広げて「複数人・並列エージェント・バッチ推論」に載せようとしている人に向けて、Continuous Batching と PagedAttention の仕組みを KV キャッシュの挙動から順に整理します。エンジンそのものの比較は「ローカルLLM 本格サービング推論エンジン比較 2026年版」に、KV キャッシュがそもそも VRAM をどれくらい食うかは「ローカル LLM のコンテキスト長と VRAM・KV キャッシュ 2026年版」にまとまっているので、隣接トピックとして参照してください。

前提：LLM 推論は「prefill」と「decode」に分かれる

Continuous Batching と PagedAttention の話に入る前に、LLM 推論の基本構造を揃えます。1 回のリクエストは大きく 2 段階に分かれます。

prefill：入力プロンプト（例：システムプロンプト＋ユーザー質問）を一括で処理し、各層の中間表現から KV キャッシュを構築する段階。並列度が高く、GPU の計算資源をフルに使えます
decode：1 トークンずつ逐次生成する段階。1 トークンごとにモデル全重みと KV キャッシュを読み、次のトークンを計算します。逐次的でメモリ帯域律速です

このうち decode が生成速度（tok/sec）を支配する主戦場で、GPU 上のメモリ帯域が天井になります。仕組みの詳細は「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版」で扱っています。

decode の逐次性と KV キャッシュの存在が、この記事の話の起点です。

静的バッチの何が問題だったのか

かつての LLM 推論サーバーは、リクエストを固定サイズのバッチにまとめて処理する「静的バッチ」が主流でした。イメージとしてはこうです。

リクエスト A, B, C, D の 4 本を受け取る
バッチとして GPU に流し込む
全リクエストの生成が終わるまで次のバッチを開始しない
全部終わったら E, F, G, H の次のバッチへ

この方式には大きな問題が 2 つあります。

問題 1：短いリクエストが長いリクエストに引きずられる。リクエスト A が 20 トークンで終わり、リクエスト D が 500 トークン生成する場合、A は 20 トークン生成した時点で待機状態になり、D の完了までバッチ全体が終わりません。GPU の使用率も落ちます。

問題 2：KV キャッシュを最大コンテキスト分だけ事前確保する必要がある。バッチ内のどのリクエストがどれだけ長く生成するかは事前に分からないため、実装は最大コンテキスト長ぶんの KV キャッシュを各リクエストに割り当てておく必要があります。例えば 128k コンテキスト対応モデルなら、実際は 2k トークンしか使わないリクエストにも 128k 分の VRAM 領域が予約され、他のリクエストが入れなくなります。

公開資料では、静的バッチ実装の KV キャッシュ利用効率が 20〜40% 程度に留まるケースが示されており、残りは断片化した空きスペースとして無駄になっていました。VRAM が高価な GPU 環境で、これは重い制約です。

Continuous Batching：バッチが揃うまで待たない

Continuous Batching は 2022 年の Orca 論文で提示された Iteration-level scheduling が起点で、vLLM が実装で広めました。発想はこうです。

スケジューリング単位を「1 バッチ＝1 セット」から「1 イテレーション（1 トークン生成）」へ切り替える
各イテレーションの終わりに、生成が終わったリクエストを離脱させる
空いた枠に、待機列の新規リクエストを即座に合流させる

つまり「バッチ全体が終わるのを待たず、GPU の枠が空いたらすぐ次を入れる」方式です。イメージ図を書くとこうなります。

イテレーション	GPU 上のリクエスト
1	A, B, C, D
2	A, B, C, D
…	…
20	A, B, C, D（A は 20 トークンで完了）
21	B, C, D, E ← 新規合流
22	B, C, D, E
…	…
50	B, D, E, F, G ← C も完了、2 本合流

得られる効果：

GPU の稼働率が高く保たれる（枠が空きっぱなしにならない）
短いリクエストが長いリクエストを待つ必要がない（レイテンシ改善）
リクエスト到着がバースト的でも捌ける（待機列に貯めて隙間に差し込む）

vLLM は最初からこの Iteration-level scheduling を主軸に設計されており、SGLang / TensorRT-LLM / TGI も同種のスケジューラを実装しています。TensorRT-LLM ではこれを In-flight batching と呼びますが、実質同じ考え方です。

PagedAttention：KV キャッシュをページ単位で管理する

Continuous Batching は「スケジューリング」の話でしたが、それだけでは KV キャッシュの断片化問題は解けません。動的にリクエストが出入りする以上、KV キャッシュも動的に確保・解放できる必要があります。

ここで vLLM が持ち込んだのが PagedAttention です。発想は OS の仮想メモリで使われる paging と全く同じで、Fan Yin ら（vLLM 論文、2023 SOSP）が LLM 推論に適用しました。

KV キャッシュを固定サイズの「ページ」（block）に分割する（例：16 トークン分／ページ）
リクエストが必要になったときに、必要なページだけを非連続な GPU メモリブロックから割り当てる
論理アドレス（リクエスト内のトークン位置）から物理アドレス（GPU メモリ上のページ）へのマッピングテーブルを持つ

従来の「事前に最大分を確保」から、「必要になった分だけ、空いているブロックに順次確保」に変わります。

得られる効果：

KV キャッシュ利用効率が 96% 超：vLLM 論文では PagedAttention による KV キャッシュのメモリロスが 4% 未満まで抑えられたと報告されています
同時接続数が増やせる：同じ VRAM でより多くのリクエストを捌けるため、スループットが伸びる
KV キャッシュの共有：異なるリクエストが同じプレフィックス（共通のシステムプロンプトなど）を持つ場合、そのページを共有できる

vLLM 公表の当初ベンチでは、PagedAttention と Continuous Batching の組み合わせで Hugging Face Transformers 比 24 倍のスループット を出したという数値もあります。これは初期比較なので現在の TGI との差はもっと小さくなっていますが、それでも本格サービングエンジンとそうでない実装の間には大きな溝があります。

静的バッチ / Continuous Batching / In-flight Batching の 3 列比較

主要 3 方式を並べて整理します。

方式	スケジューリング単位	KV キャッシュ管理	代表実装	主な用途
静的バッチ	バッチ全体	最大コンテキスト分を事前確保	旧世代の推論サーバー、Hugging Face Transformers	実験・単発推論
Continuous Batching	イテレーション（1 トークン）	PagedAttention（vLLM）／同等のページ管理（SGLang）	vLLM、SGLang	本格 API サーバー、マルチテナント
In-flight Batching	イテレーション（1 トークン）	ページ管理＋ NVIDIA 特化最適化	TensorRT-LLM	NVIDIA GPU で最大スループット

Continuous Batching と In-flight Batching は基本設計が同じで、TensorRT-LLM の呼称の違いにすぎません。「静的バッチ vs Iteration-level scheduling」が本質的な分岐点です。

SGLang の RadixAttention：PagedAttention の拡張

PagedAttention はページ単位の管理でしたが、同じプレフィックスを持つ複数リクエストで KV キャッシュを共有する ところまでは踏み込んでいません。SGLang はこの一歩先に踏み込みました。

KV キャッシュを Radix 木構造で LRU 保持する（RadixAttention）
新規リクエストのプレフィックスが過去リクエストと重なる場合、そのページを再利用して prefill をスキップ
RAG のように「検索結果＋長いシステムプロンプト＋短いユーザー質問」が並ぶワークロードで大きく効く

公開ベンチでは、プレフィックス支配的なワークロードで vLLM 比 最大 6.4 倍 のスループット向上、一般的なワークロード（H100 80GB、LLaMA 3 70B AWQ、同時 16 接続）でも vLLM 12,500 tok/s に対し SGLang 16,200 tok/s（+29%）という数値が報告されています。

PagedAttention が「1 リクエスト内で KV キャッシュを効率化」する仕組みだったのに対し、RadixAttention は「リクエスト間で KV キャッシュを共有する」拡張、と整理すると理解しやすいはずです。

KV キャッシュ量子化との交差点

PagedAttention は KV キャッシュの「配置」の話でしたが、KV キャッシュそのものの「サイズ」を減らすアプローチも並行して進んでいます。FP16 の KV キャッシュを FP8 や INT4 に量子化すれば、同じ VRAM でより長いコンテキスト・より多くの同時接続を捌けます。

vLLM v0.6 以降で FP8 KV キャッシュに対応
SGLang も FP8 / INT4 KV キャッシュ量子化を実装
TensorRT-LLM は NVIDIA の FP8 / FP4 に踏み込んで最も最深

Continuous Batching + PagedAttention（配置の効率化）と KV キャッシュ量子化（サイズの圧縮）は独立に効くため、両方組み合わせることで実効スループットが跳ねます。量子化フォーマットの選び方は「LLM 量子化フォーマット別解説 2026年版」で扱っています。

個人利用と本格サービングの分岐点

個人利用のツールと本格サービングエンジンの差は、ここまで見てきた通り「同時接続数」で表面化します。

ユースケース	Ollama / LM Studio	vLLM / SGLang / TensorRT-LLM
1 人がチャットで対話	十分	差は出にくい
Claude Code / Copilot ローカル補助	十分	差は限定的
社内 API（数人が同時に叩く）	待ちが出る	○
エージェントの並列ツール呼び出し	並列化に苦戦	○
RAG バッチ（数千件を一括処理）	事実上非現実	○
プレフィックス支配ワークロード（RAG など）	効率悪い	SGLang が特に強い

単一リクエストのレイテンシでは Ollama と vLLM の差はほとんど出ません。Continuous Batching と PagedAttention が効くのは、同時接続数を増やしたときに GPU の稼働率と VRAM 利用率を維持する ためであり、そこが問われる段階になって初めて本格サービング系エンジンの価値が立ちます。

Attention 側の別軸最適化（Flash Attention）と組み合わせる話は「Flash Attention 2 / 3 とは 2026年版」に、投機的デコードとの組み合わせは「投機的デコード（Speculative Decoding）とは 2026年版」にまとまっています。

まとめ

Continuous Batching は「バッチが揃うまで待たない」Iteration-level scheduling。GPU の枠が空いたら待機列から即座に新規リクエストを合流させる方式で、稼働率とレイテンシの両方に効く
PagedAttention は KV キャッシュをページ単位で必要な分だけ確保するメモリ管理。公開ベンチではメモリロスが 4% 未満まで抑えられ、静的バッチ実装の 20〜40% の利用効率から大きく改善する
この 2 つが vLLM を本格サービングエンジンの既定解に押し上げ、SGLang（RadixAttention でプレフィックス共有）、TensorRT-LLM（NVIDIA 特化の In-flight batching）が同じ思想の上で拡張している
単一ユーザーのチャット用途では差は出にくく、社内 API・並列エージェント・RAG バッチのように「同時接続数」が問われる場面で価値が立つ
KV キャッシュ量子化（サイズ圧縮）と組み合わせると実効スループットがさらに伸びる

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート