
LFM2.5-2.6B-DSpark: Liquidのオンデバイスエージェントを2.3倍高速化する328Mドラフター
- DeepSeekNEWDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 100万トークンあたり
- z-aiNEWZ.ai: GLM 5.32026-08-1860知能75コーディング
- obsidianNEWQwen3.8 27B2026-08-1552知能68コーディング
- qwenNEWQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekNEWDeepSeek: DeepSeek V4 Pro 08132026-08-1253知能69コーディング
- grokNEWSpaceXAI: Grok 4.62026-08-1261知能77コーディング
- metaMeta: Muse Spark 1.22026-08-0557知能72コーディング
- qwenQwen: Qwen3.8 Max2026-08-0358知能72コーディング
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152知能69コーディング
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 100万トークンあたり
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463知能78コーディング
- googleGoogle: Gemini 3.6 Flash2026-07-2152知能69コーディング
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137知能49コーディング
- metaMeta: Muse Spark 1.12026-07-1653知能71コーディング
- kimiMoonshotAI: Kimi K32026-07-1560知能76コーディング
- openaiOpenAI: GPT-5.6 Luna2026-07-0952知能71コーディング
- openaiOpenAI: GPT-5.6 Terra2026-07-0957知能77コーディング
- openaiOpenAI: GPT-5.6 Sol2026-07-0961知能77コーディング
Liquid AIの外部でLFM2.5-2.6B-DSparkを自社ハードウェアで実行し、その数値を公開した人はまだいない。このモデルを語る上で、正直な出発点はここだ。なぜなら、このモデルのすべてはパフォーマンスの主張だからだ。これはより優れた2.6Bモデルではなく、2.6BのエージェントモデルLFM2.5-2.6Bの前に配置され、検証用のトークンを提案する328Mパラメータのドラフトモデルである。それによって、エージェントは出力を変えることなく約2倍の速度で動作する。
2026年8月20日に、Hugging Face上の技術解説と、Liquid自身のブログ上の関連記事とともにリリースされたLFM2.5-2.6B-DSparkは、Liquidがその日に公開した投機的デコーディング用ドラフターチェックポイントの小さなファミリーの旗艦モデルです。以下の速度列の数値はすべてベンダー計測によるもので、まだ第三者による独立確認はされていません。リポジトリ内のすべての内容、フォーマット、フレームワーク対応は、ただ確認できる状態でそこにあります。
DSparkとは何か、ひとことで言えば
投機的復号化(スペキュラティブ・デコーディング)とは、低コストのドラフトモデルを本モデルの先頭で動かすテクニックだ。ドラフターが次の数トークンを推測し、ターゲットモデルがそのバッチ全体を一度のフォワードパスで検証して、一致したトークンを採用する。推測が当たっていれば、1回分のコストで複数トークンを進められるため、ターゲットモデルの重みに触れることなくスループットが向上する。DSpark — 2026年7月にDeepSeekの研究者らが最初に提案し、すでにDeepSeek-V4に搭載されているこのテクニック — は、そのトリックを小型のオンデバイスモデル向けに調整したバージョンだ。Liquidはこれを「信頼度スケジュール型投機的復号化」と呼んでおり、3つの構成要素がある。すなわち、すべてのドラフトトークンの隠れ状態を1回のパスで生成する並列バックボーン、隣接トークン間の依存関係をモデル化してブロック後半での受容率の低下を防ぐ軽量な逐次ヘッド、そして検証コストが節約効果を上回る場合に低信頼度のサフィックスを刈り込む検証器である。

この最後の点が、DSparkを単なるドラフターとは違うものにしている。つまり、常に完全なブロックを検証に通すわけではない。ドラフト自身の信頼度が、サフィックスが受け入れられる見込みが低いと判断した場合、ブロックを途中で打ち切り、無駄な計算を節約する。ドラフトブロックは9トークンなので、ターゲットは一度に最大10トークンを検証する。
数字で見る起草者
LFM2.5-2.6B-DSparkチェックポイントは、0.3Bパラメータのアテンションのみのドラフトモデルです。5つのフルアテンション層(隠れ層サイズ2,048、32ヘッドと8キー・バリューヘッドを備えたグループ化クエリアテンション)、128Kトークンの語彙、ランク256のマルコフヘッド、および信頼度ヘッドを備えています。Liquidは、AMDハードウェア上で、命令、会話、コード、関数呼び出しデータを混ぜたデータセットを用いて15エポック訓練し、損失が最も低いエポックではなく、受容率が最も高いエポックを選択しました。
その受理率は、ドラフターの価値を決める数値です。バッチサイズ1、温度0の5つのベンチマークにおいて、LFM2.5-2.6B-DSparkは、H100上では1デコードステップあたり平均4.83トークン、M4 Max上では4.42トークンが受理されました——これはブロックの約半分が受理されたことを意味し、そこから2倍の高速化が生まれます。
ラベル付きの高速化
以下の数値はすべて、Liquid AI 自身の測定によるものです——単一のH100 80GB上でのSGLang(BF16)、およびM4 Max MacBook Pro上でMetalバックエンドを用いたllama.cpp(FP16 GGUF)、バッチサイズ1、温度0——そして、本稿執筆時点でこれらのいずれも独立した第三者による再現はされていません:
• H100平均 — 2.67×、323〜864 トークン/秒。ベンチマーク別: MATH500 3.06×、HumanEval 2.56×、MBPP 2.64×、GSM8K 2.22×、MT-Bench 2.87×。
• M4 Max 平均 — 2.27倍、61〜139 tokens/s。ベンチマーク別: MATH500 2.25倍、HumanEval 2.63倍、MBPP 2.11倍、GSM8K 2.36倍、MT-Bench 1.99倍。
• ツール呼び出し — マルチツール関数呼び出しシナリオでは、平均レイテンシが57%低下しました。
• ファミリーの文脈 — ファミリー内で最大のドラフターであるLFM2.5-8B-A1B-DSparkはH100上で最大3.18倍を記録し、1.2BドラフターはM4 Max上で最大2.87倍を記録しました。上記の2.6Bの数値は中間に位置するものです。

