Seberapa cepat VM macOS, dan seberapa kecil ukurannya?

• Hasil pengukuran ulang VM macOS 26.4.1 di Mac mini M4 Pro menunjukkan bahwa bahkan dengan konfigurasi 5 inti virtual dan 16GB vRAM, performa CPU inti tunggal dan GPU mendekati host
• Berdasarkan Geekbench 6.7.1, CPU inti tunggal mencatat VM 3.855 / host 3.948, dan GPU Metal mencatat VM 106.896 / host 111.970, masing-masing sekitar 98% dan 95% dari host
• CPU multi-core mencatat VM 13.222 / host 23.342; karena host memiliki 14 inti (10 P + 4 E) dan VM memiliki 5 inti virtual, perbandingan langsung memang sulit, tetapi performa VM tergolong cukup baik
• Bagian yang paling lemah adalah Neural Engine virtual; pada pengujian CoreML presisi setengah dan kuantisasi, hasilnya jauh lebih lambat daripada host, sehingga di VM pekerjaan AI kemungkinan akan diproses oleh CPU dan GPU
• Dalam pengujian konfigurasi minimum, hanya dengan 2 inti virtual dan memori 4GB, tugas ringan seperti Safari dan analisis ruang penyimpanan di Settings tetap berjalan normal, dan jika mempertimbangkan pembaruan macOS, ruang penyimpanan VM minimal 60GB dinilai tepat

---

Latar belakang pengujian

• Angka performa yang digunakan dalam tinjauan virtualisasi macOS di Apple silicon berasal dari pengukuran sebelumnya, dan belum membahas spesifikasi minimum VM yang masih layak dipakai
• Karena minat untuk menjalankan VM di MacBook Neo meningkat, pengujian ini meninjau ulang performa dan konfigurasi minimum berdasarkan macOS Tahoe

Pengukuran performa dan interpretasi

• Host pengujian adalah Mac mini M4 Pro, dengan macOS 26.4.1, 14 inti (10 P + 4 E), RAM 48GB, dan SSD internal 2TB
• Untuk guest VM, dialokasikan 5 inti virtual dan 16GB RAM virtual
• Skor Geekbench 6.7.1 untuk host maupun VM sedikit lebih cepat dibanding sebelumnya
• Hasil pengukuran adalah sebagai berikut
  • CPU inti tunggal: VM 3.855, host 3.948
  • CPU multi-core: 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
• Tiga angka pada Neural Engine CoreML tersebut masing-masing adalah hasil pengujian presisi tunggal, presisi setengah, dan kuantisasi
• Hasil CPU multi-core sulit dibandingkan secara langsung karena host memiliki lebih dari dua kali jumlah inti dibanding VM, dan 4 di antaranya adalah inti E
• Perbandingan performa GPU dilakukan dalam kondisi host tidak sedang menggunakan GPU secara kompetitif bersamaan
• Saat berjalan di VM, macOS kemungkinan akan memproses pekerjaan AI menggunakan CPU dan GPU alih-alih Neural Engine

Pengujian konfigurasi minimum

• Setelah kemunculan MacBook Neo, ada ketertarikan apakah perangkat itu dapat menjalankan VM
• Sebagai host Linux tampaknya perangkat itu cukup memadai, tetapi apakah ia bisa berguna untuk pekerjaan nyata dengan VM macOS sempat diragukan; pengujian nyata menunjukkan bahwa itu memungkinkan
• Untuk memastikan konfigurasi minimum, VM macOS 26.4.1 yang sama dijalankan di Viable dengan alokasi inti CPU dan memori yang secara bertahap diperkecil
• Jendela tampilan VM diatur ke ukuran standar 1600 × 1000
• Safari digunakan dalam beberapa cara, dan dilakukan tugas harian ringan termasuk analisis ruang penyimpanan di Settings
• Hasil tiap konfigurasi adalah sebagai berikut
  • Dengan 4 inti virtual dan 8GB vRAM, VM berjalan sepenuhnya lancar, dengan penggunaan memori sekitar 5GB
  • Dengan 3 inti dan 6GB, penggunaan memori turun menjadi 3,9GB dan semua tugas berjalan baik
  • Dengan 2 inti dan memori 4GB, hanya 3,1GB yang terpakai, dan tugas ringan tetap tertangani dengan normal
• VM macOS yang hanya diberi 2 inti virtual dan memori 4GB pun tampaknya akan bisa dijalankan di MacBook Neo, dan cukup untuk pekerjaan harian
• Konfigurasi seperti ini memang bukan tempat untuk mencoba menjalankan LLM, tetapi masih cukup layak untuk tugas macOS ringan

Ruang penyimpanan dan batasan pembaruan

• Saat membuat VM di Mac dengan SSD internal kecil, ukuran VM perlu diperhatikan
• VM macOS yang jauh lebih kecil dari 50GB tidak akan dapat menjalankan pembaruan macOS
• Demi kelonggaran dan keamanan, sebaiknya menargetkan minimal 60GB
• Di APFS, VM disimpan sebagai sparse file, sehingga VM bawaan 100GB di disk nyata hanya memerlukan sekitar 54GB
• Konfigurasi seperti ini kemungkinan dapat ditampung dengan lebih tepat di MacBook Neo dengan SSD 512GB

[GN⁺]

Komentar Hacker News

• Ini pengingat yang bagus bahwa ada sejumlah memori yang terikat per core. Kemungkinan besar terutama terkait page cache atau hal seperti penanganan konkurensi

  • Saya akan bertaruh pada hipotesis nol. Kalau jumlah core tetap dan hanya ukuran memori VM yang diubah, sepertinya perubahan penggunaan memori yang sama juga akan muncul
  • Secara umum, kapasitas memori fisik yang dipasang di komputer juga sebaiknya sebanding dengan jumlah hardware thread yang disediakan CPU
    Bukan hanya karena sistem operasi bisa mengalokasikan sebagian memori per thread, tetapi juga karena aplikasi multithread yang memakai semua thread—seperti kompilasi proyek perangkat lunak besar—sering kali mengambil memori kerja sebanding dengan jumlah thread pekerja
    Saya juga sering melihat aplikasi multithread yang baru berjalan baik jika tersedia maksimal sekitar 2GB per thread, jadi untuk CPU desktop 32-thread seperti Ryzen 9 9950X, 64GB memang terasa pas
    Saat mengompilasi proyek seperti Chrome/Chromium, jika CPU 16-core/32-thread hanya punya 32GB, Anda harus menurunkan jumlah kompilasi paralel dengan parameter yang sesuai seperti make -j, sehingga sebagian core menganggur. Kalau tidak, Anda bisa menemui error kehabisan memori
  • Memang ada overhead per core, tetapi penurunan pemakaian ini tampaknya lebih mungkin dipengaruhi oleh berubahnya cara kernel mengalokasikan memori saat memori yang tersedia berkurang
    Jika memori melimpah, kernel akan mempertahankan cache baca lebih lama, lebih memilih kompresi memori daripada swap disk, dan lebih jarang membersihkan memori yang bisa direklamasi. Ukuran buffer internal dan tabel vnode juga disesuaikan berdasarkan total memori
    Ini bagus karena sumber daya yang tersedia dimanfaatkan secara dinamis semaksimal mungkin, tetapi konsekuensinya jadi lebih sulit melihat baseline minimum yang benar-benar dibutuhkan untuk operasi nyata
    Perintah yang menarik untuk dicek adalah vm_stat, dan Anda bisa melihat nilai seperti free/active/inactive/wired/purgeable pages, compressor, pagein/pageout, swapin/swapout. Edit: saya tidak tahu apakah ini karena Markdown code fence tidak didukung, atau saya yang salah melakukan sesuatu

• Saya baru membeli M5 Air dan ini pertama kalinya memakai macOS, jadi sedang mencoba memahami bagian ini, tetapi tampaknya praktis mustahil mendapatkan pytorch, akselerasi GPU, dan isolasi setingkat VM/container sekaligus
  Lapisan virtio-gpu tampaknya yang paling mendekati, tetapi sepertinya hanya meneruskan GPU grafis, bukan GPU komputasi, jadi pytorch tidak bisa

  • Saya juga butuh ini, jadi setahun lalu saya cukup banyak mencari. Saya belum sempat mengecek perubahan terbaru di Docker Model Runner (vllm-metal) atau podman libkrun, apakah keduanya tetap tidak berhasil?
  • Saya berhasil menjalankan torch di instance Cirruslabs Tart

• Satu-satunya VM yang pernah saya pakai di macOS adalah colima+docker, dan itu relatif menyakitkan serta tidak efisien. Meski begitu, tetap bisa dipakai

  • Coba pakai container CLI dari Apple. Beberapa minggu lalu, selama akhir pekan, saya memindahkan salah satu proyek saya dari colima+docker dengan cukup mudah
    https://github.com/apple/container
  • Saya membeli Mac Mini untuk CI lokal dan sempat meninjau ekosistem secara luas untuk dipakai bersama Forgejo Actions, tetapi pada akhirnya saya memilih build di host
    Mengisolasi konfigurasi signing dan notarization dari host tampaknya terlalu sulit ditangani, bahkan dengan agen. Namun sekarang build macOS benar-benar cepat, dan signing/notarization juga bisa dilakukan hanya dengan sekitar 200 baris Bash
  • OrbStack cukup bagus. Saya sendiri tidak merasa itu tidak efisien

• https://github.com/trycua/cua/tree/main/libs/lume menunjukkan pendekatan yang menarik untuk masalah ini

• Meskipun hanya memakai 5GB saat VM mulai, bukankah ketika Anda menjalankan aplikasi di dalam VM, yang dibutuhkan akhirnya bukan 5GB yang dipakai saat start melainkan seluruh 8GB yang dialokasikan?

  • Saya tidak mengira virtualisasi macOS cukup canggih untuk mendukung memory ballooning, bukankah itu yang dibicarakan?
    Edit: saya salah

• Sepertinya saya yang punya yang paling kecil. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB, dan saya memakainya untuk cross build Darwin

• Terus terang, macOS tampaknya bisa turun jauh lebih rendah dari itu jika hal-hal yang tidak benar-benar diperlukan di VM dimatikan
  iPhone pertama hanya punya RAM 128MiB, dan setahu saya menjalankan versi macOS Tiger yang dipangkas. Sampai sekarang RAM cukup berlimpah sehingga tidak ada alasan untuk merampingkannya, tetapi ini jelas mungkin, dan mungkin juga tidak terlalu sulit. Tinggal dicoba lagi saja

  • iPhone awal tidak punya multitasking aplikasi, jadi perbedaannya cukup besar. Aplikasi akan berhenti saat ditutup

• Apakah menjalankan macOS di PC itu memungkinkan? Atau setidaknya, apakah ada cara untuk melakukan pengembangan untuk Mac dari PC?

  • Mem-boot macOS dengan QEMU memungkinkan, tetapi grafik dengan akselerasi hardware dan beberapa fitur tidak bisa dipakai

• Pertanyaan agak nyeleneh, tetapi apakah mungkin mendaftarkan VM macOS ke Intune sebagai perangkat pribadi?

• Saya penasaran kenapa tidak ada yang membuat lingkungan agen khusus macOS. Akan bagus jika agen bisa di-spawn di lingkungan Mac