Publié le 29 septembre 2026 à 11:00 · Publication originale
Le modèle n'utilise pourtant qu'une partie de sa mémoire et de sa capacité de calcul.
Le reste existe, consomme et coûte.
Faire simplement tourner plusieurs applications sur le même GPU améliore son utilisation, mais crée une concurrence: une charge peut saturer la mémoire ou les caches et dégrader les autres.
NVIDIA a développé une autre mécanique: MIG, pour "Multi-Instance GPU".
Sur les GPU compatibles, une puce physique peut être découpée en plusieurs instances isolées.
Il ne s'agit pas seulement d'attribuer une fraction théorique de puissance à chaque utilisateur.
Chaque instance reçoit des ressources matérielles dédiées. NVIDIA isole notamment des portions de cache L2, des contrôleurs mémoire et des chemins vers la mémoire DRAM. Une charge qui sature sa propre bande passante mémoire ne doit donc pas absorber celle de sa voisine.
Sur plusieurs GPU A100, H100, H200, B200 ou GB200, jusqu'à sept instances peuvent ainsi coexister selon les profils disponibles.
Pour Kubernetes, ces ressources peuvent ensuite être exposées aux applications comme des dispositifs attribuables.
Et l'orchestration évolue.
Depuis Kubernetes 1.35, l'allocation dynamique de ressources, DRA, est stable. Au lieu de demander seulement "un GPU", une application peut exprimer des besoins matériels qui sont associés à des dispositifs disponibles par le planificateur et les pilotes.
En septembre 2026, Kubernetes 1.37 a encore étendu cette architecture.
Une infrastructure IA commence alors à ressembler moins à une collection de GPU qu'à un marché interne de capacités matérielles.
Cette différence devient économique.
Une équipe n'a pas nécessairement besoin d'une puce entière.
Elle a besoin d'une quantité déterminée de mémoire, de calcul et d'isolation pendant une durée déterminée.
ULTRA®
Partitionner un GPU améliore son utilisation, mais peut supprimer certaines propriétés recherchées pour le calcul distribué.
Avec MIG, les instances disposent de chemins mémoire isolés. Cette isolation a un prix: NVIDIA indique que CUDA IPC n'est pas pris en charge entre instances MIG et que NVLink/NVSwitch ne sont alors pas disponibles pour leur communication.
Une architecture excellente pour servir plusieurs charges indépendantes peut donc devenir mauvaise pour un calcul qui doit échanger massivement entre accélérateurs.
Conseil: mesurer l'utilisation mémoire, la bande passante et le profil de communication avant de choisir la granularité des instances.
Kubernetes DRA ajoute une couche intéressante: le besoin matériel peut être formulé comme une revendication de ressource, puis associé à un dispositif compatible.
Le FinOps IA descend ainsi jusqu'au silicium.
Deux équipes facturées chacune pour "un GPU" peuvent consommer des fractions radicalement différentes de la ressource physique réellement rare.