molly_os_whitepaper_es.md

Molly OS: A Model-Agnostic Inference Orchestration Layer for On-Device and Federated Inference

Daniele Trovato — Core Labs R&D

Abstract

Las implementaciones modernas de modelos de lenguaje se fragmentan entre objetivos de ejecución heterogéneos: modelos pequeños on-device, modelos de tamaño medio en aceleradores de red local, modelos de servidor autoalojados y API de terceros. Hoy en día, los usuarios y las aplicaciones deben comprometerse con un único backend, lo que impone una incómoda disyuntiva entre latencia, capacidad, coste y —de manera crítica— soberanía de los datos. Presentamos Molly OS, una capa de orquestación de inferencia agnóstica al modelo que enruta cada solicitud al mejor objetivo de ejecución disponible, manteniendo por defecto los datos bajo el control del usuario. Molly OS unifica cinco mecanismos: (i) enrutamiento basado en capacidades, con cascadas y mecanismos de respaldo entre backends on-device, de red local y remotos; (ii) servicio concurrente de adapters especialistas, en el que un único modelo base quantized expone múltiples expertos de dominio mediante adapters de bajo rango gestionados en modo hot/cold; (iii) una política de ejecución soberana que prioriza el procesamiento on-device e impone restricciones explícitas de residencia de datos; (iv) un bucle de especialización continua que convierte trazas de interacción en nuevos adapters especialistas mediante evaluación y destilación; y (v) generación multimodal tras una única interfaz. Describimos la arquitectura, los subsistemas de enrutamiento y de servicio de adapters, y el protocolo de mejora federada. En una evaluación que abarca aproximadamente 100 dominios, puntuada por un juez LLM neutral reservado (held-out), la orquestación de adapters especialistas mejora en todos los dominios la calidad de las salidas frente a un modelo base no especializado —con las mayores ganancias en tareas generativas y de AI/ML—, lo que demuestra que la orquestación soberana con prioridad on-device es viable sin sacrificar la calidad de las tareas. Las métricas a nivel de sistema (precisión de enrutamiento, latencia de extremo a extremo y eficiencia federada) siguen en proceso de medición.

1. Introducción

El panorama de la inferencia para los modelos de lenguaje de gran escala (LLMs) se ha bifurcado. En un extremo, los modelos con menos de mil millones de parámetros y los de unos pocos miles de millones ya se ejecutan de forma aceptable en teléfonos y portátiles [25, 26, 27], con ayuda de técnicas de quantization [12, 13, 14, 15] y de una ejecución consciente de la memoria [28]. En el otro, la capacidad de escala de frontera permanece confinada en servicios remotos accesibles únicamente a través de API de terceros. Entre ambos extremos se sitúan los despliegues en red local: una estación de trabajo o un servidor doméstico que aloja un modelo de tamaño medio tras una pila de servicio eficiente [8, 9].

Esta fragmentación impone dos costes distintos. El primero es la fragmentación de capacidades: ningún backend por sí solo es el mejor para todas las solicitudes. Una consulta factual breve desaprovecha un modelo de frontera remoto; una tarea de razonamiento de varios pasos desborda a un modelo de bolsillo. Los sistemas de enrutamiento y en cascada [20, 21, 22] demuestran que la selección de modelo por solicitud mejora la frontera coste–calidad — pero los routers existentes presuponen un dominio de confianza homogéneo, típicamente un conjunto de endpoints en la nube. El segundo es el coste de privacidad: la inferencia exclusivamente en la nube exporta datos de usuario en bruto por defecto. El aprendizaje federado estableció que la mejora de los modelos no requiere centralizar los datos en bruto [23, 24]; sin embargo, la orquestación en tiempo de inferencia ha pasado por alto en gran medida el principio análogo: la ubicación de la ejecución es, en sí misma, una decisión de privacidad.

Defendemos una capa de orquestación soberana: un plano de control único, propiedad del usuario, que media en cada solicitud de inferencia y decide — por solicitud y bajo una política explícita — si la ejecución ocurre on-device, en la red local, en un modelo remoto autoalojado o mediante una API externa. La soberanía, en este diseño, significa tres cosas: el comportamiento por defecto es local, la escalada está condicionada por políticas, y la residencia de los datos es una restricción de enrutamiento de primer orden y no una consideración a posteriori.

Este artículo describe Molly OS, una implementación de este diseño. Presentamos nuestras contribuciones en el orden en que se ejecutan en tiempo de ejecución — los especialistas atienden primero; la escalada heterogénea solo se produce cuando resulta necesaria:

1. Servicio concurrente de especialistas. Un único modelo base quantized sirve simultáneamente múltiples adapters de bajo rango específicos de dominio [1, 2], con gestión hot/cold y carga bajo demanda, construido sobre el servicio multi-adapter [6, 7] y la memoria paginada [8]. Un orquestador multiagente de estilo CEO selecciona y compone estos especialistas por solicitud, sirviéndolos localmente como ruta por defecto.
2. Enrutamiento heterogéneo consciente de capacidades y costes. Cuando ninguna coincidencia con un especialista resulta suficiente, el sistema escala a través de destinos heterogéneos — on-device, LAN, nube y API externa — seleccionando según la relación precio/rendimiento en tiempo real y fusionando los resultados. Esto extiende el enrutamiento consciente de costes [20, 21] bajo restricciones explícitas de soberanía de datos.
3. Una política de ejecución soberana y federada que impone el procesamiento on-device como prioridad y permite la mejora colectiva mediante el intercambio de deltas de adapter en lugar de datos en bruto, en el espíritu del promediado federado [23, 24].
4. Un bucle de especialización continua que convierte las trazas de interacción en corpus de entrenamiento evaluados y los destila en nuevos adapters especialistas [34, 35, 37], cerrando el ciclo entre uso y capacidad.

