Gemma 4 et Qwen Coder face au cloud : les LLM locaux à l'épreuve du terrain

Les modèles locaux comme Gemma 4 et Qwen Coder occupent une position paradoxale : d'un côté, personne ne les prend au sérieux ; de l'autre, rares sont ceux qui ont évalué leurs capacités en conditions réelles plutôt que sur des benchmarks synthétiques.

Le problème des tests YouTube

YouTube regorge de tests de LLM locaux. Mais ils se ressemblent tous : on prend un gros modèle, on le lance n'importe comment et on lui demande d'écrire un tri à bulles. Évidemment, il s'en sort. Personne n'est impressionné.

La vraie question est ailleurs : un modèle local peut-il écrire du code fonctionnel, refactoriser des fichiers truffés de bugs et extraire des données d'une page HTML, comme dans un vrai projet ?

La plupart des tests ignorent les paramètres. Or ce sont souvent eux qui font toute la différence. Une mauvaise temperature, une mauvaise fenêtre de contexte, un mauvais schéma de quantification, et les résultats s'effondrent. Obtenir un mauvais résultat avec un modèle local est facile. En obtenir un bon demande du temps.

Gemma 4 et Qwen : quels modèles, dans quelles conditions

Viatcheslav a testé plusieurs modèles, en retenant ceux qui tiennent réellement dans les 16 Go de mémoire vidéo d'une carte graphique grand public :

• Gemma 4 (Google) — un modèle généraliste bien équilibré
• Qwen 3.6 (Alibaba) — un bon compromis entre performances et vitesse
• Qwen Coder — spécialisé dans la génération et l'analyse de code
• Exécution via llama.cpp avec des paramètres optimisés
• Optimisation GPU et choix de quantization adapté à la mémoire

Première partie du problème : simplement mettre en route l'API de llama.cpp. Seconde partie : choisir les bons paramètres. Quel niveau de quantification ? Quelle temperature ? Jusqu'à combien de tokens étendre le contexte ? Ces réglages doivent être ajustés à chaque tâche, pas devinés.

Résultats en environnement agentique

L'auteur n'a pas testé les modèles sur des exemples isolés, mais dans un véritable environnement agentique, avec des chaînes d'actions où une erreur à une étape fait dérailler toute la suite.

• Écriture de code fonctionnel du premier coup
• Refactorisation d'une base de code comportant de la logique et des bugs existants
• Extraction de données structurées depuis du HTML
• Respect d'instructions complexes dans le contexte de la tâche
• Adaptation aux changements d'exigences en cours de session

Verdict : avec des paramètres bien choisis, les modèles locaux se hissent au niveau des solutions cloud sur les tâches courantes, sans latence réseau.

À quoi servent les LLM locaux

La question peut sembler académique. Pourtant, dans certains scénarios, une API cloud n'est pas envisageable : données sensibles, environnements isolés, contraintes réglementaires, coût des API à grande échelle.

Les modèles locaux redonnent le contrôle. Vous savez où tournent les calculs. Aucune mauvaise surprise côté journalisation des données. C'est crucial quand on manipule des informations confidentielles ou qu'on travaille dans un environnement où les API cloud sont interdites.

Ce que cela signifie

Les LLM locaux ont dépassé le stade de l'expérimentation. Ils sont prêts pour la production, à condition d'accepter de passer du temps à régler leurs paramètres. Pour les entreprises, cela signifie qu'investir dans une carte graphique peut remplacer les API cloud pour toute une catégorie de problèmes, du développement au traitement d'informations sensibles.