{{1}}Liquid AI d1対Liquid AI d1-omni-600M：あなたの声を聞くことができるオープンな意思決定モデル{{/1}}

名前を検索すると、Liquid AI d1という、テキストと画像を読む30億パラメータモデルに行き着く。同じファミリーのもう一つのオープンチェックポイントは5分の1のサイズで、最大30秒の音声を考慮でき、2つのうち声について何らかの判断ができる唯一のものである。それはLiquid AI d1-omni-600Mと呼ばれており、もしあなたがベンダー自身のドキュメントではなくローカルランタイムライブラリを通じてこのファミリーを見つけたのなら、その名前を見たことがない可能性は十分にある。この比較が解決しようとしているのはまさにその状況である。なぜなら、この2つのモデルは同じ問いに対する競合する答えではないからだ。それらは2つの異なる問いへの答えであり、そのうち聞くことが関係するのは一方だけである。

以下の数値はすべて、Liquid AI 自身の資料、すなわち LiquidAI/d1-omni-600M のモデルカード、その姉妹リポジトリである d1-omni-600M-GGUF、そして両方のオープンチェックポイントを同時に発表した10月7日付のリリース投稿に由来する。性能の各行は、公開ランキングに提出されたものではなく、ベンダーが自ら管理する指標に基づいて採点したものであり、その投稿は、音声判断に特化したベンチマークが未解決の課題であると明言している。ここにあるものは、ラボの外部のだれによっても再現されていない。

5億8700万のパラメータは何でできているのか

見出しの数字は、ある珍しい分割を隠している。総パラメータは587Mだが、それらは一つのスタックではない。判断ヘッドが取り付けられた381Mの共有トランク、94Mの視覚エンコーダ、そして112Mの音声エンコーダだ。すべてのモダリティは同じトランクの重みを通り、これが全体を小さく保つ設計上の決断である。このモデルはトレンチコートを着た3つのモデルではなく、2つの入力経路を持つ1つの判断トランクなのだ。

各部品は、Liquidのカタログ内の異なる場所に由来しています。トランクは、双方向エンコーダーであるLFM2.5-Encoder-350Mに由来し、より大きな兄弟モデルが由来するデコーダーのみの系統からではありません。ビジョンタワーは、LFM2.5-VL-450Mから取り出したSigLIP2で、バックボーンにアダプターとLoRA更新を適用したものです。音声パスは、独自のアダプターを備えた17層のFastConformerエンコーダーで、凍結されたテキストバックボーンに対して微調整されています。モデルカードには、テキスト、画像、音声の位置にまたがって共有される16,384トークンのコンテキストが記載されており、画像が存在する場合にはテキストが896トークンに切り詰められ、語彙は65,536トークン — より大きな兄弟モデルの128,000の半分です。この最後の数字は、このファミリーが部分的にしかカバーしていない言語で作業する場合には注目に値します。

双方向とデコーダ専用の違いが、両方を実行したことがある人なら誰でも、2つのモデルを異なって感じる理由です。エンコーダ型のトランクは、何かを生成する前に、双方向で状態全体を一度に読み取ります。デコーダ型のものは、言語モデルが行うように前方に読み取ります。どちらも、出力トークンがゼロの分布から答えを報告するように訓練されているため、どちらもテキストを書きません — しかし、その下にある仕組みは異なるクラスのモデルであり、以下で説明する精度ギャップは、より小さなエンコーダ型設計の目に見えるコストです。

30秒間のスピーチ、それを採点するものがない

音声こそが、このチェックポイントが存在する理由だ。最大30秒、16 kHzモノラルの単一クリップを、回答を生成するのと同じフォワードパスで受け付ける。そうできるのは、このファミリーの中でオープンウェイトのモデルとしてはこれだけだ。オンデバイスの用途にとって、これは些末な特徴ではない。生産ラインで欠陥を検知するカメラは、より大きな兄弟モデルがすでに扱える視覚の問題である。一方、音声によるリクエストを振り分け、発話を分類し、あるいは発信者が返金を求めているかどうかを判断するデバイスは、これだけを向けられる問題なのだ。

その能力の上には2つの制約が乗っており、どちらも文書化されている。つまり、本番環境でそれらにつまずく言い訳はない。第一に、1つのリクエストが運ぶのは画像または音声のいずれか一方であり、両方ではない — 両方を渡すと、片方を黙って捨てるのではなく ValueError が発生するので、失敗ははっきりと現れ、テストで見つけるのは容易だ。第二に、音声パスは英語話者とアシスタントの間のやり取りで訓練されており、クリップは30秒で切られている。それは1つの話者配置、1つのターン構造、1つのアクセント分布にすぎない。それをコールセンターの録音やフィールド音声に向けるのは、カードが主張していない挙動を求めることであり、まさにベンチマークが存在すれば明るみに出すであろう種類のギャップだ。

