d1-omni 対 Liquid AI D1 Omni 600M：2つの名前、1つのチェックポイント、そして誰も出典を特定できないコンテキスト数

Liquid AI D1 Omni 600Mとd1-omniは2つのモデルではなく、同一モデルの2つのチェックポイントでもありません。これらは1組の重み——Liquid AI LFM2.5-Encoder-350Mを基盤とし、2026年10月5日にLiquidAI/d1-omni-600Mというリポジトリ名でHugging Faceに公開された、Liquid AIの587Mパラメータのマルチモーダル意思決定モデル——が、2つの異なるカタログでそれぞれ異なるファイル名を持っているものです。そのうち一方、ベンダーのカタログはモデルが何であるかを伝えます。もう一方のOllamaのカタログは、誰かがそれを何にパッケージしたかを伝え、ベンダーのドキュメントが裏付けていない3つの数値をカードに記載しています。このギャップこそが、この比較を読む価値がある理由のすべてです。というのも、これほど小さなモデルにとってパッケージングは脚注ではなく、テキストと画像のモデルと、カードがダウンロードしたと称するモデルとの違いそのものだからです。

ベンダーはOllamaの項目について何も発表しておらず、Ollamaページにはメンテナーのメモも、変更履歴のエントリも、readmeもなく、そのいずれについても説明がない。したがって、以下のすべてについての正直な枠組みはこうだ。重みは公開されており検査可能であり、パッケージングも公開されており検査可能であり、ここで示すパッケージングの解釈は私たちのものであってLiquid AIのものではない。数値を情報源までたどれない場合、本記事はそれを繰り返さず、その旨を明記する。

その2つの名前が実際には何なのか

Liquid AIは2026年10月5日という作成タイムスタンプでHugging Faceにモデルを公開した。これは10月7日にベンダー自身のブログ記事「Open d1: Edge decision models for text, vision, and audio」に登場する2日前のことである。重みはLiquid独自のLFM 1.0条件でライセンスされ、d1_omni、system-one、multimodal、vision、audio、decision-modelというタグが付与されており、執筆時点で約13,900ダウンロード、135いいねを獲得している。量子化版は独自のスケジュールで続いた。GGUFリポジトリは10月6日、Apple Silicon向けMLXビルドは10月12日である。

そのOllamaの項目は、それらのリポジトリのいずれでもありません。それはd1-omniという名前のOllamaライブラリページで、「vision 600m」というバッジを掲げ、4つのタグを表示し、この文章が書かれる数分前に更新されていました — だからこそレーダーはそれを拾い上げたのです。その中にはLiquid AI、LFM2.5-Encoder-350M、またはそのバイト列の出所であるHugging Faceリポジトリの名前はどこにもありません。

つまり実際の違いはファイル名と配布経路であり、モデルそのものではない。異なるのは、そして重要なのは、そのバイト列を包み込んでいるメタデータだ。

Ollamaカードにある3つの数値を、1つずつ確認しました

Ollamaのページは、タグごとにサイズ、コンテキストウィンドウ、入力リストを表示している。この3つはいずれも再確認する価値がある。なぜなら、このモデルではそのうち2つは、ソースと突き合わせるとそのままでは通用しないからだ。

• コンテキストウィンドウ — カード上は125K、ベンダー資料ではすべて16,384。Liquid AIのモデルカードには、テキスト、画像、音声の位置を合わせてカバーする16,384トークンの上限が記載されており、ベンダー自身のd1-omni-600M向けドキュメントページには「16K tokens」とある。125Kという文字列はどちらにも現れない。これは基盤となるLFM2.5-Encoderアーキテクチャの位置設定の産物かもしれないし、Ollamaがキャッシュ上限を報告する方法の産物かもしれないが、Liquid AIが公表した数値ではなく、本記事が誰かに帰属できる数値でもない。この食い違いが単なる揚げ足取りではない理由は、その次に小さい数値にある。

