vLLM vs Ollama vs SGLang — LLM サービングフレームワークの選択

インフラ AI
読了 5分

自己ホスティングをすると決めたら(損益分岐の計算 参照)、次の問いは「何でサービングするか」です。同じ GPU に同じモデルを載せても、フレームワークによってスループットが数倍変わります。結論を先に書くと、ノート PC・ローカル実験は Ollama、多ユーザーのプロダクションは vLLM が基本で、複雑なプロンプト構造やエージェントのワークロードは SGLang を検討します。 サーバー規模の推定は LLM サーバー規模 で扱ったので、この記事はその上で動くソフトウェアの選択です。

二つの分岐 — ローカル実行 vs プロダクションのスループット #

フレームワークは目的の異なる二つの分岐です。一つは「1 台で簡単に動かす」、もう一つは「多数のユーザーを高いスループットで受ける」です。この二つを混ぜると選択が狂います。

  • Ollama は llama.cpp の上に作ったローカル実行ツールです。ollama pull でモデルを取得すると、すぐに OpenAI 互換 API がローカルに立ちます。インストールと使用が最も単純で、CPU+GPU の混合実行で VRAM が不足する環境でも動きます。代わりに連続バッチングも、PagedAttention も、マルチノードもありません。 同時ユーザーを高いスループットで受ける用途ではありません。
  • vLLM はプロダクションのスループットのためのエンジンです。PagedAttention と連続バッチングで、同じ GPU で Ollama の 3〜4 倍のスループットを出します。多ユーザーサービングの事実上の標準です。
  • SGLang は vLLM と同じ高スループットの系統でありながら、複雑なプロンプト構造(分岐、多段、構造化出力)とプリフィックスキャッシュに強みがあります。エージェント・複合パイプラインのワークロードで有利な区間があります。

スループットはなぜ分かれるか — PagedAttention と連続バッチング #

vLLM・SGLang が Ollama を大きく上回る理由は二つの技法です。

  • 連続バッチング(continuous batching): バッチが終わるのを待たず、生成ステップごとに新しいリクエストを回っているバッチに差し込みます。リクエストごとに長さがまちまちな LLM の特性上、短いリクエストが先に終わって空きが出れば、すぐに新しいリクエストで埋めます。GPU が遊ぶ時間が減ります。
  • PagedAttention: KV キャッシュをオペレーティングシステムのページのように分割して管理します。メモリの断片化が減り、同じ VRAM により多くの同時リクエストが入ります。

数値で見ると、ベンチマークで vLLM が毎秒数百トークン台、Ollama が数十トークン台になる事例がよくあります。負荷が高いほど差が広がり、同時ユーザー 5〜10 人程度の軽い負荷では差が縮まります。つまり 少人数ならどちらでも動きますが、ユーザーが増えるほど vLLM 系のエンジンが必須になります。このスループットがそのまま 損益分岐 のトークンあたりの原価を決めます。

2026 年の地形変化 — TGI がメンテナンスモードに #

しばらく vLLM の代替に挙げられていた Hugging Face の TGI(Text Generation Inference)は、2025 年 12 月にメンテナンスモードに移行しました。今はバグ修正とドキュメントの PR だけを受け付け、Hugging Face は新しい Inference Endpoint に vLLM または SGLang を推奨しています。古い比較記事が TGI を主要な選択肢に置いているなら、その部分は古くなっています。今のプロダクションの三つ巴は、事実上 vLLM、SGLang、そして特殊用途の TensorRT-LLM(NVIDIA スタックの最適化)です。

機能の軸 — 量子化、構造化出力、互換性 #

スループットのほかに、実務で分かれる軸です。

  • 量子化のサポート: vLLM は AWQ・GPTQ・FP8 など主要な方式を幅広く受けます(量子化比較 参照)。Ollama は GGUF 中心です。どの量子化ファイルをサービングするかが、フレームワークの選択を狭めることもあります。
  • 構造化出力: JSON スキーマの強制や文法制約デコードが必要な場合、SGLang と vLLM の両方がサポートしますが実装の成熟度が異なります。エージェントのツール呼び出しのように出力形式が厳格なワークロードなら、この部分を先に見ます。
  • API 互換性: 三つとも OpenAI 互換 API を提供するので、クライアントのコードを変えずに API から自己ホスティングへ乗り換えられます。損益分岐 で述べたハイブリッドの移行が容易な理由です。
  • 運用の成熟度: vLLM はコミュニティが大きく、新モデルのサポートが速いです。新しいモデルが出た直後にサービングする必要があるなら、サポートの速さが実質的な基準になります。

選択の手順 #

  1. 用途からふるいにかけます: ローカル実験・プロトタイプ・1 人利用なら Ollama で足ります。多ユーザーのプロダクションなら vLLM 系です。
  2. スループットの要求を数えます: 同時ユーザーが少数ならどれでも動きますが、増える計画なら最初から vLLM で始めて書き直しを避けます。
  3. ワークロードの性格を見ます: 単純なチャット・補完なら vLLM、分岐・多段・構造化出力の多いエージェントパイプラインなら SGLang を比較します。
  4. 量子化ファイルと合わせます: サービングするモデルの量子化形式(GGUF vs AWQ/GPTQ)がフレームワークのサポートと合うかを確認します。
  5. 古い選択肢をふるい落とします: TGI の新規導入は避け(メンテナンスモード)、NVIDIA スタックの極限の最適化が必要なときだけ TensorRT-LLM を検討します。

まとめ #

  • フレームワークはローカル実行(Ollama)とプロダクションのスループット(vLLM・SGLang)の二つの分岐です。目的を混ぜると選択が狂います。
  • vLLM・SGLang が Ollama を 3〜4 倍上回る理由は連続バッチングと PagedAttention です。ユーザーが増えるほど差が広がります。
  • TGI は 2025 年 12 月にメンテナンスモードへ移行しました。今のプロダクションの標準は vLLM、代替は SGLang です。
  • 量子化形式のサポート、構造化出力の成熟度、新モデルのサポート速度が、スループット以外の選択軸です。
  • ローカルは Ollama、多ユーザーは vLLM を基本、複雑なエージェントのワークロードは SGLang を比較するのが実務の基本線です。
X