d1-2B 対 Liquid AI d1-3B：小さいモデルはボードで勝ち、デプロイでは敗れる

この対戦を決めるのは4つの問いであり、そのどれも「どちらのモデルが優れているか」ではない。状態に動画が含まれるか。32Kトークンを超えるか。llama.cppで動かす必要があるか。最初のテスターになる余裕があるか。d1-2BはLiquid AIの1.92B意思決定モデルで、LFM3-VL-2Bを基盤とし、ベンダーのDecision Index表で51.1を記録した。Liquid AI d1-3Bは10月7日にリリースされた3.12Bモデルで、LFM2.5-VL-3Bを基盤とし、同じ表で49.0を記録した。より新しく小さいモデルが平均でリードしている。それでも、実際のデプロイで重視される行のうち3つでは負けており、2つのうちllama.cpp経路がなく、独立したテスト結果もないのはこのモデルの方だ。このページはリーダーボードではなく、これら4つの問いを中心に構成している。リーダーボードはそのどれにも答えていないからだ。

手短な答え（ワークロード別）

• 大量処理におけるテキストのみのトリアージ — d1-2Bは、64のバッチ状態に対して毎秒1,132件の判断を下せることと、重みが3.84GBであることを強みとしています。出力がラベルである場合、Typed Decisionsにおける3Bの優位性は意味を持ちません。

• 図表やグラフの読み取り — Liquid AI d1-3B。AI2Dでは79.9対76.7で勝利し、独立した実行結果に裏付けられたモデルです。

• 長い文書、長いフォーム、長い通話記録 — d1-2B。そのウィンドウは32,768に対して128Kトークンであり、カードには約64Kを超えると信頼性が低下することが正直に示されているが、それでも3Bの総容量の2倍は残る。

• llama.cppを実行するエッジボックス — Liquid AI d1-3Bが、実力ではなくデフォルトで選ばれている。GGUFリポジトリと量子化された重み活性化ビルドを備えるが、d1-2Bにはどちらもない。

• 誤った判断が大きな代償を伴い、しかも未検証であるあらゆるもの — 自分のデータで両方を実行するまでは、どちらでもありません。そのうち片方でさえ、第三者が実行したことがあるにすぎないのです。

同じファミリー、1世代違い

この2つのモデルは、名前から連想されるような兄弟関係にはない。Liquid AI d1-3B は LFM2.5-VL-3B の系譜に連なり、LFM2.5-VL-3B は LFM2.5-2.6B-Base に由来し、400M の SigLIP2 NaFlex ビジョンエンコーダを搭載している。d1-2B は次世代ファミリーである LFM3-VL-2B の系譜に連なり、バックボーンは24層で、13のゲート付きショート畳み込み、5のスライディングウィンドウアテンション層、6のグローバルアテンション層に分かれている。この世代差こそがベンチマーク逆転の原因である。新しいアーキテクチャはパラメータあたりにより多くの処理を行うため、小さいチェックポイントがほとんどの行で大きい方を上回ることができる。

• パラメーター — d1-2Bは1.92B、Liquid AI d1-3Bは3.12B。

• ダウンロード — BF16 safetensorsは3.84GB対6.25GB、どちらも単一ファイルです。

• コンテキスト — 128Kトークン対32,768。

• 語彙 — LFM2.5の語彙に対して128,000トークン。

• 入力 — テキストまたはJSON、画像または動画、さらにd1-2B向けの名前付き質問、3B向けのテキストまたはJSONと画像。動画は両者の最も明確な能力差です。

• 言語 — それぞれ16言語、同じセットです。

• ライセンス — 両方とも LFM Open License v1.0 であり、商用利用は年間収益が 10,000,000 ドル未満であることが条件です。ライセンス面でどちらかを優先する理由はありません。

• リリース — d1-3Bのウェイトは10月5日に公開され、10月7日に発表された。d1-2Bのリポジトリは10月24日に作成され、これまで独自の投稿を一度も持っていない。それを名指ししているベンダーの文は、10月27日のLFM3ローンチにあるものだけである。

ドキュメントの細部の一つは、事実としてではなくシグナルとして読む価値がある。Liquid AIのdecision-modelドキュメントページには現在、d1-2B、d1-omni-2B、d1-omni-600M、d1.1、d1-ultraが記載されている。d1-3Bはもう記載されていない。3Bは廃止されたわけではない—そのリポジトリ、GGUF、MLXビルドはすべて現役だ—が、ベンダー自身のインデックスではオープンウェイトの枠が2Bに移っている。

