Si ha cotizado inferencia en GPU recientemente, ya conoce el sobresalto del precio. Una H100 reservada en una nube importante supera los $4/h. El spot es más barato pero impredecible. Un equipo dedicado de 8 GPU llega a decenas de miles al mes. Y eso antes de la salida de datos, el soporte o cualquiera de las herramientas de valor añadido.
Esa cifra no sale de la nada. Refleja tres costos reales que la nube tiene que recuperar. Cada uno abre una oportunidad para que un modelo distribuido lo haga mejor.
Primer factor de costo: la utilización.
Una GPU reservada se factura la use o no. La nube le vende el derecho a una porción de silicio durante una ventana de tiempo, y necesita que el cliente promedio la use lo suficiente para que la tarifa cubra sus costos. La mayoría de los clientes no lo hace. Datos internos de operadores con los que hemos hablado sitúan la utilización promedio de GPU en empresas en un 15–40% a lo largo del día, con utilización de un solo dígito por la noche y los fines de semana.
Usted paga la tarifa por hora por el 100% de las horas, pero solo obtiene trabajo útil de una fracción. El resto se amortiza en el precio que ve en la página.
Segundo factor de costo: el CapEx.
Una H100 se vende hoy por unos $30,000. Un nodo de 8 GPU con red y hardware anfitrión supera cómodamente los $300,000 más la instalación. El proveedor de nube paga eso por adelantado y lo recupera a lo largo de la vida económica de la GPU, normalmente de 3 a 5 años. También tiene que financiar la depreciación de la generación anterior, que ahora es barata, y el margen para la siguiente generación, que todavía no se entrega.
Añada energía, refrigeración, inmuebles y personal de operaciones, y el costo total de propiedad completo es de $5–7/h por H100 solo para alcanzar el punto de equilibrio a plena utilización. La tarifa publicada tiene que superar eso más la brecha de utilización descrita arriba.
Tercer factor de costo: la prima de tiempo real.
Este es el que más gente pasa por alto. Cuando aprovisiona capacidad de GPU, está pagando para que esté caliente y en espera. La nube tiene que mantener el hardware en línea, el modelo cargado y la canalización de inferencia lista para atender una solicitud en milisegundos, aunque no llegue ninguna solicitud.
Ese estado de espera tiene un costo real. Es la misma razón por la que el precio bajo demanda en la nube es de 4 a 6 veces el precio spot: paga por disponibilidad garantizada, no por cómputo que se ejecutó. Y para muchas cargas de trabajo, usted no necesita esa garantía. A una canalización de procesamiento de documentos que se ejecuta cada noche no le importa si cada trabajo empieza en 50 ms o en 5 segundos. A un trabajo de enriquecimiento de datos que tarda cuatro horas no le importa tardar cuatro horas y tres minutos.
Si su carga de trabajo tolera unos segundos de espera en cola, está pagando muchísimo de más al ejecutarla en una GPU con precio de tiempo real.
Qué cambia con un mercado distribuido.
Una red de inferencia distribuida reconfigura esos tres factores.
Utilización. Hay GPU inactivas en todas partes: en laboratorios de investigación, PC para videojuegos, pequeños centros de colocación y clústeres empresariales sobredimensionados. Sus propietarios ya pagaron el CapEx; el costo marginal de ejecutar un trabajo en ellas es energía, red y un pequeño margen para el operador. Un mercado permite a esos propietarios vender esa capacidad inactiva a un precio que refleja el costo marginal, no el CapEx amortizado. El efecto agregado es encontrar las GPU que habrían estado al 5% de utilización y llevarlas al 60%, con el ahorro de precio fluyendo hacia el cliente.
CapEx. El operador del mercado no es dueño de las GPU. No cargamos con la depreciación, no financiamos el margen para la siguiente generación y no tenemos que amortizar una flota. Cobramos una pequeña comisión de plataforma por cada trabajo — infraestructura de transacciones, programación, facturación, soporte — y el resto va al operador propietario del silicio.
Prima de tiempo real. Una cola de trabajos asíncrona es un producto de otra forma. Envíe un trabajo, reciba un identificador de trabajo y recoja el resultado cuando esté listo. No hay capacidad caliente reservada para usted. El cómputo arranca cuando el programador empareja su trabajo con un worker disponible, se ejecuta y se libera. Paga solo por el trabajo que se ejecutó, a la tarifa de un cómputo que de otro modo no se habría usado.
Las cifras, en términos aproximados.
Tome un trabajo con Llama 3.1 8B que produce 1,000 tokens de salida. En el producto de inferencia serverless de una nube importante, eso cuesta hoy aproximadamente $0.10–$0.20, incluida la prima de tiempo real. El mismo trabajo en MicroDC.ai se factura en torno a $0.011 — una tarifa base más una tarifa por token — unas 10 veces más barato.
La diferencia se amplía con modelos más grandes. Un trabajo con Llama 3.3 70B de la misma longitud supera $1 en serverless de tiempo real y queda muy por debajo de $0.10 en una red distribuida. Para trabajos en contenedor — imágenes Docker arbitrarias en GPU — la diferencia es aún mayor, porque los productos de contenedores en GPU de la nube llevan una prima de reserva adicional.
Dónde esto no funciona.
Conviene ser honestos: un mercado distribuido no es la forma adecuada para algunas cargas de trabajo.
- Latencia inferior a un segundo de cara al usuario. Si su producto necesita empezar a transmitir tokens a un usuario en 200 ms, un trabajo asíncrono en cola no es su herramienta. Lo que quiere es inferencia en tiempo real.
- Sistemas críticos en tiempo real. Si un trabajo perdido significa una falla en el mundo real, quiere el SLA de la nube, no un grupo distribuido.
- Requisitos estrictos de localización. Si las normas de soberanía de datos exigen que el cómputo se ejecute en una jurisdicción concreta, un mercado con operadores en muchas ubicaciones requiere un filtrado cuidadoso; es posible, pero implica más trabajo.
Para todo lo demás — procesamiento de documentos, enriquecimiento de conjuntos de datos, generación de contenido, cargas de investigación, canalizaciones de automatización, lotes nocturnos — el cálculo favorece claramente al modelo distribuido.
La conclusión.
"La inferencia en GPU es cara" no es un hecho sobre las GPU. Es la consecuencia de tres decisiones de precios tomadas por los hiperescaladores: incluir la capacidad no utilizada en la tarifa, recuperar el CapEx a través de esa tarifa e incluir un SLA en tiempo real que quizá usted no necesite. Elimine cualquiera de las tres y el precio se reduce a la mitad. Elimine las tres y obtiene la reducción de un orden de magnitud que estamos viendo en producción.
Si su carga de trabajo tolera tiempo en cola — y la mayoría de las cargas por lotes lo toleran — debería ejecutarla en un lugar que no le haga pagar por lo que no está usando.