El trilema de la inferencia: latencia, throughput y costo — el arte de elegir qué sacrificar

En los capítulos anteriores vimos cómo optimizar la inferencia (destilación, cuantización, batching, KV cache) y cómo gestionar la demanda en producción (latency, throughput, rate limits). Pero hay un problema de fondo que ninguna optimización resuelve por sí sola: no puedes optimizar las tres cosas a la vez.

El trilema: no puedes optimizar las tres a la vez

Dimensión	Qué significa	Qué pasa si la priorizas
Latencia baja	Cada solicitud individual es rápida	Necesitas sobre-aprovisionar capacidad → costo alto
Throughput alto	Muchas solicitudes por segundo	El batching agresivo añade latencia → latencia alta
Costo bajo	Poco gasto en hardware/inferencia	Aceptas throughput más bajo, latencia más alta, o ambas

Ejemplo ilustrativo (patrón cualitativo típico de un modelo de 70B en GPUs de gama alta, no cifras medidas de un despliegue específico):

Configuración	Latencia (p95)	Throughput (req/s)	Costo relativo
Batch=1, sin optimizar	Baja	Bajo	Base
Batch=64, optimizado	Alta	Alto	Igual (mismo hardware)
2× GPUs, batch=1	Baja	Medio	El doble
Modelo más pequeño	Muy baja	Muy alto	Mucho menor (pero con menor calidad)

Ninguna configuración gana en las tres dimensiones a la vez. El trilema es real: siempre hay que elegir qué sacrificar.

Por qué la inferencia de LLMs rompe los paradigmas normales de software

Son stateful (tienen estado): en una API REST típica, cada solicitud es independiente. En un LLM, el contexto crece con cada token generado — la KV cache (capítulo anterior) almacena el estado de la atención para todos los tokens previos. Esto significa que no puedes balancear carga enviando cada solicitud a cualquier réplica indistintamente (la caché de cada réplica es diferente), y cambiar de réplica a mitad de generación implica perder ese estado.

Son memory-bound (limitados por memoria), no compute-bound: en la mayoría del software, el cuello de botella es el cómputo. En LLMs, es el ancho de banda de memoria — el modelo pesa gigabytes, y cada token generado requiere mover todos esos pesos desde la memoria al procesador. El tiempo de mover los pesos domina el costo, no las operaciones matemáticas en sí. Por eso una GPU más rápida en FLOPS ayuda poco si el ancho de banda de memoria no mejora, la cuantización acelera reduciendo cuánto hay que mover, y el batching funciona compartiendo ese costo fijo entre varias solicitudes.

Depende íntimamente del hardware físico: el rendimiento no es solo “GPU A es más rápida que GPU B” — depende de la topología de interconexión (NVLink, PCIe), el ancho de banda de memoria (HBM vs. GDDR), el tamaño de la caché L2, y la versión de CUDA/driver. Dos GPUs del mismo modelo pueden rendir distinto según la placa base y la refrigeración.

Las cuatro decisiones de ingeniería que definen el techo de rendimiento

Arquitectura del modelo: denso vs. MoE

Tipo	Descripción	Implicación para inferencia
Denso	Todos los parámetros se activan por token (70B → mover ~140GB de pesos en FP16 por paso)	Cuello de botella = ancho de banda de memoria; más simple de desplegar
MoE (Mixture of Experts)	Solo una fracción se activa por token (ej. un modelo de 671B total con 37B activos)	Menos pesos activos por token, pero requiere comunicación entre GPUs — más complejo

Un modelo denso de 70B no cabe en FP16 en una sola GPU de 80GB (necesita ~140GB) — hace falta cuantización o múltiples GPUs. Un MoE grande necesita varias GPUs de entrada, pero cada token activa solo una fracción de los parámetros totales, lo cual puede ser más rápido en ciertas tareas pese al tamaño total mayor. Con una sola GPU, un denso cuantizado suele ser la opción más simple; con un clúster disponible, un MoE puede ser más eficiente.

Cuantización, profundizando

Precisión	Tamaño relativo (ej. modelo 70B)	Velocidad relativa	Pérdida de precisión (orden de magnitud)
FP16/BF16	140GB (base)	1×	Ninguna
FP8	~70GB	1.5-2×	Muy pequeña
INT4 (Q4)	~35GB	2-3×	Perceptible en tareas exigentes
INT4 + adaptador entrenado con QLoRA	~35GB	2-3×	Variable; el formato de servicio y el fine-tune deben evaluarse por separado

Nota sobre las cifras de pérdida de precisión: los porcentajes exactos varían mucho según modelo, tarea, y método de cuantización específico — no existe un número universal confiable. La relación de orden (FP16 sin pérdida < FP8 pérdida mínima < INT4 pérdida más notable) sí es un patrón consistente y bien documentado.

