LFM2.5-24B-A2B : un modèle de raisonnement de 24B conçu pour dépenser comme un 2B par morceau de mot

La taille inscrite dans le nom d'un modèle dit mal à quelle vitesse il va vous répondre. LFM2.5-24B-A2B, le modèle publié par Liquid AI le 13 octobre, compte 24 milliards de paramètres (les nombres qui composent un modèle, une mesure grossière de sa taille). C'est le 24B du nom. Le A2B signifie qu'environ 2 milliards de paramètres sont actifs pour chaque morceau de mot qu'il écrit, à peu près un sur dix (2,45B d'après la fiche du modèle). Un morceau de mot, ou token, est l'unité qu'un modèle lit et écrit, environ les trois quarts d'un mot. Liquid l'a conçu pour les agents : des programmes qui raisonnent, appellent des outils et tournent sur votre propre matériel. Liquid a aussi publié une copie compressée officielle, un fichier de 24,8 GB, qui sur le papier tient sur une seule carte graphique de 48 GB avec beaucoup de place en trop.

Deux choses avant tout le reste. D'abord, la licence : vous pouvez utiliser ce modèle commercialement et gratuitement seulement tant que votre entreprise, en comptant les sociétés qu'elle possède ou qui la possèdent, fait moins de 10 millions de dollars américains de chiffre d'affaires par an. Au-dessus de cette ligne, l'usage commercial n'est pas couvert. Ensuite, nous avions prévu de mesurer sa vitesse sur un GPU loué et le test n'a jamais tourné, donc tous les chiffres de vitesse de cet article sont ceux de Liquid. Tout ce qui figure dans le tableau ci-dessous est vérifié dans les fichiers de Liquid.

Question	Réponse	D'où ça vient
Taille du modèle complet	24,0B paramètres	fiche du modèle de Liquid
Utilisés pour chaque morceau de mot écrit	2,45B paramètres	fiche du modèle de Liquid
Fichier compressé officiel	24,8 GB	Hugging Face (où Liquid publie les fichiers), en additionnant la taille des fichiers
Fichier en taille réelle	environ 48 GB	Hugging Face (où Liquid publie les fichiers), en additionnant la taille des fichiers
Conversation la plus longue acceptée	131 072 morceaux de mot	fichier de configuration
Tient sur une carte de 48 GB ?	Devrait, avec de la place pour de longues conversations	notre calcul, pas une mesure
Gratuit pour un usage commercial ?	Seulement sous 10M USD de chiffre d'affaires annuel, sociétés liées comprises	la licence
Nos propres chiffres de vitesse	Aucun, le test n'a pas tourné	notre rapport de test de déploiement

Une équipe de 64 spécialistes

L'astuce derrière le A2B porte un nom technique, mixture of experts (mélange d'experts), et repose sur une idée simple. Un modèle traite chaque morceau de mot en une série d'étapes, l'une après l'autre. Imaginez la plupart de ces étapes comme une salle avec 64 spécialistes. Quand un morceau de mot arrive, un petit aiguilleur à l'entrée en choisit 4 pour s'en occuper et les 60 autres restent au fond. Tous les spécialistes doivent être dans le bâtiment, c'est pour cela que le fichier est gros. Mais seuls les 4 de service travaillent, c'est pour cela que chaque morceau de mot coûte peu.

Un mélange d'experts paie donc la mémoire comme un gros modèle et le travail comme un petit. C'est tout le pari de LFM2.5-24B-A2B : la capacité d'un modèle de 24B, l'effort par morceau de mot d'un 2B. La fiche du modèle ajoute deux détails qui comptent pour un agent. Il réfléchit toujours avant de répondre, contrairement à son prédécesseur LFM2-24B-A2B. Et quand il a besoin d'un outil, il le demande dans un format fixe et facile à repérer, pour que le programme qui l'entoure puisse lancer l'outil de façon fiable et lui rendre le résultat.

Les étapes ne sont pas toutes du type habituel non plus. Sur ses 40 étapes, seules 10 relisent tout ce qui a été dit jusque-là, et c'est ce qui rend les longues conversations coûteuses. Les 30 autres ne regardent que les derniers morceaux de mot. Ce détail reviendra quand nous parlerons de mémoire.

Liquid dit aussi clairement à quoi il ne sert pas. Seul, il ne faut pas lui faire confiance pour connaître des faits : associez-le à une recherche web ou à une recherche dans vos propres documents. C'est rafraîchissant de trouver cette phrase sur une fiche de modèle.

Ce qu'il fait bien, d'après les chiffres de Liquid

La réponse d'abord : sur les propres tests de Liquid, il est le plus fort sur les workflows d'agents, l'utilisation d'outils et le suivi d'instructions. Il est derrière Qwen pour corriger du vrai code, où il a résolu 51 tâches de test sur 100 contre 66 pour Qwen (51,00 contre 66,20). Il est aussi derrière sur les questions scientifiques difficiles, où il en a réussi environ 74 sur 100 contre 84 pour Qwen (74,42 contre 83,69), et sur la navigation web.

Liquid le compare à trois modèles ouverts similaires : Qwen d'Alibaba, Gemma de Google et Nemotron de NVIDIA. Les trois rivaux sont eux aussi des équipes de spécialistes, avec une plus grande part de leurs paramètres au travail pour chaque morceau de mot. Liquid ne publie aucune comparaison avec un modèle classique, où chaque paramètre travaille sur chaque morceau de mot. Savoir s'il bat un modèle classique d'environ 24B sur la même carte, en vitesse ou en qualité, c'est donc exactement ce que ni Liquid ni nous ne pouvons encore vous dire.

Une sélection tirée de la fiche du modèle, tous les tests lancés par Liquid :

