Autoalojar un LLM de peso abierto vs. una API: las cuentas reales de coste

Tu producto sale a producción, llama a una API de LLM, y la factura ha ido subiendo poco a poco cada mes. Así que haces lo que todo builder acaba haciendo: abres una pestaña nueva y te preguntas si alquilar una GPU y ejecutar Llama tú mismo saldría más barato.

La pregunta del coste de autoalojar un LLM tiene respuesta, pero no es el número único que los primeros resultados de búsqueda y las AI Overviews repiten sin parar. Depende de tres cosas que esos artículos aplanan: contra qué API estás comparando, cuán ocupada está tu GPU, y el coste operativo que nadie mete en la hoja de cálculo.

Aquí está la versión corta antes de los detalles: para la mayoría de los builders en solitario, autoalojar no gana en coste ahora mismo. Pero hay una línea concreta donde se invierte, y puedes calcularla sobre tu propia factura en unos dos minutos. Abajo están las cuentas de 2026 (precios actuales, cifras de VRAM por modelo, y una fórmula que puedes ejecutar).

La versión corta

• El punto de equilibrio no es un número. Son tres, según contra qué API estés comparando. Frente a una API de frontera (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro), autoalojar alcanza el equilibrio antes. Frente a una API económica de peso abierto (DeepSeek, DeepInfra, Together a aproximadamente $0.14–$0.50 por millón de tokens), casi nunca gana solo en coste.
• La utilización es el multiplicador que mata el caso en solitario. Una GPU alquilada cuesta lo mismo inactiva que a plena carga, así que una GPU corriendo al 10% de utilización cuesta aproximadamente 10× por token lo que cuesta a plena carga. Las cargas de trabajo en solitario e intermitentes se sitúan en baja utilización por defecto.
• Por debajo del punto de equilibrio, la ganancia en coste suele ser cambiar a una API económica de peso abierto, no autoalojar. Autoalojar se gana su sitio cuando el volumen sostenido frente a precios de frontera cruza la línea con más del 60% de utilización, o cuando tienes una razón ajena al coste (privacidad, latencia, control del fine-tuning).
• Ejecuta la fórmula sobre tus propios números antes de alquilar nada. Tokens de equilibrio ≈ coste mensual del GPU VPS ÷ tu precio combinado de API por token.

Qué no cubre esto

• Clústeres de GPU multinodo o a escala de datacenter. Esto es una decisión de coste en solitario, no de una flota.
• La economía del fine-tuning en profundidad (un cálculo aparte con sus propias compensaciones).
• Un tutorial de configuración paso a paso de Ollama vs vLLM. El alcance aquí es la cuestión del dinero, no la instalación.
• El hardware en propiedad como tu vehículo principal. La suposición de fondo es una GPU alquilada, ya que ese es el camino realista para un builder que no tiene ya una GPU sobre el escritorio.

Qué impulsa el coste (y dónde se equivocan los números populares)

Busca «self host LLM vs API cost» y aterrizarás en una cifra de equilibrio pulcra: algo como 11.000 millones de tokens al mes, o alrededor de $4,200 en gasto mensual de API, citada por el análisis de costes de braincuber y repetida casi al pie de la letra en la AI Overview en lo alto de la página. Es un número limpio. También es casi inútil por sí solo, porque oculta las dos variables que deciden tu respuesta.

La razón de que esto sea resbaladizo es que los dos lados de la comparación tienen formas de coste distintas. Una factura de API es un coste variable: pagas por token, así que la factura sube y baja con lo mucho que la uses. Una GPU alquilada es un coste fijo: pagas la misma tarifa mensual tanto si empujas mil millones de tokens por ella como si la dejas inactiva. Comparar un coste variable con uno fijo con un solo número exige fingir que sabes exactamente cuántos tokens fluirán, y a escala en solitario, normalmente no lo sabes.

Eso deja tres palancas que mueven el punto de equilibrio:

• Contra qué API estás comparando. Una API de frontera y una API económica de peso abierto están separadas por aproximadamente dos órdenes de magnitud en precio. El punto de equilibrio frente a cada una es tremendamente distinto.
• Tu utilización de la GPU. El coste fijo solo compensa si la GPU está ocupada. El tiempo inactivo es dinero que gastaste para nada.
• El coste operativo oculto. Tus horas, el desgaste por actualizaciones de modelo, y las sorpresas de VRAM que no aparecen hasta que estás en producción.

Pon precio a cada una de esas cosas y la niebla se despeja. De eso trata el resto de este artículo.

Conclusión de la sección: el punto de equilibrio no es un solo número. Son tres números, uno por nivel de API, y elegir el nivel equivocado con el que comparar es donde la mayoría de las estimaciones de coste salen mal.

El equilibrio a tres bandas: API de frontera vs. de nivel medio vs. económica

Autoalojar un LLM de peso abierto en un GPU VPS gana a una API de frontera (clase GPT-5, Claude Sonnet 5 / Opus 4.8, Gemini Pro) a aproximadamente unos pocos millones de tokens al día, siempre que mantengas la GPU en una utilización saludable (digamos 60% o más). Frente a una API económica de peso abierto a alrededor de $0.14–$0.50 por millón de tokens, rara vez gana en coste en absoluto. Esa diferencia es toda la historia, y es por lo que un solo número de equilibrio no puede ser correcto.

Aquí está la forma que tiene a lo largo de los tres niveles. Trata estos umbrales como rangos orientativos, no como líneas duras. Vienen de estimaciones de la comunidad y precios de 2026, ambos de los cuales cambian rápido.

Precios de las páginas de precios de OpenAI, Anthropic, Google, DeepInfra, Together, y DeepSeek a fecha de July 2026. Cada uno de estos números tiene una vida útil medida en meses, así que consulta las páginas actuales antes de comprometerte.

Ahora el punto contrario, porque es el que cambia decisiones. Circula un argumento ruidoso y correcto de que las APIs económicas mataron el punto de equilibrio de autoalojar. Las APIs de peso abierto como DeepInfra y Together ahora sirven modelos Llama y Qwen a una fracción de los precios de frontera, y los propios precios de frontera han caído con fuerza desde 2025. Frente a esas tarifas económicas, el punto de equilibrio por token se dispara a los miles de millones de tokens al mes. Un solopreneur no está empujando miles de millones de tokens al mes. Así que si tu único objetivo es una factura más baja, el primer movimiento normalmente no es «alquilar una GPU», es «cambiar a una API económica de peso abierto y quedarte con cero operaciones».

El caso de coste de autoalojar sobrevive en dos lugares: comparando contra precios caros de frontera a un volumen genuinamente alto y sostenido, y las razones ajenas al coste (privacidad, latencia, control del fine-tuning) que se cubren más abajo. En todo lo demás, la API económica gana el argumento del dinero.

La fórmula del punto de equilibrio

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Ejemplo resuelto, a escala de solopreneur: digamos que un solo GPU VPS de gama alta cuesta unos $1,000/mes (rango de catálogo de 2026 para un nivel superior de una sola GPU), y estás en una API de frontera con una tarifa combinada de alrededor de $6 por millón de tokens (aproximadamente $0.000006 por token). Eso son ~$1,000 ÷ $0.000006 ≈ 167 millones de tokens/mes antes de que la GPU se amortice sobre el papel. Ahora rehazlo frente a una API económica de peso abierto a $0.40 por millón ($0.0000004/token): ~$1,000 ÷ $0.0000004 = 2.500 millones de tokens/mes. La misma GPU, el mismo coste fijo, y el punto de equilibrio se mueve por más de 10× dependiendo puramente de qué API pongas en el denominador. Esto es antes de la utilización, que empeora el número.

Conclusión de la sección: la API contra la que compares puede mover tu punto de equilibrio por 10× o más, así que «haz las cuentas» significa hacerlas contra la API concreta que de verdad reemplazarías.

Qué le hace la utilización al coste por token

Toma ese punto de equilibrio de frontera de ~167 millones de tokens y añade la variable que la fórmula da por supuesta calladamente: que tu GPU está ocupada todo el tiempo. No lo está. Una GPU alquilada factura lo mismo tanto si está saturada como inactiva, así que tu coste efectivo por token del GPU VPS LLM escala inversamente con la utilización. Corre al 10% de carga y cada token que sirves acarrea aproximadamente 10× el coste que tendría a plena carga, porque estás pagando por el 90% de capacidad que no usaste. Las estimaciones de la comunidad y los relatos de profesionales sitúan el suelo práctico en torno al 50–60% de utilización sostenida antes de que los números dejen de avergonzarte (cifras orientativas, no constantes de laboratorio).

Para una carga de trabajo en solitario e intermitente (tráfico que se dispara durante el día y se aplana por la noche), un 60% de utilización sostenida es difícil de alcanzar. Esa es la trampa. Esto es lo que le hace al coste por millón de tokens a lo largo de unos pocos puntos concretos, usando precios de GPU de catálogo de 2026 divididos por el rendimiento mensual aproximado en cada nivel de utilización:

