11月6日、Vishal Bulbuleが「Ollama vs vLLM on Cloud Run with an NVIDIA L4: A Real Benchmark from 1 to 48 Concurrent Users」と題した記事を公開した。同一GPU・同一モデル上でOllamaとvLLMを1〜48同時ユーザーで実測比較し、スループット・レイテンシ・コストの観点から推論エンジン選定の指針を示している。
結論から言う：1ユーザーならOllama、4ユーザー以上ならvLLM
同じNVIDIA L4 GPU、同じGemma 4 E2Bモデル、同じ料金（$1.42/時）で計測した結果がこれだ。
- 1ユーザー時：Ollama 113 tok/s vs vLLM 47 tok/s（Ollamaが2.4倍速い）
- 32ユーザー時：vLLM 1,235 tok/s vs Ollama 160 tok/s（vLLMが7.7倍速い）
- コスト（32ユーザー時）：vLLM $0.32/百万トークン vs Ollama $2.47/百万トークン
この逆転の理由は明快だ。1ユーザーの場合、GPU処理のボトルネックはモデルの重みをメモリから読み出す速度であり、4-bitで量子化されたOllamaのモデル（GGUF形式）はBF16のvLLMより読み出しコストが低い。しかしユーザーが増えるにつれ、vLLMの連続バッチング（Continuous Batching）と**PagedAttention**が効いてくる。PagedAttentionはKVキャッシュをOSの仮想メモリのページング方式で管理する手法で、複数リクエストを同一ステップにまとめて処理する連続バッチングと組み合わせることで、重みの読み出しコストをユーザー間で分担できる（vLLM公式ドキュメントも参照）。
Ollamaはデフォルトで1リクエストずつ順番に処理する（OLLAMA_NUM_PARALLEL=1）。32ユーザーが押し寄せると後続はキューに積まれ、中央値TTFT（Time to First Token：最初のトークンが返るまでの時間）が48秒に達した。vLLMは同条件で0.47秒だ。
測定環境の概要
フェーズ1（元記事の基本計測）の環境は以下のとおりだ。同時ユーザー数は1・4・8・16・32の5段階で測定している。タイトルにある「1〜48同時ユーザー」のうち、32を超える領域（48ユーザー等）はフェーズ2以降の追加計測で扱われている。
| 項目 | 値 |
|---|---|
| GPU | NVIDIA L4（Cloud Run, europe-west1） |
| モデル | Gemma 4 E2B（有効パラメータ2.3B、埋め込み含む5.1B） |
| vLLM精度 | BF16 |
| Ollama精度 | 4-bit GGUF |
| 負荷パターン（フェーズ1） | 1 / 4 / 8 / 16 / 32同時ユーザー、各60秒 |
| 料金 | $1.42/時（L4 + 8vCPU + 32GiB） |
| クライアント | インド・プネー → europe-west1（ネットワーク往復込み） |
コールドスタートはOllamaが約4.5分（Cloud Storageマウントから4-bitモデル読み込み）、vLLMが約7分（Hugging Faceからダウンロード）。両サービスとも最終リクエストから約10分でゼロインスタンスにスケールダウンした。
フェーズ2：Ollamaに32並列スロットを与えたらどうなるか
フェーズ1の公開後、読者から「OllamaのTTFTの悪化はキューイングの影響であり、並列処理を許可すれば改善するはずだ」という指摘があった。これを受けて著者は同一記事内でOLLAMA_NUM_PARALLEL=32を設定した追加計測（フェーズ2）を実施した。この段階で32を超える同時ユーザー（最大48ユーザー）への計測も行われており、タイトルの「1〜48同時ユーザー」はフェーズ1・2を合わせた範囲を指している。
フェーズ2の結果：
- Ollamaの32ユーザー時 中央値TTFTが 48秒 → 1.5秒 に改善
- スループットが 160 → 359 tok/s に向上
- それでもvLLMは 1,235 tok/s（3.4倍の差）、コストは $0.32 vs $1.10/百万トークン
また、フェーズ2の計測中に判明した点として、Ollama 0.40.13はGemma 4に対して投機的デコーディング（Speculative Decoding）をデフォルトで有効にしていた（ドラフト受理率≈0.41、平均長≈2.2）。投機的デコーディングは小さなドラフトモデルが先読みしたトークン列を本モデルが一括検証する手法で、受理されれば1ステップで複数トークンを確定できる。vLLMはこれを使っていない。1ユーザー時のOllamaの高速性には、4-bit量子化に加えてこの要因も含まれる。
GPU使用率82%でも実効スループットは7.7分の1
Cloud RunのGPUメトリクス（container/gpu/utilizations）を確認すると、Ollamaはベンチマーク中に79〜83%のGPU使用率を記録していた。一方でスループットはvLLMの7.7分の1だ。
GPU使用率は「GPUが何かを実行している時間の割合」であり、「GPUの処理能力をどれだけ活用しているか」ではない。1リクエストずつ処理するエンジンでも、GPU使用率は高く見える。
著者はこう結論づけている。LLMサービングの効率指標は「トークン数/秒/ドル」であり、GPU使用率でもGPUメモリ使用率でもない。
これはCloud Runの設計とも整合する。Googleのドキュメントには「Cloud RunはGPU使用率に基づいて自動スケールしない」と明記されており、スケールのトリガーはリクエストの同時実行数だ。
オートスケールの落とし穴：課金されるが誰も使わないGPUインスタンス
Cloud Runのオートスケール挙動にも注目すべき知見がある。
1インスタンスで処理しきれない負荷がかかると、Cloud Runは最初のインスタンスがまだ余裕がある段階で2台目を起動する。その2台目が実際にリクエストを受け付けられるようになるまで6分21秒かかり、その間もGPUの課金は走る。
フェーズ2では、Ollamaの新規インスタンスへのルーティング問題も確認された。Cloud Runがモデルのロード完了約4分前に新インスタンスへトラフィックを誘導し始め、p95 TTFTが274秒に達した。ヘルスチェックのプローブ設定が重要な理由がここにある。vLLMのデプロイ設定では/healthエンドポイントへのスタートアッププローブを用いてモデルロード完了を確認してからトラフィックを受け付けるよう構成されている。
エンジン選定の実務的指針
記事の結論を整理すると：
- 開発・個人用途（同時1〜数ユーザー）：Ollamaが速くシンプル。セットアップコストも低い
- API・サービス（4ユーザー以上）：vLLMが同一ハードウェア・同一コストで圧倒的に有利
- スケールアウト時：Cloud Runのウォームアップ遅延とGPU課金の空白時間を考慮した設計が必要
- GPU使用率はスケールのシグナルにならない：Cloud Run自身もリクエスト同時実行数でスケールしている
詳細はOllama vs vLLM on Cloud Run with an NVIDIA L4: A Real Benchmark from 1 to 48 Concurrent Usersを参照していただきたい。
