🎥 Résumé analytique
🎯 Promesse cognitive
- À la fin, on comprend : quelle configuration llama.cpp permet de faire tourner Qwen 3.8 27B avec vision, MTP et 100 000 tokens de contexte sur 16 Go de VRAM, et pourquoi la vision native a compté dans la détection et la vérification d’un artefact visuel.
🧩 Carte du contenu
- Recette d’inférence locale 16 Go — quant IQ4_XS Smaller, KV cache Q4, MTP, vision et contexte de 100 000 tokens sur Radeon RX 7800 XT, avec des débits rapportés autour de 40 à 42 tokens/s.
- Vérification visuelle dans OpenFox Build and Verify — génération d’un jeu type dinosaure, tests Playwright, revue de code et correction d’un artefact lié à un déséquilibre canvas de 32 save pour 31 restore ; Qwen identifie le défaut via captures, DeepSeek V4 Flash ne peut pas le vérifier visuellement.
✅ Ce que la vidéo apporte en plus de la lecture de ce post
- L’original montre la démonstration de l’artefact, les captures d’écran, le zoom sur le détail et les captures avant/après, éléments que le post restitue moins complètement.
- Il ajoute la séquence d’exécution du workflow OpenFox et l’incapacité de DeepSeek à valider visuellement le correctif.
- Reste à considérer que la démonstration est auto-rapportée et non reproduite de manière indépendante.
🕒 Niveau d’engagement recommandé
- visionnage_actif
- la valeur clé dépend de la démonstration de l’artefact visuel, des captures d’écran et de la vérification avant/après.
- le post écrit permet de retenir la configuration et la logique de vérification, mais la séquence visuelle aide à juger l’écart Qwen / DeepSeek.
Passages susceptibles de mériter l’original
- 09:39 — intégration de DeepSeek V4 Flash sans vision native et sa dépendance à des descriptions textuelles d’images.
- 10:08 — captures d’écran montrant l’artefact visuel que Qwen est censé identifier.
- 10:48 — zoom plus précis sur le détail visuel.
- 13:35 — captures avant/après de la disparition du bug.
🧰 Pistes d’exploitation et points de vigilance
- 1 idée à tester : lancer sur 16 Go de VRAM une commande llama.cpp avec Qwen3.8-27B-i1-IQ4_XS-GGUF-Smaller, —ctx-size 100000, —cache-type-k q4_0 —cache-type-v q4_0, MTP draft 3 et mmproj, afin de mesurer le débit et la capacité d’analyse de captures d’écran.
- 1 notion à creuser : le rôle de la vision native dans les agents de code qui doivent détecter et vérifier des défauts visuels via captures d’écran, par rapport aux modèles sans vision ou aux descriptions intermédiaires produites par un autre modèle.
- 1 limite / biais : la conclusion comparative repose sur un seul bug visuel auto-rapporté et non sur un benchmark reproduit avec journaux de session publics.
🔍 Déroulé détaillé et analyse critique
📄 Voir la synthèse détaillée
Déroulé structuré
Segment 1 — Configuration Qwen 3.8 27B sur 16 Go de VRAM
Statut : information auto-rapportée par l’auteur, sans reproduction indépendante.
- Selon l’auteur, Qwen 3.8 27B aurait été publié environ quatre jours avant la vidéo ; le besoin était de le faire tenir sur 16 Go.
- Le quant IQ4_XS Smaller garde les couches d’attention en IQ4_XS et compresse d’autres couches pour viser la taille de VRAM visée.
- Le KV cache Q4 est utilisé pour atteindre 100 000 tokens de contexte, avec MTP et vision activés.
- MTP est présenté comme un compromis : il augmente la vitesse au prix d’une réduction de contexte.
- Le vision tower est décrit comme BF16 et coûteux en ressources lorsque des images entrent dans le contexte.
- Le matériel rapporté est une Radeon RX 7800 XT sous Linux ; désactiver l’interface graphique réduit la VRAM utilisée de 735 Mo à environ 191 Mo.
- La configuration décrite correspond à un serveur llama.cpp avec 100 000 tokens, toutes les couches GPU, cache Q4, MTP draft 3, conservation du raisonnement et build Vulkan.
- Les débits rapportés sont d’environ 40 à 42 tokens/s en génération et 400 à 500 tokens/s en prefill.
Segment 2 — OpenFox Build and Verify : artefact visuel et comparaison Qwen / DeepSeek
Statut : témoignage auto-rapporté ; conclusion comparative à traiter comme opinion de l’auteur.
- L’auteur utilise OpenFox avec un réglage de l’effort de raisonnement dans l’interface, en mode maximal X-high.
- Changer l’effort dans une session active est présenté comme pouvant provoquer un reprocessing, car le niveau de raisonnement est intégré au prompt système.
- Le workflow produit une première version de 938 lignes du jeu ; la session complète est donnée à 46 minutes et 12 secondes.
- Le modèle détecte Playwright et lance des tests navigateur et captures d’écran de façon autonome, selon la description de la vidéo.
- Le vérificateur remarque que le dinosaure semble courir sur une seule jambe, mais ne marque pas l’échec malgré le problème visible.
- Le code reviewer trouve cinq problèmes, dont l’impossibilité de se baisser immédiatement après un saut ; les corrections sont appliquées puis retestées.
- Un artefact persistant sous forme de lignes à droite subsiste après le passage Build and Verify.
- Qwen identifie une fine ligne verticale sur le bord droit à partir des captures et zoome sur le détail.
- DeepSeek V4 Flash est lancé dans la même session sans vision native ; il reçoit des descriptions textuelles d’images et essaie d’analyser des images découpées.
- Le bug est relié à un déséquilibre canvas de 32 save pour 31 restore ; Qwen applique le correctif et montre des captures avant/après, tandis que DeepSeek identifie le même déséquilibre mais ne peut pas vérifier visuellement le résultat.
- L’auteur en conclut que la vision de Qwen est une différence majeure sur ce bug et qu’un modèle sur 16 Go surpasse, pour cette tâche de vérification, un modèle sur un cluster DGX Spark à 8 000 €.
Points notables
- Le compromis KV cache Q4 / MTP est traité de façon pratique : le KV cache Q4 élargit le contexte utilisable, tandis que MTP échange de la vitesse contre une partie du contexte.
- Le fait que le vérificateur repère un défaut visuel sans faire échouer le test montre que la détection visuelle n’a pas déclenché d’échec explicite dans ce passage du workflow.
- DeepSeek identifie la même cause probable mais reste bloqué sur la validation visuelle, ce qui distingue la détection de la confirmation.
- Le point fort revendiqué est la capacité d’un modèle local à se vérifier par captures d’écran, pas simplement à générer du code.
- L’argument du coût est fort mais localisé : 16 Go contre 8 000 € pour une tâche précise, sans classement général des modèles.
Limites & biais factuels
- Le contenu est un témoignage auto-rapporté, sans reproduction indépendante ni journaux de session partagés.
- La comparaison Qwen 3.8 27B / DeepSeek V4 Flash est centrée sur un artefact visuel précis dans un jeu de démonstration.
- L’affirmation de supériorité face à un cluster à 8 000 € est spécifique à la vérification visuelle et ne doit pas être lue comme un benchmark général.
- Les performances dépendent d’un quant, d’une configuration llama.cpp et d’un matériel précis, sans garantie de reproductibilité large.
- Des relances promotionnelles sont présentes, mais elles n’ont pas de valeur technique pour l’évaluation.
