IA locale pour le dev : cinq paliers matériels, MTP et orchestration OpenFox

🎥 Résumé analytique

🎯 Promesse cognitive

À la fin, on comprend : les paliers matériels pour le dev local, l’apport de MTP et les mécanismes d’orchestration pour des LLM locaux.

🧩 Carte du contenu

Benchmarks matériels pour LLM locaux — Fournit des débits tok/s par palier 32 Go RAM, 8/16/24 Go VRAM et 256 Go unifié, avec le compromis modèle/coût/vitesse/consommation.
MTP en inférence locale — Explique comment Multi-Token Prediction accélère la génération et reste aujourd’hui une technique à compiler et à régler pour devenir utilisable.
OpenFox et Build & Verify — Présente un harnais de dev local et un workflow critères/agent/vérification/revue de code pour compenser les limites des petits modèles.
Positionnement de Qwen 3.6 27B — Documente un modèle dense 27B présenté comme très compétitif pour le code, avec contraintes FP8/24 Go VRAM et un exemple comparatif.

✅ Ce que la vidéo apporte en plus de la lecture de ce post

Le plan d’attention signale que l’original peut ajouter l’exécution réelle des configurations, le parcours d’interface du workflow Build & Verify, la comparaison de solutions générées par deux modèles et les autoretry patterns. Ces apports restent des possibilités de visionnage ciblé, pas des contributions visuelles établies par le matériau fourni.

🕒 Niveau d’engagement recommandé

visionnage_actif
- La vidéo est une démonstration technique de paliers matériels, de MTP et d’un harnais de dev local.
- Le visionnage ciblé peut ajouter des détails d’exécution et d’interface que le post ne restitue pas entièrement.

Passages susceptibles de mériter l’original

07:12 — peut montrer la configuration réelle du 32 Go unifié et les chiffres de débit après réglage MTP et Q2_K_XL.
12:10 — peut montrer le parcours du pipeline Build & Verify dans l’interface, y compris les retours de vérification et de revue.
26:45 — l’auteur montre le câble interconnexion 200 Go/s du cluster 2x DGX Spark, utile pour évaluer la configuration et le coût.
32:02 — peut montrer la comparaison des solutions produites par Qwen 3.6 27B et Qwen 3.6 35B-A3B sur la même tâche d’abort.
40:12 — l’auteur démontre les autoretry patterns détectant des appels d’outil malformés, ce que le post ne peut pas montrer entièrement.

🧰 Pistes d’exploitation et points de vigilance

1 idée à tester : Tester un workflow Build & Verify minimal : critères d’acceptation, agent de construction, vérification sur le diff uniquement et revue de code, sur un petit modèle local.
1 notion à creuser : Vérifier les capacités réelles de Qwen 3.6 27B dense pour le code par des benchmarks indépendants, car le positionnement « OVNI » est une affirmation forte de l’auteur.
1 limite / biais : Les chiffres de performance et le positionnement des modèles proviennent des mesures personnelles de l’auteur, avec un biais possible lié à la promotion d’OpenFox et de son cluster DGX.

🔍 Déroulé détaillé et analyse critique

📄 Voir la synthèse détaillée

Déroulé structuré

Segment 1 — Benchmarks matériels pour LLM locaux

Statut : information première main, non vérifiée indépendamment.

Sur 32 Go RAM unifiée sans GPU dédié, l’auteur indique environ 34 tok/s en génération et environ 200 tok/s en traitement du prompt avec Qwen 3.6 35B-A3B Q2_K_XL, MTP activé et contexte 100K.
Sous charge soutenue, le traitement du prompt est rapporté à environ 60 tok/s, identifié comme le goulot principal pour une tâche interactive longue.
Sur 8 Go VRAM, Qwen 3.5 9B Coder Q4_K_M est rapporté à environ 70 tok/s en génération et 1300 tok/s en prompt processing, mais le modèle 9B est noté environ 30% moins bon que 35B-A3B sur un benchmark.
Sur 16 Go VRAM, Qwen 3.6 35B-A3B Q4 avec MTP est présenté comme un MoE rapide, avec seulement 3B paramètres actifs et une mémoire GPU rapide.
Sur 24 Go VRAM, Qwen 3.6 27B FP8 avec MTP est rapporté à environ 25 tok/s en génération et 1200 tok/s en prompt processing, jugé utilisable pour le dev.
Le cluster 2x DGX Spark est décrit avec 128 Go unifiés par unité, câble interconnexion 200 Go/s, 256 Go au total, et DeepSeek V4 Flash en local ; la consommation mesurée sur la prise est de 260-280 W pendant l’inférence, pour un coût total d’environ 5300 EUR.
L’auteur recommande les MoE pour mémoire unifiée et les modèles denses pour GPU dédié ; la taille du contexte dégrade le traitement du prompt, et le KV cache Q8 divise la mémoire du cache par deux par rapport à FP16.

