Jev 對 Laya：T4 上的 33 毫秒，以及一個隨機基線

Laya 的模型卡包含一句決定這項比較的話，而這句話是由打造 Laya 的人所寫：「Laya 是一個可快速特化的基礎，不是零樣本決策引擎。」Convai Innovations 於 2026 年 9 月 18 日發布 Laya，時間點是在 TypeSafe AI 推出 Jev 1.13（typesafe/jev-1.13）的三天後，採用 Apache 2.0 授權，權重放在 Hugging Face，並有 pip install laya 進入點。它以單次前向傳遞回答具型別的問題，不必逐 token 解碼，而這與 Jev 所下的架構賭注相同。主要宣稱是在 Tesla T4 上每次決策的 p50 延遲為 32.8 毫秒，並被描述為比 Jev 透過其託管 API 公布的 236–276 毫秒 p50 快約 7.8 倍。這項宣稱是真的，但它同時也在衡量兩件不同的事——本機 GPU 對上網路呼叫——而它背後的準確率全貌，才是應該決定你是否下載它的部分。在零樣本情況下，Laya 在 TypeSafe 的 typed-decisions 基準測試得分 0.362。隨機猜測得分 0.318。多數類別基準得分 0.461。開箱即用的 Laya，更接近隨機，而非平凡基準。新之處不在於任一模型，而在於其中一個模型能在哪裡被呼叫：2026 年 9 月 24 日，OrcaRouter 將 typesafe/jev-1.13 加入其目錄——模型本身是 TypeSafe 的，日期為 9 月 15 日——這是這項比較中近期唯一改變的事情。

Laya 實際上究竟是什麼

Laya 是以兩個檢查點的形式提供，背後由一個內建路由器將每個輸入分派到正確的那一個。英文檢查點是 ModernBERT-large，具有 4.21 億個參數與 512 個 token 的上下文。多語言變體則是 mmBERT-base，具有 3.22 億個參數，以及涵蓋 100 多種語言的 1,024 個 token 視窗。兩者都是非自迴歸式：單次前向傳遞就會回傳答案，因此沒有解碼迴圈、沒有需要解析的 JSON，也沒有任何空間可以輸出宣告型別以外的文字。最後這項特性正是 Jev 所提供的同一種結構性保證，只是從不同方向達成；對於任何曾為偶爾忘記閉合大括號的模型撰寫重試邏輯的人來說，這確實非常有價值。

Jev 是封閉的對應版本，而兩者之間真正重要的區別在於誰運行模型，而不是哪一個得分更高。TypeSafe AI 的第一個 System One 模型於 2026 年 9 月 15 日推出，是託管的——沒有權重可供下載——並且可以透過我們以 typesafe/jev-1.13 進行路由，經由 POST /v1/systemone，非串流，支援 65,536 個權杖的上下文。Laya 是另一種安排：開放 Apache 2.0 權重，由您自行運行，在您已擁有的硬體上，路徑中完全沒有端點。Jev 接受三種型別化基元——Choice（從您提供的清單中選擇）、Score（對有序評分標準進行評分），以及 Noul（一個帶有校準機率的是/否斷言）。所有問題都針對一個共享的狀態讀取進行並行評估。定價為每百萬個輸入權杖 0.042 美元，輸出計費為零，因為沒有輸出權杖需要計量。其架構、參數數量和訓練算力均未公開，TypeSafe 表示這些細節目前保密，之後可能會發表論文。

延遲主張，經妥善測量

Laya 在 T4 上的 32.8ms p50 是真實的數字，而且表現優異。與 Jev 的 236–276ms 相比的 7.8 倍比較，是需要謹慎的地方，而 Laya 自家的模型卡對原因異常誠實：Jev 的數字是第三方公佈的數據，Convai 從未自行測量過，而且這項比較是將本地 GPU 前向傳遞，與包含網路來回傳輸與排隊的託管 API 呼叫進行對比。若剔除網路因素，架構上的比較其實是兩個單次傳遞模型之間的對比：一個有 421M 參數，另一個則是 TypeSafe 從未公佈的未公開規模。

