Nemotron 3.5 Lightning su VPS: guida a Ollama

A cosa serve Nemotron 3.5 Lightning

Nemotron 3.5 Lightning è il modello open di NVIDIA con architettura mixture-of-experts da 30B parametri, rilasciato nell'agosto 2026. È progettato per agenti che rimangono in esecuzione per ore, non per una singola sessione di chat. MoE (mixture of experts) significa che i pesi sono suddivisi in molte sottoreti esperte e che ogni token viene instradato soltanto attraverso alcune di esse. La scheda del modello indica 30 miliardi di parametri totali, di cui 3 miliardi attivi per token. In memoria si paga il numero più grande. In termini di velocità si ottiene il numero più piccolo.

È proprio questo compromesso a rendere il modello interessante per un server noleggiato. Un agente che svolge attività reali invia migliaia di richieste brevi nell'arco della giornata. Per questo, il throughput per unità di costo determina se il modello può essere eseguito sul proprio server. Un modello che impiega 40 secondi per ogni risposta è un assistente utilizzabile, ma un agente poco efficace: una singola attività può richiedere venti chiamate e bisogna attendere ciascuna di esse.

NVIDIA descrive l'architettura come ibrida: livelli Mamba-2 e MoE intercalati, con alcuni livelli di attenzione. La scheda del modello indica una lunghezza massima del contesto fino a 1M token e una licenza OpenMDW-1.1, contrassegnata come pronta per l'uso commerciale. Le lingue principali sono l'inglese e i linguaggi di programmazione; sono inoltre elencati spagnolo, francese, tedesco, italiano e giapponese.

Artificial Analysis ha pubblicato nell'agosto 2026 misurazioni relative al lancio che mostrano quasi 670 token di output al secondo, su un endpoint DeepInfra in pre-release che forniva i pesi NVFP4. Si tratta di un endpoint GPU gestito da un provider. Il dato indica ciò che l'architettura consente di ottenere, non le prestazioni che si possono aspettare da un VPS.

Quale tag Ollama scegliere per ciascun VPS

La libreria Ollama pubblica diverse build degli stessi pesi. A cambiare è la quantizzazione, cioè il numero di bit utilizzati per memorizzare ciascun peso. Questo incide notevolmente sulla dimensione del download.

[
  {
    "label": "30b-a3b-q4_K_M",
    "size_gb": 25
  },
  {
    "label": "30b-a3b-q8_0",
    "size_gb": 35
  },
  {
    "label": "30b-a3b-bf16",
    "size_gb": 66
  },
  {
    "label": "30b-a3b-mlx",
    "size_gb": 23
  }
]

I tag denominati latest, 30b e 30b-a3b puntano tutti allo stesso digest di 30b-a3b-q4_K_M. Il download predefinito è quindi la build a quattro bit da 25 GB, con il contesto completo da 1M. Q8_0 occupa 35 GB e bf16 66 GB; entrambe le build supportano un contesto da 1M. Le build MLX da 23 GB sono destinate ai dispositivi con Apple silicon e limitano il contesto a 256K. Sono quindi la scelta sbagliata su un VPS Linux.

Queste sono dimensioni del download, non requisiti di memoria. NVIDIA non pubblica un valore minimo di VRAM (memoria video) per le build Ollama. Considera quindi la dimensione del download soltanto come una soglia minima, non come un requisito completo. I pesi devono essere mantenuti in memoria: nella memoria della GPU se la scheda riesce a contenerli, altrimenti nella RAM di sistema. A questi si aggiunge la KV cache (cache key/value, la memoria del modello utilizzata per rappresentare la conversazione token per token). Il valore effettivo per il tuo hardware si ottiene con un comando, non con un calcolo teorico, ed è riportato di seguito. Se non hai ancora scelto il livello di quantizzazione, quanto costano Q4, Q8 e FP16 spiega a cosa si rinuncia a ogni passaggio.

Usa il tag esatto, mai latest

latest è un puntatore variabile. Quando la libreria lo ripubblica, il comportamento dell'agent cambia al pull successivo, senza alcuna informazione nelle note che spieghi il motivo. Specifica il tag.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M

Lo script di installazione configura un servizio systemd che viene eseguito con l'utente ollama e conserva i modelli in /usr/share/ollama/.ollama/models. Nella maggior parte delle immagini VPS, questo percorso si trova nel filesystem root. Controlla quindi lo spazio disponibile prima di richiedere 25 GB. Se quel filesystem ha poco spazio, consulta dove Ollama memorizza i modelli e come spostarli prima del pull, non dopo che il disco si è riempito.

