Orchestration GPU sur Kubernetes en 2026 : DRA, MIG et Time-Slicing pour le Serving LLM

Dans les architectures d’IA générative en production, le GPU représente à la fois le premier poste de coût d’infrastructure et le principal goulet d’étranglement de scalabilité. Allouer des accélérateurs matériels (NVIDIA H100, L40S, A100) à des ServingRuntimes LLM (vLLM, KServe, TGI) ou à des services auxiliaires (modèles d’embedding, rerankers, pipelines RAG) exige une granularité d’orchestration bien supérieure au modèle historique de réservation statique de nœuds entiers.

Le passage à l’échelle sur Kubernetes et Red Hat OpenShift AI repose sur trois mécanismes d’allocation complémentaires : le Time-Slicing, le Multi-Instance GPU (MIG) et l’adoption de la Dynamic Resource Allocation (DRA) introduite par les récentes versions de Kubernetes.

---

1. Les limites du Device Plugin NVIDIA classique (1 Pod = 1 GPU)

Historiquement, le k8s-device-plugin exposait les GPUs comme des ressources entières et discrètes (nvidia.com/gpu: 1). Si cette approche est adaptée aux charges d’entraînement lourd distribué (PyTorch, Ray Train), elle devient inefficace pour l’inférence :

• Sous-utilisation massive de la VRAM : Déployer un modèle d’embedding (0.5 Go de VRAM) ou un reranker sur un GPU de 80 Go immobilise l’accélérateur complet au détriment d’autres charges.
• Absence d’isolation matérielle : Le partage applicatif non contraint entraîne des contentions de bus mémoire et des dégradations imprévisibles de la latence de premier token (TTFT).
• Manque de flexibilité topologique : Impossible d’exprimer des contraintes d’affinité NVLink ou de bande passante inter-cartes sans configurations manuelles complexes.

---

2. Comparatif des stratégies d’allocation GPU

Stratégie	Isolation Mémoire & Calcul	Cas d’Usage Recommandé	Avantages	Limites
Time-Slicing	Nulle (Partage temporel)	Dev, tests, embeddings légers à faible trafic	Zéro configuration matérielle, surallocation élevée	Risque de OOM croisé, pas de QoS garantie
NVIDIA MIG	Matérielle stricte (VRAM + SMs)	Inférence multi-tenant, cohabitation de ServingRuntimes	QoS garantie, isolation totale des pannes	Profils fixes (ex: 1g.10gb, 3g.40gb), GPUs haut de gamme uniquement (A100/H100)
DRA (Dynamic Resource Allocation)	Dynamique via CDI / Structured Parameters	Clusters hétérogènes, orchestration LLMOps avancée	Déclaration fine des attributs matériels, découplage du scheduler	Nécessite un cluster Kubernetes récent (1.30+) et drivers adaptés

---

3. L’avènement de la Dynamic Resource Allocation (DRA)

La Dynamic Resource Allocation (DRA) et l’interface CDI (Container Device Interface) transforment la manière dont Kubernetes gère les accélérateurs :

• Paramètres structurés (Structured Parameters) : Au lieu d’une simple quantité entière, le Pod exprime des revendications de ressources (ResourceClaims) basées sur la mémoire requise, les interconnexions NVLink ou la génération de compute.
• Allocation à la volée : Le scheduler Kubernetes alloue dynamiquement la ressource exacte lors du scheduling sans obliger l’administrateur à reconfigurer statiquement les profils de chaque nœud du cluster.
• Co-scheduling optimisé : Coordination native entre les allocations GPU, la topologie NUMA et la bande passante réseau pour le parallélisme de tenseurs (Tensor Parallelism) sous vLLM.

---

4. Mise en œuvre sur Red Hat OpenShift AI (RHOAI)

Au sein de la plateforme Red Hat OpenShift AI, ces capacités d’orchestration sont intégrées de façon industrielle :

• NVIDIA GPU Operator sous OpenShift : Automatisation du déploiement des drivers, du CDI, de MIG et du monitoring télémétrique DCGM via Prometheus.
• KNative & KServe Scale-to-Zero : Mise en sommeil des ServingRuntimes inactifs pour libérer instantanément les tranches GPU au profit de charges d’entraînement ou de batchs prioritaires.
• Orchestration hybride avec Ray / KubeRay : Distribution élastique des tâches de fine-tuning et de serving sur des pools hétérogènes.

---

5. Se former à l’ingénierie d’infrastructure IA avec Aperta Scientia

Pour concevoir et opérer des plateformes de calcul IA robustes, sécurisées et optimisées en coût :

• Cursus AS300 — AI Platform Engineer (399h) : Le parcours intensif pour maîtriser le déploiement d’OpenShift AI, le partitionnement GPU, vLLM, KServe et préparer la certification officielle Red Hat Certified Specialist in AI/ML (EX267).
• Cursus AS200 — DevOps & Platform Engineering (399h) : Le socle indispensable d’administration OpenShift, d’automatisation Ansible et de gestion des infrastructures cloud-native.

👉 Découvrir le cursus AS300 AI Platform Engineer | Explorer le cursus AS200 DevOps | Échanger avec l’équipe pédagogique

---

6. Références Techniques & Documentation

• Kubernetes Dynamic Resource Allocation (DRA) : Documentation Officielle Kubernetes
• NVIDIA Multi-Instance GPU (MIG) Architecture : NVIDIA MIG User Guide
• Red Hat OpenShift AI Acceleration Docs : OpenShift AI Hardware Acceleration