LFM2.5-VL-3B-DSpark：Liquid AIの279.5Mドラフター、誰かが発表する6日前に出荷されていた

この話には、LFM2.5-VL-3B-DSpark が新しいモデルだというバージョンがある。そうではない。これは 279.5M パラメータの投機的デコーディング用ドラフトモデルで、存在する目的はただ一つ——Liquid AI 自身の視覚言語モデル LFM2.5-VL-3B をより速くデコードさせること——に限られており、単体では使える答えを生成できない。それでも読む価値があるのは、その時系列だ。重みは 2026 年 9 月 18 日に Hugging Face に置かれ、発表は一切添えられず、6 日間そこに留まり、9 月 24 日になってようやくベンダーのブログ記事が付いた。Radar はその隙間にこのリポジトリを捉えた。

そのギャップは、現時点で知り得る範囲の境界でもある。リポジトリにあるもの――パラメータの内訳、ブロックサイズ、フレームワーク連携、ライセンス――はすべて、あなたや私が開けるディスク上のファイルだ。高速化の数値はすべてベンダーが測定したもので、Liquid自身のベンチマークハーネスによるものであり、社外で再現した例は誰も公表していない。本稿は、その二つの山を意図的に分けたままにしている。

リポジトリに実際に含まれているもの

モデルカードを開けば、その構造は明白だ。LFM2.5-VL-3B-DSparkは、メタデータ内でターゲットが固定されているドラフトモデルである：base_model: LiquidAI/LFM2.5-VL-3B別のモデルを指定することはできず、単独で提供することもできない。

• ドラフトパラメータの合計 — 279.5M、BF16、そのうち193.0Mは4層デコーダスタック、65.5Mはマルコフヘッド、21.0Mは隠れ状態投影、6.4kはノルムと信頼度ヘッドです。

• バックボーン — 4つのフルアテンション層、隠れサイズ2,048、中間サイズ6,144（SiLU/SwiGLU付き）、32個のアテンションヘッドと8個のキー・バリューヘッドによるグループ化クエリ・アテンション、ヘッド次元64

• 追加ヘッド — ランク256のマルコフヘッドと信頼度ヘッド。これがDSparkのドラフティングを単なる並列ドラフターと区別する点です

• ブロックサイズ — トレーニング時は9、推論時はハードウェアに応じて8または9、Apple siliconでは特に8

• 語彙 — 128,000。ドラフトに引き継がれるのではなく、ターゲットに紐づけられている

• デプロイされたスタックにおける比重 — Liquidは、ドラフターがデプロイ時のパラメータ数を8.9%増加させると述べている

8.9%という数字を覚えておくべきだ。このクラスのモデルの売り文句は決して「高速な推論は無料」ではなく、「高速な推論にはモデル1つ分のおよそ10分の1のメモリを要する」というものだ。3.1Bのターゲットに279.5Mの追加パラメータを載せる場合、その負担はドラフター単体のサイズから想像されるよりも小さい。なぜなら、埋め込みとLMヘッドはターゲットに結び付けられており、複製されないからだ。

DSparkはLiquidモデルである前に、DeepSeekの技術である

この命名は混乱を招きやすいので、正確を期す価値がある。DSparkはLiquid AIの発明でも、モデルファミリーでもない。別の研究ラインによる投機的デコーディングのフレームワークであり、2026年7月の論文では、半自己回帰生成を伴う信頼度スケジュール型投機的デコーディングとして説明されている。その3つのアイデアは次のとおりだ。1回のフォワードパスでブロック全体をドラフトする並列バックボーン。隣接するドラフトトークン間の依存関係をある程度回復させ、ブロック終端で受理率が崩壊しないようにする軽量な逐次モジュール。そして、ドラフト自身の信頼度が末尾は棄却されると示唆する場合に、リクエストごとに検証ウィンドウを短縮する検証器である。

Liquidがしたのは、そのレシピを視覚言語モデルに適用し、チェックポイントをリリースすることだった。モデルカードは、この移植が聞こえるほど劇的ではないことを率直に述べている。ドラフターの観点では、モダリティは無関係だ。なぜなら、トークンが隠れ層に到達するころには、画像パッチもテキストトークンもどちらも単なるテンソルだからだ。だからこそ、テキストモデルで開発された技術は、再発明されることなくVLMに移植される — そして、ドラフターを新しい能力として売り込めないのも同じ理由だ。

LiquidはすでにテキストDSparkドラフターを出荷していた——2.6B、8B-A1B、1.2B-Instructのコンパニオンは2026年8月に公開され、GGUFエクスポートは8月19日に続いた。ビジョンドラフターは同じアイデアをマルチモーダル分岐に拡張したもので、一連の4番目か5番目のエントリーであり、デビューではない。

高速化の数値、そしてそれを測定したのは誰か

以下に示す数値はすべてLiquid自身のもので、Liquidのベンチマーク基盤上で収集されたものであり、独立した再現は一つもない。これらは期待できる結果ではなく、ベンダーが示す上限値として扱うべきだ。このカードはデコードの高速化とエンドツーエンドの高速化を分けて示しており、その点は見出しの数字よりも重要だ。

• 最高のデコード高速化 — COCO で 3.13×、Apple M5 Max 上の MLX-VLM による計測、ブロックサイズ 8、FP16、バッチサイズ 1、温度 0

• GPUデコードの最高速度向上 — COCOで2.66倍、単一のH100 80GB上のSGLang、BF16、ブロックサイズ9

• 最高のllama.cppデコード高速化 — COCOで2.14倍、Apple M3 Ultra、ブロックサイズ8

• 6つのビジョンタスクにわたるH100デコード範囲 — 2.04×～2.66×、エンドツーエンドでは1.64×～2.27×

• M5 Max デコード範囲 — 2.30×～3.13×、エンドツーエンド 1.56×～2.62×

• M3 Ultra デコード範囲 — 1.57×～2.14×、エンドツーエンド 1.30×～1.77×

• ドラフト受理 — ターゲット検証パスあたりおよそ3.2～4.5トークンが受理され、3つすべてのスタックにおいて

それらの範囲に見られるパターンこそが、正直な部分だ。エンドツーエンドの改善幅は、常に各ペアのうち小さい方であり、それはドラフターがデコーディングだけを高速化し、それ以外は何も速くしないからだ。同じドラフターが同じブロックサイズでも、あるスタックでは3.13×、別のスタックでは1.57×になることにも注意してほしい。受理率はドラフターとワークロードの性質だが、実時間の短縮率はハードウェアとランタイムのオーバーヘッドの性質である。「2.66×高速」という主張も、どのスタックで測ったかが添えられていなければ、そのまま行動に移せる主張ではない。

カードにある正確性に関する2つのポイントは、率直に述べておく価値がある。というのも、それらこそがドラフターをそもそも本番環境で受け入れ可能にするものだからだ。貪欲デコーディングでは、投機的デコーディングは正確である。ターゲットがあらゆる提案トークンを検証するため、テキストはターゲットが単独で生成したものと同じになる。非ゼロ温度での一致したサンプリング設定では、ターゲットの出力分布を保持する。Liquidの言い回し — 得られるのは高速化であり、別のモデルではない — は、その範囲においては正確であり、温度を上げると受け入れ率が下がり、したがってスループットの利点が損なわれることについて、カードは正直である。

Liquidの投稿が認めていること

9月24日のブログ投稿は、モデルカードよりも有用だ。理由は一つ、限界を明言しているからである。視覚言語推論には、テキスト推論にはないプリフィルコストがかかる。画像を視覚エンコーダに通す必要があり、その後、言語バックボーンがそのエンコーダの生成する数百の視覚トークンを処理しなければならない。デバイス上では、このプリフィルがエンドツーエンドのレイテンシを支配する。投機的デコーディングが高速化するのはデコードだけだ。視覚エンコーディングとプリフィルは影響を受けない。Liquidは自社製品に対してアムダールの法則を持ち出し、プリフィルが実時間の大きな割合を占める場合、デコードを大幅に高速化してもエンドツーエンドではわずかな改善しか得られないと指摘している。

それは購入決定における実際の制約であり、このドラフターが改善する事項のリストにtime-to-first-tokenが含まれない理由を説明している。また、最も恩恵を受けるワークロードは、控えめな画像から長い出力を生成するもの——キャプション、長いOCR文字起こし、1つの画像を引き継ぐマルチターン会話——であり、大きな画像について短い質問に答えるものではないことも示唆している。

