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 avec moins de bits que le fichier utilisé pour son entraînement. 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 initiale, et la machine lit environ quatre fois moins d’octets pour produire chaque token. Les poids sont arrondis sur une grille moins fine, mais 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 nettement plus faible et davantage de tokens par seconde, en échange d’une légère perte de précision. La suite explique comment estimer ces deux aspects pour un modèle et une machine donnés, 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 étiquette de quantification Ollama comme q4_K_M

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

Le nombre indique la largeur cible. q4 signifie que la plupart des tenseurs de poids sont empaqueté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 quantification K. Les poids sont regroupés en petits blocs. Chaque bloc stocke sa propre échelle à côté des valeurs empaqueté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 échelles propres à chaque bloc permettent à un fichier sur quatre bits de rester exploitable. Elles expliquent aussi qu’un fichier sur quatre bits n’utilise jamais exactement quatre bits par poids.

La dernière lettre indique le mélange. S, M et L déterminent le nombre de tenseurs promus au-delà de la largeur cible. Dans q4_K_M, les tenseurs qui subissent le plus de pertes lors de l’arrondi sont stockés sur 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 présent sur disque au lieu de vous fier au nom que vous avez 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.

Bits par poids : la taille du fichier en dépend

Toute estimation de taille commence par un nombre : le nombre de bits que le format utilise par poids, en 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 correctement à tout modèle dense de forme comparable.

