Slm on lo0 — Blog Técnico

QLoRA y multi-LoRA al límite en modelos pequeños

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

Este post es el complemento de entrenamiento de Multi-LoRA serving. Aquel desmonta el consumidor —cómo se sirven cientos de adapters concurrentes con kernels SGMV y unified paging—; este desmonta el productor —cómo se entrena un adapter sobre un base cuantizado en una sola GPU, y por qué el patrón “un SLM base congelado + N adapters de rank bajo” es el encaje natural de los modelos pequeños. Aquí no repetimos los internals del serving; los damos por leídos.

TL;DR

QLoRA (Dettmers et al., NeurIPS 2023) resuelve un problema concreto: fine-tunear un modelo sin tener la VRAM para cargar sus pesos en BF16, sus gradientes y los estados del optimizador. La idea tiene tres piezas. Una: congelar el base y cuantizarlo a 4-bit con un formato nuevo, NF4 (NormalFloat 4-bit), cuantil-óptimo para pesos que se distribuyen casi como una gaussiana. Dos: no entrenar el base —ni un solo peso suyo se mueve—, sino un par de matrices LoRA pequeñas en BF16 enchufadas en paralelo; el gradiente fluye únicamente por ese adapter. Tres: dos trucos de memoria, la doble cuantización (cuantizar las propias constantes de cuantización) y los paged optimizers (estados del optimizador que se paginan a RAM cuando la VRAM aprieta). El resultado operacional medible: un SLM de 3-8B se fine-tunea en una RTX 4090 (24 GB, Ada Lovelace), no en un cluster. Y como el producto del entrenamiento es un adapter de megabytes, no gigabytes, el patrón que emerge es un único SLM base congelado en 4-bit más N adapters —uno por cliente, dominio o tarea—, servidos sobre la base compartida con el stack que ya cubrimos en multi-LoRA serving. Aislamiento por cliente, footprint mínimo, despliegue soberano.

La analogía: la guitarra congelada y la pedalera intercambiable

Piensa en un guitarrista de estudio que graba para clientes muy distintos: un disco de jazz, una sintonía corporativa, un tema de metal. Tiene una sola guitarra —su instrumento de confianza, afinado, con un sonido base que conoce de memoria—. Lo que no hace es comprarse una guitarra nueva para cada canción. Lo que hace es tener una pedalera de efectos: un pedal de distorsión, uno de chorus, uno de delay. Para cada tema enchufa el pedal que toca, y la misma guitarra suena completamente distinta.

El mapeo es exacto:

La guitarra = el SLM base. Una sola copia, afinada de fábrica, congelada. En QLoRA, además, está guardada en una funda comprimida: cuantizada a 4-bit. No la tocas: ni cambias sus pastillas ni reajustas el mástil. Pesa lo que pesa y ahí se queda.
Cada pedal = un adapter LoRA. Pequeño, barato, específico de un sonido. Lo entrenas para una tarea y lo guardas en un cajón.
Entrenar QLoRA = diseñar un pedal nuevo escuchando la guitarra (congelada) a través de él, ajustando solo los potenciómetros del pedal hasta que suene como quieres. El sonido base de la guitarra no se modifica; aprendes la corrección que el pedal aplica encima.
Servir multi-LoRA (Multi-LoRA serving) = tener toda la pedalera montada en el escenario y elegir el pedal correcto por nota —por request—. La guitarra es la misma; lo que cambia entre requests es qué pedal está activo.

La analogía aguanta hasta el detalle que más confunde: el gradiente del entrenamiento solo “toca” el pedal. La guitarra está congelada en su funda comprimida; el aprendizaje no la mueve. Eso es lo que permite que el base viva en 4-bit durante todo el fine-tuning sin que la cuantización estorbe: nunca se le calcula gradiente.

El mecanismo desnudo: LoRA, y por qué se puede entrenar sobre un base 4-bit

Recordatorio mínimo de LoRA (Hu et al., ICLR 2022). Un adapter modifica una matriz W del base sumándole un producto de bajo rango:

$$W’ = W + B A, \qquad A \in \mathbb{R}^{r \times d}, \quad B \in \mathbb{R}^{d \times r}$$

con r el rank, mucho menor que d. En el forward pass no se materializa BA; se calcula:

$$y = W x + B(A x)$$

El cómputo del base (Wx) ocurre igual; el adapter añade dos matmuls baratos. La clave de QLoRA está en quién recibe gradiente. El base W está congelado: ∂L/∂W no se calcula ni se almacena. Solo A y B son entrenables. Por eso W puede vivir cuantizado a 4-bit sin problema: en el forward se deshace la cuantización al vuelo para hacer Wx (dequant → matmul en BF16), pero como W nunca se actualiza, no necesita la precisión de un peso entrenable. El adapter A, B sí está en BF16, y es el único camino por el que fluye el gradiente.

Esto es lo que rompe el muro de memoria. En un fine-tuning completo necesitas, por cada peso: el peso (2 bytes BF16), su gradiente (2 bytes), y los dos estados de Adam (momento y varianza, típicamente 4+4 bytes en FP32) — del orden de 12-16 bytes por parámetro entrenable. Con QLoRA, los pesos del base ocupan 0.5 bytes (4-bit) y no tienen ni gradiente ni estados de optimizador. Solo los pocos millones de parámetros del adapter pagan el coste de 16 bytes. Para un 8B, eso es la diferencia entre ~130 GB y caber en 24 GB.

NF4: por qué un formato nuevo en lugar de INT4

QLoRA no usa INT4 lineal para el base, sino NF4 (NormalFloat 4-bit). La intuición: los pesos de un transformer entrenado se distribuyen, empíricamente, muy cerca de una gaussiana centrada en cero. INT4 reparte sus 16 niveles de forma uniforme en el rango, lo que desperdicia niveles en las colas (donde casi no hay pesos) y deja pocos en el centro (donde se amontonan). NF4 reparte los 16 niveles según los cuantiles de una normal: más niveles donde hay más masa de probabilidad. Es, por construcción, information-theoretically optimal para datos exactamente gaussianos —cada nivel cubre aproximadamente la misma cantidad de pesos—. Además es simétrico respecto al cero y garantiza una representación exacta del 0 (importante para sparsity y padding). El detalle de los formatos de cuantización está en Quantization para inferencia LLM; aquí basta con la idea de que NF4 gasta sus bits donde están los pesos.

Doble cuantización y paged optimizers

Cuantizar a 4-bit no es gratis del todo: necesitas guardar, por cada bloque de pesos (típicamente 64), una constante de escala en FP32 para poder deshacer la cuantización. Esas constantes pesan. Con bloques de 64 y una escala FP32 (32 bits) por bloque, son 32/64 = 0.5 bits por parámetro solo en metadatos — un 12.5 % de overhead sobre los 4 bits útiles. La doble cuantización ataca eso: cuantiza las propias constantes de escala (a 8-bit, en bloques de 256), bajando el overhead a ~0.127 bits/param. Cuantizar la cuantización suena recursivo y lo es; el ahorro es pequeño en términos absolutos (~0.37 bits/param) pero en un 8B son cientos de MB, que es exactamente el margen que separa “cabe” de “no cabe” en una 4090.

Los paged optimizers atacan los picos de memoria. Durante el entrenamiento, ciertos momentos —un batch con secuencia muy larga, una activación grande— hacen que la VRAM se acerque al límite y reviente con un OOM. La idea, prestada del paging de los sistemas operativos, es alojar los estados del optimizador en memoria unificada NVIDIA: cuando la VRAM aprieta, esas páginas se expulsan a la RAM del host automáticamente y se traen de vuelta cuando hacen falta. No acelera nada; evita el crash en los picos. Convierte un “OOM intermitente” en “un poco más lento en los peores momentos”, que para un entrenamiento desatendido en una sola GPU es la diferencia entre terminar y no terminar.

Forward (azul) hacia delante · Gradiente (rojo) solo por el adapter

x entrada W · x (base congelado) NF4 4-bit · dequant al vuelo · SIN gradiente Adapter LoRA (BF16) A: r×d shrink d→r B: d×r expand r→d + suma y salida ∂L/∂A , ∂L/∂B — el gradiente solo entra al adapter el base NO recibe gradiente: por eso puede vivir en 4-bit

Entrenamiento “agresivo”: rank muy bajo y QA-LoRA

“Agresivo” en este contexto significa dos cosas, a veces combinadas.

Rank muy bajo (r = 4-8). El rank es el cuello de la corrección: cuánta “capacidad” tiene el adapter para desviar al base. Un rank alto (64, 128) acerca el adapter a un fine-tuning completo pero pesa más y tarda más en entrenar. Para un SLM adaptado a una tarea estrecha y bien definida —un formato de salida, un dominio léxico, un estilo de respuesta—, un rank de 4-8 suele bastar, y el adapter resultante pesa una fracción. El riesgo del rank bajo es el underfitting: si la tarea exige reescribir mucho comportamiento del base, r=4 se queda corto. La regla honesta es empírica: sube el rank solo si el eval lo pide, no “por si acaso”. En SLMs pequeños, donde la base tiene menos capacidad de sobra, el rank bajo tiende a funcionar mejor proporcionalmente que en modelos grandes, pero esto depende de la tarea y hay que medirlo, no asumirlo.

