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

Ce guide explique la gestion des requêtes parallèles par Ollama (concurrence, file d’attente et limites de ressources) et comment l’optimiser à l’aide de la variable d’environnement OLLAMA_NUM_PARALLEL (et de paramètres associés).

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

Les agents à plusieurs étapes multiplient les tentatives si l’échantillonnage est instable ; pour les choix par défaut de température, top_p et pénalités sur les modèles de type Qwen et Gemma, consultez Paramètres d’inférence agentique pour Qwen et Gemma.

Traitement 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 simultanément, et chaque modèle chargé peut traiter 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 mémoire disponible), mais elle peut être ajustée.

• Regroupement par lots (Batching) : Lorsque plusieurs requêtes pour le même modèle arrivent simultanément, Ollama les regroupe et les traite ensemble. Cela signifie que les deux requêtes sont traitées en parallèle et que les utilisateurs verront les réponses arriver en flux au même moment. 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ée (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 la méthode premier entré, premier sorti (FIFO).

• Limites de file d’attente : Le nombre maximum de requêtes en file d’attente est contrôlé par OLLAMA_MAX_QUEUE (par défaut : 512). Si la file d’attente 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 la place, 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 au même moment et que la parallélisme du serveur est fixée à au moins 2, les deux requêtes seront traitées ensemble en lot, et les deux utilisateurs recevront des réponses simultanément. Si la parallélisme est fixé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 concernent différents modèles et qu’il y a suffisamment de mémoire, les deux modèles peuvent être chargés et les requêtes traitées en parallèle. Sinon, un modèle peut devoir ê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 maintient plus une latence stable et que la file d’attente continue de grandir sous une charge réelle, c’est l’un des signaux clairs à prendre en considération avant de passer à un moteur de service dédié. Ollama vers vLLM : Quand migrer votre serveur LLM local passe en revue cette décision, y compris le continuous batching et la PagedAttention comme mécanismes utilisés par vLLM pour empêcher les requêtes concurrentes de se dégrader mutuellement.

Gestion de l’insuffisance mémoire

Lorsque Ollama rencontre une mémoire insuffisante pour traiter les requêtes entrantes, il emploie 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 d’attente 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 (par défaut : 512 requêtes).
• Si la file d’attente 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 file d’attente.
• Le nombre de modèles chargés simultanément est limité par OLLAMA_MAX_LOADED_MODELS (par défaut : 3 × nombre de GPU ou 3 pour CPU).

Optimisation de la mémoire

• Tentatives de traitement par lots des requêtes pour le même modèle afin de maximiser l’efficacité mémoire.
• Pour l’inférence GPU, une allocation VRAM complète par modèle est requise - 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 :

• Effectuer un page-to-disk (dégradation sévère des performances)
• Retourner des erreurs « out of memory »
• Faire planter l’instance du modèle dans les 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 de l’insuffisance mémoire devient cruciale lors de l’exécution de modèles plus grands (7B+ paramètres) ou du traitement de plusieurs requêtes concurrentes.

Stratégies d’optimisation Ollama

Activez l’accélération GPU avec export OLLAMA_CUDA=1 et réglez 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/échange de modèles plus rapide
• GPU : NVIDIA RTX 3080/4090 avec 16Go+ de VRAM pour les plus grands modèles

Stratégies opérationnelles

• Regroupement des requêtes (Batching) : Traiter plusieurs requêtes simultanément pour amortir les surcoûts 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 : Garder les modèles courants 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 mémoire :
• Passez à des modèles quantifiés
• Réduisez les requêtes concurrentes
• Augmentez l’espace de swap

Exemple de flux de travail d’optimisation :

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

### Limitation des modèles chargés et des 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 que Ollama exécute 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 en même temps ou si elles 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 mises en file d’attente plus souvent.

La mémoire, en particulier, évolue avec OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH : quatre fentes parallèles avec un réglage de contexte de 32Ko réservent la cache KV comme si une seule séquence de 128Ko é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 est souvent plus important 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 avec un contexte long.

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 avec 1–2 pour un GPU unique / une VRAM limitée, puis augmentez progressivement tout en surveillant :

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

Si vous optimisez une page spécifique pour l’utilisation en CLI, consultez la section Ollama CLI dans le mémo (cheatsheet), ainsi que des exemples de commandes pour ollama serve, ollama ps et ollama run.

Recettes de réglage rapide

Priorité à la stabilité

• OLLAMA_NUM_PARALLEL=1
• Utilisez des modèles plus petits / quantifiés
• Privilégiez des tailles de contexte plus courtes

Priorité au débit

• OLLAMA_NUM_PARALLEL=2 (ou plus si vous avez de la marge)
• Envisagez le regroupement des requêtes au niveau du client
• Assurez-vous d’avoir suffisamment de VRAM et de threads CPU

« 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 / le nombre maximum de jetons

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èles fréquent
• Pics de latence lorsque la deuxième requête arrive

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 tentatives avec jitter et maintenez les connexions keep-alive. De nombreux problèmes d’« Ollama est lent » sont en réalité dus à la file d’attente + les surcoûts de connexion.

Ollama : Regroupement des requêtes (Batching) vs Exécution parallèle

Le regroupement (Batching) dans Ollama fait référence à la pratique de regrouper plusieurs requêtes entrantes 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 d’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 des opérations matricielles optimisées sur le lot.

Le regroupement 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 traiter plusieurs requêtes en même temps, soit pour le même modèle, soit pour différents modèles, selon la mémoire disponible et la configuration.

Ollama prend en charge deux niveaux de parallélisme :

• Chargement de plusieurs modèles : Si la mémoire disponible est suffisante, 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 (par défaut 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 exploite à la fois le regroupement (batching) et l’exécution parallèle pour traiter efficacement plusieurs requêtes. Le regroupement 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 en même temps. 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

• Mémo 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