LFM2.5-24B-A2B-DSpark 対 LFM2.5-8B-A1B-DSpark：同じ328Mファイル、大きく異なる2つの賭け

どちらのファイルをダウンロードしても655,421,522バイトになる。LFM2.5-24B-A2B-DSparkとLFM2.5-8B-A1B-DSparkはバイト単位で同じサイズで、5層のバックボーン、同じrank-256 Markovヘッド、同じブロックサイズ9、同じ128,000トークンの語彙を共有している。しかもどちらも単一のプロンプトにすら答えられない。どちらも対象モデルのトークンを推測するためだけに存在する投機的デコーディング用のドラフターだからだ。両者を分けるのは、それ自体の仕様ではない。どの対象モデルに対して訓練されたか、そしてその対象モデルでこの仕組みが機能するという証拠がどれだけあるかだ。一方にはローンチ投稿から公開されたGPUとMacBookでの測定値がある。もう一方にはGPUの表があるだけで、発表はない。したがって両者の選択はモデルの比較ですらない。二つの賭けの比較であり、そのうち現金化されているのは一つだけだ。このようなリリースの背後にある、文書化されたAIの失敗やエージェントのインシデントは、OrcaRouter AI Incident Archiveに集められており、各項目には独自の情報源、重大度、信頼度グレード、係争中フラグが付いている。

ファイルは双子だが、ジョブはそうではない。

2つの config.jsonファイルを並べて見ると、ほぼすべてのフィールドが一致します。hidden size 2,048、intermediate size 6,144、SiLU活性化、ヘッド次元64で8個のKVヘッドに対する32個のアテンションヘッド、5つのフルアテンション層、ブロックサイズ9、enable_confidence_head: true、ランク256の標準的なMarkovヘッド。パラメータ数は完全に同一であり、そのためsafetensorsファイルはバイト単位で一致します。

3つのフィールドが異なっており、それぞれが不可欠な役割を担っています。

• ターゲット層タップ — 8B ドラフターは、24 層のターゲットの層 2、6、10、14、18 から隠れ状態を読み取ります。24B ドラフターは、40 層のターゲットの層 2、10、18、26、34 を読み取ります。ファイルを相互交換不可にするのは、このフィールドです。

• 最大ポジション数 — 8Bドラフターでは128,000、24Bでは131,072で、それぞれのターゲットのコンテキストウィンドウに合わせています。

• RoPE theta — 5,000,000 対 10,000,000。これはドラフターに関する何かではなく、ターゲットの位置エンコーディングによって設定されます。

その最後のペアは、これらのチェックポイントが共通のベースからスケーリングされたのではなく、ターゲットごとに訓練されたことを示す最も明確な証拠である。ドラフターには独立したアイデンティティがない。その入力分布はターゲットの隠れ状態がどう見えるかに依存し、ターゲットのアーキテクチャと訓練が変わればそれらも変わる。8Bドラフターを24Bモデルに向けると、レイヤーインデックスだけでも意味をなさなくなる。たとえそれらが揃ったとしても、予測するように訓練されたロジットは揃わないだろう。

それぞれが実際に加速させているもの

ターゲットは「8B対24B」という名称から連想されるよりも大きく異なっており、大きいモデルのほうがオンデバイスでの負担が重いと考える人にとっては、その違いは逆方向に働く。

• 総パラメータ数とアクティブパラメータ数 — LFM2.5-8B-A1B は総計 8.3B で、トークンあたり 1.5B がアクティブです。LFM2.5-24B-A2B は総計 24.0B で、2.45B がアクティブです。

• 深さ — 24層（18のゲート付き畳み込みと6のGQA）対40層（30の畳み込みと10のGQA）。

• コンテキスト — 131,072 に対して 128,000 トークン

• 学習予算 — {{1}}36Tに対して38Tトークン{{/1}}、つまり小さいモデルは大きいモデルと比べて学習不足ではなかった。

• ルーティング — 8B は 24B と同じく、トップ4ルーティングを備えた64エキスパートの MoE を使用しているため、どちらも検証に悪影響を与えるエキスパート活性化のペナルティを負います。

