Laya vs Nimble：対照的データ 対 より高速なエンコーダ

LayaとNimbleは、どのように構築されたかの説明に最も力を入れた著者らによる2つのオープンウェイト意思決定モデルであり、その説明は難しさがどこにあるかについて一致していない。Convai Innovationsは2026年9月18日にLayaをApache 2.0でリリースした — 421MのModernBERT-large英語チェックポイント、100以上の言語をカバーする322MのmmBERT-base多言語チェックポイント、両者の間のサブミリ秒ルーター、そしてTesla T4上で公表されている1意思決定あたりのp50 32.8msである。Bespoke LabsはNimbleをQwen3.5-9Bに対するLoRAファインチューニングとしてApache 2.0で構築し、それを「オープンソースのJev」と表現している — TypeSafe AIのJevに触発されているが、その重みも、そのアーキテクチャも、その出力の蒸留も使っていない。Convaiの精度問題への答えは速度とファインチューニング可能なベースである。Bespokeの答えは訓練データである。この違いは、主要な表に現れる3ポイントの精度差よりも、はるかに注目に値する。

各プロジェクトが実際に打ち出している主張

Layaの主張はアーキテクチャに関するものだ。厳密な意味で非自己回帰的である — 双方向エンコーダ、デコードループなし、解析すべきJSONなし、宣言された型の外にテキストを出力する余地はない。その構造的保証は、別の方向から到達したものであるが、Jevが提供するものと同じであり、たまに閉じ波括弧を忘れるモデルのためにリトライロジックを書いたことがある人にとっては真に価値がある。コストは、512トークンのウィンドウを持ち、その背後に生成的事前学習がない421Mのエンコーダは、あまり多くのことを知らないということだ。Convaiはモデルカードでそう述べている：「Layaは特化するための高速なベースであり、ゼロショットの意思決定エンジンではない。」

Nimbleの主張はデータに関するものだ。Bespokeの手法はコントラスティブ・キュレーションであり、チームの以前のBespoke-MiniCheckの研究から応用されたものだ。つまり、1つの「焦点となる事実」だけが異なり、正解ラベルが反転するような、ほぼ同一の2つの例を書く。このパイプラインには4つの明示されたステップがある — 決定ルールが本当に異なる答えにつながり得るかを確認し、最大8語を変えてペアを構築し、別々のモデル呼び出しと各文を削除するチェックで両方の例を検証し、コードでラベルを生成しつつ、ラベルが実際に異なるペアだけを残す。目標はより多くの例ではなく、より鋭い例だ。どの証拠が決定を変えるべきかをモデルに学ばせる。それは、小型意思決定モデルがなぜ失敗するかについての異なる理論であり、もう1つの精度の数値よりも興味深いものだ。

公表された数値が実際に裏づけているもの

Nimbleは324件のホールドアウトサンプルで参照ラベルとの一致率90.12%を報告しており、それに対してJevは93.21%、未チューニングのQwen3.5-9Bベースは66.36%、未チューニングの27B Qwen3.8は84.88%です。H100では中央値約106ms、64GBのM5 Proでは中央値444msを報告しています。これらはBespoke自身のハーネスによる数値です。324サンプルの評価セットは慎重に重み付けすべき部分であり、プロジェクト自身がその理由を述べています。サンプルは10の学習ソースファミリーのうち6つにまたがり、人間によるレビューなしにモデルによって生成・検証されたものであり、したがって未知のカテゴリへの汎化は証明されていません。モデルがデータキュレーション手法で学習され、その後同じキュレーション済み分布のホールドアウト分割で評価される場合、その精度数値は手法の内部整合性についての記述であり、あなたのトラフィックについてのものではありません。

