Última revisão: junho de 2026
Uma referência rápida dos padrões arquiteturais que o exame NCP-GENL avalia. Leia de cima a baixo ou pule para uma seção.
Precisa de menor latência em H100/Blackwell sem o impacto na precisão da quantização INT agressiva.
Use a quantização FP8 (E4M3) via TensorRT-LLM; Hopper e Blackwell possuem Tensor Cores FP8 nativos.
Por quê: FP8 preserva melhor o alcance dinâmico do que INT8 e funciona na velocidade máxima do hardware em Hopper+, oferecendo qualidade próxima de FP16 com throughput de classe INT8.
O modelo mal cabe na memória da GPU e o throughput é limitado pela largura de banda da memória.
Aplique a quantização INT4 somente de pesos (AWQ ou GPTQ); mantenha as ativações em FP16/FP8.
Por quê: INT4 somente de pesos reduz a memória pela metade em relação a INT8 e alivia a pressão da largura de banda; a precisão da ativação permanece alta, então a perda de precisão é pequena.
Decidindo entre quantização pós-treinamento e treinamento com reconhecimento de quantização.
Comece com PTQ (calibre em uma amostra representativa); volte para QAT apenas se a perda de precisão do PTQ exceder o orçamento.
Por quê: PTQ é rápido e não precisa de retreinamento; QAT recupera a precisão, mas custa uma execução de treinamento, então reserve-o para modelos críticos em precisão.
Serviço de contexto longo onde o cache KV domina a memória e limita o tamanho do batch.
Ative a quantização de cache KV FP8 ou INT8 no TensorRT-LLM.
Por quê: O cache KV cresce com o comprimento da sequência × batch; quantizá-lo libera memória para batches maiores e contextos mais longos com impacto mínimo na qualidade.
Comprimentos de requisição mistos causam tempo ocioso da GPU com batching estático.
Use o batching "in-flight" (contínuo) no TensorRT-LLM para que as sequências finalizadas sejam desalojadas e novas sequências se juntem durante o processamento.
Por quê: O batching contínuo mantém a GPU saturada e aumenta o throughput muito além do batching estático para fluxos de requisições heterogêneos.
Um modelo "professor" grande atende à qualidade, mas não atinge o objetivo de latência e custo.
Destile para um modelo "aluno" menor, e então quantize o aluno para inferência.
Por quê: A destilação transfere capacidade para uma arquitetura mais barata; combinada com a quantização, ela potencializa a economia de custo/latência.
A latência de fluxo único é muito alta para um caso de uso interativo.
Aplique a decodificação especulativa com um pequeno modelo de rascunho verificado pelo modelo alvo.
Por quê: O rascunho propõe múltiplos tokens que o modelo grande verifica em uma única passagem, reduzindo a latência real sem alterar a distribuição de saída.
Quantizar tudo para INT4 prejudica a precisão em algumas camadas sensíveis.
Use precisão mista: mantenha as camadas sensíveis (por exemplo, projeção final, atenção) com maior precisão e quantize o restante.
Por quê: A sensibilidade por camada varia; a precisão seletiva protege a exatidão onde importa, enquanto ainda reduz a maior parte dos pesos.
A precisão do PTQ é ruim apesar de um esquema de quantização razoável.
Recalibre com uma amostra em distribuição (centenas de prompts representativos) que corresponda ao tráfego de produção.
Por quê: A calibração define os intervalos de ativação; uma amostra não representativa produz escalas ruins e perda de precisão evitável.
Os pesos do modelo excedem uma única GPU, mas cabem em um único nó conectado por NVLink.
Use paralelismo de tensor entre as GPUs no nó.
Por quê: O paralelismo de tensor fragmenta cada camada e troca ativações a cada etapa, então ele precisa da alta largura de banda intra-nó de NVLink/NVSwitch.
O modelo é muito grande para um nó e deve abranger vários nós via InfiniBand.
Adicione paralelismo de pipeline entre nós, mantendo o paralelismo de tensor dentro de cada nó.
Por quê: O paralelismo de pipeline comunica apenas nos limites do estágio, tolerando links inter-nós mais lentos; reserve o paralelismo de tensor, que consome muita largura de banda, para NVLink.
A escalabilidade para mais GPUs resulta em ganhos de throughput decrescentes.
Profile com Nsight Systems para classificar o gargalo; se os coletivos dominam, reduza o grau de paralelismo ou melhore a topologia.
Por quê: Além de um certo ponto, a sobrecarga de "all-reduce"/"all-gather" supera o compute adicionado; diagnosticar se é limitado por comunicação ou por compute orienta a correção.
A sobrecarga de lançamento de kernel por etapa infla a latência de decodificação em tamanhos de batch pequenos.
Habilite CUDA Graphs para capturar e reproduzir o loop de decodificação.
Por quê: CUDA Graphs colapsa muitos pequenos lançamentos em uma única reprodução, removendo a sobrecarga de lançamento do lado da CPU que domina em tamanhos de batch baixos.
Ranks de paralelismo de tensor colocados em um link lento causam atrasos.
Fixe ranks de paralelismo de tensor a GPUs que compartilham NVLink/NVSwitch; coloque estágios de pipeline entre nós.
Por quê: O posicionamento incompatível roteia coletivos de alta frequência via PCIe ou InfiniBand, estrangulando todo o pipeline.
A atenção é limitada pela memória e limita o comprimento de contexto alcançável.
Use FlashAttention (kernels de atenção fundidos e cientes de I/O) fornecidos pela stack TensorRT-LLM/NeMo.
Por quê: FlashAttention evita materializar a matriz de atenção completa, reduzindo o tráfego de memória e permitindo sequências mais longas em maior velocidade.
Vários modelos pequenos subutilizam GPUs H100 completas.
Particione as GPUs com MIG (Multi-Instance GPU) para isolar cada modelo em uma fatia.
Por quê: MIG oferece partições isoladas por hardware, aumentando a utilização e fornecendo QoS previsível para cargas de trabalho pequenas co-localizadas.
O serviço downstream requer JSON estritamente válido sempre.
Use decodificação guiada/restrita (gramática ou esquema JSON) no runtime de serviço, em vez de depender apenas da redação do prompt.
Por quê: A decodificação restrita mascara tokens inválidos no momento da geração, garantindo saída válida em termos de esquema, onde o prompting apenas reduz a taxa de falha.
A tarefa exige um formato consistente que o modelo base lida de forma inconsistente.
Experimente exemplos "few-shot" primeiro; passe para o ajuste fino somente se a direção baseada em prompt estagnar ou o custo do token for excessivo.
Por quê: Few-shot não requer treinamento e é editável instantaneamente; o ajuste fino vence apenas quando os padrões são estáveis e a sobrecarga do prompt é prejudicial.
Tarefa de raciocínio multi-etapa fornece respostas finais erradas.
Obtenha a cadeia de pensamento ('pense passo a passo') ou use um modelo de raciocínio estruturado antes da resposta final.
Por quê: Expor etapas intermediárias melhora a precisão multi-hop e torna os erros auditáveis, ao custo de tokens extras.
Uma pequena alteração no prompt regrediu silenciosamente a qualidade da produção.
Versione os prompts do sistema como código, condicione as mudanças à avaliação e implemente-as via o mesmo CI que os artefatos do modelo.
Por quê: Prompts são parte do contrato do modelo; edições não versionadas causam regressões não rastreadas e comportamento não reproduzível.
O modelo alucina fatos fora de seus dados de treinamento.
Recupere o contexto relevante e injete-o no prompt com uma instrução para responder apenas com base no contexto fornecido.
Por quê: A fundamentação em passagens recuperadas restringe o modelo ao material de origem e reduz a alucinação em consultas intensivas em conhecimento.
Latência e custo são altos porque os prompts são muito grandes.
Apare e comprima o prompt: deduplique instruções, resuma o contexto recuperado e limite os exemplos ao mínimo que mantém a qualidade.
Por quê: O pré-preenchimento escala com os tokens de entrada; prompts enxutos reduzem tanto a latência quanto o custo por requisição sem perda de qualidade mensurável.
O texto fornecido pelo usuário pode sobrescrever a instrução do sistema.
Separe instruções confiáveis de entradas não confiáveis com delimitadores claros e trate o conteúdo recuperado/do usuário como dados, não como comandos.
Por quê: Concatenar texto não confiável no canal de instrução convida à injeção de prompt; limites explícitos reduzem a superfície de ataque.
Adaptar um modelo base grande a um domínio com um orçamento de GPU limitado.
Use LoRA: treine adaptadores de baixo rank e congele os pesos base.
Por quê: LoRA treina uma pequena fração dos parâmetros, reduzindo drasticamente a memória e o compute, enquanto se iguala ao ajuste fino completo na maioria das tarefas específicas.
Mesmo o treinamento LoRA de um modelo de 70B não cabe na memória disponível.
Use QLoRA: quantize a base congelada para 4 bits (NF4) e treine adaptadores LoRA por cima.
Por quê: Manter a base em 4 bits enquanto atualiza apenas os adaptadores permite que modelos grandes sejam ajustados em uma única GPU com perda mínima de precisão.
Escolhendo o rank LoRA para uma nova tarefa de ajuste fino.
Comece com um rank modesto (por exemplo, 8-16); aumente-o apenas se a tarefa for complexa e a perda de validação ainda estiver melhorando.
Por quê: Um rank mais alto adiciona capacidade e custo; um rank excessivo corre o risco de overfitting em pequenos conjuntos de dados, enquanto um rank insuficiente limita a qualidade alcançável.
O modelo segue as instruções, mas suas saídas não correspondem à preferência humana.
Faça o ajuste fino supervisionado primeiro, depois o alinhamento de preferência com RLHF ou DPO.
Por quê: SFT ensina o formato e a tarefa; a otimização de preferência molda quais respostas válidas os humanos realmente preferem.
RLHF com PPO é instável e operacionalmente pesado.
Use DPO (Direct Preference Optimization) em um conjunto de dados de preferência em vez de um modelo de recompensa + loop PPO.
Por quê: DPO otimiza as preferências diretamente sem um modelo de recompensa separado ou execução de RL, simplificando o pipeline e melhorando a estabilidade.
O adaptador LoRA adiciona sobrecarga por requisição no momento do serviço.
Mescle os pesos do adaptador na base para implantação quando apenas um adaptador for servido.
Por quê: Um modelo mesclado não possui ramificação de adaptador na inferência; mantenha os adaptadores separados apenas quando trocar várias tarefas em uma única base.
O ajuste fino em uma tarefa específica degrada as capacidades gerais.
Misture uma parte de dados gerais/de instrução, diminua a taxa de aprendizado e prefira PEFT em vez de ajuste fino completo.
Por quê: A repetição de dados gerais e a limitação do movimento de pesos preservam habilidades amplas enquanto ainda aprendem a nova tarefa.
Os dados de pré-treinamento/ajuste fino contêm muitos quase-duplicados.
Execute a deduplicação difusa (por exemplo, MinHash/LSH) antes do treinamento.
Por quê: Duplicatas desperdiçam compute, polarizam o modelo para conteúdo repetido e podem causar memorização; a deduplicação melhora a generalização por token.
Pontuações de benchmark suspeitosamente altas após o treinamento.
Descontamine o conjunto de treinamento em relação aos dados de benchmark/avaliação via filtragem de sobreposição de n-gramas.
Por quê: O vazamento de itens de teste infla as métricas e oculta a qualidade real; a descontaminação mantém a avaliação honesta.
O corpus pode conter dados pessoais sujeitos a regras de governança.
Adicione um estágio de detecção e redação de PII ao pipeline de dados antes do treinamento.
Por quê: O treinamento em PII bruta arrisca regurgitação e violações de conformidade; a limpeza antecipada é muito mais barata do que corrigir um modelo com vazamentos.
Dados brutos da web são ruidosos e diminuem a qualidade do modelo.
Aplique filtros de qualidade (heurísticas mais um classificador) para descartar documentos de baixa qualidade, boilerplate e spam.
Por quê: A qualidade dos dados supera a quantidade bruta acima de um certo limite; a filtragem produz modelos melhores com o mesmo orçamento de treinamento.
Os dados de ajuste fino devem alimentar o pipeline de treinamento NeMo de forma limpa.
Converta para o formato NeMo esperado (por exemplo, JSONL com campos prompt/response) e tokenize com o tokenizer do modelo.
Por quê: Incompatibilidades de formato e tokenizer causam truncamento silencioso ou erros de rótulo; conformar-se ao esquema do NeMo mantém o treinamento reproduzível.
Configurar um endpoint LLM de produção rapidamente com uma API compatível com OpenAI.
Implante com um microsserviço NVIDIA NIM; construa um conjunto Triton personalizado apenas para necessidades não padrão de pré/pós-processamento.
Por quê: NIM entrega motores otimizados e uma API padrão prontos para uso; um Triton personalizado vale o esforço apenas quando você precisa de controle de pipeline sob medida.
Requisições independentes chegam mais rápido do que o serviço de requisição única pode lidar.
Habilite o batching dinâmico do Triton para agrupar requisições concorrentes em batches de GPU.
Por quê: O batching amortece a sobrecarga do kernel entre as requisições, aumentando o throughput com um pequeno e limitado custo de latência.
Uma única instância de modelo deixa o compute da GPU subutilizado.
Configure múltiplas instâncias de modelo por GPU no Triton para sobrepor a execução.
Por quê: Instâncias concorrentes preenchem lacunas de compute deixadas por paralisações de memória, melhorando a utilização quando a memória permite.
O tráfego é irregular e réplicas fixas desperdiçam GPUs ou falham nos SLOs.
Dimensionar automaticamente as réplicas com base na profundidade da fila / utilização da GPU com um pool "quente" para absorver inicializações a frio.
Por quê: As inicializações a frio (carregamento do motor) de LLM são lentas; escalar com um sinal antecedente e capacidade "quente" protege a latência durante picos.
Clientes existentes esperam a API de chat-completions do OpenAI.
Exponha o modelo através do endpoint compatível com OpenAI do NIM para que os clientes se integrem sem reescritas.
Por quê: Uma API compatível "drop-in" minimiza o trabalho de migração do cliente e permite trocar backends de forma transparente.
Uma alteração no modelo ou no prompt não deve regredir silenciosamente a qualidade.
Execute um conjunto de avaliação "golden" curado em CI e bloqueie implantações que caem abaixo de um limite de qualidade.
Por quê: Portões de regressão automatizados capturam quedas de qualidade antes que cheguem aos usuários, da mesma forma que testes de unidade controlam o código.
Saídas abertas não possuem uma única resposta de referência para pontuar.
Use um LLM como juiz com uma rubrica, calibrado contra avaliações humanas em uma amostra.
Por quê: Um juiz orientado por rubrica escala a avaliação subjetiva; a calibração humana protege contra o próprio viés do juiz.
Pontuação MMLU alta, mas os usuários reclamam da tarefa de produção.
Avalie com métricas específicas da tarefa ligadas aos resultados de negócio, não apenas benchmarks genéricos.
Por quê: Benchmarks genéricos correlacionam-se fracamente com tarefas específicas implantadas; a métrica correta reflete o que os usuários realmente precisam.
As avaliações offline parecem boas, mas o impacto no mundo real é incerto.
Execute um teste A/B online direcionando uma fração do tráfego para a nova versão e compare as métricas de resultado.
Por quê: O A/B ao vivo captura mudanças na distribuição e comportamento do usuário que os conjuntos offline perdem, confirmando melhorias reais.
Precisa de visibilidade da saúde e utilização da GPU em uma frota de serviço.
Exporte métricas DCGM (utilização, memória, ECC, temperatura) para Prometheus e configure alertas para elas.
Por quê: DCGM é a fonte de telemetria padrão da NVIDIA; sem ela, saturações e falhas no nível da GPU passam despercebidas.
Usuários veem respostas lentas intermitentemente, mas a latência média parece boa.
Monitore a latência p95/p99 do tempo para o primeiro token e entre tokens, e alerte sobre violações de SLO de percentil.
Por quê: Médias escondem latência de cauda; a UX de LLM é governada por p95/p99, então SLIs de percentil são o sinal de alerta correto.
Implantando uma nova versão do modelo em um endpoint de alto tráfego.
Implemente via canary (pequena fatia de tráfego) com rollback automatizado em caso de regressão de SLO ou qualidade.
Por quê: O canarying limita o raio de explosão e permite que as métricas confirmem a segurança antes da implantação completa, ao contrário de uma implantação em massa.
O throughput colapsa sob carga sem um pico óbvio de compute da GPU.
Monitore a utilização do cache KV e dos slots de batch; escale ou encurte o contexto máximo quando o cache saturar.
Por quê: A exaustão do cache KV limita a concorrência antes que o compute o faça; monitorá-lo explica quedas abruptas de throughput que a utilização da GPU sozinha não detecta.
O cache KV é muito grande para o batch e contexto alvo.
Prefira uma arquitetura que use Grouped-Query Attention (GQA) ou Multi-Query Attention (MQA).
Por quê: GQA/MQA compartilham os "heads" de chave/valor, reduzindo a memória do cache KV e aumentando o tamanho de batch alcançável com pouca perda de qualidade.
Precisa estender o contexto utilizável de um modelo além do seu comprimento treinado.
Use o escalonamento RoPE (por exemplo, NTK-aware / YaRN) mais um ajuste fino leve para contexto longo.
Por quê: A interpolação RoPE estica as codificações posicionais; um ajuste fino curto adapta o modelo a um alcance mais longo sem retreinamento completo.
Deseja mais capacidade sem custo de inferência proporcional.
Considere um modelo Mixture-of-Experts (MoE) que ativa apenas os top-k experts por token.
Por quê: MoE escala os parâmetros mantendo os FLOPs por token baixos, mas adiciona complexidade de roteamento e carga irregular de experts para gerenciar.
Um modelo implantado precisa de limites de tópico, segurança e formato.
Envolva o modelo com NeMo Guardrails para impor "rails" de entrada e saída (tópicos, moderação, jailbreak).
Por quê: Os "rails" programáveis adicionam uma camada de segurança controlável ao redor do modelo sem retreiná-lo.
O modelo ocasionalmente produz conteúdo tóxico ou inseguro.
Adicione um classificador de moderação de saída e bloqueie/regenere respostas que excedam um limite de risco.
Por quê: Uma passagem de moderação separada captura gerações inseguras que as instruções de nível de prompt por si só não previnem de forma confiável.
As partes interessadas exigem evidências de que o modelo atende aos padrões de IA responsável.
Execute benchmarks de viés e toxicidade, documente os resultados e rastreie-os entre as versões em um cartão de modelo.
Por quê: A avaliação de segurança documentada e repetível suporta a conformidade e detecta regressões antes que cheguem à produção.