Liquid AI d1-omni-600M vs Liquid AI d1-3B：d1ファミリーのどちらの半分が本当に必要なのか？

Liquid AI d1-omni-600M と Liquid AI d1-3B は、2026年10月5日に互いに8時間以内で Hugging Face にアップロードされ、同じ10月7日の発表で一緒にリリースされた。そのため、いつもの問い——どちらが新しいのか、どちらが優れているのか——は間違った問いになる。両者は、意図的に設計されたトレードオフの両端だ。Liquid AI d1-3B は完成品であり、3.12Bパラメータ、ベンダー採点の Decision Index 0.2.1 で48.57、ベンチマーク表、Jetson Orin Nano に至るまで測定されたレイテンシを備え、リリース記事ではそのサイズで最高の意思決定品質と説明される位置づけにある。Liquid AI d1-omni-600M は実験作であり、587Mパラメータ、同じインデックスで15.95、3Bにはない音声入力を持ち、モデルカードでは、まだ活発に開発中であるため推論の数値はなく、初期研究リリースであると明言している。どちらを選ぶかは品質の判断ではない。それは、ファミリーの下位側にある追加のモダリティが必要か、上位側にある追加の精度が必要かという判断であり、数字はその区分を曖昧にするのではなく、それを裏づける形で並んでいる。

以下はすべて、2つのモデルカードと10月7日のリリース投稿に基づくもので、リリース投稿自体のラベル付けを尊重しています。Decision Index 上の d1 行は、公開リーダーボードに提出されたのではなく、Liquid AI が公式スコアラーで採点したものであり、ここにある内容は独自に再現されていません。

決して収束することのなかった2つのバックボーン

d1ファミリーは、単一のレシピを縮小したものではない。2つのチェックポイントは、Liquidのモデルカタログの両端から出発し、中間で出会う。

Liquid AI d1-3Bは、同ベンダーが2026年8月に発表したデコーダ専用の視覚言語モデルであるLFM2.5-VL-3Bを基盤としている。そのベースは、LFM2.5-2.6Bの重みとLFM2.5-VL-3Bのテキストバックボーンを平均化し、その後、異なる乱数シードとデータ混合のもとでチェックポイントをファインチューニングしてから再びマージすることで作られた。SigLIP2 NaFlexの形状最適化された400Mの視覚エンコーダ、32,768トークンのコンテキスト、128,000トークンの語彙、そして16の文書化された言語を備えている。

Liquid AI d1-omni-600Mは逆の方向から来ている。そのトランクは LFM2.5-Encoder-350M であり、双方向エンコーダで、まず意思決定タスクでファインチューニングされ、その後段階的に拡張された——音声用の17層 FastConformer エンコーダとアダプタを備え、その後音声エンコーダが凍結されたテキストバックボーンに対してファインチューニングされ、次に LFM2.5-VL-450M から持ち上げた SigLIP2 タワーをアダプタと共に、そして視覚用にバックボーンへの LoRA 更新を加えた。最終モデルは LoRA 更新からマージされ、前のチェックポイントと平均化された。合計587Mパラメータになる：381Mの共有トランクと意思決定ヘッド、94Mの視覚エンコーダ、112Mの音声エンコーダである。

「デコーダのみ」対「双方向」という点が押さえておくべきところだ。3Bは、言語モデルがトークン列を一方向ずつ生成するのと同じように、状態を読んで決定を出す。600Mは状態全体を一度に読んで決定する。これは、生成するために作られたわけではないエンコーダから期待される通りのことだ。どちらも、出力トークンゼロでモデルの分布から答えを報告するように訓練されているが、その土台にある仕組みは同じクラスのモデルではない。そして以下の精度差は、より小さなエンコーダ型設計の目に見える代償である。

「Decision Index」のスプレッドは大きく、サブスコアは合計値よりも興味深い。

Decision Index 0.2.1 では、Liquid は Liquid AI d1-3B について 48.57、Liquid AI d1-omni-600M について 15.95 を報告しており、Winnow-12B の 50.02 と対比されています。これは、同じラボが同じ日にリリースした2つのチェックポイントの間に32ポイントの差があることを意味し、5つのサブスコアを読めば、その差がどこから生じているのかが分かります。

• 知識 — Liquid AI d1-3B は 23.8、それに対して Liquid AI d1-omni-600M は 8.3

• 言語 — 56.4 対 12.9

