LFM2.5-24B-A2B-DSpark est en ligne sur Hugging Face — Liquid AI ne l'a tout simplement pas encore annoncé

La fiche modèle du plus grand modèle de Liquid AI indique toujours que son modèle de rédaction pour le décodage spéculatif est bientôt disponible. Le modèle de rédaction n'arrive pas. LFM2.5-24B-A2B-DSpark dispose d'un dépôt public depuis le 19 octobre 2026, d'un checkpoint BF16 de 655 Mo, d'un tableau de benchmarks complet, d'un sidecar GGUF publié le soir suivant et d'indicateurs de lancement pour SGLang inscrits dans sa fiche. Ce qui lui manque, c'est une annonce. LFM2.5-24B-A2B, le modèle à mélange d'experts de 24B qu'il a pour but d'accélérer, a eu droit à un article de blog, à un lancement daté, à une liste de prix et à un lien vers un playground le 13 octobre 2026. Son modèle de rédaction a eu droit à un dépôt et à une fiche modèle, et la page de documentation de Liquid AI elle-même consacrée au décodage spéculatif ne liste encore que les cibles 1.2B, 2.6B, 8B et VL-3B comme prises en charge. Les défaillances de l'IA et les incidents d'agents documentés qui sous-tendent des versions comme celle-ci sont recueillis dans l'OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, un niveau de gravité, une note de confiance et un indicateur de contestation.

Cet écart est le cœur du sujet, et il vaut la peine d’être précis sur ce qu’il signifie et ne signifie pas. Un dépôt dont les poids sont ouverts, dont les benchmarks sont reproductibles à partir d’un fichier CSV placé à côté du modèle, et dont le chemin d’inférence est déjà fusionné en amont constitue une véritable publication, pas une fuite. Mais rien à son sujet n’a été confirmé par écrit par le fournisseur, aucun tiers ne l’a mesuré, et les chiffres de la fiche sont ceux de la même équipe, mesurés sur le même matériel qu’elle a choisi. Cet article sépare les deux : ce que le dépôt établit, et ce qui reste une affirmation.

Qu'y a-t-il réellement dans le dépôt ?

Le point de contrôle est assez petit pour que la liste des fichiers elle-même soit instructive. L'ensemble tient dans un model.safetensors de 655 421 522 octets — 327,7 M de paramètres en BF16 —, plus une configuration, une licence et un répertoire de benchmarks. Rien d'autre. Il n'y a ni tokenizer, ni matrice d'embedding, ni tête LM, car l'architecture réutilise les trois à partir du modèle cible au moment du chargement. C'est le principe même : le drafter n'a jamais besoin de savoir autre chose que deviner le bloc de tokens suivant dans le vocabulaire de la cible, et non comment représenter le monde.

La configuration confirme la structure décrite dans l'article DSpark d'août. Cinq couches d'attention complète avec une dimension cachée de 2 048 et une dimension intermédiaire de 6 144, avec SiLU/SwiGLU ; une attention à requêtes groupées avec 32 têtes et 8 têtes KV pour une dimension de tête de 64 ; une tête Markov de rang 256 et une tête de confiance distincte ; une taille de bloc de 9 ; un vocabulaire de 128 000 ; et un embedding de position maximal de 131 072, ce qui correspond exactement à la fenêtre de contexte de la cible. Le seul champ propre à ce drafter est target_layer_ids: [2, 10, 18, 26, 34] face à num_target_layers: 40 — les cinq couches du modèle 24B dont les états cachés sont lus par le drafter comme contexte. Ces indices expliquent pourquoi un drafter entraîné pour un modèle LFM2.5 ne peut pas simplement être pointé vers un autre.

La licence est lfm1.0, la même licence personnalisée que le reste de la famille, ce qu'il convient de noter pour quiconque prévoit de redistribuer un artefact groupé cible-plus-draft plutôt que de l'utiliser en interne.

Le tableau de benchmark, à lire comme un tableau de fournisseur

La fiche publie le débit pour huit jeux de données à une concurrence de 1, 32 et 256, sur un seul NVIDIA B300 avec la cible FP8, un cache KV en BF16 et une température de 0. Chaque chiffre ci-dessous est une donnée de Liquid AI et n'a pas été reproduit en dehors de l'entreprise ; les lignes brutes se trouvent dans le benchmarks/b300-fp8.csv du dépôt si vous souhaitez vérifier les calculs vous-même.

• Moyenne arithmétique sur les huit jeux de données — 2,38× à une concurrence de 1, 2,69× à une concurrence de 32, 1,71× à une concurrence de 256.

Meilleure cellule individuelle — MBPP à une concurrence de 32, 3,28×, avec MATH-500 juste derrière à 3,04×.

• Pire cellule unique — LiveCodeBench à une concurrence de 256, 1,34×, et AIME à 256, 1,36×.

Jetons acceptés par étape — 5,16 en moyenne, contre un plafond de 10 fixé par la taille du bloc plus le jeton bonus de la cible.

• Taux d’acceptation le plus élevé — MBPP à 6,70 jetons par étape ; le plus faible — LiveCodeBench à 4,02.

Deux choses à propos de ce tableau sont plus intéressantes que le titre. La première est que l’accélération moyenne est plus élevée à une concurrence de 32 qu’à une concurrence de 1 — 2,69× contre 2,38× — ce qui est l’inverse du récit habituel du décodage spéculatif, où le traitement par lots absorbe le bénéfice. La seconde est qu’elle s’effondre à 256. À 256 requêtes simultanées, le modèle cible seul génère déjà environ 15 000 tokens par seconde sur ce GPU pour MATH-500, et la contribution du modèle brouillon tombe à 1,79×. Une équipe de serving qui ne lit que « 2,4× » dimensionnerait mal un cluster ; le chiffre qui compte pour un point de terminaison par lots est 1,71×, et même celui-ci est une valeur B300 avec un profil de concurrence que la plupart des déploiements ne reproduiront pas.

La phrase qui a changé depuis août

Lorsque Liquid AI a publié les drafters DSpark pour les modèles cibles 1,2B, 2,6B et 8B-A1B le 20/08/2026, son article de blog a avancé une affirmation forte : comme le modèle cible vérifie chaque token proposé et remplace les rejets par son propre choix, « la séquence émise est donc identique à celle du décodage glouton de référence par construction ». La fiche modèle du drafter 8B en reprend l’esprit, promettant « exactement les mêmes sorties ».

La fiche du modèle proposeur 24B ne dit pas cela. Elle indique que le modèle cible vérifie chaque token proposé, puis : « Des différences en virgule flottante entre la vérification par lots et le décodage simple peuvent produire un texte différent, y compris en échantillonnage glouton. » Elle ajoute que les mesures évaluent les performances, et non l’exactitude sur la tâche.

Il s’agit d’une formulation plus prudente, et c’est la bonne. La vérification par lots n’effectue pas les mêmes opérations en virgule flottante dans le même ordre que le décodage séquentiel, de sorte que l’identité bit à bit est une hypothèse qui tient en arithmétique exacte, mais pas toujours sur du matériel réel. Le fait que la carte plus récente l’indique alors que l’ancienne ne le faisait pas relève soit d’une correction de la documentation, soit d’une découverte faite lors de l’entraînement de ce drafter — le dépôt ne vous dit pas de quel cas il s’agit, et Liquid n’a publié aucune explication. Concrètement, la portée est étroite mais réelle : si votre suite de régression compare les sorties du modèle octet par octet, l’ajout de ce drafter peut la faire échouer, et il s’agit d’une propriété de l’arithmétique plutôt que d’un bug dans le draft.

Pourquoi le rédacteur est arrivé six jours après son propre modèle

Il vaut la peine de présenter la chronologie, car elle explique le silence mieux que toute spéculation sur la stratégie.

• 2026-08-20 — Liquid publie la famille DSpark : des drafteurs pour LFM2.5-1.2B-Instruct, LFM2.5-2.6B et LFM2.5-8B-A1B. Aucune cible 24B n’existe encore.

• 2026-08-31 — SGLang fusionne la PR #31041, ajoutant la prise en charge du décodage spéculatif DSpark pour LFM2 et LFM2-MoE. Le chemin MoE dont le 24B a besoin arrive ici, un mois et demi avant le modèle qu’il servira.

• 2026-10-13 — LFM2.5-24B-A2B est publié avec un article de blog et un prix. Le même jour, SGLang fusionne la PR #43939, qui permet au serveur de réutiliser directement la configuration Hugging Face LFM2-MoE.

• 2026-10-19 — le dépôt LFM2.5-24B-A2B-DSpark apparaît, avec les poids et les benchmarks.

• 2026-10-20 — le sidecar GGUF arrive : un unique fichier F16 de 664 Mo pour llama.cpp.

• 2026-10-21 — la fiche du modèle cible comporte désormais une ligne « drafter ». Elle affiche toujours Bientôt disponible.

Lisez cette séquence, et l’explication la plus probable est la plus banale. L’infrastructure a été déployée avant l’artefact ; l’artefact a été publié lorsque l’entraînement s’est terminé ; l’annonce est une tâche marketing qui n’a pas encore eu lieu. Rien dans le dépôt ne suggère un lancement délibérément discret — la fiche est complète, les benchmarks sont documentés jusque dans le protocole, et les appels à SGLang et llama.cpp sont indiqués en intégralité. Ici, discret signifie non annoncé, et non caché.

Ce qui n’est pas encore connaissable

La limite honnête de ce texte est une courte liste, et chaque élément est une véritable lacune plutôt qu’une formalité.

Aucune mesure indépendante. Il n’existe aucune entrée Artificial Analysis, aucune exécution d’acceptation par un tiers, aucune reproduction du tableau de débits. Au 2026-10-21, le dépôt affichait sept téléchargements et un like. Chaque accélération dans cet article est celle du fournisseur, sur le GPU choisi par le fournisseur, avec la précision cible choisie par le fournisseur.

Aucune annonce, donc aucun cadrage. Nous ne savons pas si Liquid destine ce modèle à une recommandation de production pour le 24B ou à un artefact de recherche. Le ton de la fiche — des indicateurs de lancement complets, un tableau de la famille, un lien de contact — suggère la première option, mais il s'agit d'une inférence.

Pas de prix, car il ne peut pas y en avoir. Un drafter n’est pas un modèle servi. Il n’a pas de tarif par million de jetons et n’apparaîtra jamais dans un catalogue de modèles comme point de terminaison appelable. Son coût, ce sont les 655 Mo de VRAM ou de mémoire unifiée qu’il occupe à côté du modèle cible, plus le calcul supplémentaire nécessaire pour vérifier un bloc au lieu d’un jeton.

Aucun chiffre pour Apple silicon. C'est l'écart le plus important, et la section suivante explique pourquoi il compte plus que les autres.

Le numéro de Mac manquant est l’omission intéressante.

Le modèle 24B est vendu comme un modèle embarqué. L'article de lancement de Liquid met en avant 184 jetons par seconde sur un Apple M5 Max et affirme qu'il est conçu pour des agents rapides et privés fonctionnant sur l'appareil. La fiche du drafter, en revanche, ne rapporte que des chiffres B300. Pour le drafter 8B en août, Liquid a publié des résultats à la fois sur H100 et M4 Max et s'est montrée transparente au sujet de l'écart entre eux : une accélération moyenne de 2,54× sur un H100 tombait à 1,18× sur un MacBook. La raison invoquée était mécanique — vérifier k jetons active davantage d'experts qu'une seule étape de décodage, de sorte qu'une cible MoE paie plus de trafic de poids par jeton vérifié, et le backend Metal de llama.cpp aggravait la situation.

LFM2.5-24B-A2B est aussi un mélange d’experts : 64 experts par bloc avec un routage top-4. Le même mécanisme s’applique, et le 24B est un modèle plus grand avec un ensemble d’experts plus vaste à parcourir par pagination. Cela ne prouve pas que l’accélération sur l’appareil est faible — le drafter a été entraîné spécifiquement pour cette cible, et le taux d’acceptation est bien meilleur que celui du 8B au départ — mais cela signifie que le seul chiffre dont un utilisateur d’ordinateur portable a besoin est celui que la fiche ne contient pas. Considérez toute hypothèse selon laquelle le ratio du B300 se transpose à un Mac comme non vérifiée.

