15 nodos#LLM inference#serving#KV cache#quantization#unit economics

El costo de un token

Lo que le cuesta a un LLM producir un token depende más del diseño del sistema de inferencia que del precio de la GPU. Partiendo de por qué el ancho de banda de la memoria limita la decodificación, el mapa muestra cómo las técnicas de inferencia, como el procesamiento por lotes, la cuantización y la decodificación especulativa, y los diseños de modelos, como MoE y MLA, cambian cuántos tokens puede producir una misma GPU. Sigue esa diferencia hasta las tarifas de las API, los márgenes de los productos y el puesto de trabajo que se ocupa de ello.

El informe completo

Lo que le cuesta a un LLM producir un token no depende solo de las tarifas de alquiler de la GPU. El punto de partida es una restricción física: el ancho de banda de la memoria limita la decodificación. Las técnicas de inferencia y los diseños de modelos que sortean ese cuello de botella cambian cuántos tokens puede producir una misma GPU. Esa diferencia se traslada a las tarifas de las API y a los márgenes de los productos, y ha dado lugar a un puesto de trabajo especializado.

Decodificación limitada por la memoria#

La limita el ancho de banda, no la capacidad de cálculo

Cada vez que un modelo produce un token, vuelve a leer de la memoria casi todos sus pesos. Un modelo de 70 mil millones de parámetros cargado a 16 bits tiene unos 140GB solo en pesos, por lo que, cuando las solicitudes se atienden de una en una, el ancho de banda de la memoria llega a su límite antes que los núcleos de cálculo. Por eso, la mayoría de las formas de reducir el costo de inferencia consisten en obtener más tokens de cada lectura o en reducir los bytes que hay que leer.

Procesamiento inicial y decodificación#

Dos fases, dos cuellos de botella distintos

El procesamiento inicial, que lee el prompt, procesa todos los tokens de entrada a la vez, por lo que su cuello de botella es la capacidad de cálculo. La decodificación, que escribe la respuesta, produce los tokens uno a uno y vuelve a leer los pesos y la caché KV cada vez, por lo que su cuello de botella es la memoria. El tiempo hasta el primer token depende principalmente del procesamiento inicial, y el intervalo entre los tokens posteriores, de la decodificación. Por eso, investigaciones como DistServe y Splitwise propusieron ejecutar las dos fases en GPU separadas.

Técnicas de inferencia#

Tres formas de sortear el mismo cuello de botella

Hay tres formas principales de reducir el costo por token al servir un modelo sin cambiarlo. El procesamiento por lotes produce tokens para muchas solicitudes a partir de una sola lectura de los pesos, la cuantización reduce los bytes que hay que leer y la decodificación especulativa confirma varios tokens en una sola pasada de verificación. El procesamiento por lotes y la decodificación especulativa mantienen intacta la distribución de salida del modelo. La cuantización sacrifica un poco de calidad para liberar memoria.

Procesamiento continuo por lotes y caché KV#

Una lectura compartida entre muchas solicitudes

El procesamiento continuo por lotes no espera a que termine una solicitud. En cada paso de decodificación incorpora nuevas solicitudes a los espacios libres y produce tokens para muchos usuarios a partir de una sola lectura de los pesos. Lo que limita el tamaño del lote es la caché KV que se acumula para cada solicitud. El artículo de vLLM de 2023 señaló que los sistemas existentes desperdiciaban entre el 60 y el 80% de la memoria reservada para la caché KV y que, al gestionar la caché en páginas, aumentó el rendimiento entre 2 y 4 veces con la misma latencia.

Cuantización#

A 8 bits, la mitad de bytes que leer

Reducir los pesos de 16 bits a 8 disminuye a la mitad lo que hay que leer de la memoria por cada token, y usar 4 bits lo reduce a una cuarta parte. Los métodos que solo cuantizan los pesos, como GPTQ y AWQ, aportan ventajas inmediatas en la decodificación, donde la memoria es el cuello de botella, mientras que W8A8, que también reduce las activaciones a 8 bits, acelera el procesamiento inicial, donde el cuello de botella es la capacidad de cálculo. La calidad puede disminuir al reducir los bits, por lo que el número de bits se elige tras volver a evaluar el modelo con las tareas reales que atiende el servicio.

Decodificación especulativa#

Un modelo pequeño propone, el grande verifica en una pasada

Un modelo pequeño propone primero unos cuantos tokens como borrador, y el modelo principal los verifica juntos en una sola pasada hacia delante. Como solo se conservan los tokens aceptados, la distribución de salida es la misma que si el modelo principal hubiera trabajado solo. En 2023, investigadores de Google informaron de una aceleración de 2 a 3 veces en T5-XXL sin cambiar las salidas, y la mejora real depende de la frecuencia con la que se acepten los tokens del borrador.

Cálculo del costo por token#

Doble rendimiento, mitad de costo

