Fraktionierte GPUs in Kubernetes

Überblick

Die GenAI-Revolution hat in der gesamten Branche zu einem Anstieg der GPU-Nachfrage geführt. Unternehmen wollen LLMs in großen Mengen schulen, optimieren und einsetzen. Dies hat zu einer geringeren Verfügbarkeit und einem daraus resultierenden Anstieg der Preise für die neuesten GPUs geführt. Unternehmen, die Workloads in der Public Cloud ausführen, litten unter hohen Preisen und zunehmender Unsicherheit hinsichtlich der GPU-Verfügbarkeit.

Diese neuen Realitäten machen es absolut wichtig, verfügbare GPUs maximal nutzen zu können. Die Partitionierung oder gemeinsame Nutzung einer einzelnen GPUs durch mehrere Prozesse hilft dabei. Die Implementierung auf Kubernetes bietet eine erfolgreiche Kombination, bei der wir Autoscaling und einen ausgeklügelten Scheduler zur Optimierung der GPU-Auslastung erhalten.

Optionen für die gemeinsame Nutzung von GPUs

Um eine einzelne GPU mit mehreren Workloads in Kubernetes zu teilen, haben wir folgende Optionen:

MIG

Mit der Multi-Instance GPU (MIG) können GPUs, die auf der NVIDIA Ampere-Architektur basieren (wie NVIDIA A100), sicher in separate GPU-Instances für CUDA-Anwendungen partitioniert werden. Jede Partition ist vollständig speicher- und rechenisoliert und bietet vorhersehbaren Durchsatz und Latenz

Eine einzelne NVIDIA A100-GPU kann in bis zu 7 isolierte GPU-Instanzen partitioniert werden. Jede Partition wird der Software, die auf einem partitionierten Knoten ausgeführt wird, als separate GPU angezeigt. Andere MIG-unterstützte GPUs und die Anzahl der unterstützten Partitionen sind aufgeführt hier.
Mehr Infos hier

Profis

• Vollständige Rechen- und Speicherisolierung, die vorhersehbare Latenz und Durchsatz unterstützt
• nvidia-device-pluginfür Kubernetes hat native Unterstützung für MIG

Nachteile

• Wird nur für aktuelle GPUs wie A100, H100, A30 unterstützt. Dies schränkt letztendlich die Möglichkeiten ein, die man hat
• Die Anzahl der Partitionen hat für die meisten Architekturen eine feste Grenze von 7. Das ist ziemlich weniger, wenn wir kleinere Workloads mit begrenzten Speicher- und Rechenanforderungen ausführen

Zeitaufteilung

Time Slicing ermöglicht die Planung mehrerer Workloads auf derselben GPU. Die Rechenzeit wird von mehreren Prozessen gemeinsam genutzt, und die Prozesse sind zeitlich verschachtelt. Ein Clusteradministrator kann einen Cluster oder Knoten so konfigurieren, dass eine bestimmte Anzahl von Replikaten/GPU angekündigt wird, wodurch die Knoten entsprechend neu konfiguriert werden.

Profis

• Keine Obergrenze für die Anzahl der Pods, die sich eine einzelne GPU teilen können
• Kann mit älteren Versionen von NVIDIA-GPUs arbeiten

Nachteile

• Keine Speicher- oder Fehlerisolierung. Es gibt keine eingebaute Methode, die sicherstellt, dass ein Workload den ihm zugewiesenen Arbeitsspeicher nicht überschreitet.
• Time Slicing bietet allen laufenden Prozessen die gleiche Zeit. Ein Pod, auf dem mehrere Prozesse ausgeführt werden, kann die CPU viel stärker beanspruchen als beabsichtigt

Es gibt andere Optionen für die gemeinsame Nutzung von GPUs wie MPS und vGPUs, aber sie haben keine native Unterstützung in `nvidia-device-plugin` und wir werden sie hier nicht besprechen.

Demo zum Zeitschneiden

Lassen Sie uns einen kurzen Überblick darüber geben, wie wir Timesharing in Azure Kubernetes Service nutzen können. Wir beginnen mit einem bereits vorhandenen Kubernetes-Cluster.

1. Fügen Sie dem Cluster einen GPU-fähigen Knotenpool hinzu

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

‍‍Dadurch wird dem vorhandenen AKS-Cluster mit einer einzigen NVIDIA T4-GPU ein neuer Knotenpool mit einem einzelnen Knoten hinzugefügt. Dies kann überprüft werden, indem Sie Folgendes ausführen

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

2. Installieren Sie den GPU-Operator

$ 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. Sobald der Operator installiert ist, erstellen wir eine Time-Slicing-Konfiguration und konfigurieren den gesamten Cluster so, dass die GPU-Ressourcen aufgeteilt werden, sofern verfügbar‍‍

$ kubectl apply -f - <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. Stellen Sie sicher, dass der vorhandene Knoten erfolgreich neu konfiguriert wurde‍

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

5. Wir können die Konfiguration überprüfen, indem wir eine Bereitstellung mit 4 Replikaten erstellen, von denen jedes nach 2 nvidia.com/gpu-Ressourcen fragt

$ kubectl apply -f - <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

Stellen Sie sicher, dass sich alle Pods dieser Bereitstellung auf demselben bereits erstellten Knoten befinden und er sie aufnehmen konnte.

Fazit

Die GenAI-Revolution hat die Landschaft der GPU-Anforderungen verändert und die verantwortungsvolle Nutzung von Ressourcen wichtiger denn je gemacht. Beide hier skizzierten Ansätze weisen Mängel auf, aber im aktuellen Szenario führt kein Weg daran vorbei, die Verantwortung für die GPU-Kosten zu übernehmen.