LFM2.5にDSparkドラフトモデルを追加、H100のデコードスループットが最大3.18倍に

Liquid AIは、LFM2.5-1.2B-Instruct、LFM2.5-2.6B、LFM2.5-8B-A1B向けのDSparkドラフトモデルを公開し、ネイティブ形式とGGUF形式のチェックポイントを提供した。約3億パラメータのこれらのsidecarモデルは最終回答を生成するのではなく、まず候補token列を提示し、それを元のモデルが一括で検証する。サンプリングと検証が正しく実装されていれば、ターゲットモデル本来の出力分布を維持できる。

DSparkが一般的な並列ドラフターと異なる点は、並列backboneの後段に軽量な逐次モジュールを追加し、同じ候補ブロック内のtoken同士が相互に依存できるようにしていることだ。これにより、ブロック末尾に近づくほど受理率が低下する問題を緩和する。さらにconfidence headが候補prefixの生存確率を推定し、スケジューラがハードウェアのスループット曲線とシステム負荷に応じて検証長を短縮できるようにすることで、高並行処理時に低confidenceな末尾部分へバッチ容量を浪費するのを防ぐ。

LFM2.5-2.6Bを例にすると、Liquid AIが数学、プログラミング、対話の5種類のテストで測定した結果、H100 1基での平均デコード速度は毎秒323 tokenから864 tokenへ向上し、2.67倍となった。M4 Maxでは平均毎秒61 tokenから139 tokenへ向上し、2.27倍となった。複数ツールを使用するシナリオでは、function callingのレイテンシが平均57％低下した。シリーズ全体における個別テストのピーク値は、H100で3.18倍、オンデバイス環境で2.87倍だった。

エンジニアリングチームは、受理長、ドラフターのメモリ使用量、バッチサイズ、テールレイテンシを併せて測定すべきだ。構造化された数学問題やコードは通常、オープンエンドな対話よりも予測しやすく、公式の表でもデータセット間の高速化効果に2倍を超える差が生じ得ることが示されている。現時点の結果は主にベンダーによる測定で、batch size 1かつ特定のハードウェア構成に基づいている。また、llama.cppのDSpark実装経路は依然としてサーバー共通レイヤーが中心であり、llama.cppのコアC APIを直接組み込んでいるアプリケーションでは、すぐに有効化できるとは限らない。