4681 文字
23 分
【調べた】vLLMとSGLang、どっちを使う？──比較記事の結論がバラバラなので、ARC-AGIコンペの実測も入れてGPUメモリの収支で整理した
2026-11-04
deeplearning
LLM
/
vLLM
/
SGLang
/
比較・選定
/
Kaggle
JA EN
この記事について

Claude（Anthropic）との共同編集により作成されました。

要約
  • 汎用のデフォルトは vLLM。対応モデルと対応ハードウェアが広く、主要なオーケストレーション層もバックエンドに採用している
  • SGLang が得意なのは、プレフィックスを使い回す負荷（エージェント、マルチターン、構造化出力）と、DeepSeek 系のような大規模 MoE の多ノード配信である
  • 性能比較はワークロードで逆転する。2026 年の論文では dense は vLLM、MoE は SGLang が速かった。公開ベンチマークの多くはプレフィックス共有の多い条件を測っていない
  • ARC-AGI-2 の直答では vLLM が勝ち（418 対 272 tok/s）、マルチターンは差なし、ARC-AGI-3 では SGLang 系への載せ替えで public LB が 2.68 から 11.07 に上がった（要因は未分離）
  • 差が開いた場面は、KV キャッシュが GPU に収まるかで説明できると読んでいる。SGLang のプレフィックス再利用は強いが、ハイブリッドモデルでは状態の保存にメモリを払う
  • 自分の結論は、迷ったら vLLM で始めつつ、エンジンの評判より先に KV の収支を確かめること。同時本数 × 文脈長が収まる構成を選ぶ

きっかけ#

2026 年の秋に、Kaggle の ARC Prize 2026（ARC-AGI-2 と ARC-AGI-3）に出ていた1。どちらもオフラインの Kaggle ノートブックに重みを持ち込み、限られた時間で推論を回すコンペで、1 秒あたりに生成できるトークン数がそのままスコアに効く。そのため、モデルの中身と同じくらいサービングのことを考える羽目になった。

ただ、調べても結論がそろわない。「SGLang は vLLM より速い」という記事もあれば、逆の記事もある。実際に手元で載せ替えると、ARC-AGI-2 と ARC-AGI-3 でも結果が逆になった。

そこで、どんな場合にどれが強いのかを、公式情報と論文で整理し直した。あわせて、コンペで同じ負荷を載せ替えた実測を載せる。公式情報のバージョンとスター数は 2026-11-04 に確認した。

先に答えを書いておくと、どっちが速いかより、自分の負荷が GPU のメモリに収まるのはどっちかを先に確かめたほうがよい。

サービングフレームワークが解いている問題#

LLM 推論のボトルネックは、GPU メモリ上の KV キャッシュ（過去トークンの Key / Value）の扱いにある。各フレームワークの差は、主に次の 3 点に出る。

論点内容代表的な技術
メモリ管理KV を無駄なく詰め、同時に処理できるリクエストを増やすPagedAttention（vLLM）3
再利用同じプレフィックスの KV を再計算せずに使い回すRadixAttention（SGLang）7、prefix caching（vLLM）12
スケジューリングと分散バッチの組み方、prefill と decode の分離、複数 GPU への分散continuous batching、PD 分離、Expert Parallel

Claude Code を使っている人なら、再利用は prompt caching と同じ話だと思えばよい。Anthropic の API では、tools、system、messages の順で先頭から完全に一致した部分だけがキャッシュに当たり、途中を変えるとそれ以降は無効になる2。システムプロンプトと CLAUDE.md が先頭に固定され、後ろに履歴が伸びていくコーディングエージェントのハーネスは、プレフィックス再利用が最も効く負荷である。

vLLM と SGLang を比べる#

