Wie schnell ist eine macOS-VM – und wie klein kann sie werden?

 (eclecticlight.co)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Neue Messungen auf einem Mac mini M4 Pro mit einer macOS-26.4.1-VM zeigen, dass selbst mit 5 virtuellen Kernen und 16 GB vRAM die CPU-Single-Core- und GPU-Leistung nahe an den Host heranreichen
  • Nach Geekbench 6.7.1 erreicht die Single-Core-CPU 3.855 in der VM gegenüber 3.948 auf dem Host, GPU Metal 106.896 in der VM gegenüber 111.970 auf dem Host – also jeweils etwa 98 % bzw. 95 % des Hosts
  • Die Multi-Core-CPU lag bei 13.222 in der VM gegenüber 23.342 auf dem Host; da der Host 14 Kerne (10 P + 4 E) und die VM 5 virtuelle Kerne hat, ist ein direkter Vergleich schwierig, die VM-Leistung ist aber recht ordentlich
  • Die schwächste Stelle ist die virtuelle Neural Engine: In CoreML-Tests mit Halbpräzision und Quantisierung war sie deutlich langsamer als der Host; bei KI-Aufgaben in der VM ist daher zu erwarten, dass sie von CPU und GPU verarbeitet werden
  • Im Minimaltest bewältigte die VM mit nur 2 virtuellen Kernen und 4 GB Speicher auch leichte Aufgaben wie Safari und die Analyse des Speicherplatzes in den Einstellungen problemlos; mit Blick auf macOS-Updates sind mindestens 60 GB VM-Speicherplatz sinnvoll

Testhintergrund

  • Die Leistungswerte aus der Betrachtung der macOS-Virtualisierung auf Apple silicon stammten aus früheren Messungen, und die minimale brauchbare VM-Konfiguration wurde dort nicht behandelt
  • Da das Interesse an der Ausführung von VMs auf dem MacBook Neo gestiegen ist, wurden Leistung und Minimalkonfiguration unter macOS Tahoe erneut überprüft

Leistungsmessung und Einordnung

  • Test-Host ist ein Mac mini M4 Pro mit macOS 26.4.1, 14 Kernen (10 P + 4 E), 48 GB RAM und 2 TB interner SSD
  • Der Gast-VM wurden 5 virtuelle Kerne und 16 GB virtueller RAM zugewiesen
  • Die Werte in Geekbench 6.7.1 lagen sowohl auf Host als auch VM etwas höher als zuvor
  • Die Ergebnisse sind wie folgt
    • Single-Core-CPU: VM 3.855, Host 3.948
    • Multi-Core-CPU: VM 13.222, Host 23.342
    • GPU Metal: VM 106.896, Host 111.970
    • Neural Engine CoreML: VM 5.291 / 8.577 / 6.877, Host 5.973 / 41.251 / 56.616
  • Die drei Werte für Neural Engine CoreML stehen der Reihe nach für die Tests Einzelpräzision, Halbpräzision und Quantisierung
  • Das Multi-Core-CPU-Ergebnis lässt sich schwer direkt vergleichen, weil der Host mehr als doppelt so viele Kerne wie die VM hat und davon 4 E-Kerne sind
  • Der GPU-Leistungsvergleich wurde unter der Bedingung durchgeführt, dass der Host nicht gleichzeitig in Konkurrenz auf die GPU zugreift
  • Beim Betrieb in der VM ist zu erwarten, dass macOS KI-Aufgaben statt über die Neural Engine über CPU und GPU verarbeitet

