La IA generativa soberana

Por qué el RUN de un LLM autoalojado es estructuralmente insostenible

Análisis dirigido a las direcciones de sistemas de información

Es tentador, para un director de sistemas de información preocupado por el aislamiento de sus sistemas críticos, plantearse alojar en propio el LLM o los LLM útiles para sus desarrolladores o para la explotación de su empresa. Aquí consideraremos el uso de DeepSeek V4 Pro (MoE, Think, 1,6 T de parámetros, 49 B activados, 1 M de contexto). Las promesas son seductoras: control total de los datos, independencia respecto a los proveedores de API, personalización ilimitada. Pero tras el atractivo del bare-metal se esconde una realidad operativa que pocas organizaciones están dispuestas a afrontar. Lo analizamos.

El verdadero coste del RUN

Un modelo de 1,6 billones de parámetros exige unos 20 GPU NVIDIA H100 en cuantización INT4 para funcionar. En alquiler cloud, el precio de entrada ronda los 30 K€ mensuales, es decir, 360 K€ anuales solo por la potencia de cálculo. Pero esa cifra es un espejismo.

Hay que añadir el coste humano. El despliegue y la supervisión de un clúster de inferencia de esta envergadura requieren como mínimo 1,5 a 2 ETP de ingenieros MLOps especializados, es decir, 150 a 200 K€ anuales con cargas sociales en Francia. La gestión de las actualizaciones de modelo, la optimización del serving (vLLM, SGLang, TensorRT-LLM), el monitoreo de la latencia, la gestión del KV-cache y las reconfiguraciones durante los picos de carga no se improvisan.

Añadamos la capa de red, la seguridad perimetral, las licencias de software, el almacenamiento NVMe para los checkpoints y el backup. El TCO real se sitúa entre 550 y 650 K€ al año, para una sola instancia y sin redundancia.

Un SPOF arquitectónico por diseño

Este es el punto más crítico: el modelo se distribuye sobre 20 GPU en tensor parallelism. Si falla una sola GPU, todo el servicio se cae. No existe un modo degradado. No hay failover parcial. Un clúster de 20 GPU ofrece, mecánicamente, 20 veces más superficie de fallo que un servidor clásico.

Para alcanzar un SLA del 99,9 % estándar mínimo para un servicio de producción enterprise, hay que duplicar la infraestructura: un segundo clúster en standby caliente, es decir, 60 K€/mes de alquiler de GPU y un TCO anual que supera el millón de euros. En ese punto, la pregunta ya no es técnica sino estratégica: ¿el servicio prestado justifica semejante inversión?

La obsolescencia programada como frontera

El ritmo de iteración de los modelos fundacionales se acelera de forma exponencial. DeepSeek V3 salió a principios de 2025, V4 unos meses después. Cada nueva generación deja a la anterior significativamente menos capaz. Un director de sistemas que se compromete a 3 años de alquiler de GPU para un modelo dado invierte en un activo cuyo valor útil se reduce a la mitad cada 6 a 12 meses.

En caso de comprar hardware (opción bare-metal en propio, unos 300 a 400 K€ por 8 H100), el riesgo de obsolescencia se convierte en trampa contable: una inmovilización a 3 o 5 años de un material cuya pertinencia tecnológica probablemente no supere los 18 meses.

Racionalismo económico frente a instinto de control

Ante estas constataciones, el uso de APIs gestionadas, ya sean de DeepSeek, OpenAI, Anthropic o de actores europeos emergentes, presenta un perfil radicalmente distinto.

En términos de volumen, 30 K€ mensuales de API DeepSeek representan alrededor de 8 a 10 millones de peticiones al mes, es decir, 5 a 10 veces el volumen alcanzable en self-hosted. La elasticidad es nativa: sin provisioning, sin sobredimensionamiento preventivo, sin GPU desaprovechadas a las 3 de la mañana.

En términos de SLA, los grandes proveedores de API garantizan uptimes del 99,9 % al 99,95 % con failover automático, balanceo de carga mundial y soporte 24/7. Un nivel de resiliencia que ninguna organización puede reproducir internamente con un presupuesto equivalente.

En términos de mantenimiento, el coste marginal es nulo: sin parcheo, sin migración de modelo, sin gestión de versiones CUDA. Cuando salga DeepSeek V5, el paso se hará cambiando un parámetro en una llamada a la API.

Cómo mitigar los riesgos del modelo por API

Seamos lúcidos: el modelo por API no está exento de riesgos.

La soberanía de los datos es la preocupación primera. Los prompts y las respuestas transitan por servidores de terceros, potencialmente fuera de la jurisdicción europea. Para los datos sensibles (salud, defensa, datos personales en el sentido del RGPD), es un obstáculo real. Sin embargo, existe la solución: algunos proveedores ofrecen despliegues dedicados en región UE (Scaleway AI, Azure OpenAI en Francia, OVHcloud AI Endpoints), y el cifrado de extremo a extremo combinado con cláusulas contractuales (DPA, SCC) reduce considerablemente la exposición jurídica.

La dependencia del proveedor (vendor lock-in) es el segundo riesgo. Pero el ecosistema actual es estructuralmente competitivo: las APIs son ampliamente compatibles entre proveedores (el formato OpenAI se ha convertido en estándar de facto), y la migración de un proveedor a otro se mide en horas, no en meses. El lock-in de una infraestructura GPU autogestionada es, paradójicamente, mucho más restrictivo.

La variabilidad tarifaria es el tercer riesgo. Los precios de las APIs pueden evolucionar. Pero no han hecho más que bajar desde 2023, de forma espectacular (divisiones por 10 a 100 según los modelos). La tendencia profunda del mercado juega a favor del consumidor de API, no del operador de infraestructura.

Arbitraje: la rejilla de decisión del DSI

El autoalojamiento de un LLM de clase trillón solo es racional para un número reducido de organizaciones: aquellas que combinan un imperativo reglamentario estricto de localización de datos, un volumen de inferencia masivo y constante que justifique la amortización, y un equipo MLOps maduro ya en plantilla.

Para todas las demás (es decir, la inmensa mayoría de las empresas), el modelo por API sigue siendo, en 2026, la opción más sostenible, más resiliente y más racional económicamente. El papel del DSI no es poseer la infraestructura de la IA, sino garantizar que la IA sirva a la estrategia de la empresa con la mejor relación valor/riesgo. A día de hoy, esa relación se inclina resueltamente del lado de la API.