観点vLLMSGLang
設計の出発点PagedAttention によるメモリ効率3RadixAttention によるプレフィックス再利用7
自己紹介誰でも使える高速で安価な LLM 配信4エージェント、大規模配信、RL ロールアウトに最適化6
ガバナンスPyTorch Foundation5LMSYS ＋ 商用会社 RadixArk611
最新版v0.32.0（10-18）8。v0.33.0 が RCv0.5.23（11-02）10
GitHub スター約 9.6 万約 3.8 万
対応モデル200 以上のアーキテクチャ4主要な新モデルはリリースごとに追加10。網羅性は vLLM のほうが広い
対応ハードウェアNVIDIA、AMD、Intel に加え、TPU、Gaudi、Spyre、Ascend、Apple Silicon など4NVIDIA、AMD、TPU、Intel、Apple Silicon、Ascend、Moore Threads6
プレフィックス再利用固定長ブロックのハッシュ連鎖で判定。埋まったブロックだけキャッシュする12radix tree で一致部分を自動再利用。ルーティングもキャッシュを考慮する9
生成以外テキスト出力が中心画像・動画生成の SGLang Diffusion を同梱6

どちらもおおむね 2 週間ごとにリリースされ、片方にしかなかった機能が数か月でもう片方に入ることが多い。半年前の比較記事は参考程度に読むのがよい。

vLLM が強い場面#

  • 汎用の本番 API サーバ: 新しいモデルへの対応が速く、たいていのモデルがそのまま動く4
  • NVIDIA 以外のハードウェア: TPU、Gaudi、Ascend などを使うならまず候補になる4
  • dense モデルの計算効率: 後述の CCL-Bench で、MFU が SGLang の約 2 倍だった13
  • 周辺ツールとの連携: llm-d、AIBrix、Ray Serve LLM、Dynamo がそろって対応している23242526

SGLang が強い場面#

  • プレフィックス共有の多い負荷: 論文では、エージェント制御や JSON デコード、マルチターン会話などで当時の既存システム比で最大 6.4 倍のスループットを報告している7。キャッシュを考慮したロードバランサで、ヒット率が 20% から 75% に上がった例もある9
  • 構造化出力: 圧縮 FSM と xgrammar で JSON などの制約付きデコードを速くする79
  • 大規模 MoE の多ノード配信: PD 分離と大規模 Expert Parallel で、DeepSeek-V3 を H100 96 枚で配信した事例がある14
  • RL のロールアウト生成: verl、slime、AReaL などに組み込まれている6

ベンチマークは何を言っているか#

性能比較は条件で逆転する。比較的条件の分かる 2 本を挙げる。

CCL-Bench 1.0（2026-05、arXiv）は、A100 上で通信バックエンドや並列化の設定をそろえて比べた13。

ワークロード結果論文の分析
Qwen3-4B（dense）vLLM が速い。MFU 17.1% 対 8.6%vLLM の計算カーネルが効率的
Llama-3.1-8B（dense）vLLM が速い。MFU 28.4% 対 15.5%同上
DeepSeek-MoE-16B（EP4 / TP4）SGLang が速い。76.1 ms 対 81.2 msSGLang の AllToAll 実装が効率的

Jarvislabs のブログ（2026-05、H100）では、短いプロンプトは vLLM のバランスが最も良く、16K トークンの長いプロンプトでは SGLang の TPOT が最も低かった。ただし TTFT は高めで、バージョンの記録がなく、著者も普遍的な順位ではないと断っている15。

どちらも、プレフィックスを共有する条件は測っていない。SGLang の本領はそこなので、エージェント用途ならこの数字では判断できない。「SGLang が 29% 速い」のような数字を載せたブログは他にも多いが、条件が不明確で互いに食い違うため、本記事では採らなかった。

測り方自体でも数字はずれる。自分で比べるときの注意点は負荷検証ツールの記事に書いた。

ARC-AGI で載せ替えて測ったら#

ここからは手元の実験記録である。どちらも Qwen 系モデルの推論を Kaggle 上で回した。LB はすべて public の値で、private はまだ発表されていない。

  • ARC-AGI-2: NVIDIA L4（24 GB）× 4、PCIe 接続、Qwen3.8-27B（dense と GDN の混成）
    • 直答: 1 回のプロンプトで長く考えて答える。文脈は 8 万トークン前後まで伸び、プレフィックスは使い回さない
    • マルチターン: Python ツールを呼びながら解く
  • ARC-AGI-3: RTX PRO 6000（96 GB）× 1、Qwen3.8-Flash-Next（125B の MoE）。ゲームを操作するエージェントで、画像と履歴が伸びていく
