Come Ollama gestisce le richieste parallele

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 le relative impostazioni).

Link rapidi: Cos’è OLLAMA_NUM_PARALLEL? · Ricette rapide di tuning · 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 ciascun 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 su 4 (o 1, a seconda della disponibilità di memoria), ma può essere modificato.

• Batching: Quando più richieste per lo stesso modello arrivano simultaneamente, Ollama le raggruppa in batch e le elabora insieme. Questo significa che entrambe le richieste vengono gestite in parallelo e gli utenti vedranno le risposte in streaming allo stesso tempo. Il server non aspetta 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_PARALLEL richieste per un modello), le richieste aggiuntive vengono messe in coda. La coda opera in modo FIFO (First-In, First-Out).

• Limiti della Coda: Il numero massimo di richieste in coda è controllato da OLLAMA_MAX_QUEUE (default: 512). Se la coda è piena, le nuove richieste ricevono un errore 503 che indica che il server è sovraccarico.

• Caricamento del Modello: 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 al caricamento del modello.

Scenario Esempio

Se due richieste per lo stesso modello arrivano allo stesso tempo e la parallelizzazione del server è impostata su almeno 2, entrambe le richieste verranno elaborate insieme in un batch e entrambi gli utenti riceveranno risposte in modo concorrente. Se la parallelizzazione è impostata su 1, una richiesta viene elaborata immediatamente e l’altra viene messa in coda fino al termine 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

In sintesi, Ollama è progettato per gestire molteplici richieste simultanee in modo efficiente, purché il server sia configurato per la concorrenza e abbia risorse sufficienti. Altrimenti, le richieste vengono messe in coda ed elaborate in ordine.

Se l’aumento di OLLAMA_NUM_PARALLEL non mantiene più la latenza stabile e la coda continua a crescere sotto traffico reale, questo è uno dei segnali più chiari da valutare rispetto al passaggio a un motore di serving dedicato. Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale illustra questa decisione, includendo il continuous batching e PagedAttention come meccanismi che vLLM utilizza per impedire che le richieste concorrenti si degradino a vicenda.

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 poste 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 (default: 512 richieste).
• Se la coda raggiunge la capacità, le nuove richieste ricevono errori 503 “Server Overloaded”.

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 (default: 3× numero di GPU o 3 per CPU).

Ottimizzazione della Memoria

• Tentativi di elaborare in batch le richieste per lo stesso modello 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 potrebbe:

• Passare alla swap su disco (degradando gravemente le prestazioni)
• Restituire errori “out of memory”
• Crashare l’istanza del modello in casi estremi

Gli amministratori dovrebbero monitorare l’uso della memoria e regolare questi parametri in base alle capacità del proprio hardware. La gestione della memoria insufficiente diventa cruciale quando si eseguono modelli più grandi (7B+ parametri) o si elaborano multiple richieste concorrenti.

Strategie di ottimizzazione 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: NVMe SSD per caricamento/scambio modelli più veloce
• GPU: NVIDIA RTX 3080/4090 con 16GB+ VRAM per modelli più grandi

Strategie Operative

• Batch delle Richieste: Elabora multiple query simultaneamente per ammortizzare l’overhead della memoria
• Scaricamento Automatico dei Modelli: Permette a Ollama di eliminare i modelli inattivi dalla memoria
• Cache dei Modelli Usati Frequentemente: Mantieni i modelli comuni residenti in memoria

Monitoraggio & Risoluzione dei Problemi

• Usa nvidia-smi (GPU) e htop (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 modelli caricati e richieste parallele
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

Queste regolazioni possono ridurre l’uso della memoria del 30-60% mantenendo la qualità della risposta, particolarmente benefiche 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 potrebbero aumentare la latenza e la pressione sulla memoria.
• Valori più bassi riducono la contesa e possono migliorare la stabilità, ma le richieste andranno in coda più spesso.

Come impostare OLLAMA_NUM_PARALLEL

Linux / macOS (servizio systemd o shell):

export OLLAMA_NUM_PARALLEL=2
ollama serve

Esecuzione one-off (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:

• Uso della VRAM GPU (OOM / eviction)
• Uso della CPU e load average
• Latenza p95 delle tue richieste tipiche
• Tasso di errore / timeout

Se stai ottimizzando una pagina specifica per l’uso CLI, consulta la sezione Ollama CLI nella guida rapida, più esempi di comandi per ollama serve, ollama ps e ollama run.

Ricette rapide di tuning

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 che 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 che OLLAMA_NUM_PARALLEL è troppo basso

• CPU/GPU è sottoutilizzata
• I ritardi di coda dominano il tempo totale di risposta

Suggerimento: Se controlli anche il tuo client, aggiungi retry con jitter e connessioni keep-alive. Molti problemi di “Ollama è lento” sono in realtà dovuti a code + overhead di connessione.

Ollama: Batching delle Richieste vs Esecuzione Parallela

Il Batching in Ollama si riferisce alla pratica di raggruppare più richieste in arrivo e elaborarle come un’unità. Questo permette un uso più efficiente delle risorse computazionali, specialmente quando si esegue su 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 ciascuna 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 Multiplo di Modelli: Se è disponibile memoria sufficiente, più modelli possono essere caricati e servire richieste simultaneamente.
• Richieste Parallele per Modello: Ciascun modello caricato può elaborare diverse richieste in parallelo, controllato dall’impostazione OLLAMA_NUM_PARALLEL (default è 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 l’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 guide alle prestazioni, controlla il nostro hub Prestazioni LLM: Benchmark, Colli di Bottiglia & Ottimizzazione.

Link Utili

• Guida Rapida ai Comandi Ollama
• Confronto prestazioni LLM - Ollama su GPU con 16GB VRAM
• Sposta Modelli Ollama su un’Altro Disco o Cartella
• Come Ollama usa le Core Performance ed Efficient dell’CPU Intel
• Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale