Liquid AI d1-3BがOllamaに登場：意思決定モデル向けの静かなローカルエンドポイント

Ollamaのライブラリに新しいd1が登場しましたが、それはチャットモデルではありません。エントリは一行でこう説明しています —「Liquid AIによる3Bの意思決定モデルで、LFM2.5-VL-3Bをベースに構築」— そしてこの一文には、最も重要な2つの事実が詰まっています。Liquid AI d1-3Bは、Liquid AIがLiquid AI LFM2.5-VL-3Bの上に構築し、2026年10月5日にオープンウェイトとして公開した小型モデルですが、今では1回のpullでご自身のマシンに導入できるようパッケージ化されています。しかも、基盤となるチェックポイントとまったく同じく、生成テキストではなく、型付きの質問に対する較正済みの確率を返します。パイプラインにトリアージ、ルーティング、モデレーション、ゲーティングのステップがあるなら、この特定のモデルファミリーが、APIキーも呼び出しごとの課金も、ハードウェアから出ていく状態テキストもなしに、コマンド1つで動かせるようになるのは今回が初めてです。

とはいえ、ここで「静か」という言葉は実際に効いている。この話のどちらの半分が文書化され、どちらの半分がそうでないかについては、正確を期す価値がある。Liquid AI 自身のブログは Ollama について一度も言及していない。同ラボの最新投稿（2026年10月13日）は LFM2.5 系の別モデルを扱っており、d1 に関する2件の投稿——10月5日のビジョン発表と10月7日の「Open d1」リリース——は、ローカルランタイムではなく、重み、API、ベンチマークスコアについて述べている。d1 に関する Ollama のライブラリページにも告知はなく、ベンダーのドキュメント索引にもない。同索引が GGUF を利用可能としてチェックを付けているのは Liquid AI d1-3Bと、その音声対応の兄弟であるLiquid AI d1-omni-600Mだけで、その一方で llama.cpp、Ollama、MLX は汎用的なデプロイオプションとして挙げているにすぎない。存在するのは、公開されたパッケージ、検証可能なダイジェスト付きのレジストリエントリ、動作する readme、そして2026年10月15日にこれを書いている時点で10.4Kと表示されていたダウンロードカウンターである。存在しないのは、「我々がこれをやった」と言うベンダーの一文である。

リスティングに実際に含まれている内容

3 つのタグ — d1:latest、d1:3b、d1:3b-q8_0 — が一覧表示されており、3 つすべてが同じマニフェストダイジェスト 8c2d9ddae441 に解決されます。このページについてまず理解すべきことは、ライブラリの「3 models」カウンターがタグの数であって、チェックポイントの数ではないということです。1 つのアーティファクト、3 つの名前、3.7 GB、32K のコンテキストウィンドウ、そしてテキストと画像の入力。サイズや量子化を選びたいと思っていたなら、まだ選べるものは何もありません。

ページの背後にあるレジストリは、ページ自体よりも情報量が多い。パッケージの設定ブロブには、モデルファミリーがlfm2、モデルタイプが2.7B、ファイルタイプがQ8_0、最小ランタイムがOllama 0.40.4と報告されています。これは2つの重み層で提供されます：2.87 GBの生成モデルと、別個の856 MBのプロジェクターです。その2番目の層は視覚エンコーダーであり、その存在は、ローカルビルドがd1をテキストのみに削減するのではなく、マルチモーダル経路を維持していることを示しています。モデルは依然として、サポートチケットと一緒に写真を読み取り、両方について質問に答えることができます。このページ上で矛盾しているように見える2つの数字 — 説明の「3B」とレジストリの「2.7B」 — は、幹と全体として読むのが最善です：Liquid AIのモデルカードでは、チェックポイントは400Mパラメータの視覚エンコーダーを含む3.12Bパラメータであり、言語幹はより小さい数字です。その計算はベンダーのものではなく当方のものであり、仕様ではなく説明として提供されています。

ライブラリページのどこにも暦の日付はない。表示されるのは相対的なタイムスタンプ——キャプチャした時点で「2時間前に更新」——とダウンロード数カウンターだけであり、つまりこのリスティングが最初に現れた日は、リスティング自体からは分からないということだ。日付の手がかりはすべて Hugging Face とベンダー側にある。Liquid AI d1-3Bの重みリポジトリは2026年10月5日に作成され、付随するGGUFリポジトリは10月6日、そしてLiquid AIは10月7日にリリース投稿を公開した。「これはいつローカルで動かせるようになったのか」に日付を付けたいのなら、今日のところ正直に言えるのは、パッケージは存在し、今まさに取得されているということだけであり、それがどの朝に公開されたのかを言えるのはOllamaの中の人間だけだ。

なぜパッケージングイベントは本当のイベントなのか

