Throughput por megavatio: ¿self-host o API para IA?

La GPU puede producir más tokens por vatio y perder en el costo de una petición. El throughput por megavatio mide capacidad bajo una carga definida, no el costo de la infraestructura inactiva. La capacidad dedicada merece preferencia cuando ofrece un costo total medido menor con requisitos equivalentes; la API gana cuando cumple esos mismos requisitos por menos.

Artificial Analysis publicó los resultados de AA-AgentPerf el 15 de octubre de 2026. El mayor múltiplo reportado llega a 5,7x en una comparación específica de throughput por potencia de GPU. No es una promesa de ahorro ni una comparación de facturas. La decisión de compra exige comparar el costo completo de las alternativas, un cálculo que el benchmark no presenta.

¿Qué mide el throughput por megavatio?

El throughput por megavatio relaciona los tokens contabilizados por unidad de tiempo con la potencia medida, en megavatios, bajo una carga definida. El límite de medición importa. En AA-AgentPerf, la potencia cubre las GPU y su memoria, no toda la instalación; la medida describe la capacidad en las condiciones de prueba, pero no informa la energía total ni el costo por petición.

La fuente compara Vera Rubin NVL72 con la línea de configuraciones GB300 descrita por Artificial Analysis. La tabla reúne las mayores ventajas aproximadas observadas en puntos específicos de velocidad de salida por usuario, no la razón entre los máximos de throughput de cada sistema.

El detalle del comparador importa. En el máximo del Pro, la línea GB300 usa configuraciones más pequeñas construidas por Artificial Analysis, no un rack completo. En el máximo del Flash, la propia configuración Vera Rubin es menor que un rack completo. Los límites de salida también difieren en el Flash, y la fuente informa que esto favorece modestamente el throughput de Vera Rubin. Las topologías no son intercambiables.

Hay otro límite de medición. El throughput suma tokens de entrada nuevos y reutilizados desde caché con tokens de salida, según la metodología de AA-AgentPerf. No representa solo tokens reprocesados o facturados por una API. La velocidad de salida excluye la espera del primer token. Para el Pro, la conclusión cambia cuando esa espera entra en la métrica de velocidad de extremo a extremo.

La CPU, la red y la refrigeración quedan fuera de la potencia del benchmark. Un equipo que trate el denominador como consumo total del centro de datos empieza el cálculo con un gasto invisible.

¿Cómo cambia el procesamiento con la reutilización de prefijos?

La caché de prefijos permite reutilizar el estado de procesamiento de una entrada anterior cuando el prefijo es compatible y el estado de KV está disponible para la nueva petición. La repetición crea una oportunidad, no un acierto automático. La parte del prefijo cuyo estado compatible esté disponible puede reutilizarse; el resto necesita prefill.

Durante el prefill, el modelo procesa los tokens de entrada y produce estados intermedios de atención, conocidos como KV. Si una petición posterior comienza con el mismo prefijo y puede acceder al estado compatible, el sistema puede reutilizar ese trabajo y procesar la parte nueva. La salida todavía debe generarse según la petición. Esto es distinto de una caché de respuestas, que reutiliza una respuesta ya producida.

En el conjunto de trayectorias usado para describir la carga de AA-AgentPerf, las entradas llegan a 132 mil tokens y el 97% de los tokens de entrada repite, en promedio, los de la petición anterior. Esos valores describen ese conjunto de trayectorias. No son la tasa de acierto de caché, un ahorro financiero ni una característica de cualquier otra aplicación.

La permanencia del estado importa tanto como la similitud del texto. Si la caché caduca, se elimina por presión de memoria o no está accesible para el proceso que atiende la petición, el prefijo repetido no produce la reutilización esperada. El equipo debe verificar compatibilidad, retención y ruta observada en conjunto, sin suponer que cualquier gateway proporcione afinidad de sesión o enrutamiento consciente de KV.

La tasa de acierto puede dividir los tokens elegibles servidos desde la caché entre los tokens elegibles. La proporción de peticiones con algún acierto responde a otra pregunta.

¿Cómo convertir throughput por megavatio en costo por petición?

No existe una conversión directa de throughput por megavatio a costo por petición de IA. Para decidir entre self-host o API, la comparación exige dividir el gasto total atribuible en la ventana entre las peticiones lógicas completadas en esa misma ventana. Potencia y throughput indican capacidad; ocupación, energía, facturación y éxito determinan el cálculo.

La fórmula propuesta es simple, pero su límite de medición debe ser explícito:

Costo por petición = costo total atribuible en la ventana / peticiones lógicas completadas en la ventana

Una petición lógica es la unidad definida por la operación para entregar una respuesta aceptada. Si hubo un fallo o un reintento, el gasto correspondiente permanece en el numerador; el conteo del denominador no convierte cada intento en una nueva petición completada. Una tarea puede involucrar varias peticiones, por lo que el costo por tarea es otra medida. El costo real de una aplicación de IA ayuda a separar el gasto de una tarea de la tarifa anunciada por token.

Para inferencia en infraestructura propia, el numerador reúne capacidad contratada o costo de capital asignado al período, energía atribuible de la instalación, red, operación y demás gastos pertinentes. La capacidad ociosa permanece en el cálculo. La energía debe cubrir carga e inactividad dentro del límite elegido, sin repetir costos ya incorporados en otro componente.

Para la API, se incluyen la factura atribuible, con entrada, salida, posibles cargos de caché, fallos y reintentos facturados, y los gastos adicionales de red u operación que no consten en la factura. El equipo financiero usa la misma moneda y el mismo período en las alternativas. El equipo de plataforma confirma la carga, el modelo o la calidad verificablemente equivalente y el criterio de aceptación.

Potencia no es energía. La potencia media multiplicada por el tiempo proporciona energía cuando coinciden el límite de medición y la ventana. Con potencia en kilovatios y tiempo en horas, la energía queda expresada en kilovatios-hora; al multiplicarla por la tarifa en moneda por kilovatio-hora, se obtiene el costo de energía. Medir la GPU no resuelve automáticamente la energía atribuible a la CPU, la red y la refrigeración de la instalación.

Leyenda: La potencia media multiplicada por el tiempo, con el mismo límite de medición y ventana, proporciona energía. La potencia de la GPU en el benchmark no es la energía atribuible de la instalación. Alt: Diagrama que compara la composición del costo por petición en infraestructura propia y API, con potencia y energía separadas.

Los tokens contabilizados divididos entre el tiempo producen throughput; el throughput dividido entre la potencia medida en MW produce throughput por MW. Este indicador no informa cuántas peticiones se completaron: es necesario observar la longitud de entrada y salida, la concurrencia, los aciertos y la capacidad útil.

¿Qué costos deja fuera la comparación por token?

La tarifa por token no captura, por sí sola, la capacidad reservada y ociosa, la energía de la instalación, la operación ni los costos adicionales fuera de una factura de API. La comparación debe atribuir cada componente a la misma ventana e identificar su fuente para evitar tanto los gastos omitidos como los cargos contados por duplicado.

El costo de la capacidad ociosa permanece en el cálculo.

La guía para reducir costos de inferencia aborda los gastos de operación. En esta comparación, el equipo necesita medir cuántas peticiones lógicas completadas entrega la capacidad pagada y cuánto cuestan la GPU y los demás componentes.

La respuesta también debe cumplir el requisito de servicio. Las métricas de benchmark de un enrutador de modelos ayudan a evaluar calidad, latencia y costo de las rutas. Ninguna debe confundirse con la potencia de GPU utilizada en el denominador de AA-AgentPerf. La ruta más barata que no cumple el criterio de calidad no es una alternativa equivalente.

¿Cuándo suele tener sentido la capacidad dedicada?

La capacidad dedicada suele tener sentido cuando entrega peticiones lógicas completadas a un costo total medido menor que la alternativa por API, con requisitos equivalentes. La ocupación y la reutilización efectiva de la caché, cuando exista, entran en la evaluación. La recurrencia, por sí sola, no garantiza el resultado. La elección depende del gasto de toda la ventana y de los requisitos de calidad y servicio.

La utilización de GPU debe observarse durante los períodos de trabajo y de espera. Medir solo el tramo en que la cola está llena puede favorecer a la capacidad dedicada en la hoja de cálculo al omitir los períodos ociosos. La ventana de comparación debe incluir esa inactividad, así como los gastos atribuibles de mantenimiento y operación.

Cuando haya caché, el equipo mide si el prefijo es compatible, si el estado permanece disponible y si la ruta alcanza el proceso que lo mantiene. Una entrada repetida enviada a otro proceso sin acceso al estado puede requerir prefill de nuevo. No hay acierto solo porque el historial sea parecido.

Cuando el resultado satisface los requisitos y el costo completo queda por debajo del de la API medida con la misma carga, la capacidad dedicada tiene un argumento económico. Si el gasto fijo domina la ventana o la caché no aparece donde se espera, el mismo benchmark deja de respaldar la compra. La capacidad anunciada no paga el tiempo ocioso.

¿Cuándo suele tener sentido el consumo enrutado?

El consumo enrutado por API suele tener sentido cuando la demanda dispersa o irregular dejaría capacidad dedicada ociosa y cuando la factura efectiva, sumada a los costos adicionales, resulta menor bajo requisitos equivalentes. La decisión exige verificar las rutas disponibles, la calidad entregada y las reglas de facturación del contrato concreto.

La carga varía. Los modelos o los límites de servicio pueden variar entre clases; separarlas evita comparar exigencias distintas o esconder una clase costosa en el promedio.

La política de caché de la API pertenece al contrato observado. El proveedor puede ofrecer un tratamiento para la entrada reutilizada, pero el equipo necesita verificar la elegibilidad, la forma de facturación y el uso registrado; no debe presumir la misma regla en todas las rutas. Los gastos de los intentos fallidos y de operación permanecen en el numerador incluso cuando el cargo principal parece simple.

