Chi oggi porta un’automazione AI-powered in azienda si trova di fronte a una scelta architetturale che, fino a un anno fa, semplicemente non esisteva. La strada era fondamentalmente una sola: prendere il modello più grande disponibile e utilizzarlo solo lì dove l’ingente spesa da sostenere risultasse sostenibile. Le architetture agentiche e il Mixture-of-Experts (MoE) hanno spezzato questa linearità, permettendo di ottenere prestazioni elevate con modelli dai costi contenuti.
La prima strategia di ottimizzazione è l’orchestrazione esterna, ossia un modello piccolo, leggero e specializzato nel coordinamento, che decide quale strumento o quale modello verticalizzato invocare per ciascun passaggio di un compito complesso. La seconda è il MoE interno: un singolo modello enorme che, però, attiva soltanto una piccola porzione dei propri parametri per ogni token generato, riducendo il costo computazionale senza rinunciare alla capacità complessiva.
Scegliere l’architettura adatta a uno specifico contesto operativo è un compito estremamente verticale. È necessario conoscere punti di forza e debolezze di entrambe le architetture e adattare queste valutazioni al tipo di automazione che si deve attivare, alle eventuali modalità di training e ai dati che si hanno a disposizione.
Indice degli argomenti:
L’efficienza delle architetture agentiche orchestrate
I modelli di frontiera utilizzati come attori unici di un’automazione sono l’equivalente computazionale di un manager che non delega mai. La grande capacità di astrazione e generalizzazione dei modelli molto grandi risulta sprecata in tanti scenari operativi. Alcuni compiti possono essere risolti da modelli specializzati in minor tempo e con una frazione del costo computazionale richiesto da reti neurali di grandi dimensioni.
Il risultato pubblicato da Nvidia Research con il framework ToolOrchestra ha dimostrato chiaramente l’efficacia dell’approccio specialistico. I ricercatori hanno addestrato un orchestratore da soli 8 miliardi di parametri che, sul benchmark Humanity’s Last Exam ha superato modelli monolitici del calibro di GPT-5, che si era fermato al 35,1%, spendendo circa il 70% in meno.
ToolOrchestra affronta il problema dell’ottimizzazione addestrando un modello dedicato esclusivamente al routing, ottimizzato con il reinforcement learning. L’intelligenza artificiale è in grado di autovalutarsi basandosi su tre parametri: l’accuratezza del risultato (il compito è stato risolto?), l’efficienza (quanto è costato e quanto tempo ha richiesto?) e l’aderenza alle preferenze dell’utente (se l’utente ha indicato di preferire certi strumenti, il sistema li ha rispettati?).
La chiave per la riuscita di un sistema orchestrato è la distribuzione bilanciata del carico di lavoro e ottenere questo bilanciamento non è costoso; infatti, il training dell’orchestratore Nvidia ha richiesto soltanto 552 problemi sintetici e 1.296 prompt. Questo significa che un team MLOps interno, con competenze adeguate, può replicare l’approccio e addestrare un orchestratore personalizzato per i propri workload specifici, scegliendo il modello base e i tool che preferisce.
Mixture-of-Experts: il routing dentro il modello
Le architetture Mixture-of-Experts portano l’intelligenza di routing dentro al modello, al livello più basso possibile: la singola operazione di inferenza su un token. In un Transformer tradizionale, ogni token attraversa tutti i parametri del modello: ogni layer di attenzione, ogni rete feed-forward. In un’architettura MoE, i layer feed-forward vengono sostituiti da una batteria di esperti (sottoreti specializzate) e da un router interno (il gate) che decide quali esperti attivare. Gli esperti non attivati restano spenti, senza consumare risorse di calcolo.
DeepSeek V3, ancora oggi tra i modelli open-weight più performanti, è l’esempio canonico. Ha 671 miliardi di parametri totali, ma per ogni token ne attiva soltanto 37 miliardi, circa il 5,5%. Ogni layer MoE contiene un esperto condiviso, attivato per tutti i token e dedicato alla conoscenza comune, più 256 esperti instradati, dei quali ne vengono selezionati 8 per token. Il modello è stato pre-addestrato su 14,8 trilioni di token su GPU H800, una cifra che lo rende uno dei modelli più economici da addestrare nella sua fascia di prestazioni.
Qwen3 segue la stessa filosofia, con 235 miliardi di parametri totali e 22 miliardi attivi per token. GPT-5 stesso utilizza un’architettura sparsa, anche se OpenAI non ha mai rilasciato i dettagli tecnici completi. In pratica, tre dei modelli di frontiera più utilizzati sono tutti, in misura diversa, architetture MoE.
Confronto diretto: orchestrazione esterna vs routing interno
A questo punto è utile mettere i due paradigmi fianco a fianco, concentrandosi sulle variabili che contano per prendere decisioni informate. Non è possibile stabilire a priori quale sia l’approccio migliore, ma si può capire in quali contesti ciascun approccio eccelle e dove invece dimostra i propri limiti.
Costo per query. Le architetture Mixture-of-Experts riducono il costo a livello della singola inferenza: poiché solo una frazione dei parametri è attiva, il calcolo per token è proporzionalmente inferiore. L’orchestrazione esterna, invece, riduce il costo a livello di sistema, non di singola chiamata. Scegliendo il modello giusto per ciascun sotto-task, evita di invocare il modello più costoso quando uno specialista economico è sufficiente. Su Tau Bench, Orchestrator-8B ha risolto i compiti al 30% del costo di GPT-5 usato da solo. I due meccanismi di ottimizzazione operano a livelli diversi e possono sovrapporsi.
Latenza. Un modello MoE esegue l’inferenza in un singolo forward pass. Il routing tra gli esperti avviene all’interno della GPU, con latenze nell’ordine dei microsecondi per la gating function. Un sistema orchestrato, invece, introduce latenza multi-turno, con tempi di rete, serializzazione e deserializzazione. Questa latenza, però, non è decisiva in alcuni contesti: infatti, il giá citato Orchestrator-8B impiega in media 8,2 minuti per risolvere un problema su Humanity’s Last Exam, meno della metà di GPT-5 usato monoliticamente, perché sceglie strumenti più rapidi. Per i workload in tempo reale, però, la latenza dell’orchestrazione rimane un vincolo strutturale.
Vendor lock-in. Un modello MoE è un singolo artefatto software legato al suo provider. Usare DeepSeek, ad esempio, significa dipendere dall’infrastruttura e dalle API di DeepSeek, e usare GPT-5 significa dipendere da OpenAI. Se il fornitore cambia i prezzi, modifica i termini di servizio o interrompe il supporto per una versione, l’azienda subisce l’impatto direttamente. Un sistema orchestrato è strutturalmente agnostico rispetto ai modelli sottostanti. Se un modello diventa troppo costoso o viene deprecato, l’orchestratore può sostituirlo con un altro senza dover riprogettare l’intera pipeline. ToolOrchestra ha dimostrato questa flessibilità in modo esplicito: durante la valutazione, i ricercatori hanno sostituito i modelli di training con modelli mai visti prima dall’AI e il sistema ha continuato a funzionare, mantenendo il miglior trade-off tra prestazioni e costo.
Adattabilità a task nuovi. L’orchestratore, per definizione, non esegue il compito, ma coordina chi lo esegue. Quando emerge un nuovo dominio o un nuovo tipo di task, è sufficiente aggiungere un nuovo strumento o un nuovo modello specializzato al toolkit, senza dover riaddestrare l’orchestratore, che ha già imparato a generalizzare a strumenti sconosciuti. Un modello MoE, invece, codifica la propria conoscenza nei pesi degli esperti; di conseguenza, per adattarsi a un nuovo dominio occorre tipicamente un fine-tuning o un re-training, con costi e tempi significativi. Per i domini già coperti dal training, il MoE offre risposte immediate senza alcuna configurazione aggiuntiva.
Complessità operativa. Un modello MoE è un singolo deployment, con un endpoint, un modello, un set di pesi. La complessità del routing è incapsulata nel modello stesso e non richiede gestione esterna. Un sistema orchestrato prevede invece la gestione di più servizi, più API, più modelli, più versioni. Ogni strumento nel toolkit è un potenziale punto di guasto. Le competenze MLOps richieste sono proporzionalmente più alte: non basta saper chiamare un’API, ma bisogna saper monitorare, bilanciare e aggiornare un’intera costellazione di servizi.
Per un’azienda con un team AI piccolo, questo overhead operativo può essere un fattore decisivo.
Quando conviene ciascun approccio: scenari d’uso aziendali
Le architetture MoE sono una scelta naturale quando il profilo di lavoro è omogeneo, ad alto volume e a bassa variabilità. Un buon esempio applicativo può essere un chatbot di assistenza clienti che gestisce migliaia di conversazioni al giorno su un dominio circoscritto. Il modello riceve testi simili, produce risposte simili, e ciò che conta è minimizzare il costo per token e la latenza di risposta. Lo stesso vale per la classificazione automatica di documenti o la generazione di testi commerciali standard.
In tutti questi casi, la forza del MoE sta nell’efficienza del singolo forward pass, con bassa latenza, costi controllabili e complessità operativa minima.
L’orchestrazione esterna diventa superiore quando la pipeline è complessa, multi-step e coinvolge strumenti eterogenei. L’esempio più immediato è l’analisi documentale approfondita, nella quale l’intelligenza artificiale deve leggere documenti in formati variabili, verificare clausole basandosi su knowledge base, controllare dati finanziari citati nel testo, generare una sintesi critica e formattare il tutto in un report. Nessun singolo modello, per quanto grande, esegue tutti questi passaggi in modo ottimale. Un orchestratore sceglie lo strumento giusto per ogni fase, negoziando il compromesso tra qualità, costo e tempo in modo dinamico. Due diligence, audit di conformità, ricerca scientifica assistita, pipeline di data engineering con validazione, sono tutti scenari in cui la qualità complessiva dipende non dalle abilità di un singolo modello, ma dalla capacità di coordinare specialisti diversi.
Rendere questa scelta binaria però è una semplificazione eccessiva. I due paradigmi non si escludono a vicenda. Nulla impedisce di usare un modello MoE come uno dei tool nel toolkit dell’orchestratore, anzi, questo è esattamente ciò che fa il framework ToolOrchestra di Nvidia. L’orchestratore decide quando invocarli, per quali sotto-task e quanto budget allocare a ciascuno. In questo scenario ibrido, il MoE fornisce l’efficienza computazionale sulla singola inferenza, l’orchestratore fornisce l’intelligenza di routing a livello di sistema. I due livelli di ottimizzazione si sommano.
La decisione operativa
Per chi deve decidere quale architettura adottare, o in quale combinazione, è necessario tenere conto di tutti i fattori discussi nel confronto diretto. Oltre agli aspetti puramente pragmatici, bisogna anche tener contro delle necessità di auditabilità e controllo sulle decisioni di routing. Un sistema orchestrato produce un log esplicito di ogni decisione, che spiega quale strumento è stato invocato, per quale ragione e con quale costo.
Questo è fondamentale in settori regolamentati, dove ogni decisione deve essere tracciabile e spiegabile. Un modello MoE, pur avendo un router interno, non espone le proprie decisioni di routing in modo facilmente interpretabile. Quali esperti sono stati attivati per un dato token è un’informazione che vive all’interno del modello e non è progettata per essere letta facilmente da un auditor esterno.
Conclusioni
Lo stato dell’arte si muove a velocità incredibili e l’evoluzione di architetture e modelli è ancora in piena fase espansionistica. Qualsiasi scelta architetturale va rivalutata su base regolare, confrontando costi e prestazioni reali. Inoltre, bisogna tenere conto che il costo dell’infrastruttura AI non si esaurisce nel prezzo per token. I costi di integrazione, manutenzione, monitoraggio, aggiornamento e formazione sono spesso superiori al costo computazionale puro.
Un modello MoE che costa la metà per token ma richiede il doppio delle ore-uomo per l’integrazione non è necessariamente più economico.
Un orchestratore che generalizza a tool mai visti, ma richiede un team DevOps dedicato, non è necessariamente più flessibile nella pratica. La scelta giusta è quella che minimizza il costo totale per il profilo specifico dell’azienda, nel contesto specifico dove l’automazione verrà impiegata.
