Macの画像AIはDSparkでどこまで速くなる？ LFM2.5-VLをM5 Maxで試す

画像を渡して「このグラフを説明して」と頼んだとき、内容は読み取れているのに、回答が出そろうまで待たされる。ローカルで動く画像AIを使っていると、モデルの賢さとは別に、この待ち時間が気になります。

Liquid AIの LFM2.5-VL-DSpark は、その回答生成を速くするための小さな補助モデルです。発表には「Apple Siliconで最大3.13倍」という数字が登場しますが、手元のMacで同じ倍率になるとは限りません。画像の大きさ、質問、回答の長さ、ソフトウェアの設定によって結果は変わります。

そこで、M5 Maxを搭載した手元のMacに本体とDSparkをダウンロードし、同じ画像・同じ質問で比較しました。本記事では、まず測定結果を示し、その後に仕組み、再現手順、結果の読み方を説明します。

検証日：2026年9月26日。 使用したのはMLX-VLM 0.7.2です。掲載するスクリーンショットは、このMacで実行したログを表示した自作の検証画面をブラウザで撮影したものです。説明用のアニメーション図解とは分けて掲載しています。

このMacでは、どれくらい速くなったか

今回の条件では、回答生成は1.45〜4.15倍、画像の前処理を含む処理全体は1.17〜2.06倍になりました。 通常生成とDSparkの回答本文・トークンIDは、各タスクの全本測定で一致しました。

倍率は「生成速度：DSparkの中央値÷通常の中央値」「処理全体：通常の時間中央値÷DSparkの時間中央値」で計算しています。各回の倍率を平均したものではありません。

短い抽出で4.15倍になったからといって、公式の3.13倍を一般的に上回ったと結論づけることはできません。今回は定型的なJSONを53トークン生成する単一の入力です。公式とはタスク集合も回答長も計測の仕組みも異なります。

英語の説明は約5.77秒から約2.81秒へ短縮しました。一方、日本語の説明は約3.54秒から約3.01秒で、短縮は約0.52秒です。同じMac・同じ画像でも、質問と回答によって効果は変わりました。

ここでいう「生成速度」はMLX-VLMが返す generation_tps です。単位の tok/s は、1秒あたりに生成したトークン数を表します。トークンはモデル内部で文章を扱う単位であり、日本語の1文字や英語の1単語と常に一致するわけではありません。

もう一つの「処理時間」は、モデルをメモリへ載せた後、画像と質問を渡してから回答が終了するまでの実時間です。画像の前処理を含み、モデルのダウンロード・読み込み・ブラウザ描画は含みません。公式のEnd-to-Endと計測境界が完全に同じとは確認していないため、記事では今回の処理時間と呼びます。

自作の検証画面をChromeで撮影。表は各3回の中央値を表示しています。

この測定は、合成画像1枚と3種類の質問を使った小規模な比較です。COCOなどの公開データセットを使った公式試験を再現したものではありません。測定した倍率を、そのまま写真、帳票、UI操作、複数画像のすべてに当てはめることはできません。

「画像を見るAI」と「下書きするAI」を分ける

VLM（Vision-Language Model）は、画像と文章を入力として扱うモデルです。たとえば売上グラフの画像と「一番売れた曜日は？」という質問を一緒に渡すと、画像を読み取り、文章で回答します。今回の本体が LiquidAI/LFM2.5-VL-3B です。

一方、LiquidAI/LFM2.5-VL-3B-DSpark は、単独で画像について回答するためのモデルではありません。本体が次に出しそうな文章の候補を先回りして作る、下書き役（Drafter）です。本体は Target Model と呼ばれます。

Liquid AIのモデルカードでは、この下書き役は約2億7,950万パラメータの実験的なモデルとして案内されています。今回の組み合わせは次のとおりです。出典：DSparkモデルカード

この下書き役を、名前の似ていない別のVLMへそのまま付けることはできません。本体の内部状態を利用するため、対応する本体と組み合わせる必要があります。また、「DSparkという方式が他のVLMにも使われること」と「このLiquid AIのチェックポイントを他のモデルへ流用できること」は別の話です。