スコアボードは、行ごとに読み取ります。

以下の数値はすべて、d1-2B のモデルカードにあるベンチマーク表から来ています。この表は、4 つのオープンな d1 モデルを同じ項目で同じスコアラーを使って評価したものです。これが重要なのは、Liquid AI d1-3B 自身のカードでは Decision Index 0.2.1 で 48.57 と報告されている一方、この表ではバージョン 0.3 で 49.0 と報告されているからです。この差はモデルの変更ではなくインデックスの版によるもので、カードにも注記でそう書かれています。2 つのカードを直接比較すること——48.57 対 51.1——は、2 つの異なるテストをまたいで引き算することになってしまいます。この表の内部で比較するのは妥当であり、このセクションの残りもそうしています。

• Decision Index public suite v0.3 — 51.1 対 49.0。

• DecisionBench（Hanno Labs）v1 — 77.1 対 73.1。

• Decision Bench（decisionbench.ai）v4 — 85.2 対 83.6。

• JevBench v1.4.1 — 77.9 対 76.2。

• ImajevBench v2.0-lite — 75.5 対 64.0、意思決定側で最大の差。

• WorkflowEvals — 81.6 対 74.4。

• Liquid AIの社内ボード — 63.2 対 58.8。

• Vision平均 — 18個のベンチマークで70.2対65.4。

その表にある名前付きの決定スイートはすべて2Bの勝ちであり、LFM3のローンチ記事がd1-2Bをd1-3Bの置き換えと呼び、「パラメータが3分の1少ない」うえに「4つの決定スイートすべてで」より高いスコアを出すと述べているのは、そういう意味だ。この主張は書かれているとおり正確であり、「3Bを上回る」より狭い話である。だからこそ次の段落がある。次に、逆方向の3行を見てみよう。Fast Decisionsはd1-2Bが58.8、3Bが59.3。Typed Decisionsは61.3に対し65.0。AI2Dは76.7に対し79.9。これらの差はどれも大きくなく、3つのうち2つは1ポイント以内に収まっているが、余分な1.2Bパラメータが依然として測定可能な何かを買っている行ではある。つまり、スピード重視の決定、型付き抽出、図の読み取りだ。パイプラインのジョブがフォームからの型付き抽出であるなら、3Bはドキュメントページが示唆するような時代遅れの選択肢ではない。

レイテンシ：2つの主要な数値は比較できません

Liquid AIはd1-2Bについて決定あたり5.7 ms、Liquid AI d1-3Bについて8 msと公表しているが、これらは同じ測定条件ではない。2Bの数値はH100 PCIe上、3Bの数値はRTX 4090上で得られたものだ。異なる2つのGPU間の2.3 msの差は、あなたのハードウェア上でどちらのモデルが速いかについて何も教えてくれない。それを比較として繰り返すのは、まさにこのブログが避けるために存在する「数値の洗浄」の類だろう。

両方のカードが報告している同一のマシンが 1 台あります。Apple M5 Pro では、d1-2B は 1 問あたり 18.6 ms、3B は 30 ms かかり、同一のシリコン上で 38% の削減です。これが正直な速度比較であり、サイズ差が示唆するのと同じ方向を示しています。バッチ処理では、d1-2B は H100 PCIe 上で 1 秒あたり 1,132 件の決定を処理し、1 回の呼び出しで 64 状態を扱う MI325X 上では 1 秒あたり 1,699 件を処理します。3B のカードは RTX 4090 上で 1 秒あたり 475 件、MI325X 上で 1 秒あたり 1,106 件を報告しています。MI325X の行は両方のカードが共有しており、そこでは 2B が約 54% 先行しています。

現存する唯一の独立したテストは3Bを実行した

10月中旬、Efraín Garay は8つの意思決定モデルを Decision Index 0.3 と3つの実データタスクに対して実行し、その結果をコードとともに公開した。この比較に関わる知見が2つある。

最初の点はスコアボードにとって心強い。彼は公開スイートをそのキットから再構築し、ダウンロードしたファイルが公式のものと一致することを確認し、6,000件のリクエストをサンプリングし、Liquid AI d1-3Bを49.11と採点した——同じ行でLiquid自身の49.04、フルスイートで48.99に対して。これは、上の表にあるv0.3の数値が正しく計算されていることを示す、利用可能な最強の証拠である。それは3Bに関する証拠であり、彼がテストしなかったd1-2Bに関するものではない。

