Fino a un anno fa gli agenti AI erano, per la maggior parte delle aziende, dei chatbot travestiti. Oggi la conversazione è cambiata: non si discute più di quale modello adottare, ma di quanti modelli far lavorare insieme e con quale criterio. L’11 agosto 2026 NVIDIA ha messo un nome e due prodotti su questo passaggio, rilasciando Nemotron 3.5 Lightning, un Mixture-of-Experts open da 30 miliardi di parametri, e NeMo Switchyard, una libreria open source per il routing tra modelli. È l’occasione migliore per capire cosa sono davvero i systems of models per gli agenti AI in azienda e perché riguardano anche una PMI italiana che non comprerà mai una DGX.
In questo articolo scoprirai:
- Nemotron 3.5 Lightning: cosa ha rilasciato NVIDIA l'11 agosto 2026
- NeMo Switchyard: il routing è la parte interessante del rilascio
- Systems of models e sistemi multi-agente: la differenza che nessuno spiega
- Quando conviene un modello piccolo invece di un frontier model
- Come si progetta un system of models per gli agenti AI in azienda
Nemotron 3.5 Lightning: cosa ha rilasciato NVIDIA l’11 agosto 2026
NVIDIA lo presenta come il modello più efficiente della sua classe per carichi agentici a lunga durata, secondo l’annuncio pubblicato sul blog ufficiale NVIDIA. I numeri chiave dichiarati dal vendor: fino a 4 volte la velocità di output dei modelli di dimensioni comparabili e completamento dei task agentici più rapido del 30% rispetto alla concorrenza di pari classe. Sono claim NVIDIA su benchmark scelti da NVIDIA, non misurazioni indipendenti: vanno letti come indicazione di direzione, non come garanzia contrattuale.
Il rilascio non arriva isolato: si inserisce nella traiettoria che NVIDIA ha tracciato negli ultimi mesi, dagli annunci hardware e software del GTC 2026 fino alla spinta sui modelli open distribuibili su RTX, DGX Spark e Jetson. La logica è coerente: se l’inferenza agentica diventa il carico dominante, chi vende silicio ha interesse a che quel carico giri ovunque, anche su una workstation sotto la scrivania, e non soltanto dentro i data center di tre hyperscaler. Per chi legge da un’azienda il segnale è che i modelli piccoli non sono un ripiego per chi non può permettersi il meglio, ma una categoria progettata apposta per un tipo di lavoro preciso.
I numeri reali di Nemotron 3.5 Lightning: 30B totali, 3B attivi
La model card su Hugging Face colma i vuoti dell’annuncio commerciale. L’architettura è ibrida: layer Mamba-2 interlacciati con layer MoE e alcuni layer di attention, più Multi-Token Prediction per il decoding speculativo. Su 30 miliardi di parametri totali solo 3 miliardi sono attivi a ogni token: è questa la ragione della velocità, non la magia. Il pre-training conta oltre 20 trilioni di token, con cutoff a settembre 2025 e post-training fino a maggio 2026. La context window arriva a 1 milione di token, ma il deployment pratico su una singola H100 80GB si ferma a 256K. La licenza è OpenMDW-1.1, utilizzabile commercialmente. Sui benchmark dichiarati: 81,94% su MMLU Pro, 75,44% su GPQA Diamond, 51,56% su SWE-bench Verified. Numeri solidi per un modello che gira su una GPU sola, non da frontier model. Per capire cosa significano davvero questi parametri, la nostra guida agli LLM spiega l’architettura sottostante.
NeMo Switchyard: il routing è la parte interessante del rilascio
Il modello fa notizia, ma la libreria è la mossa strategica. NeMo Switchyard è un proxy e SDK provider-agnostico che smista ogni richiesta di un workflow agentico verso il modello più adatto, valutando a runtime tre famiglie di segnali: capacità dei modelli disponibili, profili di costo e latenza, metriche infrastrutturali di carico e affidabilità. Accetta richieste in formato OpenAI, Anthropic e Responses API e le traduce internamente, il che significa che l’orchestrazione non ti incatena a un fornitore.
Quanto si risparmia davvero con il routing tra modelli
Il technical blog NVIDIA riporta due misurazioni di partner. LangChain, su 145 task multi-turn, ha registrato una riduzione dei costi del 74% rispetto a una baseline solo-frontier, instradando appena il 7% delle chiamate al modello di punta, con un calo di accuratezza di circa 6 punti. Cognition, sul benchmark FrontierCode Main, riferisce 50,6% di accuratezza a 3,11 dollari di costo medio: 2,8 punti sotto Opus 5, ma con circa il 28% di costo medio in meno. Anche qui: sono dati di partner selezionati dal vendor. La lezione trasferibile non è la percentuale, è il meccanismo, gli algoritmi di routing disponibili includono un Escalation Router che parte dal modello economico e sale solo quando la difficoltà persiste, e uno Stage Router che legge l’attività sui tool per capire quando serve più capacità.
Perché rendere open il routing è la mossa che conta
L’analisi di Moor Insights & Strategy legge il rilascio in chiave di posizionamento: aprire il codice del router significa candidarsi a diventare lo strato di controllo che decide quale modello riceve quale richiesta, una posizione più difendibile nel lungo periodo di un singolo modello che tra sei mesi sarà superato da qualcun altro. Per chi compra, la conseguenza pratica è concreta: se il livello di routing è open e provider-agnostico, cambiare fornitore di modelli diventa una modifica di configurazione e non un progetto di migrazione da mesi. È la differenza tra scegliere un modello e scegliere un’architettura, e spiega perché il pezzo di software apparentemente meno appariscente dei due sia quello che merita attenzione.
Systems of models e sistemi multi-agente: la differenza che nessuno spiega
La SERP italiana su questo tema restituisce definizioni generiche di agenti AI, e quella inglese collassa il concetto di “system of models” su “multi-agent system”. Sono due cose diverse e la confusione costa soldi. Un sistema multi-agente è un’architettura in cui agenti specializzati con ruoli distinti collaborano: un orchestratore riceve la richiesta, interpreta l’intento e decide quali agenti coinvolgere, come descrive l’analisi di Airia sull’architettura enterprise. Un system of models opera un livello più in basso: è la scelta di quale modello esegue quale singola inferenza, dentro lo stesso agente.
Perché la distinzione conta per gli agenti AI in azienda
Prima ancora della distinzione serve un accordo sui termini: IBM definisce un agente AI come un sistema che ragiona, pianifica e agisce in autonomia per raggiungere un obiettivo assegnato dall’utente, usando strumenti esterni quando servono. È una definizione che non dice nulla su quanti modelli ci siano sotto il cofano, ed è esattamente lì che si apre lo spazio di progettazione. Google Cloud lo mette in una riga: «ogni agente può avere foundation model diversi, quelli che meglio si adattano ai suoi bisogni». Databricks arriva alla stessa conclusione da un’altra strada, sostenendo che «componenti multipli che interagiscono offrono output di qualità molto più alta di un singolo foundation model». Tradotto: puoi avere un solo agente e cinque modelli sotto, oppure cinque agenti e un modello solo. Le due dimensioni sono indipendenti, e sbagliare quale delle due stai progettando è il modo più rapido per costruire un sistema che costa come un frontier model e sbaglia come un modello piccolo. Se il tema degli agenti è nuovo, il nostro approfondimento sugli agenti AI per le aziende chiarisce le fondamenta.
Quando conviene un modello piccolo invece di un frontier model
La regola pratica che emerge dai dati di routing è che la maggior parte delle inferenze di un agente non richiede intelligenza di frontiera: classificare un ticket, estrarre campi da un PDF, decidere se una mail va inoltrata. Nel test LangChain solo il 7% delle chiamate è finito al modello di punta: tutto il resto è stato servito da modelli più piccoli. Se la gran parte del lavoro può essere gestita così, pagare un frontier model per farlo è come noleggiare un camion per portare la spesa a casa.
I tre trade-off: costo, latenza, controllo
Sul costo abbiamo i numeri sopra. Sulla latenza, un modello che gira in locale su RTX, DGX Spark o Jetson elimina il round-trip di rete: per un agente always-on che fa migliaia di chiamate al giorno, la differenza è strutturale, non cosmetica. Sul controllo, i pesi open sotto licenza commerciale significano che i dati non escono dal perimetro aziendale, argomento non secondario per chi lavora con dati sanitari, finanziari o industriali in Europa. Il rovescio della medaglia: un modello piccolo va scelto, quantizzato, valutato e mantenuto, e su questo la disciplina dell’inference engineering non è opzionale.
Nemotron non è il primo a percorrere questa strada: l’avevamo già vista con LFM2.5-2.6B e con Meta Muse Glimmer. La differenza è che qui il modello arriva accompagnato dallo strumento che decide quando usarlo, e questo cambia il modo in cui la scelta va impostata.
Come si progetta un system of models per gli agenti AI in azienda
L’architettura di riferimento che emerge dalla letteratura enterprise ha quattro strati: agent layer, orchestrazione, knowledge e data, governance e observability, secondo l’analisi di Dataiku sugli enterprise agent systems, che cita anche un dato che raffredda gli entusiasmi: sul benchmark AgentArch persino i modelli migliori raggiungono solo il 35,3% di successo sui task complessi. Non è un problema di modello, è un problema di progettazione del sistema.
Dalla scelta del modello alla scelta dell’architettura: il ruolo dell’onboarding
Qui sta il punto per una PMI italiana. La domanda giusta non è «meglio Gemini, Claude o un modello open?». La prima domanda è: quali passaggi del mio processo sono deterministici, quali ambigui, quali richiedono ragionamento vero? Da lì si deriva l’architettura, e solo dopo i modelli.
È esattamente il lavoro che facciamo nell’onboarding di MIMIR: non vendiamo un modello, mappiamo un processo e costruiamo attorno l’architettura che regge, con assistenza dedicata nelle settimane in cui il sistema entra in produzione. Perché come abbiamo già argomentato, nell’AI agent enterprise il servizio conta più del modello. Se hai un processo aziendale che pensi possa reggere un agente AI e non sai da dove partire, parlarne con noi è il modo più rapido per scoprire se l’architettura giusta esiste già o va disegnata.
Fonti:
- NVIDIA — annuncio Nemotron 3.5 Lightning e NeMo Switchyard
- Hugging Face — model card NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16
- NVIDIA Developer — routing dei workload agentici con NeMo Switchyard
- Moor Insights & Strategy — l’open sourcing del model routing è la vera mossa
- Airia — architettura enterprise dei sistemi multi-agente
- Dataiku — enterprise agent systems e benchmark AgentArch
- Databricks — AI agent systems e qualità dell’output
- Google Cloud — cosa sono gli agenti AI
- IBM Think — definizione di agente AI
Domande frequenti
Che differenza c'e' tra un system of models e un sistema multi-agente?
Un sistema multi-agente e' un'architettura in cui agenti specializzati con ruoli distinti collaborano sotto un orchestratore che interpreta l'intento e distribuisce il lavoro. Un system of models opera un livello piu' in basso: e' la scelta di quale modello esegue quale singola inferenza, anche all'interno di un solo agente. Le due dimensioni sono indipendenti: si puo' avere un agente con cinque modelli sotto, oppure cinque agenti che usano lo stesso modello.
Quanti parametri usa davvero Nemotron 3.5 Lightning a ogni token?
Il modello ha 30 miliardi di parametri totali, ma essendo un Mixture-of-Experts ne attiva solo 3 miliardi per ogni token generato. E' questa la ragione tecnica della velocita' dichiarata da NVIDIA, non un'ottimizzazione software. La context window arriva a 1 milione di token, ma il deployment pratico su una singola H100 da 80GB si ferma a 256K.
Conviene sempre usare un modello piccolo al posto di un frontier model?
No, conviene distinguere. Classificare un ticket, estrarre campi da un documento o decidere se inoltrare una mail non richiedono intelligenza di frontiera, e su questi task un modello piccolo abbatte costi e latenza. I passaggi che richiedono ragionamento complesso restano appannaggio dei modelli di punta: il valore del routing sta proprio nel far convivere le due categorie senza scegliere a priori.
