Ollama : choisir entre q4_K_M, q8_0 et fp16

Ce que change la quantification d’Ollama

La quantification d’Ollama stocke chaque poids d’un modèle sur moins de bits que le fichier avec lequel il a été entraîné. Un tag qui se termine par q4_K_M utilise environ quatre bits par poids, tandis que fp16 en utilise seize. Le téléchargement représente donc environ un quart de la taille, et la machine lit quatre fois moins d’octets pour produire chaque token. Les poids sont arrondis sur une grille plus grossière, mais ils ne sont pas supprimés. Avec quatre bits, la plupart des modèles répondent presque comme avec la précision maximale.

C’est tout le compromis : une empreinte mémoire bien plus faible et davantage de tokens par seconde, au prix d’une légère perte de précision. La suite explique comment prévoir ces deux effets pour un modèle donné sur une machine donnée, avant de passer vingt minutes à télécharger un fichier qui ne pourra pas être chargé.

Si Ollama ne fonctionne pas encore, commencez par installer Ollama sur un VPS. Cette page suppose que ollama ls fonctionne déjà.

Comment lire une balise de quantification Ollama comme q4_K_M

Les modèles locaux sont distribués sous forme de fichiers GGUF, le format utilisé par llama.cpp pour stocker les poids sur disque. Ollama repose sur llama.cpp. Ses balises reprennent donc les noms de quantification de llama.cpp sans modification.

Le nombre indique la largeur cible. q4 signifie que la plupart des tenseurs de poids sont regroupés sur quatre bits chacun. q8 signifie huit bits. fp16 n’est pas quantifié : il s’agit du modèle en virgule flottante sur seize bits, la précision dans laquelle la plupart des modèles sont publiés.

K indique une K-quant. Les poids sont regroupés en petits blocs, et chaque bloc stocke son propre facteur d’échelle à côté des valeurs regroupées. Un bloc dont les poids sont tous proches de 0.01 utilise une échelle fine. Un bloc contenant une valeur aberrante élevée utilise une échelle plus grossière. Ces facteurs d’échelle par bloc rendent un fichier sur quatre bits exploitable. Ils expliquent aussi pourquoi un tel fichier n’utilise jamais exactement quatre bits par poids.

La dernière lettre indique le mélange. S, M et L déterminent combien de tenseurs sont stockés avec une largeur supérieure à la largeur cible. Dans q4_K_M, les tenseurs qui subissent le plus de pertes lors de l’arrondi sont stockés avec une largeur supérieure, tandis que la majorité reste sur quatre bits. C’est pourquoi q4_K_M produit de meilleurs résultats que l’ancien q4_0, pour une taille de fichier presque identique.

Demandez à Ollama ce qui est réellement présent sur disque au lieu de le déduire du nom saisi :

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show affiche architecture, parameters, quantization, context length et embedding length. La ligne quantization fait foi pour un modèle que vous avez téléchargé il y a plusieurs mois et dont vous ne vous souvenez plus du choix.

Les bits par poids déterminent la taille du fichier

Toute estimation de taille part d’un nombre : le nombre de bits utilisés par le format pour chaque poids, calculé comme une moyenne sur l’ensemble du fichier. llama.cpp publie des valeurs mesurées pour Llama 3.1 8B dans sa documentation sur la quantification. Elles s’appliquent aussi correctement à tout modèle dense de forme similaire.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

La deuxième colonne de ce tableau est surprenante. Q4_K_M n’utilise pas quatre bits par poids. Il utilise 4.89 bits, car les facteurs d’échelle des blocs et les tenseurs promus occupent eux aussi de l’espace. Q8_0 utilise 8.5 bits plutôt que huit, pour la même raison. Utilisez la valeur mesurée : le calcul donne une taille située à quelques pour cent de celle du fichier réel :

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Il s’agit du fichier Q4_K_M de 4.58 Gio, obtenu à partir de deux nombres. Cela correspond également, à peu près, à la mémoire occupée par les poids une fois chargés. Ollama ne décompresse rien au chargement : les poids quantifiés restent en mémoire sous la même forme compacte, et chaque bloc est converti au moment de son utilisation.

Ce qu’Ollama fournit réellement pour chaque taille de modèle

La bibliothèque publie une balise q4_K_M, une balise q8_0 et une balise fp16 pour la plupart des familles. Quelques familles plus récentes ne suivent pas ce modèle et apparaissent dans la bibliothèque avec des balises cloud only, sans rien à pull, quelle que soit la largeur du modèle. C’est le problème que vous rencontrez lorsque vous essayez d’exécuter GLM 5.2 sur un VPS. Voici les tailles de Qwen3 en août 2026, relevées dans la liste des balises de la page du modèle. Chaque valeur ci-dessous correspond d’abord à l’espace disque, avant même le chargement en RAM. Deux ou trois modèles peuvent remplir le volume root d’un petit VPS. Il est donc utile de savoir où Ollama stocke les modèles qu’il télécharge avant de commencer à accumuler les balises.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

La balise par défaut est importante ici. ollama pull qwen3:8b télécharge exactement les mêmes 5.2 Go que ollama pull qwen3:8b-q4_K_M, car la balise sans suffixe est la build q4_K_M. Q4_K_M n’est pas un compromis proposé à contrecœur par la bibliothèque. C’est la version par défaut choisie en amont. Commencer par celle-ci est donc le choix le plus logique pour un modèle que vous n’avez pas encore testé vous-même. Le même raisonnement guide le choix des balises dans l’exécution de Qwen 3 sur un VPS.

Les proportions restent valables sur chaque ligne. Passer de q4_K_M à q8_0 coûte environ soixante-dix pour cent de plus, et non exactement le double, car les tenseurs d’embedding et de sortie n’évoluent pas de la même manière que les autres. fp16 représente environ trois fois la taille de q4_K_M. Un modèle 32B en q4_K_M contient 20 Go de poids. C’est déjà plus que ce qu’un serveur de 16 Go peut contenir avec la moindre fenêtre de contexte. Pour une vue d’ensemble des modèles compatibles avec chaque machine, consultez les modèles que vous pouvez auto-héberger.

Pourquoi le cache KV représente un second coût dépendant du contexte

Les poids représentent le coût fixe. Le cache KV (cache des clés et des valeurs) représente le coût variable. Chaque token de la fenêtre de contexte conserve ses vecteurs de clé et de valeur pour chaque couche. Le cache augmente donc linéairement avec la taille de la fenêtre autorisée. Il est alloué pour toute la fenêtre au chargement du modèle, et non au fur et à mesure que la conversation se remplit. C’est pourquoi une longue fenêtre consomme de la mémoire même pour une invite d’un seul mot.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Ces valeurs proviennent de la configuration du modèle : 36 couches, 8 têtes clé/valeur et une dimension de tête de 128. ollama show fournit l’architecture et le nombre de paramètres. La config.json du modèle sur Hugging Face fournit le reste. Multipliez le coût par token par la taille de la fenêtre : le cache cesse alors d’être négligeable.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Avec la fenêtre par défaut de 4096 tokens d’Ollama, le cache ajoute 0.6 Go aux poids. Augmentez la fenêtre à 32k : le cache seul atteint 4.83 Go. Cela représente presque autant de mémoire que les poids quantifiés, et la mémoire minimale nécessaire pour le modèle complet passe à 10 Go. Il s’agit d’un minimum, car les buffers de calcul et le système d’exploitation s’ajoutent à cette valeur. Consultez la valeur réelle dans la colonne SIZE de ollama ps après le chargement du modèle.

