vLLM と SGLang はどちらが速いですか？

同時16接続・共通プロンプトなしの純粋なスループット比較では TensorRT-LLM が最上位ですが、実運用ではワークロード次第です。SGLang は RadixAttention によって共通プレフィックスを KV キャッシュで使い回すため、RAG やマルチターンチャットのように「同じシステムプロンプト＋違うユーザー質問」を大量に捌く用途では vLLM に対して 29% 前後、プレフィックス支配的なワークロードでは最大 6.4 倍のスループット優位が公開ベンチで報告されています。逆にプロンプトが毎回ユニークなバッチ推論なら vLLM のほうがハード対応の広さを含めて安定します。

TensorRT-LLM は vLLM とどう違いますか？

TensorRT-LLM は NVIDIA GPU に特化したエンジンで、in-flight batching と低レベル最適化により高並列時の総スループットで vLLM を 30〜50% 上回るケースがあります。半面、対応ハードは NVIDIA のみ、量子化フォーマットも NVIDIA 系（FP8、Blackwell の FP4）が中心で、AMD ROCm や Apple Silicon は対象外です。ハードが NVIDIA 一色で確定していて最大スループットが目的なら TensorRT-LLM、対応の広さや将来のハード変更に含みを持たせたいなら vLLM を選ぶ整理になります。

vLLM / SGLang / TensorRT-LLM / TGI はすべて OpenAI 互換 API に対応していますか？

はい、4本とも `/v1/chat/completions` を含む OpenAI 互換エンドポイントに対応しています。したがってクライアント側は OpenAI SDK のベース URL を差し替えるだけでランタイムを乗り換えられます。TGI は Hugging Face の Messages API という独自形式も同時に提供しますが、OpenAI 互換モードで使う限り実装差はほぼ見えません。乗り換え時の実質的な作業は、量子化フォーマットの差し替えとサーバー起動オプションの調整に絞られます。

個人利用でも SGLang や vLLM を使ったほうがいいですか？

自分一人がチャット用途で使うだけなら Ollama や LM Studio で十分です。SGLang や vLLM の強みは同時接続数が増えた時に伸びる連続バッチングとキャッシュ再利用にあり、単一リクエストのレイテンシでは Ollama との差はほとんど出ません。社内で複数人が同時に叩く、エージェントが並列にツール呼び出しを走らせる、大量のバッチ推論を回すといった段階になって初めて本格サービングエンジンの価値が立ちます。切り分けは個人検証か本格サービングかで判断してください。

ローカルLLM 本格サービング推論エンジン比較 2026年版：vLLM / SGLang / TensorRT-LLM / TGI を continuous batching・マルチテナント・OpenAI互換で選ぶ

本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細はプライバシーポリシーをご覧ください。

ローカルLLM 本格サービング推論エンジン比較 2026：vLLM / SGLang / TensorRT-LLM / TGI をマルチテナント・continuous batching で選ぶ

結論：ローカルLLM を Ollama から本格サービングに移すなら、対応ハードが広く実装が枯れている vLLM が既定解です。RAG やマルチターンチャットのようにシステムプロンプトを使い回すワークロードなら SGLang の RadixAttention が効き、公開ベンチで vLLM に対して 29% 前後、プレフィックス支配時は最大 6.4 倍のスループット優位が出ます。NVIDIA GPU で純粋な高並列スループットを最大化したいなら TensorRT-LLM が上回りますが、対応ハードは NVIDIA 限定です。Hugging Face TGI は Messages API と OpenAI 互換を両方持つ運用重視の選択肢ですが、高並列時の絶対スループットは vLLM に劣る傾向です。

Ollama や llama.cpp でローカルLLM を触っていて、次のどれかが見え始めたら本格サービングへの移行タイミングです。

社内やチームで複数人が同時に同じサーバーを叩く
エージェントがツール呼び出しを並列で走らせて 1 セッションあたり数十リクエスト飛ぶ
夜間バッチで数千件のプロンプトを一気に回す
同じシステムプロンプト＋違うユーザー質問を大量に捌く RAG ワークロード

