LLM en local: por qué las empresas montan sus propios servidores de IA.
Dos de cada tres organizaciones han sacado cargas de IA del cloud público en el último año. Lo que las frena no es el presupuesto. Es tener que documentar por dónde pasan los datos antes de poder encender nada.
Durante años la respuesta por defecto fue "en la nube". OpenAI, Azure, Bedrock. Pagas por token, te olvidas del hardware, escala solo. El razonamiento se ha roto por un sitio que no estaba en la hoja de cálculo: el 95% de las empresas ha retrasado o cancelado algún proyecto de IA por gobierno del dato, cumplimiento o regulación. Ni presupuesto ni talento: saber qué datos tienes, de dónde salen y quién puede tocarlos.
del cloud público
por gobierno del dato
infraestructura de IA
Los dos primeros datos salen de The Great AI Re-Architecture, encuesta de Cloudera realizada por Wakefield Research entre 1.500 arquitectos de empresas de más de 1.000 empleados, publicada el 11 de agosto de 2026. La cifra de inversión es la previsión de IDC para 2026: 487.000 millones de dólares en infraestructura de IA.
Por qué ahora
El departamento legal ha aprendido a preguntar
"¿Dónde procesan mis datos los proveedores americanos?" es la pregunta que nadie quería hacer y que ahora hace todo el mundo, normalmente la semana antes de una auditoría.
El problema de fondo no está en el proveedor, está en el trayecto. Sacar datos personales del Espacio Económico Europeo obliga a sostener el expediente de una transferencia internacional: evaluar el país de destino, documentar garantías, informar al interesado. Procesar en tu centro de datos te ahorra ese expediente. Ojo, que no te ahorra el resto del RGPD, y si el proveedor de tu sala europea es filial de una matriz estadounidense, la conversación sobre acceso a los datos sigue abierta.
La factura del cloud no avisa, se presenta
Pagar por token parecía barato hasta que alguien miró el primer mes con el piloto ya en producción. Un servidor tiene coste fijo, así que pasado cierto volumen de inferencia la cuenta se da la vuelta. Dónde está ese punto no lo sabe nadie de antemano: depende de tu volumen, de tu modelo y de si la máquina hace algo más el resto del día. Conviene calcularlo antes de comprar, y no después.
Que quede claro, porque el sector tiende a los absolutos: esto no significa que todo el mundo esté saliendo del cloud. La misma encuesta recoge organizaciones que van a gastar más en cloud y organizaciones que van a gastar más on-premise, a la vez. Lo que se está muriendo es la respuesta única.
Latencia: se quita el viaje, no el pensamiento
Aquí conviene precisar, porque se mezclan dos cosas. Procesar en local no hace que el modelo razone más rápido; elimina el viaje de ida y vuelta a un centro de datos que puede estar en otro continente. Si la IA va incrustada en un proceso que ya es lento, ese trayecto es lo único que se puede recortar sin tocar el modelo. Si tu problema es que el modelo tarda en pensar, cambiar de sitio la máquina no te va a salvar.
Ya no hace falta el modelo más grande
Llama, Mistral, Qwen o Phi publican versiones pequeñas precisamente para esto, y para un chatbot interno, clasificar documentos o resumir actas, esas versiones hacen el trabajo. Lo que se está imponiendo es el reparto: el modelo pequeño se come el grueso de las peticiones y solo las complicadas escalan a uno grande.
Qué hardware necesitas
La memoria es lo que manda, y sale del propio formato del modelo. Cuantizado a 4 bits ocupa alrededor de medio gigabyte por cada mil millones de parámetros; en FP16, unos dos gigabytes. Sumas el contexto, que crece con la longitud de la conversación, y ya tienes el suelo.
| Modelo | Pesos (4 bits) | RAM total recomendada | Para qué sirve |
|---|---|---|---|
| 7B | ~4 GB | 16 GB en CPU | Chatbot interno, clasificación, resumen |
| 13B | ~8 GB | 32 GB en CPU, o GPU de consumo | Lo anterior con más matiz y contexto largo |
| 34B | ~20 GB | 24 GB de VRAM | Razonamiento, código, análisis de documentos |
| 70B | ~40 GB | 48 GB de VRAM o varias tarjetas | Lo que no resuelve un modelo pequeño |
Los pesos salen de multiplicar parámetros por bits. La RAM recomendada es mayor porque ahí caben también el contexto, el sistema y el margen para que el servidor no vaya al límite. Y sigue sin contemplar cuántas peticiones simultáneas vas a servir, que es la parte que casi nadie calcula.
Y ahí está el error caro. Hemos visto comprar una tarjeta de centro de datos para mover un modelo que resume actas de reunión: funciona, igual que funciona un camión para ir a por el pan. El tamaño del modelo dice si cabe en la máquina. Las peticiones simultáneas dicen si va.
La misma máquina que sirve un 7B con soltura a tres usuarios se arrastra con treinta, porque lo que se satura es el ancho de banda de memoria, no los núcleos. Si vas a dimensionar por algo, dimensiona por concurrencia en hora punta. La demo con un usuario siempre sale bien.
De las piezas que quedan, la que más se subestima es el almacenamiento. Los pesos se cargan enteros en memoria al arrancar, así que un disco lento se paga en cada reinicio y en cada cambio de modelo. Si vas a manejar varios modelos o datasets grandes, ahí es donde deja de valer un NVMe suelto y entra un sistema distribuido: lo comparamos en Storage Scale frente a Ceph para inferencia.
Que se pueda hacer sin GPU no es teoría. Lo hemos montado sobre IBM Power con vLLM, sobre AIX con llama.cpp y hasta sobre IBM i a través de PASE, que era el candidato más improbable de los tres.
Preguntas frecuentes
¿Cuánta RAM necesita un modelo de lenguaje en local?
Para los pesos, medio gigabyte por cada mil millones de parámetros si está cuantizado a 4 bits. La regla práctica es pedir el doble de lo que ocupan: un 7B se mueve cómodo con 16 GB y un 13B con 32 GB. Esa diferencia es el contexto, el sistema y el margen para que la máquina no vaya justa, que es cuando empiezan los sustos.
¿Necesito GPU para ejecutar IA en local?
No siempre, pero seamos claros con lo que significa. Hasta 13.000 millones de parámetros funciona en CPU con memoria suficiente, y va bien para procesos por lotes, tareas nocturnas o unos pocos usuarios. En un chat con gente esperando delante de la pantalla, la CPU se nota. La GPU deja de ser opcional cuando suben las peticiones simultáneas o el tamaño del modelo. Lo hemos medido sin tarjeta gráfica en vLLM sobre IBM Power.
¿Sale más barato un servidor propio que pagar por token?
A partir de cierto volumen, sí: el servidor tiene coste fijo y la API crece con el uso. Dónde está exactamente ese punto depende del modelo, del volumen y de si la máquina hace algo más el resto del día. Por debajo de ese volumen, la API sigue ganando.
¿Es legal procesar datos personales con un LLM en cloud?
Puede serlo, pero exige base legal, evaluación de impacto y garantías sobre las transferencias internacionales cuando el proveedor procesa fuera del Espacio Económico Europeo. Procesar en casa te ahorra ese expediente, no el resto del RGPD. Y si el proveedor de tu sala europea es filial de una matriz estadounidense, la conversación sobre acceso a los datos sigue abierta.
¿Qué modelos se pueden ejecutar en un servidor de empresa?
Las familias abiertas —Llama, Mistral, Qwen, Gemma, Phi— publican versiones de varios tamaños precisamente para esto. Para chatbots internos, clasificación de documentos o resumen, las pequeñas resuelven sin hardware especializado.
El siguiente paso
Antes de mirar catálogos hay que dimensionar, y son tres preguntas: qué modelo vas a correr, cuántas peticiones a la vez y con qué tiempo de respuesta te vale. De ahí salen la memoria, la CPU, la GPU y el almacenamiento, en ese orden y no en otro.
Para eso hemos montado un configurador de servidores: eliges caso de uso, escala y prioridades, y ves cómo se monta la máquina delante de ti. Sin part numbers y sin marca impuesta. Al terminar te llamamos con una propuesta cerrada.
¿Cuánto servidor necesitas para tu LLM?
Elige caso de uso, escala y prioridades, y mira cómo se monta la máquina. Sin compromiso y sin formularios eternos.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