La fenêtre est définie sur le serveur, et non par requête, lorsque vous exécutez Ollama en tant que service :

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Pour une installation systemd, placez plutôt ce paramètre dans un drop-in :

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Redémarrez avec sudo systemctl restart ollama, puis vérifiez la colonne CONTEXT de ollama ps pour confirmer la fenêtre effectivement utilisée lors du chargement du modèle en cours d’exécution. OLLAMA_KV_CACHE_TYPE quantifie également le cache : f16 est la valeur par défaut, q8_0 utilise environ la moitié de la mémoire utilisée par f16, et q4_0 environ le quart. Il s’agit d’une option globale. Tous les modèles de ce serveur utilisent donc le même paramètre. Sur une petite machine avec une longue fenêtre, réduire de moitié le cache libère plus de mémoire que toute autre modification isolée. Définir num_ctx et comprendre son coût décrit la fenêtre elle-même en détail. Le cache est également dimensionné une fois par slot de requête concurrente, et non une fois par serveur. Autoriser Ollama à répondre à deux invites simultanément double donc la valeur que vous venez de calculer. C’est le principe du calcul présenté dans choisir le nombre de slots parallèles et la limite de file d’attente.

Ce qui tient sur un VPS de 8, 16 ou 32 GB

Poids du modèle, cache KV, marge pour le système d’exploitation et pour les autres services en cours d’exécution. Une marge de 2 GB est confortable sur un petit VPS.

8 GB. Un modèle 4B en q4_K_M occupe 2.6 GB et laisse de la place pour une fenêtre de contexte longue. Un modèle 8B en q4_K_M tient avec la fenêtre par défaut de 4k, mais avec très peu de marge. Ne prévoyez pas un modèle 8B avec une fenêtre de 32k ici, car le seuil de 10 GB dépasse déjà la capacité de la machine.

16 GB. Un modèle 8B en q4_K_M avec une fenêtre de 16k ou 32k tient confortablement. Un modèle 14B en q4_K_M représente 9.3 GB de poids et tient avec une fenêtre modeste. Un modèle 8B en q8_0 occupe 8.9 GB. Il tient donc lui aussi. Comparer ces deux modèles avec vos propres prompts est le meilleur usage que vous puissiez faire d’une heure sur ce sujet.

32 GB. Un modèle 14B en q8_0 (16 GB) et un modèle 32B en q4_K_M (20 GB) se chargent tous les deux. Le modèle 32B avec une grande fenêtre de contexte approchera la limite. Surveillez donc ollama ps au lieu de partir du principe que cela passera.

Ce que la quantification dégrade en premier

L’erreur de quantification ne se répartit pas uniformément dans les capacités d’un modèle. La fluidité reste préservée le plus longtemps, ce qui rend précisément les dégradations difficiles à détecter : un modèle mal quantifié produit encore des phrases correctes. La précision se dégrade en premier. Le rappel exact d’un numéro de version, d’une signature d’API ou d’une date. Les longues chaînes de raisonnement, où une petite erreur à l’étape deux devient une réponse incorrecte à l’étape huit. Les formats de sortie stricts, où une seule mauvaise parenthèse fait échouer un appel d’outil.

Ce dernier point constitue le test pratique. Lorsqu’un modèle doit renvoyer du JSON que votre code analyse, les effets de la quantification se manifestent par une erreur d’analyse plutôt que par une prose simplement moins bonne. Vous les voyez donc le jour même. Un agent de programmation est la version la plus exigeante de ce test, car il enchaîne les appels d’outils. Ainsi, configurer un agent pour utiliser votre serveur Ollama révélera une quantification trop agressive en un après-midi.

En dessous de quatre bits, la perte devient importante. Les types q3 et deux bits s’adressent aux utilisateurs qui cherchent à faire tenir un modèle volumineux sur un matériel limité. Ils constituent une option réelle lorsque l’alternative consiste à ne pas exécuter le modèle du tout. Ce sont de mauvais choix par défaut. L’écart entre q4_K_M et q8_0 est suffisamment faible pour qu’un tableau publié de perplexité ne permette pas de trancher pour votre charge de travail. N’essayez donc pas de le déterminer ainsi. Testez les deux avec trente de vos propres prompts, puis examinez la sortie.

Quand q8_0 ou fp16 justifient la RAM

