Gemma 4 ne rentrait pas dans mon GPU — jusqu'à ce que je supprime ce qu'il n'utilisait pas

Hier, je vous présentais les modèles Gemma 4 de Google. Des modèles impressionnants, sortis le 3 avril 2026 sous licence Apache 2.0, avec un système de raisonnement intégré et une architecture multimodale texte + image.

Le problème : ils étaient trop gros pour mon GPU.

Le modèle E4B (le plus intéressant pour l'analyse en profondeur) demandait 9,8 Go de VRAM. Mon GPU n'en a que 6.

Du coup, j'ai trouvé une parade. En les passant en text-only, ils rentrent dans 6 Go — et en bonus, leurs performances explosent.

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.

Le problème : 3 modèles dans 6 Go, c'est serré

Mon infrastructure d'IA locale — que je décrivais dans mon article sur Ollama comme mon « 286 à moi » — tourne avec 3 modèles Ollama chargés en permanence :

Total : 4 673 Mo sur 6 000 Mo disponibles. Il reste 1 327 Mo de marge.

Quand j'ai voulu intégrer Gemma 4 pour remplacer qwen3 sur certaines tâches d'analyse profonde, le mur était immédiat :

• gemma4:e2b (le petit) : 2 800 Mo — possible en déchargeant d'autres modèles, mais ça casse le pipeline
• gemma4:e4b (le puissant) : 9 830 Mo — littéralement impossible, il dépasse à lui seul la VRAM totale

Chaque appel au modèle E4B nécessitait de décharger l'embedding, ce qui interrompait la recherche sémantique pendant 2 à 5 secondes. Inacceptable en production, même pour des tâches asynchrones. J'avais déjà documenté ces contraintes lors de l'audit de performance de mon PC.

La découverte : 50 % de la VRAM servait à voir des images

Gemma 4, comme beaucoup de modèles récents (LLaVA, Qwen2-VL, Phi-3-vision), est un VLM — un modèle vision-langage. Il embarque un composant appelé mmproj (multimodal projector) : un encodeur d'images qui traduit les pixels en tokens compréhensibles par le transformer.

Ce composant pèse lourd :

Dans mon cas d'usage — analyse de confiance, scoring de qualité, classification de tâches — aucune image n'est jamais envoyée au modèle. Le composant vision est du poids mort.

C'est comme acheter un SUV pour faire des courses en ville : vous payez le poids du châssis renforcé et de la garde au sol sans jamais quitter le bitume.

La solution : créer des variants text-only

Étape 1 — trouver les bons fichiers GGUF

Les modèles Ollama officiels (gemma4:e2b, gemma4:e4b) incluent systématiquement le composant vision. Pour s'en débarrasser, il faut partir de fichiers GGUF « text-only » — des versions du modèle repackagées sans le multimodal projector.

Plusieurs packagers sur Hugging Face proposent ces variants. Les fichiers GGUF text-only sont identifiables par la mention "text" dans leur nom : gemma-4-9b-text-Q4_K_M.gguf au lieu de gemma-4-9b-it-Q4_K_M.gguf.

La quantization Q4_K_M (4 bits, K-Quant Medium) est le sweet spot pour les modèles de 2B à 9B paramètres : elle réduit la taille de ~55 % avec une perte de qualité inférieure à 4 %.

Étape 2 — importer dans Ollama

# Télécharger le GGUF text-only depuis Hugging Face
wget "https://huggingface.co/bartowski/gemma-4-9b-text-GGUF/resolve/main/gemma-4-9b-text-Q4_K_M.gguf"

# Créer le modèle dans Ollama
ollama create gemma4-e4b-q4km-text --from ./gemma-4-9b-text-Q4_K_M.gguf

Étape 3 — contraindre le contexte pour économiser encore plus

Le KV cache (la mémoire qui stocke l'historique de conversation) est proportionnel à la taille du contexte. Gemma 4 supporte jusqu'à 128K tokens de contexte — mais pour des tâches de scoring et de classification, 4 096 tokens suffisent largement.

FROM gemma4-e4b-q4km-text

# Réduire le contexte de 32k à 4k → -87 % de KV cache
PARAMETER num_ctx 4096

# Paramètres officiels Gemma 4
PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Cette seule ligne num_ctx 4096 récupère environ 3 400 Mo de VRAM. C'est la décision la plus impactante de tout le processus — un principe d'optimisation de tokens appliqué au niveau matériel.

ollama create gemma4-e4b-q4km-text-4k -f Modelfile

Les résultats : c'est spectaculaire

VRAM : ça rentre (enfin)

*La mesure initiale du E2B multimodal était sous-estimée (mode CPU offload partiel). En mode pure GPU, la mesure est plus fiable.

Le E4B text-only à 6 364 Mo ne cohabite toujours pas avec bge-m3 (655 Mo) simultanément. Mais avec une stratégie de chargement/déchargement séquentiel (500 ms d'overhead), c'est exploitable — surtout pour des tâches asynchrones qui tournent quand personne n'est devant l'écran.

Vitesse : +75 % de tokens par seconde

L'accélération vient de deux facteurs :
1. Le GPU ne charge plus l'encodeur vision — la bande passante mémoire est intégralement dédiée au texte
2. Le KV cache réduit (pour E4B) — moins d'accès mémoire à chaque token généré

61,5 tokens par seconde sur un modèle 2B, c'est une réponse de 200 mots en moins de 2 secondes. Sur un GPU grand public.

Qualité : aussi bon, voire mieux

C'est le résultat le plus surprenant. La suppression du composant vision n'a pas dégradé la qualité — elle l'a légèrement améliorée :

Le Brier score mesure la calibration de confiance : est-ce que le modèle sait dire « je ne suis pas sûr » quand il devrait ? Un score de 0,041 signifie que ses déclarations de confiance sont presque parfaitement alignées avec sa précision réelle.

L'hypothèse : en supprimant le mmproj, on libère de la capacité de représentation interne pour les tâches textuelles. Le modèle concentre toute sa puissance sur ce qu'on lui demande réellement.

Validation : le modèle résiste-t-il aux pièges ?

Un bon score sur des questions faciles ne prouve rien. J'ai donc lancé un probe adversarial avec 10 questions stratégiques, dont 3 questions pièges conçues pour tromper le modèle :

Confiance moyenne sur les pièges : 46,7 % — exactement ce qu'on attend d'un modèle bien calibré.

Ce comportement est critique pour un système de routing automatique : quand le modèle doute, il escalade vers un modèle plus puissant (Claude Haiku) au lieu de répondre n'importe quoi. C'est exactement le type de surveillance que j'ai mis en place sur mes agents IA.

L'architecture finale : une cascade de précision

Le text-only E4B s'intègre dans une cascade de décision à 3 niveaux :

Question entrante
       │
       ▼
[gemma4-e2b-text] — Analyse initiale rapide (~40 ms)
       │
       ├── Confiance ≥ 92 % → Réponse validée ✓
       │
       └── Confiance < 92 % → Escalade
              │
              ▼
       [gemma4-e4b-text-4k] — Analyse approfondie (~80 ms)
              │
              ├── Confiance ≥ 92 % → Réponse validée ✓
              │
              └── Confiance < 92 % → Escalade vers Claude

Le E2B filtre le volume (questions simples), le E4B traite les cas ambigus, et Claude Haiku prend le relais pour les situations vraiment incertaines.

Coût total de cette cascade : 0 € pour les deux premiers niveaux (modèles locaux) + quelques centimes par jour pour les escalades vers Claude. L'ensemble est observé par 920 appels de métriques quotidiens.

Ce que ça change concrètement

Le guide en 5 minutes pour reproduire ça chez vous

Prérequis : Ollama 0.20+, un GPU avec au moins 6 Go de VRAM (NVIDIA, AMD ou Apple Silicon).

# 1. Télécharger le GGUF text-only
wget "https://huggingface.co/bartowski/gemma-4-9b-text-GGUF/resolve/main/\
gemma-4-9b-text-Q4_K_M.gguf" -O gemma4-text.gguf

# 2. Créer le modèle de base
ollama create gemma4-e4b-text --from gemma4-text.gguf

# 3. Créer un Modelfile avec contexte réduit
cat > Modelfile << 'EOF'
FROM gemma4-e4b-text
PARAMETER num_ctx 4096
PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64
EOF

# 4. Créer le variant optimisé
ollama create gemma4-e4b-text-4k -f Modelfile

# 5. Tester
ollama run gemma4-e4b-text-4k "Explique le principe de moindre action en physique."

Si vous n'avez besoin que du modèle 2B (plus rapide, suffisant pour du triage) :

wget "https://huggingface.co/bartowski/gemma-4-2b-text-GGUF/resolve/main/\
gemma-4-2b-text-Q4_K_M.gguf" -O gemma4-e2b-text.gguf
ollama create gemma4-e2b-text --from gemma4-e2b-text.gguf

Les leçons à retenir

1. Les modèles multimodaux ne sont pas toujours le bon choix. Si vous ne traitez que du texte, vous payez un surcoût VRAM permanent pour une fonctionnalité inutilisée. La tendance à tout rendre multimodal crée un gaspillage silencieux sur les GPU contraints.

2. Le contexte est le premier levier d'optimisation VRAM. Passer de 32K à 4K tokens de contexte a économisé plus de VRAM que la suppression du composant vision. Si vos tâches n'ont pas besoin d'un long historique, réduisez num_ctx en priorité.

3. Q4_K_M est le sweet spot. La quantization Q3 (3 bits) détruit la qualité (33 % de score dans mes tests). Q4_K_M offre le meilleur compromis taille/qualité pour les modèles 2B à 9B.

4. La calibration de confiance est plus importante que la précision brute. Un modèle qui dit « je ne sais pas » quand il ne sait pas est plus utile qu'un modèle qui répond toujours avec 100 % de confiance — même s'il a raison plus souvent.

5. L'IA locale viable, c'est maintenant. Avec un GPU à 200 € et des modèles open source sous Apache 2.0, on fait tourner une cascade d'analyse à 3 niveaux sans serveur cloud, sans abonnement, sans latence réseau.

Pour aller plus loin

• Gemma 4 — page officielle Google DeepMind
• Annonce Gemma 4 — blog Google
• Guide complet d'exécution locale avec Ollama
• Guide VRAM Gemma 4 par taille de modèle
• Quantizations GGUF bartowski sur Hugging Face

Est-ce que vous avez déjà tenté de faire tourner des LLM en local sur un GPU contraint ? Dites-moi en commentaire quel modèle vous avez réussi (ou pas) à caser dans votre VRAM.

Retrouvez mes articles précédents :
- Mon 286 à moi, c'est Ollama — pourquoi et comment j'ai monté mon stack LLM local
- L'IA locale m'a révélé les failles cachées de mon PC — audit performance GPU/CPU
- 920 appels LLM par jour à votre insu — l'architecture d'observabilité complète
- Quand vos agents IA oublient les consignes — la surveillance des agents autonomes

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

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.