GRPO sur 350M : 29,7 % de sorties valides après 100 étapes

Un ajustement GRPO de LFM2.5-350M mené avec TRL et environ 500 échantillons fait progresser la conformité aux sorties structurées sur IFStruct de 22,6 % à 29,7 %. L'ensemble s’exécute sur un GPU de niveau gratuit et s’appuie sur une pile d’évaluation locale via llama.cpp. Les scores détaillés JSON et YAML, ainsi que la configuration d’entraînement et les récompenses, sont publiés. Le pipeline revendique une démonstration de faisabilité plutôt qu’une reproduction du score officiel d’IFStruct.

Le 350M ajusté atteint 29,7 % sur IFStruct, JSON à 31,9 %

Après ajustement, le modèle atteint 29,7 % de succès sur 2000 échantillons, avec 319/1000 en JSON (31,9 %) et 275/1000 en YAML (27,5 %). La latence moyenne mesurée sur cette passe est de 1518 ms. En configuration de base servie localement, le score global était de 22,6 % (452/2000), avec 18,0 % en JSON (180/1000) et 27,2 % en YAML (272/1000), pour une latence moyenne de 1453 ms. L’écart global répliqué localement va donc de 22,6 % à 29,7 %. Le blog IFStruct rapporte 21,1 % pour LFM2.5-350M ; la mesure locale de référence à 22,6 % via llama.cpp en BF16 est jugée proche et sert de base de comparaison sur la même pile.

Des récompenses ciblées et 100 étapes d’entraînement

Trois fonctions de récompense, toutes bornées sur [0,1], évaluent la structure des sorties : format demandé et analysabilité, compte de champs de premier niveau et validation de schéma. Elles sont agrégées avec des poids [1.0, 0.5, 2.0]. L’entraînement GRPO court sur 100 étapes, avec 8 générations par groupe d’invite, et une empreinte pensée pour un GPU de 16 Go. La configuration inclut un taux d’apprentissage de 5e-5, 10 étapes de warmup, une taille de lot par périphérique de 4, une accumulation de gradient sur 8, 2 steps par génération, une longueur maximale de complétion de 1024, la désactivation du masquage des complétions tronquées, une température de 1,1, et un logging à chaque étape. En cours d’exécution, les trois composantes de récompense progressent, la divergence de KL par rapport au modèle de référence augmente après l’échauffement, et la part de sorties tronquées reste proche de zéro.

Données Nemotron et deux augmentations d’invite

Le jeu de données utilisé pour l’entraînement est nvidia/Nemotron-RL-instruction_following-structured_outputs, qui relie chaque invite à un schéma JSON de référence et précise le nombre de champs attendus, pour un total d’environ 500 exemples. Afin d’aligner cette distribution sur celle de l’évaluation IFStruct, deux modifications sont apportées : dans 40 % des cas, une instruction demande de présenter la sortie dans un bloc de code fermé pour renforcer le respect du format, et dans 20 % d’un autre sous-ensemble, les invites sont reformulées en exercices de tableau de niveau supérieur, ce qui impose de générer des listes brutes avec un nombre d’éléments défini.

Adaptation LoRA ciblée puis fusion en checkpoint autonome

Le modèle LFM2.5-350M est ajusté avec un adaptateur LoRA, en ciblant des modules spécifiques à son architecture hybride attention/convolution : q_proj, k_proj, v_proj, out_proj, in_proj, w1, w2 et w3. Cette adaptation ajoute environ 6 millions de paramètres, soit environ 1,66 % du total. En fin d’entraînement, l’adaptateur est fusionné dans les poids de base pour obtenir un checkpoint autonome, puis le modèle et le tokenizer sont sauvegardés dans un répertoire suffixé -merged, prêt pour la conversion en GGUF.

Pile d’évaluation locale : llama.cpp, GGUF et 2000 échantillons

L’évaluation s’appuie sur uv pour les outils Python et sur llama.cpp pour servir le modèle, installable via Homebrew, la commande llama-server --version permettant la vérification. Le service expose une API compatible OpenAI, ici utilisée localement, notamment sur un MacBook Pro équipé d’un Apple M5 Max et de 36 Go de mémoire unifiée. Le modèle de base est servi en BF16 GGUF, avec un alias, host 127.0.0.1 et des paramètres runtime, puis évalué sur 2000 échantillons via http://localhost:8080/v1 avec un max-tokens de 2048. Après ajustement, le checkpoint fusionné est converti en BF16 GGUF grâce au convertisseur de llama.cpp (dépôt cloné en depth 1, installation de gguf-py, exécution du script de conversion), servi avec un nouvel alias et évalué via http://localhost:8081/v1, en enregistrant les résultats dans un fichier distinct.

Périmètre déclaré : démonstrateur, non-reproduction du pipeline IFStruct

Les auteurs précisent que le pipeline présenté n’est pas celui du modèle RL évoqué par IFStruct et que l’objectif n’est pas de reproduire le score officiel. Il s’agit d’un démonstrateur de faisabilité montrant qu’un ajustement spécifique à la tâche peut améliorer un petit modèle au niveau de la conformité de sortie, potentiellement jusqu’à rivaliser avec des modèles plus grands. Le code est mis à disposition sur GitHub. L’entraînement se fait sur un GPU de niveau gratuit, et l’évaluation peut être exécutée localement via llama.cpp, les deux volets constituant un parcours complet et léger.