Laya対Deciderの比較用に生成されたタイトルカードで、この記事自身のサブタイトルと、どちらの側の数値がベンダー報告でどちらが第三者によるものかを示すフッター行を備えています。
Engineering & Research

Laya vs Decider:421Mエンコーダー対35B混合モデル

著者

Gideon Frost

公開日

最新モデル · 20すべてのモデルを見る
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

LayaとDeciderはどちらもオープンウェイトの非自己回帰型意思決定モデルで、型付きの質問——提供されたリストからの選択、順序付きルーブリック上のスコア、はい/いいえの確率——に単一のフォワードパスで回答し、サイズのスペクトルの両端に位置する。Convai Innovationsは2026年9月18日にLayaをApache 2.0の下でリリースした:英語向けの512トークンウィンドウを持つ421MのModernBERT-largeエンコーダ、100以上の言語をカバーする1,024トークンウィンドウを持つ322MのmmBERT-base多言語チェックポイント、およびスクリプトを検出して適切な方へディスパッチするルーター。MapikaのDeciderファミリーは、小規模な生成ベース上のdecider-0.8bとdecider-2bから、約3Bのアクティブパラメータを持つ35Bのmixture-of-expertsであるdecider-35b-a3bまで及ぶ。どちらも無料でダウンロードでき、どちらもテキストではなく確率を返す。両者が互換でない理由は、ほとんどの解説が最初に持ち出す精度の数値ではない。

2つの家族、1つの建築的な賭け

A screenshot of the Laya project page, showing the Apache 2.0 licence, the 421M ModernBERT-large English checkpoint with a 512-token window, the 322M mmBERT-base multilingual checkpoint with a 1,024-token window, the 32.8ms p50 per decision on a Tesla T4, and the pip install entry point.

共通の前提は、意思決定にデコードループは不要だというものだ。「このチケットは返金リクエストか?」と尋ねられた生成モデルはトークンを出力せねばならず、トークンを出力した瞬間、200回に1回、波括弧を忘れるときのためのパース、スキーマ検証、リトライ経路を自分で抱え込むことになる。Laya と Decider はどちらもそれを回避し、単一のフォワードパスから直接答えを読み取る——Laya は双方向エンコーダから、Decider はプロンプト内の専用の回答スロットにおける、文字付き選択肢トークンのロジットから。

類似点が終わるのはそこだ。Layaは言語ルーターの背後にある2つの小型エンコーダであり、それが421Mと322Mのパラメータ数で、512トークンの英語ウィンドウと1,024トークンの多言語ウィンドウを実現している。Deciderは生成的バックボーンを保持し、その上にリードアウトを追加する。decider-2bはQwen3.5-2B-Baseを教師あり微調整したもので、続いてライブブラウザタスクとexact games上でのキャリブレーション考慮型強化学習パスを行う。一方、decider-35b-a3bはルーティングされたエキスパートを凍結し、Muonでブロック行列を訓練する。実用的な帰結は、Deciderが言語モデルの世界知識を受け継ぎ、Layaはそうではないということだ。もう一つの帰結は、Deciderが言語モデルのフットプリントを受け継ぐということだ。

A screenshot of the decider-2b model card on Hugging Face, showing the Qwen3.5-2B base, the text-classification pipeline tag, the English-language tag, and the decision-model and calibrated tags for the Mapika Decider family.

Mapika自身のドキュメントでは、decider-2bはB300上でbf16、バッチサイズ1、CUDAグラフやコンパイルなしで、決定あたりの中央値18ms、decider-35b-a3bは同じ構成で41msとされています。GH200上で、約230トークンのサポートチケットのコンテキストと3~5個の入力された質問を扱う場合、同じプロジェクトはeagerで49ms、CUDAグラフとtorch.compileで4.0ms、バッチ32で毎秒約1,370件の決定を報告しています。これらはプロジェクト自身の記事に掲載されたベンダー公表の数値であり、独立した測定ではありません。Layaの主要な数値も同様にベンダー公表です。Tesla T4上で決定あたりp50 32.8ms、バッチサイズ10で質問あたり7.2msです。

較正の問い、それに二つのプロジェクトが異なる規模で答える

キャリブレーションは、意思決定モデルにとって最も重要な数値です。なぜなら、確率を返すことの狙いは、下流の誰かがそれに対してしきい値を設定することにあるからです。ここもまた、Laya と Decider を直接比較すると誤解を招くところです。

Laya は自身のモデルカードで期待較正誤差 0.466 を提示して出荷されており、そのカードには、質問タイプごとに温度を再フィットするとこれが 0.081 になると明記されている。これは異例なほど正直な開示であり、また出荷されるチェックポイントが較正済みの成果物ではないことも意味する。すぐに使える状態で得られる数値は 0.466 だ。

Deciderはまったく別の評価尺度で報告している。Decision Index——Jevのすべてのオープン再現を132,422リクエストにわたって実行したオープンなリーダーボード——は、decider-35b-a3bを、Jevの59.5に及ばない54.3で総合4位に位置づけ、32エントリ中で最もキャリブレーションが良いものとして、キャリブレーション誤差3.1ポイント、95%以上の表明信頼度での誤答率0.4%を報告している。decider-2bは8.8ポイントと0.9%を報告している。これらはリーダーボードが公表した数値であり、Indexの10ビンECEにおける3.1ポイントは、Layaが独自の評価で示した0.466と同じ測定ではない。それらを表で並べるのは、厳密さを装ったリンゴとオレンジの比較という誤りだろう。言えるのは、Deciderの作者は第三者リーダーボードで測定されることを選び、Layaの作者は自ら最も弱いキャリブレーション数値を公表することを選んだということだ。どちらも相手側のハーネスによる監査を受けていない。