負荷構成同時KV 容量（トークン）結果
ARC2 直答vLLM 素241,408,000298.5 tok/s
ARC2 直答vLLM ＋ MTP 2211,157,090418.1 tok/s（採用）
ARC2 直答SGLang ＋ MTP24（実際は 9〜12）516,014272.1 tok/s
ARC2 直答SGLang 素（radix なし）241,307,584最初の prefill で OOM
ARC2 マルチターンvLLM241,436,259LB 16.11（1 本）
ARC2 マルチターンSGLang24752,964LB 16.25（2 本の平均）
ARC3vLLM（KV 5 GiB 固定・MTP 3）28 × 32k5 GiBLB 2.68（9 本の平均）
ARC3vLLM（MTP なし）7 × 64k486,838LB 4.46（2 本の平均）
ARC3SGLang 系 fork（FP8 KV・MTP 3）10 × 128k1,011,264LB 11.07（1 本）

MTP はモデルに同梱された投機デコードで、KV を余分に使う代わりに速くなる。ARC-AGI-2 の版は vLLM 0.30.0 と SGLang 0.5.20、ARC-AGI-3 の fork は 0.5.19 相当である。

分かったことは 4 つある。

1 つ目は、直答で SGLang が負けた理由がエンジンの遅さではなかったこと。SGLang ＋ MTP は、GDN の中間状態に 1 GPU あたり 3.52 GB を取られて KV が 516k まで減り、同時 24 のうち 9〜12 本しか走らなかった。素の構成は prefill の CUDA graph で OOM した。つまり、24 GB の GPU に収まらなかった結果で、エンジンの速さを比べたものになっていない。別の方の RTX 4090 × 4 の記事では、同時 1 の decode は SGLang が約 1.35 倍速い一方、KV は 281k 対 441k だった16。向きがそろっている。

2 つ目は、マルチターンでは再利用の差が出ても、スコアは動かなかったこと。同じ窓で比べると、プレフィックスの再利用は SGLang 0.955 対 vLLM 0.723 で、1 ターンあたりの新規 prefill は 702 対 4,164 トークンだった（1 run 同士）。Decode の速さは定常区間で同じである。一方で KV は約半分になった。

理由はハイブリッドモデルの構造にある。GDN のような線形注意の層は、トークンごとの KV ではなく固定サイズの状態を持つ。途中のトークンの分だけを取り除けないので、再利用するには途中の状態を保存しておく必要がある。SGLang の extra_buffer は 1 要求あたり 5 枠の状態を持つ。再利用は無料ではなく、KV を削って買っている。LB は同じ版でも 15.00 と 17.50 に振れる分解能なので、差なしと読んだ。

3 つ目は、ARC-AGI-3 では KV が約 2 倍に増える構成へ替えたらスコアが上がったこと。当時の vLLM の image では、この MoE の KV が BF16 のみで、FP8 にできなかった。SGLang 系の fork なら FP8 KV と MTP 3 が同時に使え、10 本 × 128k が現実的になった。公開解法の Daniel Franzen さんの serving 一式をそのまま持ってきたものである17。キャッシュのヒット率は 48% から 84% に上がった（測った条件は別）。

ただし、この 11.07 は重み、KV の型、MTP、窓、同時本数を同時に変えた結果で、エンジンの差とは分離できていない。使ったのは素の SGLang でもなく、パッチの当たった Pennyroyal という fork である18。上流の 0.5.21 に差し替えると KV は 820k 程度に減る見積もりだったので、差し替えは見送った。また、公開解法自体の LB は 27.24 で、そこまでの差はサービング以外の部分が持っていると読んでいる。