Los céntimos por token absolutos dependen de tu modelo, la cuantización, y de cuántas peticiones concurrentes puedas empaquetar en la tarjeta, así que trata las columnas como algo que muestra la forma de la penalización más que una cotización. El punto es el multiplicador: baja de plena carga a un cuarto de carga y tu coste por token se cuadruplica aproximadamente. Eso suele ser lo que mata el caso de autoalojar en solitario, no el precio de etiqueta de la GPU.

Hay una escapatoria estructural, y es la razón por la que alquilar puede ganar a poseer para la demanda a picos: puedes detener una instancia alquilada cuando está inactiva. Posee el hardware y se deprecia y consume energía tanto si lo usas como si no. En alquileres por horas o bajo demanda, puedes detener o desmontar la instancia cuando el trabajo está hecho y evitar pagar por horas inactivas. En planes mensuales fijos, la factura sigue siendo fija para el periodo de facturación, así que la utilización sigue siendo el principal problema de coste. No arregla una carga de trabajo que es genuinamente de baja utilización todo el día, pero para una demanda que está ocupada a picos y muerta entre medias, la capacidad de apagar el contador es la única palanca que hace que el alquilar-vs-poseer se incline hacia el alquiler.

Conclusión de la sección: la utilización, no el precio mensual de la GPU, suele ser lo que decide si autoalojar sale a cuenta, y es la variable que los números populares de equilibrio dejan fuera por completo.

Qué modelo encaja en qué GPU: la realidad de la VRAM

El plan que se rompe primero es «ya ejecutaré un 70B en una 4090». No puedes. Un modelo de 70B con cuantización Q4_K_M necesita aproximadamente 40–46 GB de VRAM, y una RTX 4090 de 24 GB o una RTX 5090 de 32 GB simplemente no tiene el espacio. Fuérzalo en una tarjeta de 24 GB y bajas a cuantización Q2_K (alrededor de 21 GB) con pérdida de calidad visible, o el modelo se derrama a la RAM del sistema y la velocidad de generación se desploma. La VRAM es el muro duro que decide qué modelos están siquiera sobre la mesa para una GPU dada.

Esto es lo que encaja dónde. Las cifras de VRAM son aproximadas: se derivan de la aritmética estándar de bytes por parámetro (FP16 ≈ params × 2 con ~15% de overhead; Q4_K_M ≈ params × ~0.55 con overhead), así que trátalas como orientación de dimensionamiento, no como garantías.

Las cifras de VRAM están cotejadas contra las páginas oficiales de especificaciones de GPU de NVIDIA de cada tarjeta. El A100 da a un 70B cuantizado un margen más cómodo; la RTX 6000 Ada puede funcionar para montajes Q4 más ajustados, mientras que las tarjetas de consumo de 24 GB y 32 GB no tienen suficiente VRAM para un despliegue normal de 70B Q4. Si quieres el desglose completo de cómo los formatos GGUF, GPTQ, AWQ y EXL2 consumen memoria, esa es una madriguera que merece su propia lectura: GGUF, GPTQ, AWQ, EXL2: cómo usan la memoria realmente los formatos de cuantización de LLM.

El punto dulce de la comunidad para una sola tarjeta de 24 GB es un modelo de 24B a 32B (Mistral Small 3.1 o Qwen 3 32B a Q4). Ese es el tamaño que le da a un builder en solitario un modelo útil en el nivel de GPU más barato sin pelear con la VRAM todo el camino. Si estás sopesando qué tarjeta alquilar en primer lugar, nuestro benchmark H100 vs RTX 4090 para cargas de trabajo de IA compara los niveles en rendimiento.

Consejo pro: presupuesta para la KV cache, no solo para los pesos. La sorpresa más común del primer despliegue: dimensionas la GPU para los pesos del modelo, lo cargas, y encaja. Luego llegan las peticiones, la KV cache crece con la longitud del contexto y la concurrencia, y te quedas sin VRAM sirviendo a tus primeros usuarios. Cuando la VRAM se desborda y el modelo se derrama a la CPU, la velocidad de generación cae 10–100×. Deja margen por encima de las cifras de pesos de la tabla para la cache, especialmente si sirves contextos largos o varios usuarios a la vez.

Los costes ocultos que borran el ahorro ingenuo

La hoja de cálculo que dice que autoalojar es más barato casi siempre tiene una línea: el precio mensual de la GPU. La factura que pagas tiene más líneas. Está tu tiempo (cada hora que pasas parcheando, reiniciando un servidor de inferencia colgado, o persiguiendo un fallo de falta de memoria es una hora que no pasaste en el producto). Está el desgaste por actualizaciones de modelo: el modelo de peso abierto que desplegaste queda superado, y volver a hacer benchmarks y a desplegar es trabajo recurrente, no una configuración de una sola vez. Está la sorpresa de la VRAM y la KV cache de la última sección. Y está el desperdicio inactivo, las horas que la GPU está facturando mientras no corre nada.

Los profesionales que han contado esto sitúan el coste real en aproximadamente 1.3–2× el precio bruto de la GPU una vez que se pliega el tiempo operativo, y algunos van más alto, a 3–5×, en montajes más desordenados. Esos son multiplicadores orientativos de relatos de la comunidad, no cifras auditadas, pero la dirección es el punto. Como lo expresa un encuadre muy citado, una GPU inactiva no es un activo, es un pasivo facturado por hora. Para un builder en solitario, la forma correcta de ponerle precio a esto no es una línea de salario de MLOps, son tus propias horas, que son lo más escaso que tienes. Si autoalojar te ahorra $200 al mes sobre el papel pero te cuesta seis horas de operaciones que de otro modo gastarías enviando producto, eso no es obviamente una victoria.

Cuándo gana autoalojar de todos modos: privacidad, latencia y fine-tuning

El coste no es la única razón para ejecutar tu propio modelo, y para algunos builders ni siquiera es la principal. Por debajo del punto de equilibrio de coste, donde el dinero dice «quédate en la API», hay tres razones para autoalojar de todos modos. Soberanía de los datos: mantener los prompts y datos de tus usuarios fuera del pipeline de un proveedor de IA externo, lo cual importa para algunos productos al margen de lo que digan los números. Latencia predecible: sin cola de inquilinos compartidos, sin límites de tasa que no fijaste tú, sin ralentizaciones sorpresa durante el pico de tráfico de otro. Y control total: la libertad de hacer fine-tuning, cuantizar, cambiar modelos y fijar versiones sin esperar a un proveedor.

Hay una salvedad sobre el punto de la privacidad, y saltársela sería deshonesto. Un GPU VPS alquilado sigue corriendo sobre el hardware de otro en el datacenter de otro. Eso es una soberanía significativa frente al pipeline de entrenamiento y registro del proveedor de IA (tus prompts no fluyen por los sistemas de un proveedor de modelos), pero no es lo mismo que un equipo en las instalaciones que controlas físicamente. Si tu requisito es un aislamiento on-premises real, un VPS alquilado no te lleva ahí. Si tu requisito es «mantener nuestros datos fuera de las manos de un proveedor de modelos externo», sí lo hace. Sabe cuál de los dos necesitas.

Para cargas de trabajo que corren en entornos de red restrictivos, un modelo autoalojado sobre infraestructura que controlas también puede sortear dependencias de endpoints externos que pueden estar inaccesibles, una capacidad que importa con independencia de dónde lo despliegues.

Entonces, ¿deberías autoalojar? Una respuesta directa por situación

Todo lo anterior se ordena en una decisión corta. Tienes una factura, una idea aproximada de tu volumen mensual de tokens, y ahora los tres niveles de equilibrio, la penalización por utilización, y el multiplicador de coste oculto. Mapea tu situación a una de estas:

• Estás por debajo del equilibrio de frontera y el coste es tu única preocupación. Quédate en una API, y pon precio en serio a una API económica de peso abierto (DeepSeek, DeepInfra, Together) antes que a nada. Esa suele ser la ganancia en coste, no autoalojar. Cambiar de API es un cambio de configuración; autoalojar es un segundo trabajo.
• Tienes volumen alto y sostenido frente a precios de frontera y puedes mantener una GPU con más del 60% de utilización. Aquí es donde autoalojar compensa. Ejecuta la fórmula contra tu tarifa de frontera, confirma que cruzas el umbral con utilización sostenida (no de pico), y un GPU VPS alquilado empieza a ganar.
• Tienes un impulsor ajeno al coste: privacidad, latencia o control del fine-tuning. Autoaloja por debajo del punto de equilibrio deliberadamente, con los ojos abiertos a que estás pagando por el control. Solo no te digas que es más barato si no lo es.
• Estás en medio. Fíjate en el patrón híbrido en el que aterrizan la mayoría de los profesionales en 2026: un modelo pequeño autoalojado para tareas de alto volumen y simples, más una API de frontera para el razonamiento difícil al que tu modelo local llega en un 85–90% (benchmarks de la comunidad, no verificados en laboratorio, y el último tramo suele ser donde más necesitas la calidad).

