Liquid AI d1-omni-600MがOllama Pullで利用可能に：あなたの声を聞き取れる600Mの意思決定モデル

Liquid AI d1-omni-600M2026年10月17日22:32 UTCにOllamaパッケージになった。このタイムスタンプは推測ではない。Ollamaのレジストリはすべてのマニフェストでollama-push-timeヘッダーを返しており、d1-omniという名前の下にある4つのタグはその夜の22:31:25から22:32:13の間に受け付けられた。これは執筆時点のおよそ4時間前のことだ。モデル自体は新しいものではない——Liquid AIオープンウェイトとしてLiquid AI d1-omni-600MとともにLiquid AI d1-3B2026年10月5日に公開し、10月7日の「Open d1」投稿で両方を発表した——しかし昨夜まで、音声対応のモデルを自分のハードウェアで実行する方法は、trust_remote_code=Trueを指定したtransformers環境か、自分でコンパイルしたllama.cppビルドだけだった。今ではollama pull d1-omniだ。誰もそれを発表しなかった。Liquid AIのブログも、Ollamaも。

パッケージこそが本題であり、そのどの部分が文書化されているかについては正確を期す価値がある。Liquid AIの最新のブログ記事は10月15日のd1-ultraと10月13日のLFM2.5-24B-A2Bで、どちらもOllamaに言及していない。同ラボ自身のOllamaデプロイページは今なお、GGUFリポジトリをHugging Faceから直接`ollama run hf.co/LiquidAI/...`で実行する方法を説明しており、d1モデルには一切名前を出していない。Ollamaのブログも同様に沈黙している——最新の記事は10月16日のReflection's Beamと10月13日のFly.io統合だ。代わりに存在するのは、レジストリのエントリ、4つのタグ、検証可能なダイジェスト、そしてこの記事の執筆中にもまだ作成途上だったライブラリページだ。そのページの初期のキャプチャでは「No readme」が返され、40分後のキャプチャでは、ベンチマーク表とライセンスセクションを備えた、Liquid AIが書いた完全な説明が返された。過去7日間について日付付きで検証可能な出来事が欲しいなら、そのヘッダーこそがそれだ。

レジストリが実際に受け入れたもの

4つのタグが2つのイメージに対応する。これは pull する前にまず理解しておくべきことだ。d1-omni:latest、d1-omni:600m、d1-omni:600m-q8_0 は同一のマニフェスト（ダイジェスト 1ba59f63e836）であり、一方 d1-omni:600m-bf16 は2つ目のマニフェスト（ダイジェスト c1e95fce6627）だ。F16 タグは存在しないが、ベンダー自身の GGUF リポジトリは F16 トランクを公開している。

• ウェイト層（Q8_0 ビルド）— d1-omni-600M-Q8_0.gguf からの 407 MB のトランクに加え、mmproj-d1-omni-600M-BF16.gguf からの 442 MB のプロジェクター、さらに 10.5 KB のライセンス blob と 18 バイトのパラメータ blob を含み、合計 849,659,968 バイト。

• 報告されているサイズ — デフォルトタグで 850 MB、600m-bf16 で 1.2 GB（いずれもライブラリページに記載されているとおり）。

• ランタイムの下限 — 必須: 設定ブロブ内の 0.40.4。同じ設定ブロブには model_family: lfm2、model_type: 380.73M、ファイルタイプ Q8_0 も記載されています。

• コンテキスト — パラメータブロブは num_ctx を 16,384 に固定します。

• ライセンス — 埋め込まれたテキストは LFM Open License v1.0 であり、許諾者として Liquid AI, Inc. を明記しており、モデルカード上の lfm1.0 識別子と一致しています。

そのプロジェクターはもう一度見る価値があります。なぜなら、それは接続先のモデルよりも大きいからです。レジストリの blob から GGUF メタデータを直接読むと、同じファイル内に clip.has_vision_encoder = True と clip.has_audio_encoder = True があることがわかります。768 次元の埋め込みと 256 ピクセル入力で 12 ブロックにまたがる 197 個の視覚テンソル、そして 512 次元の埋め込みと 128 個のメルビンで 17 ブロックにまたがる 641 個の音声テンソルです。これは SigLIP2 タワーと FastConformer エンコーダーの両方がマルチモーダルバンドル内を一緒に移動しているということであり、だからこそ 381M パラメータのトランクが 442 MB のアタッチメントの後ろに同梱されているのです。音声機能は、ダウンロードするパッケージに物理的に含まれています。エンドポイントがそれに到達できるかという問題は、後で扱うことになります。

モデルは587Mパラメータで、125Kバッジは実態より大きい

Ollamaのページはすべてのタグで「125Kコンテキストウィンドウ」を宣伝している。パッケージ自体のnum_ctxは16,384であり、Liquid AIのモデルカードも同じことを言葉で明記している。つまり、テキスト・画像・音声の位置を合わせて16,384トークンで、画像が含まれる場合は常に状態と質問文が896トークンに切り詰められる。125Kという数字は追跡可能で、trunk GGUFにはlfm2.context_length = 128000が入っている。しかしそれはアーキテクチャの上限であり、実際に得られるウィンドウではなく、長いコンテキストの分類器の代替品をサイズ選定している人を最も誤解させやすい数値だ。実用値としては16,384を、状態に画像が含まれる場合はテキスト896トークンを実用値として扱うこと。

