Portée de cet article. Les trois mécanismes qui permettent à une ou plusieurs machines virtuelles d’utiliser un accélérateur, ce que chacun impose en exploitation, et comment choisir. Les commandes de mise en œuvre dépendent de la plateforme et ne sont pas détaillées ici. L’ordonnancement de conteneurs et les accélérateurs autres que ceux de NVIDIA ne sont pas traités.
Un accélérateur dans un serveur, et trois équipes qui le demandent. La question n’est pas de savoir laquelle passe en premier, mais si la carte peut les servir toutes les trois, et à quelles conditions.
Trois mécanismes répondent à cette question. Ils ne diffèrent pas par leur performance brute mais par ce qu’ils imposent au reste de l’exploitation : la maintenance, les licences, et l’engagement de service. C’est là que se joue le choix, pas dans un comparatif de débit.
Trois mécanismes, trois compromis
| Mécanisme | Partage | Isolation | Licence éditeur |
|---|---|---|---|
| Passthrough PCIe | Aucun : une carte, une machine virtuelle | Totale, par construction | Non |
| vGPU | Mémoire découpée, calcul ordonnancé dans le temps | Logicielle | Oui |
| MIG | Partition matérielle en instances | Matérielle | Selon l’usage |
Le passthrough : la carte entière, sans intermédiaire
L’hyperviseur détache le périphérique de l’hôte et le remet tel quel à une machine virtuelle, qui charge le pilote du constructeur comme sur du matériel physique. Performance native, aucune couche intermédiaire, aucune licence supplémentaire.
Trois choses le compliquent, et la troisième est de loin la plus coûteuse.
Les groupes d’isolation
Le contrôleur d’entrées-sorties regroupe les périphériques par ensembles indissociables. Si la carte partage son groupe avec un autre contrôleur, il faut affecter tout le groupe à la même machine virtuelle, ou renoncer.
Il existe un contournement qui force la séparation des groupes. Il n’est pas pris en charge par les constructeurs, et il retire précisément la protection qui empêche un périphérique d’accéder à la mémoire d’un autre. Sur une plateforme mutualisée, c’est une frontière de sécurité qu’on supprime en échange d’une commodité de câblage. La bonne réponse est de changer d’emplacement physique, pas de désactiver la protection.
Une carte expose plusieurs fonctions
Un accélérateur se présente rarement comme un périphérique unique : il en expose souvent deux ou plus, dont un contrôleur audio hérité de son ascendance graphique. Affecter la fonction principale sans les autres produit une machine virtuelle qui démarre, voit la carte, et échoue au chargement du pilote. Le message d’erreur ne désigne jamais la fonction manquante.
Ce que le passthrough coûte en exploitation
Une machine virtuelle qui détient un périphérique physique ne peut pas être migrée à chaud. C’est vrai sur toutes les plateformes courantes, et cela change la nature de l’exploitation bien plus profondément qu’on ne l’anticipe.
L’évacuation d’un hôte devient impossible. Chaque mise à jour du noyau, chaque remplacement d’alimentation, chaque intervention matérielle exige un arrêt planifié des machines concernées, négocié avec leurs utilisateurs. Sur une plateforme classique, la maintenance est une opération invisible ; sur des hôtes en passthrough, c’est un événement.
Ce coût doit figurer dans la conception, pas être découvert au premier correctif de sécurité. C’est l’un des points que nous instruisons dans un cadrage d’infrastructure GPU, parce qu’il détermine le nombre d’hôtes nécessaires autant que la charge elle-même.
Le vGPU : partage dans le temps, avec licence
Un pilote installé sur l’hôte découpe la carte en instances virtuelles. Chacune reçoit une part fixe de la mémoire embarquée et un accès au calcul réparti dans le temps par un ordonnanceur.
Trois contraintes accompagnent ce mécanisme.
Les pilotes hôte et invité forment un couple. Leurs versions doivent correspondre. Mettre à jour l’un sans l’autre casse le service, ce qui impose de coordonner les mises à jour de toutes les machines virtuelles avec celles de l’hôte.
Une licence de l’éditeur est nécessaire, facturée à l’instance ou à l’utilisateur simultané selon le niveau, et non à la carte physique. Le coût suit donc le nombre d’utilisateurs, pas le matériel. Nous ne plaçons pas de licences ; ce point relève de votre relation directe avec l’éditeur, et il doit être chiffré avant l’achat des cartes, pas après.
Le calcul est partagé, donc soumis à contention. Une instance qui sollicite intensément la carte ralentit les autres. Pour des postes de travail graphiques, c’est acceptable et même souhaitable. Pour un service dont on veut tenir le temps de réponse, ça ne l’est pas.
MIG : une partition matérielle, pas un partage
Sur les architectures récentes, la carte se divise en instances dont les chemins mémoire sont séparés physiquement : le réseau interne, les bancs de cache, les contrôleurs mémoire et les bus d’adresses sont attribués à une instance et à une seule.
La conséquence est décisive : il n’y a pas de contention entre instances. Une charge intense sur l’une ne ralentit pas les autres, et une défaillance applicative reste confinée. C’est ce qui rend le mécanisme pertinent dès qu’on doit tenir un engagement de service, ou isoler des équipes qui ne doivent pas se voir.
Deux limites en découlent directement.
La géométrie est imposée. On ne découpe pas librement : l’architecture définit des profils, et l’on choisit parmi eux. Sur une carte de génération récente, l’administrateur crée par exemple deux instances de grande taille, ou quatre moyennes, ou sept petites. Un besoin qui tombe entre deux profils se paie en capacité inutilisée.
L’activation n’est pas une opération à chaud. Basculer la carte dans ce mode exige une réinitialisation, des privilèges élevés, et l’arrêt préalable de tout service tenant une référence sur le pilote — supervision matérielle et télémétrie comprises. À planifier comme une intervention, pas comme un réglage.
Le tableau de décision
| Situation | Mécanisme |
|---|---|
| Une charge unique qui sature la carte, entraînement ou calcul intensif | Passthrough |
| Plusieurs postes de travail graphiques, charge irrégulière | vGPU |
| Plusieurs services d’inférence avec engagement de temps de réponse | MIG |
| Équipes ou clients à cloisonner strictement | MIG |
| Maintenance sans interruption exigée | Écarter le passthrough |
Les deux derniers mécanismes se combinent : une instance matérielle peut elle-même être partagée dans le temps, ce qui multiplie le nombre de machines virtuelles servies par une seule carte.
Le piège de dimensionnement
Le calcul se partage, la mémoire se découpe. Cette différence est la source d’erreur la plus fréquente.
Découper une carte en sept instances ne crée pas sept fois plus de capacité mémoire : chaque instance ne dispose que de sa part. Un modèle doit tenir dans l’instance, pas dans la carte. Une carte de grande capacité découpée en sept ne peut plus héberger le modèle qui tenait tout juste dessus entière.
Et la mémoire nécessaire ne se limite pas aux poids : le cache d’attention croît avec la longueur de contexte et le nombre de requêtes simultanées, et il doit être calculé avant tout découpage, comme le détaille notre article sur le dimensionnement de la VRAM. Le partitionnement doit donc être décidé après ce calcul, jamais avant.
Ce qu’un laboratoire ne montre pas
Sur une carte unique, dans un laboratoire, les trois mécanismes fonctionnent et se ressemblent. Ce qui les sépare n’apparaît qu’en exploitation : la coordination des versions de pilotes, le coût de licence indexé sur les utilisateurs, l’impossibilité d’évacuer un hôte, et la contention entre charges concurrentes.
Aucun de ces quatre points ne se mesure sur une maquette à une seule machine virtuelle.
Une séquence de vérification
- Confirmer que le contrôleur d’entrées-sorties est actif, et relever le contenu du groupe auquel appartient la carte.
- Vérifier que toutes les fonctions exposées par la carte sont bien affectées à la même machine virtuelle.
- Relever les versions de pilote côté hôte et côté invité, et confirmer qu’elles forment un couple valide.
- Vérifier que le mode de partitionnement est réellement actif et que les profils correspondent au découpage prévu.
- Le contrôle décisif. Lancer une charge soutenue sur une instance, mesurer le temps de réponse sur une autre. S’il se dégrade, l’isolation n’est pas celle que la configuration annonce.
Ce dernier point est le seul qui mesure un comportement plutôt qu’un réglage, et c’est celui qui distingue une plateforme sur laquelle on peut s’engager d’une plateforme qui fonctionne tant que personne ne la sollicite. Il fait partie de la recette de toute plateforme d’inférence que nous mettons en service.
Ce que cet article ne traite pas
Le partage d’accélérateurs entre conteneurs relève d’autres mécanismes, gérés par l’ordonnanceur plutôt que par l’hyperviseur, avec des propriétés d’isolation différentes. Les accélérateurs d’autres constructeurs disposent de mécanismes équivalents dont les contraintes de licence et de pilote ne se transposent pas.
Les accès directs entre cartes et entre cartes et réseau, déterminants pour l’entraînement réparti, sortent également du périmètre : ils imposent leurs propres contraintes de topologie, souvent incompatibles avec un découpage.
Sources
- NVIDIA, Multi-Instance GPU User Guide — partitionnement, isolation des chemins mémoire, conditions d’activation.
- NVIDIA, Virtual GPU Software User Guide — profils, appariement des pilotes, modèle de licence.
- Documentation du noyau Linux, VFIO — groupes d’isolation et affectation de périphériques.
- Documentation Proxmox VE et OpenShift Virtualization — mise en œuvre sur chaque plateforme.