SGLangとvLLMの比較：性能と使い分け

この記事では、ローカルAI向けに広く使われている2つの推論エンジン、SGLangとvLLMを比較します。セットアップの容易さ、性能、モデル形式のサポートなどを見ていきます。

SGLang vs vLLM：比較早見表

まず、各プラットフォームの基本情報を確認しましょう。

SGLangとは

SGLangは、大規模言語モデル（LLM）の配信とプログラミングのためのオープンソース推論フレームワークです。UC BerkeleyのSky Computing Labで生まれ、LMSYSがホストしており、2025年にPyTorchエコシステムに加わりました。

SGLangは、チャットアプリケーション、コーディングエージェント、その他のエージェントベースのシステムなど、本番環境でLLMを配信するワークロード向けに設計されています。Grokなどのモデル配信を含む大規模な環境で使われており、導入規模は数十万基のGPUに達しています。

‍

SGLangの設計上の主要な目標は、リクエスト間で似たプロンプトを送信するアプリケーションにおいて、繰り返し発生する計算を減らすことです。たとえば、コーディングエージェントは、同じシステム指示、ツール定義、会話コンテキストを繰り返し送信することがよくあります。SGLangはRadixAttentionを使い、繰り返されるプレフィックスのアテンション状態をキャッシュして再利用することで、重複するプリフィル計算を減らします。

RadixAttentionに加え、SGLangには次の機能があります。

• スケジューリングのオーバーヘッドを減らし、リソース使用率を高めるCPUベースのスケジューリング。
• プロンプト処理とトークン生成を異なるGPUリソースに分けるプリフィルとデコードの分離。
• 生成スループットを高める投機的デコーディング。現行リリースではV2にも対応しています。
• xgrammarエンジンによる構造化出力の生成。
• Kimi K3、GLM-5.1、Qwen3.6などのモデル向けに最適化されたカーネルや連携機能を含む、新しくリリースされたモデルへの対応。

vLLMとは

vLLMは、大規模言語モデル向けのオープンソースの推論・配信エンジンです。UC Berkeleyで開発され、LLMの配信で広く使われるようになった2つの技術、PagedAttentionと継続的バッチ処理を導入しました。

• PagedAttentionは、アテンションキャッシュをより効率的に構成することで、メモリ管理を改善します。
• 継続的バッチ処理により、サーバーは固定されたバッチを処理する代わりに、リクエストを動的にまとめて処理できます。

これらの技術を組み合わせることで、共有GPUリソース上で複数のユーザーにモデルを提供する際の効率が向上しました。

vLLMは、LLMエコシステム全体で広くサポートされています。普及率の高さとモデルリポジトリとの連携により、多くの新しいモデルアーキテクチャは、リリース準備の段階でvLLMを使ったテストが行われています。

関連記事：OllamaとvLLMの比較。

‍

最近のvLLMリリースでは、新しいGPUアーキテクチャでスループットを改善するModel Runner V2や、EAGLE 3.1による投機的デコーディングなど、性能とスケーリングに関する機能が追加されています。

投機的デコーディングについて詳しく解説しています。

次の観点で2つのプラットフォームを比較しましょう。

• モデル形式
• ハードウェアのサポート
• 同時リクエストの処理方法
• それによって生じる性能差

モデル形式と量子化

SGLangとvLLMは、基本的に同じモデル形式を使用します。safetensors形式の標準的なHugging Faceチェックポイントは、通常、どちらのエンジンでも変換せずに読み込めます。

両エンジンは、次のような一般的な数値精度形式と量子化手法をサポートしています。

• FP16
• BF16
• FP8
• AWQ
• GPTQ

GGUFは例外です。サーバー向けの推論エンジンよりも、主にllama.cppベースのランタイムやローカル推論のワークフロー向けに設計されているため、一般にSGLangとvLLMはGGUFモデルに適したランタイムの第一候補にはなりません。

ハードウェアとオペレーティングシステムのサポート

SGLangとvLLMは、どちらも主にLinuxシステムで使用されています。Windowsへのデプロイは、通常、WSL2やDockerなどの互換レイヤーを通じて行われます。

同時リクエストの処理

要するに、SGLangは同時リクエストの処理により高性能な仕組みを使っており、その結果、わずかから中程度の性能上の優位性があります。

SGLang

SGLangは、基数木を使ったプレフィックスキャッシュの仕組みであるRadixAttentionによって、同時に実行する推論の効率を高めます。

この構造では、木の各ノードがトークン列のプレフィックスを表し、GPUメモリに保存された対応するKVキャッシュブロックにマッピングされます。新しいリクエストが届くと、SGLangは木に対して最長プレフィックス一致検索を行います。すでにキャッシュにあるトークンはプリフィル計算を省略でき、プロンプトの新しい部分だけを処理すれば済みます。

スケジューラーは、プレフィックスを共有するリクエストをグループ化することで、単純な到着順のスケジューリングよりも、類似したキャッシュエントリが頻繁に再利用されるようにします。

この設計には、実用上、次のような特徴があります。

