¿Compensa montarte tu propia infraestructura para correr modelos abiertos? Hemos hecho números

Cada pocas semanas una empresa viene a preguntarnos qué hardware le aconsejamos. El plan suele ser el mismo siempre:

"Los modelos son abiertos. Los bajamos nosotros y los correremos nosotros."

Y muchas veces tiene sentido. Sobre todo si la empresa es grande y ya tiene hardware y gente para disponibilizarlo.

Los modelos abiertos permiten tener más control sobre los datos, elegir dónde ejecutarlos y evitar depender de un proveedor concreto. Nosotros existimos, en buena parte, por ese mismo instinto.

El problema aparece cuando solamente pensamos en el precio de la GPU, que ya de por sí asusta bastante a mucha gente.

Porque los pesos son la parte gratis.

Lo que cuesta es todo lo demás: mantener las GPUs encendidas aunque no estén trabajando, conseguir suficiente utilización para amortizarlas, optimizar el serving, mantener drivers y motores de inferencia, responder cuando algo falla y dedicar personas a todo ello.

Así que vamos a intentar responder a una pregunta bastante más sencilla:

¿Cuánto me cuesta realmente correr un modelo abierto yo mismo frente a pagar una API?

Y después veremos todo lo que hay detrás de esa cifra.

Si solo quieres la respuesta rápida

Vamos a utilizar GLM-5.2 como ejemplo.

Para servirlo en FP8 tomamos como referencia un nodo de 8× NVIDIA H200.

Si alquilas ese hardware, nuestra cuenta base queda aproximadamente así:

Esta es probablemente la cifra más importante de todo el artículo.

Antes de saber cuántos tokens vas a servir, tu infraestructura self-hosted ya te cuesta alrededor de 25.000 € al mes.

La API funciona justo al revés.

No pagas por tener ocho GPUs esperando tráfico. Pagas solo por los tokens que consumes.

Por eso la comparación cambia muchísimo dependiendo de tu volumen.

Tomemos tres precios posibles de GLM-5.2 para verlo:

• API promocional: el precio más barato disponible ahora mismo en OpenRouter.
• API competitiva: una referencia como el precio base de DeepInfra.
• Precio estándar: los $1,40/M de entrada y $4,40/M de salida que aparecen como precio sin descuento en OpenRouter.

Para hacer todas las cuentas utilizamos una proporción de 3 tokens de entrada por cada token de salida.

Con ese mix, aproximadamente:

Ahora sí podemos hacer la comparación que nos interesa, en función de tu consumo mensual:

Aquí ya aparece una imagen bastante más clara.

Con 5.000 o 10.000 millones de tokens al mes, alquilar ocho H200 para ti solo difícilmente tiene sentido económico, y tu CFO no lo va a aprobar jamás.

A partir de 15.000 o 20.000 millones de tokens al mes, la respuesta empieza a depender muchísimo del precio por token que puedas conseguir.

Y con decenas de miles de millones de tokens al mes, una carga estable y un precio de API normal, el self-hosting empieza a ponerse muy interesante.

Pero hay una excepción bastante curiosa.

El precio promocional actual de GLM-5.2 en OpenRouter tiene un descuento enorme. Con ese precio, ni siquiera utilizando nuestro nodo prácticamente a plena capacidad conseguimos competir con la API.

Eso dice más del descuento que del self-hosting. No puedes competir comprando capacidad fija contra alguien que en ese momento está vendiendo esa misma capacidad un 77% por debajo de su precio de lista. Así que te aconsejaría hacer tus cuentas contra el precio estándar o el competitivo, y tratar el promocional como lo que es: una oferta que puede desaparecer cualquier día.

Y hay otro coste importante: la capacidad que dedicas a un modelo deja de estar disponible para los demás.

Si tus 8× H200 están sirviendo GLM-5.2 a plena capacidad, no puedes utilizar esas mismas GPUs simultáneamente para servir otro modelo grande sin repartir recursos o reducir la capacidad disponible para GLM-5.2.

Esto significa que self-hostear no solo te obliga a conseguir una utilización alta. También tienes que conseguirla en el modelo correcto.

Puedes tener GLM-5.2 al 90% mientras DeepSeek está al 10%, y no puedes trasladar automáticamente esa capacidad de un modelo al otro. Si quieres garantizar capacidad para ambos, necesitas dimensionar infraestructura para ambos o introducir una capa de scheduling y carga/descarga de modelos, con sus propios costes y trade-offs.

Lo que cuenta es la utilización de las GPUs asignadas a cada modelo concreto, y esa siempre es peor que la del parque entero.

Antes de seguir: ¿qué significa realmente "montar mi infraestructura"?

Conviene separar tres decisiones que a menudo se meten en el mismo saco.

