Ollama vs vLLM vs SGLang：オープンLLM推論サービング入門

オープンウェイトのモデルを手元に落とすこと自体は簡単です。本当に初心者がつまずくのは、どう動かすか——とくに複数人が同時に答えを求めるようになったとき——の選択です。

自前ホスティングの話にほぼ必ず出てくるのが Ollama、vLLM、そして SGLangの三つです。同じ製品の味違いではありません。それぞれ別のサービング課題を解き、選び間違えると「GPUは余っているのにAPIが遅い」という感覚になりがちです。

このガイドでは、各エンジンの役割、平易な言葉での内部の違い、ベンチマーク表を暗記せずに選ぶシンプルな方法を順に見ていきます。

推論エンジンが実際にやっていること

モデルファイルは重みです。推論エンジンは、その重みを実トラフィック下でトークンに変えるランタイムです。モデルの読み込み、Attention状態（KVキャッシュ）のGPUメモリ管理、どのリクエストを一緒に走らせるかの決定、トークンのストリーミング返却までを担います。

ノートブックでのチャットは一件のリクエストです。プロダクトのサービングは、開始と終了のタイミングがずれた多数のリクエストの重なりです。エンジン同士の差は、主にバッチの賢さと、すでに計算した作業の再利用の仕方にあります。

三つのエンジン、三つの役割

Ollama：まずローカルDemoを出す

Ollamaはセットアップ速度と開発体験を優先します。モデルをプルすればOpenAI互換エンドポイントが立ち、CUDAビルドと格闘せずにプロンプトを回せます。内部はllama.cpp系のGGUF実行に寄り、本番GPUサーバーより控えめなリクエスト経路です。

これは意図した設計です。同時実行がほぼ自分一人、あるいは少人数の試作なら非常に優秀です。一方、数十〜数百の重なり合うリクエストに安定したレイテンシを求める用途には向きません。「API」が実質ノートPC上の共有プロセスなら、モデル品質より先に待ち行列と速度のばらつきを感じるはずです。

vLLM：GPUを空きなく回す

vLLMが本番のデフォルトになったのには理由があります。連続バッチでは、終わったリクエストがバッチを抜け、新規が他全員の完了を待たずに入れます。PagedAttentionはKVキャッシュを固定サイズのブロックで管理し——リクエストごとに巨大な連続領域を確保するよりOSのページングに近い——断片化によるVRAMの無駄を減らします。

実務では、素朴なループよりはるかに多くの同時ユーザーを一枚のGPUでさばけます。トラフィックが互いに独立したプロンプト（ユーザーが違い、共有コンテキストが少ない）なら、vLLMが最初の本番選択としていちばん無難です。モデル対応の幅も広く、ロードマップが四半期ごとに変わるチームにも効きます。

SGLang：すでに計算したものを再利用する

SGLangはvLLMと同じ高スループット陣営にいますが、看板はRadixAttentionです。計算済みのKVプレフィックスを基数木に保持し、新しいリクエストが同じプロンプト先頭を共有すれば再利用します。長いシステムプロンプト、共有RAG文書、伸びていく多ターン履歴を、毎回ゼロからやり直す必要はありません。

スケジューラもプレフィックス意識があり、キャッシュヒットしやすい仕事を優先します。エージェントのツールループ、固定の前置きがあるチャットボット、同じ構造が繰り返される制約デコード（JSONスキーマ、正規表現）で特に効きます。

リクエストが端から端までほぼ毎回ユニークなら利点は縮み、運用慣れとモデル対応で選べば足ります。トークンの半分以上が共有プレフィックスに乗るなら、本格的な比較検証の価値があります。

並べて比較

実務での選び方

公開のスループット数字はリリースごとに動きます。方向性として捉え、運命とは思わないこと。標準化する前に、自分のプロンプトでTTFTと毎秒トークンを測り、使えるならプレフィックスキャッシュを有効にしてください。

初心者がやりがちな失敗

まとめ

Ollamaはほぼ摩擦ゼロでローカルのチャットAPIまで連れていきます。vLLMは汎用トラフィックで同じGPUからより多くの同時ユーザーを引き出します。SGLangは共有プレフィックスが支配的なとき——エージェント、RAG、多ターンシステム——に元が取れます。

チャート上の「勝者」ではなく、今日のワークロードがある場所から始めましょう。同時実行やプレフィックス再利用がボトルネックになったときにエンジンを移す——ブログ記事に言われたからではありません。