Layaの数値は反対の端から来ている。TypeSafeのtyped-decisionsベンチマークでは、ゼロショットで0.362を記録する — ランダムは0.318、多数派クラスのベースラインは0.461 — そしてベンチマーク自身のトレーニング分割でファインチューニングすると0.766となる。Banking77（77ラベル）では、Jevの0.870に対して0.425を記録し、これはその多選択肢の天井を最も鋭く示している。4ラベルのAG Newsでは、Jevの0.910に対して0.950を記録し、6ラベルのDAIR Emotionでは、0.480に対して0.595を記録する。そのキャリブレーション誤差は0.466で出荷され、質問タイプごとの温度再調整後には0.081に低下する。Mars-baseの緊急メッセージ100件による第三者テストでは、Jevが100/100、Layaが53/100であった。そして独立したエージェントツール呼び出し評価では、Layaは危険な呼び出しに対して100%の拒否再現率を達成したが、それはすべてにフラグを立てることによってのみであり、安全上の勝利を装った精度の失敗である。

二組の数値を並べてみれば、正直な読み方は、それらは別々の対象で測定されたということだ。Nimbleの90.12%は、自社がキュレーションした参照ラベルとの一致率だ。Layaの0.362は、同社が構築していないベンチマークだ。どちらの数値もそのままでは通用しない。

キャリブレーション：両プロジェクトが異例なほど率直になる唯一の場

二つのプロジェクトが精神において最も近く、結果において最も隔たっているのは、まさにこの点である。

BespokeのREADMEは、Nimbleの確率は提供された候補に対するソフトマックス正規化されたロジットであり、校正された正解率ではないと明示的に警告している — 0.9は90%正しいという意味ではない。正解が候補の中にない場合でも、そのうちの1つが勝ってしまうため、「上記のいずれでもない」オプションを追加することを推奨している。13のサブセットにまたがる新しい3,880件の評価では、Jevは13サブセット中11で報告された校正誤差がより低く、13中10でブライアスコアがより低かった。したがって、同様のラベル一致は同様の確率品質を意味するものではなく、Bespokeもそう述べている。

Convaiの開示はまさに鏡像だ。0.466という期待キャリブレーション誤差がカードに記載され、その隣には、質問タイプ別の温度再フィッティングが生み出す0.081がある。どちらのプロジェクトも、追加作業なしにその信頼度に基づいて行動できるモデルを出荷しているわけではない。両方とも、そのことを文書で明言している。信頼度しきい値 — 0.95超は自動リリース、0.7未満はエスカレーション — を構築しているなら、両著者のドキュメントは同じことを伝えている。まず自分のラベル付きデータでしきい値をフィットさせよ。

次元ごとの比較

• バックボーン — Laya: ModernBERT-large 421Mエンコーダ、双方向、生成的事前学習なし。Nimble: LoRAファインチューニングを施したQwen3.5-9B、生成的ベースを保持。

• 言語 — Laya：322M 多言語チェックポイントを通じて 100 以上。Nimble：英語。

• プロンプト予算 — Laya: 英語512トークン、多言語1,024。Nimble: プロンプトあたり最大2,048トークン、フラットスキーマのみ、enumはフィールドあたり最大26個の選択肢。

• 速度 — Laya: T4 で p50 32.8ms、10 件ずつバッチ処理した場合 1 質問あたり 7.2ms。Nimble: H100 で中央値約 106ms、M5 Pro 64GB で 444ms。

• ハードウェア — Laya: CPU、CUDA、Apple MPS。MLXポートでは1ギガバイト未満の常駐。Nimble: 記載の数値はBF16 CUDA GPUによるもので、MLXとCUDAの両パスをサポート。

• 報告された精度 — Laya: ゼロショット 0.362、ファインチューニング済み 0.766、Banking77 では 0.425。Nimble: Jev の 93.21% に対して、厳選された 324 件のホールドアウトサンプルで 90.12%。

• 手法 — Laya: アーキテクチャを優先し、デプロイごとにファインチューニング。Nimble: 対照的データキュレーションをレシピとして公開。

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

