今回の論文
今回取り上げるのは、Lianmin Zheng、Liangsheng Yin、Zhiqiang Xie らによる論文「SGLang: Efficient Execution of Structured Language Model Programs」です。2023年12月に arXiv で公開された論文で、公開元は arXiv、研究分野は LLM システム、推論基盤、AI エージェント実行基盤です。URL は https://doi.org/10.48550/arXiv.2312.07104 です。
この論文を選んだ理由は、いまのAIアプリ開発で当たり前になっている「1回のプロンプトで終わらない処理」を、どう速く、どう壊れにくく実装するかに正面から取り組んでいるからです。RAG、エージェント、構造化出力、長文処理などを作るとき、モデルそのものより実行基盤の差が効く場面は多いです。SGLang はそこに対して、言語設計とランタイム設計を一体で最適化した点が実務的です。
どんな技術か
SGLang は、LLM を使った複雑なアプリケーションを「書きやすくしながら、同時に速くする」ための技術です。
普通の LLM アプリは、1回の chat.completions 呼び出しで終わるとは限りません。たとえば、途中で検索したり、複数候補を並列に作ったり、JSON 形式で出力させたり、同じ長いコンテキストを何度も使い回したりします。こうした処理は、コードがすぐに複雑になり、しかも同じ prefix を何度も再計算して無駄が出やすいです。
SGLang は、この問題に対して二つの層でアプローチします。ひとつは Python に埋め込める軽量な DSL として、gen、select、fork、join のようなプリミティブを提供することです。もうひとつは、ランタイム側で KV キャッシュ再利用や並列実行を自動化し、複数の LLM 呼び出し全体をまとめて高速化することです。要するに SGLang は、「LLM を呼ぶコード」ではなく「LLM プログラム」を前提にした実行基盤です。
課題
SGLang が解こうとしている課題は、複数回の LLM 呼び出しを含むアプリケーションが、実装面でも性能面でも非効率になりやすいことです。
何が難しいのかというと、エージェント、RAG、自己反省型推論、構造化出力のようなワークフローでは、1つの処理の中に多段の LLM 呼び出しが入り、しかもそれらが条件分岐やループ、外部ツール呼び出しと絡むからです。単純な API 呼び出しを積み上げるだけだと、プロンプト文字列の手作業連結、出力パース、並列実行制御、再利用可能なコンテキスト管理がアプリ側に散らばります。
既存の方法では、二つの限界がありました。ひとつはフロントエンドの限界で、LangChain や Guidance のようなツールを使っても、複数呼び出しの依存関係や制約付き出力を見通しよく記述するのが意外と面倒なことです。もうひとつはバックエンドの限界で、vLLM のような高速推論エンジンも、基本的には「1回の生成リクエスト」を効率化する設計なので、複数呼び出しの間にある共有 prefix や並列性を十分には活かせません。
なぜこの課題を解く必要があるのかというと、実際の AI システムではモデル単体の性能より、ワークフロー全体の待ち時間や運用コストが支配的になることが多いからです。たとえばエージェントでは、思考、行動、観測を毎ターン追記し続けるので、似た prefix を何度も再計算しがちです。RAG では長い文書や複数チャンクをまたいで処理するため、長文 prefix の扱いがボトルネックになります。JSON 出力では、構造の制約を守らせるために出力制御まで必要になります。
つまり SGLang が扱うのは、「モデルをどう賢くするか」ではなく、「モデルを組み合わせたアプリをどう現実的な速度と保守性で動かすか」という課題です。
用語解説
- KVキャッシュ
- Transformer の推論時に、すでに読んだトークンの中間表現を保存して再利用する仕組みです。SGLang の核心は、この KV キャッシュを単一リクエスト内だけでなく、複数の呼び出し間でも使い回すことにあります。
- 共有 prefix
- 複数のプロンプトで先頭部分が共通している状態です。few-shot 例、システムプロンプト、会話履歴、長文コンテキストなどが典型です。SGLang はこの共有部分を自動検出して再計算を避けることで高速化します。
- DSL
- 特定の問題領域に特化した小さな言語です。SGLang は LLM プログラミング専用の DSL を Python に埋め込む形で提供し、通常の Python 構文を使いながら LLM 特有の操作を簡潔に書けるようにしています。
- 制約付きデコーディング
- 生成結果を JSON や選択肢のような決まった形式に制限する推論方法です。SGLang では構造化出力を扱いやすくすることが重視されており、実務上の API 連携や後段処理で重要になります。
- intra-program parallelism
- 1つのアプリ処理の中にある独立した LLM 呼び出しを並列化する考え方です。SGLang の `fork` と `join` はこの並列性を前提にしており、単なるリクエスト並列ではなく、1つのワークフロー内部の並列化をしやすくします。
技術の仕組み
SGLang の仕組みは、「LLM アプリをプログラムとして表現できるフロントエンド」と、「そのプログラム構造を理解して最適化するランタイム」の組み合わせで捉えるとわかりやすいです。
基本アイデア
基本アイデアは、複数の LLM 呼び出しを独立した API リクエストとして扱うのではなく、共有 prefix や依存関係を持つひとまとまりのプログラムとして扱うことです。
通常の実装では、同じ会話履歴や同じ few-shot 例を含むプロンプトを何度も組み立てて、そのたびにモデルへ投げます。SGLang はそこを変えます。プロンプト状態をストリームとして管理し、必要な生成や分岐をプリミティブとして宣言し、ランタイムがその実行順序と共有可能部分を見て自動で最適化します。
フロントエンド言語
SGLang は Python に埋め込まれた DSL です。extend や += でプロンプトを伸ばし、gen で生成し、select で候補から選ばせ、fork で分岐し、join で合流します。画像や動画入力を扱うプリミティブも拡張できます。
重要なのは、これが単なる糖衣構文ではないことです。言語として「この呼び出しは共通 prefix を持つ」「この分岐は並列に解ける」「この出力は制約付きにしたい」といった構造を露出させるので、ランタイムが最適化しやすくなります。論文では、同等の処理を OpenAI API ライクな書き方で実装するより、SGLang のほうがコード量をかなり減らせるケーススタディも示しています。
実行モデル
SGLang には interpreter と compiler の二つの実行モードがあります。基本となる interpreter モードでは、プロンプトを非同期ストリームとして管理し、各プリミティブをバックグラウンドで順次または並列に流していきます。依存関係があるときだけ同期し、それ以外は並列に実行できます。
この設計は GPU カーネルを非同期に積んでいく感覚に近く、Python 側の制御フローを保ちながら、LLM 呼び出しだけを効率よく流せるのが特徴です。さらに compiler モードでは、SGLang プログラムを計算グラフに落として、コード移動や prefetch のような最適化も狙えます。
RadixAttention による KV キャッシュ再利用
SGLang の技術的な中心は RadixAttention です。
LLM の KV キャッシュは、通常は1回の生成が終わるとリクエスト単位で破棄されがちです。しかし、実際のワークフローでは「同じシステムプロンプト」「同じ会話履歴」「同じ長文コンテキスト」を共有する呼び出しが大量にあります。そこで SGLang は、KV キャッシュをリクエストごとに捨てるのではなく、radix tree 上に LRU キャッシュとして保持します。
これにより、同じ prefix を持つ別リクエストが来たときは、共有部分の forward 計算をやり直さずに済みます。few-shot 学習の共通例文、エージェントの過去履歴、RAG の長い文書、分岐した思考候補など、共有パターンが木構造っぽく広がる場面で特に効きます。論文のポイントは、単純な prefix caching ではなく、不規則な共有パターンまで含めて自動処理しようとしていることです。
並列実行の扱い
SGLang は fork と join を言語機能として持ちます。これにより、1つの入力に対して複数候補を同時生成したり、異なる観点の評価を並列に走らせたりできます。
たとえば skeleton-of-thought のように、最初に骨子を出して各セクションを並列展開する処理や、エッセイを複数観点から評価して最後に統合する処理は、このモデルに自然に乗ります。一般的な API 実装でもスレッドや async を使えばできますが、SGLang はそれをアプリ側で細かく書かなくてもよい設計にしています。
長文処理と構造化出力
論文では、長文処理と JSON のような構造化出力も重要なユースケースとして扱っています。
長文処理では、同じ長い文書を何度も読むコストが重いので、共有 prefix の再利用がそのまま効きます。さらに論文では、複数文書を別々に encode して後から KV キャッシュを連結する parallel-context window 的な使い方も示しています。これは通常の「全部を一つの長いプロンプトに詰める」より、長文計算コストを抑えやすい発想です。
構造化出力では、select や制約指定によって、true/false、選択肢、JSON フィールドのような生成を扱いやすくしています。論文中では、複数フィールドを持つ JSON オブジェクトの生成時に、長い prompt の KV キャッシュを再利用しながら各フィールドの生成を進める例も評価されています。
重要な工夫は何か
SGLang の重要な工夫は三つあります。ひとつ目は、LLM ワークフローの構造を DSL で明示したことです。ふたつ目は、その構造情報を使ってランタイムが KV キャッシュ再利用と並列化を自動で行うことです。三つ目は、言語設計と推論基盤を別々にせず、一体で設計していることです。
この三つがそろっているので、SGLang は「書きやすいが遅い抽象化」でも「速いが扱いにくい推論サーバー」でもなく、その中間を狙えています。
実験と結果
SGLang の実験は、単一モデルの精度比較ではなく、複数呼び出しを含む実際の LLM ワークロードでどれだけ throughput と latency を改善できるかを検証しています。比較対象には vLLM、Guidance、LMQL などが置かれています。
何を検証したのか
論文では、few-shot 学習、エージェント、推論、コンテンツ生成、長文処理、マルチモーダル処理まで、かなり広いワークロードで SGLang を評価しています。狙いは、SGLang の最適化が特定タスクにだけ効くのではなく、「複数の LLM 呼び出しを持つ処理」全般で効くかを見ることです。
評価指標は主に throughput と latency です。つまり、何問を毎秒さばけるか、1回の処理にどれだけ時間がかかるかを見ています。これは実務のサービング基盤としてはかなり重要な視点です。
few-shot 学習系の結果
few-shot in-context learning の評価では、MMLU、HellaSwag、GSM-8K のようなベンチマークを使っています。ここでは few-shot 例が共有 prefix になりやすく、KV キャッシュ再利用の効果が大きく出ます。
論文では、SGLang は共有 prefix の自動再利用と batching を組み合わせることで、競合より高い throughput を示しています。特に既存系では、prefix 共有をコード側で明示しないと使えない、あるいは batch size が実質 1 に制約されるといった限界があり、SGLang はそこを自動化している点が効いています。
エージェントと推論タスクの結果
エージェント評価では、ReAct agent と generative agents を題材にしています。ReAct のようなループ型エージェントでは、思考、行動、観測を毎ターン履歴へ追記していくので、prefix の重複が非常に多くなります。論文では、こうした反復型ワークロードで SGLang が vLLM より高い throughput と低い latency を示したと報告しています。
generative agents の評価でも、SGLang は throughput と latency の両方で vLLM を約 30% 上回ったとされています。ここでは、各エージェントのルーティンやテンプレートが複雑に共有されるため、単純な prefix cache では扱いにくいパターンでも RadixAttention が効いていることが読み取れます。
推論タスクでは、multi-chain reasoning や tree-of-thought のように、1つの質問から複数候補を展開して最後にまとめる処理を評価しています。これらは共有できる質問文があり、途中の候補生成は並列にしやすいです。論文では、SGLang が prefix 共有と intra-program parallelism によって高い throughput と低い latency を達成したと説明しています。
長文処理と構造化出力の結果
長文処理では、10K トークンを超える入力を含む二つのベンチマークを評価しています。ひとつは複数文書片にまたがる質問応答、もうひとつは長い Wikipedia 由来文書をもとに JSON を出力する処理です。
ここでは、前者で parallel-context window を使い、後者で長い prompt の KV キャッシュを JSON の各フィールド生成に再利用しています。結果として、論文ではそれぞれ 1.2 倍と 2.9 倍の改善が報告されています。長文入力ほど prefix 再計算の無駄が大きくなるので、この結果はかなり実用的です。
全体として何が言えるか
論文全体では、SGLang はワークロードによって差はあるものの、最大で 6.4 倍の throughput 改善を示しています。重要なのは、この改善が特別なモデル改造ではなく、ワークフロー構造を活かした実行最適化から来ていることです。
つまり結果から言えるのは、AI アプリの性能ボトルネックは「モデルが遅い」だけではなく、「同じ prefix を何度も読んでいる」「並列にできるのに順番に呼んでいる」「構造化出力のための周辺処理をアプリ側で抱えている」といった設計上の無駄にもある、ということです。
何に使える？
SGLang は、単発チャットよりも「複数の LLM 呼び出しを組み合わせるアプリ」で真価が出ます。
AIエージェントの実行基盤
エージェントは、思考、ツール選択、引数生成、観測反映を何度も繰り返します。このとき毎ターンの履歴はほぼ共有 prefix なので、KV キャッシュ再利用の恩恵が大きいです。SGLang を使うと、エージェントの制御コードを Python で保ちながら、内部の LLM 呼び出しだけ高速化しやすくなります。
RAG や長文 QA
長い文書を何度も読む RAG では、retrieval 後に複数の質問や複数の生成を流すことがあります。SGLang は長文 prefix の再利用に向いているので、社内文書検索、議事録要約、契約書 QA のような長文系ユースケースと相性がよいです。JSON フォーマットで結果を返したい場合も構造化出力の設計に乗せやすいです。
構造化出力を使う業務自動化
業務自動化では、自然言語のまま返すより、分類ラベル、真偽値、JSON、フォーム入力用データとして返したい場面が多いです。SGLang は選択肢や制約付き出力を前提にしたプリミティブを持つので、メール仕分け、問い合わせ分類、要件抽出、社内入力補助のような処理を壊れにくく実装しやすいです。
推論パイプラインの高速化
自己整合性、複数候補生成、multi-chain reasoning、branch-solve-merge のような推論パターンでは、同じ質問を土台に複数の分岐を作ります。SGLang はこの共有部分と並列分岐を扱いやすいので、精度向上のために複数回推論を回す設計を、性能面で現実的にしやすくなります。
マルチモーダル処理の統合
論文では画像入力対応や LLaVA 系のケーススタディも示されており、画像付き評価やビジュアル QA のような処理にも拡張可能です。テキストだけでなく画像や動画を含むワークフローを、同じ実行モデルで扱えるのは今後のアプリ基盤として強いです。
開発や事業へのヒント
SGLang から得られるヒントは、AI プロダクトの競争力が「どのモデルを使うか」だけでなく、「そのモデル呼び出しをどう編成するか」に移っていることです。
APIラッパーではなく実行基盤として設計する
自分で AI アプリを作るなら、単発の LLM API ラッパーを増やしていく設計は早めに限界が来ます。分岐、再試行、複数候補、構造化出力、ツール呼び出しが増えるほど、アプリコードが複雑になり、性能の無駄も増えます。SGLang の考え方は、最初から「これは LLM を含むワークフローだ」と見なして実行基盤を設計することの重要性を示しています。
長いプロンプトを資産として扱う
多くのプロダクトでは、システムプロンプト、few-shot 例、ナレッジ断片、会話履歴のような長い prefix はコスト要因としてしか見られていません。しかし SGLang 的には、それらは再利用可能な資産です。社内 SaaS やオペレーション自動化でも、長いテンプレートや定型文脈を持つ処理が多いなら、prefix 再利用前提で設計したほうが費用対効果が出やすいです。
小規模プロダクトでも効く
この論文は大規模サービング基盤の話に見えますが、小規模プロダクトでも効きます。たとえば、問い合わせ要約後に分類し、そのあと返信案を作るだけでも複数呼び出しです。同じ履歴や文脈を何度も使うなら、ワークフロー単位の最適化余地があります。利用者数が少なくても、待ち時間短縮と API コスト削減は直接価値になります。
今後注目すべき方向性
今後注目すべきなのは、推論最適化が「単一カーネル最適化」から「アプリ構造 aware な最適化」へ進んでいる点です。SGLang はその代表例です。今後はここに speculative decoding、量子化、長文最適化、マルチモーダル最適化がさらに重なっていくはずです。つまり、プロダクトを作る側もプロンプト設計だけでなく、実行計画設計の視点を持つ必要があります。
限界
SGLang にも限界はあります。まず、導入コストです。単発の推論しかないアプリなら、専用 DSL や独自ランタイムを入れるメリットは小さいです。複雑なワークフローほど効く一方で、簡単なユースケースでは過剰設計になりえます。
次に、論文時点の制約として、tracing と compiler はデータ依存の制御フローに十分対応していません。つまり interpreter では柔軟でも、すべてをコンパイル最適化できるわけではないです。実行時に分岐が大きく変わるエージェントでは、この点が効く可能性があります。
また、KV キャッシュ再利用は共有 prefix が多いほど効くので、毎回まったく違う短い入力ばかりのワークロードでは効果が薄くなります。高速化は万能ではなく、ワークロード依存です。論文でも、共有できる prefix が短い設定では改善幅が相対的に小さくなることが示唆されています。
実装面では、独自の実行モデルを採用するぶん、既存のアプリ基盤へどう組み込むかを考える必要があります。既存 observability、リトライ、権限制御、ツール実行基盤とどう接続するかは別途設計が必要です。
さらに、論文の limitation には grammar-constrained decoding の未実装や tokenization 境界の課題も挙げられています。つまり SGLang の方向性は強いですが、当時の論文版だけで完成形というわけではありません。
よくある質問
Q. SGLang は LangChain や DSPy と何が違うのですか？
A. LangChain や DSPy は主にアプリ構成やプロンプト設計を支援するレイヤーですが、SGLang は実行効率まで含めて設計された低レイヤ寄りの基盤です。とくに共有 prefix の KV キャッシュ再利用や、ワークフロー内部の並列実行が技術的な違いです。
Q. SGLang は推論サーバーの置き換えですか？
A. 一部はそうですが、単なるサーバー置き換えではありません。SGLang は DSL とランタイムを合わせた仕組みで、複数の LLM 呼び出しを1つのプログラムとして最適化するのが本質です。単一リクエストの高速化だけを狙う基盤とは視点が違います。
Q. どんなユースケースで一番効果が出やすいですか？
A. 同じ長い文脈を何度も使う処理、複数候補を並列生成する処理、エージェントのように履歴を継ぎ足していく処理です。RAG、FAQ エージェント、問い合わせ自動化、構造化レポート生成などは相性がよいです。
Q. 小さなチームでも取り入れる価値はありますか？
A. あります。ただし、単発チャットだけなら優先度は低いです。一方で、ひとつのユーザー操作の裏で 3 回以上 LLM を呼ぶようなプロダクトなら、待ち時間とコストの削減余地があります。とくに長い system prompt や文書コンテキストを使うなら検討価値があります。
Q. SGLang の論文から学べる一番大きなポイントは何ですか？
A. LLM アプリの性能は、モデルそのものよりワークフローの実行方法で大きく変わるという点です。同じモデルでも、共有 prefix 再利用や並列実行を前提に組むだけで、実用上の体感速度やコストが大きく変わりえます。
今日の学び
この論文は、複数回の LLM 呼び出しを含む AI アプリが、実装も実行も非効率になりやすいという課題を扱いました。SGLang は、Python 埋め込み DSL と RadixAttention を中心としたランタイム最適化によって、その課題を解こうとしています。
そこから得られるヒントは、AI プロダクトでは「良いモデルを選ぶこと」だけでなく、「呼び出し方をプログラムとして最適化すること」が重要だということです。エージェント、RAG、構造化出力、長文処理を作るなら、今後は実行基盤そのものが差別化ポイントになりそうです。