Alojar LLMs en la UE: Cuándo Salen a Cuenta los Open Weights

Sobre el papel, alojar tú mismo un LLM open-weight parece una victoria fácil. Alquila una GPU por unos dólares la hora, ejecuta un modelo gratuito, deja de pagar por token. La factura se aplana y el stack es tuyo. Ese es el pitch, y es verdad a medias. Lo que omite decide si ahorras o pierdes dinero en silencio: la GPU es la parte barata. La parte cara es el ingeniero que mantiene vivo el servidor de inferencia, el harness de evaluación que prueba que un modelo cuantizado sigue respondiendo bien, y la cadencia de actualización que no se detiene cuando dos meses después sale un modelo abierto mejor.

Es una perspectiva de ingeniería y de proceso, no un pitch de proveedor. Las cifras de abajo son orientativas, sacadas de tendencias públicas de 2026, y deberías contrastarlas con presupuestos reales antes de comprometerte, porque tanto los precios de GPU como los de tokens se mueven mes a mes. Montamos IA interna sobre la infraestructura del cliente dentro de nuestro trabajo de AI Enablement, así que estos trade-offs son los que sopesamos de verdad con clientes, no un modelo teórico. Este artículo amplía nuestro manual de costes de tokens, que solo roza el self-hosting, profundizando en la pregunta que lo decide todo: ¿cuándo gana la inferencia interna a una API alojada?

¿Cuánto cuesta de verdad alojar un LLM, más allá de la GPU?

La partida de la GPU es la que todos citan, y hoy es realmente barata. Una NVIDIA H100 se alquila por unos $2 a $4 la hora en nubes especializadas de la UE, los hyperscalers cobran dos o tres veces más y los proveedores soberanos de la UE rondan los $2 (orientativo, contrasta antes de comprometerte). Ten una H100 reservada funcionando todo el día y estás ante unos $1.500 a $3.000 al mes solo de hardware.

Esa cifra es real, y también es la parte más pequeña del total. Los costes que deciden las cuentas son los que el spreadsheet se salta:

• Tiempo de ingeniería. Alguien tiene que levantar el servidor de inferencia, ajustar los tamaños de batch, gestionar drivers de GPU y versiones de CUDA, manejar la carga del modelo y el rollback, y mantenerlo todo en marcha. No es un setup único. Es operación continua, y en la UE un ingeniero de ML-ops competente cuesta al mes mucho más que la GPU.
• Redundancia. Una sola GPU es un punto único de fallo. Producción suele significar al menos dos más un plan de failover, lo que casi duplica la partida de hardware y añade trabajo de balanceo de carga.
• Evaluación y aseguramiento de calidad. Un modelo self-hosted es tu responsabilidad cuando empeora. Necesitas un harness de evaluación que pruebe que el modelo mantiene la calidad tras cada decisión de cuantización y cada salto de versión. Sin él vuelas a ciegas.
• Cadencia de actualización. Los open weights se mueven rápido. Un modelo competitivo hoy es de gama media en un trimestre. Mantenerse al día es trabajo de ingeniería recurrente, no una instalación que se olvida.

Súmalo y el encuadre honesto es el mismo que en nuestro trabajo de costes de tokens: el punto de equilibrio lo determina el tiempo de ingeniería, no el precio del rack de GPU. El modelo es barato de ejecutar. La disciplina que lo rodea, no.

¿Dónde está el punto de equilibrio frente a una API alojada?

No existe un único número de equilibrio, porque depende por completo de qué API estás reemplazando. La horquilla es lo bastante amplia como para que equivocarse aquí sea el error de self-hosting más común.

• Frente a una API frontier cara (gama alta de Claude, GPT o Gemini), el self-hosting en una GPU reservada puede alcanzar el equilibrio con unos pocos millones de tokens al día, a veces citado en torno a 2 a 5 millones. Los tokens de salida frontier son caros, así que el listón a superar es bajo.
• Frente a un proveedor de API open-weight barato (Together, Fireworks, DeepInfra y similares), el punto de equilibrio se dispara, citado a menudo en torno a 50 millones de tokens al día o más. Esos proveedores ya operan infraestructura optimizada a escala con márgenes finos, así que compites con su economía de escala, no con su precio de lista.