メタデータの残りの部分は、マーケティング上の謳い文句ではなくモデルカードを裏付けている。トランクは18ブロック、幅1,024の埋め込み、語彙数65,536で、デコーダではない。lfm2.attention.causal は False だ。層ごとのKVヘッド数は 0, 0, 8, 0, 0, 8, … となっており、これらのブロックの大半はそもそもアテンションブロックではない。これは双方向エンコーダ由来の系譜が透けて見えているものだ。決定ヘッドは2ブロック（lfm2.decision.block_count = 2）で、ベンダーが config.json に保持しているキャリブレーション定数もこの GGUF に入っている。選択式質問は、選択肢が2つのとき温度1.7465、3〜5つのとき1.3999、6〜10つのとき1.1751、11以上で1.3725。はい/いいえは1.6663。採点式質問は3〜5段階で1.7301、6〜10段階で1.0。これで設計全体が一箇所に示されている。名前付き回答の固定セットを1回のパスで採点し、質問形式ごとにキャリブレーションし、最後に output_tokens: 0 を付ける。

チャットモデルではなく、テキストも書きません。Liquid AIは15言語を挙げていますが、音声学習データは英語のみ——話者とアシスタントの間のリクエスト——で、クリップは30秒までに制限しています。カードはまた、GPUでのbfloat16の使用に警告を発しています。ベンダー自身の検証では、テキスト行の0.8%と音声行の1.7%で最上位の回答が変わりましたが、float16はすべての箇所でfloat32と一致しました。

音声は重みの中にあり、文書化されたAPIには存在しない。

これは、バグを報告する前に知っておく価値のある不一致です。Liquid AI が書いたライブラリページの readme は、/v1/systemone リクエストの images 配列内に base64 WAV を入れることで音声を文書化しています。ベンダーの Hugging Face GGUF の同じチェックポイント向け readme は、それを別の方法で文書化しており、files 配列で data:audio/wav;base64,… を llama.cpp サーバーに渡します。そして、Ollama が公開しているエンドポイントリファレンスは、どちらの方法も文書化していません。そのリクエストスキーマには state、images、questions、keep_alive があり、images を「視覚を備えたモデル（Clef など）が必要」と説明し、audio フィールドも files フィールドも一切含んでいません。一方、Ollama 自身の決定モデルガイドは、Nimble、Tev1、Clef、Clef Flash を決定モデルとして挙げており、Clef モデルは画像も判定できるとだけ述べています。

つまり、今日のOllamaにおける音声に関する正直な立場はこうだ。エンコーダーがblob内に存在することは確認済みで、ベンダーのreadmeには画像経由で動作すると書かれているが、公開されているスキーマはそれを認めていない。同じモデルの画像入力はより確かな根拠に基づいている。視覚は文書化されたSystem Oneの機能であり、d1-omniはOllamaのビジョンカテゴリ一覧に現れている。これに並ぶ、より小さい文書のギャップが2つある。エンドポイントリファレンスでは選択式の質問で最大255個のオプションキーを許容しているのに対し、決定ガイドでは2から26とされている。また、パッケージのランタイム下限0.40.4は、エンドポイントドキュメントが引用する0.35.0より高い。

ビジョンに分類され、決断には分類されない

Ollamaのモデル検索では、意思決定モデルが専用カテゴリに分類されます。そこには9件のエントリ（nimble-v3、pplx-decider、kev、tev1、nimble、clef-flash、clef、laya、strands-decider）が含まれていますが、d1もd1-omniもその中にはありません。d1-omniのページにはvisionと600mのタグが付いており、visionの一覧には実際に表示されるため、「意思決定モデル」を探して閲覧している読者は最新のものを見つけられません。これは能力の問題ではなく発見可能性の問題ですが、Ollama自身のカタログで意思決定モデル群を比較しようと考え、これが存在しないと結論づけたなら、これは重要です。

それがまた意味するのは、d1-omni が Ollama のライブラリで音声をそもそも入力できる最初の決定モデルだということだ——音声エンコーダーはパッケージに含まれており、その9モデルのリストの中でそれを持っているのは他にない。エンドポイントがあなたの WAV をそれに渡すかどうかは、上の節で述べた未解決の問題であり、これを読む頃には最も変わっている可能性が高い唯一の点である。

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

以下に付随するすべての精度数値、すなわちLiquid AI d1-omni-600Mについての数値はLiquid AIのものであり、われわれが確認できる限り、現存するどのd1モデルについても独立した評価は存在しない——リーダーボードの行も、第三者による実行も、ベンダーの採点に対する公表された反駁もない。ベンダーはd1チェックポイントの両方を公開リーダーボードに提出するのではなく、公式のDecision Indexスコアラーで自ら採点しており、そのことをカードに明記している。同社の表にある競合の行はすべてリーダーボード v0.2.1 に由来しており、つまりこの比較は、自己採点の数値が外部で採点された数値の隣に並んでいるということだ。

