Un encodeur de 17 millions de paramètres choisit un outil en 14 ms sur CPU

La dernière étape de nombreux pipelines LLM paraît modeste : choisir une option parmi un ensemble connu à l'avance. Quel outil appeler, sous quelle étiquette classer la requête, vers quel itinéraire l'orienter. On confie généralement cette tâche à un grand modèle via un prompt, ce qui est lent, coûteux et sensible à l'ordre des options. Tardelli Ronan Coelho Stekel a testé jusqu'où un encodeur peut être réduit pour ce travail, et publie en open source la famille Crivo, composée de six modèles allant de 17 millions à 1 milliard de paramètres.

Les chiffres clés. Les modèles de 68M et 150M devancent le classificateur zero-shot DeBERTa-v3 à 435M de paramètres de 4,9 et 5,9 points de précision sur les 209 tâches de System1-Arena, qui ont fait l'objet d'un audit de recoupement avec les données d'entraînement. Sur les 145 tâches jamais vues par les modèles pendant l'entraînement, ils se maintiennent au moins au niveau de DeBERTa. Le plus petit modèle, 17M, répond à une requête en 14 ms de médiane sur 16 threads CPU. Le classificateur DeBERTa, dans les mêmes conditions, affiche une médiane de 728 ms.

Lire les options ensemble ou une par une ?

La deuxième question de l'étude importe davantage aux architectes de systèmes. L'encodeur peut recevoir toutes les options en une fois (joint) ou évaluer chaque option séparément, appariée à la requête (per-option). L'auteur a mené une étude sur trois graines aléatoires avec un modèle de 32M de paramètres, sur un ensemble de test tiré de 37 benchmarks.

Le mode per-option l'emporte de 5,8 points de compétence corrigée du hasard, pour un nombre égal de pas d'optimisation. À budget de calcul d'entraînement à peu près équivalent, l'écart se réduit à 2,8 points. Deux benchmarks externes confirment la direction de l'effet, mais sur les tâches jamais vues, la différence n'est pas statistiquement significative.

L'avantage n'existe pas toujours. Il n'apparaît qu'en cas d'initialisation à partir d'un reranker : son entrée sous forme de paire « requête – candidat » correspond à la façon dont le schéma per-option lit les options. En partant d'un encodeur brut, les deux approches sont indiscernables.

Le prix de la précision et le point faible du mode joint

Le mode per-option exige de 5 à 13 fois plus de passages dans l'encodeur. En latence médiane, la perte ne dépasse pas un facteur deux, mais en moyenne elle dépasse déjà un facteur quatre : les longues listes d'options pèsent sur la queue de distribution. C'est pourquoi les modèles joint sont ceux retenus pour la publication.

L'approche joint présente un défaut mesuré : la permutation des options change 12 à 23 % des réponses. Le schéma per-option n'a pas cette dépendance, les réponses ne changent pas du tout. Pour la production, c'est un argument sérieux : l'ordre des outils dans une liste ne devrait pas influencer le choix, mais ici c'est le cas.

Jusqu'à 68M de paramètres, les modèles Crivo dominent dans leur catégorie de taille sur le classement public. L'évaluation se fait sur des tests privés, majoritairement proches de la distribution d'entraînement, ce qui en fait un résultat solide pour des tâches similaires à celles de l'entraînement, mais pas une garantie de transfert.

Le contenu de la publication

• Famille Crivo : six encodeurs joint ouverts de 17M à 1 milliard de paramètres, collection sur Hugging Face (tardellirs/crivo).
• 68M et 150M : +4,9 et +5,9 points de précision par rapport à DeBERTa-v3 (435M, zero-shot) sur les 209 tâches de System1-Arena.
• 145 tâches jamais vues : parité avec DeBERTa-v3 au minimum.
• 17M : médiane de 14 ms sur 16 threads CPU, contre 728 ms pour DeBERTa-v3.
• Étude sur le modèle de 32M : le mode per-option bat le mode joint de 5,8 points à pas égaux et de 2,8 points à calcul égal, trois graines aléatoires, 37 benchmarks.
• Coût du mode per-option : de 5 à 13 fois plus de passages, jusqu'à 2× en latence médiane et plus de 4× en moyenne.
• Sensibilité à l'ordre : 12 à 23 % des réponses du mode joint changent lors de la permutation des options.
• Code et résultats publiés dans le dépôt crivo-decision-encoders sur GitHub.

À quoi cela peut servir

Pour le routage de requêtes entre modèles, le choix d'outils par un agent et la classification selon un ensemble fermé d'étiquettes, ces encodeurs offrent une alternative bon marché à l'appel d'un LLM. Le modèle de 17M tient en 14 ms sur un processeur ordinaire, sans GPU, ce qui change l'économie du problème : la décision peut être prise à chaque étape d'une boucle agentique, plutôt que réservée à une requête coûteuse isolée.

Les conclusions pratiques sont les suivantes. Si la stabilité importe, il faut soit randomiser et moyenner l'ordre des options, soit utiliser le schéma per-option en acceptant une latence de queue plus élevée. Si vous entraînez vous-même ce type de sélection, partez d'un reranker : à partir d'un encodeur brut, la lecture option par option n'apporte aucun gain. Avant tout déploiement, il faut faire tourner le modèle sur ses propres tâches : la parité sur données jamais vues signifie « pas moins bon que DeBERTa », pas une supériorité, et les plus gros écarts sont obtenus lorsque la distribution reste proche de celle de l'entraînement.