Réglages, limites mémoire et upgrade matériel réaliste

L’IA locale pour le développement progresse vite, et certains modèles comme qwen3-coder-next promettent beaucoup : gros contexte, spécialisation code, capacités agentiques…
Sur le papier, c’est séduisant.
En pratique, faire tourner qwen3-coder-next:q4_K_M sur un PC “classique” est loin d’être trivial.

Dans cet article, je te propose un tutoriel réaliste, basé sur mon setup courant :

  • Windows 11 Pro (hôte)
  • VS Code + Continue
  • Ollama en local (côté Windows)
  • WSL2 pour l’environnement de dev
  • GPU type RTX 4060 / 4070
  • 32 à 64 GB de RAM

Objectifs :

  • comprendre pourquoi ça bloque,
  • savoir comment le configurer proprement,
  • identifier les limites matérielles réelles,
  • et déterminer quel upgrade a du sens en 2026, sans fantasmes.

qwen3-coder-next:q4_K_M : ce qu’il faut comprendre avant de commencer

Sur la bibliothèque Ollama, qwen3-coder-next:q4_K_M est affiché à ~52 GB.

Quelques points clés à bien avoir en tête :

  • 52 GB, ce n’est pas de la RAM “recommandée”, c’est la taille des poids du modèle.
  • À cela s’ajoutent :
    • l’overhead du runtime,
    • le KV cache (qui dépend du contexte),
    • le système (Windows, VS Code, WSL2, etc.).
  • Le contexte maximal (256K) est une capacité théorique : en pratique, chaque augmentation du contexte augmente fortement la consommation mémoire.

👉 Conclusion immédiate : ce modèle est structurellement lourd, même en quantization Q4.

Pourquoi ça ne passe pas (ou très mal) sur 32 GB RAM + RTX 4060 8GB

Pourquoi j’évoque spécifiquement la RTX 4060 8GB ?

Parce que c'est ma carte ;-) et aussi parce que c'est une carte qui s'est beaucoup vendu à une époque pas si lointaine et qui contient 8GB de VRAM ce qui est assez classique.

Et surtout parce que, pour l’inférence de LLM en local, la VRAM est un facteur clé.
Plus tu as de VRAM, plus Ollama peut offloader une partie des poids sur le GPU, ce qui réduit la pression sur la RAM système.

La RTX 4060 est une carte très répandue, mais limitée à 8 GB de VRAM.
Or qwen3-coder-next:q4_K_M pèse ~52 GB.

Dans une configuration typique :

  • RTX 4060 8GB
  • 32 GB de RAM

on cumule deux limites majeures :

  • VRAM insuffisante → offload massif vers la RAM.
  • RAM insuffisante → le modèle ne tient pas, même sans compter le cache et le système.

Résultat fréquent :

  • chargement impossible,
  • ou bascule en pagefile Windows (swap disque),
  • avec des latences énormes et une expérience inutilisable.

👉 La RTX 4060 n’est pas une mauvaise carte, mais elle est dimensionnée pour des modèles bien plus petits.

Repères matériels concrets

Exemple A — PC très courant
RTX 3060 12GB + 32GB RAM
→ un peu plus de VRAM, mais toujours pas assez de RAM pour un modèle de 52 GB.

Exemple B — Config “dev solide”
RTX 4070 12GB + 64GB RAM
→ le modèle peut se charger, mais reste majoritairement en RAM, donc performances acceptables uniquement avec :

  • contexte limité,
  • une requête à la fois,
  • prompts ciblés.

Le vrai saut pour ce modèle
Passer à 24 GB de VRAM (ex. RTX 3090) change nettement la donne :
on peut offloader beaucoup plus vers le GPU, même si le modèle ne tient toujours pas entièrement en VRAM.

Prérequis logiciels (indispensables)

Avant toute chose :

  • Windows 11 Pro
  • Ollama installé côté Windows (pas dans WSL2)
  • VS Code sous Windows
  • Extension Continue
  • WSL2 (Debian/Ubuntu) pour le code, si souhaité

Vérification rapide

curl http://localhost:11434

→ doit répondre que le service Ollama est actif.

Installation du modèle

Téléchargement (prévoir beaucoup d’espace disque) :

ollama pull qwen3-coder-next:q4_K_M

Test simple :

ollama run qwen3-coder-next:q4_K_M

Si le modèle ne démarre pas ou s’arrête brutalement, ce n’est pas un bug : c’est très souvent un problème de mémoire.

Réglages Ollama indispensables (sinon ça casse)

L’objectif : éviter la saturation RAM et réduire les risques de swap/paging sous Windows.

5.1 Limiter la charge (à faire en priorité)

À définir en variables d’environnement Windows :

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=0

Objectif :

  • une seule requête à la fois,
  • un seul modèle chargé,
  • libération immédiate de la RAM après usage.

Astuce : si tu trouves le rechargement trop fréquent, tu peux tester OLLAMA_KEEP_ALIVE=1m. Mais sur un modèle énorme, garder en mémoire peut vite devenir un piège (RAM “bloquée”).

5.2 Maîtriser le contexte (num_ctx)

Le contexte par défaut est 4096 tokens : c’est la meilleure base sur une machine perso.

Recommandations simples :

  • 4096 : stable (recommandé)
  • 8192 : possible si tu as beaucoup de marge RAM
  • > 8192 : à éviter sur config “grand public” (KV cache très coûteux)

En session interactive (pendant ollama run) :

/set parameter num_ctx 4096

5.3 Méthode “test de stabilité” (à faire une fois)

  1. Lance le modèle
  2. Pose une question courte
  3. Puis une question longue (colle un fichier un peu volumineux)
  4. Surveille l’occupation RAM/CPU/GPU + la réactivité