還有一個值得知道的批次處理數字：當批次大小為十時，Laya 回報每題 7.2 毫秒。這就是這個產品的形態。Laya 是為了在本機大規模運行而打造，而像 laya-mlx 這類裝置端社群移植版本則將此延伸到 Apple Silicon。關於「比 Jev 快 50 倍」的瘋傳說法，並未獲得該專案自己公布的基準測試支持；誠實的說法是：本機與雲端之間存在巨大落差，其中一部分是架構性的，另一部分則只是你的 GPU 和別人的 API 之間的差異。

準確率數字依序所說明的內容

這裡就是比較不再討喜的轉折點，值得按順序一一鋪陳，因為次序本身就有影響。

• 在 TypeSafe 的 typed-decisions 基準測試上的零樣本 —— Laya 0.362，隨機 0.318，多數類別 0.461，Jev 0.727。Laya 高於隨機水準，但低於平凡基線。

• 在該基準測試本身的訓練分割上進行微調——Laya 0.766 對上 Jev 的 0.727。Laya 勝出，而這場勝利來自一個看過該基準測試訓練資料的檢查點，這使它成為一項關於微調的陳述，而非關於基礎模型的陳述。

• Banking77 意圖分類，其中選項集龐大——Laya 為 0.425，對比 Jev 的 0.870。Laya 在超過約 20 個選項後急遽劣化，而根據文件，Jev 的 Choice 欄位可處理多達 255 個，之後才需要兩階段評分模式。

• 校準 — Laya 的平均預期校準誤差為 0.466，只有在按問題類型進行溫度重新擬合後才改善至 0.081。Jev 使用一種 TypeSafe 稱為 RLCD 的方法進行訓練，即 Reinforcement Learning for Calibrated Decisions，並且每個答案都附帶機率分佈——儘管 TypeSafe 也告訴使用者要在自己的標記資料上驗證閾值，而一項獨立審計發現 Jev 的校準因任務而異，變化很大。

這個模式毫不含糊。Laya 是強大的微調基礎，卻是薄弱的零樣本決策引擎，而且它自己也這麼說。Jev 是強大的零樣本決策引擎，但其校準仍須依每次部署檢查。這些是不同產品，有不同的價格結構，而要在兩者之間選擇，主要取決於你是否有標註資料和訓練迴圈。

成本計算的形態跟 Jev 的不一樣。

Jev 每百萬個輸入 token 為 $0.042，輸出免費，也就是每十億個 $42，而依照文件所載的 64K token 請求預算進行最大規模的呼叫，成本遠低於一分錢。一般常被引述為約 32,000 個 token 的數字，是狀態加上單一最長問題的上限，而不是請求的上限——TypeSafe 記載每次請求在狀態與所有問題合計下為 64K token，而我們自家針對 typesafe/jev-1.13 的模型卡則列出 65,536 token 的上下文。Every 的獨立測試在 37 份文件上共做出 777 項判斷，成本約為四分之一分錢。

Laya 的每次呼叫成本在邊際上為零，總量上卻不是零，而這個總量並不小。在 T4 上執行一個 4.21 億參數的模型很便宜，但仍然得佔用你一張 GPU；而真正花錢的地方，是讓 Laya 具備競爭力的微調步驟——資料標註、訓練執行、評估框架，以及針對各題型重新擬合溫度參數，讓校準誤差從 0.466 降到 0.081。對於一個永不改變的固定分類體系，那是一筆一次性的成本，只要量夠大就能回本。對於會漂移的分類體系，那便是經常性的成本，而 Jev 的零樣本基線 0.727 就划算得多了。

