Intelligent Computing LINGJUN:Guia do usuário

3,1 Alocação de GPU inteira

Para solicitar uma GPU inteira, especifique apenas recursos de GPU inteira. Não é necessário definir poder computacional ou memória da GPU:

apiVersion: v1
kind: Pod
metadata:
  name: whole-card-demo
spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  containers:
  - name: app
    image: <your-image>
    resources:
      limits:
        nvidia.com/gpu: "1"     # Whole NVIDIA GPU (the community-compatible resource name). For whole GPUs from other vendors, use aliyun.com/gpu

3,2 Fatiamento de poder computacional por divisão de tempo (TDM)

Especifique duas dimensões independentes: gpu-core (percentual de poder computacional, de 1 a 100) e gpu-memory (memória da GPU, em GiB), combinando-as livremente:

apiVersion: v1
kind: Pod
metadata:
  name: tdm-demo
spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  containers:
  - name: app
    image: <your-image>
    resources:
      limits:
        aliyun.com/gpu-core: "50"      # 50% of the computing power of a single GPU
        aliyun.com/gpu-memory: "4"     # 4 GiB of GPU memory

Importante: Não especifique gpu-core ao usar uma GPU inteira. Deixar esse campo indefinido significa que o limite de poder computacional não está ativo. Definir explicitamente como 0 também não impõe limites, mas isso pode fazer com que o programa de GPU no contêiner apresente comportamento inesperado.

3,3 Particionamento espacial MIG

Antes de usar o particionamento espacial MIG, o administrador do cluster deve ativar o modo MIG na GPU executando o comando nvidia-smi mig no nó. Trata-se de uma alteração de configuração de hardware que exige reinicialização da GPU. Após a ativação do modo MIG, o sistema gerencia automaticamente a criação e a recuperação das instâncias. Quando um Pod inicia, uma instância MIG é criada conforme as especificações solicitadas. Ao destruir o Pod, a instância é recuperada automaticamente, sem necessidade de intervenção manual.

apiVersion: v1
kind: Pod
metadata:
  name: mig-demo
spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  containers:
  - name: app
    image: <your-image>
    resources:
      limits:
        aliyun.com/gpu-slice: "3"     # A MIG instance with three shares of computing power
        aliyun.com/gpu-memory: "4"    # 4 GiB of GPU memory

gpu-slice aceita os valores 1, 2, 3, 4 e 7. O MIG suporta atualmente apenas os modelos de placa A100 e H800. Para PPU, a capacidade equivalente é a tecnologia de particionamento espacial nativa do PPU. Em cenários com PPU, recomendamos priorizar o uso de multiplexação por divisão de tempo (TDM).

3,4 Solicitações multi-GPU homogêneas

As solicitações multi-GPU suportam atualmente apenas configurações homogêneas (cada GPU recebe a mesma alocação de poder computacional e memória). Defina a quantidade de GPUs usando o rótulo de Pod replica e especifique a configuração de recursos para cada GPU em resources.limits:

apiVersion: v1
kind: Pod
metadata:
  name: multi-gpu-demo
  labels:
    replica: "2"                       # Requests 2 GPUs
spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  containers:
  - name: app
    image: <your-image>
    resources:
      limits:
        aliyun.com/gpu-core: "50"
        aliyun.com/gpu-memory: "4"

3,5 Limitações

1. Não é possível ativar simultaneamente multiplexação por divisão de tempo (TDM) e particionamento espacial Multi-Instance GPU (MIG) na mesma GPU.

2. O TDM é compatível com todas as séries de GPUs NVIDIA e com PPU. Placas AMD suportam apenas GPUs inteiras, sem suporte a fatiamento.

3. A memória da GPU é especificada em GiB ou MiB. No modo MiB, a granularidade mínima é de 128 MiB.

4,1 Agendamento de topologia multi-GPU intra-nó

PPU 810E: Essa funcionalidade entra em vigor automaticamente quando você solicita aliyun.com/gpu e a quantidade de GPUs é 2, 4 ou 8. O agendador prioriza as GPUs mais interconectadas dentro do mesmo grupo de topologia. Para cenários RDMA, solicite também aliyun.com/rdma.

spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  containers:
  - name: train
    image: <your-training-image>
    resources:
      limits:
        aliyun.com/gpu: "4"          # Requests 4 whole PPU 810E GPUs; topology optimization is applied automatically

PPU M890P (afinidade conjunta GPU-RDMA): Em resources.limits, solicite aliyun.com/gpu (qualquer inteiro de 1 a 8) e aliyun.com/rdma: "1" simultaneamente para habilitar esse recurso. O agendador aloca as GPUs e as NICs RDMA no mesmo domínio PCIe como um grupo, aplicando fallback em quatro níveis na ordem switch PCIe → nó NUMA → soquete CPU → entre soquetes, do mais próximo ao mais distante. aliyun.com/rdma funciona como chave para ativar o caminho de afinidade de topologia e não representa a quantidade de NICs. O Device Plugin monta automaticamente os dispositivos RDMA correspondentes no contêiner. A comunicação RDMA requer hostNetwork: true.

spec:
  schedulerName: lj-runtimekit-scheduler
  runtimeClassName: lj-runtime
  hostNetwork: true
  containers:
  - name: training
    image: <your-training-image>
    resources:
      limits:
        aliyun.com/gpu: "4"
        aliyun.com/rdma: "1"

4,2 Agendamento de topologia gang entre nós

Para treinamento distribuído em vários nós, envie seu job por meio do JobSet para acionar essa funcionalidade. O agendador identifica automaticamente os Pods do mesmo JobSet como um único grupo de agendamento e aloca nós com base na afinidade de topologia de rede. Convenções principais:

1. Nos rótulos do modelo de Pod, defina aliyun.com/min-member: "N". O valor deve ser igual a parallelism (quantidade total de Pods no grupo).

2. Em uma configuração típica, parallelism = completions = aliyun.com/min-member.

3. Para comunicação RDMA, defina hostNetwork: true e adicione a capacidade IPC_LOCK. Caso contrário, o registro de memória RDMA falhará.

Comportamento do agendador: O agendador prefere posicionar os membros do grupo nos nós com menor distância de comunicação de rede (mesmo nó > mesmo HyperNode > mesmo switch leaf > mesmo network-pod). O agendamento segue a lógica "tudo ou nada": se nem todos os membros do grupo estiverem prontos em até 180 segundos, todo o grupo é revertido e tentado novamente. Se os recursos totais dentro do domínio network-pod forem insuficientes para acomodar todo o grupo, todos os membros permanecem em Pending.

Exemplo (treinamento distribuído gang entre nós com 7 workers, apenas partes principais):

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: gang-nccl-test
spec:
  replicatedJobs:
    - name: worker
      template:
        spec:
          completionMode: Indexed
          parallelism: 7
          completions: 7
          backoffLimit: 2
          template:
            metadata:
              labels:
                app: gang-nccl-test
                aliyun.com/min-member: "7"      # The number of gang group members, equal to parallelism
            spec:
              schedulerName: lj-runtimekit-scheduler
              runtimeClassName: lj-runtime
              hostNetwork: true
              containers:
              - name: trainer
                image: <your-training-image>
                resources:
                  limits:
                    aliyun.com/gpu: "1"
                    aliyun.com/rdma: "1"
                securityContext:
                  capabilities:
                    add: ["IPC_LOCK"]
              restartPolicy: Never

Q1: Um contêiner é criado com sucesso, mas o programa de GPU não gera saída por muito tempo

Possíveis causas: O poder computacional foi definido como 0 na solicitação Allocate. Solução: Não especifique o campo de poder computacional ao usar uma GPU inteira. Para limitar o poder computacional, especifique uma porcentagem inteira positiva.

Q2: Um Pod permanece em Pending

Verifique o seguinte: O Pod especifica schedulerName: lj-runtimekit-scheduler. O nó de destino tem o rótulo lj_runtimekit_enable=true e seus recursos foram reportados. Os valores solicitados de poder computacional, memória da GPU e slice são válidos (slice aceita apenas 1, 2, 3, 4 e 7, e o modelo da placa deve ser A100 ou H800). Para mais detalhes sobre solução de problemas no lado da implantação, consulte Deployment and release guide - FAQ.