Jev 1.13 解釋：為何模型以標籤而非句子作答

Jev 1.13 (typesafe/jev-1.13) 不是聊天模型，而要理解它最快的方法，就是別再像讀其他每一份規格表那樣去讀它的規格表。TypeSafe 於 2026-09-15 推出它，作為該公司稱之為 System One 模型這個類別的第一個成員：你交給它一段狀態和一組具名問題，它就為每個問題回傳一個具型別的答案——一個取自你提供清單的標籤、一個落在你定義量表上的等級，或是一個附帶機率的真／假值。沒有散文、沒有程式碼、沒有解釋。這不是一篇發布報導。模型本身出自 2026-09-15，已問世十五天，落在本部落格撰寫所涵蓋的七天窗口之外，因此它並不因自身發布而挣得一篇頁面。窗口內真正發生的事，是 OrcaRouter 於 2026-09-24 將 typesafe/jev-1.13 加入自家目錄，並在 https://www.orcarouter.ai/models/typesafe/jev-1.13 開設 Jev 1.13 模型卡——這是 Jev 首度能透過第三方閘道呼叫，而非僅能經由 TypeSafe 自家端點，也是 TypeSafe 以外任何人所發布的第一批實際服務資料。那才是值得一讀的變化：這個模型在原本無法執行的地方變得可以執行了。

這項變更的實際樣貌既小又具體。在 2026-09-24 之前，採用 Jev 意味著多一層供應商關係——一個 TypeSafe 帳號、一組 TypeSafe 金鑰、一張 TypeSafe 發票，以及一套必須依循撰寫的專用請求格式。在那之後，Jev 與堆疊其餘部分共用同一組金鑰：用一個 API 存取 200+ 個模型，0% 加價（供應商定價原樣傳遞，因此廠商降價這裡當天就能生效），而該模型可在 POST /v1/systemone 以 typesafe/jev-1.13 存取。你仍然要以它自己的格式呼叫——該端點不是 OpenAI 聊天補全路由，若假裝是，會得到 404 而非一個決策——但你簽署的合約與你輪替的金鑰，就是你已經擁有的那同一份。

Jev 是什麼樣的模型？

TypeSafe 的發布貼文用一句話說得明白：「我們的第一個公開模型是 Jev，即日起以早期試用形式開放。」貼文接著把這個模型定位為「前沿智慧的函式呼叫：非結構化狀態輸入，型別化的機率性決策輸出」。這是對該介面相當中肯的描述，而且十分重要，因為幾乎所有對 Jev 的錯誤期待，都源自把它當成小型語言模型來評估。它不是小型語言模型。它是一個具有固定輸出文法的決策模型，而這套文法就是產品本身。

這個介面恰好有兩個輸入。狀態是要評判的材料：一封電子郵件、一張支援單、一行日誌、一筆 JSON 記錄、一組遊戲座標。問題則是一組具名項目的映射，每個項目都帶有一個類型、自己的指示，以及——針對兩種結構化類型——其準則。每個問題都會對照同一個狀態進行評估，而答案會以單一結構化 JSON 酬載的形式回傳。TypeSafe 的文件將這些問題描述為並行且獨立地執行，並提出兩項源自該設計而非調校的主張：新增問題幾乎不會改變回應時間，且新增問題不會造成上下文腐化，因為每個問題都是被獨立評判，而不是在先前問題的下游被評判。

TypeSafe 自家的設計指引值得一再重申，因為它是對這個模型用途最清楚的說明。讓每個問題保持單一且範圍明確——「一種知識極其淵博的人能在幾秒鐘內做出的判斷」。如果某個決策需要長時間推理，或確實結合了數個彼此獨立的因素，就把它拆成幾個獨立問題，再在你自己的程式碼中重新組合。他們的例子：不要用一個「為這份新創簡報評分」的提示詞，而是分別詢問市場規模、技術可行性與差異化，然後套用你自己的權重。這件事之所以重要，是因為如此一來，權重就存在於一個你能修改的係數中，而不是存在於一個你必須重寫的提示詞裡。

就一位思考風險的工程師所關注的每個層面而言，這個模型都是封閉的。Jev 的架構、參數量、訓練算力與權重皆未公開。TypeSafe GitHub 組織底下沒有任何權重儲存庫——那裡十一個公開儲存庫是工具、SDK、工作流程，以及三個不相關的 fork，而它們沒有一個是該模型。

「Typed」就是整個產品。

OrcaRouter 模型卡公布了三個基本操作，而且重要的是，也公布了每個操作的限制。你向 Jev 提出的每個問題都恰好屬於三種形式之一：

• noul — 一種真/假判斷，會以經過校準的機率回傳，而非單純的布林值，因此「可能為真」和「確定為真」是可區分的值。

• 選擇 — 從最多 255 個帶標籤的選項中挑選一個，每個選項各自帶有準則文字，讓模型知道你的標籤之間有何區別。

• {{1}}score{{/1}} — 依 2–10 個等級的有序量表進行評分，並以所提供的等級定義作為評分標準。

那項限制的後果是：沒有東西可以從自然語言文字中解析出來，也沒有任何東西可以對照你希望模型遵循的結構描述來驗證。TypeSafe 的發布文章對這項保證說得異常直接：其圖表中的「0%」結構描述不符數字「並非實證而來。結構描述比對是有保證的，因此我們可以放心地把 0% 加進圖表中。」當你的答案空間是你所提供的封閉集合時，回傳的值要嘛落在集合內，要嘛就不是來自模型——不存在第三種結果，讓模型寫出形狀錯誤卻看似合理的東西，而你的正規表達式默默接受了它。

這三種類型也正是審查者無法像評估聊天模型那樣評估 Jev 的原因。沒有可比較的 MMLU-Pro 分數，沒有可閱讀的寫作樣本，也沒有可檢查的推理軌跡。唯一有意義的問題是，具型別的答案是否正確，以及附加於其上的機率是否誠實。這兩者都是可量測的，但只能對照你的資料與你的標籤來衡量。

有一項有文件記載的差異值得標記出來，而不是直接解決：TypeSafe 自家的文件顯示了一個以零為起始索引的 Score 範例，而 OrcaRouter 卡片公布的量表是 2–10 個等級。廠商文件寫的是等級；我們的卡片公布的是 2–10。如果你要在 Score 之上建立評分規準，請閱讀你自己回應中的等級定義，而不要假設索引方式。

為什麼沒有可計費的輸出 token

定價是這套架構最純粹的體現。Jev 在 OrcaRouter 上每百萬輸入 token 收費 $0.042，而輸出費率是每百萬 $0.000000——這不是折扣，也不是上市促銷，而是根本不存在可計量的數量。生成式模型是就它寫出的文字計費；Jev 不寫任何文字。它回傳一個標籤、一個等級和一個機率。輸出端沒有任何東西可計數，因此那裡也就完全不收費。

TypeSafe 在其首頁從另一個方向指出同一個數字——「每十億輸入 token 42 美元」——並附上一項比較宣稱：「輸入價格比 Claude Fable 5.1 低 238 倍」。這項比較，就像首頁上其他所有內容一樣，是供應商自己的說法，未經任何人重複驗證。但它所依據的算術，讀者很容易對照自己的帳單來查核，而這正是有用之處。決策工作負載的量幾乎完全取決於你推入多少狀態，而狀態很便宜，生成出來的 token 則不然。

廠商的頭條數字比價格列還大，理當獲得同樣的標註。TypeSafe 廣告宣稱「快 193.6 倍、便宜 444.6 倍」，並以附註限定這僅適用於「System One 任務的工作流程」，還在下方公布一個計算範例：TypeSafe AI 以 $0.000081 在 0.114 秒內完成，相較於 LLM 以 $0.013880 在 8.566 秒內完成。發布文章本身也承認這種表述風險——193.6 倍與 444.6 倍被描述為可能落在「真實世界增益的較高端」——並指出並排演示使用的是一個「高度簡化」的查詢，其中便於理解的金鑰還是由廠商挑選，以「將我們的模型描繪得更有利」。這些數字全都未經獨立重現，而廠商自家的基準測試卡仍標示為待確認。

「calibrated」是什麼意思，以及 RLCD 是什麼

TypeSafe 自己為其訓練方法命名：「Reinforcement Learning for Calibrated Decisions（RLCD）」。RLCD 是 TypeSafe 自家的術語，並非早於該公司存在的通用機器學習縮寫，而其在發布貼文的比較表中所陳述的優化目標是「校準決策：在 System One 任務上，給出具有認識論誠實機率的答案」。同一張表所拉出的對比，是與 RLHF——優化人類偏好，也就是評分者喜歡的書面內容與聊天回覆——以及 RLVR——優化可透過程式化方式驗證的輸出。RLCD 優化的則是第三件事：附隨於某個答案的機率，能否準確陳述模型自身的不確定性。

實際上，「校準」（calibrated）是關於信心度的宣稱，而不是保證答案正確。一個校準過的模型若在一組問題上給出 0.8 的信心度，就應該在整組問題中大約有 80% 的時候是對的；但它在任何個別問題上仍可能出錯。這個區別是誠實解讀 TypeSafe 首頁那句話的方式：「零幻覺——每個 Jev 決策都附帶信心估計，因此你的軟體可以在信心高時採取行動，並在信心不高時升級處理。」那是對信心估計的宣稱，不是零錯誤的證明，而平衡說法就是我們自己的資料：在截至 2026-09-30 的七天內，我們的卡片量測到經由 OrcaRouter 的 Jev 流量有 0.49% 的錯誤率——同一時窗較早時這個數字是 0.57%，因為它是在滾動的七天即時 playground 流量上計算，而不是在固定的測試集上。這兩項事實都應放在同一段裡：信心度是這個模型的重點，而這個模型在我們的流量上仍然大約每兩百次呼叫就失敗一次。

校準這件事也解釋了一種延遲行為，否則這種行為看起來會像是個 bug。TypeSafe 的發布文章說：「對於基數較高的選項，我們採用兩階段系統，先獨立評分，再做出明確選擇，因此偶爾會變慢。」一個有 255 個選項的選擇並不是一次前向比較；廠商會先評分，然後再選擇。如果你看到針對大型標籤集發出的請求，耗時比 noul 明顯更久，那就是文件記載的機制，而不是壅塞。

你今天怎麼稱呼它

在 OrcaRouter 上，該模型為 typesafe/jev-1.13，在目錄中名稱為「TypeSafe: Jev 1.13」，其 context_length 為 65,536 個 token，且僅支援一種端點類型：systemone。你可以使用你的 OrcaRouter 金鑰，以 POST /v1/systemone 呼叫它，並傳送 model 欄位、state 欄位（字串、物件或陣列），以及一個 questions 映射，其中每個項目都帶有 type（noul、choice 或 score）、其 instructions 及其 criteria。回應是單一的結構化 JSON 承載資料，且不會以串流方式傳送——沒有可選擇啟用的串流模式。

這張卡片本身對合約的措辭是「輸入文字，輸出結構化 JSON」，而公布的限制是設計時必須依循的依據：非串流、合併的狀態與問題最多約 64K 輸入 token，超過該限制的要求會在觸及模型前遭到拒絕。目錄條目將定價列為每百萬輸入 token $0.042，並顯示完成率為零。那些是供應商原封不動傳遞的數字——也就是我們定價方式的等比形式：對供應商定價加價 0%。

這個模型有兩組 token 預算在流傳，而它們彼此並不衝突，因此請把它們分開看待。65,536 這個數字是模型卡的 context_length，文件記載為大約 64K 的輸入，這是狀態加上問題合計的數量。較早的 OrcaRouter 文章所引用的「大約 32,000 個 token」，僅是狀態預算本身——也就是在問題分走它們那份之前，你的素材所能獲得的空間。如果你正在為某個請求編列預算，狀態預算就是限制你所建構 payload 的那個數字；合計數字則是整個呼叫的上限。

Jev 做不到的事，直白地說

它無法撰寫散文、進行摘要、翻譯或對話。這是設計使然，而非需要致歉的限制：發布文章指出 Jev「放棄字串生成」，而 TypeSafe 自家的鋸齒狀頁面將「生成」列為具名的失敗模式，並在旁標註「使用生成式模型」的指示。強制生成既緩慢又拙劣。若你的流程需要書面摘要，Jev 就是錯誤的元件，再怎麼精心設計提示詞也改變不了這點。

它並不是生成式模型的替代品。Jev 所屬的工作流程裡有兩個模型：一個以文字閱讀、寫作與推理的生成式模型，以及坐在它旁邊、在毫秒內發出具型別呼叫的 Jev。這就是供應商首頁上每一項成本比較的誠實框架——「LLMs」那一欄並不是一個正在被取代的競爭者，而是同一個系統的另一半；而這種配對之所以有趣，是因為決策的那一半如今與生成的那一半共用同一把金鑰，而不是被自身合約擋在後面。

而「經過校準」並不代表正確。附加在 noul 上的那個數字，用意是要能被解讀為一個。noul 上的 0.62，是模型在告訴你它並不確定，這是有用的資訊，是單純的是／否會摧毀掉的——而它並不是在保證那個「是」是對的。以信心值為基礎建構的升級邏輯才是預期的模式；把答案當成絕對真值則不是。

