Comment Ollama gère les requêtes parallèles

Ce guide explique comment Ollama gère les demandes parallèles (concurrency, mise en file d’attente et limites de ressources), et comment l’optimiser à l’aide de la variable d’environnement OLLAMA_NUM_PARALLEL (et des réglages associés).

Liens rapides : Qu’est-ce que OLLAMA_NUM_PARALLEL ? · Recettes d’optimisation rapide · Fonctionnement de la mise en file d’attente · Dépannage · Voir aussi : Aide-mémoire des commandes CLI Ollama

Pour en savoir plus sur le débit, la latence, la VRAM et les benchmarks à travers les différents environnements d’exécution et matériels, consultez Performance des LLM : Benchmarks, Goulots d’étranglement et Optimisation.

Les agents multi-étapes multiplient les nouveaux essais lorsque l’échantillonnage est instable ; pour les choix par défaut de température, top_p et de pénalités sur les modèles de type Qwen et Gemma, consultez Paramètres de déduction agentique pour Qwen et Gemma.

Traitement des demandes simultanées

• Traitement parallèle : Ollama prend en charge le traitement simultané des demandes. Si le système dispose de mémoire suffisante (RAM pour l’inférence CPU, VRAM pour l’inférence GPU), plusieurs modèles peuvent être chargés à la fois, et chaque modèle chargé peut gérer plusieurs demandes en parallèle. Cela est contrôlé par la variable d’environnement OLLAMA_NUM_PARALLEL, qui définit le nombre maximal de demandes parallèles que chaque modèle peut traiter simultanément. Par défaut, cela est fixé à 4 (ou 1, selon la disponibilité de la mémoire), mais peut être ajusté.

• Regroupement (Batching) : Lorsque plusieurs demandes pour le même modèle arrivent simultanément, Ollama les regroupe et les traite ensemble. Cela signifie que les deux demandes sont traitées en parallèle et que les utilisateurs verront les réponses s’afficher en flux à la même heure. Le serveur n’attend pas intentionnellement pour remplir un lot ; le traitement commence dès que les demandes sont disponibles.

File d’attente et limites

• Mise en file d’attente : Si le nombre de demandes simultanées dépasse le parallélisme configuré (par ex., plus de OLLAMA_NUM_PARALLEL demandes pour un modèle), les demandes supplémentaires sont mises en file d’attente. La file d’attente fonctionne selon le principe premier entré, premier sorti (FIFO).

• Limites de file d’attente : Le nombre maximal de demandes en file d’attente est contrôlé par OLLAMA_MAX_QUEUE (par défaut : 512). Si la file d’attente est pleine, les nouvelles demandes reçoivent une erreur 503 indiquant que le serveur est surchargé.

• Chargement des modèles : Le nombre de modèles différents qui peuvent être chargés en même temps est contrôlé par OLLAMA_MAX_LOADED_MODELS. Si une demande nécessite le chargement d’un nouveau modèle et que la mémoire est insuffisante, Ollama déchargera les modèles inactifs pour faire de la place, et la demande sera mise en file d’attente jusqu’à ce que le modèle soit chargé.

Scénario d’exemple

Si deux demandes pour le même modèle arrivent en même temps et que le parallélisme du serveur est réglé sur au moins 2, les deux demandes seront traitées ensemble dans un lot, et les deux utilisateurs recevront des réponses simultanément. Si le parallélisme est réglé sur 1, une demande est traitée immédiatement, et l’autre est mise en file d’attente jusqu’à ce que la première soit terminée.

Si les demandes concernent des modèles différents et qu’il y a suffisamment de mémoire, les deux modèles peuvent être chargés et les demandes gérées en parallèle. Sinon, un modèle peut devoir être déchargé, et la demande sera mise en file d’attente.

Tableau récapitulatif

En résumé, Ollama est conçu pour traiter efficacement plusieurs demandes simultanées, à condition que le serveur soit configuré pour la concurrence et dispose de ressources suffisantes. Sinon, les demandes sont mises en file d’attente et traitées dans l’ordre.

Si l’augmentation de OLLAMA_NUM_PARALLEL ne maintient plus la latence stable et que la file d’attente continue de croître sous le trafic réel, c’est l’un des signaux plus clairs à considérer par rapport à un passage vers un moteur de service conçu à cet effet. D’Ollama à vLLM : Quand migrer votre serveur LLM local passe en revue cette décision, y compris le regroupement continu et PagedAttention comme mécanismes que vLLM utilise pour empêcher les demandes simultanées de se dégrader mutuellement.

Gestion de l’insuffisance de mémoire

Lorsque Ollama rencontre une mémoire insuffisante pour traiter les demandes entrantes, il met en œuvre une combinaison de mécanismes de mise en file d’attente et de stratégies de gestion des ressources pour maintenir la stabilité :

Mise en file d’attente des demandes

• Les nouvelles demandes sont placées dans une file FIFO (First-In, First-Out) lorsque la mémoire ne peut pas être allouée immédiatement.
• La taille de la file d’attente est contrôlée par OLLAMA_MAX_QUEUE (par défaut : 512 demandes).
• Si la file d’attente atteint sa capacité, les nouvelles demandes reçoivent des erreurs 503 “Server Overloaded”.

Gestion des modèles

• Les modèles actifs peuvent être déchargés de la mémoire lorsqu’ils deviennent inactifs pour libérer des ressources pour les demandes en file d’attente.
• Le nombre de modèles chargés simultanément est limité par OLLAMA_MAX_LOADED_MODELS (par défaut : 3× le nombre de GPU ou 3 pour CPU).

Optimisation de la mémoire

• Tente de traiter les demandes pour le même modèle par lots pour maximiser l’efficacité de la mémoire.
• Pour l’inférence GPU, nécessite une allocation complète de VRAM par modèle - les chargements partiels ne sont pas pris en charge.

Scénarios d’échec

Épuisement critique de la mémoire : Lorsque même les demandes en file d’attente dépassent les ressources disponibles, Ollama peut :

• Écrire sur le disque (dégradation sévère des performances)
• Retourner des erreurs “out of memory”
• Faire planter l’instance du modèle dans des cas extrêmes

Les administrateurs doivent surveiller l’utilisation de la mémoire et ajuster ces paramètres en fonction de leurs capacités matérielles. La gestion de la mémoire insuffisante devient cruciale lors de l’exécution de modèles plus grands (7B+ paramètres) ou du traitement de plusieurs demandes simultanées.

Stratégies d’optimisation d’Ollama

Activez l’accélération GPU avec export OLLAMA_CUDA=1 et définissez les threads CPU via export OLLAMA_NUM_THREADS=84. Améliorations matérielles

• RAM : 32Go+ pour les modèles 13B, 64Go+ pour les modèles 70B
• Stockage : SSD NVMe pour un chargement/décrochage plus rapide des modèles
• GPU : NVIDIA RTX 3080/4090 avec 16Go+ de VRAM pour les modèles plus grands

Stratégies opérationnelles

• Demandes par lots : Traitez plusieurs requêtes simultanément pour amortir le surcoût mémoire
• Déchargement automatique des modèles : Permet à Ollama de purger les modèles inactifs de la mémoire
• Mise en cache des modèles fréquemment utilisés : Conservez les modèles communs résidents en mémoire

Surveillance et dépannage

• Utilisez nvidia-smi (GPU) et htop (CPU/RAM) pour identifier les goulots d’étranglement
• Pour les erreurs de mémoire :
• Passez à des modèles quantifiés
• Réduisez les demandes simultanées
• Augmentez l’espace d’échange (swap)

Exemple de flux de travail d’optimisation :

### Utilisez un modèle quantifié avec accélération GPU
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### Limitez les modèles chargés et les demandes parallèles
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

Ces ajustements peuvent réduire l’utilisation de la mémoire de 30 à 60 % tout en maintenant la qualité de la réponse, ce qui est particulièrement bénéfique lors de l’exécution de plusieurs modèles ou du traitement de volumes de demandes élevés.

Variable d’environnement OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL contrôle le nombre de demandes qu’Ollama exécutera en parallèle. Si vous envoyez plusieurs demandes au même serveur Ollama, ce réglage détermine largement si elles s’exécutent simultanément ou sont mises en file d’attente.

• Des valeurs plus élevées peuvent augmenter le débit si vous avez suffisamment de CPU/GPU/VRAM, mais peuvent augmenter la latence et la pression sur la mémoire.
• Des valeurs plus basses réduisent la concurrence et peuvent améliorer la stabilité, mais les demandes seront mises en file d’attente plus souvent.

La mémoire, en particulier, est proportionnelle à OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH : quatre créneaux parallèles avec un réglage de contexte de 32K réservent la cache KV comme si une seule séquence de 128K était chargée, même avant qu’aucune demande ne l’utilise. Sur une carte de 16 Go, ce calcul budgétaire compte souvent plus que le comportement de la file d’attente — voir Cache KV sur GPU 16 Go pour le budget VRAM complet et pourquoi OLLAMA_NUM_PARALLEL=1 est généralement le bon point de départ pour une session unique de long contexte.

Comment définir OLLAMA_NUM_PARALLEL

