molly_os_whitepaper_it.md

Molly OS: Un Livello di Orchestrazione dell'Inferenza Indipendente dal Modello per l'Inferenza On-Device e Federata

Daniele Trovato — Core Labs R&D

Abstract

Le moderne implementazioni di modelli linguistici risultano frammentate tra target di esecuzione eterogenei: piccoli modelli on-device, modelli di medie dimensioni su acceleratori nella rete locale, modelli server self-hosted e API di terze parti. Oggi, utenti e applicazioni sono costretti a vincolarsi a un unico backend, il che impone un compromesso sfavorevole tra latenza, capacità, costo e — aspetto cruciale — 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) routing 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 quantized espone numerosi 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 mediante valutazione e distillazione; e (v) generazione multimodale dietro un'unica interfaccia. Descriviamo l'architettura, i sottosistemi di routing e di serving degli adapter e il protocollo federato di miglioramento. In una valutazione che copre circa 100 domini, condotta da un LLM giudice neutrale escluso dal training, l'orchestrazione con adapter specialistici migliora la qualità dell'output rispetto a un modello base non specializzato in tutti i domini — con i guadagni più marcati nei compiti generativi e di AI/ML — dimostrando che un'orchestrazione sovrana e on-device-first è praticabile senza sacrificare la qualità dei task. Le metriche a livello di sistema (accuratezza del routing, latenza end-to-end ed efficienza federata) sono oggetto di misurazioni in corso.

1. Introduzione

Il panorama dell'inferenza per i modelli linguistici di grandi dimensioni (LLM) si è biforcato. A un estremo, modelli con meno di un miliardo o pochi miliardi di parametri girano 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]. All'altro estremo, le capacità di scala frontier restano confinate in servizi remoti accessibili soltanto tramite API di terze parti. Tra questi due poli si collocano i deployment su rete locale: una workstation o un home server che ospita un modello di dimensioni intermedie dietro uno stack di serving efficiente [8, 9].

Questa frammentazione impone due costi distinti. Il primo è la frammentazione delle capacità: nessun singolo backend è il migliore per ogni richiesta. Una semplice ricerca fattuale spreca un modello frontier remoto; un compito di ragionamento multi-step mette in crisi un modello tascabile. I sistemi di routing e a cascata [20, 21, 22] dimostrano che la selezione del modello per singola richiesta migliora la frontiera costo–qualità — ma i router esistenti presuppongono un dominio di fiducia omogeneo, tipicamente un insieme di endpoint cloud. Il secondo è il costo in termini di privacy: l'inferenza esclusivamente in cloud esporta per impostazione predefinita i dati grezzi dell'utente. Il federated learning ha dimostrato che il miglioramento dei modelli non richiede la centralizzazione dei dati grezzi [23, 24]; eppure l'orchestrazione al momento dell'inferenza ha ampiamente trascurato il principio analogo: il posizionamento dell'esecuzione è di per sé una decisione di privacy.

Sosteniamo la necessità di uno strato di orchestrazione sovrano: un unico piano di controllo, di proprietà dell'utente, che media ogni richiesta di inferenza e decide — per singola richiesta, in base a una policy esplicita — se l'esecuzione debba avvenire on-device, sulla rete locale, su un modello remoto self-hosted oppure tramite un'API esterna. Sovranità, in questo design, significa tre cose: il default è locale, l'escalation è vincolata da policy e la residenza dei dati è un vincolo di routing di prima classe, anziché una considerazione a posteriori.

Questo articolo descrive Molly OS, un'implementazione di questo design. Presentiamo i nostri contributi nell'ordine in cui vengono eseguiti a runtime — prima intervengono gli specialisti; l'escalation eterogenea segue solo quando necessario:

1. Serving concorrente di specialisti. Un singolo modello base quantized serve simultaneamente numerosi adapter a basso rango specifici di dominio [1, 2], con gestione hot/cold e caricamento on-demand costruiti sul serving multi-adapter [6, 7] e sulla memoria paginata [8]. Un orchestratore multi-agente in stile CEO seleziona e compone questi specialisti per ogni richiesta, servendoli localmente come percorso predefinito.
2. Routing eterogeneo consapevole di capacità e costi. Quando nessuna corrispondenza con uno specialista risulta sufficiente, il sistema effettua l'escalation attraverso target eterogenei — on-device, LAN, cloud e API esterne — selezionandoli in base al rapporto prezzo/prestazioni in tempo reale e fondendo i risultati. Questo approccio estende il routing consapevole dei costi [20, 21] sotto vincoli espliciti di sovranità dei dati.
3. Una policy di esecuzione sovrana e federata che impone l'elaborazione on-device-first e consente il miglioramento collettivo scambiando delta di adapter anziché dati grezzi, nello spirito del federated averaging [23, 24].
4. Un ciclo di specializzazione continua che converte le tracce di interazione in corpora di addestramento valutati e li distilla in nuovi adapter specialisti [34, 35, 37], chiudendo il ciclo tra utilizzo e capacità.