存在しない。リリース記事は専用の音声判断ベンチマークを「現在未解決の課題」と呼び、コミュニティにその構築を呼びかけている。これはラボが書くには率直なことだが、このモデルを評価しようとする者にとっては現実的な制約となる。Liquid AI d1-omni-600Mは、まだ誰も測定できない能力の強みによって自らを正当化することを求められている。ベンダーはまた、モデルが活発に開発中の初期研究リリースであるという明示的な理由のもと、推論の数値を完全に伏せている。したがって、600Mのレイテンシ値はまったく存在しない — テキストについても、ビジョンについても、そして肝心要である音声経路についても。

何もでっち上げずに言えるのは、公開されているパラメータ数に対する算術だけだ。モデルカードがGPU向けに推奨するfloat16精度では、587Mパラメータはアクティベーションを考慮する前の重みで約1.2GBの規模になり、これに対して同じ精度の3.12Bの兄弟モデルではおよそ6.2GBになる。モデルカードには、つい流し読みして通り過ぎてしまいがちだが、そうすべきではない精度に関する警告も記載されている。モデルはfloat32で学習され、GPUではfloat16が推奨されており、テスト中にbfloat16では一部の行で最上位の回答が変わった。もしあなたのサービングスタックがデフォルトでbfloat16を使うなら、このモデルではそのデフォルトは安全ではない。

家族が見落とされやすい理由

読み手が3Bにたどり着いてそこで止まるのは、偶然ではなく構造的な理由による。Liquid AIのドキュメント索引は意思決定モデルの下に3つの行を並べているが、それらは同じようには読めない：d1-3Bとd1-omni-600MにはHugging FaceとGGUFのリンクがあり、trainable列は「No」なのに対し、d1は独自の行にあり、他のあらゆるモデルのダウンロードリンクがあるべき場所に、裸の「API」の文字が置かれている。リリース投稿はd1をファミリー名と呼び、提供されるエンドポイントとオープンなチェックポイントをまったく区別していない。するとローカルのランタイムライブラリは3Bを選ぶ。というのも、公開したいエントリとサイズとモダリティ数が一致するのはそれであり、600Mは同じ一覧にはまったく現れないからだ。

その結果は、公開されているアクセスに関する説明をざっと読むと、一つのモデルと一つのAPI行のように見えるファミリーである。実際に提供されているのは、異なるトランクと異なるモダリティを持ち、ベンダー自身のインデックスで両者のスコアに32ポイントの差がある二つのオープンチェックポイントに加え、どちらのチェックポイントとの関係についてもベンダーが確認したことがないホスト型エンドポイントである。600Mは何かによって隠されているわけではない。単に、検索語として使うd1で浮かび上がってくる名前を持っていないだけであり、二つのうち聴覚を持つのはこれだけである。

存在するスコア、そして読む価値のある唯一の列

Decision Index 0.2.1 では、ベンダーは 15.95 を報告しています。対象はLiquid AI d1-omni-600Mです。一方、より大きな兄弟モデルは 48.57 です — その差は、選択の根拠として合計がほとんど役に立たないほど大きなものです。サブスコアは合計よりも情報量が多く、そのうちの1つは本当に驚くべきものです。

• 知識 — 8.3 対 23.8

• 言語 — 12.9 対 56.4

• 検索 — 35.0 対 52.8

• ツール — 15.1 対 74.5

• 芸術 — 6.8 対 36.3

Retrievalは、小さいモデルが健闘する領域だ。ほかの4つの列ではスコアの60～80パーセントを失うのに対し、ここでは大きいモデルのスコアの3分の1未満しか失っていない。このパターンは、学習済みエンコーダが得意とすべきことと一致する。状態とコンテンツを照合することは、トランクがまさにそのために作られたことに近く、デコーダ型の兄弟分がはるかに大規模な事前学習から受け継いだ層状の言語能力への依存度ははるかに低い。Tools列は逆の話であり、ワークロードがリクエストを適切な関数にルーティングするものであるなら、そこでの59ポイントの差こそじっと見つめるべき数字だ。