本体が一つずつ考える間に、小さなモデルが先を予測する

通常の自己回帰生成では、確定済みの文章をもとに次のトークンを生成し、それを入力に加えて次へ進みます。長い回答では、この処理を何百回も繰り返します。

Speculative Decoding（投機的デコーディング）は、下書き役が複数の候補を作り、本体がまとめて確かめる方式です。候補の先頭から一致した部分を採用し、食い違ったところは本体の判断に従います。先の候補がよく当たれば、本体の検証1回で複数トークン分だけ進めます。

次の図では、下書き役が勝手に回答を決めるのではなく、本体が採否を決める流れに注目してください。

下書き、検証、確定を繰り返す概念図です。毎回同じ個数が採用されるわけではありません。静止画版

この方法で速くなるかは、下書きの的中率だけでは決まりません。候補を作る時間、まとめて検証する時間、採用されなかった部分を戻す処理にもコストがかかります。候補がほとんど採用されなければ、小さなモデルを追加した分だけ処理が増える可能性もあります。

Speculative Decodingは、重みの桁数を減らす量子化とは異なる高速化の軸です。量子化はモデルの表現精度やメモリ量を変えます。Speculative Decodingは、本体の判断を検証に使いながら生成手順を工夫します。一般的な方式では、適切な検証・補正を行うことで本体の出力分布を保てます。参考：Fast Inference from Transformers via Speculative Decoding

なぜ画像モデルにも使えるのか

画像のピクセルを、そのまま下書き役が文章として読むわけではありません。本体の画像処理を経て、画像の情報も内部の数値表現になります。下書き役は本体の途中の情報、つまり隠れ状態を使って先のトークンを予測します。Liquid AIは、この段階では画像とテキストを同じ生成アルゴリズムで扱えると説明しています。出典：Liquid AI公式ブログ

ただし、画像を最初に読み込む処理そのものが省略されるわけではありません。この点が、次の「生成速度」と「待ち時間」の違いにつながります。

生成が3倍速くても、待ち時間が3分の1とは限らない

VLMの処理を大きく分けると、画像の前処理、画像特徴の計算、質問を含む入力の処理、回答生成があります。DSparkが主に改善するのは最後の Decode（回答生成） です。

Vision Encoding は画像をモデルが扱える特徴へ変換する工程、Prefill は画像由来の情報と質問を本体がまとめて処理する工程です。これらが長いと、回答生成だけを高速化しても、全体では改善幅が小さくなります。

どの工程に効くのかを図にすると、見積もりの誤解を避けやすくなります。

回答生成が高速化しても、それ以前の処理は必要です。図の大きさは時間の比率を表していません。静止画版

たとえば、説明用の仮定として「画像と質問の処理に2秒、回答生成に6秒かかる」とします。合計8秒です。回答生成だけが3倍速くなれば、6秒が2秒になり、全体は4秒です。改善は2倍になります。

一方、入力側に2秒、回答生成に0.6秒かかる短い抽出なら、同じ3倍の生成高速化でも合計は2.6秒から2.2秒へ変わるだけです。この数値は今回の実測ではありません。高速化できない部分が残ると全体の改善幅が制限される、という考え方を説明する例です。

公式の「最大3.13倍」は、M5 Max上の特定の試験におけるDecodeの値です。同じ公開結果のCOCOでは、End-to-Endは2.59倍とされています。GPUや別のMacの数字を見る場合も、チップ、ランタイム、タスクをセットで読む必要があります。出典：公式モデルカードの測定表

「MLX-VLMの数字がllama.cppより大きいから、常にMLX-VLMの方が優秀」とは判断できません。公開表ではハードウェアも異なるためです。今回は、Apple Silicon上でPythonから比較しやすいMLX-VLMに絞りました。

検証環境と、比較に使った画像

今回、実際に使った環境は次のとおりです。

