Le mur des 60 : neuf tentatives contre un plafond, et la variable qui le fait tomber.

Dans le premier article de cette campagne, un RNN local de 2,9 milliards de paramètres atteignait la parité avec Qwen3-30B en tool-calling pour 0,53 $ d'entraînement. Restait à savoir si on pouvait faire mieux que 61 sur 82. La réponse courte : pas avec ce modèle. Nous avons passé une semaine à essayer, six méthodes et neuf mesures sont venues s'écraser entre 58 et 61, et il a fallu changer la seule chose que l'entraînement ne peut pas changer pour comprendre ce qui bloquait.

Brut, un RWKV-7 de 7,2 milliards fait 29/82, à peu près comme le 2,9B brut (28). Le même state-tuning qu'au premier article, appliqué tel quel pour environ 3 $, l'amène à 69/82. C'est onze points au-dessus de Qwen3-30B dans sa configuration de production, et deux points sous le même Qwen quand on lui prête notre échafaudage de retrieval. Comme d'habitude, tout est vérifiable : générations brutes, états entraînés, empreintes, recettes, et cette fois le code de la boucle RL aussi.

Neuf tentatives, trois points d'écart

Après le premier article, nous avons attaqué le plafond avec ce qu'on avait sous la main. Chaque tentative est dans le banc public, générations comprises :

Quelques leçons sont sorties de cette série, et elles valent la peine d'être détaillées parce qu'elles disent ce qu'un petit modèle sait et ne sait pas apprendre.

Les données ciblées n'ont pas fait ce qu'on attendait d'elles. Nous avions construit 135 exemples visant précisément les sept erreurs récurrentes de sélection, validés contre les schémas, filtrés contre le juge. Aucune des sept n'a été corrigée. Les mauvaises réponses se sont déplacées, model_get_info devenant model_manage, pendant que l'abstention montait à la perfection sans qu'on la vise. Un état de 11 Mo apprend très bien quand se taire. Il n'apprend pas lequel de deux noms proches est le bon.

Le RL n'a pas percé non plus, mais il a échoué de façon instructive. Nous avons monté une boucle GRPO (avantages normalisés par groupe, surrogate clippé, notre scoreur mécanique comme récompense) au-dessus du champion, en deux versions : continuer d'entraîner l'état, ou geler l'état et poser un LoRA frais par-dessus. Cinq millions de paramètres entraînables d'un côté, trente de l'autre. Les deux convergent vers presque le même profil, arguments 13, sélection difficile 16, simple autour de 14, pour un total de 60 et 59. Le RL a bougé ce que les données n'arrivaient pas à bouger, la sélection simple passe de 12 à 15, et l'a payé en précision d'arguments, au tarif exact de notre récompense qui payait la sélection le double des arguments. Les modèles ont maximisé ce qu'on a payé, rien d'autre.

C'est le point important de cette série : la bande 58-61 se comporte comme une frontière. L'entraînement choisit où l'on se place dessus, jamais son niveau. On le voit round après round dans la version LoRA, les arguments font 16, 17, puis 13 pendant que la sélection simple fait 12, 12, 14, et le total ne bouge pas. L'early stopping n'y change rien, les checkpoints pris au pic de la récompense interne scorent 58 à 60 sur le juge.

Deux notes pratiques pour qui réutilisera le code : à LR 1e-4 le LoRA détruit la politique en un round, l'abstention passe de 8/8 à 1/8 (2e-5 est stable) ; et une sonde de 24 cas ne prédit pas un juge de 82, n'en faites jamais un critère de sélection de checkpoint.

La variable qui restait

Quand six méthodes plafonnent au même endroit, le suspect n'est plus la méthode. Nous avons donc changé la taille, et rien d'autre. Le checkpoint RWKV-7 G1g 7,2B est de la même génération que notre 2,9B, publié trois jours avant lui. Mêmes 2 920 exemples, même recette de state-tuning, un epoch, mêmes hyperparamètres, même juge figé. Environ 3 $ de L40S.

Et pour que le résultat veuille dire quelque chose, le contrôle exigé avant publication : évaluer aussi le 7,2B nu, sans entraînement.

Le mur était donc bien le backbone. Six méthodes n'avaient pas acheté un point au-dessus de 61 ; le changement de taille en achète huit. Et les catégories qui bougent sont celles que la série précédente avait désignées : les arguments passent de 18 à 21, au-dessus du Qwen équipé de notre top-40, et la sélection difficile atteint 18/23, le meilleur score de la campagne.

Le contrôle raconte l'autre moitié de l'histoire. Nus, les deux checkpoints sont jumeaux, 28 et 29 sur 82, avec la même signature, zéro abstention et des sorties non parsables. Le 7,2B brut n'appelle pas mieux les outils que le 2,9B brut. La taille seule ne donne rien sur cette tâche. C'est l'état entraîné qui va chercher ce que le gros modèle sait latentement, et son effet grandit avec la taille : +33 points au 2,9B, +40 au 7,2B.

Reste le classement qui intéresse tout le monde. Le RNN de 7,2 milliards bat Qwen3-30B dans sa configuration de production, celle où un opérateur l'utiliserait vraiment, 69 contre 58. À échafaudage égal il s'approche à deux points d'un modèle quatre fois plus gros. L'artefact qui porte tout ça est un état initial de 17 Mo, chargeable à chaud sur le checkpoint public.