{{1}}どちらも回答前に考える推論モデルであり{{/1}}、ここではパラメータ数よりもその点が重要だ。{{2}}投機的デコーディングの最大の弱点は長く制約のない出力であり{{/2}}、思考の連鎖はまさにそれだ。ベンダーの表がそれを示している。両リリースで最も受け入れ率が高い行はMBPPやMT-Benchのような短答ベンチマークであり、最も低いのはモデルが長い解法経路を考案しなければならないものだ。

証拠の乏しさこそが本当の違いだ

ここから、2つのリリースは単純比較できなくなる。8Bドラフターは、ファミリー全体の発表の一環として2026年8月20日に提供開始され、大きく異なる2台のマシンで測定された。SGLang経由でBF16を実行するH100 80 GB 1台と、実験的なMetalカーネルを使いllama.cpp経由でFP16 GGUF重みを実行するM4 Max MacBook Proである。H100では平均2.54倍、MATH-500では最大3.18倍だったのに対し、MacBookではわずか1.18倍——5つのデータセットで平均して毎秒90～106トークンだった。

24B drafterのハードウェア行は1つだけです。FP8ターゲット、BF16 KVキャッシュ、temperature 0を使用する単一のNVIDIA B300です。8つのデータセット全体で、同時実行数1では平均2.38倍、同時実行数32では2.69倍、同時実行数256では1.71倍となり、同時実行数32のMBPPでは最大3.28倍を記録します。Macの行もH100の行もなく、この省略を説明する発表投稿もありません。

オンデバイスエージェントを売り文句のすべてにしているモデルにとって——Liquidの24B向けローンチ記事はApple M5 Max上で毎秒184トークンという数字を先頭に掲げている——欠けているMacBookの数値は、このリリースにおける最も重大な空白だ。8Bの結果は、なぜその数値が小さくなる可能性があるのかを示している。トークンのブロックを検証すると、1つをデコードするよりも多くのエキスパートが活性化するため、MoEターゲットは受け入れられたトークンあたりより多くの重みを動かす。また、受け入れ率だけが予測要因ではない。8Bドラフターは実際、1ステップあたり24Bのカードが報告するよりも多くのトークンを受け入れていた（5つのデータセットで6.95、8つのデータセットでは5.16）にもかかわらず、MacBook上では1.18×しか出していない。そこが覚えておく価値のある点だ——8Bでは、高い受け入れ率もオンデバイスのスループットを救わなかった。24Bが異なる挙動をすると仮定するのは、裏付けとなる数値のない賭けだ。

2つの表を突き合わせて読む

見出しの比率は同一条件での比較ではなく、互いに差し引くべきものではない。GPUが異なり、目標精度が異なり、データセット群が異なり、並行度のスイープも異なる。しかし、その不一致を超えてもなお残る二つのパターンがある。

{{1}}まず、上限は同様です。8Bの最良のH100セルはバッチサイズ1でMATH-500において3.18倍でした。24Bの最良のB300セルは同時実行数32でMBPPにおいて3.28倍です。この設計のドラフターは、どのターゲットに提供するかに関係なく、同じ1.5倍～3.3倍の帯域に収まります。これは、ドラフターのアーキテクチャを固定し、重みのみを変更する場合に予想されることです。{{/1}}

第二に、より有用な点として、下限こそがターゲットの分かれるところです。8Bで最も弱いH100セルはGSM8Kの1.29倍でした。24Bで同時実行数256における最も弱いB300セルはLiveCodeBenchの1.34倍とAIMEの1.36倍でした。どちらのリリースも、投機が無料で済むケースは生み出しておらず、両方ともメモリを割く価値がほとんどないケースを生み出しています。

2枚のカードの間には、見落としやすく、指摘する価値のあるドキュメントの変更もあります。8月の資料では、貪欲法（greedy decoding）による出力は「構成的に」ベースラインと同一だとされていました。8Bカードは「まったく同じ出力」を約束しています。一方、24Bカードは、バッチ検証と通常のデコーディングの間の浮動小数点差により、貪欲サンプリング時を含めて異なるテキストが生成され得ると警告しています。後者のカードのほうがより慎重であり、CIでバイトレベルの出力差分を実行するなら、古い約束を信じるのではなく、どちらも同一でない可能性があるものとして扱う価値があります。

どれがあなたにとって適切かは、予算ではなく目標によって決まります

