Nemotron 3.5 Lightning è il modello operativo per gli agenti IA di NVIDIA

NVIDIA Nemotron 3.5 Lightning non nasce per essere l’ennesimo chatbot generalista. È piuttosto il modello “operaio” di un sistema di agenti IA: rapido, personalizzabile e pensato per gestire migliaia di operazioni ripetitive dopo che un modello più capace ha definito il piano di lavoro.

Presentato l’11 agosto 2026, Lightning combina 30 miliardi di parametri complessivi con circa 3 miliardi di parametri attivi durante ogni passaggio di generazione. La differenza è importante: il modello conserva la capacità potenziale di una rete più grande, ma non deve attivarla interamente per produrre ogni token.

Che cos’è Nemotron 3.5 Lightning

Lightning è un modello open da 30B basato su un’architettura Mixture-of-Experts, sviluppato per i compiti specializzati degli agenti che lavorano in modo continuo. NVIDIA considera open la famiglia Nemotron perché mette a disposizione pesi, dati di addestramento e ricette, permettendo agli sviluppatori di valutare e adattare i modelli prima della messa in produzione.

Il modello è distribuito nei formati BF16 e NVFP4. I materiali tecnici lo descrivono inoltre come un’architettura ibrida che combina elaborazione di tipo state-space o Mamba, attenzione e percorsi di esperti instradati. L’obiettivo è offrire una capacità complessiva elevata senza utilizzare l’intera rete per ogni token.

Le due cifre principali indicano quindi aspetti diversi:

• 30B di parametri totali: l’intero insieme dei parametri appresi dal modello.
• Circa 3B di parametri attivi: la porzione utilizzata, in media, per ciascun passaggio di generazione.

Questa esecuzione sparsa può ridurre il calcolo necessario per token. Non significa però che il modello completo scompaia: i parametri totali devono comunque essere archiviati e gestiti dal sistema di serving.

Il vero bersaglio: l’esecuzione, non la pianificazione

Un agente autonomo può consumare molte chiamate al modello anche per completare un solo incarico. Dopo la pianificazione iniziale, il workflow può richiedere di selezionare strumenti, estrarre campi da documenti, verificare regole, interrogare fonti, trasformare dati e produrre un output strutturato.

Usare un modello di fascia frontier per ogni singola operazione può aumentare latenza e costi. Lightning è pensato per prendere in carico proprio questa parte prevedibile e ad alta frequenza, lasciando a un modello più potente le decisioni ambigue e il ragionamento più impegnativo.

Un’architettura tipica potrebbe funzionare così:

1. Un modello di ragionamento interpreta l’obiettivo e costruisce il piano.
2. Lightning esegue i passaggi ordinari su strumenti, documenti o dati strutturati.
3. Il modello più grande viene richiamato quando emergono eccezioni, incertezze o decisioni che richiedono maggiore capacità.

NVIDIA presenta Nemotron 3 Ultra, un modello MoE da 550B di parametri totali e 55B attivi, come soluzione per il ragionamento avanzato e l’orchestrazione. Il confronto chiarisce il ruolo complementare di Lightning.

NeMo Switchyard è il componente che decide chi deve lavorare

Per realizzare davvero questa divisione dei compiti serve un sistema di instradamento. Un agente non dovrebbe inviare ogni richiesta allo stesso endpoint: deve poter scegliere il modello più efficiente per ciascun passaggio.

NeMo Switchyard è l’SDK di NVIDIA, indipendente dal provider, che rappresenta le richieste, definisce i modelli disponibili e gestisce le chiamate verso il provider o l’ID del modello selezionato.

In pratica, Switchyard consente di costruire una gerarchia di modelli: Lightning può occuparsi delle richieste ordinarie e numerose, mentre Nemotron 3 Ultra o un altro sistema più capace interviene sui casi difficili.

È un punto architetturale decisivo. Lightning ha probabilmente più valore come componente di uno stack multi-modello instradato che come chatbot autonomo utilizzato in isolamento.

Contesto esteso e opzioni di deployment

