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

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

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

Pour plus d’informations sur le débit, la latence, la VRAM et les benchmarks à travers différents runtime et matériels, consultez Performance LLM : Benchmarks, Goulots d’étranglement & Optimisation.

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

Gestion des requêtes concurrentes

• Traitement parallèle : Ollama prend en charge le traitement concurrent des requêtes. Si le système dispose de suffisamment de mémoire disponible (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 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 définie sur 4 (ou 1, selon la disponibilité de la mémoire), mais elle peut être ajustée.

• Regroupement (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 traitées en parallèle, et les utilisateurs verront les réponses diffusées (streaming) en même temps. Le serveur n’attend pas intentionnellement que le batch soit rempli ; le traitement commence dès que les requêtes sont disponibles.

Mise en file d’attente et limites

• File d’attente : Si le nombre de requêtes concurrentes dépasse le 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 sur une base 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 (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 simultanément 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 faire 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 en même temps et que le parallélisme du serveur est défini sur au moins 2, les deux requêtes seront traitées ensemble dans un batch, et les deux utilisateurs recevront des réponses de manière concurrente. Si le parallélisme est défini sur 1, une requête 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 requêtes 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 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 plusieurs requêtes simultanées efficacement, à 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 la latence stable et que la file d’attente continue de croître sous un trafic réel, c’est l’un des signaux les plus clairs à prendre en compte avant de passer à un moteur de service dédié. Ollama vers vLLM : Quand migrer votre serveur LLM local décrit cette décision, y compris le batching continu et PagedAttention comme mécanismes que vLLM utilise pour empêcher les requêtes concurrentes de se dégrader mutuellement.

Gestion de l’insuffisance de mémoire

Lorsque Ollama rencontre une mémoire insuffisante pour gérer 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é :

Mise en file d’attente des requêtes

• Les nouvelles requêtes 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 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 pour maximiser l’efficacité 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 :

• Passer à la pagination sur le disque (dégradant sévèrement les performances)
• Retourner des erreurs « out of memory » (mémoire insuffisante)
• 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 de 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 définissez 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

• Regroupement des requêtes : 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 : Gardez 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 d’échange (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 de la gestion de volumes élevés de requêtes.

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 en grande partie si elles s’exécutent de manière concurrente ou si elles sont mises en file d’attente.

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

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 GPU unique / VRAM limitée, puis augmentez progressivement tout en surveillant :

• L’utilisation de la VRAM GPU (OOM / évictions)
• L’utilisation du CPU et la moyenne de charge
• La latence p95 de vos requêtes typiques
• Le taux d’erreur / les timeouts

Si vous optimisez une page spécifique pour l’utilisation CLI, consultez la section Ollama CLI dans 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
• 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 une VRAM et des threads CPU suffisants

« J’épuise ma 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 tokens 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èles fréquents
• 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 retries avec du jitter et maintenez des connexions keep-alive. De nombreux problèmes « Ollama est lent » sont en réalité dus à la file d’attente + à la surcharge de connexion.

Ollama : Regroupement des requêtes 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 sur du matériel qui bénéficie d’opérations parallélisées (telles que les GPU).

Lorsque plusieurs requêtes pour le même modèle arrivent simultanément, Ollama peut les traiter ensemble dans un batch 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 tirer parti d’opérations matricielles optimisées sur le batch.

Le batching 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, 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 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 (la valeur par 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.

Conclusion

Ollama utilise à la fois le batching et l’exécution parallèle pour traiter plusieurs requêtes efficacement. Le batching 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 de manière concurrente. Les deux méthodes dépendent de la mémoire 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 Performance LLM : Benchmarks, Goulots d’étranglement & Optimisation hub.

Liens utiles

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