Cuantizacion on lo0 — Blog Técnico

Cuantización agresiva (estado del arte): del 4-bit al ternario

Tue, 09 Jun 2026 02:10:00 +0000

Este post es la continuación directa de Quantization para inferencia LLM, que cubre el régimen “resuelto” (FP8, INT4 con GPTQ/AWQ). Léelo primero: aquí asumo la matemática del scale+zero-point, qué hacen GPTQ y AWQ, y la distinción PTQ/QAT. Lo que añadimos es la frontera sub-4-bit, donde la cuantización post-hoc escalar deja de funcionar y hay que cambiar de herramienta.

TL;DR

Hay una línea divisoria nítida alrededor de los 4 bits. Por encima, cuantizar es un problema resuelto: INT8 es indistinguible de BF16, e INT4 con un método bueno (AWQ, GPTQ) pierde 1-2 puntos de MMLU y poco más. El método sigue siendo el mismo de siempre —tomar cada peso, escalarlo, redondearlo a un entero corto— y funciona. Por debajo de 4 bits, ese método colapsa: a 2 bits la cuantización escalar ingenua puede duplicar la perplexity. La razón es geométrica —cada peso tiene solo 4 valores posibles, el error de redondeo deja de ser despreciable— y la salida no es “redondear mejor”, es cambiar de representación. Los métodos SOTA de 2 bits (AQLM, QuIP#, QTIP) dejan de cuantizar pesos individuales y cuantizan vectores de pesos contra diccionarios (códigos), y “blanquean” la matriz de pesos para repartir su energía y aplastar outliers (incoherence processing). El ternario es otra cosa todavía: BitNet b1.58, con pesos en {-1, 0, +1} (~1.58 bits), no es PTQ —es un modelo entrenado nativamente con esa restricción— y cambia la aritmética de la matmul de multiplicaciones a sumas/restas, tocando a la vez el techo de cómputo y el de memoria. La regla mental: ≥4-bit comprimes la foto; <4-bit tienes que repintarla.

La analogía: el JPEG que ya no se puede comprimir más

En el post de quantization usamos el JPEG con detector de bordes para explicar INT4. Aquí la analogía sigue, pero hay que llevarla hasta su límite.

Un JPEG con factor de calidad 90 es indistinguible del original. A calidad 60 ya se nota un poco, pero sigue siendo “la misma foto”. A calidad 30 aparecen los bloques 8×8, los halos alrededor de los bordes, el banding en los degradados. A calidad 10 la imagen está destruida: reconoces que había una cara, pero los detalles han desaparecido bajo los artefactos. Y aquí está la clave: no existe ningún encoder JPEG que comprima a calidad 10 sin esos artefactos, porque el algoritmo JPEG (DCT por bloques + cuantización de coeficientes) tiene un suelo de información por debajo del cual su propio mecanismo introduce el ruido.

¿Qué haces si necesitas la foto a ese tamaño de archivo y que se siga viendo bien? No comprimes más la original. Repintas la foto sabiendo de antemano que va a vivir comprimida: un ilustrador la redibuja con líneas limpias, paleta reducida, cero degradados sutiles —una imagen diseñada para sobrevivir a la compresión brutal—. El resultado a “10 KB” se ve infinitamente mejor que el JPEG original aplastado a 10 KB, porque no es el mismo proceso: uno destruye información existente, el otro genera información nueva ya adaptada a la restricción.

Esa es exactamente la frontera de este post:

PTQ escalar (≥4-bit) = comprimir el JPEG. Hasta cierto ratio, sigue siendo la misma foto.
PTQ vectorial SOTA (2-bit: AQLM, QuIP#, QTIP) = un códec de imagen mucho más sofisticado (diccionarios, transformadas que decorrelacionan) que estira el ratio comprimible un poco más antes del colapso.
Ternario nativo (BitNet b1.58) = repintar la foto. No comprimes un modelo BF16 existente; entrenas uno nuevo que nace ternario.

El mapa de la frontera, bit a bit

Cuantizar un modelo es decidir cuántos valores distintos puede tomar cada peso. Con b bits por peso hay 2^b valores posibles. La pregunta central es: ¿a partir de qué b el número de valores es tan pequeño que el redondeo destruye el modelo?

Bits	Valores/peso	Estado del arte	Método necesario	Pérdida típica vs BF16
8	256	Resuelto	RTN, SmoothQuant, FP8	~0 (indistinguible)
4	16	Resuelto	AWQ, GPTQ	1-2 pp MMLU, +0.1-0.3 PPL
3	8	Degradación pequeña	GPTQ/AWQ tuneado, GGUF Q3_K	3-5 pp MMLU
2	4	Serio salvo SOTA	AQLM, QuIP#, QTIP (no escalar)	escalar: colapso; SOTA: 4-8 pp
1.58	3 (ternario)	Solo nativo	BitNet b1.58 (QAT/entrenamiento nativo)	n/a (no es PTQ)
1	2 (binario)	Investigación	nativo, claims dudosos	grande / sin metodología clara

Las tres transiciones que importan:

8 → 4 bits: nada se rompe. Con 16 niveles por peso y un scale por bloque de 128, el error de redondeo es pequeño relativo a la dinámica de los pesos. GPTQ compensa el error propagándolo a los pesos vecinos; AWQ protege el ~1 % de canales salientes. El modelo casi no lo nota. Esto está en el post anterior.

4 → 2 bits: el codo. Aquí pasan dos cosas a la vez. Primero, con solo 4 niveles, el cuantizador escalar ya no puede representar la distribución de pesos —que es aproximadamente gaussiana con colas largas— sin un error de redondeo enorme en proporción. Segundo, y más sutil: el error de cuantización deja de ser “ruido pequeño que el modelo absorbe” y se vuelve estructurado, sesgando sistemáticamente las activaciones. La PTQ escalar ingenua a 2 bits sobre un Llama 8B típicamente duplica la perplexity o más. Es el codo de la curva.

2 → 1.58 bits: cambio de naturaleza. No se cruza con un método de compresión mejor. Se cruza entrenando el modelo desde el principio con la restricción. Es una discontinuidad: a la izquierda estás haciendo PTQ, a la derecha estás haciendo entrenamiento.

Por qué la PTQ escalar colapsa por debajo de 4 bits

El cuantizador escalar tiene una limitación de fondo: cuantiza cada peso por separado, ignorando que los pesos de una fila/columna están correlacionados y que el error de uno se podría compensar con otro. A 4 bits esto importa poco; a 2 bits es letal. Hay tres ataques posibles, y los métodos SOTA usan los tres.

1. Cuantización vectorial: diccionarios en lugar de escalas

En lugar de mapear cada peso a uno de 4 valores, agrupa los pesos en vectores (p. ej. de 8 pesos) y mapea cada vector al entrada más cercana de un diccionario (codebook) aprendido. Si el diccionario tiene 256 entradas, codificar un vector de 8 pesos cuesta 8 bits (el índice) → 1 bit/peso, pero cada “valor reconstruido” es un punto en un espacio de 8 dimensiones elegido para minimizar el error sobre la distribución real de pesos.

La ventaja es de teoría de la información: un diccionario de vectores puede colocar sus puntos de reconstrucción donde realmente están los pesos (en racimos), mientras que el cuantizador escalar está obligado a poner sus 4 niveles en una rejilla regular, gastando resolución en zonas vacías. Es la diferencia entre un mapa de carreteras con cuadrícula uniforme y uno que pone más detalle donde hay ciudades.

AQLM (Additive Quantization of Language Models, arXiv:2401.06118) lleva esto al extremo con cuantización aditiva: cada vector de pesos se reconstruye como suma de varios códigos de varios diccionarios (multi-codebook). Es más expresivo que un solo diccionario porque el número de combinaciones es el producto de los tamaños, no la suma. AQLM fue uno de los primeros métodos en hacer 2-bit “usable” (no colapsado) en modelos grandes, a costa de un proceso de calibración caro y kernels de inferencia especializados.

2. Incoherence processing: blanquear la matriz

El segundo ataque es contra los outliers. Las matrices de pesos de un transformer tienen unas pocas entradas (y unos pocos canales) con magnitud mucho mayor que el resto. Esos outliers dominan el rango del cuantizador: si tienes que representar un peso de magnitud 8 y el resto son de magnitud 0.5, tu scale se estira para cubrir el 8 y desperdicias casi toda la resolución.

Incoherence processing (la idea central de QuIP y QuIP#) ataca esto multiplicando la matriz de pesos W por matrices ortogonales aleatorias por la izquierda y la derecha: W' = U W V^T. Como U y V son ortogonales, la operación es invertible y la matemática del producto se puede deshacer en inferencia absorbiéndola en las capas vecinas (igual que AWQ absorbe sus escalas). Pero la rotación reparte la energía: una matriz “incoherente” tiene sus valores repartidos de forma casi uniforme, sin outliers concentrados, porque mezclar coordenadas con una rotación aleatoria aplana la distribución (es, en esencia, el teorema central del límite actuando sobre combinaciones lineales). Una matriz sin outliers se cuantiza muchísimo mejor a 2 bits. Es el equivalente a “blanquear” una señal antes de digitalizarla.

QuIP# (arXiv:2402.04396) combina incoherence processing con códigos reticulares E8: en vez de un diccionario arbitrario, usa el retículo E8 (un empaquetamiento de esferas óptimo en 8 dimensiones, el mejor conocido). Cuantizar vectores de 8 pesos contra el retículo E8 da el menor error de reconstrucción posible para una densidad de bits dada, porque E8 es literalmente la forma más eficiente de colocar puntos en 8D. Es teoría de codificación clásica aplicada a pesos de LLM.

3. Codificación con memoria: trellis

QTIP (arXiv:2406.11235) añade el tercer ataque: trellis-coded quantization. En lugar de cuantizar cada vector de forma independiente, modela la secuencia de pesos como un camino a través de un trellis (la misma estructura de los códigos convolucionales de las telecomunicaciones) y elige la secuencia de códigos óptima con el algoritmo de Viterbi. La intuición: introducir memoria entre cuantizaciones sucesivas permite errores correlacionados que se cancelan, en vez de errores independientes que se acumulan. QTIP, sobre incoherence processing, mejora a QuIP# en calidad a 2-3 bits manteniendo kernels de inferencia rápidos.

La idea común a los tres: dejar de cuantizar escalares y empezar a cuantizar vectores con diccionarios, y decorrelacionar la matriz antes de hacerlo. Ninguno es “redondear mejor”; los tres cambian la representación de raíz. Por eso, por debajo de 4 bits, ya no basta con un flag en vLLM: hace falta co-diseño de método de cuantización + kernel de inferencia.

El ternario nativo: BitNet b1.58

Aquí cambiamos de continente. Todo lo anterior es PTQ: parte de un modelo BF16 entrenado y lo comprime. El ternario de BitNet no comprime nada.

BitNet b1.58 (arXiv:2402.17764) entrena un transformer desde cero donde cada peso está restringido a {-1, 0, +1} durante todo el entrenamiento. Tres valores ⇒ log₂(3) ≈ 1.58 bits/peso. La cuantización no es un paso posterior: las capas lineales (BitLinear) cuantizan sus pesos a ternario en el forward pass de cada step de entrenamiento, y los gradientes fluyen a través de un estimador straight-through. El modelo aprende a funcionar con pesos ternarios. Esto es QAT llevado al extremo: no un fine-tune corto de robustez, sino la restricción presente desde el primer token de entrenamiento.

Esa diferencia es la que esquiva el codo de la curva. La PTQ a 2 bits intenta encontrar la mejor aproximación ternaria/quaternaria de un modelo que se entrenó esperando precisión completa —y ese modelo tiene pesos “frágiles” que dependen de matices que 2 bits no capturan—. BitNet, en cambio, nunca tuvo esos matices: sus pesos nacieron ternarios, así que la red distribuyó su capacidad representacional de forma compatible con la restricción. Es repintar la foto en vez de comprimirla.

Lo que cambia no es solo la memoria, es la aritmética

El punto que más se subestima de BitNet: con pesos en {-1, 0, +1}, la multiplicación desaparece de la matmul. Multiplicar una activación x por un peso ternario w es trivial: si w = +1 sumas x, si w = -1 restas x, si w = 0 no haces nada. La operación dominante de un transformer —el producto matriz-vector— pasa de ser un mar de multiplica-acumula (MAC) en coma flotante a ser sumas y restas enteras.

Esto importa porque conecta con el roofline. Como se explica en El roofline invertido de los modelos pequeños, la inferencia LLM tiene dos techos: el de memoria (ancho de banda HBM para cargar pesos) y el de cómputo (FLOPs de las tensor cores). La cuantización normal (INT4, FP8) ataca solo el techo de memoria: el peso ocupa menos, pero para multiplicarlo lo descuantizas a FP16 y haces la misma multiplicación de siempre. El ternario ataca ambos techos a la vez: el peso ocupa 1.58 bits (memoria) y la operación es una suma en lugar de una multiplicación (cómputo). Por eso BitNet necesita kernels propios —bitnet.cpp— que ejecutan la matmul ternaria sin pasar nunca por FP16; un kernel que descuantizara a FP16 para multiplicar tiraría a la basura la mitad de la ventaja.

La contrapartida honesta: BitNet b1.58 es entrenamiento desde cero. No puedes “convertir tu Llama 8B a BitNet”. Si quieres ternario, entrenas (o usas) un modelo nativamente ternario, con todo lo que implica en coste de pre-entrenamiento y en disponibilidad de pesos. Hoy es una línea de investigación con modelos publicados a escalas modestas, no un drop-in para reemplazar tu serving actual.

QAT como puente entre PTQ y nativo

Entre “comprimir post-hoc” (PTQ) y “entrenar nativamente ternario” (BitNet) hay un punto intermedio: QAT (Quantization-Aware Training). Tomas un modelo ya entrenado y haces un fine-tune corto con las operaciones de cuantización dentro del bucle, para que aprenda a ser robusto a bits bajos sin pagar un pre-entrenamiento completo.

Gemma 3 publica variantes QAT oficiales precisamente para esto: modelos que, tras el fine-tune QAT, sostienen INT4 con una pérdida de calidad mucho menor que la PTQ pura sobre el mismo modelo. El coste es de entrenamiento (horas-días de GPU sobre un modelo ya existente), no de inferencia. Para INT4 con QAT recuperas casi toda la calidad; para 2-bit, QAT ayuda pero sigue siendo terreno difícil; para ternario, el QAT deja de ser “fine-tune corto” y se convierte en entrenamiento nativo (BitNet).

La jerarquía de decisión:

PTQ = default a ≥4 bits. Minutos-horas, sin tocar pesos de entrenamiento. Cubre el 90 % de producción.
QAT = cuando PTQ pierde demasiado y la diferencia importa. Bits bajos (2-3), o modelos sensibles. Pagas fine-tune.
Nativo (ternario) = cuando quieres bajar de 2 bits y cambiar la aritmética. Pagas pre-entrenamiento. Solo tiene sentido si controlas el modelo desde su creación.

Las matemáticas que importan: footprint y cuántos caben

El footprint de los pesos es directo: bytes = (bits/param / 8) × N, con N el número de parámetros. Para un modelo de 8B:

Nivel	bits/param	Footprint 8B	Ratio vs BF16
BF16	16	16.0 GB	1.0×
INT8	8	8.0 GB	2.0×
INT4	4	4.0 GB	4.0×
3-bit	3	3.0 GB	5.3×
2-bit	2	2.0 GB	8.0×
1.58-bit (ternario)	~1.58	~1.6 GB	~10×

(El ternario real ocupa algo más de 1.58 bits/param porque hay que empaquetar 5 valores ternarios en 8 bits —5 × log₂(3) ≈ 7.92 bits— y porque las normas y embeddings suelen quedarse en más precisión. La cifra de ~1.6 GB para 8B es el orden de magnitud correcto.)

¿Cuántos modelos de 8B caben en una RTX 4090?

Una RTX 4090 (24 GB, Ada Lovelace) tiene 24 GB. Reservamos ~4 GB para KV cache y activaciones, dejando 20 GB para pesos. Cuántos modelos de 8B distintos caben cargados simultáneamente:

Nivel	Footprint 8B	Modelos en 20 GB	Comentario
BF16	16.0 GB	1	uno y queda margen escaso
INT8	8.0 GB	2	dos modelos distintos
INT4	4.0 GB	5	régimen resuelto; calidad ~lossless con AWQ
3-bit	3.0 GB	6	degradación pequeña ya visible
2-bit	2.0 GB	10	solo viable con AQLM/QuIP#/QTIP
1.58-bit	~1.6 GB	~12	solo modelos nativamente ternarios

La cuenta es seductora —de 1 a 12 modelos en la misma tarjeta— pero hay que leerla con escepticismo. Saltar de INT4 (5 modelos, casi sin pérdida) a 2-bit (10 modelos) duplica la capacidad, pero solo si usas un método SOTA y aceptas 4-8 puntos de MMLU. Y el salto de 2-bit a ternario (10 → 12) es marginal en memoria: el ternario no se justifica por footprint frente a un 2-bit SOTA, se justifica por la aritmética (el techo de cómputo) y porque evita el codo de calidad al ser nativo. Si tu única métrica es “cuántos GB ocupa”, el 2-bit SOTA ya te da casi todo. El ternario es para cuando además quieres el ahorro de cómputo.

La curva conceptual: perplexity vs bits

Tres lecturas de la curva. Uno: a la derecha de 4 bits, las tres ramas están casi pegadas y casi planas —el régimen resuelto—. Dos: la rama roja (PTQ escalar ingenua) tiene un codo brutal entre 3 y 2 bits; ahí es donde duplica la perplexity. La rama azul (PTQ SOTA vectorial) aplana ese codo —no lo elimina, pero lo hace tolerable hasta 2 bits—. Tres: el punto verde del ternario nativo no está en ninguna de las dos curvas de PTQ, porque no se obtiene comprimiendo: se obtiene entrenando, y por eso puede caer por debajo del codo sin pagar el precio de calidad que paga cualquier PTQ a esa densidad de bits. Es la diferencia entre el JPEG aplastado y la foto repintada.

Escepticismo obligatorio: el 1-bit “sin pérdida” y los benchmarks sin metodología

Tres alertas para leer la literatura de cuantización agresiva:

“1-bit sin pérdida” casi siempre tiene letra pequeña. El binario puro {-1, +1} (1 bit) pierde la capacidad de representar el cero, que en transformers es importante (muchos pesos efectivamente nulos). Por eso el verdadero estado del arte de baja densidad es ternario (1.58 bits), no binario: el cero vale su 0.58 de bit extra. Cuando un paper anuncia “1-bit”, conviene mirar si (a) es realmente 1 bit o 1.58 redondeado hacia abajo en el titular, (b) “sin pérdida” se mide en perplexity de WikiText (fácil) o en benchmarks de razonamiento (donde el colapso aparece), y (c) compara contra un baseline del mismo tamaño efectivo o contra un modelo mucho mayor para inflar la ventaja.

Perplexity plana ≠ calidad preservada. La perplexity en un corpus genérico es la métrica más indulgente con la cuantización agresiva. Un modelo 2-bit puede tener perplexity casi idéntica al BF16 y a la vez caer 10 puntos en GSM8K o en un benchmark de código, porque el razonamiento multi-paso amplifica errores que la perplexity media no ve. Desconfía de cualquier claim sub-4-bit que solo reporte perplexity. Como ya dijimos en el post de quantization, la pérdida hay que medirla en la tarea de destino.

Comparabilidad de hardware. Los números de “X veces más rápido” del ternario solo aplican con los kernels especializados (bitnet.cpp) y en el hardware donde la aritmética suma/resta gana de verdad. En una GPU con tensor cores diseñadas para FP16/FP8, un kernel ternario ingenuo puede ser más lento que INT4 bien optimizado, porque desaprovecha el silicio. La ventaja del ternario es real, pero es una ventaja de co-diseño (modelo + kernel + a veces hardware), no un flag que activas sobre tu stack actual. Cualquier benchmark que no especifique el kernel y el hardware exacto es ruido.

Implicaciones para inferencia on-premise

En la RTX 4090 (24 GB, Ada Lovelace): el régimen práctico hoy sigue siendo INT4 AWQ para modelos de 7-14B —resuelto, casi lossless, soportado nativamente—. El 2-bit SOTA (AQLM/QuIP#/QTIP) es viable y permite cargar modelos más grandes o más modelos a la vez, pero exige los kernels específicos de cada método y una calibración cara, y paga calidad. Tiene sentido cuando el cuello es la VRAM y aceptas el trade-off; no como default. El ternario en 4090 es experimental: sin tensor cores diseñadas para suma/resta ternaria, la ventaja de cómputo se diluye, aunque el ahorro de memoria se mantiene.

En un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo): aquí el default es FP8 (calidad casi indistinguible, throughput nativo) o INT4 AWQ para modelos que no caben en FP8. El sub-4-bit SOTA es para servir modelos enormes (200B+) cuando ni FP8 ni INT4 caben con el margen de KV cache que quieres, a costa de calidad y de complejidad de kernel. El ternario nativo, hoy, es objeto de investigación más que de producción: su promesa —tocar ambos techos del roofline— es mayor en CPU/edge (donde no hay tensor cores FP8 que aprovechar) que en un cluster H100, que ya tiene hardware FP8 dedicado.

La regla de pulgar, junio 2026: ≥4-bit es ingeniería resuelta; 2-bit SOTA es una palanca real pero con coste de método y de calidad; ternario es una apuesta de arquitectura, no un ajuste de despliegue.

Ver también

Quantization para inferencia LLM: FP8, INT4, GGUF — la base imprescindible: la matemática del scale+zero-point, GPTQ/AWQ y PTQ vs QAT que aquí se dan por sabidas; este post es su continuación hacia la frontera sub-4-bit.
FP8 end-to-end: pesos, KV y calidad — el otro extremo del espectro, el régimen resuelto del datacenter donde la cuantización ya casi no cuesta calidad.
Knowledge distillation — la palanca complementaria: destilar reduce parámetros, cuantizar reduce bits por parámetro; a 2-bit suelen combinarse para llegar al footprint objetivo.
Poda de modelos LLM — sparsidad y cuantización agresiva son ortogonales y se acumulan: 50 % sparso + 2-bit es otra ruta al mismo footprint que el ternario.
KV cache: la memoria de trabajo — los ~4 GB que reservamos para KV en la cuenta de la 4090 salen de aquí; cuantizar el cache es la otra mitad del presupuesto de memoria.
El roofline invertido de los modelos pequeños — por qué el ternario es especial: ataca a la vez el techo de memoria y el de cómputo, mientras INT4/FP8 solo tocan el de memoria.
Test-time quantization en caliente — cuantizar dinámicamente en inferencia frente a la cuantización estática y calibrada que describen AQLM/QuIP#/QTIP.
Arquitecturas nativas device + MoE de grano fino — el Q4 en device como punto de partida del que el sub-4-bit y el ternario son la siguiente frontera para edge.
QLoRA y multi-LoRA agresivo en SLM — fine-tune sobre una base ya cuantizada; el límite de cuánto puedes comprimir la base antes de que el adapter no pueda recuperar la calidad.

Referencias

Ma, S. et al. The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits (BitNet b1.58). https://arxiv.org/abs/2402.17764
Egiazarian, V., Panferov, A., Kuznedelev, D. et al. Extreme Compression of Large Language Models via Additive Quantization (AQLM). https://arxiv.org/abs/2401.06118
Tseng, A., Chee, J., Sun, Q., Kuleshov, V., De Sa, C. QuIP#: Even Better LLM Quantization with Hadamard Incoherence and Lattice Codebooks. https://arxiv.org/abs/2402.04396
Tseng, A., Sun, Q., Hou, D., De Sa, C. QTIP: Quantization with Trellises and Incoherence Processing. https://arxiv.org/abs/2406.11235
Frantar, E., Ashkboos, S., Hoefler, T., Alistarh, D. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. https://arxiv.org/abs/2210.17323
Lin, J., Tang, J., Tang, H., Yang, S., Dang, X., Han, S. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. https://arxiv.org/abs/2306.00978
Google DeepMind. Gemma 3 QAT (Quantization-Aware Training) models — blog oficial: https://developers.googleblog.com/en/gemma-3-quantized-aware-trained-state-of-the-art-ai-to-consumer-gpus/
Microsoft. bitnet.cpp — kernels de inferencia ternaria 1-bit: https://github.com/microsoft/BitNet

Test-time quantization: cuantizar en caliente sin dataset de calibración

Tue, 09 Jun 2026 02:00:00 +0000

Este post es la continuación natural de Quantization para inferencia LLM, que conviene leer primero: allí están GPTQ, AWQ, el scale + zero-point y por qué los outliers de activación son el problema central. Aquí no discutimos cuántos bits usar, sino cuándo y con qué información se calculan las escalas: offline contra un corpus (PTQ) o en caliente contra el tráfico real (TTQ).

TL;DR

La cuantización activation-aware (AWQ, SmoothQuant) decide qué canales proteger midiendo la magnitud de las activaciones sobre un dataset de calibración en un pase offline, antes de desplegar. El supuesto implícito es que ese corpus representa el tráfico futuro. Pero los outliers de activación —los canales de magnitud 10-100× la mediana que dominan el error de cuantización— dependen del input: cambian con el dominio, el idioma y la distribución del cliente. Cuando el tráfico real se aleja de la calibración, las escalas fijas dejan de ser óptimas y la calidad cae. Test-time quantization (TTQ) elimina el corpus y el pase offline: deriva las escalas activation-aware en tiempo de inferencia, a partir de las activaciones que realmente se observan, por token o por batch. La contrapartida es honesta y no menor: introduce overhead en runtime —calcular estadísticas, detectar outliers, recomputar escalas en cada step— que compite directamente con el ahorro de cuantizar. En modelos pequeños ese overhead pesa proporcionalmente más, porque el forward es corto y los costes fijos por step dominan (el marco está en roofline invertido para SLM). TTQ es ortogonal al formato: no es un competidor de INT4 o FP8, es una forma distinta de derivar s. Compensa cuando no hay pipeline de calibración, cuando la distribución del tráfico es cambiante o desconocida, y en multitenant donde no existe un corpus representativo.

Estás aquí: DEPLOY

La analogía: el sastre que toma medidas frente a las tallas pre-confeccionadas

Una tienda de ropa tiene dos formas de vestir a un cliente.

La primera es vender tallas pre-confeccionadas. La fábrica midió en su día a un “cliente medio” —un maniquí promedio construido sobre una muestra de población— y cortó las prendas según esas medidas. Cuando entra un cliente, le das la talla que más se le acerca. Es rapidísimo: la prenda ya está cosida, solo se entrega. El problema aparece cuando el cliente no se parece al maniquí promedio: si tiene los hombros mucho más anchos que la media —su outlier particular—, la talla estándar le tira o le sobra tela, porque se cortó protegiendo otras zonas. Esto es la PTQ offline calibrada: AWQ midió la importancia de cada canal sobre un corpus y fijó las escalas de una vez; rápido en inferencia, pero ciego al cliente concreto.

La segunda es el sastre que toma medidas en el momento. Cuando entra el cliente, el sastre saca el metro, mide a ese cliente, detecta dónde está su volumen particular y ajusta el corte a su anatomía real. El resultado encaja mejor, sobre todo en los clientes que se salen del molde. Pero cada cliente cuesta tiempo: medir, marcar, decidir. Esto es TTQ: las escalas se derivan en caliente de las activaciones que ese input genera realmente.

La analogía se sostiene en tres detalles:

El maniquí promedio = el dataset de calibración. Si la población que entra a la tienda se parece al maniquí, las tallas funcionan; si no, fallan en los extremos.
Tomar medidas en cada cliente = calcular estadísticas de activación por token/batch. Mejor ajuste, pero un coste fijo que se paga en cada prenda.
Los hombros anchos = los canales outlier de activación. Son precisamente las zonas donde el ajuste importa y donde la talla genérica más se equivoca.

El sastre gana cuando los clientes son variados o desconocidos. Pierde cuando tienes una población homogénea y un maniquí que la representa bien: ahí pagar la medición en cada cliente es tirar el tiempo.

El problema que TTQ resuelve: la calibración fija envejece con el tráfico

Recordemos del post de quantization qué hacen exactamente AWQ y SmoothQuant. No cuantizan todos los canales por igual: identifican el ~1 % de canales cuyas activaciones tienen magnitud grande —los salient channels— y los protegen escalándolos antes de cuantizar. Para medir esa importancia necesitan ver activaciones, y las ven sobre un dataset de calibración (128-512 muestras, típicamente WikiText o un slice del dominio) en un pase offline previo al despliegue.

El supuesto es fuerte: que la distribución de activaciones del corpus de calibración representa la del tráfico de producción. Dos razones por las que ese supuesto se rompe:

Los outliers de activación dependen del input. No son una propiedad fija del modelo como los pesos. El canal que es outlier procesando código C++ puede no serlo procesando árabe conversacional o JSON de logs. La magnitud y la posición de los picos cambian con el dominio, el idioma y el formato de entrada.
El tráfico real rara vez es el corpus. Calibras con WikiText en inglés y el cliente te manda tickets de soporte en español con tablas pegadas. La calibración protegió los canales que WikiText activaba, no los que activa el tráfico real. Las escalas son subóptimas justo donde el cliente vive.

El resultado es degradación dependiente de la distribución: el modelo cuantizado mantiene la calidad mientras el input se parece a la calibración y la pierde a medida que se aleja. El caso más incómodo es el multitenant: si sirves a clientes con dominios distintos desde el mismo modelo cuantizado, no existe un único corpus representativo; cualquier calibración fija favorece a unos tenants y penaliza a otros.

El mecanismo de TTQ: medir las activaciones reales y escalar en caliente

TTQ (arXiv:2603.19296, marzo 2026) propone derivar la cuantización activation-aware en tiempo de inferencia, sin pase offline ni dataset de calibración. La idea, en su forma desnuda y conceptual:

Paso 1 — Observar. Cuando llega el tensor de activaciones X a una capa lineal (por token o por batch), se calculan estadísticas baratas sobre los canales: una medida de tendencia central (mediana o media de magnitud) y una de dispersión por canal. Esto es el equivalente a que AWQ mirase su corpus, pero hecho sobre las activaciones que de verdad están entrando ahora.

Paso 2 — Detectar outliers en caliente. Con esas estadísticas se identifican los canales cuya magnitud se dispara respecto a la mediana del tensor —el criterio típico es un umbral del estilo “magnitud > k × mediana”. Son los canales que, si se cuantizan con la misma escala que el resto, disparan el error.

Paso 3 — Derivar escalas y segregar. Para los canales normales se calcula una escala que aprovecha el rango; para los outliers se aplica un tratamiento distinto —una escala propia, o mantenerlos en precisión más alta— al estilo mixed-precision en caliente. Es la misma filosofía que LLM.int8() (segregar outliers a FP16) o AWQ (escalar salient channels), pero con el umbral y las escalas recalculados sobre el input actual, no congelados desde la calibración.

Paso 4 — Cuantizar y multiplicar. Con las escalas frescas se cuantiza y se ejecuta el GEMM. Las activaciones que entran al siguiente layer compensan el reescalado, igual que en AWQ, para que la matemática se cancele.

La diferencia clave con AWQ no está en qué se hace (proteger outliers de activación) sino en cuándo y contra qué: AWQ lo decide una vez, offline, contra un corpus; TTQ lo decide en cada step, en caliente, contra el tráfico real. Es la traslación a inferencia de la idea de “test-time”: adaptar el cómputo a la muestra concreta que tienes delante en lugar de a un promedio precomputado.

dataset calibración pase OFFLINEfija escalas s, outliers escalas CONGELADAS input parecido → OK input lejano →degradación overhead inferencia ≈ 0 · calidad depende de la calibración

activaciones REALESdel tráfico actual medir + detectaroutliers EN CALIENTE escalas FRESCASpor token / batch cuantizar + GEMM+ overhead por step sin corpus · calidad robusta a la distribución · overhead ≠ 0

Las matemáticas que importan

El error de cuantizar un outlier con la escala equivocada

Recordemos la cuantización uniforme afín del post base: un código entero q = round(x/s) - z con escala s y zero-point z, y reconstrucción x̂ = s·(q + z). Para un cuantizador de b bits con rango simétrico, la escala que cubre un tensor de magnitud máxima M es aproximadamente s = M / (2^{b-1} - 1). El error de redondeo de cada elemento está acotado por media escala: |x - x̂| ≤ s/2.

Aquí está el problema del outlier. La escala s se elige para cubrir el valor más grande del grupo. Si un canal tiene magnitud 30× la mediana y compartes una sola escala con el resto del tensor, esa magnitud manda: M es el outlier, así que s se infla 30× respecto a lo que necesitaría la mayoría. El error absoluto de redondeo de los valores normales sube proporcionalmente.

Cuenta concreta. Tomemos un grupo donde la mediana de magnitudes es 1.0 y un canal outlier vale 30.0, cuantizado a INT4 (b = 4, niveles ±7):

Con escala compartida, s = 30 / 7 ≈ 4.29. El error de redondeo de un valor típico (magnitud ~1) es de hasta s/2 ≈ 2.14. Es decir, el error sobre los valores normales es del orden de su propio valor: el outlier ha destruido la resolución de todo lo demás. Error relativo de un valor de magnitud 1: hasta ~214 %.
Segregando el outlier (lo sacas a FP16 o le das su propia escala) y cuantizando el resto con M = 1, s = 1/7 ≈ 0.143. El error de un valor típico baja a s/2 ≈ 0.071, ~7 % relativo. Treinta veces menos error sobre la mayoría de los pesos del grupo.

Esa es toda la razón de ser de la cuantización activation-aware: detectar y tratar aparte el ~1 % de canales que, de no segregarse, secuestran la escala. AWQ lo hace contra el corpus; TTQ lo hace contra el input real. Y si el canal que es outlier en producción no era outlier en la calibración, AWQ no lo protegió: cuantizó el tráfico real con la escala inflada del caso de arriba. Ahí TTQ gana precisión.

El overhead: el coste de medir en cada step

El precio es simétrico. Calcular las estadísticas por token —magnitudes por canal, mediana o percentil, umbral de outlier, escalas— son reducciones sobre el tensor de activación que no existían en el forward con escalas congeladas. Llamemos:

T = tiempo del forward por token con escalas fijas (PTQ estática), en µs.
Δ = coste extra por token de derivar las estadísticas y escalas en caliente, en µs.

El overhead relativo es simplemente:

$$\text{overhead} = \frac{\Delta}{T}$$

La clave es que Δ es relativamente fijo por step (depende del número de canales y capas, no de cuánto trabajo “útil” haga el modelo), mientras que T escala con el tamaño del modelo. Por eso el cociente se comporta de forma muy distinta según el modelo:

Modelo grande (p. ej. 70B): T es grande —cada forward mueve decenas de GB de pesos desde HBM—. Si Δ ≈ 8 µs y T ≈ 800 µs, el overhead es 8/800 = 1 %. Despreciable frente al ahorro de cuantizar.
SLM (p. ej. 1B): T es pequeño —el forward por token es corto—. Con el mismo Δ ≈ 8 µs y T ≈ 60 µs, el overhead es 8/60 ≈ 13 %. Ya no es despreciable: se come buena parte de lo que ganaste cuantizando.

Esto conecta directamente con el roofline invertido para modelos pequeños: en SLM los costes fijos por step (lanzamiento de kernels, sincronizaciones, overheads que no escalan con el modelo) pesan proporcionalmente más, porque hay menos trabajo útil entre los que repartirlos. El Δ de TTQ es exactamente uno de esos costes fijos. Per-batch en lugar de per-token amortiza Δ entre todos los tokens del batch y baja el overhead relativo, a costa de escalas menos finas; es el primer parámetro a tocar.

La conclusión incómoda: TTQ regala robustez a la distribución pero gasta parte del presupuesto de aceleración en medir, y en el régimen donde la aceleración más escasea —los SLM, los que más se despliegan en el edge— es donde ese gasto más duele. No es gratis; es un cambio de moneda.

Nota de escepticismo metodológico: arXiv:2603.19296 es de marzo de 2026, muy reciente, y a la fecha de este post no hay reproducciones independientes amplias. Las cifras de speedup y de calidad que circulen conviene tomarlas con la misma cautela que cualquier número sin metodología publicada: ¿qué hardware, qué tamaño de batch, qué Δ real medido, contra qué baseline (PTQ bien calibrada o mal calibrada), en qué dominio? El argumento conceptual —robustez a la distribución a cambio de overhead por step— es sólido; los multiplicadores concretos, pendientes de validación.

Qué NO es TTQ: deslindando del resto del zoo

TTQ se confunde fácilmente con técnicas vecinas. La distinción que importa es que TTQ es el cómo derivas las escalas, no el formato ni el momento del entrenamiento.

Técnica	Cuándo se fijan las escalas	Necesita corpus calibración	Toca entrenamiento	Es un formato
PTQ estática (GPTQ, AWQ)	Offline, antes de desplegar	Sí	No	No (usa INT4/INT8)
QAT	Durante el entrenamiento	No (datos de train)	Sí (re-entrena)	No
FP8 end-to-end	En runtime, pero escalas simples por tensor	Mínimo / ninguno	No	Sí (E4M3/E5M2)
TTQ	En runtime, activation-aware por token/batch	No	No	No (ortogonal al formato)

Las cuatro distinciones, una a una:

Frente a PTQ estática (GPTQ/AWQ). Misma meta (proteger outliers), mismo formato posible (INT4), pero PTQ congela las decisiones offline contra un corpus y TTQ las recalcula en caliente. TTQ es, en cierto sentido, “AWQ sin la fase de calibración, pagada en runtime”.
Frente a QAT. QAT mete la cuantización dentro del bucle de entrenamiento para que el modelo aprenda a ser robusto a ella; cuesta re-entrenar. TTQ no toca el entrenamiento: opera sobre un modelo ya entrenado, en inferencia. Son ataques en momentos opuestos del pipeline.
Frente a FP8 end-to-end. FP8 es un formato con su propio rango logarítmico; su “dynamic scaling” calcula un escalar simple por tensor en runtime, pero no hace detección activation-aware de outliers por canal. TTQ podría, conceptualmente, derivar escalas en caliente para un cuantizador FP8 o INT4: es ortogonal al formato.
TTQ es ortogonal al formato. Decide cómo obtener s, no en cuántos bits guardas q. Puedes imaginar “TTQ sobre INT4” o “TTQ sobre FP8”. Lo que define a TTQ es la fuente de la escala —activaciones reales en caliente— no el ancho del código.

Cuándo compensa (y cuándo no)

TTQ no es un reemplazo universal de AWQ. Es una herramienta para un perfil concreto de despliegue. Compensa cuando:

No tienes pipeline de calibración. Quieres desplegar un modelo cuantizado ya, sin montar el dataset de calibración, ejecutar el pase offline ni validar que el corpus representa el tráfico. TTQ recorta esa fase entera: cargas el modelo y sirves.
La distribución del tráfico es cambiante o desconocida. Un asistente que un día recibe código y otro día contratos legales en otro idioma. Ninguna calibración fija cubre bien ambos; la adaptación en caliente sigue la distribución sin re-calibrar.
Multitenant sin corpus representativo. Sirves el mismo modelo a clientes con dominios dispares. No existe un corpus único que represente a todos; cualquier calibración fija crea ganadores y perdedores entre tenants. TTQ ajusta a cada input, sea del tenant que sea.

No compensa cuando:

Tienes un dominio estable y un buen corpus de calibración. Si tu tráfico es homogéneo y representativo, AWQ offline te da la misma calidad con cero overhead en runtime. Pagar Δ en cada token para reaprender lo que un corpus ya capturó es desperdicio.
Sirves SLM con SLA de latencia ajustado. Es justo el caso donde Δ/T es alto. Si el modelo es pequeño y el TPOT importa, el overhead de medir puede borrar la ganancia de cuantizar. Mide tu Δ real antes de asumir que sale a cuenta.
El batch es grande y compute-bound. Con concurrencia alta el forward ya no está memory-bound y el coste de las reducciones extra compite peor; conviene al menos amortizar Δ per-batch.

Implicaciones en hardware on-premise

En una RTX 4090 (24 GB, Ada Lovelace)

El caso natural de la 4090 es el SLM —Qwen 3 1.5B, Llama 3 8B AWQ-INT4— sirviendo a baja concurrencia. Es precisamente el régimen donde TTQ es más arriesgado: T por token es pequeño y la 4090 no tiene FP8 nativo acelerado (lo discutimos en el post de quantization), así que las reducciones extra de TTQ corren en CUDA cores compitiendo por el mismo tiempo. Aquí la pregunta no es “¿mejora la calidad?” sino “¿el overhead me deja un TPOT aceptable?”. Si el tráfico es homogéneo, AWQ offline gana por simplicidad y latencia. TTQ solo justifica su Δ si la distribución de inputs es genuinamente impredecible y la degradación de la calibración fija es medible.

En un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo)

Aquí el cálculo se invierte parcialmente. Con modelos grandes T es alto y el Δ/T baja a la zona de pocos puntos porcentuales, así que el overhead de TTQ es más digerible. El caso de uso fuerte es el multitenant: un cluster que sirve un modelo grande a clientes con dominios heterogéneos, donde no hay un corpus de calibración que contente a todos. Ahí la robustez a la distribución de TTQ tiene valor real y el overhead se diluye en un forward grande. Aun así, sobre H100 con FP8 nativo, el baseline a batir es exigente: FP8 estático casi no pierde calidad (ver tabla del post de quantization) y no cuesta nada en runtime. TTQ tiene que demostrar que su ganancia de robustez en los tenants outlier supera lo que regala en overhead. Con un paper de marzo de 2026 y sin reproducciones, esa demostración está pendiente.

Lo que no hemos cubierto

El coste de memoria de las estadísticas en caliente: buffers por canal, su impacto en el footprint y en la presión de cache.
Interacción con continuous batching: cómo se derivan escalas cuando un batch mezcla requests de dominios distintos en el mismo step.
TTQ + speculative decoding: si el draft y el target derivan escalas en caliente por separado, y cómo afecta eso a la tasa de aceptación.
Estabilidad numérica: qué pasa cuando un batch tiene un outlier extremo puntual que infla la escala de todos los tokens de ese step.

Ver también

Quantization para inferencia LLM — la base imprescindible: scale + zero-point, GPTQ, AWQ y por qué los outliers de activación son el problema; TTQ es AWQ con las escalas derivadas en caliente en vez de offline.
Roofline invertido para modelos pequeños — por qué los costes fijos por step pesan más en SLM; explica directamente por qué el overhead Δ de TTQ duele más en modelos pequeños.
Cuantización agresiva sub-4-bit y ternario — la frontera estática por debajo de 4 bits; complementa a TTQ, que ataca el cómo de la escala en vez del cuántos bits.
QLoRA y multi-LoRA agresivo en SLM — adapters sobre un base cuantizado; el base podría derivar escalas en caliente mientras los adapters van en BF16.
FP8 end-to-end: pesos, KV y calidad — el formato del datacenter Hopper/Blackwell; TTQ es ortogonal y podría derivar escalas para un cuantizador FP8.
KV cache: la memoria de trabajo de la inferencia LLM — el KV cache también se cuantiza; sus escalas son otro candidato a derivarse en caliente por la misma lógica.
Knowledge distillation — la otra vía para servir modelos pequeños robustos; destilar reduce el modelo, TTQ ajusta su cuantización al tráfico.
Optimizando el decode en vLLM — donde se materializan en parámetros las palancas de cuantización en runtime para exprimir una 4090.

Referencias

TTQ: Activation-Aware Test-Time Quantization to Accelerate LLM Inference On The Fly (marzo 2026). https://arxiv.org/abs/2603.19296
Lin, J., Tang, J., Tang, H., Yang, S., Dang, X., Han, S. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (MLSys 2024). https://arxiv.org/abs/2306.00978
Frantar, E., Ashkboos, S., Hoefler, T., Alistarh, D. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers (ICLR 2023). https://arxiv.org/abs/2210.17323
Xiao, G., Lin, J., Seznec, M., Wu, H., Demouth, J., Han, S. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models (ICML 2023). https://arxiv.org/abs/2211.10438
Dettmers, T., Lewis, M., Belkada, Y., Zettlemoyer, L. LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale (NeurIPS 2022). https://arxiv.org/abs/2208.07339