Capítulo 4: Cuantización: qué cambia y qué falta medir. En este capítulo aprenderás a comparar formatos sin confundir tamaño, memoria total, velocidad y calidad.

Cuantizar significa representar parte del modelo con menos bits. El objetivo suele ser reducir memoria y facilitar la inferencia, pero el nombre del formato no predice por sí solo el resultado. Dos opciones de cuatro bits pueden conservar capas distintas, usar escalas diferentes, depender de kernels diferentes y producir otra mezcla de velocidad y calidad. La comparación debe hacerse sobre el mismo modelo, con tareas y condiciones iguales.

En llama.cpp, el baseline activo usa GGUF Q4_K_L. La letra L no es un adorno: esta variante conserva embeddings y salida en Q8_0, mientras otras variantes Q4 pueden ocupar menos. Ese diseño puede ayudar a retener calidad, pero no hay un A/B local controlado que demuestre cuánto aporta en Ornith. Q4_K_M, IQ4_XS, Q5 y Q6 son candidatos de comparación, no peldaños con un ganador conocido.

AWQ W4A16 sigue otra ruta. Cuantiza pesos a cuatro bits y mantiene activaciones de dieciséis bits, con capas sensibles excluidas según la receta del checkpoint. Hay una ejecución local cercana a 261 mil tokens con KV INT4 y recuperación correcta. Su alcance es una solicitud. No valida concurrencia triple, no establece calidad equivalente al GGUF de llama.cpp y no permite declarar que AWQ sea mejor para producción.

El cache KV es un eje aparte. Se puede conservar el mismo archivo de pesos y cambiar la precisión del KV. La reducción ideal de memoria no es la reducción real del sistema, porque siguen presentes escalas, alineación, buffers y estado recurrente. Además, cuantizar y desquantizar puede sumar trabajo. Un KV más pequeño puede ampliar contexto o concurrencia sin mejorar la latencia. Por eso memoria, capacidad y velocidad deben reportarse por separado.

Fuente A documenta el Q4_K_L activo y la prueba limitada de AWQ W4A16. También reúne tamaños y recetas públicas de varios formatos. Fuente B refuerza la necesidad de un barrido de KV y aporta detalles que todavía requieren corroboración local. Consenso sostiene que no existe un ranking honesto sin A/B controlado. No sostiene que una etiqueta cualitativa del publicador sea una medición de Ornith.

Hay otras rutas, como GPTQ y NF4. El inventario auditado no encontró un checkpoint GPTQ exacto para este modelo, aunque el método pueda ser compatible con el motor. NF4 aparece como opción de carga o entrenamiento eficiente, pero no cuenta con un artefacto Ornith y una evaluación local equivalentes. En ambos casos, la clasificación correcta es compatible sin probar, no alternativa ya validada.

La calidad necesita tareas que puedan fallar de manera visible. Perplexity o similitud de logits sirven como señales, pero no reemplazan pruebas de código ejecutable, JSON contra esquema, llamadas de herramientas, español e inglés, recuperación en contexto largo y robustez. El mismo conjunto debe correr con plantilla, parser, muestreo y semillas fijas. Cuando exista una referencia de mayor precisión, conviene incluirla para medir la pérdida causada por cada quant.

La memoria también necesita un protocolo. Hay que registrar tamaño del archivo, memoria al cargar, pico durante prefilling y nivel estable durante generación. Para contexto largo se agregan longitud de entrada, salida, número de slots usados y concurrencia real. Una sola cifra de VRAM sin esos datos mezcla componentes y no permite reproducir la prueba.

La velocidad requiere separar arranque, compilación, primer token y generación sostenida. Los kernels pueden compilar en la primera corrida, y esa espera no representa el estado caliente. También hay que distinguir una secuencia de varias, porque el throughput total y la latencia por usuario responden de forma distinta. Las métricas históricas del Atlas siguen pendientes de trazabilidad y no deben llenar estos huecos.

MTP y DFlash no forman parte automática de la cuantización. MTP es una ruta especulativa integrada que aún no fue evaluada funcionalmente. DFlash es un archivo auxiliar presente, apagado y no validado. Activarlos durante una comparación de quants cambiaría más de una variable. Primero se comparan pesos con decodificación normal; después, KV; por último, cada mecanismo especulativo en un perfil separado.

QLoRA tampoco es una victoria de cuantización para serving. Es una técnica de ajuste eficiente con una base cuantizada y adaptadores entrenables. Hay ejecuciones comunitarias y advertencias específicas para Qwen3.5, pero falta una comparación Ornith controlada de calidad. LoRA BF16 puede actuar como referencia futura. QLoRA queda como alternativa experimental de menor memoria, no como logro del Atlas.

El criterio de decisión debe ser explícito. Si el objetivo es maximizar contexto, quizá convenga priorizar KV. Si se busca calidad de código, un quant más grande puede justificar su costo. Si se necesita concurrencia, hay que medir varias solicitudes reales. Ninguna decisión debe apoyarse sólo en el tamaño del archivo o en una etiqueta del repositorio.

Confirmado hoy… Q4_K_L con KV Q4 está activo en llama.cpp, y AWQ W4A16 tiene una prueba limitada cercana a 261 mil tokens. Son rutas distintas con alcances distintos.

Falta demostrar… El A/B de calidad entre quants, el barrido de KV, la memoria por fase, la velocidad reproducible, la concurrencia larga y la trazabilidad de métricas históricas.

Siguiente capítulo… Separaremos MTP, DFlash y los drafts externos para entender qué propone cada módulo y qué debe medirse antes de hablar de aceleración.