Coste por millón de tokens de LLM autoalojados: un modelo reproducible de costes de GPU

Coste por millón de tokens de LLM autoalojados: un modelo reproducible de costes de GPU

La forma fiable de calcular el coste por millón de tokens de LLM autoalojados es dividir el coste de servicio totalmente cargado entre los tokens que realmente acepta tu carga de trabajo, no entre el rendimiento máximo anunciado de una GPU.

Esa distinción es importante. Una GPU puede obtener buenos resultados en benchmarks y, aun así, resultar costosa en producción cuando pasa tiempo pagado inactiva, procesa prompts inusualmente largos, reintenta solicitudes fallidas o genera resultados que tu producto rechaza. Esta guía proporciona un modelo repetible para el coste por millón de tokens de LLM autoalojados, una hoja de cálculo, un ejemplo desarrollado y una forma justa de comparar un endpoint autogestionado con una API administrada.

Actualizado el 16 de octubre de 2026. Todos los importes en dólares y rendimientos que aparecen a continuación son valores ilustrativos, no cotizaciones de proveedores ni afirmaciones de rendimiento.

La fórmula del coste por millón de tokens de LLM autoalojados

Para una perspectiva de tokens de salida, usa:

cost per 1M accepted output tokens =
  fully loaded hourly serving cost
  / (active-window output tokens/second × 3,600 × paid-time utilization × success rate × acceptance rate)
  × 1,000,000

Donde:

El denominador es la clave. El coste por millón de tokens de LLM autoalojados debe ser un coste por unidad útil, no un coste por benchmark de GPU.

La regla de no contar dos veces

Usa una de estas dos vías de medición:

1. Mide el rendimiento en ventana activa y, después, multiplícalo por la utilización del tiempo pagado.
2. Mide los tokens aceptados durante todo el intervalo pagado y, después, establece la utilización en 1 porque el tiempo inactivo ya está incluido en la observación.

No hagas ambas cosas. Aplicar un factor de utilización al rendimiento de tiempo de reloj que ya incluye el tiempo inactivo hace que el coste de inferencia de LLM por token parezca peor de lo que es. Omitir la utilización de un benchmark de ventana activa hace que parezca mejor de lo que es.

Una hoja de cálculo copiable de coste de GPU por millón de tokens

Incluye una fila en tu hoja de cálculo para cada modelo, topología de hardware, región y forma de carga de trabajo. No mezcles un benchmark de chat corto con una carga de trabajo de producción de contexto largo.

La hoja de cálculo hace que el cálculo del coste por millón de tokens de LLM autoalojados sea auditable: otro operador debería poder sustituir las entradas, repetir la ventana de medición y reproducir el resultado.

Este es un cálculo ilustrativo, no una lista de precios de ninguna GPU. Sustituir las cinco entradas por valores medidos produce tu propio coste de GPU por millón de tokens.

Ejemplo desarrollado: por qué la utilización cambia la respuesta

Mantén constantes el coste horario totalmente cargado de $4.07 del endpoint hipotético y los 900 tokens de salida por segundo en ventana activa. Pequeños cambios en las entradas modifican drásticamente el coste unitario.

La lección no es comprar un acelerador concreto. La lección es que la tarificación de LLM autoalojados es un modelo de operaciones y rendimiento. Un mayor coste horario por nodo puede generar un menor coste por salida aceptada si dispone de suficiente memoria, margen para el procesamiento por lotes y demanda para sostener más trabajo útil. Una tarifa horaria inferior puede perder cuando la capacidad ociosa y los reintentos entran en el denominador.

Separe el prefill del decode antes de realizar pruebas comparativas

El servicio de LLM no es una carga de trabajo homogénea. La inferencia tiene una fase de procesamiento de contexto (prefill) y una fase de generación (decode); la guía de TensorRT-LLM de NVIDIA las trata explícitamente como fases independientes y hace hincapié en el ajuste específico para cada carga de trabajo. Revise la guía de ajuste del rendimiento de TensorRT-LLM antes de considerar representativa cualquier cifra destacada de tokens por segundo.

• Los prompts largos, el contexto de recuperación y los adjuntos grandes ejercen presión sobre el prefill y la caché KV.
• Las respuestas largas, la generación de código y el razonamiento de agentes ejercen presión sobre la capacidad de decode y el tiempo por token de salida.
• Una alta concurrencia hace que el comportamiento del planificador, el procesamiento por lotes, la residencia en caché y el margen de memoria formen parte del modelo de precios.

Registre por separado las distribuciones de prompts y salidas. Para un asistente con gran uso de recuperación, con 20,000 tokens de entrada y 300 tokens de salida, la economía basada solo en la salida puede pasar por alto el verdadero cuello de botella. Para un flujo de trabajo de programación con 2,000 tokens de entrada y 4,000 tokens de salida, puede dominar el decode.

