RSI-Jev vs Jev 1.13：一個供下載，一個供呼叫

把RSI-Jev v6.1-VL 4B與Jev 1.13並排放在一起，呼叫方首先注意到的是，它們是同一個請求。把一個狀態和一組具型別的問題——是非題、從 k 個選項中選一個、依評分規準評分——交給任一個，兩者都會在一次前向傳遞中，為每個選項回傳一個校準過的機率，而且沒有需要解析的生成文字。這並非巧合：RSI-Jev 刻意建造成能說 Jev 的傳輸格式，因此針對 TypeSafe API 撰寫的用戶端，只要更改基礎 URL，就能對它運行。不同的是這個呼叫周遭的一切。Jev 1.13 是 TypeSafe 的閉源商業模型，從一個你需按用量計費的端點提供服務；RSI-Jev v6.1-VL 則是一個 4.69B 參數的檢查點，以 Apache-2.0 授權的權重發布，由你下載並在自己的硬體上提供服務。兩者都不是另一方的重新貼牌，兩家廠商也都沒有為另一方背書，而且這項比較中幾乎每一項數據都來自產出它的一方。

主體上的日期很重要，因為這個專案幾乎每天都會推出一個版本。RSI-Jev v6.1-VL 4B 是由第三方Shanghua-Gao/RSI-Jev專案於 2026-10-07 發布的——這是一個自我精進的研究迴圈，訓練 Jev 風格的決策模型，並將每一個失敗的實驗臂連同勝出的那些一併公布。它是該系列十三天內的第八個版本，內容是前一個版本與同一個 Qwen3.5-4B-Base 第二次微調的權重平均。Jev 1.13 是 TypeSafe AI 的模型，於 2026-09-15 推出，自 2026-09-24 起收錄在我們自家的目錄中。這兩個日期在下文都很重要，因為與一個每天都在推進的專案相比，比較結果的保鮮期是以天為單位來計算的。

這兩者實際上究竟是什麼，各用一行說明

Jev 1.13 是一個託管式決策模型，位於專用端點之後——POST /v1/systemone，非串流，輸入預算約 64,000 個 token，涵蓋狀態與你所有問題的總和，價格為每百萬輸入 token $0.042，輸出計費為零，因為沒有輸出 token。其架構、參數數量與訓練算力皆未披露；TypeSafe 表示細節仍保密，之後可能會有論文發表。你不是自行執行它。你呼叫它，而每次呼叫都是一次計量的網路請求。

RSI-Jev v6.1-VL 是另一種完整配置。它是端到端微調的 Qwen3.5-4B-Base 塔，在第 16、20 與 32 層設有決策頭，並由一個自包含、bf16 格式下為 9.7 GB 的檢查點提供服務。參數量為 4.69B，值得了解其分布：3.57B 在 32 個解碼層、0.64B 在詞元嵌入、0.33B 在視覺塔、0.05B 在主決策頭，以及 0.10B 在兩個提前退出頭。沒有專家混合，也沒有第二個模型。你透過儲存庫中的 pip 指令安裝它、執行其伺服器，從那一刻起，決策永遠不會離開你的基礎設施。

• 誰在運行它 — 一個你無法控制、按用量計費的託管端點，對比放在你自己的 GPU、Apple Silicon 或 CPU 上的 9.7 GB 檢查點。

• 價格型態 — 每百萬個輸入 token 為 0.042 美元，輸出免費，按呼叫次數付費；對比邊際成本為零，再加上機器與營運成本。

• 輸入預算——在託管模型上，每次請求約為 64,000 個 token；而在檢查點上，則是 32,768 個文字 token 加上影像預算，超過長度的內容會被拒絕，而不是遭到截斷。

• 權重與授權 — 封閉、規模未公開，對比 Apache-2.0 權重、MIT 程式碼、46.9 億參數。

• 模態 — Jev 的合約僅限文字，對比 RSI-Jev 視覺版本每次請求為文字加上最多四張圖片。

• 所有權 — TypeSafe AI 的商業模式相對第三方研究專案，後者在其授權條款中聲明「Not affiliated with TypeSafe AI.」

RSI-Jev 自家看板上的分數，以及為什麼這只是一半的比較

專案率先提出的數字，是它在 Decision Index 0.3 的分數：v6.1-VL 4B 為 50.98，高於前一版的 46.23。這是預設配置的完整執行——140,178 次請求、覆蓋率 1.0——且在專案自家的公開排行榜上，日期為 2026-10-06，它與該榜上最佳的 4B 模型並列（50.98 對上 ezjev 4B s2 的 50.82，套件將 0.25 以內視為並列），整體在 113 個中排名第 27。在較舊的 Decision Index 0.2.1 上，它的讀數為 50.74，對比 v6.0-VL 的 46.24。其十五項基準套件在回報時排除 open_jev_ood 這個被發現與訓練列重疊的任務後，為 0.793，而其留出集為 0.729。

那些數字每一個都是 RSI-Jev 自己的，是在 RSI-Jev 的測試框架上測得的。Decision Index 是一個公開的基準排行榜，但上面沒有 Jev 1.13 的成績，因為該專案的測試套件是為了替開放的決策檢查點評分而打造，而 Jev 是封閉的端點。所以，在 typed-decisions 基準測試上把 50.98 拿來對比 Jev 的 0.727，然後宣布誰勝出，這種誘惑正是應該避免的錯誤：這兩個數字來自不同的測試框架、不同的樣本數和不同的資料，而且沒有人用同一套測試框架跑過這兩個模型。

唯一存在的正面對決是 Laya 的，而非 RSI-Jev 的。

有一份已發表的比較，確實把 Jev 數值與一個開放檢查點並列，而它並不是由這裡的任何一方所執行。Laya 決策模型的開發商 Convai Innovations，將 TypeSafe 已發佈的 Jev 1.13.0 數據與自家數據列表對照，並自行標示了其限制：這些 Jev 數值由第三方發佈，從未由 Convai 測量；樣本數與提示不同；而且該供應商並未列出其模型本身的基準。那張表值得一讀，是為了校準，而非為了裁決——而且它完全未納入 RSI-Jev，因為該表發佈時 RSI-Jev 尚不存在。

它確實顯示的是讀者實際上正在權衡的託管式與開放式問題的輪廓。當選項空間很大，而模型必須維持廣泛答案集穩定時，託管模型會勝出；開放模型則在每次呼叫的原始延遲上勝出，因為路徑中沒有網路。這種模式完全無法告訴你這兩款特定模型哪一款更適合你的任務，而誠實的立場是：公開資訊中還沒有答案。

檢查點能帶來而端點無法帶來的效益

RSI-Jev 最有力的論點不是分數，而是權重就放在你自己的硬體上。對於醫療文件、法律文件或客戶帳戶歷史所做的路由決策而言，「資料從不離開這棟大樓」不是你能拿來跟某個基準分數權衡取捨的事——而是硬性要求，無論價格多高，任何代管端點都無法滿足。同樣的特性也消除了速率限制：供應商自家針對代管模型的文件指出，其限制會動態調整，且可能未經通知就變更；而自架檢查點除了你的硬體之外，沒有這種上限。

檢查點帶來的第二件事是深度控制，而這一點並不尋常。由於決策頭位於三個深度，一個effort設定會決定一項請求最多可以使用多少層：low停在 16 層，中位數約 23 毫秒，medium為 27 毫秒，high停在 32 層，約需 40 毫秒，而 auto則在第一個信心足夠的出口給出答案，在該專案的測試套件上平均使用 32 層中的 19.5 層。這些延遲數字是該專案自行在單一張 H200 上以 bf16 測得的數據，不應與任何代管服務的數據混為一談——本機的前向傳遞與按用量計費的 API 呼叫並不是同一種量測，而 RSI-Jev 自家的文件也明白指出，它先前與 Jev 延遲的比較，是拿本機 GPU 的工作去比網路來回傳輸。