このあたりから Ollama の「既定で 1 並列」というモデルは崩れます。本記事は Ollama の次に立てるレイヤーとして、vLLM / SGLang / TensorRT-LLM / Hugging Face TGI の 4 本を、continuous batching・PagedAttention・投機的デコード対応・OpenAI 互換 API・マルチテナントでの tok/sec の視点で比較します。個人利用向けのランタイム全般の話は「ローカルLLM実行ツール比較 2026年版」にまとまっているので、そちらは「個人検証＝Ollama / LM Studio」の側、本記事は「本格サービング」の側と読み分けてください。

4本の立ち位置を1枚で

エンジン	一言で	主要技術	対応ハード	OpenAI 互換 API	主な用途
vLLM	本格サービングの既定解	PagedAttention・continuous batching・prefix cache・投機的デコード	NVIDIA / AMD ROCm / Intel Gaudi / TPU / Trainium	あり	一般的な API サーバー、幅広いハード
SGLang	プレフィックス支配ワークロードの本命	RadixAttention・structured output	NVIDIA 中心（AMD 実験対応）	あり	RAG、マルチターンチャット、JSON 強制
TensorRT-LLM	NVIDIA 特化の高並列	in-flight batching・FP8 / FP4 量子化	NVIDIA のみ（Blackwell 最適化）	あり（trtllm-serve）	Blackwell / Hopper で最大 tok/sec
Hugging Face TGI	運用ツール込みのマネージド寄り	continuous batching・token streaming・Messages API	NVIDIA / AMD / Gaudi	あり	HF エコシステム、社内 SaaS 運用

ざっくり言うと、vLLM は「ハード対応と機能の広さで既定選択」、SGLang は「共通プレフィックス支配ワークロードで差がつく」、TensorRT-LLM は「NVIDIA でスループットの天井を狙う」、TGI は「Hugging Face エコシステムに寄せるなら」という住み分けです。

continuous batching と PagedAttention：本格サービングの底が2倍以上変わる

Ollama 既定の 1 並列運用から、本格サービングエンジンに移すと何が変わるかの中心はここです。

Continuous batching（連続バッチング） は、リクエストを固定サイズのバッチで束ねて待つ代わりに、生成が終わったリクエストを都度抜き、待機列から新しいリクエストを都度差し込む方式です。単一リクエストのレイテンシを大きく損なわずに GPU の稼働率を維持できるため、リクエスト到着がバースト的になる実運用でスループットを稼ぎます。

PagedAttention は KV キャッシュを固定サイズのページに分割して管理する仕組みで、リクエストごとに KV キャッシュを事前確保しなくても済むため、同時接続数を増やしても VRAM 断片化でスループットが崩れません。vLLM は初期からこの 2 つを主軸に設計されており、本格サービングエンジンの土台になっています。

SGLang は PagedAttention 相当のページ管理に加え、RadixAttention で共通プレフィックスの KV キャッシュを Radix 木構造で LRU 保持し、新規リクエストのプレフィックスが過去リクエストと重なる場合に再計算をスキップします。RAG では検索結果と長いシステムプロンプトが毎回同じで、ユーザー質問だけが変わることが多いため、この再利用が効きます。プレフィックス支配的なワークロードで最大 6.4 倍のスループット向上、一般的なワークロードでも H100 で vLLM 12,500 tok/s に対して SGLang 16,200 tok/s（+29%）という公開ベンチが出ています。

TensorRT-LLM は同種の in-flight batching と NVIDIA の Tensor Core / FP8 / FP4 に踏み込んだ最適化で、Blackwell / Hopper 上での高並列スループットを稼ぎます。ハードが NVIDIA に固定される代わりに、量子化と GEMM の底を潰す方向で伸びが出るのが特徴です。TGI は自前の continuous batching と token streaming を持ち、機能面では vLLM を追随していますが、公開ベンチでは高並列時のスループットが vLLM 比 30〜50% 低いケースが観測されています。

投機的デコードとプレフィックスキャッシュ：単一リクエストのレイテンシにも効く

