Qwen 3.8 27B NVFP4 contre DeepSeek V4 Flash 0731 : inférence locale multi-agents sur RTX 5090 et cluster DGX Spark

Déroulé structuré

Segment 1 — Duel local Qwen 3.8 27B NVFP4 vs DeepSeek V4 Flash 0731

Statut : information first-party ; mesures individuelles d’un seul setup, non répétées.

• Tâche réelle commune : ajouter une courbe de position du soleil à un dashboard solaire, analyser 30 jours de données de production via l’API Victron VRM pour détecter les ombres, puis déployer sur NAS.
• Qwen 3.8 27B en BF16 ne tient pas dans 32 Go de VRAM ; l’auteur utilise un quant NVFP4 (~15 Go de poids), présenté comme le plus petit build testé, optimisé pour Blackwell.
• Patch vLLM maison pour un KV cache NVFP4 sur 4 bits par poids, contre 8/16 bits en FP8/FP16, visant un pool de contexte d’environ 400 000 tokens (451 000 tokens de KV cache cités dans la description du source) pour la concurrence ; l’auteur décrit le travail comme non trivial.
• Performances rapportées : 136 tok/s en pic pour Qwen, 46,9 tok/s pour DeepSeek ; 119 tok/s en moyenne sur la session Qwen, 152 000 tokens générés (pensées, sorties, tool calls, écritures de fichiers), 2 compactions de contexte.
• DeepSeek tourne sur un cluster DGX Spark de 256 Go ; le chiffre 46,9 tok/s est explicitement fragilisé par l’auteur, qui admet qu’une autre personne utilisait peut-être le cluster en même temps.
• Qwen affiche une auto-vérification plus poussée : après déploiement, il se connecte au site NAS, reprend une capture d’écran et vérifie le résultat ; DeepSeek corrige, relance des tests et déclare la tâche terminée sans cette étape supplémentaire.
• Sur la sous-tâche d’ombres : Qwen identifie une ombre partielle d’arbre autour de 17 h 15 et utilise un filtre top 10 % des heures d’irradiance (jours nuageux exclus) ; DeepSeek utilise une approche similaire avec top 20 %.
• Qwen met à jour une code map dans un fichier .adjun.m ; une pause notable est observée lors du chargement d’une image, imputée au moteur vLLM.
• Fiche modèle Qwen citée : temperature 1, top_p 0.95, top_k 20 pour sessions code ; l’auteur ajoute qu’un max_tokens élevé est utile pour éviter que le modèle s’égare dans sa chaîne de pensée.

Segment 2 — vLLM pour la concurrence multi-agents

Statut : découverte personnelle de l’auteur ; affirmation technique sur des moteurs tiers, à vérifier.

• L’auteur a choisi vLLM plutôt que llama.cpp ou SGLang pour gérer 3 sessions Qwen concurrentes, en reconnaissant que vLLM est plus complexe à mettre en place.
• Point décisif rapporté : llama.cpp et SGLang diviseraient le contexte disponible par le nombre de sessions concurrentes, ce qui limiterait le contexte par agent sur une VRAM donnée.
• vLLM, lui, n’imposerait pas cette division de la même façon ; cela conditionne la possibilité d’avoir un pool KV concurrentiel de ~400 000 tokens sur 32 Go.
• Cette affirmation n’est pas présentée comme documentée officiellement ; elle relève d’une observation personnelle et d’une inférence de l’auteur.

Segment 3 — Puissance, coût et marché du matériel

Statut : information first-party ; prix et observations marché à un instant T.

• La RTX 5090 (Gigabyte Aorus Master, 32 Go) est bridée à 400 W, décrite comme le plancher de configuration sous Linux ; elle consomme 250-270 W en session code normale.
• Le système complet en charge consomme 816 W : PC principal, écran, cluster Spark, PC de jeu contenant la 5090.
• La 5090 a été achetée d’occasion pour 4 000 € (neuve ~4 700 €, marché Bon Coin 3 500-4 000 €) ; l’auteur est allé l’acheter à Sofia, en Bulgarie, et se méfie d’annonces anormalement basses (ex. Rouen à 2 400 €).
• Le cluster DGX Spark (256 Go) a été acheté en mars 2026 pour 6 300 € TTC, 5 300 € après récupération de TVA ; le coût de remplacement serait ~8 000 € TTC au moment de l’enregistrement, avec l’offre la moins chère observée à 4 100 € sur un comparateur.
• Le cluster sert aussi d’endpoint IA local pour d’autres usages, ce qui peut interférer avec les mesures.

Points notables

• Le point le plus reproductible est l’association quant NVFP4 ~15 Go + patch vLLM 4-bit KV cache : elle transforme une contrainte de 32 Go VRAM en ~400 000 tokens de pool KV pour 3 sessions concurrentes.
• Le MTP (3 tokens proposés) est présenté comme plus adapté que les drafts distants « 10 Flash 2 » / « 10 Spark » dans ce contexte, car les drafts distants consommaient de la VRAM utile au contexte ; stabilité rapportée jusqu’à 185 000 tokens (128 → 112 tok/s).
• La différence de comportement entre les deux modèles est aussi instructive que les vitesses : Qwen effectue une vérification navigateur après déploiement et maintient une code map, ce que DeepSeek ne fait pas dans les conditions observées.
• Le choix du moteur d’inférence peut être plus déterminant que le GPU seul pour l’orchestration multi-agents : la division du contexte par session, rapportée pour llama.cpp/SGLang, réduit le contexte utilisable par agent.
• Le rapport performance/contrainte reste ouvert : 136 tok/s sur une 5090 à 400 W et 4 000 € d’occasion contre 46,9 tok/s sur un cluster ~6 300-8 000 € ; l’auteur ne tranche pas.

Limites & biais factuels

• Toutes les mesures de performance proviennent d’une seule session individuelle, sans répétition ni variance.
• Le chiffre DeepSeek (46,9 tok/s) est explicitement confondu par une utilisation simultanée possible du DGX Spark.
• La conclusion « MTP > draft distant » est une inférence de l’auteur à partir de tests restreints, pas un benchmark contrôlé.
• La division du contexte par session dans llama.cpp et SGLang n’est pas vérifiée ici contre la documentation officielle ; c’est une observation personnelle de l’auteur.
• Le canal a une très faible audience (159 vues à la découverte), le ton est informel et il n’y a pas de contre-expertise indépendante.
• Les prix du matériel sont datés (août 2026) et volatils ; ils n’ont qu’une valeur indicative.