7つの公開テキストベンチマークでは、全体像は和らぐ。ベンダーは600Mの平均78.4を、3Bの82.9に対して報告している。小型モデルは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は2Bの意思決定モデルの平均77.1を、パラメータ4分の1で上回る。2つのベンチマークスイートは、どちらも自己申告でありながら2つの異なる見かけ上の判定を出しており、正直に読めば、どちらもオーディオ経路について何も決着させていない。なぜなら、オーディオ経路はどちらのスイートにも含まれていないからだ。

二人が実際に出会う場所

あらゆる相違があっても、プログラミングモデルは同一であり、まさにその点が、ある特定の意味で両者を交換可能にしている。どちらも状態に対して noul、選択式、スコア式の質問に答え、どちらも選ばれた回答を確率マップと0から1の間の信頼度の値とともに返し、どちらも output_tokens: 0 を報告する。confidence フィールドは人々が誤読するもので、それは確率が一つの回答をどれほど強く支持しているかを測るのであって、その回答が正しいオッズを測るのではない。不適切に提示された質問に対する0.96は自信に満ちた誤答であり、このフィールドはあなたに警告しない。

実運用で両者が交わるのはカスケードだ。スクリーニングにはLiquid AI d1-omni-600Mを使う — 安価に、ローカルで、しかもテキストのみのスコアラーでは扱えない音声ケースも含めて — その後、それが尺度の中間付近に置いた項目を、より鋭い判断のために大きなチェックポイントへエスカレーションする。エスカレーションのルールは、600M がすでに返す信頼度と分布なので、ルーティングロジックに追加のモデルは不要であり、簡単な項目が大多数を占めるワークロードでは、トラフィックの大半が第2段階に到達しない。この構成が機能するのは、両モデルが同じ種類のオブジェクトを返すからだ。任意の2つのモデルではそうならない。

そのカスケードが、自分で動かすのではなく借りている生成モデルへの呼び出しをゲートするようなことがあるなら、その下のレイヤーこそ配管が面白くなるところであり、私たちが関わってくるのもそこです。意思決定をモデルの連鎖に通すのは、まさにルーティングルールが得意とする形の問題です。OrcaRouter は複数のモデルを 1 つの OpenAI 互換エンドポイントの背後にまとめ、それぞれをプロバイダーの定価のまま 0% のマークアップで提供し、プロバイダーをまたぐ自動フェイルオーバーを備えているので、プロバイダー層で失敗したエスカレーションはリクエスト全体を失敗させるのではなくフォールバックで再試行されます。私たちは Liquid AI のモデルを一切ホストしていません（これを書く前に確認しました）ので、ここまでの内容は、これらの重みを私たち経由で呼び出すことについての主張ではありません。要点は、意思決定モデルはパイプラインの中で安価な部分であり、反対側で借りているモデルのほうが落ちる部分だということです。

ファイルの入手元、今日それを実行したいなら

ローカル展開の場合、600M向けのベンダー自身のGGUFリポジトリはQ8_0を407 MBで、F16とBF16をそれぞれ764 MBで提供しており、4ビットビルドは掲載されていません — そのため、公式ダウンロードで最小のものは、より大きなモデルの対応するビルドよりも約7分の1のサイズで、中解像度の写真とほぼ同じ大きさです。カード自体の例では、llama.cppサーバーをバッチフラグ4096で起動し、より長い状態には16384へ引き上げることを提案したうえで、より大きな兄弟モデルが使用するのと同じ /v1/systemone エンドポイントにクエリを送ります。

ローカル経路が与えてくれない唯一のものは、音声経路の数値だ。なぜなら、それは存在しないからだ。これを実際のユーザーの前で音声に通すつもりなら、評価は自分で構築するしかない。ラベル付きのクリップ一式、同じ3種類の質問タイプ、そしてクラスごとに測定された回答率だ。これはモデルを否定するものではない——音声クリップを1パスで判定する587Mのチェックポイントは、文字起こしステップにテキスト分類器を接ぎ木したものとはまったく異なるツールであり、雰囲気に基づくテストではなく本物のテストに値する。

そのカスケードが、自分で運用するのではなくレンタルする生成モデルへの呼び出しをゲートすることがあるなら、OrcaRouter は OpenAI 互換の単一エンドポイントの背後に複数のモデルを組み合わせ、それぞれをプロバイダーの定価のまま、0% のマークアップで提供します。

テキスト専用のものではなくオムニチェックポイントを選ぶことは、このクラスですでに何がうまくいかなかったかを確認するのにも良い機会です。小規模マルチモーダルモデルが関与した、記録されたAIインシデントやエージェント障害はOrcaRouter AI Incident Archiveにまとめられており、各エントリには独自の情報源、重大度、信頼度グレード、異議ありフラグが付いています。