REAP20 accélère Qwen en local de 42 % sans perte de précision sur DS1000

Lorsqu’on choisit un LLM local pour coder, il est facile d’organiser un beau tournoi et de couronner un vainqueur inutile. Il suffit de reprendre le jeu de prompts de quelqu’un d’autre, d’oublier la limite de raisonnement ou de comparer les modèles dans des modes différents. L’auteur de l’article a commis presque toutes ces erreurs lui-même, avant de dépenser des centaines d’heures-GPU pour comprendre à quel moment l’expérience avait déraillé.

La valeur pratique de ce récit réside précisément dans ces erreurs. Sur une RTX 4070 Ti Super dotée de 16 Go de mémoire vidéo, l’auteur a testé la famille Qwen avec DS1000, un ensemble de mille tâches portant sur Pandas, NumPy, SciPy, Scikit-learn, Matplotlib, PyTorch et TensorFlow. Le code produit par le modèle était injecté dans un modèle de programme, exécuté, puis son résultat comparé à une référence. Cette méthode se rapproche davantage du travail réel d’un spécialiste des données qu’un énième test consistant à créer une landing page ou un jeu dans le navigateur.

Premier passage : la vitesse sans longues réflexions

Lors du test initial, le raisonnement était désactivé. REAP20-28B et Qwen3.6-35B-A3B ont obtenu les meilleurs nombres de tâches résolues. REAP20 s’est montrée particulièrement intéressante : avec une précision comparable, elle générait ses réponses 42 % plus vite que le modèle d’origine, alors même que 20 % de ses poids avaient été supprimés.

Pour le travail quotidien, ce résultat compte. Lorsqu’une personne attend le prochain fragment de code NumPy, la latence importe davantage que la capacité du modèle à réfléchir pendant plusieurs minutes. L’auteur propose donc une répartition pragmatique : un modèle MoE rapide assiste le travail interactif, tandis qu’un modèle dense plus lent exécute la nuit les tâches ne nécessitant pas de supervision constante, comme une première revue de code.

Mais ce résultat ne doit pas être transformé en classement universel. DS1000 est sorti en 2023, et certaines tâches ont pu se retrouver dans les données d’entraînement de modèles plus récents. Un seul passage ne montre pas la dispersion des résultats, tandis que les différentes quantifications et configurations de décodage compliquent encore une comparaison équitable. Enfin, le choix des bibliothèques doit refléter le travail réel : NumPy, SciPy, Scikit-learn et PyTorch étaient importants pour l’auteur, qui a donc réduit par la suite l’ensemble de 1 000 à 509 tâches.

La limite de tokens a faussé la deuxième expérience

Lors du deuxième passage, l’auteur a activé le mode thinking, mais n’a accordé que 4 096 tokens au raisonnement. Cette décision a renversé le classement. La précision de REAP20 a été divisée par plus de deux, tandis que la version complète du même modèle a obtenu un résultat presque inchangé. La cause était prosaïque : dans environ deux cas sur trois, REAP20 atteignait le plafond avant d’avoir pu terminer sa réponse.

Prenons un exemple simple. Le modèle sait écrire la solution pour Scikit-learn et construit le bon plan, mais sa sortie est interrompue avant le code final. Le système d’évaluation lui attribue zéro, exactement comme pour une réponse entièrement erronée. En ne regardant que la précision finale, on pourrait conclure que le modèle s’est dégradé. En réalité, c’est le dispositif de mesure qui est défectueux.

C’est une leçon essentielle pour tout benchmark interne : enregistrez la cause de fin de réponse, le nombre de tokens utilisés, le temps de génération et la proportion de sorties interrompues. Les résultats avec finish_reason=length doivent être analysés séparément, faute de quoi une contrainte d’infrastructure sera prise pour une faiblesse du modèle.

Résultats après correction

L’auteur a commencé à augmenter progressivement la limite et à reprendre les raisonnements interrompus. En mode d’effort maximal, Qwen3.8-27B a finalement résolu 252 des 509 tâches, contre 173 au départ. Le gain a atteint 79 solutions, mais son coût était désagréable : la série d’itérations a pris environ 153 heures. En précision finale, le modèle a seulement rejoint la Qwen3.6-MoE, plus rapide et utilisée sans raisonnement.

Sur une RTX 6000 Pro professionnelle, le modèle Qwen3.8-Flash-Next-NVFP4 a obtenu 58,1 % sur l’intégralité de DS1000 en 8,5 minutes. Ce résultat ne peut toutefois pas être transposé à une carte graphique grand public : le matériel, le format des poids et la configuration diffèrent, ce qui modifie l’économie de l’exécution.

La conclusion pratique est banale, mais utile. Commencez par constituer un petit ensemble de vos propres tâches, puis fixez les versions des bibliothèques et des paramètres d’exécution identiques. Mesurez ensuite la précision, la latence, les interruptions dues à la limite et le coût d’une solution réussie. Pour un assistant quotidien, choisissez le modèle selon sa vitesse dès lors que sa qualité est suffisante ; pour les tâches nocturnes, vous pouvez lui accorder davantage de temps et de tokens. Et surtout, ne tentez pas de compenser une expérience mal conçue par quelques centaines d’heures-GPU supplémentaires.