ローカルLLM比較：OllamaとvLLMの選び方と移行の判断基準

ローカルLLM比較：OllamaとvLLMはどちらを選ぶべきですか？

ノートPC、個人用アシスタント、すでに十分な応答速度が出ている小規模な社内サービスなら、Ollamaを使い続けてよいでしょう。リクエストが継続的に重なる共有GPUサービスや、分散推論を明示的に制御したい環境には、vLLMが向いています。 サーバーで動かすというだけで、切り替える必要はありません。

Ollamaは、モデルのダウンロード、設定、配信をコンパクトな手順にまとめたモデル実行ツールです。vLLMは、多数のリクエストのスケジューリングと、それらが使う作業用メモリの管理を中心に設計された推論エンジンです。どちらもモデルそのものではありません。同じアプリケーションを移行する場合、変わるのはモデルの動かし方です。

判断の軸は、ピーク時の同時リクエスト数、利用できるGPUメモリ、実際に使うモデルの配布ファイル、そしてユーザーに約束するレイテンシーの4点です。登録ユーザー数だけでは判断できません。エージェントを動かす少人数の開発チームのほうが、ときどき質問する大人数のグループより、多くの処理を同時に発生させることもあります。

ソフトウェア料金とドキュメントは2026年10月12日に確認しました。本記事はドキュメントに基づく比較と費用の試算であり、推論ベンチマークは実施していません。Ollamaの公開料金ページにはローカルでの無料利用が記載され、vLLMのプロジェクトライセンスでもソフトウェア料金なしでの利用が認められています。 Ollamaの料金、vLLMのライセンス。

機能の記述は、公式のOllama並列処理ドキュメント、vLLMの機能概要、vLLMのスケーリングガイドに基づいています。推奨は、記載されている機能に対する編集上の判断であり、実測速度の順位ではありません。

ユーザー数・GPU・モデルサイズから候補を絞る

以下は、最初に何を評価するかを決めるための目安であり、処理能力の保証ではありません。 ここでいう「ユーザー」は、同時に処理を発生させる人やエージェントを指し、人数の区分は計画を立てるための例です。8Bモデルは、そのモデルを定義する数値であるパラメータを、およそ80億個持っています。

モデルサイズだけでは、購入するGPUを決められません。理想化したDense型の8Bモデルを重みあたり4ビットで格納すると、重みだけの下限は4 GBです。70Bモデルなら35 GBになります。 計算式は「パラメータ数 × ビット数 ÷ 8」で、10進表記のバイト数を使っています。量子化メタデータ、高精度のテンソル、ランタイム、会話用メモリが、この下限に加わります。どちらの数値も、推奨VRAM容量ではありません。

そのため、「モデルをロードできた」だけでは合格とはいえません。重みが収まっても、ユーザーが継続する会話のための容量が足りない場合があります。まずコーディング向けローカルモデルのガイドでチェックポイントを選び、その後で配信時の負荷に必要な構成を見積もります。

インストールとハードウェア：最初の1台はOllamaが手軽

手元のハードウェアで役立つモデルを動かすことが当面の目的なら、Ollamaが有利です。 デスクトップ版のダウンロードとコマンドライン中心の操作により、導入時に決める項目を減らせます。Linux向けに案内されているインストール手順は次のとおりです。

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

サーバーがまだ起動していなければ、ollama serveを使います。Linuxガイドには、サービスとして起動する方法も記載されています。他の人のリクエストを受け付ける用途なら、ターミナルを開いたままにするより、常駐サービスにするほうが適しています。

Ollamaは、MetalによるApple GPUアクセラレーション、ROCm経由の一部AMDハードウェア、NVIDIA GPU、さらにVulkan経由で追加のWindows/Linuxデバイスに対応しています。NVIDIA向けのページでは、現在compute capability 5.0以上を挙げており、古いカードではドライバー要件が異なります。使うカードとOSの組み合わせを、Ollamaの対応ハードウェア一覧で確認してください。

インストールを出発点として、管理された推論配信環境を整えるなら、vLLMが有利です。 現在のNVIDIA向けクイックスタートでは、分離したPython環境を使います。uvと互換性のあるGPUドライバーがインストール済みであれば、ドキュメント上の手順は次のとおりです。

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

これらはドキュメントに基づくセットアップ用コマンドであり、本比較のために実行したものではありません。AMDとIntelでは、別のバックエンド向け手順に従います。vLLMクイックスタート。

vLLMのNVIDIA向けインストール手順では、Linuxとcompute capability 7.5以上が指定されています。この手順はWindowsネイティブ環境には対応しておらず、ドキュメントではWindowsユーザーにWSLを案内しています。対応ハードウェアはNVIDIAだけではありません。インストール一覧にはAMD ROCm、Intel XPU、CPU向けの手順に加え、コミュニティが保守するvLLM-Metalプラグイン経由のApple Siliconも含まれます。GPU要件、インストール一覧。

