En pocas palabras: La frontera eficiente de inferencia LLM es el conjunto de combinaciones óptimas entre latencia y throughput con GPUs limitadas. Baseten la divide en dos familias: técnicas que negocian un tradeoff (batch size, paralelismo) y técnicas que empujan toda la frontera hacia afuera (kernels, speculative decoding, disaggregation).
La frontera eficiente en inferencia de LLM es el conjunto de combinaciones óptimas entre latencia y throughput cuando corrés un modelo con GPUs limitadas. Baseten publicó en 2024 una guía que ordena la optimización inferencia LLM en dos grupos: técnicas que mueven un tradeoff a lo largo de la frontera y técnicas que empujan toda la frontera hacia afuera.
La frontera eficiente (efficient frontier) es un término que la industria de IA le robó a la economía. Aplicado a inferencia de modelos de lenguaje, describe el rango de combinaciones óptimas entre dos resultados valiosos, la latencia por usuario y el throughput total, dentro de un entorno con recursos limitados. Un deployment está sobre la frontera cuando optimiza un factor manteniendo el otro dentro de los límites aceptables.
En 30 segundos
- Hay dos familias de técnicas: las que negocian un tradeoff (batch size, tipo de paralelismo) y las que expanden la frontera entera (kernels, speculative decoding, disaggregation).
- Batch chico = latencia baja pero costo por token alto; batch grande invierte el resultado. La curva es escalonada, no una recta suave.
- La quantización empuja la frontera y, con formatos como MXFP4 y NVFP4, casi no toca la calidad del modelo.
- Las mejoras se multiplican: 2x en hardware más 2x en software da 4x de serving total, repartible entre latencia y throughput.
- No hay bala de plata: el punto óptimo se descubre a fuerza de sweeps empíricos según cómo sea tu tráfico real.
¿Qué es la frontera eficiente en inferencia de modelos de lenguaje?
Es la línea que marca las combinaciones óptimas cuando negociás entre dos objetivos valiosos con recursos acotados. En inferencia, casi siempre hablamos de latencia contra throughput (y el throughput define el costo). También podés cambiar calidad por throughput, vía quantización, destilación o pruning, o inteligencia por velocidad, ajustando el nivel de razonamiento del modelo.
Baseten separa las herramientas del ingeniero de inferencia en dos tipos. Las primeras hacen un tradeoff entre dos factores para moverte a un punto distinto de la misma frontera. Las segundas corren la frontera completa hacia afuera y generan eficiencia nueva, que después repartís donde más te convenga.
Las dos sirven. Resignar velocidad por usuario te habilita pipelines de batch baratos y de alto volumen. Resignar throughput para ganar velocidad tiene sentido cuando tenés usuarios sensibles a la latencia dispuestos a pagar más. Y empujar toda la frontera, bueno, ese es el premio grande. Cubrimos ese tema en detalle en en nuestra guía sobre Claude.
¿Cómo se relacionan latencia y throughput en el serving de LLM?
Es una relación inversa, y el batch size es la palanca más directa. Un batch es la cantidad de requests que se procesan en paralelo. Con batches chicos, la latencia por usuario es excelente pero generás pocos tokens por GPU, así que el costo por token se dispara. Subís el batch y pasa lo contrario: peor latencia individual, mejor throughput global y menor costo.
Ojo con una cosa que el artículo de Baseten remarca: la frontera es escalonada, no suave. No es una recta prolija entre los dos extremos. Cambios chicos pueden tener impactos enormes, y esos puntos de corte suelen ser poco intuitivos. ¿Se pueden calcular de antemano? En general, no. Se descubren con sweeps empíricos sobre tu tráfico.
Un detalle técnico que ayuda: el continuous batching a nivel de token evita la latencia de esperar a que se arme el batch. O sea, el request no se queda en la cola esperando compañeros. Pero el tamaño configurado del batch sigue mandando sobre la latencia por usuario y el throughput total. Esa parte no la esquivás.
¿Cómo optimizar el paralelismo de GPUs para inferencia?
Elegís el tipo de paralelismo según si priorizás latencia o throughput. En 2026, los LLM miden en cientos de miles de millones o billones de parámetros, así que no entran en una sola GPU y hay que repartirlos. Cómo los repartís cambia el resultado.
Tensor Parallelism (TP) para bajar latencia
Para deployments sensibles a la latencia, subí el Tensor Parallelism. El TP tiene una comunicación all-to-all cara, pero baja las latencias porque esas operaciones vuelan sobre interconexiones de alto ancho de banda como NVLink de NVIDIA. Si tu interconexión es lenta, el beneficio se te evapora.
Expert Parallelism (EP) para las dos cosas
El Expert Parallelism ayuda tanto a latencia como a throughput, según cómo lo escales. Un grado bajo de EP suele asociarse con mejores latencias. Un EP ancho, incluso repartido en un rack entero de GPUs, empuja el throughput hacia arriba. Es la técnica más flexible de las tres. Tema relacionado: tal como explicamos para GPT.
Attention Data Parallelism (ADP) para throughput
El Attention Data Parallelism replica las capas de atención para computarlas en paralelo. Eso sube el throughput del sistema a costa de la velocidad por request. Es la elección clásica cuando lo que te importa es procesar mucho volumen y podés bancarte que cada usuario espere un poco más.
¿La quantización reduce la calidad de los modelos?
Casi no, si usás los formatos correctos. La quantización corre el modelo con menor precisión en pesos, activaciones y/o valores del KV cache, y eso mejora latencia y throughput a la vez. Un modelo quantizado empuja la frontera de serving hacia afuera. El costo aparece en otra frontera nueva: calidad contra eficiencia.
Acá viene lo bueno: esa frontera calidad-eficiencia también es escalonada. Podés ganar muchísima eficiencia de serving con poca o nula caída de calidad, sobre todo con formatos de punto flotante de microescalado como MXFP4 y NVFP4. La “pérdida” que muchos temen, en la práctica, con el formato adecuado es marginal (si es que la notás siquiera).
¿Qué es el speculative decoding y cuánto acelera la inferencia?
Es el proceso de adivinar qué tokens va a generar el modelo y después validar esas apuestas. Cuando el speculative decoding era nuevo, planteaba un tradeoff feo entre latencia y throughput: la especulación era cara, las secuencias eran cortas y las tasas de aceptación bajas, así que solo servía con batches chicos.
Hoy la cosa cambió. Las técnicas modernas todavía compiten por recursos con el loop principal del modelo, lo que limita un poco el batch máximo. Pero rinden tan bien, en especial en generación de código donde las secuencias de salida son bastante predecibles, que suman eficiencia por dos vías: se saltean forward passes completos y bajan la latencia entregando más tokens por segundo por usuario. Ponele que estás generando código repetitivo, la máquina “adivina” casi todo y valida en bloque. Relacionado: similar a lo que describimos en ChatGPT.
¿Para qué sirve separar prefill y decode (P/D disaggregation)?
La P/D disaggregation separa las fases de prefill y decode en workers dedicados, y es una estrategia para deployments de alto volumen. Al correrlas por separado, optimizás cada worker para las características propias de cada fase. Además podés ajustar la proporción entre workers de prefill y de decode según las longitudes de secuencia de entrada y salida y las tasas de cache hit de tu tráfico.
En la práctica, lo más útil de la disaggregation es subir el throughput manteniendo las latencias iguales o un poco mejores. No es magia para todos los casos: si tu volumen es bajo, el overhead de coordinar dos pools de workers probablemente no te compense.
¿Cómo expanden toda la frontera los kernels y el runtime?
Optimizando las operaciones de más bajo nivel. Un kernel CUDA es una función que ejecuta una pieza del proceso de inferencia, por ejemplo una multiplicación de matrices. Si mejorás el rendimiento de cada kernel, y el de un forward pass completo dentro del engine, necesitás menos recursos para generar cada token. Esas ganancias se acumulan a lo largo de todo el stack y corren la frontera.
Lo mejor es que estas técnicas se componen. Duplicar el rendimiento por mejor hardware y a la vez duplicarlo por mejor software da una mejora de cuatro veces en el serving total, según la guía de Baseten. Esa eficiencia extra la repartís como quieras: menos latencia, más throughput, o una mezcla.
Tabla: qué hace cada técnica de optimización
| Técnica | Efecto principal | Tipo |
|---|---|---|
| Batch size chico | Baja latencia, sube costo/token | Mueve el tradeoff |
| Batch size grande | Sube throughput, baja costo | Mueve el tradeoff |
| Tensor Parallelism (TP) | Baja latencia (usa NVLink) | Mueve el tradeoff |
| Expert Parallelism (EP) | Latencia o throughput según ancho | Mueve el tradeoff |
| Attention Data Parallelism (ADP) | Sube throughput, baja velocidad/request | Mueve el tradeoff |
| Quantización (MXFP4/NVFP4) | Mejora latencia y throughput | Expande la frontera |
| Speculative decoding | Más tokens/segundo, saltea forward passes | Expande la frontera |
| P/D disaggregation | Sube throughput, latencia igual o mejor | Expande la frontera |
| Optimización de kernels CUDA | Menos recursos por token, ganancia global | Expande la frontera |
Qué significa para equipos en Latinoamérica
Si estás poniendo un LLM en producción desde la región, el mensaje práctico es simple: primero exprimí las técnicas que expanden la frontera (quantización con MXFP4/NVFP4, kernels afinados, speculative decoding en cargas de código) porque te dan eficiencia gratis, y recién después negociá el tradeoff de latencia contra throughput según tu tráfico real. Para el resto de tu infraestructura web, hosting y dominios en Argentina, donweb.com es una opción local. La GPU es cara en todos lados, así que cada punto de eficiencia que ganás se nota en la factura.
Errores comunes al optimizar inferencia de LLM
- Creer que la frontera es una recta suave. Es escalonada. Un cambio mínimo de batch size puede tirarte a otro punto de rendimiento. Corregí con sweeps empíricos, no con intuición.
- Copiar la config de otro sin mirar tu tráfico. El punto óptimo depende de tus longitudes de secuencia, tus cache hit rates y tu tolerancia a latencia. La receta ajena rara vez transfiere.
- Descartar la quantización por miedo a perder calidad. Con formatos de microescalado la caída suele ser marginal. Medí calidad antes y después en tu caso, no asumas lo peor.
- Elegir Tensor Parallelism sin interconexión rápida. El TP baja latencia solo si tenés NVLink u otro enlace de alto ancho de banda. Sin eso, la comunicación all-to-all te come la ganancia.
Preguntas Frecuentes
¿Qué es la frontera eficiente en inferencia de LLM?
Es el rango de combinaciones óptimas entre dos resultados valiosos, como latencia y throughput, cuando corrés un modelo con recursos limitados. El término viene de la economía. Un deployment está sobre la frontera cuando optimiza un factor manteniendo el otro dentro de los límites aceptables.
¿Cómo elijo entre latencia baja y alto throughput?
Depende de tu tráfico. Para usuarios sensibles a la latencia dispuestos a pagar más, usá batches chicos y Tensor Parallelism. Para pipelines de batch de alto volumen y bajo costo, subí el batch size y sumá Attention Data Parallelism. El punto exacto se descubre con sweeps empíricos. Esto se conecta con lo que analizamos en como documentamos sobre Gemini.
¿La quantización baja la calidad del modelo?
Poco o nada con los formatos adecuados. Formatos de punto flotante de microescalado como MXFP4 y NVFP4 permiten grandes ganancias de eficiencia con caída de calidad marginal. Aun así, conviene medir calidad antes y después en tu caso concreto porque la frontera es escalonada.
¿Cuánto acelera el speculative decoding?
Suma eficiencia por dos vías: entrega más tokens por segundo por usuario y saltea forward passes completos. Rinde especialmente bien en generación de código, donde las secuencias de salida son predecibles. Todavía compite por recursos con el loop principal, así que limita un poco el batch máximo.
¿Qué diferencia hay entre mover el tradeoff y expandir la frontera?
Mover el tradeoff te reubica en otro punto de la misma frontera, ganando en un factor a costa del otro (batch size, tipo de paralelismo). Expandir la frontera genera eficiencia nueva que repartís donde quieras (quantización, kernels, disaggregation). Las dos familias sirven y se combinan.
Conclusión
La guía de Baseten deja un marco mental claro para pensar la optimización inferencia LLM: hay técnicas que negocian tradeoffs y técnicas que corren toda la frontera. Lo que cambió respecto de hace unos años es que las segundas maduraron. La quantización con MXFP4/NVFP4 casi no toca la calidad, y el speculative decoding pasó de ser un experimento caro a rendir en producción, sobre todo en código.
¿Por dónde empezar? Primero las técnicas que expanden la frontera, porque dan eficiencia sin costo de tradeoff. Después ajustás batch size y paralelismo según tu tráfico real, midiendo con sweeps. Y acordate del efecto multiplicador: mejoras que se componen convierten un 2x más otro 2x en un 4x total. Eso, en GPUs caras, es plata.