Liquid AI、LFM2.5-VL-DSparkを公開：3B視覚モデル向けドラフトモデルでデコード最大3.13倍の高速化
Liquid AIのブログによると、Liquid AIは2026年9月、オープンウェイトの視覚言語モデルLFM2.5-VL-3B向けに実験的なDSparkドラフトモデルを公開した。約2.8億パラメータを追加し（3Bのターゲットモデルに対して8.9%増）、デバイス上のデコードで最大3.13倍、H100で最大2.66倍の高速化を主張している。初日からllama.cpp、MLX-VLM、SGLangをサポートする。
主な変更
Liquid AIは2026年9月、視覚言語モデルLFM2.5-VL-3Bに対応する実験的なDSparkドラフトモデルを公開した。ベンダーのブログによると、このドラフトモデルはテキスト版LFM2.5-DSparkのアーキテクチャ方針を踏襲している。固定された接続層でターゲットモデルの隠れ状態を取得し、それに基づいて候補トークンを起草する。画像パッチとテキストトークンはこれらの層に入る前に共有表現空間へ投影されるため、ドラフトモデルは次元の揃った隠れ状態を処理し、推論アルゴリズムはテキストモデルと同一である。ドラフトモデルは4層のアテンションのみの構造で、ブロックサイズは9、約2億7950万パラメータ。内訳はデコーダスタック1億9300万、隠れ状態投影2100万、Markov head 6550万、Normsと信頼度head 6400である。ベンダーは、M5 Max上のMLXで各タスクのデコードが2.30～3.13倍、エンドツーエンドで1.56～2.62倍、M3 Ultra上のllama.cppでデコードが1.57～2.14倍になると述べている。H100のデコードとエンドツーエンドの数値については、原文に組版異常の疑いがある。ベンダーは投機的デコードが正確であることを強調し、ターゲットモデルが提案された各トークンを検証するため貪欲出力はターゲットモデル単体と同じになるとしている。ドラフトモデルはSafetensorsとGGUFの2形式でHugging Faceにて提供される。
開発者への影響
ローカルやエッジデバイスでマルチモーダルモデルを配備する開発者にとって、この発表の意味は絶対的な速度の数値ではなく、ドラフトモデルとターゲットモデルのパラメータ比が約8.9%であること、つまりVRAMとメモリの増分を抑えられる点にある。ただし大半の加速比はデコード段階の指標であり、エンドツーエンドの効果はワークロードにおける視覚エンコードとprefillの比率に依存する。ベンダー自身もこれを説明するためにアムダールの法則を引用している。ここから分岐が生まれる。長い出力、マルチターン対話、画像キャプションが中心のシナリオではベンダーが主張するエンドツーエンドの数値に近づく可能性があるが、1回の長い画像質問応答のように大量の視覚トークンを先に処理しすぐ終わるシナリオでは効果が明確に小さくなる。さらに、ドラフトモデルの実行はメインラインに未統合か特定ビルドが必要なllama.cpp、MLX-VLM、SGLangのブランチに依存し、統合コストは無視できない。なお、本稿の確認時点で、KimiSeekの現行モデルカタログにLFM2.5-VL-3BやLFM2.5-VL-DSparkの項目はなく、ソースが言及するAPIとウェイトの可用性はいずれもベンダーの説明である。
導入と評価の提案
推奨1：ドラフトモデルを導入するか決める前に、まず自分のワークロードでデコードが総遅延に占める割合を測定する。ソースは投機的デコードがデコードのみを加速し、視覚エンコードとprefillは加速しないと述べており、エッジデバイスではprefillがエンドツーエンド遅延に占める割合がより高い。前提として、初回トークン遅延とデコード所要時間の内訳データを取得できること。同じ6種類の視覚タスク（汎用VQA、テキストVQA、画像キャプション、チャートVQA、複雑な推論、マルチターン対話）でベースラインとドラフトモデルの2構成を実行し、評価指標はデコードスループットだけでなくエンドツーエンド遅延の分位点を取ることを勧める。短い画像と長いテキスト出力が中心ならドラフトモデルは割に合う可能性があるが、単発の長い画像質問応答が中心なら効果の上限はprefillに制約される。推奨2：主張されたピーク加速ではなく、配備形態に応じてllama.cppとSGLangを選ぶ。ソースは両者の具体的な起動方法が異なるとしている。SGLangは--speculative-dspark-block-sizeなどのパラメータでドラフトモデルを接続し、radix cacheを無効化することを明示的に要求する。llama.cpp側は--spec-type draft-dsparkと--spec-draft-n-max 8を組み合わせる必要がある。前提として、使用するビルドが対応するPRを含むこと。含まなければこれらのパラメータは使えない。評価時は各応答のdraft_nとdraft_n_acceptedを記録し、受理率からブロックサイズを8と9のどちらにすべきか判断することを勧める。受理率が低い場合は、タスク分布が訓練データの混合から外れていないか確認する。これらは推奨される実践であり、ベンダーの約束ではない。
制限と未確認事項
第一に、本稿の確認時点で、KimiSeekの現行モデルカタログにLFM2.5-VL-3BやLFM2.5-VL-DSparkの正確な項目はなく、このバージョンは現在KimiSeekに掲載されていない。ソースで言及されたウェイトのダウンロード、形式、統合方法はいずれもベンダーの説明であり、本サイトでの可用性を示すものではない。第二に、ベンダー原文のH100の箇所でデコード加速の範囲が「20.4倍から2.66倍」と書かれており、明らかな組版または転記の異常があるため、信頼できる上限として引用すべきではない。第三に、ベンダーはドラフトモデルを実験的と述べており、その4層構造とブロックサイズ9は3、4、5層のアブレーションに由来し、訓練データの混合は想定負荷に重み付けされているため、受理率と加速比は実際のタスク分布によって変動する。第四に、加速の数値はベンダーがM5 Max、M3 Ultra、H100上で自ら測定したもので、MMSpecベンチマークの6種類のタスクで評価されている。他のハードウェア、量子化形式、コンテキスト長、バッチ処理設定での性能は独立に検証されていない。第五に、ソースはモデルをオープンウェイトで自由にダウンロード、微調整、配備できると説明しているが、ブログは具体的なライセンス条項を示していない。ウェイトが入手可能であることはオープンソースライセンスを意味せず、商用利用と再配布の権利はHugging Faceモデルページの実際のライセンスに従う必要がある。
元の報道の図版
