Qwen 3.6 vs Gemma 4 : test sur une machine locale

Comparaison de Qwen 3.6 et Gemma 4 : Tests pratiques sur une machine locale

Les nouveaux modèles locaux Qwen 3.6 d'Alibaba et Gemma 4 offrent des performances impressionnantes même sur un ordinateur portable moyen. Nous les avons testés dans des conditions de développement réelles, en configurant un environnement pour travailler avec des outils et du code. Les résultats confirment : les deux modèles s'intègrent efficacement dans le flux de travail avec une configuration appropriée, mais ils nécessitent un réglage fin pour les ressources limitées.

Configuration matérielle et sélection des outils

Les tests ont été menés sur un ordinateur portable Asus Tuf Gaming équipé d'une carte graphique discrète NVIDIA RTX 4070 (8 GB VRAM). Contraintes principales : mémoire vidéo limitée et nécessité d'équilibrer l'accélération GPU avec les ressources système. Les outils suivants ont été sélectionnés pour exécuter les modèles :

• LM Studio — pour charger et gérer les modèles locaux
• Zed IDE — comme environnement de développement principal avec un agent IA intégré

Exigence clé : prise en charge des outils pour travailler avec le système de fichiers et le terminal. Les clients CLI alternatifs (OpenCode, Claude CLI, pi.dev) ont été écartés en raison de :

• Échecs lors du lancement des invites système
• Détection incorrecte du shell (Bash/PowerShell)
• Problèmes avec l'édition de fichiers en temps réel

Zed IDE a montré des performances stables après activation de l'agent via l'icône « étoile » dans le coin inférieur droit (paramètres dans la section IA).

Configuration de LM Studio pour Qwen 3.6

Pour que Qwen 3.6 fonctionne correctement dans LM Studio, le modèle Jinja devait être modifié. Étapes :

• Dans la section MyModels, sélectionnez le modèle Qwen 3.6
• Ouvrez les paramètres (icône d'engrenage)
• Dans l'onglet Inference, remplacez le modèle par un optimisé

Modifications critiques :

• Ajout de {%- set enable_thinking = false %} au début du modèle pour accélérer les réponses
• Limitation du déchargement GPU à 80-90 % de la VRAM totale
• Définition de la longueur de contexte ≤60K en tenant compte de la RAM disponible

Modèle original (abrégé pour l'exemple) :

{%- set enable_thinking = false %}
{%- set image_count = namespace(value=0) %}
{%- macro render_content(content, do_vision_count, is_system_content=false) %}
    {%- if content is string %}
        {{- content }}
    {%- elif content is iterable and content is not mapping %}
        {%- for item in content %}
            {%- if 'image' in item or 'image_url' in item or item.type == 'image' %}
                {%- if do_vision_count %}
                    {%- set image_count.value = image_count.value + 1 %}
                {%- endif %}
                {{- '<tool_call><tool_call><tool_call>' }}
            {%- elif 'text' in item %}
                {{- item.text }}
            {%- endif %}
        {%- endfor %}
    {%- endif %}
{%- endmacro %}

Dépasser 90 % de VRAM entraînait des hallucinations et un passage au chinois/espagnol. L'avertissement rouge dans l'interface LM Studio indique une erreur de configuration critique.

Invite système et optimisation de la vitesse

Pour raccourcir les longueurs de réponse et économiser des tokens, une invite système spécialisée a été utilisée :

You are a professional React/NextJS developer. Respond briefly, without explanations. Use only necessary tokens. When working with files: first check the project structure, then make changes. Avoid generating code outside the current directory.

Effets de l'optimisation :

• Longueur de réponse moyenne réduite de 30 %
• Vitesse de génération augmentée de 15-20 % grâce à la désactivation du mode thinking
• Moins d'erreurs lors du travail avec les outils

Important : la désactivation de thinking (enable_thinking = false) est critique pour les tâches ne nécessitant pas de raisonnement multi-étapes. Pour les algorithmes complexes, il est recommandé de garder le mode activé.

Comparaison des performances

Les tests ont été effectués sur des tâches :

• Génération de composants React
• Débogage TypeScript
• Automatisation de commandes terminal

Qwen 3.6 (35B, Q4_K_M) :

• Force : précision lors du travail avec les outils
• Faiblesse : utilisation élevée de VRAM à contexte >48K
• Vitesse : 12-15 tokens/sec à 85 % de déchargement GPU

Gemma 4 :

• Force : stabilité à faible VRAM
• Faiblesse : erreurs dans les appels d'outils multi-étapes
• Vitesse : 18-22 tokens/sec avec les mêmes paramètres

Les deux modèles ont géré correctement des invites comme celle-ci :

Hi. You are a professional React/NextJS developer. In the current directory...

mais Qwen 3.6 a montré 25 % d'erreurs en moins lors du travail avec le système de fichiers. Gemma 4 générait du code plus rapidement mais nécessitait des corrections manuelles pour les appels d'outils.

Enseignements clés

• Équilibre VRAM : Ne déchargez jamais plus de 90 % de la mémoire vidéo sur le GPU. Pour RTX 4070 (8 GB), 7 GB est optimal.
• Limite de contexte : Une longueur de contexte de 60K nécessite au moins 16 GB RAM. Sur des systèmes à 32 GB, laissez 4-5 GB pour l'OS.
• Outils : Qwen 3.6 est plus stable avec les outils, mais Gemma 4 est plus rapide pour la génération de code.
• Invites : La désactivation de thinking accélère les réponses mais réduit la qualité pour les tâches complexes.
• Environnement : Zed IDE est préférable aux clients CLI pour l'intégration avec les outils de développement.

— Editorial Team