Jev 對決 Kev：一個在客服工單上擊敗 Jev 的 95 美元微調

Jared Palmer 於 2026 年 9 月 20 日發布 Kev，時間點就在 TypeSafe AI 推出 Jev 的五天後，而真正重要的數字並不在基準測試表裡。它在 README 中：整件事在 Modal 上花了大約 95 美元的 H100 機時，外加三分錢的 Jev API 呼叫費用，用於產生評估資料。Kev 採用 Apache-2.0 授權、可自架，並以 Qwen3.5 基礎權重建構出三種尺寸——大約 0.8B、4B 與 9B——搭配 rank-16 LoRA 適配器，以及一個外掛於凍結基礎模型上的指標頭（pointer head），而非從零開始打造的決策模型。它完全比照 Jev 的型別化決策 API：Choice、Score 與 Noul，相容程度足以搭配 TypeSafe 自家的 Python SDK。至於 Jev，則是在 2026 年 9 月 15 日推出，作為 TypeSafe AI 封閉式、託管的 System One 模型，會回傳帶有校準信心的型別化答案，且完全不附任何文字，並從未公開其架構、參數數量、訓練算力或權重。因此，這項比較實際上並不是模型比較。它測試的是：Jev 的價值有多少能在一個下午內、以一台二手筆電的價格被複製出來後依然成立。

基準測試實際上怎麼說

重點是 Kev 已經很接近，而且在某一項狹窄任務上勝出。在 Kev 鎖定的新來源測試集上，Kev-9B 得分 0.837，Jev 則是 0.857。在橫跨 900 張工單的客服工單路由任務——scienthoon 資料集——Kev-9B 得分 0.952，Jev 則是 0.897，這是唯一一項已發表結果中，開放復現勝過它所復現的模型。Kev 也在一些邏輯辨識任務上略占上風。在 SemiF 決策集，一個 144 題的結構化題組中，Jev 以 0.965 對 Kev-9B 的 0.917 拿下勝利。

Kev 輸的地方，就輸得很慘。域外準確率：Kev-8B 為 79.6%，Jev 則是 85.7%。MMLU：70% 對 90%。MMLU-Pro：0.515 對 0.840。日期運算（精確到日）：60% 對 93%。這個模式相當一致——在標籤集小、領域固定的狹窄路由與分類任務上，Kev 還算有競爭力，但只要是需要世界知識或多步算術的任務，它就徹底崩潰，因為世界知識並不存在於一個凍結的小型基礎模型上的 rank-16 適配器裡。

那些數字每一個都來自 Kev 自己的測試框架，或是來自第三方追蹤工具，而 Palmer 的 README 明白寫著這並非受控比較——Jev 的訓練資料並未公開，因此根本無從建立受控比較。README 也指出，訓練時並未使用任何 Jev 的輸出。這兩項免責聲明都屬於會讓數字更可信、而非更不可信的那一類：發布這項比較的人，正是那個告訴你它無法證明什麼的人。

花 $95 就能得到、但無論出多少錢都無法從 Jev 獲得的東西

成本比較正是這兩項產品完全失去可比性的地方。Jev 每百萬個輸入 token 收費 0.042 美元，輸出免費，這種便宜程度以單次呼叫來說確實難以匹敵——但它是代管式的搶先體驗 API，得排隊等候名單，而且 TypeSafe 表示速率限制可能未經通知就變更。Kev 則是你自行下載的權重。第一千萬次分類的邊際成本，就是你自己的電費。

由此可得出四件事，而它們都與基準測試分數無關。

• 資料不會離開你的基礎架構。Jev 是託管端點；你傳送給它的每一筆狀態資料——支援工單、日誌行、醫療紀錄——都會送往 TypeSafe。Kev 在你自己的 GPU 上執行，對於受監管的工作負載而言，這不是偏好，而是決定性因素。

• 沒有速率限制、沒有等候名單、沒有遭淘汰的風險。TypeSafe 自家的文件指出，速率限制可能未經通知即變更。本機檢查點沒有這類條款。

• 你可以微調它。Kev 是一個可供特化的基礎，而產生它的 LoRA 配方是公開的。如果你的路由分類體系有 40 個類別，卻沒有通用模型能處理得好，你可以用你自己的標籤來訓練——這正是 Palmer 的做法，成本以數十美元計，而不是動用一個 ML 團隊。

• 上下文上限由你自行調整。Jev 文件記載的請求額度約為 32,000 個 token，而 Choice 欄位的上限是 255 個選項。Kev 沿用 Qwen3.5 的視窗，其規模遠比前者大，而且選項上限是你自家服務堆疊的實作細節，並非供應商的限制。

Jev 仍擁有而 Kev 沒有的東西