Segment 2 — MTP en inférence locale

Statut : information première main, avec une déduction explicite de l’auteur.

L’auteur présente MTP comme un gain de +30 à +80% en génération sur MoE, avec un gain encore plus élevé sur modèles denses.
MTP est décrit comme récent dans llama.cpp, nécessitant de compiler llama.cpp depuis le source plutôt que de compter sur des binaires prêts à l’emploi ou LM Studio.
Un paramètre contrôle le nombre de tokens suggérés à chaque étape, avec retours décroissants ; l’auteur part de la valeur 2 comme valeur sûre.
L’auteur en déduit que MTP serait spécialisé pour la génération de code, ce qui introduit une variabilité dans les benchmarks et complique la comparaison entre modèles.

Segment 3 — OpenFox et Build & Verify

Statut : information première main sur l’outil de l’auteur, potentiellement promotionnelle.

OpenFox est décrit comme un harnais de dev local open source, basé sur le navigateur, clone d’OpenCode, v2.0, Node 24 minimum, installable en global, principalement utilisé sous Linux avec WSL noté facile ; l’auteur cite 1040 commits en 3 mois.
Le workflow Build & Verify suit l’ordre : critères d’acceptation définis en plan mode, agent build itératif, sous-agent de vérification limité au code modifié et aux critères, sous-agent de revue de code évaluant UX et maintenabilité, puis récapitulatif des changements.
Les étapes build, vérification et revue peuvent être lancées séparément pour des tâches petites.
OpenFox intègre un serveur de dev local contrôlable par l’agent, avec des autoretry patterns utilisant des regex pour détecter des appels d’outil malformés, notamment des marqueurs bruts fuyant dans les tool calls.
Des hooks pre-commit exécutent tests, lint et un contrôle de duplication bloquant les commits contenant 5 lignes ou plus identiques ; en cas d’échec, l’utilisateur doit confirmer une override, sinon l’agent est invité à corriger.
L’auteur affirme que les petits modèles locaux exigent plus d’orchestration que des modèles frontier type Opus, et que Build & Verify sert à rendre les critères explicites et la vérification automatique.

Segment 4 — Positionnement de Qwen 3.6 27B

Statut : opinion de l’auteur, appuyée par un exemple de tâche unique.

L’auteur qualifie Qwen 3.6 27B d’« OVNI » : 27B paramètres denses, avec un niveau qu’il compare à Qwen 3.5 400B (17B actifs) et à une distance qu’il juge courte de Kimi K2.6 ou DeepSeek V4 Flash.
En FP8, le modèle demande environ 27 Go plus le contexte, ce qui le rend faisable sur 24 Go VRAM mais plus difficile sur 32 Go unifiés ; l’auteur l’exécute sur son cluster 256 Go.
Sur une tâche d’implémentation d’un mécanisme d’abort dans OpenFox, Qwen 3.6 27B aurait produit une solution jugée plus propre que Qwen 3.6 35B-A3B, en répliquant un pattern existant plutôt qu’en ajoutant une nouvelle fonction.
L’auteur affirme ne pas avoir rencontré de problème réel que Qwen 3.6 27B ne pouvait pas résoudre ou aider à résoudre, tout en reconnaissant que le modèle exige de substantielles ressources.

Points notables

Le goulot identifié est le prompt processing, pas la génération, surtout avec de grands contextes sur du matériel contraint.
La consommation électrique est traitée comme un quatrième axe du compromis local : 260-280 W pour le cluster DGX, contre plus de 250 W pour un GPU gaming avec un modèle plus petit.
MTP change l’utilisabilité pratique à chaque palier, mais il impose une friction d’adoption : compilation de llama.cpp et réglage du nombre de tokens suggérés.
Le choix MoE/dense n’est pas neutre : MoE pour mémoire unifiée, dense pour GPU dédié, ce qui modifie le palier optimal selon le matériel.
La comparaison 27B vs 35B-A3B est intéressante car elle valorise la réutilisation d’un pattern existant plutôt que l’ajout d’une fonction supplémentaire, même si elle repose sur un cas unique.

Limites & biais factuels

Les benchmarks et mesures proviennent de l’auteur sur un matériel spécifique, sans vérification indépendante.
Le positionnement de Qwen 3.6 27B comme comparable à des modèles plus grands repose sur une évaluation subjective et un exemple de tâche unique.
OpenFox est l’outil de l’auteur ; la présentation est potentiellement promotionnelle et la qualité réelle du workflow n’est pas neutralisée.
Les performances dépendent fortement des quantisations, du contexte, du KV cache Q8 et du réglage MTP, ce qui limite la reproductibilité immédiate.