ハクソク

世界を動かす技術を、日本語で。

macOSの仮想マシンはどれくらい高速で、どれくらい小さくできるか？

13時間前原文(eclecticlight.co)

概要

  • Apple Silicon搭載MacでのmacOS仮想化性能の最新検証
  • Mac mini M4 Pro上でのベンチマーク結果とVM性能比較
  • MacBook NeoでのmacOS VMの実用性と最小要件
  • ストレージ要件とAPFSの利点
  • MacBook Neoでも日常用途に十分なVM運用が可能

Apple Silicon上でのmacOS仮想化性能再検証

  • Mac mini M4 Pro（14コア：10 P + 4 E、48GB RAM、2TB SSD）をホストに使用
  • macOS 26.4.1上でGeekbench 6.7.1によるベンチマーク実施
    • シングルコアCPU：VM 3,855, ホスト 3,948
    • マルチコアCPU：VM 13,222, ホスト 23,342
    • GPU Metal：VM 106,896, ホスト 111,970
    • Neural Engine CoreML（単精度/半精度/量子化）：VM 5,291, 8,577, 6,877, ホスト 5,973, 41,251, 56,616
  • VMのシングルコア性能はホストの**98%**に達する高効率
  • マルチコア比較はコア数差のため単純比較不可だが、VMでも十分な性能
  • GPU性能はVMがホストの**95%**と高水準
  • Neural EngineはVMで半精度・量子化テスト時に大きく性能低下
    • AI処理はCPUやGPU活用が望ましい

MacBook NeoでのmacOS VMの実用性と最小要件

  • MacBook NeoでのmacOS VM運用への関心の高まり

  • Viableを用い、macOS 26.4.1 VMのCPUコア・メモリ割当を段階的に縮小して検証

    • 4コア/8GB vRAM：快適動作、実メモリ使用量約5GB
    • 3コア/6GB vRAM：メモリ使用量3.9GB、問題なく動作
    • 2コア/4GB vRAM：メモリ使用量3.1GB、軽作業は通常通り処理可能

  • VMのディスクサイズに注意

    • 50GB未満ではmacOSアップデート不可
    • 60GB以上推奨、100GB VMもAPFSスパースファイルのおかげで実際の使用量は約54GB
    • 512GB SSD搭載MacBook Neoなら十分対応可能

  • 2コア4GBメモリ割当のmacOS VMでも、日常作業やSafari利用、設定アプリでのストレージ分析などが快適に利用可能

    • LLM等の重いAI処理には不向きだが、普段使いには十分な実用性

MacBook NeoとmacOS VMの展望

  • MacBook NeoでもmacOS VMは実用的
  • 軽量作業や開発環境としての活用に期待
  • APFSのスパースファイル特性でストレージ効率も確保
  • 今後のNeoシリーズでの仮想化利用拡大への期待

Hackerたちの意見

