Les LFM2.5-Encoders plaident pour les petits modèles : 3,7× plus rapides que ModernBERT sur CPU

Depuis un certain temps déjà, le réflexe par défaut en NLP consiste à pointer un modèle génératif sur le problème et à payer pour ce privilège. La nouvelle publication de Liquid AI défend une thèse plus discrète : les tâches qui tournent en continu, routage d'intention, contrôles de conformité, détection de PII, classification de texte, sont mieux gérées par un petit encodeur posé sur un CPU d'ordinateur portable.

Les LFM2.5-Encoders sont open-weight et disponibles dès aujourd'hui sur Hugging Face, construits à partir des backbones décodeurs LFM2.5 de Liquid AI. L'entreprise transforme chaque décodeur causal en encodeur bidirectionnel et positionne le résultat face à la classe de modèles qui tient ce terrain depuis BERT. L'argument est simple : vous n'avez pas besoin d'un modèle de plusieurs milliards de paramètres pour décider si un ticket d'assistance mentionne un remboursement ou si un contrat contient une clause interdite.

Un gain de vitesse de 3,7× à l'extrémité haute de la fenêtre de contexte

Les LFM2.5-Encoders et ModernBERT prennent tous deux en charge un contexte de 8 192 tokens, la comparaison couvre donc toute la plage. C'est sur CPU que l'écart se creuse. ModernBERT-base met plus d'une minute et demie par passe avant à longueur maximale. Le LFM2.5-Encoder-230M réalise la même passe en environ 28 secondes. Liquid AI parle d'une vitesse environ 3,7× supérieure et affirme que le 230M est le modèle le plus rapide de la comparaison à chaque longueur de séquence, devant même le ModernBERT-base, pourtant plus petit, sur les entrées courtes.

Le débit raconte la même histoire en miroir. À mesure que les entrées s'allongent, le débit de ModernBERT chute fortement, tandis que les courbes des LFM2.5 grimpent vers une plage intermédiaire avant de s'atténuer. La conséquence pratique, selon l'entreprise : un contrat complet, une transcription ou un long fil d'assistance peut être analysé ou classé en moins de 30 secondes sur un CPU d'ordinateur portable. C'est la différence entre une tâche que l'on exécute sélectivement et une tâche que l'on peut se permettre d'exécuter sur tout.

Le tableau des benchmarks : 14 modèles, 17 tâches

Liquid AI a affiné 14 modèles sur 17 tâches issues de GLUE, SuperGLUE et de la classification multilingue, en rapportant pour chacun la moyenne sur cinq seeds de validation distincts. Le LFM2.5-Encoder-350M se classe quatrième sur les 14. Les trois modèles devant lui sont tous plus grands, dont un de 3,5 milliards de paramètres, près de dix fois sa taille. Le modèle 230M bat ModernBERT-base et tous les modèles EuroBERT du tableau tout en étant plus petit que la plupart d'entre eux. Les deux obtiennent également des scores supérieurs aux LFM2.5-Retrievers de Liquid AI publiés le mois dernier.

Ce sont les chiffres de l'entreprise elle-même, et le framework comme les résultats bruts sont open-sourcés : le tableau peut donc être vérifié, plutôt que pris pour argent comptant.

Pourquoi un encodeur de 230M bat un LLM génératif pour les tâches tournant en continu

L'économie est le cœur du sujet. Un encodeur affiné est plus petit, plus rapide et bien moins coûteux à exécuter qu'un LLM génératif, et il tient sur des CPU que l'entreprise possède déjà, selon Liquid AI. L'architecture est à l'origine de cette efficacité. Chaque encodeur est initialisé à partir de l'un des backbones décodeurs LFM2, puis rendu bidirectionnel grâce à trois modifications : un masque d'attention bidirectionnel, des convolutions courtes non causales avec un padding symétrique, et un objectif de langage masqué qui masque 30 % des tokens pendant l'entraînement.

L'entraînement se déroule en deux étapes. La première construit une compétence linguistique générale sur un grand corpus web avec un contexte de 1 024 tokens. La seconde étend le contexte à 8 192 tokens sur l'ensemble des données, ce qui, selon l'entreprise, renforce les compétences factuelles, juridiques et multilingues. Le créneau est explicite : des tâches de compréhension à haut volume, classification, routage, extraction, scoring, qui tournent en permanence et doivent rester peu coûteuses.

Sur GPU, le schéma se confirme avec une marge plus réduite. ModernBERT-base mène en dessous d'environ 1 000 tokens sur le GPU Apple, et les modèles LFM2.5 prennent la tête à partir d'environ 2 000 tokens. C'est sur les chiffres CPU que l'argument prend tout son sens : ces tâches tournent toute la journée, généralement sur CPU.

Ce que vous pouvez construire, et ce qu'il en coûte pour démarrer

Liquid AI a publié cinq démos, chacune dans un espace Hugging Face CPU uniquement. Le routage de prompts zero-shot évalue un prompt entier par rapport à des voies de routage rédigées en texte libre en une seule passe. Le linting de politiques vérifie le texte par rapport aux règles de l'entreprise, également en texte libre, en attribuant un score à chaque token pour chaque règle. La vérification orthographique corrige les fautes token par token. La détection de PII retire 40 types d'informations personnelles dans 16 langues. Une démo bonus transforme l'encodeur en chatbot à diffusion masquée, générant du texte par démasking itératif plutôt que de gauche à droite.

Le coût d'entrée est de quelques lignes de code transformers. Chargez le modèle avec AutoModelForMaskedLM pour la prédiction de tokens masqués, ou chargez le corps avec AutoModel et ajoutez votre propre tête pour la classification, la classification de tokens, la régression ou la recherche. L'affinage se fait par tâche : l'entreprise recommande le 350M quand la précision est primordiale et le 230M pour un matériel plus restreint ou un débit plus élevé, avec un tutoriel couvrant de longs documents juridiques en contexte 8K.

Les encodeurs n'ont jamais vraiment disparu, ils sont seulement passés de mode face aux modèles génératifs. Ce que Liquid AI a ajouté, c'est précisément ce qui avait poussé les équipes vers les modèles génératifs à l'origine : le long contexte et l'inférence rapide. Le résultat est une classe de modèles qui rivalise sur les métriques que l'on ressent concrètement, la latence et le coût par document, les deux tailles étant publiées en open weights sur Hugging Face.