インターフェースは同じでも、モデルは異なる
両システムは状態に対して choice, score と noul の質問に答えます。返す確率は、アプリケーションのコードでしきい値判定、組み合わせ、エスカレーションに使えます。文章作成を目的としたモデルではありません。
Jev は TypeSafe AI の非公開・ホスト型 System One モデルです。Laya は ModernBERT-large と mmBERT-base エンコーダーに判断ヘッドを加えた Apache-2.0 のモデル群です。Jev のパラメータ数とアーキテクチャは公開されていないため、Laya が「Jev のアーキテクチャを再現する」という主張は、現在の根拠を超えます。
機能比較
| 項目 | Laya | Jev |
|---|---|---|
| アクセス | ダウンロード可能なウェイトと Python パッケージ | 早期アクセスのホスト型 API |
| ライセンス | Apache 2.0 | 商用サービスの利用条件 |
| 公開されている構造 | 322M の mmBERT-base または 421M の ModernBERT-large と判断ヘッド | 公開されていない |
| 導入 | ローカル、プライベートクラウド、自分のサーバー | TypeSafe が管理するエンドポイント |
| カスタマイズ | ウェイトとファインチューニング手順を公開 | ウェイトへの公開アクセスなし |
| 入力価格 | API 料金はないが、計算資源と運用は有料 | TypeSafe によると入力 100 万トークンあたり $0.042 |
| choice の最大選択肢数 | 既定のヘッド予算では大きなラベル集合で性能が低下 | 最大 255 選択肢。多選択肢には 2 段階経路を使用 |
| 言語への対応 | 専用多言語チェックポイント。51 言語の公開評価 | 比較可能な公開多言語ベンチマークは見つからない |
| コールドスタート／ネットワーク | チェックポイント読み込みに数秒かかることがある。ウォーム推論はローカル | ローカル読み込みはないが、毎回ネットワークとサービスの遅延がある |
上記の Jev 入力価格と 255 選択肢制限の出典： TypeSafe の System One と Jev の発表。2026年9月25日に確認しました。購入前に TypeSafe の最新価格と制限を確認してください。
正確度：主な数値だけでは分からない
Laya リポジトリは、ワークフロー専用チェックポイントが 2,000 件の型付き判断で正確度 0.766 を達成したと報告しています。引用された Jev 結果は 0.727 です。AG News と DAIR Emotion でも優位を報告します。有用な兆候ですが、普遍的な順位表ではありません。
同じ報告で、二つの基本 Laya チェックポイントは typed-decisions で約 0.34〜0.36 と、多数派ベースライン 0.461 を下回っています。0.766 はベンチマークの学習分割でファインチューニングした結果です。根拠が支持するのは特化の基盤としての Laya であり、万能なゼロショット判断器ではありません。
Banking77 では Jev の公開結果 0.870 が、既定ヘッド予算の Laya の 0.425 を明確に上回ります。Laya の選択肢は固定プロンプト予算を共有するため、数十個指定するとラベルごとに数トークンしか残りません。予算増加、候補絞り込み、階層化は助けになりますが、追加の実装判断です。
遅延：ローカル推論と API は別の計測
Laya リポジトリは Tesla T4 上の単一質問で約 33〜40ms、バッチ化で質問あたりの処理効率向上を報告します。独立した Apple Silicon 評価ではウォーム MLX 呼び出しが約 7.6ms でした。Jev の計測は通常ネットワーク往復を含み、Laya が集めた資料では約 236〜276ms、小規模な中国語チケット評価では 588ms です。
Laya はリアルタイムのローカル処理に魅力がありますが、構造だけの速度比較ではありません。公平な運用比較には、Laya のモデル読み込み、GPU または端末の費用、並行処理、ご自身と Jev エンドポイントの距離を含める必要があります。
校正：自動化前に検証する
Laya は適正スコアリングルールに基づく報酬で学習しますが、学習目的だけで新しい全ドメインの校正は保証されません。配布基本チェックポイントの過信と、未使用データへの温度適合による期待校正誤差の大幅低下を報告しています。
独立した中国語チケット 40 件の評価には、Laya が誤ったラベルを高い確信で選ぶ例がありました。一般的な結論には小さすぎる標本ですが、導入時の正しい実践を裏づけます。自分のラベル付き実データで信頼性曲線を測ってから、自動化のしきい値を設定してください。
どちらを選ぶべきか
Laya を優先する条件
- 入力を自分の環境の外に出せない。
- ラベル付きのドメイン事例を集められる。
- ウォーム状態の低遅延が重要。
- 実行環境を調査・適応・再配布したい。
- 選択肢集合が通常は小さい。
Jev を優先する条件
- モデル基盤より API を望む。
- 初期状態で大きな選択肢集合が必要。
- ファインチューニング用データを得る前に動く必要がある。
- 管理型の版管理を好む。
- ホスト型サービスへ状態を送ってよい。
実用的な第三の選択：カスケード
大量処理では Laya を先に実行し、低確信や対象外の事例を Jev または大きな LLM に送ります。明確な判断をローカルに保ちつつ、より強い代替経路を確保できます。しきい値は固定した検証集合から学ぶ必要があり、0.8 が「高そう」だから選ぶものではありません。
Laya をローカルで実行
ネットワーク呼び出しなしで型付き分布を返します。
検証済みの条件を確認
ラベル付きデータで信頼できたタスク型と確信度領域だけを受け入れます。
残りをエスカレーション
曖昧または未対応の事例を Jev、LLM、人のレビュアーへ送ります。
一次出典： Laya リポジトリ, Laya ベンチマーク報告, TypeSafe の Jev 発表。独立した小規模評価： laya-jev-lab。この独立ガイドは、いずれのプロジェクトとも提携しておらず、承認も受けていません。