高並列時のスループットに加えて、単一リクエストの体感速度に効く機能でもエンジンによって差があります。

投機的デコード（Speculative Decoding）：小さいドラフトモデルで先読みし、本モデルで一括検証する方式。vLLM は v0.6 以降で本格対応、SGLang / TensorRT-LLM / TGI も対応済み。用途と受理率次第で 1.5〜2 倍前後のレイテンシ改善が出ます
プレフィックスキャッシュ：システムプロンプトなど固定部分の KV を再利用。vLLM は Automatic Prefix Caching、SGLang は RadixAttention として組み込み済み。TensorRT-LLM / TGI もキャッシュ対応
チャンクドプレフィル（Chunked Prefill）：長いプロンプトのプレフィル処理を分割し、デコード中のリクエストと干渉させにくくする。vLLM / SGLang で採用、TTFT（Time To First Token）の悪化を抑える

RAG や長文プロンプト前提のワークロードでは、この 3 機能の噛み合わせでレイテンシと総スループットの両方が大きく動きます。プレフィルとデコードの比率がどう効くかは「LLM プレフィル vs デコードベンチマーク 2026年版」で詳しく扱っています。

OpenAI 互換 API：エンジン乗り換えのハードルは低い

4 本とも OpenAI 互換の /v1/chat/completions を提供しています。したがってクライアント側の実装は共通で、乗り換え時に触るのは主にサーバー起動オプションと量子化フォーマットです。

vLLM：vllm serve <model> で起動、--tensor-parallel-size でマルチ GPU 分割、--quantization awq/gptq/fp8 で量子化指定
SGLang：python -m sglang.launch_server --model-path <model> で起動、structured output や JSON 強制モードが標準装備
TensorRT-LLM：trtllm-serve コマンドまたは Triton Inference Server 連携。事前に TensorRT-LLM 用のエンジンをビルドする一手間が必要
TGI：Docker イメージが公式で提供され、docker run ghcr.io/huggingface/text-generation-inference で起動、MAX_CONCURRENT_REQUESTS で並列制御

いずれも OpenAI SDK のベース URL を http://<host>:<port>/v1 に向ければ、既存の OpenAI ベースのアプリケーションはほぼそのまま動きます。マルチテナントでの認証はエンジン側では扱わず、前段のリバースプロキシ（Nginx / Traefik / Envoy）で API キー検証やレート制限を掛ける構成が定番です。

対応モデルと量子化フォーマット：ハードが決まると選択肢が絞られる

エンジン選定はハードと量子化フォーマットの噛み合わせでほぼ決まります。

フォーマット	vLLM	SGLang	TensorRT-LLM	TGI
FP16 / BF16 (safetensors)	○	○	○	○
AWQ	○	○	○	○
GPTQ	○	○	○	○
FP8 (NVIDIA Hopper 以降)	○	○	○（強い）	○
FP4 (NVIDIA Blackwell)	○（v0.10 以降）	○	◎（最適化最深）	△
GGUF	△（限定）	×	×	×
MLX (Apple Silicon)	×	×	×	×

GGUF や MLX を主軸にしたいなら本記事の対象外で、Ollama / LM Studio / llama.cpp の側に留まるのが素直です。Safetensors + AWQ / GPTQ / FP8 系で運用するなら 4 本ともほぼ同じモデルを回せます。Blackwell の FP4 に踏み込む場合は TensorRT-LLM が最適化最深、その次に vLLM v0.10 系という順です。量子化フォーマット別の選び方は「LLM 量子化フォーマット別解説 2026年版」を参照してください。

マルチテナントでの tok/sec：同時16接続で総スループットがどう伸びるか

個人利用のツールと本格サービングエンジンの一番の差は、単一 GPU で「同時 16 接続時に総 tok/sec がどう伸びるか」です。同時 1 接続なら Ollama とも大きな差は出ませんが、同時 16 接続では設計思想の差がそのまま現れます。