Les statistiques, pour finir. L'effet de la méthode ne se discute pas : tuné contre brut à 7,2 milliards, 42 cas discordants gagnés contre 2, p = 1,1×10⁻¹⁰ en McNemar exact. Le saut de taille pris isolément, 69 contre 61, donne 12 gagnés contre 4 et p = 0,077, au bord de ce qu'un juge de 82 cas peut trancher seul. Ce qui rend le constat solide n'est pas ce test isolé, c'est la convergence : neuf tentatives enfermées dans trois points, puis un changement de backbone qui en sort de huit. Les deux chiffres sont publiés, avec les fichiers pour les recalculer.

Le contrôle d'architecture, et il coupe dans les deux sens

Restait la question qui fâche : tout ça, c'est l'architecture RWKV ou c'est notre entraînement ? Nous avons pris un transformer de taille appariée, Qwen2.5-7B-Instruct, et nous lui avons fait subir le protocole exact du rung précédent. D'abord nu sur le juge. Puis tuné sur nos 2 920 exemples, mêmes textes bruts, LoRA à défaut de state-tuning puisqu'un transformer n'a pas d'état, deux epochs, et re-jugé.

Premier verdict : nu, le transformer sait déjà faire le métier. 69/82 sans le moindre entraînement, avec un 20/23 en sélection difficile qu'aucun modèle de notre campagne n'avait atteint, son grand frère de 30 milliards compris. L'écart entre les familles n'est donc pas l'architecture, c'est le corpus de pré-entraînement : celui de Qwen2.5 est saturé d'appels de fonction, celui des RWKV G1 n'en contient presque pas. Notre state-tuning à 3 $ comble exactement ce fossé, ni plus ni moins.

Second verdict, moins attendu : transplantée telle quelle sur un modèle déjà réglé en usine, notre recette fait des dégâts. 69 → 51, une dégradation nette (23 cas perdus contre 5 gagnés, p = 9×10⁻⁴), portée par 25 faux refus. Le curriculum d'abstention dont le RWKV avait besoin, lui qui ne se taisait jamais, apprend à un modèle déjà calibré à se taire sur de vraies demandes. Un SFT optimisé pour Qwen, avec son chat template et ses hyperparamètres à lui, ne ferait sans doute pas ça, et c'est précisément la leçon : une recette d'entraînement n'est pas une commodité portable, elle épouse un modèle. Le state-tuning épouse RWKV. C'est cet ajustement-là que les +40 points à 3 $ achètent.

Ce qui survit à l'échelle

Deux faiblesses traversent le changement de taille. La sélection simple reste moyenne (13/18) : les collisions de namespace, linear_search_issues contre github_search_issues, survivent au scaling, ce qui suggère un problème de format ou de retriever plus que de capacité. Et le multi-étapes reste à zéro partout, sans mystère : notre harnais est un tour, un appel, par construction.

Les limites du protocole restent celles du premier article, un seul banc, une seule tâche, nos outils. Le run 7,2B n'a pas encore été répliqué de bout en bout comme l'avait été le rung 1, et le contrôle transformer n'a eu droit qu'à notre recette naïve, pas à un SFT aux petits soins : ces deux chantiers sont ouverts à qui veut les prendre.

Et en production ?

Une précision pour finir, parce que le chiffre de banc et l'usage réel sont deux choses. Le 7,2B à 69/82 n'est pas, aujourd'hui, notre modèle de production interactive : sur un CPU ordinaire, préfiller les 5 300 tokens d'une shortlist top-40 avec un 7,2B se compte en dizaines de secondes, et c'était déjà la raison de notre choix du 2,9B au début de la campagne. Il prend deux rôles : les tâches d'agent asynchrones, où personne n'attend devant l'écran, et le jour où un GPU entre dans la boucle, l'état de 17 Mo est prêt.

Le modèle de production interactive reste le 2,9B à 61/82, et son prochain gain ne viendra pas d'un entraînement de plus, la campagne l'a assez montré. Il viendra du cache d'état : un RNN peut sauvegarder son état après un préfixe fixe et repartir de là, le mécanisme est mesuré à quelques secondes par requête. Reste un détail d'ingénierie qui a son importance : le format GGUF ne transporte pas un état initial entraîné, le serving passe par le runtime natif. C'est le genre de chose qu'on découvre en déployant, pas en benchmarkant, et autant l'écrire ici.

La suite de cette histoire fait l'objet d'un troisième article : comment le créateur de l'architecture nous a fait découvrir que notre protocole biaisait nos propres mesures, et ce que la correction a révélé.

Reproduire

Tout est dans le dépôt du banc (miroir Forgejo) : le juge de 82 cas, les schémas, les générations brutes de chaque mesure de cet article, y compris celles qui ne nous arrangent pas, les états entraînés avec leurs SHA-256, les recettes de pod, la boucle GRPO, et les scripts qui régénèrent les figures depuis les JSON commités. La campagne complète, neuf mesures, deux runs de RL, l'ascension 7,2B et son contrôle, a coûté environ 25 $ de GPU loué. Le protocole détaillé du juge et de l'anti-fuite est dans le premier article.

Un trou dans le protocole ? Écrivez-nous : contact@scarletwolf.ai. C'est à ça que sert la publication.