
Laya解説:1トークンも書かずに答える意思決定モデル
- openaiNEWOpenAI: GPT-6 Luna2026-09-2237知能
- openaiNEWOpenAI: GPT-6 Sol2026-09-2248知能
- anthropicNEWAnthropic: Claude Opus 5.52026-09-2258知能
- grokNEWGrok 4.72026-09-2146知能
- OrcaNEWOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 100万トークンあたり
- orcaNEWOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 100万トークンあたり
- deepseekNEWDeepSeek: DeepSeek V4.1 Flash2026-09-1040知能
- openaiOpenAI: GPT-6 Astra2026-09-0453知能77コーディング
- googleGoogle: Gemini 3.8 Flash2026-09-0241知能76コーディング
- qwenQwen: Qwen3.8 Max (0902)2026-09-0245知能76コーディング
- anthropicAnthropic: Claude Fable 5.12026-09-0153知能82コーディング
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 100万トークンあたり
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642知能72コーディング
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 100万トークンあたり
- z-aiZ.ai: GLM 5.32026-08-1845知能75コーディング
- obsidianQwen3.8 27B2026-08-1534知能68コーディング
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1236知能69コーディング
- grokSpaceXAI: Grok 4.62026-08-1244知能77コーディング
- metaMeta: Muse Spark 1.22026-08-0540知能72コーディング
- qwenQwen: Qwen3.8 Max2026-08-0345知能76コーディング
Laya で最も興味深いのは、その速さではない。あなたが提示するあらゆる選択肢が、それぞれ固有の[MASK] トークンでスコアリングされ、その確率がその 1 つの質問の選択肢に対してソフトマックスされる、という点だ。Convai Innovations は 2026 年 9 月 18 日、Laya の重みを Hugging Face 上で Apache 2.0 の下に公開した — 3 つのチェックポイント、1 つのリポジトリ、英語モデルは 4 億 2,100 万パラメータ。出力トークンはない。デコーディングループも、パースすべき JSON も、閉じ忘れる波括弧もない。状態と型付きの質問群を渡せば、1 回のフォワードパスで、名前付き選択肢の中からの選択、期待水準付きの順序スコア、あるいは文が真である確率が得られる。この設計には人々が見落とす帰結がある。答えの空間が語彙ヘッドに焼き込まれているのではなくリクエストごとに組み立てられるため、今日の午後に考案したスキーマでも再学習は不要だ。また限界もあり、プロジェクトは自らのモデルカードでそれを率直に述べている。ベースチェックポイントは型付き意思決定ベンチマークで 0.362、ランダム推測の 0.318、常に多数派クラスと答えた場合の 0.461 に対してである。Convai 自身の文言こそ頭に留めておくべきものだ —「Laya は特化させるための高速なベースであり、ゼロショットの意思決定エンジンではない」。明白な比較対象は TypeSafe AI の Jev、公開された重みも、公開されたパラメータ数も、公開されたベースモデルもないホスト型の System One モデルだ。Laya はそれに対するオープンウェイトの答えである。その答えがあなたにとって有用かどうかは、パイプラインのどちらの半分を置き換えようとしているかにほぼ完全に依存する。
レイヤが実際に何であるか、そして何でないか
まず否定的な点から始めよう。ここがほとんどの解説記事が間違えるところだからだ。Laya は LLM ではない。非自己回帰型であり、単一のフォワードパスが答えを生成し、モデルがテキストを出力することは決してない。そのレイテンシをチャットモデルのトークン毎秒と比べるのは、二つの異なる操作を比べていることになる — 一方は分類し、もう一方は生成する。段落、要約、計画、あるいは推論の連鎖が必要なら、Laya はそれを与えることはできないし、そうしようともしていない。
概要: 双方向エンコーダに決定ヘッドを上に取り付けたものです。英語版チェックポイントは ModernBERT-large — 395M パラメータ、完全にファインチューニング済み — に加えて、ゼロから学習させたヘッド(2 つの Transformer 層、オプションマーカー・スコアラー、act/escalate ヘッドで構成)を備え、合計 421M です。多言語チェックポイントはバックボーンを mmBERT-base に差し替え、22 層、256k 語彙で、合計 322M です。1 つのリポジトリに 3 つのチェックポイントが含まれており、リクエストしたものだけがダウンロードされます:
• convaiinnovations/laya — ModernBERT-large、4億2100万パラメータ、512トークンのコンテキスト、英語、ディスク上で約808 MB。
• convaiinnovations/laya-multilingual — mmBERT-base、3億2,200万パラメータ、1,024トークンのコンテキスト(エンコーダーはRoPEにより最大8,192まで対応)、100以上の言語、約2.2倍高速、約647 MB。
• convaiinnovations/laya-typed-decisions — ModernBERT-large、4億2,100万パラメータ、1,024トークンのコンテキスト長を持ち、3つの中で唯一、どこでも引用されている0.766という数値を備えているものです。
あるルーターは前段に位置し、いかなるフォワードパスが行われるよりも前に、純粋な Python でスクリプトと言語を半ミリ秒未満で検出して、リクエストごとにチェックポイントを選びます。それは便利機能ではありません。正しさのための機能であり、プロジェクト自身の証拠がその理由を示しています。英語チェックポイントはクメール語で精度 0.000 を記録する一方、信頼度 0.952 を報告します。完全に間違っていながら自信を持ち続けるモデルは、まさに信頼度ゲーティングでは救えないケースであり、そのためルーティングの判断はモデルが入力を見る前に行わなければなりません。51 言語のスイープ全体で、ルーターは 51 言語中 45 言語を利用可能にしました — ランダムの 3 倍を上回ることと定義されます — 一方、英語チェックポイント単体では 51 言語中 23 言語でした。

