Liquid AI LFM2.5-VL-3B-DSpark、ビジョンデコーディングを高速化するも、「3.13倍」の見出しは物語の半分にすぎない

Liquid AIは、コンパクトなビジョン・言語モデルのデコーディングを最大3.13倍高速化したとするLFM2.5-VL-3B-DSparkを公開した。この改善は、画像を理解して回答を生成するプロセス全体ではなく、トークン生成を対象としている。

この区別こそがLiquid AI LFM2.5-VL-3B-DSparkの意義を決める。実験的なドラフトモデルは、データセンター向けハードウェアとコンシューマー向けハードウェアの双方で、推測的デコーディングが視覚・テキスト両方のタスクに機能しうることを示している。ただし、Liquid AI自身の結果では、最高のエンドツーエンド改善はピーク時のデコーディング値を下回る2.62倍だった。

このリリースは、開発者にローカルのビジョン・言語アプリケーションをどう最適化するか再考を促している。モデル圧縮やアーキテクチャの小型化だけがレイテンシを削減する道ではない。個別のドラフターを使えば、同一のデコーディング設定の下で出力挙動を維持しながら、既存のターゲットモデルを高速化できる。

したがって、比較対象はLiquid AIと単一の競合モデルではない。推測的デコーディングと、速度を得るために主力のビジョン・言語モデルを小型化、簡素化、あるいは低精度化する従来の手法との比較である。

Liquid AI LFM2.5-VL-3B-DSpark、専用ドラフトモデルを追加

このリリースは、回答品質とレイテンシ問題の重要な一部分を切り分ける。

Liquid AI LFM2.5-VL-3B-DSparkは、LFM2.5-VL-3B専用に構築された、2億7,950万パラメータのドラフトモデルだ。30億パラメータのターゲットモデルを置き換えるものでも、リクエストに単独で回答するものでもない。代わりに、大規模モデルがまとめて検証する前に、可能性の高い複数のトークンを提案する。

このプロセスは推測的デコーディングと呼ばれ、より小さな予測器がターゲットモデルによる並列検証用のトークンを下書きする手法である。受理されたトークンにより、回答生成に必要な高コストなターゲットモデルの実行回数を減らせる。却下された提案はターゲットによって修正される。

Liquid AIによると、このドラフターは4層のフルアテンション層、Markovヘッド、信頼度ヘッドを備える。学習ブロックには9つの提案トークンが含まれる。デプロイ時には、ハードウェアと推論フレームワークに応じて、8または9のブロックを使用する。

同社は、SafetensorsおよびGGUF形式でモデルをモデルリポジトリを通じて公開した。Nvidia GPUではSGLang、Apple siliconではMLX-VLM、GGUFチェックポイントを介してllama.cppをサポートする。

このフレームワーク対応は重要である。推論高速化は、論文やカスタム研究実装の中に閉じたままとなることが多いためだ。ここでLiquid AIは、サーバー、Mac、ローカルの量子化モデル向けにすでに使われている3つのデプロイ経路へドラフターを接続している。

公開された構成では、SGLangにバージョン0.5.19以降が必要となる。MLX-VLMにはバージョン0.7.2以降が必要で、現時点ではこのDSpark実装をgreedy samplingで実行する。Liquid AIはMLXユーザーにtemperatureをゼロへ設定するよう案内している。

ターゲットモデルはドラフターより先に登場した。Liquid AIは2026年8月、エッジデプロイを目的とするオープンウェイトのビジョン・言語モデル、LFM2.5-VL-3Bを発表した。このモデルは、言語バックボーンとビジョンエンコーダーを組み合わせ、画像、文書、グラウンディング、光学文字認識、視覚的ツール利用を扱う。

Liquid AIは以前、ターゲットがM5 Maxで毎秒228トークンをデコードできると主張していた。また、Ryzen AI Max+ 395では毎秒116トークン、Galaxy S26 Ultraでは20トークンと報告している。これらの以前の数値は同社独自のテストによるものだ。

DSparkのリリースは、基盤モデルが学習した能力ではなく、デプロイパッケージを変更する。開発者は推論時にドラフターを接続し、LFM2.5-VL-3Bは生成されるすべてのトークンの承認を引き続き担う。

greedy decodingでは、ターゲットが単独で選択したはずのトークンと一致する場合にのみ、ターゲットはドラフトトークンを受理する。そのため、得られる回答は通常のgreedy generationと一致するはずだ。temperatureがゼロ以外の場合、設定を一致させたサンプリングにより、単一の決定論的なシーケンスではなくターゲットモデルの出力分布を維持できる。

この性質により、推測的デコーディングは量子化や蒸留とは異なる価値提案を持つ。これらの技術は数値精度、モデルサイズ、学習済みの挙動を変える可能性がある。一方DSparkは、ターゲットモデルが本来下す決定に到達するまでの時間を短縮しようとする。

このため、このリリースは2つの最適化経路の間に意味のある競争を生む。開発者は主力モデルが行う処理を減らすことも、より多くの処理を予測して効率的に検証することもできる。

3.13倍という結果は、ハードウェア、ワークロード、測定方法に依存する

Liquid AIの最高値は、普遍的なアプリケーション高速化ではなく、ある1つのデコーディング結果を示している。

Liquid AIは、MMSpecの6つのカテゴリ、すなわち一般的な視覚質問応答、テキスト認識、画像キャプショニング、チャート分析、複雑な推論、マルチターン会話でドラフターを評価した。同社はAppleハードウェアとH100 GPU 1基で、バッチサイズ1のテストを実施した。

MLX-VLMを用いたM5 Maxでは、Liquid AIは2.30倍から3.13倍のデコーディング向上を報告した。エンドツーエンドの改善は1.56倍から2.62倍だった。3.13倍のピークは、COCO画像キャプショニングのワークロードで発生した。

同社はllama.cppを用いたM3 Ultraもテストした。デコーディングは報告値で1.57倍から2.14倍向上し、エンドツーエンド性能は1.30倍から1.77倍改善した。

SGLangを用いたH100 80GB GPU 1基では、Liquid AIは2.04倍から2.66倍のデコーディング向上を測定した。エンドツーエンドの改善は1.64倍から2.27倍だった。同社の詳細なベンチマーク開示には、構成とタスク別の結果が示されている。

これらのテストでは、ビジョンエンコーダーと言語バックボーンに16ビット処理を使用した。H100構成ではBF16、9トークンのドラフトブロック、バッチサイズ1、temperatureゼロを使用した。AppleでのテストではFP16、8トークンのブロック、最大2,048トークンの生成を用いた。

Apple評価における回答長の中央値は90トークンだった。この点は重要である。出力の長さによって、リクエストのうちデコーディングに費やされる割合が変わるためだ。長い説明を生成するシステムでは、ドラフターが初期設定のオーバーヘッドを回収する時間がより多く得られる。

短い回答では、より不利なバランスになる。アプリケーションがラベル、座標、あるいは1文を返す場合、画像エンコーディングとプロンプト処理が支配的になりうる。生成の高速化が総待ち時間に占める割合は小さくなる。

ドラフトの受理率は、報告された高速化を説明する一助となる。Liquid AIはAppleスタック全体で、検証1パスあたりおよそ3.2から4.5トークンが受理されたと測定した。H100の結果では、3.46から4.57トークンが受理された。

受理されるトークン数が多いほど、ターゲットは各パスでより多くの有用な出力を検証できる。しかし、受理率がそのまま同等の速度向上に変換されるわけではない。ドラフターの実行、同期、メモリアクセス、フレームワークのオーバーヘッドも依然として時間を消費する。

結果はタスクによっても異なる。画像キャプショニングではMLXにおけるデコーディング改善のピークが得られた一方、マルチターン会話では2.30倍を記録した。エンドツーエンドの改善は、それぞれ2.59倍と1.91倍だった。

このばらつきにより、「最大3.13倍」をあらゆる視覚アシスタントで期待できる結果として責任を持って解釈することはできない。これは、公開された1つの設定で観測された上限値である。アプリケーションの結果は、ハードウェア、プロンプト長、出力長、サンプリング設定、視覚ワークロードに左右される。