Si tú mismo sirves un modelo, el costo de un token es el costo por hora de la GPU dividido por el número de tokens producidos en esa hora. Las técnicas de inferencia y los diseños de modelos reducen ese costo al aumentar el rendimiento, no al cambiar lo que cuesta la GPU. Sin embargo, aunque baje el precio unitario de un token, un producto que llama al modelo muchas veces por tarea, como hacen los agentes, puede registrar un crecimiento aún más rápido del volumen de llamadas, de modo que la factura total puede seguir aumentando.

open_in_newstartupxo.com/ko/news/2026/06/ai-inference-cost-economics-for-founders

El impuesto por token#

El costo de inferencia entra en el costo de ventas

En el SaaS tradicional, atender a un usuario más cuesta poco, pero un producto basado en un LLM consume tiempo de GPU en cada solicitud. Por eso, el costo de inferencia se incluye en el costo de ventas y, en un plan de tarifa plana, el usuario que más lo utiliza se convierte en el más costoso. Necesitas conocer los tokens de entrada, los de salida y la tasa de aciertos de caché de una solicitud individual para poder saber si un plan de precios es rentable.

Descuentos por aciertos de caché#

Un prompt que no se vuelve a leer cuesta menos

Cuando todas las solicitudes incluyen al principio el mismo prompt del sistema o un documento largo, reutilizar la caché KV de esa parte inicial permite al modelo omitir esa parte del procesamiento inicial. Por eso, las principales API de modelos cobran menos por los tokens de entrada en caché que por los de entrada normales. Solo hay un acierto de caché en la parte que coincide exactamente desde el principio, así que el simple hecho de colocar primero el contenido fijo y al final el variable puede cambiar la tasa de aciertos.

Diseño del modelo#

Reducir desde el diseño lo que hay que leer

Si las técnicas de inferencia permiten ejecutar un modelo dado a bajo costo, el diseño del modelo permite reducir desde el principio cuánto hay que leer y calcular por cada token. La mezcla de expertos (MoE) reduce los parámetros utilizados por token, y MLA reduce la caché KV que se acumula por solicitud. DeepSeek-V3 utiliza ambas, se entrenó con precisión mixta FP8 y también publicó sus pesos en FP8.

Mezcla de expertos (MoE)#

37 mil millones de 671 mil millones por token

DeepSeek-V3 activa solo 37 mil millones de sus 671 mil millones de parámetros totales para procesar cada token. El cálculo por token y los pesos que hay que leer se reducen a los parámetros activos, pero, como no se puede saber de antemano qué expertos se utilizarán, los 671 mil millones deben permanecer cargados en memoria. MoE ahorra cálculo a cambio de necesitar más capacidad de memoria, lo que da lugar a diseños que distribuyen los expertos entre varias GPU.

MLA#

Comprimir la caché KV para ampliar el lote

La atención latente multicabeza (MLA) no almacena las claves y los valores tal como son. Los comprime en pequeños vectores latentes y almacena estos en caché. El informe técnico de DeepSeek-V2 indica que este modelo, que utiliza MLA, tiene una caché KV un 93.3% menor que la de DeepSeek 67B. Cuando cada solicitud ocupa menos memoria, una misma GPU puede alojar más solicitudes y contextos más largos.

Ingeniero de sistemas de inferencia#

El puesto que reduce el costo de un token

A medida que el costo de inferencia pasó a determinar directamente los márgenes de los productos, ejecutar modelos de forma rápida y económica se convirtió en un trabajo importante por derecho propio, separado de su desarrollo. El desempeño en este puesto se mide por la capacidad de elegir y ajustar motores de inferencia como vLLM, SGLang y TensorRT-LLM para obtener más tokens de la misma GPU. La mayoría de las ramas de este mapa corresponden a configuraciones que se ajustan a diario en este trabajo.

open_in_newreputo.net/ko/jobs/software-engineer/specializations/llm-serving-systems-engineer

El trabajo del ingeniero de sistemas de inferencia#

De medir la carga a ajustar la decodificación

El primer paso es medir la carga de trabajo y determinar si el cuello de botella está en el procesamiento inicial o en la decodificación, y si el objetivo de latencia se refiere al tiempo hasta el primer token o al intervalo entre tokens. Después se ajustan el tamaño del lote, la memoria asignada a la caché KV y el número de bits de cuantización, y se decide si usar decodificación especulativa, para luego comprobar que se mantiene la calidad. Cada vez que cambia un ajuste, se vuelven a medir conjuntamente el rendimiento, la latencia y la calidad.

Fuentes y contenido relacionado

¿Quieres llevarlo a la práctica?

Después de leer el informe, la siguiente pregunta suele ser cómo hacerlo realidad. Weple es un estudio de desarrollo externo que convierte estructuras como la de esta página en entregas pequeñas con un alcance definido. Incluye esta página en tu consulta.

Consultar sobre el desarrollo