- DSparkでLFM2.5の推論がGPU最大3.18倍、端末最大2.87倍に
- 関数呼び出しの遅延を平均57%削減、エッジ向けに有効
- llama.cppとSGLangに初日対応、オープンソースで利用可能
発表の概要
Liquid AIは2026年8月20日、同社のLFM2.5シリーズを対象にしたDSparkドラフトモデルを公開しました。DSparkは投機的デコーディングを応用した推論高速化手法です。GPU上では最大3.18倍、Apple M4 Max搭載MacBook Pro上では最大2.87倍のスループット改善が確認されています。関数呼び出しを使う複数ツールのシナリオでは、LFM2.5-2.6Bの遅延を平均57%削減すると報告されています。
ドラフトモデルのチェックポイントはHugging Faceで公開され、SafetensorsとGGUFの両形式が用意されています。llama.cppとSGLangには初日から実装が取り込まれ、オープンソースとして利用できる状態です。これにより、開発者は自前の環境で高速化を試せるようになります。
DSparkの仕組み
LLMのデコードフェーズは、計算そのものよりDRAMからSRAMへの重み読み出しがボトルネックになることが知られています。投機的デコーディングでは、軽量なドラフトモデルが候補トークンを生成し、ターゲットモデルがその候補を1回のフォワードパスで一括検証します。重みの読み出しコストを複数トークンで共有できるため、高速化につながります。
DSparkは、DFlashが提案する並列バックボーンと、トークン間の依存関係をモデル化する軽量な逐次ヘッド、そして検証コストが利益を上回るときに低信頼度の接尾辞を枝刈りする信頼度スケジューリングを組み合わせた手法です。ドラフトモデルは5層、ブロックサイズ9のアテンションのみの構造で、パラメータ数は約3億とされています。
品質と性能評価
DSparkは貪欲デコードでの出力をターゲットモデル単体と同一に保ちます。ドラフト候補が拒否された場合はターゲットモデル自身のトークンが採用されるためです。そのため、pass@1やexact matchなどのベンチマーク精度は変わらないと説明されています。
性能面では、LFM2.5-2.6BはMacBook上で特に効果が大きく、データセットによっては毎秒約140トークンに達します。一方、LFM2.5-1.2B-Instructではデータセット依存のばらつきが大きく、高速化率は最大52%の幅があります。LFM2.5-8B-A1Bではオンデバイスの平均改善が18%にとどまっており、llama.cppのMetalバックエンドにおけるMoE実装の制約が要因とみられます。
利用方法と注意点
SGLangで使うには、DSparkサポートを含むビルド（PR #31041）が必要です。起動時に--speculative-algorithm DSPARKと--speculative-draft-model-pathでドラフトモデルを指定します。llama.cppではPR #27383のビルドを使い、-mdでドラフトモデルを指定します。ブロックサイズはconfig.jsonまたはサイドカーメタデータから読み込まれます。
評価はH100 80GBとM4 Max MacBook Proで、それぞれBF16とFP16 GGUF、バッチサイズ1、温度0の条件で行われています。品質を保ちつつ高速化できる一方、MoEモデルではバックエンドの実装次第で効果が限定的になる点に注意が必要です。
| 項目 | 通常のデコード | DSpark |
|---|---|---|
| トークン生成 | 1トークンずつ生成 | ドラフトモデルが候補を生成し、ターゲットモデルが一括検証 |
| 重み読み出し | 生成トークンごとに必要 | 複数トークンで読み出しコストを共有 |
| 出力品質 | 基準 | 貪欲デコードではターゲット単体と同一 |
Speculative decoding is exact: the target verifies every proposed token, so greedy output equals the target alone; per-response timings report draft_n / draft_n_accepted.
投機的デコードは厳密です。ターゲットモデルが提案されたすべてのトークンを検証するため、貪欲デコードの出力はターゲット単体の場合と一致します。レスポンスごとのタイミングにはdraft_n / draft_n_acceptedが報告されます。
今後の見通し
DSparkはllama.cppとSGLangに初日対応したことで、オープンソースの推論基盤における投機的デコーディングの選択肢が広がりました。今後はMoEモデル向けのMetalバックエンド最適化や、ほかのターゲットモデルへの対応が進むとみられます。実際にどの程度の高速化が得られるかは、利用するデータセットや関数呼び出しの頻度によって変わるため、自社のワークロードで計測することが次の判断材料になります。DSparkの受け入れ率やバックエンド別の挙動が詳細に公開されれば、導入の見極めがしやすくなると考えられます。
日本の開発者・IT企業にとっての意味
日本企業にとっては、エッジ端末でのLLMエージェントや、関数呼び出しを多用する業務システムに直接関係します。llama.cppとSGLangの両方が初日対応しているため、既存の推論スタックに組み込みやすく、LFM2.5のGGUF形式を使えばローカル環境でも検証できます。API経由の外部モデルに依存せず、自社のデータを外部に出さずに推論したいケースでは、オンデバイスでの高速化は有力な選択肢になります。一方、MoEモデルでは実装によって効果が限定的な例が示されており、採用時にはモデル構造とバックエンドの組み合わせを確認する必要があります。
気になる点
- DSparkを使うと生成品質は変わる?
- 貪欲デコードでは、ドラフト候補がターゲットモデルの分布と一致しない場合、ターゲットモデル自身のトークンで置き換えられます。そのため出力はターゲット単体と同一になり、pass@1やexact matchなどの精度は変わらないと説明されています。
- llama.cppやSGLangで使うには?
- SGLangではDSparkサポートを含むPR #31041のビルドが必要です。起動時に--speculative-algorithm DSPARKと--speculative-draft-model-pathを指定します。llama.cppではPR #27383のビルドを使い、-mdでドラフトモデルを指定します。対応したSafetensorsとGGUFがHugging Faceで公開されています。
- GPUとMacのどちらでも使える?
- GPUはH100 80GBとSGLang、オンデバイスはM4 Max MacBook Proとllama.cppのMetalを使って評価されています。どちらでもドラフトモデルによる高速化が確認されていますが、MoEモデルではMetalバックエンドの制約で改善が限定的です。
用語解説
- 投機的デコード
- 軽量なドラフトモデルが候補トークンを生成し、ターゲットモデルがまとめて検証する高速化手法。
- DSpark
- 投機的デコーディングを発展させた高速化手法。DFlashやEAGLE-3のアイデアに加え、信頼度に基づく枝刈りを組み合わせる。
- LFM2.5
- Liquid AIが開発した大規模言語モデル。1.2B、2.6B、8B-A1Bなどのサイズがある。
- SGLang
- LLM推論を高速化するオープンソースのフレームワーク。
- llama.cpp
- C/C++で実装されたオープンソースのLLM推論エンジン。
- MoE
- 複数の専門エキスパートを入力に応じて切り替えるモデル構造。
出典
Up to 3.2x Faster Inference with LFM2.5-DSpark
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する