Laya vs Kev：ローカル意思決定モデルのための2つのレシピ

Laya 対 Kev の比較で最も有用な数字は領収書だ。ジャレッド・パーマーは、Modal 上の H100 時間でおよそ 95 ドル、加えて評価データ用の API 呼び出しに約 3 セントをかけて Kev ファミリーを訓練し、重みとともにそのレシピを公開した。Convai Innovations は Laya で別の道を選んだ。2026年9月18日、TypeSafe AI の Jev の3日後にリリースされ、Apache 2.0、Hugging Face 上の重み、pip install layaのエントリーポイント、そして訓練パイプラインはない — 421M の ModernBERT-large 英語チェックポイント、322M の mmBERT-base 多言語チェックポイント、そして両者を選び分けるルーターである。Kev は 0.8B、4B、9B の3つの小規模モデルからなるファミリーで、それぞれが凍結されたベースに rank-16 LoRA アダプターと小さなポインターヘッドを加えたものだ。どちらも型付きの質問に1回のフォワードパスで答えるもので、どちらもテキストを生成しない。両者の選択は、実際にはどちらの成果物を所有したいかという選択だ。チェックポイントか、レシピか。

各プロジェクトが実際に出荷しているもの

Layaは推論を提供する。英語版チェックポイントは512トークンウィンドウの双方向エンコーダであり、多言語版は1,024トークンウィンドウで100以上の言語をカバーし、約2倍の速さで動作する。ルーターはスクリプトを0.5ミリ秒未満で検出する。これが答えるのは選択、スコア、そしてnoul——リストからの1つ選び、順序付きルーブリック上の期待レベル、そしてある主張が真である確率の較正済み推定値だ。3つ目のチェックポイント、laya-typed-decisionsがある。これは、typed-decisionsベンチマークの訓練分割でファインチューニングされた同一の421Mバックボーンだ。Convai自身のモデルカードには、すべてのLayaの数値をどう読むべきかを規定すべき一文が載っている。「Layaは特化のための高速なベースであり、ゼロショットの意思決定エンジンではない。」

Kevはある手法を公開している。リポジトリにはdecision-v7が記録されている：10の公開データセットから抽出した10,000件の例、896件の生成ポリシー例、および60の生成ルール構造から構築した1,680件の例に対して2エポック。ヘッドは提供された各選択肢を、質問のdecideトークンに対してスコア付けし、その結果にソフトマックスを適用する。Qwen3.5チェックポイントはアテンションマスクを無視する再帰的Gated DeltaNet層とアテンションを混在させているため、各質問は独自の行として実行され、共有状態は一度計算されてキャッシュされる——これによりモデルは、質問ごとに新たなプリフィルを支払うことなく、質問同士を分離したままにできる。KevはTypeSafeの公開/v1/systemone契約をミラーしているため、既存のTypeSafe SDKクライアントはベースURLを変更するだけでローカルのKevサーバーを指すことができる。READMEには、訓練にJevの出力は一切使用されていないと記載されている。

その2つの故障モードは別物であり、それこそが核心だ

どちらのモデルも、知識を必要とするタスクではJevに敗れるが、その敗れ方は異なる緩和策を要する。

Laya について公表されている弱点は、入力の形に関するものだ。TypeSafe の typed-decisions ベンチマークでは、ゼロショットで 0.362 を記録する。ランダム推測の 0.318、多数派クラスベースラインの 0.461 に対してであり、偶然の水準に近く、自明な答えからは遠い。選択肢がおよそ20を超えると崩壊する。Banking77 では 0.425 で、Jev の 0.870 に対してだ。順序に十分敏感で、ある第三者テストでは選択肢の順序を単純に反転させただけで精度が 13.75 ポイント低下し、同一回答率は 42.5% になった。さらに、出荷済みチェックポイントは無効な temperature を伴って届く——ライブラリはインポート時に警告を出す。つまり、カードに記載のキャリブレーション値、期待キャリブレーション誤差 0.466 は、再フィットする前に実際に得られる数値だ。質問タイプごとに再フィットすれば 0.081 まで改善するが、それはあなたが行う作業であり、ダウンロードがやってくれる作業ではない。公表されている多言語の失敗例は、全文を読む価値がある。非ラテン文字では、英語チェックポイントは壊滅的に過信しており、クメール語の例では平均信頼度 0.952 で精度 0.000 を示している。

Kev の公表されている弱点は知識と算術に関するものだ。Kev-9B は自身のロックされた新規ソーステストで 0.837 を記録し、4B は 0.832、0.8B は 0.668 であり、dev スプリットでのドメイン外では約 0.822 で、Jev の 0.857 と対比される。差が開くのは世界知識が必要とされる場面だ。MMLU は約 70% に対し Jev は 90%、MMLU-Pro は 0.515 に対し 0.840、日精度の日付演算は 60% に対し 93% である。ラベルが固定された狭いルーティング集合では Kev が勝つ。サポートチケットのルーティング評価では Kev-9B が 0.952、Jev が 0.897 だった。しかし著者は明言している。これは自身のハーネスであり、Jev の訓練データは非公開であり、したがって統制された比較は構成不可能だと。Kev はまた、新しいソースに対しても過信を続ける。KEV_TEMPERATURE=2.0 を設定すると、プロジェクト自身のテストで確信度の高い誤りが 8.7% から 4.4% に減少した。これはデフォルトが安全な設定ではないことを示している。

