LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B : faut-il vraiment attacher le drafteur ?

Voici la décision en une ligne : LFM2.5-24B-A2B-DSpark est un fichier de 327,7 M de paramètres que vous placez à côté de LFM2.5-24B-A2B afin que le modèle 24B produise le même type de sortie plus rapidement. Ce n'est pas une alternative au modèle et ce n'est pas quelque chose que vous choisissez à la place de celui-ci. La seule vraie question que soulèvent ces deux noms est d'ordre technique — faut-il rattacher le drafter à votre déploiement ou le laisser de côté — et la réponse dépend moins du gain de vitesse mis en avant par Liquid AI que de deux chiffres que personne ne communique : combien de tokens du draft sont acceptés sur votre trafic, et quel volume de concurrence vous gérez déjà. Les défaillances de l'IA et incidents d'agents documentés à l'origine de versions comme celle-ci sont recensés dans l'OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, sa gravité, son niveau de confiance et son indicateur de contestation.

Liquid AI n’a pas publié de billet d’annonce pour le drafter. Le dépôt est devenu public le 2026-10-19 avec les poids, un CSV de benchmarks et des flags de lancement SGLang, tandis que la fiche modèle de la cible elle-même indique encore que le drafter est « bientôt disponible » et que la page de documentation de Liquid sur le décodage spéculatif ne répertorie que les cibles 1.2B, 2.6B, 8B et VL-3B. Il s’agit donc d’une comparaison entre un artefact livré et un modèle livré, rédigée à partir du dépôt plutôt que d’un communiqué de presse — ce qui signifie que chaque chiffre de performance ci-dessous est rapporté par le fournisseur et qu’aucun n’a été reproduit indépendamment.

Ce que le rédacteur modifie réellement, et ce qu’il ne modifie pas

Le mécanisme vaut trente secondes d’attention, car il conditionne tout le reste. Le décodage d’un token est limité par la mémoire : la GPU passe l’essentiel de son temps à transférer les poids vers la SRAM, pas à effectuer des calculs. Le décodage spéculatif exploite cela en faisant deviner par un petit modèle les plusieurs tokens suivants d’un coup, puis en faisant vérifier toute la prédiction par le vrai modèle en une seule passe avant. Si la prédiction était bonne, vous avez produit neuf tokens pour à peu près le coût d’un seul. Si elle était mauvaise, le modèle cible conserve son propre token et vous n’avez payé qu’un léger surcoût.

Ce qui change : les tokens par seconde et la forme de l’utilisation de votre GPU. Ce qui ne change pas : les poids du modèle, sa fenêtre de contexte, son comportement d’appel d’outils ou ses prix là où il est vendu. LFM2.5-24B-A2B conserve 24,0 B de paramètres au total avec 2,45 B actifs par token, 40 couches réparties entre convolutions courtes à portes et attention à requêtes groupées, 64 experts par bloc avec routage top-4, un contexte de 131 072 tokens et un vocabulaire de 128 000 tokens. Le drafter ajoute cinq couches d’attention, une tête de Markov de rang 256 et une tête de confiance, et réutilise les embeddings et la tête LM de la cible au lieu de porter les siens.

Une réserve a évolué entre les deux versions et mérite une ligne. En août, le compte rendu de Liquid sur DSpark indiquait que la séquence émise est « identique au glouton de référence par construction ». La fiche du drafter 24B dit en revanche que les différences en virgule flottante entre la vérification par lots et le décodage simple « peuvent produire un texte différent, y compris avec un échantillonnage glouton ». Les deux affirmations sont défendables — la première est vraie en arithmétique exacte — mais si votre harnais d’évaluation compare les sorties octet par octet, attendez-vous à ce qu’il s’en aperçoive.

Le côté des coûts du grand livre

Le modèle brouillon n'est pas gratuit. Il occupe 655 Mo en BF16 sur le GPU (ou un GGUF F16 de 664 Mo sur CPU), il réside dans le même pool de mémoire que le modèle cible, et chaque étape qu'il propose coûte une passe avant de vérification sur un bloc de jetons plutôt que sur un seul jeton. Sur une cible MoE, cette dernière partie est plus coûteuse qu'elle n'en a l'air : vérifier neuf jetons active davantage d'experts que décoder un seul jeton, si bien que le nombre d'octets déplacés par jeton vérifié augmente au lieu de diminuer. Liquid a cité exactement ce point comme la raison pour laquelle son modèle brouillon 8B n'a atteint que 1,18× sur un M4 Max malgré un taux d'acceptation élevé.

