Jusqu’où peut-on réduire une VM macOS, et à quelle vitesse peut-elle tourner ?

• Sur un Mac mini M4 Pro, de nouvelles mesures d’une VM macOS 26.4.1 montrent que, même avec une configuration de 5 cœurs virtuels et 16 Go de vRAM, les performances CPU monocœur et GPU restent proches de celles de l’hôte
• Selon Geekbench 6.7.1, le CPU monocœur atteint 3 855 dans la VM contre 3 948 sur l’hôte, et le GPU Metal 106 896 dans la VM contre 111 970 sur l’hôte, soit environ 98 % et 95 % des performances de l’hôte
• Le CPU multicœur obtient 13 222 dans la VM contre 23 342 sur l’hôte ; comme l’hôte dispose de 14 cœurs (10 P + 4 E) et la VM de 5 cœurs virtuels, la comparaison directe est difficile, mais les performances de la VM restent tout à fait correctes
• Le point le plus faible est le Neural Engine virtuel : il est nettement plus lent que l’hôte dans les tests CoreML en demi-précision et quantifiés, et on peut donc s’attendre à ce que les tâches d’IA soient traitées par le CPU et le GPU dans la VM
• Dans le test de configuration minimale, 2 cœurs virtuels et 4 Go de mémoire ont suffi pour exécuter normalement des tâches légères comme Safari et l’analyse du stockage dans Réglages ; en tenant compte des mises à jour macOS, un espace de stockage d’au moins 60 Go est recommandé pour la VM

---

Contexte du test

• Les chiffres de performance utilisés dans l’examen de la virtualisation macOS sur Apple silicon provenaient de mesures antérieures, et la question de la configuration minimale exploitable d’une VM n’y était pas abordée
• Dans un contexte d’intérêt croissant pour l’exécution de VM sur le MacBook Neo, les performances et la configuration minimale ont été revérifiées sur la base de macOS Tahoe

Mesures de performance et interprétation

• La machine hôte de test est un Mac mini M4 Pro sous macOS 26.4.1, avec 14 cœurs (10 P + 4 E), 48 Go de RAM et un SSD interne de 2 To
• La VM invitée s’est vu attribuer 5 cœurs virtuels et 16 Go de RAM virtuelle
• Les scores Geekbench 6.7.1 sont légèrement meilleurs qu’auparavant, aussi bien sur l’hôte que dans la VM
• Les résultats sont les suivants
  • CPU monocœur : VM 3 855, hôte 3 948
  • CPU multicœur : VM 13 222, hôte 23 342
  • GPU Metal : VM 106 896, hôte 111 970
  • Neural Engine CoreML : VM 5 291 / 8 577 / 6 877, hôte 5 973 / 41 251 / 56 616
• Les trois valeurs de Neural Engine CoreML correspondent, dans l’ordre, aux tests en simple précision, demi-précision et quantifié
• Les résultats CPU multicœur sont difficiles à comparer directement, l’hôte ayant plus du double du nombre de cœurs de la VM, dont 4 cœurs E
• La comparaison des performances GPU a été réalisée dans des conditions où l’hôte n’utilisait pas simultanément le GPU de manière concurrente
• En exécution dans une VM, on peut s’attendre à ce que macOS traite les tâches d’IA avec le CPU et le GPU plutôt qu’avec le Neural Engine

Test de configuration minimale

• Depuis l’arrivée du MacBook Neo, la question de savoir s’il pouvait exécuter des VM suscitait de l’intérêt
• Pour un usage avec Linux comme hôte, cela semblait plausible, mais il était plus douteux qu’une VM macOS puisse y permettre un travail réellement utile ; les tests ont pourtant montré que c’était possible
• Pour vérifier la configuration minimale, la même VM macOS 26.4.1 a été lancée dans Viable avec des allocations progressivement réduites en cœurs CPU et en mémoire
• La fenêtre d’affichage de la VM a été réglée sur le format standard 1600 × 1000
• Safari a été utilisé de plusieurs façons, et diverses tâches légères du quotidien ont été effectuées, y compris l’analyse du stockage dans Réglages
• Les résultats selon la configuration sont les suivants
  • Avec 4 cœurs virtuels et 8 Go de vRAM, la VM était totalement fluide, avec environ 5 Go de mémoire utilisés
  • Avec 3 cœurs et 6 Go, l’utilisation mémoire est descendue à 3,9 Go et toutes les tâches ont bien fonctionné
  • Avec 2 cœurs et 4 Go de mémoire, seulement 3,1 Go étaient utilisés, et les tâches légères continuaient à s’exécuter normalement
• Une VM macOS avec seulement 2 cœurs virtuels et 4 Go de mémoire semble donc envisageable sur le MacBook Neo, avec une capacité suffisante pour les tâches quotidiennes
• Ce type de VM n’est pas l’endroit idéal pour faire tourner un LLM, mais il reste tout à fait utilisable pour des tâches macOS légères

Contraintes de stockage et de mise à jour

• Lors de la création d’une VM sur un Mac doté d’un petit SSD interne, il faut faire attention à la taille de la VM
• Une VM macOS nettement inférieure à 50 Go ne pourra plus effectuer les mises à jour macOS
• Pour garder une marge de sécurité, il est préférable de viser au moins 60 Go
• Avec APFS, la VM est stockée sous forme de fichier sparse, si bien qu’une VM configurée à 100 Go ne nécessite en pratique qu’environ 54 Go sur le disque réel
• Une telle configuration peut être mieux adaptée à un MacBook Neo équipé d’un SSD de 512 Go

[GN⁺]

Avis sur Hacker News

