Si vous utilisez Ollama en production pour répondre aux besoins des modèles LLMVous l'avez probablement déjà compris, il ne s'agit pas simplement d'« installer et de jeter ». Entre le choix du bon modèle, la quantification, l'obtention de la quantité adéquate de VRAM, le nombre de requêtes simultanées et les agents multi-étapes, il est très facile de se retrouver avec des réponses lentes, des erreurs 503, voire des plantages dus à une mémoire insuffisante.
La bonne nouvelle, c'est que, sachant comment cela fonctionne Ollama la concurrence, files d'attente et mémoireEn appliquant quelques bonnes pratiques d'architecture et de système, vous pouvez améliorer considérablement les performances des GPU et des CPU. De plus, cela est possible sans compromettre la confidentialité des données ni la flexibilité des modèles locaux.
Ollama et llama.cpp en production : composants et rôles
Avant de procéder à des réglages précis, il est important de comprendre qui fait quoi. llama.cpp est le moteur d'inférence, extrêmement optimisé en C++ pour tirer le meilleur parti du matériel (CPU, Apple Silicon, NVIDIA, AMD). Ollama est l'« emballage » de haut niveau qui orchestre ce moteur et d'autres backends (tels que vLLM dans certains cas), exposant une interface de ligne de commande simple et une API REST prête à l'emploi.
En pratique, lorsque vous lancez un modèle avec Ollama, ce qui se passe, c'est que l'application (écrite en Go) Il lance un processus enfant qui exécute llama.cpp (ou un autre environnement d'exécution compatible), gère le déchargement des poids, la configuration GPU/CPU, la taille du contexte et la durée de vie du modèle en mémoire. Cela simplifie considérablement les opérations de production par rapport à l'utilisation directe de llama.cpp, où il faudrait le compiler, gérer les routes et des paramètres tels que : –n-couches-gpuquantification, etc.
Si l'on raisonne en termes d'analogies, llama.cpp est le centre de chirurgie tensorielleMinimaliste, optimisé pour tirer le meilleur parti de chaque cycle CPU/GPU. Ollama est le « IKEA » de l'IA locale : un système pré-assemblé avec Gestion des modèles, API standard, file d'attente des requêtes et réglage automatique du matérielIdéal pour les environnements de production où l'on ne souhaite pas se battre avec chaque option de compilation.
Configuration matérielle requise et sélection du modèle pour la production
Un élément clé pour garantir un bon fonctionnement est de ne pas être trop ambitieux quant à la taille du modèle par rapport à votre matériel. La combinaison paramètres du modèle + type de quantification + longueur du contexte Détermine les temps de RAM, de VRAM et d'inférence.
À titre indicatif, pour la production avec Ollama sur une seule machine, les plages de valeurs suivantes sont généralement utilisées :
- 8 Go de RAMModèles de petite taille (1B, 3B, 7B quantifiés). Conviennent aux prototypes et aux petits services, mais la fluidité peut être affectée par une charge importante.
- 16 Go de RAMUn point de vue pertinent pour les modèles quantifiés 7B et 13B de type Q4_K_M. Un service réel peut être fourni si la concurrence est bien maîtrisée.
- 32 Go ou plusRecommandé si vous souhaitez jouer avec des modèles 30B, 40B ou 70B, ou si vous prévoyez de faire fonctionner plusieurs modèles en parallèle.
Sur les GPU, le schéma est similaire : Plus vous avez de VRAM, plus vous pouvez décharger de couches sur la carte graphique. Vous obtiendrez ainsi un débit supérieur. Avec un GPU de 16 Go, vous pouvez facilement gérer des modèles 7B-13B bien quantifiés, tandis que pour 70B, il vous faudra du matériel très haut de gamme ou plusieurs GPU.
En ce qui concerne le stockage, il est important de garder à l'esprit que Les petits modèles quantifiés peuvent occuper 2 GoLes SSD de taille moyenne offrent des capacités allant de 5 Go ou plus à des modèles très volumineux de plusieurs dizaines, voire centaines de gigaoctets. Un SSD NVMe se distingue par des performances accrues lors du chargement ou du changement de modèles.
Enfin, le processeur reste important, surtout si vous effectuez des inférences en utilisant uniquement le processeur ou en combinaison avec le GPU. 4 cœurs constituent le minimum acceptablePour un service stable avec plusieurs requêtes simultanées, 8 cœurs ou plus sont idéaux.
Quantification et formats de modèles : comment améliorer les performances sans sacrifier la qualité
Pour qu'un LLM soit utilisable en production, vous avez presque toujours besoin d'une forme ou d'une autre de quantificationIl s'agit du processus de conversion des poids à virgule flottante (FP16, FP32) en représentations entières avec moins de bits (4, 8, etc.), réduisant la taille du modèle et la mémoire qu'il consomme, au prix d'une légère perte de précision.
Une règle empirique souvent répétée dans la communauté est que Q4_K_M est la norme raisonnable pour le localCela réduit la taille du fichier d'environ la moitié par rapport à FP16, la perte de qualité est d'environ 1 à 2 % selon des métriques comme la perplexité, et la vitesse d'inférence augmente considérablement. Si une compression encore plus importante est nécessaire, vous pouvez opter pour Q3 ou Q2, mais au prix d'une augmentation des erreurs d'interprétation et d'une qualité de raisonnement moindre.
Pour utiliser des modèles avec Ollama, le format standard est GGUFqui regroupe les poids, les métadonnées et un tokenizer de manière optimisée pour les environnements d'exécution de type llama.cpp. De nombreux modèles de la bibliothèque Ollama sont déjà au format GGUF et quantifiés, donc un ollama pullSi vous faites appel à des mannequins externes (par exemple, de Hugging Face), vous pouvez :
- Convertissez des formats comme Safetensors en GGUF Ã l'aide des outils de lama.cpp (scripts comme convert_hf_to_gguf.py).
- Quantifiez-les en binaire quantifier à partir de llama.cpp en choisissant le schéma (Q4_K_M, Q5_K_S, etc.).
- Créer un Fichier modèle Dans Ollama, pointant vers le fichier .gguf et définissant le modèle, les paramètres par défaut et le système.
Ce flux de télécharger → convertir → quantifier → enregistrer dans Ollama Il permet d'intégrer des modèles de niche dans la production, tels que les LLM juridiques (par exemple, un modèle comme Jurema-7B) ou des modèles spécifiques à un domaine, tout en conservant le même pipeline de déploiement.
Paramètres internes du modèle : num_ctx, température et contrôle de sortie
Une fois le modèle choisi, il est temps de maîtriser son comportement. En production, il ne suffit pas qu'il « réponde correctement » ; il doit être prévisible, limité et efficaceLes principaux paramètres exposés par Ollama (hérités de llama.cpp) sont :
D'un côté est num_ctxLa fenêtre de contexte définit le nombre d'éléments que le modèle peut prendre en compte simultanément : messages système, historique des conversations et invite de commande actuelle. Plus la fenêtre est grande, plus le nombre d'éléments pris en compte est élevé. de longues conversations et l'analyse de documents volumineuxCependant, elles augmentent considérablement la consommation de RAM/VRAM et le temps de calcul. De plus, si vous définissez une valeur supérieure à celle pour laquelle le modèle a été entraîné, vous risquez de rencontrer des comportements anormaux ou une dégradation des performances.
Il est également crucial de contrôler la génération avec num_predict (nombre maximal de jetons de sortie), listes de Arrêtez et la température. Une température basse (0,2-0,5) produit des réponses plus stables et moins créatives, idéales pour RAG, codage ou vérificationsLes valeurs élevées sont réservées aux usages créatifs, qui correspondent rarement à des scénarios de production sérieux.
De plus, des options telles que top_p y top_k Elles contribuent à limiter l'aléatoire. Réduire top_p à des valeurs modérées (par exemple, 0,8-0,9) restreint l'espace des jetons possibles, ce qui est utile pour réduire les hallucinations et obtenir des résultats plus reproductibles.
Tous ces paramètres peuvent être définis de manière permanente dans le Fichier modèle par le biais d'instructions PARAMETER, écraser spécifiquement avec l'interface de ligne de commande (commande) /set (en mode interactif) ou transmettre dynamiquement via une API REST dans le champ options à partir de JSON.
Concurrence, files d'attente et traitement par lots chez Ollama : optimiser les performances sans surcharger la machine
Le véritable passage du « jouet local » à service en production Cela se produit lorsque vous commencez à recevoir plusieurs requêtes simultanément. Ollama intègre son propre système de foules et files d'attente pour gérer cela sans avoir à installer de serveur supplémentaire.
L'élément central est la variable d'environnement OLLAMA_NUM_PARALLELCela définit le nombre de requêtes qu'un modèle chargé peut traiter en parallèle. La valeur par défaut est généralement de 4 (ou 1 si la mémoire est limitée). Des valeurs plus élevées augmentent le débit si vous disposez de suffisamment de ressources CPU/GPU et VRAM, mais elles augmentent également la charge sur la mémoire et peuvent aggraver la latence de chaque requête.
Lorsque plusieurs demandes arrivent pour le même modèle, Ollama essaie de faire mise en lotIl regroupe les requêtes et les traite simultanément, optimisant ainsi l'utilisation des opérations sur les tableaux GPU. De l'extérieur, les utilisateurs constatent que les réponses commencent à être transmises simultanément. Si le nombre de requêtes dépasse la capacité de OLLAMA_NUM_PARALLEL, une exception est levée. File d'attente FIFO réglementé par FOUR MAX_QUEUE, qui par défaut est de 512.
Si la file d'attente est saturée, Ollama renvoie des erreurs 503 (« Surcharge du serveur »). Et si la mémoire est saturée, une autre limite entre en jeu. FOUR_MAX_CHAUFFÉ_MODÈLESCela indique le nombre de modèles pouvant être chargés simultanément. Lorsqu'un nouveau modèle doit être chargé et que la mémoire est insuffisante, les modèles inactifs sont déchargés et la requête attend que le nouveau modèle soit prêt.
Dans les déploiements réels, une approche courante consiste à commencer par OLLAMA_NUM_PARALLEL=1 ou 2 Pour privilégier la stabilité, surveillez l'utilisation du processeur, la VRAM et la latence p95, et augmentez progressivement les paramètres tant qu'aucune erreur de manque de mémoire ou aucun pic de file d'attente n'apparaît.
Stratégies de gestion de la mémoire dans Ollama
La mémoire (RAM et VRAM) est une ressource essentielle pour tout service LLM local. Ollama combine plusieurs stratégies pour éviter de faire planter le système lorsque le nombre de requêtes dépasse la capacité de la mémoire ou lorsque vous prévoyez d'utiliser des modèles trop volumineux pour votre machine.
D'une part, il utilise un File d'attente FIFO Ce comportement est contrôlé par OLLAMA_MAX_QUEUE afin d'éviter le rejet simultané de toutes les requêtes en cas de saturation de la mémoire. Si la file d'attente est pleine, elle renvoie explicitement le code 503 au lieu de simplement interrompre le processus.
D'autre part, elle maintient un nombre limité de modèles chargés en mémoire L'option OLLAMA_MAX_LOADED_MODELS (par défaut, 3 par GPU ou 3 par CPU) permet de décharger automatiquement les modèles inactifs pendant un certain temps, libérant ainsi de la VRAM et de la RAM pour les requêtes suivantes.
Ce paramètre entre également en jeu. OLLAMA_GARDER_EN_VIECela définit la durée pendant laquelle un modèle reste en mémoire après la dernière requête. Des valeurs comme 5 minutes empêchent le rechargement du modèle à chaque requête, sans pour autant le conserver indéfiniment en RAM. Avec 0, le modèle est téléchargé immédiatement après son exécution, ce qui économise de la mémoire mais augmente le temps de démarrage ; avec -1, il reste en mémoire tant que le serveur est actif.
En cas de forte sollicitation de la mémoire, le système d'exploitation peut recourir à échange sur disqueCela dégrade considérablement les performances et peut même provoquer des erreurs de type « mémoire insuffisante » et des plantages d'instance. Il est donc essentiel d'ajuster : la taille du modèle, la quantification, la longueur du contexte, le nombre de requêtes parallèles et le nombre de modèles chargés simultanément.
Comparaison CPU vs GPU en environnements de production avec Ollama
Tout le monde n'a pas accès à des GPU puissants en production, surtout lorsqu'ils sont déployés sur des serveurs ou des ordinateurs portables d'entrée de gamme. D'où l'intérêt croissant pour Optimisation de l'inférence en utilisant uniquement le processeur, en choisissant des modèles légers et bien quantifiés qui permettent des latences raisonnables.
Pour une utilisation exclusive du processeur, il est recommandé de choisir des modèles parmi les suivants : 2B, 3B ou 7B Pour les contextes quantifiés (Q4_K_M, Q5, etc.), utilisez des tailles de contexte modérées et limitez le nombre de requêtes parallèles. Ajuster OLLAMA_NUM_THREADS Le nombre de cœurs physiques (ou légèrement inférieur) permet d'équilibrer les performances et l'utilisation des ressources, évitant ainsi la surcharge du système.
Si vous possédez une carte graphique, il est essentiel de vérifier, en utilisant ollama psque le modèle utilise effectivement la carte graphique (idéalement « 100 % GPU » dans le champ PROCESSEUR). Les configurations qui mélangent trop de couches CPU et GPU ont tendance à produire faibles rendementsDans les environnements disposant d'une quantité suffisante de VRAM, il est souhaitable de décharger autant de couches que possible sur le GPU.
Pour activer explicitement l'accélération, dans certains environnements, il est nécessaire d'exporter des variables telles que : CUDA_OVEN=1 ou configurez correctement les pilotes NVIDIA/AMD. Si vous voyez des erreurs comme « erreur CUDA » ou « erreur ROCm » dans les journaux, il s'agit probablement d'un problème de compatibilité entre les pilotes ou le matériel.
Configuration avancée : variables d’environnement et déploiement stable
Au-delà des paramètres d'inférence, Ollama peut être finement paramétré avec une bonne poignée de Variables d'environnement qui définissent le réseau, les routes, CORS, la journalisation et le comportement de chargement des modèles. En production, il est courant de modifier au moins les éléments suivants :
D'une part, OLLAMA_HÔTE Définit l'interface et le port d'écoute de l'API. Par défaut, il s'agit de 127.0.0.1:11434, ce qui signifie qu'elle est uniquement accessible localement. Pour l'exposer sur le réseau interne, vous pouvez la modifier en 0.0.0.0:11434 ou en spécifiant une adresse IP, toujours protégée par un pare-feu ou un proxy inverse.
Un autre paramètre très utile est MODÈLES DE FOURSCela vous permet de déplacer le dossier contenant les modèles vers un autre disque ou volume (par exemple, un SSD de grande capacité). Vous bénéficiez ainsi d'une plus grande flexibilité pour la gestion de l'espace et des sauvegardes, à condition que l'utilisateur exécutant le service dispose des autorisations de lecture et d'écriture sur ce dossier.
Pour intégrer des interfaces web telles que Ouvrir l'interface utilisateur Web ou d'autres interfaces graphiques, vous devez les ajuster. OLLAMA_ORIGINESCeci contrôle les origines autorisées dans CORS. Vous pouvez spécifier des domaines particuliers (http://localhost:3000, etc.) ou utiliser « * » pour autoriser tous les domaines, ce qui n'est pertinent que si le service n'est pas accessible en dehors d'un réseau strictement contrôlé.
Lors du déploiement et du dépannage, l'activation OLLAMA_DEBUG=1 Pour consulter les journaux détaillés : détection du GPU, chargement des blobs de modèles, temps de réponse, erreurs spécifiques, etc. Sous Linux, ces journaux sont facilement accessibles via journalctl -u ollama, en pouvant les rediriger vers des fichiers ou les filtrer par date.
La méthode précise pour définir ces variables dépend de l'environnement : sous Linux, cela se fait généralement par une substitution systemd pour le service. ollama.servicesur macOS via launchctlSous Windows, cela se fait à l'aide de variables d'environnement système, et sous Docker, via l'option -e en docker courir.
Gestion des modèles, fichiers de modèles et flux de travail avec plusieurs LLM
Après la partie système, il est temps de réfléchir à la manière dont organiser les modèlesOllama propose son propre catalogue qui fonctionne avec des commandes telles que ollama pull, liste d'ollama, ollama rm y poussée d'ollamaCette dernière fonctionnalité vous permet de télécharger des modèles personnalisés dans votre registre, facilitant ainsi la distribution et le versionnage au sein des équipes ou des entreprises.
Pour personnaliser le comportement d'un modèle (tonalité, modèle d'invite, paramètres par défaut), le système est utilisé pour Fichiers modèlesCes fichiers définissent, par exemple, l'instruction FROM avec le chemin vers .gguf, les lignes PARAMETER (température, num_ctx, num_predict, top_p, etc.) et un modèle qui spécifie la structure de l'invite (messages système, messages utilisateur, messages de l'assistant, délimiteurs).
Avec ollama créer Vous pouvez compiler un fichier de modèle et enregistrer un nouveau modèle logique dans le système sans dupliquer physiquement l'espace disque. Ceci est très utile pour générer plusieurs variantes d'un même modèle de base (par exemple, une pour un usage général, une autre optimisée pour le code, une autre pour le style formel, etc.).
Dans les architectures avec agents ou flux multi-étapes (RAG + garde-fou + évaluation de document + expansion de requête + vérification d'hallucination), il est courant combiner plusieurs modèlesUn modèle polyvalent, un modèle compact et rapide pour la classification et les garde-fous, et éventuellement un modèle spécialisé pour le terrain. Là encore, il est crucial de bien paramétrer OLLAMA_MAX_LOADED_MODELS et KEEP_ALIVE afin d'éviter les chargements et déchargements constants de modèles.
Enfin, l'API REST d'Ollama expose des points de terminaison pour chat, génération, intégrations et gestion des modèlesCela permet une intégration facile avec des orchestrateurs d'agents comme LangGraph, ainsi qu'avec des applications backend en Python, JavaScript, PHP, etc., en ajoutant des tentatives de reconnexion et des connexions persistantes côté client pour éviter les pics de file d'attente occasionnels.
Avec tout cela, il est possible de passer d'un simple « jouet » d'IA locale à un plateforme robuste de LLM en productionGrâce à un contrôle précis des performances, de la mémoire et du comportement, vous conservez vos données au sein de votre propre infrastructure et sans dépendre entièrement de fournisseurs de cloud externes ; un atout particulièrement précieux dans les scénarios où les exigences de confidentialité sont élevées, les coûts serrés ou le besoin d’une personnalisation poussée.