Liquid AIによると、H100テストでは高い同時実行性でもDSparkは優位性を維持した。ただし、同時実行性が高まるにつれ、その差は縮小した。これは、GPUがメモリ帯域律速のデコーディングから計算律速の実行へ移行する際に、ドラフターの相対的な利点が変化することを示唆する。

プロダクトチームにとって実務上の問いは、ピーク値がLiquid AIのテスト内で実在するかどうかではない。自社のレイテンシプロファイルが、その数値を生んだテストに似ているかどうかである。そのためには、見出しの倍率をキャパシティ計画へそのまま転記するのではなく、推論の各フェーズを測定する必要がある。

Liquid AIの推測的デコーディングはターゲットモデルをどう維持するのか

DSparkは、予測エラーを最終出力に変えずに、より先まで下書きしようとしている。

標準的な自己回帰生成では、トークンを1つずつ順番に生成する。続く各トークンには、継続部分の予測可能性が高い場合であっても、ターゲットモデルの追加実行が必要となる。この逐次的な構造により、メモリ帯域律速のデコーディング時にハードウェアが十分活用されないことがある。

推測的デコーディングは、このループにより小さなモデルを挿入する。ドラフターが将来のトークンのブロックを提案し、ターゲットがそれらの位置をまとめて評価する。複数の提案が検証を通過すれば、処理を節約できる。

課題は、追加モデルを使う価値があるほど高速かつ正確に提案を生成することだ。弱いドラフターは却下されるトークンを生む。重いドラフターは精度良く予測するが、ブロックの生成に時間を使いすぎる。

DSparkは並列生成と軽量な逐次コンポーネントを組み合わせる。Markovヘッドは提案位置間に限定的な依存関係を導入し、信頼度ヘッドは後続の提案を検証すべきかを推定する。この設計は、ドラフトを完全な自己回帰型にすることなく、ブロックの一貫性を保つことを目指す。

基盤となるDSpark研究は、この手法を半自己回帰生成を用いた、信頼度スケジュール型の推測的デコーディングと説明している。その中心的なトレードオフは、提案の品質、ドラフトのレイテンシ、検証へ送るトークン数に関わる。

純粋な並列ドラフトではブロックを高速に生成できるが、ブロック内で後ろの位置になるほど精度が下がりやすい。各位置は、前の推測を含むコンテキストに依存する。そのため、エラーは提案全体にわたって複合しうる。

完全な自己回帰ドラフターはより強い依存関係を維持するが、逐次的なボトルネックの一部を再現してしまう。DSparkのハイブリッド構造は、その中間を狙う。並列ドラフト処理の後に、小さな逐次ヘッドを加える。

信頼度の仕組みは、別の無駄の原因にも対処する。ドラフターが後続トークンの失敗を予想している場合、固定長ブロック全体を検証しても意味は薄い。スケジューラーは、低信頼度の位置がターゲットの計算資源を消費する前に、送信するプレフィックスを短縮できる。

公開されたLFM2.5-VL-3B-DSparkの構成は、rank-256のMarkovヘッドと独立した信頼度ヘッドを使用する。語彙には128,000トークンが含まれる。このアーキテクチャは指定されたターゲットモデルに結び付いており、あらゆるVLM向けの汎用的な差し替えドラフターとしては利用できない。

このモデル固有の関係は、強みであると同時に制約でもある。1つのターゲットに対して学習すれば、提案の整合性を改善できる。しかし、別のターゲットモデルへ切り替えるチームには、互換性のあるチェックポイント、学習プロセス、ランタイム統合が必要となる。

「lossless」という説明にも、正確な解釈が必要である。temperatureゼロのgreedy decodingでは、検証によりターゲット単独の場合と完全に同じトークン選択が維持される。ドラフターに、もっともらしいだけの代替案を置き換える権限はない。

temperatureがゼロ以外の場合、目標は1つのシーケンスを再現することから、ターゲットの分布を維持することへ移る。基礎となるsampling研究によると、正しい推測的サンプリングは、設定を一致させた条件下でそれを実現できる。速度は依然として、ドラフトとターゲットの分布がどれほど頻繁に一致するかに左右される。

Liquid AIは、実験においてtemperatureを上げると受理率が低下したと報告している。確率が低順位のトークンへより広く分散し、ドラフターとターゲットが不一致になる機会が増えるためだ。結果として、創造的なサンプリングでは決定論的な生成より改善幅が小さくなる可能性がある。

これはアプリケーション設計にとって重要だ。文書抽出、視覚的グラウンディング、グラフ読解、制約付き応答では、低い温度設定がよく使われる。自由度の高い画像対話ではサンプリングを多く用いる場合があり、公開されたgreedyの結果は代表性が低くなる。

したがって、Liquid AIの推測デコーディングは、予測可能な出力に特によく適合する。標準化された製品画像へのキャプション付与、レシートの読取、インターフェースのスクリーンショット説明、構造化された事実の抽出は、もっともらしいワークロードだ。ただし、実際の効果にはローカル環境での測定がなお必要である。

高速なデコーディングでもVision-Languageのボトルネックは解消されない

最大の不確実性は、実際のリクエストのうち、加速されたデコーディング段階の外側にどれだけの処理が残るかにある。

Vision-Languageリクエストには、テキスト生成以上の処理が含まれる。システムは画像をエンコードし、視覚表現へ変換し、それらの視覚トークンをプロンプトとともに処理したうえで、回答をデコードしなければならない。

DSparkが加速するのは最終段階だけだ。画像エンコードを高速化するものではない。また、prefillも変更しないため、最初の回答トークンを生成する前に、ターゲットモデルは引き続きプロンプトと視覚トークンのコンテキストを処理する。

この境界が、デコーディングとエンドツーエンドの結果の差を説明する。Liquid AIはM5 Maxで最大3.13xのデコーディング高速化を報告したが、総合的な最大改善は2.62xだった。ほかのタスクでは、さらに大きな差が見られた。

TextVQAでは、同社はM5 Maxで2.69xのデコーディング改善と1.56xのエンドツーエンド改善を測定した。この結果は、画像処理とprefillが元のリクエスト時間のかなりの部分を占めていたことを示唆する。

この制約は、ワークロードの一部が変化しない限り全体の高速化に上限があるというアムダールの法則に従う。デコーディングがベースライン遅延の半分を占める場合、デコーダーを無限に高速化しても、リクエスト全体の改善は2xを超えられない。

エッジハードウェアでは、この制約は特に重要になる。コンシューマー向けデバイスは、視覚エンコードや長いコンテキストのprefillに関して、データセンターGPUより計算能力が低い。大きな画像や複数画像を含むプロンプトは、推測デコーディングが効果を発揮し始める前の最初のトークン生成を遅らせる可能性がある。

独立したMMSpecベンチマークは、慎重な解釈の必要性をさらに裏付けている。著者らは6つのタスクカテゴリと10種類の推測デコーディング手法にわたり、600サンプルを評価した。スループットの高速化だけでは、レイテンシ性能を信頼できる形で表せないことが分かった。

MMSpecはまた、テキスト専用の言語モデル向けに設計された手法が、マルチモーダル環境では性能を低下させうることも示した。クロスモーダルな依存関係により、どの提案が採用される可能性が高いかが変化する。バッチサイズが大きくなるほど、視覚認識の重要性は増す。

Liquid AIはMMSpecのタスクカテゴリに従っており、これにより社内評価の幅は広がっている。ただし、DSparkの性能テストを実施・公開したのはLiquid AI自身である。一般的なデバイスや本番プロンプトを対象とした独立した再現検証は、依然として限られている。

比較ベースラインにも同様の注意が必要だ。公開された倍率は、指定されたフレームワークにおいて、同一のLFM2.5-VL-3Bターゲットをdrafterあり・なしで比較したものである。統合システムがあらゆる競合VLMを上回ることを示すものではない。

また、このシステムは代替のレイテンシ戦略とも比較されていない。開発者はターゲットを量子化し、画像解像度を下げ、視覚埋め込みをキャッシュし、プロンプトを短縮し、リクエストをバッチ化し、より小さなモデルを選択できる。これらの変更はレイテンシ予算の異なる部分に影響する。

