SSD Nodes Learn Hosting plans →
Guide Matt ConnorDi Matt Connor · Aggiornato 2026-08-27

Muse Glimmer 30B su VPS: RAM e disco necessari

I tag Muse Glimmer richiedono da 17 a 59 GB: calcola RAM e disco per un VPS Linux prima del pull e valuta il costo dell'inferenza solo CPU.

Requisiti di Muse Glimmer su un VPS

Muse Glimmer funziona su un normale VPS Linux senza GPU. Il tag scaricato determina se il modello rientra nella memoria disponibile. Meta Superintelligence Labs ha pubblicato il modello il 10 agosto 2026 con licenza Apache 2.0: 30 miliardi di parametri, una finestra di contesto da 128K e un encoder di percezione dedicato da 1.8B parametri, che consente di elaborare immagini insieme al testo. Meta lo propone per agenti locali sempre attivi, non per la chat, con una capacità di ragionamento configurabile per ogni richiesta.

I tag Ollama pubblicati, consultati il 16 agosto 2026, vanno da 17 GB a 59 GB. Questo intervallo determina interamente il dimensionamento. Il tag predefinito è indicato a circa 18 GB. Pertanto, il server più piccolo utilizzabile deve avere chiaramente più di 18 GB di RAM libera. Al disco necessario per il download e alla memoria richiesta dalla finestra di contesto va aggiunta ulteriore capacità.

Quale tag muse-glimmer dovresti scaricare?