誠實地解讀數字

我們卡片上的每一項服務數據，都來自我們自己透過 OrcaRouter 的 playground 在滾動七天窗口內的流量，而非供應商的基準測試；而且這篇文章撰寫期間，窗口仍在移動——請把它當作一次讀數，而不是規格。截至 2026-09-30 的七天內：首 token 中位數時間 151 毫秒，p95 247 毫秒，輸出吞吐量約每秒 349 個 token，錯誤率 0.49%，服務 token 數 7,620 萬。整個窗口的每日 p50 依序為 175、170、163、161、170、147 和 143 毫秒——一條平緩改善的曲線。09-28 的 p95 為 2,448 毫秒，是那個序列中真實存在的單日離群值；把它當作常態來引用會是錯的，就像完全略去它會是不誠實的一樣。

關於流量數字還有一點需要注意：每秒 349 個輸出符元聽起來像是生成式模型的吞吐量，直到你想起 Jev 不會產生任何生成的文字。這個計量器測量的是我們的 playground 在回應端對結構化負載所計算的任何內容，它適合用來發現不同日期之間的效能下降，而不是用來將 Jev 與聊天模型進行比較。

那些是我們的數字。供應商的數字是 193.6x、444.6x、0.000081 美元的計算範例，以及與 Claude Fable 5.1 相比的 238x——全都是 TypeSafe 自家的，沒有經過獨立重現驗證，且全都被他們自己的註腳限制為僅適用於 System One 任務工作流程。TypeSafe 提出的一項根本不是基準測試、卻比那些倍數更有價值的效能主張，是一項結構性的主張：因為答案是具型別的，所以整合沒有解析步驟，也沒有結構描述驗證步驟，而那是一項不會出現在任何延遲表中的成本。

什麼是開放的，什麼不是

於 2026-09-30 查核時，TypeSafe GitHub 組織發佈了十一個儲存庫。沒有任何一個包含 Jev。對整合該模型的開發者而言，重要的那些全都採用 MIT 或 Apache-2.0 授權：skills（MIT）、system-one-adapter-python（MIT，被描述為「由 LLM API 支援、可直接替換 TypeSafeClient 的替代方案」）、typesafe-sdk-js（MIT）、typesafe-sdk-python（MIT）、daggerverse（Apache-2.0）、WorkflowEvals（Apache-2.0，工作流程程式碼發佈於 evals.typesafe.ai）、n8n-nodes-typesafe-ai（MIT）、typesafe-ai.github.io 以及 pulumi-clickhouse。星數與推送日期會變動，所以如果你之後才讀到這段內容，請重新查核，而不要直接相信這份清單。

這十一個之中有三個是無關專案的分支，完全無法證明 Jev 如何運作：一個最後於 2025 年 5 月推送的 vLLM 分支、一個 2025 年 6 月的 LLaDA 分支——LLaDA 是一個無關的擴散語言模型發布——以及一個 ClickHouse Cloud 的 Pulumi 提供者。人們很容易從分支清單中推斷出架構。不要這麼做：那三個分支完全推不出 Jev 的設計，尤其 Jev 不是擴散模型，無論 LLaDA 分支的存在可能多麼暗示如此。

「Jev 是不是開源」這個問題，誠實的一行答案就是：工具鏈是開放的，模型則不是。對一個託管的前沿模型來說，這是正常的安排，而當你圍繞 Jev 做規劃時，也應該假定就是這種安排：一個有公開定價、有文件記載的合約，卻沒有公開參數量的 API。

在供應商說 Jev 不可靠的地方

TypeSafe 為 jev-1.13 發布了自己的鋸齒狀頁面，最後審閱日期為 2026-09-17，點出模型會在哪裡失靈。這份頁面異常坦率，也是開始撰寫「限制」章節的正確起點，因為它是廠商自家的清單，而非競爭對手的：

• 字面解讀——它會照字面意思理解措辭。範圍界定詞、否定詞和隱含條件不會被推斷；它「回答你寫下的問題，而不是你原本想問的問題。」廠商的修正做法是為每個選項寫出確切條件與準則。

• 數學與數字 — 它不是計算機，也無法可靠地計數。把算術留在程式碼中。

• 日期與時間比較 — 日期會被當成文字來讀取，而非可排序的數值，因此排序、間隔與時間範圍都不可靠，若格式混雜則更糟。

• 迂迴 — 雙重否定與多跳推理會降低準確度。減少跳躍，並直接指向相關狀態。

