O que Exportação Quantizada faz?
A última parada após a promoção-de-checkpoint entrega um veredito PROMOTE: um checkpoint que passou pelo portão de quatro estágios ainda não está implantado até ser exportado no formato correto para seu runtime-alvo e provado que ainda funciona pós-exportação. Um veredito REJECT nunca chega a esta skill — a exportação começa apenas a partir de um checkpoint promovido.
Entrada: um checkpoint promovido (ou adaptador LoRA) mais a superfície de implantação alvo — classe de GPU, stack de servidor e se workloads de contexto longo/código/matemática estão no escopo. Saída: um artefato exportado no formato escolhido mais um relatório de diff do teste de fumaça comparando 3–5 saídas golden pré-exportação e pós-exportação.
Mapa de Formatos
Escolha o formato pelo hardware e formato de implantação, não por hábito — a escolha errada ou desperdiça margem de throughput ou quebra silenciosamente em workloads específicos (consulte Substituições de Workload).
- FP8 é o padrão em GPUs da classe Hopper e superiores. Ele preserva qualidade próxima a bf16 com aproximadamente metade da memória, e é a primeira escolha segura sempre que a GPU alvo suportá-lo e nenhuma restrição de dispositivo de borda se aplicar.
- AWQ INT4 é para GPUs mais antigas que antecedem o suporte de hardware FP8. GPTQ é substituído para novas implantações — não o use em uma exportação nova; AWQ tem melhor retenção de precisão na mesma largura de bits e suporte de ferramentas mais amplo atualmente.
- GGUF com quantização Q4_K_M, construído a partir de um imatrix, é o formato de borda/llama.cpp. Use-o para implantação local ou adjacente a CPU, não para throughput de servidor GPU — ele otimiza para tamanho, não para tokens/segundo em uma GPU de datacenter.
- NVFP4 é apenas para implantações em escala Blackwell — e explicitamente NÃO em GB10. NVFP4 em SM121 (GB10) roda ~32% mais lento que FP8 porque o hardware carece de um caminho nativo
cvt.e2m1x2a menos que o kernel seja compiladosm_121a. Escolher NVFP4 em um alvo GB10 é uma regressão, não uma melhoria — escolha FP8 lá. - Mesclado vs. apenas LoRA é um eixo separado do formato de quantização. Uma exportação mesclada funde o adaptador nos pesos base: artefato maior, sem dependência de modelo base no momento do servidor. Apenas LoRA mantém o adaptador separado: artefato muito menor, mas o stack de servidor deve carregar exatamente o mesmo modelo base junto com ele — um base incompatível ou de revisão errada altera silenciosamente as saídas. Escolha mesclado quando a portabilidade do artefato importar mais que o armazenamento; escolha apenas LoRA quando o tamanho do disco ou o servidor multi-adaptador importar mais.
Escolhas Práticas
O trade-off central da seleção de formato, lido como uma tabela de consulta para cenários comuns:
| Alvo | Workload | Formato |
|---|---|---|
| GPU de datacenter | chat genérico | FP8 |
| GPU de datacenter | contexto longo/código/matemática | FP8 ou W8A8 — nunca INT4 |
| Geração de GPU antiga | genérico | AWQ INT4 |
| Dispositivo de borda / laptop | servidor llama.cpp | GGUF Q4_K_M + imatrix |
| GB10 | qualquer workload | FP8 via vLLM nightly, ou GGUF via llama.cpp localmente — pule NVFP4 |
# trecho de decisão rápido — veja a tabela acima para o mapa completo
hopper_or_newer: fp8
older_gpu: awq-int4
edge_llama_cpp: gguf-q4_k_m+imatrix
gb10_any_workload: fp8-vllm-nightly # nunca nvfp4 em GB10
Substituições de Workload
O Mapa de Formatos acima é um padrão, não uma regra que sobrevive a todo workload. Workloads de contexto longo, código e matemática quebram em INT4 — o erro de quantização se acumula em sequências longas e raciocínio preciso no nível de token de maneiras que não aparecem em prompts curtos e genéricos. Para qualquer uma dessas três classes de workload, fique em FP8 ou W8A8 mesmo que o hardware alvo justificaria INT4 por razões de custo.
- Não valide esta substituição com MMLU ou benchmarks de conhecimento amplo semelhantes — eles não estressam o modo de falha. Meça com as avaliações de tarefa reais — os goldens e avaliadores de
eval-harness-first, executados através do artefato exportado — porque a degradação INT4 em contexto longo, código ou matemática se manifesta como falhas específicas de tarefa (contexto perdido, sintaxe quebrada, erros aritméticos) bem antes de mover um benchmark de conhecimento. - Se uma avaliação de tarefa regredir após uma exportação INT4 em uma dessas três classes de workload, a correção é trocar de formato, não reajustar a receita de quantização — variantes AWQ e GPTQ na mesma largura de bits compartilham o mesmo modo de falha de erro composto nesses workloads.
O Teste de Fumaça
Bugs de exportação são silenciosos no nível do arquivo — uma exportação malformada ainda produz um artefato carregável, então verificações de existência de arquivo não provam nada. O teste de fumaça é obrigatório para toda exportação, sem exceção para um formato que "deveria funcionar":
- Carregue o artefato exportado em seu runtime-alvo real — vLLM para FP8/AWQ, llama.cpp para GGUF, não uma carga de verificação rápida em um framework diferente daquele que vai servir em produção.
- Execute 3–5 prompts golden através dele — retire-os do mesmo
eval/goldens.jsonlqueeval-harness-firstmantém, não de um conjunto ad hoc novo. - Compare cada saída com a geração pré-exportação para o mesmo prompt, mesmas configurações de amostragem determinística — decodificação gulosa (temperatura 0) e uma semente fixa, persistida e reutilizada entre as execuções pré e pós-exportação, não apenas configuração nominalmente idêntica. Para uma exportação sem perdas, a correspondência de bytes é o portão — qualquer diff é um bug. Para uma exportação com perdas (quantizada), espera-se que a correspondência de bytes falhe; o portão é a concordância do veredito do avaliador de tarefa — consulte
references/export-commands.md's Esqueleto do Script de Teste de Fumaça.
Execute isso como um portão, não uma verificação manual:
python smoke_test.py "$EXPORT_PATH" \
eval/goldens.jsonl pre-export-outputs.jsonl
# saída não-zero em qualquer incompatibilidade pré/pós
Assinaturas de Falha
Como os bugs de exportação realmente se parecem, não uma bandeira limpa de aprovação/reprovação:
- Incompatibilidade de template se apresenta como saída confusa ou contínua — o template de chat embutido na exportação não corresponde àquele contra o qual o checkpoint foi treinado e avaliado, então limites de turno ou tokens especiais caem no lugar errado.
- Quantização errada aplicada a
lm_headse apresenta como saída fora do template ou semanticamente sem sentido que ainda parece fluente — a cabeça de saída perdeu precisão que precisava mesmo que o resto da rede tenha quantizado limpo.
Nunca envie uma exportação que pulou esta etapa — o veredito PROMOTE de um checkpoint diz que o checkpoint não exportado é bom; ele não diz nada sobre o pipeline de exportação. Reexecute em qualquer mudança de método de quantização ou versão do runtime, não apenas após a primeira exportação. Sequências de comandos executáveis para cada formato mais o esqueleto do script de teste de fumaça: references/export-commands.md.
Skills Relacionadas
promoção-de-checkpoint— a única fonte upstream válida para esta skill. Um checkpoint sem um vereditoPROMOTEnão chega à exportação.eval-harness-first— possui oeval/goldens.jsonldo qual o teste de fumaça desta skill extrai seus 3–5 prompts, e as avaliações de tarefa que a seção Substituições de Workload exige para validação de contexto longo/código/matemática.seleção-de-método-de-ajuste-fino— seureferences/model-catalog.mdé o lugar para verificar suposições de classe de hardware (quais gerações de GPU um modelo base visa) antes de escolher um formato do Mapa de Formatos acima.
Usuários Spark: no GB10, GGUF via llama.cpp funciona bem para servidor local, e servidor FP8 via builds nightly do vLLM é o outro caminho comprovado — NVFP4 é o único formato para evitar lá (veja a exceção do Mapa de Formatos acima). Uma vez que o plugin dgx-spark-ops esteja instalado, delegue perguntas específicas de servidor Spark e térmicas a suas skills em vez de rederivá-las aqui.