• C’est un bon rappel qu’il y a une certaine quantité de mémoire liée à chaque cœur. Probablement surtout du côté du cache de pages ou de la gestion de la concurrence

  • Je miserais sur l’hypothèse nulle. Même en gardant constant le nombre de cœurs et en ajustant uniquement la taille mémoire de la VM, on aurait probablement observé la même variation de consommation mémoire
  • En général, la quantité de mémoire physique installée dans une machine devrait aussi être proportionnelle au nombre de threads matériels fournis par le CPU
    Non seulement l’OS peut allouer une partie de la mémoire par thread, mais les applications multithread qui utilisent tous les threads, comme la compilation de gros projets logiciels, réservent souvent une mémoire de travail proportionnelle au nombre de threads de travail
    J’ai souvent vu des applis multithread qui tournent bien avec jusqu’à 2 Go par thread, et pour un CPU desktop 32 threads comme le Ryzen 9 9950X, 64 Go tombent juste
    Lorsqu’on compile des projets comme Chrome/Chromium avec un CPU 16 cœurs / 32 threads et seulement 32 Go de RAM, il faut réduire le parallélisme de compilation avec des paramètres adaptés comme make -j, au prix de laisser certains cœurs inutilisés. Sinon, on peut se retrouver face à des erreurs de mémoire insuffisante
  • Il y a bien un surcoût par cœur, mais cette baisse de consommation semble plus probablement liée au fait que la manière dont le noyau alloue la mémoire change lorsque la mémoire disponible diminue
    Quand il y a beaucoup de mémoire, le noyau garde plus longtemps le cache de lecture, préfère la compression mémoire au swap disque, et nettoie moins souvent la mémoire récupérable. La taille des buffers internes et de la table des vnode s’ajuste aussi en fonction de la mémoire totale
    C’est une bonne chose dans la mesure où cela exploite dynamiquement au maximum les ressources disponibles, mais cela rend plus difficile l’observation du plancher minimal réellement nécessaire au fonctionnement
    Une commande intéressante pour vérifier cela est vm_stat, qui permet de voir des valeurs comme les pages free/active/inactive/wired/purgeable, le compressor, ainsi que pagein/pageout et swapin/swapout. Édit : je ne sais pas si c’est l’absence de prise en charge du Markdown en bloc de code, ou si c’est moi qui m’y prends mal

• J’ai récemment acheté un M5 Air, et comme c’est mon premier macOS, j’essaie encore de comprendre ce point, mais obtenir à la fois pytorch, l’accélération GPU et une isolation au niveau VM/conteneur semble en pratique impossible
  La couche virtio-gpu semble être ce qui s’en rapproche le plus, mais elle paraît ne transmettre qu’un GPU graphique, pas un GPU de calcul, donc pas de pytorch

  • J’en ai aussi besoin, donc j’ai pas mal creusé la question il y a un an. Je n’ai pas encore eu le temps de vérifier les évolutions récentes autour de Docker Model Runner (vllm-metal) ou de podman libkrun, mais aucun des deux ne fonctionne ?
  • J’ai réussi à exécuter torch sur une instance Tart de Cirruslabs

• Sur macOS, les seules VM que j’ai utilisées sont colima+docker, et c’est relativement pénible et inefficace. Cela dit, ça reste utilisable

  • Tu pourrais essayer le container CLI d’Apple. Il y a quelques semaines, pendant un week-end, j’ai migré assez facilement l’un de mes projets depuis colima+docker
    https://github.com/apple/container
  • J’ai acheté un Mac Mini pour du CI local et pour l’utiliser avec Forgejo Actions, et j’ai exploré assez largement l’écosystème, mais au final je suis parti sur des builds sur l’hôte
    Isoler de l’hôte la configuration de signature et de notarisation semblait difficilement gérable, même avec un agent. En revanche, les builds macOS sont maintenant vraiment rapides, et la signature/notarisation tient en environ 200 lignes de Bash
  • OrbStack est plutôt bien. Je n’ai pas particulièrement l’impression que ce soit inefficace

• https://github.com/trycua/cua/tree/main/libs/lume montrait une approche intéressante de ce problème

• Même si la VM n’utilise que 5 Go au démarrage, une fois des applications lancées dans la VM, n’aura-t-elle pas besoin de l’ensemble des 8 Go alloués, et pas seulement des 5 Go utilisés au départ ?

  • Je ne pensais pas que la virtualisation macOS était assez avancée pour prendre en charge le ballooning mémoire, tu ne parles pas de ça ?
    Édit : j’avais tort

• J’ai l’impression d’avoir la plus petite image. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB, et je l’utilise pour du cross-build Darwin

• Honnêtement, macOS pourrait probablement descendre bien plus bas que ça dans une VM si on désactivait tout ce qui n’est pas strictement nécessaire
  Le premier iPhone n’avait que 128 MiB de RAM, et si je me souviens bien, il faisait tourner une version allégée de macOS Tiger. Jusqu’ici, la RAM a été suffisamment abondante pour qu’il n’y ait aucune raison de la réduire, mais c’est clairement possible, et probablement pas si difficile. Il suffit de s’y remettre

  • Les premiers iPhone n’avaient pas de multitâche applicatif, donc la différence est importante. Une fois fermées, les applications étaient arrêtées

• Peut-on exécuter macOS sur un PC ? Ou au moins faire du développement pour Mac depuis un PC d’une manière ou d’une autre ?

  • Il est possible de démarrer macOS avec QEMU, mais on ne peut pas utiliser les graphiques accélérés matériellement ni certaines autres fonctionnalités

• Question un peu sortie de nulle part, mais est-il possible d’enrôler dans Intune une VM macOS comme appareil personnel ?

• Je me demande pourquoi personne ne crée un environnement d’agents dédié à macOS. Ce serait bien si les agents pouvaient être lancés dans un environnement Mac