Linux / macOS (service systemd ou shell) :

export OLLAMA_NUM_PARALLEL=2
ollama serve

Exécution unique (préfixe uniquement pour cette commande) :

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker (exemple) :

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

Comment choisir une valeur

Commencez par 1–2 pour un GPU unique / VRAM limitée, puis augmentez progressivement en surveillant :

• Utilisation de la VRAM GPU (OOM / évictions)
• Utilisation du CPU et charge moyenne
• Latence p95 de vos demandes typiques
• Taux d’erreur / dépassement de délai

Si vous optimisez une page spécifique pour l’utilisation CLI, consultez la section CLI Ollama dans l’aide-mémoire, ainsi que des exemples de commandes pour ollama serve, ollama ps et ollama run.

Recettes d’optimisation rapide

Stabilité d’abord

• OLLAMA_NUM_PARALLEL=1
• Utilisez des modèles plus petits / quantifiés
• Préférez des tailles de contexte plus courtes

Débit d’abord

• OLLAMA_NUM_PARALLEL=2 (ou plus si vous avez de la marge)
• Envisagez le regroupement des demandes au niveau client
• Assurez-vous de disposer de VRAM et de threads CPU suffisants

« Je manque de VRAM quand deux demandes arrivent »

• Réduisez OLLAMA_NUM_PARALLEL
• Utilisez un modèle plus agressivement quantifié
• Réduisez la longueur du contexte / tokens max

Dépannage

Symptômes que OLLAMA_NUM_PARALLEL est trop élevé

• Les demandes échouent de manière intermittente sous charge
• OOM GPU / déchargement de modèle se produit fréquemment
• Pic de latence lorsque la seconde demande arrive

Symptômes que OLLAMA_NUM_PARALLEL est trop bas

• Le CPU/GPU est sous-utilisé
• Les délais de mise en file d’attente dominent le temps de réponse total

Astuce : Si vous contrôlez également votre client, ajoutez des nouveaux essais avec gigue (jitter) et des connexions keep-alive. De nombreux problèmes « Ollama est lent » sont en réalité de la mise en file d’attente + surcharge de connexion.

Ollama : Demandes par lots vs Exécution parallèle

Le regroupement (Batching) dans Ollama fait référence à la pratique de regrouper plusieurs demandes entrantes et de les traiter comme une unité. Cela permet une utilisation plus efficace des ressources de calcul, surtout lors de l’exécution sur du matériel qui bénéficie d’opérations parallélisées (tels que les GPU).

Lorsque plusieurs demandes pour le même modèle arrivent simultanément, Ollama peut les traiter ensemble dans un lot si la mémoire le permet. Cela augmente le débit et peut réduire la latence pour chaque demande, car le modèle peut tirer parti des opérations matricielles optimisées sur le lot.

Le regroupement est particulièrement efficace lorsque les demandes sont similaires en taille et en complexité, car cela permet une meilleure utilisation du matériel.

L’exécution parallèle dans Ollama signifie le traitement de plusieurs demandes à la fois, soit pour le même modèle, soit pour des modèles différents, selon la mémoire disponible et la configuration.

Ollama prend en charge deux niveaux de parallélisme :

• Chargement de plusieurs modèles : Si suffisamment de mémoire est disponible, plusieurs modèles peuvent être chargés et servir des demandes simultanément.
• Demandes parallèles par modèle : Chaque modèle chargé peut traiter plusieurs demandes en parallèle, contrôlé par le réglage OLLAMA_NUM_PARALLEL (par défaut est 1 ou 4, selon la mémoire).

Lorsque les demandes dépassent la limite de parallélisme, elles sont mises en file d’attente (FIFO) jusqu’à OLLAMA_MAX_QUEUE.

À retenir

Ollama exploite à la fois le regroupement et l’exécution parallèle pour traiter efficacement plusieurs demandes. Le regroupement regroupe les demandes pour un traitement simultané, tandis que l’exécution parallèle permet à plusieurs demandes (ou modèles) de s’exécuter simultanément. Les deux méthodes dépendent de la mémoire système et sont configurables pour une performance optimale.

Pour plus de benchmarks, de réglages de concurrence et de conseils de performance, consultez notre hub Performance des LLM : Benchmarks, Goulots d’étranglement et Optimisation.

Liens utiles

• Aide-mémoire des commandes Ollama
• Comparaison de performance LLM - Ollama sur GPU 16GB VRAM
• Déplacer les modèles Ollama vers un autre disque ou dossier
• Comment Ollama utilise les cœurs Performance et Efficient du CPU Intel
• D’Ollama à vLLM : Quand migrer votre serveur LLM local