Deje de comparar precios por token con horas de GPU. Mida la inferencia por tarea completada, en horas pagadas
Una GPU que perdió dinero en una semana, un agente 29x más barato con el mismo modelo, un modelo de decisión que solo cobra la entrada. Nuestro marco para decidir cómo comprar inferencia.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
¿Cuánto le cuesta a su empresa una unidad de trabajo de IA terminada?
No un token, no una hora de GPU: una tarea bien hecha, como un caso clasificado, un documento conciliado o un formulario completado. Pocas empresas pueden responder, porque las cifras que comparan están en unidades distintas. Una API alojada cobra en dólares por millón de tokens. Una GPU, en dólares por hora. Una plataforma, por usuario. Compararlas directamente es la forma en que los equipos se convencen de la arquitectura equivocada, en ambos sentidos.
Tres resultados publicados en la misma semana muestran por qué.
Tres cifras de una semana
Una GPU que compensó por la mañana y perdió en la semana. Un ingeniero de Microsoft ejecutó un modelo de pesos abiertos en una H100 Spot de Azure. En las tres horas más intensas produjo 24,35 dólares en tokens con 4,65 dólares de cómputo. En la semana produjo 86 dólares en tokens con unos 98 dólares de cómputo, porque la configuración, la carga, el tiempo ocioso y los desalojos también se pagan. Mismo hardware, mismo modelo, conclusiones opuestas, según qué horas se cuenten.
Un flujo de trabajo 29 veces más caro de lo necesario con el mismo modelo. El agente de navegador de Asana costaba al menos 36,21 dólares por ejecución; corregir cómo almacenaba en caché y recortaba su propio historial dejó el mismo modelo en 1,24 dólares. Un presupuesto de contexto mayor también llevó la proporción de ejecuciones completadas de 3 de 18 a 18 de 18. Una configuración más barata que no termina no es más barata.
Una decisión con precio separado de la generación. Microsoft-Decision-1 cobra 0,042 dólares por millón de tokens de entrada y nada por la salida, porque puntúa opciones en lugar de escribir texto. Las llamadas que en realidad son decisiones tienen ahora su propia curva de precio.
Cada resultado es acotado, y dos los publicaron proveedores. Juntos dicen lo mismo: el precio de la tarifa explica menos de la factura que la utilización, el diseño del contexto y la tasa de finalización.
La unidad: costo por tarea completada
Nuestra propuesta es una única unidad para todas las opciones:
El gasto total de un periodo, incluida la capacidad ociosa y las personas que lo operan, dividido entre el número de tareas completadas correctamente en ese periodo.
Las dos mitades importan. El numerador debe incluir las horas que se pagan y no se usan, y el tiempo de ingeniería que mantiene el sistema en marcha. El denominador solo debe contar las tareas que terminaron y superaron su criterio de aceptación, no las solicitudes atendidas. Con esta unidad, un modelo autoalojado con baja utilización y una API de frontera con una política de contexto derrochadora aparecen tan mal como realmente están.
Esto amplía una idea que mantenemos desde que defendimos que la IA es ya un portafolio de modelos y que las horas ahorradas son capacidad, no valor: la medida tiene que seguir al trabajo, no al componente.
Cuatro formas de comprar inferencia
| Forma de compra | Usted paga por | El tiempo ocioso le cuesta | Suele ganar cuando |
|---|---|---|---|
| API gestionada, por token | Tokens procesados | Nada | El tráfico es irregular o desconocido; el listón de calidad es alto |
| Capacidad gestionada dedicada | Rendimiento reservado | Todo lo reservado | El volumen es estable y previsible; necesita un SLA |
| Pesos abiertos autoalojados | Horas de GPU, más la operación | Todo, incluidas cargas y desalojos | El tráfico es estable con prefijos largos compartidos; la custodia lo exige |
| Combinación enrutada | Varias de las anteriores, más el enrutador | Depende de la combinación | Las tareas varían mucho; muchas llamadas son pequeñas decisiones |
La tabla es menos una recomendación que una lista de quién asume el riesgo de una hora vacía. Con una API por token, lo asume el proveedor. Con capacidad reservada o autoalojada, lo asume usted, y la justificación depende de mantenerla ocupada.
Cuatro mediciones antes de elegir
Utilización por hora. Represente las solicitudes esperadas por hora a lo largo de una semana, no la media diaria. Una GPU necesita un mínimo sostenido de trabajo; en el experimento de Azure tenía que estar ocupada alrededor de una cuarta parte del tiempo solo para cubrir costos a precios Spot.
Proporción de prefijo y tasa de aciertos de caché. El tráfico de agentes reenvía historiales largos. Si la mayor parte de la entrada se repite, la entrada en caché es barata en cualquier plataforma, y puede ganar la opción que mejor aprovecha la caché, no la más barata por token. En la prueba de Azure, la entrada en caché supuso el 52% del valor servido.
Tasa de finalización por configuración. Mida la proporción de tareas completadas correctamente para cada modelo y política de contexto que esté evaluando. Las cifras de Asana muestran que puede variar seis veces con el mismo modelo.
Horas de operación. Cuente el tiempo de ingeniería para aplicar parches, monitorizar, escalar y reiniciar una plataforma autoalojada, y la carga de las guardias. Suele ser la partida más grande que falta en los business cases de autoalojamiento.
Con esas cuatro cifras, la comparación se vuelve aritmética. Sin ellas, es un debate entre una tarifa y el precio de una GPU, y pierde quien nunca comprobó sus supuestos.
Nuestra expectativa, y es una opinión, no un hecho: a medida que maduren los modelos de decisión, la caché de prompts y el enrutamiento, el precio por token de los modelos de frontera pesará menos en los presupuestos de IA de las empresas que la proporción de horas, tokens y ejecuciones que no producen nada. Los equipos que midan primero esa proporción elegirán su infraestructura con evidencia. Los demás la elegirán por la tarifa.