← Resources
By Jordan Malik
— Staff Engineer, Inference
·
· GUIDE
Cuándo alojar LLMs por tu cuenta sale más barato que una API
Alojar un LLM por tu cuenta sale más barato que una API solo por encima de un volumen de tokens que depende por completo de la utilización de la GPU: no existe un único punto de equilibrio. Esta guía cubre las cuentas reales, por qué el batching y la cuantización lo deciden, el coste operativo oculto y por qué la solución híbrida suele ser la respuesta correcta.
No existe un único punto de equilibrio
La respuesta honesta a «¿cuándo sale más barato el autoalojamiento?» es un rango condicionado por la utilización, no una cifra. De ahí que las estimaciones publicadas difieran en órdenes de magnitud: parten de distintos precios de GPU, tasas de utilización y la API con la que se comparan.
La pauta útil: el autoalojamiento tiende a ganar a las APIs premium con un volumen sostenido relativamente modesto (unos pocos millones de tokens al mes en una GPU bien aprovechada), pero ganar a las APIs económicas exige mucho más (decenas o cientos de millones al mes). Una regla general orientativa se sitúa en un par de millones de tokens al día, de forma sostenida. Por debajo de esa cifra, una API casi siempre gana.
Las cuentas de la GPU
Alojar por tu cuenta implica alquilar o comprar una GPU, y ese coste fijo es lo que tu volumen de tokens tiene que «llenar». Una H100 bajo demanda cuesta entre 1,50 y 3,00 $/hora en nubes especializadas (más en los hyperscalers), por lo que una H100 dedicada 24/7 supone del orden de 1.000–5.000 $ al mes según el nivel del proveedor.
Esa cuota mensual es fija, la uses o no, y por eso el coste por millón de tokens solo es bajo con alta utilización. Bien aprovechado, un modelo de tamaño medio puede situarse muy por debajo de un dólar por millón de tokens; al 10 % de carga, el coste real por token se multiplica aproximadamente por diez, suficiente para que el autoalojamiento salga más caro que una API premium. Una GPU inactiva es la forma más rápida de perder el argumento del coste.
El batching y la cuantización lo deciden
Dos palancas desplazan el punto de equilibrio más que ninguna otra cosa. El batching continuo (gracias a los servidores de inferencia modernos) es el motor económico: atender muchas peticiones a la vez en la misma GPU puede reducir drásticamente el coste por token; pasar de una petición a la vez a lotes grandes puede mejorar el rendimiento en órdenes de magnitud. El tráfico irregular y de baja concurrencia no llena los lotes y rinde varias veces peor que en el pico, razón por la que las cargas de trabajo con ráfagas se autoalojan mal.
[La cuantización](/articles/llm-quantization-explained-gguf) es la otra palanca: FP8 duplica aproximadamente el rendimiento con una pérdida de calidad mínima, e INT4 puede triplicarlo a la vez que reduce el modelo lo suficiente para que quepa en una GPU más pequeña y económica. Juntos, el batching y la cuantización pueden multiplicar por varias veces el coste por token en uno u otro sentido.
El coste oculto: las operaciones
La factura de la GPU no es toda la factura. Las operaciones suelen añadir varias veces el coste bruto del hardware: un ingeniero de MLOps tiene un salario de seis cifras, y cada ciclo de actualización del modelo —recuantizar, probar, volver a desplegar— supone semanas de trabajo. Los modelos de pesos abiertos «gratuitos» pueden esconder cientos de miles de dólares al año en ingeniería en cuanto tienes en cuenta el servidor de inferencia, la gestión de drivers y CUDA, el autoescalado y la monitorización.
Es la partida que hunde las cuentas ingenuas del autoalojamiento. El coste por token de la ficha técnica da por hecho que la GPU se gestiona sola; en realidad, alguien tiene que mantenerla en marcha, y esa persona no es gratis.
Cuándo gana claramente la API (y los factores ajenos al coste)
Una API es la opción correcta para volúmenes bajos o irregulares, tráfico impredecible, equipos sin MLOps propio y cualquier necesidad de modelos de calidad frontier que no puedas ejecutar tú mismo. Según una estimación, una API es la mejor opción para la gran mayoría de los casos de uso, y los precios de las APIs siguen bajando, lo que empuja el punto de equilibrio del autoalojamiento cada vez más arriba con el tiempo.
Dos factores quedan por completo fuera de las cuentas: la latencia y la privacidad. El autoalojamiento gana en residencia de datos, cargas de trabajo reguladas y latencia predecible dentro de la región, al margen de la economía de los tokens; consulta nuestra [guía sobre on-premise](/articles/on-premise-ai-for-enterprise). Estos factores pueden justificar el autoalojamiento incluso cuando las cuentas puras no lo hacen.
Enruta por economía con osFoundry
La respuesta pragmática es híbrida: enrutar por criterios económicos, no ideológicos. El volumen alto y constante pertenece a la inferencia local o propia, donde llenar los lotes de una GPU reduce el coste por token. Las cargas de volumen medio y predecibles encajan en un endpoint de GPU dedicado: rendimiento que aprovecha bien la utilización sin tener que poseer hardware ni asumir el multiplicador operativo completo. El tráfico irregular, bajo o impredecible, y todo lo que requiera calidad frontier, se queda en APIs BYOK de pago por token.
osFoundry maneja automáticamente las palancas que de verdad mueven el punto de equilibrio —cuantización, batching y enrutamiento por niveles— y permite que la misma carga de trabajo se ejecute en local, en un endpoint dedicado o a través de una API BYOK. Así capturas el ahorro allí donde el autoalojamiento gana sin tener que gestionar tú mismo CUDA, el autoescalado ni las cuentas del ciclo de uso. (Nuestro [desglose de costes BYOK](/articles/byok-vs-managed-ai-cost-breakdown) cubre el lado de la API de la ecuación.)
Frequently asked questions
- ¿A qué volumen de tokens el autoalojamiento sale más barato que una API?
- Depende de la utilización, así que no hay una cifra única. A grandes rasgos, el autoalojamiento puede ganar a las APIs premium con unos pocos millones de tokens al mes en una GPU bien aprovechada, pero ganar a las APIs económicas exige decenas o cientos de millones al mes. Un umbral orientativo habitual es un par de millones de tokens al día de forma sostenida; por debajo de eso, una API suele ganar.
- ¿Cuánto cuesta tener una H100 al mes?
- Una H100 bajo demanda cuesta entre 1,50 y 3,00 $/hora en nubes de GPU especializadas (más en los hyperscalers), por lo que una instancia dedicada 24/7 se sitúa alrededor de 1.000–5.000 $ al mes según el nivel del proveedor. Ese coste fijo es lo que el volumen de tokens debe cubrir para que el autoalojamiento salga a cuenta.
- ¿Por qué la utilización de la GPU determina la viabilidad económica del autoalojamiento?
- Porque la GPU cuesta lo mismo esté ocupada o inactiva. Bien aprovechada, el coste por millón de tokens puede caer por debajo de un dólar; con poca carga (digamos un 10 %), el coste real por token se multiplica aproximadamente por diez, lo que a menudo hace que el autoalojamiento salga más caro que una API premium. Una GPU inactiva es puro desperdicio: la utilización es la variable más decisiva.
- ¿Sale el autoalojamiento más barato que una API económica, como un modelo pequeño alojado?
- Por lo general, solo con volúmenes muy altos. Las APIs económicas tienen precios muy agresivos, así que ganarles mediante autoalojamiento suele exigir decenas o cientos de millones de tokens al mes con buena utilización. Frente a las APIs premium, el cruce se produce mucho antes. Compara con la API concreta que usarías de otro modo, no con una tarifa genérica.
- ¿Cuánto reduce la cuantización el coste del autoalojamiento?
- Considerablemente. FP8 duplica aproximadamente el rendimiento con una pérdida de calidad mínima, e INT4 puede triplicarlo a la vez que reduce el modelo para que quepa en una GPU más pequeña y económica. En un modelo grande, eso puede recortar el coste por millón de tokens a la mitad o más; la cuantización es una de las palancas de coste con mayor impacto para el autoalojamiento.
- ¿Qué costes ocultos conlleva alojar un LLM por tu cuenta?
- Las operaciones. Más allá de la factura de la GPU, pagas por la ingeniería de MLOps (un salario de seis cifras), los ciclos de actualización del modelo (semanas de trabajo cada uno) y el servidor de inferencia, la gestión de drivers, el autoescalado y la monitorización. Estas partidas suelen añadir varias veces el coste bruto del hardware y son justo lo que omiten la mayoría de los cálculos de punto de equilibrio ingenuos.
- ¿Puedo combinar autoalojamiento y APIs para optimizar el coste?
- Sí: lo híbrido suele ser el enfoque más inteligente. Ejecuta el volumen alto y constante en inferencia local o propia, las cargas de volumen medio y predecibles en un endpoint dedicado, y el tráfico irregular o de bajo volumen (más todo lo que requiera calidad frontier) en una API de pago por token. Enrutar por criterios económicos captura el ahorro del autoalojamiento sin pagar GPUs inactivas en trabajo con ráfagas.
Sources