La lectura práctica para la mayoría de equipos: si tu alternativa es un endpoint open-weight alojado y barato, lo alojado sigue siendo más barato hasta que sostienes un volumen serio y constante. El tráfico a ráfagas empeora el self-hosting, porque pagas la GPU esté ocupada o inactiva, mientras que una API solo cobra por lo que usas. El equilibrio asume una GPU que puedas mantener cargada de forma significativa. Trata las cifras de arriba como orientativas e introduce tu propio volumen de tokens, precio de GPU y coste de ingeniería antes de decidir. Cubrimos la curva de costes más amplia en qué cambian los tokens baratos en tu arquitectura de IA.

"La mayoría de equipos se autoalojan demasiado pronto. Ponen precio a la GPU, no al ingeniero que tiene que mantenerla viva, y unos meses después la API alojada habría salido más barata y con menos trabajo."

¿Cuándo obliga la residencia de datos a alojar, cueste lo que cueste?

El coste es solo un eje. El otro es la gobernanza, y para algunas cargas de la UE anula las cuentas por completo. Si procesas datos personales o regulados y no puedes enviarlos a un endpoint fuera de la UE, la comparación de costes queda sin sentido. La pregunta deja de ser "¿es el self-hosting más barato?" y pasa a ser "¿cuál es la opción conforme más barata?".

Bajo el RGPD lo que importa es dónde se ejecuta la inferencia y dónde acaban los datos, no solo dónde se almacenan en reposo. Un acuerdo de tratamiento de datos firmado, residencia de datos en la UE, limitación de finalidad y una arquitectura documentada que muestre exactamente dónde se procesan los datos personales son los pilares de un setup conforme. Alojar open weights en tu propia infraestructura en la UE te da la menor exposición a subprocesadores externos, porque ningún tercero toca los datos en el momento de la inferencia. También conlleva la mayor carga operativa, ya que el serving, el logging, el control de acceso y el rollback pasan a ser tu responsabilidad. Profundizamos en las opciones de residencia en residencia de datos en la UE para apps de IA.

Encima hay una capa regulatoria. La Ley de IA de la UE entra en vigor por fases, y el calendario es provisional y aún en movimiento, así que trata cualquier fecha concreta como sujeta a cambios. A mediados de 2026, las obligaciones para modelos de IA de propósito general ya están en aplicación, las obligaciones más amplias de alto riesgo se han retrasado en el marco de un acuerdo político de mayo de 2026, y las competencias de ejecución están previstas para ir escalando a lo largo de 2026 y después. La conclusión práctica para un equipo de la UE no es una fecha. Es que controlar dónde se ejecuta tu modelo se está convirtiendo en un activo de gobernanza, no solo en una partida de coste, y el self-hosting es una forma de mantener ese control en tus propias manos. Confirma las obligaciones vigentes contra las fuentes oficiales antes de basar una afirmación de cumplimiento en ellas.

¿Cuál es el stack de producción si te autoalojas?

Si el volumen o el cumplimiento lo han decidido por ti, el stack de producción de 2026 está bien asentado, y no es lo mismo con lo que prototipaste en tu portátil. Un runner local de un solo flujo está bien para experimentos y mal para producción, porque deja la mayor parte de la GPU inactiva.

