Liquid AI d1 対 Liquid AI d1-3B：Ollama Library が1つのモデルと呼び、ベンダーが2つと呼ぶもの

同じ重みの集合に名前を付ける方法は2通りあり、Liquid AI d1とLiquid AI d1-3Bは、パラメータの比較では到底示せない違いをよく表している。2番目の名前からハイフンを1つとサイズ接尾辞を取れば1番目の名前になるので、短い方の文字列を愛称と見なしたくなる。しかし、これらのモデルを実際に掲載している2つのカタログは、その読み方に同意していない。Liquid AI自身のドキュメント索引はd1を独自の行に置き、ダウンロードリンクがある場所に「API」の文字を記し、d1-3Bとd1-omni-600Mは別々の2行に分けて、機能するHugging FaceとGGUFのリンク、そしてtrainable列の「No」を添えている。このペアについてわざわざ書く価値があるのは、まさにそのOllamaのライブラリ登録があるからだが、Ollamaはそれをすべてd1という1つのページにまとめ、1行で「Liquid AIによる3Bの決定モデルで、LFM2.5-VL-3B上に構築」と説明し、その下にちょうど3つのタグを用意している。したがって、Liquid AI d1をLiquid AI d1-3Bと比較することは、ホスト型エンドポイントとオープンチェックポイントの比較ではなく、2つのチェックポイント同士の比較でもない。それは、ホスト型エンドポイントと、ローカルランタイムのエコシステムが、修飾語なしでその言葉を口にしたときにd1だと判断したオープンチェックポイントとの比較である。以下で述べることの大半は、こうした読み方のうち、あなたのデプロイが実際にどちらに依存しているかについてだ。

以下の数値がどこから来ているかについての注記です。その体裁よりも誠実さのほうが重要だからです。ここにある数値はすべて、Liquid AI 自身の報告によるもので、モデルカードまたは10月7日のリリース投稿に記載されています。Decision Index の行は、公開ランキングに提出されたものではなく、ベンダーが公式スコアラーで採点したものです。また、我々が確認できた限りでは、第三者によって d1 の結果が独立に再現されたことはありません。数値が測定値ではなく、公表された数値に対する計算である場合は、その旨が明記されています。

2つの名前の由来

短い方の名前のほうが古い。Liquid AI の10月5日の投稿では、このモデルはLiquid AI d1として紹介された——「当社初の意思決定モデル」であり、そのリリースではマルチモーダルで、テキスト、画像、またはその両方からなる状態に対して入力された質問に、出力トークンゼロで1回のフォワードパスで回答する。この投稿では、ホスト型サービスの価格を入力トークン100万あたり0.04ドルと記載し、課金は入力トークンのみ、画像は32×32パッチあたり1.5トークンとしてテキストと同様に課金されるため、1024×1024の画像は1,536トークンになると述べている。また、テキストの意思決定レイテンシは200～300 msとしている。これらはホスト型サービスの数値であり、その背後にあるランタイムはベンダー自身の意思決定エンドポイント api.liquid.ai/decisions/v1/systemone であると、この投稿は明言している。

より長いほうの名前は10月7日の投稿と Hugging Face に登場しており、再現可能な詳細を携えているのはこちらのほうだ。3.12B パラメータ、32,768トークンのコンテキスト、128,000トークンの語彙、文書化された16言語、SigLIP2 NaFlex 形状最適化 400M ビジョンエンコーダ、そしてベースチェーン LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B。そのカードには、このモデルがチャットモデルではなく、テキストを書かないこともはっきりと記されている。これこそがローカルエコシステム全体の土台となっているチェックポイントだ。GGUF リポジトリには Q4_K_M が 1.67 GB、Q8_0 が 2.87 GB、F16 と BF16 がそれぞれ 5.4 GB で置かれている。

