2026 : Ollama trop lent en CPU, optimiser ou changer de serveur ?

Un modèle Ollama met longtemps à répondre, ou sa génération ralentit après un prompt volumineux.

Avant de changer de machine, vérifiez le modèle, la taille du contexte, l’utilisation de la mémoire et les restrictions de threads du conteneur. Une fois ces causes écartées, les mesures peuvent indiquer si davantage de ressources CPU ou de mémoire aidera ; pour une inférence à faible latence ou à forte concurrence, évaluez plutôt une solution GPU ou une API de modèle externe.

Cet article s’adresse aux personnes qui utilisent Ollama en CPU-only et trouvent les réponses trop lentes, aux petites équipes qui hébergent des applications d’IA ou une base de connaissances, ainsi qu’aux responsables techniques qui envisagent de quitter un VPS pour un serveur dédié. Il vise à isoler le goulot d’étranglement avant d’engager des frais de migration.

Dernière vérification : 23 octobre 2026, à partir des annonces, de la documentation et des versions officielles d’Ollama, ainsi que de la documentation Docker. L’annonce Ollama sur la version 0.30 et GGUF date du 5 juin 2026. Elle décrit des améliorations autour de llama.cpp et de la compatibilité GGUF, mais ne constitue ni une garantie de performances CPU ni une preuve que cette version est la plus récente. Les échanges communautaires sur les longs prompts servent à repérer des symptômes rencontrés, pas à établir une performance générale.

Établir une référence avant de toucher à la configuration

Une impression comme « c’est devenu lent » ne permet pas de départager un modèle trop ambitieux, une charge système changeante et une restriction Docker. Il faut d’abord pouvoir reproduire le symptôme. Choisissez un modèle déjà utilisé et conservez exactement le même prompt, les mêmes options et la même longueur de contexte pour les essais comparatifs.

Pour chaque exécution, notez :

• le modèle et sa quantification ;
• le texte du prompt et le contexte configuré ;
• le délai avant le premier jeton, puis la durée de génération ;
• la mémoire disponible, la mémoire occupée par le processus et l’activité du swap ;
• l’occupation CPU de l’hôte et celle observée depuis le conteneur ;
• les autres charges présentes au moment du test.

L’API de génération d’Ollama permet d’obtenir des informations sur une requête et des durées associées ; vérifiez les champs disponibles dans la documentation de l’API de génération. Pour comparer deux essais, consignez les mêmes indicateurs et évitez de transformer une mesure faite sur une seule requête en promesse de débit ou de capacité. Une valeur de tokens par seconde n’est pertinente qu’accompagnée du modèle, de la quantification, de la longueur du prompt et du matériel testé.

Distinguez surtout le délai de chargement du délai de génération. Si l’attente survient avant que le modèle réponde, examinez le chargement et la mémoire. Si la première réponse arrive, puis que chaque jeton est produit lentement, regardez plutôt le calcul, la taille du modèle, le contexte ou la concurrence. Un autre service qui occupe le processeur peut aussi fausser une comparaison entre deux essais.

Réduire la charge du modèle avant d’acheter de la mémoire

La taille du fichier GGUF donne un premier indice, mais elle ne décrit pas à elle seule toute la mémoire nécessaire à l’exécution. Pour obtenir un ordre de grandeur des poids, on peut estimer :

nombre de paramètres × nombre de bits par paramètre ÷ 8

Cette formule représente les poids selon la quantification choisie, pas la mémoire totale de la machine. Il faut encore tenir compte des structures utilisées à l’exécution, de l’architecture du modèle, du cache KV et de la place nécessaire au système et aux autres services. La documentation des formats et modèles pris en charge par llama.cpp aide à comprendre le rôle des formats et quantifications ; elle ne permet pas de déduire la mémoire exacte d’un déploiement Ollama à partir du seul nom du modèle.

Procédez par comparaison contrôlée :

