Exportación Cuantizada
La última parada después de que checkpoint-promotion
emite un veredicto PROMOTE: un checkpoint
que superó la puerta de cuatro etapas aún no está
implementado hasta que se exporta en el formato
correcto para su tiempo de ejecución objetivo y se demuestra que
sigue funcionando después de la exportación. Un veredicto REJECT
nunca llega a esta habilidad — la exportación comienza solo
desde un checkpoint promocionado.
Entrada: un checkpoint promocionado (o adaptador LoRA) más la superficie de implementación objetivo — clase de GPU, pila de servicio, y si las cargas de trabajo de contexto largo/código/matemáticas están en el alcance. Formato de salida: un artefacto exportado en el formato elegido más un informe de diferencias de la prueba de humo que compara 3 a 5 salidas de referencia pre-exportación y post-exportación.
Mapa de Formatos
Elige el formato según el hardware y la forma de implementación, no por costumbre — la elección incorrecta o desperdicia capacidad de procesamiento o falla silenciosamente en cargas de trabajo específicas (consulta Anulaciones por Carga de Trabajo).
- FP8 es el valor predeterminado en GPUs de clase Hopper y superiores. Preserva una calidad cercana a bf16 con aproximadamente la mitad de la memoria, y es la primera opción segura siempre que la GPU objetivo lo soporte y no se aplique ninguna restricción de dispositivo perimetral.
- AWQ INT4 está dirigido a GPUs más antiguas que son anteriores al soporte de hardware FP8. GPTQ está obsoleto para nuevas implementaciones — no lo uses en una exportación nueva; AWQ tiene una mejor retención de precisión con el mismo ancho de bits y un soporte de herramientas más amplio.
- GGUF con cuantización Q4_K_M, construido a partir de una imatrix, es el formato para dispositivos perimetrales/llama.cpp. Úsalo para implementación local o adyacente a CPU, no para rendimiento de servicio con GPU — optimiza para huella de memoria, no para tokens/segundo en una GPU de centro de datos.
- NVFP4 es solo para implementaciones Blackwell a gran
escala — y explícitamente NO en GB10.
NVFP4 en SM121 (GB10) se ejecuta ~32%
más lento que FP8 porque el hardware carece de una
ruta nativa
cvt.e2m1x2a menos que el kernel se compile comosm_121a. Elegir NVFP4 en un objetivo GB10 es una regresión, no una mejora — elige FP8 allí. - Fusionado vs. solo LoRA es un eje separado del formato de cuantización. Una exportación fusionada incorpora el adaptador en los pesos base: artefacto más grande, sin dependencia del modelo base en tiempo de servicio. Solo LoRA mantiene el adaptador separado: artefacto mucho más pequeño, pero la pila de servicio debe cargar el mismo modelo base exacto junto a él — un modelo base no coincidente o de revisión incorrecta cambia silenciosamente las salidas. Elige fusionado cuando la portabilidad del artefacto importe más que el almacenamiento; elige solo LoRA cuando la huella de disco o el servicio multiadaptador importe más.
Selecciones Prácticas
El intercambio central de selección de formato, leído como una tabla de consulta para escenarios comunes:
| Objetivo | Carga de trabajo | Formato |
|---|---|---|
| GPU de centro de datos | chat genérico | FP8 |
| GPU de centro de datos | contexto largo/código/matemáticas | FP8 o W8A8 — nunca INT4 |
| Generación de GPU más antigua | genérico | AWQ INT4 |
| Dispositivo perimetral / portátil | servicio llama.cpp | GGUF Q4_K_M + imatrix |
| GB10 | cualquier carga de trabajo | FP8 mediante vLLM nightly, o GGUF mediante llama.cpp localmente — omitir NVFP4 |
# fragmento de decisión rápida — consulta la tabla anterior para el mapa completo
hopper_o_nuevo: fp8
gpu_antigua: awq-int4
perimetral_llama_cpp: gguf-q4_k_m+imatrix
gb10_cualquier_trabajo: fp8-vllm-nightly # nunca nvfp4 en GB10
Anulaciones por Carga de Trabajo
El mapa de formatos anterior es un valor predeterminado, no una regla que sobrevive a toda carga de trabajo. Las cargas de trabajo de contexto largo, código y matemáticas fallan con INT4 — el error de cuantización se acumula en secuencias largas y en razonamientos precisos a nivel de token de formas que no aparecen en indicaciones cortas y genéricas. Para cualquiera de estas tres clases de carga de trabajo, quédate con FP8 o W8A8 incluso si el hardware objetivo justificaría INT4 por razones de costo.
- No valides esta anulación con MMLU o
puntos de referencia similares de conocimiento amplio — no
estresan el modo de fallo. Mide con las evaluaciones de tareas reales
— las salidas de referencia y los calificadores de
eval-harness-first, ejecutados a través del artefacto exportado — porque la degradación de INT4 en contexto largo, código o matemáticas se manifiesta como fallos específicos de la tarea (contexto perdido, sintaxis rota, errores aritméticos) mucho antes de que mueva un punto de referencia de conocimiento. - Si una evaluación de tarea retrocede después de una exportación INT4 en una de estas tres clases de carga de trabajo, la solución es cambiar de formato, no reajustar la receta de cuantización — las variantes AWQ y GPTQ con el mismo ancho de bits comparten el mismo modo de fallo de error compuesto en estas cargas de trabajo.
La Prueba de Humo
Los errores de exportación son silenciosos a nivel de archivo — una exportación mal formada aún produce un artefacto cargable, por lo que las comprobaciones de existencia de archivos no prueban nada. La prueba de humo es obligatoria para cada exportación, sin excepción para un formato que "debería funcionar":
- Carga el artefacto exportado en su tiempo de ejecución objetivo real — vLLM para FP8/AWQ, llama.cpp para GGUF, no una carga rápida de verificación en un marco diferente al que lo servirá en producción.
- Ejecuta 3 a 5 indicaciones de referencia a través de él —
extráelas del mismo
eval/goldens.jsonlque mantieneeval-harness-first, no de un conjunto ad hoc nuevo. - Compara cada salida con la generación
previa a la exportación para la misma indicación,
las mismas configuraciones de muestreo deterministas — decodificación voraz (temperatura 0)
y una semilla fija, persistida y reutilizada
entre las ejecuciones pre y post exportación, no solo
configuraciones nominalmente idénticas. Para una exportación sin pérdida, la coincidencia de bytes es la puerta —
cualquier diferencia es un error. Para una exportación con pérdida
(cuantizada), se espera que la coincidencia de bytes falle;
la puerta es el acuerdo del calificador de tarea en su lugar — consulta
references/export-commands.md's Esqueleto de Script de Prueba de Humo.
Ejecuta esto como una puerta, no como una verificación manual:
python smoke_test.py "$EXPORT_PATH" \
eval/goldens.jsonl pre-export-outputs.jsonl
# salida distinta de cero en cualquier discrepancia pre/post
Firmas de Fallo
Cómo se ven realmente los errores de exportación, no una bandera simple de aprobado/reprobado:
- Desajuste de plantilla se presenta como salida confusa o continua — la plantilla de chat incorporada en la exportación no coincide con aquella contra la que el checkpoint fue entrenado y evaluado, por lo que los límites de turno o los tokens especiales caen en el lugar equivocado.
- Cuantización incorrecta aplicada a
lm_headse presenta como salida fuera de plantilla o semánticamente sin sentido que aún parece fluida — la cabeza de salida perdió la precisión que necesitaba aunque el resto de la red se cuantizó limpiamente.
Nunca envíes una exportación que omitió este paso —
un veredicto PROMOTE de un checkpoint dice que el
checkpoint no exportado es bueno; no dice
nada sobre el proceso de exportación. Vuelve a ejecutar
ante cualquier cambio de método de cuantización o versión del tiempo de ejecución, no
solo después de la primera exportación. Secuencias de comandos ejecutables para
cada formato más el esqueleto del script de prueba de humo:
references/export-commands.md.
Habilidades Relacionadas
checkpoint-promotion— la única fuente ascendente válida para esta habilidad. Un checkpoint sin un veredictoPROMOTEno llega a la exportación.eval-harness-first— posee eleval/goldens.jsonldel cual la prueba de humo de esta habilidad obtiene sus 3 a 5 indicaciones, y las evaluaciones de tareas que la sección Anulaciones por Carga de Trabajo requiere para la validación de contexto largo/código/matemáticas.finetuning-method-selection— sureferences/model-catalog.mdes el lugar para verificar las suposiciones de clase de hardware (qué generaciones de GPU tiene como objetivo un modelo base) antes de elegir un formato del mapa de formatos anterior.
Usuarios de Spark: en GB10, GGUF a través de llama.cpp
funciona bien para el servicio local, y el servicio FP8
a través de las compilaciones nocturnas de vLLM es la otra ruta
probada — NVFP4 es el único formato que se debe evitar allí
(consulta la excepción del mapa de formatos anterior). Una vez que el
plugin dgx-spark-ops esté instalado, delega las preguntas
específicas de servicio y térmicas de Spark a
sus habilidades en lugar de derivarlas aquí.