LLM locales: cuándo realmente tiene sentido ejecutar IA en tu propio servidor

Hace apenas un año, la conversación sobre las LLM locales solía reducirse a demos, GPUs caseras y la emoción de ver que un modelo podía funcionar sin la nube. En 2026, el tema se ha vuelto bastante más adulto. Las empresas ya han acumulado facturas de API, preguntas de compliance y cansancio por depender de un proveedor externo. Por eso la conversación ha cambiado: ya no se trata de "¿podemos ejecutar un modelo por nuestra cuenta?", sino de en qué escenarios eso resulta de verdad más rentable y más seguro que depender solo de OpenAI, Google o Anthropic.

Conviene quitar un poco de dramatismo desde el principio. Los modelos locales no han "matado a la nube", y las plataformas cloud de IA tampoco se han vuelto inútiles de repente. De hecho, OpenAI, Anthropic y Google explican por separado que, en sus productos comerciales, no usan por defecto los datos empresariales ni el tráfico de API para entrenar sus modelos. (6 8) Así que la discusión ya no va de la idea simplista de que "en la nube todo se filtra". La discusión real va de control del perímetro, previsibilidad de costes, latencia, integración con sistemas internos y el nivel de complejidad operativa que una empresa está dispuesta a asumir.

Por qué las empresas se alejan de la IA en la nube

Normalmente no hay una sola razón, sino varias a la vez.

La primera y más terrenal es la economía. Mientras la carga sea pequeña, una API en la nube casi siempre resulta más cómoda. Pero cuando aparece un flujo constante de solicitudes, los contextos se alargan, entran en juego escenarios internos de RAG y decenas de personas pasan documentos por un modelo cada día, la factura deja de parecer "una línea pequeña en la tarjeta". En ese momento, el coste fijo de tener hardware propio empieza a parecer menos un capricho de ingeniería y más una forma de volver predecible el presupuesto.

La segunda razón es el control. Si el modelo funciona dentro del propio perímetro, es más fácil mantener los datos, los logs, los índices vectoriales y las integraciones cerca del resto de la infraestructura. Para sectores con requisitos de residency, políticas internas y redes segmentadas, eso a menudo pesa más que el ahorro en sí.

La tercera razón es la dependencia de un proveedor externo. En la nube no compras solo la inteligencia del modelo, sino también el SLA de otro, sus límites, su hoja de ruta y sus cambios de condiciones. Para un producto experimental eso es normal. Pero cuando una capa interna de IA ya forma parte de los procesos operativos, muchas empresas quieren menos dependencia.

Ollama, LM Studio y cómo es hoy un stack local de verdad

Hoy un stack local ya no parece un montón de scripts raros de shell sacados de Stack Overflow.

Ollama se ha convertido en una forma cómoda de levantar un runtime local o de servidor para modelos, trabajar con ellos vía CLI y API, importar modelos GGUF y gestionar parámetros de ejecución. En la documentación de Ollama se dice de forma explícita que, cuando lo ejecutas localmente, el servicio no ve tus prompts ni tus datos, y que además las funciones cloud pueden desactivarse por completo si hace falta. Allí mismo también se describe cómo se comporta el servicio con CPU, GPU, VRAM, colas y solicitudes en paralelo. (1)

LM Studio resuelve un problema cercano. Es un entorno de escritorio cómodo para evaluar modelos y, al mismo tiempo, un servidor API local que puede levantarse en localhost. La documentación muestra cómo iniciar el servidor local desde la GUI o con lms server start, usar interfaces compatibles con OpenAI y configurar un token de API separado para el acceso. (3) Dicho de forma simple, LM Studio encaja muy bien para elegir modelos rápido y para flujos de trabajo de escritorio, mientras que Ollama suele resultar más natural cuando hace falta un modo de operación más orientado a servidor.

En la práctica, eso es justamente un stack local maduro: un runtime, un modelo, almacenamiento documental o vectorial, autenticación seria, monitorización, límites de acceso y una forma clara de actualizar los pesos. El problema no es obtener una respuesta una vez en una terminal. El problema es integrar esa respuesta después en un flujo de trabajo real de forma segura y predecible.

Qué modelos merece la pena mirar: Llama, Mistral, Mixtral

Para la mayoría de los equipos, la elección no empieza por "el modelo más inteligente del mundo", sino por el tipo de tarea.

Si hace falta un punto de partida generalista, lo habitual es mirar la familia Llama. Tiene un ecosistema muy fuerte, muchos runtimes compatibles, un montón de builds cuantizadas y una trayectoria técnica bastante clara desde modelos pequeños hasta otros mucho mayores. Meta también subraya en su documentación que la cuantización reduce las necesidades de memoria y cómputo, aunque lo hace a costa de perder algo de calidad. (5) Precisamente eso explica por qué la ejecución local se ha vuelto masiva: hoy se puede comprimir bastante un modelo y seguir obteniendo un resultado útil.

Si lo que se busca es una opción de trabajo compacta y no demasiado pesada, muchas veces el punto de entrada es Mistral. En el catálogo de Ollama, mistral aparece como un modelo 7B con un tamaño de distribución de alrededor de 4.1 GB. (1) Ese ya es un rango que se puede probar sin hardware exótico. Para asistentes internos, borradores, búsqueda sobre documentos y escenarios de copilot más ligeros, suele ser un punto de partida más realista que perseguir el mayor número posible de parámetros.

Mixtral se vuelve interesante cuando los modelos dense pequeños ya no alcanzan. En la documentación de Mistral, Mixtral 8x22B aparece descrito como un modelo MoE abierto con 141B de parámetros totales, 39B de parámetros activos y una ventana de contexto de 64k. (4) Eso ya implica otra clase de requisitos y otra conversación sobre GPU RAM, latencia y coste operativo. Este tipo de modelos tiene sentido cuando un equipo necesita de verdad un techo de calidad más alto, y no simplemente un nombre más vistoso en el README.

La regla práctica, por tanto, es sencilla: no elegir por hype, sino por la combinación tipo de tarea -> latencia aceptable -> hardware disponible -> coste del error.

Cómo se ve el hardware en la práctica

El gran malentendido de las LLM locales suena más o menos así: "si el modelo se descargó bien, entonces sirve para producción".

Un modelo puede descargarse perfectamente en un portátil. La pregunta real es a qué velocidad responde, cuántas solicitudes concurrentes soporta y hasta qué punto se dispara la latencia cuando el contexto se hace largo.

Como referencia básica, la documentación de Ollama da una guía bastante clara: para modelos 7B conviene tener al menos 8 GB de RAM, para modelos 13B, 16 GB, y para modelos 33B, 32 GB. (1) Eso no es una promesa de comodidad. Es más bien el umbral mínimo a partir del cual la conversación deja de convertirse enseguida en sufrimiento.

Si simplificamos mucho, el panorama suele verse así:

Escenario	Qué puede mover de forma realista
Solo CPU o un portátil normal	Modelos cuantizados pequeños para demos, borradores, Q&A simple y solicitudes esporádicas
Una GPU con 16-24 GB de VRAM	La clase más práctica para modelos 7B-14B de trabajo real, RAG interno y escenarios locales de copilot
48 GB de VRAM o más, o multi-GPU	Modelos más pesados, contextos más grandes, experimentos con MoE y mayor paralelismo

Aquí importan especialmente dos cosas. La primera es que las solicitudes en paralelo y los contextos largos consumen memoria muy rápido: Ollama señala explícitamente que las necesidades de RAM crecen con el número de solicitudes paralelas y con el tamaño del contexto. (2) La segunda es que la cuantización ayuda, pero siempre implica un compromiso. Meta lo formula de forma muy directa en la guía de Llama: menos memoria y una inferencia más rápida a cambio de cierta pérdida de calidad. (5)

Así, la conversación sobre LLM locales deja rápidamente de ser una conversación sobre el modelo en sí y pasa a ser una conversación sobre capacidad de infraestructura.

Privacidad y seguridad: qué resuelve el despliegue local y qué no

El despliegue local sí tiene un argumento fuerte en términos de privacidad. Cuando el modelo, los documentos y la inferencia viven dentro del propio perímetro, se reduce el número de puntos externos por los que circulan datos. Resulta más fácil explicar a auditores dónde están los prompts, quién tiene acceso a los embeddings, cómo se manejan los logs y qué servicios participan realmente en la cadena.

Pero aquí los detalles importan. La ventaja del despliegue local no está en que los proveedores cloud supuestamente no sepan trabajar bien con datos corporativos. Al contrario: OpenAI, Anthropic y Google explican por separado que, en productos comerciales y de API, no usan esos datos para entrenamiento por defecto. (6 8) La ventaja del stack local es otra: sacas del circuito el perímetro externo de inferencia y controlas tú mismo el límite de acceso.

