DSparkは画像モデルを最大3.13倍高速化するが、最初のtokenは早くならない

Liquid AIは、vision-languageモデルLFM2.5-VL-3B向けに実験的なDSpark drafterを公開した。小さなモデルが次のtoken群を予測し、target modelが検証して正しい候補だけを採用する。同じsampling設定なら、出力分布はtarget model単体と等価に保たれる。

8.9％のparameter追加でdecode速度を大きく伸ばす

DSparkは2億7,950万parameter、4層で構成され、推奨block sizeは8または9 tokenだ。30億parameterのtarget modelと組み合わせた時、配備parameter数は8.9％増える。Liquid AIはllama.cpp、MLX-VLM、SGLangを初日から支援し、SafetensorsとGGUF形式のweightを提供している。

M5 Maxでは、課題に応じてdecodeが2.30倍から3.13倍、end-to-end latencyが1.56倍から2.62倍改善した。H100 80 GBを1基使った測定では、decodeが2.04倍から2.66倍、全体が1.64倍から2.27倍高速化した。

Edgeは主モデルを交換せずに応答を速くできる

すでにLFM2.5-VL-3Bを配備しているチームには、変更範囲の狭さが利点になる。drafterはtarget modelを置き換えず、量子化で品質を下げることもない。候補を提案し、元のモデルが確認する。画像説明、文書への回答、視覚的な対話を、application logicを変えずに短縮できる。

利点は出力tokenが多いほど大きい。長い説明や複数turnの対話では、decode高速化の効果が積み上がる。短い回答では、DSparkの対象外となる処理が時間の大半を占める可能性がある。

画像encodingとprefillは開始時の遅延を残す

画像は最初にvision encoderを通り、その後に主モデルが数百の視覚tokenを処理する。speculative decodingはこの段階も最初のtokenまでの時間も速くしない。そのためend-to-endの最大改善幅は、decodeだけの数字より小さい。公開測定は16-bit weight、batch size 1、6種類のMMSpec課題を使用しており、量子化モデルの高速化は今回の対象外だ。

短い回答と同時利用が実用性を試す

実際の結果は、画像encodingの比率、prompt長、回答長、同時request数で決まる。Liquid AIは高いconcurrencyでも優位性を確認したが、同時処理が増えるほど差は縮まった。チームが測るべきなのはend-to-end latencyと最初のtokenまでの時間であり、3.13倍という最大値だけではない。

Lilithの判定

DSparkは30億parameterの隣に小さな先読み役を置き、主モデルの走りを速くした。ただし画像処理はスタート地点に残る。計るべきはゴール前の直線だけではなく、レース全体だ。