• 検索 — 52.8 対 35.0

• ツール — 74.5対15.1

• 芸術 — 36.3 対 6.8

検索は、小型モデルが唯一健闘する領域であり、他の4カテゴリでは3Bのスコアの60〜80パーセントを失うのに対し、ここでは3Bのスコアの3分の1未満しか失わない。このパターンは600Mというモデルの性質と一致している。つまり、状態とコンテンツを照合するための真の表現能力を備えた訓練済みエンコーダであり、はるかに多くの言語で事前学習されたデコーダから3Bが受け継ぐ層状の能力ははるかに少ない。あなたのワークロードが検索型の判断——この文章はこの問いに答えるか、これらの文書のどれが関連するか——であるなら、600Mのプロファイルは、その総合スコアが示唆するよりも悪くない。ワークロードがツールルーティングの判断であるなら、その列の51ポイントの差こそが、じっと見つめるべき数字だ。

テキストベンチマークの表は、インデックスよりも穏やかな内容を示している。どちらの数値も主張の根拠に使われる前に知っておく価値がある。7つの公開ベンチマークでは、3Bが平均82.9でリードし、600Mは78.4に達する。600Mは実際、SQuAD 2.0（74.0 対 85.3）、PubMedQA（61.3 対 66.0）、BoolQ（77.7 対 86.7）、XNLI（74.7 対 85.0）では僅差で負けているが、Civil Commentsの毒性検出（95.8 対 93.0）とPAWS-Xの言い換え識別（79.5 対 76.9）では勝っている。Liquid自身の説明では、600Mはパラメータ数4分の1でDecider 2Bの平均77.1を上回る。2つのベンチマークスイート、2つの異なる見かけ上の判定、いずれもベンダー報告——証拠が支持するのはそこまでであり、それ以上ではない。

600Mが持っていて3Bにはないもの

32ポイントの指標差を許容する理由は、Liquid AI d1-omni-600M が Liquid AI d1-3B にはできないことを一つ実行するからであり、それは忠実度の違いではない。

• 音声 — Liquid AI d1-omni-600M は FastConformer エンコーダーを介して、リクエストあたり最大 30 秒の音声を処理できます。Liquid AI d1-3B は音声を一切受け付けません

• モダリティの混在 — 600M はテキストと画像、またはテキストと音声を受け付け、両方が同時に渡された場合は ValueError を送出します。3B はテキストと画像を受け付けます

• コンテキストウィンドウ — 600Mではテキスト、画像、音声の各位置にわたり16,384トークンで、画像が存在する場合はテキストが896トークンに切り詰められる；3Bでは32,768トークン

• 語彙数 — 600Mは65,536、3Bは128,000

• 精度 — 600M カードは GPU で float16 を推奨し、bfloat16 が一部の行で最上位の回答を変えたと警告しています。3B は w8a8 ビルドを含む 15 種類の量子化を提供しています

• 言語 — 600Mは16言語を、3Bの16言語とは異なるセットで列挙しており、その音声は英語話者とアシスタントのやり取りで学習されたと説明されているが、これは本番の音声フィードに含まれる内容のごく一部にすぎない

音声トレーニングに関する注記は流し読みして見逃しやすく、見逃すべきではない。英語の話者とアシスタント間のやり取りで訓練されたモデルは、1つの話者配置、1つのターン構造、1つのアクセント分布しか見てきていない。それをコールセンター音声やフィールド録音に導入するのは、カードが主張していない挙動を求めることになる。またリリース投稿は、照らし合わせて確認できる音声意思決定ベンチマークが存在しないことを率直に述べており——Liquidはそれを「現在未解決の問題」と呼び、コミュニティーにその構築を呼びかけている。

レイテンシ：一方の兄弟にはテーブルがあり、もう一方には脚注がある

決定モデルでは興味深い数値はエンドツーエンド遅延です。というのも、計測すべきデコードが存在しないからです。Liquid は 3B については完全なセットを公開していますが、600M については何も公開していません。

• 質問1回 — RTX 4090で8 ms、MI325Xで9 ms、Jetson AGX Thorで16 ms、Jetson AGX Orin 64 GBで26 ms、Orin Nanoで50 ms、Apple M5 Proで30 ms

• 1つの状態に対する3つの質問 — RTX 4090では21 ms、AGX Thorでは20 msで、単一の質問のコストのおよそ1.3倍であり、3倍ではない