Sobre la pregunta de «cómo consigo la GPU», la respuesta para un builder en solitario es casi siempre alquilar, no comprar. Poseer hardware de grado datacenter es una apuesta de capex que solo tiene sentido a una escala que aún no tienes. La inferencia serverless puede reducir el desperdicio inactivo al escalar a cero y facturar solo por el cómputo activo, pero a menudo lo cambia por una tarifa por GPU-hora más alta y latencia de arranque en frío. Un GPU VPS alquilado se sitúa en medio: sin capex, una factura mensual predecible, acceso root, y la capacidad de detener la instancia cuando está inactiva.

Si has ejecutado la fórmula, cruzado el punto de equilibrio, y quieres un servidor de inferencia dedicado, privado y con acceso root sin comprar una tarjeta, eso es exactamente para lo que sirve una máquina GPU alquilada. Los planes de GPU VPS de Cloudzy cubren la gama desde un modelo de 8B en una sola tarjeta hasta un 70B cuantizado, y la app de Ollama de un clic en el marketplace se despliega en aproximadamente un minuto con una REST API compatible con clientes de OpenAI, así que el cambio de una API de pago a tu propio servidor puede ser casi un cambio directo en tu código, sin coste por token después de la tarifa mensual fija. Consulta la página para el precio actual; las tarifas de GPU se mueven.

La única acción que merece la pena tomar antes de alquilar nada: ejecuta la fórmula del punto de equilibrio sobre tu propia factura. Lleva dos minutos y te dirá en cuál de las cuatro situaciones de arriba estás.

Preguntas frecuentes

¿Sale más barato autoalojar un LLM o usar una API?

Depende de qué API. Autoalojar un modelo de peso abierto en un GPU VPS puede ganar a una API de frontera (clase GPT-5, Claude Sonnet 5 / Opus 4.8) a volumen alto y sostenido con buena utilización de la GPU. Rara vez gana a una API económica de peso abierto (DeepSeek, DeepInfra, Together a aproximadamente $0.14–$0.50 por millón de tokens a fecha de July 2026) solo en coste: ese punto de equilibrio se dispara a miles de millones de tokens al mes, que la mayoría de los builders en solitario nunca alcanzan.

¿Qué GPU necesito para ejecutar un modelo de 70B?

Un modelo de 70B con cuantización Q4_K_M necesita aproximadamente 40–46 GB de VRAM solo para los pesos cuantizados. Un A100 de 80 GB es la opción de una sola GPU más segura porque deja sitio para la KV cache, el overhead en tiempo de ejecución, y prompts más largos. Una RTX 6000 Ada de 48 GB puede funcionar para montajes Q4 más ajustados, pero la longitud del contexto y la concurrencia hay que gestionarlas con cuidado.

¿Cómo afecta la utilización de la GPU al coste por token?

Una GPU alquilada cuesta lo mismo tanto si está inactiva como a plena carga, así que tu coste efectivo por token escala inversamente con la utilización. Al 10% de carga, cada token que sirves cuesta aproximadamente 10× lo que costaría a plena carga, porque estás pagando por la capacidad sin usar. El suelo práctico para que autoalojar tenga sentido está en torno al 50–60% de utilización sostenida.

¿Cuántos tokens al mes hacen falta antes de que autoalojar merezca la pena?

Frente a una API de frontera, aproximadamente 160–256 millones de tokens al mes con una utilización saludable es el umbral orientativo (a fecha de July 2026). Frente a una API económica de peso abierto son miles de millones al mes, en la práctica inalcanzable en solitario. El número exacto depende de tu coste de GPU y de tu tarifa combinada de API, así que ejecuta la fórmula: tokens de equilibrio ≈ coste mensual del GPU VPS ÷ tu precio de API por token, luego descuéntalo por la utilización sostenida.

¿Puedo ejecutar un LLM de peso abierto en un VPS?

Sí, en un GPU VPS dimensionado a la VRAM del modelo. Una herramienta como Ollama ejecuta modelos de peso abierto (Llama, Qwen, Mistral, y otros) con un despliegue de un clic y una REST API compatible con OpenAI, así que tu código existente que llama a la API puede apuntar a tu propio servidor con cambios mínimos. Ajusta el nivel de GPU a tu modelo: un 8B encaja cómodamente en una tarjeta de 24 GB, un 70B cuantizado necesita 48–80 GB.