Titre : Modèles locaux vs cloud : Qwen-3.6-27B, Gemma-4-31B, Claude Haiku, Codex-Spark sur la génération de code difficile

Un utilisateur de Reddit a comparé Qwen-3.6-27B (GGUF q4_k_m) exécuté localement à ses équivalents via API : Qwen-3.6-27B via OpenRouter, Gemma-4-31B via OpenRouter, Claude Haiku 4.5 et GPT-Codex-Spark. Le test consistait à implémenter une boucle d'auto-recherche à partir d'un document de conception — une tâche délibérément difficile pour évaluer la propreté des échecs, et non le taux de réussite.

Configuration matérielle

• CPU : Ryzen 7 7800X3D
• RAM : 64 Go DDR5-6400
• GPU : RTX 5080 (16 Go de VRAM)
• Modèle local : Qwen-3.6-27B q4_k_m (GGUF) — tient dans 16 Go de VRAM grâce à la quantification

Résultats

• Gemma-4-31B (API) : Échec complet. A écrit une structure vide avec des modules simulés, pas de tests, ni de fichiers de configuration (__init__.py, requirements.txt, pyproject.toml). Coût : 0,112 $, 803 000 tokens de contexte consommés, 21 000 générés.
• Codex-Spark (API) : A produit une belle structure de dossiers et du code, mais les imports étaient hallucinés. Pas de tests unitaires. A utilisé 1 % des limites mensuelles de 100 $ de Spark.
• Claude Haiku 4.5 (API) : Implémentation détaillée mais a échoué sur l'exactitude. (Plus de détails tronqués dans la source.)
• Qwen-3.6-27B (local q4_k_m) : Pas noté explicitement, mais l'utilisateur note que l'inférence quantifiée dégrade la qualité par rapport à la version API en pleine précision.

Contexte

L'utilisateur soutient que les évaluations typiques des modèles locaux utilisent des tâches triviales (par exemple, Snake en HTML) où les modèles locaux et les modèles frontière réussissent, ce qui donne une fausse image de la qualité des modèles locaux. Ce test a utilisé un projet de travail réel avec un document de conception ; seul Codex-Spark a produit un code entièrement écrit (mais défectueux). Le constat : les modèles locaux ne sont pas encore prêts pour la génération de code complexe sans corrections substantielles.