Laya vs Kev：本地決策模型的兩種配方

在 Laya 與 Kev 的比較中，最有用的一個數字是一張收據。Jared Palmer 在 Modal 上以大約 95 美元的 H100 運算時間訓練了 Kev 系列，外加約三分錢的 API 呼叫費用來取得評估資料，並將配方連同權重一起公開。Convai Innovations 則以 Laya 走了另一條路：於 2026 年 9 月 18 日發布，比 TypeSafe AI 的 Jev 晚三天，Apache 2.0 授權，權重放在 Hugging Face，一個pip install laya 進入點，而且沒有訓練流程——一個 421M 的 ModernBERT-large 英文檢查點、一個 322M 的 mmBERT-base 多語言檢查點，以及一個在兩者之間挑選的路由器。Kev 是三個小模型的家族，分別為 0.8B、4B 和 9B，每一個都是凍結的基礎模型加上 rank-16 LoRA 適配器與一個小型指標頭。兩者都能在一次前向傳播中回答具型別的問題，而且都不生成文字。在它們之間做選擇，其實就是在決定你想擁有哪一種產物：一個檢查點，還是一份配方。

每個專案實際上正在交付什麼

Laya 提供推論功能。英文檢查點是具備 512 個 token 視窗的雙向編碼器；多語言版本則以 1,024 個 token 的視窗涵蓋 100 多種語言，執行速度約快上一倍；路由器在不到半毫秒內就能偵測出文字系統。choice、score和noul——從清單中挑選一項、在有序評分表上的預期等級，以及某項主張為真的校準後機率。還有第三個檢查點，laya-typed-decisions，它是在 typed-decisions 基準測試訓練分割上微調的同一組 421M 主幹。Convai 自家的模型卡上寫著一句話，這句話應該主導你解讀每一個 Laya 數字的方式：「Laya 是個適合用來特化的快速基礎，而非零樣本決策引擎。」

Kev 發布了一套方法。該儲存庫記錄了 decision-v7：在取自十個公開資料集的 10,000 個範例上跑兩個 epoch，另有 896 個生成的策略範例，以及由 60 個生成的規則結構建構而成的 1,680 個範例。該 head 會針對問題的 decide token 為每個提供的選項評分，並對結果取 softmax。由於 Qwen3.5 檢查點混合了注意力與會忽略注意力遮罩的循環 Gated DeltaNet 層，每個問題都各自以獨立的一列執行，共享狀態只計算一次並加以快取——這正是模型能讓各問題彼此隔離，又不必為每個問題付出一次全新 prefill 成本的方式。Kev 仿照 TypeSafe 公開的 /v1/systemone 合約，因此既有的 TypeSafe SDK 用戶端只要變更基礎 URL，就能指向本機的 Kev 伺服器。README 指出，訓練中未使用任何 Jev 輸出。

這兩種失效模式並不相同，而這才是真正的關鍵

這兩個模型在需要知識的任務上都輸給了 Jev，但它們落敗的方式需要不同的緩解措施。

Laya 已發表的弱點與輸入的形態有關。在 TypeSafe 的 typed-decisions 基準上，其零樣本得分為 0.362，而隨機猜測為 0.318，多數類別基線為 0.461——更接近隨機，而非那個顯而易見的答案。一旦超過大約二十個選項，它就會崩潰：在 Banking77 上為 0.425，而 Jev 為 0.870。它對順序足夠敏感，以至於在一項第三方測試中，單純翻轉選項順序就使準確率下降 13.75 個百分點，留下 42.5% 的相同答案率。而且隨附的檢查點帶有無效的溫度參數——程式庫在匯入時發出警告，這意味著模型卡上的校準數值，即期望校準誤差 0.466，是你重新擬合前實際得到的數字。針對每種題型重新擬合可將其降至 0.081，但那是你得做的工作，不是下載檔會做的工作。有一個已發表的多語言失敗案例值得完整閱讀：在非拉丁文字上，英文檢查點災難性地過度自信，其中一個高棉文範例顯示準確率 0.000、平均信心 0.952。

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-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 GB。Kev：0.8B 到 9B，9B 需要 BF16 CUDA GPU，而 Qwen3.5 架構在 CUDA 與 ROCm 上需要flash-linear-attention。

• 延遲 — Laya：在 Tesla T4 上，每次決策的 p50 為 32.8ms，batch 10 時每題為 7.2ms。Kev：在 32GB Mac 上以 bf16 執行 4B 模型，五個輸入問題約需 300ms，在 H100 上約需 40ms。

• 上限 — Laya：512 個 token 的英文視窗，多語言為 1,024。Kev：可從 1–255 個選項中選擇，分數涵蓋 2–255 個等級，384 個訓練狀態 token，推論服務時為 8,192。

• 伺服器 — Laya：處理程序內的 Python，外加社群 ONNX、Go 與 Apple MLX 移植版。Kev：一個繫結至 127.0.0.1、無需驗證的本機伺服器，附有 npm SDK，以及 LangChain 與 LlamaIndex 配接器。

• 授權條款 — 兩者皆採用 Apache 2.0。

有兩點操作上的備註並未出現在那些頭條數字中。Kev 的伺服器在設計上僅處理單一請求且未做身分驗證——它是本機的 sidecar，不是讓你對外暴露的東西。而且 Kev 的 Mac 延遲明顯比其 H100 延遲更差，因為目前還沒有適用於 MLX 的快速 DeltaNet 核心，而這正是那種會把「可本機執行」的說法，變成「可在正確硬體上本機執行」的說法的那種細節。

該模式的生成性那一半

這兩個模型的存在，都是為了取代某個特定呼叫：你純粹為了取回標籤或機率而進行的 LLM 呼叫。它們不會取代那些你確實需要成段文字的那些呼叫。一個使用 Kev-9B 來分派工單的支援系統，仍然需要一個模型來摘要討論串並草擬回覆，而那個模型不會是帶有指標頭的 9B LoRA。

這正是 OrcaRouter 所處的接縫，而不是對代管其中任何一方的宣稱。Laya 和 Kev 都不在我們的模型清單上——它們是你自行下載的權重——若文章暗示並非如此，就會造成誤導。清單上的是 200 多個生成式模型，只要用一組與 OpenAI 相容的金鑰就能取用，價格為供應商定價，零加成轉嫁。如果你用 Kev 來判斷某個請求該歸入三種摘要層級中的哪一種，或用 Laya 來評估某份草稿答案是否可接受，那麼這兩個迴圈的生成端就是同一個端點，具備自動容錯移轉，而不需要第二份合約和第二套 SDK。路由 DSL 是最能自然契合決策模型架構的一塊：把便宜模型和昂貴模型組成單一呼叫，讓決策模型的輸出挑選分支。

接下來要看什麼

兩者證據上的缺口是一樣的，而且這個缺口不會由任何一個專案來填補。沒有人用位元組完全相同的輸入、相同的提示、相同的選項排序，以及相同的信心閾值掃描，來跑過 Laya 和 Kev。Laya 的亮眼勝績來自它自家的測試框架；Kev 近乎並駕齊驅的說法來自其作者的測試框架；而那項發現 Jev 的校準會因任務而劇烈變動的校準稽核——在一項隱藏政策的優先級任務上準確率 44.7%、期望校準誤差 0.325——是第三方做的，而 Laya 和 Kev 都不曾接受過那樣的檢驗。在有人這麼做之前，上述數字是現有最好的，但它們彼此之間無法互相比較。

如果你今天就要做決定：想要這週就能在你已經租用的 GPU 上跑出可用的路由模型，就選 Kev，並接受它有些事就是不懂。如果你的輸入是多語言的，或你的硬體預算是台筆電，就選 Laya，並把微調編列為專案的一部分，而不是日後的優化。無論選哪一個，在把信心閾值放到正式流量前面之前，都要用你自己標註的資料來衡量——這兩個專案都在各自的文件裡這樣告訴你。