Microsoft-Decision-1 対 Liquid AI d1-3B：同じ32Kウィンドウ、2つの異なる意味合い

今回ばかりは仕様が一致している。Microsoft-Decision-1は2026年10月8日からMicrosoft Foundryで一般提供されており、32,768トークンのコンテキストを扱う。Liquid AI d1-3Bも同様で、こちらは2026年10月5日にHugging Faceへアップロードされ、その2日後にLiquid AIが発表した。どちらも状態と、型付けされた質問の集合——はい/いいえ、名前付き選択肢の中からの選択、順序尺度上の位置——を受け取り、生成テキストではなく確率分布を単一のフォワードパスで返す。Laya、Intern-Decision-4B、Kev、そしてこのニッチの残りのモデルたちはコンテキスト長について互いに見解を異にしているため、この次元が脱落し、比較が別の何かで論じられなければならない唯一の組み合わせがこれである。

その“何か別のもの”の正体は、入力チャネルだった。Microsoftのモデルは明示的にテキスト専用で、「画像、音声、動画コンテンツを受け付けたり生成したりしない」。Liquid AIのモデルは、26億パラメータの言語バックボーンに4億パラメータのSigLIP2 NaFlex視覚エンコーダを搭載し、合計31.2億パラメータに達する。そして、Microsoftが除外したまさにその用途——スクリーンショット、スキャンしたフォーム、カメラのフレームを固定の質問に照らして採点すること——のために作られている。この分岐に、能力とは無関係なライセンスの違いを加えたものが、この対決のすべてだ。

両者が一致する場合、それは予想以上のことだ。

• コンテキストウィンドウ — Microsoft-Decision-1 は 32,768 トークン、Liquid AI d1-3B も 32,768 トークンです。

• 出力形式 — 提供された選択肢に対する較正済みの確率であり、どちらもテキストを生成しません。Liquid AI の使用量カウンターはその事実をoutput_tokens: 0。

• 質問タイプ — 文書選択、順序付きスコア、二値のはい／いいえのいずれにも対応し、いずれも語彙ヘッドを再トレーニングすることなくリクエストごとに選択肢セットを定義できます。

• 棄権 — Microsoft は "cannot tell" のような明示的な棄権オプションを文書化しています。Liquid AI の Decision Index スキーマも、そのオプションセットを通じて同様のことを実現しています。

• シングルパス推論 — どちらも意思決定ごとに1回の呼び出しで済み、この点が両者をパイプライン規模の処理量で実用可能にしています。

このニッチで最も難しい2つの制約について2つのモデルが一致していることは、少し立ち止まって考える価値がある。32Kウィンドウは、完全な契約書、複数ページのポリシー、長いサポートスレッドに対して意思決定スコアラーを使い物にするものだが、512トークンの英語LayaチェックポイントとIntern-Decision-4Bの呼び出しごとの質問制限はそうではない。入力が短ければ、この分野の大半は交換可能で、判断はホスティング次第だ。入力が長ければ、選択肢はこの2つに絞られる。

彼らのうちの1人だけが持っている感覚

Liquid AI d1-3Bはマルチモーダルであり、モデルツリーはその系譜を明確に示している。LFM2.5-2.6B-Base、次にLFM2.5-VL-3B、そしてシングルパスで較正された意思決定のためにポストトレーニングされたd1-3Bだ。画像はSigLIP2 NaFlexエンコーダーを通じて入力され、モデルカードは11の公開画像ベンチマークで平均74.1を報告している。これはベースビジョンモデルの73.9に対する数値であり、意思決定チューニングが視覚品質を犠牲にしなかったことを示している。また、逆の実験も報告されている。画像を取り除くと、同じ質問のスコアは45.1まで低下する。これは、知覚チャネルが装飾ではなく不可欠な構成要素であることを示す、これ以上ないほど明快な証拠だ。

Microsoft-Decision-1には相当するものがなく、この省略は未完成ではなく意図的である。Microsoftのモデルカードは、適用範囲外の用途としてテキスト生成、自由回答形式の質問応答、会話、翻訳、要約を挙げ、さらに別途、このモデルはテキスト専用であると明記している。フォームのスクリーンショットをルーブリックに照らして採点する必要があるパイプライン、またはカメラのフレームに安全イベントが含まれるかどうかを判断するパイプラインにとって、これは完全な行き止まりだ — モデルにそもそも与えられていないモダリティを、プロンプトエンジニアリングで取り戻すことはできない。

言語数は逆方向に進んでおり、これが2つ目の真の分水嶺だ。Microsoft-Decision-1は25のサポート言語を挙げており、同社はカバレッジ、品質、キャリブレーションが「言語によって異なる場合がある」と率直に認め、非英語、特に低リソース言語を性能不足分野として挙げている。Liquid AI d1-3Bは16言語を明記している。幅広さでは、紙の上ではマイクロソフトが先行している。幅広さが何を意味するかについての誠実さでは、両ベンダーは似たようなことを述べており、どちらも言語別のキャリブレーションを公開していない。

ベンチマークタブ、またか

Microsoft-Decision-1 の Foundry ページには、方法論セクションを備え、数値が一切ないベンチマークタブがある。公開およびコミュニティの意思決定ベンチマークに加え、ホールドアウトされた内部セット、精度とキャリブレーション誤差を対象とする指標、選択肢の順序を変えること、対応のある統計検定、そしてこのモデルが「同じ方法論で評価された主要な意思決定モデルと同等の性能を発揮し、他のオープンな意思決定モデルより優れている」という主張が含まれている。確認するものも、再現するものも何もない。

