重要なポイント
- 無料・Apache 2.0ライセンスのオープンソースで、UC Berkeley、スタンフォード、LMSYSに関連する研究から誕生
- RadixAttentionは、リクエストごとのキャッシュ分離ではなくradixツリーを使って、プレフィックスを共有するリクエスト間でKVキャッシュエントリを自動的に再利用する
- 構造化出力(JSONスキーマと正規表現制約)は、事後処理フィルターではなく圧縮有限状態機械を介してデコード中に強制される
- 複数呼び出しLLMプログラムを書くためのPython埋め込み型フロントエンドDSL(
sgl.gen、sgl.select、sgl.fork)を搭載 python -m sglang.launch_serverで起動する組み込みOpenAI互換APIサーバー- 継続的バッチング、テンソル並列、FP8・INT4・AWQ・GPTQを含む量子化フォーマットに対応
- 主要かつ最もサポートされたハードウェアはNVIDIA GPU。プロジェクトはAMD、Intelなど他のアクセラレーターバックエンドも文書化しているが実際のカバレッジは狭い
- 単一ユーザー向けデスクトップアプリではない — グラフィカルインストーラーはなく、llama.cppやOllamaのようにCPU専用やApple Silicon向けに設計されているわけでもない
📍 一文で説明
SGLangは、UC Berkeley、スタンフォード、LMSYSに関連する研究から生まれた、LLMおよびビジョン言語モデル向けの無料・Apache 2.0ライセンスのサービングフレームワークで、RadixAttentionにより共通プレフィックスを共有するリクエスト間でKVキャッシュ状態を自動的に再利用し、デコードループ内で構造化出力を強制する。
💬 簡潔に説明
デスクトップチャットアプリではなく、SGLangは同時に2つのことを行うサーバーソフトウェアだ。システムプロンプトや会話履歴を繰り返すものを中心に多数の同時リクエストを効率的に処理することと、モデルの出力が指定したJSONスキーマやパターンに実際に一致することを保証することだ。
📌補足: この記事はSGLangの公式GitHubリポジトリと公開ドキュメントに基づいており、独自のベンチマークによるものではない。SGLang自身の資料は特定のリリースベンチマークでRadixAttentionとJSONデコードの具体的な高速化倍率を挙げているが、それらはワークロード、ハードウェア、テストされたバージョンに依存するため、この記事では普遍的な数値として繰り返さない。SGLangとvLLMはいずれも自らに有利なベンチマークを公開している。
SGLangとは何か
SGLangは、大規模言語モデルとビジョン言語モデル向けの無料・Apache 2.0ライセンスのサービングフレームワークである。UC Berkeley、スタンフォード、Chatbot Arenaを運営する同じコミュニティであるLMSYS組織に関連する研究から生まれ、現在はGitHub組織sgl-projectのもとで開発されている。ローカルでモデルとチャットする単一ユーザー向けに主に構築されたツールとは異なり、SGLangは重なり合う2つの課題をターゲットにしている。多数の同時リクエストを効率的に処理すること、そしてモデルの出力がJSONのような構造化フォーマットに準拠することを保証することで、これはファンクションコーリング、エージェントパイプライン、その他機械が消費する出力にとって重要である。
- UC Berkeley、スタンフォード、LMSYSに関連する研究から誕生し、現在は
sgl-projectオープンソース組織のもとで開発 - Apache 2.0ライセンス:ソースコードはライセンス条項のもとで利用、改変、再配布のために公開されている
- 複数呼び出しLLMプログラムを書くためのPython埋め込み型フロントエンドDSLと、共に設計されたバックエンドランタイム(SGLang Runtime、しばしばSRTと略される)を組み合わせている
- Hugging Face Transformers互換のモデルチェックポイントを読み込み、Llama、Qwen、Mistral、DeepSeekなどのモデルファミリーをほとんどのモデルで別途変換ステップなしにカバー
- 毎日大量のトークンを生成する本番環境デプロイを文書化しており、独自資料の中で複数の企業や研究機関を採用者として挙げている
RadixAttentionとは何で、なぜ重要なのか
RadixAttentionは、SGLangが最もよく知られているメモリ管理技術である。実際の多くのLLMワークロードは、共通のプレフィックスを共有する複数の生成呼び出しを発行する — すべてのリクエストで同じシステムプロンプト、同じFew-shot例、あるいは進行中の会話の以前のターンなどである。この共有プレフィックスのアテンションキー・バリュー(KV)キャッシュを呼び出しごとに再計算するのは、GPUの計算とメモリの無駄になる。RadixAttentionは代わりに、完了済みおよび実行中のリクエストの両方のKVキャッシュエントリを、トークンシーケンスでインデックス付けされたツリー構造であるradixツリーに格納する。これにより、新しいリクエストは以前のリクエストと共有する任意のプレフィックスのキャッシュを自動的に見つけて再利用でき、開発者がその再利用を手動で追跡・管理する必要がない。
- radixツリーというデータ構造を使い、トークンシーケンスのプレフィックスを共有するリクエスト間でKVキャッシュエントリを自動的にマッチングし再利用する
- 繰り返されるシステムプロンプト、共有されるFew-shot例、複数ターンの会話履歴からのプレフィックスをカバーする — 単に一字一句繰り返される同一リクエストだけではない
- radixツリーにLRU(最も使われていないものから)排出ポリシーを適用し、ツリーが成長するにつれてキャッシュメモリを回収・再利用できるようにする
- 継続的バッチングやページ化されたブロック単位のKVキャッシュ割り当てと連携し、SGLangが実行中のバッチにリクエストを到着・完了に応じて追加・削除できるようにする
フロントエンドDSLと構造化出力は実際に何をするのか
SGLangは中核のサービングに加えて、関連はしているが別個の2つの機能を備えている。LLMプログラムを書くためのPython埋め込み型フロントエンド言語と、エンジンレベルでの構造化出力フォーマットの強制である。
SGLangに必要なハードウェアは何か
SGLangの主要かつ最もサポートされたターゲットはNVIDIA GPUであり、プロジェクト自身の資料に記載された本番デプロイの大半はNVIDIAハードウェア上で稼働している。プロジェクトは追加のバックエンドも文書化しているが、カバレッジと実際の採用状況はすべてで同じではない。
NVIDIA GPU(CUDA)
- 詳細:
- データセンター向けGPUから最近のコンシューマー/ワークステーション向けカードまで、主要かつ最も成熟したターゲット。複数のNVIDIA GPUにわたるテンソル並列サービングは十分に文書化されている。
AMD GPU(ROCm)
- 詳細:
- ROCm経由でAMD Instinctクラスのアクセラレーター向けにサポートされるバックエンドとして文書化されているが、実際の採用とコミュニティのカバレッジはCUDA経路より狭い。
Intel Xeon CPUとGaudiアクセラレーター
- 詳細:
- プロジェクトがIntelハードウェア向けに文書化する追加のバックエンド。NVIDIA GPUよりも小規模で実績の少ないデプロイ経路として扱うべき。
Google TPUとAscend NPU
- 詳細:
- Google Cloud TPUやHuawei Ascendインフラをすでに利用しているチーム向けに文書化されたバックエンド。
Apple Silicon(Mac)
- 詳細:
- 公式に維持されるファーストクラスの経路ではない。SGLangはGPUベースのデータセンターおよびワークステーション向けハードウェアを中心に構築されており、単一Macでのローカル利用向けではない。
単一のMacやCPU専用マシンでモデルを実行することが目的なら、SGLangはそのために作られたツールではない — llama.cppや、それを基盤とするOllama、LM StudioなどのツールはCPUとApple Siliconのハードウェアを直接ターゲットにしており、そのシナリオにはより適している。
SGLangはどの量子化フォーマットに対応しているか
SGLangは、メモリ使用量を減らし、多くの場合スループットを向上させるために、数値精度を落としたモデルのサービングに対応しており、いくつかの確立された量子化フォーマットを文書化している。
FP8
- 詳細:
- ハードウェアFP8サポートを持つNVIDIA GPU世代でサポートされる8ビット浮動小数点精度で、FP16/BF16より低いメモリ使用量と高速な実行を引き換えに、精度をいくらか犠牲にする。
FP4
- 詳細:
- それをサポートする最新世代のNVIDIAハードウェア向けにプロジェクトが文書化している、より新しく精度がさらに低い浮動小数点フォーマット。
AWQ
- 詳細:
- Activation-aware Weight Quantizationの略で、広く使われている4ビットの重み量子化手法。Hugging Faceでコミュニティが公開する事前量子化済みモデルがある。
GPTQ
- 詳細:
- 一般に事前量子化済みチェックポイントとして配布される学習後量子化手法で、こちらも通常4ビット精度で実行される。
INT4
- 詳細:
- AWQやGPTQと並んでプロジェクトが文書化している、さらなるメモリ削減のための精度がより低い整数量子化経路。
この記事には各フォーマットについて独立に測定された品質低下の数値は含まれていない — これらはモデルアーキテクチャとタスクによって異なるため、自分のプロンプトでいくつかのフォーマットの出力を比較することが、自分のワークロードにとってのトレードオフを判断する最も信頼できる方法である。
SGLangのOpenAI互換サーバーは何を提供するか
python -m sglang.launch_serverを実行すると、OpenAI APIプロトコルを実装したHTTPサーバーが起動する。そのため、すでにOpenAI API向けに構築されたアプリケーションやSDKは、多くの場合、ベースURLとモデル名の変更だけで自己ホストのSGLangインスタンスを指すようにできる。
- OpenAI API向けのクライアントコードをそのまま置き換えられる、OpenAI互換のチャット補完(chat completions)および補完(completions)エンドポイント
- 設定可能なホストとポート(プロジェクト自身の例では一般に
http://localhost:30000) - JSONスキーマ制約や正規表現制約付き生成のための、APIで公開されるリクエストレベルの構造化出力パラメーター
- サーバー起動時に設定する、テンソル並列サイズ、メモリ割り当て、量子化フォーマット向けのエンジンフラグ
- 読み込んだ単一のベースモデルに対して複数のLoRAアダプターをサービングするサポート
SGLangのインストールと実行方法は
SGLangはPythonパッケージとして配布されており、通常はNVIDIA GPUと互換性のあるCUDAドライバーが利用可能なPython環境にインストールする。
- 1対応するNVIDIA GPUと最新のCUDAドライバーがインストールされていることを確認する(これらのバックエンドのいずれかを対象とする場合は、プロジェクトのドキュメントでAMD/Intel/TPU固有のインストール手順を確認する)。
- 2Python仮想環境を作成し、SGLangをインストールする。例:`pip install "sglang[all]"`。
- 3Hugging FaceのモデルでOpenAI互換サーバーを起動する。例:
python -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 127.0.0.1 --port 30000。 - 4任意のOpenAI API互換クライアント(例:
base_url="http://127.0.0.1:30000/v1"を指すPythonのopenaiパッケージ)で基本的なチャットリクエストを送信する。 - 5JSON制約付きの応答を得るには、リクエストの構造化出力パラメーターにJSONスキーマを渡す。これにより、プロンプトで単にJSONを要求するのではなく、サーバーがデコード中にスキーマを強制する。
- 6マルチGPUサービングには、テンソル並列フラグを追加する。例:モデルを2つのGPUに分割する
--tp-size 2。 - 7ベースURLとモデル名だけを変更して、既存のOpenAI APIクライアントコードを自己ホストサーバーに向ける。
SGLangの実行にGPUは必要か?
テスト以上の用途では必要である — SGLangの主要かつ最もサポートされたターゲットはNVIDIA GPUである。プロジェクトは他のアクセラレーターバックエンドも文書化しているが、それらは主要なデプロイ経路ではない。
SGLangから保証されたJSON出力を得られるか?
得られる — リクエストの構造化出力パラメーターにJSONスキーマを渡すと、SGLangはデコード中にスキーマに違反するトークンをマスクすることでそれを強制する。プロンプト内でモデルにJSONの生成を求めるだけではこの保証は得られない。
SGLangはvLLMと比べてどうか
SGLangとvLLMは、GPUベースのオープンソースLLMサービングエンジンとして最も広く議論されている2つであり、いずれもApache 2.0ライセンスで、単一ユーザー向けデスクトップチャットではなく本番の複数ユーザー向けサービングをターゲットにしている。両プロジェクトとも互いに有利になるベンチマークを公開しており、この記事はその比較に決着をつけるのではなく、それぞれのプロジェクトが文書化している設計と主張を説明する。
中心的なキャッシュ技術
- SGLang:
- RadixAttention — 任意の共通プレフィックスを共有するリクエスト間での、radixツリーベースの自動KVキャッシュ再利用。
- vLLM:
- PagedAttention — 過剰予約された割り当てによるメモリ無駄を削減する、ページサイズの非連続KVキャッシュブロック。
構造化出力
- SGLang:
- エンジンレベルのJSONスキーマと正規表現の強制は、圧縮有限状態機械の上に構築された中核的で十分に文書化された機能である。
- vLLM:
- 統合されたグラマーバックエンドを介した構造化/ガイド付きデコードにも対応しているが、目玉機能というよりは広範な機能セットの一部として文書化されている。
プログラミングモデル
- SGLang:
- APIサーバーに加えて、複数呼び出しLLMプログラム向けのPython埋め込み型フロントエンドDSL(
sgl.gen、sgl.select、sgl.fork)を搭載している。 - vLLM:
- 主にAPIサーバーまたはPythonライブラリ呼び出しとしてアクセスされる。同等のプログラム作成用DSLは搭載していない。
起源
- SGLang:
- UC Berkeley、スタンフォード、Chatbot Arenaを運営するLMSYS組織に関連する研究。
- vLLM:
- UC BerkeleyのSky Computing Labで誕生。
スループットの主張
- SGLang:
- 特定のワークロードにおけるRadixAttentionとJSONデコードの倍率を引用するリリースベンチマークを公開。
- vLLM:
- 独自のリリースベンチマークを公開。単一の普遍的な速度指標ではなく、PagedAttentionのメモリ効率の根拠を説明している。
どちらのエンジンのマーケティングベンチマークも中立的な評決として受け取るべきではない — いずれも、そのプロジェクトが選んだワークロードで、より有利に見える結果を出したプロジェクト自身によるものである。スループットが意思決定において重要なら、自分自身のモデル、ハードウェア、トラフィックパターンで両エンジンをテストする方が、この記事を含むどの記事の数値よりも信頼できる。
SGLangはllama.cppやTensorRT-LLMと比べてどうか
SGLang、llama.cpp、TensorRT-LLMは、ハードウェアの柔軟性とピーク最適化のスペクトル上で異なる位置にある。
SGLang
- 詳細:
- Apache 2.0ライセンス、Pythonベースで、RadixAttentionとエンジンレベルの構造化出力を中心に構築されている。Hugging Face Transformers互換モデルを直接読み込む。NVIDIA GPUが主要ターゲットで、追加のバックエンドも文書化されている。
llama.cpp
- 詳細:
- MITライセンスのC/C++推論エンジンで、GGUFモデルフォーマットを中心に構築されており、CPU、Apple Silicon、GPUで動作する。マルチGPUの本番クラスターよりも、単一マシンやエッジ展開をターゲットにしている。
TensorRT-LLM
- 詳細:
- NVIDIA GPU専用に構築されたNVIDIAのエンジン。モデルは対象GPU向けに最適化されたTensorRTエンジンへ事前にコンパイルされ、その特定のハードウェア上で高い性能を発揮しうるが、コンパイルステップとSGLangより低いハードウェア間の柔軟性という代償を伴う。
この記事はこれら3つのエンジンを互いに独立してベンチマークしておらず、いずれかが普遍的に速いとは主張していない — スループットはモデル、ハードウェア、バッチの特性、各エンジンのバージョンに大きく依存する。vLLM、TGI、NVIDIA NIMもカバーする展開重視の比較については、エンタープライズ推論サーバーガイドを参照。
SGLangはどんな人に向いているか
SGLangは、GPUインフラ上で多数の同時ユーザーやアプリケーションにモデルをサービングするチーム、特に繰り返されるプロンプトプレフィックスや構造化出力への厳格な要件があるワークロードに向いている。自分のコンピューターでモデルと最速でチャットする方法を探している人向けではない。
SGLangと代替ツールの一覧比較
これらのツールは、単一ユーザー向けと本番サービング向けのスペクトル、およびスループット重視と構造化出力重視のスペクトルの異なる位置にある。
SGLang
- インターフェースとセットアップ:
- Pythonパッケージ。
python -m sglang.launch_serverで起動するOpenAI互換APIサーバー。ほとんどのデプロイでNVIDIA GPUとCUDAを前提とする。 - 最適な用途:
- プレフィックスの再利用が多い、および/または構造化(JSON/正規表現)出力への厳格な要件がある、高並行性のGPUサービング。
vLLM
- インターフェースとセットアップ:
- Pythonパッケージ。
vllm serveで起動するOpenAI互換APIサーバー。ほとんどのデプロイでNVIDIA GPUとCUDAを前提とする。 - 最適な用途:
- 構造化出力優先の設計に特化していない、本番環境での一般的な高スループット・複数ユーザー向けGPUサービング。
Ollama
- インターフェースとセットアップ:
- CLIとREST API。ほとんどのプラットフォームでllama.cppをバックエンドとして動作すると一般に報告されている。1つのコマンドでインストールし、1つのコマンドでモデルを取得・実行できる。
- 最適な用途:
- ビルドステップやGPUを必要とせず、単一ユーザー向けにローカルモデルを最速で動かす方法。
llama.cpp
- インターフェースとセットアップ:
- CLI、組み込みWeb UI、llama-server経由のOpenAI互換API。ソースからビルドするか、ビルド済みバイナリを使用する。CPUまたはGPUで動作する。
- 最適な用途:
- エンジンレベルでの直接的な制御、組み込み/エッジ展開、CPUまたはApple Siliconハードウェア。
この記事はこれらのツール間の速度や出力品質を独立にベンチマークしておらず、どれかが技術的に優れていると主張していない — 上記の比較は、文書化されたアーキテクチャ、セットアップ、アクセスモデルの事実のみを扱う。この3つの間のスループットとセットアップの複雑さに特化した比較についてはllama.cpp vs. Ollama vs. vLLM比較を、vLLM、TGI、NVIDIA NIMを展開の観点から見るにはエンタープライズ推論サーバーガイドを参照。
この記事がカバーしていないこと
これはSGLangの公開ドキュメントとリポジトリから構築された解説記事であり、実践的なベンチマークレポートではない。
- SGLangやその比較についての、独立に測定されたスループット、レイテンシ、秒間リクエスト数の数値はない — これらはGPU、モデル、バッチ構成、バージョンに大きく依存する
- RadixAttentionやJSONデコードについてSGLang自身が主張する高速化倍率の独立した検証はない — これらはプロジェクトのリリースベンチマークによるものであり、第三者による測定ではない
- SGLangのコードベースの行単位のセキュリティ監査はない — オープンソースでApache 2.0ライセンスなので、コード自体はレビュー可能である
- サポートされるすべてのハードウェアバックエンド、エンジンフラグ、デプロイオーケストレーションオプション(Kubernetes、クラウド固有のセットアップ)の完全な網羅はない — この記事はほとんどのチームが最初に評価する概念とフラグに焦点を当てている
- SGLang自体がサポート契約を持つベンダー製品ではなくコミュニティのオープンソースプロジェクトであるため、商用サポート契約やマネージドSGLangホスティングサービスのカバーはない
SGLangを試す際によくある間違い
SGLangに関するほとんどの摩擦は、それを単一ユーザー向けデスクトップツールのように扱うこと、あるいはプレフィックスを実際には共有していないワークロードにRadixAttentionが役立つと期待することから生じる。
よくある質問
SGLangとは何ですか?
SGLangは、UC Berkeley、スタンフォード、Chatbot Arenaを運営するLMSYS組織に関連する研究から生まれた、大規模言語モデルとビジョン言語モデル向けの無料・Apache 2.0ライセンスのサービングフレームワークです。共通のプレフィックスを共有するリクエスト間でKVキャッシュを自動的に再利用する技術であるRadixAttentionで最もよく知られています。
SGLangは無料ですか?
はい。SGLangはApache 2.0ライセンスの下でリリースされた無料のオープンソースソフトウェアで、自分で実行するのにサブスクリプションやアカウントは不要です。
RadixAttentionとは何ですか?
RadixAttentionは、完了済みおよび実行中のリクエストのアテンションKVキャッシュをradixツリーに格納するSGLangの技術です。これにより、システムプロンプト、Few-shot例、以前の会話ターンなどトークンシーケンスのプレフィックスを共有する新しいリクエストが、再計算する代わりに一致するキャッシュを自動的に再利用できます。
SGLangは有効なJSON出力を保証しますか?
リクエストにSGLangの構造化出力パラメーターでJSONスキーマが含まれる場合、エンジンは各デコードステップでスキーマに違反するトークンをマスクします。これにより、事後検証ではなく構造上、出力がスキーマに準拠するよう設計されています。これらのパラメーターを使わずプロンプトテキストで単にJSONを求めるだけでは、この保証は得られません。
SGLangにGPUは必要ですか?
実際のワークロードには必要です — SGLangの主要かつ最もサポートされたターゲットはNVIDIA GPUです。プロジェクトはAMD、Intel、その他のアクセラレーターバックエンドも文書化していますが、これらは主要なデプロイ経路ではなく、ファーストクラスのApple Siliconサポートもありません。
SGLangはどの量子化フォーマットに対応していますか?
SGLangは、新しいハードウェア向けのFP8、FP4、AWQ、GPTQ、INT4を含む複数のフォーマットに対応しており、これらのフォーマットの事前量子化済みモデルの多くがHugging Faceで公開されています。
SGLangはvLLMより優れていますか?
どちらのプロジェクトの独自ベンチマークもこの点について中立な評決とは言えません — 両者とも自らに有利な結果を公開しています。SGLangはRadixAttentionのプレフィックスベースのキャッシュ再利用とエンジンレベルの構造化出力を主要な機能として強調し、vLLMはPagedAttentionのメモリ効率を強調しています。どちらがより適しているかは、ワークロードのプレフィックス共有パターンと構造化出力が厳格な要件かどうかによります — 上記の比較表を参照してください。
SGLangにはOpenAI互換のAPIがありますか?
あります。python -m sglang.launch_serverを実行するとOpenAI APIプロトコルを実装したサーバーが起動するため、OpenAI API向けに構築された多くのアプリケーションは、ベースURLとモデル名だけを変更して自己ホストのSGLangインスタンスを指すことができます。
SGLangのフロントエンドDSLは何に使われますか?
これは、複数ステップのLLMプログラム(例えば複数の並列サブ生成に分岐して結果をマージするなど)を、個別のAPI呼び出しを手動でオーケストレーションするのではなく通常のPythonコードとして書くための、sgl.gen、sgl.select、sgl.forkなどを含む一連のPythonプリミティブです。
SGLangは誰が作ったのか、RadixArkとは何か?
SGLangはUC Berkeley、Stanford、そしてChatbot Arenaを運営するLMSYS組織を結ぶ研究から生まれました。2026年、SGLangの共同開発者であるYing ShengとBanghua ZhuがAIインフラ企業RadixArkを設立し、Accelが主導するシード資金1億ドルを調達してSGLang関連サービスの商業化を進めています。中核となるフレームワーク自体は引き続きApache 2.0ライセンスの無料ソフトウェアです。