Plataforma de inferencia compartida. No compras ni operas GPUs. Pagas por utilizar capacidad de inferencia. Es especialmente interesante cuando la demanda es irregular, quieres probar modelos distintos o no quieres convertir la operación de inferencia en parte de tu producto. (OpenRouter)

Infraestructura dedicada gestionada. Tienes capacidad dedicada para ti, pero no necesariamente quieres encargarte de todo el stack de inferencia. Es una opción intermedia: más control y previsibilidad que una infraestructura compartida, sin asumir todo el trabajo operativo. (Helmcode)

Self-hosting. Alquilas o compras las GPUs y operas tú mismo la infraestructura, desde el despliegue hasta la optimización, monitorización y mantenimiento.

Y dentro del self-hosting hay además otra decisión importante:

¿Alquilo las GPUs o las compro?

Son cuentas muy diferentes.

Si alquilo las GPUs: unos 25.000 € al mes

Tomemos el caso que estamos analizando.

GLM-5.2 es un modelo de 744B de parámetros. Para este cálculo tomamos como referencia un despliegue FP8 sobre 8× H200 de 141 GB.

Los precios públicos de alquiler varían bastante según proveedor, región, compromisos y disponibilidad.

En agosto de 2026 encontramos referencias que van desde aproximadamente $3,95 a $4,50 por GPU/hora en proveedores especializados hasta $50,44/hora por un nodo completo de 8× H200 en CoreWeave, que son unos $36.800 al mes.

Tomamos $4,30 por GPU/hora, que está en la mitad de esa horquilla. Con ese precio, nuestra factura queda alrededor de:

~21.500 €/mes por el nodo.

Pero esa es solamente la primera factura. Todavía no hemos operado nada.

La parte que solemos olvidar

El plan de "lo corremos nosotros" también incluye un trabajo nuevo: operar inferencia.

Los modelos cambian constantemente.

Cada vez que aparece uno que puede mejorar vuestro stack hay que comprobar qué calidad ofrece, cuánto throughput consigue, qué memoria necesita, qué motor de inferencia soporta, cómo se comporta con vuestro tráfico, qué ocurre con contextos largos y, sobre todo, si funciona con vuestros casos reales.

Sabemos lo que cuesta porque lo hacemos nosotros.

Después está la optimización.

Desplegar un modelo no significa que hayas conseguido el rendimiento que puede dar ese hardware. Hay que decidir precisión, cuantización, tensor parallelism, batching, configuración del motor, contexto, KV cache y scheduling.

En nuestros propios despliegues hemos medido mejoras relevantes simplemente optimizando estas variables. Por ejemplo, al cuantizar Qwen 3.6 a NVFP4 conseguimos mejorar su throughput un 11% y dar sitio para 32 clientes más.

Eso es FinOps de inferencia. Porque mejorar el throughput es dinero.

Si consigues servir el doble de tokens con el mismo hardware, acabas de reducir a la mitad la infraestructura necesaria para conseguir ese throughput.

Y después hay que mantenerlo: motores de inferencia, drivers, kernels, versiones de CUDA, seguridad, monitorización, alertas, capacidad, despliegues y cambios de modelo.

Y está el on-call.

La inferencia deja de ser "algo que utilizas" y pasa a ser un sistema que tienes que operar.

Si falla a las tres de la mañana, es tu problema. Si falla en agosto, también.

Para hacer la cuenta comparable hemos imputado:

0,5 FTE de ingeniería MLOps / infraestructura.

Con un coste empresa de 90.000 €/año, son aproximadamente:

3.750 €/mes.

No estamos diciendo que todo self-hosting necesite exactamente medio ingeniero.

Es un supuesto.

Un equipo que ya tenga MLOps, GPUs y capacidad de operación puede imputar mucho menos coste incremental. Una empresa que parte de cero puede necesitar bastante más.

Por eso nuestra cuenta completa es:

21.500 € de infraestructura + 3.750 € de operación = 25.250 €/mes.

El problema: pagas esos 25.250 € tengas o no tengas tráfico

Aquí está probablemente la mayor diferencia entre self-hosting y API.

Tu nodo está disponible unas 730 horas al mes. Tu tráfico, no. Si no tienes un volumen de peticiones constante, la cuenta no sale.

Imagina una empresa cuyo principal tráfico se concentra durante el horario laboral.

Habrá picos. Habrá valles. Habrá fines de semana. Habrá noches. Habrá momentos en los que las GPUs estarán esperando trabajo.

Pero tu factura seguirá siendo:

25.250 €.

Podríamos hablar aquí de "utilización efectiva", que es la métrica técnicamente correcta. Es más fácil verlo en tokens.

¿Cuántos tokens puedo sacar de esos 25.250 €?

