vLLM vs SGLang vs LMDeploy: 2026年の最速LLM推論エンジンはどれか?

Dev.to / 2026/3/5

Developer Stack & InfrastructureIdeas & Deep AnalysisTools & Practical Usage

要点

  • H100上のLlama 3.1 8BベンチではSGLang(~16,200 tok/s)とLMDeploy(~16,100 tok/s)が首位で、vLLM(~12,500 tok/s)は約29%遅いとされる。
  • ワークロード適性は異なり、SGLangはマルチターン会話やprefix再利用に強く、LMDeployは量子化(特にInt4)で高性能、vLLMは成熟したエコシステムと導入容易性が強みである。
  • 29%のスループット差は、1日100万リクエスト規模の提供で月あたり約15,000ドルのGPUコスト差になり、トラフィック増加で影響が拡大する。
  • 3エンジンはいずれもOpenAI互換APIを提供しつつ、vLLMはPagedAttention、SGLangはRadixAttention、LMDeployはC++のTurboMindなど異なるアーキテクチャで性能差が生じる。

SGLangとLMDeployは2026年に最速のLLM推論エンジンであり、どちらもH100 GPU上でおよそ16,200トークン毎秒を実現しています。vLLMは約12,500トークン毎秒で続き、29%の差があります。

最適なエンジンはワークロードによります。SGLangはマルチターン会話に優れ、LMDeployは量子化モデルのサービングで優位に立ち、vLLMは一般的な運用で最も成熟したエコシステムを提供します。

その29%のスループット差は、1日に100万リクエストを処理する際に月々約15,000ドルのGPUコスト節約に相当します。この差はトラフィックの増加によりさらに拡大します。

オープンソースのLLMサービングでは、vLLM、SGLang、LMDeployの3つのエンジンが主導しています。各エンジンは異なるアーキテクチャを採用し、異なるシナリオで強みを発揮します。以下の比較は13以上の推論エンジンのベンチマークデータを基に、性能差を生むアーキテクチャの違いを説明し、最適な選択の指針を提供します。

vLLM vs SGLang vs LMDeployの簡単比較

特徴 vLLM SGLang LMDeploy
スループット (H100, Llama 3.1 8B) ~12,500 tok/s ~16,200 tok/s ~16,100 tok/s
コア技術 PagedAttention RadixAttention TurboMind (C++)
マルチターン性能 良好 優秀(10-20%高速) 良好
量子化サポート Int4, AWQ, GPTQ FP4/FP8/Int4/AWQ/GPTQ 最高クラス(Int4で2.4倍高速)
初トークンまでの時間 低並列時に優秀 キャッシュヒット時に最速 全体で最速
セットアップの複雑さ 簡単(pipインストール) 中程度 中程度
コミュニティ規模 最大 成長中(40万GPU超) 中規模
OpenAI API互換性 あり あり あり
最適用途 一般的な運用、広い互換性 エージェントワークフロー、チャット、prefix再利用 量子化モデル、メモリ制約環境

SGLangとLMDeployは生のスループットで拮抗しています。vLLMは29%遅れますが、成熟したエコシステムと容易な導入で補っています。

LLM推論エンジンとは?

LLM推論エンジンは、学習済み言語モデルを効率的に動作させるソフトウェアです。プロンプトからのテキスト生成計算を担います。最適化がなければ7Bパラメータモデルは応答に数秒かかりますが、適切なエンジンを使うと応答はミリ秒単位になります。

重要な4つの指標があります:

スループットは1秒あたりに生成されるトークン数を表します。スループットが高いほど、GPU当たりより多くのリクエストを処理可。12,000トークンと16,000トークンの差は同じハードウェアで33%多く対応できることを意味します。

初トークンまでの時間 (TTFT)はユーザーが最初の単語を見るまでの速度を測定します。チャットアプリケーションでは体感応答速度を左右し、100ms以下を目標とします。

トークン間レイテンシ (ITL)はストリーミング中の連続トークン間の時間差を表します。一貫したITLは滑らかな出力を生み、ばらつきがあると出力が途切れ途切れになります。

GPUメモリ消費量はモデルサイズの上限や同時リクエスト数を決めます。一リクエストあたりのメモリ使用量が少ないほどGPUあたり多くのリクエストを処理可能です。

vLLM: 実運用の標準