この投稿では、さらに2つの適用範囲の制限が追加されている。すべての数値は、視覚エンコーダーと言語バックボーンの両方で16ビット処理を使用しており、量子化モデルの高速化は今回のリリースの対象外である。3BのエッジVLMの最大の売りは数ギガバイトで動作することであることを踏まえると、「高速化はFP16で測定されている」というのは、4ビットエクスポートと組み合わせることを計画していた人にとって重要な注意点である。Liquidはまた、ドラフターが完全にAMDハードウェアでトレーニングされたことも指摘している。

それを実行する

初日からのサポートは実際に用意されており、3 つのランタイムをカバーしている。これは大半のドラフターが得られる以上のものだ。NVIDIA 上の SGLang は v0.5.19 以降が必要で、ドラフターを --speculative-algorithm DSPARK で使い、ドラフトパスとブロックサイズ 9 を指定する。Apple シリコン上の MLX-VLM は v0.7.2 以降が必要で、ドラフターが --draft-model と一緒に渡されるとそれを検出する。鋭い注意点が 1 つある — MLX-VLM の DSpark デコードは現在グリーディサンプリングを使用しているため、temperature は 0 に設定する必要がある。llama.cpp 用には別の GGUF リポジトリがあり、約 567 MB の単一の F16 エクスポートが用意されている。そしてカードには、量子化されたドラフターは元の safetensors チェックポイントではなく、量子化されたターゲットと組み合わせるべきだと明記されている。

ここでルーティング層がその価値を発揮するのは、このモデルにおいてではない — OrcaRouter は LFM2.5-VL-3B-DSpark や LFM2.5-VL-3B をルーティングせず、これは自分でダウンロードして自分でホストするセルフホスト型のドラフターの組み合わせだ。そうではなく、その周りにあるスタックの残りの部分においてだ。小規模なオープンウェイトのビジョンモデルをオンデバイスで動かす同じアプリケーションには、通常、その小規模モデルでは扱えないクエリ向けのフォールバック経路があり、その経路を 200 以上のモデルをカバーする単一のエンドポイント — 各プロバイダーの定価で課金され、上乗せは一切なく、プロバイダーが劣化した際の自動フェイルオーバー付き に向けることは、2 つ目のベンダー契約を締結するよりも小規模な統合で済む。ドラフターはそのアーキテクチャの片方の脚を改善するが、もう片方の脚が第二のプロジェクトになるのを防ぐのがルーターだ。

まだ知られていないこと

執筆時点で、このリポジトリには37件のダウンロードと6件のいいねがある。公開ベンチマークアグリゲーターのどこにもこのドラフターの項目はなく、高速化幅のいずれについても第三者による再現も、Liquidがテストしなかったハードウェアでの受理率の独立した測定も存在しない。また、明らかな理由により、カード上に品質ベンチマークもない。このドラフターは構造上出力を保持するため、品質の数値はLFM2.5-VL-3Bに属し、カードは独自の数値をでっち上げるのではなく、そのモデルのベンチマークを参照している。

メタデータの中のある細部は、これがどれほど新しいかを示す小さな手がかりだ。モデルには SGLang ライブラリタグと、それを呼び出すために専用に存在する SGLang アルゴリズムフラグが付いている。フレームワークのサポートは発表より先に投入されている必要があり、これはリポジトリとブログ記事の間の6日間の隔たりとも一致する。

つまり、本物で有用、範囲の狭いエンジニアリングの成果が、出荷の1週間後に発表された。その価値提案のすべては、あなたが持っていないかもしれないハードウェア上でベンダーが測定した数値にある。H100 や M シリーズ Mac で LFM2.5-VL-3B を提供していて、ワークロードがデコード中心なら、メモリコストは 8.9% で、出力は証明可能にターゲットのものなので、デメリットはほぼゼロだ。レイテンシがプリフィルに支配されている場合、あるいは 4-bit エクスポートを当てにしていた場合、Liquid 自身の投稿が、それは役に立たないと教えてくれる。再現が出てきたら、それが待つべきものだ。

OrcaRouterは200以上のモデルを1つのキーで、プロバイダーのリスト価格のまま0%のマークアップで利用可能にし、フォールバック経路をルーティングレイヤーとして、アプリケーションコードではなく表現します。ドラフターはいずれの場合もセルフホストです — 小さいモデルが引き継ぐ区間が第二のプロジェクトになってしまうのを防ぐのが、このルーターです。