Private AI sur VCF : l'architecture qui rentre dans ton DC

Tous les DSI se posent la même question : « Où vont tourner nos workloads IA ? » Le cloud public donne du GPU à la demande, mais saigne le budget et enferme les données dans une région tierce. La réponse que pousse Broadcom, c’est VCF Private AI Foundation — une stack construite sur VCF 9 qui rassemble GPU pooling, Kubernetes (VKS), bases vectorielles et schedulers Ray-like sous un même control plane.

Cet article parcourt cette architecture couche par couche. Pas le diagramme marketing — le vrai, avec les coutures visibles : où vSphere rencontre les drivers GPU, comment VKS expose les nodes avec des slices MIG, ce que fait NSX pour le trafic IA est-ouest, et quels composants sont matures contre encore bruts.

TL;DR

• VCF Private AI Foundation assemble GPU pooling, VKS, bases vectorielles et schedulers Ray-like sous un même control plane VCF 9.
• Les coutures à inspecter : vSphere ↔ drivers GPU, VKS ↔ slices MIG, NSX ↔ trafic IA est-ouest.
• Maturité inégale — choisir quelles couches adopter maintenant vs attendre.

Les quatre couches (compute, GPU, K8s, data)

Le service le plus utile que tu puisses te rendre en tant qu’architecte : arrêter de regarder Private AI Foundation comme un produit, et le voir comme quatre couches empilées, d’âges différents, de profils de risque différents, et surtout de coûts de sortie différents.

Couche 1 — compute. Clusters vSphere, vSAN ou baie externe, NSX, SDDC Manager, VCF Operations. Rien de spécifique à l’IA ici, et c’est précisément l’intérêt : le socle que tu construirais pour un parc de bases de données est le socle que tu construis pour de l’inférence. Ce qui change, c’est la forme des hôtes. Les serveurs porteurs de GPU sont plus gros, plus gourmands et plus rares que le reste de ta flotte : la topologie PCIe et la localité NUMA redeviennent un sujet, le budget électrique et le refroidissement deviennent une contrainte réelle sur le nombre d’hôtes, et tu te retrouves avec un îlot petit, cher et non fongible au milieu d’un cluster par ailleurs uniforme.

Couche 2 — GPU. Le driver côté hôte, le modèle de partitionnement (passthrough du device entier, vGPU en time-slicing, ou MIG), l’entitlement NVIDIA AI Enterprise et son service de licences, et la logique de placement qui décide quelle VM atterrit sur quelle carte physique. C’est la couche qui casse d’une manière que ton équipe vSphere n’a jamais vue.

Couche 3 — Kubernetes. VKS, avec des node pools capables de porter du GPU, le GPU Operator NVIDIA, le device plugin qui annonce la capacité GPU comme ressource schedulable, et le mobilier habituel : ingress, secrets, policies, GitOps. Une fois que le device plugin fonctionne, c’est du Kubernetes ordinaire, et tout ce que tu sais déjà reste vrai.

Couche 4 — data et modèles. Stockage objet pour les poids et les checkpoints, un registry pour les images et les artefacts de modèles, un vector store pour la recherche, et le pipeline qui transforme tes documents en embeddings. C’est la couche où VCF a le moins d’opinion native, et où les décisions ont le plus de conséquences.

Couche	Ce que VCF t’apporte vraiment	Ce qui reste ton problème
Compute	Clusters, HA/DRS, storage policies, lifecycle, supervision	BOM des hôtes, layout PCIe/NUMA, électricité et froid
GPU	Packaging du driver dans l’image ESXi, profils vGPU en VM classes	Discipline de version des drivers, licences NVIDIA, stratégie de profils
Kubernetes	Clusters VKS, node pools, lifecycle CAPI, CNI, stockage	GPU Operator, taints et tolerations, politique de quotas
Data & modèles	Du stockage, du réseau, un endroit où faire tourner les choses	Choix du vector store, pipeline d’embeddings, gouvernance des modèles

Lis ce tableau comme un ordre d’adoption. Les couches 1 et 3, tu peux les standardiser aujourd’hui sans quasiment aucun risque de regret. La couche 2, ça ne se configure pas, ça s’achète en discipline opérationnelle. La couche 4, tu as tout intérêt à la garder délibérément interchangeable.

Où vSphere rencontre le GPU

C’est la couture qui génère le plus de tickets de support, et il vaut mieux la comprendre avant de signer quoi que ce soit.

Tu as deux façons fondamentalement différentes de donner une carte à une VM. Le passthrough (DirectPath I/O, ou sa variante dynamique) confie le device physique entier à une seule VM. L’hyperviseur n’installe aucun driver GPU ; le guest charge le driver constructeur comme s’il était sur du bare-metal. La fidélité est parfaite, la matrice logicielle est courte, et tu perds tout ce que la virtualisation t’apportait : pas de partage, migration à chaud absente ou pénible, et une carte qui reste inactive dès que sa VM l’est. Le vGPU insère un device médié entre la carte et le guest. L’hôte ESXi porte un driver constructeur livré en VIB, le guest porte un driver compatible, et un profil sous licence décide de la quantité de framebuffer et de ressources de calcul que voit la VM.

Pour de l’IA, le vGPU est en général le bon défaut, pour une raison purement économique : un accélérateur qui dort est le moyen le plus rapide de détruire le business case. Le passthrough garde sa place pour les cas particuliers — un gros node d’entraînement dédié, un workload qui a besoin d’une fonction du device que le chemin médié n’expose pas, ou une appliance constructeur avec sa propre matrice de support.

La bonne réponse : traiter les versions de driver comme des artefacts déclarés, pas comme quelque chose qu’un admin installe. Mets le vendor addon et le composant driver dans l’image de cluster vSphere Lifecycle Manager, pour que le côté hôte fasse partie de l’état désiré. Construis tes images guest dans un pipeline qui épingle la version correspondante, et étiquette les deux avec le même identifiant : un désalignement se verra dans l’inventaire plutôt qu’au boot. Vérifier le côté hôte ne coûte rien :

# le driver vGPU hôte est-il réellement présent dans l'image active ?
esxcli software vib list | grep -i nvidia

# mode du device : shared direct (vGPU) vs passthrough
esxcli graphics device list
esxcli graphics host get

# vue des cartes côté hôte, depuis le shell ESXi
nvidia-smi

Deux points à dimensionner tôt. D’abord les licences : le chemin médié est conditionné à un entitlement, et le service de licences doit être joignable depuis les guests. Un segment réseau qui le bloque produit des workloads qui démarrent, tournent dégradés ou refusent de tourner — et qui ressemblent à un problème applicatif. Ensuite la migration à chaud : le vMotion de VM vGPU est supporté, mais le temps de stun croît avec le framebuffer à déplacer. Sur les gros profils, ça peut dépasser ce que tes fenêtres de maintenance et tes timings HA tolèrent. Mesure-le sur ton propre matériel, avec tes propres tailles de profil, avant de promettre à qui que ce soit du patch d’hôte non disruptif.

Les nodes VKS avec slices MIG

Multi-Instance GPU découpe une carte datacenter compatible en instances isolées matériellement, chacune avec sa part de mémoire, d’unités de calcul et de chemins de cache. Ce n’est pas du time-slicing : deux instances MIG sur la même carte ne se disputent pas les mêmes SM. C’est cette isolation qui rend acceptable de poser deux tenants sur un même accélérateur.

Ce que les architectes comprennent mal, c’est comment une carte découpée remonte jusqu’au scheduler Kubernetes. Le device plugin du GPU Operator annonce la capacité comme ressource étendue sur le node, et le nommage dépend de la stratégie choisie. En stratégie single, le node présente un compteur uniforme nvidia.com/gpu et un pod en demande simplement un, sans savoir qu’il obtient une fraction. En stratégie mixed, chaque profil devient un nom de ressource distinct, et les pods réclament la forme exacte dont ils ont besoin :

apiVersion: v1
kind: Pod
metadata:
  name: embeddings-worker
spec:
  nodeSelector:
    nvidia.com/gpu.present: "true"
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: serve
      image: registry.internal/embeddings:pinned
      resources:
        limits:
          nvidia.com/mig-1g.10gb: 1   # une slice, pas une carte

Trois conséquences en découlent, et ce sont toutes des conséquences de capacity planning, pas de configuration.

Les slices ne sont pas fongibles. Un node avec quatre petites instances ne peut pas satisfaire un pod qui en veut une grande, même si le silicium est inactif. Le scheduler voit des classes de ressources distinctes : ta décision de bin-packing se prend au moment de configurer les hôtes, avant qu’aucun workload n’existe. Un mix de profils mal choisi se manifeste par des pods bloqués en Pending sur un cluster que la supervision annonce sous-utilisé.

Les node pools doivent être séparés. Donne aux nodes GPU leur propre machine deployment, avec la VM class qui porte le profil vGPU, et tiens-le à distance de ton pool généraliste. Les mélanger, c’est garantir que le scheduler posera un service web stateless sur ton matériel le plus cher. La défense standard, c’est un taint sur le pool GPU avec la toleration correspondante uniquement sur les workloads GPU, plus des quotas de namespace qui plafonnent la ressource GPU par tenant — sinon la première équipe qui écrit un replicas généreux absorbe tout le pool.

Tu auras besoin de plus d’un pool. Les instances découpées vont bien à l’inférence et aux embeddings, où beaucoup de petits modèles tournent en parallèle. L’entraînement distribué, lui, veut des cartes entières avec l’interconnect intact, ce que MIG ne fournit délibérément pas. Prévois dès le départ au moins un pool d’inférence découpé et un pool GPU entier ; rattraper la séparation plus tard, c’est reconfigurer des hôtes et drainer des nodes.

Si tu n’as pas encore monté de cluster VKS, la mécanique des node pools est celle décrite dans le déploiement d’un premier cluster VKS — le GPU change la VM class et les taints, pas le modèle.

Ce qui est mature, ce qui reste brut

Voici la lecture honnête, et c’est la raison d’être de cet article. L’essentiel de Private AI Foundation n’est pas nouveau. La couche compute, c’est du VCF ordinaire. VKS, c’est du Kubernetes ordinaire, avec un lifecycle en production depuis assez longtemps pour avoir un vrai corpus de troubleshooting. La virtualisation GPU existe depuis des années — elle a grandi dans la VDI, et le chemin du device médié est balisé. Ce qui est réellement jeune, c’est la colle : l’automatisation spécifique à l’IA qui transforme ces trois couches matures en quelque chose qu’une équipe data science consomme en self-service.

Composant	Maturité	Décision d’architecte
Socle vSphere / vSAN / NSX	Mature	Standardiser maintenant, sans réserve IA
Clusters et node pools VKS	Mature	Standardiser maintenant
Partitionnement vGPU / MIG	Techno mature, exploitation exigeante	Adopter avec une discipline stricte sur les drivers
GPU Operator + device plugin	Largement déployé en upstream	Adopter, épingler les versions, tester les upgrades
Segmentation est-ouest du trafic IA	NSX mature, usages nouveaux	Réutiliser le modèle de policy existant
Images deep-learning, catalogues de modèles, self-service IA	Jeune	Piloter, ne pas encore standardiser
Vector store et pipeline de recherche	Dépend de l’écosystème	Garder interchangeable, décider tard

Un mot sur la ligne réseau. Le firewall distribué et la segmentation NSX ne sont pas neufs, mais le trafic IA les sollicite dans un motif nouveau : des flux est-ouest lourds et soutenus entre les pods d’inférence, le vector store et le stockage objet qui héberge les poids, souvent en traversant des frontières de tenants qui ne voyaient jusque-là que du nord-sud. La technologie est prête ; ce qui ne l’est en général pas, c’est le modèle de policy, parce que personne n’a écrit de règles pour un namespace qui parle massivement à un service de recherche partagé. Traite ça comme un exercice de conception de policy, pas comme une évaluation de produit.

La colle plus jeune mérite un avertissement lucide plutôt qu’un rejet. Les images deep-learning prêtes à l’emploi, les model stores et le provisioning par catalogue raccourcissent réellement le délai jusqu’à la première inférence, et si ton objectif du trimestre est une démonstration crédible, ils valent le coup. Mais la documentation bouge vite, les retours de terrain sont rares, et quand ça casse tu seras parmi les premiers à tomber dessus. C’est une position confortable pour un pilote et mauvaise pour un contrat de plateforme avec un SLA attaché.

Dernière note budgétaire, celle que les architectes apprennent souvent en dernier : l’entitlement logiciel NVIDIA est une ligne de coût distincte de tes licences VCF, et elle se compte en GPU, pas en cœurs. Mets ce chiffre devant la finance avant le gel du design, pas après la signature du devis matériel.

Conclusion

Private AI Foundation se comprend mieux comme un assemblage bien intégré de choses que tu fais déjà tourner, plus une couche fine et mouvante de confort spécifique à l’IA par-dessus. Ce cadrage n’est pas une critique — c’est justement ce qui rend la stack adoptable. Le risque, c’est d’acheter le diagramme marketing comme un monolithe et de découvrir que le composant le plus jeune fixe la maturité de tout le design.

Prochaine étape. L’article suivant descend en détail dans la couche 2 : le GPU pooling avec vGPU et MIG en pratique — choix des profils, scheduling de workloads mixtes, et les pièges qui n’apparaissent que sous contention. Vient ensuite la couche base vectorielle, où les choix t’appartiennent bien plus qu’à Broadcom.

Si tu construis tout ça sur un parc qui n’a pas encore de baseline de métriques, commence par là. Le taux d’utilisation GPU est le chiffre qui justifie ou tue tout le business case de l’IA privée, et ça ne se plaide pas rétroactivement — l’article sur les fondations d’observabilité couvre le terrassement.