Les mêmes réponses, deux fois moins de tokens : nos deux premiers modèles sont sur Hugging Face

GreenPT est désormais sur Hugging Face. Nous y avons publié nos deux premiers modèles ouverts :

• GreenPT/Qwen3.5-9B-honey : adaptateur LoRA sur Qwen3.5-9B
• GreenPT/Qwen3.8-27B-honey : adaptateur LoRA sur Qwen3.8-27B

Aucun des deux ne sait quoi que ce soit que le modèle de base ignore. Ils sont entraînés pour un seul comportement : donner la même réponse en moins de tokens. C’est la même règle que celle de Honey pour Mac, déplacée de l’outil vers les poids.

C’est une expérience à ses débuts. Nous la publions dès maintenant, défauts compris, parce que les premiers chiffres ont changé notre façon de penser l’efficacité, et parce que nous préférons que d’autres la mettent à l’épreuve plutôt que de la peaufiner en privé.

Le problème que nous voulons résoudre

Chaque token produit par un modèle coûte du calcul, de l’argent et de l’énergie. Dans une réponse typique, la plupart des tokens ne sont pas la réponse. Ce sont le préambule, la question reformulée, le « Bien sûr ! Voici une analyse détaillée », le résumé final du résumé.

Pour un chatbot, c’est un peu agaçant. Pour des agents, des modèles qui appellent des modèles des milliers de fois par jour, c’est un pur surcoût, payé à la fois par l’émetteur et par le destinataire.

On peut corriger cela par le prompt. Nous avons essayé : une consigne de style détaillée dans le prompt système a réduit la sortie de 74 %. Elle a aussi rendu chaque requête 8,3 fois plus chère au total, parce que la consigne elle-même est renvoyée et retraitée à chaque appel. La concision était bien réelle, mais la facture est partie dans le mauvais sens.

La question est donc devenue : peut-on intégrer la concision par l’entraînement, pour qu’elle ne coûte rien à l’inférence ?

Qu’est-ce qu’un adaptateur LoRA (en 30 secondes)

Un adaptateur LoRA est un petit ensemble de poids supplémentaires entraînés par-dessus un modèle de base figé.

Au lieu de mettre à jour une grande matrice de poids W, on apprend deux matrices fines A et B et on calcule W + BA. Comme A et B sont de rang faible, d’où le nom Low-Rank Adaptation, la partie entraînable pèse quelques centaines de mégaoctets, et non des dizaines de gigaoctets.

Cela vous apporte trois choses :

• Peu coûteux à entraîner : un seul GPU, quelques heures, pas des semaines.
• Portable : vous distribuez l’adaptateur seul ; les utilisateurs apportent le modèle de base qu’ils ont déjà.
• Non destructif : désactivez-le et vous retrouvez le modèle d’origine.

Cela signifie aussi que la modification est assez petite pour qu’on puisse raisonner dessus. Ce qui rend les résultats ci-dessous plus intéressants, pas moins.

Les chiffres

Nous avons mené des évaluations A/B appariées : mêmes prompts, même décodage glouton, raisonnement désactivé, adaptateur activé puis désactivé. 26 prompts dont la réponse peut être vérifiée, répartis entre questions-réponses, explications et code.

	Tokens de sortie	Correct (base / adaptateur)
9B honey	−52 %	25/26 · 25/26
27B honey	−46 %	26/26 · 26/26

Par catégorie, l’adaptateur 9B a réduit les questions-réponses de 58 %, les explications de 56 % et le code de 27 %. Le 27B est allé plus loin sur les questions-réponses (−78 %) et a tenu −47 % sur les explications. Même taux de réussite dans tous les cas. Là où les deux modèles ont échoué, ils ont échoué sur le même prompt.

Deux fois moins de sortie pour une exactitude identique, grâce à un adaptateur qui tient sur une clé USB.

Ce qui n’a pas marché

Publier tôt, c’est aussi publier ce qui ne va pas.