> 4つの仮想コアと8GBのvRAMから始めたんだけど、VMは約5GBのメモリを使ってすごくスムーズに動いてた。でも… VM内でアプリを起動すると、スタート時に使う5GBじゃなくて、割り当てた8GBを全部使いたがるんだよね？
└
macOSの仮想化がメモリバルーニングをサポートするほど進んでるとは思わないけど、それが言いたいことじゃないのかな？ 編集: 訂正します！
> 4つの仮想コアと8GBのvRAMから始めて、VMは約5GBのメモリを使ってすごくスムーズに動いてたんだけど、3コアと6GBに減らしてみたら、メモリ使用量が3.9GBに下がって、すべてがうまく動いたよ。2コアと4GBだと、使われたのは3.1GBだけで、VMは軽いタスクを普通に処理し続けた。各コアに結びついているメモリの量があるっていうのを思い出させてくれるね（たぶん主にページキャッシュや同時処理のためのもの）。
└
僕は帰無仮説に賭けるね。コア数を一定に保って、VMのメモリサイズだけを調整すれば、メモリの挙動は変わらないと思う。
└
コアごとのオーバーヘッドは確かにあるけど、個人的にはこの使用量の減少はカーネルが利用可能なメモリを割り当てる方法から来てると思う。メモリが減ってるからね。カーネルはメモリが多いときはリードキャッシュを長く保持するし、メモリが多ければディスクにスワップする代わりにメモリを圧縮することを好む。メモリが多いときは、再利用可能なメモリをあまり頻繁にクリーンアップしないとか、内部バッファサイズやvnodeテーブルもトータルメモリに応じてスケールするんだよね。いいことだと思う。利用可能なものを最大限に活用してるけど、運用するための真の最小要件の基準を見えにくくしてるのが難点かな。面白いことをチェックするには、`vm_stat`を使ってみて。 `$ vm_stat Mach Virtual Memory Statistics: (ページサイズは4096バイト) 空きページ: 230295 アクティブページ: 1206857 非アクティブページ: 1206361 推測ページ: 31863 スロットページ: 0 ワイヤードページ: 470093 パージ可能ページ: 18894 "翻訳フォルト": 21635255 コピーオンライトページ: 1590349 ゼロフィルページ: 11093310 再活性化ページ: 15580 パージされたページ: 50928 ファイルバックページ: 689378 匿名ページ: 1755703 圧縮器に保存されたページ: 0 圧縮器が占有するページ: 0 デコンプレッション: 0 圧縮: 0 ページイン: 832529 ページアウト: 225 スワップイン: 0 スワップアウト: 0 編集: コードフェンスのマークダウンサポートがないのか、それとも何か間違ってるのかな？
└
一般的なルールとして、コンピュータにインストールされている物理メモリの量は、CPUが提供するハードウェアスレッドの数に比例するべきだよ。オペレーティングシステムが各スレッドにメモリを割り当てることがあるから、例えば大きなソフトウェアプロジェクトのコンパイルのように、すべての利用可能なスレッドを使えるマルチスレッドアプリケーションを起動すると、作業スレッドの数に比例した作業メモリを割り当てることが多いんだ。多くのマルチスレッドアプリケーションは、スレッドごとに最大2GBのメモリが必要だと感じたことがあるよ。これは、32スレッドのデスクトップCPU（例えばRyzen 9 9950X）に対して64GBのメモリを持つことに相当する。コンパイルの例で言うと、Chrome/Chromiumやその派生プロジェクトのように、ハードウェアスレッドの数に比例した十分なメモリがないと、例えば16コア/32スレッドのCPUに32GBしかない場合、同時コンパイルの数を減らさなきゃいけないんだ。例えば、"make -j"の適切なパラメータを使って、いくつかのスレッドやコアをアイドル状態にしておかないと、メモリ不足のエラーが発生するかもしれないよ。
正直、macOSはVMにとって厳密に必要じゃないものをオフにすれば、もっと低い設定でも動くと思う。初代iPhoneは128MiBのRAMしかなかったけど、macOS Tigerの軽量版を動かしてたはず。今までRAMがかなり豊富だったから、削減する理由がなかっただけで、実際には可能だし、そんなに難しくもないと思う。再度挑戦してみる必要があるね :)
└
そういえば、初期のiPhoneにはアプリのマルチタスクがなかったから、そこはかなりの違いだね。アプリを閉じると、どれも強制終了されちゃった。
macOSでのVMの経験はcolima+dockerだけなんだけど、結構痛いし効率も悪い（でも使える）。
└
最近、ローカルCI用にMac Miniを手に入れたんだけど（Forgejo Actionsと一緒に）、エコシステムをざっと見て「ホスト上でビルドする」ことに決めた。署名や認証の設定は、エージェントを使ってもホストから隔離するのが圧倒的に難しそうに見えた。少なくとも、macOSのビルドは今はすごく速いし、署名や認証はBashで約200行くらいで済むよ。
└
AppleのコンテナCLIを試してみて。2週間前に、自分のプロジェクトをcolima+dockerから比較的簡単に移行できたよ。 https://github.com/apple/container
└
OrbStackは結構いいよ。あんまり非効率だとは思わないな。
最近M5エアを手に入れたんだけど、初めてのMacOS体験で、これを解決しようとしてる。* pytorch * GPUアクセラレーション * VM/コンテナのような隔離がほぼ不可能に思える。virtio-gpuレイヤーが最も近いけど、計算用GPUじゃなくてグラフィックスGPUしかパススルーしないみたいで、pytorchは使えない。
└
これも必要なんだけど、1年前に結構調べたんだよね。最近のDocker Model Runner (vllm-metal)やpodman libkrunの進展をチェックする時間がなかったんだけど、どっちもダメだったの？
└
CirruslabsのTartインスタンスでtorchを動かすことができたよ。
https://github.com/trycua/cua/tree/main/libs/lume については面白い見解があったよ。
なんで誰もmacOS専用のエージェント環境を作らないのか、めっちゃ気になる。mac環境でエージェントがスパーンする感じで。
ちょっとランダムな質問なんだけど、macOSのVMを個人デバイスとしてIntuneに登録するのって可能かな？
一番小さいのを見つけたかも：$ podman image list | grep cross docker.io/gotson/crossbuild latest d96ea9b7054b 3年前のもので、6.71 GBでdarwin用にクロスビルドしてた。
PCでmacOSを動かすのって可能なの？それとも、せめてPCでMac用の開発ができる方法はあるかな？
└
QEMUを使えばmacOSを起動できるけど、ハードウェアアクセラレーションのグラフィックスや他のいくつかの機能は使えないよ。