En 2026, el autoalojamiento de un gran modelo de lenguaje ya no es una curiosidad de laboratorio. Se ha convertido en una opción madura, eficaz y económicamente defendible para una parte creciente de los proyectos que encuadramos. Los modelos abiertos como Mistral Large 2, Llama 3.3 70B, Qwen 2.5 72B o DeepSeek V3 alcanzan ya entre el 90 y el 95 % del rendimiento de GPT-4 Turbo o Claude 3.7 Sonnet en la mayoría de los casos estándar: extracción, clasificación, síntesis, generación asistida, RAG. Esta brecha de calidad, que era prohibitiva en 2023, se ha estrechado hasta el punto de que la pregunta ya no es «¿es lo bastante bueno?», sino «¿cuál es el arbitraje adecuado para nuestro negocio?».

Este artículo se dirige a CTO, CIO y lead engineers que evalúan seriamente la opción del LLM autoalojado. Detallamos las seis decisiones estructurantes: criterios de soberanía, elección del modelo, dimensionado de GPU, stack de serving, seguridad y observabilidad, FinOps. Nos apoyamos en lo que vemos concretamente en nuestros proyectos, sin ceder al discurso de marketing ambiente. Soberanía no significa «todo self-host a toda costa»: la cuestión es saber dónde colocar la frontera y con qué exigencia de ingeniería.

Por qué esta cuestión vuelve con fuerza en 2026

Tres fuerzas convergen. Primero, la regulación se endurece: RGPD para cualquier dato personal, HDS para el sector sanitario, NIS2 para los operadores esenciales, AI Act para los sistemas de riesgo, sin contar las exigencias contractuales específicas que las grandes cuentas imponen ya a sus proveedores. Muchas de estas cláusulas prohíben explícitamente la transferencia a una API de IA no europea, o exigen una trazabilidad completa imposible de garantizar en una API de terceros.

Después, el ecosistema open-weight ha recuperado su retraso. Mistral Large 2 (123B de parámetros), Llama 3.3 70B, Qwen 2.5 72B y DeepSeek V3 (671B en MoE, ~37B activos) son hoy modelos industriales. Combinados con servidores como vLLM o TensorRT-LLM y con hardware NVIDIA H100, A100 o L40S, o incluso AMD MI300X, entregan caudales reales de 30 a 80 tokens por segundo por solicitud, con un batching dinámico que permite absorber varios centenares de usuarios simultáneos en un único servidor correctamente dimensionado.

1. Definir los criterios de soberanía antes que todo lo demás

El error más frecuente consiste en elegir un modelo y luego revestir el proyecto con un discurso de soberanía. El enfoque riguroso es el inverso: cualificar primero la sensibilidad de los datos, las obligaciones regulatorias y los compromisos contractuales, y después desplegar las implicaciones técnicas. Un dato sanitario identificable impone un alojamiento HDS y bloquea toda API fuera de la UE. Un documento clasificado por un cliente de defensa impone una compartimentación de red total. Un secreto de negocio de I+D impone como mínimo un cifrado en tránsito y en reposo, e idealmente una infraestructura cuyo operador del LLM no tenga las llaves.

En nuestras auditorías, separamos sistemáticamente tres niveles: datos públicos o banales (API propietaria aceptable), datos confidenciales internos (API europea con DPA estricto o self-host cloud soberano), datos sensibles o regulados (self-host obligatorio, idealmente on-prem o cloud SecNumCloud / HDS). Esta rejilla permite objetivar la necesidad y evitar el «todo o nada» que lastra a la mayoría de los comités de IA.

2. Elegir el modelo open-weight adecuado

La elección del modelo depende de cuatro criterios: calidad en tus casos, calidad específica en tu idioma, tamaño (y por tanto coste de infraestructura) y licencia. Mistral Large 2 sigue siendo nuestra referencia para los casos francófonos exigentes: calidad de razonamiento, instruction-following, generación natural. Llama 3.3 70B ofrece una excelente relación calidad/tamaño, pero su licencia (Acceptable Use Policy) sigue siendo restrictiva para ciertos usos y excluye a las grandes plataformas. Qwen 2.5 72B es sorprendentemente fuerte en código y matemáticas. DeepSeek V3, en MoE, ofrece una calidad cercana a GPT-4 con un coste de serving paradójicamente moderado gracias a sus 37B de parámetros activos.

Nuestro método: nunca creemos en los rankings genéricos tipo MMLU o Chatbot Arena. Construimos un benchmark interno de 50 a 200 prompts representativos del negocio del cliente, y medimos faithfulness, formato, tono, latencia y coste en cada modelo candidato. Es la única forma de decidir honestamente.

  • Mistral Large 2 (123B): excelente en idiomas latinos, licencia MRL clara, despliegue 2-4×H100
  • Llama 3.3 70B: mejor relación calidad/tamaño, atención a la AUP
  • Qwen 2.5 72B: fuerte en código y razonamiento, licencia Apache 2.0 parcial
  • DeepSeek V3 (671B MoE): calidad top-tier, coste de serving razonable a pesar del tamaño

3. Dimensionar la infraestructura GPU

El dimensionado no tiene nada de intuitivo. Tres variables cuentan: la VRAM disponible, la latencia objetivo (time to first token y tokens/segundo por usuario) y la concurrencia (usuarios simultáneos). Para un Llama 3.3 70B cuantizado en INT4, una sola H100 80GB basta en POC pero satura rápido por encima de 5-10 usuarios simultáneos. En FP8 hacen falta dos H100. Para Mistral Large 2 en producción, partimos típicamente de 2 a 4×H100 o un nodo 8×L40S según el perfil de carga.

En infraestructura, dos opciones dominan: compra directa (1×H100 80GB en torno a 30 a 40 k€ HT, amortizable en 24-36 meses) o alquiler de cloud GPU en Scaleway, OVHcloud, Lambda Labs o RunPod, entre 2,5 y 4 € la hora según el proveedor y el compromiso. El cloud GPU europeo sigue siendo pertinente cuando se busca conciliar soberanía y flexibilidad, a condición de verificar la jurisdicción real del proveedor y su estatus SecNumCloud llegado el caso.

4. Elegir el stack de serving

Cuatro opciones estructuran el mercado. vLLM se ha convertido en la referencia open-source: PagedAttention, continuous batching, soporte OpenAI-compatible, comunidad masiva. Es nuestra elección por defecto. TGI (text-generation-inference de Hugging Face) sigue siendo muy sólido, particularmente integrado en el ecosistema HF, ligeramente menos eficaz que vLLM en caudal pero muy maduro en producción. TensorRT-LLM de NVIDIA entrega el mejor rendimiento bruto en hardware NVIDIA, al precio de una complejidad de compilación y mantenimiento mucho mayor — pertinente a gran escala únicamente. NVIDIA NIM propone un enfoque gestionado on-prem, con microservicios contenedorizados listos para usar: interesante cuando el equipo interno no tiene un perfil MLOps senior, menos flexible y más caro a la larga.

Para proyectos hasta unos cientos de usuarios concurrentes, vLLM detrás de un reverse proxy (Traefik, NGINX) con un cliente OpenAI-compatible del lado aplicativo es la combinación más simple, eficiente y mantenible. Es la que desplegamos en la mayoría de nuestros proyectos de autoalojamiento.

5. Securizar y observar el LLM en producción

Un LLM autoalojado nunca es una simple API que exponer. Es un componente crítico que potencialmente manipula datos sensibles y constituye una nueva superficie de ataque. Imponemos sistemáticamente cuatro líneas de defensa: aislamiento de red estricto (VPC privada, sin acceso directo a internet), autenticación aplicativa fuerte (JWT firmados, rotación), registro completo de prompts y respuestas con retención controlada, y barreras de negocio (filtros de entrada, validación de salida, detección de prompt injection).

La observabilidad técnica cuenta tanto: monitorización GPU (uso, memoria, temperatura), métricas de serving (TTFT, tokens/seg, tamaño de cola), trazabilidad aplicativa (Langfuse, OpenLLMetry o solución propia). Sin esta telemetría no sabrás ni cuándo se satura tu infraestructura, ni cuándo un modelo deriva, ni de dónde viene una regresión de calidad.

6. FinOps: modelizar el TCO con honestidad

La cuestión financiera no se resume al precio del GPU. El TCO real de un LLM autoalojado integra la amortización del hardware o el alquiler, la electricidad y la refrigeración si es on-prem, las competencias MLOps internas o externas, el mantenimiento de los modelos (actualizaciones cada 3-6 meses en open-weight), la observabilidad, la seguridad y las fases de upgrade. En nuestros proyectos siempre construimos un comparativo a 24 meses entre tres escenarios: API propietaria pura, híbrido (API para el pico, self-host para el recurrente), full self-host.

A título indicativo: Mistral Large 2 sobre 1×H100 80GB en serving vLLM optimizado entrega unos 50 tokens/segundo por solicitud y de 1.500 a 2.500 tokens/segundo en caudal agregado según el batching. En 30 días completos, esto representa un volumen teórico de varios miles de millones de tokens, a comparar con una factura API equivalente que se cuenta en decenas de miles de euros al mes en esos mismos volúmenes.

Las trampas que hacen fracasar los proyectos de autoalojamiento

Cuatro trampas se repiten en nuestras auditorías de rescate. Primera, infravalorar la observabilidad: sin telemetría, el equipo pilota a ciegas y cualquier caída se convierte en un siniestro. Segunda, descuidar la seguridad de red: demasiados POC llegan a producción con un endpoint vLLM expuesto en claro. Tercera, olvidar el coste recurrente de actualización de los modelos: un LLM open-weight de 2026 será obsoleto en 2027, hay que prever la cadencia de upgrade desde el encuadre. Cuarta, no formar al equipo: un LLM self-host no se pilota como un microservicio clásico, las competencias MLOps y ML engineering son indispensables.

A estas trampas técnicas se añade una trampa estratégica: confundir soberanía con rendimiento. Autoalojarse no convierte un mal caso de uso en bueno. Si la necesidad de negocio está mal encuadrada, si el RAG está descuidado, si la evaluación brilla por su ausencia, el proyecto fracasará con o sin soberanía. El autoalojamiento es un medio, no un fin.

¿Y ahora qué?

Si evalúas seriamente el autoalojamiento de un LLM, el primer paso es cualificar honestamente tu necesidad de soberanía, tu volumen objetivo y la criticidad del caso de uso. Es exactamente lo que hacemos en nuestros encuadres en DevHighWay: decidir entre API, híbrido y self-host con cifras, no con eslóganes.

  • Ponte en contacto para un encuadre de proyecto de soberanía (taller de 2 días, entregable decisional)
  • Nuestra auditoría también cubre la dimensión de visibilidad de tu plataforma de IA
  • Consulta nuestras tarifas para los paquetes que incluyen la gestión del LLM

El autoalojamiento de un LLM es hoy una opción creíble, a veces la única, para las organizaciones que deben conservar el control sobre sus datos. Pero es un proyecto de ingeniería serio que se trata como tal: objetivos claros, modelo benchmarkeado, infraestructura dimensionada, seguridad y observabilidad afinadas, FinOps documentado. Es exactamente la postura que adoptamos en nuestros proyectos, y la que separa de forma duradera los despliegues sostenibles de los POC que mueren al primer incidente de producción.