QA-LoRA (quantization-aware LoRA, Xu et al., arXiv:2309.14717). Hay una fricción sutil en QLoRA estándar: entrenas el adapter en BF16 contra un base 4-bit, pero si luego quieres fusionar el adapter en el base (W' = W + BA) para servir un modelo cuantizado limpio, la fusión reintroduce precisión que el formato 4-bit no puede representar, y al recuantizar pierdes parte de lo aprendido. QA-LoRA entrena el adapter siendo consciente de la cuantización del destino: equilibra los grados de libertad de la cuantización y de la adaptación (con cuantización por grupos) de modo que, al terminar, el adapter se fusiona limpio en un base cuantizado sin un paso de recuantización que degrade. El resultado es un modelo final cuantizado-más-adaptado, sin adapter separado en runtime, útil cuando quieres un único artefacto desplegable por tarea en lugar del patrón base-compartido + adapters. La elección entre “QLoRA + servir multi-adapter” y “QA-LoRA + fusionar por tarea” es una decisión de arquitectura de despliegue, no de calidad pura.

La matemática que importa

Tres cuentas mueven cualquier decisión con QLoRA sobre SLMs.

Parámetros del adapter. Para cada matriz objetivo de dimensión d con rank r, el adapter aporta A (r×d) más B (d×r), es decir 2·r·d parámetros. Sumando sobre las matrices objetivo y multiplicando por el número de capas:

$$\text{params}{\text{adapter}} = L \cdot \sum{\text{matrices}} 2 \cdot r \cdot d$$

Ejemplo trabajado — Llama-3-8B, atención (q, k, v, o), d = 4096, L = 32 capas, r = 8. Tomando las cuatro proyecciones de atención con la misma d = 4096 (simplificación; en Llama-3 K y V son más estrechas por GQA, lo que da menos params aún):

$$\text{params} \approx 32 \cdot 4 \cdot (2 \cdot 8 \cdot 4096) = 32 \cdot 4 \cdot 65,536 \approx 8.4\text{M params}$$

En BF16 (2 bytes/param): 8.4M · 2 ≈ 16.8 MB ≈ ~17 MB. Diecisiete megabytes. Compáralo con el base: un 8B en NF4 ocupa 8\text{G} · 0.5\,\text{bytes} ≈ 4\text{ GB} (más el pequeño overhead de constantes tras doble cuantización). El adapter es el 0.4 % del tamaño del base cuantizado. Esto es lo que hace operacionalmente trivial tener cientos: un adapter no es un modelo, es casi un fichero de configuración pesado.

¿Cuántos adapters caben en una 4090 tras el base + KV? Presupuesto de una RTX 4090 (24 GB): base 8B NF4 ~4 GB, dejemos ~5 GB para KV cache y activaciones de inferencia con concurrencia moderada → quedan ~15 GB libres (siendo conservadores, llamémoslos ~12-15 GB). Con adapters de ~17 MB (r=8, attention-only):

$$\frac{15,000\ \text{MB}}{17\ \text{MB/adapter}} \approx 880 \text{ adapters}$$

Del orden de miles si bajas el KV cache reservado o usas rank 4 (~8.5 MB/adapter → ~1750 en 15 GB). El cuello de botella nunca es el espacio de los adapters; es el KV cache y la concurrencia. Para los detalles de cómo se sirven concurrentemente esos miles —el batching heterogéneo, el unified paging, los kernels SGMV— ver Multi-LoRA serving. El resumen relevante aquí: el compute del adapter es casi gratis (rango bajo, dos matmuls finos); el reto de rendimiento del serving no es ese compute sino el gather/scatter de los adapters correctos por fila del batch cuando un mismo batch mezcla requests de adapters distintos. Eso es problema del consumidor, no del productor.

VRAM de entrenamiento QLoRA en 24 GB. El presupuesto aproximado para fine-tunear el 8B en una 4090:

Componente	VRAM aprox.
Base 8B en NF4 (pesos congelados)	~4.0 GB
Adapter (params BF16 + gradiente + estados Adam, ~16 B/param sobre ~8-40M params)	~0.3-0.7 GB
Activaciones (depende de batch y longitud de secuencia; el grueso variable)	~6-14 GB
Buffers de dequant, escalas, workspace	~1-2 GB
Total	cabe en 24 GB con margen

La pieza grande y variable son las activaciones, que escalan con batch × longitud de secuencia. Por eso el QLoRA real en una 4090 se hace con batch pequeño + gradient accumulation (simular batch grande acumulando gradientes de microbatches) + gradient checkpointing (recomputar activaciones en backward en lugar de guardarlas, cambiando compute por memoria) + secuencias acotadas. Los paged optimizers son el airbag para los picos de activación que, sin ellos, reventarían. La afirmación “QLoRA fine-tunea un 8B en una 4090” es cierta con esa configuración; sin gradient checkpointing y con secuencias largas y batch grande, no cabe. Como con cualquier número, la metodología importa más que el titular.

Batch heterogéneo: 4 requests, 3 clientes, 3 adapters — un solo SLM base compartido

req_1 → cliente A req_2 → cliente A req_3 → cliente B req_4 → cliente C SLM BASE — Llama-3-8B NF4 (~4 GB) — cargado UNA vez, compartido W·x se calcula igual para los 4 requests, sin importar el adapter

Pedalera (adapters ~17 MB) adapter A (cliente A) adapter B (cliente B) adapter C (cliente C) … miles más, MB cada uno

El delta del adapter se aplica por fila del batch: reqs 1-2 → adapter A · req 3 → adapter B · req 4 → adapter C El reto NO es el compute del delta (casi gratis) — es el gather/scatter heterogéneo. Internals (SGMV, unified paging, batching heterogéneo): ver Multi-LoRA serving.

El encaje con modelos pequeños y la soberanía

Aquí es donde QLoRA + SLM deja de ser un truco de VRAM y se vuelve un patrón de arquitectura.

Un SLM (3-8B) ya cabe holgado en una sola GPU para inferencia. Si encima el base vive en 4-bit (~4 GB para un 8B), te sobra memoria. Lo que QLoRA habilita es que ese mismo equipo —la 4090— sea tanto el productor como el consumidor: entrenas el adapter de un cliente nuevo en horas, en la misma clase de hardware donde luego lo sirves. El artefacto que circula entre “entrenar” y “desplegar” es un adapter de MB, no GB: se versiona, se firma, se mueve por la red, se almacena en MinIO/S3 sin pensar en el coste.

El patrón soberano se cae por su propio peso:

Aislamiento por cliente. Cada cliente tiene su adapter, entrenado solo con sus datos. El base es genérico y compartido; lo específico del cliente vive aislado en su par (A, B). Borrar un cliente es borrar un fichero de MB, no reentrenar nada.
Footprint mínimo. Un base + N adapters cabe donde N bases no cabrían ni de lejos. La economía de “un modelo por cliente” (decenas de GB cada uno) es prohibitiva; la de “un base + adapters” (MB cada uno) es trivial. Es exactamente la diferencia entre la pedalera y comprar una guitarra por canción.
Despliegue soberano. Todo cabe on-premise, en tu hardware, sin sacar un dato del perímetro. El entrenamiento (QLoRA en la 4090) y el serving (multi-LoRA sobre el mismo base) viven dentro. No hay dependencia de una API externa para fine-tunear ni para servir.

La elección de adaptar por dominio (un adapter por área de conocimiento) frente a recuperar por contexto (RAG que inyecta el conocimiento en el prompt) es real y no excluyente: el adapter cambia el comportamiento y el estilo del modelo, el RAG cambia los hechos a los que accede. Lo trabaja el post hermano de RAG agresivo en modelos pequeños de esta serie; la regla corta es: adapta lo que es estable y conductual, recupera lo que es volátil y factual.

Aplicado a la infraestructura on-premise

En una RTX 4090 (24 GB, Ada Lovelace)

Es el banco de trabajo natural de QLoRA. Caso canónico: base SLM 3-8B en NF4, fine-tuning de un adapter r=8 attention-only, con gradient checkpointing + gradient accumulation + paged optimizer. Entrena en horas para datasets de tarea estrecha (miles a decenas de miles de ejemplos), y el mismo equipo sirve después el base + decenas o cientos de adapters para demos multi-tenant y prototipos de plataforma. La 4090 es donde QLoRA pasó de “técnica de paper” a “lo puede hacer cualquiera con una GPU de consumo”, y ese es exactamente su valor. La regla honesta: cabe con la configuración de memoria descrita; con secuencias largas, batch grande o rank alto, sube el hardware.

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

Aquí QLoRA deja de ser estrictamente necesario para caber —un 8B en BF16 entra de sobra— pero sigue siendo útil por otra razón: paralelizar la producción de adapters. Con 320 GB y FP8 nativo puedes entrenar varios adapters a la vez (un job por cliente, varios en paralelo), o fine-tunear modelos algo mayores con QLoRA sin TP. El consumidor en este cluster es el setup serio de Multi-LoRA serving: base FP8 + cientos de adapters concurrentes. La regla de pulgar: en la 4090, QLoRA es la herramienta para poder fine-tunear; en el cluster H100, es la herramienta para fine-tunear muchos a la vez, barato, manteniendo el formato cuantizado consistente entre entrenamiento y serving.

Lo que no hemos cubierto

Los internals del serving heterogéneo (kernels SGMV, MBGMM/MBGMV, unified paging, cold start, eviction): están enteros en Multi-LoRA serving. Este post es deliberadamente el lado del productor.
DoRA y variantes (descomposición magnitud-dirección): cierran parte del gap con el full fine-tuning; patrón de entrenamiento distinto, patrón de serving idéntico.
Cuantización sub-4-bit y ternaria del base: qué pasa cuando el base baja de NF4 a 2-bit o ternario bajo el adapter; lo trabaja el post hermano de la serie.
Recolección del dataset de fine-tuning: cómo se construye el corpus de cada adapter a partir de feedback de producción está en Retrain: cerrar el bucle.

Ver también

Multi-LoRA serving — el consumidor: los internals de cómo se sirven miles de adapters concurrentes (SGMV, unified paging, batching heterogéneo). Léelo: este post da por sabido todo lo de serving.
Quantization para inferencia LLM — el marco de formatos (NF4, INT4, FP8, AWQ) que sostiene el base cuantizado bajo el adapter.
Knowledge distillation — la alternativa/complemento a adaptar: comprimir el conocimiento en el propio modelo en lugar de en un adapter encima.
Fine-tuning continuo en producción — el ciclo operacional que produce adapters nuevos de forma continua a partir de señal de producción.
Retrain: cerrar el bucle feedback → dataset → adapter — de dónde sale el dataset con el que se entrena cada adapter QLoRA.
Roofline invertido en modelos pequeños (hermano de la serie) — el régimen de rendimiento donde un SLM se mueve, que explica por qué el footprint mínimo del adapter encaja con GPUs de consumo.
Cuantización agresiva sub-4-bit / ternaria (hermano de la serie) — qué pasa con el base cuantizado por debajo de NF4 bajo el adapter.
RAG agresivo en modelos pequeños (hermano de la serie) — adaptar por dominio (este post) frente a recuperar por contexto; cuándo cada uno.

Referencias

Dettmers, T., Pagnoni, A., Holtzman, A., Zettlemoyer, L. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023. https://arxiv.org/abs/2305.14314
Hu, E., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., Chen, W. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. https://arxiv.org/abs/2106.09685
Xu, Y., Xie, L., Gu, X., Chen, X., Chang, H., Zhang, H., Chen, Z., Zhang, X., Tian, Q. QA-LoRA: Quantization-Aware Low-Rank Adaptation of Large Language Models. ICLR 2024. https://arxiv.org/abs/2309.14717
Sheng, Y. et al. S-LoRA: Serving Thousands of Concurrent LoRA Adapters. MLSys 2024. https://arxiv.org/abs/2311.03285
Chen, L. et al. Punica: Multi-Tenant LoRA Serving. MLSys 2024. https://arxiv.org/abs/2310.18547
Repo oficial QLoRA / bitsandbytes: https://github.com/artidoro/qlora
Hugging Face PEFT (LoRA, QLoRA): https://github.com/huggingface/peft

RAG agresivo en modelos pequeños: compensar parámetros con recuperación

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

Este post pertenece a la serie sobre rendimiento de inferencia en modelos pequeños. Su pieza hermana, El roofline se invierte en modelos pequeños, explica por qué el prefill compute-bound es el cuello de botella que aquí da forma a toda la discusión. Conviene leerlo antes: aquí asumimos que meter más contexto no es gratis.

TL;DR

Un SLM (digamos 1B–8B de parámetros) sabe menos hechos que un modelo de 70B–700B, simplemente porque tiene menos pesos donde memorizarlos. Pero su capacidad de razonar sobre texto que tiene delante —seguir instrucciones, extraer, sintetizar, comparar— se degrada mucho menos con el tamaño que su conocimiento enciclopédico. La consecuencia operacional es directa: usa el SLM como motor de razonamiento sobre contexto curado, no como base de datos. Mueve el conocimiento de los pesos al contexto vía recuperación. El problema es que “recuperación agresiva” se interpreta a menudo como “meter muchos chunks”, y eso choca de frente con tres hechos sobre los SLM: ventanas de contexto más cortas, peor aprovechamiento del contexto largo (el efecto lost in the middle es más severo cuanto más pequeño el modelo) y un prefill compute-bound cuyo coste crece con la longitud del contexto $C$ —lineal en las proyecciones, cuadrático en la atención—. No puedes simplemente añadir tokens. La salida no es recuperar menos, sino recuperar mejor: reranking de precisión sobre recall, compresión de contexto antes de inyectarlo, prefix caching de los documentos estables, caché semántico de respuestas y structured output con herramientas externas que sustituyen al conocimiento interno. Este post trabaja las matemáticas y da un número de TTFT antes y después de comprimir un contexto de 4000 a 1000 tokens en una RTX 4090.

La analogía: el examen a libro abierto

Dos estudiantes se presentan al mismo examen. El primero tiene una memoria prodigiosa: ha memorizado el temario entero, párrafo a párrafo. El segundo tiene una memoria normal —olvida fechas, confunde nombres— pero le permiten entrar con una chuleta.

Si la chuleta del segundo estudiante es un caos de fotocopias amontonadas, pierde: tarda en encontrar lo que busca, se distrae con páginas irrelevantes y se le acaba el tiempo. Pero si su chuleta es excelente —recortada a lo esencial, reordenada por relevancia, con lo importante arriba y sin paja—, entonces no solo no pierde: a menudo gana, porque razona igual de bien que el primero y además trabaja sobre material verificado en lugar de sobre recuerdos borrosos que puede estar inventando.

La moraleja tiene tres capas, y cada una mapea a una decisión de ingeniería:

Memorizarlo todo es caro. El primer estudiante invirtió meses. Un modelo grande invierte parámetros —y VRAM, y FLOPs de inferencia— en memorizar hechos.
La chuleta importa más que su tamaño. Una chuleta de una página bien hecha bate a diez páginas mal organizadas. Más contexto recuperado no es mejor contexto: la precisión del material gana al volumen.
Saber buscar y sintetizar es una habilidad distinta de saber. Es la que el SLM conserva. La estrategia entera consiste en apoyarse en esa habilidad y subcontratar la memoria.

El resto del post es, esencialmente, cómo construir una chuleta excelente bajo la restricción de que el estudiante (el SLM) lee despacio y se cansa con los textos largos.

El argumento de capacidad: cuántos hechos caben en los pesos

Empecemos por justificar la tesis con orden de magnitud, no con fe. ¿Cuánto conocimiento factual cabe realmente en los pesos de un modelo?

Hay una estimación empírica recurrente en la literatura de interpretabilidad y memorización: un modelo denso es capaz de almacenar del orden de 2 bits de información memorizada por parámetro antes de saturar (la cifra exacta varía según el estudio y el régimen de entrenamiento; tómese como orden de magnitud, no como ley). Un modelo de 8B parámetros tiene entonces un techo de almacenamiento de información del orden de:

$$8 \times 10^9 \text{ params} \times 2 \text{ bits/param} = 1.6 \times 10^{10} \text{ bits} \approx 2 \text{ GB de información}$$

Y ese presupuesto no es solo para hechos: la inmensa mayoría se gasta en gramática, sintaxis, capacidad de razonamiento, código, formato, y solo una fracción queda para conocimiento enciclopédico. Compáralo con el otro lado: un corpus recuperable de varios millones de documentos —una wiki corporativa, un repositorio documental, una base de conocimiento técnica— ocupa fácilmente cientos de GB a terabytes de texto, indexado y consultable con latencia de milisegundos. La asimetría es de dos o tres órdenes de magnitud a favor del corpus externo.

La conclusión no es que los pesos sean inútiles —son donde vive el razonamiento, que es lo caro de replicar— sino que competir con un índice externo por capacidad de hechos es perder por construcción. Un modelo de 70B tiene ~9× más presupuesto de memorización que uno de 8B, pero sigue siendo despreciable frente al corpus. Por eso el modelo grande también hace RAG en producción. La diferencia es que el SLM lo necesita: sin recuperación, su conocimiento factual es demasiado escaso y, peor, propenso a alucinar justo en los huecos que no memorizó.

En los pesos (memorizado) ~2 GB de info útil en 8B fijo, caro de actualizar, alucina en huecos

En el contexto (recuperado) cientos de GB – TB indexados fresco, citable, verificable, sin reentrenar

El SLM como motor de razonamiento razona sobre el contexto curado no es la base de datos: es quien la lee y sintetiza

La tensión central: recuperar más no es meter más

Aquí es donde la mayoría de los diseños ingenuos se rompen. “Recuperación agresiva” suena a top-k grande: si recuperar ayuda, recupera 20 chunks en vez de 5. Pero en un SLM eso falla por dos razones independientes, una de calidad y otra de coste.

(a) Los SLM usan peor el contexto largo

El efecto lost in the middle (Liu et al., 2023) es bien conocido: los LLM recuperan mejor la información situada al principio y al final del contexto, y peor la del medio. Lo que se enfatiza menos es que el efecto es más severo cuanto más pequeño el modelo. Un SLM tiene menos cabezas de atención, menos capas y representaciones internas más pobres para “rastrear” un hecho relevante enterrado en la posición 14 de 20 chunks. Además, su ventana de contexto nominal suele ser más corta (4K–32K frente a los 128K+ de los grandes), y la ventana efectiva —la longitud a partir de la cual la calidad se desploma— es todavía menor. Meter 20 chunks no significa que el modelo los lea los 20: significa que probablemente ignore o malinterprete los del medio, mientras paga el coste de todos.

(b) El prefill crece con el contexto y es compute-bound

Este es el golpe que la gente subestima. El prefill —procesar el prompt completo antes de emitir el primer token— es la fase compute-bound de la inferencia (a diferencia del decode, memory-bound; el detalle vive en El roofline se invierte). Su coste crece con la longitud del contexto $C$, y determina el TTFT (time to first token). Más chunks → más tokens de prefill → más TTFT y más coste de cómputo por petición. En un SLM, donde el prefill es proporcionalmente más caro respecto al modelo, esto duele especialmente.

La conclusión operacional es incómoda pero clara: no puedes compensar menos parámetros simplemente metiendo más contexto. Cada token recuperado se paga dos veces —en calidad degradada y en TTFT— y el SLM es el peor situado para absorber ambos costes. La salida es recuperar menos pero mejor, y comprimir lo que recuperas.

Las matemáticas del prefill

Pongamos números a “el prefill crece con el contexto”. Para un contexto de $C$ tokens, una capa transformer hace dos clases de trabajo:

Proyecciones lineales (QKV, salida de atención, FFN): cada token se multiplica por matrices de pesos de tamaño fijo. El coste es $O(C)$ en FLOPs —lineal en el número de tokens.
Atención ($QK^\top$ y la multiplicación por $V$): cada token atiende a todos los demás. El coste es $O(C^2)$ —cuadrático en el número de tokens.

El coste total de prefill por capa es de la forma:

$$\text{FLOPs}{\text{prefill}} \approx \underbrace{a \cdot C}{\text{proyecciones}} + \underbrace{b \cdot C^2}_{\text{atención}}$$

con $a$ y $b$ constantes que dependen de la dimensión del modelo. Para contextos moderados (unos pocos miles de tokens) en un SLM, el término lineal aún domina o es comparable al cuadrático; el término cuadrático se vuelve dominante a contextos largos. Lo relevante: si comprimes el contexto $C \to C/k$, el término lineal cae $\times k$ y el cuadrático cae $\times k^2$. Comprimir es la única palanca que ataca ambos términos a la vez, y ataca el peor de forma desproporcionada.

Ejemplo numérico: TTFT antes y después de comprimir, RTX 4090

Modelemos el TTFT como el tiempo de procesar los tokens de prefill a un throughput de prefill dado. Tomemos una RTX 4090 (24 GB, Ada Lovelace) sirviendo un SLM cuantizado, con un throughput de prefill de ~5000 tok/s (cifra ilustrativa; el valor real depende del modelo, la cuantización y el batch —mídelo, no lo asumas).

Sea un contexto recuperado de 4000 tokens (8 chunks de ~500 tokens). Aproximando el TTFT como dominado por el prefill del contexto:

$$\text{TTFT}_{\text{antes}} \approx \frac{4000 \text{ tok}}{5000 \text{ tok/s}} = 0.80 \text{ s}$$

Ahora comprimimos ese contexto a 1000 tokens ($k = 4$). El throughput de prefill no es constante con $C$ —baja un poco a contextos largos por el término cuadrático— pero, tomando la aproximación lineal conservadora de tokens/throughput:

$$\text{TTFT}_{\text{después}} \approx \frac{1000 \text{ tok}}{5000 \text{ tok/s}} = 0.20 \text{ s}$$

El TTFT cae de 0.80 s a 0.20 s, una reducción de $4\times$ en la parte lineal. Pero la cuenta de FLOPs es más favorable todavía en la componente de atención: esa parte del trabajo cae $\sim k^2 = 16\times$. En la práctica el TTFT total no cae 16× porque el coste no es puramente cuadrático a esta escala, pero la reducción real está entre 4× y un valor mayor según cuánto pesara la atención, y el ahorro de cómputo agregado (lo que paga la factura eléctrica y libera la GPU para otra petición) es sustancialmente mayor que el simple 4× del recuento de tokens.

El argumento se generaliza: comprimir el contexto un factor $k$ reduce el TTFT al menos $\sim k\times$ y el coste de atención $\sim k^2\times$. Para un SLM, donde el TTFT es a menudo el SLA que importa, esto es la diferencia entre un asistente que responde al instante y uno que se siente lento.

Las cinco palancas para resolver la tensión

La estrategia no es “recuperar menos y conformarse”. Es recuperar agresivamente del índice y luego destilar agresivamente lo recuperado antes de que llegue al SLM. Cinco palancas, en orden de aplicación dentro del pipeline.

1. Reranking agresivo: precisión sobre recall

El retriever inicial (denso, sparse o híbrido) optimiza recall: trae 50–100 candidatos para no dejarse nada fuera. El reranker —un cross-encoder que ve la query y el documento juntos— optimiza precisión: reordena esos candidatos y te quedas con los 3–5 mejores. Para un SLM esto no es un lujo, es estructural: como el modelo usa mal el contexto largo, cada chunk que entra debe ganarse su sitio. Mejor 4 chunks de altísima relevancia que 15 mediocres. El detalle de retrieval híbrido y reranking está en Reranking e hybrid retrieval; aquí basta con la regla: maximiza recall en el retriever, maximiza precisión en el reranker, e inyecta pocos.

2. Compresión de contexto: destilar la chuleta

Una vez tienes los mejores chunks, todavía contienen paja —frases de relleno, redundancia, contexto irrelevante a la query concreta. La compresión de contexto los recorta antes de inyectarlos:

Compresión extractiva (estilo LLMLingua / LongLLMLingua, Jiang et al. 2023): un modelo pequeño puntúa la perplejidad o relevancia de cada token/frase respecto a la query y elimina los de baja información, quedándose con el subconjunto extractivo más denso. Reduce tokens sin un segundo modelo generativo grande de por medio. LongLLMLingua añade reordenación consciente de la posición para mitigar lost in the middle.
Compresión abstractiva: un modelo resume los chunks recuperados en un texto más corto. Más agresiva en reducción de tokens, pero introduce un paso generativo (coste y posible pérdida de fidelidad).
Soft prompts / context distillation: comprimir el contexto recuperado no a texto, sino a un puñado de embeddings/soft tokens que el modelo consume directamente. Reduce el número de tokens de prefill al mínimo, a costa de un componente entrenado y específico del modelo.

El punto clave conecta con las matemáticas de arriba: comprimir lo recuperado un factor $k$ reduce los tokens de prefill $\times k$, y por tanto el TTFT $\sim\times k$ y el coste de atención $\sim\times k^2$. Es la palanca con mejor retorno cuando el contexto largo es el cuello de botella.

3. Prefix caching del contexto estable

No todo el contexto cambia entre peticiones. Instrucciones de sistema, definiciones, documentos de referencia recurrentes, esquemas: son prefijos estables. El prefix caching guarda el KV cache ya computado de esos prefijos y lo reutiliza, de modo que el prefill solo procesa la parte nueva (la query y los chunks específicos). Si el 60 % de tu contexto es estable, te ahorras el 60 % del prefill de ese segmento en cada hit. Para que funcione, el contexto estable debe ir al principio del prompt (el KV cache es prefijo-dependiente) y conviene maximizar el hit rate; el detalle de ingeniería de hit rate está en Prefix cache hit rate. Combina especialmente bien con RAG: documentos recuperados que se repiten entre sesiones se cachean una vez.

4. Caché semántico de respuestas

Una capa por delante del modelo: si una query es semánticamente equivalente a una respondida antes (similitud de embeddings por encima de un umbral), devuelve la respuesta cacheada y sáltate el modelo entero —retrieval, prefill y decode incluidos. En cargas reales con colas largas de preguntas repetidas o casi-repetidas (FAQ, soporte), el ahorro es enorme porque elimina el coste completo, no solo el de prefill. La trampa es el umbral: demasiado laxo y sirves respuestas equivocadas a preguntas parecidas-pero-distintas. El diseño está en Caché semántico para RAG.

5. Structured output y function calling: apoyarse en herramientas, no en memoria

La última palanca cambia de qué depende el SLM. En lugar de pedirle que sepa un dato (su punto débil), haz que llame a una herramienta que lo sabe: una consulta a base de datos, una API, una calculadora, un validador. El structured output (forzar JSON conforme a un esquema) y el function calling convierten al SLM en un orquestador que extrae argumentos del contexto y delega el cálculo o la consulta. Un SLM razonablemente capaz emite un tool call bien formado mucho más fiablemente de lo que recuerda un hecho concreto. Esto reduce la presión sobre el conocimiento paramétrico y sobre la recuperación: para datos estructurados y frescos (precios, inventario, estados), consultar bate a recuperar texto y a memorizar. Los fundamentos están en Structured output y Function calling.

El pipeline completo

Las cinco palancas no son alternativas: se encadenan. El flujo, con el contador de tokens cayendo en cada paso:

Recuperar agresivo, destilar agresivo, razonar barato

Retriever híbrido, recall ~80 chunks Reranker precisión 5 chunks · 4000 tok Compresión extractiva k=4 1000 tok Prefix cache + caché semántico prefill mínimo SLM razona + tool calls respuesta

El contador de tokens de prefill cae a lo largo del pipeline retrieve: mucho rerank: 4000 tok 1000

TTFT en RTX 4090 a ~5000 tok/s · 4000 tok = 0.80 s → 1000 tok = 0.20 s atención cae ~k² = 16× en esa parte del cómputo

El orden importa. Recuperar agresivo (recall alto) antes de filtrar garantiza que el material correcto está entre los candidatos; rerankear y comprimir después garantiza que solo lo denso y relevante paga el peaje del prefill; cachear envuelve todo para no repetir trabajo. El SLM solo ve la chuleta final, corta y ordenada.

Implicaciones para inferencia on-premise

La trampa mental a evitar: tratar el SLM como un modelo grande con menos calidad. No lo es. Es un perfil de coste distinto que premia un diseño distinto. Tres consecuencias prácticas:

El presupuesto de tokens es un recurso de primera clase. Con un modelo grande de 128K de ventana, “meter un poco más” es barato relativo al modelo. Con un SLM, cada token de contexto se nota en el TTFT y en la calidad. Trata el tamaño del contexto como una cantidad a minimizar bajo restricción de cubrir la respuesta, no a maximizar.
La inversión vale la pena precisamente porque el modelo es barato. Reranker, compresor y cachés añaden complejidad, pero el modelo que sirven es lo suficientemente económico como para correr muchas réplicas. El cuello de botella se desplaza del modelo al pipeline de datos, que es justo donde quieres que esté.
Recuperar no sustituye a adaptar; se combinan. Para conocimiento de dominio profundo y recurrente, adaptar el SLM con LoRA (ver el hermano QLoRA y multi-LoRA agresivo) puede meter parte del conocimiento “en los pesos” de forma barata, reduciendo lo que hay que recuperar. RAG agresivo y adaptación agresiva no compiten: la primera da frescura y citabilidad, la segunda da fluidez y formato de dominio. El diseño bueno usa ambas.

En la RTX 4090 (24 GB, Ada Lovelace)

El escenario canónico: un SLM cuantizado (4B–8B en INT4/FP8) cabe holgado, dejando VRAM para un KV cache generoso —imprescindible para el prefix caching— y para el reranker (un cross-encoder de unos cientos de MB). El compresor extractivo tipo LLMLingua corre en un modelo pequeño aparte o en CPU. El cálculo de TTFT de arriba (0.80 s → 0.20 s comprimiendo 4× a ~5000 tok/s) es representativo de esta tarjeta. La regla de pulgar: si el TTFT se va por encima de tu SLA, el primer ajuste es comprimir el contexto, no cambiar de modelo.

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

Con 320 GB y FP8 nativo el prefill es mucho más rápido, así que la tentación es relajar la disciplina de tokens. No conviene del todo: la palanca cambia de TTFT a throughput agregado. Comprimir el contexto no solo acelera cada petición sino que libera cómputo de prefill para servir más peticiones por GPU —el prefill compute-bound es exactamente el recurso que satura primero bajo carga. Aquí el prefix caching y el caché semántico, compartidos entre réplicas, son los que más rinden: a alto QPS, el trabajo de prefill que evitas cachear es throughput puro que ganas. El SLM sigue siendo el motor de razonamiento barato; la diferencia es que ahora corres muchos en paralelo y el pipeline de datos es lo que decide cuántas peticiones caben.

Lo que no hemos cubierto

Evaluación de la compresión: cómo medir que comprimir $k=4$ no tira respuestas correctas (faithfulness, answer recall sobre un set de preguntas con ground truth).
Compresión consciente de la query frente a agnóstica: comprimir antes o después de conocer la pregunta cambia qué se puede cachear y qué se puede tirar.
Chunking y granularidad: el tamaño de chunk interactúa con el reranking y la compresión; queda para el post de curación de corpus.
Multi-hop y agentes: cuando una pregunta requiere varias rondas de recuperación, el presupuesto de tokens se reparte entre hops y la disciplina de compresión se vuelve crítica.

Ver también

Reranking e hybrid retrieval para RAG — la palanca 1 en detalle: maximizar recall en el retriever y precisión en el reranker para inyectar pocos chunks pero excelentes, que es lo que un SLM necesita.
Curación del corpus para RAG — un corpus limpio y bien chunked reduce la paja que el compresor tiene que eliminar; la calidad de la chuleta empieza aguas arriba.
Caché semántico para RAG — la palanca 4: saltarse el modelo entero cuando una query es semánticamente equivalente a una ya respondida.
Embeddings 2026: dense, sparse y multivector — la base del retrieval híbrido y del umbral del caché semántico; qué representación recupera mejor con menos ruido.
Ingeniería del prefix cache hit rate — la palanca 3: cómo estructurar el prompt (contexto estable primero) para maximizar la reutilización del KV cache del contexto recuperado.
Optimizaciones de prefill en vLLM — el prefill compute-bound es el coste que toda esta discusión intenta minimizar; aquí están los parámetros concretos para acelerarlo.
Structured output: fundamentos — la palanca 5: forzar JSON conforme a esquema para que el SLM orqueste herramientas en vez de recordar datos.
Function calling y recuperación aumentada con herramientas — cuando consultar una API o base de datos bate a recuperar texto y a memorizar; el SLM como orquestador de tools.
El roofline se invierte en modelos pequeños — por qué el prefill compute-bound es el cuello de botella que da forma a todo este post: meter más contexto no es gratis.
QLoRA y multi-LoRA agresivo en SLM — la alternativa complementaria: adaptar el SLM por dominio para meter parte del conocimiento “en los pesos” y reducir lo que hay que recuperar.

Referencias

Lewis, P., et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. https://arxiv.org/abs/2005.11401
Liu, N.F., et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. https://arxiv.org/abs/2307.03172
Jiang, H., et al. LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. EMNLP 2023. https://arxiv.org/abs/2310.05736
Jiang, H., et al. LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression. ACL 2024. https://arxiv.org/abs/2310.06839

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

Arquitecturas nativas para device: MoE de grano fino y pre-attention router

Tue, 09 Jun 2026 01:50:00 +0000

Este post es de la serie sobre rendimiento de inferencia en modelos pequeños. Es la cara arquitectónica de un problema que ya hemos mirado por el lado del régimen de cómputo (el roofline invertido del SLM) y por el lado de la carga de pesos en Del disco a la HBM. Aquí la pregunta es distinta: ¿y si en lugar de adaptar un modelo grande al device, diseñamos el modelo para el device desde el primer commit?

TL;DR

El gesto por defecto para llevar un LLM a un portátil, un móvil o un edge box es coger un denso pensado para cloud y comprimirlo: destilación, poda, cuantización. Es un gesto de reducción: partes de algo grande y le quitas. SmallThinker (arXiv:2507.20984, SJTU IPADS + Zenergize AI) defiende el gesto inverso —diseñar desde cero— y lo articula en tres piezas. Primera: MoE de grano fino, muchos expertos pequeños con muy pocos activados por token, de modo que los parámetros totales N (la capacidad) se desacoplan de los parámetros activados A (el coste de cómputo por token). Segunda: sparse FFN, sparsity de activación tipo ReLU dentro de cada bloque, que añade un segundo nivel de dispersión sobre el primero. Tercera: un pre-attention router que predice qué expertos hará falta antes de ejecutar el bloque de atención y lanza el prefetch de esos pesos desde SSD/flash en paralelo con el cómputo de la atención, ocultando la latencia de almacenamiento —que es el cuello de botella real cuando el modelo no cabe entero en RAM. Los autores reportan SmallThinker-4B-A0.6B y SmallThinker-21B-A3B superando ~20 tok/s en CPU de consumo con Q4_0, consumiendo ~1 GB y ~8 GB de RAM. Los números son interesantes y la dirección es correcta; la metodología de evaluación y el coste de calidad de activar tan poco merecen escepticismo, y a eso dedicamos la última parte.

La analogía: el bibliotecario que se adelanta a tu pedido

Imagina una biblioteca enorme con una sala de lectura pequeña. Tú estás sentado en la sala con un único pupitre: ahí caben pocos libros a la vez (eso es la RAM). El grueso del fondo está en la trastienda, en estanterías largas y lentas de recorrer (eso es el SSD/flash). Y hay un bibliotecario.

El método ingenuo: tú lees, llegas a un punto donde necesitas un libro concreto, lo pides, y entonces el bibliotecario se levanta, va a la trastienda, lo busca y vuelve. Mientras tanto, tú esperas con la página abierta sin avanzar. Cada vez que necesitas un libro nuevo, pagas el viaje completo a la trastienda. La sala de lectura está la mayor parte del tiempo esperando, no leyendo.

El método de SmallThinker: el bibliotecario es listo y se adelanta. Mientras tú todavía estás leyendo el índice del capítulo —averiguando de qué va, relacionando ideas, lo que en el modelo es el bloque de atención—, él ya ha mirado por encima de tu hombro, ha predicho qué tres o cuatro libros vas a pedir y se ha ido a la trastienda a buscarlos. Para cuando terminas el índice y formulas el pedido, los libros ya están sobre tu pupitre. No has esperado: el viaje a la trastienda ocurrió en paralelo con tu lectura del índice.

La analogía se sostiene en cuatro detalles:

El pupitre pequeño es la RAM; la trastienda lenta es el SSD/flash.
Los libros son los expertos del MoE: solo unos pocos están sobre el pupitre en cada momento.
Leer el índice es el bloque de atención; pedir y usar los libros es el bloque FFN/expertos.
El bibliotecario que predice y se adelanta es el pre-attention router: la predicción se hace antes, y el viaje a buscar (el prefetch) se solapa con la lectura del índice (la atención).

La pregunta cuantitativa que recorre todo el post es: ¿llega el bibliotecario a tiempo? Solo se oculta la espera si el viaje a la trastienda dura menos que tu lectura del índice. Esa es la condición t_{\text{atención}} \ge t_{\text{prefetch}}, y la haremos con números.

Comprimir un denso vs. diseñar para device

Conviene poner los dos enfoques en frío, porque no son grados de lo mismo: son filosofías distintas.

Enfoque A — comprimir un denso pensado para cloud. Partes de, digamos, un modelo denso de 7B–14B entrenado para correr en una RTX 4090 (24 GB, Ada Lovelace) o en un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo). Para meterlo en un device aplicas tres palancas, cada una con su post propio: destilación (entrenas un student pequeño que imita al teacher), poda (eliminas pesos o estructuras enteras) y cuantización agresiva (bajas a 4 bits o menos). El modelo resultante sigue siendo denso: todos sus parámetros se activan en cada token. Has reducido el número de parámetros, pero el patrón de cómputo es el del cloud, solo que más pequeño.

