Come Ollama gestisce le richieste parallele
Comprendi la concorrenza, la gestione delle code in Ollama e come ottimizzare OLLAMA_NUM_PARALLEL per richieste parallele stabili.
Questa guida spiega come Ollama gestisce le richieste parallele (concorrenza, code e limiti delle risorse) e come ottimizzarla utilizzando la variabile d’ambiente OLLAMA_NUM_PARALLEL (e i relativi parametri).
Link rapidi: Cos’è OLLAMA_NUM_PARALLEL? · Ricette di tuning rapide · Come funziona la coda · Risoluzione dei problemi · Correlato: Guida rapida ai comandi CLI di Ollama
Per ulteriori informazioni su throughput, latenza, VRAM e benchmark tra diversi runtime e hardware, consulta Prestazioni LLM: Benchmark, Colli di Bottiglia & Ottimizzazione.
Gli agenti multi-step moltiplicano i tentativi quando il campionamento è instabile; per le impostazioni predefinite di temperatura, top_p e penalità sui modelli di classe Qwen e Gemma, consulta i parametri di inferenza agentic per Qwen e Gemma.

Gestione delle Richieste Concorrenti
-
Elaborazione Parallela: Ollama supporta l’elaborazione concorrente delle richieste. Se il sistema ha memoria sufficiente disponibile (RAM per l’inferenza CPU, VRAM per l’inferenza GPU), più modelli possono essere caricati contemporaneamente e ogni modello caricato può gestire diverse richieste in parallelo. Questo è controllato dalla variabile d’ambiente
OLLAMA_NUM_PARALLEL, che imposta il numero massimo di richieste parallele che ogni modello può elaborare simultaneamente. Di default, questo valore è impostato a 4 (o 1, a seconda della disponibilità di memoria), ma può essere modificato. -
Batching (Raggruppamento): Quando più richieste per lo stesso modello arrivano simultaneamente, Ollama le raggruppa (batch) e le elabora insieme. Ciò significa che entrambe le richieste vengono gestite in parallelo e gli utenti vedranno le risposte trasmesse in streaming allo stesso tempo. Il server non attende intenzionalmente che un batch sia pieno; l’elaborazione inizia non appena le richieste sono disponibili.
Code e Limiti
-
Code: Se il numero di richieste concorrenti supera la parallelizzazione configurata (ad esempio, più di
OLLAMA_NUM_PARALLELrichieste per un modello), le richieste aggiuntive vengono messe in coda. La coda opera in modalità FIFO (First-In, First-Out, primo arrivato primo servito). -
Limiti della Coda: Il numero massimo di richieste in coda è controllato da
OLLAMA_MAX_QUEUE(predefinito: 512). Se la coda è piena, le nuove richieste ricevono un errore 503 che indica che il server è sovraccarico. -
Caricamento dei Modelli: Il numero di modelli diversi che possono essere caricati contemporaneamente è controllato da
OLLAMA_MAX_LOADED_MODELS. Se una richiesta richiede il caricamento di un nuovo modello e la memoria è insufficiente, Ollama scaricherà i modelli inattivi per fare spazio e la richiesta verrà messa in coda fino a quando il modello non sarà caricato.
Scenario Esempio
Se due richieste per lo stesso modello arrivano nello stesso momento e la parallelizzazione del server è impostata almeno a 2, entrambe le richieste verranno elaborate insieme in un batch e entrambi gli utenti riceveranno le risposte in modo concorrente. Se la parallelizzazione è impostata a 1, una richiesta viene elaborata immediatamente e l’altra viene messa in coda fino al completamento della prima.
Se le richieste sono per modelli diversi e c’è memoria sufficiente, entrambi i modelli possono essere caricati e le richieste gestite in parallelo. In caso contrario, potrebbe essere necessario scaricare un modello e la richiesta verrà messa in coda.
Tabella Riassuntiva
| Scenario | Risultato |
|---|---|
| Due richieste, stesso modello, parallelizzazione sufficiente | Entrambe elaborate insieme in parallelo (batch) |
| Due richieste, stesso modello, parallelizzazione=1 | Una elaborata, la seconda in coda fino al completamento della prima |
| Due richieste, modelli diversi, memoria sufficiente | Entrambi i modelli caricati, richieste gestite in parallelo |
| Due richieste, modelli diversi, memoria insufficiente | Una in coda fino a quando la memoria è disponibile o un modello viene scaricato |
In sintesi, Ollama è progettato per gestire molteplici richieste simultanee in modo efficiente, purché il server sia configurato per la concorrenza e disponga di risorse sufficienti. Altrimenti, le richieste vengono messe in coda ed elaborate in ordine.
Gestione dell’Insufficienza di Memoria
Quando Ollama incontra memoria insufficiente per gestire le richieste in arrivo, impiega una combinazione di meccanismi di code e strategie di gestione delle risorse per mantenere la stabilità:
Code delle Richieste
- Le nuove richieste vengono posizionate in una coda FIFO (First-In, First-Out) quando la memoria non può essere allocata immediatamente.
- La dimensione della coda è controllata da OLLAMA_MAX_QUEUE (predefinito: 512 richieste).
- Se la coda raggiunge la capacità, le nuove richieste ricevono errori 503 “Server Overloaded” (Server Sovraccarico).
Gestione dei Modelli
- I modelli attivi possono essere scaricati dalla memoria quando diventano inattivi per liberare risorse per le richieste in coda.
- Il numero di modelli caricati contemporaneamente è limitato da OLLAMA_MAX_LOADED_MODELS (predefinito: 3× numero di GPU o 3 per CPU).
Ottimizzazione della Memoria
- Tenta di elaborare le richieste per lo stesso modello in batch per massimizzare l’efficienza della memoria.
- Per l’inferenza GPU, richiede l’allocazione completa della VRAM per modello - i caricamenti parziali non sono supportati.
Scenari di Fallimento
Esaurimento Critico della Memoria: Quando anche le richieste in coda superano le risorse disponibili, Ollama può:
- Eseguire paging su disco (degradando severamente le prestazioni)
- Restituire errori “out of memory” (memoria esaurita)
- Causare il crash dell’istanza del modello in casi estremi
| Impostazione Controlli di Configurazione | Scopo | Valore Predefinito |
|---|---|---|
| OLLAMA_MAX_QUEUE | Richieste in coda massime | 512 |
| OLLAMA_NUM_PARALLEL | Richieste parallele per modello caricato | 4 (o 1 se limitato) |
| OLLAMA_MAX_LOADED_MODELS | Modelli caricati contemporaneamente massimi | 3× numero di GPU o 3 |
Gli amministratori dovrebbero monitorare l’utilizzo della memoria e regolare questi parametri in base alle capacità del proprio hardware. La gestione dell’insufficienza di memoria diventa cruciale quando si eseguono modelli più grandi (7B+ parametri) o si elaborano molteplici richieste concorrenti.
Strategie di ottimizzazione di Ollama
Abilita l’accelerazione GPU con export OLLAMA_CUDA=1 e imposta i thread CPU tramite export OLLAMA_NUM_THREADS=84.
Miglioramenti Hardware
- RAM: 32GB+ per modelli 13B, 64GB+ per modelli 70B
- Archiviazione: SSD NVMe per un caricamento/scambio dei modelli più veloce
- GPU: NVIDIA RTX 3080/4090 con 16GB+ VRAM per modelli più grandi
Strategie Operative
- Richieste in Batch: Elabora più query simultaneamente per ammortizzare il sovraccarico della memoria
- Scaricamento Automatico dei Modelli: Permette a Ollama di rimuovere i modelli inattivi dalla memoria
- Cache dei Modelli Usati Frequentemente: Mantieni i modelli comuni residenti in memoria
Monitoraggio e Risoluzione dei Problemi
- Usa
nvidia-smi(GPU) ehtop(CPU/RAM) per identificare i colli di bottiglia - Per errori di memoria:
- Passa a modelli quantizzati
- Riduci le richieste concorrenti
- Aumenta lo spazio swap
Esempio di workflow di ottimizzazione:
### Usa modello quantizzato con accelerazione GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048
### Limita i modelli caricati e le richieste parallele
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4
Questi aggiustamenti possono ridurre l’utilizzo della memoria del 30-60% mantenendo la qualità della risposta, particolarmente benefico quando si eseguono più modelli o si gestiscono volumi elevati di richieste.
Variabile d’ambiente OLLAMA_NUM_PARALLEL
OLLAMA_NUM_PARALLEL controlla quante richieste Ollama eseguirà in parallelo. Se invii più richieste allo stesso server Ollama, questa impostazione decide in gran parte se verranno eseguite in concorrenza o messe in coda.
- Valori più alti possono aumentare il throughput se hai abbastanza CPU/GPU/VRAM, ma possono aumentare la latenza e la pressione sulla memoria.
- Valori più bassi riducono la contesa e possono migliorare la stabilità, ma le richieste verranno messe in coda più spesso.
Come impostare OLLAMA_NUM_PARALLEL
Linux / macOS (servizio systemd o shell):
export OLLAMA_NUM_PARALLEL=2
ollama serve
Esecuzione singola (prefisso solo per questo comando):
OLLAMA_NUM_PARALLEL=2 ollama serve
Docker (esempio):
docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama
Come scegliere un valore
Inizia con 1–2 per una singola GPU / VRAM limitata, poi aumenta gradualmente monitorando:
- Utilizzo della VRAM GPU (OOM / espulsioni)
- Utilizzo della CPU e load average
- Latenza p95 delle tue tipiche richieste
- Tasso di errore / timeout
Se stai ottimizzando una pagina specifica per l’uso della CLI, consulta la sezione Ollama CLI nella guida rapida, oltre agli esempi di comando per
ollama serve,ollama pseollama run.
Ricette di tuning rapide
Priorità alla Stabilità
OLLAMA_NUM_PARALLEL=1- Usa modelli più piccoli / quantizzati
- Preferisci dimensioni del contesto più brevi
Priorità al Throughput
OLLAMA_NUM_PARALLEL=2(o superiore se hai margine)- Considera il batching delle richieste a livello client
- Assicurati di avere VRAM e thread CPU sufficienti
“Mi manca la VRAM quando arrivano due richieste”
- Riduci
OLLAMA_NUM_PARALLEL - Usa un modello più aggressivamente quantizzato
- Riduci la lunghezza del contesto / token massimi
Risoluzione dei Problemi
Sintomi di OLLAMA_NUM_PARALLEL troppo alto
- Le richieste falliscono intermittente sotto carico
- OOM GPU / scaricamento del modello avviene frequentemente
- Picchi di latenza quando arriva la seconda richiesta
Sintomi di OLLAMA_NUM_PARALLEL troppo basso
- CPU/GPU sottoutilizzati
- I ritardi di code dominano il tempo di risposta totale
Suggerimento: Se controlli anche il tuo client, aggiungi ritentativi con jitter e connessioni keep-alive. Molti problemi di “Ollama è lento” sono in realtà dovuti a code + sovraccarico delle connessioni.
Ollama: Richieste in Batch vs Esecuzione Parallela
Il Batching in Ollama si riferisce alla pratica di raggruppare più richieste in arrivo ed elaborarle come un’unità. Questo consente un uso più efficiente delle risorse computazionali, specialmente quando si utilizza hardware che beneficia di operazioni parallelizzate (come le GPU).
Quando più richieste per lo stesso modello arrivano simultaneamente, Ollama può elaborarle insieme in un batch se la memoria lo consente. Questo aumenta il throughput e può ridurre la latenza per ogni richiesta, poiché il modello può sfruttare operazioni matriciali ottimizzate sul batch.
Il batching è particolarmente efficace quando le richieste sono simili per dimensione e complessità, poiché questo permette una migliore utilizzazione dell’hardware.
L’esecuzione parallela in Ollama significa gestire più richieste allo stesso tempo, sia per lo stesso modello che per modelli diversi, a seconda della memoria disponibile e della configurazione.
Ollama supporta due livelli di parallelismo:
- Caricamento Multipli Modelli: Se è disponibile memoria sufficiente, diversi modelli possono essere caricati e servire richieste simultaneamente.
- Richieste Parallele per Modello: Ogni modello caricato può elaborare diverse richieste in parallelo, controllato dall’impostazione OLLAMA_NUM_PARALLEL (il predefinito è 1 o 4, a seconda della memoria).
Quando le richieste superano il limite di parallelismo, vengono messe in coda (FIFO) fino a OLLAMA_MAX_QUEUE.
Conclusione
Ollama sfrutta sia il batching che l’esecuzione parallela per elaborare più richieste in modo efficiente. Il batching raggruppa le richieste per un’elaborazione simultanea, mentre l’esecuzione parallela permette a più richieste (o modelli) di girare in concorrenza. Entrambi i metodi dipendono dalla memoria di sistema e sono configurabili per prestazioni ottimali.
Per ulteriori benchmark, tuning della concorrenza e indicazioni sulle prestazioni, consulta il nostro hub Prestazioni LLM: Benchmark, Colli di Bottiglia & Ottimizzazione.