Come Ollama gestisce le richieste parallele

Questa guida spiega come Ollama gestisce le richieste parallele (concorrenza, code di attesa e limiti delle risorse) e come ottimizzarlo utilizzando la variabile d’ambiente OLLAMA_NUM_PARALLEL (e le relative impostazioni).

Link rapidi: Che cos’è OLLAMA_NUM_PARALLEL? · Ricette rapide di ottimizzazione · Come funziona la code di attesa · Risoluzione dei problemi · Correlato: Scheda rapida comandi Ollama CLI

Per maggiori dettagli su throughput, latenza, VRAM e benchmark tra runtime e hardware diversi, consulta Prestazioni LLM: Benchmark, Colli di Bottiglia e Ottimizzazione.

Gli agenti multi-passaggio moltiplicano i tentativi di ripetizione quando il campionamento è instabile; per le scelte predefinite su temperatura, top_p e penalità per i modelli di classe Qwen e Gemma, consulta Parametri di inferenza agentica per Qwen e Gemma.

Gestione delle richieste concorrenti

• Elaborazione Parallela: Ollama supporta l’elaborazione concorrente delle richieste. Se il sistema dispone di memoria disponibile sufficiente (RAM per l’inferenza CPU, VRAM per l’inferenza GPU), è possibile caricare più modelli 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 ciascun modello può elaborare simultaneamente. In modo predefinito, questo valore è impostato a 4 (oppure 1, a seconda della disponibilità della memoria), ma può essere regolato.

• Batching: Quando più richieste per lo stesso modello arrivano simultaneamente, Ollama le raggruppa in batch e le elabora insieme. Ciò significa che entrambe le richieste vengono gestite in parallelo e gli utenti vedranno le risposte che scorrono all’indietro nello stesso momento. Il server non attende intenzionalmente per riempire un batch; l’elaborazione inizia non appena le richieste sono disponibili.

Code di attesa e Limiti

• Code di Attesa: Se il numero di richieste concorrenti supera la parallelismo configurato (ad es., più di OLLAMA_NUM_PARALLEL richieste per un modello), le richieste aggiuntive vengono messe in coda. La coda opera secondo la logica first-in, first-out (FIFO).

• 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 indicando che il server è sovraccarico.

• Caricamento dei Modelli: Il numero di diversi modelli 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 sarà 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 parallelismo 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 parallelismo è impostata su 1, una richiesta viene elaborata immediatamente e l’altra viene messa in coda fino a quando la prima non è completata.

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 più richieste simultanee in modo efficiente, a patto che il server sia configurato per la concorrenza e disponga di risorse sufficienti. Altrimenti, le richieste vengono messe in coda e elaborate in ordine.

Se aumentare 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 a un passaggio a un motore di serving sviluppato appositamente. Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale illustra quella decisione, incluso 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 una memoria insufficiente per gestire le richieste in arrivo, utilizza una combinazione di meccanismi di code di attesa e strategie di gestione delle risorse per mantenere la stabilità:

Code di Attesa delle Richieste

• Le nuove richieste vengono inserite 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 concorrentemente è limitato da OLLAMA_MAX_LOADED_MODELS (predefinito: 3×numero di GPU o 3 per CPU).

Ottimizzazione della Memoria

• Tenta 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 carichi parziali non sono supportati.

Scenari di Fallimento

Esaustione Critica della Memoria: Quando anche le richieste in coda superano le risorse disponibili, Ollama può:

• Eseguire la paginazione su disco (degradando gravemente le prestazioni)
• Restituire errori “out of memory” (memoria esaurita)
• Crashare l’istanza del modello nei casi estremi

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

Strategie di ottimizzazione di Ollama

Abilita l’accelerazione GPU con export OLLAMA_CUDA=1 e imposta i thread CPU con export OLLAMA_NUM_THREADS=84. Miglioramenti Hardware

• RAM: 32GB+ per modelli 13B, 64GB+ per modelli 70B
• Archiviazione: SSD NVMe per un caricamento/switching più rapido dei modelli
• GPU: NVIDIA RTX 3080/4090 con 16GB+ di VRAM per modelli più grandi

Strategie Operative

• Batch delle Richieste: Elaborare più query simultaneamente per ammortizzare l’onere della memoria
• Scaricamento Automatico dei Modelli: Permette a Ollama di rimuovere i modelli inattivi dalla memoria
• Cache dei Modelli Frequentemente Usati: Mantenere i modelli comuni residenti in memoria

Monitoraggio e 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

Workflow di ottimizzazione di esempio:

### Usa un 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 larga misura se verranno eseguite in modo concorrente o messe in coda.

• Valori più alti possono aumentare il throughput se si ha 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.

La memoria, in particolare, scala con OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: quattro slot paralleli con un’impostazione di contesto di 32K riservano la KV cache come se fosse caricata una singola sequenza di 128K, anche prima che una richiesta la utilizzi. Su una scheda da 16 GB, quel calcolo di budget spesso conta più del comportamento della code di attesa — consulta KV Cache su GPU da 16 GB per il budget VRAM completo e il motivo per cui OLLAMA_NUM_PARALLEL=1 è di solito il punto di partenza giusto per una singola sessione con contesto lungo.

Come impostare OLLAMA_NUM_PARALLEL

Linux / macOS (servizio systemd o shell):

export OLLAMA_NUM_PARALLEL=2
ollama serve

Esecuzione una tantum (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, quindi aumenta gradualmente monitorando:

• Utilizzo della VRAM GPU (OOM / evictions)
• 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 scheda rapida, oltre agli esempi di comando per ollama serve, ollama ps e ollama run.

Ricette rapide di ottimizzazione

Priorità alla Stabilità

• OLLAMA_NUM_PARALLEL=1
• Usa modelli più piccoli / quantizzati
• Preferisci dimensioni di contesto più corte

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 si esaurisce la VRAM quando arrivano due richieste”

• Riduci OLLAMA_NUM_PARALLEL
• Usa un modello quantizzato in modo più aggressivo
• Riduci la lunghezza del contesto / token massimi

Risoluzione dei problemi

Sintomi che OLLAMA_NUM_PARALLEL è troppo alto

• Le richieste falliscono a intermittenza sotto carico
• GPU OOM / scaricamento del modello accade frequentemente
• Picchi di latenza quando arriva la seconda richiesta

Sintomi che OLLAMA_NUM_PARALLEL è troppo basso

• La CPU/GPU è sottoutilizzata
• I ritardi di code di attesa dominano il tempo di risposta totale

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

Ollama: Batch delle Richieste vs Esecuzione Parallela

Il batching in Ollama si riferisce alla pratica di raggruppare più richieste in arrivo insieme ed elaborarle come un’unità. Questo consente un uso più efficiente delle risorse di calcolo, 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 di matrice ottimizzate sul batch.

Il batching è particolarmente efficace quando le richieste sono simili in termini di dimensioni e complessità, poiché questo consente una migliore utilizzo dell’hardware.

L’esecuzione parallela in Ollama significa gestire più richieste nello stesso momento, sia per lo stesso modello che per modelli diversi, a seconda della memoria disponibile e della configurazione.

Ollama supporta due livelli di parallelismo:

• Caricamento Multi-Modello: Se c’è abbastanza memoria disponibile, diversi 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 (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 l’elaborazione simultanea, mentre l’esecuzione parallela consente a più richieste (o modelli) di funzionare in modo concorrente. Entrambi i metodi dipendono dalla memoria di sistema e sono configurabili per prestazioni ottimali.

Per maggiori benchmark, ottimizzazione della concorrenza e indicazioni sulle prestazioni, consulta il nostro hub Prestazioni LLM: Benchmark, Colli di Bottiglia e Ottimizzazione.

Link utili

• Scheda Rapida Comandi Ollama
• Confronto prestazioni LLM - Ollama su GPU con 16GB VRAM
• Sposta i Modelli Ollama su un Disco o Cartella Diversa
• Come Ollama utilizza le Core Performance ed Efficient dei CPU Intel
• Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale