Cuántos tokens por segundo necesitas realmente — y por qué esa no es la pregunta correcta

Has diseñado un sistema agéntico. Tienes el prompt calibrado, los evals funcionando, y el flujo de agentes probado en local. Llega el momento de producción, y la primera pregunta es: “¿qué hardware necesito?” Y la segunda: “¿cuántos tokens por segundo necesito?”

La respuesta corta: depende de tu caso de uso. La respuesta larga, que es la que importa: tokens por segundo es solo una métrica, y no la más importante.

El número mínimo depende completamente del caso de uso

No existe un umbral universal de tokens/segundo (tok/s) — depende de si hay un humano esperando o no.

Caso de uso	Rango típico usable	Por qué
Chat interactivo	10–20 tok/s	La velocidad a la que una persona puede leer mientras se genera
Programación interactiva	30–40 tok/s	El código tiene mucha repetición estructural; más rápido se siente más fluido
Programación agéntica intensiva	60–100+ tok/s	Múltiples llamadas a herramientas acumulan latencia; cada tok/s extra se nota
Agente desatendido / corridas nocturnas	Menos de 1 tok/s puede bastar	Sin humano esperando, importa el costo y la fiabilidad, no la velocidad bruta
RAG con muchos documentos	>10 tok/s	El prefill (procesar los documentos) suele dominar la latencia total
Procesamiento por lotes	Depende del volumen	La velocidad total (tokens/hora) importa más que la velocidad por solicitud

La orientación práctica que se desprende de esta tabla: si hay un humano esperando, apuntar a más de 20 tok/s tiene sentido; si es un proceso de fondo, vale más la pena optimizar por costo que por velocidad.

Tokens por segundo no basta: otras métricas que importan tanto o más

Un modelo puede generar a 50 tok/s y sentirse insoportablemente lento si tarda 30 segundos en producir el primer token.

Time to First Token (TTFT): el tiempo desde que envías el prompt hasta el primer token de respuesta. Para prompts largos (un documento de 10,000 tokens), el TTFT puede ser de 5-10 segundos — el usuario lo percibe como “lentitud”, aunque luego genere rápido. Se optimiza con prefix caching (ver abajo).

Prefill — velocidad de procesar el prompt: antes de generar, el modelo tiene que calcular las keys/values de atención para todo el prompt de entrada. En modelos grandes, esto puede dominar la latencia total. Modelos con Flash Attention (Parte I, capítulo de atención) reducen drásticamente el tiempo de prefill.

KV cache y contexto largo: el modelo guarda las claves y valores de tokens anteriores para no recalcularlos — pero la caché crece con el contexto, y la generación se ralentiza. Un modelo puede producir 50 tok/s con contexto casi vacío, y desacelerar dramáticamente después de 50,000 tokens acumulados — reportar tok/s sin especificar la longitud de contexto puede ser engañoso. La KV cache cuantizada (Q8, Q4) reduce memoria y acelera en contextos largos.

Prefix caching: si muchos prompts comparten el mismo prefijo (un prompt de sistema largo, repetido en cada llamada), ese cómputo puede cachearse y reutilizarse — reduciendo drásticamente TTFT y costo. Servicios como Anthropic, OpenAI, y backends como vLLM lo soportan. Si tu sistema reutiliza el mismo prompt de sistema en muchas consultas, esta es de las optimizaciones más rentables disponibles.

Latencia de llamadas a herramientas (flujos agénticos): un agente que llama herramientas vía MCP suma tiempo de red, procesamiento, y espera en cada llamada. La generación de tokens puede ser excelente, pero si cada llamada a herramienta tarda 500ms, la experiencia total es lenta. Se mitiga ejecutando herramientas en paralelo cuando sea posible (patrón paralelo, Capítulo 6b) y eligiendo herramientas de baja latencia.

Tiempo total para completar la tarea: al final, importa cuánto tarda la tarea completa, no cada token individual.

Ejemplo trabajado: un agente ReAct hace 4 vueltas (4 llamadas al modelo), cada una generando 200 tokens. Eso es 800 tokens totales — a 50 tok/s, son 16 segundos de generación pura. Si cada llamada a herramienta tarda 300ms y hay 4 llamadas, suma 1.2 segundos adicionales. El tiempo total de la tarea es de ~17 segundos, incluso con una velocidad de generación que, aislada, se ve excelente. La lección: no optimices tok/s en aislamiento — mide el tiempo de extremo a extremo de tu flujo agéntico completo.

