LLM en local: cuándo tiene sentido que tu empresa ejecute sus propios modelos (y cuándo no)

Conviene precisar el término, porque mezcla tres decisiones distintas. La primera es el modelo: usar modelos de pesos abiertos —Llama, Mistral, Qwen, Gemma, DeepSeek y sus derivados—, cuyos pesos puedes descargar y ejecutar en tu infraestructura. Ojo al matiz: pesos descargables no significa licencia irrestricta ni, en muchos casos, open source en sentido estricto. Muchas familias permiten el despliegue comercial, pero las condiciones varían por modelo e incluso por versión —límites de uso, cláusulas de atribución, políticas de uso aceptable—, así que la licencia oficial vigente se revisa antes de adoptar el modelo en producción, no después.

La segunda es la infraestructura, y "en local" cubre en realidad varias formas de inferencia privada con implicaciones distintas: on-premise (hardware físico de la empresa), nube privada o VPC (infraestructura cloud aislada bajo control contractual y técnico), hosting dedicado en un proveedor de GPU, y edge (inferencia pegada a donde se produce el dato). La clave no es solo dónde está físicamente la GPU, sino quién controla la infraestructura, qué proveedores intervienen y por qué sistemas circulan los datos: una nube privada, un proveedor de GPU, el almacenamiento, la observabilidad o el backup pueden seguir introduciendo terceros en la foto. La tercera decisión es la operación: quién sirve, actualiza, escala y vigila ese modelo.

Sobre las piezas técnicas, dos ideas bastan a este nivel. Para producción con concurrencia real se evalúan motores de serving especializados —vLLM es de los más extendidos, con continuous batching, gestión eficiente de memoria, API compatible con OpenAI y despliegue multi-GPU; SGLang o TensorRT-LLM son alternativas según hardware y arquitectura—, mientras que herramientas como Ollama destacan por su sencillez en desarrollo, escritorio y despliegues pequeños, y pueden ejecutarse también como servidor en escenarios controlados. El criterio no es la popularidad: es concurrencia, throughput, latencia, hardware, compatibilidad y complejidad operativa. Y la cuantización —reducir la precisión numérica de los pesos, de FP16/BF16 a 8 o 4 bits— puede recortar drásticamente memoria y coste de inferencia, pero su impacto en calidad depende del modelo, del método y de la tarea: cada combinación de modelo y cuantización debería volver a pasar por las evals del caso de uso antes de servir tráfico.

Los motivos legítimos son cinco, y conviene reconocer el propio en esta lista con honestidad, porque cada uno lleva a decisiones distintas.

El primero y más frecuente: datos que no pueden salir. Historias clínicas, expedientes, propiedad industrial, datos bajo secreto profesional o cláusulas contractuales que prohíben el tratamiento por terceros. Aquí el local no compite en coste con el cloud: compite con no hacer el proyecto, porque la alternativa real era que el caso de uso no existiera. El segundo es la soberanía y la resiliencia: no depender de un proveedor extracomunitario —ni de sus cambios de precios, de términos o de modelos— para una capacidad que se ha vuelto crítica, una preocupación que en la Europa de 2026 ha pasado de los discursos a los presupuestos. El tercero es el coste a volumen: con carga alta, estable y predecible, la inferencia propia puede costar una fracción del equivalente en tokens de API. El cuarto, la latencia y el aislamiento: entornos industriales, edge o redes desconectadas donde la API simplemente no llega. Y el quinto, el control fino: fijar la versión exacta del modelo, garantizar reproducibilidad del comportamiento y, cuando de verdad hace falta, hacer fine-tuning sobre datos propios — que no es la vía por defecto: para conocimiento empresarial cambiante se comparan prompting, RAG, herramientas y fine-tuning, y conviene recordar que el fine-tuning modifica comportamiento mientras que el RAG aporta conocimiento actualizado; son problemas distintos.

Un matiz que conviene tratar con precisión es el de la soberanía, porque son varias cosas a la vez: soberanía de datos (dónde se procesan y almacenan), de modelo (quién controla versión, pesos y disponibilidad), de infraestructura (quién controla el hardware o la nube) y operativa (quién tiene el conocimiento para mantener el servicio). Descargar los pesos no elimina automáticamente la dependencia: puedes seguir dependiendo del fabricante de GPU, del runtime, del proveedor cloud o de especialistas externos. La pregunta útil no es "¿somos soberanos?", sino qué dependencia concreta quieres reducir y qué precio tiene reducirla.

