vLLM vs SGLang 2026：H100で両方をベンチマークしました

vLLM vs SGLang 2026：H100で両方をベンチマークしました

Hugging Faceは2025年12月にTGI（Text Generation Inference）をメンテナンスモードに移行し、新しいデプロイメント向けにvLLMまたはSGLangへの移行を推奨しています。今日、推論スタックを構築しようとしている場合、真の課題は「TGIからの移行すべきか？」ではなく、「これらの2つのエンジンのうち、どれが実際のワークロードに適しているか？」です。

クイックサマリー

vLLMを選ぶべき場合：最も広範なハードウェアサポート、最大のコミュニティ、そしてAWS、GCP、Azure全体での本番環境向けの実証済みのパスを求めている場合。

SGLangを選ぶべき場合：マルチターン会話、構造化出力、RAGのようなプレフィックス重視のパイプラインに負荷がかかるワークロードであり、エコシステムが小さくても問題ない場合。

それでは、各エンジンが実際に優位性を発揮するポイントを詳しく見ていきましょう。

ここに至るまでの経緯：TGIの撤退

Text Generation Inference（TGI）は長年Hugging Faceエコシステムを支えてきましたが、2025年12月現在はバグ修正のみを受け付け、新機能は追加されていません。Hugging Face独自のInference Endpointsも現在、デフォルトでvLLMを使用し、SGLangを代替オプションとしています。

これにより、セルフホスト型LLMサービングにおける真の競合者は2つに残りました。どちらもオープンソースであり、OpenAI APIに対応し、NVIDIA GPU上で動作します。違いは負荷がかかった状態で顕著になります。

結論：vLLMとSGLangの両方が、TGIの本番環境代替として準備完了です。 移行を検討している場合、どちらを選んでも安全ですが、このガイドの残りの部分でどちらを選ぶべきかの判断材料を提供します。

スループットとレイテンシのベンチマーク

ベンチマーク結果はモデル、GPU、同時実行性によって異なりますが、ここでは同じハードウェアでの独立したテストの数値を示します。以下のデータは、FP8形式のLlama 3.3 70B Instructを使用したSpheronのH100ベンチマークと、Llama 3.1 8Bを使用したPremAIのテストに基づいています。

H100上のLlama 3.3 70B（FP8）

H100上のLlama 3.1 8B

小規模なモデルでは差が広がります。PremAIの測定によると、SGLangは約16,200 tok/s、vLLMは12,500 tok/sであり、SGLangには29%のスループット優位性があります。LMDeployもここでSGLangと同等の結果を出しましたが、それは別の話題です。

数値が意味すること

70Bスケールでは差は modest（3-5%）ですが、8Bスケールでは顕著です。このパターンは理にかなっています。SGLangのRadixAttentionは、プリフィルが総コストの大部分を占める場合に効果を発揮しますが、これは小規模なモデルや短い出力で発生しやすい状況です。

テールレイテンシも同様の傾向を示します。SGLangのTTFT p95は、テストされたすべての同時実行レベルでvLLMより一貫して5-8%低かったです。50ms単位が重要なリアルタイムチャットインターフェースを構築している場合、この差はユーザー数に応じて累積していきます。

結論：SGLangは生スループット、特に小規模モデルで勝利します。 vLLMは70B以上のスケールでは接近しています。ほとんどの本番ワークロードでは、差は一桁のパーセンテージであり、大規模化では意味を持ちますが、どちらか一方が決定的な要因になるわけではありません。

プレフィックスキャッシング：RadixAttention vs 自動プレフィックスキャッシング

両エンジンは繰り返されるプレフィックスのKV計算をキャッシュしますが、そのメカニズムは特定のワークロードにとって重要な点で異なります。APIレベルでのプロンプトキャッシングにすでに慣れている場合は、これをサーバーサイド版と考えてください。

vLLMはブロックレベルのハッシングを使用します。KVキャッシュを固定サイズのブロックに分割し、ハッシュ化して、新しいリクエストで一致を検索します。予測可能で効率的、かつ理解しやすいですが、キャッシュヒットには一貫したブロック境界が必要です。

SGLangはトークンレベルでインデックス化されたRadix Treeを使用します。手動設定なしにリクエスト間で共有プレフィックスを自動的に発見します。50人のユーザーが同じ会話スレッドでメッセージを送信した場合、SGLangは共通のプレフィックスを自動的に見つけて再利用します。