どのベンダー文書も明言していないのは、Liquid AI d1とLiquid AI d1-3Bが同じ重みだということです。ドキュメント索引では、両者は別々の行に割り当てられています。リリース投稿ではd1をチェックポイントではなくファミリーと呼んでいます。第三者による記事はこの乖離に気づいており、ベンダーが同一性を確認していないと指摘しています。したがって、正直な説明は短いものです。2つの名前が公表されている数値は、私たちが確認できる限りどこにも矛盾せず、ファミリーのリリースと提供中のエンドポイントは、整合する説明とともに2日違いで発表されており、ベンダーはそれらが同じモデルだとは述べていません。等価性は妥当な作業仮説として扱い、ベンダーがその名を付して認めた事実として扱わないでください。

ローカルビルドが実際に変更するもの

Ollamaのエントリーは再リリースではなく、新しいチェックポイントでもない。それはパッケージングの判断であり、そのパッケージングには、ベンダー自身のドキュメントが一切言及していない3つの制約が課されている。第一はタグリストだ。d1:latest、d1:3b、d1:3b-q8_0 ——3つのタグが1つの量子化を指している。Liquidが公開しているGGUFリポジトリには4つの精度が含まれており、1.67 GBのQ4_K_M ——ノートPCでほとんどの人が手を伸ばすであろうもの——はOllamaのタグの中にない。pullできるのは2.87 GBのQ8_0と、それがローカルストアで展開される何かであり、ライブラリページはダウンロードを3.7 GBと報告している。

2つ目はリクエスト契約です。Ollama は /v1/systemone でこれらのモデルへの応答を行い、state と questions オブジェクトを受け取り、output_tokens: 0 が付いた型付きの回答を返します。これはベンダーのホスト型エンドポイントが使っているのと同じ形状であり、そのおかげでローカルとホスト型の切り替えは書き直しではなく設定変更になります。3つ目の制約は、モデルページではなく Ollama のエンドポイントドキュメントに記載されており、生成モデルのものよりも厳しいものです。リクエストは画像なしで 64 KiB 以内、画像ありで 32 MiB 以内に収まる必要があり、ストリーミングはサポートされず、クラウドホスト型モデルは拒否され、画像はリクエストボディ内で base64 の PNG、JPEG、または WebP でなければなりません — リモート URL は拒否されます。画像はリクエスト内のすべての質問で共有されるため、1つの回答にだけ考慮させたい画像は、専用の呼び出しが必要です。入力が切り捨てられることはありません。つまり、サイズが大きすぎる state は、黙って切り詰められるのではなくエラーを返します。それはより良い障害モードであり、それでもやはりクライアントが対処しなければならない障害モードです。

バグを報告する前に知っておく価値のある、未解決のドキュメントの詳細が2つあります。Ollamaのエンドポイントリファレンスでは、選択式質問タイプは2～255個のオプションキーを受け付けると説明されていますが、そのデシジョンモデルのケイパビリティページには2～26と記載されています。どちらか一方が古い情報です。また、そのケイパビリティページにはサポート対象モデルとしてNimble、Tev1、Clef、Clef Flashが挙げられているだけで、d1には一切触れられていません。しかしd1パッケージ自体のreadmeには/v1/systemoneと--askのサポートが記載されており、そのパッケージはOllama 0.40.4を必要としていますが、エンドポイント側で文書化されている最低要件は0.35.0です。ガイドに書かれているものではなく、パッケージのバージョン要件を確認してください。

番号と、それらがどの名前で出版されたか

これはペアリングの中でも最も間違えやすい部分です。というのも、どちらの名前も性能値とともに公表されており、その数値はあなたが期待するようには整理されていないからです。