メモリも運用上の考慮事項だ。drafterは30億パラメータのターゲットと比べれば小さいが、無償ではない。その重み、キャッシュ、ランタイム状態、統合処理は、制約のあるデバイスで重要な容量を消費する。

互換性もさらなる摩擦を生む。SGLang、MLX-VLM、llama.cppはいまや公開された対応パスを提供しているが、ほかのサービングシステムを使うチームが即時サポートを前提にすることはできない。本番導入には、安定したロード、可観測性、バッチ処理の挙動、障害処理が必要となる。

MLX-VLMで現在提供されるgreedy専用のDSparkパスは、当面のユースケースを狭める。サンプリング生成に依存するアプリケーションは、別の対応スタックを使うか、より広範なサンプリング対応を待つ必要がある。その場合でも、高い温度設定はドラフトの受理率を下げる可能性がある。

したがって、このリリースは、明確に示された境界を持つ信頼できるシステム最適化として評価すべきだ。視覚推論があらゆる意味で3.13x高速化されたことを示す証拠ではない。

真の競争は、より良い予測とモデル処理量の削減の間にある

DSparkは、ターゲットを維持したまま、その実行頻度を最適化するという道筋を強化する。

エッジAIにおけるレイテンシへの標準的な対応は、ターゲットモデルの処理量を減らすことだった。チームはパラメータ数を減らし、精度を下げ、プロンプトを短くし、画像を小さくし、タスク特化の蒸留を利用する。各手法は応答性を改善できる一方で、品質や柔軟性とのトレードオフを生みうる。

Liquid AI LFM2.5-VL-3B-DSparkは別の道を提案する。既存のターゲットを維持し、特化した補助モデルで複数の将来ステップを予測する。ターゲットに最終出力の制御を手放させることなく、それらの推測を検証させる。

このアプローチは、チームがすでにターゲットモデルの能力を受け入れている場合に魅力的になる。置き換えには、新たな評価、プロンプト変更、安全性チェック、製品チューニングが必要になる。drafterを追加すれば、その投資をより多く維持できる。

この手法は、メモリ帯域幅がトークン生成をしばしば制約するローカルデプロイにも適している。ブロックの検証は、1トークンごとにモデル状態を繰り返しロードするよりも、ハードウェアを効率的に利用できる可能性がある。Liquid AIのApple上の結果は、その可能性を具体的に示している。

それでも、小型モデルには利点が残る。パッケージングを簡素化し、総メモリ使用量を削減し、デコーダー専用の最適化では触れられない段階も高速化する。コンパクトな視覚エンコーダーは最初のトークンまでの時間を改善できるが、DSparkにはできない。

量子化も、推測デコーディングと排他的に競合するのではなく組み合わせられる。Liquid AIは、GGUFターゲットに対応したGGUF drafterを提供している。そのため、ランタイムがペアを正しくサポートすれば、ローカルスタックは精度を下げつつドラフティングを追加できる。

この組み合わせにより、エンジニアリング上の問いは、1つの手法を選ぶことから、各手法を適切なボトルネックへ割り当てることへ移る。量子化は重みサイズと演算コストを削減する。画像前処理は視覚コストを変える。推測は自己回帰生成を対象とする。

そのため、フェーズ単位のプロファイリングが不可欠になる。高解像度ページを分析する文書アシスタントは、デコーディング前の処理に大半の時間を費やす可能性がある。詳細な説明を生成するビジュアルチャットツールは、出力生成により多くの時間を費やす可能性がある。

同じ区別はユーザー体験にも当てはまる。最初のトークンまでの時間は、アプリケーションが開始時に応答的に感じられるかを左右する。毎秒トークン数は、生成開始後に長い回答が滑らかに感じられるかを左右する。

DSparkは後者の指標を直接改善する。デコーディングがリクエストの十分な割合を占める場合、総レイテンシも改善する。ただし、前者が比例して改善することを保証するものではない。

開発者は、単一ユーザーの速度とフリート全体のスループットも分けて考えるべきだ。Liquid AIは測定したH100の全同時実行レベルで優位性を観測したが、高負荷時には差が縮小した。本番環境の経済性は、リクエスト構成、バッチ処理、サービスレベル目標に依存する。