Para una comparación rigurosa del coste por millón de tokens de LLM autoalojados, mantenga al menos estas tres perspectivas:

Mida el denominador a partir de la telemetría de producción

No deduzca el rendimiento aceptado a partir de una especificación de hardware. La pila de servicio debe exportar los datos de entrada que hacen reproducible el cálculo.

Por ejemplo, vLLM documenta métricas de Prometheus para tokens de prompt, tokens generados, finalizaciones de solicitudes, rechazos de admisión, tiempo de cola, tiempo de prefill, tiempo de decode, uso de caché KV, tiempo hasta el primer token y latencia por token de salida. Estas son suficientes para crear un registro de medición en lugar de hacer estimaciones a partir de una prueba comparativa. La referencia de métricas de vLLM enumera los nombres y significados actuales de las métricas.

Capture este registro para cada ejecución:

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

La telemetría de hardware es útil, pero es un diagnóstico, no un denominador de coste unitario. La documentación de perfiles de DCGM de NVIDIA señala que la actividad es un promedio por intervalo y debe correlacionarse con el rendimiento de una carga de trabajo representativa. Use las métricas de perfilado de DCGM para investigar si el cálculo, el ancho de banda de memoria o el comportamiento de la interconexión están limitando la ejecución; no sustituya la utilización del tiempo pagado por un único porcentaje de utilización de la GPU.

Construya el numerador totalmente cargado

El precio de alquiler de GPU es un dato de entrada, no la respuesta. Para calcular de forma justa el coste del servicio de LLM, incluya los costes de capacidad y operaciones necesarios para la misma ventana de medición.

Para un piloto, informe dos cifras:

Coste solo de GPU por 1M de tokens
Coste total por 1M de tokens aceptados

La diferencia no es un error; es el coste operativo del servicio autoalojado. Hace que la decisión de precios de LLM autoalojados sea auditable.

Incluya reintentos y salida rechazada

Los tokens generados no son automáticamente tokens útiles. Una solicitud puede consumir capacidad de prellenado y decodificación parcial antes de que agote el tiempo de espera, produzca JSON no válido, falle una llamada a una herramienta, incumpla una regla de política o no alcance un umbral de calidad.

Utilice un ajuste de aceptación que su equipo de producto pueda reproducir:

tokens de salida aceptados =
  tokens de salida generados
  × tasa de éxito de ejecución
  × tasa de aceptación del producto

Si la aceptación se mide a nivel de solicitud, registre la regla exacta: versión del evaluador, conjunto de muestreo, validador de esquema, protocolo de revisión humana o evento de éxito de la tarea. Cambiar la regla sin versionarla hace que una tendencia de costes carezca de sentido.

Por eso, un coste de inferencia de LLM por token sin procesar también puede resultar engañoso. Una configuración que gana un 30 % de rendimiento, pero reduce el éxito de las tareas aceptadas, puede costar más en la capa de producto.

Compare el autoalojamiento con una API gestionada en la misma unidad

El autoalojamiento compra capacidad. Una API gestionada compra uso. Solo son comparables cuando el numerador y el denominador coinciden.

Utilice esta comprobación de rendimiento de equilibrio cuando la referencia de la API se exprese en la misma unidad:

tokens de salida/segundo requeridos en la ventana activa =
  coste horario total del servicio × 1,000,000
  / (coste de API gestionada por 1M de tokens de salida aceptados × 3,600 × utilización × tasa de éxito × tasa de aceptación)

Antes de decidir, alinee estos controles en ambas alternativas:

• El mismo modelo o un modelo equivalente en calidad evaluado explícitamente.
• La misma distribución de longitud de prompts y salidas.
• El mismo SLO de latencia y perfil de concurrencia.
• Las mismas reglas de reintento, respaldo y aceptación.
• El mismo tratamiento de aciertos de caché, fallos de herramientas y trabajo cancelado.

Si el control directo de GPU, los pesos personalizados, la ubicación estricta o una pila de kernels especializada son requisitos, el autoalojamiento puede seguir siendo la respuesta correcta incluso por encima de la referencia gestionada. Si el tráfico es bajo o irregular, los modelos cambian con frecuencia o el equipo no desea operar infraestructura de inferencia, una API con precios por uso puede absorber el riesgo de utilización.

Para una comparación de compra más amplia, consulte la guía de Flatkey sobre nube GPU frente a API de modelos y la guía de precios de alquiler de GPU. Cuando no se requiere control directo de GPU, una ruta gestionada es una referencia útil: Flatkey proporciona una API unificada de modelos y herramientas con un único saldo, para que los equipos puedan comparar una ruta gestionada con su cálculo autoalojado sin mantener claves de proveedores independientes. Inicie una referencia de API de Flatkey con el mismo conjunto de pruebas y regla de aceptación.

