Appliquer les limites de mémoire GPU dans Kubernetes avec CUDA 13.4 et KAI Scheduler

NVIDIA a publié CUDA 13.4, introduisant une application transparente des limites de mémoire pour les charges de travail GPU. Pour opérationnaliser cette fonctionnalité dans Kubernetes, l'outil open source GPU Fractioning Operator fonctionne désormais avec KAI Scheduler v0.18.0 afin de gérer les ressources GPU fractionnées. Cette combinaison permet aux équipes de plateforme de partager les GPU plus efficacement tout en maintenant une isolation stricte de la mémoire.

Ce qui s'est passé

De nombreuses charges de travail d'inférence IA et de développement ne nécessitent pas un GPU entier. L'attribution de dispositifs complets à de petites tâches entraîne une capacité inutilisée significative. Bien que les GPU NVIDIA prennent en charge le partage depuis longtemps via Multi-instance GPU (MIG), le découpage temporel (time-slicing) ou le Multi-Process Service (MPS), les méthodes précédentes manquaient d'une application robuste des limites de mémoire dans les modes partagés. Le découpage temporel permettait aux processus de se relayer mais n'empêchait pas un processus de consommer toute la mémoire disponible. MPS autorisait l'exécution concurrente mais reposait sur la discipline de l'application concernant l'utilisation de la mémoire.

CUDA 13.4 comble cette lacune en appliquant les limites de mémoire de manière transparente au niveau du pilote. Les applications ne voient que leur fraction allouée de la mémoire, et les allocations dépassant cette limite échouent immédiatement. Pour combler le fossé entre cette capacité bas niveau et l'orchestration Kubernetes, NVIDIA a introduit le GPU Fractioning Operator. Hébergé sous l'organisation KAI Scheduler sur GitHub, cet opérateur fonctionne parallèlement au NVIDIA GPU Operator. Il gère la configuration de MPS sur chaque nœud, applique les limites de mémoire par charge de travail et signale l'utilisation par fraction plutôt que par GPU entier.

KAI Scheduler v0.18.0 s'intègre directement à cet opérateur via un nouveau mode de partage GPU appelé NvFractions. Le planificateur sélectionne les GPU appropriés en fonction de la mémoire disponible et écrit des annotations spécifiques dans les spécifications des Pods. Le GPU Fractioning Operator lit ces annotations et configure le nœud pour appliquer les limites de mémoire et les modes de calcul demandés avant le démarrage du conteneur. Cette séparation des responsabilités garantit que les décisions de planification restent distinctes de l'application au niveau du nœud.

Comment cela fonctionne

Le système repose sur deux modes de calcul pour le partage des ressources GPU : le découpage temporel (time-slicing) et le partage SM (sm-sharing). Dans le découpage temporel, les charges de travail utilisent le GPU entier à tour de rôle. Si une charge de travail est inactive, son créneau horaire est redistribué aux autres. Ce mode offre une isolation complète des erreurs, ce qui signifie qu'un plantage dans une charge de travail n'affecte pas les autres. Dans le partage SM, les multiprocesseurs de flux (SM) du GPU sont divisés entre les charges de travail concurrentes. Toutes les charges de travail actives s'exécutent simultanément, et les SM inutilisés sont réalloués dynamiquement. Cependant, le partage SM place les charges de travail dans un seul domaine d'erreur, de sorte qu'une défaillance dans l'une peut affecter les autres.

CUDA 13.4 applique les limites de mémoire quel que soit le mode de calcul. Une charge de travail peut demander une quantité exacte de mémoire ou une plage comprenant un minimum garanti et un maximum élastique (burstable). Si une charge de travail tente d'allouer de la mémoire au-delà de sa limite, l'allocation échoue comme elle le ferait sur un GPU physique plus petit. Cette application est transparente pour l'application, ne nécessitant aucune modification du code. Le GPU Fractioning Operator garantit que ces limites sont appliquées en configurant les démons MPS sous-jacents et en surveillant l'utilisation par fraction.

