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

Ce guide explique comment Ollama gère les requêtes parallèles (concurrence, 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).

Lien d’accès rapide : Qu’est-ce que OLLAMA_NUM_PARALLEL ? · Recettes d’optimisation rapide · Fonctionnement de la file d’attente · Dépannage · Lié : Aide-mémoire des commandes CLI Ollama

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

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

Gestion des requêtes concurrentes

• Traitement parallèle : Ollama prend en charge le traitement simultané des requêtes. 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 en même temps, et chaque modèle chargé peut gérer plusieurs requêtes en parallèle. Cela est contrôlé par la variable d’environnement OLLAMA_NUM_PARALLEL, qui définit le nombre maximum de requêtes parallèles que chaque modèle peut traiter simultanément. Par défaut, cette valeur est fixée à 4 (ou à 1, selon la disponibilité de la mémoire), mais elle peut être ajustée.

• Mise en lot (Batching) : Lorsque plusieurs requêtes pour le même modèle arrivent simultanément, Ollama les regroupe (batch) et les traite ensemble. Cela signifie que les deux requêtes sont gérées en parallèle et que les utilisateurs verront les réponses s’afficher en streaming en même temps. Le serveur n’attend pas intentionnellement de remplir un lot ; le traitement commence dès que les requêtes sont disponibles.

File d’attente et limites

• File d’attente : Si le nombre de requêtes concurrentes dépasse la parallélisme configuré (par exemple, plus de OLLAMA_NUM_PARALLEL requêtes pour un modèle), les requêtes supplémentaires sont mises en file d’attente. La file d’attente fonctionne selon le principe premier entré, premier sorti (FIFO).

• Limites de la file d’attente : Le nombre maximum de requêtes en file d’attente est contrôlé par OLLAMA_MAX_QUEUE (défaut : 512). Si la file est pleine, les nouvelles requêtes 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 requête nécessite le chargement d’un nouveau modèle et que la mémoire est insuffisante, Ollama déchargera les modèles inactifs pour libérer de l’espace, et la requête sera mise en file d’attente jusqu’à ce que le modèle soit chargé.

Scénario d’exemple

Si deux requêtes pour le même modèle arrivent en même temps et que la parallélisme du serveur est réglée au minimum à 2, les deux requêtes seront traitées ensemble en lot (batch), et les deux utilisateurs recevront leurs réponses simultanément. Si la parallélisme est réglée à 1, une requête est traitée immédiatement, et l’autre est mise en file d’attente jusqu’à la fin de la première.

Si les requêtes sont pour des modèles différents et qu’il y a assez de mémoire, les deux modèles peuvent être chargés et les requêtes gérées en parallèle. Sinon, un modèle peut nécessiter d’être déchargé, et la requête sera mise en file d’attente.

Tableau récapitulatif

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

Si l’augmentation de OLLAMA_NUM_PARALLEL ne permet plus de maintenir la latence stable et que la file d’attente continue de croître sous une charge réelle, c’est l’un des signes clairs à prendre en considération pour envisager un passage à un moteur de service conçu à cet effet. Ollama vers vLLM : Quand migrer votre serveur LLM local détaille cette décision, y compris la mise en lot continue (continuous batching) et PagedAttention comme mécanismes utilisés par vLLM pour empêcher les requêtes concurrentes de se dégrader mutuellement.

Gestion du manque de mémoire

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

File d’attente des requêtes

• Les nouvelles requêtes sont placées dans une file FIFO (Premier entré, Premier sorti) 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 (défaut : 512 requêtes).
• Si la file atteint sa capacité, les nouvelles requêtes reçoivent des erreurs 503 « Serveur surchargé ».

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 requêtes en attente.
• Le nombre de modèles chargés simultanément est limité par OLLAMA_MAX_LOADED_MODELS (défaut : 3 × nombre de GPU ou 3 pour CPU).

Optimisation de la mémoire

• Tente de traiter les requêtes par lots pour le même modèle afin de maximiser l’efficacité de la mémoire.
• Pour l’inférence GPU, nécessite une allocation complète de la 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 requêtes en file d’attente dépassent les ressources disponibles, Ollama peut :

• Utiliser la mémoire virtuelle (swap) sur disque (dégradant sévèrement les performances)
• Retourner des erreurs « manque de mémoire »
• Crasher 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 des capacités de leur matériel. La gestion du manque de mémoire devient cruciale lors de l’exécution de modèles plus grands (7B+ paramètres) ou lors du traitement de multiples requêtes concurrentes.

