Elige el stack de LLM más barato que cumpla tu latencia p95

El compromiso es aritmético, no de gusto: el coste por token baja cuando los tokens por segundo de GPU suben, mientras que la latencia p95 aumenta cuando crecen el encolamiento, la contención de batch y la sobrecarga de paralelismo. Escribe la restricción como coste = segundos de GPU por token × $/segundo de GPU, y el SLA como p95 = percentil 95 del tiempo de finalización de la solicitud. El stack de inferencia de LLM más barato que cumple es el punto donde se cruzan tu piso de calidad, tu SLA de latencia p95 y tu techo de $/token. Las fronteras eficientes de inferencia suelen expresarse como un compromiso entre latencia y throughput, con el coste determinado por el throughput.

Por eso, el modelo más barato es la pregunta equivocada. Un modelo más pequeño puede parecer más barato en el papel y aun así incumplir tu latencia o tu piso de calidad. Un modelo más grande puede ser más caro por token con un tamaño de batch bajo y volverse más barato con un throughput alto si el serving se ajusta correctamente. El objetivo no es minimizar los parámetros del modelo. El objetivo es minimizar el $/token mientras se mantiene por encima del piso de calidad y dentro del SLA de latencia.

Costes

Empieza por la optimización de costes, no por la ficha del modelo. Define tres números antes de hacer benchmark: el piso de calidad, el SLA de latencia p95 y el techo de $/token. El piso de calidad debe ser una barrera medible, no una sensación: precisión de la tarea, puntuación del juez, batería de regresión o KPI de negocio. El SLA de latencia debe ser p95, no la media, porque los usuarios sienten la cola. El techo de coste debe expresarse por token, no por solicitud, porque la longitud del prompt y la de la salida varían.

Luego haz explícita la ecuación de coste. Si una configuración de serving genera menos tokens por segundo de GPU, su $/token sube aunque el modelo sea pequeño. Si genera más tokens por segundo de GPU, su $/token baja aunque el modelo sea más grande. Los tamaños de batch pequeños ofrecen una excelente latencia por usuario pero un alto coste por token, mientras que los tamaños de batch más grandes empeoran la latencia pero mejoran el throughput y reducen el coste. Esa es la palanca principal de coste: el tamaño de batch te mueve a lo largo de la frontera. Si tu SLA de p95 tiene holgura, aumenta el tamaño de batch hasta que la latencia toque el límite. Si tu techo de coste es ajustado y la latencia es holgada, deja que el sistema aumente el batch. Si ambos son ajustados, necesitas un punto diferente en la frontera, no apretar más una sola perilla.

Modelos

La elección del modelo es un punto de calidad-latencia-coste, no una preferencia de marca. Barre el tamaño del modelo, pero no te quedes ahí. El mismo modelo puede ocupar varios puntos en la frontera según la precisión, la longitud de contexto y la configuración de serving. Un gráfico de frontera debe tener tres ejes: calidad, latencia p95 y $/token. Si solo trazas calidad frente a tamaño de modelo, te perderás el stack más barato que cumple. Si solo trazas latencia frente a coste, puedes elegir un modelo que incumple tu piso de calidad.

La cuantización es la primera palanca del lado del modelo que hay que probar. La cuantización mejora tanto la latencia como el throughput, y puede generar grandes ganancias de eficiencia de serving con poca o ninguna reducción de calidad, especialmente con MXFP4 y NVFP4. En la práctica, prueba el piso de calidad después de la cuantización. La frontera puede ser irregular: una precisión puede ser casi gratuita, mientras que otra puede deteriorar una tarea que te importa. No asumas que un menor número de bits es automáticamente mejor. Ejecuta el mismo conjunto de evaluación en cada precisión y luego marca el punto de $/token más bajo que aún supera el piso. Si la caída de calidad es pequeña y la ganancia de latencia o coste es grande, la cuantización puede mover todo el stack a la izquierda y hacia abajo en el gráfico.

Serving

El serving es donde la frontera se vuelve operativa. El modelo es un punto; el stack de serving es el camino alrededor de él. Necesitas barrer el tamaño de batch, el paralelismo y la forma del tráfico. El mismo modelo puede ser demasiado lento con batch bajo, demasiado caro con batch alto o demasiado pesado en la cola bajo tráfico mixto. La configuración de serving debe elegirse después de fijar el piso de calidad, porque el serving cambia más la latencia y el coste que la calidad bruta del modelo.

El tamaño de batch es la primera perilla de serving. Intercambia la latencia por usuario por throughput. Si tu SLA de p95 es holgado, aumenta el batch. Si tu SLA de p95 es ajustado, reduce el batch o cambia la estrategia de paralelismo. Para despliegues sensibles a la latencia, centra el foco en aumentar Tensor Parallelism (TP). Usa TP cuando la cola sea el problema y puedas permitirte la huella. Usa el tamaño de batch cuando el presupuesto sea el problema y la cola tenga holgura.

El paralelismo orientado al throughput es el intercambio opuesto. Attention Data Parallelism (ADP) aumenta el throughput replicando las capas de atención, a costa de la velocidad por solicitud. Usa ADP cuando los tokens totales por segundo sean el cuello de botella y tu SLA de p95 pueda absorber la penalización. Usa TP cuando la cola sea el problema.

Las cargas de trabajo de alto volumen añaden otro eje. La desagregación P/D, o la separación de prefill y decode en workers dedicados, es una estrategia para optimizar despliegues de alto volumen de LLMs. Pruébala solo cuando el volumen sea alto, el tamaño de batch y el paralelismo hayan alcanzado sus límites y el techo de coste aún falle.

Hoja de decisión de la frontera de inferencia

1. Define el piso de calidad, el SLA de latencia p95 y el techo de $/token antes de hacer benchmark.
2. Barre tamaño de modelo, cuantización, tamaño de batch, TP, ADP y P/D.
3. Traza calidad frente a latencia p95 frente a $/token, no solo calidad frente a tamaño de modelo.
4. Elige el punto de $/token más bajo por encima del piso de calidad y dentro del SLA de latencia.
5. Si la latencia falla, aumenta TP; si el coste falla, aumenta el tamaño de batch o ADP, o cuantiza; si el volumen es alto, prueba P/D.

El resultado no es un modelo favorito. Es un punto en la frontera: el stack más barato que cumple para tu tráfico, tu umbral de calidad y tu cola de latencia. Si alguna restricción cambia, mueve el punto. El método se mantiene igual: mide la frontera, aplica las restricciones y compra el token más barato que aún pasa.