En contrepartie, les économies sont suffisamment importantes pour être mesurées en heures-GPU. En utilisant les propres chiffres B300 du fournisseur issus de benchmarks/b300-fp8.csv, et en ne faisant rien de plus que diviser un milliard de jetons de sortie par le débit observé :

• MATH-500, concurrence 1 — 324 tok/s seul (857 heures-GPU par milliard de tokens) contre 853 tok/s avec le drafter (326 heures-GPU). Une réduction de 2,63× du temps de calcul.

• MATH-500, concurrence 256 — 15 423 tok/s seul (18,0 heures GPU) contre 27 579 tok/s avec le drafter (10,1 heures GPU). Une réduction de 1,79×.

• GSM8K, concurrence 256 — 4 491 tok/s seul (61,9 heures GPU) contre 9 660 tok/s avec le drafter (28,8 heures GPU). Une réduction de 2,15×.

• LiveCodeBench, concurrence 256 — 18 812 tok/s seul (14,8 heures GPU) contre 25 231 tok/s avec le drafter (11,0 heures GPU). Seulement une réduction de 1,34×, la cellule la plus faible du tableau.

Ce sont des ratios de débit convertis en temps, pas en argent, car l’argent dépend de ce que vous payez par heure-GPU et cet article ne va pas inventer un tarif. Mais l’ordre relatif tient quel que soit le tarif : attacher le drafter vaut deux à trois heures sur dix pour le trafic de raisonnement et de génération de code à faible concurrence, et environ un tiers de cela à forte concurrence. Si votre déploiement 24B est un agent mono-utilisateur sur une station de travail, l’argument est solide. S’il s’agit d’un point de terminaison par lots saturé, l’argument est réel mais bien plus ténu que ne le suggère le 2,4× mis en avant.

Là où le rédacteur justifie son coût, en termes de charge de travail

L'écart entre les huit jeux de données dans le tableau du fournisseur n'est pas du bruit ; il correspond aux types de prompts, et cette correspondance est l'élément le plus utile de la publication. Le taux d'acceptation allait de 6,70 jetons par étape sur MBPP à 4,02 sur LiveCodeBench. Les jeux de données qui ont obtenu des scores élevés sont ceux où la sortie du modèle est contrainte par le prompt — de courtes fonctions de type tests unitaires, de l'arithmétique avec un chemin vérifiable, des réponses à choix multiples. Ceux qui ont obtenu des scores faibles sont ceux où le modèle doit inventer une longue solution non contrainte : des problèmes de programmation compétitive et des mathématiques de style AIME.

C’est l’intuition à garder en tête pour votre propre évaluation. Un modèle de raisonnement 24B commercialisé pour des tâches agentiques consacre la majeure partie de ses tokens de sortie à une chaîne de raisonnement, ce qui ressemble davantage à LiveCodeBench qu’à MBPP. Un modèle utilisé pour l’extraction structurée, la classification avec un schéma ou un format d’appel d’outil fixe ressemble bien davantage aux lignes à fort taux d’acceptation. Si votre charge de travail correspond au premier cas, attendez-vous à vous situer plus près du bas de la fourchette, à 1,34×, que du haut, à 3,28×. Personne n’a publié de taux d’acceptation par charge de travail pour ce drafter, et les huit jeux de données de la fiche sont ce qui s’approche le plus d’un guide.

Par contraste : le 24B est un modèle uniquement dédié au raisonnement. Liquid déclare qu’il réfléchit toujours avant de répondre — le gabarit de conversation insère automatiquement une balise <think>. C’est la configuration la plus défavorable possible pour la spéculation, car le segment de raisonnement correspond exactement à la longue portion à faible taux d’acceptation. Le générateur de propositions aidera tout de même ; il sera le plus utile sur la réponse finale et le moins utile sur la partie qui prend le plus de temps.

Comment le savoir, sur votre propre matériel, en un après-midi

Vous n’êtes pas obligé de croire tout ce qui précède. Les deux chemins d’inférence exposent le compteur d’acceptation, qui est le seul chiffre qui détermine si le drafter est rentable sur votre trafic.

