Los equipos que despliegan modelos de lenguaje ajustan sus configuraciones para cumplir metas concretas de latencia, velocidad, memoria y cómputo. Con la familia abierta NVIDIA Nemotron, los desarrolladores pueden elegir el modelo del tamaño adecuado para cada necesidad, pero el salto real de eficiencia aparece cuando ese modelo se comprime sin degradarse.

El nuevo checkpoint Nemotron 3.5 Lightning NVFP4 es el ejemplo que NVIDIA puso sobre la mesa esta semana: pasa de 66 GB a 22 GB al cuantizar buena parte de sus pesos a 4 bits, y entrega hasta 4 veces más rendimiento preservando la precisión.

¿Qué es la destilación consciente de cuantización?

Para comprimir modelos al formato NVFP4, la cuantización posterior al entrenamiento (PTQ, por sus siglas en inglés) es el método habitual y cubre la mayoría de los casos. El problema aparece cuando se busca máximo rendimiento con un presupuesto de memoria más ajustado: ahí hace falta una cuantización más agresiva, y la PTQ sola empieza a costar precisión.

La destilación consciente de cuantización (QAD) resuelve ese punto con un esquema de profesor y alumno. El modelo original en precisión completa BF16 queda congelado como profesor. Sobre esa misma base se corre PTQ para generar el alumno cuantizado, y luego el alumno se entrena comparando sus logits contra los del profesor mediante una función de pérdida de divergencia KL.

Proceso de dos etapas de QAD usado para construir el checkpoint NVFP4 de Nemotron 3.5 Lightning
Proceso de dos etapas de QAD usado para construir el checkpoint NVFP4 de Nemotron 3.5 Lightning

En la primera etapa, la PTQ lleva los pesos a W4A16 y produce el alumno. En la segunda, ese alumno se entrena con cuantización simulada en cada pase hacia adelante, de modo que aprende a convivir con el ruido que va a encontrar en inferencia. El resultado es el checkpoint NVFP4 final, con la precisión recuperada cerca de la línea base.

¿Por qué conviene cuantizar más fuerte de lo habitual?

Acá está el cambio de criterio menos obvio del trabajo. Cuando la PTQ es el paso final, la meta típica es una recuperación mediana de precisión superior al 99%. Cuando se sabe que después vendrá QAD, NVIDIA apuntó a un rango deliberadamente más bajo, entre 95% y 99%.

La lógica es que esa caída pequeña pero medible confirma que la compresión se empujó lo suficiente como para capitalizar las ganancias de tamaño y latencia, dejando margen claro para que la segunda etapa cierre la brecha. En el caso de Nemotron 3.5 Lightning, eso significó llevar las capas lineales de Mamba a W4A16 en lugar del más conservador FP8, una decisión que una receta de PTQ pura habría evitado.

Las recetas y la configuración de entrenamiento

NVIDIA evaluó cinco recetas de PTQ que se diferencian en cómo se calibran los pesos y en cuán agresivamente se cuantizan las proyecciones de Mamba y la caché KV. Todas comparten algunos parámetros: cuantizan la capa lm_head a W4A16, mantienen las proyecciones de atención en BF16 y usan 1.000 muestras de calibración sobre una sola NVIDIA DGX B300.

La calibración se probó con largos de secuencia de 8K a 128K, y los 32K dieron el mejor resultado sobre la receta llamada four_over_six, que terminó siendo la elegida por su equilibrio entre degradación y ganancia de rendimiento. La variante más agresiva del set empuja además las matrices K y V a NVFP4 (W4A4).

En el entrenamiento QAD, el largo de secuencia resultó crítico para los benchmarks de contexto largo. El ajuste supervisado posterior había usado unos 522K tokens, y las pruebas mostraron que hacía falta ese mismo largo de 522K para preservar el desempeño en contexto extendido. Las ablaciones iniciales corrieron a 256K y recién la corrida final escaló a 522K.

¿Qué significan 22 GB en la práctica?

La cifra importa más de lo que parece para quien no tiene un centro de datos detrás. Un checkpoint de 66 GB en BF16 no entra en ninguna GPU de consumo y obliga a repartirlo entre varios aceleradores de clase servidor. A 22 GB, el modelo pasa a caber holgadamente en una tarjeta de 32 GB de memoria y queda al filo de una de 24 GB, siempre que se reserve espacio para la caché KV y la ventana de contexto que se quiera abrir.

AspectoCheckpoint BF16Checkpoint NVFP4
Tamaño en disco66 GB22 GB
Reducciónlínea base3 veces menos
Rendimientolínea basehasta 4 veces más
Formato de pesosBF16W4A16 / NVFP4

Para integradores y laboratorios en Chile y la región, donde el arriendo de GPU por hora suele ser el cuello de botella real más que la licencia del modelo, la diferencia entre necesitar dos aceleradores y necesitar uno cambia la ecuación de costo por completo. Los pesos están publicados en Hugging Face y las recetas son reproducibles con NVIDIA Model Optimizer, que incluye ejemplos de QAD de punta a punta y un ejemplo de PTQ sobre modelos de Hugging Face.

El código para generar el alumno cuantizado cabe en pocas líneas:

Código
import modelopt.torch.quantization as mtq

# Bucle de calibración sobre el dataset
def forward_loop(model):
    for batch in calib_dataloader:
        model(batch)

# Cuantiza el modelo base a NVFP4 para crear el alumno PTQ
model = mtq.quantize(model, mtq.W4A16_NVFP4_CFG, forward_loop=forward_loop)

Los resultados experimentales sobre varios checkpoints de Lightning muestran que QAD supera de forma consistente a la PTQ sola en recuperación mediana de precisión y en los benchmarks agénticos y de programación, que son justamente los más sensibles a la degradación.