vLLMとSGLangを比較：エージェント・RAG向け推論エンジンの選び方

vLLMとSGLang、どちらを選ぶべきですか？

一般的なデプロイの第一候補はvLLMです。共通コンテキストの処理が中心のワークロードでは、SGLangを先に評価することを勧めます。 これは公開ドキュメントにあるデプロイ方法とキャッシュ制御に基づく推奨であり、どちらかが常に高速だという意味ではありません。

短いチャットを大量に処理する場合、共通のシステムプロンプトがあることはSGLangを評価する理由になります。ただし、それだけでvLLMを候補から外す必要はありません。プロンプトの計算結果は、どちらも再利用できます。インフラに割ける時間が限られ、シンプルなAPIを提供したい事業立ち上げの段階なら、まずvLLMで始めましょう。切り替えは、サービス品質かコストの改善を実証できてからで十分です。

RAG（検索拡張生成）は、検索で取得した文書をモデルのプロンプトに加える仕組みです。プレフィックスキャッシュが役立つかどうかを決めるのは、RAGという分類ではなく、プロンプトの先頭部分が繰り返し使われるかどうかです。

確認日：2026年10月14日。今回確認できた最新の安定版は、10月5日公開のvLLM 0.31.0と、10月2日公開のSGLang 0.5.21です。以下の機能説明は、確認時点の各プロジェクトのドキュメントに基づきます。必要な機能の組み合わせは、実際に固定して使うリリースで検証してください。この比較では、推論ベンチマークを実行していません。

ライセンスは、vLLMのライセンス文書とSGLangのリポジトリで確認しています。モデルの重みのライセンス、インフラ、エンジニアリングの費用は別です。どちらのオープンソースエンジンにも、比較対象となるホスト型サービスのトークン従量料金はありません。

各エンジンでできることと、導入時の制約

vLLM：汎用サービングの基本となる選択肢

vLLMは、モデルの重みを読み込み、ハードウェア上でリクエストをスケジューリングする推論・サービングエンジンです。 ドキュメントに記載された主要な仕組みには、処理を終えたリクエストに代わって新しいリクエストを受け入れるcontinuous batchingと、PagedAttentionがあります。PagedAttentionは、リクエストごとに大きな連続メモリ領域を確保する代わりに、モデルのKey-Valueキャッシュをブロック単位で管理します。KVキャッシュはAttentionの中間状態を保存し、それまでの履歴全体を再計算せずに生成を続けられるようにします。vLLMドキュメント

vLLMから始めやすい理由は、デプロイに必要な構成が明確なことです。モデル、公式サーバーイメージ、API、プラットフォームごとの導入手順がそろっています。カスタマーサポート用のエンドポイントを開発するプロダクトチームにとって、処理容量を測るための扱いやすい基準になります。

制約になるのは、構成全体での動作確認です。 GPUが対応しているだけでは足りません。モデルのアーキテクチャ、量子化、Attentionバックエンド、必要な機能が組み合わさって動く必要があります。評価サービスでは、キャッシュの例外にも注意が必要です。vLLMの説明では、プロンプトの対数確率を要求するリクエストはプレフィックスキャッシュを使わず、プロンプトを再計算します。そのため、同じ文書を使っていても、スコアリング用エンドポイントとチャット用エンドポイントでは挙動が異なる可能性があります。vLLM V1ガイド

エンジンの料金は$0です。汎用サービングや、異なるハードウェアが混在する環境に向いています。稼働中のSGLangがすでにサービス目標を満たし、必要な機能にも不足がないなら、vLLMへ移行する必要はありません。

SGLang：エージェントが同じコンテキストを繰り返し使う場合の有力候補

SGLangは、言語モデルとマルチモーダルモデル向けのオープンソース推論フレームワークで、エージェント型ワークロードを重点分野のひとつに掲げています。 RadixAttentionは、共通のプレフィックスを軸に、再利用できるプロンプトの状態を整理します。拡張機能のHiCacheは、GPUキャッシュの背後にホストメモリとストレージの階層を追加します。繰り返し発生するリクエスト間でコンテキストを保持・再利用するための仕組みが文書化されている点が、実務上の魅力です。SGLangリポジトリ、HiCacheの設計

同じサポートポリシーを何度も読み込み、そこから顧客ごとに異なる質問へ分岐するエージェントを考えてみてください。こうした処理は、互いに無関係なプロンプトが単に大量に同時到着する場合よりも、SGLangを評価する明確な理由になります。

