Export Quantisé

La dernière étape après checkpoint-promotion qui remet un verdict PROMOTE : un checkpoint qui a franchi la barrière à quatre étapes n'est toujours pas déployé tant qu'il n'est pas exporté dans le bon format pour son runtime cible et qu'il n'a pas prouvé fonctionner post-export. Un verdict REJECT n'atteint jamais cette skill — l'export ne démarre que depuis un checkpoint promu.

Entrée : un checkpoint promu (ou adapter LoRA) plus la surface de déploiement cible — classe GPU, serving stack, et si les workloads long-context/code/math sont en scope. Format de sortie : un artefact exporté au format choisi plus un rapport de diff smoke-test comparant 3–5 sorties golden pré-export et post-export.

Format Map

Choisissez le format selon le matériel et la forme de déploiement, pas par habitude — le mauvais choix gaspille soit la bande passante soit casse silencieusement sur des workloads spécifiques (voir Workload Overrides).

FP8 est le défaut sur les GPUs Hopper et plus récents. Il préserve une qualité proche de bf16 à à peu près la moitié de la mémoire, et c'est le premier choix sûr tant que le GPU cible le supporte et aucune contrainte edge-device ne s'applique.
AWQ INT4 cible les anciennes GPUs antérieures au support hardware FP8. GPTQ est supplanté pour les nouveaux déploiements — n'y recourez pas sur un export frais ; AWQ a une meilleure rétention de précision à la même largeur de bit et un support outillage plus large.
GGUF avec quantization Q4_K_M, construit à partir d'une imatrix, est le format edge/llama.cpp. Utilisez-le pour le déploiement local ou adjacent CPU, pas pour la throughput GPU-serving — il optimise pour l'empreinte, pas les tokens/sec sur une GPU de datacenter.
NVFP4 est pour les déploiements Blackwell-at-scale uniquement — et explicitement PAS sur GB10. NVFP4 sur SM121 (GB10) tourne ~32% plus lentement que FP8 parce que le hardware manque d'un chemin natif cvt.e2m1x2 sauf si le kernel est compilé sm_121a. Choisir NVFP4 sur une cible GB10 est une régression, pas une amélioration — choisissez FP8 là à la place.
Merged vs. LoRA-only est un axe séparé du format quant. Un export merged replie l'adapter dans les poids de base : artefact plus grand, pas de dépendance base-model au serve time. LoRA-only garde l'adapter séparé : artefact beaucoup plus petit, mais le serving stack doit charger le exact même base model à côté — un base mal-assorti ou bad-revision change silencieusement les sorties. Choisissez merged quand la portabilité de l'artefact importe plus que l'storage ; choisissez LoRA-only quand l'empreinte disque ou le multi-adapter serving importe plus.

Picked Worked

Le tradeoff de sélection de format principal, lu comme une lookup table pour scénarios courants :

Target	Workload	Format
Datacenter GPU	generic chat	FP8
Datacenter GPU	long-context/code/math	FP8 ou W8A8 — jamais INT4
Older GPU generation	generic	AWQ INT4
Edge device / laptop	llama.cpp serving	GGUF Q4_K_M + imatrix
GB10	any workload	FP8 via vLLM nightly, ou GGUF via llama.cpp locally — skip NVFP4

# quick decision snippet — see the table above for the full map
hopper_or_newer: fp8
older_gpu: awq-int4
edge_llama_cpp: gguf-q4_k_m+imatrix
gb10_any_workload: fp8-vllm-nightly   # never nvfp4 on GB10

Workload Overrides

Le Format Map ci-dessus est un défaut, pas une règle qui survit à chaque workload. Les workloads long-context, code, et math cassent à INT4 — l'erreur de quantization s'accumule sur les longues sequences et le raisonnement au niveau token précis d'une manière qui n'apparaît pas sur les prompts courts et génériques. Pour n'importe lequel de ces trois workload classes, restez sur FP8 ou W8A8 même si le hardware cible justifierait autrement INT4 sur la base des coûts.

