LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark : même fichier de 328M, deux paris très différents

Téléchargez l’un ou l’autre fichier et vous obtenez 655 421 522 octets. LFM2.5-24B-A2B-DSpark et LFM2.5-8B-A1B-DSpark font exactement la même taille, à l’octet près, partagent un backbone à cinq couches, la même tête de Markov de rang 256, la même taille de bloc de 9 et le même vocabulaire de 128 000 jetons — et aucun des deux ne peut répondre à un seul prompt, car tous deux sont des modèles brouillons de décodage spéculatif qui n’existent que pour deviner des jetons pour un modèle cible. Ce qui les distingue n’est pas leur propre spécification. C’est la cible contre laquelle ils ont été entraînés, et l’ampleur des preuves que l’astuce fonctionne sur celle-ci. L’un a publié des mesures sur GPU et MacBook dans un article de lancement ; l’autre a un tableau de résultats GPU et aucune annonce. Choisir entre eux n’est donc pas du tout une comparaison de modèles — c’est une comparaison de deux paris, et un seul a été encaissé. Les défaillances documentées de l’IA et les incidents d’agents derrière des versions comme celle-ci sont recueillis dans l’OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, sa gravité, son niveau de confiance et un indicateur de contestation.

Les fichiers sont jumeaux ; les tâches ne le sont pas.

Lisez les deux config.json côte à côte et presque tous les champs correspondent : taille cachée 2 048, taille intermédiaire 6 144, activation SiLU, 32 têtes d’attention sur 8 têtes KV avec une dimension de tête de 64, cinq couches d’attention complète, taille de bloc 9, enable_confidence_head: true, une tête Markov standard de rang 256. Le nombre de paramètres est identique, c’est pourquoi les fichiers safetensors correspondent octet pour octet.

Trois champs diffèrent, et chacun est déterminant.

• Captures de couches du modèle cible — le drafter 8B lit les états cachés des couches 2, 6, 10, 14 et 18 d’une cible à 24 couches ; le drafter 24B lit les couches 2, 10, 18, 26 et 34 d’une cible à 40 couches. C’est ce champ qui rend les fichiers non interchangeables.

• Positions maximales — 128 000 pour le drafteur 8B, contre 131 072 pour le 24B, suivant les fenêtres de contexte de leurs modèles cibles.

• Thêta RoPE — 5 000 000 contre 10 000 000, défini par l’encodage positionnel de la cible plutôt que par quoi que ce soit propre au générateur de propositions.

Cette dernière paire est la preuve la plus claire que ces checkpoints ont été entraînés par cible plutôt que mis à l’échelle à partir d’une base commune. Le drafteur n’a pas d’identité indépendante : sa distribution d’entrée correspond à ce à quoi ressemblent les états cachés de la cible, et ceux-ci changent lorsque l’architecture et l’entraînement de la cible changent. Pointez le drafteur 8B vers le modèle 24B, et les indices de couche à eux seuls le rendent absurde ; même s’ils s’alignaient, les logits qu’il a été entraîné à prédire ne le seraient pas.

Ce que chacun accélère réellement

Les cibles sont bien plus différentes que ne le laisse supposer l'appellation « 8B versus 24B », et cette différence va dans le sens inverse de ce que croirait quiconque part du principe que le plus gros modèle est la charge la plus lourde à exécuter sur l'appareil.

• Paramètres totaux et actifs — LFM2.5-8B-A1B compte 8,3 B de paramètres au total, dont 1,5 B actifs par token ; LFM2.5-24B-A2B compte 24,0 B de paramètres au total, dont 2,45 B actifs.

• Profondeur — 24 couches (18 convolutions à portes plus 6 GQA) contre 40 couches (30 convolutions plus 10 GQA).

• Contexte — 128 000 tokens sur 131 072.

• Budget d’entraînement — 38T de tokens contre 36T, donc le modèle plus petit n’était pas sous-entraîné par rapport au plus grand.

• Routage — le 8B utilise un MoE à 64 experts avec un routage top-4, comme le 24B, donc les deux subissent la pénalité d’activation des experts qui nuit à la vérification.

Les deux sont des modèles de raisonnement qui réfléchissent avant de répondre, ce qui compte ici davantage que le nombre de paramètres. La plus grande faiblesse du décodage spéculatif réside dans les sorties longues et non contraintes, et une chaîne de pensée en est exactement un exemple. Les tableaux du fournisseur le montrent : les lignes aux taux d’acceptation les plus élevés dans les deux versions concernent des benchmarks à réponses courtes comme MBPP et MT-Bench, et les plus faibles sont celles où le modèle doit inventer un long chemin de solution.

L’écart en matière de preuves est la véritable différence

C’est ici que les deux versions cessent d’être comparables. Le drafter 8B est sorti le 2026-08-20 dans le cadre de l’annonce d’une famille complète, avec des mesures sur deux machines très différentes : un seul H100 80 Go en BF16 via SGLang, et un MacBook Pro M4 Max exécutant des poids GGUF FP16 via llama.cpp avec des kernels Metal expérimentaux. Il a atteint en moyenne 2,54× sur le H100, avec un pic à 3,18× sur MATH-500, et seulement 1,18× sur le MacBook — 90 à 106 tokens par seconde, en moyenne sur cinq jeux de données.

Le drafter 24B ne comporte qu’une seule ligne matérielle : un unique NVIDIA B300 avec la cible FP8, le cache KV BF16 et une température de 0. Il atteint en moyenne 2,38× à une concurrence de 1, 2,69× à une concurrence de 32 et 1,71× à une concurrence de 256 sur huit jeux de données, avec un pic de 3,28× sur MBPP à une concurrence de 32. Il n’y a pas de ligne Mac, pas de ligne H100, et aucun article d’annonce pour expliquer cette omission.

Pour le modèle dont tout l’argument de vente repose sur des agents embarqués — le billet de lancement de Liquid pour le 24B met en avant 184 jetons par seconde sur un Apple M5 Max —, le chiffre manquant pour le MacBook est la lacune la plus lourde de conséquences de cette annonce. Le résultat du 8B explique pourquoi il pourrait être faible : vérifier un bloc de jetons active davantage d’experts que d’en décoder un, si bien qu’une cible MoE déplace plus de poids par jeton accepté. Et le taux d’acceptation à lui seul ne permet pas de prédire : le modèle draft 8B a en réalité fait la moyenne de davantage de jetons acceptés par étape que ne l’indiquent les chiffres de la fiche technique du 24B (6,95 sur cinq jeux de données contre 5,16 sur huit) et n’a malgré tout offert qu’un facteur 1,18× sur un MacBook. C’est le point à retenir — sur le 8B, un fort taux d’acceptation n’a pas sauvé le débit embarqué. Supposer que le 24B se comporte différemment est un pari sans chiffre à l’appui.

Lire les deux tableaux en regard l’un de l’autre

Les ratios phares ne sont pas comparables à périmètre égal et ne doivent pas être soustraits les uns des autres. GPU différent, précision cible différente, ensembles de données différents, balayages de concurrence différents. Mais deux tendances persistent malgré ce décalage.

D'abord, le plafond est similaire. La meilleure cellule H100 du 8B était de 3,18× sur MATH-500 avec une taille de lot de 1 ; la meilleure cellule B300 du 24B est de 3,28× sur MBPP à une concurrence de 32. Les drafters de cette conception se situent dans la même plage de 1,5× à 3,3×, quelle que soit la cible qu'ils servent, ce à quoi on s'attend lorsque l'architecture du drafter est maintenue fixe et que seuls les poids changent.

Deuxièmement, et plus utilement, c’est au niveau du plancher que les cibles divergent. La cellule H100 la plus faible du 8B était GSM8K à 1,29× ; la cellule B300 la plus faible du 24B à une concurrence de 256 était LiveCodeBench à 1,34× et AIME à 1,36×. Aucune des deux versions ne produit de cas où la spéculation est gratuite, et les deux produisent des cas où elle vaut à peine le coût mémoire.

Il y a aussi, entre les deux fiches, une modification de la documentation facile à manquer et qui mérite d’être signalée. Le document d’août indiquait que la sortie en décodage glouton est identique à celle de la référence « par construction » ; la fiche 8B promet « exactement les mêmes sorties ». La fiche 24B avertit en revanche que 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. La fiche plus récente est la plus prudente, et si vous exécutez des différences de sortie au niveau octet en CI, mieux vaut traiter les deux comme potentiellement non identiques plutôt que de faire confiance à l’ancienne promesse.

Celui qui est pertinent pour vous est déterminé par votre objectif, et non par votre budget.