FP8 suele ser el punto de partida razonable para despliegues en hardware de producción compatible — buen equilibrio entre memoria y precisión. INT4 conviene cuando el hardware es limitado, siempre probando antes de confiar en tareas críticas.

Estrategia de paralelismo

Estrategia	Qué hace	Mejor para	Efecto en latencia
Paralelismo de tensores	Divide las capas del modelo entre GPUs	Minimizar latencia en modelos que no caben en una sola GPU	Reduce latencia por solicitud
Paralelismo de expertos	Distribuye los “expertos” de un MoE en distintas GPUs	Despliegue de MoE a gran escala	Alta eficiencia, menos comunicación innecesaria
Paralelismo de datos	Réplicas completas del modelo, cada una procesando solicitudes distintas	Maximizar throughput total	No acelera la latencia individual

Ejemplo ilustrativo (patrón típico, no una medición específica): un modelo de 70B en 2 GPUs con paralelismo de tensores tiende a dar menor latencia individual pero throughput más modesto; el mismo modelo con paralelismo de datos tiende a dar throughput notablemente mayor a costa de latencia individual más alta. La elección práctica: paralelismo de tensores cuando la latencia importa más, paralelismo de datos cuando el throughput importa más, y paralelismo de expertos específicamente cuando se despliega un MoE.

Batching y el “codo de la curva”

Cargar los pesos del modelo es un costo fijo por cada paso de generación — el batching lo amortiza repartiendo ese costo entre varias solicitudes procesadas juntas.

Ejemplo ilustrativo (patrón típico de comportamiento, no una medición de un benchmark específico):

Batch size	Latencia p50	Throughput (req/s)	Zona
1	Muy baja	22	Memory-bound
4	Baja	83	Memory-bound
8	Baja	154	Buen equilibrio
16	Moderada	258	El codo empieza
32	Media-alta	376	Pico de throughput
64	Alta	356	El throughput ya no crece — empieza a bajar
128	Muy alta	284	Compute-bound — el throughput cae por debajo del pico

Un matiz importante que esta tabla revela, y que vale la pena resaltar: pasado el codo, el throughput no solo deja de crecer — en este patrón, cae. No es solo “rendimientos decrecientes”, es directamente contraproducente seguir aumentando el batch más allá de cierto punto. Encontrar el codo de la curva (el punto donde el throughput deja de mejorar) es la configuración de batch óptima para tu hardware específico — y confirmar dónde está ese punto requiere medir en tu propio sistema, no asumir un valor genérico.

Las cuatro dimensiones reales del costo

El costo de un sistema de IA no es solo el precio de las GPUs:

Dimensión	Qué es	El riesgo oculto
CapEx	Costo de hardware	GPUs con interconexión rápida suelen venderse en bloques fijos — no puedes comprar “media unidad”
OpEx	Energía y refrigeración	Pagas la factura de hardware aunque no se use — el “impuesto por inactividad”
Costo de oportunidad	Capacidad ociosa en tráfico intermitente	Cada minuto sin procesar tokens es capacidad ya pagada y desperdiciada
Costo de ingeniería	Talento para configurar y mantener el sistema	Tiempo caro buscando la configuración óptima — el “impuesto de benchmarking”

Ejemplo ilustrativo de orden de magnitud (no cifras verificadas de un caso real — la estructura del argumento es lo que importa, no los números exactos): una API alojada puede tener costo de hardware nulo pero costo de integración notable; un despliegue autohospedado con pocas GPUs tiene costo de hardware y operación moderados; un despliegue autohospedado grande tiene costo de hardware alto, y el costo de ingeniería para operarlo bien puede terminar siendo comparable entre las tres opciones, incluso cuando el costo de hardware es muy distinto. La lección real, independiente de las cifras exactas: el hardware más barato en el papel rara vez es el más rentable una vez que se factoriza el talento necesario para operarlo bien — a veces la API resulta más barata a largo plazo, aunque el costo por token individual sea más alto.

Dos mundos, dos estrategias completamente distintas

Mundo sensible a la latencia (chatbots, agentes en tiempo real): la prioridad es que el usuario no espere. Métricas clave: TTFT y latencia entre tokens. Estrategias: paralelismo de tensores, batches pequeños (1-8), decodificación especulativa, chunked prefill.

Mundo sensible al throughput (generación masiva offline, resúmenes por lotes): la prioridad es procesar el máximo de datos al mínimo costo. Métrica clave: tokens por dólar. Estrategias: batches grandes, paralelismo de datos, tratar el encolamiento como un activo (mantener cola constante asegura máxima utilización de GPU), no como un fallo.