• Datos sensibles o regulados que no pueden tratarse por terceros: el caso más claro y el que desbloquea proyectos parados.
• Soberanía: eliminar la dependencia estratégica de un proveedor para una capacidad crítica del negocio.
• Volumen alto y estable: a partir de cierto caudal continuo, los tokens de API cuestan más que amortizar GPU.
• Latencia, edge y entornos desconectados: fábricas, buques, infraestructuras críticas, redes aisladas.
• Control y reproducibilidad: versión de modelo congelada, comportamiento auditable y fine-tuning propio cuando procede.

La misma honestidad aplica en sentido contrario, porque el despliegue local tiene tres costes que el entusiasmo tiende a minusvalorar. El primero es la calidad: los modelos comerciales de frontera suelen concentrar las máximas capacidades generales, aunque la distancia frente a los de pesos abiertos cambia con rapidez y depende mucho de la tarea. La pregunta útil no es cuál gana el benchmark general, sino cuál alcanza la tasa de éxito que tu caso necesita — y eso se mide con evals sobre tus casos reales, no se asume por reputación. El segundo es la operación: un modelo servido en casa es un servicio de producción más —serving, capacity planning, actualizaciones y parches, CVE, cuantizaciones, observabilidad, escalado, evaluación y rollback—, y requiere un equipo de plataforma que muchas organizaciones no tienen y no van a construir por un solo caso de uso. La pregunta ejecutiva que lo destapa: ¿quién es el propietario de este servicio cuando falle a las tres de la mañana? El tercero es el coste fijo: la GPU se paga aunque no se use, y con carga baja o irregular el pago por uso suele tener ventaja económica, salvo que existan restricciones de privacidad, infraestructura ya amortizada u otros condicionantes.

Hay además un error de secuencia muy repetido: empezar por el local antes de validar el caso de uso. Prototipa primero con la alternativa que permita validar con menor fricción —normalmente una API—, pero diseña desde el principio una capa de abstracción que evite acoplar la aplicación a un único proveedor: cambiar implica diferencias en tool calling, salidas estructuradas, contexto, límites y comportamiento, y esa misma capa es la que después hace posible el enrutado híbrido. Valida que el caso aporta valor, mide el volumen real, y entonces decide dónde debe vivir la inferencia. Comprar infraestructura para un caso de uso sin validar es la versión 2026 de comprar el clúster de Hadoop antes de tener los datos.

• Tu caso vive en la frontera de capacidad y los modelos comerciales punteros alcanzan la tasa de éxito que los abiertos hoy no dan — comprobado con evals, no por reputación.
• Tu carga es baja, irregular o experimental y no hay restricciones que fuercen el aislamiento: el pago por uso existe exactamente para eso.
• No tienes equipo de plataforma para operar un servicio crítico más, ni plan realista para tenerlo.
• Todavía no has validado el caso de uso: el orden es validar, medir, y decidir después.

La comparación de costes seria no es "tokens contra GPU": es coste total contra coste total. En el TCO local entran la infraestructura —GPU o servidores con su amortización y renovación, energía y refrigeración cuando proceda, almacenamiento, red, redundancia—, la plataforma —serving, observabilidad, seguridad, backups— y, sobre todo, las personas: la fracción de equipo que ese servicio consume de forma permanente, incluida la capacidad ociosa que se paga aunque no se use. En el TCO cloud entran los tokens de entrada y salida al volumen real proyectado —con sus picos, los embeddings y el caché de prompts cuando aplica—, los servicios gestionados alrededor y el riesgo de precio: la tarifa que hoy hace viable el caso la fija un tercero que puede cambiarla.

La estructura de la decisión es la de cualquier build vs buy con coste fijo contra variable: el coste local mensual es aproximadamente fijo —infraestructura amortizada más operación, energía y plataforma—, el cloud es variable —volumen real por coste efectivo de inferencia—, y el punto de equilibrio está donde ambas curvas se cruzan. Dónde cae depende del modelo, del hardware y de los precios del momento —por eso no publicamos aquí una cifra que caduca en un trimestre—, pero dos refinamientos convierten el ejercicio en uno útil. El primero es la utilización: una GPU barata pero infrautilizada puede salir más cara por tarea que una API aparentemente cara, así que hay que medir solicitudes al día, tokens por solicitud, concurrencia, horas de uso reales y picos. El segundo es la métrica: el coste que importa es por tarea completada correctamente, no por token — un modelo más barato por token sale más caro si necesita más iteraciones, más reintentos, más contexto o más revisión humana para el mismo resultado. Es la misma métrica que gobierna la observabilidad de agentes, y obliga a proyectar volumen real: la variable que la mayoría de los planes de IA no tiene estimada.

