Ollama vs vLLM：本番環境に適したLLMランタイムはどちら？

Ollama と vLLM の選択は、デプロイの簡便さと並行負荷下での生スループットとのトレードオフを判断することになります。この対決は現在、オープンウェイト LLM を自己ホストするインフラストラクチャの決定の大部分を構成しており、社内エージェントの提供やマルチテナント API の公開など、あらゆる場面に適用されます。ここでは、アーキテクチャ、GPU NVIDIA 上で測定可能なスループット、メモリ管理（KV キャッシュ、PagedAttention）、サポートされるライセンスとフォーマット、運用コストの観点から、これら 2 つのランタイムを比較します。最後に、モデルサイズ別の推奨事項と技術的な FAQ で締めくくります。目標は、プラットフォームエンジニアが 15 分未満の読み時間で判断できるようにすることです。

アーキテクチャと設計思想：2つのランタイム、2つの世界

Ollama は、 llama.cpp, GB単位で表され、シンプルなHTTP APIを提供し、モデルGGUFのダウンロード、キャッシュ、動的ロードを管理します。ターゲットは開発者向けマシン（Mac Mシリーズ、RTX搭載デスクトップPC）および軽量のシングルテナントデプロイメントです。その下位のランタイムは透明なCPUオフロードを実装しており、これにより Qwen 2.5 72B Instruct （Q4でのVRAM使用量は約42 GB）を、システムRAMに一部を退避させながら、24 GBのRTX 4090で実行できます。ただし、スループットは低下します。

vLLMは、UC Berkeleyが公開した、多数のリクエストの同時処理に最適化されたPythonサーバーです。主な貢献は PagedAttentionは、OSが仮想メモリを管理するのと同じようにKVキャッシュを管理します。固定サイズのブロック、ページング、リクエスト間での共有を用います。具体的には、単純なランタイムでは断片化によってKVキャッシュの60～80％が無駄になるのに対し、vLLMでは4％未満に抑えられます。その結果、負荷に応じて総スループットは2～24倍になります。ただし、導入には制約があります。GGUF量子化をネイティブにサポートせず、CUDAに必須依存し、モデル全体をVRAMに収める必要があります。

llama.cpp と vLLM のサーバー側アプローチの違いについて詳しく知りたい場合は、当社の llama.cppとvLLMの比較完全ガイド.

スループットとレイテンシ：数値が示すこと

公開されている測定結果は一点に収束しています。並行負荷下では、vLLM が圧倒的に優位です。ある Llama 3.3 70B Instruct （70B、コンテキスト128 000）を4基のA100 80 GBでFP8形式で提供する場合、通常は次のような結果が観測されます（バッチサイズに応じて確認が必要）：

MoEモデルにおいても差がさらに広がっています。 Mixtral 8x22B Instruct (141B、Apache 2.0、ctx 64K) ではvLLMがマルチGPUによるテンソル並列処理を効率的に活用し、llama.cppが達成しづらい性能を発揮します。非常に大きなMoEモデルについては、 DeepSeek V3 671B または Qwen 3 235B-A22Bについては、vLLMがマルチユーザー向けの本番運用で依然として唯一の現実的な選択肢です。特に、エキスパート並列処理をネイティブにサポートしていることがその理由です。

一方、単一ストリームでの使用で強力な量子化（Q4_K_M、Q5_K_M）を適用した場合、Ollamaは最初のトークンの遅延（TTFT）において比較的優れ、7B〜13Bモデルにおいてはランタイムの軽量化により、場合によっては優れた性能を発揮します。消費型GPU向けの詳細ベンチマークについては、当社の LLM向けRTX 4090とRTX 5090の比較.

量子化、フォーマット、実際のVRAM

ここが2つのランタイムが根本的に分岐する点です。Ollamaは排他的に GGUF (Q2_KからQ8_0まで、FP16対応)。この柔軟性により、 Llama 3.1 70B （Q4 で約 40 GB）を単一の RTX A6000 48 GB に。vLLM は HuggingFace のネイティブ重み（FP16、BF16）を受け入れ、現在では AWQ、GPTQおよびFP8、ただし、安定した本番運用ではGGUFに対応していません。

VRAM Q4のいくつかの参考データ quelllm.fr カタログ :

小規模なデプロイメント向けに、 gpt-oss 120B et Mistral Small 4 は、扱いやすいサイズ、制約の少ないライセンス、両方のランタイムへの対応という、バランスの取れた選択肢です。当サイトのモデル紹介をご覧ください： Mistral Small 4 詳細なベンチマークについては

ライセンスとコンプライアンス

ランタイムの選択はライセンス条件に影響しません。条件を決めるのは モデル が条件を定めます。欧州での典型的な運用例は以下の通りです

詳細な情報は、私たちの オープンソースLLMライセンスガイド およびコミュニティの追跡については、以下のページをご確認ください HuggingFaceモデル.

ユースケース：用途ごとにどちらを選ぶべきか？

以下の条件に該当する場合に Ollama を選択してください - 開発者用PCまたは単一のGPUワークステーションに社内アシスタントを導入する - 複数のモデルを素早く切り替えながら試行を重ねたい（API経由でのホットスワップ） - 同時ユーザー数が5人未満である - RTX 3090/4090/5090またはMac Studio M3 Ultraを想定している - 試してみたい dots.llm1 Instruct (142B、MIT、Rednote) または Hunyuan-A13B Instruct クラスタを設定せずに