制約になるのは、キャッシュの共有範囲と、バックエンド間の機能差です。 HiCacheのGPU層とホストメモリ層は、個々の推論インスタンスに属します。ストレージが共有されるのは、選んだバックエンドをその目的に合わせて設定した場合だけです。ホストキャッシュを大きくしても、全インスタンスで共有するキャッシュが自動的にできるわけではありません。階層を追加すれば、メモリの配分、データ転送、設定の管理も運用に加わります。HiCacheの共有範囲

エンジンの料金は$0です。同じコンテキストの繰り返しが多く、調整する価値がある場合に選びましょう。プロンプトの先頭が完全に一致することが少ないなら、「エージェント向け」という言葉だけを理由に切り替える必要はありません。

プレフィックスキャッシュとRadixAttention：まずSGLangを評価する理由

同じコンテキストから分岐する処理や、コンテキストを繰り返し使う処理では、SGLangを先に評価する価値があります。ただし、vLLMにも必要なキャッシュ機能はすでにあります。 PagedAttentionとキャッシュ機能の有無を対比する話ではありません。PagedAttentionが扱うのはメモリの管理方式、プレフィックスキャッシュが扱うのは計算結果の再利用です。vLLMのAutomatic Prefix Cachingは、同じ長文書への繰り返しの質問や、複数ターンの会話を明示的に対象としています。vLLMのプレフィックスキャッシュ

プリフィルは、生成を始める前にプロンプトを読み込む処理です。デコードは、新しいトークンを生成する処理を指します。キャッシュがヒットすれば同じプリフィルの繰り返しを省けますが、新しい回答を書き出すデコード処理は残ります。そのため、共通の入力が少なく回答が長い場合は、どちらのエンジンでもプレフィックスの再利用による効果が小さくなり得ます。

短いチャットを扱うサービスでは、モデルが想定するプロンプト形式の範囲内で、変化しないポリシーやツールの説明を、リクエストごとに変わる内容よりも前に置きましょう。シリアライズの形式と文書の順序もそろえます。先頭付近のタイムスタンプが変わるだけで、それ以降が同じ内容でも再利用できなくなる場合があります。同じ道をたどると考えるとわかりやすいでしょう。一度ルートが分かれれば、その先の風景が同じでも、そこまでの道のりが同じになるわけではありません。

長いコンテキストを扱うRAGでは、もうひとつ確認が必要です。そのコンテキストは再利用できるのか、それとも単に長いだけなのか。 内容が変わらないマニュアルへの繰り返しの質問は、キャッシュが有効な典型例です。一方、リクエストごとに異なる抜粋を異なる順序で組み立てる検索サービスでは、短いシステムプレフィックスしか再利用できない場合があります。階層型ストレージに投資する前に、これらを分けて測定しましょう。

SGLangのドキュメントでは、RadixAttentionはデフォルトで有効になっており、--disable-radix-cacheで制御します。HiCacheは別途設定する機能です。どちらのエンジンでも、プロジェクト名からキャッシュの挙動を推測せず、実際に有効になっている設定を確認してください。SGLangのサーバー引数

エージェント向け機能：JSONは互角、アダプターとドラフト方式は検証が必要

JSONが必要というだけでは、どちらか一方が優位にはなりません。 両方とも、スキーマに制約された生成に対応しています。値の選択はモデルに任せ、構造には制約をかけ、アクションを実行する前に結果を検証しましょう。

JSONの構造化出力

vLLMは、response_formatとstructured_outputsのオプションを通じてJSON Schemaに対応しています。SGLangもJSON Schemaに対応し、デフォルトの文法バックエンドにはXGrammarを使います。これらは単にモデルへ「JSONを返してください」と指示するのではなく、デコード処理そのものに制約をかける仕組みです。vLLMの構造化出力、SGLangの構造化出力

サポートエージェントなら、スキーマでアクションとチケット識別子を必須にできます。ただし、そのチケットがリクエストしたユーザーのものか、選ばれたアクションが妥当かまでは保証できません。そうした確認はアプリケーションコードで行います。実際に使うスキーマ、推論モード、ストリーミングの挙動を組み合わせてテストしてください。各機能に個別に対応していても、その組み合わせが正しく動く証明にはなりません。

判定：一般的なJSON要件なら互角です。 代表的なスキーマ付きリクエストで具体的な差が見つからない限り、運用中のエンジンを使い続けるのがよいでしょう。

投機的デコーディング

投機的デコーディングは両プロジェクトで使える調整手段ですが、有効にすれば高速になるとは限りません。 ドラフト機構がトークンを提案し、ターゲットモデルが検証します。役立つ提案が受け入れられれば、逐次生成の処理を減らせます。ただし、ドラフト生成、検証、メモリにもコストがかかります。

