バッチ戦略が SLO を決める
LLM serving のアーキテクチャで SLO に最も直接効くのはバッチングの作り方である。どれだけ高性能な GPU を積んでも、TTFT（Time To First Token）、ITL（Inter-Token Latency）、aggregate throughput の三つの指標を同時に満たすためには、リクエスト到着の波形・入力長の分布・出力長の分布・KV cache 占有パターンに合わせてバッチ戦略を設計する必要がある。本稿では 2026 年時点で実戦投入されている五つの手法 ― continuous batching、chunked prefill、PagedAttention、RadixAttention、sorted batching ― の特性と、SLO への影響、そして prompt cache との組み合わせを整理する。
Continuous Batching
Continuous batching（別名 iteration-level scheduling）は、decode の各ステップごとにバッチ構成を再決定する方式。従来の static batching が「同じバッチの全 request が完了するまで新規を入れない」のに対し、continuous batching は「完了した request をすぐ抜き、空いたスロットに新規 request を差し込む」。この結果、GPU 利用率が request 長の偏りに影響されづらく、特に出力長の variance が大きいチャットワークロードで effective throughput が 2～4 倍伸びる。
ただし continuous batching だけでは prefill と decode が同じ step 内で衝突する問題が残る。長い prompt（8K トークン以上）が入った request の prefill は数百 ms 以上かかり、その間他の request の decode が止まる。この prefill stall が ITL 分布の long tail を作る。
Chunked Prefill
Chunked prefill は長い prompt を小さいチャンク（典型的に 512～2048 トークン）に分割し、各 iteration で「prefill の 1 チャンク ＋ 他 request の decode」を同時に処理する仕組み。これにより prefill 負荷が複数 step に分散し、ITL の jitter が激減する。SLO p99 ITL を 50ms 以内に抑える必要があるシステムでは必須機能で、vLLM、SGLang、TensorRT-LLM のすべてで標準サポート。
チャンクサイズは small すぎると kernel launch overhead が支配的になり、large すぎると decode を stall させる。KGA の経験則としては、H200 であれば 4096～8192 トークン、B200 では 8192～16384 トークンが妥当な起点になる。compute bound の prefill と memory bound の decode をミックスすると、GPU の compute / memory 両方が同時に使われるため MFU が単独処理より高くなる副次効果もある。
PagedAttention
PagedAttention は KV cache を固定サイズのページ（典型的に 16 トークン分）に分割して管理する方式で、vLLM の中核。メモリ断片化を劇的に減らし、physical メモリ使用量で 2～4 倍の実効キャパシティを得られる。2026 年現在、vLLM だけでなく TensorRT-LLM、SGLang、DeepSpeed-Inference の大半も類似の paging メカニズムを採用している。
PagedAttention は「prefix 共有」の基盤としても重要で、同一 system prompt を使う複数リクエストが同じページを参照することで物理 KV を 1 つしか持たない。ただし vLLM 本家の prefix caching は「完全一致 prefix 単位」であり、partial 一致や tenant 横断の最適化は RadixAttention 系に軍配が上がる。
RadixAttention
SGLang が提唱した RadixAttention は、KV cache を radix tree 構造で管理することで「任意の prefix 断片」を共有可能にする。system prompt、few-shot examples、tool 定義、tenant 共通 context など、ネストした共有構造を自動的に検出して物理 KV を 1 箇所に集約する。
実測ベンチマークでは、共有 system prompt を含むマルチターンチャット（平均ターン数 8、同時セッション 256）で、RadixAttention が vLLM の prefix caching 比で prefill コスト 40～60% 削減、TTFT 中央値 30～45% 改善を出す。長い tool 定義を含むエージェント workload では 2～3 倍の差が出るケースもある。
一方で eviction policy の設計が難しく、LRU 単純適用ではホットな tenant とコールドな tenant が入れ替わったときに TTFT が跳ね上がる。KGA では tenant ごとに優先度を付与した weighted LRU、または tenant パーティションを固定割当する hard partitioning を状況に応じて選んでいる。
Sorted Batching
Sorted batching は「入力長または残り出力長が近い request を同一バッチにまとめる」戦略。naive な continuous batching は長短が混在するとパディングと padding mask の非効率が出るが、sorted batching はこれを緩和する。2026 年時点では serving フレームワークに標準実装されているというより、上位レイヤーのルーター／スケジューラが実装する機能である。
短応答専用エンドポイント（classification、reranking、短い summarization）と長応答エンドポイント（report 生成、long-form コード生成）を分離し、それぞれで sorted batching を適用する設計が最もシンプルで、effective throughput 20～35% 向上が実測できる。
SLO への影響まとめ
- TTFT: chunked prefill と prefix caching / RadixAttention が支配的。これら 2 つが入っていれば p50 TTFT は 100ms 前後、p99 でも 500ms 以内に収まる。
- ITL: continuous batching と chunked prefill が効く。chunked prefill を入れないと p99 ITL が容易に 200ms を超える。
- Throughput: PagedAttention でメモリ効率を出し、continuous batching で slot を詰め、RadixAttention で prefill 無駄を削る、の三点セットで最大化。
- p99 tail: sorted batching と admission control で守る。QPS spike 時は低優先度 request を queue させる admission policy が必要。
Prompt Cache 戦略
本番スタックで prompt cache を設計するときの軸は四つある。
System prompt sharing。全 tenant 共通の system prompt は起動時にプリウォームして常駐させる。RadixAttention では起動スクリプトで `warmup` リクエストを投げて KV tree に乗せておくのが定石。
Tenant partitioning。SaaS 型でマルチテナントを混ぜる場合、tenant A と B の context が混ざると security／compliance の観点で問題になることがある。RadixAttention は暗号論的分離ではないため、金融・医療など厳しいドメインでは tenant ごとにプロセス（または GPU グループ）を分離し、共有レイヤーを「非機密な system prompt のみ」に限定する設計が必要。
TTL と eviction。セッションが長いチャットエージェントでは、マルチターン会話の中間 KV を一時キャッシュに保存し、会話中断後 N 分で evict する設計が効く。KGA の社内検証では TTL を 15～30 分に設定し、メモリ圧と再 prefill コストの balance を取っている。
Cross-request dedup。エージェント系では同一 tool 応答を複数の LLM call に渡すパターンが多く、この tool 応答をフィンガープリントで dedup して KV tree に一度だけ載せる工夫が TTFT を 30% 以上削る。
設定例: vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
`max_num_seqs` を大きくし過ぎるとメモリ圧で swap が頻発するため、実運用では QPS 想定と p99 出力長から逆算する。KGA の経験値では、QPS_peak × p99_output_length / expected_decode_rate が概ねの上限になる。
まとめ
バッチ戦略は「五つの手法を単品で選ぶ」ものではなく、「全部入れた上でパラメータを SLO に合わせて調整する」のが 2026 年の正解。TTFT を守るなら chunked prefill と RadixAttention、ITL を守るなら chunked prefill と sorted batching、throughput を上げるなら continuous batching と PagedAttention、tenant 分離を守るなら hard partitioning と tenant-aware eviction。この四軸でアーキテクチャを設計すれば、H200 SXM 8 枚構成で 70B モデルでも aggregate 2500 tok/s、p99 TTFT 400ms 以内の SLO は十分に狙える。