Apple向けの構成では、MLXとMLX向けに最適化されたモデルを使います。CUDAサーバーと同じ挙動を前提にせず、独立したバックエンドとして評価すべきです。Macを中心に使うなら、最初の選択肢としては引き続きOllamaのほうが手軽です。主な関心がデスクトップ上の作業環境にある場合は、別記事のOllamaとLM Studioの比較をご覧ください。

OllamaとvLLMの性能差：分かれ目は同時リクエスト

同時リクエストが継続的に発生する用途では、その負荷に直接対応するスケジューリング機能がドキュメントに示されているvLLMを、まず検討するのが妥当です。 スループットは、一定時間内に完了できる処理の総量を指します。単独のリクエストにどれだけ早く回答が返るかとは、別の指標です。

vLLMは、処理中のリクエストが進むのに合わせて新しい処理を受け入れる継続的バッチ処理と、テキスト生成時のKey/Valueキャッシュを管理するPagedAttentionを挙げています。このキャッシュは一般にKVキャッシュと呼ばれ、会話のトークンを扱うためのモデルの作業用メモリです。vLLMの機能概要。

チャンク単位のプリフィルは、長いプロンプトを読み込む処理を小さく分割し、進行中の回答生成とスケジューリングの時間を共有できるようにします。プレフィックスキャッシュは、繰り返し使うシステムプロンプトなど、プロンプトの先頭部分が一致するときに処理結果を再利用します。効率化できるのはプロンプトの処理であり、新しい回答トークンを生成する処理がなくなるわけではありません。スケジューリングと調整、プレフィックスキャッシュの制約。

Ollamaも並列リクエストに対応しています

Ollamaのドキュメントには、メモリの範囲内で、モデルごとにリクエストを並列処理し、複数モデルを同時にロードできると記載されています。前者を制御するのがOLLAMA_NUM_PARALLEL、後者がOLLAMA_MAX_LOADED_MODELSです。OLLAMA_MAX_QUEUEは待機中の処理数を制限し、過負荷時にはサーバーがHTTP 503を返すことがあります。現在のFAQでは、並列リクエスト数の既定値は1です。Ollamaの並列処理設定。

小規模なサポート用アシスタントなら、許可する同時処理数を増やすだけで足りる場合があります。ただし、キューを長くしても計算能力は増えません。最初のトークンが届くまで顧客を長く待たせるだけになることもあります。サーバーが受け付けられる最大キュー長ではなく、応答目標に合わせて調整してください。

ユーザー向けに残したつもりのメモリを、コンテキストが使うこともあります

エンジンを比較する前に、コンテキスト長を明示的に設定してください。 Ollamaのコンテキスト専用ページではメモリに応じた既定値が説明されている一方、FAQには固定の既定値が残っています。この記述の不一致も、ノートPCとサーバーの設定が同じだと思い込まず、実際に適用されている設定を確認すべき理由です。ollama psで、ロード済みのコンテキスト長とCPU/GPUへの配置を確認できます。Ollamaのコンテキストに関するガイド。

設定例として、8,192トークンの会話を4件並列で処理する場合、合計32,768トークン分のコンテキスト容量を確保します。4,096トークンの会話1件と比べると、コンテキストの合計容量は8倍ですが、プロセス全体のRAM使用量が8倍になるわけではありません。モデルの重みなど、ほかのメモリ割り当ては同じ比率で増えないためです。このコンテキスト容量の増え方は、Ollamaの並列処理ドキュメントでも説明されています。

vLLMもメモリの制約からは逃れられません。調整ガイドでは、KVキャッシュの容量不足によってプリエンプションと再計算が発生し、レイテンシーが悪化する可能性を指摘しています。同時シーケンス数やバッチのトークン上限を減らす方法もあれば、GPUを追加する方法もあります。スケジューラーが高機能でも、マシンに存在しないメモリを生み出すことはできません。

切り替えを検討するタイミングは、適切に調整しても、実際の利用を代表するピーク負荷でサービスの目標を満たせないときです。 最初のトークンまでの時間、回答完了までの時間、成功したリクエスト数、キューの増加、エラーを記録してください。ユーザーが気づくのは遅いケースなので、中央値だけでなく、遅い側のパーセンタイルも比較します。vLLMには、この確認に使える本番運用向けのメトリクスがあります。

モデルのリビジョン、精度、プロンプト長、出力上限、トラフィックのパターンをそろえてください。Ollama上の小さな量子化モデルと、vLLM上の大きな高精度チェックポイントを比べても、それはデプロイ構成同士の比較であり、エンジンだけの性能を切り分けた測定にはなりません。