El motor de inferencia importa tanto como el hardware

Backend	Qué es	Cuándo usar
GGUF (llama.cpp)	Cuantización y ejecución eficiente en CPU y GPU	Modelos grandes en hardware limitado; soporte amplio
MLX (Apple Silicon)	Backend optimizado para chips M de Apple	Nativo y rápido en Mac
vLLM	Servidor de inferencia con batching y prefix caching	Producción a escala, múltiples usuarios simultáneos
TGI (Hugging Face)	Similar a vLLM, integrado al ecosistema HF	Alternativa a vLLM con buen soporte de modelos populares
Decodificación especulativa / MTP	Un modelo pequeño genera candidatos, uno grande los verifica	Puede acelerar 2-3×, con complejidad adicional

Ejemplo real: la misma RTX 3090 puede dar ~70 tok/s con un modelo de 27B + MTP en un backend optimizado, contra ~40 tok/s con el mismo modelo en otro backend sin esa optimización. Vale la pena probar distintos backends con tu propio modelo y caso de uso antes de invertir en hardware nuevo — a veces, la mejora más barata es de software, no de silicio.

El espectro de hardware

GPU de consumo (RTX 3090/4090/5090): corre modelos 27B-35B cuantizados con contexto moderado. RTX 3090 (24GB): ~70 tok/s con un 27B + MTP. RTX 4090 (24GB): ~40 tok/s con un 36B Q4 GGUF. RTX 5090 (32GB): >100 tok/s con modelos optimizados. Ventaja: mejor relación rendimiento/precio para interactividad. Desventaja: VRAM limitada — modelos >70B requieren cuantización agresiva o simplemente no caben.

Apple Silicon (Mac Studio/Pro, M4/M5 Max): corre modelos más grandes (70B+) gracias a memoria unificada de 64-128GB. M5 Max: ~40 tok/s con precisión de 8 bits vía MLX. Ventaja: modelos que no caben en una GPU de 24GB, sin copia entre CPU/GPU. Desventaja: más lento que GPU dedicada para modelos de tamaño comparable.

Multi-GPU (estaciones de servidor): modelos gigantes (70B+, 100B+) con contexto largo — 4-8 tarjetas de gama alta. Ventaja: máxima capacidad. Desventaja: costo y complejidad — deja de ser una configuración de “gaming” y se convierte en un servidor de IA real.

Modelos secundarios especializados — el patrón más accionable: combinar varios modelos en vez de buscar uno perfecto. Un modelo rápido (~27B) para implementación y cambios rutinarios; uno grande (~70B+) para planeación y debugging difícil; modelos especializados pequeños (~7B) para resumen, voz a texto, o clasificación. Ejemplo: usar un modelo mediano para el 80% de las tareas (rápido y barato), reservando un modelo grande solo para el 20% que realmente lo necesita.

El debate Q4 vs. Q6

La cuantización reduce el tamaño del modelo a costa de algo de precisión — el debate de qué nivel usar es constante en la comunidad. En términos relativos: Q4 comprime más y es más rápido, con algo más de pérdida de precisión; Q6 comprime menos, es algo más lento, y preserva más fidelidad; Q8 se acerca a la precisión completa, al costo de más memoria y velocidad reducida. Las cifras exactas de “cuánta” precisión se pierde varían mucho según el modelo específico y la tarea — no hay un porcentaje universal confiable que aplique a todos los casos.

¿Q4 es suficiente? Depende de la tarea: para chat, resumen, y razonamiento general, suele ser prácticamente indistinguible de precisión completa. Para código matemático o razonamiento complejo, Q6 puede marcar una diferencia real. Para tareas donde la precisión numérica es crítica (cálculos financieros), conviene precisión completa o Q8.

La decisión práctica: en una GPU de 24GB, Q4 puede permitir que todo el modelo quepa en VRAM, mientras Q6 podría forzar un contexto más pequeño o descarga a CPU. No hay respuesta universal — probar ambos con tareas específicas propias sigue siendo la única forma confiable de decidir. En la práctica, Q4 suele ser un punto de partida razonable para la mayoría de los casos; si aparecen fallos consistentes en ciertas tareas, vale la pena escalar a Q6 u 8 bits.

Nube vs. local: el debate que nadie quiere tener

