macOS VMはどれほど高速で、どこまで小さくできるのか？

 (eclecticlight.co)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Mac mini M4 Proで macOS 26.4.1 VM を再計測した結果、5 仮想コアと 16GB vRAM 構成でも CPU シングルコアと GPU 性能はホストに近いことが分かった
  • Geekbench 6.7.1 時点で シングルコア CPUは VM 3,855 / ホスト 3,948、GPU Metalは VM 106,896 / ホスト 111,970 で、それぞれホストの約 98%、95% 水準を示した
  • マルチコア CPU は VM 13,222 / ホスト 23,342 で、ホストは 14 コア（10 P + 4 E）、VM は 5 仮想コアのため直接比較は難しいが、VM 性能はかなり良好だった
  • 最も弱い部分は 仮想 Neural Engine で、CoreML の半精度および量子化テストではホストより大幅に遅く、VM では AI 処理が CPU と GPU で処理されることを期待できる
  • 最小構成テストでは、2 仮想コアと 4GB メモリだけでも Safari や設定のストレージ分析のような軽い作業を正常に処理でき、macOS アップデートを考慮すると VM のストレージ容量は少なくとも 60GB が適切

テストの背景

  • Apple silicon における macOS 仮想化レビューで使われた性能値は以前の測定値であり、実用的な VM の最小仕様は扱われていなかった
  • MacBook Neo で VM を実行することへの関心が高まる中、macOS Tahoe 時点での性能と最小構成をあらためて確認した

性能測定と解釈

  • テストホストは Mac mini M4 Pro で、macOS 26.4.1、14 コア（10 P + 4 E）、48GB RAM、2TB 内蔵 SSD 構成
  • ゲスト VM には 5 仮想コア と 16GB 仮想 RAM を割り当てた
  • Geekbench 6.7.1 のスコアは、ホストと VM の両方で以前よりやや高速化していた
  • 測定結果は以下の通り
    • シングルコア 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
  • Neural Engine CoreML の 3 つの数値は、順に 単精度、半精度、量子化 テストの結果
  • マルチコア CPU の結果は、ホストが VM の 2 倍を超えるコア数を持ち、そのうち 4 つが E コアであるため直接比較が難しい
  • GPU 性能の比較は、ホストが GPU を競合的に併用していない条件での結果
  • VM で実行する際、macOS は AI 処理を Neural Engine ではなく CPU と GPU で処理すると期待できる

最小構成テスト

  • MacBook Neo の登場以降、このデバイスで VM を実行できるかへの関心があった
  • Linux ホスト用途には向いていそうだったが、macOS VM で実用的な作業ができるかは疑問視されていたものの、実際のテストでは可能だった
  • 最小構成を確認するため、同じ macOS 26.4.1 VM を Viable で徐々に小さい CPU コア数とメモリ割り当てにして実行した
  • VM 表示ウィンドウは標準の 1600 × 1000 に設定した
  • Safari をさまざまな形で使い、設定のストレージ分析を含む軽い日常作業を行った
  • 構成ごとの結果は以下の通り
    • 4 仮想コアと 8GB vRAM では VM は終始きびきび動作し、メモリ使用量は約 5GB だった
    • 3 コアと 6GB ではメモリ使用量が 3.9GB に減り、すべての作業が問題なく動作した
    • 2 コアと 4GB メモリでは 3.1GB しか使用せず、軽い作業を引き続き正常に処理した
  • 2 仮想コアと 4GB メモリだけを割り当てた macOS VM でも MacBook Neo で動作可能とみられ、日常作業を十分こなせる
  • このような VM は LLM を動かしてみる場所ではないが、軽い macOS 作業には十分実用的