Sur SGLang, lancez la cible avec le drafter attaché, une taille de bloc de 9 et dix jetons de brouillon, puis lisez les métriques de décodage spéculatif que le serveur rapporte par requête. Le taux d’acceptation dans le tableau du fournisseur se situe entre 0,33 et 0,65 selon le jeu de données ; une exécution qui se situe bien en dessous de la ligne pertinente signifie que le drafter devine mal et que vous payez la vérification sans récolter l’accélération. Sur llama.cpp avec le sidecar GGUF F16, les timings par réponse portent draft_n et draft_n_accepted directement. Divisez l’un par l’autre.

Deux détails opérationnels vous coûteront une heure si vous les manquez. Le serveur SGLang nécessite une compilation qui inclut le chemin LFM2-MoE DSpark fusionné le 2026-08-31 — sur toute version plus ancienne, l'architecture du drafter est tout simplement inconnue. Et la taille de bloc est une propriété du checkpoint, pas un paramètre libre : llama.cpp limite --spec-draft-n-max à la valeur de métadonnées du sidecar, soit 9, donc demander 12 n'apporte rien.

La question à laquelle cette comparaison ne peut pas répondre

Il existe une version de la question « dois-je attacher le drafter » qui n’a rien à voir avec les GPU, et c’est celle à laquelle la plupart des équipes sont réellement confrontées. Si vous appelez LFM2.5-24B-A2B via une API hébergée, la décision concernant le drafter ne vous appartient pas. La pile de service attache ou non un décodeur spéculatif ; vous voyez un chiffre de jetons par seconde et un prix, et les deux ont été décidés en amont. La Console de Liquid elle-même indique le 24B à $0.10 par million de jetons d’entrée, $0.05 pour l’entrée mise en cache et $1.00 par million de jetons de sortie — un tarif publié qui reflète déjà le chemin de décodage qu’ils utilisent, quel qu’il soit, et qui peut changer sans préavis.

C’est là que le routage aide plutôt qu’il ne complique. Un appel hébergé et un déploiement auto-hébergé ne sont pas tant des offres concurrentes que deux réglages du même curseur de coût : l’auto-hébergement associé au modèle draft minimise le coût par token si votre volume maintient le GPU occupé, et un point de terminaison hébergé minimise le travail nécessaire pour obtenir une réponse. OrcaRouter est conçu pour la seconde — une seule clé pour plus de 200 modèles à 0 % de marge sur le prix catalogue du fournisseur, de sorte qu’un changement de prix chez un fournisseur se répercute chez nous le jour même, avec un basculement automatique si un fournisseur se dégrade et un DSL de routage pour répartir le trafic plutôt que coder en dur un seul backend. Nous ne proposons pas actuellement la famille LFM2.5, donc pour ce modèle précis, le côté hébergé signifie l’API propre à Liquid ou vos propres GPU ; la comparaison qui vaut la peine d’être faite est avec les modèles que nous proposons, comme Qwen3.6-35B-A3B — le modèle auquel Liquid se compare sur les tâches agentiques — ou Gemma 4 26B-A4B.

Alors : l'attacher ou pas

Joignez-le si vous servez vous-même LFM2.5-24B-A2B à une concurrence modérée, en particulier pour une sortie structurée ou de type extraction, et si vous disposez de 655 Mo de marge à côté du modèle cible. Les chiffres du fournisseur indiquent que vous diviserez à peu près par deux ou par trois votre temps de décodage dans ce cas, et le revers est limité : un mauvais drafteur coûte une passe de vérification, pas une réponse erronée.

Laissez-le désactivé si votre endpoint est déjà saturé à plusieurs centaines, si votre sortie est un long raisonnement en texte libre, ou si vous avez besoin de chiffres Apple-silicon avant de vous engager — la fiche n’en contient aucun, et l’analogue le plus proche de la même famille est sorti à 1,18× sur un MacBook. Et laissez-le désactivé, évidemment, si vous n’exécutez pas du tout le modèle : un drafter est une optimisation pour un déploiement, et il n’y a rien à optimiser tant que le déploiement n’existe pas.

Ce qui permettrait de trancher le reste, c’est un article du fournisseur et une mesure sur Mac. Ni l’un ni l’autre n’existe au 2026-10-21, ce qui est un état étrange pour une version dont les poids sont déjà téléchargeables — et, pour quiconque accepterait de faire tourner lui-même le compteur d’acceptation, une occasion inhabituellement peu coûteuse d’être le premier chiffre indépendant au tableau.