• 画像パス上で実際に渡せる状態は、896トークンで上限がかかります。Liquid のカードには、画像がある場合、「状態と質問のテキストは、トレーニング時と同様に896トークンに切り詰められる」と書かれています。したがって、写真を含む意思決定リクエストのテキスト予算は、プルページにどんなコンテキスト数が記載されていても、この文とほぼ同じ大きさになります。トリアージプロンプトを125Kに合わせて設計し、長い状態のコストを払うつもりでいたなら、それはランタイムを表していない数値に合わせて設計していることになります。16,384 という数値が本当の上限であり、896 という数値がマルチモーダルパスの実際の実用上限です。125K は根拠となる記録がない数値です。

• サイズ — カード上で850MB、レジストリに2つのファイル。Ollamaのタグd1-omni:latestは、Q8_0指定の407MBの量子化重みファイルと、BF16指定の442MBのプロジェクタファイルに解決され、407 + 442 = 849となり、ページではこれを850MBに丸めている。どちらも正直に記載されており、この算術は1つのファイルではなく、混精度のペアの合計にすぎない。d1-omni:600m-bf16タグの方がよりすっきりしている。BF16の重み764MBに同じ442MBのプロジェクタを加えて、ディスク上で1.2GBであり、プロジェクタは2つのタグ間でバイト単位で同一である。次のセクションで注目に値する。なぜなら、独自の重みを抱えるプロジェクタは実効パラメータ数を変動させうるからだ。

説明するよりも記録しておく価値のある細部がもう一つある。Ollamaのd1-omniパッケージ内のランタイムパラメータブロブは、バイト単位で同じ長さ——18バイト——であり、Ollamaの別個のd1パッケージ内のものと同じである。このパッケージには、2.87GBのQ8_0重みと855MBのプロジェクタを備えたLiquid AI d1-3Bが含まれている。二つのアーキテクチャ、二つのパラメータ数、両者の間にはパラメータ規模で二桁の差があり、しかもランタイム設定は同じ18バイトである。これはパッケージング上の定数であり、どちらのモデルについての主張でもない。

重み自体が語るもの

外装を剥がしてしまえば、このモデルは驚くほどよく文書化されている。Liquid AI D1 Omni 600M は合計587Mパラメータを3つに分割している。381Mの共有トランクと決定ヘッド、94Mの視覚エンコーダ、112Mの音声エンコーダだ。トランクは双方向であり、これはデコーダではなくエンコーダである。そしてすべてのモダリティで同じトランクを使い、モダリティ固有のタワーを外付けしている。

• ビジョンは、Liquid AI LFM2.5-VL-450Mから継承したSigLIP2タワーに由来し、アダプターとLoRA更新は画像入力に対してのみ有効で、エンコーダー自体は凍結されたままでした。

• 音声は、専用のアダプターを備えた17層のFastConformerから生成され、テキストバックボーンを凍結した段階でファインチューニングされ、その後スタック全体がファインチューニングされ、LoRAが統合され、重みは以前のチェックポイントに対して平均化されて戻されました。

• 語彙は、英語、ドイツ語、スペイン語、フランス語、イタリア語、オランダ語、ポーランド語、ポルトガル語、アラビア語、ヒンディー語、日本語、ロシア語、トルコ語、ベトナム語、中国語の15言語にわたる65,536トークンです。

• モダリティは混在できません。 1回のリクエストで扱えるのは、テキストと画像、またはテキストと最大30秒の音声のいずれかであり、両方を同時には使えません。音声は16kHzモノラル、0.5〜30秒であることが想定されており、英語話者とアシスタントのやり取りで学習されているため、多言語や雑音のある環境では実際の制約となります。