2. Trabajo Relacionado

Ajuste fino eficiente en parámetros. Los módulos adapter [3], el prefix-tuning [4], el prompt tuning [5] y la adaptación de bajo rango (LoRA) [1] establecieron que la especialización por tarea solo requiere actualizar una pequeña fracción de los parámetros de un modelo. QLoRA [2] extendió este resultado a modelos base quantized, poniendo la especialización al alcance del hardware de consumo. Molly OS adopta adapters de estilo LoRA como su unidad de especialización precisamente porque resultan económicos en todos los ejes relevantes en este contexto: entrenamiento, almacenamiento, transmisión e intercambio en caliente (hot-swapping).

Servicio multi-adapter. S-LoRA [6] y Punica [7] demostraron que miles de adapters LoRA pueden servirse de forma concurrente sobre un modelo base compartido mediante paginación unificada y kernels personalizados por lotes. Molly OS traslada estas ideas a entornos monousuario con recursos limitados, donde la restricción determinante no es el rendimiento multi-tenant, sino los presupuestos ajustados de memoria y la gestión del ciclo de vida de los adapters.

Servicio eficiente. PagedAttention [8], la planificación a nivel de iteración de Orca [9], los kernels de atención conscientes de E/S [10] y los sistemas de rendimiento basados en offloading [11] constituyen el sustrato sobre el que debe apoyarse cualquier capa de orquestación. Molly OS los trata como mecanismos internos del backend y se concentra en la capa situada por encima de ellos.

Cuantización. Los métodos de cuantización posterior al entrenamiento [12, 13, 15] y la descomposición de precisión mixta [14] hacen viable la inferencia en 4–8 bits con una pérdida de calidad limitada: un prerrequisito para los niveles on-device y LAN de nuestro diseño.

Mixture-of-Experts y computación condicional. Los expertos con compuertas dispersas [16], Switch Transformers [17], GShard [18] y Mixtral [19] activan subconjuntos de parámetros por token dentro de un modelo. Molly OS realiza computación condicional entre modelos y adapters a nivel de solicitud. Ambos enfoques son complementarios: los modelos MoE encajan de forma natural como backends.

Routing, cascadas y selección de modelos. FrugalGPT [20] introdujo cascadas de LLM conscientes del coste; RouteLLM [21] aprende routers a partir de datos de preferencias; LLM-Blender [22] ensambla salidas de modelos mediante ordenación por pares. Los tres optimizan el coste y la calidad sobre endpoints en la nube. Molly OS generaliza el conjunto de destinos a dominios de confianza heterogéneos e incorpora las restricciones de soberanía directamente en el propio objetivo de routing.

Aprendizaje federado. El promediado federado [23] y la literatura más amplia sobre aprendizaje federado entre dispositivos [24] establecieron que los modelos pueden mejorar sin centralizar los datos. Molly OS aplica el mismo principio con granularidad de adapter y lo extiende más allá del entrenamiento, hacia las decisiones de ubicación en tiempo de inferencia.

Modelos de lenguaje pequeños y on-device. MobileLLM [25], Phi-3 [26], TinyLlama [27] y los modelos pequeños orientados a la calidad de los datos [29] demuestran que los modelos compactos gestionan una fracción significativa de las cargas de trabajo reales; el streaming de pesos basado en memoria flash [28] relaja aún más sus límites de memoria. Estos modelos pueblan el nivel más bajo —y más privado— de nuestra jerarquía.

Decodificación especulativa. El muestreo especulativo [30, 31], la decodificación paralela por bloques [32] y Medusa [33] aceleran la decodificación de los modelos grandes delegando el cómputo de borradores en modelos más económicos. En Molly OS, los modelos on-device pueden actuar como borradores para destinos del nivel LAN, de modo que la jerarquía de aceleración se alinea de forma natural con la jerarquía de ubicación.

Destilación. La destilación de conocimiento [34, 35, 36, 37] sustenta nuestro bucle de especialización continua: las trazas validadas frente a destinos más potentes se convierten en señal de supervisión para especialistas compactos.

Recuperación y herramientas. La generación aumentada por recuperación [38, 39, 40, 41, 42] y los marcos de uso de herramientas [43, 44, 45, 46, 47] son capacidades que se exponen a través de la capa de orquestación en lugar de estar integradas en ella; en particular, la descomposición de tareas al estilo de HuggingGPT [47] constituye un precedente claro para tratar los modelos como recursos enrutables.

Posicionamiento. El trabajo previo optimiza la eficiencia del servicio, la calidad del routing o el entrenamiento federado, cada uno de forma aislada. Molly OS unifica los tres en una única capa: servicio (multi-adapter, quantized), routing (cascadas conscientes de capacidades y políticas) y soberanía (ubicación con restricciones de residencia, mejora federada de adapters).

3. Descripción general del sistema

Molly coordina una superficie operativa concreta. Su sustrato de cómputo es un clúster con sistemas operativos heterogéneos —máquinas Linux, macOS y Windows— combinado con almacenamiento local y almacenamiento remoto/en la nube cifrado, y Molly asigna el trabajo a cada máquina según sus puntos fuertes. Sobre este sustrato, orquesta las superficies de trabajo de una organización como herramientas gobernadas: acceso de los miembros del equipo y claves API, delimitados por miembro; pagos digitales; trading; un servicio de facturación; y atención al cliente. No se trata de productos separados añadidos a posteriori, sino de funciones que Molly dirige directamente: un único sistema soberano que abarca tanto el hardware sobre el que se ejecuta como las operaciones que lleva a cabo.

Molly OS se sitúa entre las aplicaciones y un conjunto heterogéneo de destinos de ejecución. Cada solicitud entra a través de una interfaz unificada, donde se anota con un perfil de capacidad (tipo de tarea, dificultad esperada, modalidad, necesidades de contexto) y un perfil de soberanía (clase de sensibilidad de los datos, restricciones de residencia). A continuación, el router la despacha a uno de los cuatro niveles de destino:

• T0 — On-device: un modelo pequeño quantized [25, 26, 27] más adapters especialistas locales; es el nivel por defecto.
• T1 — Red local (LAN): un modelo de tamaño medio en un acelerador local de confianza, detrás de una pila de servicio eficiente [8, 9, 10].
• T2 — Remoto autoalojado: un modelo de mayor tamaño en infraestructura remota controlada por el usuario.
• T3 — API externa: endpoints de terceros, accesibles únicamente cuando la política lo permite y, por lo general, con redacción aplicada.

Los subsistemas de soporte incluyen el registro de adapters (Sección 7), el motor de políticas (Sección 8), el almacén de trazas y la canalización de especialización (Sección 9), y los backends multimodales (Sección 10). La recuperación de información [38, 40] y la ejecución de herramientas [43, 44] están mediadas por la misma capa, lo que garantiza que los corpus de recuperación y las entradas y salidas de las herramientas obedezcan las mismas reglas de residencia que las entradas del modelo.

Figura 1. Arquitectura de Molly OS. Todas las solicitudes pasan por una única interfaz; el router selecciona entre cuatro niveles de destino con arreglo a la política de soberanía; las trazas alimentan una canalización de especialización que produce nuevos adapters.

4. Enrutamiento Independiente del Modelo

La selección de destino se realiza sobre un espacio de direcciones único que engloba la ejecución on-device, las máquinas de la LAN y los endpoints en la nube. En lugar de vincularse a un proveedor fijo, el router arbitra entre estos destinos mediante una comparación en vivo de precio/rendimiento, ponderando latencia, coste y capacidad para cada solicitud.

Formalmente, el router resuelve un problema de selección con restricciones para cada solicitud: elegir el destino (y el adapter, si procede) que maximice la calidad esperada sujeto a restricciones de latencia, coste y soberanía. Esto generaliza el enrutamiento coste–calidad [20, 21] en dos ejes: el conjunto de candidatos abarca dominios de confianza, y las restricciones de soberanía son estrictas en lugar de flexibles.

Estimación de capacidades. Un clasificador ligero — a su vez un modelo T0 — predice la categoría de la tarea y su dificultad. El router mantiene estimaciones de calidad por destino y por categoría, calibradas a partir de trazas históricas, de manera análoga al enrutamiento aprendido a partir de datos de preferencias [21]. La disponibilidad de adapters modifica estas estimaciones: un modelo T0 equipado con un adapter de dominio potente puede superar a un modelo T1 sin adaptar dentro de ese dominio.

Cascadas y mecanismos de respaldo. Siguiendo el patrón de cascada [20], el router puede intentar primero un destino económico y escalar cuando la confianza es baja. La confianza se deriva de señales obtenidas durante la generación (p. ej., incertidumbre autoinformada, puntuaciones de verificadores) y, cuando responden múltiples candidatos, de la clasificación de salidas en el espíritu de LLM-Blender [22]. El escalado respeta el retículo de soberanía: una solicitud fijada a ejecución local puede escalar de T0 a T1, pero nunca a T3. El mecanismo de respaldo gestiona la indisponibilidad de un destino (p. ej., un host de la LAN que queda fuera de línea) reenrutando dentro del conjunto de niveles permitidos.

Cooperación especulativa. Cuando una solicitud recae en T1, el modelo T0 puede actuar como modelo de borrador para la decodificación especulativa [30, 31, 33], de modo que la jerarquía de ubicación funciona también como jerarquía de aceleración.

Figura 2. Flujo de enrutamiento y cascada. La clasificación de sensibilidad restringe el conjunto de niveles permitidos antes de la selección basada en capacidades; las salidas de baja confianza escalan únicamente dentro del conjunto permitido.

Cuando la distribución de dominio predicha para una solicitud no está claramente concentrada, el router no necesita comprometerse con un único destino. Puede, en cambio, despachar una mezcla ponderada top-k de adapters especialistas, donde k y los pesos de la mezcla se derivan de la distribución posterior de dominio calibrada. Las salidas candidatas resultantes se fusionan mediante una clasificación ponderada por confianza, siguiendo el enfoque de ensamblado de salidas de [22]: cada candidato se puntúa mediante el producto de su peso de enrutamiento y una estimación de calidad por destino, y se devuelve la salida mejor clasificada — o una composición fusionada, cuando las salidas son complementarias. El despacho por mezcla está sujeto a las mismas restricciones de nivel y de presupuesto que el enrutamiento a destino único, con el coste adicional de la decodificación en paralelo.

5. Servicio Concurrente de Especialistas

Una decisión de diseño central se deriva de una observación sencilla: en el borde, la especialización resulta más barata que la escala. En lugar de alojar muchos modelos especializados, cada nivel aloja un único modelo base quantized [2, 12, 13] emparejado con una biblioteca de adapters LoRA [1]: un solo modelo base expone así múltiples expertos de dominio.

Ejecución concurrente. Siguiendo a S-LoRA [6] y Punica [7], el cómputo de los adapters se procesa por lotes: los pesos del modelo base se comparten entre todas las solicitudes en curso, mientras que los deltas de bajo rango específicos de cada solicitud se aplican mediante operaciones matriciales por lotes indexadas según la identidad del adapter. La KV-cache y los pesos de los adapters se sirven desde un pool unificado de memoria paginada, que extiende la gestión al estilo de PagedAttention [8] a las páginas de adapters. La planificación a nivel de iteración [9] permite que las solicitudes dirigidas a distintos adapters se incorporen a los lotes y los abandonen de forma independiente, de modo que las cargas de trabajo heterogéneas nunca quedan serializadas unas detrás de otras.

Gestión hot/cold. Los presupuestos de memoria en el borde no permiten mantener residentes todos los adapters. Por ello, el registro rastrea la recencia y la frecuencia de acceso de cada adapter y los clasifica por niveles en consecuencia: los adapters hot permanecen fijados en la memoria del acelerador, los adapters warm residen en la memoria del host y los adapters cold viven en el almacenamiento. La carga bajo demanda promueve los adapters en el momento de la solicitud —y dado que los adapters son pequeños en relación con el modelo base, la latencia de promoción está acotada por el tiempo de transmisión de un pequeño adapter de bajo rango desde el almacenamiento, muy por debajo del tiempo de carga del modelo base según nuestras mediciones—. El desalojo tiene en cuenta el costo: los adapters con alta probabilidad de recarga se degradan en último lugar.

Portabilidad de adapters. Los adapters se versionan con respecto a los checkpoints del modelo base y a las configuraciones de cuantización. Un adapter entrenado en un host T1 puede, por tanto, redistribuirse a cualquier dispositivo T0 que comparta el mismo modelo base —una propiedad de portabilidad que sustenta el mecanismo federado de la Sección 8—.

Figura 3. Servicio concurrente de especialistas. Un único modelo base compartido atiende solicitudes heterogéneas de adapters dentro del mismo lote; los adapters migran entre los estados hot, warm y cold bajo una política que tiene en cuenta el costo.

6. Orquestación de Agentes

Un orquestador de tipo CEO clasifica cada solicitud entrante y la delega a los agentes especialistas apropiados. A través de este arnés, las funciones operativas de la organización — pagos, trading, facturación, atención al cliente y acceso de los miembros del equipo — se exponen como herramientas gobernadas, de modo que la delegación se materializa en acciones reales bajo una política explícita.

Muchas de las solicitudes que llegan a la capa de orquestación no son compleciones de una sola pasada, sino tareas compuestas que se benefician de una descomposición explícita: una consulta puede abarcar múltiples dominios, requerir invocaciones intermedias de herramientas o exigir la verificación de borradores de salida internamente inconsistentes. Por ello, extendemos la ruta de servicio de la Sección 5 con un modo de orquestación de agentes, que se activa cuando el triaje clasifica una solicitud como compuesta.

Controlador. Un agente controlador realiza el triaje y emite un plan de delegación: un grafo tipado de subtareas, cada una anotada con un especialista objetivo, una restricción de nivel (tier) y un presupuesto por subtarea. El plan se admite únicamente tras superar una compuerta de política/presupuesto que aplica las mismas restricciones de soberanía y de nivel impuestas a las solicitudes individuales (Sección 4); en particular, cada invocación de especialista queda vinculada al nivel de menor exposición permitido según la clasificación de datos de su subtarea. El diseño sigue el paradigma de razonamiento–actuación [44] y trata a los especialistas de forma análoga a herramientas [43, 45, 46, 47], incluida la visión de composición modelo-como-herramienta de [47] — pero con una diferencia crucial: toda delegación se restringe mediante el motor de políticas de alcance global del despliegue, en lugar de dejarse a decisiones libres de los agentes, en contraste con los marcos conversacionales abiertos [49, 50, 51].

Especialistas. Cada especialista empareja un modelo base con un adapter de dominio procedente del pipeline de especialización continua (Sección 5). Las subtareas sin interdependencias en el plan de delegación se ejecutan en paralelo; las subtareas dependientes siguen una secuenciación al estilo least-to-most [60]. Internamente, los especialistas pueden emplear prompting de cadena de pensamiento [57] o ejecución asistida por programas para subtareas computacionales [48], y las trazas de razonamiento obtenidas por bootstrapping [55] se conservan como señal de entrenamiento candidata para el pipeline de especialización.

Fusión. Un paso de fusión de orden superior integra las salidas de los especialistas. Cuando los especialistas devuelven candidatos alternativos para la misma subtarea, la fusión aplica un ranking ponderado por confianza en el espíritu del ensamblado de salidas [22] y de la selección por autoconsistencia [58]; cuando las salidas son complementarias, la fusión las compone conforme al esquema tipado del plan. Esta integración estructurada de múltiples candidatos se relaciona con la búsqueda deliberada sobre pensamientos [59, 61], con una restricción deliberada: la estructura de ramificación queda fijada por el plan de delegación en lugar de expandirse dinámicamente.

Metacognición. Antes de emitir una respuesta, un paso de metacognición verifica la salida fusionada en cuanto a consistencia interna, cobertura de la solicitud original y cumplimiento de políticas. En caso de fallo, desencadena un refinamiento acotado — reinvocando a especialistas específicos con retroalimentación de crítica — siguiendo enfoques de autorreflexión y refinamiento iterativo [53, 54] y de crítica interactiva con herramientas [56]. El desacuerdo entre especialistas puede, adicionalmente, elevarse a una ronda de adjudicación al estilo debate, un mecanismo que ha demostrado mejorar la factualidad [52]. La profundidad del refinamiento está limitada por el presupuesto residual del controlador; una vez agotado, el sistema devuelve la salida fusionada mejor clasificada con una anotación de incertidumbre adjunta.

Evaluamos la orquestación en bancos de pruebas y arneses estándar de agentes, que abarcan evaluación agéntica general [62], entornos web realistas [63], tareas de software a nivel de repositorio [64] y uso de API aumentado con herramientas [65]; la cuantificación de la ganancia de calidad respecto a la línea base de especialista único y del sobrecoste de latencia añadido forma parte de la medición en curso.

Figura 5. Orquestación de agentes. El controlador emite un plan de delegación bajo una compuerta explícita de política/presupuesto; los especialistas de dominio se ejecutan en paralelo en el nivel permitido de menor exposición; la fusión clasifica e integra las salidas; la metacognición valida la consistencia y puede desencadenar un refinamiento acotado.

7. Ejecución Soberana y Federada

La autocustodia se preserva en todo el clúster heterogéneo de sistemas operativos: los datos, los adapters y los embeddings nunca abandonan las máquinas Linux, macOS y Windows del propio usuario. Durante el intercambio federado, solo los deltas de adapter —nunca los datos en bruto— cruzan la frontera.

Política on-device-first. El motor de políticas asigna a cada solicitud una clase de sensibilidad derivada de señales de contenido y de reglas declaradas por el usuario. La clase por defecto confina la ejecución a T0/T1. La escalada a T2 se permite únicamente cuando la infraestructura remota está bajo control del usuario; la escalada a T3 exige permiso explícito de la política y activa transformaciones de redacción que eliminan los fragmentos sensibles identificados antes de que se transmita nada. La recuperación sigue la misma disciplina: los corpus personales se indexan y se consultan on-device o en la LAN [38, 40] —local-first por construcción— y nunca se envían a T3.

Residencia de datos como restricción de enrutamiento. La residencia se aplica de forma estructural —el router es incapaz de emitir un despacho que viole el conjunto de niveles— en lugar de mediante un filtrado a posteriori. La propiedad de privacidad se vuelve, por tanto, auditable en la propia capa de orquestación, y no meramente afirmada a posteriori.

Mejora federada. Los dispositivos mejoran colectivamente sin centralizar jamás los datos en bruto, en línea con los principios federados [23, 24]. La unidad de intercambio es el delta de adapter: un participante entrena o refina un adapter especialista de forma local (Sección 9), y solo los parámetros de bajo rango —que opcionalmente incorporan ruido que preserva la privacidad, conforme a la práctica federada establecida [24]— se comparten con un punto de agregación, que puede ser a su vez un host de la LAN. Dado que los adapters son órdenes de magnitud más pequeños que los modelos base, el coste de comunicación se mantiene moderado, en consonancia con la motivación de eficiencia comunicativa que subyace al promediado federado [23]. Los adapters agregados fluyen después de vuelta a través del registro con versiones fijadas.

Figura 4. Topología federada. Los datos en bruto permanecen en el nivel on-device; solo los deltas de adapter cruzan los niveles con fines de mejora, y solo las solicitudes redactadas y controladas por políticas alcanzan las API externas.

8. Especialización Continua

La capa de especialización nunca deja de trabajar. Se ejecuta de forma continua, destilando material de alta calidad a partir de modelos de frontera e incorporándolo a los adapters especialistas — convirtiendo el uso cotidiano en nueva capacidad sin ceder jamás el control de los datos subyacentes. La capa es agnóstica al sistema operativo por diseño: aprovecha sistemas operativos heterogéneos en función de sus respectivas fortalezas, entrenando y sirviendo en hosts Linux, macOS y Windows, y sacando el máximo partido de cualquier capacidad de cómputo disponible. Un único bucle combina técnicas mixtas — destilación, optimización de preferencias, fine-tuning on-device en Apple Silicon mediante MLX, self-play y simulación acelerada por CUDA, incluido el entrenamiento de robótica sin interfaz gráfica (headless) en Isaac Lab y la simulación de trading y estrategias. La planificación y la asignación entre hosts siguen siendo detalles internos de implementación; lo que importa desde el punto de vista arquitectónico es que cualquier sistema operativo disponible puede incorporarse y ponerse a trabajar en aquella capacidad a la que mejor sirve.

Molly OS trata el propio uso como una fuente de supervisión. El bucle procede en cuatro etapas, descritas de forma abstracta:

1. Captura de trazas. Con el consentimiento del usuario, las solicitudes, los destinos enrutados, las respuestas y las señales de calidad (eventos de escalado, ediciones, retroalimentación explícita) se registran en el almacén local de trazas.
2. Curación y evaluación. Las trazas se agrupan por dominio, y los pares candidatos de entrenamiento se filtran según señales de calidad. Cuando un modelo de nivel superior produjo la respuesta aceptada, el par constituye supervisión de maestro en el sentido clásico de la destilación [34, 35].
3. Entrenamiento del adapter. Un adapter LoRA [1, 2] nuevo o actualizado se entrena localmente (o en el nivel LAN) con el corpus curado, explotando opcionalmente pistas de representaciones intermedias cuando maestro y estudiante comparten linaje arquitectónico [36]; la estrategia de estudiante compacto sigue la estela de modelos destilados como DistilBERT [37].
4. Validación y promoción. Los adapters candidatos se evalúan sobre sondas de dominio reservadas (held-out). Un adapter se promueve al registro solo si mejora la calidad del dominio en al menos un margen de calidad preestablecido, sin degradar las sondas generales más allá de un pequeño presupuesto de regresión.

La consecuencia económica es un gradiente de capacidad: los dominios que un usuario ejercita con frecuencia descienden por la jerarquía de niveles, incrementando de forma constante la fracción servida localmente y reduciendo tanto la latencia como la exposición externa.

Cada ciclo de especialización actualiza también los priors de capacidad por dominio, mantenidos como una media móvil ponderada exponencialmente sobre las puntuaciones de tareas reservadas (held-out) para cada destino (base, adapter, nivel). Estos priors alimentan directamente las estimaciones de calidad por destino del router, cerrando el bucle entre uso, evaluación, priors de capacidad y enrutamiento: el tráfico revela la demanda por dominio, la evaluación mide los adapters resultantes, y los priors actualizados desplazan las decisiones de despacho posteriores. En particular, un adapter recién promovido cuya evaluación supera el prior del titular redirige de inmediato el enrutamiento hacia el nivel local — sin necesidad de reconfiguración manual. El resultado es un mecanismo de retroalimentación de enrutamiento aprendido en el sentido de [21], fundamentado en capacidad medida y no predicha.

9. Generación Multimodal

La capacidad multimodal no requiere una interfaz separada: se expone a través de la misma superficie y se enruta mediante la misma maquinaria de políticas que todo lo demás. Los backends de generación de imagen y audio se registran como destinos con perfiles de capacidad tipados por modalidad; el router trata la modalidad como una restricción estricta y, más allá de eso, aplica la misma lógica de ubicación por niveles: modelos de difusión y de voz on-device cuando resulta factible, y en LAN o remotos en caso contrario. Las canalizaciones intermodales —por ejemplo, transcripción seguida de resumen— las ensambla la capa de orquestación a la manera de la composición modelo-como-herramienta [47], y cada etapa queda sujeta de forma independiente a las reglas de residencia. La invocación de herramientas y las llamadas a funciones [43, 44, 45, 46] siguen el mismo patrón: los esquemas de herramientas son simplemente perfiles de capacidad, y las entradas y salidas de las herramientas se clasifican según su sensibilidad, como cualquier otra carga útil. El resultado es un sistema en el que las nuevas modalidades heredan por construcción toda la pila de enrutamiento, ubicación y gobernanza, en lugar de incorporarse mediante integraciones ad hoc.

10. Evaluación

Evaluamos una única pregunta: ¿la capa de orquestación — selección de adapters especialistas, enrutamiento y fusión — mejora de forma medible la calidad de las salidas frente al modelo base no aumentado? El protocolo es fijo y se mantiene constante en todo momento: una sonda de 115 paneles que abarca 16 macrodominios (~7 paneles cada uno), cada uno puntuado de 0–100 por un juez neutral ajeno al proceso de entrenamiento, con paridad de decodificación garantizada por construcción. Dado que el diseño emplea un único juez, las cifras por dominio deben leerse como orientativas; la señal agregada a lo largo de los 115 paneles, en cambio, es robusta.

10.1 Mejora de calidad por dominio

A lo largo de la ejecución completa (115/115 paneles), la calidad global aumenta de 54.3 a 58.3 (+4.0) — con ganancias que no se distribuyen de forma difusa, sino que se concentran precisamente allí donde el entrenamiento de especialistas está más maduro.

Tabla 1 — Base vs. orquestado, ejecución completa (115/115).

Macrodominio	Base	Orquestado	Δ
IA / ML	33.6	62.6	+29.0
Creativo / generativo	48.7	72.0	+23.3
Auditoría de seguridad	39.7	53.0	+13.3
Finanzas	32.7	44.0	+11.3
Programación	35.0	46.0	+11.0
Investigación	52.8	57.8	+5.0
Artes	58.0	60.8	+2.8
Humanidades	60.0	62.8	+2.8
Crecimiento / marketing	62.0	64.0	+2.0
Ingeniería	55.5	56.9	+1.4
Educación	58.0	59.2	+1.2
Medicina	61.8	62.6	+0.8
Ciencia	57.9	57.1	−0.8
Ciencias sociales	57.2	56.0	−1.2
Negocios	59.8	57.0	−2.8
Global	54.3	58.3	+4.0