Ollamaは2026年9月29日、意思決定モデルというカテゴリを開設した。同日、/v1/systemoneエンドポイントと、型付きの質問に単一のフォワードパスで答えるモデル向けの--ask CLIフラグを提供した。NimbleとClefが、その扉を通った最初のファミリーだった。新しいd1パッケージが加えるものは、新しいベンチマークの行とは別物だ。それは、これまでモデルクラスをベンダリングしたPython環境の中か、ホスト型エンドポイントの背後にしか存在しなかったモデルを取り、ローカル推論を1つのコマンドにする。

この契約は改めて述べる価値がある。なぜなら、ほとんどの読者が「モデルを実行する」と聞いて思い浮かべるものではないからだ。d1 に状態 — 文字列、JSON オブジェクト、配列、または文字列と画像 — と、名前付きの質問のセットを渡すと、生成トークンは一切なしで回答が返ってくる。noul は yes/no の質問であり、0 から 1 の間の単一の確率として回答される。choice は選択されたラベル、信頼度、および選択肢全体の完全な確率マップを返す。score は状態を 2 から 10 レベルの順序付きルーブリック上に位置づけ、確率で重み付けられたレベルと各レベルの確率を返す。1 つの状態、最大 64 の質問、入力に対する 1 回のパス。Ollama 自身のサポートチケット向けの応答例は usage.output_tokens: 0 を返しており、これはこの設計を最も明確に示す言明だ。

HTTP経由ですでに意思決定モデルを呼び出しているパイプラインを持つ人にとって、ローカル経路は三つのことを同時に変える。レイテンシ——リクエストがマシンから出なくなるからだ。コスト——呼び出しごとの課金メーターが存在しないからだ。そしてデータの扱い——分類しているチケットのテキストと写真がネットワークを一切通過しないからだ。扱う対象が顧客のメッセージや社内文書であるなら、通常、最後の点こそが示すべき唯一の論拠となる。

実行すること、そしてドキュメントが課す制限

サポートされている利用方法は 3 つあり、いずれもライブラリページに記載されています。CLI の方法は、状態をファイルからパイプで渡して `ollama run d1 --ask "返金が要求されていますか？"` を実行するもので、ほかの 2 つの質問タイプには `--choice` と `--level` フラグを使います。HTTP の方法は、model、state、省略可能な images 配列、questions オブジェクトを指定して http://localhost:11434/v1/systemone に POST するものです。SDK の方法では、TypeSafe の Python クライアントを localhost に向けます。ここでは API キーは無視され、任意のプレースホルダー値で動作します。

制限はLiquid AIではなくOllamaのエンドポイントドキュメントに由来しており、生成モデルのものより厳しい。リクエストは、画像なしなら64 KiB以内、画像ありなら32 MiB以内に収まる必要があり、ストリーミングはサポートされず、クラウドホスト型モデルは完全に拒否され、画像はbase64のPNG、JPEG、WebPをリクエストボディで送る必要がある——リモートURLは拒否される。1つのリクエスト内のすべての質問で画像は共有されるため、最初の回答にだけ考慮させたい画像は、それ自体を個別の呼び出しとして送る必要がある。入力が切り捨てられることはない。つまり、大きすぎる状態は、黙って切り詰められたプロンプトではなくエラーになる。

未解決として指摘しておく価値のあるドキュメント上の詳細が2つあります。Ollama のエンドポイントリファレンスでは、choice 型は 2～255 個のオプションキーを受け付けると説明されていますが、意思決定モデルのケイパビリティページでは 2～26 個と記載されています。どちらかが古くなっており、どちらなのかは明らかではありません。また、ケイパビリティページでは対応モデルとして Nimble、Tev1、Clef、Clef Flash が挙げられているものの、d1 には言及がありません。しかし d1 パッケージの readme 自体には、/v1/systemone および --ask を通じて動作すると記載されています。このパッケージは Ollama 0.40.4 を必要としますが、エンドポイント自体について文書化されている下限は 0.35.0 です。とはいえ、いずれもモデルのプルを妨げる矛盾ではありませんが、ケイパビリティガイドに書かれているバージョンではなく、パッケージ側のバージョン要件を読んでください。

数字、そしてそれらすべてを誰が生み出したのか

ここからが最も注意を要する部分です。このモデルに付随する性能数値はすべて Liquid AI によるもので、私たちが調べた限り、Liquid AI d1-3Bに対する独立した評価は存在しません。ベンダーが報告し、Ollama のページとモデルカードで繰り返されている結果は以下のとおりです。

• Decision Index 0.2.1 — d1-3Bで48.57、Decider 35B-A3Bの47.11に対して。Liquidはこれを、パラメータ数10B未満の意思決定モデルにおける最高スコアだと説明している。 • Vision — 11の公開画像ベンチマークで平均74.1、そのベースとなったLFM2.5-VL-3Bの73.9に対して。 • Latency — RTX 4090で1決定あたり8ms、AMD MI325Xで9ms、Apple M5 Proで30ms。 • Throughput — 質問をバッチにまとめた場合、4090で毎秒475決定、MI325Xで1,106決定。 • Ablation — 画像なしで同じ質問セットに回答したスコアは45.1で、これはビジョン経路がどれだけ貢献しているかについてのLiquid自身の指標だ。

期待を抑えるべきなのは、ビジョン行だ。一連の画像ベンチマークにおけるベースモデル比0.2ポイントの改善は、ほとんどのベンチマーク報告のノイズの範囲内である。デシジョンヘッドが何をもたらすにせよ、実質的により優れた画像エンコーダではない。アブレーション行は逆方向により興味深い——画像を追加した際の約29ポイントの振れ幅——だが、それは同じ質問セットの2つのバージョンではなく、2つの異なる質問セットを比較している。そしてDecision Indexは第三者の指標であり、Liquidは公開ランキングに提出するのではなく、そこで自社のエントリーを自ら採点した。したがって48.57は、他人の物差しで測られたベンダー主張として扱うべきだ。速度の数値も未監査だ。4090での8 msは、1回のフォワードパスを行う3Bモデルとしてはもっともらしい数字であり、自分が所有していない実行結果を公開した人はいない、という状況は依然として変わらない。

OrcaRouterが適する場面と、適さない場面

OrcaRouter はLiquid AI d1-3Bを提供していません。これを書く前に当社のカタログを確認しました — 207 モデル、Liquid AI のものは一つもなく、意思決定モデルも一つもありません — したがって、d1 を自前のハードウェアからではなく API から呼び出したい場合、現時点でのホスト型のルートはベンダー自身の意思決定エンドポイント api.liquid.ai/decisions/v1/systemone であり、そこでは有料の d1 ティアが画像を扱い、無料の d1:free ティアはテキスト専用で、さらにこれを採用するサードパーティのプラットフォームがあればそれも加わります。本記事のいずれの部分も、当社がそれをホストしているという主張として読まれるべきではありません。

私たちがやっていることは、このモデルが解決する問題と隣接しています。意思決定モデルが存在する理由は、パイプラインが選択肢の中から選ぶための安価で決定論的な手段を必要としているからであり、d1自身が文書化した例は、宛先チームへルーティングされるチケットです。これは私たちの課題より一段下のルーティング問題です。その決定が、実行するのではなく借りてくる生成モデルへの呼び出しを制御するとき、OrcaRouter はプロバイダーの定価で200以上のホスト型モデルを利用できる単一のOpenAI互換キーであり、0%のマークアップでそのまま提供されます。だからこそ、ベンダーの値下げは次の契約更新時ではなく実施されたその日にあなたの元へ届きます。そして、このパイプラインのローカル側こそあなたが所有する側であるため、リスクはホスト側にあります：プロバイダー間の自動フェイルオーバーは、ルーティング先のモデルがダウンしたときにトリアージ済みのリクエストを存続させます。これらのどちらも、3Bの意思決定モデルを使う理由にはなりません。それらは、決定の反対側にあるものが単一障害点であってはならない理由なのです。

これを単なる包装メモから物語へと変えるものは何だろう

5つの事柄——そのどれか一つでも評価が変わる。Liquid AIがこの移植を認めること、あるいは同社のドキュメント索引が、現在llama.cppとMLXで埋めているデプロイ行にOllamaを追加すること。2つ目の量子化：Liquid自身のGGUFリポジトリはQ8_0と並んでQ4_K_M、F16、BF16を出荷しているので、より小さなローカルビルドは技術的には入手可能だが、このパッケージ経由では手に入らないだけだ。Liquid AI d1-omni-600Mへのローカルパス——最大30秒の音声を読み取る587Mパラメータの兄弟モデルで、ベンダーはこれを早期研究リリースと位置づけている。オンデバイス作業なら3Bよりもこちらのほうが重要だろうが、どのライブラリにもまだその気配はない。独立したDecision Indexの行、あるいは公開リーダーボードへの掲載——これがこのモデルファミリー全体を通じて唯一欠けている要素だ。そしてOllamaがd1をその意思決定能力ページに追加すること——これは一行の変更で、この移植が偶発的なものではなく公認されたものだと教えてくれる。

それまでは、判断は十分に簡単で、自分の条件で下せる。すでに最近のOllamaを動かしているなら、pullはコマンド1つ、ダウンロードは3.7 GBで、これが置き換えるものは、顧客のテキストで行いたくないホスト型呼び出しか、モデルの価値に見合わないほど保守に手間がかかるPython環境のどちらかだ。これが実際のユーザーの前に置かれる前に精度の独立した証拠が必要なら、その証拠はどのd1モデルにもまだ存在せず、どれだけローカルでパッケージングしても生み出せない。

意思決定ステップを自分のハードウェアで実行することは、このクラスでこれまでに何がうまくいかなかったかを確認するのにも良い機会です。意思決定モデルに関わる文書化されたAIインシデントやエージェント障害は、以下に収集されています：OrcaRouter AI Incident Archive。各エントリには、それぞれ独自の出典、重大度、信頼度グレード、異議フラグが付いています。