Enfoque B — diseñar para device desde cero. Aquí las restricciones del device entran en la arquitectura, no en una fase posterior de compresión. Las restricciones son tres y muy concretas:

Cómputo débil. Una CPU de portátil o un SoC móvil hace órdenes de magnitud menos FLOPs que una GPU de datacenter. Esto empuja a minimizar los parámetros activados por token, no los totales.
Poca RAM. No caben decenas de GB. Esto empuja a tener residente solo lo imprescindible y a streamear el resto.
Almacenamiento lento. El SSD o la flash a la que te ves obligado a streamear tiene un ancho de banda muy inferior al de la HBM de una GPU. Esto convierte la I/O de almacenamiento en el cuello de botella, y empuja a ocultarla.

SmallThinker es el enfoque B llevado al detalle: cada una de esas tres restricciones tiene una respuesta arquitectónica. El cómputo débil se ataca con MoE de grano fino + sparse FFN (minimizar A). La RAM escasa se ataca con streaming desde SSD (residente ≈ A + caché, no N). El almacenamiento lento se ataca con el pre-attention router (ocultar la I/O tras la atención). No es casual que las tres piezas encajen: cada una resuelve una restricción, y juntas se refuerzan.

Un matiz importante, para no caer en el hype: el enfoque B no es gratis ni universalmente superior. Requiere entrenar un modelo nuevo (no reutilizas pesos existentes), y el techo de calidad de un modelo con A muy pequeño está intrínsecamente acotado, como veremos. El argumento no es “B gana siempre”, sino “para el régimen del device, B ataca los cuellos correctos, y A solo los ataca de refilón”.

