Contexte technique
Aujourd'hui, j'ai examiné de près les premiers retours d'expérience sur le terrain concernant le LFM2.5-8B-A1B, et la situation est claire : le modèle est rapide et dynamique pour sa taille, mais en raisonnement (reasoning), il a encore tendance à se bloquer dans des boucles. Pour des tâches où je mets en place de l'AI automation et du structured output, ce n'est pas un détail, mais une condition essentielle pour une utilisation en production.
Officiellement, Liquid AI recommande un préréglage prudent : temperature 0.2, top_k 80, repetition_penalty 1.05. Leur logique est bonne, car le modèle a été spécifiquement entraîné pour contrer les « doom loops ». Cependant, la communauté montre déjà que dans des environnements d'exécution réels sur divers stacks, cette configuration n'est pas toujours optimale.
Ce qui a attiré mon attention : les utilisateurs qui déploient du BF16 et du GGUF juste après la sortie s'accordent sur un symptôme. Si le chemin de raisonnement démarre mal, le modèle commence à répéter la même étape en boucle. Pas des balises « think », pas des données aléatoires, mais bien un processus interne qui tourne en boucle.
Le préréglage alternatif le plus intéressant actuellement est le suivant : context 8192, reasoning on, reasoning-format deepseek, reasoning-budget 4096, temp 0, top-k 80, repeat-penalty 1.03, repeat-last-n 64. Sur ce point, je ne ferais pas de débats théoriques ; je testerais simplement sur mes propres tâches, car la différence entre 1.03 et 1.05 avec ce type de modèles est parfois beaucoup plus marquée qu'il n'y paraît sur le papier.
Autre conclusion pratique : les versions quantifiées proposées par les développeurs semblent pour l'instant moins performantes que la version complète. Si je dois déboguer le comportement du modèle, je prendrais le BF16 comme référence avant de chercher à réduire l'empreinte mémoire. Sinon, vous risquez de passer beaucoup de temps à corriger des artefacts de quantification plutôt que le modèle lui-même.
Impact sur l'entreprise et l'automatisation
Si vous construisez un pipeline avec de l'utilisation d'outils (tool use), des formats de réponse et un routage d'agents, temp 0 n'est pas une option ennuyeuse, mais une décision pragmatique. Augmentez légèrement la température, et le format de sortie commence à dériver. Pour l'automatisation, cela nuit immédiatement à la fiabilité.
Les gagnants sont ceux qui ont besoin d'un modèle de raisonnement compact et rapide pour une inférence locale ou peu coûteuse. Les perdants sont ceux qui espéraient simplement utiliser le préréglage officiel pour obtenir un résultat infaillible en production sans réglages fins.
Je considérerais le LFM2.5-8B-A1B comme une base intéressante pour l'AI integration, mais pas comme un modèle à déployer sur des systèmes critiques sans garde-fous. Des limites de longueur, des séquences d'arrêt et une validation stricte du format de sortie sont indispensables. Chez Nahornyi AI Lab, nous concevons précisément ce type de systèmes robustes pour nos clients : nous ne nous contentons pas de choisir un modèle, nous menons l'AI solution development jusqu'à un niveau d'efficacité qui fait gagner du temps sans générer d'alertes en pleine nuit.
Si vous rencontrez un problème similaire et que votre modèle consomme déjà des jetons en boucle au lieu de produire de la valeur, nous pouvons analyser rapidement votre stack pour configurer un preset fiable. Chez Nahornyi AI Lab, c'est généralement par là que je commence : éliminer l'instabilité, puis bâtir l'AI automation autour d'un processus qui fonctionne réellement.