Come Ollama gestisce le richieste parallele

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

Collegamenti rapidi: Cos’è OLLAMA_NUM_PARALLEL? · Ricette di tuning rapide · Come funziona la coda · Risoluzione dei problemi · Correlato: Scheda comandi CLI Ollama

Per ulteriori informazioni su throughput, latenza, VRAM e benchmark tra runtime e hardware diversi, consulta LLM Performance: Benchmarks, Colli di Bottiglia & Ottimizzazione.

Gli agenti multi-step moltiplicano i tentativi quando il sampling è instabile; per le scelte predefinite di temperatura, top_p e penalità su modelli della classe Qwen e Gemma, consulta 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 abbastanza memoria disponibile (RAM per l’inferenza su CPU, VRAM per l’inferenza su GPU), è possibile caricare più modelli contemporaneamente e ciascun modello caricato può gestire diverse richieste in parallelo. Ciò è controllato dalla variabile d’ambiente OLLAMA_NUM_PARALLEL, che imposta il numero massimo di richieste parallele che ciascun modello può elaborare simultaneamente. Di default, questo valore è impostato a 4 (o 1, a seconda della disponibilità di memoria), ma può essere adattato.

• Batching: Quando diverse 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 fluire in streaming nello stesso momento. Il server non aspetta intenzionalmente di riempire un batch; l’elaborazione inizia non appena le richieste sono disponibili.

Coda e Limiti

• Coda: Se il numero di richieste concorrenti supera la parallelità configurata (ad es., più di OLLAMA_NUM_PARALLEL richieste per un modello), le richieste aggiuntive vanno in coda. La coda opera con la policy 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 liberare spazio e la richiesta andrà in coda finché il modello non viene caricato.

Esempio di Scenario

Se due richieste per lo stesso modello arrivano nello stesso momento e la parallelità del server è impostata ad almeno 2, entrambe le richieste verranno elaborate insieme in un batch e entrambi gli utenti riceveranno risposte in modo concorrente. Se la parallelità è impostata a 1, una richiesta viene elaborata immediatamente e l’altra va in coda finché la prima non termina.

Se le richieste sono per modelli diversi e c’è abbastanza memoria, entrambi i modelli possono essere caricati e le richieste gestite in parallelo. In caso contrario, potrebbe essere necessario scaricare un modello e la richiesta andrà in coda.

Tabella Riassuntiva

In sintesi, Ollama è progettato per gestire molte richieste simultanee in modo efficiente, a condizione che il server sia configurato per la concorrenza e disponga di risorse sufficienti. Altrimenti, le richieste verranno messe in coda e elaborate in ordine.

Se l’aumento di OLLAMA_NUM_PARALLEL non riesce più a mantenere stabile la latenza e la coda continua a crescere sotto traffico reale, questo è uno dei segnali più chiari da valutare per passare a un motore di serving costruito ad hoc. Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale illustra questa decisione, incluso il continuous batching e PagedAttention come meccanismi che vLLM utilizza per impedire che le richieste concorrenti degradino reciprocamente le prestazioni.

Gestione della Memoria Insufficiente

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à:

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

Gestione dei Modelli

• I modelli attivi potrebbero 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 su 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:

• Esercitare la paginazione su disco (degradando gravemente le prestazioni)
• Restituire errori “out of memory”
• Far 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 più grandi (7B+ parametri) o si elaborano molte richieste concorrenti.

Strategie di ottimizzazione per Ollama

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

• RAM: 32GB+ per modelli 13B, 64GB+ per modelli 70B
• Storage: SSD NVMe per un caricamento/sostituzione 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’overhead della memoria
• Scaricamento Automatico dei Modelli: Permette a Ollama di espurgare i modelli inattivi dalla memoria
• Cache dei Modelli Usati Frequentemente: Mantenere i modelli comuni residenti in memoria

Monitoraggio & Risoluzione Problemi

• Usa nvidia-smi (GPU) e htop (CPU/RAM) per identificare i colli di bottiglia
• Per errori di memoria:
• Passare a modelli quantizzati
• Ridurre le richieste concorrenti
• Aumentare lo spazio di 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

Queste regolazioni possono ridurre l’utilizzo della memoria del 30-60% mantenendo la qualità delle risposte, particolarmente benefico quando si eseguono più modelli o si gestiscono volumi di richieste elevati.

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 vengono eseguite in modo concorrente o se vanno 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 andranno in coda più spesso.

La memoria, in particolare, scala con OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: quattro slot paralleli con un’impostazione di contesto da 32K riservano la KV cache come se fosse caricata una singola sequenza da 128K, anche prima che una 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 completo di VRAM e perché OLLAMA_NUM_PARALLEL=1 è solitamente il punto di partenza corretto per una singola sessione a lungo contesto.

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

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

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

Ricette di tuning rapide

Priorità alla stabilità

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

Priorità al 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 si esaurisce 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 in modo intermittente sotto carico
• GPU OOM / 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 della coda dominano il tempo di risposta totale

Suggerimento: Se controlli anche il tuo client, aggiungi retry con jitter e connessioni keep-alive. Molti problemi di “Ollama è lento” sono in realtà code + 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 per dimensione e complessità, poiché questo consente una migliore utilizzazione dell’hardware.

L’esecuzione parallela in Ollama significa gestire più richieste simultaneamente, 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 è 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 molte richieste in modo efficiente. Il batching raggruppa le richieste per un’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 ulteriori benchmark, tuning della concorrenza e guida sulle prestazioni, consulta il nostro hub LLM Performance: Benchmarks, Colli di Bottiglia & Ottimizzazione.

Collegamenti utili

• Scheda comandi Ollama
• Confronto prestazioni LLM - Ollama su GPU VRAM 16GB
• Spostare i Modelli Ollama su un’Unità o Cartella Diversa
• Come Ollama utilizza le Core Performance e Efficient della CPU Intel
• Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale