Come Ollama gestisce le richieste parallele

Questa guida spiega come Ollama gestisce le richieste parallele (concorrenza, code e limiti di risorse) e come configurarla utilizzando la variabile d’ambiente OLLAMA_NUM_PARALLEL (e parametri correlati).

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

Gli agenti multistep moltiplicano i retry quando il sampling è instabile; per le scelte predefinite di temperatura, top_p e penalità sui modelli di classe Qwen e Gemma, consulta Parametri di inferenza agentica per Qwen e Gemma.

Gestione delle Richieste Concurrenti

• 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), più modelli possono essere caricati simultaneamente 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ò gestire simultaneamente. Di default, questo valore è impostato a 4 (o 1, a seconda della disponibilità di memoria), ma può essere regolato.

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

Code e Limiti

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

• 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 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.

Esempio di Scenario

Se due richieste per lo stesso modello arrivano nello stesso momento e la parallelismo del server è impostata almeno a 2, entrambe le richieste verranno elaborate insieme in un batch e entrambi gli utenti riceveranno risposte in concomitanza. Se la parallelismo è 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

In sintesi, Ollama è progettata per gestire più richieste simultanee in modo efficiente, a condizione 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 l’aumento di OLLAMA_NUM_PARALLEL non mantiene più stabile la latenza e la coda continua a crescere sotto traffico reale, questo è uno dei segnali più chiari da valutare in vista del passaggio a un motore di serving specializzato. Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale esamina questa decisione, incluso il continuous batching e PagedAttention come meccanismi utilizzati da vLLM 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 entrata, impiega una combinazione di meccanismi di coda e strategie di gestione delle risorse per mantenere la stabilità:

Coda 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

• Cerca di elaborare in batch le richieste per lo stesso modello per massimizzare l’efficienza della memoria.
• Per l’inferenza GPU, è richiesta l’allocazione completa della VRAM per modello - i caricamenti parziali non sono supportati.

Scenari di Fallimento

Esondazione Critica della Memoria: Quando anche le richieste in coda superano le risorse disponibili, Ollama potrebbe:

• Eseguire la paging su disco (degradando gravemente le prestazioni)
• Ritornare errori “out of memory”
• In casi estremi, causare il crash dell’istanza del modello

Gli amministratori dovrebbero monitorare l’utilizzo della memoria e regolare questi parametri in base alle capacità hardware. La gestione della memoria insufficiente diventa cruciale quando si eseguono modelli più grandi (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 tramite export OLLAMA_NUM_THREADS=84. Miglioramenti Hardware

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

Strategie Operative

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

Monitoraggio e Troubleshooting

• 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 di swap

Esempio di workflow di ottimizzazione:

### 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

Queste regolazioni possono ridurre l’utilizzo della memoria del 30-60% mantenendo la qualità della risposta, particolarmente utile 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 determina in gran parte se vengono eseguite in concomitanza 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.

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 qualsiasi richiesta la utilizzi. Su una scheda da 16 GB, il calcolo di questo budget di solito conta più del comportamento della coda — consulta KV Cache su GPU da 16 GB per il budget VRAM completo e perché OLLAMA_NUM_PARALLEL=1 è solitamente il punto di partenza giusto per una singola sessione long-context.

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, quindi aumenta gradualmente monitorando:

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

Se stai ottimizzando una specifica pagina per l’uso da CLI, consulta la sezione Ollama CLI nella scheda rapida, oltre a esempi di comandi per ollama serve, ollama ps e ollama run.

Ricette rapide di tuning

Prima la Stabilità

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

Prima il Throughput

• OLLAMA_NUM_PARALLEL=2 (o più alto se hai margine)
• Considera il batching delle richieste a livello client
• Assicurati di avere VRAM e thread CPU sufficienti

“Mi finisce la VRAM quando arrivano due richieste”

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

Troubleshooting

Sintomi che OLLAMA_NUM_PARALLEL è troppo alto

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

Sintomi che OLLAMA_NUM_PARALLEL è troppo basso

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

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

Ollama: Batch delle Richieste vs Esecuzione Parallela

Il Batching in Ollama si riferisce alla pratica di raggruppare più richieste in entrata e elaborarle come un’unità. Ciò consente un utilizzo più efficiente delle risorse computazionali, soprattutto quando si esegue su hardware che beneficia da 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 per dimensione e complessità, poiché ciò consente una migliore utilizzazione dell’hardware.

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

Ollama supporta due livelli di parallelismo:

• Caricamento Multipli di Modelli: Se c’è abbastanza memoria disponibile, più modelli possono essere caricati e servire richieste simultaneamente.
• Richieste Parallele per Modello: Ciascun modello caricato può gestire 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 sia 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 essere eseguite in concomitanza. Entrambi i metodi dipendono dalla memoria del sistema e sono configurabili per prestazioni ottimali.

Per ulteriori benchmark, tuning della concorrenza e guida alle prestazioni, controlla il nostro hub LLM Performance: Benchmark, Colli di Bottiglia e Ottimizzazione.

Link Utili

• Scheda Rapida dei Comandi Ollama
• Confronto delle prestazioni LLM - Ollama su GPU 16GB VRAM
• Sposta i Modelli Ollama su un’unità o Cartella Diversa
• Come Ollama Utilizza i Core di Prestazione ed Efficienti della CPU Intel
• Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale