LFM2.5-24B-A2B-DSpark 対 LFM2.5-24B-A2B：ドラフターを実際に接続すべきか？

結論を一行で言うと、LFM2.5-24B-A2B-DSpark は、{{4}}LFM2.5-24B-A2B{{/4}} の隣に置く 327.7M パラメータのファイルです。LFM2.5-24B-A2Bこれにより、24B モデルは同じ種類の出力をより速く生成します。これはモデルの代替ではなく、モデルの代わりに選ぶものでもありません。この 2 つの名前が提起する本当の問いはエンジニアリング上の 1 つだけです — ドラフターをデプロイに付けるか、付けないか — そしてその答えは、Liquid AI が掲げる高速化の見出しよりも、誰も宣伝しない 2 つの数字に左右されます。つまり、ドラフトが受け入れられるトークン数はあなたのトラフィックによって決まり、すでに実行している同時実行数にも左右されます。このようなリリースの背景にある、文書化された AI 障害やエージェントインシデントは、OrcaRouter AI Incident Archive に集められており、各エントリには独自の出典、重大度、信頼度グレード、異議ありフラグが付いています。

Liquid AIはドラフター向けのローンチ投稿を公開していません。リポジトリは2026-10-19に重み、ベンチマークCSV、SGLangの起動フラグとともに公開されましたが、ターゲット自身のモデルカードは依然としてドラフターを「近日公開」と表記しており、Liquidの投機的デコーディングのドキュメントページには1.2B、2.6B、8B、VL-3Bのターゲットのみが記載されています。したがって、これは出荷済みの成果物と出荷済みモデルの比較であり、プレスリリースではなくリポジトリから書かれたものです。つまり、以下の性能数値はすべてベンダー報告であり、いずれも独立に再現されていません。

ドラフターが実際に変更するものと、変更しないもの

この仕組みは30秒かける価値がある。なぜなら、それが他のすべてを決めるからだ。トークンのデコードはメモリ律速である。GPUはほとんどの時間を、演算ではなく重みをSRAMへストリーミングするために費やしている。投機的デコーディングはこれを利用する。小さなモデルに次の複数トークンを一度に推測させ、その後、実際のモデルにその推測全体を1回のフォワードパスで検証させるのだ。推測が当たれば、ほぼ1トークン分のコストで9トークンを生成できたことになる。外れた場合、ターゲットモデルは自身のトークンを保持し、少し余分なコストを払うことになる。

変わるのは、1秒あたりのトークン数と、GPU使用率の推移です。変わらないのは、モデルの重み、コンテキストウィンドウ、ツール呼び出しの挙動、そして販売されている地域での価格です。LFM2.5-24B-A2B は総パラメータ数 24.0B、トークンあたりのアクティブパラメータ 2.45B を維持し、40 層をゲート付きショート畳み込みとグループ化クエリ注意に分割し、各ブロックに 64 のエキスパートを備えた top-4 ルーティング、131,072 トークンのコンテキスト、128,000 トークンの語彙を持ちます。ドラフターは 5 つの注意層、ランク 256 のマルコフヘッド、信頼度ヘッドを追加し、独自に保持するのではなくターゲットの埋め込みと LM ヘッドを再利用します。

1つの注意点が2つのリリースの間で移っており、一言触れる価値がある。8月には、LiquidのDSparkの記事が、出力されるシーケンスは「構造上、ベースラインのgreedyと同一」だと述べていた。一方、24Bドラフターのカードは、バッチ検証と通常のデコーディングの間の浮動小数点差が「greedyサンプリングの下でも含め、異なるテキストを生成し得る」と述べている。どちらの記述も擁護可能である——最初のものは厳密な算術では真である——が、評価ハーネスが出力をバイト単位で比較するなら、それが気づくことを想定しておくべきだ。

帳簿のコスト面

ドラフターはタダではない。GPU上ではBF16で655 MB（CPU上ではF16 GGUFで664 MB）を占有し、ターゲットと同じメモリプールに存在し、提案する各ステップには単一トークンではなくトークンのブロックに対する検証用フォワードパスが必要になる。MoEターゲットでは、この最後の点は見た目以上に高コストだ。9トークンを検証すると1トークンをデコードするより多くのエキスパートが活性化されるため、検証済みトークンあたりの移動バイト数は減るどころか増える。Liquidはまさにこれを、自社の8Bドラフターが高い受理率にもかかわらずM4 Max上で1.18×しか出せなかった理由として挙げた。

それに対して、節約量はGPU時間単位で測れるほど大きい。benchmarks/b300-fp8.csv、10億個の出力トークンを観測スループットで割るだけなら：

• MATH-500、同時実行数1 — 単独では324 tok/s（10億トークンあたり857 GPU時間）、ドラフター使用時は853 tok/s（326 GPU時間）。計算時間を2.63分の1に短縮。

• MATH-500、同時実行数256 — 単独では15,423 tok/s（18.0 GPU時間）に対し、ドラフター併用では27,579 tok/s（10.1 GPU時間）。1.79倍の削減。

• GSM8K、同時実行数256 — 単独では4,491 tok/s（61.9 GPU時間）に対し、ドラフター併用では9,660 tok/s（28.8 GPU時間）。2.15倍の削減。

• LiveCodeBench、同時実行数256 — 単独では18,812 tok/s（14.8 GPU時間）に対し、ドラフター併用では25,231 tok/s（11.0 GPU時間）。わずか1.34×の削減で、表の中で最も弱いセル。

これらはスループット比を時間に換算したものであり、金額に換算したものではない。金額はGPU時間あたりにいくら支払うかによって変わるうえ、本記事は単価を勝手にでっち上げるつもりはないからだ。しかし、順序関係はどの単価でも成り立つ。ドラフターを付けることは、低並列度の推論およびコード生成トラフィックでは10時間あたり2〜3時間分の価値があり、高並列度ではその約3分の1の価値になる。24Bのデプロイがワークステーション上のシングルユーザーエージェントなら、導入効果の根拠は強い。飽和したバッチエンドポイントなら、根拠は確かにあるが、2.4×という見出しが示唆するほどはかなり薄い。

作業負荷の観点で、ドラフターが元を取れるのはどこか

ベンダー表における8データセットのばらつきはノイズではない。それはプロンプトの種類に対応しており、この対応関係こそが今回のリリースで最も有用な点だ。Acceptanceは、MBPPの1ステップあたり6.70トークンからLiveCodeBenchの4.02まで幅があった。高スコアだったデータセットは、モデルの出力がプロンプトによって制約されるものだ——短い単体テスト形式の関数、検証可能な道筋のある算術、多肢選択式の回答。低スコアだったのは、モデルが長く制約のない解法を考案しなければならないもの、すなわち競技プログラミング問題とAIME形式の数学だ。

それが、自分の評価に持ち込むべき直感です。エージェント作業向けに販売される24B推論モデルは、出力トークンの大半を思考の連鎖の中で費やし、その様相はMBPPよりもLiveCodeBenchに近くなります。構造化抽出、スキーマ付き分類、固定のツール呼び出し形式に使われるモデルは、はるかに高受け入れ率の行に近くなります。自分のワークロードが前者なら、範囲の上限3.28×よりも下限1.34×に近いところに落ちると予想してください。このドラフターについてワークロード別の受け入れ率を公表した人はおらず、カードの8つのデータセットがガイドに最も近いものです。

それと対照的に、24Bは推論専用モデルだ。Liquidによれば、常に答える前に考える——チャットテンプレートが自動的に <think> タグを挿入する。これは投機にとって最悪の形だ。なぜなら推論区間はまさに長く、受け入れ率の低い区間だからだ。ドラフターはそれでも役立つ。最終回答では最も役立ち、最も時間がかかる部分では最も役立たない。

自分のハードウェアで、半日でどう見分けるか

上記のいずれも信頼する必要はありません。両方の推論パスはアクセプタンスカウンターを公開しており、これがあなたのトラフィック上でドラフターが元を取れているかどうかを決める唯一の数値です。

SGLangでは、ドラフターを接続したターゲットをブロックサイズ9、ドラフトトークン10で起動し、サーバーがリクエストごとに報告する投機的デコーディングのメトリクスを読み取ります。ベンダー表にある受け入れ率は、データセットに応じて0.33から0.65の間に収まります。該当する行を大きく下回る実行結果は、ドラフターが誤った推測をしており、高速化を獲得できないまま検証のコストだけを払っていることを意味します。F16 GGUFサイドカーを用いたllama.cppでは、レスポンスごとのタイミングにdraft_nとdraft_n_acceptedが直接含まれます。一方を他方で割ってください。

見落とすと1時間を無駄にする運用上の注意点が2つある。SGLangサーバーには、2026-08-31にマージされたLFM2-MoE DSparkパスを含むビルドが必要だ。それより古いビルドでは、ドラフターのアーキテクチャはそもそも認識されない。そしてブロックサイズはチェックポイントの属性であり、自由に設定できるパラメータではない。--spec-draft-n-maxをサイドカーのメタデータ値である9にクランプするため、12を指定しても何も得られない。

この比較では答えられない問い

「ドラフターを付けるべきか」にはGPUとは何の関係もないバージョンがあり、実際にほとんどのチームが直面するのはこちらだ。LFM2.5-24B-A2BをホステッドAPI経由で呼び出す場合、ドラフターの判断はあなたのものではない。サービングスタックが投機的デコーダを付けるか付けないかであり、あなたに見えるのは毎秒トークン数と価格だけで、どちらも上流で決められている。Liquid自身のConsoleでは、24Bが入力100万トークンあたり0.10ドル、キャッシュ済み入力0.05ドル、出力100万トークンあたり1.00ドルと掲載されている。これは公開レートであり、彼らが実行するデコード経路をすでに反映していて、予告なく変更される可能性がある。

そこが、ルーティングが複雑にするのではなく役立つ境界です。ホスト型の呼び出しとセルフホスト型のデプロイは、競合するプランというより、同じコスト調整ノブの2つの設定です。セルフホスティングとドラフターの組み合わせは、ボリュームがGPUを稼働させ続けるならトークンあたりのコストを最小化し、ホスト型エンドポイントは回答を得るための作業を最小化します。OrcaRouterは後者のために作られています — 1つのキーでプロバイダーの定価に対する0%のマークアップで200以上のモデルを利用でき、そのためベンダーの価格変更は当日に当社側へ反映され、プロバイダーが劣化した場合の自動フェイルオーバーと、単一のバックエンドをハードコードするのではなくトラフィックを分割するためのルーティングDSLを備えています。現在LFM2.5ファミリーは提供していないため、この特定のモデルについてホスト側はLiquid自身のAPIかご自身のGPUを意味します。比較する価値があるのは、当社が提供しているモデル、たとえばQwen3.6-35B-A3B — エージェントタスクでLiquidがベンチマークの比較対象としているモデル — またはGemma 4 26B-A4B。

では、それを添付するかどうか

LFM2.5-24B-A2B を適度な同時実行数で自分で提供していて、特に構造化出力や抽出形式の出力を扱う場合は、ターゲットモデルのそばに 655 MB の余裕があるなら、それをアタッチしてください。ベンダーの数値によると、そこでデコード時間はおよそ半分か3分の1になり、欠点は限定的です。悪いドラフターは検証パスを1回余分に消費するだけで、誤った回答にはなりません。

エンドポイントがすでに数百で飽和している場合、出力が長い自由形式の推論である場合、または採用を決める前にApple-siliconの数値が必要な場合は、オフにしておいてください——カードにはその数値はなく、同じファミリーの最も近い類似品はMacBookで1.18倍で提供されています。そして明らかに、モデルをまったく実行していない場合もオフにしておいてください。ドラフターはデプロイメントのための最適化であり、デプロイメントが存在するまで最適化するものは何もありません。

残りを決着させるのは、ベンダーの投稿とMacでの測定だ。2026-10-21時点でどちらも存在しない。重みがすでにダウンロード可能なリリースとしては奇妙な状態であり、アクセプタンスカウンターを自分で走らせる気がある人にとっては、ボード上で最初の独立した数値になる、異例に安上がりな機会でもある。