Una API no es automáticamente más barata por evitar la compra de hardware. Si la carga es recurrente y la capacidad dedicada presenta un mejor costo completo con calidad equivalente, la evidencia apunta a self-host. La hipótesis se invierte cuando la factura efectiva y los costos adicionales favorecen a la API. El estudio de Artificial Analysis no decide ninguno de esos casos.

¿Cómo probar la decisión con la propia carga?

La prueba compara las alternativas en la misma ventana, con clases de petición, criterios de calidad y unidad financiera definidos previamente, mientras el equipo registra prefijos, aciertos, capacidad, energía, gastos y peticiones lógicas completadas. El resultado es un cálculo verificable por clase y para el conjunto, no una extrapolación del benchmark público.

1. Definir la ventana, las clases de petición, el modelo o la calidad verificablemente equivalente y lo que caracteriza una respuesta aceptada. Registrar el total de peticiones enviadas, completadas, fallidas y reintentos sin confundir intentos con peticiones lógicas.
2. Registrar entrada, salida y prefijo repetido por clase, preservando la distribución de las peticiones.
3. Medir los tokens elegibles servidos desde la caché, el tiempo de retención y la disponibilidad del estado compatible. Distinguir un acierto parcial de la reutilización completa.
4. Medir capacidad asignada, potencia, energía atribuible, capacidad ociosa y gastos operativos. Documentar los límites de medición y las unidades.
5. Obtener la factura efectiva de API y agregar costos atribuibles no incluidos. Revisar la facturación de entrada, salida, caché e intentos.
6. Dividir el costo total de cada alternativa entre las peticiones lógicas completadas y comparar la calidad y los requisitos de servicio por clase. Revisar la decisión si cambian la carga, el contrato o la disponibilidad de caché.

Leyenda: El estado compatible disponible permite la reutilización completa o parcial del prefijo; el resto exige prefill. Alt: Flujo que separa la reutilización completa, el acierto parcial y la ausencia de estado compatible en la caché de KV.

El procedimiento para decidir la ruta de LLM con tráfico real complementa esta evaluación con tráfico observado. La medida financiera sigue siendo independiente: una ruta técnicamente aceptable todavía debe resultar viable en la unidad elegida.

Preguntas frecuentes

Un mayor throughput no garantiza un menor costo; el cálculo depende de la ocupación, la energía y los gastos de la ventana. Un prefijo repetido tampoco es un acierto de caché: la reutilización exige un estado compatible y disponible. Para una API, la facturación depende del contrato y del uso registrado.

¿Un mayor throughput significa un menor costo?

No necesariamente. Un mayor throughput por potencia puede indicar más capacidad para la carga y el límite de medición probados, pero el costo por petición depende también de la ocupación, la energía de la instalación, la capacidad asignada, la operación y las peticiones completadas. La ventaja financiera solo aparece cuando se mide el costo completo con requisitos equivalentes.

¿La repetición de prefijos equivale a un acierto de caché?

No. La repetición describe el contenido de la entrada; un acierto de caché exige que el estado compatible esté disponible y se encuentre cuando llega la petición. En AA-AgentPerf, el 97% indica la repetición promedio de tokens de entrada en esa carga, no la proporción de tokens servidos desde la caché ni un ahorro.

¿Una API siempre factura el prefijo reutilizado de la misma manera?

El contrato define la facturación. El tratamiento de la entrada reutilizada depende del contrato y de las reglas de la ruta utilizada. El equipo debe revisar la elegibilidad, el uso registrado y la factura efectiva, incluidos los posibles cargos de caché e intentos. Sin esos datos, no hay base para atribuir una tarifa o un ahorro a la reutilización.

¿Una carga repetitiva basta para justificar la capacidad dedicada?

No basta. La repetición puede crear una oportunidad de reutilización, pero la elección depende del costo completo medido, de la ocupación, de la caché efectivamente observada y de requisitos equivalentes, incluso si no hay aciertos. La comparación debe incluir los períodos ociosos y verificar que la calidad y los requisitos de servicio sean equivalentes a los de la API.

Referencias y lectura complementaria

Artificial Analysis es la fuente de los resultados y de la metodología de throughput y potencia, pero el estudio no compara facturas ni costo por petición entre self-host y API. La fórmula es una propuesta. La operación necesita medir los gastos en la misma ventana y dividirlos entre las peticiones lógicas completadas para usar la medida financiera.

• AA-AgentPerf: resultados Vera Rubin NVL72, Artificial Analysis, 15 de octubre de 2026.
• Metodología de AA-AgentPerf, Artificial Analysis.

Qué medir antes de elegir la ruta

La elección no proviene del benchmark. La decisión debe partir de una ventana representativa, costos atribuibles y peticiones lógicas completadas con calidad aceptada, en comparación con una API que cumpla los mismos requisitos. La alternativa con menor costo medido en esa ventana tiene un argumento económico.

El siguiente paso es asignar responsables a la medición de energía, factura y calidad antes de negociar capacidad. Nexforce Router es un gateway para acceder a modelos y enrutarlos mediante una API, con criterios configurables y observabilidad del consumo. La elección entre las rutas efectivamente disponibles sigue sujeta a medición, sin promesa de ahorro ni de caché de prefijos.