Qwen3.8 Flash Next passe de 354 Go à 29,6 Go

Comment le modèle a été compressé sans quantification aveugle

Ce qui est intéressant ici n'est pas le format GGUF lui-même, mais la combinaison de deux leviers : réduire le nombre d'experts MoE et appliquer une quantification hétérogène aux poids restants. Dans la fiche Hugging Face d'ISTA-DASLab, Qwen3.8 Flash Next est présenté comme un modèle MoE à 512 experts, compressé avec GSQ et RCO pour des environnements compatibles avec llama.cpp.

La version publiée supprimerait la moitié des experts et ramènerait la précision des poids à 3,5 bpw. La base BF16 d'origine occupait 354 Go, tandis que l'ensemble de travail après traitement atteint 29,6 Go. Il ne s'agit plus d'une simple réduction cosmétique du fichier, mais d'un passage vers une autre catégorie de matériel accessible.

GSQ effectue une quantification scalaire post-entraînement. La méthode apprend l'affectation des coordonnées aux grilles ainsi que les échelles pour des groupes de poids, grâce à une relaxation Gumbel-Softmax. L'objectif est d'éviter d'imposer le même schéma grossier à tous les tenseurs alors que la sensibilité des différentes parties du modèle varie clairement.

RCO traite l'étape suivante : il choisit pour chaque tenseur l'un des K types de quantification tout en respectant une contrainte exacte sur la taille finale. Aucun coefficient de pénalité distinct pour le budget n'a besoin d'être réglé. D'un point de vue d'ingénierie, c'est plus robuste que de tester des préréglages GGUF, car la taille devient une contrainte d'optimisation plutôt qu'un effet aléatoire des paramètres.

Le maintien de qualité annoncé est impressionnant : 91,3 % du résultat d'origine sur SWE-bench Verified et 98,7 % sur LiveCodeBench v6. Toutefois, les documents de la fiche officielle confirment en détail GSQ, RCO et l'architecture à 512 experts, sans permettre de vérifier indépendamment tous les chiffres de compression et de test. Je les considère donc comme des résultats de publication, non comme des mesures reproduites.

Ce que cela change pour les modèles de code locaux

Le changement pratique est simple : un grand modèle MoE peut se rapprocher de l'inférence locale non pas avec une unique quantification agressive, mais par une optimisation conjointe de sa structure et de la représentation de ses poids. Cela réduit la mémoire nécessaire tout en préservant une grande partie de la qualité annoncée en programmation.

Je commencerais néanmoins par vérifier la suppression des experts. Un score moyen de benchmark peut masquer une baisse sur des langages rares, des dépôts inhabituels ou des tâches dont le routage utilisait des experts spécialisés. La vitesse réelle, la mémoire consommée lors de longues sessions et la stabilité de la qualité au-delà des deux tests cités sont aussi importantes.

L'approche ressemble moins à une astuce qu'à une véritable stratégie de compression sous contrainte budgétaire. La question centrale reste de savoir si la qualité sur les routes MoE rares se maintient aussi bien que sur la distribution familière des benchmarks de code.

Nous avons également envisagé Pony Alpha comme modèle pour un pilote à faible risque et pour valider une architecture d'IA avec des ressources limitées. La quantification de Qwen3.8 Flash Next rend ces expérimentations bien plus accessibles en local et à moindre coût.