それぞれがどこで優位に立つか、項目ごとに

• バックボーン — Laya: ModernBERT-large 421Mエンコーダ、双方向。デサイダー: Qwen3.5生成ベース、0.8B~35B-A3B。

• 言語 — Laya:ルーター背後の322M多言語チェックポイント経由で100以上。Decider:英語のみ、制限として明記。

• コンテキストウィンドウ — Laya:英語512トークン、多言語1,024。Decider:最大32kの入力を受け付け、v6世代で16kまで学習し、30kまで検証済み。

• 選択肢セットの上限 — Laya: 選択肢がおよそ20個を超えると急激に劣化し、Banking77では0.425(Jevは0.870)。Decider: 2~255個の名前付き選択肢に対するChoice、2~10個の記述されたレベルに対するScore。

• ゼロショット精度 — Laya: typed-decisions ベンチマークで 0.362、多数クラスベースラインの 0.461 を下回る。Decider: ゼロショットの数値としては公表されておらず、代わりにプロジェクトがタスク固有の結果を報告している。

• キャリブレーション — Laya: ECE 0.466(出荷時)、質問タイプ別の温度再調整後は0.081。Decider: 35BのDecision Indexで3.1ポイント、32エントリ中最高。

• 推論 — Laya:設計上、存在しない。決定器:明示されているとおり、存在しない — それは推論器ではなく、パターンマッチングの読み出しである。

• ライセンス — 両方とも Apache 2.0。

Decider を選ぶ前に知っておく価値のあるもう 1 つの詳細: このプロジェクトは、長い JSON 配列から位置で 1 件のレコードを選ぶのは弱いケースだと警告しており、レコードはキーで指定することを推奨しています。これは、実際に動かしてみて初めて分かる種類の制限です。

どちらか一方を運用するのに、あなたにかかるコスト

Layaのコストプロファイルは、ファインチューニング前提のプロジェクトだ。モデルは小型で、低スループットの用途ならラップトップのCPUでも動かせるが、出荷されている英語チェックポイントのゼロショットスコアは自明なベースラインを下回っている。つまりLayaを採用することは、ラベル付きデータセットを構築し、ファインチューニングし、質問タイプごとにtemperatureを再フィッティングするという仕事を引き受けることを意味する。その見返りは、一度それをやってしまえば、成果物は4億2100万パラメータで、T4上で数十ミリ秒で回答するということだ。Convai自身がファインチューニングしたlaya-typed-decisionsチェックポイントは、ベンチマークの学習用分割で0.766に達している——この数字はベースモデルよりもファインチューニングについて多くを語っており、モデルカードにもそう明記されている。

Decider のコスト特性はサービングの判断です。あなたはどれだけの GPU を借りるかを選んでおり、このファミリーは本物の調整つまみを与えてくれます。2B なら 18ms、それに対して 35B-A3B なら 41ms で、より大きなモデルは、小型モデルにはない GPQA、GSM8K、CRUXEval、MMLU における知識と推論の余裕を買うことになります。タスクが狭く、ラベルが固定されているなら、decider-2b が安価なマシンです。タスクがモデルに物事を知っていることを求めるなら、Mixture の分を支払うことになります。

OrcaRouterが適する場面 — そして適さない場面

Laya も Decider も OrcaRouter 上のホスト型モデルではありません。重みをダウンロードして自分で実行するものであり、ここでの話はそれを変えません。変わるのはこのパターンのもう半分です。型付きの意思決定モデルがアプリケーション全体であることはほとんどありません。チケットを読み、スレッドを要約し、あるいはその意思決定がゲートする返信の下書きを作る何かが必要です。その半分は生成系の呼び出しであり、まさに OrcaRouter が作られた領域です — 1 つの OpenAI 互換キーの背後に 200 以上のモデルがあり、プロバイダーの定価をそのまま 0% のマークアップで提供されるため、ベンダーの値下げは次回の契約更新時ではなくその日のうちに請求に反映されます。Laya のチェックポイントをフロンティアモデルの出力に対してファインチューニングしている場合でも、トリアージには decider-2b、難しい 4% には大型モデルへとルーティングしている場合でも、生成側を 1 つのエンドポイントにまとめておけば、意思決定側と生成側で 2 つの契約と 2 つの SDK を持つ必要はありません。自動フェイルオーバーは、大型モデルのほうがダウンしてしまうケースをカバーします。

どちらを選ぶべきですか

入力が多言語で、ラベルが少数で、レイテンシ予算がそこそこのハードウェアで数十ミリ秒であり、ファインチューニングする覚悟があるなら、Layaを選ぼう——なぜなら、そうせざるを得なくなるからだ。入力が英語で、モデルに何らかの世界知識を意思決定に持ち込ませる必要があり、学習パイプラインを回すよりもモデルサイズを選ぶほうを好むなら、Deciderを選ぼう。選択肢セットが20ラベルを超えるなら、採用を決める前にLayaのBanking77の数値を読もう。入力が位置で指定する長いJSONドキュメントなら、採用を決める前にDeciderの明記された制限を読もう。

これに実際に決着をつける比較——両モデルをバイト単位で完全に同一の入力、同じプロンプト、同じ選択肢の順序、同じしきい値スイープで評価する——は、まだ存在しない。それが存在するまでは、誠実な立場はこうだ。Layaにはより優れたコスト曲線があり、Deciderにはより優れたキャリブレーションの証拠がある。そしてどちらも十分に初期段階にあるため、あなたが自分のデータで構築する評価は、どちらのプロジェクトの公表数値よりも価値があるだろう。

A generated two-column scoreboard comparing Laya and Decider across backbone, languages, context, zero-shot accuracy, calibration and serving, with a footer reading "Laya figures per its own model card; Decider per Mapika and the Decision Index."