これらの数値について、平均値以上に重要な点が2つある。第一に、それらは温度0・バッチサイズ1で測定されている。これは投機を有利にする構成であり、インタラクティブなオンデバイスエージェントの作業がほとんど該当する構成でもある。同一性の保証もここで成り立つ。投機的デコードは提案されたすべてのトークンを検証するため、貪欲デコードのもとでは、出力されるテキストはターゲットが単独で生成したものと完全に一致する。第二に、並行性が高まるにつれてその差は縮まる。単一のH100上では、LiquidはDSparkの優位性がバッチサイズ128付近で収束すると報告している。つまり、ドラフターモデルは、インタラクティブでツールを多用するワークロードではレイテンシ面で効果を発揮するが、フル稼働のサーバーにおける生のスループットを向上させる特効薬ではない。
確認されていることと、確認されていないこと
確認済みです。リポジトリが公開されており検証可能という意味で、以下が事実です。ドラフターはSafetensors(BF16)およびGGUF形式で提供され、ベースモデルではなくポストトレーニング済みのLFM2.5-2.6Bとペアになります。初日からllama.cpp(実験的なMetalカーネルを含む)とSGLangでサポートが導入されました。ライセンスはLiquidのLFMオープンライセンスv1.0に基づきます。そして、これを前提に計画を立てる人にとって重要な点ですが、モデルカードには推論プロバイダーがこのモデルを提供していないと明記されているため、これは自己実行コンポーネントです。
まだ確認されていないのは、その高速化が他のハードウェアや構成でも再現されるか(Liquidの外部では誰も測定結果を公表していない)、ドラフターがグリーディデコーディングではなくサンプリング時にどのように動作するか、そして57%のツール呼び出しレイテンシという数値が、Liquidが使用したベンチマークハーネス以外の実際のエージェントハーネスでも維持されるかどうかである。これらのいずれも非難ではない——リリースはまだ1日前だ——しかし、それらは有望な数字と検証済みの数字との違いである。

それを実行する
SGLangでは、DSparkサポートを含むビルドを使用し、対象モデルに対してサーバーを起動して、ドラフターを指定します。投機的アルゴリズムはDSPARKで、ドラフトモデルのパスはLiquidAI/LFM2.5-2.6B-DSparkを指し、ブロックサイズはドラフトのconfig.jsonから読み取られます。llama.cppでは、ターゲットGGUFをロードし、ドラフトGGUFをドラフトモデルとして指定して、スペックタイプをdraft-dsparkに設定します。ブロックサイズはサイドカーメタデータから読み取られます。両方の統合はアップストリームに含まれているため、フォークは不要です。それらを含む十分に新しいビルドが必要なだけです。
追加する価値があるとき
LFM2.5-2.6B-DSparkは、Liquidが設計した本来の配置先、つまり電話、ラップトップ、エッジボックス上で2.6Bエージェントを実際にデプロイし、レイテンシ制約がありグリーディ実行される対話型またはツール呼び出しワークロードを実行する場合に、約0.3GBの追加メモリに見合う価値を発揮します。まさにそのプロファイルこそ、2.27倍のオンデバイス数値と57%のツール呼び出しレイテンシ削減が効果を発揮する場面です。サーバー上でハイバッチの推論を行う場合(高速化は1倍に収束します)や、温度がゼロより高いワークロード(報告された数値が適用されなくなります)では、その価値は薄れます。また、このファミリーの8B-A1Bバリアントを使用している場合は、エッジケースに注意してください。現時点ではそのオンデバイス高速化は約1.18倍にすぎません。ドラフトトークンの検証により、llama.cppのMetalバックエンドでより多くのエキスパートがアクティブ化されるためです。Liquidはこれを既知の問題として明示しています。
DSparkによって、2.6Bエージェントが実行される場所が変わることはありません。設計上、これはセルフホストが前提の話であり、すでに呼び出しているホスト型モデルと並んで配置されます。ローカルドラフターと十数個のAPIエンドポイントの組み合わせは、まさにルーティングレイヤーが解消するために存在する種類の配管です。200以上のモデルを1つのAPIキーで使い、プロバイダーが劣化したら自動フェイルオーバーし、プロバイダーの定価を0%マークアップでそのまま通す——これにより、2.6Bクラスのエージェントのローカル対ホスト型のコスト比較が、スプレッドシートに埋もれることなく、明確に読み取れるままになります。
今日のLFM2.5-2.6B-DSparkを正しく捉えるなら、実際にダウンロードして実行できるチェックポイントに付随した、有望だがベンダー計測のみで、まだ独立した検証を受けていない速度主張として見ることです。2.6Bエージェントをオンデバイスで展開するなら、ドラフターは試すのも簡単で、外すのも簡単です。SGLangコマンドに2つの投機的フラグを追加し、グリーディーデコーディングを維持したまま、2.3倍という数字を信じる前に、自分のワークロードで測定してください。リポジトリは用意されています。独立した検証が残された課題です。