• 主な利点はプリフィルのコスト削減です。キャッシュにヒットすると、繰り返されるプロンプトのトークンを再計算する必要がないため、最初のトークンが出力されるまでの時間が短くなります。生成開始後のデコード性能は、通常は変わりません。
• KVキャッシュは、処理中のリクエストとGPUメモリを共有します。キャッシュされたブロックと実行中のシーケンスは、--mem-fraction-staticで設定された同じメモリプールを取り合います。メモリの逼迫度が高まると、LRUベースのポリシーに従って古いキャッシュエントリが削除されます。
• 効果はプレフィックスの再利用状況によって異なります。同一のシステムプロンプトやツール定義を繰り返し送るエージェントなど、プレフィックスが繰り返されるワークロードでは大きな効果が得られます。プレフィックスの重複がほとんどない、またはまったくないリクエストでは、キャッシュ管理のオーバーヘッドが発生する一方で、得られる効果は限られます。キャッシュはプロセス内に保持されるため、サーバーを再起動するとキャッシュエントリは消去されます。

vLLM

vLLMは、PagedAttentionと継続的バッチ処理によって、同時に実行する推論の効率を高めます。

PagedAttentionは、リクエストごとに連続したバッファーを割り当てる代わりに、固定サイズのメモリページを使ってKVキャッシュを管理します。これによりメモリの断片化が減り、利用可能なGPUメモリ内に、より多くの処理中のシーケンスを保持できます。

継続的バッチ処理では、先行するシーケンスが完了するたびに新しいリクエストを動的に追加して、リクエストをスケジューリングします。完了したシーケンスは割り当てられたページを解放し、待機中のリクエストは、固定されたバッチ全体の完了を待たずに次の実行サイクルへ入れます。これにより、同時リクエスト数が増えてもGPUリソースの使用率を高く保てます。

vLLMには、リクエスト間で同一のKVキャッシュブロックを識別して再利用する自動プレフィックスキャッシュもあります。プロンプトのプレフィックスが繰り返されるワークロードでは、SGLangのRadixAttentionと同様の利点が得られますが、両者は照合とスケジューリングの戦略が異なります。

vLLMのプレフィックスキャッシュはページ単位で動作する一方、SGLangのRadixAttentionはプレフィックスの照合に基数木構造を使い、共有プレフィックスに基づいてリクエストをスケジューリングできます。こうした違いは、ワークロードによって性能に影響することがあり、特にエージェントシステムのように長いプロンプトを繰り返し使うアプリケーションで影響が出ます。

SGLang vs vLLM：性能ベンチマーク

性能面でSGLangとvLLMのどちらが優位なのかを見ていきましょう。

次の2つのシナリオを比較します。

• すべてのプロンプトがそれぞれ異なる場合に、各ソフトウェアがどう処理するか
• プロンプト間で、システムプロンプトなどの繰り返される内容を多く共有する場合に、各ソフトウェアがどう処理するか

プロンプトがそれぞれ異なる場合のスループット

第三者によるH100ベンチマークでは、SGLangとvLLMでLlama 3.3 70B InstructをFP8で配信し、50件の同時リクエストと、それぞれ異なるプロンプトを使って比較しました。

プロンプトがそれぞれ異なるワークロードでは、両エンジンは同程度の性能を示しました。より大きな差が現れるのは、複数ターンのチャットやエージェントシステムなど、プレフィックスが繰り返されるワークロードです。

プレフィックスの共有が多いワークロードとエージェントのワークロード

プロンプトのプレフィックスが繰り返されるワークロードでは、KVキャッシュの再利用による効果がより大きくなります。これには、同じシステムプロンプト、ツール定義、会話コンテキストを繰り返し送信するエージェントシステムが含まれます。

プレフィックスの再利用率が高いベンチマークでは、SGLangはvLLMよりも高いスループットと、最初のトークンが出力されるまでの短い待ち時間を示しました。

プロンプトがそれぞれ異なるワークロードと比べて差が大きいのは、プレフィックスキャッシュの挙動によるものです。リクエスト間で長いプロンプトプレフィックスを共有する場合、SGLangのRadixAttentionは、以前に計算したKVキャッシュの状態をより多く再利用できます。

SGLangとvLLMを使い分ける場面

各プラットフォームの概要、機能、強みを理解したところで、どのような場面でどちらを選ぶとよいかを考えましょう。vLLMとSGLangの選択では、多くの場合、リクエスト間でプロンプトの内容がどれだけ繰り返されるかが決め手になります。

SGLangを選ぶとよい場合：

• リクエスト間で長いプレフィックスを共有する場合。エージェントのワークロード、複数ターンの会話、システムプロンプトやツール定義を繰り返し使うアプリケーションは、RadixAttentionによるプレフィックスキャッシュの恩恵を受けられます。
• 高スループットの構造化出力が必要な場合。SGLangには、xgrammarエンジンを通じた制約付き生成に最適化されたサポートがあります。
• AMD GPUを使用する場合。SGLangは、対応ハードウェア構成の一部としてAMDをサポートしています。
• 使用するモデルにSGLang専用の最適化がある場合。最近リリースされたモデルの中には、SGLang向けに最適化されたカスタムカーネルや連携機能を含むものがあります。