Dos niveles de sparsity

La idea central de capacidad es vieja y bien entendida en MoE: separar capacidad de coste de cómputo. En un MoE, el modelo tiene N parámetros totales repartidos en expertos, pero para cada token solo se activan A parámetros (los del top-k de expertos que el router elige). El coste de cómputo por token escala con A; la capacidad de conocimiento escala con N. SmallThinker aplica esta idea en dos niveles superpuestos.

Nivel 1 — MoE de grano fino. “Grano fino” significa muchos expertos pequeños en vez de pocos expertos grandes, con muy pocos activados por token. En vez de, digamos, 8 expertos de los que activas 2, tienes decenas de expertos de los que activas un puñado. Con expertos más pequeños, el mismo A se reparte entre más combinaciones posibles, lo que da granularidad fina al router y mantiene A muy bajo respecto a N. El resultado es un cociente N/A agresivo: mucha capacidad, poquísimo cómputo por token.

Nivel 2 — sparse FFN (sparsity de activación tipo ReLU). Este nivel es ortogonal y opera dentro de cada FFN. Con una no-linealidad tipo ReLU, una fracción grande de las neuronas de la capa intermedia produce exactamente cero para un token dado. Una neurona que sale a cero no contribuye nada a la salida: su multiplicación matriz-vector se puede saltar. Esto es sparsity de activación: predecible token a token, y aprovechable para no cargar ni multiplicar las filas/columnas de peso correspondientes a neuronas inactivas. Es el mismo fenómeno que explotan trabajos como Deja Vu o PowerInfer; SmallThinker lo incorpora de fábrica eligiendo activaciones que lo favorecen.

El efecto combinado, en una frase: N grande (capacidad), A minúsculo (coste de cómputo por token ≈ proporcional a A), y además dentro de ese A una fracción de las multiplicaciones se ahorra por la sparsity de activación. Es sparsity sobre sparsity.

8 expertos grandes · activa 2 A grande por experto · granularidad gruesa

muchos expertos pequeños · activa pocos A total bajo · granularidad fina

+ sparse FFN dentro de cada experto activo: neuronas a 0 (ReLU) → se saltan en el cómputo

Capacidad = N (todos los expertos) · Coste/token ≈ A (activados) · y dentro de A, sparse FFN ahorra más El truco: subir N sin subir A. La granularidad fina permite un cociente N/A mucho más agresivo.

El pre-attention router: predecir y prefetchar

Aquí está la pieza específica del paper, y la que da nombre al post. El problema que resuelve es de scheduling de I/O, no de calidad.

Cuando el modelo no cabe entero en RAM, los pesos de los expertos viven en SSD/flash y se cargan bajo demanda. El flujo ingenuo de una capa MoE es secuencial: ejecutas la atención, luego el router decide qué expertos tocan, luego cargas esos expertos desde SSD (esperando), luego ejecutas la FFN de esos expertos. El paso de carga es una espera pura: la CPU está bloqueada esperando bytes del SSD. En el régimen del device, donde el SSD es lento, ese tiempo de espera domina el step de decode.

El pre-attention router rompe la secuencialidad invirtiendo el orden de la decisión. La observación es que el router no necesita la salida de la atención de esta misma capa para hacer una predicción razonable de qué expertos harán falta: puede predecirlo a partir del estado que ya tiene antes de ejecutar la atención. Así que:

Antes de ejecutar el bloque de atención de la capa, el router predice los expertos que se necesitarán.
Lanza el prefetch de esos expertos desde SSD/flash de forma asíncrona.
En paralelo, la CPU ejecuta el bloque de atención —que es cómputo puro, no necesita el SSD.
Cuando la atención termina, los expertos prefetchados ya están (idealmente) en RAM, y la FFN procede sin esperar.

El I/O de almacenamiento se ha solapado con el cómputo de atención. Es exactamente el bibliotecario que va a la trastienda mientras tú lees el índice.

Ingenuo (secuencial): la carga desde SSD bloquea atención router carga expertos desde SSD (espera bloqueante) FFN expertos t_total = t_att + t_load + t_ffn

Pre-attention router: el prefetch se solapa con la atención

hilo de cómputo (CPU) router (pre) atención (t_att) FFN expertos

hilo de I/O (SSD) prefetch expertos (t_prefetch)

El prefetch queda oculto si t_att ≥ t_prefetch: para cuando la atención termina, los expertos ya están en RAM. Si t_prefetch > t_att, asoma una burbuja de espera (t_prefetch − t_att) antes de la FFN. Ese es el caso a evitar.

La condición de ocultamiento es la desigualdad de arriba: el prefetch se oculta completamente si y solo si

$$t_{\text{atención}} ;\ge; t_{\text{prefetch}}.$$

Si la atención tarda más que cargar los expertos, la carga es gratis (ya estaba hecha). Si los expertos son demasiado grandes o el SSD demasiado lento, t_prefetch > t_att y asoma una burbuja de espera igual a t_prefetch − t_att. Por eso el diseño necesita que A sea pequeño (expertos pequeños → menos bytes a prefetchar → t_prefetch bajo) y que el grano sea fino: las dos cosas que hace el nivel 1 de sparsity no son solo para ahorrar FLOPs, son para que el prefetch quepa debajo de la atención.

Las matemáticas que importan

Footprint de memoria: N residente vs. A + caché

El parámetro que decide si el modelo cabe es cuánto tienes que tener residente en RAM a la vez.

Todo en RAM. Si exiges que todos los expertos estén cargados, el footprint es \approx N (todos los parámetros, multiplicados por bytes/parámetro según la cuantización). Para un 21B esto es prohibitivo en un device.
Streaming desde SSD. Si solo mantienes residentes los expertos activos más una caché de los recientes/probables, el footprint cae a \approx A + \text{caché}. Los pesos que no están en RAM viven en SSD y se prefetchan cuando toca. Aquí está el ahorro real: el residente escala con A, no con N.