• testez un modèle plus petit, ou une quantification moins lourde, sans modifier le prompt ;
• comparez la qualité de réponse autant que le délai : une réponse plus rapide qui ne satisfait plus le cas d’usage n’est pas une optimisation réussie ;
• observez si le modèle reste chargé ou si le système doit libérer de la mémoire pour répondre ;
• gardez une marge pour l’application, la base vectorielle et le système d’exploitation au lieu d’allouer toute la RAM au modèle.

Le choix entre changer de modèle et augmenter la mémoire dépend de ce que montrent les mesures. Si les signes de pression mémoire ou d’échange disque coïncident avec le ralentissement, l’ajout de mémoire peut être pertinent. Si la mémoire reste disponible et que le processeur travaille intensément pendant la génération, un modèle plus petit peut être un meilleur premier test qu’un serveur disposant simplement de davantage de RAM.

Vérifier le contexte, le swap et le chargement en mémoire

Un contexte plus long n’est pas gratuit : le traitement dépend du modèle, et la mémoire utilisée comprend aussi des éléments d’exécution tels que le cache KV. Si une tâche demande seulement de résumer un court document, conserver un contexte bien plus large que nécessaire peut ajouter un coût sans bénéfice pour cette tâche. À l’inverse, réduire le contexte au hasard peut couper l’information utile et dégrader la réponse.

Répétez l’essai en réduisant le contexte, mais sans toucher au modèle ni aux autres options. Si le délai ou l’usage mémoire change, consignez cette différence ; s’il ne change pas, ne concluez pas que le contexte est toujours sans effet. Le comportement peut varier selon l’architecture du modèle et le prompt. La FAQ officielle d’Ollama décrit des paramètres et aspects de fonctionnement à vérifier pour la version utilisée.

Sur l’hôte, surveillez la mémoire disponible et l’activité du swap pendant le chargement comme pendant la génération. L’échange vers le disque peut donner une impression de blocage qui ressemble à un processeur trop lent, alors que la cause immédiate est la mémoire insuffisante. Il faut donc traiter séparément trois constats :

• Mémoire sous pression ou swap actif : réduire le modèle ou le contexte, ou envisager davantage de RAM si les autres services doivent rester sur la même machine.
• Mémoire disponible, processeur très occupé pendant la génération : tester un modèle plus petit, vérifier l’allocation CPU et mesurer à nouveau ; davantage de RAM, à elle seule, ne prouve pas que le calcul sera accéléré.
• Modèle qui n’est pas conservé en mémoire : vérifier les paramètres de conservation et les effets des autres charges avant de mesurer une génération, car le chargement peut être confondu avec le temps de réponse.

Ne comparez pas un essai à froid, avec chargement initial, à un essai où le modèle est déjà en mémoire sans le signaler. Pour chaque situation, notez si le délai concerne le chargement, le traitement du prompt ou la génération. Cette séparation évite d’acheter des ressources qui ne ciblent pas la cause observée.

Contrôler les threads et les limites de Docker

Le nombre de processeurs visibles sur l’hôte n’est pas nécessairement celui dont dispose le processus dans un conteneur. Une restriction CPU peut venir de quotas ou d’une affinité définie au lancement. Docker documente ces mécanismes dans sa page sur les contraintes de ressources des conteneurs. Vérifiez les options réellement appliquées au conteneur et les ressources qu’il voit ; ne vous fiez pas uniquement à la commande utilisée pour créer le service.

Une vérification exploitable compare trois niveaux : ressources disponibles sur l’hôte, limites du conteneur, threads ou processeurs visibles par le processus Ollama. Si le conteneur ne peut utiliser qu’une partie de la machine, régler Ollama comme s’il avait accès à toutes les ressources ne supprime pas cette limite. À l’inverse, supprimer les garde-fous sans comprendre les autres services peut entraîner une concurrence indésirable sur l’hôte.

Pour un déploiement Docker, vérifiez le fichier Compose et la configuration réellement active après redémarrage. La documentation officielle d’Ollama pour Docker sert à valider le mode de déploiement ; les options de ressources doivent ensuite être recoupées avec la documentation Docker. Les noms et effets des réglages Ollama pouvant évoluer, confirmez-les dans les versions publiées par le projet avant de modifier un service. Un réglage partagé dans un forum est un cas particulier tant que la version, le processeur et la configuration du conteneur n’ont pas été comparés.

Si les performances semblent anormales après une mise à jour, relevez la version installée et consultez les notes de version avant d’attribuer le changement au matériel. Une mise à jour de backend peut modifier le comportement, mais l’annonce d’une amélioration générale ne prédit pas le résultat sur une machine donnée. Répétez plutôt le même test avant et après mise à jour, dans des conditions documentées.

Séparer les symptômes avant de déplacer les services

Une machine peut héberger l’interface, l’orchestration, le stockage des documents, la base vectorielle, les calculs d’Embedding et Ollama. Ces charges n’ont pas toutes le même profil : une requête de génération lente n’est pas la même panne qu’une file de requêtes qui s’allonge pendant qu’un processus d’indexation consomme le processeur.

Établissez un inventaire des services et notez ceux qui sont actifs lors du test :

• Génération lente sur une requête isolée : répétez-la avec un modèle et un contexte plus légers, puis examinez le processeur et la mémoire.
• Réponses retardées quand plusieurs demandes arrivent : mesurez l’attente en file séparément de la durée de génération ; augmentez temporairement la charge de manière contrôlée pour confirmer que la concurrence est en cause.
• Pause au démarrage, mais génération ensuite stable : examinez le chargement du modèle et la mémoire, plutôt que de supposer que le processeur manque de cœurs.
• Dégradation pendant l’indexation ou le traitement des documents : répétez la génération quand ces tâches sont arrêtées, puis évaluez si l’Embedding, la recherche vectorielle et l’inférence doivent partager la même machine.

La séparation des services peut apporter de la marge opérationnelle et rendre les mesures plus lisibles, mais elle implique aussi davantage d’administration et de transferts de données entre composants. Pour un service de connaissances d’entreprise, l’hébergement autonome peut répondre à des exigences de contrôle des données ; il faut néanmoins vérifier les accès, les sauvegardes et les flux vers d’éventuelles API externes. Les informations de confidentialité de SFP Cloud peuvent servir à examiner le cadre du service, sans remplacer une analyse propre aux données et aux applications déployées.

Décider avec les symptômes, pas avec un seuil universel

Le tableau ci-dessous sert à orienter la prochaine vérification. Il ne fixe ni durée acceptable universelle ni seuil matériel : ces critères dépendent du produit, des utilisateurs et de la tâche.

Avant de migrer depuis un VPS ou de louer un serveur dédié, consignez le modèle, la quantification, le contexte, les ressources système, les limites Docker et les délais observés. Comparez ensuite les options sur la même charge. Une machine dédiée peut réduire les incertitudes liées au partage des ressources, mais elle ne transforme pas une inférence CPU en inférence GPU et ne corrige pas, par elle-même, un mauvais choix de modèle.

FAQ sur le diagnostic d’Ollama en CPU

Pourquoi Ollama est-il lent en inférence uniquement sur CPU ?
Une réponse lente peut être la limite attendue du modèle sur CPU, mais aussi venir d’un contexte trop long, d’un chargement incomplet en mémoire, d’échanges vers le disque ou d’un conteneur bridé. Rejouez une requête identique en surveillant ces ressources. Si le délai apparaît surtout avant le premier jeton, examinez le chargement ; s’il augmente pendant la génération, vérifiez le calcul et les tâches concurrentes.

Faut-il choisir un modèle plus petit ou ajouter de la mémoire ?
Commencez par vérifier si le modèle chargé tient en mémoire sans échange vers le disque. Si le système manque de mémoire disponible ou utilise le swap, une capacité mémoire supérieure peut aider ; si le modèle est chargé mais que le processeur reste occupé pendant la génération, testez d’abord un modèle plus petit ou une quantification adaptée. Comparez les essais avec le même prompt et le même contexte.

La longueur du contexte ralentit-elle Ollama sur CPU ?
Elle peut alourdir le traitement, mais l’effet dépend du modèle, de son architecture et de la configuration. Un contexte très supérieur au besoin peut augmenter la mémoire nécessaire, notamment pour le cache KV, et rallonger certaines phases de traitement. Réduisez-le pour un test contrôlé, sans le fixer à une valeur universelle : la limite utile dépend de la tâche et du modèle.