df -h /usr/share/ollama

Un pull che si interrompe a metà e restituisce no space left on device indica esattamente questo. I blob parziali restano sul disco finché non li elimini. Verifica quindi cosa è stato scaricato:

ollama show nemotron-3.5-lightning:30b-a3b-q4_K_M

ollama show mostra l'architettura, il numero di parametri, la lunghezza del contesto e la quantizzazione effettivamente contenuta nel file. Se uno di questi valori non corrisponde alla pagina della libreria, hai eseguito il pull di un tag diverso da quello previsto.

Avvialo e verifica dove è stato effettivamente eseguito

sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"

Mentre il modello è ancora caricato, apri una seconda shell:

ollama ps

Questo comando risponde alla domanda sulla memoria per la tua macchina. ollama ps mostra il modello caricato, lo spazio che occupa in memoria e una colonna PROCESSOR. 100% GPU indica che il modello è interamente nella VRAM. 100% CPU indica che non lo è affatto e che ogni token viene elaborato dal processore usando la RAM di sistema. Un valore suddiviso, come 65%/35% CPU/GPU, indica che i layer non entrano tutti nella VRAM e che la quota elaborata dalla CPU determina la velocità. Non stimare il requisito. Carica il modello e leggi questa riga.

Se il modello non può essere caricato, Ollama rifiuta l'operazione in modo pulito invece di terminare in modo anomalo:

Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)

Un VPS con sole CPU è abbastanza veloce?

Un VPS general purpose non ha una GPU, quindi tutto il lavoro viene eseguito dalla CPU, che legge dalla RAM di sistema tutti i pesi necessari. MoE è utile in questo caso, perché per ogni token vengono utilizzati soltanto circa 3 miliardi dei 30 miliardi di parametri. Di conseguenza, il calcolo per token è molto inferiore rispetto a quello richiesto da un modello denso da 30B. La memoria, invece, non beneficia di questa riduzione. Tutti i 30 miliardi di parametri devono rimanere residenti, perché il router può selezionare qualsiasi expert per qualsiasi token.

L'inferenza su un modello CPU-only è quindi limitata dalla larghezza di banda della memoria, più che dal numero di core. Aggiungere vCPU a un piano che ne ha già un numero adeguato cambia molto poco. Servono abbastanza RAM per contenere i pesi e la KV cache, oltre alla memoria più veloce disponibile nel piano.

Misura le prestazioni prima di assegnargli un agent, usando il metodo descritto in misurare i token al secondo per un LLM locale:

ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."

La riga eval rate stampata alla fine indica la velocità di generazione in token al secondo. Questo singolo valore determina la risposta, perché il tempo trascorso da un agent è dominato da questo fattore. Moltiplicalo per la lunghezza prevista della risposta. Se il risultato supera il tempo che sei disposto ad aspettare, limitare l'output con num_predict è l'unica impostazione che consente di limitare la durata di una singola chiamata senza modificare l'hardware.

[
  {
    "label": "Nemotron 3.5 Lightning",
    "sec_per_task": 30
  },
  {
    "label": "gpt-oss-120b",
    "sec_per_task": 204
  },
  {
    "label": "Qwen3.6 35B",
    "sec_per_task": 210
  }
]

Si tratta di dati pubblicati da terze parti, convertiti dai minuti per attività riportati da Artificial Analysis al momento del lancio. Le misurazioni sono state eseguite su endpoint GPU hosted, non su un VPS. Nemotron 3.5 Lightning ha registrato una media di circa 30 secondi per attività; gpt-oss-120b ha richiesto circa 204, mentre Qwen3.6 35B circa 210. Usali per valutare l'entità del divario, non come garanzia per il tuo hardware.

La raccomandazione dipende da chi deve aspettare. Se una persona attende la risposta dell'agent, oppure l'agent esegue lunghe sequenze di chiamate consecutive, conviene noleggiare capacità GPU. Se l'agent viene eseguito secondo una pianificazione durante la notte e nessuno ne attende l'esecuzione, un piano CPU con molta RAM è una scelta ragionevole. In entrambi i casi, la configurazione è la stessa. Eseguire Ollama su un VPS illustra il dimensionamento del piano e il confronto tra un'istanza GPU e il pagamento di un provider API in base ai token. Il punto di pareggio dipende dall'utilizzo: un'istanza GPU viene fatturata per ogni ora in cui esiste, mentre i token API vengono fatturati soltanto quando vengono utilizzati. Di conseguenza, un agent attivo per gran parte della giornata favorisce un server di proprietà; un agent che viene eseguito due volte all'ora, in genere, no.

