Una H100 de 2 dólares la hora rindió cuatro veces su costo en una mañana intensa. En la semana, perdió dinero
Un ingeniero de Microsoft ejecutó Qwen3.8-27B en una H100 Spot de Azure. Las horas intensas pagaron cuatro a uno; la semana completa no cubrió el cómputo. Decidió la utilización.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Durante tres horas de la mañana del 9 de octubre, una sola H100 en Azure atendió 1.434 solicitudes a Qwen3.8-27B: 168,7 millones de tokens de entrada y 1,27 millones de tokens de salida. Al precio de lista público de ese modelo, esos tokens valían 24,35 dólares. Las tres horas de VM Spot costaron 4,65 dólares.
Ahí se detienen casi todos los argumentos a favor del autoalojamiento. Wuyi Weng, que hizo el experimento y lo publicó en el blog Apps on Azure de Microsoft el 10 de octubre, siguió midiendo el resto de la semana.
| Medida | Las 3 horas más intensas (9 de oct.) | Primera semana (3 al 10 de oct.) |
|---|---|---|
| Horas con el servidor del modelo activo | 3,0 | 37,9 |
| Solicitudes | 1.434 | 5.469 |
| Tokens de entrada (parte servida desde la caché de prefijos) | 168,7 M (88%) | 564,2 M (88%) |
| Tokens de salida | 1,27 M | 6,11 M |
| Valor a precio de lista | 24,35 dólares | 85,94 dólares |
| Costo de cómputo | 4,65 dólares | Unos 98 dólares por 46 horas de VM, más discos y NAT |
Las horas intensas rindieron 8,12 dólares en tokens por hora de servidor activo, frente a unos 2 dólares de VM. En la semana, eso bajó a 2,27 dólares por hora de servidor, y las VM funcionaron en realidad unas 46 horas, contando la configuración, la carga del modelo, los benchmarks y las primeras ejecuciones antes de que existiera la telemetría. La semana costó unos 98 dólares de cómputo para producir 86 dólares en tokens. La respuesta del propio autor a la pregunta del título: compensa cuando está ocupada.
De dónde salió el valor
Un detalle de los datos desmonta una costumbre habitual. En la ventana intensa, la entrada servida desde la caché produjo el 52% del valor en tokens, la entrada calculada en el momento el 35% y la salida solo el 13%. El tráfico de tipo agente reenvía historiales largos de conversación, y la caché de prefijos de vLLM sirvió el 88% de los tokens de entrada.
Los benchmarks de rendimiento suelen informar tokens de salida por segundo. En esta carga, la salida fue menos de una quinta parte del valor. Si sus agentes reenvían contextos largos, el procesamiento del prompt y el comportamiento de la caché importan más que la velocidad de generación, y un benchmark que los ignora mide lo que no es. Es el mismo mecanismo que redujo el costo del agente de navegador de Asana, visto desde la infraestructura.
Las horas que se pagan y no se pueden vender
La pérdida de la semana no vino de una inferencia lenta. Vino de horas sin tráfico que pagara: cargar el checkpoint de 31 GB, ejecutar benchmarks, tiempo ocioso e interrupciones.
La capacidad Spot vende GPU sobrantes con descuento, sin SLA y con 30 segundos de aviso antes del desalojo. El experimento sufrió siete desalojos en unas 40 horas de ejecución y cinco intentos de crear o reiniciar una VM en una región que fallaron por falta de capacidad. El autor señala además que la tasa de desalojo de Azure es por hora: al 5% por hora, una ejecución de ocho horas tiene aproximadamente una probabilidad entre tres de ser interrumpida. El consejo del artículo es leer incluso el tramo más bajo de desalojo como un motivo para planificar interrupciones, no como señal de que son raras.
Con los precios de esta prueba, la GPU tenía que estar ocupada aproximadamente una cuarta parte del tiempo para cubrir costos. Cada hora desalojada, cargando u ociosa era una hora en la que no podía generar valor.
Esto fue un experimento, no un diseño de producción
El autor es claro sobre los límites, y son importantes. El gateway no tenía autenticación propia; una lista de IP permitidas en el túnel era el único control de acceso, algo válido para pruebas personales y nada más. Las VM Spot no tienen SLA de disponibilidad. La capacidad regular eliminaría los desalojos a un precio por hora mayor, lo que mueve el punto de equilibrio. Y el “valor a precio de lista” es una equivalencia, no dinero ahorrado.
Nada de esto convierte el autoalojamiento en una mala idea. Lo convierte en una cuestión de utilización. Las condiciones del autor para que tenga sentido merecen conservarse: tráfico constante cuyos prompts comparten prefijos largos, una necesidad real de controlar el checkpoint exacto y la configuración de servicio, y una carga que tolere un reinicio, o presupuesto para capacidad regular.
Es un caso más estrecho que “los pesos abiertos son más baratos”, y honesto. Como señalamos cuando Reflection publicó los pesos de Beam, con pesos abiertos la obligación de operar pasa a usted. Este experimento pone precio a una parte de esa obligación: las horas en las que nadie usa lo que usted mantiene en marcha. Antes de comparar el precio por hora de una GPU con el precio por token de una API, mida cuántas horas al día su tráfico mantendría realmente ocupada la GPU.