• Motor de inferencia: vLLM. El continuous batching y PagedAttention de vLLM permiten que una sola GPU sirva muchas peticiones concurrentes con un throughput agregado muy superior al de un setup ingenuo de un solo flujo. Los benchmarks públicos de 2026 lo sitúan en torno a ocho o nueve veces los tokens agregados de un runner simple en la misma H100 con la misma cuantización. El throughput, no la velocidad de una sola petición, es lo que hace funcionar la economía de la GPU, porque es lo que la mantiene cargada. SGLang y TensorRT-LLM son alternativas creíbles de la misma clase.
• Open weights cuantizados. Casi siempre ejecutas un modelo cuantizado, no a precisión completa, para meter un modelo útil en una GPU y servir más concurrencia. En hardware clase H100, FP8 se mantiene cerca de la calidad a precisión completa con aproximadamente la mitad de memoria. Cuando necesitas bajar más, AWQ de 4 bits suele ser el más fuerte de los formatos de 4 bits en tareas reales (las comparaciones públicas lo sitúan en retención de calidad en los 90 altos), con GPTQ justo detrás. El matiz: la cuantización de 4 bits puede degradarse de forma notable en razonamiento y matemáticas difíciles, manteniéndose bien en resumen, clasificación y extracción. Por eso la evaluación de abajo no es opcional.
• El modelo en sí. Llama, Qwen, DeepSeek y open weights clase Mistral son los candidatos habituales. Elegir entre ellos es una decisión propia, y la trabajamos en nuestra comparativa de modelos open-weight.

¿Cómo sabes que el camino más barato mantuvo la calidad?

Esta es la parte que los equipos se saltan y luego lamentan. Cada elección en un stack self-hosted, el modelo, la cuantización, los ajustes de batch, puede bajar la calidad en silencio, y un camino más barato que responde peor sin avisar es el resultado más caro de todos. La única defensa honesta es un harness de evaluación que puntúe tus tareas reales, no un benchmark público.

Aquí somos deliberadamente humildes. Construir y mantener buenas evaluaciones es más difícil que levantar el servidor de inferencia, y la mayor parte del coste de ingeniería continuo del self-hosting vive aquí, no en la GPU. Necesitas un conjunto de tareas representativo, un método de puntuación en el que confíes y una verja que se ejecute antes de cada cambio de modelo o cuantización. Sin ella no puedes saber si tu cambio a FP8 te costó dos puntos de precisión en los casos que importan. Es la misma disciplina que aplicamos en proyectos de IA en producción como Twinsoft AI: la elección del modelo solo es segura sobre una evaluación que pruebe que mantuvo el listón.

Entonces, ¿deberías autoalojarte? Una checklist de decisión.

Recorre estas preguntas en orden. Si la respuesta honesta a las dos primeras es no, opta por defecto por una API alojada y retoma el tema más adelante.

1. ¿Te obliga la residencia de datos? Si no puedes enviar legalmente los datos a un endpoint fuera de la UE y ninguna API alojada en la UE encaja, el self-hosting puede ser la opción conforme más barata, al margen de las cuentas de tokens. Esto solo puede decidirlo.
2. ¿Es tu volumen alto y constante? Frente a una API open-weight barata, normalmente necesitas sostener decenas de millones de tokens al día en una GPU que puedas mantener cargada antes de que gane el self-hosting. El volumen a ráfagas o bajo favorece a la API.
3. ¿Tienes capacidad de ops? El self-hosting es trabajo de ingeniería recurrente: drivers, redundancia, actualizaciones, monitorización. Si tu equipo no puede asumirlo sin dejar de lado el trabajo de producto, los ahorros de GPU se evaporan.
4. ¿Puedes probar la calidad con evaluaciones? Si no puedes medir si un modelo open cuantizado mantiene tu listón de calidad, no estás listo para depender de él en producción.
5. ¿Has puesto precio al cuadro completo? GPU más redundancia más tiempo de ingeniería más mantenimiento de evaluaciones, frente al coste todo incluido de la API. Compara totales, no la partida de GPU contra la de tokens.

Para la mayoría de productos en fase temprana y media, la respuesta sigue siendo: quédate en una API alojada, y elige una con residencia en la UE si la residencia importa. Autoalójate cuando el volumen o el cumplimiento fuercen la pregunta, no antes. Si quieres ayuda para hacer esa comparación con tus propios números e infraestructura, para eso está exactamente nuestro trabajo de AI Enablement.