La parte no-experta del modelo (embeddings, atención, router, layernorms) sí está siempre residente, pero en un MoE de grano fino el grueso de N está en los expertos, así que la aproximación residente ≈ A + caché + parte_densa es buena.

El cálculo de prefetch, con números

Pongamos los números de la analogía. Supón un SSD de consumo a 5 GB/s de lectura secuencial y un experto cuantizado de tamaño X MB. El tiempo de cargar un experto es

$$t_{\text{1 experto}} = \frac{X \text{ MB}}{5000 \text{ MB/s}} = \frac{X}{5000}\ \text{s} = \frac{X}{5}\ \text{ms}.$$

Concretemos X. En SmallThinker-4B-A0.6B con Q4_0 (~0.5 byte/param efectivo contando overhead de bloques), un experto pequeño de, digamos, 4M parámetros pesa \approx 4\text{M} \times 0.5 = 2 MB. Cargarlo cuesta t_{\text{1 experto}} = 2/5 = 0.4 ms.

Ahora la pregunta de scheduling: si el bloque de atención de la capa toma Y ms, ¿cuántos expertos puedo prefetchar mientras la atención corre? El número es

$$n_{\text{prefetch}} = \left\lfloor \frac{Y}{t_{\text{1 experto}}} \right\rfloor = \left\lfloor \frac{Y \cdot 5}{X} \right\rfloor.$$

Con Y = 2 ms de atención y X = 2 MB por experto: n_{\text{prefetch}} = \lfloor 2 \times 5 / 2 \rfloor = 5 expertos. Es decir, en la ventana de atención de esa capa el SSD alcanza a traer 5 expertos. Si el top-k de la capa activa ≤ 5 expertos, el prefetch los oculta todos y t_prefetch ≤ t_att: latencia de carga cero. Si la capa necesitara 8 expertos, traerías 5 gratis y pagarías la carga de los 3 restantes como burbuja: (8-5) \times 0.4 = 1.2 ms de espera por capa. De ahí que el diseño quiera grano fino con top-k pequeño: para caber debajo de la ventana de atención.

Dos observaciones críticas sobre este cálculo:

Los 5 GB/s son lectura secuencial idealizada. Los expertos están dispersos en disco; lecturas aleatorias 4K en un SSD de consumo van mucho más lentas. El ancho de banda efectivo puede ser una fracción del nominal, lo que reduce n_{\text{prefetch}}. La metodología que reporte tok/s debería decir si mide con expertos pre-ordenados en disco o con acceso realista.
La ventana Y de atención encoge con el contexto corto y al inicio de la generación. Con prompts cortos, la atención es barata y puede que no cubra el prefetch; la ventaja del solapamiento crece con secuencias más largas. Otro detalle que un benchmark honesto debería desglosar.

Footprint de pesos: por qué reportan ~1 GB para un 4B

Hagamos la cuenta del 4B en Q4_0. Cuantización a 4 bits ≈ 0.5 byte/param, más un pequeño overhead de escalas por bloque (Q4_0 añade un FP16 de escala cada 32 pesos, ~0.56 byte/param efectivos). Entonces:

$$4\text{B} \times 0.5\ \text{B/param} \approx 2\ \text{GB}.$$

Es decir, el modelo completo en Q4_0 ocupa ~2 GB en disco. Pero los autores reportan ~1 GB de RAM. ¿Contradicción? No, y entender por qué es entender el diseño:

No todos los expertos están residentes. Solo los activados (A = 0.6B) y una caché caben en RAM; el resto vive en SSD y se streamea. 0.6\text{B} \times 0.5 \approx 0.3 GB de expertos activos, más la parte densa (atención, embeddings, router) y una caché de expertos calientes.
La sparse FFN reduce el trabajo y el residente útil. Las neuronas que salen a cero no necesitan estar materializadas para ese token.

Sumando expertos activos + parte densa + caché razonable, ~1 GB es plausible. Pero ojo con el matiz: ~1 GB es el residente en RAM, no el footprint total en almacenamiento, que sigue siendo ~2 GB en SSD. Confundir ambos —reportar “1 GB” a secas— es engañoso si el lector entiende “el modelo ocupa 1 GB”. Ocupa 2 GB; mantiene 1 GB en RAM. La distinción importa para un device con 2 GB de almacenamiento libre: ahí no entra.

Análogamente, SmallThinker-21B-A3B: 21\text{B} \times 0.5 \approx 10.5 GB en disco; 3\text{B} \times 0.5 \approx 1.5 GB de expertos activos, y el ~8 GB de RAM reportado incluye expertos activos + caché generosa + parte densa. La caché grande es lo que sube de 1.5 a ~8 GB: mantienes muchos expertos calientes residentes para no golpear el SSD constantemente.

El coste de calidad: el escepticismo necesario

Toda la maquinaria anterior reduce el cómputo por token a \approx A. Pero A = 0.6B activados es muy poco. Aquí es donde hay que poner el freno al entusiasmo:

Capacidad de razonamiento acotada. Un modelo que activa 0.6B de parámetros por token tiene, por token, la potencia de cómputo de un modelo de 0.6B, no de 4B. La capacidad total N=4B ayuda a almacenar más conocimiento (más expertos especializados), pero el procesamiento de cada token sigue limitado por A. Para tareas que requieren composición y razonamiento multi-paso intensivo, esto es un techo real, no un detalle.
El router es un punto único de fallo de calidad. Si el router de grano fino elige mal los expertos —y con grano fino hay más decisiones que tomar—, la calidad cae sin que ninguna métrica de velocidad lo refleje. El pre-attention router agrava esto: predice los expertos antes de ver la atención, con menos información que un router post-atención. Los autores deberían reportar cuánta calidad se pierde por predecir antes (mismatch entre experto prefetchado y experto que el router post-atención habría elegido).
Los ~20 tok/s necesitan letra pequeña. ¿En qué CPU exactamente? ¿Con qué longitud de contexto y de generación (la ventaja del solapamiento depende de Y)? ¿Cold start incluido o steady state? ¿El SSD estaba con los expertos pre-ordenados secuencialmente? Un “supera 20 tok/s” sin esas condiciones es un número de marketing, no de metodología.
Comparación justa. La pregunta correcta no es “¿es rápido?”, sino “¿a igualdad de calidad en un benchmark independiente, es más rápido o más pequeño que un denso comprimido equivalente?”. Eso requiere evals que el lector pueda reproducir, no solo tok/s en la máquina de los autores.

Nada de esto invalida la dirección. Diseñar para device es, conceptualmente, el enfoque correcto: ataca los cuellos reales (cómputo, RAM, I/O) en la arquitectura en vez de paliarlos después. Pero “20 tok/s en ~1 GB” es una afirmación de eficiencia, y la eficiencia solo significa algo anclada a un nivel de calidad medido honestamente. Mientras esa ancla no esté clara, el número correcto de escepticismo es alto.

Implicaciones para inferencia on-premise y edge

El SSD pasa a ser parte de la jerarquía de inferencia. En cloud, la jerarquía es HBM → RAM. En device, el SSD/flash entra como un nivel más, y su ancho de banda y latencia de acceso aleatorio se vuelven parámetros de rendimiento de primer orden. Esto conecta con Del disco a la HBM: el cold start y el streaming de pesos dejan de ser solo un problema de arranque y pasan a ser parte del steady state.
El edge box heterogéneo gana sentido. En un patrón de entornos mixtos, un modelo nativo-device como SmallThinker corre en el NUC/edge con CPU y SSD, sirviendo localmente, mientras lo pesado se queda en el cluster central. El pre-attention router es lo que hace viable el edge box sin GPU.
El capacity planning cambia de ejes. Como discute Capacity planning de inferencia, en device el recurso a planificar no es VRAM sino la terna RAM-residente / ancho-de-banda-SSD / FLOPs-de-CPU. Un modelo con A pequeño y prefetch solapado mueve el cuello de botella de “¿cabe en RAM?” a “¿el SSD alimenta el prefetch a tiempo?”.

Conclusión

SmallThinker es, sobre todo, un cambio de pregunta. No “¿cómo encojo este modelo cloud para que quepa en el device?” sino “¿cómo sería el modelo si lo diseñara para el device desde el primer parámetro?”. La respuesta —MoE de grano fino para desacoplar N de A, sparse FFN para ahorrar dentro de A, y un pre-attention router que oculta la I/O de almacenamiento bajo la atención— ataca las tres restricciones del device (cómputo, RAM, I/O) en la arquitectura, no en una fase de compresión posterior. La condición clave, t_att ≥ t_prefetch, explica por qué las piezas encajan: el grano fino no solo ahorra FLOPs, hace que el prefetch quepa debajo de la atención. Los números reportados (~20 tok/s, ~1 GB / ~8 GB de RAM) son prometedores y la dirección es sólida; el coste de activar tan poco y la falta de detalle metodológico sobre calidad piden cautela. Diseñar para device es la apuesta correcta; medirlo honestamente es la asignatura pendiente.

Ver también

MoE inference: el call center con 256 especialistas — la base conceptual de este post: cómo un router enruta tokens a expertos y por qué N y A se desacoplan; léelo primero si MoE te suena lejano.
Del disco a la HBM: cold start y carga de modelo — el streaming de pesos desde almacenamiento lento, que aquí deja de ser problema de arranque y pasa a steady state vía prefetch.
Knowledge distillation — la palanca canónica del enfoque “comprimir un denso de cloud”, el contrapunto exacto del enfoque nativo-device.
Poda de modelos LLM — la otra palanca de reducción; útil para comparar “quitar a un grande” frente a “diseñar pequeño desde cero”.
Entornos mixtos NVIDIA + Intel — dónde encaja un modelo nativo-device: el edge box con CPU y SSD que sirve localmente sin GPU.
Capacity planning de inferencia LLM on-premise — en device los ejes a planificar son RAM-residente, ancho de banda de SSD y FLOPs de CPU, no VRAM.
Roofline invertido en modelos pequeños (hermano de esta serie, próximamente) — el régimen de rendimiento del SLM que explica por qué A pequeño mantiene el decode memory-bound y dónde está el techo real.
Self-speculative decoding con early-exit (hermano de esta serie, próximamente) — self-spec aplicado a MoE on-device: cómo acelerar el decode sin draft externo cuando el modelo ya es pequeño.
Cuantización agresiva sub-4-bit y ternaria (hermano de esta serie, próximamente) — Q4_0 y más allá en device: ternario y 2-bit para bajar aún más el footprint de expertos en SSD.

Referencias

Equipo SmallThinker (SJTU IPADS + Zenergize AI). SmallThinker: A Family of Efficient Large Language Models Natively Trained for Local Deployment. arXiv:2507.20984. https://arxiv.org/abs/2507.20984
Repositorio oficial SmallThinker: https://github.com/SJTU-IPADS/SmallThinker
Self-Speculative Decoding for On-device MoE Acceleration. ACM The Web Conference (WWW) 2026. doi:10.1145/3774904.3792218. https://doi.org/10.1145/3774904.3792218
Liu, Z. et al. Deja Vu: Contextual Sparsity for Efficient LLMs at Inference Time. ICML 2023. https://arxiv.org/abs/2310.17157
Song, Y. et al. PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU (sparse activation + hot/cold experts). SJTU IPADS, 2023. https://arxiv.org/abs/2312.12456

Self-speculative decoding: el modelo que se adelanta a sí mismo

Tue, 09 Jun 2026 01:40:00 +0000

Este post es el complemento directo de Speculative decoding: el secretario que adelanta. Allí draft y target son dos modelos distintos; aquí son el mismo modelo a dos profundidades. Léelo primero: damos por sabidos el rejection sampling, el techo 1/(1-α) y la fórmula del speedup, y aquí solo cambiamos qué es el draft.

TL;DR

Speculative decoding clásico exige una pareja: un modelo draft barato propone γ tokens y un target caro los verifica en un único forward pass paralelo. En modelos grandes el draft puede ser un 1 % del target y caber holgado. En modelos pequeños (SLM, 1B–8B) esa receta se rompe por dos lados: un draft que sea 1/10 de un 3B es un 0.3B que apenas acierta (α se desploma), y cargar un segundo modelo —por pequeño que sea— dobla las piezas a mantener y se come VRAM que en una 4090 o en device no sobra. Self-speculative decoding resuelve ambos: el draft es el propio modelo ejecutado de forma superficial. Un modelo de L capas produce tokens borrador saliendo en una capa intermedia k < L (early-exit) o saltando un subconjunto de capas (layer-skip), y luego verifica esos tokens con el forward completo de las L capas. Como draft y verify comparten pesos y comparten el KV cache de las capas comunes, el coste extra de memoria es cero: no hay un segundo modelo, no hay un segundo KV cache, no hay nada nuevo que cargar. El precio es que el draft early-exit es más caro que un draft externo minúsculo (recorre k/L del modelo en vez de un 1 %), así que el coste relativo c sube. El trade-off honesto: con draft dedicado bien entrenado (EAGLE-3) que quepa en memoria, su α suele ser mayor y gana; self-spec gana cuando no hay draft entrenado, no cabe, o estás en device.

La analogía: el ajedrecista que juega a ojo y luego calcula

Un buen jugador de ajedrez hace dos cosas con el mismo cerebro. Primero mira el tablero y, a ojo, en medio segundo, propone una jugada “que pinta bien”: es intuición de patrones, reconocimiento rápido, las capas superficiales del juicio. Después, antes de mover, calcula a fondo: tres jugadas por delante, las respuestas del rival, las líneas tácticas. Ese cálculo profundo confirma la intuición o la corrige.

Lo decisivo es que es la misma persona haciendo de borrador y de revisor. No contrata a un segundo ajedrecista más débil para que adivine la jugada y luego él la valida —eso sería el speculative clásico con draft externo—. Aquí el borrador rápido y la verificación lenta salen del mismo cerebro, recorrido a dos profundidades.

La analogía se sostiene punto por punto:

El vistazo a ojo es el forward early-exit: el modelo recorre solo las primeras k capas y emite un token borrador. Rápido, aproximado.
El cálculo a fondo es el forward completo de las L capas, que verifica el borrador con rejection sampling exacto.
Que sea la misma persona es el reuso de pesos y de KV cache: las k capas superficiales del draft son literalmente las mismas que las k primeras capas del verify; lo ya computado no se recomputa.
Que la jugada final sea idéntica a la que el jugador habría elegido calculando siempre a fondo es la garantía de rejection sampling: la calidad del output no se degrada (la prueba está en el post de speculative).

Por qué el draft externo no encaja en modelos pequeños

Repasemos el coste del speculative clásico con dos números. El speedup depende de la tasa de aceptación α (cuánto acierta el draft) y del coste relativo c = T_draft / T_target. Un draft útil necesita α alto y c bajo a la vez. En modelos grandes eso es alcanzable: un draft de 1B para un target de 70B tiene c ≈ 0.015 y, si está bien destilado (EAGLE), α > 0.8. El producto sale rentable.

En un modelo pequeño el equilibrio se rompe:

El draft proporcional es inservible. Si quieres c ≈ 0.1 para un target de 3B, tu draft es un ~0.3B. Un 0.3B genérico tiene una distribución tan distinta del 3B que α cae a la zona 0.3–0.5. Y 1/(1-α) con α = 0.4 es un techo de 1.67 tokens/step: ni con γ infinito sacas más. El premio se evapora.
Cargar un segundo modelo dobla las piezas. Aunque el draft sea pequeño en VRAM, es otro checkpoint que versionar, cuantizar, validar y servir, y tiene su propio KV cache. En una RTX 4090 (24 GB, Ada Lovelace) con un 8B cuantizado y un contexto largo, el KV cache ya aprieta; meter un segundo modelo y su cache puede forzarte a bajar la concurrencia o el contexto máximo. En device (un móvil, un NUC, un edge box) directamente no hay sitio.
No siempre existe un draft entrenado para tu modelo exótico o fine-tuneado. EAGLE necesita entrenar el draft on-policy contra ese target concreto (ver knowledge distillation). Si tu SLM es un fine-tune propio, no hay draft oficial publicado.

Self-speculative ataca los tres a la vez con una idea: no traigas un segundo modelo; usa el primero a media profundidad.

El mecanismo: early-exit como draft, forward completo como verify

Un transformer de L capas, en cada posición, transforma el hidden state capa a capa: h_0 → h_1 → ... → h_L, y la LM head proyecta h_L a logits. La observación que lo habilita todo: h_k para k < L ya es un hidden state razonable. Si lo pasas por la misma LM head (o por una head ligera dedicada), obtienes una distribución de salida “prematura” pero a menudo correcta para los tokens fáciles. Esa es la fuente del borrador.

La iteración de self-speculative tiene la misma estructura que el speculative clásico —draft, verify, accept/reject— pero ambos roles son el mismo modelo:

Paso 1 — Draft superficial. Para producir γ tokens borrador, el modelo recorre solo las primeras k capas (o un subconjunto de capas en el caso layer-skip) y aplica la LM head. Cada token borrador cuesta ≈ k/L de un forward completo. Llamamos c = k/L al coste relativo del draft. Los γ borradores se generan autoregresivamente a este coste reducido.

Paso 2 — Verify completo. El modelo ejecuta un único forward pass de las L capas sobre prompt + x_1...x_γ. Por la atención causal obtiene p(·|prompt, x_<i) para cada posición, exactamente igual que en el speculative clásico.

Paso 3 — Accept/reject. Rejection sampling idéntico al del post anterior: se aceptan tokens de izquierda a derecha, se corrige en la primera divergencia muestreando del residual norm(max(0, p−q)), y si se aceptan los γ se añade el token bonus. La calidad del output es exactamente la del modelo completo.

El truco que hace `c` aún más barato: reuso de KV cache de capas compartidas

Aquí está la diferencia clave frente a un draft externo. Cuando el modelo hace el draft recorriendo las capas 0..k, calcula y almacena el KV cache de esas k capas para los tokens del prompt y los borradores. Cuando llega el verify completo, las capas 0..k del forward de L capas son bit a bit las mismas operaciones sobre los mismos pesos que ya hizo el draft. No hay que recomputarlas: el verify reusa directamente el KV cache que el draft dejó para las capas 0..k, y solo computa de verdad las capas k..L que faltan.

Eso tiene dos consecuencias:

Memoria extra cero. No hay un segundo KV cache. El KV de las capas comunes es uno solo, compartido entre draft y verify. Contrasta con vanilla SD, donde el draft tiene su propio cache completo (ver KV cache).
Cómputo parcialmente reusado. El verify solo paga las capas k..L “nuevas” para los tokens que ya pasaron por el draft. El forward completo no es tan caro como sugiere L, porque las primeras k capas vienen del cache.

DRAFT · early-exit en k=8 capas 0..8 recorrido superficial coste ≈ k/L = 0.25 LM head → borrador x₁ x₂ x₃ x₄ (γ=4)

VERIFY · forward completo L=32 capas 0..8 (reusadas, no se recomputan) capas 8..32 cómputo nuevo LM head → p(·)

KV cache COMPARTIDO capas 0..8 · un solo cache memoria extra = 0

escribe KV 0..8 lee KV 0..8

Rejection sampling (idéntico al speculative clásico) x₁ ✓ x₂ ✓ x₃ ✓ x₄ ✗ Output = exactamente el del modelo completo · 0 modelos extra · 0 KV extra El draft y el verify son el mismo modelo; las capas 0..8 se computan una sola vez.

Las familias (estado 2026)

No hay una sola forma de hacer self-speculative. Difieren en qué capas se saltan y en si hace falta entrenar.

Familia	Año / venue	Cómo elige qué saltar	¿Entrenamiento?	Idea distintiva
LayerSkip (Elhoushi et al.)	2024, arXiv:2404.16710	Early-exit en capa fija `k`; una sola LM head sirve a todas las salidas	Sí — layer dropout + early-exit loss en train/fine-tune	Un único modelo entrenado para hacer draft y verify; reusa cómputo parcial
SWIFT	ICLR 2025 (OpenReview EKJhH5D5wA)	Selecciona qué capas saltar on-the-fly, sin tocar pesos	No — plug-and-play sobre el modelo dado	Self-spec training-free: optimiza el conjunto de capas saltadas en caliente
CLaSp	2025, arXiv:2505.24196	In-context layer skip dinámico: el patrón de capas saltadas se adapta al contexto	No (dinámico en inferencia)	El skip no es fijo; cambia según lo que se está generando
ConfLayers	2026, arXiv:2604.14612	Salta capas según confianza del estado intermedio (adaptativo por token)	No (criterio de confianza)	Profundidad variable: tokens fáciles salen antes, difíciles llegan más hondo
Saguaro	2025–26	Formulación asíncrona: el draft sigue especulando en paralelo mientras corre la verificación	Depende de la variante	Solapa draft y verify en el tiempo en lugar de alternarlos
SSD para MoE on-device	ACM Web Conf. 2026, doi 10.1145/3774904.3792218	Self-spec aprovechando la sparsity del MoE (pocos expertos activos por token)	Variante específica MoE	El draft superficial activa aún menos expertos; encaja con MoE en device

Tres lecturas operacionales de la tabla:

El eje que más importa es entrenamiento sí/no. LayerSkip da el mejor α porque el modelo aprende a ser un buen draft superficial (con early-exit loss las capas intermedias se entrenan explícitamente para predecir bien). Pero exige fine-tune. SWIFT, CLaSp y ConfLayers son training-free: peor α, pero se aplican a cualquier modelo ya entrenado sin tocar nada. Para un SLM que no controlas, training-free es lo realista.
El skip adaptativo (CLaSp, ConfLayers) sube α porque ajusta la profundidad del draft al token: gasta poco en lo fácil y más en lo difícil, en vez de un k fijo. A cambio, el c efectivo deja de ser constante.
Saguaro ataca otra cosa: no sube α, solapa el tiempo de draft y verify. Es ortogonal al resto y combinable.

La matemática: mismo marco, distinto `c`

Reutilizamos el aparato del post de speculative sin cambiar una letra. Con α la tasa de aceptación y γ el número de borradores:

$$E[\text{tokens por step}] = \frac{1 - \alpha^{\gamma+1}}{1 - \alpha}, \qquad \text{Speedup} = \frac{1 - \alpha^{\gamma+1}}{(1 - \alpha)(\gamma c + 1)}$$

Y el techo algorítmico es el mismo: lim_{γ→∞} = 1/(1-α). Lo único que cambia en self-speculative es el valor de c: ya no es el ratio de tamaños de dos modelos, sino c = k/L, la fracción de capas que recorre el draft early-exit.

Ejemplo numérico: self-spec con L=32, salida en k=8

Tomemos un SLM de L = 32 capas que sale en k = 8 para el draft: c = k/L = 8/32 = 0.25. Supongamos α = 0.7 (razonable para early-exit en tokens conversacionales) y γ = 4.

Tokens esperados por step: (1 − 0.7⁵) / (1 − 0.7) = (1 − 0.168) / 0.3 = 0.832 / 0.3 = 2.77
Speedup: 2.77 / (4 × 0.25 + 1) = 2.77 / 2.0 = 1.39×

El factor del denominador es γc + 1 = 4·0.25 + 1 = 2.0: el draft early-exit, al costar un cuarto del modelo cada token, se come parte del beneficio. Salir más arriba ayuda: con k = 4 (c = 0.125), denominador = 1.5 y speedup = 2.77/1.5 = 1.85× — pero salir más arriba normalmente baja α, así que hay tensión real entre k pequeño (barato) y α alto (acierta).

Comparación honesta con un draft externo

Pongamos al lado un draft externo minúsculo bien destilado: c = 0.1 y α = 0.78 (lo que un EAGLE-style draft puede dar), mismo γ = 4.

Tokens/step: (1 − 0.78⁵)/(1 − 0.78) = (1 − 0.289)/0.22 = 0.711/0.22 = 3.23
Speedup: 3.23 / (4 × 0.1 + 1) = 3.23 / 1.4 = 2.31×

Configuración	c	α	tokens/step	speedup	VRAM extra	piezas a mantener
Self-spec early-exit (k=8)	0.25	0.70	2.77	1.39×	0	0
Self-spec early-exit (k=4)	0.125	0.65	2.50	1.67×	0	0
Draft externo destilado	0.10	0.78	3.23	2.31×	sí (+modelo +KV)	1 modelo extra

La lectura es exactamente la que cabe esperar y conviene no maquillar: si tienes un draft dedicado, entrenado contra tu target, y cabe en memoria, su α mayor y su c menor le dan más speedup. EAGLE-3 con draft bien entrenado suele ganar en speedup bruto. Self-spec no compite en speedup bruto; compite en coste total. Sus columnas ganadoras son las dos de la derecha: cero VRAM extra y cero piezas que mantener. Self-spec gana cuando:

no hay draft entrenado para tu modelo (SLM propio, fine-tune raro),
el draft no cabe (4090 ya llena, contexto largo que necesita el KV),
estás en device (móvil, NUC, edge), donde un segundo modelo y su KV simplemente no entran.

Es el mismo patrón que con MTP en el post anterior: a veces el mejor draft es el que no tienes que cargar.

Por qué encaja justo con modelos pequeños y device

El régimen donde self-spec brilla es el de baja concurrencia, memory-bandwidth-bound, con presupuesto de memoria escaso — exactamente el de un SLM en una sola GPU o en device (el porqué del régimen está en el roofline invertido). Tres razones:

Cero memoria extra es decisivo donde no sobra. En una RTX 4090 (24 GB, Ada Lovelace) sirviendo un 7B–8B cuantizado con contexto largo, cada GB cuenta. Self-spec no pide ni uno: reusa pesos y KV. Un draft externo, aunque pequeño, te obliga a recortar contexto o concurrencia. En device la diferencia es binaria: con self-spec aceleras; con draft externo no hay sitio y punto.
No hay segundo checkpoint que versionar. Operacionalmente, un SLM en edge desplegado en cientos de cajas se vuelve insostenible si cada una necesita dos modelos sincronizados. Un solo binario que hace draft y verify es muchísimo más simple de mantener.
Encaja con MoE en device. En un MoE de grano fino para device (ver arquitecturas nativas para device), el draft superficial activa aún menos expertos, y el régimen memory-bound persiste incluso a batch medio — justo lo que el trabajo de SSD para MoE on-device (ACM WWW 2026) explota.

El contrapunto, repetido para que no se olvide: en un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo), donde la memoria no es el cuello de botella, un draft EAGLE-3 dedicado sí cabe y su α mayor le da más speedup. Allí self-spec es plan B: lo usas si el modelo es exótico y no hay draft entrenado, no porque la memoria apriete.

Pitfalls

El α depende muchísimo de k. Salir demasiado arriba (k pequeño) abarata el draft pero hunde α; salir demasiado abajo (k cercano a L) sube α pero el draft cuesta casi un forward completo y c → 1, matando el speedup. El óptimo es empírico y específico del modelo. Desconfía de cualquier número de speedup que no diga en qué k se midió.
Training-free no es gratis en calidad de draft. SWIFT/CLaSp dan α menores que LayerSkip precisamente porque las capas intermedias del modelo no se entrenaron para ser buenas salidas prematuras. El número que importa es α medido en tu distribución, no el del paper.
Sampling temperature y outputs creativos bajan α igual que en el speculative clásico. A T alta, el speedup de self-spec se erosiona más rápido todavía porque parte de un α más bajo.
Batch grande lo neutraliza igual que al speculative clásico. En cuanto el decode pasa a compute-bound, los borradores dejan de ser “casi gratis”. Self-spec es para baja concurrencia.