2. Lavori correlati

Fine-tuning efficiente in termini di parametri. I moduli adapter [3], il prefix-tuning [4], il prompt tuning [5] e l'adattamento a basso rango (LoRA) [1] hanno stabilito che la specializzazione su un compito richiede l'aggiornamento di una piccola frazione soltanto dei parametri di un modello. QLoRA [2] ha esteso questo risultato ai modelli di base quantized, mettendo la specializzazione alla portata dell'hardware di largo consumo. Molly OS adotta adapter in stile LoRA come propria unità di specializzazione proprio perché risultano economici su ogni asse rilevante in questo contesto: addestramento, archiviazione, trasmissione e hot-swapping.

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 di base condiviso, mediante paginazione unificata e kernel batched personalizzati. Molly OS trasferisce queste idee in contesti single-tenant con risorse limitate, dove il vincolo determinante non è il throughput multi-tenant, bensì budget di memoria stringenti e la gestione del ciclo di vita degli adapter.

Serving efficiente. PagedAttention [8], lo scheduling a livello di iterazione di Orca [9], i kernel di attention IO-aware [10] e i sistemi orientati al throughput basati su offloading [11] costituiscono il substrato su cui qualsiasi livello di orchestrazione deve poggiare. Molly OS li considera meccanismi interni al backend e si concentra sul livello sovrastante.

Quantizzazione. I metodi di quantizzazione post-training [12, 13, 15] e la decomposizione a precisione mista [14] rendono praticabile l'inferenza a 4–8 bit con una perdita di qualità contenuta — un prerequisito per i livelli on-device e LAN del nostro progetto.

Mixture-of-Experts e computazione condizionale. Gli esperti a gating sparso [16], gli Switch Transformers [17], GShard [18] e Mixtral [19] attivano sottoinsiemi di parametri per token all'interno di un modello. Molly OS effettua la computazione condizionale tra modelli e adapter a livello di richiesta. I due approcci sono complementari: i modelli MoE si integrano naturalmente come backend.

Routing, 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 in ensemble gli output dei modelli tramite ranking a coppie. Tutti e tre ottimizzano costo e qualità su endpoint cloud. Molly OS generalizza l'insieme dei target a domini di fiducia eterogenei e incorpora i vincoli di sovranità direttamente nell'obiettivo di routing.

Apprendimento federato. Il federated averaging [23] e la più ampia letteratura sul federated learning cross-device [24] hanno stabilito che i modelli possono migliorare senza centralizzare i dati. Molly OS applica lo stesso principio alla granularità degli adapter e lo estende oltre l'addestramento, fino alle decisioni di collocazione in fase di inferenza.

Modelli linguistici on-device e di piccole dimensioni. MobileLLM [25], Phi-3 [26], TinyLlama [27] e i modelli compatti guidati dalla qualità dei dati [29] dimostrano che questa classe di modelli gestisce una frazione significativa dei carichi di lavoro reali; lo streaming dei pesi basato su memoria flash [28] ne attenua ulteriormente i vincoli 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 modelli di grandi dimensioni delegando il calcolo delle bozze a modelli più economici. In Molly OS, i modelli on-device possono fungere da modelli bozza per i target del livello LAN, cosicché la gerarchia di accelerazione si allinea in modo naturale con la gerarchia di collocazione.

Distillazione. La knowledge distillation [34, 35, 36, 37] è alla base del nostro ciclo di specializzazione continua: le tracce validate rispetto a target più potenti diventano segnale di supervisione per specialisti compatti.