vLLMはEAGLE、multi-token prediction、独立したドラフトモデル、n-gram方式、suffix方式を文書化しています。SGLangにもEAGLE、multi-token prediction、ドラフトモデル、NGRAMの手順があります。機能一覧に載っているかどうかより、ドラフトとターゲットモデルの適合性、ハードウェア、トラフィック量が重要です。vLLMの方式、SGLangの方式

判定：使用モデルに合うドラフト構成を検証できたエンジンを選びます。 まず基準値を測り、その後で投機的デコーディングを有効にして、応答レイテンシと全体の処理容量を比較しましょう。本番負荷で追加処理に見合う効果が出ないなら、無効のままにします。

テナントごとの振る舞いを変えるmulti-LoRA

両方とも、複数のLoRAアダプターを提供できます。LoRAアダプターは、共通のベースモデルをカスタマイズするために加える、追加学習で得られた小規模な重みです。 vLLMでは--lora-modulesでアダプターを登録でき、同時実行数とランクも制御できます。SGLangには--lora-pathsと--max-loras-per-batchがあり、ドキュメント上のバッチのデフォルト値は8アダプターです。これは顧客総数の上限ではありません。vLLMのLoRA、SGLangのLoRA

テナントごとに文章のスタイルなどを変えるサービスでは、未ロードのアダプターや頻繁な切り替えも含め、想定されるアダプターの利用分布でテストしましょう。SGLangのオーバーラップ読み込みオプションは、転送待ちを隠せる場合があります。一方、ドキュメントでは、複数アダプターのプリフィルをまとめてバッチ処理しにくくなり、最初のトークンまでのレイテンシが増える可能性も指摘しています。設定項目が多いからといって、処理容量が増えるとは限りません。

判定：アダプターの動作を検証済みのエンジンを維持します。 multi-LoRA対応だけでは、切り替える理由になりません。アダプターの読み込みや、キャッシュを多用するワークロードがボトルネックなら、SGLangを試す価値があります。TPUでは、そのバックエンド専用の機能対応表を確認してください。SGLang-JAXのガイドでは、multi-LoRAは引き続き開発中とされています。SGLangのTPU機能対応表

ハードウェア対応：多様な環境ではvLLMから検討

両プロジェクトとも、NVIDIA、AMD、TPU、CPUへの対応を掲げています。ただし、実際の対応範囲はバックエンドとモデルの組み合わせで決まります。 プロジェクト全体の対応ハードウェア一覧を見て、GPU向けの構成、アダプター、デコード方式がすべてそのまま使えると考えてはいけません。

• NVIDIA： vLLMはCUDA GPUへの導入手順を公開し、SGLangのリポジトリはデータセンター向け製品群とRTX製品群を挙げています。使用するリリースのイメージとホストのドライバーには互換性が必要です。vLLMのGPU導入手順、SGLangの対応ハードウェア一覧
• AMD： 両方ともROCmでのデプロイ方法を文書化しています。SGLangはInstinct MI300X、MI325X、MI350X、MI355Xを挙げ、専用の導入ガイドを用意しています。対応するROCmイメージとモデル構成を使ってください。SGLangのAMDガイド
• Google TPU： vLLMは、別のtpu-inferenceの導入手順へ案内しています。SGLangのTPUガイドは別バックエンドのSGLang-JAXを使い、v6eとv7を挙げています。いずれも独立したデプロイ経路であり、それぞれ機能の確認が必要です。vLLMのTPU導入手順、SGLangのTPUガイド
• CPU： vLLMはCPU向けの選択肢としてIntel/AMD x86やARM AArch64などを文書化しています。SGLangのCPUサーバーガイドは、第4世代以降のXeon Scalableプロセッサーに搭載されたIntel AMXを対象にしています。「CPU対応」でも、対応範囲が同じとは限りません。vLLMのCPUガイド、SGLangのCPUガイド

次のデプロイ先を決めるうえで、運用上の具体的な差が効くこともあります。vLLM 0.31.0は、デフォルトのCUDA 13.0イメージに加えてCUDA 12.9イメージを公開しています。一方、SGLangの現行導入ガイドはCUDA 13を必須とし、CUDA 12のイメージ提供は0.5.19で終了したと説明しています。 手元の環境を対応ドライバーへまだ移行できないなら、スループットの結果を比べる前に、この点を調べてください。vLLMのリリース成果物、SGLangの導入手順

