Latency, throughput, rate limits y batch — cómo se relacionan en producción

Estos cuatro conceptos se confunden constantemente porque están entrelazados, pero cada uno responde una pregunta distinta.

Las cuatro preguntas

Concepto	Pregunta que responde	¿Quién lo controla?
Latency	¿Cuánto tarda una solicitud individual en completarse?	Resultado — no se ajusta directamente
Throughput	¿Cuántas solicitudes procesa el sistema en total por unidad de tiempo?	Resultado — no se ajusta directamente
Batch size	¿Cuántas solicitudes se procesan juntas en una misma pasada?	Se configura (solo si autohospedas inferencia)
Rate limit	¿Cuál es el techo máximo permitido en una ventana de tiempo?	Un tercero lo impone (proveedor), o tú internamente

Latency y throughput son mediciones. Batch size y rate limit son palancas y restricciones.

Batch size: la palanca que mueve throughput y latency en direcciones opuestas

Una GPU es masivamente paralela; procesar una sola solicitud desperdicia capacidad. Agrupar solicitudes en un lote aprovecha esa capacidad ociosa. Trade-off mecánico:

Subir el batch → sube el throughput (menos capacidad ociosa)
Subir el batch → sube la latency individual (cada solicitud comparte la pasada de cómputo)

Esta perilla solo existe si controlas la capa de inferencia (autohospedada). Con una API alojada, el proveedor hace batching internamente mezclando tráfico de miles de clientes.

Ejemplo ilustrativo (no real): batch 1 → 9 req/s a 107ms; batch 8 → 51 req/s a 156ms; batch 64 → 117 req/s a 548ms. El throughput crece con rendimientos decrecientes (la GPU se acerca a su límite de cómputo); la latency crece de forma sostenida y se acelera hacia el final.

Rate limit: no es lo mismo que throughput, es su techo

Throughput es una medida. Rate limit es una política. El rate limit le pone un techo al throughput — pero el throughput real puede estar muy por debajo del límite o exactamente topado en él.

Es como un límite de velocidad en carretera: el letrero no dice qué tan rápido vas, solo pone un techo.

Casi siempre son dos límites: RPM (requests per minute) y TPM (tokens per minute) — puedes chocar contra cualquiera primero. Solicitudes largas pueden topar TPM mucho antes de acercarse al límite de RPM.

Ejemplo con números concretos: rate limit de 1,000 solicitudes/min. Demanda por hora: 8h:600, 9h:1500, 10h:900, 11h:500, 12h:300, 13h:250, 14h:400, 15h:600, 16h:450, 17h:300, 18h:150. A las 9am, la demanda (1,500) supera el límite (1,000) — las 500 solicitudes excedentes se encolan o se rechazan, y quien mandó su solicitud en ese pico experimenta más latency que uno que la mandó a las 11am.

Cómo se conectan los cuatro conceptos, de principio a fin

La demanda es lo que el negocio genera — no se controla directamente, solo se prevé.
El rate limit es el techo impuesto sobre esa demanda.
Cuando demanda ≤ rate limit → el throughput simplemente iguala la demanda.
Cuando demanda > rate limit → el exceso se encola, y ese tiempo de cola se convierte en latency extra.
El batch size (si autohospedado) decide cuánta capacidad real tiene el sistema para absorber picos antes de necesitar encolar.

Diseñando contra esto: opciones reales

Encolar con prioridad: solicitudes síncronas (usuario esperando) primero; asíncronas (procesamiento nocturno) después.
Comprar más rate limit: tiers empresariales suelen ofrecer RPM/TPM mucho más altos.
Aplanar la demanda: escalonar notificaciones o cachear resultados recientes para bajar el pico sin tocar infraestructura.
Subir el batch propio (solo si autohospedado): sube el techo real de absorción, a costa de latency.

Un caso aplicado: de 10 usuarios a 1,500 vendedores

Con 10 usuarios evaluando clientes y generando correos: el reto es criterio y calidad, no throughput. Arquitectura recomendada: App interna (plugin CRM/correo) → Orquestación (arma el prompt con reglas) → ramifica a Datos del cliente (CRM/DB) y Modelo de IA (API alojada) → Revisión humana antes de enviar. No conviene autohospedar nada — una API alojada ya resolvió inferencia a una escala que 10 usuarios nunca alcanzarían.

Con 1,500 vendedores, el problema cambia de naturaleza: throughput, costo, y gobernanza se vuelven reales.

La “revisión humana” como aprobador separado ya no escala — se convierte en filtro automático (guardrails) + autoaprobación del propio vendedor antes de enviar.
Rate limits del proveedor se topan en picos (ej. todos revisando su lista a las 9am).
El costo por token, multiplicado por 1,500 usuarios diarios, se vuelve una línea de presupuesto real.
No se puede auditar manualmente cada interacción — se necesita observabilidad real.

Arquitectura escalada: App/CRM → Gateway de IA (límite, caché, enrutamiento — la pieza nueva que antes no hacía falta) → ramifica a Modelo rápido (evalúa clientes) y Modelo capaz (redacta correos) → Guardrails y revisión (chequeo automático + aprobación del vendedor).

Piezas nuevas y por qué existen:

Gateway de IA: rate limiting (encolar/espaciar solicitudes), caché de prompts (reutilizar el bloque de instrucciones compartido por los 1,500 vendedores en vez de reprocesarlo cada vez), enrutamiento entre modelos.
Dos niveles de modelo: evaluar clientes (tarea más estructurada) puede resolverse con un modelo barato/rápido, posiblemente afinado específicamente; redactar correos (tono/calidad importan para la reputación) justifica un modelo más capaz.
Guardrails automáticos: revisión ya no es “alguien más aprueba” — es un filtro automático (¿menciona datos indebidos? ¿inventó una cifra?) seguido de que el propio vendedor apruebe antes de enviar.

Lo que falta en el diagrama pero importa igual: observabilidad y costos por equipo/vendedor; auditoría por muestreo (no revisión total) en vez de revisar cada correo; redundancia ante caídas del proveedor de API.

Síncrono vs. asíncrono, la distinción que cambia el diseño:

	Evaluación en vivo (vendedor esperando)	Carga nocturna de leads nuevos
Patrón	Síncrono	Asíncrono
Latency tolerada	Baja (segundos)	Alta
Prioridad	Latency baja para el modelo rápido	Throughput máximo
Config de batch (si autohospedado)	Batch pequeño/moderado	Batch grande

No hay una sola configuración de batch en el sistema — el mismo modelo rápido podría correr con batch conservador en horario laboral y batch agresivo durante la noche.

Prompt caching / KV cache aterrizado aquí: los 1,500 vendedores comparten las mismas instrucciones base — contexto idéntico repetido 30,000 veces al día. Con prompt caching (API alojada) o KV cache reutilizado (autohospedado), ese bloque se procesa una vez y se reutiliza, reduciendo costo y latency directamente.

Cuándo reconsiderar self-hosting: la pregunta correcta es de volumen real, no de número de usuarios — ¿cuántas llamadas por día, de qué tamaño? Si la tarea más frecuente (evaluación) genera decenas de miles de llamadas diarias con un modelo pequeño, el cálculo de costo puede inclinarse hacia autohospedar ese modelo específico (ej. con vLLM), mientras la redacción de correos (menos frecuente, necesita más calidad) se queda en la API alojada. Patrón híbrido: cada tarea con la infraestructura que su volumen y necesidad de calidad justifican.