GPU fractionnaires dans Kubernetes

Vue d'ensemble

La révolution GenAI a entraîné une augmentation de la demande de GPU dans l'industrie. Les entreprises souhaitent former, affiner et déployer des LLM en grande quantité. Cela s'est traduit par une baisse de la disponibilité et par conséquent une augmentation des prix des derniers GPU. Les entreprises qui exécutent des charges de travail sur le cloud public ont souffert de prix élevés et d'une incertitude croissante quant à la disponibilité des GPU.

Face à ces nouvelles réalités, il est absolument essentiel de pouvoir utiliser au maximum les GPU disponibles. Le partitionnement ou le partage d'un seul GPU entre plusieurs processus y contribue. L'implémenter en plus de Kubernetes constitue une combinaison gagnante où nous bénéficions d'une mise à l'échelle automatique et d'un planificateur sophistiqué pour optimiser l'utilisation du GPU.

Options de partage de GPU

Afin de partager un seul GPU avec plusieurs charges de travail dans Kubernetes, voici les options dont nous disposons :

MIG

Le GPU multi-instance (MIG) permet de partitionner de manière sécurisée les GPU basés sur l'architecture NVIDIA Ampere (tels que NVIDIA A100) en instances GPU distinctes pour les applications CUDA. Chaque partition est complètement isolée de la mémoire et du calcul et peut fournir un débit et une latence prévisibles

Un seul GPU NVIDIA A100 peut être partitionné en 7 instances GPU isolées au maximum. Chaque partition apparaît comme un GPU distinct pour le logiciel exécuté sur un nœud partitionné. Les autres GPU compatibles MIG et le nombre de partitions prises en charge sont répertoriés ici.
Plus d'informations ici

Pros

• Isolation complète du calcul et de la mémoire pouvant prendre en charge une latence et un débit prévisibles
• plug-in pour appareil NVIDIApour kubernetes dispose d'un support natif pour MIG

Les inconvénients

• Compatible uniquement avec les GPU récents tels que A100, H100, A30. Cela finit par limiter les options dont on dispose
• Le nombre de partitions est strictement limité à 7 pour la plupart des architectures. C'est nettement moins si nous exécutons des charges de travail plus petites avec des exigences de mémoire et de calcul limitées

Tranchage temporel

Le découpage temporel permet de planifier plusieurs charges de travail sur le même GPU. Le temps de calcul est partagé entre les multiples processus et les processus sont imbriqués dans le temps. Un administrateur de cluster peut configurer un cluster ou un nœud pour annoncer un certain nombre de réplicas/GPU, ce qui reconfigure les nœuds en conséquence.

Pros

• Aucune limite supérieure au nombre de pods pouvant partager un seul GPU
• Peut fonctionner avec les anciennes versions des GPU NVIDIA

Les inconvénients

• Pas de mémoire ni d'isolation des pannes. Il n'existe aucun moyen intégré de s'assurer qu'une charge de travail ne dépasse pas la mémoire qui lui est attribuée.
• Le découpage temporel fournit un temps égal à tous les processus en cours d'exécution. Un pod exécutant plusieurs processus peut monopoliser le processeur bien plus que prévu

D'autres options s'offrent à nous pour le partage de GPU, comme les MPS et les vGPU, mais elles ne sont pas prises en charge nativement dans `nvidia-device-plugin` et nous n'en discuterons pas ici.

Démo de Time Slicing

Passons en revue brièvement la manière dont nous pouvons utiliser le partage du temps sur Azure Kubernetes Service. Nous commençons par un cluster Kubernetes déjà existant.

1. Ajouter un pool de nœuds compatible GPU dans le cluster

 
$ az aks nodepool add \
    --name <nodepool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --node-vm-size Standard_NC4as_T4_v3 \
		--node-count 1

‍‍Cela ajoutera un nouveau pool de nœuds avec un seul nœud au cluster AKS existant avec un seul GPU NVIDIA T4. Cela peut être vérifié en exécutant ce qui suit

 
$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'

2. Installation de l'opérateur GPU

$ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
	&& helm repo update
$ helm install gpu-operator nvidia/gpu-operator \
-n gpu-operator --create-namespace \
--set driver.enabled=false \
--set toolkit.enabled=false \
--set operator.runtimeClass=nvidia-container-runtime

3. Une fois l'opérateur installé, nous créons une configuration de découpage temporel et configurons l'ensemble du cluster pour découper les ressources GPU, le cas échéant.‍‍

$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 10
EOF

# Reconfigure gpu operator to pick up the config map
$ kubectl patch clusterpolicy/cluster-policy \
-n gpu-operator --type merge \
-p '{"spec": {"devicePlugin": {"config": {"name": "time-slicing-config", "default": "any"}}}}'

4. Vérifiez que le nœud existant a été correctement reconfiguré‍

$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'
10

5. Nous pouvons vérifier la configuration en créant un déploiement avec 4 répliques, chacune demandant 2 ressources nvidia.com/gpu

$ kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: time-slicing-verification
  labels:
    app: time-slicing-verification
spec:
  replicas: 4
  selector:
    matchLabels:
      app: time-slicing-verification
  template:
    metadata:
      labels:
        app: time-slicing-verification
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      hostPID: true
      containers:
        - name: cuda-sample-vector-add
          image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubuntu20.04"
          command: ["/bin/bash", "-c", "--"]
          args:
            - while true; do /cuda-samples/vectorAdd; done
          resources:
           limits:
             nvidia.com/gpu: 1
EOF

Vérifiez que tous les modules de ce déploiement se trouvent sur le même nœud déjà créé et qu'il a pu les accueillir.

Conclusion

La révolution GenAI a changé le paysage des exigences en matière de GPU et a rendu plus que jamais la responsabilité en matière d'utilisation des ressources. Les deux approches décrites ici présentent des lacunes, mais il n'y a aucun moyen d'éviter d'être responsable des coûts du GPU dans le scénario actuel.