Fractionele GPU's in Kubernetes

Overzicht

De GenAI-revolutie heeft geleid tot een enorme toename in de vraag naar GPU's in de hele sector. Bedrijven willen LLM's in grote aantallen trainen, fine-tunen en implementeren. Dit heeft geleid tot een lagere beschikbaarheid en een daaruit voortvloeiende stijging van de prijzen voor de nieuwste GPU's. Bedrijven die workloads in de public cloud uitvoeren, hebben te kampen met hoge prijzen en toenemende onzekerheid met betrekking tot de beschikbaarheid van GPU's.

Deze nieuwe realiteit maakt het absoluut noodzakelijk om beschikbare GPU's tot het uiterste te benutten. Het partitioneren of delen van een enkele GPU tussen meerdere processen helpt hierbij. De implementatie hiervan bovenop Kubernetes biedt een winnende combinatie waarin we autoscaling en een geavanceerde scheduler krijgen om te helpen bij het optimaliseren van het GPU-gebruik.

Opties voor het delen van GPU's

Om een enkele GPU te delen met meerdere workloads in Kubernetes, hebben we de volgende opties -MIG

Multi-Instance GPU (MIG) zorgt ervoor dat GPU's op basis van de NVIDIA Ampere-architectuur (zoals NVIDIA A100) veilig kunnen worden gepartitioneerd in afzonderlijke GPU-instances voor CUDA-toepassingen. Elke partitionering is volledig geïsoleerd qua geheugen en compute en kan zorgen voor een voorspelbare throughput en latency.

Een enkele NVIDIA A100 GPU kan worden gepartitioneerd in maximaal 7 geïsoleerde GPU-instances. Elke partitionering verschijnt als een afzonderlijke GPU voor de software die op een gepartitioneerde node draait. Andere door MIG ondersteunde GPU's en het aantal ondersteunde partitioneringen worden hier vermeld.
Meer info hier.

Voordelen

• Volledige compute- en geheugenisolatie die voorspelbare latency en throughput kan ondersteunen
• nvidia-device-pluginvoor Kubernetes heeft native ondersteuning voor MIG

Nadelen

• Alleen ondersteund voor recente GPU's zoals A100, H100, A30. Dit beperkt uiteindelijk de opties die men heeft
• Het aantal partitioneringen heeft een harde limiet van 7 voor de meeste architecturen. Dit is vrij weinig als we kleinere workloads uitvoeren met beperkte geheugen- en compute-vereisten

Time slicing

Time slicing maakt het mogelijk om meerdere workloads op dezelfde GPU in te plannen. Computetijd wordt gedeeld tussen de meerdere processen en de processen worden in de tijd afgewisseld. Een clusterbeheerder kan een cluster of node configureren om een bepaald aantal replica's/GPU aan te kondigen, wat de nodes dienovereenkomstig herconfigureert.

Voordelen

• Geen bovengrens aan het aantal pods dat een enkele GPU kan delen
• Kan werken met oudere versies van NVIDIA GPU's

Nadelen

• Geen geheugen- of foutisolatie. Er is geen ingebouwde manier om ervoor te zorgen dat een workload het toegewezen geheugen niet overschrijdt.
• Time slicing biedt gelijke tijd aan alle draaiende processen. Een pod die meerdere processen uitvoert, kan de CPU veel meer opeisen dan de bedoeling is

Er zijn andere opties beschikbaar voor het delen van GPU's, zoals MPS en vGPU's, maar deze hebben geen native ondersteuning in `nvidia-device-plugin` en we zullen ze hier niet bespreken.

Time slicing demo

Laten we een korte handleiding doornemen over hoe we time sharing kunnen benutten op Azure Kubernetes Service. We beginnen met een al bestaand Kubernetes-cluster.

1. Voeg een nodepool met GPU-ondersteuning toe aan het cluster

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

‍‍Dit voegt een nieuwe nodepool met een enkele node toe aan het bestaande AKS-cluster met een enkele NVIDIA T4 GPU. Dit kan worden geverifieerd door het volgende uit te voeren

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

2. Installeer de 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. Zodra de operator is geïnstalleerd, maken we een time slicing-configuratie aan en configureren we het gehele cluster om de GPU-resources te slicen waar beschikbaar‍‍

$ 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. Controleer of de bestaande node succesvol is geherconfigureerd‍

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

5. We kunnen de configuratie verifiëren door een deployment te maken met 4 replica's waarbij elke replica vraagt om 2 nvidia.com/gpu resources

$ 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

Controleer of alle pods van deze deployment zijn opgestart op dezelfde reeds aangemaakte node en dat deze in staat was om ze te accommoderen.

Conclusie

De GenAI-revolutie heeft het landschap van GPU-vereisten veranderd en het verantwoord omgaan met ressourcetoewijzing belangrijker gemaakt dan ooit. Er zijn tekortkomingen aan beide hier beschreven benaderingen, maar er is geen ontkomen aan om verantwoordelijk om te gaan met GPU-kosten in het huidige scenario.