Marco de 7 pasos para elegir la configuración correcta

1. Caracterizar la carga: ¿cuántas solicitudes por segundo en pico? ¿cuál es el SLO de latencia? ¿qué tamaño tienen los prompts y respuestas típicos?
2. Elegir modelo y cuantización: el modelo más pequeño que cumpla la tarea; FP8 como estándar cuando el hardware lo soporte, INT4 solo si el hardware lo exige y ya probaste que la pérdida es aceptable.
3. Medir en hardware real: benchmarks propios en al menos dos configuraciones — nunca confiar en números publicados sin verificar en tu propio sistema.
4. Localizar el codo de la curva: el punto donde el sistema pasa de memory-bound a compute-bound — el límite útil real de tu configuración.
5. Dimensionar con margen: réplicas para el pico esperado, con buffer adicional para picos inesperados.
6. Calcular el costo total real: CapEx + OpEx + costo de ingeniería, comparado contra el costo de una API alojada si existe la alternativa.
7. Autoescalar con criterio: reducir réplicas en horas valle, aceptando la latencia de arranque en frío al escalar hacia arriba.

Conexión con la Parte II: los agentes multiplican el trilema

Arquitectura (Parte II)	Impacto en el trilema	Recomendación
Agente único	Menos llamadas al modelo → menor costo y latencia	Úsalo cuando la tarea lo permita
ReAct (múltiples vueltas)	Cada vuelta añade latencia y costo — el trilema se multiplica	Limita el número de vueltas; usa un modelo rápido para ellas
Coordinador	Añade una llamada extra para clasificar	Usa un modelo barato específicamente para esa clasificación
Multi-agente (domótica)	Múltiples agentes = múltiples llamadas, cada una afectando el trilema	Ejecuta en paralelo cuando sea posible; varía el tamaño de modelo según la tarea de cada agente
Human-in-the-loop	La espera humana domina la latencia total, no la inferencia	Permite configuraciones de batch más agresivas, porque la latencia de inferencia deja de ser el cuello de botella crítico

El caso de los 1,500 vendedores, revisitado: el modelo rápido de evaluación de clientes prioriza throughput y costo (autohospedado, batch grande en horas valle); el modelo capaz de redacción de correos prioriza calidad y latencia, porque el vendedor espera la respuesta (vía API, o autohospedado con paralelismo de tensores). Cada pieza del sistema se ubica en un punto distinto del mismo triángulo, según lo que esa pieza específica necesita.

El valor para consultoría

Cuando alguien pregunta “¿qué modelo es mejor?”, la respuesta honesta suele ser: no es una pregunta de modelo, es una pregunta de trilema. La conversación productiva es: “dado tu patrón real de tráfico, tu tolerancia a latencia, y tu presupuesto, ¿en qué punto del trilema deberíamos pararnos, y qué configuración específica nos lleva ahí?”

Diagnóstico rápido: si el sistema es lento, medir TTFT y tok/s — probablemente falta optimización de inferencia. Si es caro, medir el costo por solicitud — probablemente convenga destilación o un modelo más pequeño. Si no escala, medir el rate limit y el comportamiento del batching — probablemente haga falta batching continuo o más réplicas. No hay una respuesta universal — hay un proceso de diagnóstico que depende del caso específico.

Resumen del capítulo

• El trilema es real: latencia, throughput, y costo no se optimizan los tres a la vez — hay que decidir conscientemente qué sacrificar.
• Los LLMs son diferentes de software tradicional: tienen estado, están limitados por memoria (no por cómputo puro), y dependen íntimamente del hardware físico.
• Cuatro decisiones definen el techo de rendimiento: arquitectura del modelo (denso vs. MoE), cuantización, estrategia de paralelismo, y el punto óptimo de batching.
• El costo real tiene cuatro dimensiones, no solo el precio de las GPUs — y el hardware más barato en el papel no siempre es el más rentable en la práctica.
• Existen dos mundos con estrategias opuestas: optimizar para latencia (interactivo) u optimizar para throughput (procesamiento masivo) — rara vez ambos a la vez.
• Un marco de 7 pasos ayuda a elegir la configuración correcta: caracterizar, elegir, medir, localizar el codo, dimensionar, calcular costo total, y autoescalar.
• Los agentes de la Parte II multiplican el impacto del trilema — más autonomía casi siempre significa más llamadas, y por tanto más presión sobre las tres esquinas del triángulo.

La pregunta final nunca es “¿qué configuración es la mejor?” en abstracto — es “¿qué configuración es la mejor para mi caso de uso, con mis restricciones de presupuesto y latencia?” La respuesta siempre es un equilibrio consciente, no una solución perfecta.