Stratégies d’optimisation Ollama

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

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

Stratégies opérationnelles

• Requêtes par lots : Traitez plusieurs requêtes simultanément pour amortir la surcharge 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 : Conserve les modèles courants 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 requêtes concurrentes
• Augmentez l’espace de swap

Exemple de workflow d’optimisation :

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

### Limiter les modèles chargés et les requêtes 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é des réponses, ce qui est particulièrement bénéfique lors de l’exécution de plusieurs modèles ou du traitement de volumes de requêtes élevés.

Variable d’environnement OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL contrôle le nombre de requêtes qu’Ollama exécutera en parallèle. Si vous envoyez plusieurs requêtes au même serveur Ollama, ce paramètre 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 contention et peuvent améliorer la stabilité, mais les requêtes seront plus souvent mises en file d’attente.

La mémoire, en particulier, évolue proportionnellement à OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH : quatre emplacements parallèles avec un contexte de 32K réservent la cache KV comme si une seule séquence de 128K était chargée, même avant que n’importe quelle requête ne l’utilise. Sur une carte de 16 Go, ce calcul de budget 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 contexte long.

Comment définir OLLAMA_NUM_PARALLEL

Linux / macOS (service systemd ou shell) :

export OLLAMA_NUM_PARALLEL=2
ollama serve

Exécution ponctuelle (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 seul GPU / VRAM limitée, puis augmentez progressivement tout en surveillant :

• Utilisation de la VRAM GPU (OOM / évictions)
• Utilisation du CPU et moyenne de charge
• Latence p95 de vos requêtes typiques
• Taux d’erreurs / dépassements de délai

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

Recettes d’optimisation rapide

Priorité à la stabilité

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

Priorité au débit

• OLLAMA_NUM_PARALLEL=2 (ou plus si vous avez de la marge)
• Envisagez la mise en lot des requêtes au niveau du client
• Assurez-vous de disposer d’une VRAM et de threads CPU suffisants

« Je manque de VRAM lorsque deux requêtes arrivent »

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

Dépannage

Symptômes indiquant que OLLAMA_NUM_PARALLEL est trop élevé

• Les requêtes échouent de manière intermittente sous charge
• OOM GPU / déchargement de modèle fréquent
• Pics de latence à l’arrivée de la deuxième requête

Symptômes indiquant que OLLAMA_NUM_PARALLEL est trop bas

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

Astuce : Si vous contrôlez également votre client, ajoutez des réessais avec du jitter (variations aléatoires) et des connexions persistantes (keep-alive). Beaucoup de problèmes « Ollama est lent » sont en réalité des problèmes de file d’attente + surcharge de connexion.

Ollama : Mise en lot des requêtes vs Exécution parallèle

La mise en lot (batching) dans Ollama fait référence à la pratique de regrouper plusieurs requêtes entrantes ensemble et de les traiter comme une unité. Cela permet une utilisation plus efficace des ressources de calcul, en particulier lors de l’exécution sur du matériel qui bénéficie des opérations parallélisées (tel que les GPU).

Lorsque plusieurs requêtes pour le même modèle arrivent simultanément, Ollama peut les traiter ensemble en lot si la mémoire le permet. Cela augmente le débit et peut réduire la latence pour chaque requête, car le modèle peut exploiter les opérations de matrice optimisées sur le lot.

La mise en lot est particulièrement efficace lorsque les requêtes sont similaires en taille et en complexité, car cela permet une meilleure utilisation du matériel.

L’exécution parallèle dans Ollama signifie gérer plusieurs requêtes en même temps, que ce soit pour le même modèle ou 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 : S’il y a assez de mémoire, plusieurs modèles peuvent être chargés et servir des requêtes simultanément.
• Requêtes parallèles par modèle : Chaque modèle chargé peut traiter plusieurs requêtes en parallèle, contrôlé par le paramètre OLLAMA_NUM_PARALLEL (défaut est 1 ou 4, selon la mémoire).

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

À retenir

Ollama utilise à la fois la mise en lot et l’exécution parallèle pour traiter efficacement plusieurs requêtes. La mise en lot regroupe les requêtes pour un traitement simultané, tandis que l’exécution parallèle permet à plusieurs requêtes (ou modèles) de s’exécuter simultanément. Les deux méthodes dépendent de la mémoire du système et sont configurables pour des performances optimales.

Pour plus de benchmarks, de réglages de concurrence et de conseils de performance, consultez notre hub Performance 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
• Ollama vers vLLM : Quand migrer votre serveur LLM local