Core Labs R&DWhitepaper / Preprint (Español)
Daniele Trovato — Core Labs R&D
Los despliegues modernos de modelos de lenguaje se fragmentan a través de objetivos de ejecución heterogéneos: modelos pequeños en dispositivo, modelos de tamaño medio en aceleradores de red local, modelos de servidor autoalojados y APIs de terceros. Los usuarios y las aplicaciones se ven obligados a elegir un único backend, sacrificando latencia, capacidad, costo 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 mientras mantiene los datos bajo control del usuario por defecto. Molly OS unifica cinco mecanismos: (i) enrutamiento basado en capacidades con cascadas y mecanismos de respaldo a través de backends en dispositivo, de red local y remotos; (ii) servicio concurrente de adaptadores especialistas, en el que un único modelo base cuantizado expone múltiples expertos de dominio mediante adaptadores de bajo rango gestionados en caliente/frío; (iii) una política de ejecución soberana que impone el procesamiento prioritario en dispositivo y restricciones explícitas de residencia de datos; (iv) un bucle de especialización continua que convierte trazas de interacción en nuevos adaptadores especialistas mediante evaluación y destilación; y (v) generación multimodal detrás de una única interfaz. Describimos la arquitectura, los subsistemas de enrutamiento y servicio de adaptadores, y el protocolo de mejora federada. Una evaluación en aproximadamente 100 dominios, puntuada por un LLM juez neutral reservado, muestra que la orquestación con adaptadores especialistas mejora la calidad de las salidas frente a un modelo base no especializado en los distintos dominios — con las mayores ganancias en tareas generativas y de AI/ML — demostrando que la orquestación soberana con prioridad en dispositivo es práctica 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) son objeto de medición en curso.
El panorama de inferencia para modelos de lenguaje de gran escala (LLMs) se ha bifurcado. Por un lado, modelos de menos de mil millones y de pocos miles de millones de parámetros ya se ejecutan de forma aceptable en teléfonos y portátiles [25, 26, 27], con la ayuda de la cuantización [12, 13, 14, 15] y la ejecución consciente de la memoria [28]. Por otro, la capacidad a escala de frontera permanece concentrada en servicios remotos accesibles a través de APIs de terceros. Entre estos extremos se sitúan los despliegues de red local: una estación de trabajo o servidor doméstico que aloja un modelo de tamaño medio detrás de una pila de servicio eficiente [8, 9].
Esta fragmentación impone dos costos. Primero, la fragmentación de capacidades: ningún backend único es el mejor para todas las solicitudes. Una consulta factual corta se desperdicia en un modelo de frontera remoto; una tarea de razonamiento de múltiples pasos desborda un modelo de bolsillo. Los sistemas de enrutamiento y cascada [20, 21, 22] muestran que seleccionar entre modelos por solicitud mejora la frontera costo–calidad, pero los enrutadores existentes asumen un dominio de confianza homogéneo — típicamente un conjunto de endpoints en la nube. Segundo, el costo de privacidad: la inferencia exclusiva en la nube exporta datos de usuario en bruto por defecto. El aprendizaje federado demostró que la mejora de modelos no necesita centralizar los datos en bruto [23, 24], y sin embargo la orquestación en tiempo de inferencia ha ignorado en gran medida el principio análogo: que la ubicación de la ejecución es en sí misma una decisión de privacidad.
Defendemos una capa de orquestación soberana: un único plano de control, propiedad del usuario, que media todas las solicitudes de inferencia y decide — por solicitud y bajo una política explícita — si la ejecución ocurre en el dispositivo, en la red local, en un modelo remoto autoalojado o mediante una API externa. Soberanía significa aquí que el valor por defecto es local, que la escalada está condicionada por políticas y que la residencia de datos es una restricción de enrutamiento de primera clase en lugar de una consideración posterior.
Este artículo describe Molly OS, una implementación de este diseño. Nuestras contribuciones, ordenadas tal como se ejecutan en tiempo de ejecución —los especialistas sirven primero, y la escalada heterogénea solo cuando es necesaria— son:
Ajuste fino eficiente en parámetros. Los módulos adaptadores [3], el prefix-tuning [4], el prompt tuning [5] y la adaptación de bajo rango (LoRA) [1] mostraron que la especialización en tareas requiere actualizar solo una pequeña fracción de los parámetros. QLoRA [2] extendió esto a modelos base cuantizados, haciendo factible la especialización en hardware común. Molly OS adopta adaptadores estilo LoRA como su unidad de especialización porque son económicos de entrenar, almacenar, transmitir e intercambiar.
Servicio multi-adaptador. S-LoRA [6] y Punica [7] demostraron que miles de adaptadores LoRA pueden servirse concurrentemente contra un modelo base compartido utilizando paginación unificada y kernels personalizados por lotes. Molly OS adapta estas ideas a entornos de un solo inquilino con recursos limitados, donde el desafío no es el rendimiento multi-inquilino sino los presupuestos de memoria ajustados y la gestión del ciclo de vida de los adaptadores.
Servicio eficiente. PagedAttention [8], la planificación a nivel de iteración en Orca [9], los kernels de atención conscientes de E/S [10] y los sistemas de rendimiento basados en descarga [11] forman el sustrato sobre el que descansa cualquier capa de orquestación. Molly OS los trata como mecanismos internos del backend y se centra en la capa superior.
Cuantización. Los métodos de cuantización posterior al entrenamiento [12, 13, 15] y la descomposición de precisión mixta [14] permiten inferencia de 4–8 bits con pérdida de calidad limitada, y son prerrequisitos para los niveles en dispositivo 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 adaptadores a nivel de solicitud; ambos son complementarios, y los modelos MoE pueden servir como backends.
Enrutamiento, cascadas y selección de modelos. FrugalGPT [20] introdujo cascadas de LLM conscientes del costo; RouteLLM [21] aprende enrutadores a partir de datos de preferencias; LLM-Blender [22] combina salidas de modelos mediante clasificación por pares. Estos trabajos optimizan el costo y la calidad sobre endpoints en la nube. Molly OS generaliza el conjunto de objetivos a dominios de confianza heterogéneos y añade restricciones de soberanía al objetivo de enrutamiento.
Aprendizaje federado. El promediado federado [23] y la literatura más amplia sobre federación entre dispositivos [24] establecieron la mejora de modelos sin centralizar los datos. Molly OS aplica el mismo principio a actualizaciones a nivel de adaptador y lo extiende a las decisiones de ubicación en tiempo de inferencia.
Modelos de lenguaje pequeños y en dispositivo. MobileLLM [25], Phi-3 [26], TinyLlama [27] y modelos pequeños impulsados por la calidad de los datos [29] muestran que los modelos compactos manejan una fracción significativa de las cargas de trabajo reales; el streaming de pesos basado en memoria flash [28] relaja aún más los 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 modelos grandes utilizando computación de borrador más económica. En Molly OS, los modelos en dispositivo pueden actuar como modelos de borrador para objetivos del nivel LAN, alineando la jerarquía de aceleración con la jerarquía de ubicación.
Destilación. La destilación de conocimiento [34, 35, 36, 37] subyace en nuestro bucle de especialización continua: las trazas validadas contra objetivos más fuertes se convierten en 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 expuestas a través de la capa de orquestación; en particular, la descomposición de tareas al estilo HuggingGPT [47] es un precedente para tratar los modelos como recursos enrutables.
Posicionamiento. El trabajo previo optimiza la eficiencia de servicio, la calidad de enrutamiento o el entrenamiento federado de forma aislada. Molly OS combina servicio (multi-adaptador, cuantizado), enrutamiento (cascadas conscientes de capacidades y políticas) y soberanía (ubicación con restricciones de residencia, mejora federada de adaptadores) en una única capa.
Molly coordina una superficie operativa concreta. El sustrato de cómputo es un clúster de SO heterogéneo —máquinas Linux, macOS y Windows— combinado con almacenamiento local y con almacenamiento remoto/en la nube cifrado, y Molly trata cada máquina según sus fortalezas. Sobre este sustrato orquesta como herramientas gobernadas las superficies operativas de una organización: acceso y claves de API para los miembros del equipo, con alcance por miembro; pagos digitales; trading; un servicio de facturación; y atención al cliente. No son productos separados añadidos a posteriori, sino funciones que Molly dirige directamente, de modo que un único sistema soberano abarca tanto el hardware sobre el que corre como las operaciones que ejecuta.
Molly OS se sitúa entre las aplicaciones y un conjunto heterogéneo de objetivos de ejecución. Cada solicitud entra a través de una interfaz unificada, se anota con un perfil de capacidades (tipo de tarea, dificultad esperada, modalidad, necesidades de contexto) y un perfil de soberanía (clase de sensibilidad de datos, restricciones de residencia), y es despachada por el enrutador a uno de cuatro niveles de objetivo:
Los subsistemas de soporte incluyen el registro de adaptadores (Sección 7), el motor de políticas (Sección 8), el almacén de trazas y el pipeline de especialización (Sección 9), y los backends multimodales (Sección 10). La recuperación [38, 40] y la ejecución de herramientas [43, 44] están mediadas por la misma capa, de modo que los corpus de recuperación y la E/S de herramientas obedecen las mismas reglas de residencia que las entradas de los modelos.
flowchart TD
APP[Applications / Clients] --> GW[Unified Inference Interface]
GW --> CLS[Capability + Sensitivity Classifier]
CLS --> RT[Router]
POL[Sovereignty Policy Engine] --> RT
REG[Adapter Registry] --> RT
RT --> T0[T0: On-Device Model + Adapters]
RT --> T1[T1: LAN Model Server]
RT --> T2[T2: Self-Hosted Remote Model]
RT --> T3[T3: External API - policy gated]
T0 --> AGG[Response Aggregator / Verifier]
T1 --> AGG
T2 --> AGG
T3 --> AGG
AGG --> GW
AGG --> TRC[Trace Store]
TRC --> SPC[Specialization Pipeline]
SPC --> REG
RAGS[Retrieval Store] --- RT
TOOLS[Tool Executor] --- RT
Figura 1. Arquitectura de Molly OS. Todas las solicitudes pasan por una única interfaz; el enrutador selecciona entre cuatro niveles de objetivo bajo la política de soberanía; las trazas alimentan un pipeline de especialización que produce nuevos adaptadores.
La selección de objetivos abarca la ejecución en dispositivo, las máquinas de LAN y los endpoints en la nube dentro de un único espacio de direcciones. El router elige entre ellos por comparación de precio/rendimiento en vivo, sopesando latencia, costo y capacidad para cada solicitud en lugar de atarse a un proveedor fijo.
El enrutador resuelve, por solicitud, un problema de selección con restricciones: elegir el objetivo (y el adaptador, si corresponde) que maximice la calidad esperada sujeto a restricciones de latencia, costo y soberanía. Esto generaliza el enrutamiento costo–calidad [20, 21] de dos maneras: el conjunto de candidatos abarca dominios de confianza, y las restricciones de soberanía son duras en lugar de blandas.
Estimación de capacidades. Un clasificador ligero — él mismo un modelo T0 — predice la categoría y la dificultad de la tarea. El enrutador mantiene estimaciones de calidad por objetivo y por categoría calibradas a partir de trazas históricas, de forma análoga al enrutamiento aprendido a partir de datos de preferencias [21]. La disponibilidad de adaptadores desplaza estas estimaciones: un modelo T0 con un adaptador de dominio fuerte puede superar a un modelo T1 no adaptado para ese dominio.
Cascadas y respaldo. Siguiendo el patrón de cascada [20], el enrutador puede intentar primero un objetivo económico y escalar ante baja confianza. La confianza se calcula a partir de señales en tiempo de generación (p. ej., incertidumbre autorreportada, puntuaciones de verificadores) y, cuando responden múltiples candidatos, mediante clasificación de salidas en el espíritu de LLM-Blender [22]. La escalada respeta el retículo de soberanía: una solicitud fijada a ejecución local puede escalar T0 → T1 pero nunca a T3. El respaldo maneja la indisponibilidad de objetivos (p. ej., host LAN fuera de línea) reenrutando dentro del conjunto de niveles permitido.
Cooperación especulativa. Cuando una solicitud aterriza en T1, el modelo T0 puede servir como modelo de borrador para decodificación especulativa [30, 31, 33], de modo que la jerarquía de ubicación funciona también como jerarquía de aceleración.
flowchart TD
REQ[Incoming Request] --> SENS{Sensitivity class?}
SENS -->|Private| LOCK[Tier set = T0, T1]
SENS -->|Standard| OPEN[Tier set = T0..T3]
LOCK --> CAP[Capability + Difficulty Estimate]
OPEN --> CAP
CAP --> AD{Specialist adapter available?}
AD -->|Yes| LOCAL[Attempt T0 with adapter]
AD -->|No| EST[Score permitted targets]
EST --> PICK[Select max expected quality s.t. latency and cost]
LOCAL --> CONF{Confidence above threshold?}
PICK --> EXEC[Execute on selected target]
EXEC --> CONF
CONF -->|Yes| OUT[Return response]
CONF -->|No| ESC{Higher tier permitted?}
ESC -->|Yes| UP[Escalate to next tier]
UP --> EXEC
ESC -->|No| BEST[Return best local response with caveat]
Figura 2. Flujo de enrutamiento y cascada. La clasificación de sensibilidad restringe el conjunto de niveles permitido antes de la selección basada en capacidades; las salidas de baja confianza escalan solo dentro del conjunto permitido.
Para solicitudes cuya distribución de dominio predicha no está marcadamente concentrada, el enrutador no necesita comprometerse con un único objetivo. En su lugar, puede despachar una mezcla ponderada de los k mejores adaptadores 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 clasificación ponderada por confianza, siguiendo el enfoque de combinación de salidas de [22]: cada candidato se puntúa por el producto de su peso de enrutamiento y una estimación de calidad por objetivo, y se devuelve la salida mejor clasificada (o una composición fusionada, cuando las salidas son complementarias). El despacho por mezcla está condicionado a las mismas restricciones de nivel y presupuesto que el enrutamiento a un único objetivo, con el costo adicional de la decodificación en paralelo.
Una decisión de diseño central es que la especialización es más barata que la escala en el borde. En lugar de alojar muchos modelos especializados, cada nivel aloja un modelo base cuantizado [2, 12, 13] y una biblioteca de adaptadores LoRA [1], de modo que una única base expone muchos expertos de dominio.
Ejecución concurrente. Siguiendo a S-LoRA [6] y Punica [7], la computación de adaptadores se procesa por lotes: los pesos del modelo base se comparten entre todas las solicitudes en curso, y los deltas de bajo rango por solicitud se aplican mediante operaciones matriciales por lotes indexadas por identidad de adaptador. La caché KV y los pesos de los adaptadores comparten un grupo de memoria paginada unificado, extendiendo la gestión al estilo de PagedAttention [8] a páginas de adaptadores. La planificación a nivel de iteración [9] permite que las solicitudes que usan diferentes adaptadores se unan y abandonen los lotes de manera independiente.
Gestión caliente/fría. Los presupuestos de memoria en el borde no permiten la residencia de todos los adaptadores. El registro rastrea la recencia y la frecuencia de acceso por adaptador; los adaptadores calientes permanecen fijados en la memoria del acelerador, los adaptadores templados residen en la memoria del host, y los adaptadores fríos viven en el almacenamiento. La carga bajo demanda promueve adaptadores en el momento de la solicitud; dado que los adaptadores son pequeños en relación con el modelo base, la latencia de promoción está acotada por el tiempo de transferir un pequeño adaptador de bajo rango desde el almacenamiento, muy por debajo del tiempo de carga del modelo base en nuestras mediciones. La expulsión es consciente del costo: los adaptadores con alta probabilidad de recarga se degradan en último lugar.
Portabilidad de adaptadores. Los adaptadores se versionan contra checkpoints del modelo base y configuraciones de cuantización, de modo que un adaptador entrenado en un host T1 puede redistribuirse a dispositivos T0 que compartan la misma base — esta portabilidad sustenta el mecanismo federado de la Sección 8.
flowchart LR
subgraph SRV[Adapter-Augmented Serving Engine]
BASE[Shared Quantized Base Model]
SCHED[Iteration-Level Scheduler]
POOL[Unified Paged Memory: KV cache + adapter pages]
K[Batched LoRA Kernels]
SCHED --> BASE
BASE --> K
POOL --- BASE
POOL --- K
end
R1[Request A: legal adapter] --> SCHED
R2[Request B: medical adapter] --> SCHED
R3[Request C: code adapter] --> SCHED
subgraph REG[Adapter Registry]
HOT[Hot: device memory]
WARM[Warm: host memory]
COLD[Cold: storage]
COLD -->|on-demand load| WARM
WARM -->|promote| HOT
HOT -->|evict| WARM
end
HOT --> POOL
Figura 3. Servicio concurrente de especialistas. Un modelo base compartido sirve solicitudes heterogéneas de adaptadores en el mismo lote; los adaptadores migran entre los estados caliente, templado y frío bajo una política consciente del costo.
Un orquestador estilo CEO clasifica cada solicitud y la delega a los agentes especialistas apropiados. A través de este harness expone las funciones operativas de la organización —pagos, trading, facturación, atención al cliente y acceso de los miembros del equipo— como herramientas gobernadas, de modo que la delegación alcanza acciones reales bajo política explícita.
Muchas solicitudes presentadas a la capa de orquestación no son completaciones de un solo paso 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 salidas en borrador internamente inconsistentes. Por lo tanto, 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 y un presupuesto por subtarea. El plan se admite solo tras pasar una puerta de política/presupuesto que impone las mismas restricciones de soberanía y nivel aplicadas a las solicitudes individuales (Sección 4); en particular, cada invocación de especialista está vinculada al nivel menos expuesto permitido para la clasificación de datos de su subtarea. Este diseño sigue el paradigma de razonamiento–acción [44] y trata a los especialistas de forma análoga a las herramientas [43, 45, 46, 47], incluyendo la visión de composición de modelo-como-herramienta de [47], pero restringe toda delegación a través del motor de políticas de todo el despliegue en lugar de dejar el enrutamiento a decisiones libres de los agentes, en contraste con los marcos conversacionales abiertos [49, 50, 51].
Especialistas. Cada especialista es un modelo base emparejado con un adaptador de dominio proveniente 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 de estilo de menor a mayor [60]. Los especialistas pueden emplear internamente prompting de cadena de pensamiento [57] o ejecución asistida por programas para subtareas computacionales [48], y las trazas de razonamiento generadas por bootstrapping [55] se retienen como señal candidata de entrenamiento 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 una clasificación ponderada por confianza en el espíritu de la combinación de salidas [22] y la selección por autoconsistencia [58]; cuando las salidas son complementarias, la fusión las compone bajo el esquema tipado del plan. La integración estructurada de múltiples candidatos se relaciona con la búsqueda deliberada sobre pensamientos [59, 61], aunque aquí la estructura de ramificación está fijada por el plan de delegación en lugar de expandirse dinámicamente.
Metacognición. Antes de responder, 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 especialistas específicos con retroalimentación crítica—siguiendo los enfoques de autorreflexión y refinamiento iterativo [53, 54] y la crítica interactiva con herramientas [56]. El desacuerdo entre especialistas puede además presentarse como una ronda de adjudicación estilo debate, que ha demostrado mejorar la factualidad [52]. La profundidad del refinamiento está limitada por el presupuesto residual del controlador; su agotamiento produce la salida fusionada mejor clasificada con una anotación de incertidumbre adjunta.
Evaluamos la orquestación en benchmarks y harnesses estándar de agentes, incluyendo evaluación agéntica general [62], entornos web realistas [63], tareas de software a nivel de repositorio [64] y uso de APIs aumentado con herramientas [65]; cuantificar la ganancia de calidad sobre la línea base de especialista único y la sobrecarga de latencia añadida es parte de la medición en curso.
flowchart TD
R[Request] --> C[Controller: triage + delegation plan]
G[Policy / Budget Gate] --> C
C --> S1[Specialist A: base + domain adapter]
C --> S2[Specialist B: base + domain adapter]
C --> S3[Specialist C: base + domain adapter]
S1 --> F[Fusion: confidence-weighted ranking]
S2 --> F
S3 --> F
F --> M[Meta-cognition: consistency check]
M -- refine --> C
M -- accept --> O[Response]
Figura 5. Orquestación de agentes. El controlador emite un plan de delegación bajo una puerta explícita de política/presupuesto; los especialistas de dominio se ejecutan en paralelo en el nivel menos expuesto permitido; la fusión clasifica e integra las salidas; la metacognición valida la consistencia y puede desencadenar un refinamiento acotado.
La autocustodia se mantiene en todo el clúster de SO heterogéneo: los datos, los adaptadores y los embeddings permanecen en las propias máquinas Linux, macOS y Windows del usuario, y solo los deltas de adaptadores —nunca los datos en bruto— salen del límite durante el intercambio federado.
Política de prioridad en dispositivo. El motor de políticas asigna a cada solicitud una clase de sensibilidad derivada de señales de contenido y reglas declaradas por el usuario. La clase por defecto confina la ejecución a T0/T1. La escalada a T2 requiere que la infraestructura remota esté controlada por el usuario; la escalada a T3 requiere permiso explícito de la política y aplica transformaciones de redacción para eliminar los fragmentos sensibles identificados antes de la transmisión. La recuperación es local primero: los corpus personales se indexan y consultan en el dispositivo o en la LAN [38, 40], y nunca se envían a T3.
Residencia de datos como restricción de enrutamiento. La residencia se impone estructuralmente — el enrutador no puede emitir un despacho que viole el conjunto de niveles — en lugar de mediante filtrado a posteriori. Esto hace que la propiedad de privacidad sea auditable en la capa de orquestación.
Mejora federada. Los dispositivos mejoran colectivamente sin centralizar datos en bruto, siguiendo principios federados [23, 24]. La unidad de intercambio es el delta de adaptador: un participante entrena o refina un adaptador especialista localmente (Sección 9), y solo los parámetros de bajo rango — opcionalmente con ruido para preservación de privacidad consistente con la práctica federada establecida [24] — se comparten con un punto de agregación, que puede ser él mismo un host LAN. Dado que los adaptadores son órdenes de magnitud más pequeños que los modelos base, el costo de comunicación es modesto, haciendo eco de la motivación de eficiencia de comunicación del promediado federado [23]. Los adaptadores agregados se redistribuyen a través del registro con fijación de versiones.
flowchart TD
subgraph DEV[On-Device Tier T0]
P1[Phone: SLM + adapters]
P2[Laptop: SLM + adapters]
DATA[(Raw user data - never leaves tier)]
P1 --- DATA
P2 --- DATA
end
subgraph LAN[Local Network Tier T1]
HUB[LAN Model Server + Adapter Aggregator]
end
subgraph REM[Remote Tiers]
T2N[T2: Self-Hosted Model]
T3N[T3: External API]
end
P1 -->|adapter deltas only| HUB
P2 -->|adapter deltas only| HUB
HUB -->|aggregated adapters| P1
HUB -->|aggregated adapters| P2
P1 -.->|policy-gated, redacted requests| T3N
HUB -->|escalated inference| T2N
HUB -.->|policy-gated, redacted| T3N
Figura 4. Topología federada. Los datos en bruto permanecen en el nivel en dispositivo; solo los deltas de adaptadores cruzan los niveles para la mejora, y solo las solicitudes redactadas y autorizadas por la política alcanzan las APIs externas.
La capa de especialización corre de forma continua, ensamblando material de alta calidad destilado de modelos de frontera y alimentándolo a los adaptadores especialistas —convirtiendo el uso diario en nueva capacidad sin ceder el control de los datos que la sustentan. La capa es agnóstica al sistema operativo por diseño: está construida para explotar sistemas operativos heterogéneos según sus respectivas fortalezas, entrenando y sirviendo a través de hosts Linux, macOS y Windows, y aprovechando lo mejor del cómputo disponible. Combina técnicas mixtas bajo un solo bucle —destilación, optimización por preferencias, fine-tuning en dispositivo sobre Apple Silicon vía MLX, self-play y simulación acelerada por CUDA, incluyendo entrenamiento robótico headless en Isaac Lab y simulación de trading/estrategia. La programación y la asignación específicas entre hosts son detalles internos de implementación; lo que importa a nivel arquitectónico es que cualquier sistema operativo disponible puede incorporarse y usarse para la capacidad que mejor sirve.
Molly OS trata el uso como una fuente de supervisión. El bucle tiene cuatro etapas, descritas de forma abstracta:
La consecuencia económica es un gradiente de capacidades: los dominios que un usuario ejerce frecuentemente migran hacia abajo en la jerarquía de niveles, aumentando la fracción servida localmente con el tiempo y reduciendo tanto la latencia como la exposición externa.
Los resultados de evaluación de cada ciclo de especialización actualizan adicionalmente los priores de capacidad por dominio, mantenidos como una media móvil ponderada exponencialmente sobre las puntuaciones de tareas reservadas para cada objetivo (base, adaptador, nivel). Estos priores alimentan directamente las estimaciones de calidad por objetivo del enrutador, de modo que uso, evaluación, priores de capacidad y enrutamiento forman un bucle cerrado: el tráfico hace visible la demanda por dominio, la evaluación mide los adaptadores resultantes, y los priores actualizados desplazan las decisiones de despacho posteriores. En particular, un adaptador recién promovido cuya evaluación supera el prior del titular redirige inmediatamente el enrutamiento hacia el nivel local sin reconfiguración manual. Esto materializa un mecanismo de retroalimentación de enrutamiento aprendido en el sentido de [21], fundamentado en capacidad medida en lugar de predicha.
La capacidad multimodal se expone a través de la misma interfaz y se enruta mediante la misma maquinaria de políticas. Los backends de generación de imágenes y audio se registran como objetivos con perfiles de capacidad tipados por modalidad; el enrutador trata la modalidad como una restricción dura y, por lo demás, aplica la misma ubicación por niveles (modelos de difusión/voz en dispositivo donde sea factible, LAN o remoto en caso contrario). Los pipelines intermodales — p. ej., transcripción seguida de resumen — son compuestos por la capa de orquestación a la manera de la composición de modelo-como-herramienta [47], con cada etapa sujeta independientemente a las reglas de residencia. La invocación de herramientas y la llamada a funciones [43, 44, 45, 46] siguen el mismo patrón: los esquemas de herramientas son perfiles de capacidad, y la E/S de herramientas se clasifica según su sensibilidad como cualquier otra carga útil.
Evaluamos si la capa de orquestación —selección de adaptadores especialistas, enrutamiento y fusión— mejora la calidad de las salidas sobre el modelo base sin aumentar. El protocolo es fijo: una sonda de 115 paneles que abarca 16 macro-dominios (~7 paneles cada uno), puntuada de 0–100 por un juez neutral disjunto del proceso de entrenamiento, con paridad de decodificación garantizada por construcción. El diseño de un solo juez implica que las cifras por dominio deben leerse como direccionales; la señal agregada sobre 115 paneles es robusta.
En la ejecución completa (115/115 paneles), la calidad global sube de 54.3 a 58.3 (+4.0), con ganancias fuertes y concentradas en los dominios donde el entrenamiento especialista está más maduro.
Tabla 1 — Base vs. orquestado, ejecución completa (115/115).
| Macro-dominio | Base | Orquestado | Δ |
|---|---|---|---|
| AI / 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 |
La capa de orquestación entrega grandes mejoras en AI/ML (+29.0) y en trabajo creativo/generativo (+23.3), con mejoras de dos dígitos en auditoría de seguridad, finanzas y programación. El puñado de dominios cercanos a la paridad son las cohortes de especialistas incorporadas más recientemente, aún completando su entrenamiento —un orden de madurez de la cohorte, no un techo del método. De forma coherente con la transferencia de capacidad basada en destilación hacia modelos compactos [34], la especialización por adaptadores es el principal motor de la mejora, con el enrutamiento seleccionando al especialista apropiado.
La calidad se compone a medida que madura el entrenamiento especialista. La calidad atómica absoluta ha subido de 41 a 54 a lo largo de meses de entrenamiento continuo. Los dominios de mayor ganancia son aquellos cuyos especialistas entraron primero en entrenamiento; los dominios más nuevos ya siguen la misma curva ascendente. Sobre la misma sonda, un modelo base mayor alcanza ~66 —comportamiento consistente a mayor escala, indicando que el enfoque se sostiene conforme crece la capacidad del modelo.
La orquestación adaptativa al hardware es el diseño central del sistema y el principal motor de estos resultados. La mejora no proviene de un único modelo mayor, sino de seleccionar y componer los adaptadores especialistas y las herramientas adecuadas por tarea, bajo un coordinador que se adapta al hardware disponible —eligiendo la escala de la base y el conjunto de especialistas residentes para el dispositivo en cuestión. La evaluación confirma que esta capa de composición, y no el tamaño bruto del modelo, explica las ganancias medidas.
Esta sección delimita las condiciones bajo las cuales se sostienen nuestros resultados y señala las consideraciones que un profesional debería sopesar al generalizarlos. Cada punto está acotado y cuenta con una mitigación existente.
Metodología de evaluación. Las cifras de calidad en §10 usan un juez LLM neutral de la clase Claude Haiku, reservado del entrenamiento. Es práctica estándar y ampliamente adoptada para la evaluación LLM-como-juez [22], y esa familia de modelos es bien reconocida para este rol. El agregado de 115 paneles es robusto; los valores por dominio se leen como direccionales dada su menor muestra por macro. Las rondas multi-juez y adjudicadas por humanos son una extensión planificada que afinará la resolución por dominio.
Base académica verificable. Todas las referencias citadas están verificadas contra la API de arXiv, con enlaces oficiales de sede para los dos trabajos no-arXiv, de modo que el fundamento académico de este artículo es directamente comprobable.
Calibración del enrutador. Las estimaciones de calidad se aprenden de trazas históricas, por lo que el desplazamiento de distribución en las cargas puede afectar la precisión del enrutamiento, y los enrutadores aprendidos reflejan los datos de preferencias con los que se entrenan [21]. Lo acotamos con recalibración periódica frente a trazas frescas; las cascadas añaden latencia solo en el subconjunto de solicitudes escaladas.
Interferencia y deriva de adaptadores. La especialización continua conlleva un riesgo de regresión en entradas fuera del dominio. Nuestras puertas de promoción lo previenen explícitamente al exigir una mejora medida antes del despliegue, y la fijación de versiones de adaptadores ofrece una vía controlada para coordinar las actualizaciones del modelo base.
Suposiciones federadas. El intercambio de deltas de adaptadores reduce sustancialmente la superficie de fuga frente al uso compartido de datos en bruto o de gradientes completos. Los ataques de inferencia a nivel de actualización estudiados en la literatura federada [24] siguen en alcance, y una contabilidad formal de privacidad (p. ej., un presupuesto de privacidad diferencial sobre los deltas) es una capa natural sobre el diseño actual.
Generalidad entre arquitecturas. Los resultados se establecen para los modelos base y las configuraciones de cuantización evaluados. La transferencia a arquitecturas sustancialmente diferentes, incluidos los backends MoE [17, 19], se espera que siga los mismos mecanismos, pero conviene confirmarla empíricamente por backend.
Validez externa de la carga de trabajo. Nuestras trazas enfatizan distribuciones de producción representativas. Las consultas raras y de alto riesgo —donde las decisiones de escalada importan más— son comparativamente infrecuentes en tales trazas; conjuntos de estrés dirigidos para estos casos son un complemento útil a la evaluación agregada.
A lo largo de los últimos años hemos desarrollado un trabajo sostenido de investigación y desarrollo en esta área, y el sistema aquí descrito refleja el estado maduro de ese trabajo, no una prueba de concepto. Cerramos situándolo frente a mapas externos de hacia dónde se dirigen los sistemas capaces.
El artículo From AGI to ASI de Google DeepMind [66] expone cuatro vías hacia sistemas más capaces, y nuestra arquitectura se alinea con las cuatro:
La misma dirección se ve reforzada por trabajos convergentes de grandes laboratorios. Magentic-One de Microsoft [67] sitúa en el centro un orquestador líder que planifica y delega en agentes especialistas —la estructura de orquestador-sobre-especialistas que adoptamos en §6. Sistemas multiagente recientes entrenan un modelo compartido con contextos especialistas aislados bajo coordinación líder/subagente [68], en eco de nuestro diseño de base compartida con múltiples adaptadores. Y la destilación abierta de capacidad de DeepSeek en modelos densos compactos [69] refleja nuestro bucle de destilación en adaptadores especialistas. El historial de nuestro repositorio y los timestamps de entrenamiento sitúan este trabajo en las mismas líneas de forma independiente y contemporánea a esos esfuerzos —la alineación está documentada, no es retrospectiva.
Vemos esto como confirmación, no como aspiración: las vías que el campo nombra en abstracto son aquellas sobre las que ya construimos. Nuestra dirección futura es profundizar cada una —especialistas más afilados, enrutamiento más ajustado y un bucle de entrenamiento más rápido y mejor evaluado— manteniendo todo el sistema soberano y bajo el control del usuario.
Molly OS demuestra que la eficiencia de servicio, el enrutamiento de solicitudes y la soberanía de los datos — usualmente estudiados por separado — se componen 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-adaptador [6, 7] hace que un modelo base local se comporte como muchos especialistas; y el intercambio federado de adaptadores [23, 24] convierte una población de dispositivos soberanos en un sistema que mejora colectivamente sin centralizar los datos en bruto. El gradiente de capacidades resultante — las habilidades de uso frecuente migrando hacia el dispositivo — sugiere una trayectoria a largo plazo en la que la escalada externa se convierte en la excepción y no en el valor por defecto. El trabajo futuro incluye la contabilidad formal de privacidad para el intercambio de adaptadores, clasificadores de residencia aprendidos con garantías auditables, y una integración más estrecha de la decodificación especulativa entre niveles [30, 33].
[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