OpenAI互換サーバー：クライアントの移行だけでは終わらない

どちらも、OpenAI形式のChat Completionsを使うクライアントの接続先にできます。 両方のドキュメントに/v1/chat/completionsと/v1/completionsが記載されており、アプリケーションの接続部分で置き換える範囲を減らせます。ただし、すべてのエンドポイント、拡張機能、ツールパーサー、モデルの挙動が互換になるわけではありません。vLLMサーバー、SGLang API

チャットテンプレートは、ロール付きのメッセージをモデルが想定するトークン列に変換します。エンジンを比較するときは、このテンプレートをそろえてください。そうしないと、気づかないうちに異なるプロンプトを比較することになります。モデルのリビジョン、トークナイザー、サンプリング設定、出力上限も統一します。

既存のvLLMクライアントを移行・アップグレードする場合は、出力制約に使う古いフィールドを確認してください。ドキュメントによると、guided_jsonと関連フィールドは0.12.0で削除されています。現在のコードでは、サポートされているstructured_outputsまたはresponse_formatの形式を使う必要があります。古いリクエストボディが原因でも、エンジン間の非互換に見える場合があります。vLLMの移行に関する注意点

判定：基本的なクライアントインターフェースは互角です。標準的な運用の選択肢としてはvLLMを勧めます。 受け入れテストでは、テキスト応答が一度成功しただけで終わらせず、ツール引数のストリーミング、エラー、リトライを含むエージェントのターン全体を確認しましょう。

GPUクラウドでそれぞれを動かす

バージョンを固定したコンテナと、動作確認用の小さなモデルから始め、後で本番モデルとメモリ配分に置き換えます。 以下の例は、各プロジェクトのDocker・起動コマンドのドキュメントを基にしています。Docker、NVIDIAコンテナランタイム、イメージと互換性のあるドライバーを備えたLinuxのNVIDIA GPUホストを想定しています。ドキュメントとは照合していますが、レンタルGPU上では実行していません。vLLMのDocker手順、SGLangクイックスタート

以下のQwen/Qwen3-0.6Bは接続確認用です。エージェントの回答品質を理由に推奨するモデルではありません。同じポートを使うため、エンジンは片方ずつ実行してください。コンテキスト上限は例として明示的に設定した値で、モデルが公称する最大値ではありません。

vLLMのコンテナ

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

SGLangのコンテナ

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

初期化が終わったら、GPUホスト上で次のリクエストを実行します。

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

この例では、ホスト側のポートをループバックにバインドしています。リモートユーザーに提供する前に、認証を行うアプリケーションゲートウェイをサーバーの手前に置いてください。特にvLLMでは重要です。ドキュメントには、--api-keyがHTTPサーバーの全ルートを認証するわけではないと明記されています。vLLMの認証範囲

Runpodが導入手順を公開しているvLLMワーカー

Runpodは、HubからすぐにデプロイできるvLLMワーカーを提供し、その手順を文書化しています。 このクラウドへの導入のしやすさが、標準的な運用向けにvLLMを勧める根拠です。ワーカーのパッケージは、エンジン本体とは別に配布されるデプロイ用成果物です。上流の最新リリースと同じだと思い込まず、同梱されたエンジンのバージョンを確認しましょう。Runpodのデプロイガイド

SGLangについて、ここで示す再現可能なクラウドへのデプロイ方法は、互換性のあるGPUホスト上で公式コンテナを使う方法です。上記のRunpodによる簡便な導入方法は、Runpodが文書化しているvLLMワーカー専用です。

料金の違い：同じGPU構成なら請求額も同じ

借りる処理容量が同じなら、どちらかのエンジンだけが安くなることはありません。 2026年10月14日時点で、Runpodの料金ページにはPods向けの80 GB搭載A100 PCIeが$1.79/時間と掲載されていました。これは専有GPUの料金であり、Serverlessワーカーの課金単価ではありません。以下の計算では、両エンジンに共通するインフラ費用の前提として使います。Runpodの料金

予算計算上の1か月を730時間とすると、GPUを1台常時確保する費用は、vLLMでもSGLangでも**$1,306.70/月です。2台なら$2,613.40/月**です。ストレージ、ネットワーク料金、冗長化、エンジニアリングの費用は含みません。

仮想のサポート用途として、月50,000リクエスト、各リクエストが入力2,000トークン、出力200トークンという共通条件を置きます。合計は入力1億トークン、ユーザーに返した出力1,000万トークンです。必要な応答時間を守りながらGPU 1台で処理できるなら、どちらのエンジンでもGPU費用はユーザーに返した出力1,000トークンあたり$0.13067になります。分母は出力トークンですが、この費用には入力を読み込む処理も含まれます。

