Flash Attention + KV Cache q8_0 : pourquoi les modèles pensants en profitent plus que les modèles instruct

Hier, je vous parlais d'une technique pour multiplier par dix le contexte de vos modèles locaux avec deux variables d'environnement Ollama : Flash Attention et KV Cache q8_0. Sur gemma4, je suis passé de 10k à 32k tokens. Sur qwen3.5, de 8k à 80k. Le tout sur une RTX 3050 6 Go, sans changer de matériel.

Une fois la config en place, j'ai fait ce que tout le monde aurait fait : je l'ai déployée sur tous mes modèles. gemma4, qwen3, granite, deepseek — tout le catalogue local y est passé.

Et c'est là que j'ai remarqué quelque chose que je n'avais pas anticipé.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Ce que j'ai vu en appliquant la config à tous mes modèles

Sur mes modèles instruct classiques — ceux qui répondent directement sans raisonnement intermédiaire — le gain était conforme à ce que j'avais mesuré : plus de contexte, une vitesse stable ou légèrement améliorée. Rien d'inattendu.

Mais sur les modèles pensants, la différence était nettement plus marquée.

Un modèle pensant — ou reasoning model — c'est un modèle qui génère des tokens de raisonnement avant de produire sa réponse. Au lieu d'écrire directement « la réponse est 42 », il va d'abord produire une chaîne interne du type « analysons le problème... l'équation donne... vérifions les hypothèses... » puis seulement formuler la réponse finale. Ces tokens de raisonnement sont invisibles pour l'utilisateur (ou apparaissent dans un bloc dédié), mais ils comptent dans le contexte.

Et chaque token de raisonnement, comme tout token qui traverse le modèle, laisse une entrée dans le KV cache.

Du coup, à prompt égal, un modèle pensant remplit le KV cache bien plus vite qu'un modèle instruct. Là où un instruct traite 500 tokens de prompt et génère 200 tokens de réponse, un modèle pensant peut générer 2 000 tokens de raisonnement avant même de commencer sa réponse. Résultat : le cache KV est cinq à dix fois plus sollicité.

C'est précisément pour ça que la quantification q8_0 change tout pour ces modèles.

Pourquoi les modèles pensants sont les vrais gagnants du KV cache q8_0

Revenons aux fondamentaux. Le KV cache stocke les clés et les valeurs de chaque token déjà traité, pour éviter de les recalculer à chaque nouveau token. Sans cache, l'attention serait en O(N²) à chaque étape — avec cache, elle est en O(N) par nouveau token.

Le problème, c'est que ce cache grandit linéairement avec le nombre total de tokens (prompt + réponse). Et en FP16, chaque entrée occupe 2 octets par élément, par tête, par couche.

Sur un modèle instruct, le ratio est simple : vous avez N tokens de prompt et M tokens de réponse. Le cache pèse N+M.

Sur un modèle pensant, vous avez N tokens de prompt, R tokens de raisonnement, et M tokens de réponse. Le cache pèse N+R+M.

Et R, le raisonnement, peut être largement supérieur à N+M. J'ai vu des sessions où qwen3 avec le mode think activé générait 3 000 tokens de raisonnement pour une réponse de 400 tokens. Le cache était saturé de tokens « invisibles » qui ne servaient qu'au raisonnement interne.

C'est là que le q8_0 devient un multiplicateur. En passant le cache de 16 bits à 8 bits par élément, vous divisez par deux la consommation de l'ensemble — y compris les tokens de raisonnement. Et comme ces tokens représentent souvent la majorité du cache, le gain est proportionnellement plus grand que sur un modèle instruct.

Ce n'est pas que les modèles pensants « profitent mieux » du q8_0 au sens magique du terme. C'est que leur goulot d'étranglement principal est le cache, et que la quantification du cache le débloque. Sur un modèle instruct, le goulot est souvent ailleurs — bande passante mémoire des poids, parallélisme des couches. Le q8_0 aide, mais la différence est moins spectaculaire parce que le cache n'était pas le facteur limitant.

L'impossibilité de séparer Flash Attention et KV cache q8_0

L'autre découverte, c'est qu'il est techniquement impossible — et conceptuellement absurde — de vouloir séparer les effets de Flash Attention et du KV cache q8_0.

Je vois passer des questions du type : « c'est Flash Attention ou le q8_0 qui fait le plus de différence ? » ou « quel est le gain marginal de chacun ? ». La réponse honnête, c'est qu'on ne peut pas répondre.

