Como dividir, compartilhar e orquestrar GPUs no OpenShift — time-slicing, MPS, MIG e DRA — e como vLLM e llm-d extraem o máximo de cada fatia.
Começamos pela anatomia da GPU, passamos por cada técnica de fatiamento e terminamos no serving distribuído de LLMs.
Anatomia da GPU, o que uma inferência LLM consome e onde a GPU fica ociosa.
Compartilhamento por tempo e por processo no NVIDIA GPU Operator — mecânica, configuração e limites.
Partição por hardware: perfis, isolamento real, estratégias single/mixed e o mig-manager.
O novo modelo de alocação do Kubernetes: ResourceSlice, DeviceClass, ResourceClaim e o driver NVIDIA.
PagedAttention, continuous batching e o Red Hat AI Inference Server sobre qualquer fatia.
Inferência distribuída: roteamento consciente de KV cache, prefill/decode desagregado e OpenShift AI.
Compute + memória + banda. Dezenas de SMs executam kernels em paralelo; a HBM guarda pesos e KV cache; a banda entre eles é o limite físico. Tudo isso é o que vamos fatiar.Duas fases com perfis opostos: o prefill satura os SMs (compute-bound); o decode gera um token por vez relendo os pesos inteiros da HBM (memory-bound). O KV cache cresce com contexto × requisições.Kubernetes só entende inteiros: um pod pede nvidia.com/gpu: 1 e leva a GPU inteira — mesmo usando 20% da memória e uma fração dos SMs. O resto fica ocioso e alguém fica na fila.
Cada técnica reparte um recurso diferente e oferece um nível diferente de isolamento. Não são concorrentes: são ferramentas para cargas diferentes — e o DRA muda a forma de pedi-las ao Kubernetes.
instâncias isoladas por GPU com MIG (A100 / H100 / H200 / B200) — e N fatias de tempo em qualquer GPU.
Qualquer GPU · sem isolamento · dev, notebooks, cargas esporádicas.
Kernels concorrentes · limite de memória por cliente · muitos processos pequenos.
Partição física · isolamento de memória, falhas e QoS · multi-tenant com SLA.
Seleção por atributos · MIG sob demanda · multi-nó (NVLink) · GA no K8s 1.34.
replicas: N faz o device plugin anunciar N recursos por GPU física. N pods pedem nvidia.com/gpu: 1 e são escalonados na mesma GPU.A GPU alterna entre os contextos em fatias de tempo: nunca rodam ao mesmo tempo. Sem isolamento de memória (a soma precisa caber na HBM) nem de falhas; a latência depende dos vizinhos.
nvidia.com/gpu: 2 na mesma GPU (failRequestsGreaterThanOne).Um daemon de controle funde os processos clientes num único contexto CUDA: kernels de pods diferentes executam ao mesmo tempo, em SMs diferentes — sem troca de contexto. O device plugin limita threads e memória por cliente.
GPUs Ampere+ (A100, H100, H200, B200) nascem com 7 fatias de compute (GPCs com seus SMs e L2) e 8 fatias de memória (HBM + controladores + banda). O MIG combina essas fatias em instâncias.Um perfil Ng.MMgb = N fatias de compute + MM GB de HBM. Perfis podem ser misturados na mesma GPU, respeitando as combinações que o hardware permite.Cada instância aparece ao Kubernetes como um recurso próprio (nvidia.com/mig-3g.40gb). Pods não disputam SMs, L2, HBM ou banda: isolamento de memória, de falhas e de desempenho garantido pelo silício.
1g.5gb2g.10gb3g.20gb4g.20gb7g.40gb1g.10gb1g.20gb2g.20gb3g.40gb7g.80gbspec.mig.strategy): single → todas as GPUs do nó com o mesmo perfil, expostas como nvidia.com/gpu (transparente para as cargas); mixed → perfis diferentes, expostos como nvidia.com/mig-3g.40gb, nvidia.com/mig-1g.10gb…
Três mecanismos, três níveis de isolamento. Tudo configurado pelo NVIDIA GPU Operator, por nó, via ConfigMap + label.
| Time-slicing | MPS | MIG | |
|---|---|---|---|
| O que reparte | Tempo (contextos alternam) | Espaço (kernels concorrentes num contexto) | Hardware (SMs, L2, HBM, banda) |
| Isolamento de memória | Nenhum — soma precisa caber | Limite por cliente (daemon) | Físico — endereçamento separado |
| Isolamento de falhas | Nenhum | Fraco — erro fatal afeta todos | Total por instância |
| Latência / QoS | Imprevisível (vizinhos) | Melhor, sem garantia de banda | Previsível — banda dedicada |
| Hardware | Qualquer GPU NVIDIA | Volta+ | A100 · A30 · H100 · H200 · B200 (Ampere+) |
| Granularidade | replicas: N livre | replicas: N → 1/N SMs e HBM | Perfis fixos Ng.MMgb, até 7 |
| Recurso no Kubernetes | nvidia.com/gpu (ou .shared) | nvidia.com/gpu (ou .shared) | nvidia.com/gpu (single) · nvidia.com/mig-* (mixed) |
| Melhor para | Dev, notebooks, cargas esporádicas, CI | Muitos processos pequenos do mesmo tenant | Multi-tenant, produção com SLA, inferência de modelos ≤ 40 GB |
O driver DRA da NVIDIA roda em cada nó e publica um ResourceSlice: cada GPU com seus atributos (modelo, memória, arquitetura, MIG) — não mais um contador opaco. Ele também instala as DeviceClasses.O desenvolvedor descreve o que precisa num ResourceClaimTemplate com seletor CEL; o Pod referencia a claim. O scheduler casa demanda × inventário e reserva o dispositivo na ResourceClaim.No nó, o kubelet chama o driver (NodePrepareResources): ele prepara o dispositivo — pode criar a instância MIG só naquele momento — e injeta no container via CDI. Multi-nó (GB200 NVLink): ComputeDomain + IMEX.
Inteiro opaco · sharing configurado por nó · sem escolher modelo/memória · sem relação entre dispositivos.
Atributos + CEL · sharing e MIG por workload · claims compartilháveis entre pods · topologia (NVLink, multi-nó).
GA no Kubernetes 1.34 · driver k8s-dra-driver-gpu da NVIDIA · OpenShift: feature gate DynamicResourceAllocation (TP) validar
Device plugin e DRA coexistem no GPU Operator; migração gradual por pool de nós. Time-slicing/MPS/MIG viram opções da claim.
O KV cache de cada sequência era reservado contíguo, para o comprimento máximo. O que não é usado fica preso (fragmentação interna) e sobram buracos entre sequências (externa): poucas requisições cabem por GPU.PagedAttention divide o KV cache em blocos fixos (16 tokens) mapeados por uma tabela — como paginação de memória virtual. Blocos são alocados só quando o token chega e podem ser compartilhados entre requisições (prefix caching).
No lote estático, N requisições entram juntas e o lote só termina quando a mais longa termina. Cada slot que acaba cedo fica ocioso e a fila espera o lote inteiro.O scheduler do vLLM decide a cada iteração (um token por sequência): sequências prontas saem, novas entram no mesmo instante. A GPU fica cheia — limitada só pelo KV cache disponível (PagedAttention).
O Red Hat AI Inference Server é o vLLM empacotado, endurecido e suportado pela Red Hat — em container no RHEL, no OpenShift AI (runtime KServe) ou em qualquer Kubernetes. Ele enxerga exatamente o que o Kubernetes entrega: uma GPU inteira, uma instância MIG ou uma fatia de tempo.
PagedAttention, continuous batching, prefix caching, speculative decoding, chunked prefill, multi-LoRA, API compatível com OpenAI.
Quantização FP8 / INT8 / INT4 (AWQ, GPTQ) e sparsity: modelo 8B cabe em 1g.10gb; 70B em uma H100.
Repositório Red Hat AI (Hugging Face) com modelos otimizados e testados por aceleradores (NVIDIA, AMD, TPU, Gaudi).
--tensor-parallel-size entre GPUs inteiras com NVLink; --pipeline-parallel-size entre nós.
--gpu-memory-utilization 0.9, --max-model-len conforme a HBM, sem TP.--gpu-memory-utilization (ex.: 0.3) para a soma caber; aceitar latência variável.--tensor-parallel-size N para modelos maiores que a HBM; --enable-prefix-caching para RAG/agentes.--max-num-seqs e --max-num-batched-tokens definem o teto do continuous batching por fatia.llm-d (Red Hat, Google, IBM, NVIDIA, CoreWeave…) é o vLLM em escala Kubernetes: um Inference Gateway (Envoy + Gateway API Inference Extension) na frente de um pool de réplicas vLLM. Um balanceador comum distribui por round-robin — e ignora o cache.O EPP (Endpoint Picker, scheduler do llm-d) sabe qual réplica já tem o prefixo no KV cache e qual está com fila curta. A requisição vai para onde o prefill pode ser pulado: menos latência (TTFT) e mais throughput para RAG, agentes e chats longos.Prefill/Decode desagregados: prefill (compute-bound) em um pool, decode (memory-bound) em outro; o KV cache viaja via NIXL (RDMA/NVLink). Cada pool escala e usa a fatia certa. Terceiro caminho: wide expert parallelism para MoE.
Distributed inference com llm-d é um modo de serving do OpenShift AI: o mesmo Red Hat AI Inference Server, orquestrado por um gateway inteligente sobre Gateway API — tudo suportado.
| Carga | Técnica | Por quê | Serving |
|---|---|---|---|
| Notebooks, dev, CI, experimentos | Time-slicing | Barato, qualquer GPU, sem exigência de SLA; oversubscription alta. | Workbench OpenShift AI |
| Muitos processos pequenos do mesmo time (visão, embeddings) | MPS | Concorrência real de kernels com limite de memória por cliente. | vLLM / Triton por processo |
| Inferência multi-tenant com SLA, modelos ≤ 40 GB | MIG | Isolamento físico de memória, falhas e banda; latência previsível. | vLLM em mig-3g.40gb / 1g.10gb |
| Modelos > 1 GPU (70B+, contextos longos) | GPU inteira + TP/PP | MIG não tem NVLink; tensor parallel precisa de GPUs inteiras. | vLLM --tensor-parallel-size |
| Alto volume, prefixos repetidos (RAG, agentes), SLO de TTFT | llm-d | Roteamento KV-aware + P/D desagregado sobre o pool de fatias. | OpenShift AI · distributed inference |
| Seleção por atributo, MIG sob demanda, multi-nó NVLink | DRA | Claims descrevem o que a carga precisa; o cluster decide onde e como. | Qualquer — via ResourceClaim |
nvidia.com/mig.config, device-plugin.config): reconfigurar MIG esvazia o nó.nvidia.com/mig-1g.10gb é um recurso como outro qualquer.Respostas salvas neste navegador (localStorage).
Fatiamento de GPU · Time-slicing, MPS, MIG, DRA, vLLM e llm-d
Red Hat OpenShift AI · NVIDIA GPU Operator · Red Hat AI Inference Server · llm-d