これは費用の計算であり、処理容量の実測ではありません。そのワークロードを処理しきれない場合、GPU 1台という計算結果は適用できません。

費用の優劣が変わるのは、同じサービス目標を満たすために、どちらかの構成で追加のレプリカが必要になる時点です。SGLangならGPU 1台、vLLMなら2台が必要な場合、SGLangで月$1,306.70を削減できます。実測した処理容量の関係が逆なら、vLLMで同額を削減できます。両方とも1台で足りるなら、インフラ費用の差はゼロです。

移行作業を8時間、時間単価を仮に$100/時間とすると、費用は**$800です。このGPUを1台減らせれば、継続的な運用費の差を考慮する前の計算で、約0.61か月**で回収できます。レプリカを減らせず、サービス改善にも価値を見いだせないなら、「高速化」しても金銭的なリターンがまったく生まれない場合があります。

コスト面で選ぶべきなのは、より低い総運用コストで目標を満たす構成です。 自分たちのワークロードを安全に処理できる容量を測る前に、エンジンごとの損益が逆転するトラフィック量を示すことはできません。

スループット：レイテンシ目標を守って完了できる処理量で選ぶ

ここでは、あらゆる条件でスループットが勝るエンジンを特定していません。 プロジェクトが公開する結果は、そのモデル、ハードウェア、数値精度、リクエスト長、リリースにひもづきます。カーネルの改善はサービング全体の改善と同じではなく、プリフィルのスループットも出力トークンのスループットとは別です。どちらの数字も、そのまま「SGLangのほうが速い」「vLLMのほうが速い」と一般化すべきではありません。

出発点には、各プロジェクトの公式ツールを使えます。vLLMのベンチマークCLIとSGLangのサービングベンチマークガイドです。比較には、キャッシュが温まった状態と空の状態の両方に加え、自分たちのプロダクトで実際に発生するワークロードの特徴を反映する必要があります。

次の4条件は分けて測定してください。固定のシステムプロンプトを共有する短いチャット、同じ長文書への繰り返しの質問、取得する抜粋が変わる長いRAGプロンプト、そして実際に使うスキーマ・ツール呼び出し・アダプターの組み合わせです。同時実行数だけでなく、リクエストの到着タイミングも再現しましょう。同時に集中するバーストと、一定のペースで続くリクエストでは、異なるボトルネックが現れる場合があります。

完了したリクエスト数、ユーザーに返した出力トークン数、エラー、最初のトークンまでのレイテンシを記録します。平均が良好でも遅い応答が隠れるため、95パーセンタイルと99パーセンタイルに当たるp95・p99レイテンシも確認してください。アプリケーションのスキーマ検証や正しさのチェックに通らない出力は、有効な処理量に含めず失敗として数えます。

勝者は、これらの受け入れ条件を守れるデプロイ構成のうち、最も低コストなものです。別のモデルや古いリリースでの速度の主張は、この比較を行うきっかけにはなりますが、答えにはなりません。

エンジンの移行：入出力の仕様を維持し、元に戻せるようにする

実測した効果が移行費用と運用費用を上回る場合にだけ、サービング層を変更しましょう。 生成バックエンドだけを変えるなら、通常、アプリケーションのデータと検索用ストアはそのまま維持できます。主な作業は、モデルのパッケージ化、リクエストの拡張、出力の解析、デプロイ時の挙動にあります。

プレフィックスキャッシュやJSON制約を手に入れるためだけに、正常に動いているvLLMを置き換える必要はありません。どちらもすでに備えています。同様に、この記事でvLLMを標準的な選択肢として勧めているという理由だけで、正常に動いているSGLangを置き換える必要もありません。蓄積した運用ノウハウも、コスト比較の一部です。

そもそも本番用の共有サーバーが必要かどうかで迷っているなら、OllamaとvLLMの比較を参照してください。使いやすいローカルモデルのワークフローと、同時に発生するリクエストを処理するサービング層のどちらを選ぶかという、ひとつ前の段階の判断を扱っています。

次に行うことは、代表的なピーク時のトラフィックを記録し、許容できる応答時間とエラー率の上限を決めることです。GPUを増やす前に、同じハードウェア上で、バージョンを固定した両エンジンを比較しましょう。

よくある質問

AI業務ワークフロー監査チェックリストを使って、共有モデルサーバーを導入する価値のある業務を見極めましょう。ニュースレターに登録して、その後のツールの変化も確認できます。