[
  {
    "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 la plus surprenante. Q4_K_M n’utilise pas quatre bits par poids. Il utilise 4.89 bits, car les échelles de bloc et les tenseurs conservés en haute précision occupent eux aussi de l’espace. Pour la même raison, Q8_0 utilise 8.5 bits au lieu de huit. Utilisez la valeur mesurée : le calcul donne une taille à quelques pour cent près 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

C’est le fichier Q4_K_M de 4.58 GiB, obtenu à partir de deux nombres. Cette valeur 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 un tag q4_K_M, un tag q8_0 et un tag fp16 pour la plupart des familles. Voici les tailles de Qwen3 en août 2026, relevées dans la liste des tags sur la page du modèle.

[
  {
    "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
  }
]

Le tag par défaut est important ici. ollama pull qwen3:8b télécharge exactement les mêmes 5.2 Go que ollama pull qwen3:8b-q4_K_M, car le tag sans suffixe est le build q4_K_M. Q4_K_M n’est pas un compromis que la bibliothèque propose à contrecœur. C’est le format par défaut choisi en amont. Le reprendre est donc le premier choix logique pour tout modèle que vous n’avez pas encore testé vous-même. Le même raisonnement guide le choix des tags dans exécuter Qwen 3 sur un VPS.

Les proportions restent valables pour chaque ligne. Passer de q4_K_M à q8_0 coûte environ soixante-dix pour cent de plus, et non exactement deux fois plus, car les tenseurs d’embedding et de sortie n’évoluent pas comme 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. Cette taille dépasse déjà ce qu’un serveur de 16 Go peut héberger 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 deuxième 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és et de valeurs 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 avec un prompt 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 chiffres proviennent de la configuration du modèle : 36 couches, 8 têtes de clés/valeurs et une dimension de tête de 128. ollama show vous donne l’architecture et le nombre de paramètres. Le 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 ne représente alors plus une erreur d’arrondi.

[
  {
    "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 le plancher pour l’ensemble du modèle passe à 10 Go. Parlez de plancher, car les buffers de calcul et le système d’exploitation s’y ajoutent. 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 comme service :

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Pour une installation systemd, placez-la plutôt 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 avec laquelle le modèle en cours d’exécution a réellement été chargé. 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 de 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 réglage. Sur une petite machine avec une longue fenêtre, réduire de moitié le cache libère davantage de mémoire que toute autre modification unique. Définir num_ctx et comprendre son coût détaille la fenêtre elle-même.

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

Les poids du modèle, le cache KV, la marge pour le système d’exploitation et les autres processus en cours d’exécution doivent tous tenir en mémoire. 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 il reste très peu de marge. Ne prévoyez pas un modèle 8B avec une fenêtre de 32k dans ce cas, car le minimum de 10 GB dépasse déjà la mémoire disponible.

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 occupe 9.3 GB de poids et tient avec une fenêtre de taille modeste. Un modèle 8B en q8_0 occupe 8.9 GB, donc il tient 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 approchera la limite de mémoire. Surveillez donc ollama ps au lieu de partir du principe que tout tiendra.

Ce que la quantification dégrade en premier

L’erreur de quantification ne se répartit pas uniformément entre les capacités d’un modèle. La fluidité résiste le plus longtemps. C’est précisément pour cela que les dommages sont difficiles à repérer : un modèle mal quantifié produit encore des phrases correctes. La précision se dégrade en premier. Il en va de même pour la restitution exacte d’un numéro de version, d’une signature d’API ou d’une date. Les longues chaînes de raisonnement sont également touchées : une petite erreur à l’étape deux peut produire une mauvaise réponse à l’étape huit. Les formats de sortie stricts posent enfin problème : une seule parenthèse incorrecte peut faire é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 code est la version la plus exigeante de ce test, car il enchaîne les appels d’outils. Ainsi, pointer un agent vers votre serveur Ollama permet de révéler une quantification trop agressive en une après-midi.

En dessous de quatre bits, la perte devient importante. Les types q3 et deux bits existent pour les utilisateurs qui cherchent à faire tenir un grand modèle sur un matériel limité. Ils constituent une option réelle lorsque l’alternative consiste à ne pas exécuter le modèle du tout. Ils constituent un 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 trancher de cette manière. Exécutez les deux modèles avec trente de vos propres prompts, puis examinez les résultats.

Quand q8_0 ou fp16 justifie la RAM

Utilisez q8_0 lorsque la mémoire est réellement disponible et que la tâche pénalise les petites erreurs : extraction structurée, appels d’outils ou code qui doit compiler. Vous achetez alors 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 vous avez besoin du fichier source, soit vous mesurez une référence pour déterminer ce que votre build en 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 peuvent pas repérer en aveugle. Sur une machine équipée uniquement d’un CPU, le débit de tokens tombe aussi au 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 pour un modèle 14B, contre 8.9 Go pour un modèle 8B : la quantité de RAM (mémoire vive) est presque identique, mais le modèle plus grand en sait davantage. Testez cela avec vos propres prompts au lieu de vous en remettre à cette règle.

L’inférence uniquement sur CPU 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, car la production de chaque token nécessite de lire tous les poids une fois. Cela impose une limite qui ne dépend pas du nombre de cœurs que vous avez 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 DDR4-3200 en double canal. La bande passante dont vous disposez est plus faible, 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.

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

Ne prenez aucun de ces calculs pour acquis. Mesurez le nombre de tokens par seconde sur votre propre machine avec le même prompt pour chaque niveau de quantification, et laissez vos mesures primer sur ces estimations.

Créer vous-même un modèle quantifié

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. Indiquez les poids non quantifiés dans un Modelfile :

FROM /path/to/my/model/f16

Créez 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 fourni avec llama.cpp pour effectuer la quantification, puis importez le fichier GGUF obtenu. La ligne quantization de ollama show permet de vérifier que la compilation a bien appliqué les paramètres demandés.

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 (la mémoire vidéo de la carte graphique). Une partie du modèle a donc été placée dans la mémoire système. Le débit se rapproche alors de celui 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 une build plus petite. 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 devenues moins bonnes alors que vous n’avez rien changé. 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 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. C’est le tag par défaut utilisé par la bibliothèque Ollama pour la plupart des modèles. ollama pull qwen3:8b et ollama pull qwen3:8b-q4_K_M téléchargent donc le même fichier. Passez à q8_0 uniquement si vous disposez de mémoire supplémentaire 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 la mémoire disponible est fixe, un modèle plus grand en q4_K_M est généralement meilleur qu’un modèle plus petit en q8_0. Testez donc cette combinaison avant d’allouer 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 en effet son propre facteur d’échelle, et les tenseurs les plus sensibles utilisent un type plus large. Pour la même raison, Q8_0 utilise 8.5 bits au lieu de huit. Pour vos estimations, utilisez la valeur mesurée : le nombre de paramètres multiplié par le nombre de bits par poids, puis divisé par huit, donne la taille du fichier en octets.

De combien de RAM un modèle 8B a-t-il besoin sur un VPS utilisant uniquement le CPU ?

Additionnez les poids, le cache KV et une marge. Les poids de Qwen3 8B en q4_K_M occupent 5.2 Go. Avec la fenêtre de 4096 tokens par défaut, le cache ajoute 0.6 Go, soit un minimum d’environ 5.8 Go avant de compter les buffers de calcul et le système d’exploitation. Avec une fenêtre de 32k, le cache seul occupe 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 la machine dispose d’un GPU ?

Exécutez ollama ps et lisez 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 capacité de 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.