LFM2.5-VL-3B-DSpark 対 LFM2.5-VL-3B：どちらかを選ぶのではなく、どちらかをアタッチする

ここへ人々を導いている検索語は比較ですが、正直に言えば、LFM2.5-VL-3B-DSpark と LFM2.5-VL-3B は、どちらかを選ぶ二つのものではありません。後者はダウンロードして提供できる3.1Bの視覚言語モデルです。前者は279.5Mパラメータのドラフトモデルで、後者の前段に置かれ、そのデコードを速くするためだけに存在します。ドラフターをスタックから外せば何も生成しません。単独でベンチマークすることはできません。なぜなら「単独」は、それがサポートする構成ではないからです。本当の比較は、LFM2.5-VL-3Bを単独で動作させた場合と、同じモデルをドラフター付きで動作させた場合です。

そう読めば、判断は一つの問いに帰着する。余分なメモリと余分な実行時複雑性は、あなたのワークロードで意味を持つほどのレイテンシをもたらすのか？ Liquid AI 自身の数値は、デコード中心の処理ではイエスと言い、プリフィルが支配的な場合には明確にノーと言っている。そのどちらの側も、同社の外部では再現されていない。

横並びの2つのチェックポイント

両者の違いがすべてを物語っているのだから、速度の議論が始まる前に、その二つのリポジトリを並べて見る価値がある。

• 役割 — LFM2.5-VL-3B はテキストを生成し、画像についての回答を行います。LFM2.5-VL-3B-DSpark は検証を依頼するトークンを提案するもので、それ自体では実用的なものは何も生成しません

• パラメータ — ターゲットは3.1B、ドラフターはBF16で279.5M。Liquidはこれを、デプロイされるパラメータ数に対する8.9%の増加と見ている

• アーキテクチャ — ターゲットは、LFM2.5-2.6BバックボーンとSigLIP2 NaFlexビジョンエンコーダに基づくハイブリッドモデルです。ドラフターは、隠れ次元2,048の4つのフルアテンション層で構成され、grouped-query attentionに加えてマルコフヘッドと信頼度ヘッドを備えています。

• コンテキストウィンドウ — ターゲット用は32,768；ドラフターは自身のコンテキストを持たず、ターゲットのコンテキストを継承する

• ビジョンエンコーダ — ターゲット側にはSigLIP2 NaFlex 400Mを搭載。ドラフタには搭載されておらず、画像を直接見ることもない

• 語彙 — 128,000。そして、ドラフターの埋め込みとLMヘッドは複製されるのではなくターゲットに紐付けられている。そのため、メモリ負担は279.5Mパラメータが示唆するよりも小さい。

• ライセンス — 両方ともLiquidのLFM1.0ライセンスで提供されており、これはHugging FaceではOSIライセンスではなく「その他」に分類されているため、商用展開の前に条件をよく確認してください。

• 形式 — ターゲットは safetensors、GGUF、ONNX、MLX の量子化として提供され、ドラフターは safetensors と約 567 MB の単一の F16 GGUF として提供されます

そのリストの1行は強調に値する。なぜなら、この組み合わせがそもそも機能する機械的な理由だからだ。ドラフターは小さな視覚モデルではない。視覚エンコーダを持たず、画像に一切触れない。ドラフターが下書きに使う隠れ層にトークンが到達する時点で、画像パッチもテキストトークンも等しくただのテンソルであり、したがってドラフト計算にとってモダリティは見えない。だからこそLiquidは、テキストモデル向けに開発された手法を、設計し直すことなくVLMに移植できたのだ。

ドラフターが変更するものと、そのままにするもの

ターゲットモデルは変わりません。それはマーケティングではなく、投機的デコーディングの正確性に関する特性です。貪欲法では、すべてのドラフトトークンがターゲットによって検証されるため、出力はターゲットが単独で生成した場合とまったく同じになります。非ゼロ温度で一致したサンプリング設定では、出力分布はターゲットの分布と一致します。ドラフターはメモリを時間と引き換えにするだけで、それ以外には何も触れません。

つまり、LFM2.5-VL-3Bについて見つけられるあらゆる品質指標は、ペア構成にもそのまま当てはまる。Liquid自身の評価では、ターゲットはScreenSpot-v2で80.7、BLINKで61.5、MuirBenchで58.3、MMEで73.1、MMStarで63.3、ChartQAで81.3、POPEで88.7を記録している。すべてベンダーによる報告であり、独立に再現されたものは一つもなく、ドラフターが接続されているかどうかに関係なくすべて等しく当てはまる。ここで比較検討すべき品質対速度のトレードオフは存在せず、それを提示している比較ページはモデルを誤って解釈している。

変わるのは、ウォールクロック時間における1トークンあたりのコストだ。Liquidは、単一のH100上でBF16、SGLang経由、ブロックサイズ9の場合に2.04×から2.66×、Apple M5 Max上でMLX-VLM経由、ブロックサイズ8の場合に2.30×から3.13×、M3 Ultra上でllama.cpp経由の場合に1.57×から2.14×のデコード高速化を測定している。エンドツーエンドでは、同じ実行がそれぞれ1.64×–2.27×、1.56×–2.62×、1.30×–1.77×となる。これらの対が議論のすべてだ。デコードはエンドツーエンドの約2倍改善し、その差はドラフターが触れることのできないワークロードの部分である。

ベンダーが述べたプレフィル問題

Liquid自身の発表の中で最も有用な一文は、その見出しを無制限に解釈することに異を唱えている一文だ。視覚言語推論には、テキスト推論にはないプリフィルコストがかかる。画像は視覚エンコーダを通り、その後、言語バックボーンがそのエンコーダが出力する数百の視覚トークンを処理する。エッジデバイスでは、そのプリフィルがエンドツーエンド遅延の大きな割合を占める。投機的デコーディングが高速化するのはデコードだけであり、視覚エンコードとプリフィルは変わらない。プリフィルが支配的な場合、デコードの3倍の高速化も、エンドツーエンドでははるかに小さな利得にしかならない。

それは、ベンダーが自社製品に適用したアムダールの法則であり、このページを誰が読むべきかを形作るはずだ。単一のスキャンされたページの長い文字起こし、キャプション、1枚の画像を引き継ぐマルチターン会話——デコード負荷が高く、ドラフターはその279.5Mパラメータに見合う働きをする。大きな高解像度画像についての短い質問——プリフィル負荷が高く、ドラフターはその価値を発揮しない。同じターゲットを高並行度のサーバーに置くと、状況は再び変わる。Liquidは単一の数値ではなく、スループットと対話性のフロンティアを測定し、DSparkが試験されたすべての並行度レベルで優位を保つ一方、並行度が上がるにつれてその差は縮まると報告している。

同じソースからの、より小規模なスコープに関する注記が2つあります。すべての測定では、視覚エンコーダーと言語バックボーンの両方に16ビット処理を使用しており、量子化モデルの高速化はこのリリースの対象範囲外です。3B VLMの魅力は数ギガバイトに収まることにあるからといって、4ビットのターゲットエクスポートをドラフターと組み合わせる計画なら、その組み合わせは測定されたものではありません。

添付することで実際にかかる負担

メモリは目に見えるコストであり、カードはそれを定量化している。デプロイされたスタックではパラメータが8.9%増える。実行時の複雑さは目に見えないコストだ。SGLangにはv0.5.19以降が必要で、起動行に次を指定する必要がある：--speculative-algorithm DSPARK、ドラフトモデルのパス、ブロックサイズ；カード自体の例では、radixキャッシュを無効化し、静的なメモリ割合を固定している。これらは、あなたが今や考慮しなければならないサービング上の判断だ。MLX-VLMにはv0.7.2以降が必要で、ドラフターを次で取り込む：--draft-model、ただし、そこのDSparkデコードは現在greedyサンプリングを使用しているため、temperatureを0に強制する必要がある — アプリケーションがサンプリングの多様性に依存しているなら、これは実際の制約だ。llama.cppは、元のsafetensorsチェックポイントではなく、GGUFターゲットとペアにしたGGUFドラフターを通じて動作する。

ベンチマークではなく本番環境でこそ表面化するコストがもう一つある。ドラフターとターゲットは常に一緒に動かさなければならない。両者の間のバージョンずれは、単一モデルのデプロイでは存在しない障害モードであり、どちらか一方だけを独立してロールアウトすることは、今や2つの成果物を扱う問題になっている。

これはセルフホスト型のペアリングです。OrcaRouter は LFM2.5-VL-3B やそのドラフターをルーティングしません — どちらもご自身でダウンロードして配信していただくことになります — したがって、ルーティングの論点は、この小型モデルが受け渡す先のすべてに関わってきます。3B のエッジ VLM をドラフターと組み合わせているほとんどのデプロイメントでも、小型モデルが答えるべきではないクエリは依然として存在し、それらを送る先は各プロバイダーの定価で 200 以上のモデルをカバーし、プロバイダーが劣化した場合には自動フェイルオーバーを行う単一のエンドポイントであり、ベンダーごとに 1 つずつ統合するのではなく 1 つの統合で済むということです。また、プロバイダーが値下げした瞬間に、次回の契約更新時ではなくその日のうちに料金に反映されるということでもあります。

どれをダウンロードすればいいですか？

ワークロードがデコード中心で、ハードウェアが Liquid が検証した3つのうちのいずれかであれば、ドラフターを組み込んでください。欠点は限定的です。出力がターゲットのものであることが証明可能で、メモリコストはモデルの10分の1未満だからです。レイテンシがプリフィル中心である場合、量子化されたターゲットを実行している場合、またはその制約が解除されていないランタイムで非貪欲サンプリングに依存している場合は、LFM2.5-VL-3B を単体で実行してください。それ自体が高速です。M5 Max で毎秒228トークン、AMD Ryzen AI Max+ 395 で116、Galaxy S26 Ultra で20で、いずれもベンダー公表値であり、メモリは約3 GBです。

まだ誰もあなたに言えないのは、Liquidの数字があなたのハードウェア上でも成り立つかどうかだ。このドラフターは執筆時点でHugging Faceで37ダウンロードされており、その表にあるどの数値についても独立した再現はない。エンジニアリングは堅実で、正確性の議論は主張ではなく証明である。しかし、その大きさは測定値であり、1つの研究室が1組のマシンで得た測定値こそ、容量計画に組み込む前に自分で検証すべき類の数値だ。

OrcaRouterは1つのキーで200以上のモデルにアクセスでき、各プロバイダーの定価が0%のマークアップでそのまま適用され、プロバイダー間の自動フェイルオーバーも行われます。 プロバイダーの定価が0%のマークアップでそのまま適用 このページのペアリングはどちらにしてもセルフホストです - ルーターは小型モデルが引き渡すすべてのもののためのもので、プロバイダーの値下げが同じ日にあなたの料金に反映されるということです。