• 充滿無關細節的大型狀態 — 不相關的內容會成為干擾因素，且隨著狀態增長，準確率會下降。先過濾。

• 對抗性內容 —— 狀態不會被視為敵對，因此注入的指令或誤導性框架可能會使答案偏移。

• 相互矛盾的指令與準則 —— 當兩者要求不同的事情時，模型「可能會感到困惑」。

• 常識性的結構不變量——P(noul) 與 1 − P(not noul) 不保證會一致。每個決策只以一種方式詢問，並在程式碼中強制執行恆等式。

• 生成 — 已經涵蓋，而供應商自身的建議是使用生成式模型。

這兩點值得強調。對抗性的那一項之所以重要，是因為 Jev 的整個價值主張就是判斷不可信的材料，而含有指令的狀態可以左右答案；如果你的狀態來自使用者，那就是一個提示注入的攻擊面，形狀跟其他任何一個沒兩樣。結構不變量的那一項之所以重要，是因為一個「校準過的」模型會誘使你對它的機率做算術，而供應商是在告訴你，不要假設這套算術會封閉。

這篇發布貼文承諾了什麼，以及沒有承諾什麼

這篇文章中引用的幾乎每一項廠商說法，都可追溯至同一個頁面：TypeSafe 自家的公告，歸類於公司新聞，日期為 2026-09-15，由創辦人 Diogo Almeida 署名。直接讀它值得花那兩分鐘，因為其中一行的措辭界定了此後一切的條件。「我們的第一款公開發表模型是 Jev，即日起以早期存取形式提供。」早期存取是廠商對自家平台上可用性的自述，而這項陳述比表面上看來範圍更窄——它只讓 TypeSafe 承諾向獲准的使用者提供該模型，卻對還有誰可以提供隻字未提。這正是 2026-09-24 的目錄新增項目所填補的缺口，也是為何對今日評估 Jev 的任何人來說，模型卡比那則公告貼文更重要。

同一頁對自身限制同樣說得清楚，這也是上文引用而非改述的原因。它沒有公布參數數量，除了「一個新的模型架構」之外沒有任何架構描述，沒有訓練算力，也沒有權重儲存庫，更沒有給出正式開放的日期或條件。這些闕漏正是規劃上的限制：一邊是已公布價格的 API，另一邊是內部無法檢視的技術堆疊。這篇文章也把該模型描述得足夠坦誠，足以當作規格來用——「前沿智慧的函式呼叫：輸入非結構化狀態，輸出帶型別的機率性決策」——這是文中唯一描述介面、而非抱負的一句話。

這個介面所引發的問題

當選擇集大於 255 個選項時會發生什麼事？ 它會受到上限限制 —— 255 個具標籤選項是選擇題的上限，而當基數攀升時，廠商採取的就是兩階段「先評分再選擇」的做法，這也是有文獻記載、導致大型標籤集偶爾變慢的原因。如果你的分類體系比這還大，設計上的解答是將它拆解成幾個問題，再於程式碼中重新組合，這也正是 TypeSafe 針對複合判斷所給出的相同建議。

65,536 個 token 的上下文，是指 65,536 個 token 的狀態嗎？不是。公布的預算大約是 64K 個 token，這是狀態與所有問題合計的結果；而較舊報導中出現的「大約 32,000 個 token」數字，僅是狀態本身的預算。請以狀態的數字（而非合計數字）來規劃你的酬載，並記住，超過限制的要求會在送達模型之前就被拒絕。

這該怎麼處理？

Jev 1.13 值得一看，原因是某個具體用途，而不是泛泛之談。如果你的流程中有某個步驟，目前是要求聊天模型回傳一個標籤，並信任它會以正確格式回傳——無論是路由器、評分器、政策檢查，還是套用到數千筆記錄的評分量表分數——這個模型取代的正是那個步驟，每百萬輸入 token 收費 $0.042，輸出端則完全不計量。如果你有某個步驟需要書面答案，Jev 並不是合適的工具，而且它自己的供應商也這麼說。

過去一週改變的並不是模型本身。改變的是，試用它不再需要建立第二個供應商關係。八天前，評估 Jev 意味著要另外開一個帳號、另外做一次整合；今天，它只是一個已經能觸及 200+ 個模型的金鑰上的一個模型 ID，供應商的定價原封不動地轉嫁，而文字答案會和其他所有內容一樣從同一個地方傳回。對這麼不尋常的模型來說，能夠用自己的標籤測試它，而不必承諾簽訂新合約，就是決策的絕大部分。