Voici pourquoi.

Flash Attention optimise le calcul. Son algorithme (Tri Dao et al., 2022) découpe la matrice d'attention en tuiles et fusionne les opérations pour éviter d'écrire les résultats intermédiaires dans la mémoire haute bande passante (HBM). Il réduit la pression sur la bande passante mémoire pendant le calcul de l'attention. Mais il ne change rien au stockage permanent du cache.

KV cache q8_0 optimise le stockage. Il compresse chaque élément du cache de 16 bits à 8 bits. Il réduit la consommation VRAM permanente du cache. Mais il ne change rien à la façon dont l'attention est calculée.

Ces deux optimisations attaquent deux goulots d'étranglement différents. Sur un GPU 6 Go comme le mien :

• Sans q8_0, le cache FP16 sature la VRAM avant que Flash Attention n'ait pu montrer son intérêt — vous êtes en OOM avant d'atteindre un contexte où le tiling ferait une différence.
• Sans Flash Attention, le calcul de l'attention standard consomme plus de bande passante, ce qui réduit la marge disponible pour le contexte — même avec un cache quantifié.

Les deux sont nécessaires ensemble. Les activer séparément pour les comparer n'a pas de sens : désactiver l'un casse le bénéfice de l'autre. C'est un système à deux variables couplées, pas deux optimisations indépendantes qu'on peut benchmarker l'une après l'autre.

Dans la pratique, sur ma RTX 3050, voici ce que donnent les différentes combinaisons — les valeurs pour FA seul et q8_0 seul sont extrapolées à partir du comportement observé de la config complète :

Ce tableau montre bien que ni FA ni q8_0 ne suffisent seuls pour atteindre le maximum. Le plein potentiel (32k, 44 TPS) n'est atteint que quand les deux sont actifs. C'est la combinaison qui débloque le contexte, pas l'un ou l'autre.

Ce qu'il faut retenir

Après 24 heures de recul sur mes benchmarks d'hier, trois apprentissages supplémentaires :

1. Les modèles pensants sont les vrais gagnants du KV cache q8_0. Pas parce que la quantification leur est plus favorable, mais parce que leur goulot d'étranglement dominant est la taille du cache — une conséquence directe des tokens de raisonnement. Plus votre modèle raisonne, plus le q8_0 est rentable.

2. Flash Attention et KV cache q8_0 sont indissociables. L'un optimise le calcul, l'autre le stockage. Les tester séparément, c'est comme comparer l'aérodynamisme et le moteur d'une voiture : vous avez besoin des deux pour aller vite. Le seul benchmark qui compte, c'est la config complète.

3. La variable critique, c'est le ratio tokens de raisonnement / tokens de réponse. Si votre use case implique beaucoup de raisonnement (analyse de code, résolution de problèmes, planification), activez le q8_0 en priorité. Si vous faites surtout de la génération directe (traduction, résumé, reformulation), le gain sera réel mais moins spectaculaire.

La config complète tient toujours en deux lignes dans votre fichier systemd :

Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Si vous utilisez des modèles pensants régulièrement, ces deux flags ne sont pas optionnels. Ils sont indispensables.

Vous utilisez des modèles pensants au quotidien ? Vous avez constaté la même différence avec le q8_0 sur vos modèles instruct vs reasoning ? Dites-moi en commentaire — et si vous avez des chiffres comparatifs sur d'autres modèles (deepseek-r1, llama avec reasoning), je suis preneur.

Pour aller plus loin

Sources et références externes :
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — papier original de Tri Dao et al. (Stanford, 2022)
- Ollama GPU documentation — configuration des variables d'environnement GPU

Articles liés sur ce blog :
- Comment j'ai multiplié par 10 le contexte de mes modèles locaux avec Flash Attention et KV Cache q8_0 — l'article d'hier, avec la config pas à pas et les benchmarks complets
- J'ai benchmarké Qwen3 sur GPQA et HLE — les résultats m'ont surpris — focus sur les capacités de raisonnement de qwen3
- Benchmark de 30 modèles locaux — le classement définitif (avril 2026)

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Je documente en public ce que je construis en privé. Abonnez-vous pour ne pas manquer les prochains articles sur l'IA locale, les agents autonomes et l'architecture de systèmes LLM.

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.