Y la mera localización no convierte un sistema en seguro. Si levantas un servidor local sin autenticación seria, lo expones en la red, conectas bases internas sin guardrails y no restringes las herramientas del agente, no has construido "IA segura". Solo has acercado el problema. En LM Studio, por ejemplo, la autenticación de la API no es obligatoria por defecto; hay que configurarla aparte. (3) NIST también recuerda en su perfil sobre GenAI que la IA generativa trae su propio conjunto de riesgos y que la tarea de las organizaciones no es admirar la tecnología, sino gestionar esos riesgos a lo largo de todo su ciclo de vida. (9)

Por eso, la pregunta correcta con las LLM locales no es "los datos ya están en casa, así que todo está bien", sino "cómo están organizados el acceso, la segmentación, los logs, los secretos, el retrieval y el control sobre las acciones del modelo dentro de nuestro perímetro".

Cuándo los modelos locales son mejores que OpenAI, Google y Anthropic

Un stack local resulta especialmente fuerte en cinco tipos de escenarios.

Primero, cuando se trabaja con documentos internos, datos de clientes, materiales financieros, código o comunicación interna que la empresa no quiere enviar de forma regular a un perímetro externo de inferencia.

Segundo, cuando existe modo offline, un segmento de red aislado o requisitos de data residency para los que "la nube es razonablemente segura" no se considera una respuesta suficiente.

Tercero, cuando la carga es estable y predecible. Si un equipo sabe que va a ejecutar cada día miles de solicitudes parecidas para summarization, extraction, RAG o un helpdesk interno, su propia infraestructura suele darle una economía más previsible.

Cuarto, cuando importa una latencia baja cerca de los sistemas internos. A veces la ventaja no está en que el modelo local sea más barato, sino en que vive dentro del mismo perímetro que los documentos, las colas, las bases de datos y los servicios.

Quinto, cuando la tarea no exige calidad frontier a cualquier precio. En muchos escenarios internos, no hace falta "el mejor modelo del mercado", sino uno que cubra de forma fiable el 80 % de la rutina cotidiana sin salir del perímetro.

Cuándo la nube sigue siendo la opción más sensata

También existe la verdad inversa: en muchos casos, el despliegue local será simple sobreingeniería.

Si un equipo necesita arrancar en cuestión de días, no tiene ingenieros libres para operar un stack de GPU o necesita ya mismo la mejor calidad posible en reasoning y multimodalidad, los modelos cloud siguen ofreciendo el camino más corto hacia un resultado. No compras servidores, no cuidas drivers, no planificas VRAM y no te preguntas por qué una nueva cuantización empeoró de repente las respuestas sobre tu muestra de dominio.

Las plataformas cloud también ganan cuando la carga es irregular. Si el modelo no se necesita de forma constante, sino a ráfagas, pagar por API puede ser sencillamente más racional que mantener hardware propio para picos que aparecen dos veces por semana.

Por eso, la decisión real casi nunca se parece a una guerra ideológica entre "local" y "cloud". Más bien es una cuestión de madurez:

cuán sensibles son tus datos;
cuán predecible es la carga;
cuán importantes son la latencia y la autonomía;
cuán preparado está el equipo para operar el stack por sí mismo;
cuánto necesitas el techo máximo de calidad y no solo un resultado sólido de trabajo.

Las LLM locales no van de la épica del self-hosting. Van de límites

La idea más útil de todo este tema es bastante menos épica de lo que parece.

Las LLM locales no hacen falta porque "tu propio servidor siempre sea mejor que el de otro". Hacen falta cuando el control sobre los límites importa más que la comodidad de una API externa. Cuando importa más mantener datos, retrieval, logs y accesos dentro del propio perímetro. Cuando importa entender de antemano el coste de cada nuevo flujo de IA. Y cuando la calidad de un modelo open-weight compacto o mediano ya es suficiente para el negocio.

En todos los demás casos, las plataformas cloud de IA seguirán siendo una opción normal y, muchas veces, más razonable.

No porque los modelos locales sean malos.

Sino porque la IA local solo empieza a compensar cuando la empresa ya tiene una razón para gestionar no solo los prompts, sino toda la infraestructura que los rodea.