次の場合はvLLMを選んでください： - ロードバランサーの背後でAPIを提供し、毎秒20件を超えるリクエストを処理している - 2、4、または8基のGPUでテンソル並列処理を行っている - PagedAttention、投機的デコーディング、連続バッチ処理を活用したい - 大規模なMoEモデルを対象としている： DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - ご使用に必要な Llama 4 Scout 109B 10Mトークンのコンテキストを備えたマルチテナントサーバーでの提供

第三の選択肢も紹介しておきます： Text Generation Inference HuggingFace、両者の中間として、ネイティブでサポートされています Mistral Medium 3.5 128B およびファミリー Llama。vLLMクラスターをオーケストレーションするには、 Ray Serve 引き続き定番です。

GPU バUDGETに応じたおすすめは、当サイトの 構成選択ガイド およびページ GPUサーバー向けの最適なLLM.

運用コストと可観測性

Ollama は運用の簡素化で優位です: 単一バイナリ、最小限のテレメトリ、1コマンドでのモデル更新。隠れたコストは、細粒度メトリクスの欠如です (最近の安定版には Prometheus ネイティブサポートがない、要確認)。vLLM はネイティブで Prometheus用のエンドポイント 初回トークンまでの時間、リクエストごとのスループット、KVキャッシュの使用状況を備え、Grafanaと直接連携します。

GPUコストについては、適切に調整したvLLMクラスターは、同等のマルチインスタンスOllama構成に比べ、100万トークンあたりのコストを3分の1〜8分の1に抑えます。この差は、継続的バッチ処理とKVキャッシュの断片化がほとんどないことによります。使用モデルが Qwen3-Coder-Next 80B-A3B （MoE、Apache 2.0）の場合、読者からの報告（要確認）によると、2× H100上のvLLMで合計約14,000 tokens/secであるのに対し、RTX 6000 Adaを使ったOllamaの単一ストリームでは約80 tokens/secです。

チューニングについてさらに深く知りたい場合は、 vLLM公式ブログ と当サイトの vLLM と TGI の比較.

FAQ

Q：Ollamaは本番環境で複数のユーザーに同時にサービスを提供できますか？

技術的にははい、ただし制限があります。Ollama は内部のキューを介して複数のリクエストを処理できますが、効果的な継続的なバッチ処理は実現できません。モデル70Bに対して3〜5人の並列ユーザーを超えると Llama 3.3 70B Instruct、p95の遅延が著しく悪化します。本格的なマルチテナント運用には、vLLMまたはTGIが技術的に適切です。

Q：vLLMはQ4 GGUFのような低ビットの量子化に対応していますか？

GGUFネイティブではありません。vLLMはFP8、AWQ、GPTQを優先し、品質とVRAMのバランスを異なる方法で提供します。それらは DeepSeek R1 671Bには、HuggingFaceで公開されている公式のAWQ 4ビット版があり、vLLMで動作します。GGUF Q4_K_Mをそのまま使うなら、Ollamaかllama.cppを直接使ってください — これらが得意とする形式です。

Q：Qwen 3 235B-A22BなどのMoEモデルには、どのランタイムを選べばよいですか？

迷わずvLLMをおすすめします。MoEモデルは、vLLMが標準で実装しているエキスパート並列化と継続的バッチ処理の恩恵を大きく受けます。 Qwen 3 235B-A22B （Apache 2.0、コンテキスト131K）は、8基のH100からなるクラスタ上でもOllamaでは遠く及ばない総スループットを達成します。当サイトのモデル解説をご覧ください： Qwen 3 235B-A22B.

Q：Ollama を Kubernetes クラスタ上で使用することは可能ですか？

はい、コミュニティによる Helm チャートは存在しますが、Ollama はホライズンスケーリング（stateless）を設計していません。各 pod がモデルを再読み込み、GGUF キャッシュは共有されません。Kubernetes ナイフ環境では、vLLM がより適切に統合されます。 KServe およびその専用オペレーターです

Q：Llama 4 Scout 109Bとその10Mのコンテキストを扱うには、どのランタイムを選べばよいですか？

vLLM で稀な注意を有効にします。10Mのコンテキストを Llama 4 Scout 109B にはKVキャッシュの管理が必要であり、それをコスト面で実用的にできるのはPagedAttentionだけです。Ollamaでも技術的にはモデルを読み込めますが、1000万トークンのKVキャッシュは、ページングなしではVRAM使用量を激増させます。vLLMまたはTGIでの使用に限定してください。

Q：Apple Silicon搭載Macで使える、この2つに代わる選択肢はありますか？

はい： MLX d'Apple は Metal に最適化されており、M3 Ultra で Llama モデルなどに対して Ollama を上回ります DeepSeek R1 Distill Llama 70Bしかし、マルチユーザー対応Macのサーバーは限定的な導入です。詳細は当社の Mac M3 Ultra向けのLLMガイド.

結論

Ollama と vLLMの議論は、ターゲットの負荷によって決まります：Ollama はプロトタイピング、シングルユーザー、Mac向けに適しています。一方、APIのマルチテナント、MoEの大量構成、テンソル並列化を考慮する場合、vLLMが適しています。あなたのVRAMとターゲットライセンスに合ったモデルとランタイムの組み合わせを特定するには、当社の 構成ツール または、次のカタログに登録されている249のモデルをご覧ください： quelllm.fr カタログ.

記事公開日： 著者： Mohamed Meguedmi · データソース： /api/models.json · コンテンツのライセンス： CC BY 4.0.

報告したい誤りや更新情報はありますか？ 参加する.