---
type: "Comparison"
title: "IQ3_S vs Q4_K_M : quelle quantification GGUF pour tenir 27B en 16 Go"
description: "IQ3_S (GSQ+RCO) vs Q4_K_M (classique, uniforme)"
resource: "https://www.contextstudios.ai/fr/comparaison/iq3-s-vs-q4-k-m"
language: "fr"
tags: ["IQ3_S", "Q4_K_M", "quantification GGUF", "16 Go VRAM", "Qwen3.8-27B", "llama.cpp"]
generated:
  by: "process:contextstudios-md/1"
  at: "2026-10-08T22:10:35.589Z"
status: "stable"
---

# IQ3_S vs Q4_K_M : quelle quantification GGUF pour tenir 27B en 16 Go

La différence tient dans le plan mémoire : Q4_K_M compressse un modèle 27B à environ 15 Go et remplit presque toute une carte 16 Go — l'espace restant pour le KV-cache devient le goulot pour la longueur de contexte. IQ3_S atteint 11,8 Go grâce à la recherche par tenseur (GSQ+RCO, IST-DASLab) et conserve 99,8 % de la moyenne des tâches par rapport à la base BF16, soit une réduction de 4,6×. Sur un portable 16 Go, IQ3_S est le point final rationnel ; Q4_K_M reste le valeur sûre dès que la carte offre plus de place.

## Comparaison Détaillée

| Facteur | IQ3_S (GSQ+RCO) | Q4_K_M (classique, uniforme) | Gagnant |
|--------|------|------|--------|
| Taille du fichier | 11,8 Go — 4,6× plus petit que la base BF16 (53,8 Go) | environ 15 Go — environ 3,6× plus petit que la base BF16 | IQ3_S (GSQ+RCO) |
| Marge pour le KV-cache | 3–4 Go restent sur une carte 16 Go — les contextes jusqu’à ~100k tokens restent utilisables | moins de 1 Go restant — les fenêtres longues butent tôt sur le mur VRAM | IQ3_S (GSQ+RCO) |
| Qualité des tâches | 99,8 % de moyenne : AIME25 100,00, GPQA-Diamond 89,39, LiveCodeBench v6 85,71 — AIME et LCB au niveau exact de la base | presque sans perte sur les modèles denses, typiquement 99–100 % de la moyenne FP16 | Égalité |
| Débit de décodage | ~40 tok/s mesurés sur RTX 5060 Ti 16 Go, 552 tok/s de préfill à 112k de contexte | aussi rapide sur les grandes cartes ; sur 16 Go, le fichier plus petit déplace moins de mémoire de poids | IQ3_S (GSQ+RCO) |
| Compatibilité | fichier GGUF standard, fonctionne d’emblée dans llama.cpp, Ollama et LM Studio | défaut établi de toute la chaîne GGUF | Égalité |
| Stabilité en contexte long | 17–30 tok/s en fin de fenêtre 112k pleine — le débit baisse avec le KV-cache mais reste utilisable | fenêtre et cache se disputent les derniers gigaoctets ; risque OOM en haut de plage | IQ3_S (GSQ+RCO) |
| Auditable | attribution des tenseurs fournie en .rco-allocation.txt plus matrice d’importance (1000 × 4096 tokens) dans le dépôt | schéma standardisé et bien documenté, sans fichier d’audit par tenseur | IQ3_S (GSQ+RCO) |
| Prise en charge multimodale | fichier mmproj identique (BF16, 0,9 Go) pour tous les paliers IQ ; build MTP +0,35 Go | même fichier mmproj — pas d’inconvénient, il est identique pour les deux paliers | Égalité |

## Statistiques Clés

- **Qwen3.8-27B en IQ3_S : 11,8 Go à 3,50 bpw, AIME25 100,00 / GPQA-Diamond 89,39 / LiveCodeBench v6 85,71 — contre 53,8 Go en base BF16 (GPQA 89,90)** — [fiche du modèle IST-DASLab](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF) (2026)
- **~40 tok/s en moyenne avec IQ3_S sur RTX 5060 Ti 16 Go ; 552 tok/s de préfill à 112k de contexte ; 25–30 tok/s en fin de fenêtre pleine** — [mesures communautaires (discussion HF)](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/discussions/6) (2026)
- **~136 tok/s avec IQ3_S sur RTX 5090, contexte long** — [fiche du modèle IST-DASLab](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF) (2026)
- **Avec l’ancienne logique uniforme, un modèle dense 27B exigeait 18–20 Go ; la recherche par tenseur le fait passer sous la limite des 16 Go** — [fiche du modèle IST-DASLab](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF) (2026)
- **Même le plus petit palier IQ2_XS (8,4 Go, 2,50 bpw) atteint 96,67 sur AIME25 — au-dessus de la base BF16 en zéro-shot** — [fiche du modèle IST-DASLab](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF) (2026)
- **La compression dense a un plancher dur vers 2,5 bpw : en dessous, la moyenne des tâches s’effondre** — [fiche du modèle IST-DASLab](https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF) (2026)

## Choisissez IQ3_S (GSQ+RCO) quand...

- 16 Go de VRAM est le plafond dur
- des contextes jusqu’à ~100k avec vraie marge
- une moyenne de tâches au-dessus de 99 %
- une attribution par tenseur auditable est souhaitée

## Choisissez Q4_K_M (classique, uniforme) quand...

- plus de 18 Go de VRAM sont disponibles
- la chaîne attend le schéma uniforme standard
- les caches Q4_K_M existants ne doivent pas être reconstruits
- la largeur de bits maximale par couche compte

## Notre Recommandation

IQ3_S gagne sur les cartes 16 Go sur trois dimensions — taille de fichier, marge KV, stabilité en contexte long — pour une qualité pratiquement identique (99,8 % de moyenne, AIME25 et LiveCodeBench exactement au niveau de la base). Q4_K_M tient la distance quand la carte offre plus de 18 Go et que le schéma uniforme est le standard attendu. Règle de décision : mesurez la fenêtre de contexte réellement utilisée, puis choisissez le fichier qui laisse 3 Go au cache et aux activations — ce calcul place IQ3_S sur 16 Go, Q4_K_M juste en dessous.

## Questions Fréquentes

**Q: Quel fichier prendre sur une carte 16 Go ?**
A: IQ3_S (11,8 Go) pour la qualité pleine et un contexte 100k–112k. IQ2_S (9,3 Go) s’il faut plus de marge pour de gros batches ou des fenêtres plus longues — il atteint déjà le niveau de base sur AIME25. IQ2_XS convient aux portables 12 Go, où 8,4 Go plus le mmproj laissent de l’air entre les layouts.

**Q: Q4_K_M devient-il obsolète ?**
A: Non. Au-delà de 16 Go, Q4_K_M reste le défaut éprouvé, presque sans perte, et toutes les chaînes le comprennent. L’avantage d’IQ3_S est une conséquence géométrique, pas une magie d’algorithme : 3,4 Go de poids en moins, 3,4 Go de cache en plus.

**Q: Les 40 tok/s valent-ils pour tout contexte ?**
A: Retenez une plage, pas un chiffre : jusqu’à ~50 tok/s en début de fenêtre, 25–30 tok/s en fin de contexte 112k plein. Le préfill reste à 552 tok/s, en parallèle sur les tokens du prompt.

**Q: Faut-il la variante -mtp ?**
A: Si votre harnais accepte le décodage spéculatif : oui. La tête MTP ne coûte que 0,35 Go, ne change pas les poids et accélère le décodage de façon mesurable. Sans support MTP, le fichier standard suffit.

