# セルフホストLLM推論スタック——vLLM/SGLang選定

> 自社ホスティングのLLM推論エンジンはvLLMとSGLangが2026年の標準選択肢。RadixAttentionはプレフィックス再利用でキャッシュヒット率50〜99%を達成する。テンソル並列とKVキャッシュ設計の判断基準を解説する。

- Canonical: https://kuucorp.com/blog/self-hosted-llm-inference-stack-vllm-sglang/
- Date: 2026-08-05
- Last modified: 2026-08-05
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
データレジデンシー要件やAPIコストの規模から、エージェント基盤の一部モデルを自社GPUクラスタでホスティングする判断をする大企業が増えています。しかしAPI呼び出しと違い、セルフホスト推論は「どの推論エンジンを使うか」「GPUメモリをどう配分するか」を自分たちで設計する必要があります。本記事は[VPC内LLMデプロイのデータレジデンシー設計](/blog/vpc-llm-deploy-data-residency/)を前提に、推論エンジン層の技術選定を扱います。

## なぜ自前ホスティングの推論エンジンが必要になるのか

> データレジデンシー要件やエージェントのマルチターン特性でAPI呼び出しコストが線形に増える場合、自社GPUクラスタでの推論ホスティングが選択肢になる。

マネージドAPIはスケーラビリティと運用負荷の低さで優れていますが、契約上のデータ持ち出し制約がある業界（金融・医療・官公庁関連）や、1リクエストあたり数十回のツール呼び出しを行うエージェントワークロードでは、トークン量に比例するAPIコストが予算を圧迫します。この2つの制約が重なったときに、自社インフラでの推論ホスティングが現実的な選択肢になります。ただし推論エンジンの選定を誤ると、GPU使用率が上がらず投資対効果が出ません。

## vLLMとSGLangは何が違うのか

> vLLMはPagedAttentionでKVキャッシュをブロック単位管理する業界標準、SGLangはRadixAttentionでプレフィックスKVキャッシュを木構造で自動再利用する。

**vLLM**はUCバークレー発のOSS推論エンジンで、2026年時点で自前ホスティングのデファクトスタンダードです。PagedAttentionという固定サイズブロックでKVキャッシュを管理する方式により、メモリ断片化を抑えながら高スループットな継続的バッチング（continuous batching）を実現します。NVIDIA H100/H200/B200に加えAMD MI300X・AWS Inferentia・Google TPUまで幅広いハードウェアに対応しています。

**SGLang**はvLLMと同じページ化メモリ管理を土台にしつつ、**RadixAttention**という仕組みを追加しています。KVキャッシュを木構造（radix tree）で保持し、共通のシステムプロンプトや会話履歴を持つリクエスト間でキャッシュを自動的に共有します。設定不要でプレフィックス一致を検出するため、システムプロンプトを共有するチャットや少数ショット例を繰り返し使うワークロードでキャッシュヒット率が50〜99%に達し、vLLM比で30〜50%高いスループットを示すケースが報告されています。

## テンソル並列とKVキャッシュはどう設計するか

> モデルが単一GPUに収まらない場合はテンソル並列でGPU間分割し、`--max-model-len`でKVキャッシュ用メモリ予算を制御する。

vLLMはMegatron-LM由来のテンソル並列アルゴリズムを実装しており、`--tensor-parallel-size`にGPU数を指定するだけでGPU間通信を自動的に処理します。モデルが単一ノードに収まらない場合はパイプライン並列を併用し、MoEモデルにはエキスパート並列（EP）も選択できます。

GPUのVRAMは「モデル重み＋KVキャッシュ＋アクティベーション」のゼロサム予算です。`--max-model-len`は最大シーケンス長を制限することでKVキャッシュに割り当てるメモリ量を直接左右し、この値をモデルの最大コンテキスト長より低く設定することでバッチサイズを稼ぐ余地を確保できます。逆に`--max-num-seqs`を上げすぎるとKVキャッシュ不足でリクエストが拒否されるため、ワークロードの平均シーケンス長を計測してから調整するのが実務手順です。

## エージェントのマルチターン特性はどう推論スタックに影響するか

> エージェント推論は1リクエストではなく相関する複数LLM呼び出しの集合であり、ユーザー体感レイテンシは個別呼び出しではなくプログラム全体の完了時間で決まる。

チャット向けAPI設計は「1リクエスト・1レスポンス」を前提にしますが、AIエージェントは1つのタスク完了までに計画・ツール呼び出し・観測を何度も繰り返す「プログラム」として動きます。この特性により、システムプロンプトやツール定義など固定プレフィックスを繰り返し送信する頻度が通常のチャットより高くなり、RadixAttentionのようなプレフィックスキャッシュの効果が相対的に大きくなります。一方でツール実行待ちなど非LLM処理の間隔が挟まるため、リクエストの到着パターンが不規則になり、スケジューラのバッチ効率にも影響します。低トラフィック（300リクエスト/秒未満）では単一ノードのテンソル並列構成、高トラフィックではKubernetes上でRayスケジューラとティア化したKVキャッシュマネージャを組み合わせる構成が実務上の目安です。

## 参考

- [Parallelism and Scaling - vLLM Documentation](https://docs.vllm.ai/en/latest/serving/parallelism_scaling/)
- [Distributed Inference and Serving - vLLM Documentation](https://docs.vllm.ai/en/v0.9.1/serving/distributed_serving.html)
- [SGLang: Efficient Execution of Structured Language Model Programs (arXiv:2312.07104)](https://arxiv.org/pdf/2312.07104)

## まとめ

自前ホスティングの推論スタックは、プレフィックス共有が多いエージェントワークロードならSGLang、ハードウェア対応の広さとエコシステムの成熟を優先するならvLLMが出発点になります。設計の要点は3点です。

1. **エンジン選定**: PagedAttention（vLLM）かRadixAttention（SGLang）かをワークロードのプレフィックス共有率で判断する
2. **並列化戦略**: モデルサイズとGPU台数に応じてテンソル並列・パイプライン並列を組み合わせる
3. **メモリ予算管理**: `--max-model-len`と`--max-num-seqs`でKVキャッシュとバッチサイズのトレードオフを制御する

自社GPUクラスタでのエージェント推論基盤設計は、[Kuu株式会社のRDEサービス](https://kuucorp.com/services/rde/)で選定から運用設計まで支援しています。