第三件事是圖像。Jev 的合約是輸入文字，輸出結構化 JSON。RSI-Jev 視覺版本每次請求接收一到四張以 base64 資料 URL 形式提供的圖像，狀態會以標記指涉每一張，而 v6.1-VL 在專案的保留圖像集上得分 0.834。如果你的決策是「這張照片是否顯示出可見的損壞」，那是託管合約完全未提供的能力。

你放棄的東西同樣真實，而專案會把它公開出來。這個版本的校準變差了，而非變好：最終期望校準誤差在第 32 層為 0.048，搭配 auto 時為 0.055，相較之下前一版分別是 0.036 與 0.024。預設的單一閾值 0.95 是以明確標示為未經確認的狀態發布——它是某條選擇規則的備援值，而該規則自己選出的 0.85，在其一半的開發資料上未能通過專案的深度上限。提前退出只讀取文字，因此任何帶有圖像的問題，無論投入程度為何，都會跑完所有 32 層。此外，五個圖像訓練來源屬於非商業或僅限研究用途，專案也直言，以非商業資料訓練出的權重是否繼承這些條款，目前尚無定論。

該在哪裡呼叫託管的那個，以及哪裡不該呼叫

這是比較中與我們有利害關係的部分，因此值得精確說明。我們以 typesafe/jev-1.13 的形式，在專用的 systemone 端點上提供 TypeSafe 的商業模型——是向 /v1/systemone 發出 POST，而非 OpenAI 聊天補全的形式，非串流，並對照我們目錄所列的 65,536 個 token 上下文。這與 RSI-Jev 所實作的請求和回應形式相同，來自該專案所複製其合約的模型。RSI-Jev 本身我們並不代管；我們的目錄中沒有 rsi-jev 這個 id，也沒有 shgao 這個 id，想要那個模型的讀者得自行下載。

這個區別在這裡之所以重要，理由既狹隘又具體。決策層很少是整個工作流程的全部——它通常就位在一個生成式模型旁邊，由該模型撰寫回覆、摘要或程式碼。這在歷史上意味著兩份合約。對託管的那一半來說，如今已不必如此：Jev 1.13 與其他 200 多個模型使用同一把金鑰，以供應商定價原樣轉嫁、0% 加價，因此如果 TypeSafe 調整費率，變更會在我們這邊當天生效，而不是等到下一個帳單週期。自架的那一半從來沒有這個問題，因為供應商就是你自己。要在兩者之間做出決定，乾淨俐落的方法是先拿幾個你自己的標註案例試用商業合約，看看開箱即用的行為是否好到足以據以自動化，然後才去評估自行執行 4.69B 檢查點是否值得那些維運。

你實際上應該選哪一個？

如果這項決策必須留在你的邊界內，如果你需要同時對圖像與文字做出決策，如果你的選項集會達到數百個（此檢查點每題最多接受 5,120 個選項），或者你想依每個請求調整深度與延遲，就選擇 RSI-Jev v6.1-VL 4B。你要明白，你採用的是個十三天內變動八次的專案，它的最新版本以校準換取準確度，而且它自己的模型卡也點名了退出政策中它無法確認的部分。

選擇 Jev 1.13，前提是你希望這個決定不必靠服務堆疊就能成立、你重視由他人持續維護的端點，而且每百萬輸入權杖 $0.042 的價格——沒有輸出權杖需要計量——相對於你的呼叫量來說夠便宜。投入前請先明白，你呼叫的是封閉模型：其規模未公開、速率限制可能未經通知就變動，而它公布的基準測試也不是你能自行重跑的。

兩者共同擁有的那一點，比區隔兩者之處更有用，而這正是這類比較之所以值得寫的原因。這兩個模型都不生成文字，因此兩者都不會引入那種因模型忘記閉合大括號或虛構欄位而導致的失敗類型。兩者都會回傳機率，而在兩種情況下，機率都是你在以此為依據進行自動化之前，必須先用自己的標註資料驗證的部分——延遲早已商品化，而信心值才是每次部署都必須分別贏得的東西。無論你落在「下載」與「呼叫」這條分界的哪一側，都要先測試校準。