【ITニュース解説】Build in the VM, Think on the Mac GPU: Debian 13 on Apple container With a Local Gemma 4

Apple Silicon Mac上で、高性能な大規模言語モデル（LLM）を効率的に利用しつつ、アプリケーション開発には安定したLinux環境を使いたいと考えるシステムエンジニアにとって、この記事で紹介する手法は非常に有効である。Apple独自のコンテナ管理ツールであるcontainer CLIを使い、Debian 13の仮想マシン（VM）を構築し、そのVM内からMacのGPU上で動作するローカルLLM（Gemma 4）を呼び出す方法を解説する。

この構成の核心は、VMとMacの役割を明確に分ける点にある。VMは、アプリケーションを実行するためのLinux環境として機能する。具体的には、Debian 13上で開発中のアプリケーションを動かす。一方、MacのMシリーズチップに搭載された高性能なGPUは、LLMの推論処理、つまり質問に対する回答を生成する計算を集中的に担当する。

なぜこのような役割分担が必要なのか。それは、container CLIで作成されるLinux VMが、MacのGPUを直接利用するための仕組みであるMetalにアクセスできないためだ。VMの内部からは仮想CPUや仮想デバイスしか見えず、Macが持つ優れたGPUの処理能力は活用されない。もしVM内でLLMを動かそうとすると、限られた仮想CPUとVMに割り当てた少ないメモリで処理することになり、Macのハードウェアの利点が失われる。そこで、VM内にはアプリケーションを置き、LLMはMacのmacOS上で直接動かし、VMのネットワークを通じて呼び出すという分業が最適な解決策となる。

まず、基盤となる技術について理解しておく必要がある。Appleのcontainer CLIは、Linux環境を実行する二つの方法を提供する。「コンテナ」と「マシン」である。コンテナは、単一のプログラムを実行するための一時的な環境で、ディスクに永続性はなく、/sbin/initのようなシステム起動プログラムは不要である。一方、マシンは、本格的に起動するLinuxシステム（systemdを含む）で、ディスクは永続的で、Macのホームフォルダもマウントされる。アプリケーションの継続的な開発やカスタマイズには、環境が保持されるマシンが適している。なお、container CLIはDockerとは異なり、Docker Desktopやdockerdプロセスは存在しない。それぞれのコンテナやマシンは、Appleのシステムによって管理される軽量なVMとして動作するが、Docker HubのようなOCIイメージは利用できる。

次に、Debian VMを準備する手順を説明する。 最初に、container CLIと必要なLinuxカーネルをMacにインストールする。これはAppleのGitHubから提供されるインストーラパッケージを使い、container system startおよびcontainer system kernel set --recommendedコマンドでシステムの起動とカーネルのダウンロードを行う。 次に重要なのは、公式のdebian:13イメージがそのままではマシンとして起動しないという問題だ。このイメージには、Linuxシステムを初期化する/sbin/initというプログラムが含まれていないため、VMは起動せず停止したままになる。これはcontainer machine logsコマンドで確認できる。 この問題を解決するため、カスタムのDebianイメージをビルドする。Dockerfileを作成し、ベースイメージにdebian:13を指定しつつ、システム起動に必要なsystemd-sysvパッケージを追加する。これにより/sbin/initが提供される。さらに、procps、less、iproute2、iputils-ping、curlといった基本的なネットワークツールやユーティリティ、sudo、dbusといったシステムに必要なパッケージもインストールする。特に重要なのは、VMが複数作成された場合に各VMが異なる識別子を持つように、machine-idをクリアする行を追加することだ。このDockerfileを使ってcontainer buildコマンドでイメージをビルドする。 イメージが完成したら、そのイメージからDebian VMを作成する。container machine create debian13-machine --name dev-vmコマンドでVMを作成するが、作成直後はまだ完全に起動していないため、すぐにコマンドを送るとエラーになる。VMが完全に起動するまで数秒間待機するループを組むなどの工夫が必要だ。起動後には、container machine runコマンドでVM内にコマンドを送り、systemctl is-system-runningでシステムが正常に動作していること、MacのユーザーがVM内に作成されていること、パスワードなしでsudoが使えることなどを確認する。一度作成されたVMは、apt-getでパッケージをインストールするなど、自由にカスタマイズ可能で、その変更はVMを停止して再起動しても保持される。これは、コンテナとは異なるマシンの大きな利点である。