理解する価値のある設計上の事実:オプションごとに 1 つの [MASK] トークン
この記事から1つだけ持ち帰るとしたら、これを持ち帰ってほしい。通常の分類ヘッドでは、ラベル集合は学習時に固定される。最終層はクラスごとに1つの出力を持ち、クラスを追加するには再学習が必要になる。Layaはそうではない。各選択肢をマーカー付きのテキストとしてレンダリングし、オプション・マーカー・スコアラーがその選択肢自身の[MASK]位置からスコアを読み取る。その後、その質問に属する選択肢全体に対してソフトマックスを適用する。
したがって、回答空間はリクエスト時に定義される。選択肢を書くのはあなたで、モデルはそれらをスコアリングする。新しいスキーマに再トレーニングもファインチューニングも必要ない。なぜなら、重みの中には「請求」や「技術」をクラスとしてエンコードしているものは何もなく、あるのは状態の文脈において、レンダリングされたある選択肢を別の選択肢と比較するための仕組みだけだからだ。
それがどれほどうまく機能するかは2つの予算によって決まり、しかもそれらは共有されています。各シーケンスは、選択肢プロンプト用の予算(head_max_len、英語のチェックポイントでは192トークン、他の2つでは256トークン)と、文書用の予算(max_len の残り全部)に分割されます。呼び出し内のすべての質問は、その同じ1回のフォワードパスで回答されるため、6つの質問を含む呼び出しでも6回のモデル呼び出しにはなりません。しかし選択肢は選択肢予算を共有します。そのため、Banking77 のような77個の選択肢を持つ質問では、ラベル1つあたりおよそ3~4トークンしか割り当てられず、精度は崖から落ちるように急落します — Jev が公表した0.870に対して0.425です。修正方法は隠されるのではなく文書化されています。head_max_lenmax_len
3つのプリミティブ
Layaが行うすべてのことは、3つの質問タイプのいずれかに分類され、それぞれが異なる形を返します:
• choice — 名前付き選択肢ごとの確率、および最上位のラベルと信頼度。これはルーティングとインテント分類のプリミティブです。
• スコア — 順序付けられたルーブリック上の分布と期待レベル。これは順序プリミティブである:緊急性、フラストレーション、深刻度。
• noul — 文が真である較正済み確率(0.0~1.0)。フィッシング、解約リスク、プロンプトインジェクション。
型は、運用上重要な意味で厳格だ。ある選択式の質問は、提供していない選択肢を返すことはできない。なぜなら、採点できる選択肢は、あなたがレンダリングしたものだけだからだ。これにより、本番障害の一カテゴリ全体——でっち上げられた enum 値、切り詰められた JSON、パーサーを巡るリトライループ——が排除される。それは意味的エラーを排除するものではない。返すモデルがある。そのモデルがbilling: 0.94 を技術サポートに回すべきチケットに対して返すのは誤りであり、しかも自信を持って誤っている。型付き出力が保証するのは回答の形であり、その正しさでは決してない。
RLCD、あるいはなぜ確率は意味を持つはずなのか
ほとんどの分類器は、正しくあるように訓練される。Layaは、自分がどれだけ正しいかについて正直であるように訓練されており、その源は学習レシピにある。
この手法はRLCD——較正された意思決定のための強化学習(Reinforcement Learning for Calibrated Decisions)——と呼ばれる。方策はargmaxではなく分布を出力し、探索はロジットにゼロ平均ガウスノイズを加える。そして報酬は厳密に適正なスコアリングルール——対数スコアと球面スコアに、順序尺度の質問では順位確率スコアを加えたもの——である。その「適正」という語が効いている。厳密に適正なスコアリングルールは、期待値において、自分の真の信念を報告することによってのみ最大化される。したがって、ヘッジしたり過大に主張したりすると、指示によるのではなく構造上、報酬を失う。更新は、グループ平均ベースラインを用いたREINFORCEであり、GRPO流である。マルチターン会話では、プレフィックススライスに対してTD(λ=1.0)を用いる。
実用的な帰結として、信頼度しきい値はアプリケーションロジックを構築する上で意味のあるものになる。これは、交差エントロピーで訓練された分類器から得られるソフトマックスについては言えない主張だ。また、この主張には、プロジェクトが率直に認めている注意点がある。つまり、提供されるチェックポイントは自信過剰であり、数値を信用する前に自分のデータで温度を再フィットすることが期待されている。質問タイプと選択肢数ごとに1つの温度を再フィットすると、平均ECEは英語チェックポイントで0.466から0.081へ、多言語チェックポイントで0.314から0.106へと変わった。自動承認と人間によるレビューのどちらにするかの振り分けについて、プロジェクトが提案する開始しきい値は約0.85だ。
運営にかかる費用
レイテンシの数値はプロジェクト自身によるもので、Tesla T4 上で測定されたものです。すべてのチェックポイントが同一の実行内でバイト単位で完全に同じ質問に回答しています:
• 1つの質問 — layaでは39.5 ms、laya-multilingualでは32.8 ms。
• 5つの質問 — 84.5 ms と 40.1 ms。
• 10件の質問をバッチ処理 — 158.6 ms(質問あたり15.9 ms)、および72.3 ms(質問あたり7.2 ms)。
• 50問 — 多言語チェックポイントで771 msと337 ms、つまり1問あたり6.8 ms。
• 単一のT4でのバッチ処理スループット — 毎秒103~332問。
「Jevより50倍速い」という主張が出回っているのを見たなら、それはプロジェクトの数字ではなく、プロジェクト自身のベンチマークもそれを裏付けていません。Convaiが公開している比較は、1つの質問におけるp50レイテンシで7.8倍、32.8 ms 対 236~276 msです。この比較もまた注意深く読むべきものです。なぜなら、LayaのカードはJev側を、Convaiが一度も測定していないサードパーティ公表値としており——ConvaiにはTypeSafe APIへのアクセスがない——、さらにローカルGPUのフォワードパスを、ネットワーク往復とキューイングを含むホスト型API呼び出しと突き合わせているからです。その差のアーキテクチャ上の部分は実在します。インフラストラクチャ上の部分は、モデルの性質ではありません。
メモリについて言えば、フットプリントはチェックポイントあたり数百メガバイトで、ホストのサイズを見積もる前に知っておく価値のあるデプロイメント表があります。遅延デフォルトでは2つのチェックポイント(英語と多言語 — ルーターが自動的に選択する唯一の2つ)が常駐するため、各言語の初回ロード後は、切り替えにかかるコストは検出のみです。メモリに制約のあるマシンで Router(max_loaded=1) を使うと、言語を切り替えるたびに再ロードが発生し、CPUでは中央値7.4秒、T4では10.3秒と測定されています。Router(preload=True) はサーバー構成です。何も再ロードされず、リクエストあたりのレイテンシはGPUで32.8 ms、CPUでは193~464 msです。
正直な半分
ここがこの作品の真価が発揮される場面だ。なぜなら、Laya周辺の表面は騒がしく、制約は具体的だからである。
まず、見出しの数値はファインチューニング済みの数値です。0.766 という精度はlaya-typed-decisions、つまりそのベンチマーク自身の学習用分割でファインチューニングされたチェックポイントのものです。ベースチェックポイントはゼロショットで 0.362 と 0.342 を記録しており、これはランダムベースラインの 0.318、多数クラスベースラインの 0.461 に対して——言い換えれば、自明なベースラインを下回っています。プロジェクトはこれを覆い隠すことなく、自らの限界リストに明記しており、ファインチューニング済みチェックポイントは 0.735 という教師の自己一致の上限を上回っています。これは 4 つの狭いワークフロー(請求書処理 0.804、セキュリティインシデント 0.766、カスタマーサービス 0.764、エージェントトレースの可観測性 0.730)に取り組む 421M のエンコーダにとって、真に強力な結果です。しかしこれは特殊化に関する結果であって、ベースモデルに関するものではなく、0.766 を汎用的な能力として引用する人はカードを誤読しています。
第二に、プリミティブはどれも同じように優れているわけではない。ファインチューニング済みチェックポイントでの精度は次のとおり:noul 0.857、choice 0.733、score 0.723。プロジェクトは順序scoreを真っ向から「最も弱いプリミティブ」と呼んでおり、SST-5では0.372となっている。あなたの意思決定の対象が1~5の深刻度評価であるなら、それが初期状態のまま最も信頼する理由の少ないプリミティブである。
第三に、2つの挙動はプロジェクト自身のイシュートラッカーにバグとして文書化されており、これらを読まなければどちらも本番環境で大火傷を負います。action.act_probability はまだ使えるシグナルを運んでいません — イシュー #185 — なぜなら決定ヘッドの出力が非正規化で、エンコーダのスケールの約300倍あり、そのために act ヘッドが飽和してほぼすべての入力で1.0を示すからです。その生のロジットは正しさと逆相関しており、396件のラベル付き決定での AUROC は0.30です。判定の基準にすべきは、代わりに confidence です。これは同じ項目で AUROC 0.77に達します。別に、noul は状態ではなく自身のオプションラベルに従ってしまうことがあります — イシュー #156 — なぜなら render_options が noul のラベルを false: / true: にハードコードしており、そのラベルのペアが回答を支配して、明らかに肯定的な入力に対して自信満々の「いいえ」を返すことがあるからです。文書化されている回避策は、同じ質問を2択の choice として、中立なキーを使い、説明文に自分の yes/no の文言を入れて尋ねることです。
第四に、見落としやすく、かつ正確に述べておく価値のあるキャリブレーションの細部です。チェックポイントには choice:11+ バケット用にフィッティングされた温度 0.1006 が同梱されており、ローダーはすべての温度を [0.5, 5.0] にクランプします。このクランプはあなたにとって好都合に働いています。これほど鋭い温度では、本当に分割された分布をほぼ確実なものとして報告してしまう可能性があります。クランプのおかげで、最悪の場合でもフィットが意図したよりもやわらかい回答になり、ローダーは該当するバケットを明示し、その信頼度を未キャリブレーションとして扱うよう促す警告を出力します。読み込み時の警告は抑制せずに読んでください。
第五に、リポジトリルートは英語のみであり、英語以外での失敗の仕方は優雅ではない — だからこそルーターがあり、だからこそ推奨されるのは、laya-multilingual を英語の散文以外のすべてに使うことです。
独立した比較は、存在する場合にはベンダーの示す像よりも範囲が狭く、それを覆すものではない。独立した直接対決——sysone-bench、9つのスイートにわたる751の状態、日付は2026-09-21、バイト単位で同一の入力で実行され、比較前に質問ハッシュが同一であることが検証済み——では、Jevがトリアージ、ガードレール、モデレーション、banking77、多言語インテントで優位に立ち、LayaがAG News(0.940 対 0.910)とMNLI(0.983 対 0.867)で優位に立つ。その信頼度ゲーティングの結果こそ、私が実際に計画の前提とするものだ。信頼度0.85でのゲーティングは、Layaのトラフィックの58%を精度0.878で維持したのに対し、Jevは78%を0.917で維持した。これがトレードオフの姿である——Layaはトラフィックの自動化率がより低く、維持する部分での精度もより低く、また同社自身のルーター実行では多言語インテントが0.360から0.840へと向上する。
その周囲の表面は、異常なほど広い
重みがわずか数日前のものでしかないプロジェクトとしては、驚かされるのは統合面のほうだ。これらはすべて上流リポジトリの NandhaKishorM/laya にあり、これを書いている時点で GitHub では 19,871 個のスターが付いており、全体を通して Apache 2.0 である。
• laya-serve — Router を、TypeSafe のホスト型 Jev API と同じ POST /v1/systemone のリクエスト/レスポンス形式で公開する HTTP サーバーです。これにより、既存の TypeSafe クライアントはベース URL を変更するだけで移行できます。セキュリティ上のデフォルト設定について正直に記しておきます。これは 0.0.0.0 にバインドし、認証を行いません。ただし LAYA_API_KEY が設定されている場合はベアラートークンを要求します。より堅牢化された NixOS モジュール版も存在し、それは DynamicUser systemd ユニットの下で動作し、トークンを LoadCredential 経由で渡すため、ストアに格納する必要がありません。
• Node およびブラウザ向けの完全な TypeScript 移植版laya-ts/ にあり、さらに ONNX エージェント経路(laya.onnx_agent.ONNXAgent)も用意されており、エクスポート済みモデルを実行時に PyTorch なしで ONNX Runtime 上で動かせます。
• オプションの追加機能として提供されるMCPサーバーで、laya_predict、laya_route、laya_preset、laya_statusをツールとして公開します。
• LangChain および LangGraph の統合 — 信頼度しきい値とフォールバックを備えた条件付きエッジルーティング用の LayaRouter、および LayaGuardrail。
• 以下を備えた Nix flake: nix run .#laya-serve と services.laya-serve モジュール、4 つの compose ファイル、ドキュメント化されたクイックスタート付きの Docker イメージパス、そして約 30k 件の質問に対して無料の 2xT4 GPU 上で 4〜5 時間で RLCD ファインチューニングの全ループを実行する Kaggle ノートブック。