量子化形式：モデルの載せ替えも移行作業に含まれます

既存のローカルモデルパッケージを生かすならOllama、ハードウェアに合わせて配信用の形式を選ぶならvLLMが有利です。 量子化は、モデルの値を低い精度で保存して、必要なメモリを減らします。ファイルコンテナ、量子化方式、実行バックエンドの互換性は、それぞれ別に確認する必要があります。

Ollamaは、Safetensors形式の重みと、単一ファイルおよび分割されたGGUFモデルのインポート方法を公開しています。GGUFは、ローカル推論でよく使われるモデルのファイル形式です。Ollamaの現在のインポートガイドでは、GGUFの量子化はインポート中ではなく、事前に行う必要があるとされています。一方、create APIでは、インポート時の量子化例としてnvfp4を挙げています。ただし、あらゆるアーキテクチャとGPUで使えることを意味するものではありません。Ollamaのインポートガイド、create API。

OllamaはKVキャッシュ用にf16、q8_0、q4_0も挙げています。これらはキャッシュの設定であり、そのままモデルの重みの形式一覧として扱えるものではありません。量子化キャッシュを使うにはFlash Attentionが必要です。Ollamaのキャッシュに関するドキュメント。

vLLMは、AWQ/GPTQ、FP8、INT8、INT4、MXFP4/MXFP8、NVFP4などの量子化方式との連携を挙げています。対応状況は実装とハードウェアによって異なるため、「4ビット対応」だけでは調達の判断材料として不十分です。使うチェックポイントとカーネルの正確な組み合わせを確認してください。vLLMの量子化ドキュメント、形式の概要。

トークナイザーは、テキストをモデルが理解するトークンIDに変換します。重み、トークナイザー、チャットの書式、量子化を変えると、回答、ツール呼び出し、メモリ使用量も変わる可能性があります。モデルファミリーの名前が同じでも、回帰テストの工数を見込んでください。

Mellum2.1に見る、配布形式を確認すべき理由

JetBrainsによる2026年10月8日のMellum2.1発表は、サーバー向けの提供が先行するリリースの例です。その投稿では、Ollama、llama.cpp、LM Studio向けのGGUFビルドは近日公開とされていました。リリースのモデルページにはvLLMでの配信手順があり、公開時の連携先にはvLLMと、別の推論サーバーであるSGLangが含まれています。JetBrainsの発表記事、リリースページ。

公開時にあった差は、すでに縮まっています。 10月12日の確認時点で、JetBrainsの公式GGUFリポジトリにはダウンロード可能な量子化ファイルがありました。発表記事の「近日公開」を、そのまま現在の提供状況と受け取らないでください。新しいモデルを使うためだけにエンジンを変える前に、現時点の配布ファイルと配信手順を確認することが、実務上の教訓です。公式GGUFファイル。

OpenAI互換サーバー：クライアントを引き継ぎ、挙動を確認する

どちらもOpenAI互換サーバーを提供していますが、リクエストの形式が一致しても、挙動まで同じとは限りません。 OllamaのローカルベースURLはhttp://localhost:11434/v1/、vLLMの例ではhttp://localhost:8000/v1を使います。アプリケーションがOllama独自の/api/chatを使っている場合、移行にはポートの変更だけでなく、APIへの対応が必要です。Ollamaの互換性ドキュメント、vLLMのサーバードキュメント。

たとえば、対応ハードウェアにvLLMをインストールした後、次のコマンドでドキュメントのサーバー例と同じモデルを配信できます。コンテキストの上限と、アプリケーションから見えるモデル名を明示しています。

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

これはセットアップの例です。先ほどのOllamaコマンドと同じチェックポイントではなく、本番環境の構成規模を推奨するものでもありません。--served-model-nameを使うと、デプロイ構成が変わっても、クライアント側では同じモデル名を維持できます。vLLMのエンジン引数。

メッセージのロールをモデルの入力形式に変換するチャットテンプレートを確認し、サンプリングパラメータを明示的に設定してください。vLLMは、リポジトリのgeneration_config.jsonにある既定値を適用することがあります。--generation-config vllmを指定すると、この上書きを無効にできます。ツール呼び出しの解析、構造化出力、ストリーミング、キャンセル、エラー処理を、アプリケーションが実際に送るリクエストで比較してください。

認証も移行作業の一部として扱ってください。 Ollamaのローカル互換性の例では、クライアントのAPIキー値は無視されます。vLLMはAPIキーに対応していますが、セキュリティドキュメントでは、それですべてのエンドポイントが保護されるわけではないと注意しています。バックエンドは非公開にし、サービスの入口で認証、TLS、ルート制限を適用してください。vLLMのAPIキーの制約。