Opción	Ventajas	Desventajas
API (OpenAI, Anthropic)	Sin mantenimiento, escala automática, modelos de última generación	Costo por token, consideraciones de privacidad, dependencia del proveedor
Nube gestionada (Bedrock, Vertex)	Más control que una API pura, menos que local; integración con el resto de tu infraestructura cloud	Costo, complejidad de configuración, dependencia del proveedor
Local (servidor propio)	Privacidad total, costo predecible si ya tienes el hardware	Mantenimiento, escalado, necesidad de expertise en infraestructura

La decisión práctica: para equipos pequeños o prototipos, una API suele ser más barata que comprar hardware y más rápida de implementar. Para escala media o datos sensibles, una nube gestionada o un servidor local pequeño (1-2 GPUs) equilibra control y costo. Para escala grande o datos altamente sensibles, un servidor local multi-GPU da control total. En general, conviene no invertir en hardware propio hasta confirmar —con uso real medido— que el costo lo justifica; empezar con una API y decidir después suele ser el camino de menor riesgo.

El marco de decisión completo

Pregunta	Si SÍ…	Si NO…
¿Hay un humano esperando la respuesta?	Apunta a >20 tok/s, prioriza TTFT bajo	Prioriza costo por token, no velocidad
¿El modelo necesita contexto largo (>32K)?	Considera Apple Silicon o multi-GPU (más memoria)	Una GPU de 24GB puede bastar
¿El modelo tiene más de 70B parámetros?	Multi-GPU o Apple Silicon (memoria unificada)	GPU de 24GB con cuantización puede bastar
¿La tarea requiere máxima precisión?	Usa Q6/Q8 o precisión completa	Q4 suele ser suficiente
¿Tienes un equipo de infraestructura propio?	Local puede dar más control y menor costo a largo plazo	Nube o API implican menos mantenimiento
¿Tus datos son altamente sensibles?	Local o nube privada	API puede ser aceptable con contratos de confidencialidad adecuados
¿Esperas escalar a cientos de usuarios?	Servidor dedicado (vLLM, TGI) con batching	Una sola GPU puede bastar para pocos usuarios

Conexión con la Parte II: la misma tensión, aplicada a rendimiento

La tensión fundamental de la Parte II — autonomía y verificación crecen juntas — se manifiesta aquí en términos de rendimiento: un agente con alta autonomía (ReAct, coordinador) hace más llamadas al modelo, multiplicando latencia y costo — cada vuelta de razonamiento suma TTFT y generación. Un agente con baja autonomía (secuencial, paralelo) es más predecible y más rápido, pero menos flexible.

Retomando el ejemplo trabajado de arriba: un agente ReAct de 5 vueltas puede tardar 20 segundos aunque genere a 50 tok/s. ¿Vale la pena la flexibilidad? Depende del caso — si el usuario espera en vivo, un pipeline secuencial más rápido puede ser preferible; si la tarea es genuinamente compleja y no hay alternativa, la flexibilidad de ReAct se vuelve necesaria a pesar del costo en tiempo.

En la Parte III seguiremos viendo cómo monitorear estas métricas en producción, detectar deriva de rendimiento, optimizar costo con batching y prefix caching, y mantener seguridad incluso cuando el rendimiento se degrada.

Resumen del capítulo

• No hay un número mágico de tok/s — depende de si hay un humano esperando y de la complejidad de la tarea.
• Tok/s no es la única métrica: TTFT, prefill, contexto largo, llamadas a herramientas, y tiempo total de tarea importan tanto o más.
• El software importa tanto como el hardware — probar distintos backends antes de comprar es casi siempre rentable.
• El espectro de hardware es amplio: GPU de consumo (rápida, memoria limitada), Apple Silicon (más memoria, más lento), multi-GPU (máxima capacidad).
• Combinar modelos —uno rápido para la mayoría de tareas, uno grande solo cuando hace falta— suele ser más eficiente que buscar un solo modelo perfecto.
• Empezar con una API y migrar a infraestructura propia solo cuando el costo o la privacidad lo justifiquen reduce el riesgo de sobre-invertir temprano.

La pregunta correcta no es “¿qué modelo produce tokens más rápido?” — es “¿qué configuración completa el trabajo de forma precisa, confiable, y lo suficientemente rápido como para no pasar la sesión esperando o arreglando lo que rompió?”