• Decision Index 0.2.1 — 48.57、公開元は Liquid AI d1-3B。Liquid はこれを、パラメータ数10B未満の意思決定モデルにおける最高スコアだと説明し、47.11の35B-A3Bモデルを上回る位置づけとしている。• テキスト意思決定レイテンシ — 200〜300 ms。Liquid AI d1名義、ホスト型APIの投稿にて公開。オープンなチェックポイント自身の名前に紐づく同等の数値は存在しない。• ローカルハードウェアでの単一質問レイテンシ — RTX 4090で8 ms、Jetson AGX Thorで16 ms、Jetson AGX Orin 64 GBで26 ms、Orin Nanoで50 ms、Apple M5 Proで30 ms。Liquid AI d1-3B名義で公開。• スループット — 質問をバッチに詰め込んだ状態で、RTX 4090では毎秒475件、AMD MI325Xでは毎秒1,106件の意思決定。Liquid AI d1-3B名義で公開。• 視覚 — 11件の公開画像ベンチマークで平均74.1、基となった LFM2.5-VL-3B の73.9に対して。Liquid AI d1-3B名義で公開。• 画像アブレーション — 同じ質問セットから画像を取り除いて回答した場合のスコアは45.1で、これは視覚経路がどれだけ寄与しているかをベンダー自身が測定した値である。Liquid AI d1-3B名義で公開。

そのリストから2つの問題が浮かび上がるが、どちらも致命的ではない。まさにそれゆえ、見落とされる。ホスト型の数値とローカル型の数値は25～37倍離れている——200～300 ms 対 8 ms——そしてそれらは、ベンダーが比較可能な形では説明していない対象で測定されたものだ。この隔たりを「ローカルのほうが速い」と解釈することは支持されない。なぜなら、ホスト型の数値はAPIを通したエンドツーエンドであり、8 msは特定のGPU上でのフォワードパスだからだ。両者は同じ測定ではなく、ベンダーも同じだとは決して主張していない。

2つ目の問題は vision の行です。ベースモデルに対する0.2ポイントの改善は、11個の画像ベンチマーク全体では、ほとんどのベンチマーク報告のノイズの範囲内に収まっています。したがって、decision head が何をもたらすにせよ、それは実質的により優れた画像エンコーダーではありません。アブレーションの行は逆方向にはるかに印象的に見えます——画像を追加したときの約29ポイントの変動——が、それは1つの質問セットの2つのバージョンではなく、2つの異なる質問セットを比較しています。Liquid はそのことを投稿自体で述べています。どちらの行も有用です。どちらも視覚的意思決定の品質についての強い主張を支持するものではなく、どちらも第三者によって実行されていません。

実際には、この2つの名称がどこで分かれるのか

買い手にとって、その違いは4つの問いに帰着するが、答えがすべて同じ方向を指すわけではない。

• コスト構造 — Liquid AI d1は入力トークン単位で、ベンダーが公表しているレートで課金され、支払うべき出力トークンはありません。Liquid AI d1-3Bは、Ollamaのパッケージで2.87 GB、ベンダーのGGUFリポジトリからなら1.67 GBのダウンロードで、呼び出しごとの課金は一切ありません。• レイテンシは計測可能 — ホスト型の経路はテキスト判定1件あたり200～300 msとされています。ローカル経路が公表している8 msは、モデルをウォームアップしたRTX 4090でのフォワードパスであり、これは実在する数値であって、リクエストの往復ではありません。• データ経路 — ホスト型の経路は状態をベンダーに送信します。ローカル経路はそれをマシン上に保持し、サポートチケット、医療記録、写真などにとっては、これがたいてい議論を終わらせる決め手となります。• バージョンの固定 — Liquid AI d1をエンドポイントの背後に置いた場合、それはベンダーが今日提供しているもの次第です。Liquid AI d1-3BをOllamaで使う場合、それはあなたが管理する固定されたパッケージであり、その代償はアップグレードも自分で担うことです。

これら4つすべての底流にある気まずい現実は、オープンなチェックポイントがホスト型モデルの代替物ではなく兄弟であり、ベンダーはそうでないとは言っていないということだ。オープンなチェックポイントのモデルカードは、ルーティングとトリアージ、モデレーション、意図分類、抽出チェック、再ランキング、LLM-as-a-judge、ガードレールへの使用を推奨し、単一パスでの較正された意思決定のためにLFM2.5-VL-3Bで事後学習されたものだと説明している。ホスト版の告知は、同じ一連のタスクを別の言葉で説明し、ホスト版の価格を引用している。もしそれらが1つのモデルなら、ローカルビルドはホスト型製品の無料コピーであり、ラボがそう言わずに出荷するのは異例だろう。もし共通のベースに対する2つのファインチューンなら、公表された数値がどちらの方向にも移転すると仮定すべきではない。2番目の説明はベンダーに求めるものが少なく、手持ちの証拠に適合する。

2つのスタックを動かすことなく、意思決定の両方の半分を実行する

どの名前を採用するにせよ、その周りのパイプラインは同じように見えがちだ。サポートキューには、宛先チームを選ぶ選択質問、返金が要求されているかどうかを問うnoul質問、緊急度のスコア質問が与えられる——1つの状態、3つの答え、1回のパス。2つの名前が本当に分岐するのは、その判断が、自分で動かすのではなく借りて使う生成モデルへの呼び出しをゲートする時点だ。その呼び出しは、異なる障害プロファイルを持つ別の問題であり、パイプラインの中でもd1が正しいことの重要度が最も低い部分だ。確率0.98のルーティング回答の後に、ルーティング先のモデルから502が返ってくるのは、どちらにせよ失敗したリクエストだ。

当社はLiquid AIのモデルを一切ホストしていません——これを書く前に自社のカタログを確認しました——したがって、ここに書かれていることは、これらの重みを当社経由で呼び出せるという主張ではありません。当社が担うのは、その判断の反対側にあるレイヤーです。トリアージされたリクエストがファンアウトする先のモデルに対して、OpenAI互換のキーを1つ。各プロバイダの定価をそのまま、マークアップ0%で提供するので、ベンダーの値下げは契約更新時ではなく実施されたその日にあなたのもとに届きます。さらにプロバイダ間の自動フェイルオーバーにより、トリアージされたリクエストは、ルーティング先のモデルがダウンしても生き残ります。判断モデルを初めてパイプラインに組み込むのであれば、退屈にしておく価値があるのはそちらの半分です。

状況に応じてどの名前を使うか

今週、維持する価値のあるPython環境なしでこのモデルを試したいなら、ローカルランタイムが使う名前を使ってください。プルするにはLiquid AI d1をライブラリからプルし、Q8_0と3.7 GBを受け入れ、64 KiBのリクエスト上限とストリーミングなしのルールを厄介事ではなく設計上の制約として扱ってください。初日から実際のエンドポイント、型付きの実際の回答、そして呼び出しごとの課金メーターなしが得られます。

Q8_0より小さいフットプリントが必要なら、使うべき名前はLiquid AI d1-3Bです。というのも、1.67 GBのQ4_K_MビルドはベンダーのGGUFリポジトリにあり、ライブラリのエントリにはないからです。この一つの事実が、今日この2つの名前の間で最も実用的な違いであり、ライブラリのページを読んでそこで止まってしまう人ほど見落としやすい点です。

有料ユーザーの前にこれを出そうとしていて、まず精度の証拠が必要だというなら、どちらの名前もまだ役には立たない。われわれが探した限り、d1モデルに対する独立した評価は存在せず、Decision Indexの行は自己採点で、ベンダーは音声意思決定ベンチマークを一切公表していない。できるのは、モデルがすでに返している信頼度の値——0から1で、その答えが正しい確率ではなく、確率がどれだけ強く一方の答えを支持しているかを表す——を計測し、自分のトラフィック上で、どこでこれが不確かになるのかを見つけ出すことだ。その測定は、上のどのスライドよりも価値があり、しかも1日でできる。

判断モデルは、パイプラインの中でも安価な側の半分にすぎない。それがルーティングする先の生成モデルこそ、契約を必要とする半分だ——1つのOpenAI互換キーが、トリアージされたリクエストがファンアウトする先のモデルを担い、それぞれは各プロバイダの定価のまま、0%のマークアップでそのまま渡される。

蒸留済みチェックポイントを、その元のフルリリースと比較してサイズを縮小することは、記録を確認するのにもよい機会です。小規模なLiquidモデルに関する、記録に残されたAIインシデントやエージェント障害は、以下に収集されています: OrcaRouter AI Incident Archive。そこでは各エントリが、それぞれ独自の情報源、重大度、信頼度グレード、異議ありフラグを保持しています。