MacのローカルLLMはどこで動く？Metal・仮想マシン・API経由の違い
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
macOSのネイティブ推論、Docker DesktopのLinux VM、Docker Model Runner、API remotingを実行境界とMetal接続から比較。公式仕様と未実測の限界を整理します。
「コンテナでLLMを動かす」と聞くと、推論処理もモデルもすべてコンテナ内にあるように思えます。しかしMacでは、アプリケーションの起動場所、推論エンジンのプロセス、GPUバックエンドが別の境界に分かれる場合があります。**APIの呼び出し元と推論の実行場所は同じとは限らず、GPU性能を左右するのはMetalまでの経路です。**本稿はその経路を仕様から整理します。
三つの境界を切り分ける
Mac上のコンテナはLinuxカーネルを必要とするため、Docker DesktopはLinux VMを介します。VMにCPU・メモリを渡しても、それだけでmacOSのMetal deviceがLinux guestに現れるわけではありません。通常のOCI Linux imageはLinux向けbackendで動きます。Apple GPU用Metal backendを含むネイティブmacOS buildとは、実行ファイル、OS API、device accessが異なります。
| 構成 | アプリ／クライアント | 推論エンジン | Metalへの呼び出し |
|---|---|---|---|
| ネイティブllama.cpp | Mac上 | Mac上のllama.cpp process | 同じホストからMetal backendを利用 |
| 通常のDocker image | Macまたは別container | Docker DesktopのLinux VM内 | 標準Linux imageからは直接呼び出さない |
| Docker Model Runner | Macまたは接続container | macOSではホスト上の隔離環境 | Runnerのllama.cpp backendがMetalを利用 |
| API remoting試作 | Linux VM内container | GGML計算は分担 | GPU API呼び出しをホストMetal側へ転送 |
この表では「APIを経由すること」と「GPU APIを転送すること」を分けています。OpenAI互換HTTP endpointを使うだけなら、クライアントは推論要求を送る側であり、Metal APIを直接触りません。
Model Runnerは「コンテナ内の推論」とは限らない
DockerのModel Runner overviewは、モデル管理とAPI提供をDockerに統合します。ところが同じ公式資料は、Linuxでは推論engineがcontainer内で動作する一方、macOSとWindowsではengineはcontainer内ではなく、macOSはsandbox-exec／Seatbeltで隔離されると説明します。Inference engines資料はApple Silicon向けllama.cppのMetal自動利用を掲載しています。したがってMacでdocker model runを実行した場合、Docker CLIやモデル管理の存在だけを根拠に「Linux VMがMetal推論している」とは言えません。
HTTPの接続先も実行場所とは別の情報です。Docker Desktopでは、host processからのAPI base URLはhttp://localhost:12434/engines/v1、別containerからのURLはhttp://model-runner.docker.internal/engines/v1です。後者はcontainerからRunnerへの接続名で、推論serverがそのcontainerにいるという意味ではありません。なおModel Runner APIは認証されず、到達可能なclientはモデルを操作して推論できるとDockerは注意しています。ネットワーク到達範囲も性能と別に確認が必要です。
2026年9月26日、Docker Model Runner repositoryの担当者は公開issueのコメントで、同機能をllmmanへ移行するため非推奨にすると述べています。一方でDockerのModel Runner文書は公開されたままです。このコメントを終了日や正式な移行計画と読み替える根拠は確認できません。新規構成でAPI互換性を長期前提にするなら、Dockerの最新製品案内と代替候補の保守状況を確認してから設計してください。
API remotingは別の機構
Red Hatの2025年9月の紹介では、Podman machineが起動したLinux VMのcontainer側にggml-remotingfrontendを、Mac host側にggml-remotingbackendを置く試作構成が説明されています。VirtIO virt-gpuと改変版virglrendererを経由してGGMLの処理呼び出しを渡し、host側のMetal libraryがGPU計算を行う構成です。コンテナの推論engine自体はguest側にあり、GPUの計算backendをhostへ橋渡しするため、Model Runnerのようにengineをhostの隔離processとして実行する方式とは異なります。
Red Hatは限られた版・機種・モデルを用いた試作についてnative Metalに近い性能を報告しています。しかし記事中の仕組みはpreview／proof of conceptで、Podman/libkrunの構成をDocker Desktop一般へ移せません。また、hostとguest間にGPU処理の通信路を作ることは隔離境界の一部を開くことでもあり、記事は同一address space上のbackend同士が干渉し得る点を限界として記しています。性能の類似はセキュリティ特性や運用適合性の同一を意味しません。
版を固定し、経路を実測する
llama.cpp公式ビルド資料ではmacOSのMetalは既定で有効です。比較では「Metal対応でbuildされたか」に加え、起動ログに選択GPU、GPU layer offload、CPUへ残った処理がどう出るかを記録します。CPUへ一部を残す設定は正常な構成でも起こり、GPU使用の有無を一語で表せない場合があります。
2026年10月2日に公開された公式nightlyはb11344です。リリースページはmacOS Apple Siliconと、LinuxのCPU・Vulkan・CUDA等の配布対象を別々に列挙しています。これはOS/backendごとに実行物が分かれる現状を確認する材料ですが、そのリリースページ自体がDocker Desktop上の速度を示すわけではありません。調査や性能比較では、llama.cpp版、Docker Desktop／Model Runner版、モデルの量子化、コンテキスト長を記録し、推論ログを保存してください。
記録項目にはMacの機種とメモリ、Runnerのstatus/log、モデルの識別子、要求の入力長・出力長も含めます。DMRは推論engineがホスト側processなので、クライアントcontainerのCPUやdocker statsだけでは推論側の使用状況を捉えきれません。初回応答はモデル読み込み時間も含むため、初回とwarm runを分けて計り、同じリクエストを複数回実行して揺れを見ます。
本稿では速度を測っていません。入力処理速度と生成速度、モデル初回読み込みと常駐後の応答も別の測定項目です。VMの起動時間、API round-trip、model loadの差を、tokens per secondだけで一括評価しないことが比較の前提です。初心者向けに選択手順をまとめたMacでDockerのローカルLLMを選ぶガイドも参照してください。
参考資料
- Docker Model Runner: 実行環境・隔離・対応backend
- Docker Model Runner: 推論engineとGPU対応
- Docker Model Runner: API base URLとcontainerからの接続
- llama.cpp b11344 release（2026-10-02）
- llama.cpp b11344 build document
- llama.cpp b11344 Docker document
- Docker Model Runner issue #1045（9月26日の移行コメント）
- Red Hat: Reach native speed with MacOS llama.cpp container inference（2025-09-18）