NVIDIA indica una capacità di contesto fino a 1 milione di token, una caratteristica utile per agenti che mantengono conversazioni lunghe, analizzano documenti voluminosi o devono conservare molto stato durante un workflow prolungato. La capacità effettivamente utilizzabile e le prestazioni dipendono comunque dallo stack di serving e dalla configurazione scelta.

Il checkpoint NVFP4 è destinato all’inferenza e utilizza kernel NVIDIA specializzati sulle generazioni di GPU supportate. NVIDIA indica possibilità di esecuzione su infrastrutture locali, workstation, data center e cloud; il modello è inoltre disponibile tramite Hugging Face e servizi ospitati.

AWS segnala la disponibilità di Nemotron 3.5 Lightning in SageMaker JumpStart, con deployment dalla console SageMaker o tramite SDK Python. La documentazione NIM di NVIDIA offre invece un percorso containerizzato separato, con requisiti specifici per sistema operativo, CUDA, driver e Docker.

La promessa di esecuzione su una singola GPU va però interpretata con cautela. La quantizzazione può rendere il serving più accessibile, ma la fattibilità dipende dalla GPU, dalla memoria disponibile, dalla lunghezza del contesto, dal formato di quantizzazione, dal batching e dal software utilizzato. Le dichiarazioni sul supporto esteso alle GPU GeForce o su precise riduzioni dello spazio di archiviazione andrebbero verificate nel model card e nella ricetta di deployment correnti.

Le prestazioni dichiarate vanno lette nel contesto

NVIDIA e AWS pubblicizzano fino a quattro volte più throughput e fino al 30% in meno nel completamento dei task per workload agentici mirati. Non sono però misure universali dell’intelligenza del modello né risultati garantiti in qualsiasi ambiente produttivo.

I risultati reali possono cambiare in base a:

• modello usato come riferimento;
• generazione della GPU e quantità di memoria;
• dimensione dei batch e livello di concorrenza;
• lunghezza di prompt e contesto;
• latenza degli strumenti e della rete;
• impostazioni di decoding; e
• tasso di errore accettabile per il compito.

Per questo Lightning dovrebbe essere valutato sui parametri che contano davvero per il singolo agente: accuratezza dell’estrazione, affidabilità delle chiamate agli strumenti, rispetto degli output strutturati e tempo complessivo di completamento. Il solo dato dei token al secondo non basta.

Prezzi interessanti, ma legati al provider

I servizi hosted possono rendere Lightning particolarmente interessante per l’inferenza ad alto volume. DeepInfra indica un prezzo di 0,05 dollari per milione di token in ingresso e 0,20 dollari per milione di token in uscita, con pagamento a consumo e senza la necessità di gestire direttamente l’infrastruttura GPU.

Queste cifre non sono una caratteristica permanente del modello. Provider diversi possono applicare tariffe differenti e il costo effettivo può dipendere da precisione, caching e percorso di instradamento.

Il confronto con modelli più grandi dovrebbe quindi includere il costo dell’intero workflow: tentativi ripetuti, chiamate agli strumenti, routing e richieste che devono comunque essere affidate a un modello più potente.

Il verdetto: un lavoratore veloce, non un sostituto universale

Nemotron 3.5 Lightning va considerato un modello operativo veloce e personalizzabile per sistemi agentici. Ha senso quando un’applicazione produce molte richieste simili e quando il compito può essere specializzato, vincolato o ulteriormente addestrato.

Non viene presentato come un sostituto universale di un modello dedicato all’orchestrazione. Pianificazione complessa, giudizi incerti e attività in cui un errore ha conseguenze elevate possono richiedere Nemotron 3 Ultra o un altro sistema di fascia frontier.

La posizione di Lightning è quindi piuttosto chiara: rappresenta il livello di esecuzione a bassa latenza di uno stack agentico instradato. I 30B di capacità complessiva, i circa 3B attivi, i materiali open, l’opzione di inferenza quantizzata e i diversi percorsi di deployment puntano a rendere il lavoro ordinario degli agenti più economico e veloce. I miglioramenti dichiarati sono promettenti, ma vanno verificati sul workflow specifico prima di considerarli risultati di produzione.