La física de los tokens por segundo

La velocidad de generación de tokens no es misteriosa: durante la
decodificación, cada token exige leer esencialmente todos los pesos
activos desde memoria una vez. Eso hace que la decodificación esté
limitada por el ancho de banda de memoria, y significa que puedes predecir
tus tok/s con una división. Todo aquello sobre lo que la gente discute —
cuantización, MoE, descarga, lotes — es esta fórmula con distintos
sombreros.

La fórmula única

tokens/sec ≈ ancho de banda efectivo de memoria ÷ bytes de pesos leídos por token

RTX 4090, 8B Q4_K_M:
  1008 GB/s ÷ 4.9 GB ≈ 205 tok/s de techo teórico
  observado: ~120–150 tok/s (sobrecarga, atención, lecturas de KV)

Tabla de cordura para un caso común (8B en Q4_K_M, flujo único — números
de orden de magnitud, no especificaciones; mide los tuyos):

¿Por qué la brecha entre techo y realidad? Sobrecarga de lanzamiento de
kernels, trabajo de atención que crece con el contexto, y lecturas de la
caché KV encima de los pesos. La fórmula te da el techo;
típicamente realizas el 60–75% de él en flujo único.

Una tarjeta, cuatro modelos

La fórmula también predice cómo se troca el tamaño del modelo contra la
velocidad en hardware fijo. Techo en una tarjeta de ~1,000 GB/s, luego
60–75% realizado (ilustrativo):

Dos lecciones caen por su peso. Duplicar parámetros reduce más o menos a
la mitad la velocidad en la misma tarjeta. Y un 32B en una tarjeta de
24 GB sigue siendo suficientemente rápido para chat — estar limitado por
memoria no es desesperanzador. Ese emparejamiento es por qué las tarjetas
de 24 GB y las cuantizaciones 32B Q4 aparecen juntas constantemente
(véase niveles de GPU).

La cuantización es una función de velocidad, no solo compresión

Misma fórmula, menos bytes: un modelo 8B en fp16 lee ~16 GB por token; en
Q4_K_M lee ~4.9 GB. En la misma tarjeta, Q4 corre aproximadamente 3× la
velocidad de fp16 y cabe donde fp16 no cabe. Por eso las cuantizaciones
clase Q4 son la recomendación por omisión para uso local (véase
cuantización) — la pérdida de calidad es pequeña,
y la ganancia de velocidad es estructural, no incidental.

El contexto te frena

Conforme crece la conversación, cada token nuevo debe además leer la
caché KV de todos los tokens previos — esas lecturas escalan con la
longitud del contexto. Cerca de un contexto vacío un 8B Q4 puede hacer
140 tok/s en una tarjeta clase 4090; a fondo de una sesión de 64k tokens
la misma instalación puede caer a la mitad o un tercio de eso. Los
kernels de atención también dejan de encajar en formas amables con la
caché. Las cargas de contexto largo son donde flash attention y la
cuantización del KV se pagan solas (véase caché KV y
controles del motor).

Una confusión común: «el modelo se volvió más lento conforme avanzaba el
chat» suele ser crecimiento del KV, no el servidor degradándose (véase
caché KV).

MoE: rapidez por capacidad

Los modelos de mezcla de expertos activan solo unos pocos bloques
expertos por token, así que los bytes leídos por token siguen a los
parámetros activos, no a los totales. Un modelo de 30B totales/3B
activos en Q4 lee solo un par de gigabytes por token — decodifica como
un modelo pequeño mientras carga el conocimiento de uno grande. Ese es
todo el atractivo de las familias MoE para uso local (véase familias de
modelos): pagas memoria para almacenar los
expertos, pero ancho de banda solo por los que usas.

Forma concreta a fecha de redacción: la clase Qwen3-30B-A3B lee por token
solo sus ~3B parámetros activos — conocimiento de modelo grande a
velocidad de modelo pequeño, por ~18 GB de VRAM en Q4.

Decodificación especulativa

Empareja un modelo borrador pequeño con el grande objetivo: el borrador
propone k tokens baratos, el objetivo verifica los k en una pasada, y los
tokens aceptados salen con la calidad del objetivo. En cargas casi
voraces — completación de código, JSON, extracción a temperatura baja —
espera 2–3× de aceleración en decodificación. A temperatura alta el
borrador falla más a menudo y la ganancia se encoge. llama.cpp expone
esto con --model-draft y flags de longitud de borrador; los nombres
exactos derivan entre versiones, comprueba --help.

Costes: el borrador debe compartir el tokenizador del objetivo, y ambos
modelos se sientan en memoria.

Paralelismo: la realidad

Dos GPU no te dan 2× un flujo único. El paralelismo de tensores (vLLM
-tp 2) parte cada capa entre tarjetas para rendimiento, al coste de
tráfico de interconexión; el reparto por omisión de llama.cpp es pipeline
(por capas), que ayuda más a la capacidad que a la latencia de flujo
único. Expectativa realista para un buen reparto de dos tarjetas:
1.2–1.6× en flujo único, no 2×. Si alguien promete escalado lineal por
GPU, está vendiendo algo.

Añadir tarjetas sí escala bien la capacidad — esa es la historia de
servidor en concurrencia.

El acantilado de la descarga a CPU

Cuando las capas se quedan en la CPU, la pasada de cada token salta a
través de PCIe (~10–25 GB/s) hacia la RAM del sistema y de vuelta. El
bucle corre a la velocidad de su parte residente más lenta: un modelo con
el 80% de las capas en GPU corre mucho más cerca de la velocidad de CPU
que del «80% de la velocidad de GPU». Si un modelo casi cabe, baja un
paso de cuantización en vez de descargar a medias — véase controles del
motor. La señal delatora de una descarga parcial
accidental son 3–10 tok/s en hardware clase GPU.

El prefill está limitado por cómputo: el TTFT es una medida distinta

Procesar tu prompt es paralelo entre tokens y está limitado por
cómputo, no por ancho de banda — una tarjeta clase 4090 puede hacer
prefill de un 8B Q4 a unos pocos miles de tok/s. Así que un pegado de 12k
tokens cuesta ~3–5 s antes del primer token de salida, aunque la
decodificación después corra a 140 tok/s. El tiempo al primer token y los
tok/s en régimen estable son números distintos midiendo cuellos de botella
distintos; al leer un benchmark, comprueba cuál está mostrando.

Mide los tuyos

Los números en páginas (incluida esta) son techos y rangos. Tu
instalación se mide en dos minutos:

1. Genera ~200 tokens desde un prompt corto; ignora la primera
   ejecución (carga en frío).
2. Toma la decodificación en régimen estable: tokens generados ÷ segundos
   tras el primer token.
3. Anota aparte el tiempo al primer token en un pegado largo — es un
   cuello de botella distinto.

llama-server imprime los tok/s de prompt-eval y de eval por petición; LM
Studio muestra los tok/s de decodificación en vivo; nvidia-smi confirma
que la GPU está realmente ocupada mientras pruebas.

Qué tan rápido se siente

Los umbrales son sorprendentemente bajos porque la velocidad de lectura
humana es solo ~5–10 tok/s — pero esperar una completación a 5 tok/s es
miseria. Siéntelo tú mismo: el simulador renderiza la misma
respuesta a distintas tasas de tokens, y un minuto ahí enseña más que
cualquier tabla.

Por debajo de ~2–3 tok/s una UI en flujo se siente rota y no solo lenta —
la gente cierra la pestaña, así que trátalo como suelo duro para uso
interactivo.

Relacionados: Visión general de hardware · Cálculo de VRAM · Niveles de GPU · Controles del motor