他のアプリをすべて終了するような専用ベンチマーク環境ではなく、通常のデスクトップ利用状態で実行しました。温度やGPUクロックも固定していません。そのため、小数点以下の数字を別のMacでそのまま再現できる、という意味ではありません。

このMacで記録した構成と入力条件をまとめた、自作の検証画面です。

架空の売上ダッシュボードを使う

顧客の帳票や実際の業務画面は使わず、検証用に作った架空の画像を入力しました。英語のラベルと数字で構成し、どの数字が正しいかを人が確認できるようにしています。

この画像は実在の店舗のデータではありません。今回の入力素材として作成した1,120×760ピクセルのPNGです。

画像の正解データは、合計売上126,000円、注文数420件、平均注文額300円です。日別売上は月曜日から順に12,000円、15,000円、13,000円、18,000円、21,000円、27,000円、20,000円としました。最大は土曜日、最小は月曜日です。

この画像に対して、次の三つの依頼を使いました。

英語画像への日本語回答は試しましたが、日本語の画像に対するOCR性能を試したわけではありません。「日本語タスク」と「画像内の日本語文字の読み取り」を混同しないようにしてください。

測定手順：一度動かすだけで終わらせない

初回の実行には、ライブラリの初期化やカーネルの準備などの影響が入ります。モデルのダウンロード時間まで含めて比較すると、DSparkそのものの効果を測れません。

今回のスクリプトでは、本体と下書き役を先に読み込み、各タスク・各方式を一度ウォームアップしました。その後、通常生成とDSparkを交互に実行し、3回ずつの中央値を集計しています。繰り返しの順番は、1回目が通常→DSpark、2回目がDSpark→通常、3回目が通常→DSparkです。

手順の全体像は次の図のとおりです。

測定回数は各条件3回です。初回のウォームアップ値は中央値から除外しています。静止画版

今回、記録したもの

測定ログには生成速度だけでなく、処理秒数、最初のトークンが届くまでの時間、出力トークン数、停止理由、回答本文、トークンID、下書き採用カウンターを保存しました。最初のトークンまでの時間は TTFT（Time To First Token） として扱っています。

TTFTは「最初の文字が画面に見えるまで」と完全には同じではありません。今回の計測では、Pythonのストリームで最初のトークンを受け取るまでです。ブラウザの描画時間は含めていません。また、生成速度はライブラリ内部の指標なので、少ないトークン数の測定ほどタイミング境界の影響を受けます。

本体と下書き役は同じプロセスに読み込んでいます。通常生成の計測時は下書き役を渡していませんが、下書き役の重み自体はメモリに残っています。そのため、今回の実験から「通常生成に対してメモリが何GB増えたか」を測定結果として述べることはできません。

画像の前処理とVision Encodingは各リクエストで実行し、アプリ側で画像特徴や会話のKVキャッシュを使い回す設定は渡していません。モデル重みを読み込む処理は測定の外です。こうした境界を先に決めておくと、何が速くなったのかを説明しやすくなります。

出力は同じだったか。画像の数字は正しく読めたか

3タスク×2方式×3回、合計18回の本測定では、各タスク内の回答本文とトークンIDがすべて一致しました。 同じ方式の中で繰り返したときも同じ回答でした。6回のウォームアップは、この18回に含めていません。

短い数値抽出で得られた回答は次のとおりです。これは予想される出力例ではなく、このMacで実際に生成された本文です。

{
  "total_sales_jpy": 126000,
  "orders": 420,
  "average_order_jpy": 300,
  "best_day": "Sat",
  "best_day_sales_jpy": 27000
}

本文は両方式で一致。画面内の速度は各方式の本測定1回目で、先ほどの中央値の表とは値が異なります。

5項目を画像の正解と照合し、すべて一致しました。英語・日本語の説明でも、合計、注文数、平均、7日分の売上、最大・最小の曜日は今回の画像と一致しています。

ただし、指示への追従や説明の妥当性まで完全だったわけではありません。 日本語では約600字を求めたのに対し、実際の本文は346字でした。全条件の停止理由は stop で、出力上限による途中切れではありません。

また、日本語の回答には「月曜日の低い売上は、顧客の来店が少ない可能性」といった推測が含まれます。画像にあるのは売上額で、日別の来店数はありません。売上の違いが客数によるのか、客単価によるのかはこの画像だけでは分かりません。英語回答も休日の余暇やプロモーションを理由の候補に挙げましたが、画像から確認できた事実ではありません。

日本語回答の比較画面。表示している本文は本測定1回目の結果です。速度向上と、回答が業務上妥当かどうかは別に評価します。

下書きの採用率にも差があった

同じタスクの3回では採用カウンターも一致しました。この表は下書きの採用分であり、本体側の確定トークンを加えた「1回で進む総トークン数」ではありません。今回のJSONでは候補がよく採用され、日本語説明では採用率が低くなりました。この差は今回の入力条件での観測であり、日本語全般の特性を示す結果ではありません。

TTFTの中央値も、短い抽出では通常0.508秒／DSpark0.494秒、英語説明では0.794秒／0.805秒、日本語説明では0.925秒／1.369秒でした。最初のトークンまでの待ち時間が一律に改善する結果にはなっていません。 試行間の負荷変動もあるため、差の原因をこの測定だけで特定はしません。

出力を確認するときは、文字列の一致と、画像に対する正しさを別々に評価します。通常生成とDSparkが同じ誤答を出すこともあり得るからです。

次の図は、今回のような小規模検証でも分けて確認したい三つの観点です。

出力が一致しても、読み取った値が正しいとは限りません。静止画版

Speculative Decodingはgreedy生成で本体の出力を再現するよう設計されています。ただし、実際のランタイムでは計算順序、数値精度、実装の不具合なども確認対象です。「temperature 0にしたので、確認せずに完全一致と書く」のではなく、実際の出力を比較することが大切です。

なお、temperatureを0以外にした場合の分布保持という一般論から、「今回のMLX-VLM実装でも非ゼロtemperatureで試せる」とは言えません。今回のDSpark実行はgreedyのみを使用しています。

自分のMacで再現する

ここからは、記事と同梱した画像・スクリプトを使って実行する手順です。APIキーは使いません。初回はPythonパッケージとモデル重みをインターネットから取得しますが、取得後の画像処理・文章生成はこのMacのMLXで行います。

検証パッケージのフォルダーには、この記事、assets/、scripts/、evidence/ が入っています。ターミナルでそのフォルダーへ移動してから実行してください。

1. Pythonの仮想環境を作る

今回使ったPythonは3.12です。仮想環境を作り、既存の開発環境とパッケージを分けます。

# 記事のフォルダー内で実行する
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install -r evidence/requirements-lock.txt

同梱の requirements-lock.txt は実際に使ったパッケージ一覧です。最新バージョンへ一括更新すると、同じ記事の手順でも内部実装や出力が変わることがあるため、再現時はまず固定した環境で試します。

今回のMLX 0.32.2は、このMacに対応するmacOS 26向けの配布物が入りました。古いmacOSやIntel Macでもこのまま動く、という検証はしていません。インストール時に対応する配布物が見つからない場合は、PythonとOSの組み合わせを確認してください。

2. 同じモデルの版を取得し、FP16で比較する

主要な再現コマンドは一つです。

# 初回はモデルのダウンロードも行う。取得済みのモデルは再利用される
python scripts/benchmark.py --cache-dir model-cache --repeats 3

このスクリプトは、evidence/model-revisions.json に保存したHugging FaceのコミットIDを指定してモデルを取得します。配布元の main が後日更新されても、今回と同じ重みを参照するためです。

内部では、画像モデルを読み込んだ後に本体と下書き役をFP16へそろえています。重要な部分を抜き出すと、次の形です。これは同梱スクリプトの説明用抜粋なので、再現には上のコマンドを使ってください。

# model と draft は、固定したリビジョンから読み込んだモデル
model.set_dtype(mx.float16)
draft.set_dtype(mx.float16)
mx.eval(model.parameters(), draft.parameters())