4 つ目は、KV が詰まると損が大きいこと。ARC-AGI-2 の本番では、KV が律速の区間で生成が 374 から 218 tok/s へ約 4 割落ちた。待っている要求の prefill と preemption で decode が止まるためである。ARC-AGI-3 でも、10 本に 2 本足して 12 本にしただけで、ヒット率は 0.94 から 0.82 に、ゲーム側の生成トークンは 18% 減った。

OpenAI 互換でも差し替えるだけでは同じ入力にならない#

載せ替えで踏んだ罠も書いておく。どちらも OpenAI 互換 API なので差し替えは簡単に見えるが、プロンプトの描画が変わる。

  • SGLang は tools の渡し方が違い、system の JSON が 11 トークン変わった。1 回目は 20.17 対 24.00 で負けたが、原因候補のこの描画を揃えた 2 回目は 24.00 で並んだ
  • SGLang の Qwen3.8 テンプレートは assistant の reasoning_content しか読まず、reasoning で送ると過去の推論が黙って全部落ちる

比べる前に、同じ入力が最終的に同じトークン列になるかを確かめる必要がある。

KV の収支の見方#

ここまでの話を、自分の環境に当てはめる手順にする。必要な KV は、おおよそ次で見積もれる。

必要な KV ≒ 同時本数 × (実際に伸びる文脈長 + 1 要求の固定分)

1 要求の固定分は、Qwen3.8-27B の vLLM で素 1.5k、MTP 2 で 4.8k、MTP 3 で 7.4〜8.6k トークン相当だった。文脈長の見積もりは最大でなく、実際の平均でもよい。ARC-AGI-3 の公開解法は 10 本 × 128k（1.31M）に対して KV が 1.01M しかないが、128k に達したら 58k まで一気に捨てることで平均 88k に抑えている。少しずつ捨てるとプレフィックスが毎ターン崩れるので、まとめて捨てる。Claude Code の /compact に近い考え方である。

KV を食うものと、確かめる場所は次のとおり。

項目メモリへの効き方確かめる場所
重みの量子化重みを軽くすれば KV に回る起動ログのメモリ内訳
KV の型（BF16 / FP8 / NVFP4）FP8 で BF16 の約半分--kv-cache-dtype。モデルと版で可否が違う
投機デコードドラフト用の状態と 1 要求の固定分が増えるMTP の段数を変えて比べる
ハイブリッドの状態保存再利用のために枠を取るSGLang の --mamba-radix-cache-strategy
CUDA graphKV を確保した後の余白を食うSGLang の --mem-fraction-static

起動後に見るのは次の値である。

  • vLLM: Maximum concurrency for 81,920 tokens: 4.69x のログ。この倍率が同時本数を下回っていたら収まらない。詰まったかどうかは vllm:num_preemptions_total で数える
  • SGLang: 起動ログの max_total_num_tokens と、Decode 行の full token usage。--enable-cache-report でターンごとの cached_tokens が取れる

なお、収支の前提も変わり続けている。vLLM 0.32 では NVFP4 の KV が SM8x と SM12x でも動くようになった8。手元の L4 では容量が 1.62 倍になる一方、tok/s は 0.969 倍で、この負荷では採らなかった。SGLang 0.5.23 には、GPU メモリに載らない MoE を動かす Paged Experts が入っている10。上の表の数字は版を選ぶ判断材料にはなるが、今の版の優劣ではない。

その他の選択肢#

ほかの選択肢は「層」で分けると整理しやすい。

推論エンジン（単体で動くもの）#

フレームワーク位置づけ向いている用途
TensorRT-LLMNVIDIA GPU 専用。独自カーネル、PD 分離、投機デコード19NVIDIA GPU で性能を突き詰める本番環境
LMDeployC++ の TurboMind と PyTorch エンジンの 2 本立て27量子化モデル、InternVL などの VLM、Ascend
llama.cppC/C++ 製。GGUF で CPU や Apple Silicon でも動く28ローカル、エッジ、小さな GPU
Ollamaggml ベース。モデルの取得と起動が簡単29個人 PC での試用、開発
MLC-LLMML コンパイラで各環境向けにビルド30スマホ、ブラウザ
KTransformersよく使うエキスパートを GPU、残りを CPU に置く22巨大 MoE を少ない GPU で動かす
TGIHugging Face 製。アーカイブ済み21新規採用は避ける。HF 自身が vLLM、SGLang などを勧めている