ChartPublished muse-glimmer tag sizes on 16 August 2026 (Linux tags only)
The data behind this chart
[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama elenca 11 tag per questo modello che non sono build per Apple. Contengono gli stessi 30 miliardi di pesi, memorizzati con diverse precisioni numeriche. La dimensione indicata è quella del download ed è anche, all'incirca, la quantità di memoria che devi avere disponibile prima di aggiungere qualsiasi contesto.

Le due build a 4 bit sono quelle più piccole: 30b-nvfp4 a 17 GB e 30b-q4_K_M a 18 GB. Il tag predefinito 30b è indicato con la stessa dimensione della build q4_K_M. Le build a 8 bit, 30b-q8_0 e 30b-mxfp8, occupano circa 31 GB. 30b-bf16 è la release non quantizzata a 16 bit, da 57 GB: richiede più RAM di quella disponibile nella maggior parte dei server a noleggio a un prezzo ragionevole per un progetto secondario.

I tag -dflash corrispondono alle stesse build con supporto DFlash e ciascuno è indicato con una dimensione maggiore rispetto alla variante standard. Ollama descrive DFlash come una funzione per aumentare la velocità e ne mostra l'uso su Apple Silicon e su GPU desktop. Su un VPS con la sola CPU pagheresti quella dimensione aggiuntiva in memoria reale per una funzione misurata su altro hardware. Inizia quindi con il tag standard e modifica una sola variabile alla volta.

Inizia con 4 bit, salvo un motivo specifico per scegliere diversamente. Passando da 4 a 8 bit, raddoppiano all'incirca i byte che la CPU deve leggere per ogni token generato. Il throughput diminuisce e l'uso della memoria aumenta. Questo compromesso è descritto in quanto costano davvero le quantizzazioni q4, q8 e fp16, ma su un server con la sola CPU la risposta breve è che la build a 4 bit è l'unico punto di partenza sensato.

Perché i tag MLX non servono a nulla su un server Linux

MLX è il framework di Apple per gli array, mentre il motore MLX di Ollama è il backend per Apple Silicon. Qualsiasi tag con mlx nel nome è stato creato per quel motore e per quell'hardware. Su un VPS Linux x86 si tratta di decine di gigabyte di download che non è possibile eseguire e che resteranno inutilizzati sul disco. Anche i dati sulle prestazioni riportati nell'annuncio, misurati su un Mac, si riferiscono a quei tag e quindi non descrivono il tuo server. Quando leggi l'elenco dei tag nella pagina del modello, escludi prima tutti i nomi mlx, quindi valuta le dimensioni di quelli rimasti.

Quanta RAM e spazio su disco servono realmente?

Due componenti richiedono memoria, e solo una dipende dalla dimensione del tag. I pesi sono determinati dal tag che scarichi. La cache KV, cioè lo stato per token che il modello mantiene per la conversazione, cresce con la lunghezza del contesto configurata. La documentazione di Ollama indica che la gestione di richieste parallele moltiplica il contesto per il numero di richieste in corso. Di conseguenza, un server che risponde contemporaneamente a due agenti richiede più memoria dello stesso server quando risponde a un solo agente.

Non prendere il valore della RAM da una guida, inclusa questa. Scarica il tag, invia un prompt e, mentre il modello è ancora residente in memoria, esegui questi due comandi.

ollama ps
free -h

ollama ps mostra cosa è attualmente caricato e come il lavoro è suddiviso tra CPU e GPU. free -h mostra la memoria rimanente. Questi due output del tuo server sono più affidabili di qualsiasi tabella pubblicata, perché includono già la configurazione del contesto, la quantizzazione e tutto il resto eseguito dal server.

Lo spazio su disco è la parte più semplice. Su Linux, Ollama archivia i modelli in /usr/share/ollama/.ollama/models, che nella maggior parte delle immagini VPS si trova sul filesystem root. Un volume root da 40GB non può contenere la build bf16 da 57 GB e non può contenere neppure due tag a 8 bit affiancati. Se non hai mai verificato cosa scrive effettivamente un'operazione di pull, in quale directory Ollama archivia i modelli e come spostarli descrive quella directory. Sposta l'archivio su un volume montato prima di scaricare qualsiasi modello.

sudo systemctl edit ollama
[Service]
Environment="OLLAMA_MODELS=/mnt/models"
sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

La directory deve appartenere all'utente ollama, perché il servizio viene eseguito come ollama e vi scrive i blob con quell'utente. Se un pull fallisce per problemi di permessi, journalctl -u ollama -n 50 mostra il motivo.

Su swap è necessaria una precisazione: la swap non consente di eseguire un tag più grande. La generazione accede ai pesi per ogni token prodotto. Di conseguenza, i pesi presenti nella swap vengono letti ripetutamente dal disco, vmstat 1 mostra le colonne si e so occupate e l'output rallenta fino a richiedere secondi per token. Mantieni un piccolo file di swap come protezione contro l'out of memory killer. Dimensiona la RAM in base al tag che vuoi utilizzare realmente.

Installare Ollama e fissare un tag nominativo

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

Lo script di installazione configura un servizio systemd, quindi il server torna operativo dopo un riavvio. Se preferisci non eseguirlo come servizio di sistema gestito da root, eseguire Ollama senza root con Podman illustra questa soluzione. Poi scarica un tag esplicito.

ollama pull muse-glimmer:30b
ollama list

Leggi direttamente la colonna delle dimensioni in ollama list e confrontala con l’elenco dei tag attuali nella pagina del modello. I tag pubblicati vengono aggiunti, rinominati e rimossi, mentre una dimensione riportata in una guida è una fotografia di un singolo giorno.

Non scrivere mai ollama pull muse-glimmer su un server da cui dipendi. Un nome di modello senza tag viene risolto nel tag latest, mentre latest è un puntatore che il publisher può spostare su una build diversa. Un normale pull sostituisce quindi il modello usato dal tuo agent, con requisiti di memoria e comportamento differenti, senza che nei log venga indicato il cambiamento. Scrivi il tag negli script, nei file unit e nella configurazione del tuo agent. Self-hosting di un LLM con Ollama su un VPS illustra il resto della configurazione del server.

È possibile eseguire Muse Glimmer senza una GPU?

Sì, ma è importante chiarire i limiti. Per generare un token è necessario leggere i pesi del modello dalla memoria, quindi la velocità dipende dalla larghezza di banda della memoria, non dal numero di vCPU dichiarato dal piano. Oltre alcuni core, aggiungerne altri offre vantaggi minimi. Su un VPS condiviso, questa larghezza di banda è condivisa con tutti gli altri tenant dell'host; per questo un modello 30B a 4 bit produce pochi token al secondo.

Non fidarti dei valori indicati da altri, incluso il mio. Misura i token al secondo sul tuo server e valuta il risultato ottenuto.

Ne deriva una distinzione netta negli scenari in cui il modello è efficace. La chat interattiva è poco pratica, perché leggi più velocemente di quanto il server riesca a generare il testo e ogni risposta inizia dopo una lunga pausa. Le attività agentiche in background funzionano bene, perché un'attività eseguita senza supervisione per dieci minuti non risente della lentezza. È esattamente il tipo di carico di lavoro che Meta descrive per questo modello.

Se ti serve una velocità interattiva, le risposte realistiche sono due: una GPU o un'API in hosting. Calcola il punto di pareggio tra un GPU VPS e i token API prima di noleggiare una risorsa, quindi consulta cosa offre realmente un GPU VPS per capire che cosa stai acquistando. Per una valutazione più generale dei modelli che un determinato server può contenere, inizia da quali modelli puoi eseguire in self-hosting; eseguire un modello Qwen di dimensioni simili su un VPS è il confronto più vicino per questa classe dimensionale. Se le misurazioni risultano troppo lente per un uso pratico, Nemotron 3.5 Lightning su un VPS pone le stesse domande su RAM e token al secondo per un modello progettato per la velocità anziché per le dimensioni.

Perché dimentica le informazioni molto prima di 128K token?

Perché la finestra di contesto predefinita di Ollama è di 4096 token, indipendentemente dalla capacità supportata dal modello. Ad agosto 2026, questo valore predefinito è riportato nelle FAQ di Ollama. Il tag pubblicizza 128K, ma il server fornisce al modello 4096 token finché non specifichi un valore diverso. Di conseguenza, una lunga trascrizione delle interazioni con l'agente perde i turni iniziali e il modello sembra avere problemi di memoria.

Aumenta il valore sul server per ogni richiesta:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

All'interno di una sessione interattiva, /set parameter num_ctx 32768 modifica il valore solo per quella sessione. Tramite API, invia num_ctx nelle opzioni della richiesta.

Ogni token di contesto aggiuntivo richiede memoria oltre a quella occupata dai pesi. Se richiedi l'intero valore di 128K su un sistema dimensionato solo per i pesi, il caricamento può non riuscire oppure può usare un fallback più lento. Aumenta il valore per passi ed esegui ollama ps dopo ogni passaggio. Come funzionano num_ctx e la lunghezza del contesto in Ollama spiega i calcoli.

Livelli di ragionamento: low, medium, high e xhigh

Meta documenta quattro livelli di ragionamento per Muse Glimmer, da low a xhigh, e raccomanda i due livelli più alti per le attività di coding complesse e quelle eseguite dagli agenti. In Ollama questo comportamento è controllato dal parametro think. Usa --think= nella riga di comando oppure invia think nel corpo della richiesta API.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

All'interno di una sessione interattiva, /set think e /set nothink attivano o disattivano questa funzione. La documentazione di Ollama indica che la maggior parte dei modelli accetta un valore booleano oppure un livello come low, medium o high, mentre alcuni accettano max per indicare il livello massimo disponibile. Le stringhe esatte accettate da questo modello sono indicate nella relativa pagina del modello. Consultala invece di procedere per tentativi e prova manualmente un valore prima di integrarlo in un agente.

Su una macchina con la sola CPU, questa impostazione ha un impatto significativo. Un livello più alto comporta la generazione di un numero maggiore di token di ragionamento prima che venga visualizzata la prima parola della risposta. Ogni token di ragionamento richiede lo stesso tempo di elaborazione di un token della risposta. Per le attività ordinarie, mantieni il livello low. Anche la lunghezza della risposta richiede la stessa attenzione: limita la risposta con num_predict invece di lasciare che una singola risposta prolissa occupi una macchina lenta per diversi minuti.

Mantieni il modello caricato per un agente sempre attivo

Per impostazione predefinita, Ollama scarica un modello inattivo dopo cinque minuti. Per un agente che viene eseguito ogni dieci minuti, questo significa caricare ogni volta tutti i 18 GB dal disco. Su un VPS con storage collegato tramite rete, il caricamento non è rapido. Mantieni invece il modello in memoria.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Un valore negativo mantiene il modello residente finché un'operazione non lo scarica; keep_alive in una richiesta API sostituisce il valore predefinito del server solo per quella chiamata. Il costo è concreto: la RAM resta occupata anche quando non è in corso alcuna attività. Questa impostazione è quindi adatta a un sistema dedicato all'agente. Mantieni un modello Ollama caricato illustra le varianti.

Indirizzarlo a un agente di coding

Ollama espone un'API compatibile con OpenAI all'indirizzo http://127.0.0.1:11434/v1, quindi la maggior parte degli strumenti per agenti si connette usando un URL di base e una chiave API non vuota. La pagina Muse Glimmer di Ollama documenta inoltre una scorciatoia di avvio che collega, con un solo comando, un agente supportato a un modello locale. Anche in questo caso, specifica il tag in modo esplicito.

ollama launch claude --model muse-glimmer:30b

Gli agenti inviano prompt voluminosi. Il contenuto dei file, l'output degli strumenti e una trascrizione che cresce nel tempo arrivano tutti come token di input. Su una macchina con CPU, l'elaborazione del prompt è la fase più onerosa, prima ancora che inizi la generazione. Mantieni l'impostazione del contesto al valore più basso compatibile con l'attività. Collegare un agente di coding a Ollama tratta il lato client, eseguire un agente di coding su un VPS tratta la macchina su cui viene eseguito e controllare i costi di un agente su un VPS tratta ciò che accade quando l'agente rimane in esecuzione tutto il giorno.

L'input di immagini funziona nello stesso modo. L'API di Ollama accetta le immagini nel campo images di un messaggio. Un client che supporta solo testo non ne invierà mai, indipendentemente dalle capacità dell'encoder di percezione.

Non aprire la porta 11434

L'API di Ollama non dispone di autenticazione. Impostare OLLAMA_HOST=0.0.0.0:11434 per raggiungerla dal laptop espone su Internet un motore di esecuzione dei modelli privo di autenticazione. Chiunque lo individui può caricare modelli sul disco e leggere tutto ciò che l'agente invia tramite il servizio. Lascialo in ascolto su localhost e usa invece un tunnel.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Protezione dell'endpoint dell'API di Ollama illustra le opzioni corrette, incluso un reverse proxy che richiede credenziali.

Cosa si rompe e cosa vedrai

Il pull si interrompe a metà. Il disco è pieno. Esegui df -h nella directory del modello. Una build bf16 da 57 GB non entra in un volume root da 40GB; lo stesso vale per due tag a 8 bit affiancati.

Il modello viene caricato, poi il processo termina. La memoria è esaurita. dmesg -T registra quale processo il kernel ha scelto di terminare tramite l’out-of-memory killer, mentre journalctl -u ollama -n 100 mostra lo stesso evento dal punto di vista del servizio. La soluzione è usare un tag più piccolo o un num_ctx più piccolo. Aggiungere altro swap non risolve il problema.

L’esecuzione richiede diversi secondi per token. Esegui vmstat 1 e monitora le colonne si e so. Un’attività di swap continua indica che i pesi non entrano nella RAM e che il sistema li rilegge dal disco durante l’elaborazione.

Un tag che funzionava la settimana scorsa non è più disponibile. Gli elenchi dei tag cambiano. Rileggi la pagina del modello, fissa il tag attualmente disponibile e annota il nome in un punto che controllerai nuovamente.

Verifica nuovamente le dimensioni prima del pull

Le dimensioni nella tabella sono state rilevate dalla pagina dei tag del modello il 16 August 2026 e un elenco di tag pubblicato non costituisce una garanzia. Leggi l’elenco aggiornato nella pagina del modello, quindi verifica cosa è stato effettivamente scritto sul disco:

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

Ollama memorizza i layer del modello come blob condivisi; pertanto, due tag che condividono un layer non raddoppiano lo spazio occupato sul disco. Confronta il valore riportato da du con la dimensione pubblicata e pianifica lo spazio su disco considerando il valore maggiore tra i due.

FAQ

Quanta RAM richiede Muse Glimmer su un VPS?

Parti dalle dimensioni del tag e aggiungi la finestra di contesto. Il tag predefinito occupa circa 18 GB al 16 agosto 2026, quindi una macchina da 16GB non può contenerlo e una macchina da 24GB lo contiene lasciando poco spazio al contesto. Considera questo valore come un punto di partenza, non come una risposta definitiva. Scarica il tag, caricalo una volta, quindi esegui ollama ps e free -h sulla tua macchina e leggi i valori effettivi. Un contesto più lungo e le richieste parallele aggiungono ulteriore consumo di memoria oltre ai pesi del modello.

Posso eseguire Muse Glimmer senza una GPU?

Sì. Il modello viene caricato ed eseguito rispondendo solo sulla CPU del VPS. La velocità di generazione è limitata dalla larghezza di banda della memoria, non dal numero di core. Su un host condiviso, inoltre, tale larghezza di banda è condivisa. A 4-bit, quindi, aspettati pochi token al secondo. Questa velocità è sufficiente per attività di agent eseguite in background senza supervisione, ma è poco adatta alla chat interattiva. Esegui ollama ps durante una richiesta e leggi la colonna del processore per verificare dove viene eseguito il lavoro.

I tag MLX sono utili su un VPS Linux?

No. Ogni tag che contiene mlx nel nome è compilato per il motore MLX di Ollama, il backend per Apple Silicon. Su un server Linux x86, questi tag occupano molto spazio per il download ma non possono essere eseguiti. Usa il tag 30b senza suffisso oppure uno degli altri tag non MLX, e ignora i benchmark per hardware Apple associati alle build MLX.

Perché il modello dimentica le informazioni molto prima di 128K token?

Perché la finestra di contesto predefinita di Ollama è di 4096 token, indipendentemente dalla quantità supportata dal modello. Il server tronca quindi le conversazioni lunghe prima che il modello possa vederle. Imposta OLLAMA_CONTEXT_LENGTH sul server, oppure /set parameter num_ctx per una singola sessione, oppure invia num_ctx nelle opzioni della richiesta API. Il consumo di memoria aumenta insieme a questo valore. Aumentalo quindi per gradi e controlla ollama ps ogni volta.

Devo fissare il tag o usare semplicemente latest?

Fissalo. muse-glimmer senza tag viene risolto in latest, che è un puntatore che il publisher può spostare in qualsiasi momento verso una build diversa. Un normale pull può quindi cambiare il modello eseguito dall'agent. Scrivi muse-glimmer:30b negli script, nei file unit e nella configurazione dell'agent. Controlla l'elenco dei tag nella pagina del modello prima di fissarne uno, perché i tag pubblicati possono cambiare.