次に、Mac上でLLM環境をセットアップする。 まず、brew install ollamaコマンドでOllamaをMacにインストールし、ollama pull gemma4:e2bでGemma 4モデルをダウンロードする。重要なのは、VMからMac上のOllamaへアクセスできるようにするためのネットワーク設定だ。Ollamaはデフォルトで127.0.0.1（localhost、つまりMac自身からのみアクセス可能）でリッスンするが、これを0.0.0.0（すべてのネットワークインターフェースからの接続を受け入れる）に変更する必要がある。この設定は、Homebrewが管理するOllamaのサービス設定ファイル（homebrew.mxcl.ollama.plist）にOLLAMA_HOST=0.0.0.0:8000という環境変数を追加して行う。ここで注意すべきは、brew services restart ollamaコマンドを使うと、このカスタム設定がデフォルトに戻されてしまう点だ。そのため、設定変更後はlaunchctlコマンドでサービスを直接再起動する必要がある。設定変更後、lsofコマンドなどでOllamaが*:8000でリッスンしていることを確認する。 Ollamaの設定が完了したら、Mac側でLLMが正しく動作することを確認する。提供されているbin/test-mac-ollamaスクリプトを実行すると、Ollamaが全てのインターフェースでリッスンしているか、ローカルとVMからアクセス可能なIPアドレスで応答するか、各種API（ネイティブ、ストリーミング、OpenAI互換）でモデルが応答するか、そして最も重要なGPUが100%利用されているかを確認できる。このテストが成功すれば、Mac側の準備は万全である。

最後に、VMからLLMを呼び出す手順である。 Debian VM内から、curlコマンドを使ってMac上のOllamaに問い合わせを行う。VMから見たMacのIPアドレスは192.168.64.1であるため、http://192.168.64.1:8000をOllamaのベースURLとして利用する。例えば、curl -s http://192.168.64.1:8000/api/generateのようなコマンドでLLMにプロンプトを送信し、応答を受け取る。OllamaはOpenAI互換APIも提供しているため、VM内のアプリケーションがOpenAI APIと互換性のあるクライアントを使用している場合でも、http://192.168.64.1:8000/v1をベースURLとして設定するだけで、MacのGPU上で動作するLLMを利用できる。 この連携により、アプリケーションはDebian VM内で実行され、その計算処理は2GBのVMメモリ内で行われるが、重い推論処理はMacの高性能なGPUにオフロードされる。VMとMac間のネットワーク通信によるオーバーヘッドは非常に小さく、LLMの応答速度はMac上で直接実行した場合とほとんど変わらない。実際、bin/test-vm-ollamaスクリプトで両側の連携をテストすると、GPUが100%利用されていることが確認され、通信遅延もわずか数ミリ秒であることが示される。 Gemma 4のような推論モデルを利用する際には一つの注意点がある。小さなトークン制限を設定すると、モデルが回答を生成する前の「思考プロセス」に予算の大部分を使ってしまい、結果として空の応答が返ってくることがある。この場合は、応答が空でもHTTPステータスコードが200で成功と判断されがちだが、応答のfinish_reasonやcontentを確認する必要がある。これを回避するには、プロンプトに"think": falseや"reasoning_effort": "none"といったオプションを追加し、思考プロセスを短縮するか、トークン制限を十分に確保する必要がある。 利用するモデルについても、Macのメモリ容量に合わせた選択が重要だ。8GBのMacでは、gemma4:e2b（Q4_K_M量子化、約1.7GBロード）が安定して動作する最も推奨される選択肢である。より高品質なgemma4:e2b-it-qat（Q4_0, QAT、約3.6GBロード）も可能だが、利用可能な空きメモリが少なくなるため、使用後はモデルをアンロードすることが推奨される。

この構成の最大の利点は、アプリケーション開発とLLMの利用という二つの側面で最高の環境を得られることだ。アプリケーション開発側は、systemd、apt、sudoが利用でき、永続的なディスクとMacのソースコードがマウントされた、まさに「本物の」Debianサーバー環境で作業できる。一方、モデル側は、特別な設定なしにMacのMetalと統合メモリを最大限に活用し、GPUによる高速な推論を実行できる。VMとMacの連携は、たった一つのURL（http://192.168.64.1:8000/v1）を介して行われるため、VM内のアプリケーションはOpenAI互換APIを話すだけで、背後のLLMがMacのGPUで動作していることを意識する必要はない。必要に応じて、このURLを別のOllamaサーバーやllama.cppサーバーに変更することも容易である。 システム構築中に起こりうる問題に対しても、一般的な原因と解決策が示されている。例えば、VMが起動しない場合は/sbin/initの有無を確認し、VMがHTTPリクエストに応答しない場合はOllamaのネットワーク設定（0.0.0.0）を確認するといった具体的な対応策がある。 このように、VMはLinuxが必要な作業を、MacはGPUが必要な作業をそれぞれ担当することで、両者の最高の部分を組み合わせた効率的で柔軟な開発・実行環境が実現できる。