TensorRT-LLM は「モデルを事前にコンパイルする必要がある」と説明されがちだが、これは古い。1.2 で TensorRT バックエンドと trtllm-build は削除され、今は PyTorch が実行バックエンドになっている20。手元の L4 1 枚で小さいモデルを vLLM と比べたら、区間の decode で 9B が約 12%、4B が約 21% 速かったが、測り方を揃え直すと本数で変わった（9B で 21 本 1.08 倍、6 本 0.96 倍）。

オーケストレーション層（エンジンの上で束ねるもの）#

単一ノードならエンジンだけで足りる。複数ノードで、KV を考慮したルーティング、PD 分離、オートスケールが必要になったときに載せる。vLLM や SGLang を置き換えるものではなく、バックエンドとして使う。

フレームワーク開発元対応エンジン特徴
NVIDIA Dynamo23NVIDIASGLang、TensorRT-LLM、vLLMKV を GPU→CPU→SSD→リモートへ逃がす、SLA ベースの自動スケール
llm-d24Red Hat、Google Cloud、IBM Research など。CNCF SandboxvLLM 中心（SGLang の PD 分離も対応）Kubernetes ネイティブ。階層型 KV オフロード
AIBrix25vllm-project（ByteDance 発）vLLM、SGLang、TensorRT-LLMエンジンの状態を見たルーティング、LoRA の動的ロード
Ray Serve LLM26AnyscalevLLM、SGLangRay 上のマルチノード配信とバッチ推論

使い分けの目安#

こういう場合第一候補補足
とりあえず OSS モデルを API で立てるvLLM迷ったらこれ
NVIDIA 以外を使うvLLMSGLang も一部対応。要確認
出たばかりのモデル、珍しいアーキテクチャvLLM両方の対応状況を見る
エージェント、マルチターン、長い共通プロンプトSGLang を測るハイブリッドモデルは状態保存のメモリ分を引いて比べる
JSON などの構造化出力を大量に出すSGLang
プレフィックスを使い回さない長文の推論vLLM を測るradix の利点が消え、decode と KV の勝負になる
巨大 MoE を多ノードで配信SGLangvLLM も対応が進んでいる。両方測る
VRAM が小さい GPU（24 GB など）で同時本数を稼ぐKV 容量を先に比べるCUDA graph と投機の状態まで引く
RL のロールアウト生成使う RL フレームワーク次第
ローカル PC、エッジllama.cpp / Ollamaスマホ、ブラウザなら MLC-LLM
NVIDIA で性能を極限までTensorRT-LLMDynamo と組み合わせる
Kubernetes で大規模運用エンジンはどちらでも上に llm-d / Dynamo / AIBrix を載せる

自分の結論#

迷ったら vLLM で始めつつ、エンジンの評判より先に KV の収支を確かめること。同時本数 × 文脈長が自分の GPU に収まる構成はどれかを、起動ログで比べる。

ARC-AGI-2 では KV が半分になった SGLang が不利で、ARC-AGI-3 では FP8 KV が使えた SGLang 系が有利だった。正反対に見える 2 つの結果は、同じ軸で説明できると読んでいる。「SGLang はエージェントに強い」という一般論は間違っていないが、それだけで選ぶと、再利用のために払うメモリを見落とす。

最後に留保を書いておく。手元の実測はモデルも GPU も限られていて、どれも 1 つの負荷の話である。LB の比較は本数が少なく、ARC-AGI-3 の改善はエンジン単体の効果ではない。半年後には機能も数字も変わっているはずなので、同じ表を信じるより、自分の負荷で同じ確かめ方をするのがよい。