実用的に言い換えると、Laya の失敗はあなたのオプション設定とプロンプトの整形が引き金で、ファインチューニングと再フィッティングによって直す。Kev の失敗は事実を必要とする質問が引き金で、モデルをルーティングと分類に限定し、知識に依存する呼び出しは別に任せることで直す。どちらの修正も設定フラグではない。

彼らに仕えるために必要なこと

• ハードウェア — Laya：421M/322Mエンコーダ。低スループットならCPUでも十分実用的で、Appleシリコン上のMLXポートでは常駐メモリ1ギガバイト未満。Kev：0.8B～9Bで、9BにはBF16対応のCUDA GPUが必要。またQwen3.5アーキテクチャはCUDAおよびROCm上でflash-linear-attentionを必要とする。

• レイテンシ — Laya：Tesla T4 で1決定あたり p50 32.8ms、バッチ10で1質問あたり7.2ms。Kev：32GB Mac 上の bf16 の4Bモデルで、入力された5つの質問に約300ms、H100 ではおよそ40ms。

• 上限 — Laya: 英語では512トークンのウィンドウ、多言語では1,024。Kev: 1～255個の選択肢からの選択、2～255レベルにわたるスコア、384のトレーニング状態トークン、サービング時は8,192。

• サーバー — Laya: プロセス内Python、さらにコミュニティによるONNX、Go、Apple MLXへの移植版。Kev: 127.0.0.1にバインドされた認証なしのローカルサーバー、npm SDK、およびLangChainとLlamaIndexのアダプター。

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

見出しの数字には現れない運用上の注意が2つある。Kevのサーバーは設計上、単一リクエストかつ認証なしだ。これはローカルサイドカーであり、外部に公開するものではない。また、KevのMacでのレイテンシはH100でのレイテンシより実質的に悪い。高速なDeltaNetカーネルがまだMLX向けに存在しないからだ。これはまさに、「ローカルで動く」という主張を「適切なハードウェア上でローカルに動く」という主張に変えてしまう類の詳細である。

パターンの生成的な半分

これらのモデルはどちらも、特定の1つの呼び出しを置き換えるために存在します。それは、ラベルや確率を得るためだけに行っていたLLM呼び出しです。それらは、実際に文章が必要な呼び出しを置き換えるものではありません。Kev-9Bを使ってチケットをルーティングするサポートシステムでも、スレッドを要約し返信を起草するモデルは依然として必要であり、そのモデルがポインターヘッド付きの9B LoRAになることはありません。

OrcaRouterが担うのはその継ぎ目であり、これらのどちらかをホストしているという主張ではありません。LayaもKevも当社のモデル一覧には載っていません——それらはダウンロードする重みだからです——そうでないかのように示唆すれば、この記事は誤解を招くものになります。一覧に載っているのは、1つのOpenAI互換キーの背後にある200以上の生成モデルで、プロバイダーの定価を0%のマークアップでそのまま提供します。Kevを使ってリクエストが3つの要約ティアのどれに属するかを判断したり、Layaを使って下書きの回答が許容できるかをスコアリングしたりしているなら、両方のループの生成側は、2つ目の契約と2つ目のSDKではなく、自動フェイルオーバーを備えた1つのエンドポイントです。ルーティングDSLは、意思決定モデルのアーキテクチャに最も自然に適合する部分です。安価なモデルと高価なモデルを1回の呼び出しに組み合わせ、意思決定モデルの出力にブランチを選ばせることができます。

次に見るもの

証拠の欠落は両者にとって同じであり、どちらのプロジェクトによっても埋められることはないだろう。誰も、同じプロンプト、同じ選択肢順序、同じ信頼度閾値スイープを用いて、バイト単位で同一の入力でLayaとKevを実行したことはない。Layaの主要な勝利は自前のハーネスから得られたものであり、Kevのほぼ同等という主張はその作者のハーネスから得られたものである。Jevのキャリブレーションがタスクによって大きく変動すること——隠されたポリシーの優先度タスクで44.7%の精度と0.325の期待キャリブレーション誤差——を明らかにしたキャリブレーション監査は第三者によるものであり、LayaもKevもその扱いを受けたことはない。誰かがそれを行うまでは、上記の数値が利用可能な最良のものであり、互いに比較できるものではない。

今日決めるなら：すでに借りているGPU上で今週中に動くルーティングモデルが欲しいならKevを選び、それが物事を知らないという点を受け入れよう。入力が多言語であるか、ハードウェア予算がラップトップならLayaを選び、後からの最適化ではなくプロジェクトの一部としてファインチューニングを見込んでおこう。どちらにせよ、本番トラフィックの手前に信頼度しきい値を置く前に、自分のラベル付きデータで測定すること——両プロジェクトとも、それぞれのドキュメントでそうするよう勧めている。