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

> Analyse comparative des mécanismes d'allocation GPU sous Kubernetes et OpenShift AI : Dynamic Resource Allocation (DRA), Multi-Instance GPU et Time-Slicing.

- **Date de publication** : 2026-09-09T08:00:00.000Z

---

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 (3 mois) :** 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 (3 mois) :** Le socle indispensable d'administration OpenShift, d'automatisation Ansible et de gestion des infrastructures cloud-native.

👉 **[Découvrir le cursus AS300 AI Platform Engineer](/fr/curriculums/as300/)** | **[Explorer le cursus AS200 DevOps](/fr/curriculums/as200/)** | **[Échanger avec l'équipe pédagogique](/fr/contact/)**

---

### 6. Références Techniques & Documentation
* **Kubernetes Dynamic Resource Allocation (DRA) :** [Documentation Officielle Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* **NVIDIA Multi-Instance GPU (MIG) Architecture :** [NVIDIA MIG User Guide](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/)
* **Red Hat OpenShift AI Acceleration Docs :** [OpenShift AI Hardware Acceleration](https://docs.redhat.com/en/documentation/red_hat_openshift_ai/)

---

*Source : https://aperta.io/fr/radar/2026-09-09-orchestration-gpu-kubernetes-dra-mig-time-slicing-llmops/ — Aperta Scientia Tech Radar*