Liquid AI、視覚言語推論を高速化するため LFM2.5-VL-3B に speculative decoding を追加
Liquid AI は、エッジデバイスや H100 GPU 上で LFM2.5-VL-3B のデコードを高速化する 2.8 億パラメータの drafter、LFM2.5-VL-DSpark を公開した。
Liquid AI は、同社の視覚言語モデル LFM2.5-VL-3B を高速化するための実験的な speculative-decoding モデルを公開した。狙いは、マルチモーダル推論における中心的なボトルネック、つまり画像とプロンプトが処理された後に素早く応答を生成することにある。
LFM2.5-VL-DSpark という名前のこのモデルは、30億パラメータのターゲットモデルに 2.8 億パラメータの draft model を追加する。Liquid AI によると、社内評価では、この組み合わせにより Apple M5 Max で最大 3.13x、Nvidia H100 で最大 2.66x のデコード高速化が得られた。エンドツーエンドのレイテンシ改善はそれより小さく、M5 Max で 2.62x、H100 で 2.27x だった。
このリリースは、応答レイテンシやメモリ制約が大規模な推論クラスタより厳しくなりがちなローカルハードウェア上で視覚言語モデルを展開するチームにとって特に重要だ。また、Liquid AI の DSpark アプローチをテキストモデルからマルチモーダルなワークロードへ拡張しつつ、別の speculative-decoding アルゴリズムを必要としない点も大きい。
マルチモーダル入力向けに構築された drafter
Speculative decoding は、小さなモデルを使って複数のトークンをまとめて提案する。次に、大きなターゲットモデルがそれらの提案を検証し、自身の次トークン分布に一致するトークンを受け入れ、必要に応じて置き換えを生成する。このアプローチは、厳密な検証の下でターゲットモデルの出力を変えることなく、高コストなターゲットモデルのステップ数を減らせる。
Liquid AI の Hugging Face リリースによると、LFM2.5-VL-DSpark drafter は LFM2.5-VL-3B の選択された層から hidden states を取り出し、候補トークンのブロックを提案する。画像とテキストはまず共通表現に投影され、入力モダリティに関係なく同じ次元のベクトルを drafter が受け取れるようにしている。
Liquid AI は、視覚用 drafter が学習時に 4 つの attention-only 層とブロックサイズ 9 を使ったと述べている。推論では、ハードウェアに応じてブロックサイズ 8 または 9 を推奨する。drafter は、展開モデルのパラメータ数に約 8.9% を追加するだけで、同じタスクのために別の大規模モデルを動かす場合と比べて比較的小さなメモリ増加にとどまる。
このモデルは、Liquid AI が想定するワークロードに重み付けした視覚言語の supervised fine-tuning データの मिश्र合で学習された。同社は 3 層、4 層、5 層の設計をテストし、選択した構成を 10 epoch で訓練した。追加トークンに対する受容率は増加したが、やがて収穫逓減に入ったと報告している。
報告された改善はハードウェアとタスクで異なる
Liquid AI は MMSpec ベンチマークを用いて、6 つの視覚ベースのワークロードでシステムを評価した。タスクには、一般的な視覚質問応答、テキスト重視の視覚質問応答、画像キャプション、図表に関する質問応答、複雑な推論、マルチターン会話が含まれる。
オンデバイス結果は、M5 Max 上の MLX と M3 Ultra 上の llama.cpp で測定された。Liquid AI によると、MLX のデコードはタスクに応じて 2.30x から 3.13x 高速化し、エンドツーエンドのレイテンシは 1.56x から 2.62x 改善した。llama.cpp では、デコードの改善は 1.57x から 2.14x の範囲で、エンドツーエンドのレイテンシは 1.30x から 1.77x 改善した。
同社によれば、H100 の評価ではデコード高速化が最大 2.66x、エンドツーエンド改善が最大 2.27x となった。ソース資料には H100 のデコード範囲の下限値に一貫しない記述が含まれているため、広い結果は一様な性能期待値ではなく、ベンダー報告の最大値として扱うべきだ。
これらは Liquid AI の測定であり、独立したベンチマークではない。また、特定のハードウェア、ソフトウェア構成、タスクの組み合わせ、そして DSpark ブロックサイズ 8 を示している。実際の改善は、提案トークンの受容率、プロンプト長、画像の複雑さ、量子化、バッチサイズ、さらに総レイテンシのうち画像処理とプロンプト取り込みに費やされる割合に左右される。
Liquid AI は、ターゲットモデルが提案されたすべてのトークンを検証するため、speculative decoding は exact だと述べている。したがって実装上、greedy 出力は speculative なしで動作するターゲットモデルと一致するはずだ。この性質は、加速技術に関する主要な展開上の懸念の一つ、つまりモデルの振る舞いを密かに変えずに速度を改善できるか、に対処する。
なぜエンドツーエンドのレイテンシがなお難しい指標なのか
デコード速度と総レイテンシの差は、プロダクトチームにとって重要だ。Speculative decoding はトークン生成を速めるが、vision encoder や、画像トークンとテキストプロンプトを処理する prefill フェーズは速めない。
視覚言語モデルは、最初のトークンを生成する前にかなりの時間を費やすことがある。画像は vision encoder を通され、その後、言語モデルが数百の視覚トークンをテキスト入力とともに処理する。エッジハードウェアでは計算余力が小さいため、これらの段階が総応答時間に占める割合が大きくなりうる。その結果、デコードが 3 倍速くなっても、ユーザーが体感するレイテンシが 3 分の 1 になるわけではない。
この制約はアムダールの法則の一例だ。変わらない部分が全体の改善幅を上限づける。画像チャット、文書解析、図表解釈のようなアプリケーションでは、チームは first token までの時間と完全な応答時間を別々に測定する必要がある。画像がすでにエンコードされた後に出力生成が支配的になる長文回答、繰り返しのターン、ワークフローでは、より速いデコード経路が最も価値を持つ可能性がある。
この結果は、ハードウェア選択が価値提案を左右することも示唆している。Liquid AI が最も強いデコード範囲として報告したのは Apple Silicon だった一方、H100 は同社のテストでそれより小さいが依然として有意な改善を示した。これにより、このリリースはローカル推論にも GPU バックエンドのサービスにも関係するが、どの展開でも同じ改善が得られることを示すものではない。
統合により試しやすさが向上する
LFM2.5-VL-DSpark は、llama.cpp、MLX-VLM、SGLang 向けの統合を通じて利用できる。Liquid AI は、draft model が Hugging Face で Safetensors と GGUF 形式で提供されており、開発者にネイティブおよび量子化された展開ワークフローへの道を開くと述べている。
SGLang の統合には、LFM2 ターゲット向けの DSpark サポートを含むビルドが必要で、llama.cpp と MLX-VLM も関連する実装変更を含むバージョンを必要とする。SGLang では、運用者は drafter をターゲットモデルに接続し、OpenAI 互換のエンドポイントを問い合わせる。ブロックサイズはモデル設定から読み取られ、応答タイミングによって、いくつの draft トークンが提案され、受け入れられたかを把握できる。
ビルダーにとって、この統合モデルは重要だ。なぜなら、このリリースではターゲット視覚言語モデルの置き換えやアプリケーションインターフェースの再設計が不要だからだ。同じターゲットモデルを使って、speculative decoding ありのベースライン展開と比較し、受容率、レイテンシ、メモリ使用量、出力の一致性を測定できる。ただし、追加の 2.8 億パラメータにはメモリと読み込みコストが伴うため、小型のエッジデバイスでは重要になる可能性がある。
今後注目すべき点
最も明確な次のシグナルは、より多くの画像サイズ、量子化レベル、バッチサイズ、本番風のプロンプトにわたる LFM2.5-VL-DSpark の独立検証だ。独立した結果があれば、Liquid AI が選んだ 6 タスク評価の外でも報告された改善が維持されるかどうかを確認しやすくなる。
開発者は、見出し上のデコード倍率だけでなく、受容率とエンドツーエンドのレイテンシにも注目すべきだ。llama.cpp、MLX-VLM、SGLang のサポートは、実装が成熟するにつれて追跡が重要になる。特に Apple Silicon や制約のあるローカルハードウェアで展開するユーザーにとっては重要だ。
他の視覚言語モデル向けの追加の DSpark リリースは、このアーキテクチャが LFM2.5-VL-3B を超えて一般化するかどうかを示すかもしれない。逆に、改善がモデルアーキテクチャやワークロードに強く依存するなら、この手法は広く移植可能な推論層というより、対象を絞った最適化にとどまる可能性がある。
Creati.ai の見解
Liquid AI のリリースは、新しい能力モデルではなく、実用的な推論更新だ。その主な貢献は、追加モデルを比較的小さく保ちながら、speculative decoding をどのようにマルチモーダルなターゲットへ適応させ、厳密な検証を維持できるかを示した点にある。
商業的な意義は、最大デコード値ではなく、ユーザーが感じる総レイテンシに左右される。視覚言語ワークロードをローカルで実行するチームにとって、公開重み、既存のランタイム統合、測定可能な改善の組み合わせは、テストする理由になるだろう。ただし購入者は、現時点の性能主張をベンダー報告として扱い、自身の画像、プロンプト、ハードウェア、レイテンシ目標で検証すべきだ.