そうしたことはOllamaのページには一切記載されておらず、この欠落がもたらす結果は使用例の中に直接見て取れます。Ollamaのスニペットはチャット呼び出しです — モデル文字列、messages配列、「Hello!」という語 — そして基盤となるチェックポイントはそれらに答えることができません。それはチャットモデルではなく、テキストを書きません。返すのは型付きの答えです。すなわちyes/noの確率、ラベルごとの確率を伴うラベル、あるいは順序尺度上の位置であり、いずれも生成される出力トークンがゼロのまま、出力分布から直接読み取られます。公開されているインターフェースはそれを反映しています：system_oneとprobabilities（Transformers経由）、または/v1/systemoneエンドポイント（llama.cpp 0.7.0以降）です。決定モデルに対してチャット形式の呼び出しを行うことこそ、この命名のずれが招く誤りです。

それらの数字には、どれにも二つの注意点が伴う

第一に、Liquid は公開ランキングに提出するのではなく、公式スコアラーで自社の行を採点しました。また、d1-omni-600M の結果を第三者が再現した例はありません。ベンダーはモデルカード上で、このチェックポイントは活発に開発中の初期研究リリースであるため、推論数値を報告していないと明言しています。第二に、見出しの2つの数値は互いに食い違っています。32ポイントの指数差と4.5ポイントのベンチマーク平均差は同じモデルを表しており、だからこそ有用なのは合計値ではなくサブスコアです。Retrieval が 35.0、Tools が 15.1 であるのに対し、Arts が 6.8 であることは、このチェックポイントがどの作業に向いており、どの作業にはまだ準備できていないかを示しています。Audio にはベンチマーク列がまったくありません。Liquid は、音声専用の意思決定ベンチマークを未解決の課題と呼んでいます。

Liquid AI D1 Omni 600Mは、7項目のうち2項目でも自ファミリー内で首位に立っている。Civil Commentsで95.8、PAWS-Xで79.5だ。この2行は、587Mのエンコーダーが3Bのデコーダーを完全に上回る行であり、どちらも推論向けというよりテキスト分類向けの形をしている——これはアーキテクチャに反するどころか、むしろ合致している。

何がしたいかで選んでください。Ollama でローカルに動かしたいなら、d1-omni が使える名前です — Q8_0 ビルドで 850MB、BF16 で 1.2GB、Liquid が文書化しているのと同じイメージパスで、どちらのタグにも音声プロジェクターは含まれていません。Liquid AI D1 Omni 600M がベンダーの説明するモデルを検索する際の名前で、Hugging Face リポジトリ経由の Transformers ルートが、コンテキスト長、モダリティ一覧、パラメーター数がドキュメントと一致するものです。

どちらにせよ、これはパイプラインの低コストな半分です。意思決定モデルが分類し、その分類に基づいて行動するのは別の何かです。まさにそこがOrcaRouterの位置する境界であり、正確に述べておく価値のある境界です。当社のカタログにはLiquid AIのモデルが含まれていないため、d1-omniの呼び出し自体は、すでに実行している場所で行われます — この重みを自社ハードウェアで動かす場合でも、ホスト版の兄弟モデル向けにベンダー自身のAPIやサードパーティのプラットフォームを使う場合でも。1つのOpenAI互換キーの背後にある200以上のモデルが担うのは下流のすべてで、その価格は各プロバイダーの定価を0%のマークアップでそのまま提供し、プロバイダー間の自動フェイルオーバーにより、トリアージされたリクエストが不調なモデルに分散する場合にも対応します。

何がその未解決の問いに決着をつけるのだろうか

これを決着させるには3つのことが必要で、そのどれもベンダーの発表を必要としない。同じ入力で850MBのOllamaタグの出力とHugging Faceのチェックポイントを比較する人がいれば、パッケージングによって回答が変わったかどうかが分かる。コンテキストの数値を説明するllama.cppのコミットやOllamaの変更履歴の項目があれば、125Kが誤りなのか、モデルカードが追いついていない能力なのかが分かる。そして公開された音声結果、どんな音声結果であれ、それがあればこのチェックポイントは現在属しているカテゴリー、つまり十分に文書化されたモデルでありながら文書化されていないパッケージング層を持ち、スコアボードが完全にベンダー自身のものであるというカテゴリーから抜け出せる。

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