第二の点は、指標が何を測定しているかについての警告です。10,000件の支払いからなる合成カード詐欺データセットにおいて、Liquid AI d1-3BはAUC 0.314を記録しました。これはチャンスレベルを下回り、異常を通常の支払いよりも疑わしくないとランク付けしました。なぜなら、連続する支払いのバーストは中央値確率0.41に達し、通常の支払いの0.56と対照的だったからです。このモデルは公開指標では2位でしたが、そのタスクでは最下位でした。教訓は直接当てはまります。d1-2Bの51.1は一般的な意思決定スイートのスコアであり、それがあなたの特定の意思決定におけるパフォーマンスを予測することを示した人は誰もいません。ベンダー自身の製品カードでも、自分のデータでしきい値を較正するよう指示することで、同じことを述べています。

今日実際に実行できるもの

ここから両者の差は明確になります。Liquid AI d1-3B には、10月6日から GGUF リポジトリ、10月7日から8ビット重みアクティベーションのビルド、10月12日から4つの MLX バリアントがあります。d1-2B は10月27日に3つの MLX ビルドと ONNX エクスポートを入手しただけで、それ以外は何もありません。d1-2B の GGUF はなく、MLX の4ビットと8ビット以外の量子化もなく、したがって決定ヘッド用に公開された llama.cpp パスもありません——ベースモデルである LFM3-VL-2B には10月19日から独自の GGUF があるにもかかわらず。

Transformers でのデプロイでは、その違いは消えます。どちらも trust_remote_code=True で読み込まれ、同じ system_one と system_one_batch の呼び出しを提供します。エッジデプロイではそうはいきません。スタックが Jetson やスマートフォン上の llama.cpp である場合、2つのうちランタイム統合を書かずに実行できるのは 3B だけであり、公開されているエッジでの数値 — Jetson AGX Thor で 16 ms、AGX Orin 64GB で 26 ms、Orin Nano で 50 ms — が、計画の基準にできる数値です。

どちらのモデルもOrcaRouterでは提供されていないため、どちらを選ぶにせよセルフホスティングの判断になります。ルーターが真価を発揮するのは、その1つ外側のレイヤーです。判断用モデルが単独で動くことはほとんどなく、ルーティングラベルに基づいて動作する生成ステップは通常、ホスト型モデルが担うからです。200以上のモデルに使えるOpenAI互換のキー1つ、それらのステップを1回の呼び出しにまとめられるルーティングDSL、そして自動フェイルオーバーがあれば、パイプラインのその半分が新たな統合プロジェクトになるのを防ぎつつ、判断ノードは自社ハードウェア上に置いたままにできます。

移行する場合、変わる点が3つあります

API の表面は十分似ているため、移植は簡単に見えますが、実際はそうではありません。まず、入力契約です。d1-3B は画像を受け取り、d1-2B はメディアリストを受け取ります。このリストには動画を含めることができ、そのカードには、メディアは1回の呼び出し内のすべての質問に対して一度だけエンコードされると記載されています。単一の画像を渡すコードは動作しますが、モデルが本来想定している用途を活用することにはなりません。

次に、{{1}}閾値{{/1}}です。両モデルは確率を返すため、どちらもあなたのデータで適合させた決定閾値が必要です。d1-3Bのキャリブレーションで調整した閾値は転用できません。キャリブレーションテーブルは各リポジトリ内に同梱され、個別に適合されているためです。したがって、{{2}}古いカットオフ{{/2}}を維持したまま移行すると、動作点が変わり、モデレーションや不正検知の経路ではエラープロファイルも変わります。

第三に、信頼性の崖です。128Kウィンドウが目玉で、カードには状態が約64Kトークンを超えると回答の信頼性が低下すると書かれています。3Bでは上限が32,768なので、d1-2Bへの移行は通常、純粋な容量増となります。しかし、今ならできるからという理由で100Kトークンの状態を流し始めるパイプラインは、ベンダーがより弱いと警告している範囲の部分を試していることになります。

結論はスコアボードほど対称ではない。Transformers での新規構築で、テキスト、画像、動画のいずれでも、長時間続く状態を扱える場合は、d1-2B がより良いデフォルトであり、実行コストも安い。llama.cpp を使ったエッジ展開、型付き抽出、図の多いビジョンなら、Liquid AI d1-3B が依然として選ぶべきモデルであり、この2つのうち外部の裏付けが少しでもあるのはそれだけだ。唯一やってはいけないのは、51.1 対 49.0 の行だけで選ぶことだ。ベンダーのインデックス上の2ポイントは、誰もあなたのタスクで実行したことのない2モデル間では、判断ではなくタイブレークにすぎない。