Les planificateurs communiquent leurs exigences à l'opérateur en utilisant des annotations standard de Pod Kubernetes. Ces annotations spécifient la demande de mémoire garantie, la limite élastique optionnelle, le mode de calcul souhaité et les dispositifs GPU spécifiques attribués. L'opérateur analyse ces champs et les traduit en configurations au niveau du nœud. Ce mécanisme permet à tout planificateur Kubernetes capable d'écrire ces annotations de tirer parti de l'application de la mémoire de CUDA, bien que KAI Scheduler soit le premier à offrir une intégration native.

Détails clés

• CUDA 13.4 introduit une application transparente des limites de mémoire, permettant des quantités exactes de mémoire ou des plages élastiques pour les charges de travail GPU partagées.
• Le GPU Fractioning Operator est un outil open source qui configure MPS, applique les limites de mémoire et mesure l'utilisation par fraction de GPU.
• KAI Scheduler v0.18.0 inclut un mode NvFractions qui écrit les annotations de Pod nécessaires pour que l'opérateur applique les limites.
• Les charges de travail peuvent choisir entre le découpage temporel (exécution sérielle avec isolation des erreurs) et le partage SM (exécution parallèle avec allocation dynamique des SM).
• Les demandes de mémoire peuvent être définies comme des tailles absolues (par ex., "40Gi") ou comme des portions d'un GPU (par ex., "0.5").
• Les administrateurs activent l'intégration lors de l'installation de KAI Scheduler à l'aide d'un indicateur Helm, qui installe le GPU Fractioning Operator comme dépendance.

Pourquoi c'est important

Pour les équipes d'ingénierie construisant des infrastructures ML, cette mise à jour améliore considérablement l'utilisation des ressources sans sacrifier la stabilité. Auparavant, le partage de GPU signifiait souvent choisir entre une mauvaise isolation (MPS) ou un partitionnement rigide (MIG). Avec CUDA 13.4 et le GPU Fractioning Operator, les équipes peuvent regrouper davantage de charges de travail sur le matériel existant tout en garantissant qu'aucune tâche unique ne puisse affamer les autres en mémoire. Cela est particulièrement précieux pour les services d'inférence et les environnements de développement où les charges de travail varient en taille et en intensité.

La capacité de définir des limites de mémoire élastiques ajoute de la flexibilité pour les tâches par lots ou d'entraînement qui peuvent occasionnellement avoir besoin de plus de ressources. Si la mémoire est libre, une charge de travail peut s'étendre ; sinon, elle reste dans son minimum garanti. Cette allocation dynamique réduit le besoin de surprovisionnement. De plus, la distinction claire entre le découpage temporel et le partage SM permet aux architectes d'adapter le mode de partage aux exigences de tolérance aux pannes de la charge de travail. Les services critiques de production peuvent utiliser le découpage temporel pour l'isolation, tandis que les tâches par lots résilientes peuvent utiliser le partage SM pour un débit plus élevé.

Ce que vous pouvez faire

• Installez KAI Scheduler v0.18.0 ou ultérieur avec l'indicateur Helm global.nvFractions.set=true pour activer la prise en charge du fractionnement GPU.
• Consultez le dépôt du GPU Fractioning Operator sur GitHub pour les guides d'installation et les détails de configuration.
• Mettez à jour les spécifications des Pods pour inclure des annotations pour les demandes de mémoire, les limites et les modes de calcul lors du déploiement de charges de travail fractionnées.
• Choisissez le découpage temporel pour les charges de travail nécessitant une isolation des erreurs et le partage SM pour celles nécessitant une exécution parallèle et une utilisation dynamique des SM.
• Surveillez l'utilisation GPU par fraction à l'aide des métriques fournies par le GPU Fractioning Operator pour optimiser l'allocation des ressources.
• Rejoignez le canal Slack de KAI Scheduler ou les réunions communautaires bimensuelles pour poser des questions et contribuer au projet.