Liquid AI、LFM2.5にDSparkドラフトモデルを追加—H100 1基でデコードを最大3.18倍高速化

Liquid AIは8月20日、LFM2.5-1.2B-Instruct、2.6B、8B-A1B向けのDSparkドラフトモデルを公開し、Safetensors、GGUF、llama.cpp、SGLangとの統合も提供した。これは量子化やメインモデルの変更ではない。デコード時に、約2億9,600万〜3億2,800万パラメータの軽量モデルが一連の候補tokenを先に提案し、ターゲットモデルが1回のforward passでまとめて検証する仕組みだ。

DSparkのドラフターは、並列backbone、隣接するtoken間の依存関係を表現する逐次的なMarkov head、さらに生存確率に基づいて信頼度の低いsuffixを枝刈りするverifierを組み合わせている。これにより、完全並列ドラフターで一般的な問題に対処する。候補シーケンスが長くなるほど、後半のtokenは先行コンテキストへの依存関係が不足して拒否されやすくなり、検証に失敗した候補が計算資源を浪費してしまうためだ。

Liquid AIはbatch size 1、temperature 0でテストを実施した。8B-A1BはH100 80GB上のMATH500で428 token/sから1,362 token/sへ向上し、3.18倍の高速化を達成した。一方、M4 Maxでの平均高速化は1.18倍にとどまった。チームはその原因として、llama.cppのMoE向けMetal実装と、複数tokenの検証によってより多くのexpertが起動する点を挙げている。2.6Bは5種類のテストにおいて、H100で平均2.67倍、M4 Maxで平均2.27倍高速化し、複数ツールを使用するシナリオではレイテンシーが平均57%低減した。

greedy decodingでは、候補はターゲットモデルの分布と一致する場合にのみ受け入れられる。拒否された場合はメインモデルのtokenが使用されるため、出力をベースラインと一致させられる。ただし、この「品質が変わらない」という結論を、temperatureを設定したsampling、long context、複数ユーザーの並行処理、メモリ制約のあるサービスへ直接一般化することはできない。確認時点では、SGLangのLFM2サポートPRはまだマージされていなかった。エンジニアリングチームは本番環境への導入を決める前に、自社のprompt分布における平均acceptance length、ピークメモリ使用量、並行処理時のthroughputを改めて検証すべきだ。