Liquid AI の d1-3B が Decision Index 0.2.1 で 48.57 を公表している — そして、その但し書きは数値以上に重要だ。なぜなら Decision Index は Liquid AI 自身の指標であり、d1-3B は Liquid AI 自身のモデルだからだ。これはベンダーが作成したベンチマークに対するベンダー採点の結果であり、同社は、10B 未満の意思決定モデルの中で最高であり、同じ尺度で 35B モデルを上回ると位置づけている。48.57 は監査済みの数値ではなく、方向性を示す主張として扱うべきだ。それと並んで、モデルカードには内部の意思決定フォーマット評価が平均 77.1、SQuAD 2.0 が 85.3、PAWS-X が 76.9、DecisionBench が 71.8 と記載されている — すべて自己申告であり、「10B 未満」という枠組みは言い逃れではなく正当な但し書きだ。モデルは 3.12B だからである。

つまり、キャリブレーションの問題は、この分野全体でそうであるのと同じ形で決着する。Liquid AIは独自の尺度で算出した数値を提示し、Microsoftは方法論を提示するが数値は示さず、どちらも独立した第三者による測定値は提供しない。あなたの導入で重要になる唯一のキャリブレーション数値は、自社のラベル付きデータで算出するものだけだ。

サービング、ライセンス、そして実際に購入しているもの

d1-3Bのレイテンシは公開されており、それがこのモデルが存在する理由です。RTX 4090では決定あたり8ミリ秒、AMD MI325Xでは9ミリ秒、64状態で毎秒475および1,106のパックドスループットを備えています。エッジハードウェアでは、Apple M5 Proで30 ms、Jetson AGX Thorで16 ms、Jetson AGX Orin 64 GBで26 ms、Orin Nanoで50 msです。Microsoft-Decision-1はレイテンシの数値を一切公開しておらず、その設計上のオプション — 従量課金制または予約済みプロビジョニングスループットのホスト型Foundry APIで、バッチ推論が無効 — は、独自のデプロイを通じて測定することを意味します。これは、取得されたドキュメントまたは提案されたアクションごとに1回呼び出されることを目的とするモデルにとって、小さなギャップではありません。

ライセンスこそ、この2つが人々を驚かせる形で分かれる点だ。Liquid AI d1-3B は lfm1.0 とタグ付けされており、Apache 2.0 ではない — Liquid の LFM シリーズの他のモデルと同じファミリーライセンスで、寛容型ライセンスにはない利用条件を伴う。あなたの法務レビューが「OpenAI互換でしがらみなし」と読み取るなら、これはそうではない。モデルを出荷した後ではなく前に読む価値がある。Microsoft-Decision-1 には重みが一切ない。これは Direct from Azure ポートフォリオ配下のホスト型エンドポイントであり、Azure 認証、統合請求、ダウンロードなしを特徴とし、ライセンスの問題はサービス契約に置き換えられている。どちらのモデルも、ベンダーが文書化している経路ではファインチューニングできない。これは意思決定モデルにとって最も鋭い制約だ — 自分のラベルに適応できないスコアラーは、誤りモードを修正できず、回避するしかないスコアラーなのである。

それらを迂回するルーティングこそが、このパターンにおいてOrcaRouterが担うべき役割であり、しかもその片側に限られます。当社はMicrosoft-Decision-1もLiquid AI d1-3Bもホストしていません。どちらもテキストを返さず、どちらも当社のカタログにはなく、確率スコアリング用エンドポイントはチャット補完の対象ではありません。当社が提供するのは、ループの生成側半分です — あなたのスコアラーが採点する回答を起草し、あなたのスコアラーが判定するフィールドを抽出し、あるいはあなたのスコアラーが承認するアクションを提案するモデルです。それは、1つのOpenAI互換キーの背後にある200を超えるモデルをプロバイダー定価で、0%のマークアップでそのまま提供するもので、したがってベンダーの価格変更は当社側で当日に反映され、自動フェイルオーバーが生成呼び出しをカバーします。そのループには、それを再試行する余分なレイテンシがありません。

2つは堅い予想で、1つは接戦ではない

選びましょうLiquid AI d1-3Bパイプラインのどこかに画像が関わるなら——スクリーンショットのトリアージ、フォームの抽出、ビジュアルQAのルーティング、モデレーターによるカメラフレームの採点。Microsoft-Decision-1 にこれを行わせることはできず、d1-3B はそのために作られ、その主張を裏付ける視覚ベンチマークも公開されています。Jetson やノートPC上で数十ミリ秒単位のエッジ推論が必要な場合にも、モデルを自社のハードウェアに置きたい場合にも、あるいは法務が読めるライセンスで十分な場合にも

を採用してくださいMicrosoft-Decision-1レイテンシ値とベンチマーク表が欠落しているということは、最初の 2 週間が統合ではなく計測になることを意味する、と受け入れてください。その上で、入力がテキストの場合、ドキュメントが長い場合、ゲートが調達（Azure 認証、統合請求、責任ある AI の評価、エスカレーション先のベンダー）である場合、あるいはトラフィックが d1-3B に記載された 16 言語を超える場合は、

唯一、まったく接戦ではないケースはマルチモーダル作業だ。そこでは、Microsoftがモデルカードに「テキストのみ」と書いた時点で、選択はすでに下されていた。