Hugging Face accueille de nouveaux encodeurs LFM2.5, opposant l’inférence CPU à long contexte à ModernBERT

Hugging Face a ajouté deux modèles encodeurs de Liquid AI qui traitent des entrées de 8 192 tokens tout en défiant ModernBERT sur la vitesse CPU à long contexte. Cette sortie met à l’épreuve une affirmation précise : le traitement du langage à l’échelle d’un document ne nécessite pas toujours un GPU ni un modèle génératif.

Liquid AI affirme que son encodeur de 230 millions de paramètres réalise un passage avant de 8 192 tokens sur un CPU testé en environ 28 secondes. ModernBERT-base a nécessité plus de 90 secondes dans la comparaison de l’entreprise. Cet écart rapporté fait de LFM2.5 vs ModernBERT un affrontement sur l’économie du déploiement, et pas seulement sur la précision des benchmarks.

Ce résultat compte, car les encodeurs gèrent discrètement des charges de travail récurrentes telles que la classification, le routage, l’extraction, la modération et la détection d’informations personnelles. Ces systèmes examinent souvent chaque document ou message entrant. Un modèle plus lent peut donc consommer une infrastructure considérable, même lorsque chaque tâche individuelle semble modeste.

Liquid AI a publié les poids de ses modèles, son banc d’évaluation, ses fiches de modèles et des démonstrations exclusivement sur CPU. Cependant, la performance mise en avant reste un résultat produit par le fournisseur. Des détails importants de déploiement, notamment la configuration du processeur et la prise en charge de runtimes optimisés, doivent encore faire l’objet de tests indépendants plus larges.

Hugging Face ajoute deux encodeurs LFM2.5 à poids ouverts

La sortie transforme l’architecture de décodeur de Liquid AI en deux encodeurs ciblés sur des tâches, conçus pour les documents longs et le matériel informatique courant.

Liquid AI a publié LFM2.5-Encoder-230M et LFM2.5-Encoder-350M sur Hugging Face le 28 juillet 2026. Les deux prennent en charge des contextes allant jusqu’à 8 192 tokens et utilisent l’architecture hybride LFM2 de l’entreprise.

Un encodeur lit une entrée et produit des représentations contextualisées pour la classification, la récupération, l’extraction ou des décisions au niveau des tokens. À la différence d’un modèle de langage causal, il ne génère pas principalement le token suivant de gauche à droite.

Cette distinction façonne à la fois le coût et le comportement. Un routeur de tickets d’assistance doit sélectionner une destination, pas rédiger une réponse. Un filtre de confidentialité doit localiser des segments sensibles, pas produire un paragraphe fluide.

Liquid AI a adapté ses backbones de décodeurs existants de 230M et 350M à ces tâches plus ciblées. L’entreprise a remplacé le masque d’attention causal par une attention bidirectionnelle, permettant à chaque token de prendre en compte le texte des deux côtés. Elle a aussi rendu les convolutions courtes de l’architecture non causales grâce à un remplissage symétrique.

L’entraînement a utilisé la modélisation de langage masqué, où certains tokens sont cachés et le modèle les prédit à partir du contexte environnant. Liquid AI indique avoir masqué 30 % des tokens durant l’entraînement.

L’entreprise a utilisé un calendrier en deux étapes. L’entraînement initial a couvert des séquences de 1 024 tokens sur un vaste corpus web. Une seconde étape a étendu le contexte à 8 192 tokens en utilisant des données destinées à renforcer les performances factuelles, juridiques et multilingues.

La fiche du modèle 230M indique environ 229,7 millions de paramètres. La version 350M en contient environ 354,5 millions. Les deux ont une taille cachée de 1 024 et un vocabulaire de 65 536 entrées.

Ils prennent en charge 15 langues, selon la fiche du modèle. Ces langues comprennent l’anglais, l’espagnol, le français, l’arabe, l’hindi, le japonais, le vietnamien et le chinois.

Liquid AI positionne le plus petit modèle pour des contraintes plus strictes de latence et de mémoire. L’entreprise présente la version plus grande comme le choix orienté vers la précision. Les deux exigent un ajustement spécifique à la tâche avant de devenir des classificateurs, routeurs ou systèmes d’extraction de production.

Cette précision est importante pour toute présentation d’un encodeur LFM2.5 comme une application prête à l’emploi. Les modèles de base fournissent des représentations linguistiques, mais les organisations doivent ajouter une tête de sortie et entraîner le système pour leur tâche cible.

Les modèles utilisent la LFM Open License v1.0 de Liquid AI. Les qualifier de modèles à poids ouverts signifie que les développeurs peuvent télécharger et exécuter les paramètres entraînés. Cela ne signifie pas que la sortie utilise une licence logicielle permissive standard.

Hugging Face fournit le point de distribution, les fiches de modèles, les discussions de la communauté et les démonstrations. Liquid AI fournit l’architecture, les poids, les évaluations et l’implémentation. Cet arrangement facilite l’expérimentation tout en laissant au développeur du modèle la responsabilité des principales affirmations de performance.

Le changement immédiat est donc concret. Les développeurs disposent désormais de deux encodeurs téléchargeables à long contexte, conçus pour un déploiement CPU plutôt que pour une génération d’abord orientée GPU.

Pourquoi l’inférence CPU à long contexte est le véritable enjeu

L’opportunité centrale n’est pas un chatbot plus petit, mais une couche de décision moins coûteuse capable d’examiner des documents de travail complets.

Les systèmes de langage de production exécutent de nombreuses tâches qui ne nécessitent jamais de génération de texte. Ils étiquettent les demandes, détectent les violations de règles, classifient les sentiments, identifient les entités, classent les passages et choisissent quel modèle plus grand reçoit un prompt.

Ces opérations peuvent s’exécuter bien plus fréquemment que les réponses visibles d’un chatbot. Une plateforme d’agents peut évaluer un prompt selon plusieurs règles de sécurité avant la génération. Elle peut aussi classer à nouveau le résultat avant de le livrer.

Faire passer chaque étape par un grand modèle génératif ajoute de la latence et accroît les besoins matériels. Cela peut aussi introduire une variabilité de sortie dans des tâches qui exigent des étiquettes ou segments de tokens prévisibles.

Un encodeur ajusté offre une autre voie. Il lit le texte pertinent en un seul passage avant et renvoie des scores spécifiques à la tâche. Le modèle peut rester dans un processus local au lieu d’envoyer chaque document à un service externe.

La longueur du contexte détermine si ce processus voit la source complète. Les anciens encodeurs étaient souvent centrés sur des séquences plus courtes, obligeant les développeurs à découper les contrats, transcriptions ou fils d’assistance en fragments. Ce découpage peut séparer une décision des éléments de preuve qui en modifient le sens.

Une fenêtre de 8 192 tokens ne couvre pas tous les documents longs. Elle couvre toutefois beaucoup plus de texte que les déploiements BERT classiques à 512 tokens. Cette différence peut réduire le découpage et la logique d’agrégation qui l’entoure.

Liquid AI illustre cette approche avec des Hugging Face Spaces exclusivement sur CPU. Ses démonstrations couvrent le routage de prompts, l’analyse de conformité des règles, la vérification orthographique et la détection d’informations personnellement identifiables.

La démonstration PII détecterait 40 types d’informations dans 16 langues. L’analyse de conformité des règles attribue des scores aux tokens selon des règles fournies en texte libre. Le routage de prompts compare un prompt entier à des catégories de routage définies par l’utilisateur.

Ces démonstrations identifient les charges de travail que Liquid AI souhaite remporter. Ce sont des tâches de compréhension à fort volume, avec des sorties délimitées et des coûts d’infrastructure récurrents.

Un filtre de règles local est particulièrement pertinent pour les systèmes d’agents. Le filtre peut fonctionner dans le même environnement qu’une application, réduisant le besoin d’exposer du texte interne à un autre point de terminaison distant.

La même logique s’applique aux documents techniques locaux. Les équipes qui construisent une base de connaissances consultable ont besoin d’étapes de classification, d’extraction et de récupération avant qu’une réponse générée n’apparaisse.

Le déploiement CPU élargit les lieux où ces étapes peuvent s’exécuter. Un ordinateur portable de développeur, un serveur d’application ou un appareil en périphérie peut exécuter le modèle sans réserver un accélérateur distinct.

Cependant, « fonctionne sur CPU » ne signifie pas automatiquement instantané ou peu coûteux à toutes les échelles. Un passage de 28 secondes peut être pratique pour un contrat et inadapté à une interface interactive. Le débit en lots diffère également de la latence par document unique.

L’affirmation la plus forte est celle de la flexibilité opérationnelle. Les équipes peuvent placer un traitement spécialisé du langage là où leurs données résident déjà, puis réserver les GPU ou les modèles distants aux tâches qui nécessitent réellement de la génération.

Cette répartition du travail met sous pression les fournisseurs qui vendent une inférence généraliste pour chaque opération linguistique. Elle met également sous pression les équipes qui se tournent par défaut vers de grands modèles de langage avant de mesurer si un encodeur plus petit peut répondre au besoin.

LFM2.5 vs ModernBERT se joue sur l’architecture

L’avantage de vitesse rapporté par Liquid AI s’accroît avec la longueur des entrées, car son backbone hybride évite d’appliquer une attention complète dans chaque couche.

ModernBERT constitue l’adversaire le plus évident, car il vise lui aussi un encodage bidirectionnel efficace avec un contexte de 8 192 tokens. Publié fin 2024, il a actualisé la conception de BERT pour les entrées plus longues, le matériel moderne et un entraînement amélioré.

La recherche originale sur BERT a établi le préentraînement bidirectionnel comme fondement de la compréhension du langage. ModernBERT a ensuite combiné cette approche avec des mises à jour d’architecture et d’entraînement visant les besoins de déploiement actuels.

Liquid AI suit une autre voie. LFM2 alterne l’attention à requêtes groupées et des blocs de convolutions courtes à portes. L’attention relie les informations à travers une séquence, tandis que les convolutions courtes se concentrent sur les tokens voisins avec une surcharge de calcul moindre.

Cette structure hybride compte à mesure que les entrées s’allongent. L’auto-attention complète compare les positions dans toute la séquence, de sorte que sa charge de calcul augmente rapidement avec la longueur. Les couches convolutionnelles limitent davantage leur travail à des voisinages locaux.

Liquid AI ne supprime pas l’attention. L’entreprise réduit la fréquence à laquelle l’architecture en paie le coût complet. Le modèle peut toujours échanger des informations entre des positions éloignées tout en traitant de nombreuses couches via des opérations locales moins coûteuses.

Pour l’usage en encodeur, Liquid AI a rendu ces opérations locales bidirectionnelles. Le remplissage symétrique permet à une convolution d’intégrer les voisins avant et après le token courant. Les couches d’attention complète reçoivent également un masque bidirectionnel.

Ce mécanisme constitue l’argument central de LFM2.5 vs ModernBERT. Liquid AI parie que le traitement hybride des séquences peut préserver une compréhension compétitive tout en ralentissant la croissance de la latence des entrées longues.

Selon les résultats de la sortie, LFM2.5-Encoder-230M était le modèle testé le plus rapide à chaque longueur de séquence CPU. Son avantage est devenu le plus visible à la limite de 8 192 tokens.

Liquid AI rapporte environ 28 secondes pour le plus petit modèle LFM2.5 à cette longueur. L’entreprise indique que ModernBERT-base a pris plus de 90 secondes, produisant l’avantage annoncé de 3,7 fois.

L’entreprise a observé une tendance plus resserrée sur un GPU Apple. ModernBERT-base aurait été en tête sous environ 1 000 tokens. Les encodeurs de Liquid AI seraient passés devant à partir d’environ 2 000 tokens.

Ce point de croisement illustre le compromis. Des choix d’architecture optimisés pour les entrées longues ne garantissent pas une position de tête sur les entrées courtes. De nombreuses demandes de classification en production restent bien en dessous de 2 000 tokens.

Le nombre de paramètres complique également une simple comparaison de vitesse. ModernBERT-base contient environ 149 millions de paramètres, tandis que le plus petit encodeur de Liquid AI en contient environ 230 millions. Le modèle LFM2.5 est plus grand, mais serait plus rapide sur les longues séquences CPU.

Le benchmark teste donc plus que le nombre de paramètres. Le comportement des kernels, les accès mémoire, la longueur des séquences, la configuration du runtime et les caractéristiques du processeur influencent tous la latence mesurée.

L’encodeur LFM2.5 expliqué par ce mécanisme n’est pas un remplacement universel des modèles fondés sur l’attention. Il affirme que des opérations de séquence mixtes conviennent mieux aux charges de travail CPU à long contexte.

Les développeurs devraient effectuer des benchmarks sur leur distribution réelle d’entrées. Un système dominé par des messages courts pourrait privilégier des choix d’architecture différents de ceux d’un système traitant des accords juridiques ou de longues transcriptions.

Ils devraient également mesurer le temps total du pipeline après le fine-tuning. La tokenisation, le traitement par lots, les têtes de sortie, le post-traitement et le transfert des données peuvent modifier l’avantage observé lors d’un simple passage avant du modèle.

La qualité des benchmarks est compétitive, mais les preuves ont leurs limites

Liquid AI présente un ensemble crédible d’éléments de reproductibilité, mais ses résultats ne tranchent pas la question des performances en production sur les CPU, les runtimes ou les tâches spécialisées.

L’entreprise a évalué 14 modèles sur 17 tâches issues de GLUE, SuperGLUE et de suites de classification multilingue. Chaque modèle a bénéficié d’un fine-tuning supervisé complet pour chaque tâche.

Liquid AI rapporte la moyenne obtenue à partir de cinq seeds aléatoires distinctes. L’utilisation de plusieurs seeds réduit le risque qu’un entraînement exceptionnellement favorable détermine le classement.

Son encodeur de 350M s’est classé quatrième avec une moyenne déclarée de 81,02 sur 17 tâches. Les modèles devant lui étaient XLM-R XL, ModernBERT-large et XLM-R large.

XLM-R XL est arrivé en tête avec 83,06 et compte 3,5 milliards de paramètres. ModernBERT-large a obtenu 81,68 avec 395 millions de paramètres. XLM-R large a atteint 81,34 avec 560 millions de paramètres.

LFM2.5-Encoder-230M s’est classé sixième avec 79,29. ModernBERT-base s’est classé septième avec 78,19. Ces moyennes étayent l’affirmation de Liquid AI selon laquelle ses encodeurs restent compétitifs pour leur taille.

Elles ne démontrent pas une domination constante sur chaque tâche. ModernBERT-base a dépassé le modèle LFM2.5 de 230M sur plusieurs benchmarks individuels, tandis que Liquid AI était en tête sur d’autres.

Le classement agrégé mélange également différents types d’évaluation. Les tâches comprennent l’inférence en langage naturel, la détection de paraphrases, l’analyse des sentiments, la similarité sémantique et la classification multilingue.

Une moyenne aide à comparer les capacités générales, mais elle peut masquer la mesure qui compte pour un déploiement donné. Un système de politiques s’intéresse aux faux négatifs et à la calibration, et non à sa position sur une tâche d’analyse des sentiments sans rapport.

Liquid AI a publié son harness d’évaluation, ce qui améliore les possibilités de réplication. Le dépôt inclut le code de fine-tuning en aval et les configurations associées aux comparaisons rapportées.

Cependant, du code ouvert n’équivaut pas à une confirmation indépendante. Liquid AI a choisi la procédure d’entraînement, le protocole de comparaison, la méthode d’agrégation et l’environnement d’inférence.

L’affirmation relative à la latence sur CPU soulève la principale question non résolue. L’article public décrit les longueurs de séquence et les temps écoulés, mais n’identifie pas clairement la configuration CPU testée.

Cette omission affecte l’interprétation. Les processeurs portables, les CPU de serveurs cloud, les canaux mémoire, les jeux d’instructions, le nombre de threads et les limites de puissance peuvent produire des comportements très différents.

Les instructions de chargement actuelles utilisent également trust_remote_code=True, ce qui autorise l’exécution de code fourni par le dépôt via la bibliothèque Transformers. Les organisations soumises à des contrôles logiciels stricts devront examiner ce code avant le déploiement.

La carte de modèle ne présente pas de voie de déploiement ONNX ou OpenVINO mature. Ces runtimes comptent souvent pour les équipes qui optimisent l’inférence sur CPU, la quantification et le service multiplateforme.

Les performances quantifiées constituent une autre question ouverte. La comparaison publiée n’établit pas le comportement de LFM2.5 après une conversion en précision réduite, ni si le même avantage relatif perdure.

La publication ne fournit pas non plus de preuves en production concernant une concurrence soutenue. Le traitement d’une seule longue séquence mesure la latence, alors qu’un classificateur toujours actif nécessite du débit, une latence de queue, une consommation mémoire et de la stabilité sous charge.

La précision exige la même prudence. Le fine-tuning sur des benchmarks ne démontre pas les performances sur les contrats, règles de sécurité, formulations clients ou catégories de confidentialité d’une organisation.

Une équipe évaluant LFM2.5 face à ModernBERT devrait reproduire les deux modèles sur un matériel identique et avec des réglages optimisés. Elle devrait tester des documents courts, médians et correspondant au pire cas de la charge réelle.

L’évaluation devrait inclure le coût des erreurs. Un détecteur de PII plus rapide a peu de valeur s’il manque des identifiants sensibles que le système actuel détecte. Un modèle de routage doit également éviter d’envoyer des requêtes vers des outils en aval inappropriés.

Ces limites n’invalident pas la publication. Elles définissent la différence entre un résultat architectural prometteur et une décision de déploiement.

Ce que les développeurs Hugging Face devraient surveiller ensuite

Trois signaux détermineront si cette publication devient une norme CPU pratique ou demeure un benchmark fournisseur intéressant.

Le premier signal est la réplication indépendante sur différents matériels. Les développeurs ont besoin de résultats sur Apple silicon, des ordinateurs portables x86 courants et des processeurs serveur, avec un nombre de threads et des configurations mémoire divulgués.

La réplication devrait mesurer davantage que le point final à 8 192 tokens. Les jeux de données réels contiennent des longueurs variées ; la latence par percentile et le nombre de documents traités par heure offrent donc une image opérationnelle plus claire.

Si des tests indépendants préservent un avantage important sur les longs contextes, l’argument architectural de Liquid AI se renforce. Si l’écart se réduit après une optimisation équivalente des runtimes, les choix d’implémentation expliquent probablement davantage le résultat mis en avant.

Le deuxième signal est le support de runtimes optimisés. Des exports ONNX, une intégration OpenVINO, des recettes de quantification stables et le support de bibliothèques natives rendraient les modèles plus faciles à exploiter au-delà des environnements Python expérimentaux.

Ces ajouts permettraient également de vérifier si le backbone hybride s’adapte bien aux chaînes d’outils CPU largement déployées. Un modèle qui dépend d’une exécution eager personnalisée peut rencontrer des frictions d’adoption malgré de bons résultats de benchmark.

Des déploiements réussis en 8 bits ou à plus faible précision renforceraient l’argument en faveur de l’inférence locale. Ils pourraient réduire l’usage mémoire et augmenter le débit tout en maintenant la précision des tâches dans des limites acceptables.

Le résultat inverse affaiblirait la comparaison. ModernBERT et d’autres encodeurs établis bénéficient de parcours d’optimisation matures ; la vitesse brute de l’architecture ne garantit donc pas le meilleur système déployé.

Le troisième signal est l’adoption au niveau des tâches. Les nombres de téléchargements sur Hugging Face offrent un indicateur précoce, mais les fine-tunings publiés et les études de cas reproductibles comptent davantage.

Des preuves utiles incluraient des filtres de politiques mesurés sur des règles organisationnelles, des systèmes PII multilingues testés sur des identifiants réalistes, et des routeurs fonctionnant sous un trafic applicatif soutenu.

Les développeurs devraient rechercher les taux de faux positifs, les taux de faux négatifs, la calibration, l’usage mémoire et la latence de queue. Ces mesures révèlent si le modèle améliore un système plutôt qu’une position dans un classement.

L’exemple de fine-tuning de Liquid AI donne aux équipes un point de départ pour la classification. L’étape suivante consiste à obtenir des preuves auprès d’utilisateurs qui n’ont pas conçu l’architecture.

Les réponses des concurrents fourniront un autre indice au sein de ces signaux. Les implémentations de ModernBERT peuvent gagner des kernels optimisés, tandis que d’autres encodeurs à long contexte peuvent adopter un traitement hybride ou sparse.

Les fournisseurs de modèles génératifs peuvent également répondre avec des endpoints de classification moins coûteux. Toutefois, les services distants restent confrontés aux contraintes de transfert de données, de connectivité et de contrôle local que les encodeurs sur appareil évitent.

Pour les travailleurs du savoir, cette évolution pourrait rendre l’organisation locale des documents plus réactive et plus privée. Les contrats, transcriptions, notes et historiques de support peuvent être classifiés avant que le moindre texte ne quitte un environnement contrôlé.

Pour les acheteurs en entreprise, cette publication crée une question d’approvisionnement plus précise. Chaque tâche linguistique nécessite-t-elle un raisonnement génératif, ou un encodeur spécialisé peut-il fournir la décision requise avec une demande d’infrastructure moindre ?

Pour les développeurs, la bonne réponse est la mesure. Constituez un jeu de tests représentatif, définissez des seuils de précision, enregistrez la distribution des longueurs d’entrée et comparez des pipelines complets sur le matériel de déploiement.

Hugging Face rend cette expérimentation accessible, car les deux variantes LFM2.5 et leurs ressources associées sont disponibles au même endroit. L’accessibilité ne doit toutefois pas remplacer la validation.

Liquid AI a proposé une thèse technique claire : la compréhension de longs contextes peut rester sur CPU lorsqu’une architecture limite le travail répété d’attention complète. Ses benchmarks apportent un soutien initial crédible à cette thèse.

La question non résolue est de savoir si des déploiements indépendants reproduisent l’avantage après que chaque modèle a reçu une optimisation équivalente. Cette question devrait guider la prochaine vague de tests, de fine-tunings et de rapports de production.

Si votre équipe traite continuellement de longs documents, comparez LFM2.5 à l’encodeur qui sert déjà votre charge de travail. Utilisez des documents réels, du matériel divulgué et des mesures d’erreur propres à la tâche.

Le résultat le plus important ne sera pas un nouveau score moyen de benchmark. Ce sera la preuve qu’un petit encodeur peut examiner l’ensemble du contexte de travail, satisfaire aux exigences de précision et fonctionner de manière prévisible là où les données résident.