校準這項主張，正是無法乾淨移轉的那一項，而它卻是 TypeSafe 推銷說詞的核心。Jev 的訓練方法被 TypeSafe 稱作 RLCD——Reinforcement Learning for Calibrated Decisions，即校準決策強化學習——這個方法最佳化的是讓信心值保持誠實，而不是讓答案更討人喜歡。每個 Jev 的答案都會附上一組涵蓋各選項的機率分布，因此你的程式碼可以設定閾值：落在最高區段就自動採取行動，中段則標記出來，最低區段則向上呈報。

Kev 產生相同的型別形狀與相同的機率輸出，因為 API 刻意保持相容。那些機率是否經過校準是另一個問題，而誠實的答案是：沒有人發表過這兩個模型中任何一個的可靠度圖。一份獨立的校準稽核報告指出，Jev 在一項隱藏政策優先級任務上取得 44.7% 準確率，期望校準誤差為 0.325，這顯示 Jev 的校準會隨任務劇烈變化，而非普遍適用的性質——而 TypeSafe 本身也告訴使用者，要用自己的已標註範例來測試信心閾值，而不是信任已發布的行為。

Jev 還有另一點不同：它並非以 Qwen3.5 訓練。一個搭配 rank-16 適配器的 9B 模型有知識上限，而 MMLU-Pro 上 0.515 對 0.840 的差距，正是這道上限的具體顯現。如果你的路由決策偶爾需要知道某個東西是什麼，那麼 Jev 更大、未公開的架構正承擔著 Kev 的適配器做不到的工作。

延遲與部署形態

Jev 有記錄的端到端延遲為 70–500 毫秒，而 TypeSafe 自家的比較中，前沿 LLM 呼叫則為 3–329 秒；而且在一通呼叫中加入問題幾乎不會改變延遲，因為每個問題都會針對同一份共享的狀態讀取平行評估。在 H100 上的 Kev-9B 進行單次前向傳遞時，會落在相同的數量級，但這個比較無論從哪個方向看都不是同類比較：在負載下、共享 GPU 上的自架 9B，其延遲不同於託管端點；而託管端點也不同於你自己機櫃裡的一台機器。可以毫不含糊地說的是，兩者都夠快，可用於代理迴圈中的每輪使用，而且 Kev 的延遲取決於你可控制的硬體，而不是別人向你承諾的服務等級。

對複製品的誠實解讀

Kev 本身存在，就是關於 Jev 的一項證據，而這值得特別指出。一個封閉模型的行為，可以由一個人在五天內、花 95 美元，在公開基礎權重上加以近似，這就透露出它的優勢有多少來自架構，又有多少來自訓練資料與推論服務。這並不代表 Jev 容易打造——API 介面很容易複製，校準則不然。但這確實意味著，護城河不是介面；任何為生產路徑評估 Jev 的人，都應該把以下可能性納入考量：微調一個開放基礎模型，就能以一小部分的投入，讓他們達到大部分目標。

這也正是為什麼還不該把正式生產路徑押在兩者之中任何一個上的理由。如果你正在評估 Jev，明智的做法是試用它，但別對它做出承諾——而 OrcaRouter 並不提供 Jev，因為 TypeSafe 的模型屬於早期存取，且使用自己特有的請求格式。我們真正涵蓋的，是這些決策模型所處工作流程中的生成式那一半：用一組與 OpenAI 相容的金鑰即可取用 200 多個模型，並以供應商定價原價轉嫁、零加成，同時具備自動容錯移轉。由廉價的決策層負責分流流量、生成式模型處理其餘部分的雙模型架構，可以在我們這邊測試，無須再簽一份供應商合約；而若決策元件最後被證明在你的資料上校準得很糟，容錯移轉路徑正是防止這件事演變成事故的關鍵。

裁決結果

如果你的決策任務範圍狹窄、屬於固定領域、量大且隱私敏感，Kev 是現今更站得住腳的選擇，而且差距還很明顯——你擁有權重，你掌控資料路徑，你可以用自己的標註進行微調，而且在客服工單路由上，9B 檢查點在 Jev 自己公布的數字上就已經勝過 Jev。如果你的決策任務需要世界知識、多步驟算術，或是一個你打算據以自動化運作的信心值，Jev 那更大且未公開的模型及其 RLCD 訓練確實在發揮作用，而 Kev 的適配器無法取代其中任何一項。

兩份比較都沒能解決的一件事就是校準，因為沒有人發表過任一個模型的可靠性圖。在你針對任一方進行自動化之前，先用自己的標註案例測試這一點——信心值是這兩項產品中必須在每次部署中逐一掙得的部分，而速度則是早已商品化的部分。