Core Labs R&DWhitepaper / Preprint (Italiano)
Daniele Trovato — Core Labs R&D
Le moderne implementazioni di modelli linguistici si frammentano tra target di esecuzione eterogenei: piccoli modelli on-device, modelli di medie dimensioni su acceleratori di rete locale, modelli server auto-ospitati e API di terze parti. Utenti e applicazioni sono costretti a scegliere un singolo backend, scendendo a compromessi tra latenza, capacità, costo e — in modo critico — sovranità dei dati. Presentiamo Molly OS, un livello di orchestrazione dell'inferenza indipendente dal modello che instrada ogni richiesta verso il miglior target di esecuzione disponibile, mantenendo per impostazione predefinita i dati sotto il controllo dell'utente. Molly OS unifica cinque meccanismi: (i) instradamento basato sulle capacità con cascate e fallback tra backend on-device, di rete locale e remoti; (ii) serving concorrente di adapter specialistici, in cui un singolo modello base quantizzato espone molti esperti di dominio tramite adapter a basso rango gestiti in modalità hot/cold; (iii) una politica di esecuzione sovrana che impone l'elaborazione on-device-first e vincoli espliciti di residenza dei dati; (iv) un ciclo di specializzazione continua che converte le tracce di interazione in nuovi adapter specialistici tramite valutazione e distillazione; e (v) generazione multimodale dietro un'unica interfaccia. Descriviamo l'architettura, i sottosistemi di instradamento e di serving degli adapter, e il protocollo di miglioramento federato. Una valutazione su circa 100 domini, valutata da un giudice LLM neutrale tenuto fuori dall'addestramento, mostra che l'orchestrazione con adapter specialistici migliora la qualità dell'output rispetto a un modello base non specializzato nei vari domini — con i guadagni maggiori nei compiti generativi e di AI/ML — dimostrando che un'orchestrazione sovrana e on-device-first è praticabile senza sacrificare la qualità dei compiti. Le metriche a livello di sistema (accuratezza dell'instradamento, latenza end-to-end ed efficienza federata) sono oggetto di misurazioni in corso.
Il panorama dell'inferenza per i grandi modelli linguistici (LLM) si è biforcato. Da un lato, modelli con meno di un miliardo o pochi miliardi di parametri funzionano ormai in modo accettabile su telefoni e laptop [25, 26, 27], grazie alla quantizzazione [12, 13, 14, 15] e all'esecuzione consapevole della memoria [28]. Dall'altro, le capacità di scala frontier rimangono concentrate in servizi remoti accessibili tramite API di terze parti. Tra questi estremi si collocano le implementazioni su rete locale: una workstation o un home server che ospita un modello di medie dimensioni dietro uno stack di serving efficiente [8, 9].
Questa frammentazione impone due costi. Primo, la frammentazione delle capacità: nessun singolo backend è il migliore per tutte le richieste. Una breve ricerca fattuale è sprecata su un modello frontier remoto; un compito di ragionamento multi-passo sopraffà un modello tascabile. I sistemi di instradamento e a cascata [20, 21, 22] mostrano che selezionare tra i modelli per ciascuna richiesta migliora la frontiera costo–qualità, ma i router esistenti assumono un dominio di fiducia omogeneo — tipicamente un insieme di endpoint cloud. Secondo, il costo della privacy: l'inferenza esclusivamente cloud esporta per impostazione predefinita i dati grezzi dell'utente. L'apprendimento federato ha dimostrato che il miglioramento dei modelli non richiede la centralizzazione dei dati grezzi [23, 24], eppure l'orchestrazione a tempo di inferenza ha in larga misura ignorato il principio analogo: che il posizionamento dell'esecuzione è esso stesso una decisione di privacy.
Sosteniamo la necessità di un livello di orchestrazione sovrano: un singolo piano di controllo, di proprietà dell'utente, che media tutte le richieste di inferenza e decide — per ogni richiesta e secondo una politica esplicita — se l'esecuzione avviene on-device, sulla rete locale, su un modello remoto auto-ospitato o tramite un'API esterna. Sovranità significa qui che l'impostazione predefinita è locale, l'escalation è subordinata a una politica e la residenza dei dati è un vincolo di instradamento di prima classe e non un ripensamento.
Questo articolo descrive Molly OS, un'implementazione di questo design. I nostri contributi, ordinati come si eseguono a runtime —gli specialisti servono per primi, e l'escalation eterogenea segue solo quando serve— sono:
Fine-tuning efficiente nei parametri. I moduli adapter [3], il prefix-tuning [4], il prompt tuning [5] e l'adattamento a basso rango (LoRA) [1] hanno mostrato che la specializzazione su un compito richiede l'aggiornamento di una sola piccola frazione dei parametri. QLoRA [2] ha esteso questo approccio ai modelli base quantizzati, rendendo la specializzazione realizzabile su hardware di largo consumo. Molly OS adotta adapter in stile LoRA come unità di specializzazione perché sono economici da addestrare, archiviare, trasmettere e sostituire.
Serving multi-adapter. S-LoRA [6] e Punica [7] hanno dimostrato che migliaia di adapter LoRA possono essere serviti in modo concorrente su un modello base condiviso utilizzando paging unificato e kernel batched personalizzati. Molly OS adatta queste idee a contesti single-tenant con risorse limitate, dove la sfida non è il throughput multi-tenant ma i budget di memoria stringenti e la gestione del ciclo di vita degli adapter.
Serving efficiente. PagedAttention [8], lo scheduling a livello di iterazione in Orca [9], i kernel di attention consapevoli dell'I/O [10] e i sistemi di throughput basati su offloading [11] formano il substrato su cui poggia qualsiasi livello di orchestrazione. Molly OS li tratta come meccanismi interni ai backend e si concentra sul livello superiore.
Quantizzazione. I metodi di quantizzazione post-addestramento [12, 13, 15] e la decomposizione a precisione mista [14] consentono l'inferenza a 4–8 bit con perdita di qualità limitata, e sono prerequisiti per i livelli on-device e LAN del nostro design.
Mixture-of-Experts e computazione condizionale. Gli esperti a gating sparso [16], gli Switch Transformer [17], GShard [18] e Mixtral [19] attivano sottoinsiemi di parametri per token all'interno di un modello. Molly OS esegue computazione condizionale tra modelli e adapter a livello di richiesta; i due approcci sono complementari e i modelli MoE possono fungere da backend.
Instradamento, cascate e selezione dei modelli. FrugalGPT [20] ha introdotto le cascate di LLM consapevoli dei costi; RouteLLM [21] apprende router da dati di preferenza; LLM-Blender [22] combina gli output dei modelli tramite ranking a coppie. Questi lavori ottimizzano costo e qualità su endpoint cloud. Molly OS generalizza l'insieme dei target a domini di fiducia eterogenei e aggiunge vincoli di sovranità all'obiettivo di instradamento.
Apprendimento federato. Il federated averaging [23] e la più ampia letteratura sul federated cross-device [24] hanno stabilito il miglioramento dei modelli senza centralizzare i dati. Molly OS applica lo stesso principio agli aggiornamenti a livello di adapter e lo estende alle decisioni di posizionamento a tempo di inferenza.
Modelli linguistici piccoli e on-device. MobileLLM [25], Phi-3 [26], TinyLlama [27] e i modelli piccoli guidati dalla qualità dei dati [29] mostrano che modelli compatti gestiscono una frazione significativa dei carichi di lavoro reali; lo streaming dei pesi da memoria flash [28] allenta ulteriormente i limiti di memoria. Questi modelli popolano il livello più basso e più privato della nostra gerarchia.
Decodifica speculativa. Il campionamento speculativo [30, 31], la decodifica parallela a blocchi [32] e Medusa [33] accelerano la decodifica dei grandi modelli usando una computazione di bozza più economica. In Molly OS, i modelli on-device possono fungere da modelli di bozza per i target di livello LAN, allineando la gerarchia di accelerazione con la gerarchia di posizionamento.
Distillazione. La distillazione della conoscenza [34, 35, 36, 37] è alla base del nostro ciclo di specializzazione continua: le tracce validate rispetto a target più potenti diventano supervisione per specialisti compatti.
Retrieval e strumenti. La generazione aumentata dal retrieval [38, 39, 40, 41, 42] e i framework per l'uso di strumenti [43, 44, 45, 46, 47] sono capacità esposte attraverso il livello di orchestrazione; in particolare, la scomposizione dei compiti in stile HuggingGPT [47] è un precedente per trattare i modelli come risorse instradabili.
Posizionamento. I lavori precedenti ottimizzano l'efficienza del serving, la qualità dell'instradamento o l'addestramento federato in modo isolato. Molly OS combina serving (multi-adapter, quantizzato), instradamento (cascate consapevoli di capacità e politiche) e sovranità (posizionamento vincolato dalla residenza, miglioramento federato degli adapter) in un unico livello.
Molly coordina una superficie operativa concreta. Il substrato di calcolo è un cluster a OS eterogeneo —macchine Linux, macOS e Windows— affiancato da storage locale e da storage remoto/cloud cifrato, e Molly tratta ogni macchina secondo i suoi punti di forza. Sopra questo substrato orchestra come strumenti governati le superfici operative di un'organizzazione: accesso e API key per i membri del team, con ambito per singolo membro; pagamenti digitali; trading; un servizio di fatturazione; e customer service. Non sono prodotti separati aggiunti a posteriori, ma funzioni che Molly guida direttamente, così che un unico sistema sovrano abbracci sia l'hardware su cui gira sia le operazioni che esegue.
Molly OS si colloca tra le applicazioni e un pool eterogeneo di target di esecuzione. Ogni richiesta entra attraverso un'interfaccia unificata, viene annotata con un profilo di capacità (tipo di compito, difficoltà prevista, modalità, esigenze di contesto) e un profilo di sovranità (classe di sensibilità dei dati, vincoli di residenza), e viene inoltrata dal router a uno dei quattro livelli di target:
I sottosistemi di supporto includono il registro degli adapter (Sezione 7), il motore delle politiche (Sezione 8), l'archivio delle tracce e la pipeline di specializzazione (Sezione 9) e i backend multimodali (Sezione 10). Il retrieval [38, 40] e l'esecuzione degli strumenti [43, 44] sono mediati dallo stesso livello, in modo che i corpora di retrieval e l'I/O degli strumenti rispettino le stesse regole di residenza degli input dei modelli.
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. Architettura di Molly OS. Tutte le richieste passano attraverso un'unica interfaccia; il router seleziona tra quattro livelli di target secondo la politica di sovranità; le tracce alimentano una pipeline di specializzazione che produce nuovi adapter.
La selezione del target abbraccia l'esecuzione on-device, le macchine in LAN e gli endpoint cloud in un unico spazio di indirizzamento. Il router sceglie tra essi tramite confronto prezzo/prestazioni in tempo reale, pesando latenza, costo e capacità per ogni richiesta anziché vincolarsi a un provider fisso.
Il router risolve, per ogni richiesta, un problema di selezione vincolata: scegliere il target (e l'adapter, se applicabile) che massimizza la qualità attesa soggetta a vincoli di latenza, costo e sovranità. Questo generalizza l'instradamento costo–qualità [20, 21] in due modi: l'insieme dei candidati attraversa domini di fiducia, e i vincoli di sovranità sono rigidi anziché flessibili.
Stima delle capacità. Un classificatore leggero — esso stesso un modello T0 — predice la categoria e la difficoltà del compito. Il router mantiene stime di qualità per target e per categoria, calibrate dalle tracce storiche, in modo analogo all'instradamento appreso da dati di preferenza [21]. La disponibilità di adapter modifica queste stime: un modello T0 con un solido adapter di dominio può superare in classifica un modello T1 non adattato per quel dominio.
Cascate e fallback. Seguendo il pattern a cascata [20], il router può tentare prima un target economico ed eseguire l'escalation in caso di bassa confidenza. La confidenza è calcolata da segnali a tempo di generazione (es. incertezza auto-riportata, punteggi del verificatore) e, dove rispondono più candidati, dal ranking degli output nello spirito di LLM-Blender [22]. L'escalation rispetta il reticolo di sovranità: una richiesta vincolata all'esecuzione locale può fare escalation T0 → T1 ma mai verso T3. Il fallback gestisce l'indisponibilità di un target (es. host LAN offline) reinstradando all'interno dell'insieme di livelli consentito.
Cooperazione speculativa. Quando una richiesta approda su T1, il modello T0 può fungere da modello di bozza per la decodifica speculativa [30, 31, 33], cosicché la gerarchia di posizionamento funge anche da gerarchia di accelerazione.
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. Flusso di instradamento e cascata. La classificazione della sensibilità restringe l'insieme di livelli consentito prima della selezione basata sulle capacità; gli output a bassa confidenza fanno escalation solo all'interno dell'insieme consentito.
Per le richieste la cui distribuzione di dominio prevista non è nettamente concentrata, il router non deve necessariamente impegnarsi su un singolo target. Può invece inviare una miscela pesata top-k di adapter specialistici, dove k e i pesi della miscela sono derivati dalla distribuzione a posteriori di dominio calibrata. Gli output candidati risultanti sono fusi tramite ranking pesato per confidenza, seguendo l'approccio di ensembling degli output di [22]: ciascun candidato è valutato dal prodotto del suo peso di instradamento e di una stima di qualità per target, e viene restituito l'output con il ranking più alto (o una composizione integrata, quando gli output sono complementari). Il dispatch a miscela è soggetto agli stessi vincoli di livello e budget dell'instradamento a singolo target, con il costo aggiuntivo della decodifica parallela.
Una scelta progettuale centrale è che la specializzazione è più economica della scala alla periferia. Anziché ospitare molti modelli specializzati, ciascun livello ospita un modello base quantizzato [2, 12, 13] e una libreria di adapter LoRA [1], cosicché una singola base espone molti esperti di dominio.
Esecuzione concorrente. Seguendo S-LoRA [6] e Punica [7], la computazione degli adapter è batched: i pesi del modello base sono condivisi tra tutte le richieste in corso, e i delta a basso rango per richiesta sono applicati tramite operazioni matriciali batched indicizzate per identità dell'adapter. La KV-cache e i pesi degli adapter condividono un pool unificato di memoria paginata, estendendo la gestione in stile PagedAttention [8] alle pagine degli adapter. Lo scheduling a livello di iterazione [9] consente alle richieste che usano adapter diversi di entrare e uscire dai batch in modo indipendente.
Gestione hot/cold. I budget di memoria della periferia non consentono la residenza di tutti gli adapter. Il registro traccia la recenza e la frequenza di accesso per adapter; gli adapter hot rimangono fissati nella memoria dell'acceleratore, gli adapter warm risiedono nella memoria host e gli adapter cold vivono su storage. Il caricamento on-demand promuove gli adapter al momento della richiesta; poiché gli adapter sono piccoli rispetto al modello base, la latenza di promozione è limitata dal tempo necessario a trasferire in streaming un piccolo adapter a basso rango dallo storage, di gran lunga inferiore al tempo di caricamento del modello base nelle nostre misurazioni. L'eviction è consapevole dei costi: gli adapter con alta probabilità di ricaricamento vengono retrocessi per ultimi.
Portabilità degli adapter. Gli adapter sono versionati rispetto ai checkpoint del modello base e alle configurazioni di quantizzazione, cosicché un adapter addestrato su un host T1 può essere ridistribuito a dispositivi T0 che condividono la stessa base — questa portabilità è alla base del meccanismo federato della Sezione 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. Serving specialistico concorrente. Un unico modello base condiviso serve richieste di adapter eterogenee nello stesso batch; gli adapter migrano tra stati hot, warm e cold secondo una politica consapevole dei costi.
Un orchestratore in stile CEO classifica ogni richiesta e la delega agli agenti specialisti appropriati. Attraverso questo harness espone le funzioni operative dell'organizzazione —pagamenti, trading, fatturazione, customer service e accesso dei membri del team— come strumenti governati, così che la delega raggiunga azioni reali sotto policy esplicita.
Molte richieste presentate al livello di orchestrazione non sono completamenti single-shot ma compiti compositi che beneficiano di una scomposizione esplicita: una query può abbracciare più domini, richiedere invocazioni intermedie di strumenti o esigere la verifica di output di bozza internamente incoerenti. Estendiamo quindi il percorso di serving della Sezione 5 con una modalità di orchestrazione di agenti che si attiva quando il triage classifica una richiesta come composita.
Controller. Un agente controller esegue il triage ed emette un piano di delega: un grafo tipizzato di sottocompiti, ciascuno annotato con uno specialista di destinazione, un vincolo di livello e un budget per sottocompito. Il piano viene ammesso solo dopo aver superato un gate di politica/budget che impone gli stessi vincoli di sovranità e di livello applicati alle richieste singole (Sezione 4); in particolare, ogni invocazione di specialista è vincolata al livello meno esposto consentito per la classificazione dei dati del suo sottocompito. Questo design segue il paradigma ragionamento–azione [44] e tratta gli specialisti in modo analogo agli strumenti [43, 45, 46, 47], inclusa la visione di composizione modello-come-strumento di [47], ma vincola tutta la delega attraverso il motore delle politiche a livello di deployment anziché lasciare l'instradamento a decisioni agentiche libere, in contrasto con i framework conversazionali aperti [49, 50, 51].
Specialisti. Ogni specialista è un modello base accoppiato con un adapter di dominio proveniente dalla pipeline di specializzazione continua (Sezione 5). I sottocompiti senza interdipendenze nel piano di delega vengono eseguiti in parallelo; i sottocompiti dipendenti seguono un sequenziamento in stile least-to-most [60]. Gli specialisti possono impiegare internamente prompting chain-of-thought [57] o esecuzione assistita da programmi per sottocompiti computazionali [48], e le tracce di ragionamento bootstrappate [55] vengono conservate come segnale di addestramento candidato per la pipeline di specializzazione.
Fusione. Un passo di fusione di ordine superiore integra gli output degli specialisti. Quando gli specialisti restituiscono candidati alternativi per lo stesso sottocompito, la fusione applica un ranking pesato per confidenza nello spirito dell'ensembling degli output [22] e della selezione per auto-coerenza [58]; quando gli output sono complementari, la fusione li compone secondo lo schema tipizzato del piano. L'integrazione strutturata multi-candidato è correlata alla ricerca deliberata sui pensieri [59, 61], sebbene qui la struttura di ramificazione sia fissata dal piano di delega anziché espansa dinamicamente.
Meta-cognizione. Prima di rispondere, un passo di meta-cognizione verifica la coerenza interna dell'output fuso, la copertura della richiesta originale e la conformità alle politiche. In caso di fallimento, innesca un raffinamento limitato — reinvocando specialisti specifici con feedback di critica — seguendo approcci di auto-riflessione e raffinamento iterativo [53, 54] e di critica interattiva con strumenti [56]. Il disaccordo tra specialisti può inoltre emergere come un turno di aggiudicazione in stile dibattito, che ha dimostrato di migliorare la fattualità [52]. La profondità del raffinamento è limitata dal budget residuo del controller; il suo esaurimento restituisce l'output fuso con il miglior ranking corredato da un'annotazione di incertezza.
Valutiamo l'orchestrazione su benchmark e harness agentici standard, inclusa la valutazione agentica generale [62], ambienti web realistici [63], compiti software a livello di repository [64] e l'uso di API aumentato da strumenti [65]; la quantificazione del guadagno di qualità rispetto al baseline a singolo specialista e dell'overhead di latenza aggiunto fa parte delle misurazioni in corso.
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. Orchestrazione di agenti. Il controller emette un piano di delega sotto un gate esplicito di politica/budget; gli specialisti di dominio vengono eseguiti in parallelo sul livello consentito meno esposto; la fusione classifica e integra gli output; la meta-cognizione valida la coerenza e può innescare un raffinamento limitato.
La self-custody vale sull'intero cluster a OS eterogeneo: dati, adapter ed embedding restano sulle macchine Linux, macOS e Windows dell'utente, e solo i delta degli adapter —mai i dati grezzi— lasciano il confine durante lo scambio federato.
Politica on-device-first. Il motore delle politiche assegna a ciascuna richiesta una classe di sensibilità derivata da segnali di contenuto e regole dichiarate dall'utente. La classe predefinita confina l'esecuzione a T0/T1. L'escalation a T2 richiede che l'infrastruttura remota sia controllata dall'utente; l'escalation a T3 richiede un permesso esplicito di politica e applica trasformazioni di redazione per rimuovere gli intervalli sensibili identificati prima della trasmissione. Il retrieval è local-first: i corpora personali sono indicizzati e interrogati on-device o sulla LAN [38, 40], mai inviati a T3.
Residenza dei dati come vincolo di instradamento. La residenza è imposta strutturalmente — il router non può emettere un dispatch che violi l'insieme di livelli — anziché tramite filtraggio a posteriori. Ciò rende la proprietà di privacy verificabile al livello di orchestrazione.
Miglioramento federato. I dispositivi migliorano collettivamente senza centralizzare i dati grezzi, seguendo i principi federati [23, 24]. L'unità di scambio è il delta dell'adapter: un partecipante addestra o raffina localmente un adapter specialistico (Sezione 9), e solo i parametri a basso rango — opzionalmente con rumore a tutela della privacy coerente con la pratica federata consolidata [24] — sono condivisi con un punto di aggregazione, che può a sua volta essere un host LAN. Poiché gli adapter sono di ordini di grandezza più piccoli dei modelli base, il costo di comunicazione è modesto, riecheggiando la motivazione di efficienza comunicativa del federated averaging [23]. Gli adapter aggregati sono ridistribuiti tramite il registro con il pinning della versione.
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. Topologia federata. I dati grezzi rimangono nel livello on-device; solo i delta degli adapter attraversano i livelli per il miglioramento, e solo richieste redatte e soggette a politica raggiungono le API esterne.
La capa di specializzazione gira in modo continuo, assemblando materiale di alta qualità distillato dai modelli di frontiera e alimentandolo agli adapter specialistici —trasformando l'uso quotidiano in nuova capacità senza cedere il controllo dei dati che la sostengono. La capa è indipendente dal sistema operativo per design: è costruita per sfruttare sistemi operativi eterogenei secondo le rispettive potenzialità, addestrando e servendo su host Linux, macOS e Windows e traendo il meglio da qualunque calcolo sia presente. Combina tecniche miste in un unico ciclo —distillazione, ottimizzazione per preferenze, fine-tuning on-device su Apple Silicon tramite MLX, self-play e simulazione accelerata da CUDA, incluso il training robotico headless in Isaac Lab e la simulazione di trading/strategia. La schedulazione e l'allocazione specifiche tra host sono dettagli interni di implementazione; ciò che conta a livello architetturale è che qualsiasi sistema operativo disponibile può essere arruolato e usato per la capacità che serve meglio.
Molly OS tratta l'utilizzo come fonte di supervisione. Il ciclo ha quattro fasi, descritte in modo astratto:
La conseguenza economica è un gradiente di capacità: i domini che un utente esercita frequentemente migrano verso il basso nella gerarchia dei livelli, aumentando nel tempo la frazione servita localmente e riducendo sia la latenza che l'esposizione esterna.
I risultati di valutazione di ciascun ciclo di specializzazione aggiornano inoltre i prior di capacità per dominio, mantenuti come media mobile pesata esponenzialmente sui punteggi dei compiti tenuti fuori dall'addestramento per ogni target (base, adapter, livello). Questi prior alimentano direttamente le stime di qualità per target del router, cosicché utilizzo, valutazione, prior di capacità e instradamento formano un ciclo chiuso: il traffico fa emergere la domanda di dominio, la valutazione misura gli adapter risultanti, e i prior aggiornati spostano le decisioni di dispatch successive. In particolare, un adapter appena promosso la cui valutazione supera il prior dell'adapter in carica reindirizza immediatamente l'instradamento verso il livello locale senza riconfigurazione manuale. Questo realizza un meccanismo di feedback di instradamento appreso nel senso di [21], basato su capacità misurata anziché prevista.
La capacità multimodale è esposta attraverso la stessa interfaccia e instradata dallo stesso apparato di politiche. I backend di generazione di immagini e audio sono registrati come target con profili di capacità tipizzati per modalità; il router tratta la modalità come un vincolo rigido e applica per il resto lo stesso posizionamento a livelli (modelli di diffusione/sintesi vocale on-device ove fattibile, LAN o remoto altrimenti). Le pipeline cross-modali — es. trascrizione seguita da riassunto — sono composte dal livello di orchestrazione secondo la modalità di composizione modello-come-strumento [47], con ogni fase soggetta in modo indipendente alle regole di residenza. L'invocazione di strumenti e il function calling [43, 44, 45, 46] seguono lo stesso pattern: gli schemi degli strumenti sono profili di capacità, e l'I/O degli strumenti è classificato per sensibilità come qualsiasi altro payload.
Valutiamo se il livello di orchestrazione — selezione di adapter specialistici, instradamento e fusione — migliori la qualità dell'output rispetto al modello base non aumentato. Il protocollo è fisso: una sonda di 115 panel che copre 16 macro-domini (~7 panel ciascuno), valutata 0–100 da un giudice neutrale disgiunto dal processo di addestramento, con parità di decodifica garantita per costruzione. Il design a giudice singolo implica che le cifre per dominio vanno lette come direzionali; il segnale aggregato sui 115 panel è robusto.
Nell'esecuzione completa (115/115 panel), la qualità globale sale da 54,3 a 58,3 (+4,0), con guadagni forti e concentrati nei domini in cui l'addestramento specialistico è più maturo.
Tabella 1 — Base vs. orchestrato, esecuzione completa (115/115).
| Macro-dominio | Base | Orchestrato | Δ |
|---|---|---|---|
| AI / ML | 33,6 | 62,6 | +29,0 |
| Creativo / generativo | 48,7 | 72,0 | +23,3 |
| Audit di sicurezza | 39,7 | 53,0 | +13,3 |
| Finanza | 32,7 | 44,0 | +11,3 |
| Programmazione | 35,0 | 46,0 | +11,0 |
| Ricerca | 52,8 | 57,8 | +5,0 |
| Arti | 58,0 | 60,8 | +2,8 |
| Discipline umanistiche | 60,0 | 62,8 | +2,8 |
| Crescita / marketing | 62,0 | 64,0 | +2,0 |
| Ingegneria | 55,5 | 56,9 | +1,4 |
| Istruzione | 58,0 | 59,2 | +1,2 |
| Medicina | 61,8 | 62,6 | +0,8 |
| Scienza | 57,9 | 57,1 | −0,8 |
| Scienze sociali | 57,2 | 56,0 | −1,2 |
| Business | 59,8 | 57,0 | −2,8 |
| Globale | 54,3 | 58,3 | +4,0 |
Il livello di orchestrazione produce ampi incrementi in AI/ML (+29,0) e nel lavoro creativo/generativo (+23,3), con miglioramenti a doppia cifra in audit di sicurezza, finanza e programmazione. La manciata di domini vicini alla parità sono le coorti di specialisti integrate più di recente, ancora in fase di completamento dell'addestramento — un ordinamento di maturità della coorte, non un tetto del metodo. Coerentemente con il trasferimento di capacità basato su distillazione in modelli compatti [34], la specializzazione tramite adapter è il principale fattore dell'incremento, con l'instradamento che seleziona lo specialista appropriato.
La qualità si compone man mano che l'addestramento specialistico matura. La qualità atomica assoluta è salita da 41 a 54 nell'arco di mesi di addestramento continuo. I domini con i guadagni maggiori sono quelli i cui specialisti sono entrati prima in addestramento; i domini più nuovi seguono già la stessa curva ascendente. Sulla stessa sonda, un modello base più grande raggiunge ~66 — comportamento coerente a scala maggiore, a indicare che l'approccio regge al crescere della capacità del modello.
L'orchestrazione adattiva all'hardware è il design centrale del sistema e il principale fattore di questi risultati. Il miglioramento non deriva da un singolo modello più grande, ma dal selezionare e comporre gli adapter specialistici e gli strumenti giusti per ogni compito, sotto un coordinatore che si adatta all'hardware disponibile — scegliendo la scala della base e l'insieme di specialisti residenti per il dispositivo in uso. La valutazione conferma che è questo livello di composizione, e non la dimensione bruta del modello, a spiegare i guadagni misurati.
Questa sezione delimita le condizioni in cui valgono i nostri risultati e segnala le considerazioni che un professionista dovrebbe soppesare nel generalizzarli. Ogni punto è circoscritto e dispone di una mitigazione esistente.
Metodologia di valutazione. Le cifre di qualità in §10 usano un giudice LLM neutrale della classe Claude Haiku, tenuto fuori dall'addestramento. È prassi standard e ampiamente adottata per la valutazione LLM-as-judge [22], e quella famiglia di modelli è ben riconosciuta per questo ruolo. L'aggregato sui 115 panel è robusto; i valori per dominio si leggono come direzionali data la minore numerosità per macro. Le tornate multi-giudice e adjudicate da umani sono un'estensione pianificata che affinerà la risoluzione per dominio.
Base scientifica verificabile. Tutti i riferimenti citati sono verificati contro l'API di arXiv, con link ufficiali di sede per i due lavori non-arXiv, così che il fondamento scientifico di questo articolo sia direttamente controllabile.
Calibrazione del router. Le stime di qualità sono apprese dalle tracce storiche, quindi lo spostamento di distribuzione nei carichi può influire sull'accuratezza dell'instradamento, e i router appresi riflettono i dati di preferenza su cui sono addestrati [21]. Lo limitiamo con ricalibrazione periodica su tracce fresche; le cascate aggiungono latenza solo sul sottoinsieme di richieste in escalation.
Interferenza e deriva degli adapter. La specializzazione continua comporta un rischio di regressione su input fuori dominio. I nostri gate di promozione lo prevengono esplicitamente richiedendo un miglioramento misurato prima del deployment, e il pinning della versione degli adapter offre una via controllata per coordinare gli aggiornamenti del modello base.
Assunzioni federate. Lo scambio di delta degli adapter riduce sostanzialmente la superficie di leakage rispetto alla condivisione di dati grezzi o di gradienti completi. Gli attacchi di inferenza a livello di aggiornamento studiati nella letteratura federata [24] restano in ambito, e una contabilizzazione formale della privacy (es. un budget di privacy differenziale sui delta) è uno strato naturale sopra il design attuale.
Generalità tra architetture. I risultati sono stabiliti per i modelli base e le configurazioni di quantizzazione valutati. Il trasferimento ad architetture sostanzialmente diverse, inclusi i backend MoE [17, 19], dovrebbe seguire gli stessi meccanismi, ma va confermato empiricamente per ciascun backend.
Validità esterna del carico di lavoro. Le nostre tracce enfatizzano distribuzioni di produzione rappresentative. Le query rare e ad alto rischio —dove le decisioni di escalation contano di più— sono comparativamente infrequenti in tali tracce; set di stress mirati per questi casi sono un complemento utile alla valutazione aggregata.
Negli ultimi anni abbiamo portato avanti un lavoro continuativo di ricerca e sviluppo in quest'area, e il sistema qui descritto riflette lo stato maturo di tale lavoro, non un proof of concept. Chiudiamo collocandolo rispetto a mappe esterne di dove sono diretti i sistemi capaci.
Il position paper From AGI to ASI di Google DeepMind [66] delinea quattro percorsi verso sistemi più capaci, e la nostra architettura si allinea con tutti e quattro:
La stessa direzione è rafforzata da lavori convergenti di grandi laboratori. Magentic-One di Microsoft [67] pone al centro un orchestratore capo che pianifica e delega ad agenti specialisti —la struttura orchestratore-sopra-specialisti che adottiamo in §6. Sistemi multi-agente recenti addestrano un modello condiviso con contesti specialistici isolati sotto coordinamento capo/sotto-agente [68], in eco al nostro design a base condivisa con molti adapter. E la distillazione aperta di capacità di DeepSeek in modelli densi compatti [69] rispecchia il nostro ciclo di distillazione in adapter specialistici. La cronologia del nostro repository e i timestamp di addestramento collocano questo lavoro sulle stesse linee in modo indipendente e contemporaneo a tali sforzi —l'allineamento è documentato, non retrospettivo.
Lo vediamo come conferma, non come aspirazione: i percorsi che il campo nomina in astratto sono quelli lungo cui già costruiamo. La nostra direzione futura è approfondire ciascuno —specialisti più affilati, instradamento più stretto e un ciclo di addestramento più rapido e meglio valutato— mantenendo l'intero sistema sovrano e sotto il controllo dell'utente.
Molly OS dimostra che efficienza del serving, instradamento delle richieste e sovranità dei dati — solitamente studiati separatamente — si compongono in un unico livello di orchestrazione. Le cascate basate sulle capacità [20, 21] si generalizzano naturalmente a domini di fiducia eterogenei; il serving multi-adapter [6, 7] fa sì che un unico modello base locale si comporti come molti specialisti; e lo scambio federato di adapter [23, 24] trasforma una popolazione di dispositivi sovrani in un sistema che migliora collettivamente senza centralizzare i dati grezzi. Il gradiente di capacità risultante — con le competenze usate frequentemente che migrano sul dispositivo — suggerisce una traiettoria di lungo termine in cui l'escalation esterna diventa l'eccezione anziché l'impostazione predefinita. I lavori futuri includono la contabilizzazione formale della privacy per lo scambio di adapter, classificatori di residenza appresi con garanzie verificabili e un'integrazione più stretta della decodifica speculativa tra i livelli [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