Para tener una referencia utilizamos un benchmark público de GLM-5.2 en FP8 sobre exactamente 8× H200 con SGLang.

En la configuración *balanced*, con concurrencia 64 y un workload sintético de 8.192 tokens de entrada y 1.024 de salida, el nodo alcanzó aproximadamente:

17.993 tokens por segundo agregados.

Si mantuviéramos ese throughput durante las 730 horas de un mes, hablaríamos de aproximadamente:

47.000 millones de tokens al mes de capacidad teórica.

Ahora podemos entender mejor el coste.

La infraestructura cuesta lo mismo todos los meses.

Si sirves solamente 5B tokens, cada millón te está costando unos 5 €.

Si sirves 30B, baja a unos 0,84 €.

Y si consiguieras mantener el nodo prácticamente lleno durante todo el mes, te acercarías a unos 0,53 €/M.

Entonces, ¿cuándo empieza a compensar?

No existe un único break-even del self-hosting. Depende de contra qué modelo y qué API estés comparando.

Con nuestras hipótesis:

Contra una API a precio estándar, alrededor de 14.000 millones de tokens mensuales el hardware propio empieza a tener sentido económico. Ojo, solo económico.

Contra una API muy competitiva, necesitas acercarte a 25.000 millones y mantener más de la mitad de la capacidad del nodo realmente ocupada.

Contra el precio promocional que existe ahora mismo para GLM-5.2, no llegas al break-even ni llenando el nodo todo el mes.

Por eso mirar solamente el precio de una H200, o solamente el precio de un millón de tokens, no sirve.

¿Por qué una plataforma puede hacer esto?

¿Cómo puede una plataforma cobrar menos por servir esos tokens que lo que cuesta el nodo que ella misma alquila u opera?

Por dos cosas.

La primera es la utilización. Una empresa individual tiene una curva de demanda. Una plataforma que sirve a cientos de empresas tiene cientos de curvas de demanda.

Cuando un cliente está en un valle, otro puede estar en un pico.

Eso es multiplexado estadístico: utilizar la misma capacidad para cargas que no coinciden en el tiempo.

Una empresa individual no puede multiplexarse con sus propios clientes. Una plataforma sí puede agregar las curvas de demanda de muchos clientes.

La segunda es la operación. El medio FTE que hemos cargado entero a nuestra empresa hipotética, en una plataforma se reparte entre muchos clientes.

Aquí no hay magia. Hay una utilización mayor del hardware y un equipo cuyo trabajo consiste precisamente en operar esa infraestructura.

¿Y si en lugar de alquilar las H200 las compro?

Aquí aparece otra objeción razonable:

"Alquilar GPUs es caro. Yo las compro y las amortizo."

Correcto.

En 2026 encontramos sistemas completos HGX H200 de 8 GPUs alrededor de los $300.000 a $420.000, dependiendo del fabricante y la configuración. Incluso hay configuraciones públicas de Exxact que parten de aproximadamente $296.000.

Así que si quieres "montar tu propia infraestructura" comprando el hardware, piensa aproximadamente en:

300.000 a 400.000 € de inversión inicial para un nodo 8× H200.

Y necesitas electricidad, refrigeración, rack o datacenter, networking, mantenimiento, sustitución de componentes y operación.

Un servidor 8× H200 puede consumir varios kilovatios. Algunas configuraciones comerciales publican consumos del sistema alrededor de 6 a 7 kW, antes de considerar el overhead de refrigeración del datacenter.

Si tomamos como ejemplo un nodo de 320.000 € y lo amortizamos linealmente durante 36 meses:

320.000 € / 36 = ~8.900 €/mes de amortización.

Eso es bastante menos que alquilar el mismo hardware por 21.500 €/mes. Pero no significa que tu infraestructura cueste 8.900 €/mes.

Significa que el hardware te cuesta eso una vez amortizado.

Todavía tienes que añadir energía, refrigeración, rack, red, mantenimiento y personas. Y además has adelantado cientos de miles de euros.

Existe también otro coste que es más difícil de poner en una hoja de cálculo: la depreciación tecnológica.

Una H200 que compras hoy seguirá funcionando dentro de tres años.

La pregunta es si dentro de tres años seguirá siendo la GPU con la que quieres servir inferencia.

Comprar hardware puede ser una opción excelente cuando tienes una utilización muy alta, predecible y sostenida. Pero no convierte la capacidad en gratuita.

Cuándo gana el self-hosting

Después de todas estas cuentas, hay escenarios donde el self-hosting tiene muchísimo sentido.

Tienes una carga sostenida de verdad. Decenas de miles de millones de tokens al mes, tráfico relativamente estable y un modelo que no vas a cambiar cada dos semanas. Batch, investigación continua o determinados servicios 24/7 pueden acercarse mucho a este escenario.