チームがメリットだけでこれらの一方を他方より選ぶようなシナリオは存在しない。24Bを動かすのは、それを載せられるマシン上で24Bモデルの能力が必要だからだ——GGUFのQ4_K_Mで14.5 GB、あるいはFP8サービング構成なら単一のB300だ。8Bを動かすのは、合計8.3Bパラメータでアクティブ1.5Bという構成がエッジデバイスやラップトップに収まるからであり、ドラフターが小規模化によって犠牲にしたデコード速度の一部を取り戻してくれるからだ。ドラフターはその最初の決定に付随するものであり、その決定は投機的デコーディングが話題に上がるずっと前に、メモリと品質に基づいてほぼ常になされている。

選択が実際に意味を持つ唯一の場面は評価です。DSparkを自社スタックに導入する価値がそもそもないかどうかを検証しているなら、8Bの組み合わせの方が安価な実験です。1台のH100に収まり、自分のラップトップと比較できるMacでの数値があり、オンデバイスでの失敗モードもすでにベンダーによって文書化されています。24Bの組み合わせは、より興味深い本番環境での実験であり、文書化がより少ない方でもあります。

どちらの場合でも、結果を決める数はベンダーの表ではなく、受理カウンターだ。SGLangはリクエストごとに投機的デコーディングの受理状況を公開し、llama.cppはdraft_n と draft_n_acceptedをレスポンスごとのタイミングで報告する。自分のプロンプトを10分間実行して割り算せよ。受理率がカードの平均付近ならドラフターは元が取れ、低い端なら検証パスを買っていることになるので切り離すべきだ。そしてその結論は、仕組みが同じなので、両方のチェックポイントに当てはまる。

どちらのチェックポイントも、呼び出せるモデルではありません。

これは、モデルカタログでこれらの名前を見かけ、メニュー上の選択肢だと思い込む人が引っかかる部分です。どちらもエンドポイントではありません。どちらのドラフターにも100万トークンあたりの価格はなく、どちらもAPIの一覧に表示されず、モデルを提供するプラットフォームがこれらにルーティングすることも決してありません。正しい組み合わせはリクエストパラメーターではなく、サーバー側の設定だからです。

Liquid AIは24Bのターゲットモデル自体を、入力トークン100万件あたり0.10ドル、キャッシュ済み0.05ドル、出力トークン100万件あたり1.00ドルで販売しており、その価格の裏で行われる投機的デコーディングは呼び出し側には見えません。これが今の市場のありふれた形です。面白いエンジニアリングはサービングスタックの内部で行われ、開発者に届くのは料金と毎秒トークン数の数値だけです。ルーティングプラットフォームが存在価値を発揮するのは、そのレイヤーの上での比較においてです。つまり、候補モデルを、それが打ち負かさなければならないモデルたちの隣に置くことです。OrcaRouterは単一のエンドポイントでプロバイダー定価に0%のマークアップで200以上のモデルを運用しており、ベンダーの料金が変われば表示される料金も同日に変わり、フェイルオーバーによって、候補モデルを評価している間、それが単一障害点になることも防げます。LFM2.5ファミリーは現在これらに含まれていないため、ドラフターを付けた自己ホスト型の8Bまたは24Bはローカルデプロイのままです。それと比較テストする価値のあるモデル — Qwen3.6-35B-A3B（エージェント側）、Gemma 4 26B-A4B（効率側） — が、当社がルーティングするモデルです。

DSparkのリリースが1年で確立したもの

このファミリーは現在、4つのテキストターゲットと1つのビジョンターゲットにまたがり、1.2Bから24Bまで、すべてが1つのドラフターレシピを共有しています。約300Mパラメータ、5つのアテンション層、ブロック9、ターゲット自身の隠れ状態で学習されます。その一貫性こそが実際の知見です。Liquidは投機的デコーディングを、モデルごとの研究プロジェクトから製造工程へと変えました。同じドラフターを再ターゲットし、新しいモデルごとに数日以内に出荷するのです。その工程をあなたのハードウェアで取る価値があるかどうかは、あなたのトラフィックに関する問いであり、答えは、この2つのファイルのどちらをダウンロードするかによって変わるよりもはるかに大きくワークロードによって異なります。

24Bリリースがその全体像に加えるのは、より良い比率ではない。それは、ドラフターが付随する解説文なしで出荷された初めての事例であり、ベンダー自身のカードが、出力が結局のところビット単位で同一でない可能性があると平易な言葉で告げた最初の事例だ。