Comment vérifier les limites de threads et de ressources d’Ollama dans Docker ?
Inspectez les ressources réellement accessibles au conteneur, pas seulement celles annoncées par l’hôte. Contrôlez la configuration CPU du conteneur, son quota et son affinité, puis comparez-les aux threads disponibles et aux réglages utilisés par Ollama. Les noms des options et leur comportement doivent être vérifiés dans la documentation correspondant à votre version ; une valeur trouvée dans un cas communautaire n’est pas une règle générale.

Vérifier si un serveur dédié correspond réellement au besoin

Pour une charge CPU modérée et des applications qui doivent fonctionner en continu, un serveur dédié peut être envisagé si les mesures montrent que la contention ou le manque de ressources de l’environnement actuel est le problème. Avant de choisir, vérifiez sur la page des tarifs de SFP Cloud les ressources, les options, la localisation et les modalités de facturation réellement proposées. Les caractéristiques et le prix ne doivent pas être déduits d’un tableau générique ou d’une ancienne configuration.

Un serveur sans GPU reste soumis aux limites de l’inférence CPU. Si l’application exige une génération à faible latence, une forte concurrence ou l’entraînement de modèles, il faut évaluer une solution GPU ou une API externe plutôt que supposer qu’un processeur plus puissant suffira. Si le modèle tourne déjà correctement mais que plusieurs services se disputent les ressources, un serveur dédié peut aider à isoler les charges ; la mesure avant migration doit confirmer que cette isolation répond bien au problème.

La décision la plus fiable part donc du relevé reproductible : modèle, contexte, mémoire, swap, occupation CPU, contraintes du conteneur et délai d’attente. Si les essais montrent un manque de ressources durable, comparez ces besoins aux configurations et conditions affichées par SFP Cloud. Si le besoin réel est une inférence GPU ou une forte concurrence à faible latence, ne retenez pas un serveur CPU comme substitut.

Questions fréquentes

1. Q
   Pourquoi Ollama est-il lent en inférence uniquement sur CPU ?

   Une réponse lente peut être la limite attendue du modèle sur CPU, mais aussi venir d’un contexte trop long, d’un chargement incomplet en mémoire, d’échanges vers le disque ou d’un conteneur bridé. Rejouez une requête identique en surveillant ces ressources. Si le délai apparaît surtout avant le premier jeton, examinez le chargement ; s’il augmente pendant la génération, vérifiez le calcul et les tâches concurrentes.

2. Q
   Faut-il choisir un modèle plus petit ou ajouter de la mémoire ?

   Commencez par vérifier si le modèle chargé tient en mémoire sans échange vers le disque. Si le système manque de mémoire disponible ou utilise le swap, une capacité mémoire supérieure peut aider ; si le modèle est chargé mais que le processeur reste occupé pendant la génération, testez d’abord un modèle plus petit ou une quantification adaptée. Comparez les essais avec le même prompt et le même contexte.

3. Q
   La longueur du contexte ralentit-elle Ollama sur CPU ?

   Elle peut alourdir le traitement, mais l’effet dépend du modèle, de son architecture et de la configuration. Un contexte très supérieur au besoin peut augmenter la mémoire nécessaire, notamment pour le cache KV, et rallonger certaines phases de traitement. Réduisez-le pour un test contrôlé, sans le fixer à une valeur universelle : la limite utile dépend de la tâche et du modèle.

4. Q
   Comment vérifier les limites de threads et de ressources d’Ollama dans Docker ?

   Inspectez les ressources réellement accessibles au conteneur, pas seulement celles annoncées par l’hôte. Contrôlez la configuration CPU du conteneur, son quota et son affinité, puis comparez-les aux threads disponibles et aux réglages utilisés par Ollama. Les noms des options et leur comportement doivent être vérifiés dans la documentation correspondant à votre version ; une valeur trouvée dans un cas communautaire n’est pas une règle générale.