Ya tienes infraestructura y equipo. Si ya tienes cluster, MLOps, datacenter o capacidad contratada, el cálculo cambia completamente. El coste incremental de operar otro modelo puede ser mucho menor que los 3.750 € que hemos utilizado aquí.

Puedes utilizar las GPUs para más cosas. Quizá GLM-5.2 no llena el nodo, pero cuando no hay inferencia utilizas las GPUs para fine-tuning, batch, investigación u otros modelos. Tu utilización agregada puede ser mucho mayor.

Necesitas control por razones que no son económicas. Hay empresas cuyo compliance, cuya seguridad o cuya arquitectura les obliga a on-premise o a infraestructura dedicada. En esos casos el requisito ya ha decidido parte de la infraestructura, y la aritmética de este artículo solo sirve para saber lo que cuesta cumplirlo.

Cuándo gana pagar una API

También hay una serie de situaciones donde la respuesta es bastante clara.

Si consumes 2B, 5B o incluso 10B tokens al mes y tu tráfico es irregular, comprar o alquilar ocho H200 exclusivamente para ti probablemente no tenga demasiado sentido económico.

Si cambias de modelo constantemente, tampoco.

Si no tienes un equipo que quiera convertirse en operador de infraestructura de inferencia, tampoco.

En resumen, la decisión por situación:

Haz la cuenta con tus números

Los números de este artículo son deliberadamente reproducibles. Cambia el precio de la GPU, el número de GPUs, el throughput, la utilización, los tokens mensuales, el coste de ingeniería y el precio de la alternativa, y vuelve a calcular.

Las fórmulas son estas:

TCO mensual = infraestructura + operación

>

Coste por millón de tokens = TCO mensual / tokens servidos × 1.000.000

No hay una cifra universal de lo que cuesta self-hostear un LLM. Hay una cifra para tu modelo, tu hardware, tu tráfico y tu equipo.

Si quieres hacer la comparación con tu propio consumo sin montar la hoja de cálculo, tenemos una calculadora que hace exactamente esta aritmética con los precios de mercado actualizados.

Nos gustan los modelos abiertos precisamente porque permiten elegir. Nuestro valor está en ofrecerte esos modelos con tarifa plana sin que tengas que operar ni comprar infraestructura. Y si tu caso es de los que piden capacidad dedicada, también la operamos nosotros.

Y para terminar, un consejo honesto. A la velocidad a la que salen modelos, cuantizaciones y chips, comprar hierro tiene sentido en muy pocos casos. Sobre todo si tu negocio no es ese. Céntrate en construir un producto que la gente quiera y pague por él, y usa un proveedor de IA igual que usas un proveedor de cloud.

---

Supuestos y fuentes

*Modelo de referencia:* GLM-5.2, 744B de parámetros, en un despliegue FP8 sobre un nodo de 8× H200 de 141 GB. La configuración real depende de precisión, cuantización, contexto, KV cache, batch y motor de inferencia.

*Precios de alquiler:* precios públicos de agosto de 2026. CoreWeave ($50,44/hora por nodo HGX de 8× H200), Jarvislabs ($3,99/GPU/hora), Nebius ($4,50/GPU/hora), RunPod ($4,39/GPU/hora). El nodo de 21.500 €/mes corresponde a $4,30/GPU/hora durante 730 horas.

*Tipo de cambio:* EUR/USD 0,857.

*Coste de ingeniería:* 0,5 FTE con un coste empresa de 90.000 €/año. Es un supuesto del modelo y no un coste universal.

*Ratio de entrada/salida:* 3 tokens de entrada por cada token de salida, aplicado a los precios de API.

*Throughput:* 17.993 tokens/segundo agregados, medidos con SGLang en configuración *balanced*, concurrencia 64 y un workload sintético de 8.192 tokens de entrada y 1.024 de salida. Ese workload tiene una proporción distinta a la de 3:1 que usamos para los precios de API, así que la capacidad teórica de 47.000 millones de tokens al mes se mueve con el mix real de tu tráfico.

*Precios de API:* precio promocional y precio de lista de GLM-5.2 en OpenRouter, y el precio base de DeepInfra como referencia competitiva.

*Precios de compra:* sistemas HGX H200 de 8 GPUs entre $300.000 y $420.000 según fabricante y configuración, con configuraciones públicas de Exxact desde unos $296.000. Consumo del sistema de 6 a 7 kW en configuraciones comerciales, sin contar el overhead de refrigeración del datacenter.

Los precios de proveedores son una fotografía del mercado en la fecha indicada y pueden cambiar. Repite la aritmética con tus propios precios, utilización y volumen: el resultado puede ser diferente. Si te sale que el self-hosting gana, publícalo. Esa es precisamente la razón de hacer visibles los supuestos.