L’adaptateur 27B est plus long sur les prompts de code nus. Demandez-lui « écris une fonction qui fait X » et il produit un code environ 12 % plus compact que le modèle de base, puis ajoute une section « Comment ça marche » que le modèle de base n’écrit jamais. Effet net : +24 % de tokens sur ce type de prompt. Sur des tâches de code réalistes (corriger ce bug, refactoriser ceci, étendre cela, avec du code dans le prompt), l’adaptateur fait gagner 5–12 % comme prévu. La régression est donc limitée, et nous savons d’où elle vient : notre corpus de style comporte des sections d’explication dans ses exemples de code. C’est une correction des données d’entraînement, et c’est la prochaine sur la liste.

Deux pièges qui nous ont piégés, pour qu’ils ne vous piègent pas :

1. Les clés de l’adaptateur doivent correspondre à l’arborescence du modèle que vous chargez. Notre outil d’entraînement a enregistré les poids sous model.language_model.layers… ; AutoModelForCausalLM construit model.layers…. PEFT ignore en silence chaque tenseur qui ne correspond pas : vous obtenez un modèle qui « fonctionne » mais qui n’est que le modèle de base. Les adaptateurs publiés ont des clés remappées, mais si vous réentraînez, vérifiez ce point en premier.
2. Le token d’arrêt du dépôt de base est faux pour le chat. Qwen/Qwen3.5-9B fournit un eos_token_id égal à <|endoftext|>, alors que son modèle de chat termine les tours par <|im_end|>. Un harnais qui hérite de cette configuration ne voit jamais l’adaptateur s’arrêter, et cela ressemble exactement à un adaptateur cassé. Générez avec eos_token_id=[248046, 248044]. Nos dépôts d’adaptateurs fournissent un generation_config.json correct.

Une remarque sur le déploiement. Faire tourner un LoRA non fusionné coûte environ 37 % de plus par token dans notre configuration, car chaque couche adaptée effectue une paire supplémentaire de petites multiplications matricielles. En production, fusionnez une fois l’adaptateur dans les poids de base et servez un modèle simple. Ne le gardez non fusionné que pendant vos itérations ou si vous changez d’adaptateur à chaud.

Essayez-le

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

adapter = "GreenPT/Qwen3.5-9B-honey"
tok = AutoTokenizer.from_pretrained(adapter)
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-9B", torch_dtype="auto", device_map="auto")
model = PeftModel.from_pretrained(model, adapter)

msgs = [{"role": "user", "content": "Explain what a mutex is."}]
ids = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(ids, max_new_tokens=512, do_sample=False, eos_token_id=[248046, 248044])
print(tok.decode(out[0][ids.shape[-1]:], skip_special_tokens=True))

Commentez la dernière ligne PeftModel et lancez le même prompt pour constater la différence par vous-même.

La suite

Ce travail nous a convaincus de deux choses.

L’efficacité, ça s’entraîne. Nous n’avons pas créé de nouveau modèle. Nous avons pris un modèle que les gens utilisent déjà et l’avons rendu moins cher à faire tourner, avec quelques centaines de Mo et quelques heures de GPU. Cette recette ne devrait pas être propre à Qwen. Nous construisons des pipelines open source pour affiner n’importe quel modèle ouvert en vue de l’efficacité, avec les données d’entraînement, le code d’entraînement, le harnais d’évaluation et les pièges, et nous publierons le tout. Pas un modèle sur un benchmark, mais un processus reproductible que chacun peut appliquer au modèle qu’il a déjà choisi.

Le plus gros gain se joue entre agents. Quand la sortie d’un modèle est l’entrée d’un autre, chaque préambule poli se paie deux fois : une fois pour le générer, une fois pour le lire. Nous pensons que des protocoles d’agent à agent plus efficaces compteront davantage que n’importe quelle optimisation d’un modèle isolé. Les adaptateurs sont notre premier pas : un modèle qui s’exprime déjà de façon concise est le pair le plus simple sur lequel bâtir un protocole sobre.

Les deux modèles sont disponibles sur Hugging Face. Faites-les tourner, poussez-les dans leurs retranchements et dites-nous ce que vous trouvez.