MacでDockerのローカルLLMが遅い？ネイティブ実行とGPUのつながりを整理
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
Mac上のDockerでローカルLLMが遅いと感じる理由を、Metalを使うネイティブ実行、Linux VMのコンテナ、Docker Model Runnerの実行場所とAPI経路から整理します。
MacでDockerのローカルLLMを動かしたら、同じモデルなのにネイティブ実行より遅い。そんなとき、原因を「DockerだからCPUだけ」と決めつけるのは早計です。推論エンジンがどこで動き、GPUへどうつながるかで結果は変わります。Apple Siliconでまず速度を確かめるならネイティブのllama.cpp、アプリからAPIで使いたいならDocker Model Runner、Linuxコンテナ内で完結させたいならVM内コンテナが候補です。
この記事は公式資料と公開記事を照合した調査で、ここに書く環境を実行したり速度を測定したりしていません。Red HatのコンテナGPU転送も研究段階の実装紹介として扱い、一般的なDocker構成の測定値には置き換えません。
まず「どこで推論するか」を分ける
MacのDocker DesktopはLinuxコンテナをLinux VM内で動かします。ところがDocker Model Runner（DMR）のmacOS版は別の設計です。現在のDocker資料では、Mac上の推論エンジンはLinux VM内のコンテナではなく、ホスト側の隔離された実行環境で動くと説明されています。Apple Silicon上のllama.cppではMetalによる自動GPU利用が示されています。つまり、APIをコンテナから呼んでも、推論までそのコンテナ内で行われるとは限りません。
| 方式 | 推論する場所 | GPUへの主な経路 |
|---|---|---|
| llama.cppをMacへ直接導入 | macOS上のプロセス | Apple SiliconのMetal |
| llama.cpp公式Linuxコンテナ | Docker DesktopのLinux VM内 | 通常のLinuxコンテナ実行。Metalは直接呼べない |
| Docker Model Runner | Macホスト上の隔離プロセス | Apple SiliconではMetal。クライアントはAPI接続 |
| API転送の研究実装 | コンテナとMacホストに分かれる | GGMLの処理呼び出しをホストのMetalへ転送 |
図にすると、DMRは「コンテナからホスト推論APIへ」、研究実装は**「コンテナ内推論からGPU呼び出しだけホストへ」**という違いです。
「DockerならCPUだけ」ではない理由
macOSはLinuxカーネルを使わないため、標準的なLinuxコンテナの中からMacのMetal APIをそのまま呼び出すことはできません。llama.cpp公式DockerイメージにはLinux向けCPU版やCUDA、VulkanなどのGPU対応版がありますが、それぞれのバックエンドと対応機器が必要です。たとえばCUDA版はNVIDIA向けで、Apple GPUをCUDAで使うものではありません。Apple Silicon MacでLinux VM内のコンテナを起動しただけでは、Metal対応が加わるわけではありません。
一方、ネイティブ版llama.cppはmacOSでMetalが既定で有効になると公式ビルド資料にあります。Docker Model RunnerもMac向けの通常経路ではホスト側のllama.cppを隔離環境で実行し、モデルをOpenAI互換APIなどで提供します。ホストアプリからはhttp://localhost:12434/engines/v1、別コンテナからはhttp://model-runner.docker.internalがDocker公式資料に示された接続先です。ここでのAPIは「利用アプリと推論サービスの境界」であり、GPU転送方式そのものの名前ではありません。
Red Hatが2025年9月に紹介したのは、PodmanとlibkrunのLinux VMからGGML API呼び出しをMacホストへ転送し、ホスト側のMetalバックエンドにつなぐ試作です。記事では複数のMacで比較した結果が報告されていますが、これはRed Hatが記した特定版の試作構成による測定です。Docker Desktop標準機能やllama.cpp公式Dockerイメージの性能として読み替えないでください。分離境界をまたぐGPU呼び出しには、速度と隔離のトレードオフもあります。
また、Docker Model Runnerの公式リポジトリでは、担当者が9月26日に「llmmanへ移行するため非推奨にする」とコメントしています。一方、Dockerの公開ガイドは今もModel Runnerの使い方を案内しています。これは移行の兆候として受け止め、導入前に製品側の最新案内も確認してください。llama.cpp自体も10月2日にnightly b11344を公開しました。比較や再現では、モデルだけでなく実行ソフトの版もそろえましょう。
遅いと感じたら、この順で確かめる
- 実行方式を特定する。
docker runでllama.cppコンテナを立てているのか、Macに直接導入したllama-serverなのか、DMRのdocker model runなのかを分けます。 - 推論側のログを見る。 Metal、CUDAなどのGPUバックエンドが初期化されたか、CPUへフォールバックしていないかを実行ログで調べます。クライアントのAPI URLだけでは判断できません。
- モデルとメモリ条件をそろえる。 GGUFの量子化、モデルサイズ、コンテキスト長、同時処理数が違えば速度比較になりません。大きなモデルや長いコンテキストでは、GPU以前にメモリ圧迫や読み込み待ちが表面化します。
- 同じ条件で比較する。 同一Mac、同じモデルファイル、同じプロンプトと生成トークン数で、初回読み込みと2回目以降を分けて記録します。入力処理と生成速度も別々に見ます。
目的から方式を選ぶ
| 優先したいこと | 最初に試す方式 | 判断の目安 |
|---|---|---|
| Apple GPUの性能を素直に使う | ネイティブllama.cpp | Metalの挙動や速度を基準として調べやすい |
| アプリから同じAPIで呼びたい | Docker Model Runner | Mac上の推論エンジンをAPI経由で再利用しやすい |
| Linux環境との互換性を優先 | Linux VM内のコンテナ | VM・GPUバックエンド・CPU fallbackを個別に確認する |
| コンテナのままMacのMetalも使いたい | API転送方式を調査 | Red Hatの例は試作。製品の標準対応と混同しない |
速度だけでなく、環境再現性、隔離、対応モデル、API利用のしやすさも選択条件です。まずネイティブ版を基準にし、DMRと比較したいならAPI呼び出し時間を含め、VMコンテナならGPU認識ログも記録します。**「Dockerかどうか」ではなく「推論エンジンとGPUの間に何があるか」**を確認すれば、次に試す方式を絞れます。
本稿ではMacでのビルド手順は扱いません。導入とMetalの確認はMacでllama.cppを導入するガイド、Linux上のコンテナ起動はllama.cppのDockerガイド、DMRの配布形式とAPI境界はDocker Model RunnerのOCI・API解説を参照してください。
参考にした一次資料
- Docker Model Runner公式ガイド
- Docker Model Runnerの推論エンジンと対応環境
- Docker Model Runner REST APIと接続先
- llama.cpp b11344の公式ビルド資料
- llama.cpp b11344の公式Docker資料
- Red Hat: Reach native speed with MacOS llama.cpp container inference（2025-09-18）
- Docker Model Runner contributor comment on its transition to llmman（2026-09-26）
- llama.cpp b11344 nightly release（2026-10-02）
