LFM2.5-VL-3B DSpark：Macで画像応答を2倍以上高速化する

ビジョン言語モデルの1つの要求は、写真を特徴に変えるステップ、入力コンテキストを読み取るプリフィル、回答トークン²を続けるデコード³に分けることができます。 DSparkは、小さなドラフトモデルが次のトークンバンドルを提案し、このモデルが検証されるようにして、デコードの繰り返しを減らします。カメラの写真をエンコードする前にそれ自体を省略するわけではありません。

そのため、短い回答の1行だけを必要とする領収書OCRは、デコードが高速化されても、完了時間全体が同じ倍率で減少しない可能性があります。逆に、画像の説明や翻訳のように数十から数百のトークンを生成すると、加速が体感されやすくなります。サイト速度画面はトークン生成倍率を適用し、全体の作業判断は画像サイズと回答長さを一緒に見るように設定しました。

Liquid AIが公開した6つのビジョン課題で、M5 MaxのMLX⁴-VLMデコードは2.30～3.13倍、全体完了時間は1.56～2.62倍速くなりました。 M3 Ultraのflama.cppデコードは1.57～2.14倍、全体は1.30～1.77倍でした。同じモデルでもエンジンとハードウェア、出力長が変わると倍率が変わります。

モデルカードには、基本的なLFM2.5-VL-3BがApple M5 Maxで228 tok / s、AMD Ryzen AI Max + 395から116 tok / sで導入されます。この値は、公開された特定のパスの基準点であり、すべての量子化⁵と画像で保証される速度ではありません。サイトでは、同じ機器が確認されている場合にのみ対応するDSpark範囲を使用し、他の機器にはランダムに移動しません。

M5 Maxの最も簡単な公式ルートは、MLX-VLMサーバーにターゲットモデルとDSparkドラフトモデルを一緒に割り当てる方法です。アプリ連携が必要な場合は、OpenAI準拠のエンドポイントを確認し、最初に1枚の固定画像と固定出力長でデフォルトの実行を保存します。加速をオンにした後は、回答内容が同じで、ドラフト承認記録が発生することを確認します。

M3 Ultraのようにflama.cppパスを書き込むときは、ターゲットF16 GGUF⁶、ビジョンプロジェクター、DSparkドラフトファイルがそれぞれ正しいことを確認してください。コンテキストを8192で小さく始め、ドラフトの最大長8を使用した公式の例に基づいて設定することができます。ファイルを1つだけ変更しても比較が壊れるので、コマンドとチェックポイント⁷ハッシュを一緒に保持します。

SGLangの公式例では、DSparkアルゴリズムとドラフトモデル、FlashInferドラフトアテンション⁸、ブロックサイズ9を指定します。最初は1つの要求と短いコンテキストで始まり、サーバーがモデルをアップロードして画像を受け取るようにします。その後、加速をオフにした同じ要求と比較して、ドラフト提案の数、承認数、完了時間を記録します。

ドラフトモデルは、本モデルとは異なる答えを最終出力する代替モデルではありません。このモデルは毎回提案を検証するので、貪欲な生成条件では同じターゲットモデルの結果を維持することができます。ただし、ランタイム⁹バージョンやサンプリング設定が異なると比較条件が異なるため、まったく同じ要求と生成オプションを使用する必要があります。

同じ写真と同じ質問で、デフォルトの実行とDSparkの実行をそれぞれ3回測定します。イメージ転送から最初のトークンまで、最初のトークンから最後のトークンまで、完全な完了時間を別に残します。写真の前処理時間が長い場合、デコード加速よりも画像サイズを小さくするほうが全体の体感に大きな影響を与える可能性があります。

ドラフト承認率が低い場合、または回答が非常に短い場合は、追加のドラフトモデルのコストが利得を相殺する可能性があります。 OCR・キャプション・翻訳のように繰り返す実際の作業3つを決めて中央値を比較してください。公開倍率ではなく、私の仕事で減らされた全体の待ち時間が加速を維持する基準です。