Apache 2.0は、これを製品に組み込んで出荷できるかどうかを決めるライセンスの詳細である。商用利用、改変、再配布を許可し、変更やファインチューニングした重みを公開することを要求しない。義務は通常の帰属表示と通知保持であり、さらにライセンスに記載されている以上の特許や商標の許諾が明示的に存在しないことである。顧客トラフィックの前段に位置する意思決定レイヤーにとって、それは、重み、アーキテクチャ、トレーニングレシピがすべて非公開である早期アクセスのホステッドエンドポイントとは実質的に異なる提案である。それが今日のJevであり、100万入力トークンあたり$0.042で、出力は無料、入力はテキストのみである。
これが実際に当てはまる構成:手前に決定ヘッド、背後にルーティングされたLLM。
内面化する価値のあるパターンは、「LLMの代わりに決定モデル」ではない。それは2段階のパイプラインであり、どちらの段階も、もう一方が何かしら苦手としているからこそ存在している。
大量・狭域・機械可読な判断には、Laya を前に置く。チケットのルーティング、意図の分類、緊急度のスコアリング、この文書がクエリに関連するかどうかの判定、このドラフトがポリシーに違反していないかの確認。これらの呼び出しには固定の回答セットがあり、1時間に数千回発生し、出力トークンがゼロの33ミリ秒のローカルフォワードパスは、生成的な往復よりもそれらに適している。次に、本当に散文、統合、長いコンテキストにわたる推論を必要とする呼び出し——ドラフト作成、説明、エスカレーション要約——には、その背後に生成モデルを置く。
そこが OrcaRouter の位置するところであり、境界については正確に述べておく価値があります。当社は Laya を提供していません。Laya はご自身で実行する 421M エンコーダーであり、その要点は、お客様のデータがすでにある場所で動作することにあります。Jev も提供していません — Jev は TypeSafe の早期アクセス用エンドポイントです。当社が担うのは、同じパイプラインの生成側の半分です。1 つの OpenAI 互換キーの背後にある 200 以上のモデルを、プロバイダー定価を 0% のマークアップでそのまま提供し、プロバイダー間で自動フェイルオーバーします。ここで重要な実用的理由は、2 つの半分の間の継ぎ目にあります。意思決定ヘッドが棄却したケースについて生成モデルに判断をルーティングし始めた瞬間、あなたには 2 つ目の統合、2 つ目の請求、そして 2 つ目の障害モードが生じます。生成側に 1 つのキーがあり、プロバイダーが劣化した場合のフェイルオーバーがあれば、意思決定レイヤーのエスカレーションパスは、2 つ目のベンダー関係ではなく設定変更になります。それは小さな主張であり、そして真実の主張です。
誰が導入すべきで、誰が待つべきか
ラベル付きデータとトレーニングループがあり、特化する価値があるほど安定した決定面があるなら、今すぐLayaを採用しましょう。Kaggleノートブックが存在するのはまさに、ファインチューニングの工程を研究プロジェクトにしないためであり、ベースチェックポイントはCPU上で約2秒で読み込まれ、ライセンスによって重みを公開することなく成果物を商用リリースできます。最も相性がよいワークロードは、プロジェクトがすでにベンチマークしているものです。チケットトリアージ、請求書処理、セキュリティインシデントの分類、ガードレールとモデレーション、エージェントトレースの可観測性です。選択式の質問はおおよそ20個以下の選択肢に抑え、本番環境でしきい値を導入する前に自分のホールドアウトデータでtemperatureをキャリブレーションし、confidenceを基準にゲートし、act_probabilityを基準には決してしないでください。
ラベル付きデータなしで、すぐにそのまま使える判断が必要なら待ってください。それが公開された際に評価対象となったベンチマークで多数クラスベースラインを下回っているベースチェックポイントは、ゼロショットエンジンではありません。また、ベンダー対独立系の数値を正直に解釈するなら、適切に運用されたホステッド判定APIのほうが現時点ではより強力なゼロショットの選択肢です。選択肢集合が大きく、ヘッド予算を調整するつもりがない場合も待ってください。順序スコアリングがすぐに信頼できる必要がある場合、または画像、音声、長文ドキュメントの入力が必要な場合も同様です — Layaはテキスト専用で、そのコンテキスト予算はデフォルトで512~1,024トークンです。これは文書全体ではなく証拠の抜粋です。
このカテゴリーを決めるのは、もはや議論の対象にならないほど十分に良いレイテンシの数値ではない。あなたが定義した決定面において正直な確率を報告し、自分のラベルで再トレーニングできる小規模モデルが、大規模生成モデルを呼び出してその出力を解析することに勝るかどうかである。Layaは、その問いのオープンウェイト版に対する、信頼できる最初の本格的な試みであり、しかもせいぜい数日前のものにすぎない。それが上記のすべてを読む正しい方法である。ベースは出発点であり、製品ではない。

