Accélérer l’IA dans une VM macOS sans véritable passthrough GPU
Le constat : le GPU n’était pas le seul facteur limitant
Faire tourner un modèle de langage dans une machine virtuelle macOS sur Apple Silicon ne garantit pas que les frameworks d’IA exploitent correctement le GPU de l’hôte. Une expérience publiée le 11 août 2026 par Francesco Bonacci et Johnny Franks montre toutefois qu’une partie importante de la perte de performances peut venir d’un problème de détection des capacités Metal plutôt que d’une absence d’accès au GPU.
Les auteurs ont testé une petite couche de compatibilité, ou shim, capable de modifier certaines réponses que Metal renvoie à un processus invité. L’objectif n’est pas de transférer physiquement le GPU à la VM, mais de permettre à un logiciel donné de sélectionner des chemins d’exécution plus récents. Dans les essais avec llama.cpp, la différence entre une VM macOS standard et une VM équipée de ce shim est parfois spectaculaire.
Des gains très élevés avec llama.cpp
Le résultat le plus marqué concerne TinyLlama 1.1B. Sur un Apple M1 Ultra, le traitement des prompts a été 11,08 fois plus rapide dans la VM modifiée que dans la VM standard. La génération de tokens a progressé d’un facteur 16,36.
Les mesures absolues permettent de mieux comprendre l’écart. Pour un prompt de 512 tokens, le bare metal atteint 4 871,99 tokens par seconde. La VM standard plafonne à 431,86 tokens par seconde, tandis que la VM modifiée atteint 4 786,70 tokens par seconde, soit 98 % du résultat bare metal. Pour la génération de 128 tokens, les débits sont respectivement de 286,71, 12,63 et 206,60 tokens par seconde.
Le gain n’est donc pas seulement visible dans un ratio théorique. Dans le cas du prompt, la VM modifiée se rapproche presque du système hôte. La génération reste davantage en retrait, mais elle dépasse largement le comportement de la VM standard.
Le test TinyLlama s’appuyait sur la version officielle llama.cpp b10167 et sur le modèle TinyLlama 1.1B Chat Q4_K_M. Dix échantillons ont été utilisés pour chaque ligne de benchmark, selon le document.
Les modèles plus lourds suivent la même tendance
Le comportement ne se limite pas au plus petit modèle évalué. Avec Google Gemma 4 12B QAT Q4_0, le traitement des prompts a été amélioré d’un facteur 7,20 et la génération de tokens d’un facteur 14,54 par rapport à la VM standard.
La VM modifiée a atteint 99,59 % de la vitesse bare metal pour le traitement des prompts et 94,82 % pour la génération. Ces résultats sont particulièrement significatifs pour les usages interactifs, où le temps nécessaire pour ingérer le contexte et celui consacré à produire la réponse influencent tous deux la perception de réactivité.
Un troisième essai a porté sur le modèle Meta Muse Glimmer 30B Q4_K-M au format GGUF, dans un invité doté de 64 Gio de mémoire. Avec llama.cpp b10359, la VM modifiée a traité un prompt de 512 tokens 7,55 fois plus vite que l’invité standard et a généré 128 tokens 8,87 fois plus vite. Le document ne fournit pas, dans les faits considérés ici, les débits absolus de ce troisième scénario.
Ce que modifie réellement le shim Metal
Le mécanisme est volontairement ciblé. Le shim s’exécute à l’intérieur d’un seul processus invité et modifie les réponses de certaines requêtes de capacité Metal reçues par ce processus. Pour le profil testé, il indique une prise en charge jusqu’à la famille de GPU Apple 9, identifiée par la valeur 1009, et fait passer la mémoire maximale déclarée pour un groupe de threads de 32 Kio à 64 Kio.
Ces réponses suffisent, pour la version testée de llama.cpp, à activer des chemins reposant sur les réductions de groupes SIMD, les opérations matricielles de groupes SIMD et le format bfloat16. L’amélioration vient donc de la sélection d’implémentations logicielles plus adaptées aux capacités du GPU, et non de l’ajout d’un nouveau périphérique virtuel.
Le flux d’exécution reste celui des graphismes d’Apple Virtualization.framework et le calcul est réalisé sur le GPU Apple de l’hôte. Il ne s’agit ni d’une affectation physique du GPU à la VM, ni d’un passthrough PCI ou VFIO, ni d’une modification du noyau.
Pourquoi MLX ne bénéficie pas du même effet
Les résultats ne doivent pas être généralisés à tous les frameworks d’IA. Le document rapporte un test avec MLX-LM 0.31.3, MLX 0.32.0 et le modèle mlx-community/Llama-3.2-3B-Instruct-4bit. Dans ce cas, les performances restent pratiquement identiques entre la VM standard et la VM modifiée.
Le ratio entre VM déverrouillée et VM standard atteint 1,005 fois pour le traitement d’un prompt de 512 tokens et 0,993 fois pour la génération. Les mesures de traitement des prompts sont de 1 656,55 tokens par seconde dans la VM standard et de 1 665,47 tokens par seconde dans la VM modifiée. Autrement dit, le shim semble agir sur des chemins de code que la version testée de llama.cpp emprunte, mais pas nécessairement sur ceux utilisés par MLX.
Une approche utile, mais fragile
L’environnement expérimental était précis : Apple M1 Ultra avec GPU de 48 cœurs et macOS 26.6.1 côté hôte. L’invité utilisait l’image publique Tahoe Cua, macOS 26.5.2, 8 vCPU et 16 Gio de mémoire, le tout sous Lume 0.5.1.
Cette précision est importante pour interpréter les résultats. Le shim est décrit comme expérimental et sensible aux versions, car il s’appuie sur des détails privés de l’implémentation Metal dans l’invité. Ces détails peuvent changer lors d’une mise à jour de macOS et rendre la technique inopérante ou modifier ses résultats.
Pour les développeurs qui exécutent ponctuellement des modèles dans une VM macOS, l’expérience montre qu’il peut être pertinent d’examiner les capacités Metal déclarées et les kernels sélectionnés avant de conclure à une limitation intrinsèque de la virtualisation. Pour une infrastructure durable ou destinée à la production, cette dépendance à des détails privés impose en revanche des tests de régression à chaque évolution de l’hôte, de l’invité, de Lume, de Metal ou du framework d’inférence.
À retenir
- Un shim Metal ciblé a multiplié jusqu’à 16,36 fois la génération de tokens de TinyLlama 1.1B par rapport à une VM macOS standard sur M1 Ultra.
- La VM modifiée a atteint 98 % du bare metal pour le traitement des prompts de TinyLlama et jusqu’à 99,59 % avec Gemma 4 12B QAT Q4_0.
- Le mécanisme ne réalise pas de passthrough GPU : le calcul reste dans le chemin graphique d’Apple Virtualization.framework, sur le GPU de l’hôte.
- Les bénéfices dépendent du framework et du chemin logiciel : le test MLX-LM n’a montré pratiquement aucune amélioration.
- La solution reste expérimentale et sensible aux changements de versions de macOS, car elle exploite des détails privés de Metal.