Test	LFM2.5-24B-A2B	Qwen3.6-35B-A3B	Gemma-4-26B-A4B-it	Nemotron-3.5-Lightning
AutomationBench (workflows d'agents)	27,69	8,72	5,46	2,61
LiveClaw (tâches d'agents)	48,09	38,19	41,25	37,72
ToolSandbox (utilisation d'outils)	80,71	75,02	72,09	75,13
BFCLv4 (appels d'outils)	65,01	65,00	57,09	53,78
PinchBench (tâches d'agents)	83,18	89,93	77,12	84,20
WebArena Verified (navigation web)	26,75	37,62	25,62	28,69
IFBench (suivi d'instructions)	74,69	64,21	47,44	71,67
SWE-Bench Verified (corriger du vrai code)	51,00	66,20	25,80	53,40
GPQA Diamond (questions scientifiques difficiles)	74,42	83,69	74,90	72,42

Ce sont les chiffres du fabricant, avec la configuration du fabricant. Sur les appels d'outils (BFCLv4), c'est une égalité avec Qwen, 65,01 contre 65,00. Des écarts aussi grands que 27,69 contre 2,61 sur AutomationBench sont exactement ce qu'un test indépendant devrait vérifier en premier.

Liquid annonce 184 morceaux de mot par seconde sur une puce Apple haut de gamme pour portable (M5 Max), et 114 sur un AMD Ryzen AI Max+ 395. En comptant une page à environ 650 morceaux de mot, notre calcul donne une page de texte toutes les trois ou quatre secondes sur la puce Apple. Mais ce modèle réfléchit toujours avant de répondre, et ce raisonnement caché passe en premier : ces morceaux de mot comptent dans le chiffre de vitesse et dans l'attente avant le premier mot de la réponse, donc la réponse visible arrive plus lentement que ces chiffres ne le laissent penser. Et c'est avec une copie encore plus petite du modèle, que Liquid a faite pour les portables. D'après Liquid, il est jusqu'à 1,7 fois plus rapide que le meilleur des autres modèles essayés. Sur une carte de data center haut de gamme (une NVIDIA B300) qui répond à beaucoup de monde à la fois, Liquid annonce plus de 21 000 morceaux de mot par seconde, additionnés sur tous les utilisateurs. Une seule personne n'en voit qu'une petite part.

Pourquoi une carte de 48 GB devrait suffire, sur le papier

Sur le papier, oui : le modèle compressé occupe environ la moitié d'une carte de 48 GB, et même une conversation de longueur maximale ne demande qu'environ 2,7 GB de plus.

La copie compressée officielle stocke la plupart des nombres du modèle avec deux fois moins de précision, ce qui divise le fichier par deux : 24,8 GB contre environ 48 GB pour la version en taille réelle. Liquid recommande cette copie pour servir beaucoup de requêtes sur GPU, avec moins de mémoire.

Tout ce paragraphe est notre calcul à partir du fichier de configuration, pas une mesure. Le fichier laisse environ 23 GB libres sur la carte. Le programme qui fait tourner le modèle en prend une partie pour lui-même, et nous n'avons pas mesuré combien. Le reste contient la mémoire de chaque conversation, ce qui a été dit, et c'est là que la conception 10 sur 40 aide beaucoup. Une conversation à la longueur maximale de 131 072 morceaux de mot a besoin d'environ 2,7 GB de cette mémoire. Un modèle dont les 40 étapes relisent tout en demanderait quatre fois plus. Une seule carte devrait donc avoir de la place pour le modèle et plusieurs longues conversations à la fois.

Une limite honnête à l'idée du "2B par morceau de mot", et c'est notre raisonnement, pas une mesure. L'économie est la plus nette quand une seule personne parle au modèle. Quand beaucoup de gens l'utilisent en même temps, leurs morceaux de mot choisissent chacun des spécialistes différents, et vite la plupart des 64 sont occupés. Aller chercher chaque spécialiste occupé dans la mémoire de la carte prend du temps, donc avec beaucoup d'utilisateurs le modèle se comporte de plus en plus comme un 24B classique et son avantage de vitesse se réduit. C'est aussi pour cela que le chiffre de 21 000 de Liquid ne dit rien de la vitesse à laquelle une personne obtient sa réponse.

La licence, en clair

Le modèle est distribué sous la LFM Open License v1.0, et la clause qui compte est courte :

La licence fixe un seuil de 10 000 000 de dollars américains de chiffre d'affaires annuel.
L'usage commercial n'est autorisé que tant que vous, ou votre "Legal Entity" (entité juridique), restez en dessous.
La "Legal Entity" comprend toute société qui vous contrôle, que vous contrôlez ou qui est sous contrôle commun avec vous.
La "Commercial Use" (usage commercial) est large : tout usage "for direct or indirect commercial advantage or monetary compensation" (pour un avantage commercial direct ou indirect ou une compensation monétaire). Un outil interne qui fait gagner du temps à votre équipe peut compter.
Au-dessus du seuil, l'usage commercial "is not licensed under this Agreement" (n'est pas couvert par cet accord). L'usage non commercial et la recherche par un organisme à but non lucratif éligible sont exemptés du seuil.
Enfreindre les conditions met fin automatiquement à la licence.

Ça fonctionne comme un bar qui laisse jouer gratuitement les groupes du coin. Un groupe signé chez une grosse maison de disques est mesuré à la taille du label, pas aux quatre personnes sur scène. Au-dessus de la ligne, cette licence ne couvre pas le concert. Notre lecture est qu'il faudrait alors un accord séparé avec Liquid, mais la licence elle-même ne le précise pas. Si vous partagez les fichiers du modèle avec d'autres, vous joignez la licence, signalez vos modifications et gardez les mentions. Si votre entreprise est proche de la ligne, ou fait partie d'un groupe, c'est une conversation pour votre avocat, pas pour un article de blog.

Nous avons repéré le modèle dans la revue d'actualité d'AI Search du 18 octobre (chapitre à 37:47). Deux détails y méritent une correction. Le présentateur dit que la licence est "mostly Apache 2.0" (surtout Apache 2.0, une licence courante sans limite de chiffre d'affaires), et ce n'est pas le cas. Les "48 gigabytes" qu'il mentionne correspondent à la copie en taille réelle. La copie compressée fait environ la moitié.

Ce que nous avions prévu de mesurer

Nous n'avons encore aucun chiffre de vitesse, parce qu'aucun GPU n'a jamais été loué. Voici le plan que nous aurions suivi, en étapes simples (les commandes exactes sont dans la section pour les ingénieurs), et la permission réseau qui l'a arrêté.

Le GPU. Une carte graphique de 48 GB, du genre qu'on loue à l'heure, avec une carte récente en premier choix et une plus ancienne et plus lente en dernier recours. Nous n'avons vérifié sur aucune d'elles que la copie compressée se charge.

Le logiciel et pourquoi. vLLM, le programme que notre plateforme utilise pour faire tourner les modèles. Il connaît déjà la conception de ce modèle, donc il sait séparer le raisonnement du modèle de sa réponse finale et repérer ses demandes d'outils sans code supplémentaire. Ce modèle a besoin d'un vLLM plus récent que celui que nous installons par défaut, donc le plan était de demander une version plus récente juste pour ce modèle.

Les étapes. Dire à la plateforme quel modèle et quelle version faire tourner, la laisser louer la carte, puis poser au modèle quelques types de questions : une sur du code, une en espagnol, une qui demande un outil, une qui cache un fait au fond d'un texte très long, et plusieurs personnes qui demandent en même temps. Il n'y a pas d'exemple de code à lier, parce que le brouillon n'a jamais tourné et n'a jamais été publié.

Ce qui a mal tourné. L'assistant IA qui pilote notre test a un contrôle de sécurité, et il a refusé d'ouvrir la connexion réseau dont un GPU loué a besoin pour recevoir les questions de notre plateforme. Nous avons choisi de ne pas le contourner, donc aucun GPU n'a été loué.

À chacun son mérite

Liquid AI a entraîné le modèle sur 36 000 milliards de morceaux de mot, puis l'a affiné en le faisant travailler dans de vrais outils d'agents (OpenClaw, Hermes Agent, Pi et OpenCode). Liquid l'a publié en plusieurs versions, de la copie compressée pour les cartes de data center à des versions plus petites pour les portables, avec un support dès le premier jour dans les principaux programmes open source qui font tourner des modèles. Le projet vLLM sait déjà comment ce modèle est construit et publie une recette avec les réglages pour le faire tourner. AI Search nous l'a mis sous les yeux. Notre part cette fois est modeste : lire les fichiers, vérifier les tailles, faire le calcul de mémoire et écrire le plan de test.

Ce que deux milliards de paramètres de service achètent en secondes, sur une carte louée, reste une question ouverte. Le script qui y répondra s'appelle bench.py.

Pour les ingénieurs

Checkpoint. LiquidAI/LFM2.5-24B-A2B-FP8, sha f54bf39547fd5b7955abb9fe8d1b151e31fbbddb, créé le 2026-10-12T22:19:54Z, modifié pour la dernière fois le 2026-10-13T06:11:42Z, non gated, license_name: lfm1.0. 10 shards safetensors (de 1 857 173 880 à 2 660 477 032 octets), total du repo 24 766 905 221 octets (environ 23,1 GiB). Paramètres safetensors : 23 200 792 576 F8_E4M3 + 770 792 704 BF16 + 2 432 F32 = 23 971 587 712. Repo BF16 LiquidAI/LFM2.5-24B-A2B : 47 964 602 405 octets, sha 1769516a. Variantes publiées : Base, post-trained, FP8, GGUF, ONNX, MLX-4bit. Un modèle draft DSpark pour le speculative decoding de SGLang est annoncé comme "Coming soon".

Architecture (config.json) : Lfm2MoeForCausalLM, model_type: lfm2_moe. 40 couches : 30 blocs de convolution courte à double porte et 10 couches d'attention GQA. 64 experts par bloc MoE, routage top-4, moe_intermediate_size 1536, 2 couches denses. Hidden 2048, 32 têtes d'attention, 8 têtes KV, vocabulaire de 128 000, max_position_embeddings 131 072, rope_theta 1e7, embeddings liés. Fiche : 24,0B au total, 2,45B actifs. Le chat template insère <think> au début du tour de l'assistant (raisonnement toujours actif).

Paramètres actifs sous charge. Les 2,45B actifs s'entendent par token. Avec des requêtes en batch, des tokens différents sont routés vers des ensembles top-4 différents, donc l'union des experts lus à chaque étape de décodage grandit avec la taille du batch et l'avantage en bande passante mémoire sur un modèle dense se réduit. Le chiffre B300 plus bas est un débit agrégé, pas une vitesse de décodage par utilisateur.

Quantification. compressed-tensors FP8_BLOCK : poids FP8 statiques en blocs de 128x128, activations FP8 dynamiques par groupe de 128. Non quantifiés : lm_head, model.embed_tokens, portes du routeur MoE, poids de convolution. Lancement SGLang sur la fiche FP8 : python -m sglang.launch_server --model-path LiquidAI/LFM2.5-24B-A2B-FP8 (aucune version de SGLang indiquée).

KV cache, par calcul (non mesuré). Seules les 10 couches d'attention gardent du KV : 10 x 8 têtes KV x 64 head_dim x 2 (K et V) x 2 octets = 20 KiB par token, environ 2,5 GiB pour une séquence complète de 131 072 tokens. head_dim 64 est supposé égal à 2048 / 32. La config n'a pas de head_dim explicite. Les couches de convolution gardent un petit état fixe par séquence (conv_L_cache 3).

Entraînement (fiche et blog) : budget de 36T tokens. Pré-entraînement d'environ 33T (contre environ 17T pour LFM2-24B-A2B). Mid-training de 2T tokens à 32K, puis 300B tokens à 131K. Le contexte est passé de 32K à 131K et le vocabulaire de 65K à 128K par extension du tokenizer en place. Post-entraînement : SFT, spécialisation de professeurs, deux étapes de distillation on-policy (non agentique et agentique), RL agentique dans OpenClaw, Hermes Agent, Pi et OpenCode.

Outils et échantillonnage. Les appels d'outils sont des listes Pythonic entre <|tool_call_start|> et <|tool_call_end|>. Échantillonnage recommandé, aussi présent dans generation_config.json (donc vLLM l'applique par défaut) : temperature 0,1, top_k 50, repetition_penalty 1,05.

Servir avec vLLM. Docs vLLM de Liquid : les architectures LFM2.5 sont livrées dans vLLM 0.23.0 et versions suivantes. Laissez max_tokens non défini sauf si vous voulez limiter la sortie, car une limite basse coupe les modèles de raisonnement au milieu de leur réflexion. Passez top_k, min_p et repetition_penalty via extra_body. La recette vLLM pour LFM2.5 : support natif de Lfm2MoeForCausalLM (pas de --trust-remote-code), min_vllm_version 0.23.0, --reasoning-parser qwen3, --enable-auto-tool-choice --tool-call-parser lfm2. Le texte de la recette cite le 8B-A1B comme exemple MoE et ne nomme pas le 24B-A2B. Nos informations sur les docs viennent d'une copie de la page de Liquid sauvegardée le 2026-10-19 (la récupération en direct a été bloquée).

Commande prévue, jamais lancée :

vllm serve LiquidAI/LFM2.5-24B-A2B-FP8 \
  --max-model-len 131072 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser lfm2

avec le vllm_version du workload fixé à 0.31.0. Cette version exige torch 2.13.0 compilé pour CUDA 13, donc le plan limitait les pods aux hôtes CUDA 13.x. La valeur par défaut du worker InferenceKey est DEFAULT_VLLM_VERSION = "0.20.0", modifiable par workload avec vllm_version, que le worker passe à pip install vllm==<version>.

GPU prévu. L40S 48 GB en premier, RTX 6000 Ada 48 GB en solution de repli, A40 48 GB en dernier recours (Ampere, FP8 via Marlin, plus lent). Disque du conteneur de 80 GB. Aucun pod n'a été créé.

Chiffres de vitesse du fabricant. 184 tok/s en décodage sur Apple M5 Max et 114 tok/s sur AMD Ryzen AI Max+ 395 (llama.cpp, Q4_K_M, entrée de 4K tokens, infrastructure Pipette de Liquid). Plus de 21K tok/s de sortie sur une NVIDIA B300 à forte concurrence (SGLang 0.5.22, 1 024 tokens d'entrée, jusqu'à 256 tokens de sortie, poids BF16, total des tokens de sortie sur le temps réel écoulé).

Tableau complet des benchmarks du fabricant (LFM2.5-24B-A2B / Qwen3.6-35B-A3B / Gemma-4-26B-A4B-it / Nemotron-3.5-Lightning 30B-A3B) : AutomationBench 27,69 / 8,72 / 5,46 / 2,61. BFCLv4 65,01 / 65,00 / 57,09 / 53,78. ToolSandbox 80,71 / 75,02 / 72,09 / 75,13. LiveClaw 48,09 / 38,19 / 41,25 / 37,72. PinchBench 83,18 / 89,93 / 77,12 / 84,20. tau3-Bench Banking 8,04 / 7,63 / 4,54 / 7,01. WebArena Verified 26,75 / 37,62 / 25,62 / 28,69. GPQA Diamond 74,42 / 83,69 / 74,90 / 72,42. AA-Omniscience -24,90 / -24,35 / -59,39 / -3,58. HLE 7,40 / 7,69 / 8,57 / 5,65. IFEval 96,75 / 93,06 / 92,00 / 94,19. IFBench 74,69 / 64,21 / 47,44 / 71,67. Multi-IF 84,38 / 81,53 / 82,19 / 82,34. MATH-500 96,04 / 96,73 / 95,66 / 96,40. SWE-Bench Verified (OpenCode) 51,00 / 66,20 / 25,80 / 53,40. SciCode 32,71 / 37,35 / 35,42 / 27,78. Tous évalués avec vLLM. Aucune comparaison avec un modèle dense n'est publiée.

Tarifs de l'API de Liquid (blog) : 0,10 USD par million de tokens d'entrée, 0,05 USD par million de tokens d'entrée en cache, 1,00 USD par million de tokens de sortie. Support dès le premier jour pour llama.cpp (GGUF), MLX, vLLM, SGLang et ONNX.

Ce qui a bloqué le test. Une permission réseau de notre côté a refusé la connexion dont un GPU loué a besoin pour recevoir des jobs de notre plateforme, avant qu'aucun GPU ne soit loué. Aucun contournement n'a été tenté, il n'y a donc aucun chiffre.

Préparé, jamais lancé. bench.py : raisonnement en streaming, cas de code et d'espagnol, un aller-retour d'appel d'outil, tests de l'aiguille à 8K, 32K et 100K, et 4 et 8 requêtes en parallèle.

Limites.

Aucune mesure InferenceKey d'aucune sorte pour ce modèle : pas de tokens/s, de temps jusqu'au premier token, de VRAM, de qualité ni d'exemples.
Non testé : si le checkpoint FP8 se charge et tourne sur vLLM 0.23+ ou 0.31.0 sur une carte Ada de 48 GB, ou sur une A40 via Marlin.
Le chiffre de KV est un calcul avec un head_dim supposé. Le chiffre de mémoire libre est la taille de la carte moins les poids seulement : la réservation de vLLM, le contexte CUDA et la mémoire des activations n'ont été ni estimés ni mesurés.
L'économie des "2B actifs" s'entend par token. Elle ne promet pas de vitesse par utilisateur sous charge concurrente.
Aucune version de SGLang n'est documentée pour le checkpoint FP8.
Tous les benchmarks et chiffres de vitesse sont ceux de Liquid, avec des comparaisons uniquement contre d'autres modèles MoE.
La lecture de la licence ci-dessus est la nôtre, pas un avis juridique. La licence n'a pas de clause de droit applicable.

Sources : fiche du modèle, fiche FP8, licence, blog de Liquid, docs vLLM de Liquid, revue d'AI Search.