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. El 2 de septiembre de 2026, Scaleway anunciaba una H100 PCIe desde 2,86 € por GPU-hora y OVHcloud una H100 individual a 3,10 € por hora. A 730 horas son unos 2.088 € y 2.263 € al mes, antes de impuestos, almacenamiento, red, redundancia y operación. Revisa las condiciones vigentes antes de calcular.

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, el self-hosting puede alcanzar antes el equilibrio, pero solo si el modelo open-weight ofrece calidad, latencia y disponibilidad equivalentes para la tarea.
• Frente a un proveedor de API open-weight barato, el equilibrio queda más lejos porque compites con infraestructura ya optimizada y economías de escala.

Calcula tu equilibrio dividiendo el coste mensual total de GPU, redundancia, almacenamiento, red, ingeniería y evaluaciones entre el coste ponderado de la API por token o tarea. El tráfico a ráfagas empeora el self-hosting porque pagas la GPU inactiva. Una comparación válida exige calidad y niveles de servicio equivalentes. 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?".

El RGPD no exige de forma general que todo tratamiento ocurra solo en la UE. Su capítulo V regula las transferencias a terceros países, y también importan el encargo de tratamiento, la limitación de finalidad, la seguridad y una arquitectura documentada. Alojar en infraestructura propia de la UE puede reducir los subprocesadores externos, pero no elimina automáticamente a terceros: los proveedores de nube, red, soporte y observabilidad pueden seguir participando. Serving, logging, control de acceso y rollback pasan además a ser tu responsabilidad. Profundizamos 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. Las obligaciones para modelos de propósito general ya aplican, la transparencia del artículo 50 desde el 2 de agosto de 2026, el alto riesgo independiente desde el 2 de diciembre de 2027 y el integrado en productos desde el 2 de agosto de 2028. La conclusión práctica para un equipo de la UE no es solo una fecha. 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. Confirma clasificación y rol contra 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.

Esta sección es la propietaria de la elección general del stack. Para la cuestión operativa concreta, nuestro análisis de Netflix con vLLM y Triton cubre decoding restringido, versiones fijadas, rollouts seguros, caché de modelos y métricas unificadas.

• Motor de inferencia: vLLM. El continuous batching, PagedAttention y paralelismo de vLLM pueden mejorar mucho la utilización y el throughput agregado. La mejora depende del modelo, hardware, longitud de prompts, batch y nivel de servicio, así que mide tu carga. SGLang y TensorRT-LLM son alternativas. Nuestro benchmark de 14x para una caché KV compartida es un resultado específico del sistema, no un multiplicador universal de vLLM.
• Open weights cuantizados. La cuantización puede reducir memoria y cómputo, pero su efecto en calidad y rendimiento depende del modelo, formato, hardware, kernels y tarea. FP8, AWQ y GPTQ son candidatos, no una clasificación universal. Mide memoria, latencia, throughput y calidad con tus propias evaluaciones.
• 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. Si la memoria de móvil o portátil es el límite duro, nuestra review de Bonsai 27B separa el titular de 3,9 GB de la memoria real y la calidad por tarea. Los pesos del modelo son solo parte de la factura de memoria: si usas recuperación, el índice de embeddings tiene su propia huella, y nuestra guía para reducir 16x la memoria de vectores del RAG muestra cómo la cuantización sin datos la encoge.

¿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? Calcula el umbral con el coste mensual total y tu mezcla real de uso de API. El volumen a ráfagas o bajo suele favorecer 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.