アプリケーションがベースモデルを頻繁に切り替える場合は、別の移行コストもあります。vLLMのFAQでは、複数のベースモデルを扱うために、別々のサーバーインスタンスとルーティング層を使う構成を説明しています。API上の別名を付けても、別のモデルがロードされるわけではありません。利用頻度の低い社内ツールなら、複数のロード済みモデルを管理できるOllamaのほうが便利な場合があります。vLLMの複数モデルに関する制約。

料金の違い：同じ処理量でも運用費用は変わります

セルフホスト時のトークン単価の安さで、どちらかが勝つわけではありません。エンジンによるトークン課金はないためです。 Ollamaの有料クラウドプランは別のサービスであり、ローカルモデルを配信するための必須条件ではありません。この違いはOllamaの料金ガイドで説明しています。現在のクラウドプランは、上でリンクした提供元の料金ページを参照してください。

所有するハードウェアでは、月額費用に電気代、ハードウェア費の配賦、作業時間を含めます。レンタルの場合は、見積もられたマシンの利用時間を出発点に、ストレージ、ネットワーク、運用費を加えます。推論の効率化が経済的な効果につながるのは、確保するリソースを減らせる、課金対象の稼働時間を短縮できる、または金額に換算できる事業上の価値が生まれる場合です。

条件をそろえた予算の試算

以下は予算を試算するために明示した仮定であり、ベンダーの料金やベンチマーク結果ではありません。GPUは1時間あたり$1、月730時間、正常に完了するジョブは100,000件とします。各ジョブはプロンプト2,000トークン、出力1,000トークンで、両エンジンともモデル、量子化、品質基準、レイテンシー目標を同じにします。

常時レンタルするGPU 1基で両方が条件を満たすなら、コンピューティング費用はいずれも月額$730です。これは、成功したジョブ1件あたり、および出力1,000トークンあたり$0.0073に相当します。この出力トークンあたりの計算では、プロンプト処理の量を一定にしています。入力と出力を合算したトークン単価ではありません。

次に、vLLMの運用に毎月追加で2時間かかるとし、時間単価を$100と仮定します。さらに、初回のみ移行作業4時間を見込みます。

• 基準となるOllama構成： 両者に共通する費用を加える前で、月額$730。
• 同じハードウェア上のvLLM： 月額$930、出力1,000トークンあたり$0.0093。
• 移行費を含むvLLMの初月： $1,330、出力1,000トークンあたり$0.0133。

この作業時間は、自分の見積もりに置き換えるための入力値です。移行に実際に何時間かかるかを示したものではありません。共通の運用作業、ストレージ、ネットワーク料金、税金は、どちらの計算からも除いています。

どこで費用の優劣が逆転しますか？

このGPU時間単価では、追加運用費の仮定を相殺するために、vLLMで月200 GPU時間を超える削減が必要です。 移行作業費$400も初月に全額回収するなら、必要な削減量は600 GPU時間を超えます。

常時稼働の例として、自分で行った負荷テストで、同じ処理量と応答目標を満たすためにOllamaでは同一構成のGPUレプリカが2つ、vLLMでは1つ必要だったとします。この場合、Ollamaのコンピューティング費用は$1,460になり、vLLMのコンピューティング費用と追加運用費の合計は$930のままです。この条件なら月額$530を削減でき、移行費$400を約0.75か月で回収できます。

これは損益分岐点の計算であり、vLLMなら必要なGPUを半分にできるという主張ではありません。必要なハードウェアが同じで、移行を正当化する別のメリットもなければ、ソフトウェア料金の比較がvLLM有利に逆転することはありません。特定のユーザー数を超えれば有利になる、という普遍的な境界も示せません。

OllamaからvLLMへの移行チェックリスト

モデルとAPIの挙動を検証し、元に戻せるルートの背後で移行してください。 ダウンロードした重みは、ユーザーが依存する構成の一部にすぎません。

Ollamaがサービスの目標を満たしている、必要なモデルに検証済みのvLLM利用手順がない、あるいは動いているパッケージを不慣れなバックエンドに置き換えるだけなら、まだ移行するべきではありません。ノートPCではOllama、共有サーバーではvLLMを使う構成も合理的です。ただし、開発環境と本番環境が同じだと思い込まず、差分をテストしてください。候補を広く検討する場合は、Ollamaの代替ツールも参照してください。

次に行うことは明確です。実際の利用を代表する最も混雑した時間帯の処理を記録し、許容する応答時間を定めます。追加の処理能力を購入する前に、その負荷を候補のサーバーで再現してください。

よくある質問

AI業務ワークフローの監査チェックリストを使って、どの社内ワークフローに共有モデルサーバーを用意する価値があるかを判断してください。その後のツールの変化は、ニュースレターでお届けします。