Ver también

Speculative decoding: el secretario que adelanta — el complemento directo y prerequisito: draft + verify + rejection sampling, el techo 1/(1-α) y la fórmula del speedup que aquí reutilizamos tal cual.
El roofline invertido en modelos pequeños — por qué el SLM vive en régimen memory-bound, que es justo lo que habilita cualquier forma de speculative.
Arquitecturas nativas para device: MoE de grano fino — dónde aterriza el self-spec sobre MoE en device, aprovechando la sparsity del router.
KV cache: la memoria de trabajo — el reuso del KV de las capas compartidas entre draft y verify es lo que hace que la memoria extra sea cero; aquí está el mecanismo del cache.
Knowledge distillation — el early-exit loss de LayerSkip es pariente de la destilación: enseña a las capas intermedias a predecir como el modelo completo.
Poda de modelos LLM — saltar capas es una forma de poda estructurada en inferencia; layer-skip y layer-dropping comparten raíz conceptual.
MoE inference: el call center con 256 especialistas — el régimen memory-bound persistente del MoE hace que el self-spec sobre MoE gane incluso a batch medio.
Optimizando el decode en vLLM — dónde se configuran en la práctica los métodos speculative en producción.
Entornos mixtos NVIDIA + Intel — el caso device/edge donde “cero modelo extra” deja de ser una comodidad y pasa a ser la única opción viable.

Referencias

Elhoushi, M., et al. LayerSkip: Enabling Early Exit Inference and Self-Speculative Decoding. 2024. https://arxiv.org/abs/2404.16710
SWIFT: On-the-Fly Self-Speculative Decoding for LLM Inference Acceleration. ICLR 2025. https://openreview.net/forum?id=EKJhH5D5wA
CLaSp: In-Context Layer Skip for Self-Speculative Decoding. 2025. https://arxiv.org/abs/2505.24196
ConfLayers: Confidence-Adaptive Layer Skipping for Self-Speculative Decoding. 2026. https://arxiv.org/abs/2604.14612
Self-Speculative Decoding for MoE on Device. ACM Web Conference 2026. https://doi.org/10.1145/3774904.3792218
Hugging Face blog. Faster Text Generation with Self-Speculative Decoding. https://huggingface.co/blog/layerskip
Leviathan, Y., Kalman, M., Matias, Y. Fast Inference from Transformers via Speculative Decoding. ICML 2023. https://arxiv.org/abs/2211.17192

El roofline se invierte: por qué optimizar modelos pequeños es otro partido de rendimiento

Tue, 09 Jun 2026 01:30:00 +0000

Este post es el ancla de una mini-serie sobre rendimiento de inferencia en modelos pequeños (SLM). Casi todos los posts de optimización del blog —KV cache, decode, quantization— se escribieron con un 70B en la cabeza. Aquí defiendo que cuando el modelo encoge un orden de magnitud, el roofline cambia de régimen y varias de esas intuiciones se invierten. No es un matiz: es otro partido.

TL;DR

El decode autoregresivo de un LLM grande está memory-bandwidth-bound: en cada step hay que mover todos los pesos del modelo desde la HBM hasta los registros de los SM, y eso domina sobre las operaciones aritméticas. La GPU se pasa el rato esperando bytes, no calculando. Esa única frase —que el decode “espera a la HBM”— es la raíz de la mitad de las optimizaciones del blog. En un modelo pequeño (SLM, digamos 0.5B–7B) la frase deja de ser cierta de la forma simple en que la contábamos. A batch 1 sigues siendo memory-bound respecto al hardware, sí, pero el forward pass es tan barato (mover 6 GB a 1 TB/s son ~6 ms, no 70 ms) que los costes fijos por step —lanzamiento de kernels, overhead del scheduler de Python, el sampler, las copias host↔device, los synchronize— dejan de ser ruido y pasan a comerse un 20-30 % del tiempo. El cuello se desplaza de la HBM a la orquestación. Consecuencias concretas y cuantitativas: (1) los CUDA graphs y reducir el overhead del scheduler rinden más en SLM que en modelos grandes; (2) la cuantización de pesos da menos mejora de latencia a batch 1 en SLM, porque proporcionalmente hay menos pesos que mover frente a activaciones, KV cache y overhead fijo; (3) el batching tiene más headroom porque cruzas el ridge point tarde; (4) el KV cache puede dominar la memoria relativa. Todo esto sale de un único modelo —el roofline— aplicado con honestidad numérica.

La analogía: la despensa y el camarero

Una cocina con dos servicios muy distintos.

Servicio de degustación, un plato enorme y lento (el LLM de 70B). Cada plato lleva ingredientes pesados que el ayudante tiene que ir a buscar a la despensa del fondo, varias veces, cargando cajas. El cocinero, en cambio, monta el plato en un momento: lo lento es traer los ingredientes, no cocinarlos. Si quieres que el servicio vaya más rápido, no compras un cocinero más hábil: ensanchas el pasillo a la despensa o haces que cada viaje traiga más cajas. La despensa es la HBM; el viaje es el ancho de banda de memoria; cocinar es el compute. El plato grande está bound por la despensa.

Servicio de tapas, platillos minúsculos (el SLM). Ahora cada tapa lleva dos ingredientes y se monta en un segundo. El viaje a la despensa por tapa es brevísimo. Pero aparece un coste que en el plato grande era despreciable: el camarero. Por cada tapa, el camarero tiene que ir a la cocina, recoger el platillo, llevarlo a la barra, volver, anotar la comanda, cantarla. Ese ir y venir es fijo: cuesta lo mismo para una tapa que para el plato enorme. Cuando la tapa se monta en un segundo, el camarero —no la despensa— es el cuello de botella. Acortar el pasillo a la despensa (ensanchar la HBM, cuantizar los pesos) ya casi no mejora el servicio; lo que mejora es que el camarero encadene varias comandas sin volver a la cocina cada vez (CUDA graphs) o que sirva varias mesas de una pasada (batching).

El roofline es la herramienta que dice, con números, a partir de qué punto el camarero domina sobre la despensa. Esa frontera es el ridge point, y el chiste del título es que en SLM cruzamos el régimen mucho antes de lo que la intuición de los modelos grandes nos hizo creer.

El mecanismo desnudo: qué dice el roofline

El modelo roofline (Williams, Waterman y Patterson, 2009) parte de una sola magnitud: la arithmetic intensity (intensidad aritmética), que es cuántas operaciones haces por cada byte que mueves desde memoria.

$$\text{AI} = \frac{\text{FLOPs}}{\text{bytes movidos desde memoria}} \quad [\text{FLOP/byte}]$$

El hardware tiene dos techos: el de cómputo (peak FLOPS) y el de memoria (peak bandwidth × AI). El rendimiento alcanzable es el mínimo de ambos:

$$\text{Perf} = \min\big(\text{peak FLOPS},; \text{BW} \times \text{AI}\big)$$

Donde se cortan las dos líneas está el ridge point, la AI a partir de la cual dejas de estar limitado por memoria y pasas a estarlo por cómputo:

$$\text{AI}_{\text{ridge}} = \frac{\text{peak FLOPS}}{\text{peak BW}}$$

Si tu kernel tiene AI por debajo del ridge, estás memory-bound (la GPU espera bytes). Por encima, compute-bound (la GPU calcula a tope y la memoria sobra). Lo importante es que el ridge point es una propiedad del hardware, no del modelo. Veamos los números —aproximados, y los marco como tales porque las cifras de marketing mezclan dense y sparse, distintos dtypes y condiciones térmicas irreales.

Cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo). Por GPU, ~989 TFLOPS BF16 dense (~1979 TFLOPS FP8 dense; la cifra con sparsity es el doble y casi nunca aplica a inferencia LLM). HBM3 ~3.35 TB/s. El ridge en BF16:

$$\text{AI}_{\text{ridge}}^{\text{H100,BF16}} \approx \frac{989 \times 10^{12}}{3.35 \times 10^{12}} \approx 295 \ \text{FLOP/byte}$$

En FP8 el ridge sube a ~590 FLOP/byte (el doble de FLOPS contra el mismo BW). Cuidado: estas son cifras de pico de datasheet; en la práctica un kernel real raramente pasa del 70-80 % de cualquiera de los dos techos.

RTX 4090 (24 GB, Ada Lovelace). ~330 TFLOPS FP16 con acumulación FP16 vía tensor cores (la cifra “660 TOPS” que circula es con sparsity), y ~1 TB/s de GDDR6X. El ridge:

$$\text{AI}_{\text{ridge}}^{\text{4090,FP16}} \approx \frac{330 \times 10^{12}}{1.0 \times 10^{12}} \approx 330 \ \text{FLOP/byte}$$

Curiosamente del mismo orden que la H100 en BF16: la 4090 tiene menos BW pero también menos FLOPS, y el cociente queda parecido. El ridge ronda 300 FLOP/byte en ambos casos. Quédate con ese número.

¿Y dónde cae el decode? En decode a batch 1, cada peso se carga una vez desde HBM y se usa para una sola multiplicación-acumulación (un token, una fila de activación). La AI del GEMM de decode a batch 1 es del orden de AI ≈ 1-2 FLOP/byte (cada byte de peso participa en ~2 FLOP). Con batch B, el mismo peso cargado una vez sirve a B filas de activación, así que la AI escala aproximadamente lineal:

$$\text{AI}_{\text{decode}}(B) \approx 2B \ \text{FLOP/byte} \quad (\text{para la parte GEMM de los pesos})$$

Cruzas el ridge cuando 2B ≈ 300, es decir B ≈ 150 en orden de magnitud (en la práctica antes, por atención y overheads, pero ese es el marco). Conclusión limpia: el decode a batch bajo está siempre profundamente memory-bound, lejísimos del ridge. Por eso decimos que “el decode espera a la HBM” y por eso cuantizar pesos (mover menos bytes) acelera el decode de un modelo grande casi linealmente. Hasta aquí, todo es el discurso estándar de los posts de modelos grandes.

El matiz del título: por qué se invierte en SLM

El roofline clásico tiene un punto ciego que en modelos grandes no importa y en pequeños lo es todo: solo modela el trabajo dentro del kernel. Asume que el único tiempo es bytes/BW o FLOPs/FLOPS. Pero un step de decode real no es solo el GEMM. Es una secuencia de decenas de kernels (proyecciones QKV, atención, las dos capas del MLP, normalizaciones, residuales, la cabeza de logits, el sampling) y, alrededor de cada uno, hay un coste fijo de orquestación:

Lanzamiento de kernels (kernel launch): cada cudaLaunchKernel cuesta del orden de 5-10 µs de overhead de CPU/driver, independientemente del tamaño del kernel. Un forward de decode con ~30-60 kernels lanzados secuencialmente arrastra ~0.3-0.6 ms solo en lanzar.
Overhead del scheduler de Python: el bucle de scheduler de vLLM prepara metadatos, decide qué requests entran en el step, construye los tensores de entrada. En Python puro esto son cientos de µs a un par de ms por step, sobre todo a concurrencia baja donde no se amortiza.
Sampling y post-proceso: aplicar temperatura, top-p, penalizaciones, el argmax/multinomial, copiar el token de vuelta. Otro bloque de cientos de µs.
Sincronizaciones y copias host↔device: cada synchronize o copia pequeña añade latencia que no es ni FLOPs ni bytes de HBM.

Llamemos a la suma de todo esto T_fijo, el coste por step independiente del tamaño del modelo, del orden de 1-3 ms en un stack Python sin optimizar. Ahora el tiempo real de un step es:

$$T_{\text{step}} \approx \underbrace{\frac{\text{bytes de pesos}}{\text{BW}}}{T{\text{HBM}} \text{ (memory-bound)}} + ; T_{\text{fijo}}$$

En un 70B BF16, mover ~140 GB a 3.35 TB/s son ~42 ms de T_HBM. Frente a eso, T_fijo de 1-3 ms es ruido (2-7 %). El roofline clásico acierta: el modelo está memory-bound y punto. Pero en un 3B BF16, T_HBM cae a unos pocos ms, y de pronto T_fijo es del mismo orden que T_HBM. El cuello deja de ser la despensa y pasa a ser el camarero. Esto es la inversión del título, y de ella se derivan cuatro consecuencias contraintuitivas:

(a) A batch 1 sigues memory-bound respecto al hardware. La AI no ha cambiado: sigue siendo ~2 FLOP/byte, debajo del ridge. Quien lea solo el roofline concluirá “memory-bound, cuantiza los pesos”. Es cierto pero incompleto: el roofline no ve T_fijo.

(b) Los costes fijos pasan a ser una fracción enorme del step. Es el punto central. En el 70B, T_fijo / T_step ≈ 5 %. En el 3B puede ser 20-30 %. El cuello efectivo del 3B es mitad HBM, mitad orquestación.

(c) Por eso los CUDA graphs y reducir el overhead del scheduler rinden MÁS en SLM. Un CUDA graph captura toda la secuencia de kernels del step y la relanza con un único cudaGraphLaunch, eliminando casi todo el overhead de lanzamiento por kernel y buena parte del trabajo del scheduler de Python por iteración. En el 70B, recortar 0.5 ms de un step de 42 ms es un +1 % que apenas se nota. En el 3B, recortar esos mismos 0.5 ms de un step de ~7 ms es un +7 %, y si te llevas casi todo T_fijo puedes ganar 20-30 %. La misma optimización, distinto premio, porque el denominador cambió.

