GPU fraccionarias en Kubernetes

Visión general

La revolución de GenAI ha provocado un aumento en la demanda de GPU en toda la industria. Las empresas quieren capacitar, ajustar e implementar sistemas de LLM en cantidades masivas. Esto se ha traducido en una menor disponibilidad y, en consecuencia, en un aumento de los precios de las GPU más recientes. Las empresas que ejecutan cargas de trabajo en la nube pública se han visto afectadas por los altos precios y la creciente incertidumbre en cuanto a la disponibilidad de las GPU.

Estas nuevas realidades hacen que la capacidad de utilizar las GPU disponibles al máximo sea absolutamente fundamental. Particionar o compartir una sola GPU entre varios procesos ayuda en este sentido. Al implementarlo sobre Kubernetes, se obtiene una combinación ganadora: tenemos el escalado automático y un planificador sofisticado que nos ayuda a optimizar el uso de la GPU.

Opciones para compartir GPU

Para compartir una sola GPU con múltiples cargas de trabajo en Kubernetes, estas son las opciones que tenemos:

MIG

La GPU de instancias múltiples (MIG) permite que las GPU basadas en la arquitectura NVIDIA Ampere (como NVIDIA A100) se particionen de forma segura en instancias de GPU independientes para aplicaciones CUDA. Cada partición está completamente aislada de la memoria y la computación, y puede proporcionar un rendimiento y una latencia predecibles

Una sola GPU NVIDIA A100 se puede particionar en hasta 7 instancias de GPU aisladas. Cada partición aparece como una GPU independiente para el software que se ejecuta en un nodo particionado. Se muestran otras GPU compatibles con MIG y el número de particiones compatibles aquí.
Más información aquí

Pros

• Aislamiento total de computación y memoria que puede soportar una latencia y un rendimiento predecibles
• complemento de dispositivo nvidiapara kubernetes tiene soporte nativo para MIG

Contras

• Solo es compatible con GPU recientes como A100, H100 y A30. Esto termina limitando las opciones que uno tiene
• El número de particiones tiene un límite estricto de 7 para la mayoría de las arquitecturas. Esto es bastante menor si ejecutamos cargas de trabajo más pequeñas con requisitos de memoria y procesamiento limitados

Rebanar el tiempo

La segmentación temporal permite programar varias cargas de trabajo en la misma GPU. El tiempo de procesamiento se comparte entre los múltiples procesos y los procesos se intercalan en el tiempo. Un administrador de clústeres puede configurar un clúster o un nodo para anunciar un número determinado de réplicas o GPU, lo que reconfigura los nodos en consecuencia.

Pros

• No hay límite máximo para la cantidad de pods que pueden compartir una sola GPU
• Puede funcionar con versiones anteriores de las GPU NVIDIA

Contras

• Sin memoria ni aislamiento de errores. No existe una forma integrada de garantizar que una carga de trabajo no supere la memoria que se le ha asignado.
• La división del tiempo proporciona el mismo tiempo para todos los procesos en ejecución. Un módulo que ejecute varios procesos puede acaparar la CPU mucho más de lo previsto

Tenemos otras opciones disponibles para compartir GPU, como MPS y vGPU, pero no tienen soporte nativo en `nvidia-device-plugin` y no las discutiremos aquí.

Demostración de reducción del tiempo

Veamos un breve recorrido sobre cómo podemos utilizar el tiempo compartido en Azure Kubernetes Service. Empezaremos con un clúster de Kubernetes ya existente.

1. Agregue un grupo de nodos habilitado para GPU en el clúster

 
$ 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

‍‍Esto añadirá un nuevo grupo de nodos con un solo nodo al clúster AKS existente con una sola GPU NVIDIA T4. Esto se puede verificar ejecutando lo siguiente

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

2. Instale el operador de 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. Una vez instalado el operador, creamos una configuración temporal y configuramos todo el clúster para dividir los recursos de la GPU cuando estén disponibles‍‍

$ 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. Verifique que el nodo existente se haya reconfigurado correctamente‍

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

5. Podemos verificar la configuración creando una implementación con 4 réplicas, cada una de las cuales solicite 2 recursos de 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

Compruebe que todos los pods de esta implementación hayan aparecido en el mismo nodo ya creado y que haya podido alojarlos.

Conclusión

La revolución de GenAI ha cambiado el panorama de los requisitos de GPU y ha hecho que ser responsable con el uso de los recursos sea más importante que nunca. Los dos enfoques descritos aquí presentan deficiencias, pero no hay forma de evitar ser responsables con los costos de la GPU en el escenario actual.