したがって、このリリースで最も重要なのはアーキテクチャ上の側面だ。Liquid AIは、推測デコーディングを研究として提示するだけでなく、デプロイ可能なvision-modelファミリーの一部としてパッケージ化した。

このパターンが広がれば、モデルリリースにはターゲット、複数の量子化版、ハードウェア固有のdrafterがますます含まれるようになるかもしれない。推論最適化は、後付けのサービング判断ではなく、モデルアーティファクトの一部となる。

この方向性は、ほかのオープンウェイトモデル開発者にも圧力をかける。チェックポイントだけを公開すれば、下流チームが高速化を担うことになる。計測された効果がワークロード依存であっても、対応するdrafterを提供すれば、より完全なレイテンシの説明を示せる。

この高速化が実用上重要かを示す3つのシグナル

独立検証、より広範なサンプリング対応、実アプリケーションのプロファイルが、DSparkが再現可能なデプロイパターンとなるかを決める。

最初のシグナルは、利用しやすいハードウェアでの独立した再現検証だ。開発者は、MシリーズMac、コンシューマーGPU、エッジシステムで、同一プロンプトをdrafterあり・なしで比較するテストに注目すべきである。

有用なレポートは、画像寸法、プロンプト長、出力長、温度、量子化、ランタイムのバージョンを開示しなければならない。毎秒トークン数を1つ示すだけでは、アプリケーションの応答全体が意味のあるほど高速化したかを説明できない。

Liquid AIの範囲に近い再現結果は、同社の主張を強めるだろう。より小さい、あるいは一貫しない効果は、公開されたワークロードが日常的なアプリケーションよりdrafterに有利であることを示唆する。

2つ目のシグナルは、より広範なランタイムとサンプリングへの対応だ。MLX-VLMは現在、公開されたDSparkパスをgreedy生成に限定している一方、SGLangはNvidiaデプロイを対象とし、llama.cppはGGUFのユースケースに対応している。

追加の推論エンジンでサポートされれば、統合コストは下がる。安定した非ゼロ温度でのサンプリングも、視覚チャットやクリエイティブな説明ツールにとって、この手法の関連性を高めるだろう。

開発者は、サンプリングの変化に伴う受理率を調べるべきだ。Liquid AIによれば、実験では高い温度設定により受理率とスループットが低下した。本番テストでは、その低下が会話型製品にとって許容可能な範囲にとどまるかが明らかになるはずだ。

3つ目のシグナルは、チームが実アプリケーションからフェーズ単位の改善を報告するかどうかだ。決定的な指標は、最初のトークンまでの時間、デコーディング速度、エンドツーエンドレイテンシ、ピークメモリ、想定同時実行数におけるスループットである。

長文のビジュアルアシスタントは、セッション内で生成が支配的になるため、大きな恩恵を得る可能性がある。数フィールドだけを返すOCRワークフローでは、視覚エンコードとprefillがリクエストの大半を占めるため、効果ははるかに小さい可能性がある。

Liquid AI LFM2.5-VL-3B-DSparkを評価するチームは、見出しの倍率ではなくトレースから始めるべきだ。画像エンコード、prefill、デコーディングがベースラインで占める割合を測定する。その後、drafterを追加して同じワークロードを繰り返す。

greedyデコーディング下での出力等価性と、対応サンプリング下での分布的挙動を確認する。ウォームスタートとコールドスタートは分けて測定する。ノートPCやモバイル級システムをテストする際は、メモリ圧迫と持続的な熱特性も含める。

このリリースは、そうした評価を可能にする十分な実装詳細を提供している。また、開発者に有用な点を思い出させる。モデル能力と推論挙動は、別個のエンジニアリング課題である。

Liquid AIの3.13xという数値は、対応するdrafterがローカルのマルチモーダル推論の1つのフェーズを大幅に高速化できる証拠として理解するのが最も適切だ。エンドツーエンドの数値は、この主張の価値と限界の両方を示している。

対応するドラフトモデルは、オープンウェイトVLMの標準的な付属物になるのか、それとも長文出力ワークロード向けの特化した最適化にとどまるのか。その答えは、単一のピークベンチマークではなく、再現可能なアプリケーショントレースから明らかになる。