SGLang は、この二年ほど推論デプロイの現場で避けて通れないオープンソースのフレームワークです。同じ GPU でも、マルチターン対話やエージェント、構造化出力といった負荷では、素朴なデプロイより明確に速いことが珍しくありません。ただし、これはチャット製品ではなく、GPU と調整と見守りを必要とする推論エンジンです。セルフホストの価値は、まずリクエストの形、次に運用し続けられるかで決まります。
公式リポジトリ情報
- プラットフォーム：GitHub
- 組織名：sgl-project
- プロジェクト名：sglang
- 背景：LMSYS チームが立ち上げ、カリフォルニア大学バークレー校などの研究者と共同で推進
- ライセンス：Apache 2.0、商用利用しやすい条件
- 位置づけ：大規模言語モデルとマルチモーダルモデル向けの高性能サービングフレームワークで、OpenAI 形式互換のインターフェースを提供
なぜ広まったのか：他人が再計算する場所で速い
多くの推論フレームワークは、各リクエストを新しい問題として最初から計算します。SGLang の中核である RadixAttention は、計算済みのプロンプト接頭辞の KV キャッシュを基数木に保存し、新しいリクエストの接頭辞が同じなら、同じシステムプロンプトでも、同じ文書の冒頭でも、対話の既読部分でも、再計算せずに再利用します。公式論文では、エージェント制御や JSON デコードなどのタスクで最大で数倍規模のスループットが報告されていますが、実際の差は再利用できる接頭辞がどれだけあるかで決まります。
二つ目の売りは構造化生成です。JSON スキーマや正規表現、文法の制約に従って出力させる際、圧縮した有限状態機械でデコードを高速化し、出力の逸脱も抑えます。フィールドを大量に抽出したり、ツール呼び出しのチェーンを回したりする製品では、生のチャットインターフェースよりはるかに実用的です。連続バッチ処理、テンソル並列、FP8 や INT4 などの量子化対応も備え、単発の技ではなく本番向け推論スタック一式になっています。
向いている人、向いていない人
向いているのは、リクエスト量が既に立ち上がり、接頭辞の重複が多いチームです。マルチターンのサポートや雑談、長いシステムプロンプトを持つエージェント、同じ文書群を繰り返し組み立てる RAG などでは、セルフホスト一式でトークン単価が実際に下がります。クラウドの従量課金 API を使っていて呼び出し量がまだ小さいうちは、無理に参加しないでください。API 料金は常時稼働の GPU よりはるかに安くつきます。自分のパソコンにチャット画面が欲しいだけの個人ユーザーにも向きません。エンドユーザー向けの画面はなく、それは Open WebUI や LibreChat の領分です。
デプロイコストと実際の落とし穴
一つ目の請求書は GPU です。サーバーインスタンス一つにつきモデルは一つだけなので、二つのモデルなら二つのプロセスと二つ分の VRAM が必要で、70B 級を動かすなら複数 GPU とテンソル並列の調整は避けられません。二つ目はリリースの速さです。新モデルや新量子化形式への追随は速く、アップグレードの恩恵も大きい一方、インターフェースやパラメータも動きます。本番ではバージョンを固定し、回帰確認をしてから上げ、最新への自動追随は避けてください。三つ目は効果の見誤りです。リクエスト同士に共通の接頭辞がほぼなければ、たとえば独立した短い質問ばかりなら、RadixAttention の優位はかなり縮みます。論文の数字ではなく実トラフィックで計測してから決めましょう。四つ目は運用そのもので、ログ、レート制限、GPU 障害時の切り替え、重みの管理まで全部自前で、クラウド API の安心感はありません。
結論は明確です。流量が大きく接頭辞の再利用が多く、GPU を扱える人がチームにいるなら、セルフホストする価値があり、移行が早いほど節約も大きくなります。流量が小さい、あるいは負荷が雑多なら、当面はホスティング型 API を続け、請求書が本当に痛くなってからこの記事に戻ってきても遅くありません。
