Pourquoi nous supprimons la virtualisation :
Manifeste bare metal

En plus d'une décennie d'histoire du cloud, la machine virtuelle (VM) et l'hyperviseur ont été le socle par défaut. D'AWS EC2 à Google Cloud Compute Engine, le cloud public repose sur la virtualisation. Un gros hôte est découpé en de nombreuses petites instances : plusieurs locataires partagent la même puce, le même bus, la même alimentation — le partage poussé et la sursouscription ont bâti un modèle commercial massif et un riche écosystème SaaS.

Mais le matériel a changé, notamment avec Apple Silicon (série M) : l'architecture ARM a remis à plat les performances des postes de travail. Appliquer l'ancien modèle cloud x86 au calcul Mac a fait apparaître un constat d'ingénierie brutal : la virtualisation étouffe le cœur de ce qui rend les puces Apple rapides.

Aujourd'hui, l'équipe NOVAKVM publie cette note d'architecture. Nous allons en profondeur : pourquoi, pour des chaînes de compilation hautes performances et l'inférence LLM sur machine, la virtualisation est un poison ; et comment nous avons refondu toute la pile pour livrer ce que nous croyons être le premier plan de contrôle Apple Silicon bare metal pur, sans perte, 100 % natif, en production.

Pour comprendre pourquoi la virtualisation pénalise, partez de l'avantage de conception d'Apple : l'architecture mémoire unifiée (UMA). Sur un poste x86 classique, la RAM système et la VRAM du GPU discret sont séparées. Pour déplacer beaucoup de données — textures, poids de modèles — entre CPU et GPU, tout traverse le lien PCIe lent et étroit. Ce coût de transfert, c'est le fameux « mur PCIe ».

M4 et M4 Pro brisent ce mur. Les cœurs performance, efficacité, le GPU multicœur et le Neural Engine sont sur le même die et directement reliés à un pool unique de mémoire à très large bande passante, jusqu'à 64 Go ou 128 Go. Lors de compilations Xcode parallèles ou d'un workflow MLX avec un modèle 70B, les données sont en pratique en zéro copie : les octets restent en place, les cœurs utilisent des pointeurs, le travail se fait sans allers-retour PCIe.

Introduisez un hyperviseur, et le modèle se casse.

La couche de virtualisation s'insère entre les instructions du CPU et le matériel. Chaque accès mémoire rapide et chaque opération de système de fichiers concurrente est intercepté, traduit, émulé. Pour des compilations mesurées en minutes, c'est un coût lent et évitablement auto-infligé.

Dans notre labo, nous avons utilisé une base iOS réelle, plus de 2 millions de lignes de Swift et Objective-C mélangés. L'écart est net :

  • M4 Pro bare metal à 100 % (14 cœurs / 64 Go) : durée d'indexation et build incrémental 4 min 15 s. Charge stable, files NVMe non saturées.
  • VM au même profil M4 Pro (14 vCPU / 64 Go) : le temps incrémental passe à 12 min 40 s. Ventilateurs du serveur hôte à fond ; le noyau montre une part importante de sys time temps CPU dans les transpositions de tables de pages imbriquées et des chemins d'E/S de virtualisation bloqués.
BENCHMARK_EXECUTION.LOG
root@mg-lab-01:~$ xcodebuild -project Core_Enterprise.xcodeproj -benchmark
> Initiating Build Sequence...
> Allocating parallel compilation threads: 14

[VM Environment Detected - KVM/Hypervisor Hooked]
> Translation overhead: SEVERE
> I/O wait time spiking: > 4200ms
> Result: Build finished in 760.5s. (12m 40s)

root@mg-lab-02:~$ xcodebuild -project Core_Enterprise.xcodeproj -benchmark
> Initiating Build Sequence...

[Bare Metal Environment Detected - Direct Hardware Access]
> Native Metal framework hooked. Zero-copy memory mapped.
> Direct NVMe PCIe lanes confirmed.
> Result: Build finished in 255.0s. (4m 15s)

Au-delà de la taxe instructions et E/S, la colocation et les VM posent le problème cloud connu sous le nom de l'effet « voisin bruyant ». Plusieurs VM sur un même M4 : lorsqu'un autre locataire sature le CPU, votre instance devient instable. Les caches L2 et système se heurtent. Pour de la CI/CD qui doit être stable, cette variabilité est un vrai mode de défaillance.

Pire : le partage affaiblit la frontière de sécurité matérielle. Les canaux latéraux, de Spectre et Meltdown aux variantes spécifiques à l'ARM, restent une classe de problèmes réelle, en théorie et en pratique.

Chez NOVAKVM, nous tranchons de façon brutale, parce que c'est efficace : isolation physique. Vous n'achetez pas un abstrait « calcul » : vous obtenez un vrai Mac mini, carte et boîtier aluminium. À la fin du contrat, le plan de contrôle emprunte le chemin de sécurité maximal de la puce Apple vers le Secure Enclave, en détruisant le matériel de clé encapsulé matériellement, et, conformément au standard DoD 5220.22-M, effectue un écrasement physique profond de l'intégralité du disque NVMe.

Une fois cartographié le coût de la virtualisation, l'équipe a dû choisir : suivre le modèle de machine virtuelle utilisé partout avec de la sursouscription, ou prendre la voie plus dure et moins usitée. Nous avons pris la seconde option.

Nous ne pouvions pas faire de l'opérateur humain le goulot d'étranglement du cloud. Chez NOVAKVM, le plan de contrôle est entièrement piloté par le code.

Nos ingénieurs réseau et plateforme, après un long cycle de conception et de mise en service, s'appuient sur l'offre entreprise d'Apple MDM (Mobile Device Management) et, à partir de zéro, développent en Go un démon d'orchestration bare metal Mac à haute concurrence.

Lorsque vous cliquez sur DEPLOY INSTANCE dans la console, la séquence suivante s'exécute automatiquement dans un colo silencieux, à grande vitesse :

  1. Planification et sélection : l'ordonnanceur réserve une machine physique encore éteinte dans le pool de ressources.
  2. Remise à zéro et démarrage réseau : un PDU intelligent alimente l'unité ; le commutateur place le port sur un VLAN de récupération isolé.
  3. Déploiement d'image native : un serveur de déploiement sur liaison interne 10 Gbit/s pousse une image macOS propre ; le délai typique est inférieur à 90 secondes.
  4. Remise des accès : le MDM applique le routage IPv4 public statique et écrit votre clé publique SSH dans le chemin de confiance authorized_keys du système.

Le bare metal ne sert pas qu'à Xcode. La charge la plus lourde aujourd'hui est la recherche sur LLM locaux et l'inférence sur appareil.

Grâce à la mémoire unifiée, un M4 Pro physique avec 64 Go ou plus permet au GPU d'utiliser la RAM système comme de la VRAM sur toute la largeur. Avec le projet open source Apple MLX, vous chargez de très grands modèles sur l'hôte bare metal sans fragmentation mémoire habituelle ni échanges inter-dispositifs.

MLX_INFERENCE_TEST.LOG
# Sur un nœud bare metal NOVAKVM 64 Go, chargez un modèle peu élagué
root@mlx-engine:~$ python -m mlx_lm.generate \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --prompt "Explain quantum entanglement."

> Allocating unified memory buffer...
[OK] 48.2 GB mapped to GPU address space directly.
> Bootstrapping Neural Engine...

> Generation completed.
> Profiling: Token generation speed: 18.5 tokens/sec
> VRAM Overflow: FALSE (100% Native UMA Support)

Le cloud ne doit pas être bâti en empilant du lourd logiciel sur le matériel. La bonne direction est l'inverse : en haut, une automatisation fluide et des API solides ; en bas, un accès direct au silicium pour ne laisser aucune marge de matériel sur la table.

Chez NOVAKVM, nous appliquons l'infrastructure-as-code à la couche physique. La feuille de route inclut des fournisseurs de style Terraform : en quelques lignes, déclarer une flotte de vrais Mac sur plusieurs régions — dans l'esprit d'EC2, mais uniquement sur le métal.

L'ère de la marge sur la virtualisation n'est pas infinie. La taxe sur la performance est réelle, et les équipes d'ingénierie ne devraient plus la payer par défaut. Aujourd'hui, NOVAKVM refuse ce modèle et redéfinit la frontière de ce que signifie le « calcul » pour Mac dans le cloud.

Ne laissez pas des builds lents et saccadés briser votre concentration. C'est l'ère du bare metal : pur, brut, entièrement à vous lorsque vous êtes sur la machine.