LFM2.5-DSpark：H100 から MacBook まで最大 3.2 倍高速な推論
本日、LFM2.5 ファミリーの 3 つのモデル、LFM2.5-1.2B-Instruct、先日リリースした LFM2.5-2.6B、LFM2.5-8B-A1B 向けの DSpark [1] ドラフトモデルのチェックポイントを公開します。これにより投機的デコーディングの経路が加わり、出力品質を変えることなく、わずかなメモリ増加と引き換えにデコードを大幅に高速化できます。ドラフトモデルは、GPU で最大 3.18 倍、オンデバイスで最大 2.87 倍のスループット向上を達成しています。
Liquid Foundation Models（LFM）向けの投機的デコーディングモデルを一般公開するのは、今回が初めてです。実際の推論特性を踏まえてモデルアーキテクチャと投機手法を協調設計することは、今後のモデル設計において極めて重要な要素になると考えています。
LFM2.5-1.2B-Instruct、LFM2.5-2.6B、LFM2.5-8B-A1B 向けの DSpark ドラフトモデルは、本日より Hugging Face で利用できます。また、LFM に対応した DSpark の統合は、llama.cpp と SGLang のアップストリームにオープンソースとして取り込まれています。実行方法はモデルカードをご覧ください。
DSpark の仕組み
LLM 推論のデコードフェーズは、従来からメモリ律速です。レイテンシの大半は、高負荷な計算ではなく、DRAM から SRAM への重みの転送によって生じます。これは NVIDIA H100 のような高性能 GPU でも、MacBook や iPhone のようなエッジデバイスでも同様です。
投機的デコーディングは、軽量なドラフトモデルで候補トークンを生成することでこの問題に対処します。ターゲットモデルはそれらを 1 回のフォワードパスでまとめて検証するため、重みの読み込みコストを検証対象のすべてのトークンで分担できます。
これまでに投機的デコーディングのさまざまな手法が提案されてきました。代表的なものとして EAGLE-3 [2]、DFlash [3]、そして最新の DSpark があります。DSpark は次の 3 つの要素を組み合わせています。
- DFlash 型の並列バックボーン：ターゲットモデルのコンテキスト特徴量を条件とし、ブロック全体に対して 1 回のフォワードパスを実行して、 個のドラフトトークンそれぞれの隠れ状態とベースロジットを生成します。
- 軽量なシーケンシャルヘッド：隣接トークン間のマルコフ連鎖としてモデル化され、各位置のロジットを、直前にサンプリングされたトークンと整合する続きへと寄せるようにバイアスをかけます。これにより、DFlash のアプローチにはないドラフトトークン間の依存関係が加わり、後方の位置での受理率が向上します。
- 信頼度スケジューリング型ベリファイア：別のヘッドが、それ以前のトークンがすべて受理されたことを条件として、各ドラフトトークンの受理確率を予測します。そして、ハードウェアを考慮したスケジューラが、低信頼度のサフィックスの検証に要するバッチ容量がその価値を上回る場合に、それらを刈り込みます。
学習
DSpark のレシピに従いつつ、データミクスチャを拡張して、より大規模で多様なデータセット群で学習しました。最終的なコーパスは、SFT、チャット、コード、関数呼び出しのデータを組み合わせたものです。
層数、ブロックサイズ、モデルアーキテクチャなどの最適な設定を見つけるため、学習データセット全体の一部を用いてアブレーションを実施しました。ドラフトモデルの初版では、簡略化した Attention のみのドラフトモデルを採用しています。アブレーションの結果、5 層・ブロックサイズ 9 に決定しました。各ドラフトモデルについて、データセット全体で 15 エポックの学習を行いました。
各エポックで、検証損失とターゲットベンチマーク全体での受理率を測定しました。図 1 に示すとおり、3 つのモデルの挙動は同じではありません。LFM2.5-1.2B-Instruct では、受理率がエポックを重ねるごとに一貫して向上し、検証損失の低下とよく連動しています。LFM2.5-2.6B は最初の数エポックで向上した後に頭打ちとなり、受理率は損失よりもかなり早い段階で横ばいになります。LFM2.5-8B-A1B は最も不安定で、トークン数の増加に伴い検証損失は低下するものの、受理率の向上にはつながりません。
つまり、検証損失は LFM2.5-1.2B-Instruct のドラフトでは学習中の指標として有用ですが、より大きなドラフトでは、重視すべきベンチマークでの受理率が伸びなくなった後も損失だけが改善し続けます。そのため、最終的に公開するチェックポイントは、損失ではなく受理率が最も高いエポックを基準に選択しました。
表 1 に示すとおり、得られたドラフトモデルはいずれも約 300M パラメータと比較的小規模です。各モデルの学習とすべてのアブレーション研究は、Liquid AI の学習フレームワークを用いてAMD ハードウェアのみで実施しました。
コンポーネント | 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 |
マルコフヘッド | 33.6M | 65.5M | 65.5M |
正規化層 + 信頼度ヘッド | 27.5k | 27.5k | 27.5k |
合計 | 295.7M | 327.7M | 327.7M |
品質の同等性
貪欲デコーディングでは、ドラフトトークンはターゲットモデルの分布と一致する場合にのみ受理されます。棄却された場合は、ターゲットモデル自身のトークンがその位置に入ります。したがって、出力されるシーケンスは構造上ベースラインの貪欲デコーディングと同一となり、ベンチマーク精度（pass@1 や完全一致）は変わりません。
推論の高速化
LFM2.5 向けの DSpark ドラフトモデルは、リリース初日から推論エコシステム全体でサポートされています。
- llama.cpp — 効率的なエッジ推論のための GGUF チェックポイント
- SGLang — 本番環境のスループットを支える GPU 高速化サービング
SGLang の実装は DSpark の公式 SGLang 実装をベースにしており、llama.cpp の実装は公式コードベースをベースにしています。llama.cpp は実験的な Metal カーネルを使用して実行しています。
オンデバイスのスループットは、M4 Max 搭載の MacBook Pro 上で llama.cpp と Metal を使用し、FP16 の GGUF 重み、バッチサイズ 1、温度 0、最大 256 出力トークンの条件で測定しました。GPU のスループットは、単一の H100 80 GB 上で SGLang を使用し、BF16、バッチサイズ 1、温度 0 の条件で測定しました。どちらの構成も DSpark のブロックサイズは 9 とし、5 つのベンチマークデータセット（MATH500、GSM8K、HumanEval、MBPP、MT-Bench）で評価しています。
表 2 は LFM2.5-2.6B のスループット結果です。大規模アクセラレータ（H100）とエッジ環境（M4 Max 搭載 MacBook）のいずれにおいても、多様なデータセットにわたってスループットが顕著に向上しています。特に MacBook での高速化は目覚ましく、ユーザーが体感できるインタラクティブ性を、多くのプロプライエタリなクラウドモデルが提供するスループットをはるかに上回る水準（データセットにより約 140 tok/s）にまで引き上げます。
データセット | 受理トークン数（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 |
LFM2.5-2.6B の主な目標は、オンデバイスで実用に耐える初のエージェント型モデルにすることでした。エージェント型のワークロードでは、モデルはツール呼び出しのたびに思考を行い、ユーザーはその間ずっと待たされます。投機的デコーディングが最も効果を発揮するのはまさにこの場面です。図 2 では、BFCL データセット [4] で関数呼び出しをテストし、レイテンシへの最終的な影響を示しています。さまざまな複数ツールのシナリオにおいて、DSpark はレイテンシを平均 57% 削減しました。
LFM2.5-1.2B-Instruct でも同じテスト環境を使用しました。表 3 に LFM2.5-1.2B-Instruct のスループット結果を示します。なお、2.6B モデルとは異なり、1.2B は非推論（non-reasoning）モデルです。1.2B ではデータセットごとの受理率のばらつきがはるかに大きく、基となるテキストの分布によって高速化の度合いが最大 52% 変動します。
データセット | 受理トークン数（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-8B-A1B では、推論がより難しくなります。受理率は 2 つの Dense モデルと比べて高くなります（8B-A1B も思考型モデルです）が、実環境で観測される高速化にはそれが反映されません。表 4 に示すとおり、GPU では平均 2.54 倍という妥当なスループット向上を達成できる一方、エッジデバイスでは 18% の向上にとどまります。これは、llama.cpp の Metal バックエンドにおける現行の MoE 実装に加え、k 個のトークンの検証では 1 回のデコードステップよりも多くのエキスパートが活性化され、その分重みの転送量が増えることによるものです。この点は今後の課題とし、透明性のためにこれらの数値も公開します。
データセット | 受理トークン数（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 |
インタラクティブ性
高速化はバッチサイズ 1 のシナリオに限りません。システム全体の総スループットと、異なる同時実行レベルで個々のユーザーが体感するスループット、すなわちインタラクティブ性とのトレードオフを考えてみましょう。
同時実行数を増やすと演算強度が高まり、メモリ律速から計算律速の領域へと徐々に移行します。この演算強度の増加は、ターゲットモデルが検証すべきドラフトトークンによってさらに増幅されます。その結果、DSpark を使用したモデルとベースラインモデルとの累積的な高速化の差は縮まっていきます。
すべてのテストは、信頼度スケジューリング型ベリファイアを使用せず、単一の H100 上の SGLang で実行しました。DSpark の信頼度ヘッドはリクエストごとに検証するトークン数を動的に削減できますが、今回の実験では、削減によって失われるトークンのコストが節約できる計算量を上回ったため、固定の検証ウィンドウで提供しています。
図 4 に示すとおり、LFM2.5-1.2B-Instruct ではインタラクティブ性がやや良好で、バッチサイズ 128 でも DSpark が明らかに優位です。
LFM2.5-8B-A1B の高い受理率は、図 5 のインタラクティブ性のグラフにはっきりと表れています。すべてのデータセットと同時実行レベルにおいて、GSM8K のように受理率が比較的低いデータセットでも、DSpark はベースモデルを上回っています。その根本的な理由は、バッチ処理と投機的デコーディングがいずれもモデルのより大きな同じ部分を活性化させるためです。同時実行数が高くなるとベースラインも同じコストを負担することになり、そのオーバーヘッドは投機的デコーディングだけの不利にはならなくなります。
今すぐ始める
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
LFM2.5 によって、私たちはどこでも動作する AI というビジョンを実現しつつあります。これらのモデルの特長は次のとおりです。
- オープンウェイト — 制限なくダウンロード、ファインチューニング、デプロイが可能です。
- 初日から高速 — llama.cpp（報告した数値はこちらの PR の実験的カーネルで達成したもの）と SGLang にリリース初日から対応しています。
- モデルファミリー — 3 つのサイズから、デプロイ要件に応じて精度とフットプリントのバランスを選べます。
参考文献
[1] Cheng et al. (2026). DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. https://arxiv.org/abs/2607.05147
[2] Li et al. (2025). EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test. https://openreview.net/forum?id=4exx1hUffq
[3] Chen et al. (2026). DFlash: Block Diffusion for Flash Speculative Decoding. https://arxiv.org/abs/2602.06036
[4] Patil et al. (2025). The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models. https://proceedings.mlr.press/v267/patil25a.html
引用
引用する際は、以下の参考文献または BibTeX をご利用ください。
Liquid AI, "LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook", Liquid AI Blog, Aug 2026.
@article{liquidAI2026dspark,
author = {Liquid AI},
title = {LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook},
journal = {Liquid AI Blog},
year = {2026},
note = {www.liquid.ai/blog/lfm2.5-dspark},
}