Hay dos conversaciones que aparecen casi siempre en cuanto una empresa pasa del piloto de IA a algo serio. La primera: "¿podemos tener el modelo en nuestros servidores para que los datos no salgan de aquí?". La segunda, muchas veces en la misma reunión: "es que además tenemos medio sistema en un servidor físico de 2016 y deberíamos irnos a la nube".
Son dos preguntas distintas que conviene responder juntas, porque la decisión sobre dónde vive tu inteligencia artificial no se puede tomar al margen de dónde vive el resto de tu infraestructura.
En este artículo comparamos la infraestructura on-premise para LLM con las alternativas en nube, con requisitos técnicos y costes concretos, y explicamos cómo se plantea una migración a la nube en una empresa mediana o una pyme.
Qué significa realmente "LLM on-premise"
Ejecutar un modelo de lenguaje on-premise significa que el modelo (sus pesos) y el proceso de inferencia se ejecutan en hardware que tú controlas: un servidor en tu CPD, un rack alojado en un centro de datos o un servidor dedicado alquilado. No hay llamadas a la API de un tercero: el texto de tus usuarios nunca sale de tu perímetro.
Esto solo es posible con modelos de pesos abiertos (familias como Llama, Mistral, Qwen, Gemma o DeepSeek, entre otras). Los modelos comerciales cerrados de las grandes plataformas no se pueden descargar y ejecutar en tu servidor; para esos, la opción "privada" pasa por instancias dedicadas dentro de la nube del proveedor, que es otra cosa.
La distinción importa porque marca el techo de calidad. Los modelos abiertos han recortado muchísima distancia y para tareas de extracción, clasificación, resumen o consulta documental interna rinden de sobra. Para razonamiento complejo de largo recorrido, la frontera todavía la marcan los modelos cerrados.
¿Qué hardware hace falta para ejecutar un LLM on-premise?
La variable que manda es la memoria de la GPU. Como regla orientativa, un modelo cuantizado a 4 bits necesita aproximadamente la mitad de gigabytes de VRAM que miles de millones de parámetros tiene, más un margen para el contexto y para atender varias peticiones a la vez. Con eso, un modelo pequeño de unos 7.000 u 8.000 millones de parámetros cabe con holgura en una GPU profesional de 24 GB; uno de gama media en torno a 30.000 millones necesita entre 24 y 48 GB; y uno grande de 70.000 millones exige 48 GB largos o dos tarjetas. A eso hay que sumar CPU y RAM suficientes, almacenamiento NVMe rápido, y algo que se olvida siempre: consumo eléctrico, refrigeración y espacio en rack. Una máquina de inferencia seria no es un PC potente debajo de una mesa. Y no basta con comprarla: alguien tiene que parchearla, monitorizarla y responder a las tres de la mañana cuando deje de responder.
Comparativa honesta: on-premise, nube y modelo híbrido
On-premise tiene sentido cuando:
- Tratas datos especialmente sensibles (sanitarios, judiciales, defensa, secreto industrial) y tu política interna o tu sector lo exige.
- El volumen de peticiones es alto y sostenido. La economía cambia por completo cuando pasas de miles a millones de peticiones al mes: el coste fijo del hardware se amortiza frente a un coste variable por token que no para de sumar.
- Necesitas latencia muy baja y previsible, o funcionamiento sin conexión a internet (planta de producción, buque, instalación aislada).
- Ya tienes CPD y un equipo de sistemas que sabe operarlo.
La nube tiene sentido cuando:
- El volumen es variable o todavía no lo conoces, que es la situación de casi cualquier empresa que empieza.
- Quieres acceso al mejor modelo disponible en cada momento sin renovar hardware.
- No tienes equipo de sistemas para operar GPUs, y no quieres tenerlo.
- Necesitas arrancar en semanas, no en meses.
El modelo híbrido, que es el que más veces acaba siendo la respuesta correcta: los datos sensibles se procesan con un modelo abierto alojado en infraestructura propia o en un servidor dedicado europeo, y las tareas que exigen máxima capacidad de razonamiento se envían a una API comercial, previa anonimización o filtrado de lo que se envía. Se conserva el control donde importa y se evita pagar hardware para tareas que no lo necesitan.
Una advertencia sobre costes: la comparación honesta no es "cuota mensual de API" frente a "precio del servidor". Es cuota de API frente a hardware amortizado más electricidad más mantenimiento más horas de sistemas más el coste de oportunidad de tener capital inmovilizado en tarjetas gráficas que se deprecian rápido. Muchas empresas que hacen esa cuenta completa descubren que su volumen actual no justifica el on-premise, aunque su instinto dijera lo contrario.
¿Es más seguro tener el LLM en tus propios servidores?
No automáticamente. On-premise elimina un riesgo concreto —que un tercero procese tus datos— pero traslada a tu equipo toda la responsabilidad de seguridad: parcheo del sistema, control de accesos, cifrado en reposo y en tránsito, segmentación de red, copias de seguridad, registro y auditoría. Un servidor propio mal mantenido es bastante menos seguro que un proveedor cloud europeo con certificaciones y un equipo dedicado a esto. La pregunta correcta no es "¿dónde están los datos?" sino "¿quién puede acceder a ellos, con qué credenciales, y quién lo está registrando?". Para muchas empresas, la combinación de un proveedor con procesamiento en la Unión Europea, contrato de encargado de tratamiento firmado y compromiso de no usar los datos para entrenamiento cubre sus requisitos de cumplimiento sin necesidad de comprar hardware.
Migración a la nube para empresas y pymes: cómo se plantea
La otra mitad de la conversación. Muchas empresas descubren su necesidad de migrar a cloud precisamente al intentar hacer un proyecto de IA: se dan cuenta de que sus datos están en un servidor que nadie quiere tocar, sin API, sin copias verificadas y con una versión de sistema operativo sin soporte.
Una migración razonable sigue cinco fases:
- Inventario y evaluación. Qué aplicaciones existen, qué versiones, qué dependencias, quién las usa, qué datos manejan y cuánto costaría que estuvieran caídas un día.
- Decisión por aplicación. No todo se migra igual. Para cada sistema se elige entre mover tal cual a una máquina virtual en nube, cambiar a la versión SaaS del mismo producto, rediseñarlo, o directamente retirarlo porque ya nadie lo usa. Esta última categoría suele ser más grande de lo que la dirección espera.
- Diseño del destino. Red, identidades y permisos, cifrado, copias de seguridad, monitorización y, muy importante, control de costes: la nube mal gobernada es cara.
- Migración por oleadas. Primero lo menos crítico, para aprender. Cada oleada con su ventana, su plan de vuelta atrás y su comprobación posterior.
- Optimización. Ajustar tamaños, apagar lo que no se usa fuera de horario y revisar la factura mensualmente. Una migración sin esta fase acaba costando más que el servidor que sustituyó.
Para una pyme con pocos servidores y aplicaciones estándar, un proyecto así se mide en semanas. Para una empresa mediana con desarrollos propios y sistemas de producción conectados, en meses.
¿Quién puede migrar a cloud a una empresa que no tiene equipo de IT?
Hay tres perfiles y conviene distinguirlos. Los proveedores de infraestructura gestionada se ocupan de servidores, redes y copias: son la opción natural para un traslado sin cambios de arquitectura. Los partners certificados de los grandes proveedores cloud aportan experiencia en las particularidades de cada plataforma y suelen ser adecuados en entornos grandes o muy regulados. Y las consultoras tecnológicas trabajan primero el inventario y las decisiones de negocio (qué se migra, qué se sustituye, qué se retira) y coordinan después la ejecución. Para una empresa sin equipo de IT propio, lo determinante no es la etiqueta sino tres compromisos por escrito: un inventario documentado antes de tocar nada, un plan de vuelta atrás por cada oleada y la propiedad de las credenciales y la configuración en tu poder al terminar. Sin esos tres puntos, cambiar de proveedor después sale carísimo.
Una regla práctica para decidir
Si estás empezando con IA y no tienes ni volumen ni requisitos regulatorios estrictos, empieza en nube con un proveedor que te dé garantías de tratamiento en la Unión Europea. Mide durante tres o seis meses el volumen real y el coste. Si el gasto variable se dispara o aparece un requisito de confidencialidad que la nube no cubre, entonces evalúa el on-premise con datos propios en la mano. Es mucho más barato equivocarse en una cuota mensual que en una compra de hardware.
Conclusión
La infraestructura on-premise para LLM no es ni más moderna ni más segura por definición: es una decisión de volumen, cumplimiento y capacidad operativa. En la mayoría de empresas españolas la respuesta acaba siendo híbrida, y en muchas el primer paso real no es comprar GPUs sino ordenar y migrar la infraestructura que ya tienen.
En MG Solutions ayudamos a decidir dónde debe ejecutarse cada pieza de tu IA con números sobre la mesa, y acompañamos la migración a la nube cuando es el paso previo necesario. Si estás en esa disyuntiva, escríbenos y la analizamos con tu caso concreto.