Ne validez pas cet override avec MMLU ou des benchmarks de large connaissance similaires — ils ne stressent pas le failure mode. Mesurez avec les task evals actuels — les goldens et graders de eval-harness-first, exécutés à travers l'artefact exporté — parce que la dégradation INT4 sur long-context, code, ou math apparaît comme des échecs task-specific (context droppé, syntaxe cassée, erreurs arithmétiques) bien avant de bouger un benchmark de connaissance.
Si une task eval régresse après un export INT4 sur l'un de ces trois workload classes, la fix est de switcher le format, pas de re-tuner la recette quantization — les variantes AWQ et GPTQ à la même largeur de bit partagent le même failure mode erreur-accumulée sur ces workloads.

Le Smoke Test

Les bugs d'export sont silencieux au niveau fichier — un export malformé produit toujours un artefact loadable, donc les file-existence checks ne prouvent rien. Le smoke test est obligatoire pour chaque export, sans exception pour un format qui « devrait juste fonctionner » :

Chargez l'artefact exporté dans son runtime cible actuel — vLLM pour FP8/AWQ, llama.cpp pour GGUF, pas une chargement sanity rapide dans un framework différent de celui qui le servira en production.
Exécutez 3–5 golden prompts à travers — tirez-les du même eval/goldens.jsonl que eval-harness-first maintient, pas un ensemble ad hoc frais.
Comparez chaque sortie contre la génération pré-export pour le même prompt, les mêmes sampling settings déterministes — greedy decoding (temperature 0) et une seed fixe, persistée et réutilisée entre les runs pré- et post-export, pas juste un config nominalement identique. Pour un export lossless, byte match est la barrière — toute diff est un bug. Pour un export lossy (quantisé), byte match s'attend à échouer ; la barrière est plutôt l'accord du task-grader verdict — voir le Smoke-Test Script Skeleton de references/export-commands.md.

Exécutez-le comme une gate, pas une vérification manuelle :

python smoke_test.py "$EXPORT_PATH" \
    eval/goldens.jsonl pre-export-outputs.jsonl
# non-zero exit on any pre/post mismatch

Failure Signatures

À quoi ressemblent vraiment les bugs d'export, pas un flag pass/fail propre :

Template mismatch se présente comme une sortie brouillée ou qui s'enchaîne — le chat template incorporé à l'export ne correspond pas à celui contre lequel le checkpoint a été trained et evaluated, donc les turn boundaries ou special tokens atterrissent au mauvais endroit.
Wrong quantization applied to lm_head se présente comme une sortie off-template ou sémantiquement non-sens qui semble toujours fluide — la sortie head a perdu la précision qu'elle needed même si le reste du network quantized proprement.

Ne shippez jamais un export qui a sauté cette étape — le verdict PROMOTE d'un checkpoint dit que le checkpoint non-exporté est bon ; il ne dit rien sur la pipeline d'export. Re-run sur n'importe quel quant-method ou runtime version bump, pas seulement après le premier export. Des sequences de commandes runnable pour chaque format plus le smoke-test script skeleton : references/export-commands.md.

Related Skills

checkpoint-promotion — la seule source upstream valide pour cette skill. Un checkpoint sans verdict PROMOTE n'atteint pas l'export.
eval-harness-first — possède le eval/goldens.jsonl que le smoke test de cette skill tire ses 3–5 prompts, et les task evals que la section Workload Overrides requiert pour la validation long-context/code/math.
finetuning-method-selection — son references/model-catalog.md est l'endroit où vérifier les hardware-class assumptions (quelles générations GPU un base model cible) avant de choisir un format au Format Map ci-dessus.

Utilisateurs Spark : sur GB10, GGUF via llama.cpp fonctionne bien pour le serving local, et FP8 serving via vLLM nightly builds est l'autre chemin prouvé — NVFP4 est le seul format à éviter là (voir l'exception Format Map ci-dessus). Une fois le plugin dgx-spark-ops installé, déférez les questions Spark-specific serving et thermal à ses skills plutôt que de les re-dériver ici.

quantized-export