Test der Minimalkonfiguration

  • Seit dem Erscheinen des MacBook Neo besteht Interesse daran, ob sich darauf VMs ausführen lassen
  • Für Linux als Host schien das plausibel, bei einer sinnvoll nutzbaren macOS-VM gab es jedoch Zweifel – die Tests zeigten aber, dass es möglich ist
  • Um die Minimalkonfiguration zu bestimmen, wurde dieselbe macOS-26.4.1-VM in Viable schrittweise mit kleineren Zuweisungen von CPU-Kernen und Speicher ausgeführt
  • Das VM-Anzeigefenster wurde auf standardmäßige 1600 × 1000 eingestellt
  • Verwendet wurden Safari in mehreren Nutzungsszenarien sowie leichte Alltagsaufgaben einschließlich der Speicherplatzanalyse in den Einstellungen
  • Die Ergebnisse je Konfiguration
    • Mit 4 virtuellen Kernen und 8 GB vRAM lief die VM vollständig flüssig, der Speicherverbrauch lag bei etwa 5 GB
    • Mit 3 Kernen und 6 GB sank die Speichernutzung auf 3,9 GB, und alle Aufgaben funktionierten gut
    • Mit 2 Kernen und 4 GB Speicher wurden nur 3,1 GB genutzt, und leichte Aufgaben liefen weiterhin problemlos
  • Eine macOS-VM mit nur 2 virtuellen Kernen und 4 GB Speicher dürfte auch auf dem MacBook Neo möglich sein und für Alltagsaufgaben ausreichen
  • Für das Ausführen eines LLM ist eine solche VM nicht gedacht, für leichte macOS-Aufgaben aber gut brauchbar