「16bitだから同じ条件」と済ませず、FP16とBF16も区別します。どちらも16bitですが数値の表現形式が異なります。今回の本体チェックポイントの設定にはBF16が記載されており、公式のApple側測定条件に寄せるため、測定スクリプトでは明示的にFP16へ変換しました。

3. 出力ファイルを確認する

正常に終わると、以下のファイルが更新されます。元の測定記録を残したい場合は、パッケージをコピーしてから再実行してください。

ブラウザで確認したい場合は、別のターミナルから同じフォルダー内で次を実行します。

# ローカルの結果確認ページを配信する。外部からの接続は受け付けない
python -m http.server 8786 --bind 127.0.0.1

ブラウザで http://127.0.0.1:8786/verification.html を開くと、測定表と生成された回答を確認できます。記事のプレビューは http://127.0.0.1:8786/preview.html です。終了するときはサーバーを起動したターミナルで Control+C を押します。

4. まず1回動かすならCLIも使える

公式CLIでも、通常生成とDSpark付き生成が動くことを別途確認しました。記事フォルダー内で次を実行します。ここではCLIのデフォルト読み込みを使うため、前述の明示FP16測定とは別の動作確認です。

# benchmark.py で使ったモデルの保存先をCLIでも使う
export HF_HUB_CACHE="$PWD/model-cache"

# まず本体だけで画像の数値を取り出す
python -m mlx_vlm.generate \
  --model LiquidAI/LFM2.5-VL-3B \
  --image assets/sample-dashboard.png \
  --prompt "Read the dashboard. Return only a JSON object with total_sales_jpy, orders, average_order_jpy, best_day, best_day_sales_jpy. Do not explain." \
  --max-tokens 128 --temperature 0 --verbose

下書き役を追加した実行は次の形です。

# 同じ画像・質問にDSparkを追加する
python -m mlx_vlm.generate \
  --model LiquidAI/LFM2.5-VL-3B \
  --draft-model LiquidAI/LFM2.5-VL-3B-DSpark \
  --draft-block-size 8 \
  --image assets/sample-dashboard.png \
  --prompt "Read the dashboard. Return only a JSON object with total_sales_jpy, orders, average_order_jpy, best_day, best_day_sales_jpy. Do not explain." \
  --max-tokens 128 --temperature 0 --verbose

CLIのログは 通常生成 と DSpark を保存しています。これらのモデル名による指定は、その時点の配布元の版を参照します。今回と同じ版を固定した比較には benchmark.py を使ってください。

CLIは手軽に動作確認するための入口です。一方、今回の表は、FP16への変換、ウォームアップ、繰り返し、出力一致の確認を含めたPythonスクリプトで取得しています。CLIの1回の値と、表の中央値を同じ測定として扱わないでください。

補足すると、今回のログには Drafter detected: dflash と表示されました。MLX-VLM 0.7.2ではDSparkを内部の dflash 系実行経路へ振り分けるためです。この文字だけで誤った重みが使われたと判断せず、読み込んだモデル名と採用カウンターを確認してください。

--draft-block-size 8 の読み方

今回のMLX-VLM 0.7.2では、DSparkの候補数を計算する箇所に proposal_length = block_size - 1 という処理があります。つまり、指定した幅には基準となるトークンが含まれます。8 と指定したことを、そのまま「毎回8個の下書きが採用される」と読み替えることはできません。出典：使用バージョンのDSpark実装

さらに、実際に採用される個数は質問や生成途中の文脈で変わります。採用率を見る場合は、「提案した個数」「採用した下書きの個数」「本体側で確定した分を含む進み方」を区別してください。同梱ログでは、ライブラリから得た accept_lens と draft_lens を保存しています。

ハマりやすい点と、切り分けの順番

今回の手順を別の環境で再現するときは、問題を一つずつ切り分けます。まず通常生成が動くかを確かめ、その後に下書き役を追加すると原因を絞りやすくなります。