Si tu vois Windows commencer à paginer (disque qui “gratte”, latence énorme), baisse num_ctx et assure-toi que OLLAMA_NUM_PARALLEL=1.

Continue (VS Code) : la configuration qui a du sens

Erreur classique : utiliser qwen3-coder-next pour l’autocomplétion.
👉 Mauvaise idée (latence, consommation mémoire, UX pénible).

La bonne approche : 2 modèles.

  • Gros modèle → chat / edit / apply
  • Petit modèle → autocomplete rapide

Exemple de config.yaml

models:
  - name: qwen3-coder-next
    provider: ollama
    model: qwen3-coder-next:q4_K_M
    roles:
      - chat
      - edit
      - apply

  - name: autocomplete-fast
    provider: ollama
    model: qwen2.5-coder:3b
    roles:
      - autocomplete

Recommandations pratiques :

  • garde l’autocomplete sur un modèle léger,
  • limite les demandes “agentiques” (qui enchaînent plusieurs appels),
  • travaille en petits chunks (fichier par fichier).

Réglages système Windows à ne pas négliger

Même avec un bon setup Ollama, Windows peut te plomber l’expérience si tu ne fais pas attention à ces points.

7.1 Pagefile (mémoire virtuelle)

  • Pagefile actif sur SSD/NVMe (sinon crash quand la RAM est saturée).
  • Évite de le mettre sur un disque lent.

Le swap ne rendra pas ton modèle “rapide”, mais il peut éviter un arrêt brutal. L’objectif reste de ne pas swapper en usage normal.

7.2 Fermer ce qui mange la RAM

Exemples classiques :

  • navigateurs avec 50 onglets,
  • Docker Desktop + gros containers,
  • VM,
  • jeux en arrière-plan,
  • indexations et antivirus agressifs.

7.3 Diagnostic rapide

Surveille où Ollama charge et ce qu’il fait :

ollama ps

Si tu es en mode “CPU massif” et que ça rame, c’est cohérent avec un modèle trop gros pour ta VRAM/RAM.

Configs matérielles : ce qu’il faut vraiment

(prix observés début février 2026)

⚠️ Avertissement sur les prix
Les prix ci-dessous sont ceux observés sur comparateurs début février 2026.
Ils varient fortement selon le stock, le vendeur, la marketplace et le type exact de produit.
Vérifie toujours la capacité réelle, le format (DIMM vs SO-DIMM), l’éventuel ECC, et le vendeur avant achat.

Scénario 1 — Minimum viable (ça tourne, sans confort)

  • 64 GB de RAM
  • GPU existant conservé
  • num_ctx limité (4096/8192)
  • 1 requête à la fois

DDR4 64 GB (2×32) :
→ prix observés ~550 à ~650 €, moyenne ~600 €

➡️ Suffisant pour charger le modèle, pas pour une expérience “fluide IDE”.

DDR5 : attention au budget (2026)

En 2026 :

  • DDR5 64 GB (2×32) : souvent ~800 à ~1 150 €
  • Les kits 6000 CL30 sont fréquemment > 1 000 €

➡️ Peu rentable pour l’inférence LLM locale : la priorité, c’est la quantité de mémoire, pas la fréquence.

Scénario 2 — Upgrade réaliste et efficace (recommandé)

  • 64 à 128 GB de RAM
  • GPU 24 GB de VRAM (ex. RTX 3090 d’occasion)
  • SSD NVMe (modèles + pagefile)

Pourquoi ça marche mieux :

  • beaucoup moins d’offload CPU,
  • moins de risque de swap,
  • meilleure latence globale dans VS Code/Continue.

Sur un budget upgrade autour de +1500€, ce scénario est souvent le meilleur compromis (RAM + GPU).

Scénario 3 — Workstation (hors “PC perso”)

Si tu veux vraiment jouer avec des contextes gigantesques et/ou éviter l’offload :

  • très grosse VRAM (multi-GPU ou GPU pro),
  • RAM 128 GB+,
  • budget nettement supérieur.

Ici, on sort du “réaliste” pour un poste de dev classique.

Limites à accepter (important)

  • Le 256K context est théorique : sur machine perso, viser 4K–8K.
  • Ce modèle n’est pas fait pour :
    • charger des repos entiers,
    • multiplier les agents,
    • servir d’autocomplete.
  • Tu gagneras souvent plus à :
    • réduire le contexte,
    • découper les tâches (fichier par fichier),
    • et utiliser un modèle plus petit pour la complétion.

👉 Utilise-le comme un outil ponctuel puissant, pas comme un assistant permanent.

Le mot de la fin

qwen3-coder-next:q4_K_M est un modèle impressionnant… mais clairement dimensionné pour des machines très bien dotées en mémoire.

Sur un PC “standard” :

  • il est testable,
  • mais rarement confortable sans upgrade sérieux.

La stratégie la plus saine en 2026 :

  • petit modèle rapide pour l’IDE,
  • gros modèle pour les tâches ciblées,
  • upgrades raisonnés, pas fantasmés.

Après vous pouvez aussi utiliser ce modèle en version Cloud si la confidentialité ne vous pose pas de problèmes.

Bonus : checklist rapide “ça doit marcher”

  • Ollama tourne sur Windows (curl http://localhost:11434)
  • Modèle téléchargé (ollama pull …)
  • OLLAMA_NUM_PARALLEL=1
  • OLLAMA_MAX_LOADED_MODELS=1
  • OLLAMA_KEEP_ALIVE=0 (ou court)
  • num_ctx=4096 au départ
  • Continue : 2 modèles (gros pour chat, petit pour autocomplete)
  • Pagefile actif sur SSD/NVMe