(d) La cuantización de pesos da MENOS mejora de latencia a batch 1 en SLM. Esta es la más contraintuitiva. En el 70B, T_HBM es casi todo el step; pasar de BF16 a INT4 cuadruplica el ancho de banda efectivo de pesos y casi cuadruplica la velocidad de decode. En el 3B, T_HBM es solo parte del step (el resto es T_fijo + atención + KV). Por la ley de Amdahl, si los pesos son el 60 % del step y los aceleras 4×, el step total mejora solo 1/(0.4 + 0.6/4) = 1.8×, no 4×. Y proporcionalmente hay menos pesos que mover frente a activaciones, KV cache y el overhead fijo. La cuantización agresiva en SLM ayuda, sí, pero no por la latencia pura a batch 1 —ahí da rendimientos decrecientes— sino por capacidad y concurrencia (lo veremos al final).

(e) El KV cache puede dominar la memoria relativa. Con pesos de 6 GB (3B BF16), una sola sesión de contexto largo puede acercarse a ese orden de magnitud en KV cache. En un 70B (140 GB de pesos) el KV es proporcionalmente pequeño hasta concurrencias altas. En SLM el balance de VRAM se inclina hacia el KV mucho antes (el detalle está en KV cache), y eso cambia qué optimización de memoria es la palanca.

La matemática que importa: el 3B en una 4090

Hagamos el cálculo entero, que es donde se ve la inversión sin retórica.

Modelo: 3B parámetros, BF16 → 2 bytes/param → ~6 GB de pesos. Hardware: RTX 4090, BW ≈ 1 TB/s.

Techo memory-bound del decode (batch 1). Cada token requiere cargar los 6 GB una vez:

$$T_{\text{HBM}} = \frac{6 \times 10^{9} \ \text{bytes}}{1 \times 10^{12} \ \text{bytes/s}} = 6 \times 10^{-3}\ \text{s} = 6\ \text{ms/token}$$

$$\text{Techo} = \frac{1}{6\ \text{ms}} \approx 166\ \text{tok/s}$$

Eso es el techo teórico memory-bound: 166 tok/s, asumiendo que mover los pesos es el único coste. El roofline clásico se pararía aquí y diría “166 tok/s, ve a por más BW o cuantiza”.

Ahora el overhead fijo. Pongamos T_fijo ≈ 2 ms/step (un valor razonable de scheduler de Python + ~40 kernels lanzados + sampling, sin CUDA graphs). El step real:

$$T_{\text{step}} = T_{\text{HBM}} + T_{\text{fijo}} = 6 + 2 = 8\ \text{ms} ;\Rightarrow; \frac{1}{8\ \text{ms}} = 125\ \text{tok/s}$$

El overhead se ha comido 41 tok/s de los 166 teóricos: el T_fijo es el 25 % del step (2 de 8 ms). Compara con el 70B: T_HBM ≈ 42 ms, T_step ≈ 44 ms, T_fijo es el 4.5 %. Mismo overhead absoluto, impacto relativo 5-6× mayor en el SLM.

Qué pasa si aplicas CUDA graphs y te llevas, digamos, 1.5 de los 2 ms de T_fijo:

$$T_{\text{step}}^{\text{graphs}} = 6 + 0.5 = 6.5\ \text{ms} ;\Rightarrow; 154\ \text{tok/s}$$

De 125 a 154 tok/s: +23 % solo por orquestación, sin tocar el modelo ni el hardware de memoria. En el 70B la misma intervención habría dado de 44 a 42.5 ms, +3.5 %. Aquí está, en dos números, “otro partido”.

Qué pasa si cuantizas los pesos a INT4 (1.5 GB en vez de 6 GB), con T_fijo aún en 2 ms:

$$T_{\text{HBM}}^{\text{INT4}} = \frac{1.5 \times 10^{9}}{1 \times 10^{12}} = 1.5\ \text{ms};\quad T_{\text{step}} = 1.5 + 2 = 3.5\ \text{ms} ;\Rightarrow; 285\ \text{tok/s}$$

La cuantización 4× de pesos no dio 4× de latencia: pasó de 125 a 285 tok/s, un 2.3×, porque el T_fijo de 2 ms ahora domina (es el 57 % del step). En el 70B, cuantizar a INT4 da casi el 4× completo porque T_fijo sigue siendo ruido. La misma cuantización rinde el doble de aceleración en el grande que en el pequeño, a batch 1. Y si además aplicas CUDA graphs sobre el INT4 (T_fijo → 0.5 ms): 1.5 + 0.5 = 2 ms → 500 tok/s. El orden de las optimizaciones importa: en SLM atacar T_fijo primero desbloquea el resto.

Configuración (3B, 4090, batch 1)	T_HBM	T_fijo	T_step	tok/s	vs. base
BF16, sin graphs (base)	6.0 ms	2.0 ms	8.0 ms	125	1.00×
BF16 + CUDA graphs	6.0 ms	0.5 ms	6.5 ms	154	1.23×
INT4, sin graphs	1.5 ms	2.0 ms	3.5 ms	285	2.28×
INT4 + CUDA graphs	1.5 ms	0.5 ms	2.0 ms	500	4.00×

(Cifras ilustrativas con T_fijo redondeado; el punto es el patrón, no el decimal. El T_fijo real depende del stack, la versión de PyTorch/CUDA y si hay tensor parallelism. Mídelo en tu setup antes de creerte ninguna fila.)

Implicaciones por optimización

Con el modelo en la mano, las palancas del blog se reordenan al cambiar de régimen.

Batching: mucho más headroom en SLM. Recuerda que cruzas el ridge en B ≈ ridge/2 ≈ 150 en orden de magnitud. En un modelo grande, la VRAM se acaba mucho antes de saturar compute (los pesos + KV no te dejan llegar a batch 150). En un SLM los pesos ocupan poco, así que puedes meter batches grandes en VRAM y seguir memory-bound durante mucho más rango: el T_HBM de los pesos se amortiza entre las B requests (lo cargas una vez, sirve a B), de modo que el throughput agregado por GPU sube casi linealmente con B hasta muy arriba. Es justo lo contrario del miedo del 70B a saturar compute. En SLM, batchear es la palanca de throughput por excelencia porque saturas compute tarde; el grid search de batch en vLLM tiene una meseta de buen comportamiento mucho más ancha. Ojo: batchear mejora throughput, no latencia por request; para latencia single-stream el premio está en T_fijo.

Speculative decoding: otro punto de cruce. Speculative gana cuando el verify de γ tokens es “casi gratis” por estar memory-bound. En SLM el target ya es barato, así que el draft tiene que ser minúsculo para que c = T_draft/T_target siga siendo pequeño, y el T_fijo del propio draft (lanzar sus kernels) muerde más. El cruce a compute-bound con batch también llega antes en términos absolutos de tok/s servidos. La variante que mejor encaja aquui evita un draft separado: self-speculative / early-exit reutiliza capas tempranas del propio modelo y ahorra el T_fijo de orquestar dos modelos.

Cuantización: ayuda por capacidad, no por latencia a batch 1. Como mostró la tabla, INT4 en un SLM a batch 1 da rendimientos decrecientes en latencia. Su verdadero premio en SLM es capacidad: pesos 4× más pequeños liberan VRAM para más KV cache → más concurrencia, y es a concurrencia alta (throughput agregado) donde el ahorro de bytes vuelve a pagar. La cuantización agresiva sub-4-bit y ternaria lleva esto al extremo: en SLM tiene sentido sobre todo para encajar más sesiones por GPU, no para bajar la latencia de una sola. Y conviene recordar (ver quantization) que a batch 1 el dequantize añade trabajo de cómputo que, en un régimen ya rozado por T_fijo, no siempre sale gratis.

Arquitectura: MoE de grano fino cambia qué bytes mueves. Un MoE device-native de grano fino activa pocos parámetros por token, así que T_HBM baja respecto a un denso del mismo tamaño total —pero la fracción T_fijo sube todavía más, y el router añade su propio overhead fijo. Es el régimen SLM llevado a su límite: casi todo el partido se juega en la orquestación.

Scheduler y CUDA graphs primero. La conclusión operacional invertida respecto a los posts de modelos grandes: en SLM, antes de tocar el modelo, mata el T_fijo. CUDA graphs (ver SM, streams y graphs), un scheduler de vLLM con su parte de Python minimizada o compilada, y persistencia de kernels son las palancas de primer orden. En un 70B serían un pulido marginal; en un 3B son la mitad del speedup disponible.

Aplicado a hardware on-premise

En una RTX 4090 (24 GB, Ada Lovelace). Es el escenario donde la inversión es más visible, porque la 4090 tiene ~1 TB/s (un tercio de la H100) pero el T_fijo es el mismo en términos absolutos. Un 3B BF16 sin CUDA graphs deja ~125 tok/s sobre la mesa cuando el techo memory-bound son 166; activar graphs y limpiar el scheduler recupera la mayor parte. La 4090 cabe holgada para SLM en VRAM, así que el cuello casi nunca es la memoria total sino la orquestación y, a alta concurrencia, el KV cache. Regla de pulgar: en 4090 con SLM, perfila primero el overhead por step (Nsight Systems sobre el gap entre kernels) antes de cuantizar.

En un cluster genérico 4×H100 SXM (320 GB, NVLink, FP8 nativo). La H100 tiene 3.35 TB/s, así que T_HBM de un SLM es aún más pequeño (un 3B FP8 son ~3 GB → ~0.9 ms) y el T_fijo domina todavía antes: un SLM mal orquestado en H100 puede pasar más tiempo en el scheduler de Python que moviendo pesos. Es casi un desperdicio servir un único SLM single-stream en una H100; el modo correcto es batching agresivo (saturas compute tarde, así que metes batches grandes y el throughput por GPU se dispara) o multiplexar muchos SLM/sesiones por GPU vía MPS/MIG. Aquí conecta con capacity planning: para SLM el cálculo de capacidad lo gobiernan concurrencia y KV cache, no los pesos. Y con el dilema de una grande vs N pequeñas: replicar SLM tiene sentido precisamente porque cada réplica satura compute tarde y el TP no aporta (el modelo ya cabe; el TP solo añadiría T_fijo de comunicación).

Lo que no hemos cubierto

El T_fijo exacto medido, kernel a kernel, con Nsight Systems: cuánto es launch, cuánto scheduler, cuánto sampling. Es el contenido del siguiente post de la serie.
torch.compile / capturas parciales: alternativas y complementos a los CUDA graphs cuando hay control flow dinámico.
El régimen prefill en SLM: el prefill es compute-bound incluso en modelos pequeños (procesa muchos tokens a la vez, AI alta), así que su roofline es el opuesto del decode; ver prefill.
Atención y KV como segundo término de T_HBM: aquí los hemos metido implícitamente; el desglose fino de la atención (que escala con la longitud de secuencia, no con los pesos) merece su propio tratamiento.

Ver también

KV cache: la memoria de trabajo de la inferencia — el fenómeno memory-bound del decode nace del KV cache; en SLM el KV pasa a dominar la VRAM relativa antes que en modelos grandes.
Grid search de batch sizing en vLLM — la meseta de buen batch es mucho más ancha en SLM porque cruzas el ridge tarde; este post da el método empírico.
Optimizando el decode en vLLM — los flags concretos (CUDA graphs, eager vs captured) cuyo impacto este post reordena para el caso SLM.
Optimizando el prefill en vLLM — el reverso compute-bound del roofline: el prefill ya vive por encima del ridge incluso en modelos pequeños.
SM, CUDA streams y CUDA graphs — el mecanismo que ataca el T_fijo; aquí explicamos por qué su premio es desproporcionado en SLM.
El scheduler step de vLLM — buena parte de T_fijo vive en este bucle de Python; en SLM minimizarlo es palanca de primer orden.
Quantization para inferencia — por qué la cuantización de pesos rinde menos latencia a batch 1 en SLM (ley de Amdahl sobre T_HBM) y más por capacidad.
Speculative decoding: fundamentos — el punto de cruce memory/compute se desplaza en SLM, cambiando cuándo speculative paga.
Capacity planning de inferencia on-premise — para SLM la capacidad la gobiernan concurrencia y KV, no los pesos; este post da las fórmulas.
Una grande vs N pequeñas — replicar SLM bate al TP porque cada réplica satura compute tarde y el TP solo añade T_fijo de comunicación.
Self-speculative decoding / early-exit — hermano de serie: acelerar sin draft separado, evitando el T_fijo de orquestar dos modelos, encaje natural en SLM.
MoE de grano fino device-native — hermano de serie: el régimen SLM llevado al límite, donde el router y la orquestación dominan sobre el T_HBM.
Cuantización agresiva sub-4-bit y ternaria — hermano de serie: por qué en SLM sub-4-bit paga sobre todo en capacidad/concurrencia, no en latencia a batch 1.

Referencias

Williams, S., Waterman, A., Patterson, D. Roofline: An Insightful Visual Performance Model for Multicore Architectures. Communications of the ACM, 52(4), 2009. https://doi.org/10.1145/1498765.1498785
Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference. arXiv:2503.08311, 2025. https://arxiv.org/abs/2503.08311
Databricks. LLM Inference Performance Engineering: Best Practices. https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
NVIDIA. NVIDIA H100 Tensor Core GPU Datasheet. https://resources.nvidia.com/en-us-tensor-core/nvidia-tensor-core-gpu-datasheet
NVIDIA. GeForce RTX 4090 — especificaciones de producto (cifras de tensor cores Ada Lovelace; tratar como aproximadas, mezclan dense/sparse).
Yuan, Z. et al. LLM Inference Unveiled: Survey and Roofline Model Insights. arXiv:2402.16363, 2024 — aplicación del roofline específicamente a inferencia LLM.