そのリストにある2つの制約は、採用を決める前に二度読む価値があります。Nimbleのenumあたり26オプションという上限と、プロンプトの2,048トークンという天井は、性能劣化ではなくスキーマ上の厳格な制限です——タクソノミーに40個のラベルがある場合や、プロンプトに長い文書が含まれる場合、Nimbleの精度がどうであれ、Nimbleは適切なツールではありません。また、Nimbleは各フィールドを独立に評価するため、「Aが真ならBは偽でなければならない」といったフィールド間の整合性ルールは、モデルではなくコード側に置く必要があります。

なぜデータレシピのほうがより移植性の高い成果物なのか

精度の表が見落としているNimbleの主張はこれだ。Bespokeは重みだけでなく、キュレーション・パイプラインも公開した。あなたの意思決定問題に固定されたタクソノミーがあり、ルールを書き下せるなら、対照的手法は、好みのベースモデルが何であれその上で、独自のデータと独自のフォーカス・ファクトを使って実行できるものだ。9B LoRAは製品であると同時に、この手法のデモンストレーションでもある。

Layaのポータビリティは性質が異なり、相補的です。小規模で、CPUで動作し、ONNXとMLXのポートが存在するため、LayaはGPUもネットワークもないプロセスの中に組み込めるモデルです。サードパーティのブラウザエージェントベンチマークでは、Layaは50タスク中0タスクを完了し、33回の試行で早々に完了を宣言しました。ただしベンチマークの著者らは、Layaがナビゲーションではなく、サポートチケット、請求書、エージェントトレースのレビューといった判断業務向けに訓練されたと注記しています。この結果は判決ではなく適用範囲の表明として読むべきであり、それは両プロジェクトの位置づけとも一致します。これらは一般的なエージェントではなく、特定のクラスの意思決定のためのコンポーネントなのです。

Laya も Nimble も、OrcaRouter 上のホスト型モデルではありません。どちらも自分で実行する重みであり、本記事のいかなる記述も、当社がそれらを提供しているという主張として受け取られるべきではありません。ここでルーティング製品の話が出てくるのは、あらゆる意思決定モデルのアーキテクチャでこの話が出てくるのと同じ理由です。意思決定モデルは 1 回の呼び出しに答えるだけで、その周囲のアプリケーションには依然として文章が必要です。Nimble で下書きがコンプライアンスに適合しているかをスコアリングし、Laya で例外をルーティングするパイプラインであっても、下書きを書くための生成モデルは必要になります。その生成側を 1 つの OpenAI 互換エンドポイントに置いておくこと——200 以上のモデル、プロバイダーの定価を 0% のマークアップでそのまま提供、ベンダーの値下げが当日に反映され、プロバイダーをまたいだ自動フェイルオーバーも備わっている——というのは、生成層の契約に触れることなく意思決定層を差し替えられるということです。

評決、そしてそれを変えるかもしれない実験

分類体系が固定的で狭く、入力が英語で短く、GPU があり、モデルと同じくらいデータレシピも欲しいなら、Nimble を選びましょう。多言語入力、40ms 未満の予算、あるいは GPU をまったく使わないプロセスが必要なら Laya を選びましょう — そして、最初からファインチューニングのコストを見込んでおいてください。ゼロショットのチェックポイントは自明なベースラインを下回っており、モデルカードにもそう明記されているからです。

決着をつける実験は、実トラフィック上でのペア評価だ。同じ入力、同じオプションセット、同じ信頼度しきい値を使い、人間のラベルに対して評価し、それぞれについて信頼性ダイアグラムを作成する。Nimble 自身のドキュメントは、その確率が正解率ではないと警告しており、Laya のカードは再フィッティング前のキャリブレーション誤差が 0.466 であると報告している。したがって、そのダイアグラムこそが、どのモデルを本番環境の前に置くべきかを実際に教えてくれる成果物だ。どちらのプロジェクトも自らのダイアグラムを公開しておらず、相手のダイアグラムも公開していない。しきい値を設定する前に、自分のデータでそれを作成せよ。