プレフィックスをほとんど再利用しない、またはまったく再利用しないワークロードでは、SGLangの優位性は小さくなります。このような場合、プレフィックスキャッシュの性能への寄与は小さくなりますが、キャッシュ管理用のメモリは引き続き必要です。

vLLMを選ぶとよい場合：

• リクエストのプロンプトがほとんどの場合、それぞれ異なる場合。バッチ推論、評価ワークロード、データ生成では、プレフィックスの重複が限られることがよくあります。
• 幅広いモデルやハードウェアとの互換性が必要な場合。vLLMは、幅広いモデルアーキテクチャ、量子化形式、アクセラレーターバックエンドをサポートしています。
• 分散環境で運用する場合。vLLMは、Rayベースのデプロイワークフローを含め、複数GPUと複数ノードでのモデル配信をサポートしています。
• 既存の連携機能に依存している場合。多くのLLMツールやプラットフォームは、モデル配信バックエンドとしてvLLMをサポートしています。

SGLangとvLLMに代わるデスクトップ向けの選択肢：Atomic Chat

SGLangとvLLMは、本番環境へのモデルのデプロイを目的として設計された推論サーバーです。個人利用や、MacまたはWindows PCでAIモデルをローカル実行することは想定されていません。このような用途には、オフラインAIモデルのセットアップと実行を簡単にするために私たちが開発したオープンソースアプリ、Atomic ChatのようなローカルAIアプリが必要です。Atomic Chatには次の機能があります。

• 統合されたモデルカタログを通じて、Hugging FaceからGGUFモデルをダウンロードし、管理します。

‍

• モデルとチャットするためのグラフィカルインターフェースを内蔵しています。

‍

• 大幅に改良したllama.cppベースの推論エンジンに、TurboQuantによるKVキャッシュ圧縮を組み合わせ、一般消費者向けハードウェアで最大限の性能を引き出すための最適化を搭載しています。キャッシュの値を16ビット精度ではなく約3ビット精度で保存することで、KVキャッシュのメモリ使用量を削減します。
• ローカルのOpenAI互換APIを提供し、ツールやエージェントをローカルで動作するAIモデルに簡単に接続できます。

よくある質問

SGLangとvLLMに関するよくある質問に、簡潔に回答します。

SGLangはvLLMより高速ですか？

プロンプトのプレフィックスが繰り返されるワークロードでは、SGLangがvLLMより高速になることがあります。たとえば、ベンチマークでの差は、プロンプトがそれぞれ異なる場合の約4%から、プレフィックスの再利用が多いワークロードでの約29%まで幅がありました。リクエスト間で共有するコンテキストが少ない場合、性能は同程度になることがよくあります。

プレフィックスのヒット率はどのように見積もればよいですか？

繰り返されるプロンプトのトークン数を総入力トークン数で割って、プレフィックスの再利用率を見積もります。プレフィックスのヒット率 = 繰り返されるプレフィックスのトークン数 / プロンプトの総トークン数です。繰り返される部分には通常、リクエストごとに送信するシステムプロンプト、ツール定義、会話履歴が含まれます。

vLLMにはプレフィックスキャッシュがありますか？

はい。vLLMには、リクエスト間で一致するKVキャッシュブロックを識別して再利用する、自動プレフィックスキャッシュがあります。ただし、vLLMのプレフィックスキャッシュはページ単位で動作する一方、SGLangのRadixAttentionは基数木を使い、共有プレフィックスに基づいてリクエストをスケジューリングできます。

SGLangは本番環境で誰に使われていますか？

SGLangは、xAIでのGrokの配信を含む大規模な環境で使われています。

コードを変更せずにSGLangとvLLMを切り替えられますか？

通常は可能です。ほとんどのクライアントアプリケーションでは、サーバーURLを変更するだけで済みます。ただし、デプロイ設定をそのまま移行することはできません。起動オプション、並列化設定、ハードウェア構成、対応する量子化形式は、2つのエンジンで異なります。

まとめ

この記事では、本番環境でAIモデルを実行するために広く使われている2つの推論エンジン、SGLangとvLLMを比較しました。主なポイントは次のとおりです。

• SGLangとvLLMは、AIモデルを配信するための推論エンジンです。どちらも、個人のコンピューターでモデルをローカル実行することより、主にサーバーや本番環境へのデプロイを目的として設計されています。
• SGLangは、コンテキストが繰り返されるワークロード向けに最適化されています。長いシステムプロンプト、ツール定義、会話履歴など、同じ内容をリクエスト間で再利用する場合、vLLMを上回る性能を発揮することがあります。プロンプトがそれぞれ異なる場合、性能差ははるかに小さくなります。
• プロンプトがそれぞれ異なる場合、SGLangとvLLMの性能は同程度です。リクエスト間でプレフィックスを共有しない場合、ベンチマークの差は通常、数パーセント以内です。
• SGLangとvLLMは、サーバー向けの推論エンジンです。一般消費者向けハードウェアでモデルをローカル実行するには、Atomic Chat、Ollama、LM Studioなど、ローカル推論向けに設計されたツールを使ってください。