• Decision Index 0.2.1 — d1-omni-600M が 15.95（知識 8.3、言語 12.9、検索 35.0、ツール 15.1、芸術 6.8）であるのに対し、d1-3B は 48.57。

• 意思決定としてのベンチマーク、7項目の平均 — d1-omni-600M は 78.4、d1-3B は 82.9。600M モデルは Civil Comments（95.8 対 93.0）と PAWS-X（79.5 対 76.9）で上回り、BoolQ（77.7 対 86.7）と SQuAD 2.0（74.0 対 85.3）で下回った。

• Fast Decisions、開発者別内訳 — 76.9、ベンダー報告値、比較行は未公開。

• 速度 — 記載なし。モデルカードには、これは活発に開発中の初期段階の研究リリースであるため推論の数値は報告していないと明記されており、他の場所で見かけるレイテンシに関する主張は、誰かが独自に測定したものにすぎません。

• Ollamaページのフィクスチャの数値 — readmeの実例では、urgentが0.998、technicalが0.995で回答済みとして示されています。これらはランタイムが公開した1回のリクエストの例示的な出力であり、ベンチマークではありません。

15.95と48.57の差は、このカード上で最も有用な情報だ。なぜなら、それは購入判断をベンダー自身の言葉で決着させてくれるからだ。readmeには、テキストと画像の精度が重要なときはd1を使い、サイズが重要だったり音声が必要だったりするときはd1-omniを選ぶよう書かれている。7つの公開ベンチマークで78.4を記録する587Mモデルを、判断材料として捉え直せば、もっともらしいエッジ分類器だ。それは3Bの小型版ではない。

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

当社はこのモデルを提供していません。10月18日に当社のカタログを確認したところ、208件のモデルIDが返されましたが、そのうちLiquid AIのものは一つもありませんでした。したがって、ここには可用性に関する主張は一切なく、当社側にそれを取得する経路もありません。Liquid AI d1-omni-600Mをご希望の場合、ローカル経路は前述のとおりであり、ホスト型経路はベンダー自身のAPIと、それを採用する第三者プラットフォームです。

パッケージングが変えるのは、その周囲にあるシステムの形であり、そこが私たちの役に立つところです。決定モデルがパイプライン全体を担うことはほとんどありません。それがラベル付けするチケット、フラグを立てるフレーム、ルーティングするトランスクリプトは、依然としてテキストを書く何かによって回答され、要約され、またはエスカレーションされる必要があります。それらの生成呼び出しは200以上のホスト型モデルをプロバイダーの定価で利用でき、0%のマークアップでパススルーされるOpenAI互換キー1つの背後にあり、ベンダーの価格変更は新しい契約を待つのではなく当日にあなたへ届きます。また、d1-omni-600Mは独立した精度の証拠も公開されたレイテンシも持たずに出荷されるため、実際のトラフィックに投入する正しい方法は、プロバイダー間の自動フェイルオーバーの背後に置くことです — 自信を持てる呼び出しは処理させ、そうでないときは逃げ道を確保しておき、587Mパラメータをトリアージ工程の単一障害点にしないようにします。判断はローカルにとどまり、フォールバックはそうである必要はありません。

何がこの読みを変えるだろうか

4つのこと。そのどれか1つでもあれば、パッケージング・ノートは別の記事になっていただろう。OllamaがSystem Oneのリクエストスキーマで音声を文書化すること。これが実現すれば、readmeのWAVを画像に埋め込む裏技がサポート対象の入力に変わり、これをワンコマンドで実行できる初の音声対応意思決定モデルになる。どちらかの企業がこの移植を認めること——Liquid AIがデプロイメントドキュメントのOllamaページにd1-omniを追加する、あるいはOllamaがそれをビジョンではなく意思決定モデルの下に掲載する。ベンダーかどうかを問わず、誰かからの速度の数値。今日ではそれが存在しないからだ。そして、どのd1モデルにも独立したDecision Indexの行。これはファミリー全体を通じて唯一欠けているピースのままだ。

それまでは判断は単純だ。すでに Ollama 0.40.4 以降を実行しているなら、pull はコマンド1つ、ダウンロードは850 MB、得られるのは587Mの分類器で、テキストと画像に対する1回のフォワードパスで入力された質問に答える——そして、READMEが正しければ、30秒を超える英語音声にも答える。状態が長い場合は、125Kのバッジではなく、16,384トークンのウィンドウと896トークンのテキスト予算を念頭に置いてほしい。そして、顧客が見るものにラベルを付ける前にそれが正確だと示す証拠が必要なら、その証拠はまだ存在しない——このモデルにも、その兄弟モデルのいずれにも。

このようなリリースの背景にある、文書化されたAI障害やエージェントのインシデントは、OrcaRouter AI Incident Archiveに収集されており、各エントリには独自の情報源、重大度、信頼度グレード、異議申し立てフラグが付いています。