vLLMはメモリ断片化問題を最初に解決したことで実運用向けのデフォルトとなりました。PagedAttention登場以前は、KVキャッシュの断片化によりGPUメモリの60-80%が無駄にされていました。

PagedAttentionの説明

従来の推論エンジンは各シーケンスごとに連続したメモリブロックを割り当てます。シーケンス長が異なるため解放メモリが散在し外部断片化が蓄積します。

PagedAttentionはKVキャッシュを仮想メモリのように扱います。キャッシュは固定サイズのページ(通常16トークン単位)に分割し、要求に応じて割り当てます。シーケンスが追加キャッシュを必要とすると、物理位置にかかわらず次の空きページを割り当てます。

これによりメモリ利用効率が約30%から90%以上に改善し、同等レイテンシで旧来の推論スタックと比べ2~4倍のスループット向上を実現しました。

vLLM性能データ

A100 80GB GPU上でLlama 2 7B Chatをfloat16精度で動かした場合、vLLMはTensorRT-LLMに似た中程度のスループットで高いGPUメモリ使用量を示します。出力品質は基モデルと同等で劣化はありません。

連続バッチ処理により可変長リクエストも効率的に扱い、新規リクエストは固定バッチウィンドウを待たず即座に加入し、負荷下での平均レイテンシを削減します。

vLLMの適用場面

vLLMは最大性能よりもエコシステム成熟度を重視する場合に最適です。ドキュメントは充実しており、多くのオープンソースモデルが即利用可能で、GitHubのIssueで一般的な問題の回答が得られます。

vLLMが適するシナリオ:

  • 安定性を最優先するチーム
  • 主にシングルターンのインタラクションを持つワークロード
  • 広範なモデル互換性を求めるプロジェクト
  • RayやKubernetes統合を活用する組織

ベンチマークでもこの差が分かります。H100環境で最適化された構成では、vLLMは最大で約12,500トークン毎秒、SGLangとLMDeployは16,200に達し約29%の差が生じます。このギャップは大量処理時に実質的なコスト差となります。

SGLang: マルチターン&エージェントワークロード向け

SGLangはUCバークレーの研究から生まれ、vLLMの開発者の一部が関わっています。ただし設計目標は独立リクエストの最適化ではなく、LLMプログラムの最適化にあります。

解決策はRadixAttentionであり、共有接頭辞を持つワークロードで最大5倍の推論高速化を実現します。

RadixAttentionの説明

従来のエンジンは各リクエスト終了後にKVキャッシュを破棄します。SGLangはキャッシュされた接頭辞をラディックス木に保存し、共有されたトークン列を効率的に表現します。各ノードはトークン列と関連付けられたKVキャッシュページを保持します。

新規リクエストではランタイムがラディックス木内のマッチする接頭辞を探し、キャッシュ済みの計算を再利用します。既に処理済みトークンの重複作業はありません。

キャッシュヒット率はワークロードにより異なります:

  • 共有例を持つ少数ショット学習: 85-95%(PagedAttentionの15-25%と比較して高い)
  • 会話履歴を含むマルチターンチャット: 75-90%(同じく10-20%に対し高)
  • 共通パターンを持つコード解析: 60-80%(5-15%と比較して高)
  • 共有なしの単一リクエスト: 0%(性能は同等)

SGLang性能データ

独立テストでH100上のLlama 3.1 8Bを使うと、SGLangは約16,200トークン毎秒を示し、vLLMより29%高速です。マルチターンワークロードはRadixAttentionキャッシュヒットでさらに10-20%高速化します。キャッシュヒット時は初トークン到達時間が大幅に短縮されます。

SGLang v0.4はゼロオーバーヘッドのバッチスケジューラを導入し、CPUスケジューリングのオーバーヘッドを全体の2%未満に抑えました。以前のバージョンは15-25%もスケジューリングに費やしていました。

構造化出力生成

SGLangは制約付きデコード用の圧縮有限状態機械を備えています。JSONやXMLのような特定フォーマットが必要な場合、複数トークンの一括デコードを有効にし有効な継続列を事前計算します。JSONデコードは後処理検証付きの非制約生成と比べて3倍高速です。

SGLangの適用場面

SGLangが向くのは:

  • マルチターン会話を伴うカスタマーサポートチャットボット
  • 共有コンテキストを維持するコーディングアシスタント
  • エージェントワークフローなどprefix再利用が多いタスク