La finestra di contesto da 1M token non è gratuita

1M token è il limite massimo del modello, ma Ollama non lo assegna per impostazione predefinita. Ollama usa una finestra predefinita molto più piccola ed elimina i token più vecchi quando una conversazione supera tale limite. Quando accade, non viene registrato alcun evento. Per un agent, quindi, sembra che il modello abbia dimenticato l'inizio dell'attività.

Imposta esplicitamente la finestra. Per applicarla all'intero server, modifica il servizio:

sudo systemctl edit ollama

Aggiungi questa configurazione, quindi esegui sudo systemctl restart ollama:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Per una singola richiesta, invia invece num_ctx nell'oggetto delle opzioni:

curl http://localhost:11434/api/chat -d '{
  "model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
  "messages": [{"role": "user", "content": "Say ready"}],
  "options": {"num_ctx": 32768},
  "stream": false
}'

Ogni aumento richiede più memoria, perché la cache KV cresce in base al numero di token consentiti. Aumenta il valore, riavvia, quindi esegui di nuovo ollama ps e osserva l'aumento della dimensione riportata. Se, dopo questa modifica, la colonna PROCESSOR passa da 100% GPU a una configurazione suddivisa, la cache KV ha spostato i layer del modello fuori dalla VRAM e la velocità diminuirà nettamente. Scelta di num_ctx in Ollama analizza in dettaglio questo compromesso. Non impostare 1000000 solo perché la model card lo consente: l'allocazione avviene subito e il caricamento fallisce semplicemente.

Collegarlo a un agente sempre attivo

Il post di lancio di Ollama per questo modello documenta una scorciatoia che avvia un agente supportato già configurato per usarlo:

ollama launch claude --model nemotron-3.5-lightning

In quella posizione, il post documenta claude, opencode, openclaw e hermes. Il sottocomando richiede una versione aggiornata di Ollama. Controlla prima ollama --version e, se non è disponibile, configura manualmente l'agente per usare l'API. Ollama espone un endpoint compatibile con OpenAI, accettato dalla maggior parte degli agent harness:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

Ollama ignora la chiave, ma la maggior parte dei client non si avvia se non ne viene impostata una. La configurazione dell'harness è descritta in configurare un coding agent per usare Ollama e in creare il proprio agente OpenClaw.

Quando l'agente viene eseguito senza supervisione, sono importanti due impostazioni del server. OLLAMA_KEEP_ALIVE controlla per quanto tempo un modello rimane in memoria dopo l'ultima richiesta. Il valore predefinito lo scarica dopo cinque minuti, quindi la richiesta successiva deve sostenere nuovamente l'intero tempo di caricamento. Per un file da 25 GB senza GPU, questa pausa è sufficiente a causare il superamento del timeout. Imposta OLLAMA_KEEP_ALIVE=-1 per mantenerlo residente. OLLAMA_HOST=0.0.0.0:11434 rende l'API raggiungibile da altre macchine e non offre alcun tipo di autenticazione. Esporla soltanto dietro una regola firewall o su una rete privata.

Modalità di errore e stringhe visualizzate

Il pull fallisce immediatamente. Error: pull model manifest: file does not exist indica che il tag non esiste. I nomi dei tag sono stringhe esatte. Copiane uno dalla pagina della libreria invece di indovinare il suffisso della quantizzazione.

Il modello non viene caricato. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) indica che, con la configurazione attuale, il tag è troppo grande per questo piano. Passa a una quantizzazione più piccola oppure riduci OLLAMA_CONTEXT_LENGTH, perché la cache KV rientra in questo requisito.

La porta 11434 non risponde. curl: (7) Failed to connect to localhost port 11434 indica che il servizio non è in esecuzione oppure non è in ascolto sull'indirizzo previsto. Leggi systemctl status ollama e journalctl -u ollama -n 50. Se hai avviato manualmente anche ollama serve, la seconda istanza termina con Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Risponde, ma molto lentamente. Controlla ollama ps prima di modificare qualsiasi impostazione. Su una macchina con GPU, una percentuale di CPU nella colonna PROCESSOR indica che parte del modello non rientra nella VRAM. Riduci quindi il contesto oppure usa una quantizzazione più piccola. Su una macchina senza GPU, la lentezza è prevista e nessuna impostazione può risolverla.

