Jev 與 Laya 都把文字轉成程式可用的決策；截至 2026 年 9 月 21 日，兩者最直接的差別，是託管 API 與可自行部署的模型權重。 Laya 英文檢查點預設總長度為 512 tokens，搬移既有流程時，資料截斷與領域調校都得重新測試。
TypeSafe AI 在 9 月 15 日開放 Jev 早期存取。另一邊，Convai Innovations 的 Laya 提供開放權重，receptron 則用 ONNX Runtime 將它接到 Node.js。對工程團隊而言，選擇已經延伸到部署位置、模型維護與驗證責任。
相似的介面，不能證明相同的架構
兩者都接受狀態資料與具型別的問題，支援選擇、評分，以及回傳肯定機率的 noul。這種介面適合工單分流、內容篩選與風險標記，不會產生自由文字；選項合法仍可能選錯。
Jev 創辦人 Diogo Almeida 在發表文中描述新的模型架構、平行取樣，以及強化學習校準決策（RLCD）。公開資料足以確認產品介面與廠商描述，卻不足以重建它的完整網路。不能只因名稱相似，就斷言它使用 Laya 的編碼器或訓練實作。
Laya 的模型卡公開更多細節：英文版由 ModernBERT-large 加上決策頭組成，總計 421M 參數。決策頭含兩層 Transformer，利用選項標記進行評分，再對同一問題的選項計算機率。多語版採 mmBERT-base，總計 322M 參數。這些數字描述模型組成，不能直接換算成跨任務能力。
官方所稱單次前向運算，是把問題批次交給模型；問題增加仍會增加運算與記憶體用量。相容的問題格式能減少應用程式改寫，無法保證兩個後端有相同答案或信心門檻。
Laya 的短上下文，會先改變資料準備
| 比較項目 | Jev | Laya／receptron 封裝 |
|---|---|---|
| 執行位置 | TypeSafe 託管 API | 模型可自架，Node.js 封裝使用 ONNX Runtime |
| 已公開模型細節 | RLCD 與平行決策；完整內部網路未公開 | 英文 421M；多語 322M 參數 |
| 輸入限制 | 整體請求 64k；state 加最長問題 32k tokens | 英文預設 512；多語與 typed-decisions 預設 1,024 tokens |
| 領域適應 | 透過 state、instructions 與 criteria；無客戶專屬微調 | 可微調；檢查點與校準資料需自行管理 |
| 模型費用 | 每百萬輸入 tokens 為 $0.042；輸出免費 | 開放權重無 API token 費，仍有硬體與維運成本 |
| 授權 | 託管服務條款 | Laya 權重 Apache 2.0；receptron 封裝 MIT |
以上為 9 月 21 日查核值。Laya 的 512 tokens 不是全部留給文件：英文預設選項區預算為 192 tokens，剩餘狀態空間還受問題標頭影響。多語版編碼器支援更長序列，也不代表套件預設就以 8k 運作。
例如退款工單把關鍵要求放在長信件末尾，截斷後模型可能根本沒看到它。先量測輸入長度與截斷率，再談準確率。大量分類選項也會擠壓描述空間；必要時分成粗分類與細分類，但兩階段錯誤會相互影響，仍須測試完整流程。
官方 benchmark 先看使用哪個檢查點
Laya 模型卡在 typed-decisions 測試列出：英文基礎版準確率 0.362，專門微調版本為 0.766，多數類別基準為 0.461。較高成績來自使用該 benchmark 訓練切分進行微調的檢查點，不能視為任意新任務的零樣本能力。
它與 Jev 的比較還有另一個限制：Laya 作者明示沒有 TypeSafe API 存取權，Jev 數值引用第三方報告，樣本數與提示不同。把這些列在同一張表，仍不是同環境的直接測試。本次也沒有執行兩模型的付費或本機效能測試。
速度同樣要拆開看。receptron README 宣稱 Apple Silicon CPU 暖機後，三個問題約 140 ms；Laya 模型卡列的是 T4 GPU 上的測試。這些數字不能直接與遠端 API 往返時間相減，算成普遍加速倍數。
校準則關係到能否放心自動處理。Laya 官方承認模型可能過度自信，建議使用自己的資料重估溫度參數。替換後端時，不能照搬 Jev 原本的信心門檻；即使輸出都落在 0 到 1，與實際錯誤率的關係也可能不同。
Reddit 討論提供了哪些線索
9 月 21 日讀取的 LocalLLaMA 比較討論出現兩種使用者觀察：有人覺得 Jev 對陌生任務較容易直接使用，也有人認為 Laya 適合願意自行微調、需要本機執行的團隊。這些是自選樣本的個別心得，缺少共同測試集，不能當作社群一致結論。
另一篇 LocalLLM 開放模型討論反覆追問的是「能否直接替換」，而不只是有沒有可下載權重。這個疑問與 Laya 官方揭露的基礎檢查點限制吻合，但不代表每項工作都必須重新訓練。
討論也有人推測 Jev 是否源自 Laya 作者的研究。公開介面相似、使用相同訓練術語，都不足以證明實際承襲或抄用關係。本次查核沒有找到足以確立該因果關係的證據，因此不把指控當成選型依據，也不引用針對個人的攻擊。
實作入口先分清楚模型與封裝
Jev 的官方入口是 Playground 與 POST https://api.typesafe.ai/v1/systemone。取得帳號權限與金鑰後，可依快速入門安裝 SDK，固定模型版本並保存問題定義。這條路線適合先建立託管服務基準。
Laya 的 Python 套件提供 Router，依輸入選擇檢查點。官方提醒，若只保留一個熱模型，交替語言可能導致反覆載入；預載模型則要預留足夠記憶體。Node.js 團隊可使用 receptron 封裝：
npm install @receptron/laya
它要求 Node.js 20 以上，第一次使用下載約 1.7 GB 的 fp32 ONNX 權重。README 建議模型本身約 2 GB RAM，問題批次還需要額外空間。以下程式只示範呼叫與釋放資源；語法已檢查，未下載權重執行推論。
import { Laya } from "@receptron/laya";
const model = await Laya.load({ subfolder: "multilingual" });
try {
const result = await model.systemOne(
{ body: "同一筆訂單被扣款兩次，請協助查明。" },
{
team: {
type: "choice",
instructions: "哪個部門應先檢查這張工單？",
criteria: {
billing: "帳款、發票與退款",
support: "產品功能與故障",
other: "資訊不足或不屬於上述類別",
},
},
},
);
console.log(result.answers.team);
} finally {
await model.close();
}
中文範例依 README 設定 subfolder: "multilingual"。若省略設定，Laya.load() 預設使用英文檢查點；團隊仍須確認實際載入版本，另建繁中測試集。範例只列印建議，不應直接接上退款或停權動作。
哪種團隊先評估哪一個
沒有標註資料、任務變動頻繁，且允許呼叫外部 API 的團隊，可以先用 Jev 建立基準。它省去模型載入與硬體管理，但資料處理條款、網路延遲與服務可用性仍要納入評估。
資料必須留在本機、任務範圍穩定，而且有人能維護模型時，Laya 值得試。將資料標註、微調、校準與版本回歸測試的人力列入成本；沒有 token 帳單不等於免費運作。
實際比較時，把同一批工單分成調整集與不再修改的測試集。記錄模型版本、檢查點、輸入截斷、p50／p95 延遲、錯誤自動處理率與人工覆核量，另外分開量測冷啟動與暖機。只有在相同可接受錯誤率下，自動化比例與總成本的差異才有意義。
常見問題
Laya 能直接替換 Jev 嗎？
相似介面可以減少串接工作，無法保證能力、上下文或信心分數相同。先用現有工作負載測試，再決定是否切換。
Jev 與 Laya 都能寫文章嗎？
兩者的這類決策介面都不以自由文字生成為目的。需要解釋、摘要或回覆時，仍要接其他生成模型或固定範本。
本機執行 Laya 就不用處理資料安全嗎？
本機推論能減少把輸入交給外部 API 的需要，仍須檢查下載來源、套件、權限與紀錄內容。離線部署前應先準備模型檔案，驗證執行環境。
主要來源
Author Insight
我會先拿最容易被截斷的真實輸入做測試，再看平均準確率。若模型根本沒讀到決策依據，再精細的信心門檻也補不回來。採購 API 與自行維護模型都可以成立，前提是把錯誤處理的人力一起算進去。
