Qwen3-Coder 30B sur RTX 3090 : la limite des 24 Go
локальные LLMQwen3-CoderRTX 3090
30B tient réellement dans 24 Go, mais sans marge
Je n’écarterais pas l’idée d’un modèle de code local sur une seule RTX 3090 : en septembre 2026, c’est déjà une option fonctionnelle, bien que limite. Dans la synthèse de recherche fournie, le principal candidat est Qwen3-Coder-30B-A3B-Instruct, avec 30 milliards de paramètres, dont 3,3 milliards sont actifs pour chaque token.
En quantification 4 bits, les poids du modèle occupent environ 17 à 20 Go. Sur une carte disposant de 24 Go de VRAM, il reste de la place pour le cache KV, mais les longs contextes absorbent vite cette marge. Pour des modèles classiques de la classe 30B, la plage est encore plus serrée : environ 18 à 21 Go pour les poids seuls.
- La pleine précision ne convient pas : le scénario réaliste commence ici avec la quantification 4 bits.
- Les 3,3 milliards de paramètres actifs facilitent l’inférence : l’architecture MoE n’utilise pas les 30 milliards de paramètres à chaque token.
- Le contexte reste le facteur limitant : faire entrer le modèle en mémoire ne garantit pas un travail confortable sur un grand projet.
La synthèse cite également des résultats de Qwen3-Coder d’environ 50,3 sur SWE-bench Verified, 66,2 sur Aider Polyglot et 58,9 sur LiveCodeBench v6. Les données sources ne contiennent ni fiche modèle directe ni documentation du développeur ; je considère donc ces chiffres comme des repères, et non comme un verdict définitif. Pour un prototype de jeu, il importe davantage de tester la stabilité des modifications entre fichiers, l’usage des outils et la qualité du code après plusieurs itérations.
Le codage local est déjà utile, mais n’a pas rejoint la frontière
Le changement essentiel est simple : un modèle local de la classe 30B peut désormais devenir un assistant pratique de prototypage sur un seul GPU grand public. Il permet une exécution locale et des expérimentations sans solliciter constamment un modèle commercial, si sa qualité suffit pour le dépôt concerné.
En revanche, je ne transformerais pas en métrique l’affirmation reprise dans la discussion selon laquelle les modèles ouverts auraient exactement trois mois de retard. Aucune source primaire n’est indiquée, et l’écart dépend de la tâche : générer de petites fonctions ou corriger des erreurs locales diffère fortement d’un long cycle agentique, d’une refactorisation multifichiers ou du débogage.
D’après la synthèse fournie, les modèles propriétaires restent plus solides sur les tâches complexes et longues. Ainsi, 24 Go de VRAM résolvent le problème du lancement, mais pas celui de la fiabilité. La vraie frontière ne sépare pas l’exécution locale du cloud, mais un extrait de code convaincant d’un modèle auquel on peut confier les modifications d’un projet entier.