Il n’existe aucun scénario dans lequel une équipe choisit l’un plutôt que l’autre sur la base de leurs mérites respectifs. On utilise le 24B parce qu’on a besoin des capacités d’un modèle 24B sur une machine capable de le contenir — 14,5 Go en Q4_K_M au format GGUF, ou un seul B300 pour la configuration de service FP8. On utilise le 8B parce que 8,3 B de paramètres au total dont 1,5 B actifs, c’est ce qui tient sur un appareil en périphérie ou un ordinateur portable, et le modèle brouillon récupère une partie de la vitesse de décodage perdue en passant à un modèle plus petit. Le modèle brouillon est accessoire à cette première décision, et celle-ci est presque toujours prise en fonction de la mémoire et de la qualité bien avant que la spéculation n’entre dans la conversation.

Le seul cas où le choix est réellement en jeu est l’évaluation. Si vous testez si DSpark vaut la peine d’être adopté dans votre stack, le couplage 8B est l’expérience la moins chère : il tient sur un seul H100, il dispose de chiffres Mac que vous pouvez comparer avec votre propre ordinateur portable, et son mode de défaillance sur l’appareil a déjà été documenté par le fournisseur. Le couplage 24B est l’expérience de production la plus intéressante et la moins documentée.

Dans les deux cas, le chiffre qui décide du résultat est le compteur d'acceptation, et non le tableau du fournisseur. SGLang expose le taux d'acceptation du décodage spéculatif par requête ; llama.cpp indique draft_n et draft_n_accepted dans les timings par réponse. Lancez vos propres prompts pendant dix minutes et faites la division. Si l'acceptation se situe près de la moyenne de la carte, le drafter est rentable ; si elle se situe dans le bas de la fourchette, vous payez des passes de vérification et devriez le détacher — et cette conclusion tiendra pour les deux checkpoints, car le mécanisme est le même.

Aucun des deux checkpoints n'est un modèle que vous pouvez appeler

C’est le point qui piège ceux qui rencontrent ces noms dans un catalogue de modèles et supposent qu’il s’agit d’options sur un menu. Ce ne sont pas des endpoints. Aucun des deux drafters n’a de prix par million de tokens, aucun n’apparaît dans un listing d’API, et aucun ne sera jamais routé vers par une plateforme qui sert des modèles — car l’appariement correct est une configuration côté serveur, et non un paramètre de requête.

Liquid AI vend elle-même la cible 24B à 0,10 $ par million de tokens d'entrée, 0,05 $ en cache et 1,00 $ par million de tokens de sortie, et toute spéculation qu'elle exécute derrière ce prix est invisible pour l'appelant. C'est désormais la forme ordinaire du marché : l'ingénierie intéressante se déroule à l'intérieur de la pile de service, et ce qui parvient à un développeur est un tarif et un chiffre de tokens par seconde. Là où les plateformes de routage gagnent leur place, c'est dans la comparaison au-dessus de cette couche — placer un candidat à côté des modèles qu'il doit battre. OrcaRouter fait tourner un seul point de terminaison sur plus de 200 modèles à 0 % de marge sur le prix catalogue du fournisseur, donc quand le tarif d'un fournisseur change, le tarif que vous voyez évolue le jour même, et le basculement automatique empêche un modèle candidat de devenir un point de défaillance unique pendant que vous l'évaluez. La famille LFM2.5 n'en fait pas partie aujourd'hui, donc un 8B ou 24B auto-hébergé avec son modèle de draft attaché reste un déploiement local ; les modèles qui valent la peine d'être testés face à lui — Qwen3.6-35B-A3B du côté agentique, Gemma 4 26B-A4B du côté de l'efficacité — sont ceux que nous routons.

Ce qu’une année de sorties DSpark a établi

La famille couvre désormais quatre cibles textuelles et une cible vision, de 1,2 à 24 milliards de paramètres, toutes partageant une même recette de drafter : environ 300 M de paramètres, cinq couches d’attention, bloc 9, entraîné sur les états cachés de la cible elle-même. Cette cohérence est le véritable résultat. Liquid a fait passer le décodage spéculatif d’un projet de recherche par modèle à une étape de fabrication — le même drafter, reciblé, livré en quelques jours après chaque nouveau modèle. Savoir si cette étape vaut la peine d’être franchie sur votre matériel est une question qui concerne votre trafic, et la réponse varie bien davantage selon la charge de travail que selon lequel de ces deux fichiers vous téléchargez.

Ce que la version 24B ajoute à ce tableau n'est pas un meilleur ratio. C'est la première fois qu'un drafter est livré sans le rapport d'accompagnement — et la première fois que la fiche produit du fournisseur vous dit, en termes clairs, que les sorties pourraient bien ne pas être identiques bit à bit après tout.