La disyuntiva local-o-cloud es falsa en cuanto la organización tiene más de un caso de uso, y un patrón cada vez más útil cuando conviven varios es el de cartera: un router —una pasarela interna de LLM— que dirige cada petición al modelo que le corresponde. Los criterios de enrutado son una decisión de política, no de código de aplicación: sensibilidad de los datos, exigencia de la tarea, coste, latencia, disponibilidad, modalidad, región o fallback. El flujo conceptual es simple: ¿la petición contiene datos restringidos? — al modelo privado. ¿Necesita capacidad de frontera? — a la API comercial. ¿Ninguna de las dos? — al modelo eficiente, local o cloud, que salga mejor de precio. Todo a través de una interfaz única, de forma que las aplicaciones no saben ni les importa dónde corre la inferencia.

Este patrón tiene dos ventajas estructurales más allá del reparto de cargas. Convierte la elección de modelo en una decisión de configuración y no de arquitectura —cambiar de proveedor o promocionar un modelo abierto deja de ser un proyecto—, y concentra en un punto único la gobernanza: registro de uso, presupuestos, control de qué datos van a qué destino. Es la misma lógica de desacoplar que aplicamos a los datos en la capa de conocimiento para agentes: las piezas se eligen; la arquitectura permite cambiarlas.

Toda la discusión anterior cabe en seis preguntas, en este orden: ¿los datos pueden salir del perímetro?; ¿qué calidad necesita la tarea?; ¿cuál es el volumen real?; ¿la carga es estable o variable?; ¿qué latencia y disponibilidad exige el servicio?; ¿existe capacidad operativa para mantener el modelo? La lectura orientativa: con restricciones fuertes de datos y operación disponible, el local o la nube privada ganan peso; con poca carga y necesidad de flexibilidad, el cloud; con mezcla de requisitos, el híbrido. Es una guía para ordenar la conversación, no un algoritmo.

1. ¿Caso de uso validado? Si no, valida primero

   la infraestructura no arregla un caso que no funciona.

2. ¿Hay restricciones de datos o de aislamiento? Sí

   evalúa local o nube privada para esa carga.

3. ¿El volumen es alto y estable? Sí

   calcula el punto de equilibrio local frente a cloud con tu utilización real.

4. ¿El volumen es bajo o irregular? El pago por uso suele tener ventaja, salvo restricciones o infraestructura ya disponible.

5. ¿Conviven cargas de distinto tipo? Evalúa un enrutado híbrido

   cada carga a donde le corresponde.

Un malentendido a desmontar antes de cerrar: llevar el modelo a casa no exime de nada de lo demás. Ejecutar el modelo en infraestructura propia no elimina las obligaciones que correspondan bajo el AI Act: dependen del sistema, su finalidad, su nivel de riesgo y del papel que ocupa la organización —proveedor o responsable del despliegue—, no de dónde corre la inferencia. Un chatbot de cara al público necesita los avisos de transparencia del artículo 50 sea cual sea el modelo que tenga detrás —la Comisión Europea publicó en julio de 2026 sus directrices sobre cómo aplicar esas obligaciones—, y la alfabetización del artículo 4 obliga lo mismo. El RGPD tampoco desaparece: un despliegue verdaderamente on-premise puede reducir transferencias y accesos de terceros, pero la arquitectura completa debe revisarse —hosting, logs, backups, observabilidad, soporte y actualizaciones también pueden tratar datos—. El local ayuda con la minimización, el control y la residencia del dato; no elimina la base jurídica, la seguridad, los derechos ni la responsabilidad: el tratamiento sigue existiendo.

Y en lo técnico, un modelo local necesita exactamente la misma disciplina de calidad que uno comercial: evals antes de promocionar una versión y observabilidad en producción. Fijar la versión del modelo elimina una fuente importante de cambio no controlado, pero no elimina la deriva del sistema completo: prompts, datos, RAG, herramientas, runtime y cuantización siguen cambiando. Y la responsabilidad de actualizar y re-evaluar pasa a ser tuya, con el riesgo simétrico de quedarte congelado en un modelo obsoleto porque nadie es dueño de la actualización.

• AI Act: las obligaciones dependen de la finalidad, el riesgo y el papel de la organización; el reglamento mira el uso, no la infraestructura.
• RGPD: el tratamiento sigue existiendo; el local ayuda con minimización, control y residencia, no con la responsabilidad.
• Evals: cada combinación de modelo y cuantización se valida contra tu conjunto de referencia antes de servir tráfico.
• Observabilidad: trazas, coste y tasa de éxito se miden igual; cambia el proveedor de la factura, no la necesidad.
• Seguridad y cadena de suministro: self-hosting cambia parte de la confianza en el proveedor de API por confianza en tu cadena de suministro — procedencia y verificación de los pesos, imágenes y dependencias del runtime, CVE, permisos — y el servidor de inferencia es una pieza más de la superficie de ataque.