L'agente dimentica le istruzioni durante l'esecuzione di un'attività. La conversazione ha superato la finestra di contesto e i token più vecchi sono stati eliminati senza messaggi. Aumenta OLLAMA_CONTEXT_LENGTH e verifica con ollama ps che il modello rientri ancora nella memoria disponibile. Se non è più così, la soluzione è una macchina più potente, non una finestra più piccola.

Confronto con le alternative

Ospitare un modello MoE da 30B è impegnativo per un’attività di piccole dimensioni. Se un modello denso da 8B gestisce già il tuo caso d’uso, eseguirlo costerà molto meno e il caricamento richiederà pochi secondi; Qwen 3 a 8B e 27B su un VPS è il confronto diretto per questa scelta. Per una panoramica più ampia dei modelli che un determinato piano può effettivamente contenere, parti da quali modelli di IA puoi ospitare autonomamente. Se prevedi di servire più agenti contemporaneamente invece di uno solo, leggi prima Ollama a confronto con vLLM, perché Ollama non raggruppa le richieste simultanee come farebbe un server di inferenza per la produzione; è in questo punto che una configurazione per singolo utente smette di scalare.

FAQ

Quale tag di Nemotron 3.5 Lightning devo scaricare su un VPS Linux?

Usa nemotron-3.5-lightning:30b-a3b-q4_K_M. Ha una dimensione di 25 GB, include il contesto massimo completo di 1M ed è lo stesso digest a cui fanno riferimento i tag latest, 30b e 30b-a3b ad agosto 2026. Indicalo esplicitamente invece di scaricare latest, così una futura ripubblicazione di quel puntatore non potrà modificare il comportamento del tuo agent senza che tu te ne accorga. I tag mlx sono build per Apple silicon e non sono utili su Linux.

Quanta RAM richiede Nemotron 3.5 Lightning?

NVIDIA non pubblica un requisito minimo di memoria per le build di Ollama, quindi è meglio misurare anziché stimare. Scarica il tag, esegui il modello una volta e leggi ollama ps mentre è caricato: il comando mostra la dimensione effettivamente occupata e indica se il modello è stato caricato sulla GPU o sulla CPU. La dimensione del download, 25 GB per il tag predefinito, è un valore minimo, perché la KV cache viene aggiunta a questo valore e cresce con la finestra di contesto impostata. Se il piano è troppo piccolo, Ollama restituisce model requires more system memory e indica entrambi i valori.

Posso eseguire Nemotron 3.5 Lightning su un VPS senza GPU?

Sì, se il piano dispone di RAM sufficiente per contenere i pesi. L'architettura MoE è utile perché per ogni token vengono calcolati soltanto circa 3 dei 30 miliardi di parametri. Il limite è la velocità. Senza una GPU, il modello è limitato dalla larghezza di banda della memoria, quindi aggiungere vCPU incide poco sul risultato. Esegui ollama run --verbose con un prompt fisso, leggi la riga eval rate e confronta quel valore con il tempo massimo previsto per il tuo agent. Per un job batch eseguito durante la notte è spesso adeguato. Per qualsiasi attività che richieda l'attesa di una persona, di solito non lo è.

Perché Ollama non mi fornisce la finestra di contesto completa di 1M?

1M è il limite massimo del modello, non il valore predefinito di Ollama. Ollama applica una finestra molto più piccola ed elimina i token più vecchi quando una conversazione la supera, senza stampare errori. Questo può far sembrare che l'agent abbia dimenticato le proprie istruzioni. Imposta OLLAMA_CONTEXT_LENGTH sul servizio systemd oppure passa num_ctx per ogni richiesta. Aumenta il valore per gradi e ricontrolla ollama ps ogni volta, perché la memoria della KV cache cresce con la finestra e può spostare alcuni layer del modello fuori dalla GPU.

Nemotron 3.5 Lightning è gratuito per l'uso commerciale?

La model card di NVIDIA distribuisce il modello con la licenza OpenMDW-1.1 e lo indica come pronto per l'uso commerciale. Questo vale per i pesi che scarichi ed esegui autonomamente. Non si applica agli altri componenti dello stack, quindi verifica separatamente le licenze dell'agent harness e degli eventuali strumenti collegati. Consulta inoltre la model card aggiornata prima di basarti su queste informazioni per attività di natura contrattuale.