記事のサマリー（TL;DR）
- Liquid AIがLFM2.5-1.2B/2.6B/8B-A1B向けDSparkドラフトモデルを公開。H100で最大3.18倍、M4 Max MacBookで最大2.87倍のスループット向上
- 出力品質は変わらず：グリーディデコード下でターゲットモデルと完全同一の出力を保証するため、ベンチマーク精度（pass@1 / exact match）は不変
- llama.cpp（PR#27383）とSGLang（PR#31041）に初日からオープンソース対応。Safetensors・GGUFの両形式でHugging Faceから取得可能
生成AIオンデバイス推論・エージェント活用を検討する開発者が押さえるべきポイント
Liquid AIが今回リリースしたDSparkドラフトモデルは、サーバーGPU（H100）だけでなく、M4 Max MacBook ProというコンシューマーデバイスでもLFM2.5-2.6Bが約140 tok/s前後を達成するという点が実務上の意味を持ちます。多くのクラウドプロプライエタリAPIが提供するスループットと同等以上の速度をエッジで実現できることは、ネットワーク遅延が問題になるエージェント型ユースケースや、データをクラウドに送りたくない業務用途（社内文書処理・ローカルファンクションコールなど）での選択肢を広げます。国内では、kintoneやSalesforce・freeeなどの業務SaaSと連携するAIエージェントを構築する際、API呼び出しのレイテンシがユーザー体験の決定要因になるケースが多く、ファンクションコール遅延を平均57%削減できるという数値は直接的な効果として現れます。また、llama.cppへのDay-1対応はオープンソースの推論スタックを社内で運用している開発チームにとって採用障壁を下げます。
詳細
DSpark の仕組み
LLM推論のデコードフェーズは従来、メモリバウンドな処理です。レイテンシのほとんどはDRAMからSRAMへの重みのストリーミングに起因し、計算量自体は主なボトルネックではありません。
Speculative Decoding（投機的デコーディング）はこの課題に対処するアプローチで、軽量なドラフトモデルが候補トークンを生成し、ターゲットモデルが1回のフォワードパスでそれらをまとめて検証します。重みロードのコストを複数トークンで分担することで、実効スループットを大幅に高めます。
DSpark は既存手法の中でも最新のアプローチで、3つのコンポーネントを組み合わせています。
- DFlashスタイルの並列バックボーン：ターゲットモデルのコンテキスト特徴を条件として、全ドラフトトークンの隠れ状態を1回のフォワードパスで生成
- 軽量シーケンシャルヘッド（Markovチェーン）：隣接トークン間のトークン間依存関係を追加し、後方ポジションでの受理率を向上
- 信頼度スケジュール付きベリファイア：各トークンの生存確率を予測し、検証コストが節約分を上回る低信頼度のサフィックスを枝刈り
学習とアーキテクチャ
DSpark レシピに従い、SFT・チャット・コード・ファンクションコールデータをカバーするより大規模かつ多様なデータミックスで学習を実施しています。アブレーション実験に基づき、初版のドラフトモデルはAttentionのみの簡略化した構成（5レイヤー、ブロックサイズ9）を採用しています。各ドラフトモデルはデータセット全体で15エポック学習し、損失最小ではなく受理率最大のエポックを選択しています。
結果として生成されたドラフトモデルは約300Mパラメータと比較的小型です。
| コンポーネント | LFM2.5-1.2B-Instruct | LFM2.5-8B-A1B | LFM2.5-2.6B |
|---|---|---|---|
| デコーダースタック（5層） | 241.2M | 241.2M | 241.2M |
| 隠れ状態プロジェクション | 21.0M | 21.0M | 21.0M |
| Markovヘッド | 33.6M | 65.5M | 65.5M |
| ノルム + 信頼度ヘッド | 27.5k | 27.5k | 27.5k |
| 合計 | 295.7M | 327.7M | 327.7M |
品質の同一性保証
グリーディデコード下では、ドラフトトークンはターゲットモデルの分布と一致する場合のみ受理されます。棄却された場合はターゲットモデル自身のトークンが代わりに使用されます。出力シーケンスは設計上、ベースラインのグリーディと完全に同一であるため、ベンチマーク精度（pass@1 または exact match）は変わりません。
CPU・GPU での推論速度向上
DSparkドラフトモデルはllama.cpp（Metal実験カーネルで動作する公式コードベース上に実装）とSGLang（DSpark の公式SGLang実装上に構築）へのDay-1サポートと共にリリースされています。
測定条件
- オンデバイス：llama.cpp + Metal、M4 Max MacBook Pro、FP16 GGUFウェイト、最大256出力トークン
- GPU：SGLang、H100 80GB × 1枚、BF16
- 共通設定：DSparkブロックサイズ9、バッチサイズ1、温度0
LFM2.5-2.6B の速度向上
| データセット | 受理数（10中） | H100 高速化 | M4 Max 高速化 |
|---|---|---|---|
| MATH500 | 5.42 | 3.06x（326→1000 tok/s） | 2.25x（61→137 tok/s） |
| HumanEval | 4.54 | 2.56x（326→835 tok/s） | 2.63x（61→161 tok/s） |
| MBPP | 4.71 | 2.64x（326→861 tok/s） | 2.11x（62→132 tok/s） |
| GSM8K | 4.32 | 2.22x（312→693 tok/s） | 2.36x（60→143 tok/s） |
| MT-Bench | 5.07 | 2.87x（325→933 tok/s） | 1.99x（62→123 tok/s） |
| 平均 | 4.81 | 2.67x（323→864 tok/s） | 2.27x（61→139 tok/s） |
複数ツールを使うマルチツールシナリオ全体で、DSpark は LFM2.5-2.6B のレイテンシを平均57%削減しています。
LFM2.5-1.2B-Instruct の速度向上
| データセット | 受理数（10中） | H100 高速化 | M4 Max 高速化 |
|---|---|---|---|
| MATH500 | 6.02 | 2.56x（668→1712 tok/s） | 2.62x（140→366 tok/s） |
| HumanEval | 5.31 | 2.26x（664→1499 tok/s） | 2.87x（136→389 tok/s） |
| MBPP | 5.52 | 2.37x（667→1578 tok/s） | 2.74x（137→375 tok/s） |
| GSM8K | 4.34 | 1.67x（624→1041 tok/s） | 2.73x（140→381 tok/s） |
| MT-Bench | 3.90 | 1.66x（657→1091 tok/s） | 1.72x（137→237 tok/s） |
| 平均 | 5.02 | 2.10x（656→1384 tok/s） | 2.54x（138→350 tok/s） |
LFM2.5-1.2B-Instruct はデータセットによって受理率のばらつきが大きく、テキスト分布の違いによって速度向上幅が最大52%変動します。
LFM2.5-8B-A1B の速度向上
| データセット | 受理数（10中） | H100 高速化 | M4 Max 高速化 |
|---|---|---|---|
| MATH500 | 8.27 | 3.18x（428→1362 tok/s） | 1.21x（93→112 tok/s） |
| HumanEval | 7.02 | 2.58x（426→1100 tok/s） | 1.12x（91→101 tok/s） |
| MBPP | 6.93 | 2.64x（426→1122 tok/s） | 1.09x（89→97 tok/s） |
| GSM8K | 4.02 | 1.29x（385→496 tok/s） | 1.44x（90→129 tok/s） |
| MT-Bench | 8.52 | 3.02x（426→1288 tok/s） | 1.04x（87→90 tok/s） |
| 平均 | 6.95 | 2.54x（418→1074 tok/s） | 1.18x（90→106 tok/s） |
LFM2.5-8B-A1B は受理率こそ高いものの、オンデバイスでは平均18%の改善にとどまっています。これはllama.cppのMetalバックエンドにおける現行のMoE実装の制約と、k個のトークンを検証する際により多くのエキスパートが活性化され、シングルデコードステップよりも多くの重みトラフィックが発生するためです。
LFM2.5-DSpark の使い方
SGLang での実行
DSParkサポートが含まれたSGLangビルド（PR#31041）が必要です。以下のコマンドでターゲットモデルにドラフトモデルをアタッチして起動します。
python -m sglang.launch_server \
--model-path LiquidAI/LFM2.5-2.6B \
--speculative-algorithm DSPARK \
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark \
--speculative-draft-attention-backend flashinfer \
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
起動後、http://localhost:30000/v1 のOpenAI互換エンドポイントにクエリを投げます。ブロックサイズはドラフトの config.json から読み込まれます。ベースラインは --speculative-* フラグ3つを除いた同コマンドです。
llama.cpp での実行
llama.cppの対応ビルド（PR#27383）が必要です。
llama-server -m LFM2.5-2.6B-F16.gguf \
-md LFM2.5-2.6B-DSpark-F16.gguf \
--spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 \
-fa on -ngl 99
ブロックサイズはサイドカーメタデータから読み込まれます（n-max がそれでクランプされます）。投機的デコーディングは厳密（exact）です。ターゲットが提案された全トークンを検証するため、グリーディ出力はターゲット単独と同一になります。
モデルの入手先
DSparkドラフトモデルのチェックポイントはHugging Face上でSafetensorsおよびGGUF形式で公開されています。
Safetensors形式
- LFM2.5-2.6B-DSpark
- LFM2.5-1.2B-Instruct-DSpark
- LFM2.5-8B-A1B-DSpark
GGUF形式
- LFM2.5-2.6B-DSpark-GGUF
- LFM2.5-1.2B-Instruct-DSpark-GGUF
- LFM2.5-8B-A1B-DSpark-GGUF