Speicherplatz und Update-Beschränkungen

  • Beim Erstellen einer VM auf Macs mit kleiner interner SSD sollte die VM-Größe sorgfältig bedacht werden
  • Eine macOS-VM deutlich unter 50 GB kann keine macOS-Updates mehr durchführen
  • Für etwas Reserve und Sicherheit empfiehlt es sich, mindestens 60 GB einzuplanen
  • Unter APFS wird die VM als Sparse File gespeichert, sodass selbst eine standardmäßige 100-GB-VM auf dem tatsächlichen Datenträger nur etwa 54 GB benötigt
  • Eine solche Konfiguration lässt sich auf einem MacBook Neo mit 512-GB-SSD besser unterbringen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Gute Erinnerung daran, dass pro Kern offenbar eine gewisse Menge Speicher gebunden ist. Vermutlich liegt das vor allem an Page Cache oder Dingen wie Concurrency-Verarbeitung

    • Ich würde auf die Nullhypothese setzen. Wenn man die Anzahl der Kerne konstant gehalten und nur die VM-Speichergröße angepasst hätte, hätte man vermutlich dieselbe Veränderung beim Speicherverbrauch gesehen
    • Ganz allgemein sollte auch die physisch eingebaute Speichermenge eines Computers proportional zur Anzahl der von der CPU bereitgestellten Hardware-Threads sein
      Das Betriebssystem kann nicht nur pro Thread etwas Speicher reservieren, sondern Multithread-Apps, die wirklich alle Threads nutzen — etwa beim Kompilieren großer Softwareprojekte — belegen Arbeitspeicher oft ebenfalls proportional zur Zahl der Worker-Threads
      Ich habe viele Multithread-Apps gesehen, die erst mit bis zu 2 GB pro Thread richtig gut laufen, und bei einem Desktop-CPU mit 32 Threads wie dem Ryzen 9 9950X passen 64 GB ziemlich gut
      Wenn man Projekte wie Chrome/Chromium kompiliert und bei einer CPU mit 16 Kernen/32 Threads nur 32 GB RAM hat, muss man mit sinnvollen Parametern wie make -j die Zahl paralleler Kompilierungen reduzieren und einige Kerne ungenutzt lassen. Andernfalls kann es zu Out-of-Memory-Fehlern kommen
    • Es stimmt zwar, dass es einen Overhead pro Kern gibt, aber wahrscheinlicher ist, dass dieser Rückgang des Verbrauchs dadurch verursacht wird, dass sich mit weniger verfügbarem Speicher die Art der Speicherallokation des Kernels ändert
      Wenn viel Speicher vorhanden ist, hält der Kernel Lese-Caches länger vor, bevorzugt Speicherkompression gegenüber Disk-Swap und räumt reclaimbaren Speicher seltener auf. Auch interne Buffer-Größen und die vnode-Tabelle werden an den Gesamtspeicher angepasst
      Das ist gut, weil verfügbare Ressourcen dynamisch maximal genutzt werden, hat aber den Nachteil, dass die minimale Basislinie für den tatsächlichen Betrieb schwerer zu erkennen ist
      Ein interessanter Befehl zum Prüfen ist vm_stat; dort sieht man Werte wie free/active/inactive/wired/purgeable pages, compressor, pagein/pageout und swapin/swapout. Edit: Ich weiß nicht, ob Code-Fence-Markdown nicht unterstützt wird oder ob ich etwas falsch gemacht habe

  • Ich habe mir vor Kurzem ein M5 Air gekauft, benutze macOS zum ersten Mal und versuche gerade, das zu verstehen, aber gleichzeitig pytorch, GPU-Beschleunigung und Isolation auf VM-/Container-Ebene zu bekommen, scheint praktisch unmöglich zu sein
    Die virtio-gpu-Schicht wirkt am ehesten passend, aber sie scheint nur eine Grafik-GPU und keine Compute-GPU durchzureichen, daher funktioniert pytorch nicht

    • Ich brauche das auch und habe vor etwa einem Jahr ziemlich viel dazu recherchiert. Ich hatte noch keine Zeit, mir die jüngsten Änderungen bei Docker Model Runner (vllm-metal) oder podman libkrun anzusehen — haben beide nicht funktioniert?
    • Ich habe es geschafft, torch auf einer Cirruslabs-Tart-Instanz auszuführen

  • Unter macOS habe ich VMs nur mit colima+docker genutzt, und das ist vergleichsweise schmerzhaft und ineffizient. Nutzbar ist es trotzdem

    • Probier mal Apples container CLI aus. Ich habe vor ein paar Wochen an einem Wochenende eines meiner Projekte ziemlich leicht von colima+docker dorthin migriert
      https://github.com/apple/container
    • Ich habe mir für lokale CI-Zwecke einen Mac Mini gekauft und mir das Ökosystem gründlich angesehen, weil ich ihn mit Forgejo Actions nutzen wollte, bin am Ende aber beim Build auf dem Host gelandet
      Signatur- und Notarisierungs-Setup vom Host zu isolieren, schien selbst mit Agenten zu aufwendig zu sein. Dafür sind macOS-Builds jetzt wirklich schnell, und Signierung/Notarisierung lassen sich in ungefähr 200 Zeilen Bash erledigen
    • OrbStack ist ziemlich gut. Es fühlt sich für mich überhaupt nicht ineffizient an

  • https://github.com/trycua/cua/tree/main/libs/lume zeigte einen interessanten Ansatz für dieses Problem

  • Selbst wenn beim Start der VM nur 5 GB genutzt werden, will sie doch, sobald man darin Apps ausführt, nicht nur die beim Start genutzten 5 GB, sondern die gesamten zugewiesenen 8 GB, oder?

    • Ich hätte nicht gedacht, dass macOS-Virtualisierung so ausgereift ist, dass sie Memory Ballooning unterstützt — oder ist das gar nicht gemeint?
      Edit: Ich lag falsch

  • Ich glaube, ich habe das kleinste. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB, und ich nutze es für Darwin-Cross-Builds

  • Ehrlich gesagt könnte macOS vermutlich deutlich weiter heruntergedreht werden, wenn man Dinge deaktiviert, die in einer VM nicht zwingend nötig sind
    Das erste iPhone hatte nur 128 MiB RAM und lief meines Wissens mit einer abgespeckten Version von macOS Tiger. Bisher gab es einfach wenig Grund, das weiter zu verkleinern, weil RAM recht großzügig vorhanden war — möglich ist es sicher, und wahrscheinlich ist es nicht einmal besonders schwer. Man müsste es nur noch einmal versuchen

    • Auf frühen iPhones gab es noch kein App-Multitasking, also ist das schon ein erheblicher Unterschied. Wenn Apps geschlossen wurden, waren sie beendet

  • Kann man macOS auf einem PC ausführen? Oder zumindest irgendwie Mac-Entwicklung auf einem PC machen?

    • Man kann macOS mit QEMU booten, aber hardwarebeschleunigte Grafik und einige andere Funktionen stehen dann nicht zur Verfügung

  • Etwas aus heiterem Himmel gefragt, aber könnte man eine macOS-VM als persönliches Gerät bei Intune registrieren?

  • Ich frage mich, warum niemand eine macOS-spezifische Agent-Umgebung baut. Es wäre schön, wenn Agenten direkt in einer Mac-Umgebung gespawnt würden