参考文献#

  1. ARC Prize https://arcprize.org/
  2. Anthropic, Prompt caching https://platform.claude.com/docs/en/build-with-claude/prompt-caching
  3. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) https://arxiv.org/abs/2309.06180
  4. vLLM GitHub README https://github.com/vllm-project/vllm
  5. PyTorch Foundation Welcomes vLLM as a Hosted Project (2025-05-06) https://pytorch.org/blog/pytorch-foundation-welcomes-vllm/
  6. SGLang GitHub README https://github.com/sgl-project/sglang
  7. Zheng et al., SGLang: Efficient Execution of Structured Language Model Programs https://arxiv.org/abs/2312.07104
  8. vLLM v0.32.0 リリースノート https://github.com/vllm-project/vllm/releases/tag/v0.32.0
  9. LMSYS Blog, SGLang v0.4 (2024-12-04) https://lmsys.org/blog/2024-12-04-sglang-v0-4/
  10. SGLang v0.5.23 リリースノート https://github.com/sgl-project/sglang/releases/tag/v0.5.23
  11. TechCrunch, Sources: Project SGLang spins out as RadixArk (2026-01-21) https://techcrunch.com/2026/01/21/sources-project-sglang-spins-out-as-radixark-with-400m-valuation-as-inference-market-explodes
  12. vLLM ドキュメント, Prefix Caching https://docs.vllm.ai/en/latest/design/prefix_caching/
  13. Ding et al., CCL-Bench 1.0: A Trace-Based Benchmark for LLM Infrastructure (arXiv:2605.06544, Appendix G.1) https://arxiv.org/abs/2605.06544
  14. LMSYS Blog, Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs (2025-05-05) https://lmsys.org/blog/2025-05-05-large-scale-ep/
  15. Jarvislabs, SGLang vs vLLM: H100 Benchmarks, with TensorRT-LLM (2026-05-18) https://jarvislabs.ai/blog/vllm-sglang-trtllm-comparison
  16. engchina, SGLang × Qwen3.8-27B × RTX 4090 ×4（Qiita） https://qiita.com/engchina/items/d37f3169be4da2d31548
  17. Daniel Franzen, ARC-AGI-3 solution https://github.com/da-fr/arc-agi-3-solution
  18. Pennyroyal（SGLang for RTX PRO 6000） https://github.com/jpezzulli/sglang-rtxpro6000
  19. TensorRT-LLM GitHub README https://github.com/NVIDIA/TensorRT-LLM
  20. TensorRT-LLM Release Notes https://nvidia.github.io/TensorRT-LLM/release-notes.html
  21. Text Generation Inference GitHub README https://github.com/huggingface/text-generation-inference
  22. KTransformers GitHub https://github.com/kvcache-ai/ktransformers
  23. NVIDIA Dynamo GitHub README https://github.com/ai-dynamo/dynamo
  24. llm-d GitHub README https://github.com/llm-d/llm-d
  25. AIBrix GitHub README https://github.com/vllm-project/aibrix
  26. Ray Serve LLM ドキュメント https://docs.ray.io/en/latest/serve/llm/index.html
  27. LMDeploy GitHub README https://github.com/InternLM/lmdeploy
  28. llama.cpp GitHub https://github.com/ggml-org/llama.cpp
  29. Ollama GitHub https://github.com/ollama/ollama
  30. MLC-LLM GitHub https://github.com/mlc-ai/mlc-llm
シェア: X Bluesky はてブ
【調べた】vLLMとSGLang、どっちを使う？──比較記事の結論がバラバラなので、ARC-AGIコンペの実測も入れてGPUメモリの収支で整理した
https://yurudeep.com/posts/deeplearning/2026/20261104/
作者
ひらノルム
公開日
2026-11-04
ライセンス
CC BY-NC-SA 4.0
AIエージェントを並列で回すと追いきれない──DeepSeekの「Super-agent」設計を図解したら、ボトルネックは人間の注意力だった
© 2026 ひらノルム. All Rights Reserved. / RSS / Sitemap
Powered by Astro & Fuwari