L'exécuter, et le flag qui va vous mordre

Sur GPU, la recette publiée est SGLang avec la cible FP8 et le drafter attaché, une taille de bloc de 9 et dix jetons de draft. Le SGLang installé doit être suffisamment récent pour inclure le chemin LFM2-MoE DSpark de la PR #31041 et la réutilisation de configuration de la PR #43939 ; sur une version plus ancienne, le serveur ne reconnaîtra pas du tout l’architecture du drafter. Notez que les chiffres du benchmark supposent la cible FP8 — la cible BF16 se comportera différemment, et pas nécessairement mieux, car le drafter a été entraîné sur une distribution spécifique de logits cibles.

Sur CPU et Apple silicon, la voie passe par llama.cpp avec le side-car GGUF F16. Le side-car lit sa taille de bloc dans ses propres métadonnées et y plafonne --spec-draft-n-max, donc régler la longueur de draft sur 12 ne vous donne pas 12. Les temps par réponse exposent draft_n et draft_n_accepted, le champ à surveiller sur votre propre charge de travail : si le taux d'acceptation sur votre trafic se situe bien en dessous de la moyenne de 5,16 de la carte, le générateur de drafts vous coûte une passe avant et rapporte peu, et le plus honnête est de le détacher.

Ce que cela signifie si vous choisissez un modèle cette semaine

Pour la plupart des équipes, la conséquence pratique est faible, car le drafter modifie la vitesse et non les capacités. LFM2.5-24B-A2B est ce qui répond aux prompts ; le drafter ne change que le nombre de ces réponses que vous obtenez par seconde. Si le 24B ne figurait pas sur votre liste restreinte la semaine dernière, une version plus rapide ne l’y ajoutera pas.

S'il figurait sur votre liste restreinte, le modèle de brouillon renforce l'argument en faveur de l'auto-hébergement et n'apporte rien au cas d'usage API. Cette distinction mérite d'être énoncée clairement : un checkpoint de décodage spéculatif est invisible pour quiconque appelle un point de terminaison hébergé, car c'est la pile de service qui décide de l'attacher ou non. Ce que vous pouvez comparer à armes égales, c'est le modèle lui-même aux alternatives vers lesquelles vous auriez autrement routé — et si vous l'évaluez face à quelque chose comme Qwen3.6-35B-A3B, le modèle par rapport auquel Liquid se mesure sur cinq des huit tâches agentiques, OrcaRouter porte cette cible de comparaison derrière une seule clé à 0 % de majoration sur le prix catalogue du fournisseur, avec basculement automatique entre fournisseurs. Nous ne servons pas aujourd'hui la famille LFM2.5, donc le 24B lui-même doit provenir de l'API du fournisseur ou de vos propres GPU ; ce que nous offrons, c'est l'autre côté de la comparaison sans second contrat.

Qu’est-ce qui changerait cette image ?

Trois choses, par ordre de l’impact qu’elles auraient sur le récit. Un article de blog de Liquid trancherait le cadrage — s’agit-il d’un duo de production recommandé ou d’une version de recherche. Une mesure Mac publiée trancherait l’affirmation qui compte pour le public auquel le 24B était destiné. Et une campagne d’acceptation indépendante sur du trafic réel, plutôt que huit jeux de données de benchmark à température 0, vous dirait si 5,16 tokens par étape survit au contact des prompts longs, désordonnés et avec appel d’outils pour lesquels ce modèle est réellement vendu.

D’ici là, le dépôt est public, les poids sont téléchargeables, le CSV est juste là, et la fiche modèle du fournisseur est le dernier endroit où chercher des nouvelles de sa sortie. C’est un état inhabituel pour une version — mais c’est un état réel, et l’artefact ne devient pas moins réel parce que personne n’a écrit l’article de blog.