Utilisez q8_0 lorsque la mémoire est réellement disponible et que la tâche ne tolère pas les petites erreurs : extraction structurée, appels d’outils ou code qui doit compiler. Vous achetez ici une marge de sécurité, pas un modèle sensiblement plus intelligent.

N’utilisez fp16 que pour deux raisons. Soit vous quantifiez vous-même le modèle et avez besoin du fichier source, soit vous mesurez une référence pour déterminer ce que votre build quatre bits a perdu. Servir le modèle en fp16 consomme trois fois plus de mémoire que q4_K_M, pour une différence que la plupart des utilisateurs ne distinguent pas à l’aveugle. Sur une machine équipée uniquement d’un CPU, cela réduit également le débit de tokens à un tiers.

La règle la plus fiable, à budget mémoire fixe, est la suivante : un modèle plus grand en q4_K_M surpasse généralement un modèle plus petit en q8_0. 9.3 Go de poids 14B contre 8.9 Go de poids 8B, cela représente presque la même quantité de RAM (random access memory), et le modèle plus grand contient davantage de connaissances. Testez cela avec vos propres prompts plutôt que de l’accepter sans vérification.

L’inférence sur CPU uniquement est limitée par la bande passante mémoire

La plupart des offres VPS n’ont pas de GPU. Le modèle s’exécute donc dans la mémoire système, sur le CPU de l’hôte. La génération est alors limitée par la bande passante mémoire, et non par les calculs arithmétiques, car la production d’un token nécessite de lire chaque poids une fois. Cela impose une limite qui ne dépend pas du nombre de cœurs achetés.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 GB/s est une valeur théorique approximative pour un hôte équipé de mémoire DDR4-3200 en double canal. Votre part est inférieure, car un VPS partage ce bus avec tous les autres tenants de la machine. Considérez donc ces valeurs comme un plafond que personne n’atteint. La tendance est l’élément important : sur CPU, diviser par deux le nombre de bits par poids double approximativement le débit de tokens. La quantification est le principal levier d’accélération disponible sur une machine sans GPU. La vitesse obtenue sera acceptable ou non selon le modèle. Nemotron 3.5 Lightning sur un VPS examine ce calcul pour un build et un tag précis, avec la quantité de RAM correspondante. L’autre facteur est la longueur de la réponse générée. À 10 tokens par seconde, une réponse de 600 tokens prend une minute entière. Limiter la réponse avec num_predict permet donc souvent de réduire davantage le temps d’attente qu’une nouvelle baisse de précision.

Le traitement du prompt fonctionne différemment. La lecture d’un prompt long est limitée par les capacités de calcul plutôt que par la bande passante. Des cœurs supplémentaires sont donc utiles à cette étape, mais n’améliorent presque pas la vitesse de génération. Une machine qui traite rapidement un prompt de 4k, puis génère lentement, fonctionne normalement.

Ne considérez pas ces calculs comme acquis. Mesurez le nombre de tokens par seconde sur votre propre machine avec le même prompt pour chaque niveau de quantification, puis donnez priorité à vos propres mesures.

Quantifier vous-même un modèle

Ollama peut créer un modèle quantifié à partir d’une source fp16 ou fp32. Cela est utile lorsque vous avez effectué un fine-tuning et qu’aucun tag de bibliothèque n’existe. Pointez un Modelfile vers les poids non quantifiés :

FROM /path/to/my/model/f16

Construisez ensuite le modèle et vérifiez le résultat :

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize accepte q8_0, q4_K_S et q4_K_M. Il n’existe pas d’option q6_K ou q5_K_M ici. Pour ces formats, utilisez l’outil de llama.cpp pour quantifier le modèle, puis importez le fichier GGUF obtenu. Cette méthode d’importation présente un autre piège : une incompatibilité de chat template peut produire des réponses incohérentes. La section importer un fichier GGUF dans Ollama explique cette procédure. La ligne quantization de ollama show permet de vérifier que le build a appliqué vos paramètres.

Ce que vous verrez en cas de problème

Tout s’exécute sur le CPU alors que vous attendiez le GPU. Consultez la colonne PROCESSOR :