実際に重要になる場面

RunPodはマルチターン会話のベンチマークを実施し、高同時実行下でSGLangが一貫して約30-31 tok/sを提供したのに対し、vLLMはキャッシュ圧力が増加するにつれて22から16 tok/sに低下したことを発見しました。これはチャットボットやエージェントワークロードにとって意味のある差です。

すべてのリクエストが同じシステムプロンプトを使用するテンプレート化されたプロンプトのバッチ推論の場合、vLLMのアプローチで十分です。キャッシュ境界はテンプレート構造と自然に整列します。

結論：動的なマルチターンワークロードではSGLangが勝利します。 vLLMは、プレフィックスが予測可能なバッチ推論やテンプレート化されたプロンプトで完全に適切です。

構造化出力

JSONスキーマ強制や制約付き生成が必要な場合、このセクションは非常に重要です。両エンジンはXGrammarやLLGuidanceなどのグラマーバックエンドを通じて構造化出力をサポートしていますが、パフォーマンスの状況は大きく異なります。

SqueezeBitsの詳細なベンチマークによると、vLLMはガイド付きデコーディングを有効にすると、特にバッチサイズ8以上でスループットが大幅に低下することがわかりました。対照的にSGLangは、マスク生成をGPU推論ステップとオーバーラップさせることで、オーバーヘッドを最小限に抑えています。

反復的スキーマ vs 動的スキーマ

バックエンドの選択も重要です：

構造化強制なしでは、複雑なスキーマでの正解率は約61%まで低下します。強制ありでは、正解率が20-25ポイント上昇します。したがって、これは本番エージェントワークフローでは必須であり、選ぶエンジンによって犠牲にするスループット量が決まります。

結論：構造化出力ではSGLangが勝利します。 パイプラインがJSONスキーマ強制に依存している場合（ほとんどのエージェントワークフローが該当）、SGLangのオーバーラップアプローチにより、スループットのペナルティを支払う必要がありません。

マルチLoRAおよびファインチューニング済みモデルのサービング

両エンジンは単一のベースモデルから複数のLoRAアダプターをサービングすることをサポートしており、異なるテナントやタスク用にモデルをファインチューニングする場合に不可欠です。

SGLangはマルチLoRAをファーストクラス機能として扱い、ネイティブバッチ処理により、異なるアダプターを対象とするリクエストが同じバッチを共有できます。vLLMもサポートしていますが、SGLangの実装は最近のリリースでわずかに洗練されています。

実務的な違いは何でしょうか？ 1つのLlama 70Bベースモデルから5-10のLoRAアダプターをサービングする場合、両方とも動作します。しかし、50以上のアダプターを異種トラフィックパターンで実行している場合、SGLangのネイティブバッチ処理はスケジューリングをより円滑に処理します。

結論：大規模なマルチLoRAではSGLangがわずかに優位です。 少数のアダプターの場合、両エンジンとも同等に機能します。

推測的デコーディング

両エンジンは推測的デコーディングをサポートしており、小さな「ドラフト」モデルを使用してトークンを予測し、メインモデルがそれを並列で検証します。その結果、メモリボトルネックのシナリオで推論速度が2-3倍向上します。

vLLMは最近Unified Parallel Draftingを導入し、推測的デコーディングは構造化出力と併用できるようになりました。SGLangの実装も能力としては同様ですが、中程度の同時実行レベルでわずかに優れたパフォーマンスを示します。

真の差別化要因はエンジンではなく、推測的デコーディングがワークロードに適合するかどうかです。これは、ボトルネックが計算ではなくメモリ帯域幅である大規模モデルからの長い出力で最も効果的です。

結論：引き分け。 両エンジンとも同等の推測的デコーディング速度向上を提供します。

ハードウェアサポートとデプロイメント

ここでvLLMが大幅にリードしています。

vLLM

• NVIDIA GPU（A100, H100, H200, B200）
• AMD GPU（MI250, MI300X）
• Intel GPU（vllm-xpu-kernels経由）
• AWS TrainiumおよびInferentia
• Google TPU
• Helmチャート、スタートアップ/レディネス/ライブネスプローブを備えた成熟したKubernetesドキュメント
• NVIDIA Container Toolkitとの統合が標準で利用可能

SGLang

• NVIDIA GPU（A100, H100, H200, B200）
• AMD GPU（ROCm経由のMI300X）
• Dockerファーストのデプロイメント
• Kubernetesも可能だが、ドキュメントは少なめ

NVIDIAまたはAMD以外の環境でデプロイする場合、vLLMが唯一の選択肢です。特にAWSでは、Trainiumサポートにより推論コストを大幅に削減でき、SGLangはそのハードウェアに対応できません。

標準的なNVIDIA GPUで運用しているチームにとって、デプロイメントの状況は似ています。両方ともDockerイメージとOpenAI互換のエンドポイントを提供しています。vLLMには、より実証済みの本番ガイドとコミュニティ貢献のHelmチャートがあるだけです。

LLMをローカルで実行するためのツールを検討している場合や、セルフホスト型推論の broader view を求めている場合、両エンジンともコンシューマーGPUでのローカルデプロイをサポートしていますが、データセンターハードウェア向けに設計されています。

結論：ハードウェアの広範さとデプロイメントの成熟度ではvLLMが勝利します。 NVIDIAまたはAMDを使用している場合、SGLangでも問題ありません。それ以外の場合、vLLMが唯一の選択肢です。

分離型サービング

両エンジンは、プリフィル（計算重視）とデコード（メモリ重視）を異なるワーカープールに分離することをサポートしています。これにより、各フェーズを独立してスケールさせることができます。プロンプト重視のバースト時にはプリフィルワーカーを、長い生成時にはデコードワーカーを増やすことができます。

SGLangは分離型の転送バックエンドとしてMooncakeとNIXLをサポートしており、NVIDIA GB200 NVL72クラスターでデコードスループットが2.7倍高いという結果を発表しています。vLLMの分離型サービングも機能しますが、ドキュメントはやや目立ちません。

この機能は非常に大規模なスケール（96 GPU以上）で最も重要になります。 handful のGPUで運用している場合、まだ必要ない可能性があります。

結論：分離型サービングの成熟度ではSGLangがわずかに優位です。 両方ともサポートしていますが、SGLangはより多くの実世界での結果を発表しています。

いつどちらを使用するか：意思決定フレームワーク

多くのチームに対する率直な答え：両方を試してみてください。どちらもオープンソースで、同じOpenAI APIを公開しており、切り替えはコンテナの交換だけで済みます。実際のワークロードをそれぞれで1日実行し、あなたにとって重要な指標を比較してください。

複数の推論バックエンド間でトラフィックをルーティングしている場合、LLMゲートウェイをいずれのエンジンの前に配置し、フェイルオーバー、レート制限、オブザーバビリティを処理できます。

Techsyが推論サーバー選定にどうアプローチするか

私たちがチームのLLM搭載機能のデプロイメントを支援する際、推論エンジンの選択は次の3つの質問に集約されます。

1. どのハードウェアに縛られていますか？ TrainiumまたはTPUの場合、vLLMです。その他すべて、両方動作します。
2. ワークロードの形状はどうですか？ マルチターンチャットとエージェントループはSGLangのプレフィックスキャッシングを好みます。バッチ処理と単純な補完はどちらでも問題ありません。
3. 運用キャパシティはどの程度ありますか？ vLLMの大きなコミュニティは、午前3時に何か壊れた際のStackOverflowの回答やHelmチャートが豊富であることを意味します。

私たちは両方で本番ワークロードを実行してきました。 genuinely close です。正解は抽象的に「どちらかが優れている」ことではなく、あなたの制約条件に依存します。

推論サーバーの選択やデプロイメントでお困りですか？ お問い合わせください。ワークロードを評価し、適切なスタックを推奨します。

ツールを選ぶことは容易な半分です。それを実際の製品内で確実に動作させることが、ほとんどのチームがつまずく場所であり、这正是私たちのAI統合チームがクライアントのために構築していることです。RAGパイプラインからカスタムエージェントまで対応します。

よくある質問

SGLangはvLLMより高速ですか？

小規模モデル（7B-8B）では、SGLangはH100 GPUで約29%高いスループットを示します。70B以上のモデルでは、差は3-5%に縮まります。SGLangはまた、テストされたすべての同時実行レベルでテールレイテンシ（TTFT p95）が低いです。

vLLMとSGLangをOpenAI API形式で使用できますか？

はい。両方とも標準でOpenAI互換のエンドポイントを公開しています。クライアントコードを変更せずに一方から他方に切り替えることができます。/v1/chat/completions呼び出しはどちらでも同一に動作します。

なぜHugging FaceはTGIを非推奨にしたのですか？

TGIは2025年12月にメンテナンスモードに入りました。Hugging Faceは別の推論エンジンを維持する代わりに、vLLMとSGLangに貢献することを決定しました。TGIは既存のデプロイメントでは依然として動作しますが、新機能は追加されません。

SGLangはNVIDIAおよびAMD GPUをサポートしていますか？

SGLangはNVIDIA GPU（A100, H100, H200, B200）およびAMD GPU（ROCm経由のMI300X）をサポートしています。Intel GPU、AWS Trainium、Inferentia、またはGoogle TPUはサポートしていません。vLLMの方がハードウェアカバー範囲が広いです。

RadixAttentionとは何ですか？なぜ重要ですか？

RadixAttentionはSGLangのプレフィックスキャッシングメカニズムです。トークンレベルでインデックス化されたRadix TreeにKVキャッシュエントリを保存し、リクエスト間で共有プレフィックスを自動的に発見します。これにより、マルチターン会話やRAGパイプラインが大幅に高速化されます。繰り返されるコンテキストを再計算する必要がないためです。

構造化JSON出力に最適なエンジンはどれですか？

SGLangです。グラマーマスク生成をGPU推論とオーバーラップさせるため、構造化出力強制はスループットにほとんど影響しません。vLLMは、ガイド付きデコーディングを有効にすると、バッチサイズ8以上で顕著な低下を示します。

1つのベースモデルから複数のLoRAアダプターをサービングできますか？

両エンジンともマルチLoRAサービングをサポートしています。SGLangはこれをネイティブ機能として扱い、同じリクエストバッチ内の異なるアダプター間でのバッチ処理を行います。vLLMもサポートしていますが、アダプター数が多い場合、SGLangのスケジューリングの方が効率的です。

分離型プリフィル/デコードサービングとは何ですか？

プリフィルフェーズ（プロンプトの処理）とデコードフェーズ（トークンの生成）を別々のGPUワーカーで実行することを意味します。プリフィルは計算バウンド、デコードはメモリバウンドです。分離することで、それぞれを独立してスケールさせることができます。両エンジンともこれをサポートしており、SGLangはより多くの本番結果を発表しています。

TGIからvLLMまたはSGLangへ移行するにはどうすればよいですか？

3つすべてがOpenAI互換APIを公開しているため、移行は主にコンテナの交換です。Docker ComposeまたはKubernetesデプロイメントを新しいイメージに向け、モデル読み込みフラグを調整し、ヘルスチェックエンドポイントを更新します。クライアントコードはそのままです。

RAGパイプラインにはvLLMとSGLangのどちらを使用すべきですか？

RAGにはSGLangがより強力な選択肢です。そのRadixAttentionは、RAGパイプラインが繰り返し送信する長いシステムプロンプトやドキュメントコンテキストを自動的にキャッシュおよび再利用します。vLLMのブロックレベルキャッシングも動作しますが、リクエスト間でドキュメントチャンクがわずかに異なる場合、SGLangのトークンレベルアプローチの方がキャッシュヒット率が高くなります。

最終結論

SGLangはより多くのカテゴリで勝利していますが、vLLMの利点であるハードウェアの広範さとエコシステムの成熟度は、ノードがダウンした午前3時に重要な要素となります。

NVIDIAハードウェアを使用しており、ワークロードにマルチターン会話、構造化出力を持つエージェント、または共有プレフィックスを持つRAGパイプラインが含まれる場合は、SGLangから始めてください。重要な場所でより良いスループットと低いレイテンシを得られます。

マルチクラウドの柔軟性、NVIDIA以外のハードウェアサポート、または最大のオープンソースLLMサービングコミュニティの安心感を必要とする場合は、vLLMから始めてください。これはほとんどのチームによく適合する安全なデフォルトです。

どちらにしても、両エンジンは優れており、急速に進化しています。一つを選び、デプロイし、実際のワークロードを測定し、数値が示唆するなら切り替えてください。OpenAI互換APIにより、その切り替えは苦痛ではありません。

ソース

• Spheron H100ベンチマーク：vLLM vs TensorRT-LLM vs SGLang
• PremAI：vLLM vs SGLang vs LMDeployベンチマーク
• SqueezeBits：vLLMとSGLangでのガイド付きデコーディングパフォーマンス
• RunPod：SGLang vs vLLM KVキャッシュ再利用
• SGLang公式ドキュメント
• vLLM公式ドキュメント