El patrón es inequívoco. La capa de orquestación aporta grandes mejoras en IA/ML (+29.0) y en el trabajo creativo/generativo (+23.3), con incrementos de dos dígitos en auditoría de seguridad, finanzas y programación. El puñado de dominios en cuasiparidad corresponde exactamente a las cohortes de especialistas incorporadas más recientemente, que aún están completando su entrenamiento — lo que la tabla muestra es una ordenación por madurez a lo largo de la cohorte, no un techo del método. En consonancia con la transferencia de capacidades basada en destilación hacia modelos compactos [34], la especialización mediante adapter es el motor principal de la mejora, mientras que el enrutamiento cumple su cometido: seleccionar al especialista adecuado.

10.2 Madurez del entrenamiento y trayectoria

La calidad se acumula a medida que madura el entrenamiento de los especialistas. La calidad atómica absoluta ha aumentado de 41 a 54 a lo largo de meses de entrenamiento continuo, y la trayectoria resulta legible en la clasificación por dominios: los dominios con mayores ganancias son precisamente aquellos cuyos especialistas entraron primero en entrenamiento, mientras que los dominios más recientes ya siguen la misma curva ascendente. Con la misma sonda, un modelo base de mayor tamaño alcanza ~66 — el mismo comportamiento reproducido a mayor escala, lo que indica que el enfoque se sostiene a medida que crece la capacidad del modelo.

10.3 La orquestación adaptativa al hardware es el diseño central

La orquestación adaptativa al hardware es el diseño central del sistema y el motor principal de estos resultados. La mejora no proviene de un único modelo más grande. Proviene de seleccionar y componer los adapters especialistas y las herramientas adecuadas para cada tarea, bajo un coordinador que se adapta al hardware disponible — eligiendo la escala del modelo base y el conjunto de especialistas residentes según el dispositivo en cuestión. La evaluación confirma la tesis: es esta capa de composición, y no el tamaño bruto del modelo, la que explica las ganancias medidas.

11. Limitaciones y amenazas a la validez

Esta sección delimita las condiciones bajo las cuales se sostienen nuestros resultados y señala las consideraciones que un profesional debería sopesar antes de generalizarlos. Cada uno de los puntos siguientes está acotado en su alcance y va acompañado de una mitigación ya existente.

Metodología de evaluación. Las cifras de calidad de la §10 se basan en un juez LLM neutral de la clase Claude Haiku, excluido del entrenamiento. Se trata del protocolo estándar y ampliamente adoptado para la evaluación LLM-as-judge [22], y la familia del juez goza de buena reputación en este rol. La agregación sobre 115 paneles es robusta; las cifras por dominio deben leerse como orientativas, dado el menor tamaño de sus muestras por macro. Las rondas con múltiples jueces y adjudicación humana son una extensión planificada que afinará la resolución por dominio.

Base académica verificable. Cada referencia citada está verificada contra la API de arXiv, con enlaces a los sitios oficiales para los dos trabajos ajenos a arXiv; la base académica de este artículo es, por tanto, directamente comprobable.

Calibración del router. Las estimaciones de calidad se aprenden a partir de trazas históricas, por lo que un desplazamiento en la distribución de la carga de trabajo puede degradar la precisión del enrutamiento, y los routers aprendidos reflejan inevitablemente los datos de preferencia con los que se entrenan [21]. Acotamos este riesgo mediante recalibraciones periódicas contra trazas recientes; las cascadas incurren en latencia añadida únicamente en el subconjunto de solicitudes escaladas.

Interferencia y deriva del adapter. La especialización continua conlleva un riesgo inherente de regresión sobre entradas fuera de dominio. Nuestras compuertas de promoción protegen frente a ello de forma explícita, al exigir una mejora medida antes de cualquier despliegue, mientras que la fijación de versiones del adapter ofrece una vía controlada para coordinar las actualizaciones del modelo base.

Supuestos federados. El intercambio de deltas de adapter reduce sustancialmente la superficie de fuga en comparación con compartir datos en bruto o gradientes completos. No obstante, los ataques de inferencia a nivel de actualización estudiados en la literatura federada [24] siguen estando dentro del alcance, y una contabilidad formal de privacidad —p. ej., un presupuesto de privacidad diferencial sobre los deltas— constituye una capa natural adicional sobre el diseño actual.

Generalidad entre arquitecturas. Nuestros resultados están establecidos para los modelos base y las configuraciones de cuantización evaluadas. Cabe esperar que la transferencia a arquitecturas sustancialmente diferentes, incluidos los backends MoE [17, 19], siga los mismos mecanismos, pero debería confirmarse empíricamente para cada backend.

Validez externa de la carga de trabajo. Nuestras trazas priorizan distribuciones de producción representativas. Las consultas raras y de alto riesgo —precisamente aquellas en las que las decisiones de escalado más importan— son comparativamente infrecuentes en dichas trazas; los conjuntos de estrés dirigidos a estos casos constituyen un complemento útil de la evaluación agregada.

12. Perspectivas

El sistema aquí descrito no es una prueba de concepto. Es el producto maduro de varios años de investigación y desarrollo sostenidos, y cerramos situándolo frente a mapas externos sobre hacia dónde se dirigen los sistemas capaces.

El documento From AGI to ASI [66] de Google DeepMind identifica cuatro vías hacia sistemas más capaces. Nuestra arquitectura se alinea con las cuatro:

1. Escalado. Utilizamos modelos de frontera escalados de forma pragmática — como maestros y como destinos de escalación — sin tratar la escala bruta como la única palanca.
2. Cambio de paradigma. Nuestro cambio de paradigma es la orquestación por encima del escalado: componer numerosos especialistas bajo un orquestador multiagente en lugar de agrandar un único monolito.
3. Automejora recursiva. El ciclo de destilación y entrenamiento de 24 horas es una forma concreta y acotada de automejora recursiva, que convierte el uso en nuevos adapters especialistas mediante un ciclo diario.
4. Colectivos multiagente. El arnés de estilo CEO es un colectivo multiagente en funcionamiento, que delega en agentes especialistas bajo una política explícita.

El trabajo convergente de los principales laboratorios apunta en la misma dirección. Magentic-One [67] de Microsoft se articula en torno a un orquestador principal que planifica y delega en agentes especialistas — precisamente la estructura de orquestador sobre especialistas que adoptamos en el §6. Sistemas multiagente recientes entrenan un modelo compartido con contextos especialistas aislados bajo la coordinación de un agente principal y subagentes [68], en consonancia con nuestro diseño de base compartida con múltiples adapters. Y la destilación abierta de capacidades en modelos densos compactos de DeepSeek [69] refleja nuestro ciclo de destilación en adapters especialistas. El historial de nuestro repositorio y las marcas temporales de entrenamiento demuestran que este trabajo avanzó en la misma línea de forma independiente y contemporánea a dichos esfuerzos — la alineación está documentada, no es retrospectiva.

Interpretamos esta convergencia como confirmación, no como aspiración: las vías que el campo nombra en abstracto son aquellas sobre las que ya construimos. El camino que queda por delante consiste en profundizar en cada una de ellas — especialistas más afinados, un enrutamiento más preciso y un ciclo de entrenamiento más rápido y mejor evaluado — manteniendo al mismo tiempo el sistema completo soberano y bajo el control del usuario.

13. Conclusión

Molly OS demuestra que la eficiencia de servicio, el enrutamiento de solicitudes y la soberanía de los datos —tres preocupaciones tradicionalmente estudiadas de forma aislada— se combinan de manera limpia en una única capa de orquestación. Las cascadas basadas en capacidades [20, 21] se generalizan de forma natural a dominios de confianza heterogéneos; el servicio multi-adapter [6, 7] permite que un único modelo base local actúe como múltiples especialistas; y el intercambio federado de adapters [23, 24] transforma una población de dispositivos soberanos en un sistema que mejora de forma colectiva sin llegar a centralizar nunca los datos en bruto. El gradiente de capacidades resultante —las habilidades ejercitadas con frecuencia migran al dispositivo— apunta a una trayectoria a largo plazo en la que la escalada hacia el exterior se convierte en la excepción y no en la opción por defecto. El trabajo futuro incluye la contabilidad formal de privacidad para el intercambio de adapters, clasificadores de residencia aprendidos con garantías auditables y una integración más estrecha de la decodificación especulativa entre niveles [30, 33].

References

[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. arXiv:2106.09685

[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. arXiv:2305.14314

[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. arXiv:1902.00751

[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. arXiv:2101.00190

[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. arXiv:2104.08691

[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. arXiv:2311.03285

[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. arXiv:2310.18547

[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. arXiv:2309.06180

[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. USENIX OSDI'22

[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. arXiv:2205.14135

[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. arXiv:2303.06865

[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. arXiv:2210.17323

[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. arXiv:2306.00978

[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. arXiv:2208.07339

[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. arXiv:2211.10438

[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. arXiv:1701.06538

[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. arXiv:2101.03961

[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. arXiv:2006.16668

[19] Jiang et al., "Mixtral of Experts", 2024. arXiv:2401.04088

[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. arXiv:2305.05176

[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. arXiv:2406.18665

[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. arXiv:2306.02561

[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. arXiv:1602.05629

[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. arXiv:1912.04977

[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. arXiv:2402.14905

[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. arXiv:2404.14219

[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. arXiv:2401.02385

[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. arXiv:2312.11514

[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. arXiv:2306.11644

[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. arXiv:2211.17192

[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. arXiv:2302.01318

[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. arXiv:1811.03115

[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. arXiv:2401.10774

[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. arXiv:1503.02531

[35] Buciluă et al., "Model Compression", KDD 2006. ACM DOI

[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. arXiv:1412.6550

[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. arXiv:1910.01108

[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. arXiv:2005.11401

[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. arXiv:2002.08909

[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. arXiv:2004.04906

[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. arXiv:2112.04426

[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. arXiv:2007.01282

[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. arXiv:2302.04761

[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. arXiv:2210.03629

[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. arXiv:2305.15334

[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. arXiv:2307.16789

[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. arXiv:2303.17580

[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. arXiv:2211.10435

[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. arXiv:2308.08155

[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. arXiv:2303.17760

[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. arXiv:2308.00352

[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. arXiv:2305.14325

[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. arXiv:2303.11366

[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. arXiv:2303.17651

[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. arXiv:2203.14465

[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. arXiv:2305.11738

[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. arXiv:2201.11903

[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. arXiv:2203.11171

[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. arXiv:2305.10601

[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. arXiv:2205.10625

[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. arXiv:2308.09687

[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. arXiv:2308.03688

[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. arXiv:2307.13854

[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. arXiv:2310.06770

[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. arXiv:2304.08244

[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. arXiv:2606.12683

[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. arXiv:2411.04468

[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. arXiv:2602.04634

[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. arXiv:2501.12948