- 投機的デコーディング用ドラフターを追加し、デコードを最大3.13倍高速化
- ドラフターは約2億8000万パラメータで、本体モデル比8.9%の増加
- llama.cpp、MLX-VLM、SGLangに対応し、SafetensorsとGGUFで公開
何が発表されたのか
Liquid AIは、視覚言語モデル(VLM)の推論を高速化する投機的デコーディング用のドラフターモデル「LFM2.5-VL-DSpark」を公開しました。本体となるモデルはLFM2.5-VL-3Bで、ドラフターはその推論を補助する役割を担います。
ドラフターのパラメータ数は約2億8000万で、本体モデルに対する増加分は8.9%にとどまります。デコード速度はオンデバイスで最大3.13倍、H100で最大2.66倍、エンドツーエンドではそれぞれ最大2.62倍、2.27倍の改善が報告されています。
llama.cpp、MLX-VLM、SGLangという3つの実行環境向けの統合が初日から用意されており、モデルはSafetensors形式とGGUF形式でHugging Face上に公開されています。
ドラフターの仕組み
このドラフターは、Liquid AIのテキスト向けドラフター(LFM2.5-DSpark)と同じアーキテクチャを採用しています。本体モデルの特定の層(タップ層)の隠れ状態を取得し、それを条件として候補トークンをk個まとめて生成する仕組みです。
画像パッチとテキストトークンは、それらの層に入る前に共通の表現へ射影されます。そのためドラフターは入力モダリティに関係なく同一の次元の隠れ状態ベクトルを扱うことになり、推論アルゴリズムはテキストモデルから変更されていません。
アーキテクチャの検討では3層、4層、5層の比較が行われ、最終的に4層のアテンションのみで構成される簡略化されたドラフターとブロックサイズ9が採用されました。vision-languageのSFTデータを混ぜたデータセットで10エポック学習し、追加学習トークンとともに候補の受理率が向上したものの、やがて効果が頭打ちになったと説明されています。推論時のブロックサイズはハードウェアに応じて8か9が推奨されています。
実測された高速化
評価はオンデバイスとGPUの両方で行われ、いずれもDSparkのブロックサイズは8に設定されています。対象タスクは一般的なVQA、テキストVQA、画像キャプション、グラフVQA、複雑な推論、マルチターン会話の6種類で、MMSpecベンチマークに沿ったものと説明されています。
オンデバイスでは、M5 Max上のMLXでデコードがタスク別に2.30倍から3.13倍、エンドツーエンドのレイテンシが1.56倍から2.62倍改善しました。M3 Ultra上のllama.cppではデコードが1.57倍から2.14倍、エンドツーエンドが1.30倍から1.77倍となっています。
H100でのGPU推論では、同じドラフターがエンドツーエンドで1.64倍から2.27倍の改善を示しています。なお原文のGPU推論の記述にはデコード速度が「20.4x to 2.66x」とあり、冒頭の上限値2.66倍と整合しないため、数値の誤記とみられます。
視覚ワークロードの限界
投機的デコーディングが高速化するのはデコードの段階だけで、視覚エンコーディングやプリフィル(入力処理)は速くなりません。VLMでは画像がまず視覚エンコーダを通り、その後言語バックボーンが数百の視覚トークンとテキストプロンプトを処理するため、入力処理の負荷が大きくなります。
エッジデバイスはデータセンターのGPUに比べて計算資源がはるかに少ないため、プリフィルがエンドツーエンドのレイテンシに占める割合が大きくなります。原文は、M5のコアごとのGPUニューラルアクセラレータがこの差を狭めていると補足しています。
これらの段階がすでに実行時間の大半を占めている場合、デコードを大きく高速化してもエンドツーエンドの改善は限定的になります。原文はこれをアムダールの法則として説明し、加速されない部分によって全体の高速化が頭打ちになるとしています。
使い方と入手方法
SGLangで使う場合は、LFM2ターゲット向けのDSparkサポートを含むビルド(PR #40651)が必要です。本体モデルを起動する際にドラフターを指定し、ブロックサイズはドラフターのconfig.jsonから読み取られます。
llama.cppでは該当するビルド(PR #29339)を、MLX-VLMでは該当するビルド(PR #2280)を用意する必要があります。MLX-VLMではブロックサイズはサイドカーのメタデータから読まれ、n-maxはその値に制限されると説明されています。
投機的デコーディングは候補トークンすべてを本体モデルが検証するため出力は厳密で、greedy設定での結果は本体モデル単体と同じになるとされています。応答ごとのタイミングではdraft_nとdraft_n_acceptedが報告されます。
| 実行環境 | デコードの高速化 | エンドツーエンドの高速化 |
|---|---|---|
| MLX / M5 Max(オンデバイス) | 2.30〜3.13倍 | 1.56〜2.62倍 |
| llama.cpp / M3 Ultra(オンデバイス) | 1.57〜2.14倍 | 1.30〜1.77倍 |
| H100(GPU) | 最大2.66倍 | 1.64〜2.27倍 |
Speculative decoding speeds up only decode, not vision encoding or prefill. When those stages already take up much of the wall time, even a large decode speedup gives only a modest end-to-end gain.
投機的デコーディングが高速化するのはデコードだけであり、視覚エンコーディングやプリフィルは高速化されない。これらの段階がすでに実行時間の大半を占めている場合、デコードを大きく高速化してもエンドツーエンドの改善はわずかにとどまる。
今後の見通し
Liquid AIはLFM2.5について「どこでも動くAI」という構想を掲げており、今回のドラフターはその一部と位置づけられます。テキスト向けドラフターと同じ推論アルゴリズムを使っている点から、今後は音声など他のモダリティ向けの派生モデルにも同様の手法が広がる可能性があるとみられます。ただし公表されている数値は6種類のタスクと特定のハードウェアに限られており、実際の業務アプリケーションでどの程度の効果が出るかは、プロンプト長や画像枚数、同時実行数などの条件を変えた検証が明らかになれば判断できます。プリフィルが支配的な用途では改善幅が小さくなる点も、導入判断の際に確認しておきたい条件です。
日本の開発者・IT企業にとっての意味
投機的デコーディングは、小さいドラフターモデルで候補トークンを先に生成し、本体モデルで検証する手法です。品質を落とさずにデコードを速くできるため、レイテンシが重視される用途と相性が良く、今回のように3BクラスのVLMでも本体比8.9%の追加で済む実装が公開されたことは、エッジ側でのVLM活用を検討する開発者にとって選択肢が増えることを意味します。llama.cppやMLX-VLM、SGLangといった実務でよく使われる推論基盤が初日から対象になっている点も、自作の推論パイプラインに組み込みやすいという利点があります。一方で、高速化されるのはデコードだけで、画像のエンコードやプリフィルは対象外です。画像を多く入力するアプリケーションでは体感できる改善が限られる可能性があるため、導入前に対象ワークロードでの実測を行うことが現実的です。
気になる点
- 既存のllama.cppやSGLangの環境でそのまま使えますか。
- そのままでは使えず、DSparkサポートを含むビルドが必要です。SGLangはPR #40651、llama.cppはPR #29339、MLX-VLMはPR #2280がそれぞれ必要と原文に記載されています。導入時はこれらの変更が取り込まれたバージョンかどうかを確認する必要があります。
- 速度向上はどのくらい期待できますか。
- 原文ではオンデバイスでデコードが最大3.13倍、H100で最大2.66倍、エンドツーエンドで最大2.62倍と報告されています。ただしこれは6種類の評価タスクでの結果で、効果はタスクやハードウェアによって異なります。画像の入力処理が実行時間の大半を占める場合は改善幅が小さくなります。
- メモリやパラメータの増加はどの程度ですか。
- ドラフターは約2億8000万パラメータで、本体モデルに対する増加は8.9%と説明されています。3Bクラスのモデルに対して比較的小さい追加で済む設計ですが、推論時にドラフター用のメモリが別途必要になる点は考慮が必要です。
用語解説
- 投機的デコーディング
- 小さいドラフターモデルが候補トークンをまとめて提案し、本体モデルが検証して採用を決める推論高速化手法。出力の厳密性は保たれる。
- ドラフターモデル
- 投機的デコーディングで候補トークンを生成する補助モデル。本体より小さく、本体の隠れ状態を条件に使うことが多い。
- プリフィル
- 生成を始める前に、入力プロンプト全体を処理して内部状態を計算する段階。計算資源を多く消費し、入力が長いほど負荷が増える。
- ブロックサイズ
- 投機的デコーディングで1回の提案にまとめる候補トークンの数。大きすぎると受理率が下がり、小さすぎると効果が減る。
- GGUF
- llama.cppなどで使われるモデルのファイル形式。量子化済みの重みを単一ファイルにまとめて配布できる。
- VQA
- 画像に対する質問応答タスク。画像内容の理解や文字読み取りなど、複数の種類のベンチマークが存在する。
出典
Accelerating vision-language models with LFM2.5-VL-DSpark
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する