Última revisão: junho de 2026
Uma referência rápida dos padrões arquiteturais que o exame NCA-AIIO avalia. Leia de cima a baixo ou pule para uma seção.
Decida se uma carga de trabalho deve ser executada em GPUs ou CPUs.
Matemática massivamente paralela (treinamento/inferência de deep-learning, operações de matriz, simulação) → GPU. Lógica de controle serial com muitas ramificações, tarefas de SO, E/S leve → CPU.
Por quê: GPUs têm milhares de núcleos otimizados para throughput em trabalho SIMT paralelo; CPUs vencem em lógica serial sensível à latência. A maioria dos sistemas de IA emparelha ambos.
Escolha o bloco de construção NVIDIA: um appliance completo versus uma placa para sistemas OEM.
Servidor de IA integrado pronto para uso (GPUs + CPUs + NVLink + rede + software) → DGX. Placa-base de GPU que OEMs/provedores de nuvem usam para construir servidores → HGX.
Por quê: DGX é o sistema de referência pronto para executar da NVIDIA; HGX é a placa multi-GPU que os hyperscalers integram por si mesmos.
GPUs em um servidor precisam de largura de banda GPU-para-GPU mais rápida do que a fornecida pelo barramento.
Use NVLink (e NVSwitch para all-to-all) para interconexão de GPU intra-nó de alta largura de banda; PCIe é o fallback quando NVLink não está disponível.
Por quê: NVLink oferece largura de banda GPU-para-GPU muito maior e menor latência do que PCIe — crítico para treinamento model-parallel e com grandes lotes dentro de um nó.
Todas as 8 GPUs em um nó devem se comunicar entre si com largura de banda NVLink total simultaneamente.
NVSwitch — uma malha de switch não-bloqueante que conecta cada GPU a todas as outras GPUs na velocidade total do NVLink.
Por quê: NVLink ponto-a-ponto sozinho não fornece largura de banda all-to-all; NVSwitch fornece o crossbar para comunicação GPU full-mesh.
Distinguir interconexão scale-up (dentro de um servidor) de scale-out (entre servidores).
Interconexão de GPU scale-up dentro de um nó → NVLink/NVSwitch. Scale-out entre nós em um cluster → InfiniBand (ou RoCE Ethernet).
Por quê: NVLink é intra-nó; InfiniBand conecta nós em um cluster para treinamento distribuído multi-nó.
Escolha a malha de cluster para treinamento distribuído em larga escala onde a latência de operação coletiva é mais importante.
Menor latência, computação na rede (SHARP), RDMA-native → InfiniBand. Familiar, menor custo, ecossistema amplo → RoCE em Spectrum-X Ethernet.
Por quê: InfiniBand com SHARP descarrega all-reduce para o switch, reduzindo a latência coletiva; Spectrum-X é a resposta Ethernet da NVIDIA para malhas de IA.
Descarregue o processamento de rede, armazenamento e segurança da CPU para que os núcleos sejam liberados para a computação de IA.
NVIDIA BlueField DPU — unidade de processamento de dados programável que descarrega e isola serviços de infraestrutura da CPU/GPU hospedeira.
Por quê: DPUs aceleram a rede leste-oeste, armazenamento NVMe-oF e segurança zero-trust, aumentando a utilização efetiva da GPU/CPU e o isolamento de locatários.
Precisa de uma NIC RDMA de alta velocidade para nós GPU sem descarregamento DPU completo.
NVIDIA ConnectX SmartNIC — adaptador InfiniBand/Ethernet de alta vazão com suporte a RDMA e GPUDirect.
Por quê: ConnectX oferece RDMA line-rate; BlueField adiciona um subsistema Arm programável para descarregamento completo da infraestrutura.
Reduza a latência movendo dados para a memória da GPU sem passar pela CPU/memória do host.
GPUDirect RDMA — NICs leem/escrevem diretamente na memória da GPU; GPUDirect Storage faz o mesmo para armazenamento NVMe.
Por quê: Ignorar o buffer de salto da CPU remove cópias e latência no caminho dos dados, vital para o throughput de treinamento multi-nó.
Escolha uma arquitetura de GPU de data center de geração atual para treinamento de modelos grandes.
Hopper (H100/H200) é a geração estabelecida com Transformer Engine + FP8; Blackwell (B200/GB200) é a geração mais recente com maior throughput e FP4 para os maiores modelos.
Por quê: Ambos visam cargas de trabalho transformer; Blackwell leva a escala e a inferência de menor precisão (FP4) mais longe. Correlacione com o orçamento e o tamanho do modelo.
Identifique o hardware que acelera a matemática de matrizes de deep-learning.
Tensor Cores — unidades especializadas que realizam operações de multiplicação-acumulação de matrizes fundidas em precisão mista (FP16/BF16/FP8/FP4).
Por quê: Eles entregam throughput ordens de magnitude maior em GEMM/convolução do que os núcleos CUDA padrão, o que impulsiona o desempenho de DL.
Um modelo grande não cabe; a largura de banda da memória, não a computação, é o gargalo.
Escolha GPUs com mais e mais rápida HBM (ex: H200/B200 com HBM3e); use paralelismo de modelo multi-GPU quando a memória de uma GPU for insuficiente.
Por quê: O treinamento/inferência de modelos grandes é frequentemente limitado pela capacidade e largura de banda da memória; HBM fornece a alta largura de banda que as GPUs precisam.
Monte um supercomputador de IA multi-rack pronto para uso e validado para treinamento empresarial.
NVIDIA DGX SuperPOD — arquitetura de referência de nós DGX, malha InfiniBand, armazenamento e software Base Command.
Por quê: SuperPOD é o design full-stack pré-validado; ele remove a suposição da fiação da malha, armazenamento e orquestração em escala.
Obtenha capacidade de treinamento de classe DGX sem possuir o hardware.
NVIDIA DGX Cloud — infraestrutura de treinamento de IA gerenciada hospedada em grandes provedores de nuvem, acessada como um serviço.
Por quê: OpEx vs. CapEx: DGX Cloud é adequado para treinamento intermitente ou de curto prazo; DGX/SuperPOD on-prem é adequado para alta utilização sustentada e restrições de data-gravity.
Escolha entre cluster GPU on-prem vs. GPUs em nuvem para cargas de trabalho de IA.
Alta utilização sustentada, soberania de dados, gasto previsível → DGX/SuperPOD on-prem. Demanda variável/intermitente, início rápido, sem pegada de data center → nuvem ou DGX Cloud.
Por quê: GPUs próprias se amortizam bem apenas com alta utilização constante; hardware próprio ocioso é custo puro.
Um novo cluster de GPU excede o orçamento de energia e resfriamento do rack de um data center existente.
Planeje energia de alta densidade (dezenas de kW/rack) e resfriamento líquido para as GPUs mais recentes; dimensione PDUs, barramentos e capacidade térmica antes da instalação.
Por quê: Nós de GPU modernos (e racks GB200) consomem muito mais energia e geram mais calor do que servidores legados; o resfriamento a ar e PDUs padrão muitas vezes não conseguem acompanhar.
O treinamento para porque o pipeline de dados não consegue alimentar as GPUs rápido o suficiente.
Use armazenamento paralelo/NVMe de alta vazão com GPUDirect Storage; dimensione para largura de banda de leitura sustentada para manter as GPUs saturadas.
Por quê: E/S de armazenamento subprovisionada deixa GPUs caras ociosas esperando por dados; a camada de armazenamento deve corresponder à demanda agregada de leitura da GPU.
Um modelo é muito grande para ser treinado em um único nó em um tempo aceitável.
Expanda para múltiplos nós via InfiniBand usando paralelismo de dados/tensor/pipeline; NCCL lida com a comunicação coletiva da GPU.
Por quê: O dimensionamento multi-nó precisa de uma malha de baixa latência e de uma biblioteca de coletivos otimizada (NCCL); uma malha lenta mata a eficiência do dimensionamento.
Uma única A100/H100 é um exagero para pequenos trabalhos de inferência; você quer fatias isoladas por hardware.
Multi-Instance GPU (MIG) — particione uma GPU em até 7 instâncias isoladas, cada uma com computação e memória dedicadas.
Por quê: MIG oferece verdadeiro isolamento de hardware e QoS previsível para inferência multi-inquilino, ao contrário do fatiamento de tempo suave.
Diferencie IA vs. machine learning vs. deep learning.
IA é o objetivo amplo; ML é um subconjunto que aprende com dados; DL é um subconjunto de ML que usa redes neurais de múltiplas camadas.
Por quê: Eles se aninham: DL ⊂ ML ⊂ IA. DL impulsiona a demanda moderna por GPU porque as redes neurais são massivamente paralelas.
Diferencie o perfil de computação de treinamento vs. inferência.
Treinamento = intensivo em computação e memória, de longa duração, em lote, muitas GPUs. Inferência = sensível à latência, mais leve, frequentemente GPU única/parcial, executa continuamente em produção.
Por quê: Eles têm diferentes necessidades de hardware e escalabilidade; dimensionar um cluster requer separar as duas cargas de trabalho.
Escolha um paradigma de aprendizado: dados rotulados, dados não rotulados ou tentativa e erro guiada por recompensa.
Rotulados → supervisionado. Agrupamento/estrutura não rotulados → não supervisionado. agent aprende com recompensa → aprendizado por reforço.
Por quê: Os dados que você tem (e o objetivo) ditam o paradigma; RLHF é o aprendizado por reforço guiado pelo feedback humano para alinhar LLMs.
Explique por que as redes neurais se adaptam bem às GPUs.
São camadas de multiplicações de matrizes ponderadas e ativações não lineares — álgebra linear paralela densa que as GPUs executam com eficiência.
Por quê: As passagens forward/backward são intensivas em GEMM; Tensor Cores aceleram exatamente isso, razão pela qual DL roda em GPUs.
Identifique a arquitetura por trás dos LLMs modernos e da IA generativa.
O transformer — arquitetura baseada em atenção que escala com dados e parâmetros; foundation models e LLMs são construídos sobre ela.
Por quê: Transformers são altamente paralelizáveis, razão pela qual impulsionam a demanda por grandes clusters de GPU e hardware Transformer Engine.
Acelere o treinamento e reduza o uso de memória sem prejudicar materialmente a precisão.
Use precisão mista — FP16/BF16 (e FP8 em Hopper/Blackwell) para matemática, FP32 para acumulação; Tensor Cores aceleram as operações de menor precisão.
Por quê: Precisão mais baixa reduz a memória pela metade e multiplica o throughput; loss scaling / BF16 preserva a estabilidade numérica.
Nomeie a base que permite que o software seja executado em GPUs NVIDIA.
CUDA — plataforma de computação paralela e modelo de programação da NVIDIA; CUDA-X é a camada de biblioteca (cuDNN, cuBLAS, NCCL, RAPIDS, etc.).
Por quê: Frameworks como PyTorch/TensorFlow chamam bibliotecas CUDA-X internamente; CUDA é o fosso que liga o software de IA às GPUs NVIDIA.
Acelere primitivas de deep-learning (convoluções, atenção) dentro de um framework.
cuDNN fornece primitivas DL otimizadas para GPU; cuBLAS lida com álgebra linear densa; ambos ficam sob PyTorch/TensorFlow.
Por quê: Essas bibliotecas são a razão pela qual os frameworks obtêm velocidade de GPU sem que você escreva kernels CUDA.
Obtenha containers, modelos e Helm charts otimizados para NVIDIA e prontos para GPU.
Catálogo NGC (NVIDIA GPU Cloud) — registro curado de containers otimizados (frameworks, NIM, Triton), modelos pré-treinados e SDKs.
Por quê: Os containers NGC vêm ajustados e testados para GPUs NVIDIA, eliminando a adivinhação de dependência e compatibilidade de drivers.
Sirva muitos modelos de múltiplos frameworks por trás de um endpoint padronizado e eficiente em GPU.
NVIDIA Triton Inference Server — serviço de modelos multi-framework com dynamic batching, execução de modelo concorrente e compartilhamento de GPU.
Por quê: Triton maximiza a utilização da GPU para inferência via batching e concorrência de modelo em vez de um processo por modelo.
Implante rapidamente um foundation model como um microserviço de inferência otimizado e pronto para produção.
NVIDIA NIM — microserviços de inferência pré-construídos e containerizados com motores otimizados e APIs padrão para modelos populares.
Por quê: NIM empacota modelo + runtime otimizado (TensorRT-LLM/Triton) + API em uma única unidade implantável, reduzindo o tempo de produção.
Reduza a latência de inferência e aumente o throughput para um modelo treinado.
Compile o modelo com TensorRT (ou TensorRT-LLM para LLMs) — fusão de camadas, calibração de precisão (INT8/FP8) e auto-ajuste de kernel.
Por quê: TensorRT produz um motor de inferência otimizado para a GPU alvo, muitas vezes multiplicando o throughput em comparação com o framework original.
Acelere a preparação de dados no estilo pandas/scikit-learn e o ML clássico em GPUs.
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (gráficos) executam o fluxo de trabalho de ciência de dados em GPUs.
Por quê: RAPIDS mantém ETL tabular e ML clássico na GPU, evitando gargalos da CPU no pipeline.
Gerencie cargas de trabalho de IA, jobs e usuários em um cluster DGX/SuperPOD.
NVIDIA Base Command — agendamento de jobs, gerenciamento de cluster e orquestração de cargas de trabalho para infraestrutura DGX.
Por quê: Base Command é o plano de controle de operações para sistemas DGX; ele lida com o envio de jobs multi-usuário e o rastreamento de recursos.
Precisa de software de IA suportado, seguro e de nível de produção com SLAs empresariais.
NVIDIA AI Enterprise — o conjunto de software suportado (frameworks, NIM, Triton, RAPIDS, GPU Operator) com patches de segurança e suporte empresarial.
Por quê: Ele agrupa a pilha validada com suporte e garantias de ciclo de vida, o que ambientes regulamentados/de produção exigem.
Defina um foundation model e como as equipes o adaptam.
Grande modelo pré-treinado em dados amplos, adaptável a muitas tarefas via prompting, RAG, ou fine-tuning em vez de treinamento do zero.
Por quê: A adaptação (prompt/RAG/fine-tune) é muito mais barata do que o pré-treinamento; a maioria das empresas consome foundation models, não os constrói.
Adicione conhecimento privado/atual a um aplicativo baseado em LLM.
Fatos que mudam frequentemente → RAG (recuperar de um vector store na inferência). Ensinar novo comportamento/estilo/habilidade de domínio → fine-tuning.
Por quê: RAG mantém os dados externos e atualizáveis sem retreinamento; fine-tuning incorpora o comportamento nos pesos e é mais caro para atualizar.
Avalie se GPUs caras estão sendo usadas de forma eficiente.
Acompanhe a utilização da GPU, uso de memória e atividade de SM/Tensor-Core; baixa utilização indica gargalos no pipeline de dados, tamanho do lote ou agendamento.
Por quê: Uma GPU "ocupada" por muito tempo pode ainda mascarar baixa computação efetiva; observe a ocupação do Tensor-Core/SM, não apenas o indicador de utilização.
Monitore a saúde, utilização, temperatura, energia e erros da GPU em um cluster.
NVIDIA DCGM (Data Center GPU Manager) — telemetria, verificações de saúde e diagnósticos; exporta métricas para Prometheus/Grafana.
Por quê: DCGM é a fonte padrão de telemetria de GPU; o DCGM Exporter alimenta Prometheus para dashboards e alertas em todo o cluster.
Provisione drivers de GPU, o kit de ferramentas de container e monitoramento em um cluster Kubernetes sem configuração manual por nó.
NVIDIA GPU Operator — automatiza a configuração de driver, container runtime, device plugin, DCGM e MIG no Kubernetes.
Por quê: Ele gerencia o ciclo de vida completo do software da GPU de forma declarativa, eliminando instalações frágeis de drivers nó a nó.
Escolha um orquestrador para cargas de trabalho de GPU.
Microsserviços/inferência, cloud-native, cargas de trabalho mistas → Kubernetes. Jobs de treinamento em lote estilo HPC, gang scheduling, clusters tradicionais → Slurm.
Por quê: Kubernetes se destaca em serviços de longa duração e elasticidade; Slurm se destaca em jobs em lote enfileirados com agendamento estilo MPI.
Pods do Kubernetes precisam solicitar e ser agendados em GPUs.
O plugin de dispositivo NVIDIA anuncia GPUs como recursos agendáveis; pods solicitam `nvidia.com/gpu` e o scheduler os aloca.
Por quê: Sem o plugin de dispositivo, o Kubernetes não pode ver ou alocar GPUs; é o que torna as GPUs um recurso de primeira classe.
Muitos pequenos jobs/usuários devem compartilhar GPUs para aumentar a utilização.
Isolamento de hardware → MIG. Compartilhamento suave de uma GPU → time-slicing ou MPS. Combine com cotas de namespace para justiça.
Por quê: MIG oferece garantias de QoS; time-slicing/MPS superutilizam uma GPU sem isolamento. Escolha de acordo com o requisito de isolamento.
O treinamento de alta prioridade deve preempter experimentos de baixa prioridade em um cluster compartilhado.
Use prioridade/preempção e filas no scheduler (partições Slurm ou PriorityClasses do Kubernetes com cota); agende jobs multi-GPU em grupo (gang-schedule).
Por quê: O agendamento em grupo (gang scheduling) evita deadlocks de alocação parcial; as classes de prioridade impõem a ordem de negócios em GPUs disputadas.
Mantenha as versões dos drivers de GPU, CUDA e kit de ferramentas de containers consistentes e compatíveis entre os nós.
Padronize via GPU Operator (Kubernetes) ou containers NGC; combine o driver com as versões CUDA que seus frameworks precisam e implemente atualizações em janelas de manutenção.
Por quê: Incompatibilidades de Driver/CUDA/framework são uma das principais causas de falhas de cluster; CUDA fixado em container desacopla o aplicativo do driver do host dentro dos intervalos suportados.
Dimensionar um cluster de GPU para a demanda prevista de treinamento e inferência.
Separe o treinamento (pico, lote) da inferência (sustentado, limitado por latência); planeje margem de energia/resfriamento/malha e vise alta utilização constante.
Por quê: O superdimensionamento desperdiça CapEx em GPUs ociosas; o subdimensionamento restringe a entrega. Planeje para a mistura de cargas de trabalho, não para um único pico.
GPUs estrangulam ou falham sob carga pesada sustentada.
Monitore temperatura e energia via DCGM; assegure resfriamento adequado (líquido para racks densos), defina limites de energia razoáveis e alerte sobre limites térmicos.
Por quê: O estrangulamento térmico corta silenciosamente o throughput; telemetria proativa e design de resfriamento protegem tanto o desempenho quanto a vida útil do hardware.
Entregue aceleração de GPU para múltiplas VMs ou usuários VDI a partir de hardware compartilhado.
O software NVIDIA vGPU particiona uma GPU física entre VMs com agendamento e isolamento; MIG pode apoiar perfis vGPU para particionamento rígido.
Por quê: vGPU permite acesso virtualizado/multi-inquilino à GPU (VDI, nuvem) que o passthrough bare-metal não pode compartilhar.
Um nó retorna erros Xid ou jobs falhos; você deve isolar GPUs ruins antes que corrompam mais execuções.
Execute diagnósticos DCGM e verificações de saúde ativas; isole/esvazie o nó, substitua ou reinicie a GPU, e só então a retorne ao pool.
Por quê: Erros Xid e falhas ECC sinalizam GPUs defeituosas; o controle de saúde automatizado impede que uma GPU com problemas contamine o pool de agendamento.