公開ベンチ（H100 80GB、LLaMA 3 70B AWQ、同時 16 接続）の傾向は以下です。実測値はモデルや量子化・シーケンス長で動くため、目安として読んでください。

エンジン	同時 16 接続の総 tok/sec 目安	相対比（vLLM を 1.0 とした場合）
Ollama（並列拡張なし）	約 40〜100 tok/s	0.05〜0.1
Hugging Face TGI	約 900〜1,100 tok/s	0.7〜0.9
vLLM	約 1,200〜1,400 tok/s	1.0（基準）
SGLang（プレフィックス薄）	約 1,500〜1,700 tok/s	1.2〜1.3
SGLang（RAG / プレフィックス支配）	最大 vLLM の 6.4 倍	5.0〜6.4
TensorRT-LLM（FP8）	約 1,700〜2,000 tok/s	1.3〜1.5
TensorRT-LLM（Blackwell FP4）	それ以上	ワークロード次第

ポイントは同時 16 の総 tok/sec を単独で見ないことです。ワークロードのプレフィックス構造で選択が変わります。プレフィックスが薄い（毎回ユニークなプロンプト）なら TensorRT-LLM / vLLM、プレフィックスが厚い（RAG やマルチターンチャット）なら SGLang が有利になります。単一 GPU で 70B 級を回すハード側の目安は「GPU の選び方（ローカルLLM 用）2026年版」も合わせて確認してください。

テンソル並列とマルチ GPU：複数 GPU にモデルを分割する

70B や 100B 級の非量子化モデルを載せる場合、単一 GPU に収まらないことが多く、テンソル並列でモデルを分割する構成になります。

vLLM：--tensor-parallel-size 4 で 4 GPU に分割、--pipeline-parallel-size でパイプライン並列も併用可能
SGLang：--tp 4 で同様に分割、RadixAttention を維持したまま複数 GPU に対応
TensorRT-LLM：エンジンビルド時に並列数を指定、NVIDIA の NVLink 前提で性能が伸びる
TGI：--num-shard 4 で分割、同種の実装

Dual RTX 5090 でのマルチ GPU 実効は「Dual RTX 5090 マルチ GPU ローカルLLM ベンチマーク 2026年版」で扱っています。100B 超のモデルを 1 台で回す構成の全体像は「100B 超ローカルLLM GPU ベンチマーク 2026年版」を参照してください。

選び方の結論：ワークロード別に4本を割り振る

これから本格サービングに移す・ハードが混在している → vLLM。対応ハードと量子化の広さで既定解。実装が枯れており事故が少ない
RAG やマルチターンチャットが主 / システムプロンプトが長く固定 → SGLang。RadixAttention でプレフィックス再利用が効き、vLLM 比 29% 〜数倍のスループット優位
NVIDIA GPU 固定 / Blackwell / Hopper で総スループット最大化 → TensorRT-LLM。FP8 / FP4 の最適化最深で高並列の天井が高い。ビルドの手間はある
Hugging Face エコシステムで運用ツールも欲しい / 社内 SaaS 向け → TGI。Docker 前提のマネージド寄り運用、Messages API の使い勝手も含めて選ぶ
一人でチャット・単一リクエストのみ → 本記事の対象外。Ollama / LM Studio に留まるほうが導入と保守で得

本格サービングエンジンの選定は、単純な tok/sec 比較だけでは決まりません。プレフィックス構造・ハード・量子化フォーマットの 3 軸で判断してください。ハードが決まっているなら量子化と並列の噛み合わせで自動的に絞れますし、ハードがこれからなら vLLM を軸に置きつつ RAG 用途で SGLang を後から立てるのが素直な進め方です。

サーバー側のハードとネットワーク

本格サービングエンジンを 24 時間立てっぱなしにする場合、ハード側の設計も個人利用とは変わります。アイドル電力・冷却・宅内 API の帯域を含めた全体像は「自宅ローカルLLMサーバー構築ガイド 2026年版」に整理してあります。ローカルLLM 全体の tool use / function calling の実装は「ローカルLLM function calling / tool use ガイド 2026年版」で扱っています。

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

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

→ 診断スタート