動作確認と速度測定を分けて進めるための確認順です。静止画版

今回も試行間には変動があり、英語説明の生成速度は通常69.24〜77.49 tok/s、DSpark157.77〜178.33 tok/sの範囲でした。3回の中央値は、このばらつきを消す保証ではありません。

「速かった回だけを選ぶ」ことも避けたい点です。同じ入力でも他のアプリの負荷や温度などで時間は動きます。今回は3回の中央値にしましたが、業務の見積もりに使うなら、実際の画像を複数集め、より多くの回数と負荷条件で確認する必要があります。

メモリとライセンスは、速度とは別に確認する

今回のMacは128GBのユニファイドメモリを搭載しています。この環境で動いたことから、16GBモデルでも同じ条件で余裕をもって使える、とまでは言えません。重みに加えて画像処理の一時領域、KVキャッシュ、macOSや他のアプリがメモリを使うためです。

3B級の本体を16bitで保持すると、重みだけで数GBを使います。今回取得した本体のSafetensorsファイルは約6.25GBでした。下書き役も別途必要です。ただし、ファイルサイズはそのまま推論中の最大メモリ使用量を表すものではありません。

また、重みが公開されていることと、あらゆる商用利用が無条件に許可されていることも別です。配布モデルの LFM Open License v1.0 には、年間売上1,000万米ドルを基準とする商用利用条件があります。利用主体や条件は実際のライセンス本文に照らして確認してください。この記事の速度検証は、個別の商用利用可否を判断するものではありません。出典：モデルに付属するLICENSE

どんな用途で試す価値があるか

今回のような画像説明では、短いJSONだけを返す場合と、長めの分析を書く場合で、待ち時間の内訳が変わります。導入判断では、先に実際の業務に近い質問を用意するのがよいと思います。

短い応答を何度も繰り返す用途では、1回あたりの改善が小さくても累積で効く場合があります。ただし、UI操作や外部APIの待ち時間が大きければ、VLMだけを高速化しても処理全体の効果は限定されます。今回はUIエージェントを組み立てていないため、エージェント全体の改善率は測っていません。

量子化モデルとの組み合わせも別の検証課題です。今回の値はFP16の本体と下書き役によるもので、4bit版へ変更して同じ倍率が得られるとは限りません。メモリを減らす実験と、生成を速める実験を分けて比較すると、どの設定が効いたのかが分かりやすくなります。

おわりに

M5 Max上でLFM2.5-VL-3Bと専用DSparkを組み合わせたところ、今回の3タスクでは生成速度が1.45〜4.15倍になり、回答本文とトークンIDも一致しました。英語の画像説明では、前処理を含む待ち時間を約5.77秒から約2.81秒へ短縮できました。

ただし、日本語説明の処理全体は1.17倍にとどまり、指定した文章量や、画像から確認できない原因の推測といった課題も残りました。DSparkが変えるのは生成の進め方であり、本体の理解力を別の高性能モデルへ置き換えるものではありません。

手元の用途に取り入れるなら、まず画像1枚と質問一つを固定し、通常生成が正しく動くことを確認します。その上でDSparkを追加し、生成速度、処理時間、出力の一致をそれぞれ測る。この順序なら、「最大何倍」という数字だけに頼らず、自分のMacと用途にとって意味があるかを判断できます。

参考資料と検証ファイル

公式発表の内容と今回の実測を区別するため、参照先と測定記録を残しています。

• Liquid AI：LFM2.5-VL-DSparkの公式発表
• Hugging Face：使用したDSparkのモデルカード
• Hugging Face：本体LFM2.5-VL-3B
• MLX-VLM 0.7.2のリリースノート
• Speculative Decodingの基礎論文
• 再実行用スクリプト / 測定結果のJSON / 全実行ログ

確認範囲： このMacでのMLX-VLMによる通常生成・DSpark生成、合成画像1枚、3種類の質問、各条件3回の測定。llama.cpp、SGLang、量子化版、他のMac、継続稼働するAPIサーバー、実務データセットでの評価は含みません。