# Ollama lento su Mac? Controlla caricamento, contesto e memoria

> Usa le informazioni di runtime e timing di Ollama per separare caricamento a freddo, dimensione del contesto e pressione sulla memoria, poi scarica i modelli inattivi senza eliminarli.

Published: 2026-10-22 | Updated: 2026-10-25

Ollama può essere lento perché un modello è ancora in caricamento, un prompt ha un contesto ampio, parte del modello è in esecuzione sulla CPU o il Mac è sotto pressione di memoria. Questi casi richiedono modifiche diverse. Eliminare i modelli scaricati può liberare spazio su disco, ma non rende automaticamente più veloce il modello che sta generando una risposta.

## Confronta il caricamento a freddo con una seconda richiesta

Mantieni lo stesso modello, prompt e impostazioni. Esegui una richiesta breve, poi ripetila mentre il modello rimane caricato. Se solo la prima richiesta è lenta, il caricamento è un indizio utile. Se entrambe generano lentamente, indaga l'esecuzione e la memoria. Registra il confronto invece di trattare una singola risposta come benchmark.

La [documentazione API](https://docs.ollama.com/api/generate) di Ollama espone campi di timing separati come `load_duration`, `prompt_eval_duration` e `eval_duration` nelle risposte completate. Questi distinguono caricamento, lettura del prompt e generazione dell'output. Non confrontare i tassi di token di modelli, dimensioni di contesto o prompt diversi come se misurassero un'unica modifica.

## Misura una singola richiesta locale per fase

Per un server locale sulla porta abituale, la seguente richiesta rende più facili da ispezionare i campi di temporizzazione restituendo una risposta JSON. Sostituisci `MODEL_NAME` con un modello locale già installato da `ollama list`; non usare un modello cloud per questo confronto. La richiesta esegue inferenza e consuma risorse, ma non elimina i dati del modello.

```bash
curl -sS http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_NAME","prompt":"Explain what a file cache does in two sentences.","stream":false,"options":{"num_predict":128}}'
```

Esegui di nuovo la stessa richiesta mentre il modello resta caricato. Con lo streaming disabilitato, il terminale mostra la risposta al completamento, quindi questo comando serve per i campi di temporizzazione restituiti, non per cronometrare a occhio il primo token. Se la richiesta fallisce, conserva il suo errore e interrompi il confronto invece di interpretare un campo mancante come zero.

| Campo restituito | Come usarlo |
| --- | --- |
| `load_duration` | Confronta il tempo di caricamento iniziale e quello ripetuto |
| `prompt_eval_count` e `prompt_eval_duration` | Vedi quanto input è stato elaborato e il suo costo |
| `eval_count` e `eval_duration` | Confronta la generazione di output per lo stesso carico di lavoro |
| `total_duration` | Mantieni il costo dell'intera richiesta accanto alle temporizzazioni dei componenti |

Le durate documentate sono in nanosecondi. Dividi una durata per 1.000.000.000 per ottenere i secondi. Per la velocità di output, dividi `eval_count` per `eval_duration / 1,000,000,000`, purché la durata sia positiva. Come esempio aritmetico, `100` token su `5,000,000,000` nanosecondi equivale a `20` token al secondo; non è un risultato misurato per alcun Mac o modello.

Non dividere i token di output per la durata totale e poi chiamarla velocità di generazione pura. Questo includerebbe il caricamento e il lavoro sull'input. Nota anche se il prompt ripetuto usa input in cache, perché una seconda richiesta più veloce può riflettere sia un modello caldo sia il riutilizzo del prompt. Conserva la risposta completa invece di riportare solo il numero più lusinghiero.

## Vedi cosa è effettivamente caricato

Nel Terminale, ispeziona lo stato corrente:

```
ollama ps
```

Le [FAQ di Ollama](https://docs.ollama.com/faq) spiegano la colonna `PROCESSOR`. Può mostrare GPU, CPU o una divisione. La [guida hardware](https://docs.ollama.com/gpu) documenta l'accelerazione Metal sulle GPU Apple. Se ti aspettavi che un modello locale usasse la GPU, il risultato in esecuzione è più utile di un'ipotesi basata sul nome del Mac.

Conferma anche che la richiesta stia andando al server locale che stai ispezionando. Un front end potrebbe puntare a un altro host o a un modello cloud. In quel caso, l'output locale di `ollama ps` non descrive la richiesta remota.

## Riduci il contesto prima di dare la colpa alla dimensione del modello

I file del modello sono solo una parte del requisito di memoria. Un contesto più grande richiede memoria aggiuntiva, e le richieste concorrenti aggiungono lavoro. La [documentazione sulla lunghezza del contesto](https://docs.ollama.com/context-length) di Ollama descrive i valori predefiniti dipendenti dall'hardware e il controllo del contesto dell'app. Non dare per scontato che ogni installazione abbia lo stesso valore predefinito.

Per un test controllato, usa un prompt breve, una sola richiesta e un contesto più piccolo che contenga comunque le informazioni necessarie per quel test. Se in seguito l'attività di coding completa richiede più contesto, ripristina quanto basta per preservarne il significato. Una risposta più veloce che perde silenziosamente istruzioni necessarie non è un'ottimizzazione riuscita.

Prova un modello più piccolo o una quantizzazione solo come confronto separato. Cambia sia l'uso delle risorse sia la qualità della risposta. Conserva alcune domande rappresentative per valutare se l'opzione più veloce rimane utile.

## Prova un cambio di contesto senza renderlo permanente

Per un breve prompt diagnostico, l'API accetta un'opzione di contesto per richiesta. Nella richiesta precedente, aggiungi `"num_ctx":4096` dentro `options` accanto a `num_predict`, usando un modello locale che supporti quel contesto. Questa è una dimensione di test di esempio, non un'impostazione consigliata per ogni modello o attività di programmazione.

Mantieni invariati modello e prompt, poi ispeziona il modello in esecuzione con `ollama ps` e confronta la pressione memoria. Non ridurre il contesto attorno a una conversazione lunga e dare per scontato che la risposta includa ancora ogni istruzione. Confronta prima una piccola attività che rientra; in seguito prova il carico di lavoro reale con contesto sufficiente per i suoi input.

Le FAQ e la pagina dedicata alla lunghezza del contesto descrivono i valori predefiniti in modo diverso, quindi questa guida non si basa su un valore predefinito universale. Anche un'impostazione dell'app, un front end o un'opzione a livello di richiesta possono influire sul valore in esecuzione. Dove la versione installata riporta `CONTEXT` in `ollama ps`, registra quel valore accanto a `PROCESSOR` invece di dedurlo dalla dimensione del file del modello.

Una lettura di memoria più bassa non è l'unica condizione di successo. L'attività deve comunque completarsi con risposte accettabili, e il resto del Mac deve rimanere utilizzabile. Se un contesto più piccolo perde fatti importanti o la modifica non produce alcuna differenza ripetibile, rimuovi l'opzione di test e ripristina la configurazione funzionante precedente.

## Osserva l'intero Mac durante la generazione

Apri **Monitoraggio Attività › Memoria** e osserva la pressione mentre generi, non solo dopo che la risposta è terminata. Apple Silicon usa memoria di sistema condivisa, quindi contano anche le altre app. Un modello che entra nel disco non dimostra che si adatti comodamente al resto del tuo carico di lavoro.

Salva il lavoro e chiudi un'attività pesante non necessaria, poi ripeti la stessa richiesta. Se la pressione migliora e il rallentamento cambia di conseguenza, hai un indizio utile. La [guida sulla pressione di memoria](https://mole.fit/it/blog/mac-memory-pressure-explained) spiega come leggere gli indicatori del Mac senza trattare ogni byte in cache come sprecato.

## Scarica un modello inattivo senza eliminarlo

Prima attendi che qualsiasi richiesta che usa il modello sia terminata. Per rilasciare un modello caricato che non ti serve più, usa `ollama stop` seguito dal suo nome esatto da `ollama ps`:

```
ollama stop MODEL_NAME
```

Sostituisci `MODEL_NAME` prima di eseguire il comando. Questo scarica il modello dalla memoria. Non elimina i suoi file scaricati, e la richiesta successiva potrebbe pagare di nuovo il costo di caricamento. Scaricare ripetutamente un modello tra una richiesta e l'altra può quindi rendere l'esperienza più lenta.

Se lo spazio su disco è il vero vincolo, esamina i modelli memorizzati separatamente nella [guida alla pulizia dei modelli AI](https://mole.fit/it/blog/how-to-remove-ai-tool-leftovers-mac). Conserva i modelli creati localmente e tutto ciò che non puoi scaricare di nuovo in modo affidabile. Per le prestazioni, confronta una modifica alla volta e mantieni il risultato legato allo stesso carico di lavoro.
## Indaga una discrepanza con il log del server

Se la richiesta locale resta lenta o la suddivisione del processore è inaspettata, la [guida alla risoluzione dei problemi](https://docs.ollama.com/troubleshooting) di Ollama individua il log del server Mac in `~/.ollama/logs/server.log`. Leggi la porzione attorno al momento del test e cerca errori di caricamento, problemi di allocazione della memoria o il backend di esecuzione selezionato. Per un server avviato manualmente, i messaggi corrispondenti possono trovarsi invece nel suo terminale.

Registra la versione di Ollama, il tag esatto del modello, il contesto, la suddivisione del processore e la fase che domina le temporizzazioni. Rivedi gli estratti del log per prompt privati e percorsi locali prima di condividerli. Non cambiare diverse variabili d'ambiente della GPU o del server solo perché compaiono in un vecchio post di ottimizzazione; il log dovrebbe prima identificare la discrepanza che una modifica intende risolvere.

---

Canonical HTML page: https://mole.fit/it/blog/ollama-slow-on-mac
Blog index for agents: https://mole.fit/it/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt