GPUs Fracionadas no Kubernetes

Visão Geral

A revolução da GenAI levou a um aumento na demanda por GPUs em toda a indústria. As empresas querem treinar, ajustar e implantar LLMs em grandes quantidades. Isso resultou em menor disponibilidade e consequente aumento nos preços das GPUs mais recentes. Empresas que executam cargas de trabalho na nuvem pública têm sofrido com preços altos e crescente incerteza em relação à disponibilidade de GPUs.

Essas novas realidades tornam absolutamente crítico ser capaz de utilizar as GPUs disponíveis ao máximo. Particionar ou compartilhar uma única GPU entre múltiplos processos ajuda nisso. Implementá-lo sobre o Kubernetes oferece uma combinação vencedora, onde obtemos autoescalonamento e um agendador sofisticado para ajudar na otimização da utilização da GPU.

Opções para compartilhar GPUs

Para compartilhar uma única GPU com múltiplas cargas de trabalho no Kubernetes, estas são as opções que temos -

MIG

Multi-Instance GPU (MIG) permite que GPUs baseadas na arquitetura NVIDIA Ampere (como a NVIDIA A100) sejam particionadas de forma segura em instâncias de GPU separadas para aplicações CUDA. Cada partição é completamente isolada em termos de memória e computação e pode fornecer throughput e latência previsíveis.

Uma única GPU NVIDIA A100 pode ser particionada em até 7 instâncias de GPU isoladas. Cada partição aparece como uma GPU separada para o software em execução em um nó particionado. Outras GPUs compatíveis com MIG e o número de partições suportadas estão listados aqui.
Mais informações aqui

Prós

• Isolamento completo de computação e memória que pode suportar latência e throughput previsíveis
• nvidia-device-pluginpara Kubernetes tem suporte nativo para MIG

Contras

• Suportado apenas para GPUs recentes como A100, H100, A30. Isso acaba limitando as opções disponíveis.
• O número de partições tem um limite rígido de 7 para a maioria das arquiteturas. Isso é relativamente pouco se estivermos executando cargas de trabalho menores com requisitos limitados de memória e computação.

Fatiamento de tempo

O fatiamento de tempo permite que múltiplas cargas de trabalho sejam agendadas na mesma GPU. O tempo de computação é compartilhado entre os múltiplos processos e os processos são intercalados no tempo. Um administrador de cluster pode configurar um cluster ou nó para anunciar um certo número de réplicas/GPU, o que reconfigura os nós de acordo.

Prós

• Não há limite superior para o número de pods que podem compartilhar uma única GPU
• Pode funcionar com versões mais antigas de GPUs NVIDIA

Contras

• Sem isolamento de memória ou falhas. Não existe um mecanismo nativo para garantir que uma carga de trabalho não exceda a memória atribuída a ela.
• O fatiamento de tempo fornece tempo igual a todos os processos em execução. Um pod executando múltiplos processos pode monopolizar a CPU muito mais do que o pretendido.

Existem outras opções disponíveis para nós para compartilhamento de GPU, como MPS e vGPUs, mas elas não têm suporte nativo no `nvidia-device-plugin` e não as discutiremos aqui.

Demonstração de fatiamento de tempo

Vamos fazer um breve passo a passo sobre como podemos utilizar o compartilhamento de tempo no Azure Kubernetes Service. Começamos com um cluster Kubernetes já existente.

1. Adicionar um pool de nós habilitado para GPU no 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

‍‍Isso adicionará um novo pool de nós com um único nó ao cluster AKS existente com uma única GPU NVIDIA T4. Isso pode ser verificado executando o seguinte

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

2. Instalar o 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. Uma vez que o operador esteja instalado, criamos uma configuração de fatiamento de tempo e configuramos todo o cluster para fatiar os recursos da GPU onde disponíveis.‍‍

$ 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 se o nó existente foi reconfigurado com sucesso‍

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

5. Podemos verificar a configuração criando um deployment com 4 réplicas, com cada uma solicitando 2 recursos 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

Verifique se todos os pods deste deployment foram iniciados no mesmo nó já criado e se ele conseguiu acomodá-los.

Conclusão

A revolução da GenAI mudou o cenário dos requisitos de GPU e tornou a responsabilidade com a utilização de recursos mais crítica do que nunca. Existem deficiências em ambas as abordagens aqui descritas, mas não há como evitar ser responsável pelos custos de GPU no cenário atual.