還有第三項成本很容易被忽略：Laya 的英文檢查點只有 512 個 token 的上下文視窗。那並不是上下文預算很小的決策模型——而是專為一個段落規模設計的決策模型。Jev 的 64K token 請求預算比它大了一百倍以上，而即便是那個，也比兩者定價所對標的生成式模型低了一個數量級。如果你的狀態是一整串客服討論，而非單一客服訊息，那麼這兩個模型的視窗都不是你該據以最佳化的限制條件。

部署問題才是真正的差異

Laya 最強而有力的論點不是延遲，而是 Hugging Face 上以 Apache 2.0 授權的權重，意味著決策永遠不會離開你的基礎設施，而端點也永遠不會有速率限制。對於根據醫療紀錄、法律文件或客戶帳戶歷史所做的路由決策而言，這不是一種偏好——而是決定性因素，而且無論價格多高，任何代管端點都贏不了這個論點。TypeSafe 自家的首頁仍將 Jev 描述為處於早期存取階段，而該廠商的文件也指出，其速率限制會動態調整，且可能未經通知而變更。

反駁論點在於你放棄了什麼。Jev 未公開的更大架構正在做 Laya 的 4.21 億參數做不到的事：0.727 對上 0.362 的零樣本差距，以及 0.870 對上 0.425 的 Banking77 差距，兩者都是在衡量在你開始訓練之前，模型內部究竟蘊含了多少知識。Laya 的答覆是：那些知識由你自己透過微調來提供，而在一個狹窄的固定領域上，這個答覆確實行得通——0.766 的微調結果就是證明。

決策層在實際技術堆疊中的位置

這兩個模型都不會生成文字，因此兩者都不是任何工作流程的全部。兩者所對應設計的模式是雙模型架構：一個負責發出型別化呼叫的決策層，加上一個處理需要散文、程式碼或說明那部分的生成式模型。這樣的分工以往意味著得再簽一份供應商合約，因為決策的那一半無法與生成的那一半從同一組金鑰呼叫。現在可以了。Jev 可經由我們以 typesafe/jev-1.13 路由，透過 POST /v1/systemone 呼叫——非串流、65,536 個詞元的上下文、每百萬輸入詞元 $0.042，輸出計費為零。我們自己對該路由為期七天的服務紀錄顯示 p50 為 151 毫秒，那是我們自家硬體上自家流量的數字，而非基準測試。這是網路量測，與上方 32.8 毫秒的本地前向傳遞是不同的量測。Laya 則維持另一種安排：你自己執行的開放權重，我們不代管，也無須代管。該模式的生成那一半正是我們所涵蓋的：200 多個模型藏身在一個相容 OpenAI 的金鑰之後，以供應商定價原價轉手、0% 加成，因此供應商調價當天，我們這邊就會同步生效。雙模型架構不需要第二份供應商合約就能測試——決策那一半是如此，生成那一半亦然——而有了自動容錯移轉，在你判斷這個便宜的決策層校準得是否足以據以自動化的同時，生成路徑也不會變成單點故障。

判決

如果你有固定且狹窄的分類體系、有標註範例，而且隱私或延遲要求排除了託管 API，那麼 Laya 是更站得住腳的選擇，微調後的數字也支持這一點。如果你需要這個決策開箱即用、如果你的選項集超過二十個類別，或者狀態長度超過一個段落，Laya 自家的模型卡就告訴你它不是適合那份工作的產品——而當有人拿 7.8 倍延遲這個數字來跟你說嘴時，0.362 的零樣本分數對比 0.461 的多數類別基線，才是你該放在心上的數字。

這兩者的共同點比它們的差異更有用。兩者都能消除源自輸出格式的那一類錯誤，卻對源自判斷的那一類錯誤毫無作為。兩者都會附上機率，而兩者也都沒有已發表的可靠性圖表，讓你不必自行查核就能信任。在以任一方進行自動化之前，先用自己的標註案例測試其校準——延遲早已商品化，而信心值才是必須在每次部署中逐一掙得的部分。