試作はOllama、本番はvLLM。乗り換えのタイミングと20倍の性能差
「Ollamaで検証がうまくいったので、そのまま社内に公開したら遅くて使いものにならない」。ローカルLLMの社内展開で最も多いつまずきがこれです。原因はOllamaの性能不足ではなく、道具の役割の違いにあります。Ollamaは1人で使う分には最適ですが、同時アクセスが来る本番サーバーでは、vLLMとの間に桁違いの差が出ます。本記事では、2つのツールの設計思想の違い、性能差の実測値、そして「いつ・どう乗り換えるか」の判断基準を整理します。
この記事の要点
- 単発リクエスト（1人利用）ではOllamaが約45トークン/秒と、vLLM（約38トークン/秒）よりやや速いこともあります。検証用途ではOllamaが最適です
- 差が出るのは同時アクセスからです。同時8リクエストでvLLMが約2.3倍、高負荷ではRed Hatの検証で20〜29倍のスループット差が報告されています
- 移行を検討する目安は「同時5人超・APIでの組み込み・応答待ちの苦情・GPU使用率が上がらない」の4つのサインです
- vLLMはOpenAI互換APIのため、アプリ側の変更は接続先URLの差し替え程度で済むことが多い一方、モデル形式（GGUF→Hugging Face形式等）とVRAM要件の再確認が必要です
OllamaとvLLMの違い（競合ではなく役割の違い）
2つのツールは同じ「LLMを動かすソフト」でも、設計思想が正反対です。まず前提となる役割の違いを整理します。
| 観点 | Ollama | vLLM |
|---|---|---|
| 想定用途 | 個人・開発用 | 本番サーバー用 |
| 設計思想 | 手軽さ最優先 | スループット最優先 |
| 使い勝手 | コマンド1つでモデル取得から実行まで完結。CPU/GPUも自動で使い分け | 多数の同時リクエストをGPU上で束ねて処理する前提の設計 |
| 同時処理 | 既定では同時処理数を絞った設計 | 連続バッチングによる高同時処理が前提 |
つまり「どちらが優秀か」ではなく、「何人で使うか」で答えが決まる問題です。1人で試作する段階と、数十人が同時に使う本番運用とでは、求められる性質がまったく異なります。この役割分担を理解しないまま検証構成をそのまま公開してしまうことが、冒頭のつまずきの正体です。
OllamaとvLLMの性能差はどこから来るか（ベンチマークの読み方）
公開ベンチマークの傾向を整理すると、構図がはっきりします。
| 条件 | Ollama | vLLM | 差 |
|---|---|---|---|
| 単発リクエスト（1人利用） | 約45トークン/秒 | 約38トークン/秒 | Ollamaがやや速いことも |
| 同時8リクエスト | 約82トークン/秒 | 約187トークン/秒 | vLLMが約2.3倍 |
| 高同時（数十リクエスト） | 処理落ち・待ち行列が発生 | 全リクエスト完走 | スループットで20倍超の報告 |
重要なのは1行目です。1人で使う限り、Ollamaは何も悪くありません。むしろ手軽さの分だけ優秀です。差が開くのは同時アクセスからで、Red Hatの検証では高負荷時にvLLMが20〜29倍のスループットを記録しています。
この差の源泉は、vLLMが備える2つの技術にあります。
- 連続バッチング: 複数のリクエストを同じGPU処理に相乗りさせる仕組みです。Ollamaは既定で同時4リクエストまでの逐次処理寄りの設計のため、リクエストが増えると待ち行列が伸びていきます
- PagedAttention: 会話文脈（KVキャッシュ）のメモリ管理を効率化し、同時接続数を増やしてもGPUメモリを無駄にしない技術です
なお「トークン/秒」という速度指標そのものが何で決まるのかは、『ローカルLLMの速度はメモリ帯域で決まる。スペック表の正しい読み方』で詳しく解説しています。ハードウェア選定の前提知識として併せてご覧ください。
Ollamaを卒業するサイン（vLLM移行を検討するタイミング）
次のどれかに当てはまったら、vLLMへの移行を検討するタイミングです。
| サイン | 状況 |
|---|---|
| 同時利用者が増えた | 5人を超えたあたりから応答待ちが目立ち始めます |
| 応答待ちの苦情が出る | 「誰かが使っていると返ってこない」という声が上がります |
| 他システムからAPIで叩く | チャットボット・業務システム組み込みは同時アクセスが前提です |
| GPU使用率が上がらない | リクエストが並んでいるのにGPUが遊んでいる状態は、逐次処理の限界を示しています |
中間帯もあります。社内数人での共有であれば、Ollama+Open WebUIの構成でまだ耐えられます。全社公開や業務システムへの組み込みが見えた時点でvLLMに切り替える、というのが現実的な線引きです。
逆に言えば、1人での検証段階でvLLMを選ぶ必要はありません。手元のマシンで何が動くかは『予算別ローカルLLM PC 2026。10万・30万・60万・100万円で何が動くか』を、GPUサーバーを構えずに始める構成はMacで始める社内専用AI導入支援を参考にしてください。
vLLM移行の最小手順と2つの注意点
vLLMはOpenAI互換のAPIサーバーとして動くため、移行後もアプリ側の変更は接続先URLの差し替えだけで済むことが多いです。最小の手順は次の通りです。
# インストール(Linux + NVIDIA GPU環境)
pip install vllm
# OpenAI互換サーバーとしてモデルを起動
vllm serve Qwen/Qwen3.5-9B-Instruct --port 8000ただし、Ollamaとの違いとして2点に注意が必要です。
- モデルフォーマットが違います: OllamaはGGUF中心、vLLMはHugging Face形式やAWQ/GPTQ/FP8量子化が中心です。Ollamaで使っていたモデルファイルをそのまま流用することはできないと考えておくのが安全です
- GPU要件が上がります: vLLMは同時処理用のメモリ（KVキャッシュ領域）を確保するため、同じモデルでもVRAMに余裕が必要です。単発ぎりぎりで動いていた構成では動かないことがあります
「アプリ側の改修は小さいが、モデルとハードウェアの前提は変わる」というのがvLLM移行の実態です。移行前に、使いたいモデルのvLLM対応形式が入手できるか、手元のGPUのVRAMに余裕があるかを必ず確認してください。
vLLM本番運用で追加で考えること（認証・監視・モデル更新）
vLLMに載せ替えて終わりではなく、本番公開には運用の設計が必要です。最低限、次の3点を決めてから公開することをおすすめします。
- 認証とアクセス制御: vLLM自体は認証機能を持たないため、リバースプロキシ側で実装します
- レート制限・利用ログ・監視: 死活監視とGPUメモリの監視が中心になります
- モデル更新の手順と切り戻し: 新モデルへの載せ替え手順と、問題があった際に旧構成へ戻す手順をあらかじめ用意しておきます
構成の定番は「vLLM+リバースプロキシ+フロント（Open WebUIや自社アプリ）」の3層です。そしてこの運用を誰が回すのかという体制の問題が、実は技術選定よりも重要です。詳しくは『導入したローカルLLM、誰が維持するのか。挫折の最大要因は運用担当者問題』で扱っています。また、本番構成を持つことの費用対効果をクラウドAPIと比較したい場合は『オンプレLLMは本当に安いのか。3年TCOと損益分岐点を正直に計算する』が判断材料になります。
段階移行のすすめ（検証→部門→全社の3ステップ）
規模ごとの現実解を3段階で整理します。
| 段階 | 規模 | 構成 |
|---|---|---|
| 検証 | 1人 | Ollama（ノートPC・手元マシン） |
| 部門利用 | 〜10人 | Ollama+Open WebUI（共有サーバー） |
| 全社・システム組込 | 数十人〜 | vLLM+プロキシ+フロント（GPUサーバー） |
段階を飛ばさないことがポイントです。検証段階でvLLMを立てるのは過剰投資ですし、全社公開をOllamaのまま迎えるのは冒頭のつまずきの再現になります。各段階でどの程度の費用がかかるのかは『ローカルLLM導入費用の実額内訳。PoC300万円〜本番1,500万円の中身を開示する』で開示しています。GPUサーバーでの本格構成をご検討の場合はローカルLLM導入支援をご覧ください。
vLLM移行前チェックリスト
移行判断と移行作業の前に、次の項目を確認してください。埋まっていない項目は、移行後のトラブルの火種になります。
- 同時利用者数を把握した（5人を超えているか）
- APIでの組み込み予定（チャットボット・業務システム連携）の有無を確認した
- リクエストが並んでいるのにGPU使用率が上がらない状態が起きていないか確認した
- 使いたいモデルのvLLM対応形式（Hugging Face形式・AWQ/GPTQ/FP8量子化）が入手できることを確認した
- VRAMにKVキャッシュ分の余裕があることを確認した（単発ぎりぎりの構成は不可）
- 認証の実装方法（リバースプロキシ側）を決めた
- レート制限・利用ログ・監視（死活・GPUメモリ）の設計をした
- モデル更新と切り戻しの手順を用意した
- この構成の運用担当者を決めた（最大の挫折要因です）
まとめ
- 1人ならOllamaで十分です。単発リクエストでは約45トークン/秒と、vLLM（約38トークン/秒）よりやや速いことすらあり、検証用途では最適な選択です
- 差が出るのは同時アクセスからです。同時8リクエストでvLLMが約2.3倍、高負荷ではスループットに20倍超（Red Hatの検証で20〜29倍）の差が付きます
- 移行の目安は「同時5人超・APIでの組み込み・応答待ちの苦情・GPU使用率が上がらない」の4つのサインです
- vLLMはOpenAI互換APIのためアプリ側の変更は小さい一方、モデル形式（GGUF→Hugging Face形式等）とVRAM要件は再確認が必要です
- 本番公開には認証・監視・モデル更新の運用設計と、それを回す担当者の確保が欠かせません
よくある質問
Q. OllamaとvLLMはどちらが速いですか？
利用人数によって答えが変わります。単発リクエスト（1人利用）ではOllamaが約45トークン/秒、vLLMが約38トークン/秒とOllamaがやや速いこともあります。しかし同時8リクエストではvLLMが約187トークン/秒とOllama（約82トークン/秒）の約2.3倍になり、数十リクエストの高負荷ではRed Hatの検証で20〜29倍のスループット差が報告されています。1人ならOllama、同時アクセスが増えるならvLLMという役割の違いです。
Q. OllamaからvLLMに乗り換えるタイミングはいつですか？
目安となるサインは4つです。（1）同時利用者が5人を超えて応答待ちが目立ち始めた、（2）「誰かが使っていると返ってこない」という苦情が出た、（3）チャットボットや業務システムからAPIで叩く計画がある、（4）リクエストが並んでいるのにGPU使用率が上がらない。いずれかに当てはまったら移行を検討するタイミングです。
Q. Ollamaのまま社内で共有利用できますか？
社内数人での共有であれば、Ollama+Open WebUI（共有サーバー）の構成でまだ耐えられます。目安として10人程度までの部門利用がこの構成の範囲です。全社公開や業務システムへの組み込みが見えた時点で、vLLM+リバースプロキシ+フロントの3層構成に切り替えるのが現実的な線引きです。
Q. Ollamaで使っていたモデルはvLLMでそのまま使えますか？
そのままの流用はできないと考えておくのが安全です。OllamaはGGUF形式中心なのに対し、vLLMはHugging Face形式やAWQ/GPTQ/FP8量子化が中心で、モデルフォーマットが異なります。移行前に、使いたいモデルのvLLM対応形式が入手できるかを確認してください。
Q. vLLMへの移行でアプリ側の改修は必要ですか？
多くの場合、接続先URLの差し替え程度で済みます。vLLMはOpenAI互換のAPIサーバーとして動作するためです。ただしハードウェア側では、vLLMが同時処理用のKVキャッシュ領域を確保する分、同じモデルでもVRAMに余裕が必要になります。単発ぎりぎりで動いていた構成では動かないことがある点に注意してください。
Q. vLLMの本番運用では何を準備すべきですか？
vLLM自体は認証機能を持たないため、リバースプロキシ側での認証・アクセス制御が必須です。加えてレート制限・利用ログ・監視（死活とGPUメモリ）、モデル更新の手順と切り戻しの用意が必要です。構成の定番は「vLLM+リバースプロキシ+フロント」の3層です。この運用を誰が回すかという体制の問題は『導入したローカルLLM、誰が維持するのか』で扱っています。
Q. vLLMはなぜ同時アクセスに強いのですか？
2つの技術が理由です。1つは連続バッチングで、複数のリクエストを同じGPU処理に相乗りさせます（Ollamaは既定で同時4リクエストまでの逐次処理寄りの設計です）。もう1つはPagedAttentionで、会話文脈（KVキャッシュ）のメモリ管理を効率化し、同時接続数を増やしてもGPUメモリを無駄にしません。この2つにより、高負荷でも全リクエストを完走させられます。
主な参考資料: Ollama vs. vLLM: A deep dive into performance benchmarking(Red Hat Developer)、ollama vs vLLM Throughput Benchmark 2026(Markaicode)、Benchmarking Ollama and vLLM for Concurrent LLM Serving(Applied Sciences)
本番構成の設計から相談したい方へ
TodoONadaでは、ローカルLLM・生成AIの導入判断からPoC・構築までを支援しています。
- 検証構成（Ollama）から本番構成（vLLM）への移行設計
- 同時利用者数に合わせたGPUサイジングと負荷検証
- 認証・監視・モデル更新まで含めた運用設計
まずは30万円・2週間規模のミニ検証から始められます。「今の構成で何人まで耐えるのか」という負荷測定だけでも、お気軽にご相談ください。
この記事に関連するサービス
TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。
- ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
- Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- Red Hatの検証 （2026年7月6日確認）
- ollama vs vLLM Throughput Benchmark 2026(Markaicode) （2026年7月6日確認）
- Benchmarking Ollama and vLLM for Concurrent LLM Serving(Applied Sciences) （2026年7月6日確認）