ollama ps

Elle affiche 100% GPU, 100% CPU ou une répartition telle que 48%/52% CPU/GPU. Une répartition signifie que les poids et le cache KV ne tenaient pas dans la VRAM (mémoire vidéo, c’est-à-dire la mémoire de la carte graphique). Une partie du modèle a donc été placée dans la mémoire système. La vitesse retombe alors presque au niveau du CPU seul, car chaque token doit attendre la partie la plus lente. Réduisez la fenêtre de contexte, quantifiez le cache ou utilisez un build plus petit. Ajouter des cœurs ne changera rien.

Le modèle est tué pendant son chargement. Vérifiez le kernel et le journal du service :

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Une ligne contenant Out of memory: Killed process signifie que le total des poids, du cache KV et des buffers a dépassé la mémoire disponible sur la machine. Sur un VPS sans swap configuré, la machine entière peut se bloquer pendant plusieurs secondes avant l’apparition de cette ligne.

Les réponses sont moins bonnes alors que vous n’avez rien modifié. Deux builds du même modèle peuvent coexister dans ollama ls avec des tags différents. Un script qui utilise le nom sans suffixe suivra la référence vers laquelle la bibliothèque le pointe désormais. Exécutez ollama show avec le tag exact demandé par votre client et consultez la ligne quantization, au lieu de vous fier au nom indiqué dans votre fichier de configuration.

FAQ

Quelle quantification Ollama dois-je télécharger ?

Commencez par q4_K_M. Il s’agit du tag par défaut fourni par la bibliothèque Ollama pour la plupart des modèles. Ainsi, ollama pull qwen3:8b et ollama pull qwen3:8b-q4_K_M téléchargent le même fichier. Passez à q8_0 uniquement si la mémoire est suffisante et que la tâche tolère mal les petites erreurs, par exemple l’appel d’outils ou la génération de JSON structuré. Lorsque le budget mémoire est fixe, un modèle plus grand en q4_K_M est généralement plus performant qu’un modèle plus petit en q8_0. Testez donc cette combinaison avant de consacrer davantage de RAM à la précision.

q4_K_M signifie-t-il vraiment quatre bits par poids ?

Non. Mesuré sur Llama 3.1 8B, il utilise 4.89 bits par poids. Chaque bloc de poids stocke sa propre échelle, et les tenseurs les plus sensibles utilisent un type plus large. Pour la même raison, Q8_0 utilise 8.5 bits, et non huit. Utilisez cette valeur mesurée pour vos estimations : le nombre de paramètres multiplié par le nombre de bits par poids, puis divisé par huit, donne la taille du fichier en octets.

Combien de RAM faut-il à un modèle 8B sur un VPS utilisant uniquement le CPU ?

Additionnez les poids, le cache KV et une marge. Qwen3 8B en q4_K_M utilise 5.2 Go pour les poids. Avec la fenêtre par défaut de 4096 tokens, le cache ajoute 0.6 Go, soit un minimum d’environ 5.8 Go avant de compter les tampons de calcul et le système d’exploitation. Avec une fenêtre de 32k, le cache seul utilise 4.83 Go. Prévoyez 8 Go pour une fenêtre courte et 16 Go pour une fenêtre longue.

Pourquoi mon modèle utilise-t-il 100 % du CPU alors que le serveur dispose d’un GPU ?

Exécutez ollama ps et consultez la colonne PROCESSOR. 100% CPU, ou une répartition telle que 48%/52% CPU/GPU, signifie que les poids et le cache KV ne tenaient pas dans la VRAM. Ollama a donc placé une partie ou la totalité du modèle dans la mémoire système. La cause habituelle est une fenêtre de contexte trop grande pour la carte, car le cache est alloué pour toute la fenêtre au chargement du modèle. Réduisez la fenêtre avec OLLAMA_CONTEXT_LENGTH, définissez OLLAMA_KV_CACHE_TYPE=q8_0 pour diviser le cache par deux ou téléchargez une quantification plus petite.