MoE avanza, RAG y RLM se quedan cortos: la soberanía de la iA local sigue siendo un trabajo de arquitectura.

Lo esperable es sencillo y seductor.
Ejecutar el modelo en la propia máquina, eliminar la dependencia de la nube y recuperar el control. La narrativa dominante sostiene que, con un modelo local de calidad combinado con RAG —o con su evolución más sofisticada, el RLM (Recursive Language Models), que propone una gestión recursiva y programática del contexto— ya se alcanza el lado correcto de la soberanía tecnológica. El contexto largo se resuelve, el conocimiento se recupera y el agente razona y actúa sin enviar datos al exterior. Esa es la versión que se difunde y, en buena medida, la que se espera.

Lo real resulta más incómodo.

En abril de este año, en el artículo “Cuando el LLM no llega al objetivo, entra la RLM vestida de Azul”, se documentó en tiempo real cómo tres modelos distintos, enfrentados al mismo proyecto y al mismo historial, comenzaban a degradarse a medida que el contexto crecía. No se trataba de un fallo de un proveedor concreto. Era un problema estructural: context rot. El modelo no se volvía más capaz por disponer de más información acumulada; se volvía más ruidoso, más estético y más perdido.

Meses después, en “¿Para quién trabaja el agente iA?”, se retomó el mismo fenómeno desde otro ángulo. La podredumbre del contexto no constituye únicamente un problema técnico: es el motor de consumo de los agentes en la nube. Cuanto más “autónomos” se vuelven, más tokens consumen y más se diluye su razonamiento. La promesa de autonomía se paga con degradación.

En julio, en “Colonizando la soberanía: el agente local como nuevo administrador”, se señaló otra capa del problema. Ni siquiera el hecho de que el cómputo ocurra en el dispositivo garantiza soberanía real. Muchas de las “iA locales” que se están desplegando son agentes propietarios que administran el entorno desde dentro.

Hoy el discurso ha avanzado. RAG se presenta como la solución madura para el conocimiento local. RLM se ofrece como la arquitectura que finalmente vence al context rot. Ambas promesas resultan atractivas. Ambas, cuando se las mide contra el hardware real de consumo y los modelos que realmente caben en ese hardware, muestran límites claros.

Este texto no niega el valor de lo local. Parte de la premisa contraria: lo local es necesario. Sin embargo, la soberanía tecnológica no se resuelve únicamente con “ejecutar el modelo en la máquina”. Se resuelve —o se diluye— en la arquitectura completa.

Mixture of Experts (MoE): una mejora real de capacidad

Antes de examinar las falencias de RAG y RLM, conviene señalar una decisión arquitectónica que sí aporta valor concreto en entornos locales: el uso de modelos Mixture of Experts (MoE).

Una arquitectura MoE divide el modelo en múltiples “expertos” (subredes especializadas) y, para cada token, activa solo un subconjunto de ellos mediante un mecanismo de enrutamiento. De este modo se separan dos magnitudes que en los modelos densos van unidas: la capacidad total del modelo (número de parámetros almacenados) y el coste de cómputo por token (parámetros que realmente se utilizan). El resultado es un sistema que puede almacenar más conocimiento que un modelo denso de tamaño comparable, mientras mantiene un coste de inferencia más bajo.

Quien trabaja con Ollama o LM Studio lo experimenta de forma directa. Al cargar un modelo MoE se observa que ocupa más espacio en disco y más memoria residente que un denso de tamaño “activo” similar. La velocidad de generación suele ser más alta de lo que el tamaño total haría esperar, porque solo se computan los expertos seleccionados. Modelos de escala intermedia —alrededor de 30 B totales con unos 3 B activos— permiten, en hardware de 32 GB o más, especialmente en memoria unificada, una capacidad de conocimiento superior a la de un denso equivalente en memoria.

Hay una nota importante que no debe pasarse por alto: aunque solo se activen unos pocos miles de millones de parámetros por token, el modelo completo debe caber —o poder cargarse— en memoria. El límite real sigue siendo el tamaño total, no únicamente los parámetros activos. Aun así, cuando el hardware lo permite, MoE constituye una mejora arquitectónica real: más capacidad útil dentro de las restricciones locales, sin necesidad de enviar datos al exterior.

El problema de fondo: capacidad frente a atención

Sin embargo, es crucial distinguir entre la capacidad de almacenamiento y la capacidad de procesamiento. Mientras que MoE optimiza el conocimiento paramétrico, no es una cura para la forma en que el modelo procesa la atención en el tiempo. El context rot permanece. Es una característica estructural de la forma en que los transformadores actuales procesan información cuando el contexto se alarga. La atención se diluye, la información situada en el medio pierde peso y el razonamiento se vuelve menos fiable mucho antes de que se agote la ventana técnica disponible.

Este fenómeno se vuelve especialmente crítico en el hardware real que utiliza la mayoría de quienes buscan soberanía efectiva: un Mac M-series de 24 GB, una tarjeta RTX de consumo o un mini-PC bien equipado. En esos entornos, un modelo de gran tamaño combinado con contexto largo y un agente multipaso no cabe ni rinde de forma cómoda. La teoría admite ventanas de cientos de miles de tokens; la práctica obliga a negociar con la memoria disponible, la latencia y el calor generado.

RAG en local: la brecha de capacidad

RAG se presenta como la solución natural al problema del conocimiento externo. En la práctica local, sin embargo, introduce un overhead que no siempre se justifica.

La construcción de embeddings, el mantenimiento del almacén vectorial y la fragmentación de documentos consumen recursos. Pero el cuello de botella principal no es la recuperación en sí, sino lo que podríamos llamar la “brecha de capacidad”. Los modelos de tamaño pequeño y mediano —precisamente los que caben de forma realista en hardware de consumo— suelen carecer de la agudeza cognitiva necesaria para discernir la señal del ruido dentro del contexto recuperado.

El contexto recuperado genera distracción: respuestas que el modelo ya conocía paramétricamente se degradan, y la información relevante no siempre se traduce en un razonamiento coherente. RAG funciona de manera aceptable para bases de conocimiento personales reducidas y consultas simples. Cuando el razonamiento se vuelve denso o multipaso, se vuelve frágil. No es una solución general; es un parche con costo real.

RLM: promesa interesante, realidad todavía pesada

RLM modifica la arquitectura del proceso. En lugar de forzar al modelo a ingerir el contexto completo como un bloque plano, trata ese contexto como un entorno externo sobre el cual el modelo puede programar: descomponer, inspeccionar, llamar a sub-modelos y reintroducir solo lo relevante.

En entornos locales ofrece ventajas claras de privacidad y de escala de contexto. Sin embargo, la realidad operativa es más exigente de lo que sugiere la teoría. Una sola consulta puede generar decenas de llamadas al modelo y ejecuciones de código. La latencia se multiplica. El modelo raíz necesita ser razonablemente capaz de programar y de descomponer problemas; los modelos pequeños tienden a confundirse o a colapsar. RLM mejora la dirección respecto al RAG ingenuo, pero todavía no convierte un entorno de consumo en una iA robusta y general.

Qué significa realmente iA local absoluta en 2026

La iA local absoluta —cien por ciento offline, sin ninguna dependencia de servicios externos— es ya viable y valiosa. Su valor, no obstante, debe medirse con precisión:

• Privacidad y control: excelentes.

• Capacidad del modelo: puede mejorarse de forma real con arquitecturas MoE, siempre dentro de los límites del hardware disponible.

• Calidad de razonamiento y fiabilidad agentic: persiste una brecha significativa.

• Conocimiento actualizado: inexistente sin intervención manual.

• Agentes de horizonte largo: frágiles por la acumulación de errores y el context rot.

Conclusiones

La soberanía tecnológica no se resuelve ejecutando un modelo en local; se resuelve diseñando la arquitectura que mejor se adapte a los límites del silicio.

La pregunta útil no es si se puede o no correr un modelo en la propia máquina, sino cuál es el equilibrio óptimo entre capacidad paramétrica (MoE) y gestión de contexto (RAG/RLM) que no sature la memoria ni diluya la atención. La soberanía real exige un criterio de decisión claro: saber cuándo el costo de latencia de un RLM es aceptable frente a la degradación de un RAG, y reconocer que, en hardware limitado, menos contexto bien gestionado es superior a un contexto infinito degradado.

MoE avanza y mejora de forma tangible la capacidad base. RAG y RLM, en cambio, siguen mostrando falencias importantes cuando se los mide contra las restricciones reales del hardware local. Son herramientas, no soluciones definitivas.

La soberanía de la iA local no se alcanza por el simple hecho de desplazar el cómputo. Se construye comprendiendo los límites del hardware disponible, de los modelos que realmente caben en él y de las arquitecturas que intentan compensar sus debilidades. Y se sostiene diseñando en torno a esos límites, no negándolos.

Autor: Leo Utzinger

Laboratorio virtual: Gemma4, Grok, DeepSeek & Qwen2.5.