• 3.4Kトークンの状態 — 4090では102 ms、Thorでは220 ms、Orin Nanoでは1,640 ms

• パックドスループット — RTX 4090で毎秒475決定、MI325Xで毎秒1,106決定

• 384px の画像 — 4090 では 17 ms、MI325X では 18 ms

これらの数値は Liquid AI d1-3B のみを説明しています。Liquid AI d1-omni-600M については、モデルカードに、このモデルは活発に開発中の早期研究リリースであるため、推論の数値は報告されていないと記載されています。小さなモデルの方が遅いというわけではありません。むしろ逆であることはほぼ確実です。同じ精度でパラメータが5分の1になっても遅くはならないからです。そうではなく、数値が存在しないのであり、600M に対して 3B のミリ秒を引用するのは、もっともらしい形をした捏造になってしまいます。何も捏造せずに言えるのは、カードが推奨する float16 精度では、587M パラメータは活性化前の重みでおよそ 1.2 GB のオーダーになるということです。これは測定値ではなく、公開されたパラメータ数に基づく算術です。

ほとんどのワークロードにとって、カスケードこそが本当の答えだ

両方のチェックポイントは同時にリリースされ、同じ種類のオブジェクト — 確率、信頼度付きのラベル、または順序付きスコア — を返すため、任意の2つのモデルにはできない形で組み合わせることができます。600Mはスクリーニングを担当し、3Bは判定を下せます。受信項目を Liquid AI d1-omni-600M でスコアリングし、そのスケールの中間付近に置かれたものを Liquid AI d1-3B にエスカレーションして、より精密な判断を求めます。エスカレーションのルールは、600Mがすでに返す信頼度と分布であるため、ルーティングロジックに追加のモデルは不要です。簡単な項目が圧倒的多数を占めるワークロードでは、ほとんどのトラフィックは3Bに到達せず、ほとんどのコストは費やされません。

そのパターンは、この2つのモデルをルーターの背後で動かす価値がある理由でもある。OrcaRouter を通せば、どちらも1つのAPIキーの背後に置かれ、各プロバイダーの定価が0%のマークアップでそのまま適用されるため、カスケードは2つ目の統合ではなくルーティングルールになり、プロバイダー層で失敗したエスカレーションも、リクエスト全体を失敗させる代わりにフォールバックで再試行される。ここでは自動フェイルオーバーが、安定したモデルの場合よりも重要になる。このペアの片方は、ベンダー自身がその挙動を現在活発に開発中と説明しているチェックポイントだからだ。

それは可用性の主張ではまったくなく、この区別ははっきり示す価値があります。オープンな d1 チェックポイントは当社のカタログにはありません。ベンダーのルートは、重みをダウンロードしてローカルで実行すること——llama.cpp のサポートは初日から Apple、AMD、Qualcomm、NVIDIA のハードウェアに対応していました——あるいは、ベンダー自身の API やサードパーティのプラットフォームを通じてそれらにアクセスすることです。

一巡で選ぶ

テキストと画像が必要で、答えが正確でなければならないなら、Liquid AI d1-3B を選びましょう。これにはベンチマーク、レイテンシ表、より広いコンテキスト、より大きな語彙、量子化が備わっており、Liquid が同サイズで品質リーダーとして位置づけるペアの一方です。

判断経路に音声が必要なら、Liquid AI d1-omni-600M を選びなさい。なぜなら、このファミリーで音声をそもそも受け付ける唯一のオープンウェイトの選択肢であり、音声意思決定ベンチマークか非公開の vision split が誰かによって公開されるまでは、ノリとデモだけで採用しているのだと受け入れるほかないからです。

それらのどれが自分のワークロードを表しているのかまだ分からないなら、まず3Bから始めて、それが返す信頼度を計測しましょう。サブスコアが手がかりです。Tools列またはLanguage列に属するタスクは600Mではひどく扱われることになりますが、retrieval型のものは、小さいチェックポイントがその総合値から示唆されるよりも近い唯一の領域です。このファミリーは精度とフットプリントを交換できるように存在しており、その交換が安全なのは、自分のタスクがどの列に属するかを知っている場合だけです。

OrcaRouter経由なら、両モデルは1つのAPIキーの背後に、2つ目の統合ではなくルーティングルールで配置され、プロバイダー層で失敗するエスカレーションは、リクエストを失敗させる代わりにフォールバックで再試行されます。