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

Jared Palmer 於 2026 年 9 月 20 日發布 Kev，距離 TypeSafe AI 推出 Jev 過了五天，而重要的數字不在基準測試表裡，而是在 README 裡：整個東西在 Modal 上花了大約 95 美元的 H100 運算時間，再加上用於產生評估資料的 3 美分 Jev API 呼叫費用。Kev 採用 Apache-2.0，可自架，並有三種規模，建構在開放的 Qwe​n3.5 基礎權重上——大約 0.8B、4B 與 9B——搭配 rank-16 LoRA 適配器，以及鎖在凍結基礎模型上的指標頭，而不是從頭打造的決策模型。它完全對應 Jev 的型別化決策 API：Choice、Score 和 Noul，且接近到可與 TypeSafe 自家的 Python SDK 相容。Jev 方面，於 2026 年 9 月 15 日推出，是 TypeSafe AI 的封閉式、託管式 System One 模型，會傳回帶有校準信心度的型別化答案，完全沒有文字，且從未公開其架構、參數量、訓練運算量或權重。因此，這項比較其實不是真正的模型比較。它是在測試：用一台二手筆電的價格，在一個下午內重現 Jev 之後，Jev 的價值還剩下多少。這兩個模型都不是新的——Jev 1.13（typesafe/jev-1.13）是 9 月 15 日的發布版本，而 Kev 在五天後跟進——但這項比較最近確實有一件事改變了：2026 年 9 月 24 日，OrcaRouter 將 Jev 1.13 加入其目錄，因此這對組合中的決策半邊，現在能用與生成半邊相同的金鑰來回答，而不只是透過供應商自家的端點。

基準測試實際上怎麼說

重點是 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 每百萬輸入詞元的價格是 $0.042，輸出免費——這是 TypeSafe 自家價目表上的費率，也是我們 typesafe/jev-1.13 模型卡所載明的費率——這種便宜程度，若以單次呼叫來算，確實難以超越。它是託管式 API，而 TypeSafe 自家首頁至今仍稱其處於早期存取階段；那是廠商自己的說法，而過去擋在它後面的候補名單已經沒了——TypeSafe 在 2026 年 9 月 21 日移除了它，如今其模型文件改為公布服務限制本身：每個帳號每秒 100,000 個詞元、每秒 40 次請求，並會動態調整，且可能隨時變更，恕不另行通知。Kev 則是你下載回來的權重。第一千萬次分類的邊際成本，就是你自己的電費。

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

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

• 沒有第三方速率限制，沒有封閉式存取，也沒有棄用風險。TypeSafe 自家的文件保留隨時調整那些已公布限制的權利，這與你自己磁碟上的檢查點有實質差異。本機檢查點沒有這種條款。

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

• 上下文上限可由你改變。Jev 文件所載的請求預算是 64K 個 token，其中 32,000 是狀態加上單一最長問題，而非另計的額度，且 Choice 欄位上限為 255 個選項。Kev 繼承 Qwe​n3.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 秒；而且在一次呼叫中加入問題幾乎不會改變延遲，因為每個問題都是針對同一次共享的狀態讀取並行評估。對於那項廠商宣稱，有一個經過實測的對照，而那是我們的，並非 TypeSafe 的：在我們的 typesafe/jev-1.13 模型卡投入服務該模型的七天期間，自 2026 年 9 月 24 日起，請求中位數耗時 151 毫秒，第 95 百分位數為 247 毫秒。那是單一路由的服務紀錄，而不是基準測試。Kev-9B 在 H100 上進行單次前向傳遞時，也會處於相同的數量級，但這種比較無論從哪個方向來看都不是同類比同類：在負載下、共用 GPU 上的自架 9B，與託管端點的延遲並不相同，而託管端點也不同於你自己機架裡的一台機器。可以毫不含糊地說的是，兩者都夠快，足以在代理迴圈中用於每一回合，而且 Kev 的延遲取決於你能掌控的硬體，而不是別人向你承諾的服務等級。

對複製品的誠實解讀

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

這同時也是還不該把正式生產路徑押在兩者中任何一個身上的理由。如果你正在評估 Jev，明智的做法是先試用而不做出承諾——而自 2026 年 9 月 24 日起，這件事可以在我們的 key 上完成：OrcaRouter 以 typesafe/jev-1.13 提供 Jev 1.13，透過它在各處使用的同一個 POST /v1/systemone 端點與相同的非串流請求格式呼叫，支援 65,536 個權杖的上下文，每百萬輸入權杖收費 0.042 美元，輸出則完全不計費。決策層與生成層如今位於同一個帳戶：一個與 OpenAI 相容的 key 背後有 200 多個模型，以供應商定價原價轉售、0% 加成，並具備自動容錯移轉。由廉價的決策層分流流量、生成模型處理其餘部分的雙模型架構，可以在我們這邊測試，無須再簽第二家供應商合約；而若決策元件在你的資料上校準不佳，容錯移轉路徑正是防止它演變成事故的關鍵。

判決

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

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