社内の開発者やSREチームに、ローカルLLM（大規模言語モデルを手元のマシンで動かす仕組み）の実行環境を配布する場面で、Docker Model RunnerとOllamaのどちらを標準にするか迷うケースが増えています。この記事は、開発者ごとに環境が微妙に異なってしまい、モデルの挙動やAPIの呼び出し方が揃わずに困っている運用担当者に向けて、判断材料を整理したものです。
両者はどちらも内部でllama.cpp（C++で書かれた軽量な推論エンジン）を使うケースが多く、生成速度そのもので優劣を語るのは難しいというのが実情です。実際に2025年4月時点で取得された集計値では、Ollamaが平均11,982.18ミリ秒・平均24.65トークン/秒、Docker Model Runnerが平均12,872.06ミリ秒・平均24.53トークン/秒という近い数字が報告されています。ただしハードウェア構成、モデルの量子化方式、コンテキスト長、ウォームアップの有無が揃っていない比較のため、この数字だけで「どちらが速いか」を結論づけるのは早計です。速度で選べない以上、SREやインフラ担当者が見るべきは運用面の設計です。
どんな場面でこの選定が必要になるか
典型的には、複数の開発者が同じLLMを使ってプロトタイプを作る際、環境差異による再現性の欠如が問題になります。あるいは、社内の推論基盤をコンテナオーケストレーション（Kubernetesなど複数コンテナを管理する仕組み）に統合したいが、既存のOllama運用をどう扱うか迷っている場合もあります。GPUを使ったより高スループットな推論を検討し始めたタイミングでも、この比較が必要になります。
判断軸1: 配布と再現性の担保しやすさ
Ollamaはインストールスクリプト一発でセットアップが完了し、ollama run gemma4 のようにモデル名を指定するだけで起動できます。手軽さは大きな利点ですが、Dockerイメージのようなレイヤー管理やタグ付けの仕組みは前提にしていません。
一方Docker Model Runnerは、モデルを「アーティファクト（成果物）」としてDocker CLIやDocker Desktopの管理下に置く設計です。docker model pull ai/smollm2 のように、既存のDockerイメージ管理と同じ感覚でモデルを取得・バージョン管理できます。すでにDockerfileやdocker-composeでインフラをコード化（IaC）している組織であれば、モデルの管理もその延長線上に乗せられる点は無視できません。
判断軸2: API互換性とアプリケーション接続
OllamaはネイティブのREST APIを http://localhost:11434 で公開しています。非ストリーミングのリクエストは以下のように送れます。
curl http://localhost:11434/api/chat \
-H 'Content-Type: application/json' \
-d '{
"model": "gemma4",
"messages": [
{ "role": "user", "content": "Reply with exactly: ready" }
],
"stream": false
}'Docker Model Runnerは、OpenAI互換とOllama互換の両方のAPI面を提供しています。既存のOpenAI SDKベースのコードをそのまま指すエンドポイントを変えるだけで動かせる可能性がある点は、複数チームでコードを共有している組織にとって移行コストを下げる要素になります。
判断軸3: バックエンドの選択とGPU対応の広さ
Docker Model Runnerは、デフォルトでGGUF形式（量子化済みモデルのファイル形式）の推論にllama.cppを使いますが、NVIDIA GPU向けの高スループット処理にはvLLM、画像生成にはDiffusersというバックエンドを選択できます。docker model run ai/smollm2 --backend llama.cpp のように、実行時にバックエンドを明示的に指定することも可能です。
Ollamaもllama.cppを中核バックエンドとして採用していますが、バックエンドを差し替える運用は前提にされていません。将来的にGPU種別や推論エンジンを使い分けたい計画があるなら、この差は設計段階で効いてきます。
判断軸4: 障害切り分けのしやすさ
オブザーバビリティ（システム内部の状態を外から観測できる仕組み）の観点では、どちらのツールもコールドスタート時間・メモリの常駐状態・キャッシュ状況を厳密に切り分けて計測する標準機能を備えているとは言えません。ダウンロード時間、モデルロード時間、プロンプト評価時間、生成時間が混在した状態で「遅い」と報告されるケースは珍しくなく、これは運用チームが独自に計測ポイントを設計する必要がある領域です。
Docker Model Runnerであれば docker model ps で稼働中モデルの状態を確認でき、Dockerの既存の監視ツール（cAdvisorやDocker統計API）と組み合わせやすいという利点があります。Ollama側は専用のモニタリング面が薄く、OSレベルのプロセス監視やAPIのレスポンスタイム計測を別途組み込む必要があります。
| 観点 | Ollama | Docker Model Runner |
|---|---|---|
| 導入の手軽さ | インストールスクリプト1本で完結 | Docker Desktop/Engineの設定が前提 |
| API互換性 | 独自RESTのみ | OpenAI互換・Ollama互換の両対応 |
| バックエンド選択 | llama.cpp固定運用が中心 | llama.cpp/vLLM/Diffusersを切替可能 |
| 既存IaC資産との親和性 | 単体ツールとして独立 | Dockerイメージ管理の延長で扱える |
ケース別の推奨
- 個人の検証や小規模チームでとにかく早く動かしたいなら、Ollamaを選ぶのが妥当です。インストールから起動までの手順が短く、学習コストも低いためです
- すでにDocker Composeやコンテナベースのデプロイパイプラインを持つ組織なら、Docker Model Runnerがそのパイプラインに乗せやすく、IaCとの整合性を保ちやすくなります
- NVIDIA GPUでの高スループット推論や画像生成モデルの追加を計画しているなら、バックエンド切替の柔軟性からDocker Model Runnerに分があります
- OpenAI SDK前提で書かれた既存コードを大量に抱えているなら、API互換性の広さからDocker Model Runnerの導入コストが低くなる可能性があります
あえて見送るべき条件
生成速度の差を根拠にどちらかを選ぶのは避けるべきです。前述の通り、両者とも同じllama.cppに依存する場面が多く、公開されている集計値もハードウェアや量子化条件が統一されていません。「速いから」という理由での標準化は、後から別のベンチマークで覆される可能性が高い判断です。
また、Docker環境をまだ持たないチームが、この比較のためだけにDocker Desktopの導入を急ぐのも見送ってよい選択です。Model Runnerのメリットは既存のDocker運用と組み合わさって初めて生きるため、Dockerを使っていない環境に単体で持ち込む価値は限定的です。
導入前に確認すること
どちらを選ぶにしても、まず自組織の既存インフラがコンテナベースかどうかを確認するのが出発点です。次に、複数チームで共有するAPI仕様がOpenAI互換を前提にしているかを洗い出してください。
そのうえで、docker model status や ollama run を実際に手元で叩き、モデルのダウンロード時間・初回応答時間を自組織のハードウェアで計測し直すことをおすすめします。公開されている速度比較の数値をそのまま鵜呑みにせず、自分たちの環境で再現した数値をSLO（サービスレベル目標）設計の基礎データにするのが確実です。