Una prueba de adquisición en siete pasos

Utilice este marco de coste de LLM autoalojados por millón de tokens como un artefacto de adquisición, no solo como una evaluación comparativa de ingeniería. Debe mostrar exactamente qué supuestos de carga de trabajo, capacidad y calidad cambiaron el resultado.

1. Defina la unidad: token de entrada, token de salida, token combinado, respuesta aceptada o tarea aceptada.
2. Mida el rendimiento en la ventana activa con tráfico similar al de producción, no con un único prompt sintético.
3. Mida la utilización del tiempo pagado en cada réplica pagada y nodo de reserva en caliente.
4. Añada todos los costes operativos al numerador horario.
5. Versione las reglas de éxito y aceptación y, después, calcule la salida aceptada.
6. Ejecute la misma carga de trabajo mediante una referencia de API gestionada.
7. Revise conjuntamente el coste, la latencia p95, la fiabilidad, la calidad y el esfuerzo de ingeniería antes de reservar capacidad.

Errores comunes en un modelo de costes de LLM autoalojados

Usar el rendimiento máximo de una evaluación comparativa. El máximo es útil para comparar una configuración controlada. No es el rendimiento esperado de su combinación de producción.

Llamar a la utilización de la GPU utilización de capacidad. Una GPU ocupada puede seguir estando conectada a un endpoint sobredimensionado para la demanda pagada. Utilice la utilización del tiempo pagado para la economía unitaria y la telemetría de hardware para diagnosticar la causa.

Aplicar la utilización dos veces. Elija rendimiento de ventana activa más utilización, o rendimiento de tiempo de reloj que ya incluya el tiempo inactivo.

Ignorar los tokens de entrada. Un contexto largo aumenta la presión de prellenado y de la caché KV incluso cuando el producto factura principalmente por la salida.

Tratar cada token generado como aceptado. Los reintentos, los argumentos de herramientas no válidos, los fallos de esquema y los rechazos por calidad son trabajo pagado.

Comparar únicamente una factura de GPU con el precio de lista de una API. Ingeniería, soporte, almacenamiento, red, observabilidad y capacidad en espera deben incluirse en el mismo cálculo.

Para la decisión completa (cuándo conviene el autoalojamiento, dimensionamiento de memoria GPU, herramientas y una configuración de servidor paso a paso), consulta nuestra guía de LLM autoalojados.

Preguntas frecuentes

¿Cómo calculo el coste por millón de tokens de un LLM autoalojado?

Divide el coste horario totalmente cargado del servicio entre los tokens aceptados por hora pagada y, después, multiplica por 1.000.000. Usa el rendimiento medido en condiciones similares a producción, la utilización del tiempo pagado, la tasa de éxito y la tasa de aceptación, no el pico teórico de la GPU.

¿Es el coste de GPU por millón de tokens lo mismo que el coste de inferencia de LLM por token?

El coste de GPU por millón de tokens puede ser una métrica de infraestructura que solo incluya la GPU. El coste de inferencia de LLM por token debe incluir el numerador operativo pertinente y un denominador claramente definido. Para una decisión de producto, el coste por respuesta o tarea aceptada suele ser la métrica complementaria más segura.

¿Debo usar tokens de salida o tokens totales?

Usa ambos cuando los costes de entrada y salida tengan distintos cuellos de botella. Los tokens de salida son fáciles de comparar para cargas de trabajo generativas; los tokens totales o ponderados representan mejor las cargas de trabajo de recuperación con contexto largo. Mantén la unidad idéntica al comparar el autoalojamiento con una API.

¿Cuándo ahorra dinero el autoalojamiento?

Es más probable que ahorre dinero cuando la demanda es estable, la capacidad se mantiene bien utilizada, el modelo y el despliegue son estables, y el control directo aporta valor. Es menos probable que ahorre dinero cuando el tráfico es irregular, la selección de modelos cambia con frecuencia o la sobrecarga operativa supera los ahorros de capacidad.

Conclusión

La cifra defendible de coste por millón de tokens de LLM autoalojados es la capacidad pagada totalmente cargada dividida entre el rendimiento aceptado. Mide el prellenado y la decodificación por separado, contabiliza el tiempo inactivo una sola vez, versiona tu regla de aceptación y compara una referencia gestionada con la misma unidad. Así se convierte una cotización de GPU en un modelo de costes listo para tomar decisiones.

Referencias técnicas

• referencia de métricas de vLLM
• guía de ajuste de rendimiento de NVIDIA TensorRT-LLM
• documentación de perfilado de NVIDIA DCGM