Retrieval e strumenti. La retrieval-augmented generation [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, anziché incorporate in esso; in particolare, la scomposizione dei task in stile HuggingGPT [47] rappresenta un chiaro precedente nel trattare i modelli come risorse instradabili.

Posizionamento. I lavori precedenti ottimizzano l'efficienza del serving, la qualità del routing o l'addestramento federato — ciascuno in modo isolato. Molly OS li unifica tutti e tre in un unico livello: serving (multi-adapter, quantized), routing (cascate consapevoli delle capacità e delle policy) e sovranità (collocazione vincolata alla residenza dei dati, miglioramento federato degli adapter).

3. Panoramica del sistema

Molly coordina una superficie operativa concreta. Il suo substrato di calcolo è un cluster con sistemi operativi eterogenei — macchine Linux, macOS e Windows — abbinato a storage locale e a storage remoto/cloud cifrato, e Molly assegna il lavoro a ciascuna macchina in base ai rispettivi punti di forza. Al di sopra di questo substrato orchestra le superfici di lavoro di un'organizzazione come strumenti governati: accessi dei membri del team e chiavi API, con ambito delimitato per singolo membro; pagamenti digitali; trading; un servizio di fatturazione; e assistenza clienti. Non si tratta di prodotti separati aggiunti a posteriori, bensì di funzioni che Molly gestisce direttamente — un unico sistema sovrano che abbraccia tanto l'hardware su cui gira quanto le operazioni che esegue.

Molly OS si colloca tra le applicazioni e un pool eterogeneo di destinazioni di esecuzione. Ogni richiesta entra attraverso un'interfaccia unificata, dove viene annotata con un profilo di capacità (tipo di task, difficoltà attesa, modalità, esigenze di contesto) e un profilo di sovranità (classe di sensibilità dei dati, vincoli di residenza). Il router la instrada quindi verso uno dei quattro livelli di destinazione:

• T0 — On-device: un modello quantized di piccole dimensioni [25, 26, 27] affiancato da adapter specialistici locali; è il livello predefinito.
• T1 — Rete locale (LAN): un modello di medie dimensioni su un acceleratore locale fidato, dietro uno stack di serving efficiente [8, 9, 10].
• T2 — Remoto self-hosted: un modello più grande su infrastruttura remota controllata dall'utente.
• T3 — API esterna: endpoint di terze parti, raggiungibili solo quando la policy lo consente e, di norma, con applicazione di redazione.

I sottosistemi di supporto comprendono l'adapter registry (Sezione 7), il motore di policy (Sezione 8), l'archivio delle tracce con la pipeline di specializzazione (Sezione 9) e i backend multimodali (Sezione 10). Il retrieval [38, 40] e l'esecuzione di strumenti [43, 44] sono mediati dal medesimo livello, il che garantisce che i corpora di retrieval e l'I/O degli strumenti rispettino le stesse regole di residenza degli input del modello.

Figura 1. Architettura di Molly OS. Tutte le richieste passano attraverso un'unica interfaccia; il router seleziona tra quattro livelli di destinazione secondo la policy di sovranità; le tracce alimentano una pipeline di specializzazione che produce nuovi adapter.

4. Routing indipendente dal modello

La selezione del target avviene all'interno di un unico spazio di indirizzamento che comprende l'esecuzione on-device, le macchine LAN e gli endpoint cloud. Anziché vincolarsi a un provider fisso, il router arbitra tra questi target mediante un confronto in tempo reale tra prezzo e prestazioni, ponderando latenza, costo e capacità per ciascuna richiesta.

Formalmente, il router risolve un problema di selezione vincolata per ogni richiesta: scegliere il target (e l'adapter, ove applicabile) che massimizza la qualità attesa nel rispetto dei vincoli di latenza, costo e sovranità. Ciò generalizza il routing costo–qualità [20, 21] lungo due assi: l'insieme dei candidati abbraccia più 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 del compito e il suo grado di difficoltà. Il router mantiene stime di qualità per target e per categoria, calibrate a partire da tracce storiche in modo analogo al routing appreso da dati di preferenza [21]. La disponibilità di adapter modifica queste stime: un modello T0 dotato di un adapter di dominio robusto può classificarsi al di sopra di un modello T1 privo di adattamento in quel dominio.

Cascate e fallback. Seguendo il pattern a cascata [20], il router può tentare dapprima un target economico ed effettuare un'escalation in caso di bassa confidenza. La confidenza è ricavata da segnali rilevati al momento della generazione (ad es. incertezza auto-riportata, punteggi di verificatori) e, quando 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ò effettuare un'escalation T0 → T1, ma mai verso T3. Il fallback gestisce l'indisponibilità del target (ad es. un host LAN che va offline) mediante re-routing all'interno dell'insieme di livelli consentiti.

Cooperazione speculativa. Quando una richiesta approda su T1, il modello T0 può fungere da modello draft per lo speculative decoding [30, 31, 33] — cosicché la gerarchia di collocazione funge al tempo stesso da gerarchia di accelerazione.

Figura 2. Flusso di routing e cascata. La classificazione di sensibilità restringe l'insieme di livelli consentiti prima della selezione basata sulle capacità; gli output a bassa confidenza effettuano l'escalation soltanto all'interno dell'insieme consentito.

Quando la distribuzione di dominio prevista per una richiesta non è nettamente concentrata, il router non è obbligato a vincolarsi a un singolo target. Può invece inviare una miscela ponderata top-k di adapter specialistici, con k e i pesi della miscela derivati dalla distribuzione a posteriori calibrata sul dominio. Gli output candidati risultanti vengono fusi mediante un ranking ponderato per confidenza, secondo l'approccio di output-ensembling di [22]: ciascun candidato è valutato tramite il prodotto tra il suo peso di routing e una stima di qualità per target, e viene restituito l'output con il ranking più alto — oppure una composizione fusa, laddove gli output risultino complementari. L'invio in miscela è soggetto agli stessi vincoli di livello e di budget del routing a target singolo, al costo aggiuntivo della decodifica parallela.

5. Serving Concorrente di Specialisti

Una scelta progettuale centrale deriva da una semplice osservazione: all'edge la specializzazione è più economica della scala. Anziché ospitare molti modelli specializzati, ogni tier ospita un singolo modello base quantized [2, 12, 13] abbinato a una libreria di adapter LoRA [1] — un'unica base espone così molti esperti di dominio.

Esecuzione concorrente. Sulla scia di S-LoRA [6] e Punica [7], il calcolo degli adapter viene eseguito in batch: i pesi del modello base sono condivisi fra tutte le richieste in corso, mentre i delta a basso rango specifici di ciascuna richiesta vengono applicati tramite operazioni matriciali in batch indicizzate in base all'identità dell'adapter. La KV-cache e i pesi degli adapter attingono a un pool di memoria paginata unificato, che estende la gestione in stile PagedAttention [8] alle pagine degli adapter. Lo scheduling a livello di iterazione [9] consente alle richieste dirette ad adapter diversi di entrare e uscire dai batch in modo indipendente, così che carichi di lavoro eterogenei non si serializzino mai l'uno dietro l'altro.

Gestione hot/cold. I budget di memoria all'edge non possono garantire la residenza di ogni adapter. Il registro traccia quindi recenza e frequenza di accesso di ciascun adapter, stratificandoli di conseguenza: gli adapter hot restano fissati nella memoria dell'acceleratore, gli adapter warm risiedono nella memoria host e gli adapter cold vivono sullo storage. Il caricamento on-demand promuove gli adapter al momento della richiesta — e 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, ben al di sotto del 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. Un adapter addestrato su un host T1 può quindi essere ridistribuito a qualsiasi dispositivo T0 che condivida la stessa base — una proprietà di portabilità che sta alla base del meccanismo federato descritto nella Sezione 8.

Figura 3. Serving concorrente di specialisti. Un unico modello base condiviso serve richieste eterogenee di adapter all'interno dello stesso batch; gli adapter migrano tra gli stati hot, warm e cold secondo una politica consapevole dei costi.

6. Orchestrazione degli Agenti

Un orchestratore in stile CEO classifica ogni richiesta in ingresso e la delega agli agenti specialisti appropriati. Attraverso questo harness, le funzioni operative dell'organizzazione — pagamenti, trading, fatturazione, assistenza clienti e accesso dei membri del team — sono esposte come strumenti governati, in modo che la delega si traduca in azioni reali sotto una policy esplicita.

Molte richieste che arrivano al livello di orchestrazione non sono completamenti single-shot, bensì compiti compositi che premiano una decomposizione esplicita: una query può estendersi su più domini, richiedere invocazioni intermedie di strumenti o esigere la verifica di output preliminari internamente incoerenti. Estendiamo pertanto il percorso di serving della Sezione 5 con una modalità di orchestrazione degli agenti, attivata ogni volta che 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 tier e un budget per singolo sottocompito. Il piano viene ammesso solo dopo aver superato un gate di policy/budget che applica gli stessi vincoli di sovranità e di tier imposti alle richieste singole (Sezione 4); in particolare, ogni invocazione di uno specialista è vincolata al tier meno esposto consentito per la classificazione dei dati del relativo sottocompito. Il design segue il paradigma reasoning–acting [44] e tratta gli specialisti in modo analogo agli strumenti [43, 45, 46, 47], inclusa la visione di composizione model-as-tool di [47] — ma con una differenza cruciale: tutta la delega è vincolata attraverso il motore di policy a livello dell'intero deployment, anziché essere lasciata a decisioni libere degli agenti, in contrasto con i framework conversazionali aperti [49, 50, 51].

Specialisti. Ogni specialista abbina un modello base a un adapter di dominio proveniente dalla pipeline di specializzazione continua (Sezione 5). I sottocompiti privi di interdipendenze nel piano di delega vengono eseguiti in parallelo; i sottocompiti dipendenti seguono un'esecuzione sequenziale in stile least-to-most [60]. Internamente, gli specialisti possono impiegare prompting di tipo chain-of-thought [57] o esecuzione program-aided per sottocompiti computazionali [48], e le tracce di ragionamento ottenute per bootstrapping [55] vengono conservate come segnale di addestramento candidato per la pipeline di specializzazione.

Fusione. Una fase 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 self-consistency [58]; quando gli output sono complementari, la fusione li compone secondo lo schema tipizzato del piano. Questa integrazione strutturata multi-candidato è affine alla ricerca deliberata su pensieri [59, 61], con una restrizione intenzionale: la struttura di ramificazione è fissata dal piano di delega anziché essere espansa dinamicamente.

Meta-cognizione. Prima che una risposta venga emessa, una fase di meta-cognizione verifica l'output fuso quanto a coerenza interna, copertura della richiesta originale e conformità alle policy. In caso di fallimento, attiva un raffinamento limitato — invocando nuovamente specifici specialisti con feedback critico — secondo approcci di self-reflection e raffinamento iterativo [53, 54] e di critica interattiva con strumenti [56]. Il disaccordo tra specialisti può inoltre emergere sotto forma di un round di arbitrato in stile dibattito, un meccanismo che si è dimostrato in grado di migliorare la fattualità [52]. La profondità del raffinamento è limitata dal budget residuo del controller; in caso di esaurimento, il sistema restituisce l'output fuso meglio classificato con un'annotazione di incertezza allegata.

Valutiamo l'orchestrazione su benchmark e harness standard per agenti, che coprono la valutazione agentica generale [62], ambienti web realistici [63], compiti software a livello di repository [64] e uso di API con strumenti [65]; la quantificazione del guadagno di qualità rispetto al baseline a singolo specialista e dell'overhead di latenza aggiunto fa parte di misurazioni in corso.

Figura 5. Orchestrazione degli agenti. Il controller emette un piano di delega sotto un gate esplicito di policy/budget; gli specialisti di dominio eseguono in parallelo sul tier meno esposto consentito; la fusione classifica e integra gli output; la meta-cognizione valida la coerenza e può attivare un raffinamento limitato.

7. Esecuzione Sovrana e Federata

L'autocustodia è preservata in tutto il cluster eterogeneo di sistemi operativi: dati, adapter ed embedding non lasciano mai le macchine Linux, macOS e Windows dell'utente. Durante lo scambio federato, soltanto i delta degli adapter — mai i dati grezzi — attraversano il confine.

Politica on-device-first. Il motore di policy assegna a ogni richiesta una classe di sensibilità derivata da segnali di contenuto e da regole dichiarate dall'utente. La classe predefinita confina l'esecuzione a T0/T1. L'escalation a T2 è consentita solo quando l'infrastruttura remota è sotto il controllo dell'utente; l'escalation a T3 richiede un'autorizzazione esplicita della policy e attiva trasformazioni di redazione che rimuovono i segmenti sensibili identificati prima che qualsiasi contenuto venga trasmesso. Il retrieval segue la stessa disciplina: i corpora personali sono indicizzati e interrogati on-device o sulla LAN [38, 40] — local-first per costruzione — e non vengono mai inviati a T3.

Residenza dei dati come vincolo di routing. La residenza è applicata in modo strutturale — il router non è in grado di emettere un dispatch che violi l'insieme dei tier — anziché tramite filtraggio a posteriori. La proprietà di privacy diventa così verificabile nello strato di orchestrazione stesso, e non semplicemente asserita a cose fatte.

Miglioramento federato. I dispositivi migliorano collettivamente senza mai centralizzare i dati grezzi, in linea con 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 — eventualmente arricchiti con rumore a tutela della privacy, in conformità con la prassi federata consolidata [24] — vengono condivisi con un punto di aggregazione, che può a sua volta essere un host sulla LAN. Poiché gli adapter sono di ordini di grandezza più piccoli dei modelli di base, il costo di comunicazione rimane contenuto, riprendendo la motivazione di efficienza comunicativa alla base del federated averaging [23]. Gli adapter aggregati rifluiscono poi attraverso il registro con version pinning.

Figura 4. Topologia federata. I dati grezzi rimangono nel tier on-device; solo i delta degli adapter attraversano i tier ai fini del miglioramento, e solo richieste redatte e sottoposte a controllo di policy raggiungono le API esterne.

8. Specializzazione Continua

Il livello di specializzazione non smette mai di lavorare. Opera in modo continuo, distillando materiale di alta qualità dai modelli di frontiera e riversandolo negli adapter specialistici — convertendo l'uso quotidiano in nuove capacità senza mai cedere il controllo dei dati sottostanti. Il livello è per progettazione agnostico rispetto al sistema operativo: sfrutta sistemi operativi eterogenei per i rispettivi punti di forza, addestrando ed erogando su host Linux, macOS e Windows e traendo il massimo da qualunque risorsa di calcolo disponibile. Un unico ciclo combina tecniche miste — distillazione, ottimizzazione delle preferenze, fine-tuning on-device su Apple Silicon tramite MLX, self-play e simulazione accelerata via CUDA, inclusi l'addestramento robotico headless in Isaac Lab e la simulazione di trading/strategie. La pianificazione e il posizionamento tra gli host restano dettagli implementativi interni; ciò che conta dal punto di vista architetturale è che qualsiasi sistema operativo disponibile possa essere arruolato e messo al lavoro sulla capacità che sa servire meglio.

Molly OS tratta l'uso stesso come fonte di supervisione. Il ciclo si articola in quattro fasi, descritte in termini astratti:

1. Cattura delle tracce. Con il consenso dell'utente, le richieste, i target di instradamento, le risposte e i segnali di qualità (eventi di escalation, modifiche, feedback esplicito) vengono registrati nell'archivio locale delle tracce.
2. Curatela e valutazione. Le tracce vengono raggruppate per dominio e le coppie candidate all'addestramento vengono filtrate in base ai segnali di qualità. Laddove la risposta accettata sia stata prodotta da un modello di livello superiore, la coppia costituisce supervisione da parte del teacher nel senso classico della distillazione [34, 35].
3. Addestramento degli adapter. Un adapter LoRA [1, 2] nuovo o aggiornato viene addestrato localmente (o sul livello LAN) sul corpus curato, sfruttando facoltativamente indizi provenienti dalle rappresentazioni intermedie quando teacher e student condividono la stessa discendenza architetturale [36]; la strategia dello student compatto segue la linea dei modelli distillati come DistilBERT [37].
4. Validazione e promozione. Gli adapter candidati vengono valutati su probe di dominio tenute fuori dal training. Un adapter viene promosso nel registro solo se migliora la qualità del dominio di almeno un margine prestabilito senza regredire sulle probe generali oltre un contenuto budget di regressione.

La conseguenza economica è un gradiente di capacità: i domini che un utente esercita di frequente migrano verso il basso lungo la gerarchia dei livelli, aumentando costantemente la frazione di richieste servite localmente e riducendo al contempo la latenza e l'esposizione verso l'esterno.

Ogni ciclo di specializzazione aggiorna inoltre i prior di capacità per dominio, mantenuti come media mobile a ponderazione esponenziale sui punteggi dei task tenuti fuori dal training per ciascun target (base, adapter, livello). Questi prior alimentano direttamente le stime di qualità per target del router, chiudendo il ciclo tra utilizzo, valutazione, prior di capacità e instradamento: il traffico fa emergere la domanda di dominio, la valutazione misura gli adapter risultanti e i prior aggiornati modificano le successive decisioni di dispatch. In particolare, un adapter appena promosso la cui valutazione superi il prior del titolare in carica reindirizza immediatamente l'instradamento verso il livello locale — senza alcuna riconfigurazione manuale. Il risultato è un meccanismo di feedback di learned-routing nel senso di [21], fondato su capacità misurate anziché previste.

9. Generazione Multimodale

La capacità multimodale non richiede alcuna interfaccia separata: è esposta attraverso la medesima superficie ed è instradata dallo stesso apparato di policy del resto del sistema. I backend di generazione di immagini e audio si registrano come target dotati di profili di capacità tipizzati per modalità; il router tratta la modalità come un vincolo rigido e, al di là di questo, applica la stessa logica di collocazione a livelli — modelli di diffusione e di sintesi vocale on-device ove possibile, LAN o remoti in caso contrario. Le pipeline cross-modali — ad esempio, trascrizione seguita da riassunto — vengono assemblate dal livello di orchestrazione secondo il paradigma della composizione model-as-tool [47], con ciascuno stadio soggetto in modo indipendente alle regole di residenza dei dati. L'invocazione dei tool e il function calling [43, 44, 45, 46] seguono lo stesso schema: gli schemi dei tool non sono altro che profili di capacità, e gli I/O dei tool vengono classificati per sensibilità al pari di qualsiasi altro payload. Il risultato è un sistema in cui le nuove modalità ereditano l'intero stack di routing, collocazione e governance per costruzione, anziché tramite integrazioni ad hoc.

10. Valutazione

Valutiamo una singola domanda: il livello di orchestrazione — selezione degli adapter specialistici, instradamento e fusione — migliora in modo misurabile la qualità dell'output rispetto al modello base non aumentato? Il protocollo è fisso e mantenuto costante per l'intera durata: una sonda di 115 pannelli che coprono 16 macro-domini (~7 pannelli ciascuno), ognuno valutato da 0 a 100 da un giudice neutrale, estraneo al processo di addestramento, con parità di decodifica garantita per costruzione. Poiché il disegno sperimentale impiega un unico giudice, i valori per singolo dominio vanno letti come indicativi; il segnale aggregato sui 115 pannelli, tuttavia, è robusto.

10.1 Incremento di qualità per dominio

Sull'intera esecuzione (115/115 pannelli), la qualità complessiva sale da 54,3 a 58,3 (+4,0) — con guadagni non dispersi in modo uniforme, bensì concentrati esattamente dove l'addestramento specialistico è più maturo.

Table 1 — Base vs. orchestrated, complete run (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
Coding	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
Growth / 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
Scienze	57.9	57.1	−0.8
Scienze sociali	57.2	56.0	−1.2
Business	59.8	57.0	−2.8
Complessivo	54.3	58.3	+4.0

Il pattern è inequivocabile. Il livello di orchestrazione produce incrementi notevoli in AI/ML (+29.0) e nel lavoro creativo/generativo (+23.3), con miglioramenti a due cifre nell'audit di sicurezza, nella finanza e nel coding. La manciata di domini prossimi alla parità corrisponde esattamente alle coorti di specialisti integrate più di recente, il cui addestramento è tuttora in via di completamento — ciò che la tabella evidenzia è un ordinamento di maturità all'interno della coorte, non un limite superiore del metodo. In coerenza con il trasferimento di capacità basato su distillazione verso modelli compatti [34], la specializzazione degli adapter è il fattore primario dell'incremento, mentre il router svolge il proprio compito: selezionare lo specialista appropriato.

10.2 Maturità dell'addestramento e traiettoria

La qualità si accumula man mano che l'addestramento specialistico matura. La qualità atomica assoluta è salita da 41 a 54 nell'arco di mesi di addestramento continuo, e la traiettoria è leggibile nelle classifiche per dominio: i domini con i guadagni più marcati sono esattamente quelli i cui specialisti sono entrati per primi in addestramento, mentre i domini più recenti stanno già percorrendo la stessa curva ascendente. Sulla stessa sonda, un modello base di dimensioni maggiori raggiunge ~66 — lo stesso comportamento riprodotto su scala più ampia, a indicare che l'approccio regge al crescere della capacità del modello.

10.3 L'orchestrazione adattiva all'hardware è il progetto centrale

L'orchestrazione adattiva all'hardware è il progetto centrale del sistema e il fattore primario di questi risultati. Il miglioramento non deriva da un singolo modello più grande. Deriva dalla selezione e dalla composizione degli adapter specialistici e degli strumenti giusti per ciascun compito, sotto un coordinatore che si adatta all'hardware disponibile — scegliendo la scala del modello base e l'insieme di specialisti residenti per il dispositivo in uso. La valutazione conferma la tesi: è questo livello di composizione, non la dimensione grezza del modello, a spiegare i guadagni misurati.

11. Limitazioni e minacce alla validità

Questa sezione delimita le condizioni entro cui i nostri risultati sono validi e segnala le considerazioni che un professionista dovrebbe ponderare prima di generalizzarli. Ciascun punto elencato di seguito è circoscritto nella sua portata e associato a una mitigazione già in essere.

Metodologia di valutazione. I dati di qualità riportati nel §10 si basano su un giudice LLM neutrale della classe Claude Haiku, escluso dall'addestramento. Si tratta del protocollo standard, ampiamente adottato, per la valutazione LLM-as-judge [22], e la famiglia del giudice gode di buona reputazione in questo ruolo. L'aggregato di 115 pannelli è robusto; i dati per dominio vanno letti come indicativi, date le dimensioni campionarie più ridotte per ciascuna macro. Cicli di valutazione con più giudici e con arbitrato umano costituiscono un'estensione pianificata che affinerà la risoluzione per dominio.

Base scientifica verificabile. Ogni riferimento citato è verificato rispetto all'API di arXiv, con link alle sedi di pubblicazione ufficiali per i due lavori non presenti su arXiv — il fondamento scientifico di questo lavoro è quindi direttamente verificabile.

Calibrazione del router. Le stime di qualità sono apprese da tracce storiche, per cui un cambiamento nella distribuzione del carico di lavoro può degradare l'accuratezza dell'instradamento, e i router appresi riflettono inevitabilmente i dati di preferenza su cui sono stati addestrati [21]. Limitiamo questo rischio mediante una ricalibrazione periodica su tracce recenti; le cascate comportano latenza aggiuntiva soltanto sul sottoinsieme delle richieste sottoposte a escalation.

Interferenza e deriva degli adapter. La specializzazione continua comporta un rischio intrinseco di regressione su input fuori dominio. I nostri gate di promozione proteggono esplicitamente da questo rischio, richiedendo un miglioramento misurato prima di qualsiasi deployment, mentre il version pinning degli adapter offre un percorso controllato per coordinare gli aggiornamenti del modello base.

Assunzioni federate. Lo scambio dei 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 sul federated learning [24] restano tuttavia nel perimetro di rischio, e una contabilizzazione formale della privacy — ad esempio un budget di differential privacy sui delta — costituisce un naturale livello aggiuntivo rispetto al design attuale.

Generalità tra architetture. I nostri risultati sono stabiliti per i modelli base e le configurazioni di quantizzazione valutati. Ci si attende che il trasferimento ad architetture sostanzialmente diverse, inclusi i backend MoE [17, 19], segua gli stessi meccanismi, ma andrebbe confermato empiricamente per ciascun backend.

Validità esterna del carico di lavoro. Le nostre tracce privilegiano distribuzioni di produzione rappresentative. Le query rare e ad alto rischio — proprio quelle in cui le decisioni di escalation contano di più — sono comparativamente infrequenti in tali tracce; insiemi di stress test mirati a questi casi costituiscono un utile complemento alla valutazione aggregata.

12. Prospettive

Il sistema qui descritto non è un proof of concept. È il risultato maturo di diversi anni di ricerca e sviluppo continuativi, e concludiamo collocandolo rispetto alle mappe esterne che indicano la direzione verso cui si stanno muovendo i sistemi ad alta capacità.

Il documento From AGI to ASI di Google DeepMind [66] identifica quattro percorsi verso sistemi più capaci. La nostra architettura è allineata con tutti e quattro:

1. Scalabilità. Utilizziamo modelli di frontiera su larga scala in modo pragmatico — come insegnanti e come bersagli di escalation — senza considerare la scala pura come l'unica leva.
2. Cambio di paradigma. Il nostro cambio di paradigma è l'orchestrazione anziché la scalabilità: comporre molti specialisti sotto un orchestratore multi-agente invece di ingrandire un singolo monolite.
3. Auto-miglioramento ricorsivo. Il ciclo di distillazione e addestramento di 24 ore è una forma concreta e delimitata di auto-miglioramento ricorsivo, che converte l'utilizzo in nuovi adapter specialistici su base giornaliera.
4. Collettivi multi-agente. L'harness in stile CEO è un collettivo multi-agente funzionante, che delega ad agenti specialisti secondo una policy esplicita.

Il lavoro convergente dei principali laboratori indica la stessa direzione. Magentic-One di Microsoft [67] pone al centro un orchestratore principale che pianifica e delega ad agenti specialisti — esattamente la struttura orchestratore-sopra-specialisti che adottiamo nel §6. Recenti sistemi multi-agente addestrano un modello condiviso con contesti specialistici isolati sotto coordinamento lead/sub-agent [68], riecheggiando il nostro design a base condivisa con molti adapter. E la distillazione aperta di capacità in modelli densi compatti di DeepSeek [69] rispecchia il nostro ciclo di distillazione in adapter specialistici. La cronologia del nostro repository e i timestamp di addestramento mostrano che questo lavoro è proceduto lungo le stesse direttrici, in modo indipendente e contemporaneo rispetto a tali iniziative — l'allineamento è documentato, non retrospettivo.

Leggiamo questa convergenza come una conferma, non come un'aspirazione: i percorsi che il settore nomina in astratto sono quelli lungo i quali già costruiamo. La strada davanti a noi consiste nell'approfondire ciascuno di essi — specialisti più precisi, un routing più rigoroso e un ciclo di addestramento più rapido e meglio valutato — mantenendo l'intero sistema sovrano e sotto il controllo dell'utente.

13. Conclusione

Molly OS dimostra che l'efficienza di serving, l'instradamento delle richieste e la sovranità dei dati — tre problematiche tradizionalmente studiate in modo isolato — si integrano armoniosamente in un unico livello di orchestrazione. Le cascate basate sulle capacità [20, 21] si generalizzano in modo naturale a domini di fiducia eterogenei; il serving multi-adapter [6, 7] consente a un singolo modello base locale di operare come una molteplicità di specialisti; e lo scambio federato di adapter [23, 24] trasforma una popolazione di dispositivi sovrani in un sistema che migliora collettivamente senza mai centralizzare i dati grezzi. Il gradiente di capacità che ne risulta — con le competenze esercitate più di frequente che migrano on-device — delinea una traiettoria di lungo periodo in cui l'escalation esterna diventa l'eccezione anziché la regola. Tra gli sviluppi futuri figurano una contabilizzazione formale della privacy per lo scambio di adapter, classificatori di residenza appresi con garanzie verificabili e un'integrazione più stretta del decoding speculativo tra i diversi tier [30, 33].

References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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