ストレージ容量とアップデートの制約

  • 内蔵 SSD が小さい Mac で VM を作る際は、VM サイズに注意が必要
  • 50GB を大きく下回る macOS VM では macOS アップデートを実行できなくなる
  • 余裕と安全性のため、最低でも 60GB を目標にするのが望ましい
  • APFS では VM は スパースファイル として保存されるため、標準の 100GB VM でも実際のディスクでは約 54GB しか必要としない
  • このような構成は、512GB SSD を備えた MacBook Neo でより無理なく収容できる

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsのコメント

  • コアごとにある程度ひも付くメモリがある、という良い reminder。おそらく主にページキャッシュや並行処理あたりが原因の可能性が高い

    • 帰無仮説のほうに賭ける。コア数を固定してVMメモリサイズだけを調整しても、同じメモリ使用量の変化が現れた気がする
    • 一般的に、コンピュータに搭載する物理メモリ容量もCPUが提供するハードウェアスレッド数に比例しているべき
      OSがスレッドごとに一部メモリを割り当てることがあるだけでなく、大規模なソフトウェアプロジェクトのコンパイルのように全スレッドを使うマルチスレッドアプリでは、ワーカースレッド数に比例して作業用メモリを確保することが多い
      スレッドあたり最大2GB程度あると安定して動くマルチスレッドアプリも多く見てきたし、Ryzen 9 9950Xのような32スレッドのデスクトップCPUなら64GBがちょうど合う
      Chrome/Chromium系のようなプロジェクトをコンパイルするとき、16コア/32スレッドCPUに32GBしかないと、make -jのような適切なパラメータで同時コンパイル数を減らして一部コアを遊ばせる必要がある。そうしないとメモリ不足エラーに遭うことがある
    • コアごとのオーバーヘッドがあるのは確かだが、この使用量の減少は、利用可能メモリが減ったことでカーネルのメモリ割り当て方式が変わった影響のほうが大きそうに見える
      メモリが多いと、カーネルは読み込みキャッシュをより長く維持し、ディスクスワップよりメモリ圧縮を優先し、回収可能メモリの整理をあまり頻繁に行わない。内部バッファサイズやvnodeテーブルも総メモリ量に応じて調整される
      利用可能な資源を動的に最大限活用するという点では良いが、実際の動作に必要な最小ベースラインを見えにくくする代償がある
      確認すると面白いコマンドはvm_statで、free/active/inactive/wired/purgeableページ、compressor、pagein/pageout、swapin/swapoutのような値が見られる。編集: コードフェンスのMarkdownがサポートされていないのか、単に自分のやり方が悪いのかわからない

  • 最近M5 Airを買って、macOSは初めてなのでこのあたりを把握しているところだが、pytorch、GPUアクセラレーション、VM/コンテナレベルの隔離を同時に得るのは、実質的に不可能に見える
    virtio-gpuレイヤーが最も近そうだが、計算用GPUではなくグラフィックスGPUしか渡していないようで、pytorchには使えない

    • 自分もこれが必要で、1年前にかなり調べた。最近のDocker Model Runner（vllm-metal）やpodman libkrunまわりの変化はまだ確認する時間がなかったが、どちらもダメだった？
    • Cirruslabs Tartインスタンスでtorchを動かすことには成功した

  • macOSでVMを使ったのはcolima+dockerだけだが、比較的つらくて非効率。ただ、使えなくはない

    • Appleのcontainer CLIを試すとよい。数週間前の週末に、自分のプロジェクトの1つをcolima+dockerからかなり簡単に移せた
      https://github.com/apple/container
    • ローカルCI用途でMac Miniを買い、Forgejo Actionsと組み合わせて使うためにエコシステムを広く見て回ったが、最終的にはホストでビルドする方向にした
      署名と公証の設定をホストから隔離するのは、エージェントを使っても手に負えないように見えた。それでも今ではmacOSビルドは本当に速く、署名/公証もBashで200行程度あれば済む
    • OrbStackはかなり良い。特に非効率だとは感じない

  • https://github.com/trycua/cua/tree/main/libs/lume が、この問題に対する興味深いアプローチを示していた

  • VM起動時に5GBしか使わないとしても、VMの中でアプリを実行したら、起動時に使う5GBではなく、割り当てた8GB全体を欲しがることになるのでは？

    • macOS仮想化がメモリバルーニングをサポートするほど高度だとは思っていなかったが、そういう話ではないのか？
      編集: 自分が間違っていた

  • いちばん小さいものを持っているのは自分かもしれない。docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GBで、Darwinクロスビルドに使っている

  • 正直、macOSはVMで絶対に必要ではないものを無効化すれば、それよりずっと低くまで下げられそう
    初代iPhoneはRAMが128MiBしかなく、削ぎ落としたmacOS Tigerのバージョンを動かしていたと理解している。これまではRAMにかなり余裕があったので減らす理由がなかっただけで、間違いなく可能だし、おそらくそこまで難しくもないはず。もう一度試すだけでよい

    • 初期のiPhoneにはアプリのマルチタスクがなかったので、その違いはかなり大きい。アプリは閉じると終了していた

  • PCでmacOSを実行できるのか？ それとも少なくとも、PCでMac向け開発を何らかの形でできるのか？

    • QEMUでmacOSを起動することはできるが、ハードウェアアクセラレーション付きグラフィックスやいくつかの機能は使えない

  • 少し唐突な質問だが、macOS VMを個人デバイスとしてIntune登録することは可能だろうか？

  • なぜ誰もmacOS専用のエージェント環境を作らないのか気になる。エージェントがMac環境でspawnされるような形だとよさそう