TypeSafe 的 Jev 上個月是熱門話題：不生成文字、一次前向就吐出每個選項的機率，號稱比 LLM 快兩個數量級。然後 AutoJev 出現，把訓練配方開源了。現在有人乾脆把整件事搬到自家書桌上重做一遍——firelex/jeff 這 repo 2026 年 9 月 28 日才建立，一天就拿到 298 顆星，隔天上了 Hacker News 首頁。
它到底做了什麼
三個模型：Qwen3.5-0.8B、Qwen3.5-2B、Gemma 4 E2B，全參數微調成「決策模型」。你給它一段情境描述加一組白話選項，它回傳每個選項的校準機率，一次 forward pass，不生成文字也就沒有解析失敗的問題。請求格式刻意做成跟 Jev 一樣（/v1/systemone），可以直接換掉。
數字很具體：0.8B 在 RTX PRO 6000 上 22 毫秒、在 M4 Max（MLX）上 28 毫秒一次決策。作為對照，Jev 公開的 Doom 實驗每次呼叫 212 毫秒，那還含了網路延遲。
訓練全部在本地硬體完成：一張 RTX PRO 6000 跑微調（0.8B 約 2 小時、2B 約 3.5 小時），兩台 DGX Spark 用開源的 Qwen3.8-Flash-Next 寫合成訓練資料，筆電測試。沒有雲端 GPU。閉源模型的輸出不進訓練集，只拿來抽查一小部分合成資料的品質。權重 Apache 2.0，程式碼 MIT，訓練資料本身不釋出，但每個來源的授權都列在 docs/data-sources.md。
成績與它自己先講的弱點
README 的 benchmark 表有一件事做得漂亮：作者沒有把數字藏起來，反而先告訴你哪裡不行。
五個公開 benchmark 加總，Jeff-2B 拿 83.1%，Jev 公開數字 83.0%，看來打平。拆開就不是那麼回事：
| Jeff-0.8B | Jeff-2B | Jev（公開） | |
|---|---|---|---|
| Overall（5 項） | 79.1 | 83.1 | 83.0 |
| BBH（推理） | 64.0 | 68.0 | 94.3 |
| Financial PhraseBank | 96.4 | 96.3 | 77.0 |
| RAGTruth | 86.1 | 88.9 | 77.3 |
| JevBench hard（另計） | 47.6 | 53.3 | 73.3 |
總分是靠分類題拉平的。金融語句分類 96 分對 77 分、RAG 幻覺偵測 89 對 77，這兩項 Jeff 都贏；但 BBH 推理 68 對 94、JevBench 困難層 53 對 73，量級差距擺在那裡。作者的說法是：0.8B 和 2B 本來就不會推理，它們是快速 judgement caller，不該拿來比規劃能力。這話誠實，也確實是這個尺寸模型的極限。
他還主動註明 Jev 那些公開數字是同一套 benchmark 的不同抽樣，不是嚴格同場對比。
遊戲測試比 benchmark 有意思
作者拿三個遊戲做 zero-shot 測試（訓練資料裡沒有任何遊戲資料），每回合一組文字描述加一組選項，選項只說明這步會發生什麼，不告訴模型哪步才對。20 局平均：
- Doom：Jeff-0.8B 6.55 kills，跟手寫 bot 一樣，也跟 Jev 公開成績一樣。但 Jev 的 prompt 直接寫明了瞄準規則，Jeff 拿到的只有「怪物在你左前方一點」。
- Frogger：10.3 次穿越，手寫 bot 10.25 次，未訓練的底座模型只有 1.0 次。
- Pac-Man：98 顆豆子吃到 57 顆，約為手寫 bot 的六成。
三個反直覺的結果值得記。第一，2B 遊戲每一項都輸給 0.8B，Doom 甚至拿到負分——作者猜測 2B 本來就更保守，訓練又加劇了這點。第二，benchmark 分數完全不預測遊戲表現：未訓練的 Gemma 4 在 benchmark 上最高（62.5%），玩起來最爛。第三，措辭的影響誇張到不行：把 Frogger 最後一步改寫成跟其他前進選項一致的寫法（「safe, and one row closer to the goal」），單局穿越次數從 15 跳到 23。在那之前，青蛙只是待在最後一根木頭上不動。
Hacker News 上的反應
討論串 260 points、101 則留言，一天內累積，沒有什麼爭議，但質疑聲很清楚。整理成幾類：
「這不就是個分類器嗎？」 這是最大的一類，而且不是酸。有人指出 BERT 和 FLAN-T5 五七年前就在做這件事；網友 nico 貼出自己的實測：embedding 加邏輯回歸，在 AG News、Banking77、MASSIVE 這批分類資料集上打平甚至打贏 Jev 和 Laya，推理小於 1 毫秒、模型不到 1 MB，還附了 gist 程式碼。他後來又自訓一個不到 1 MB 的分類器，在 Jeff 測試的同一關 Defend Center 拿到 22 kills（滿分 26），Jeff 是 6.55。
「要微調就改變了產品類別」（senko，+10 層）。Jev 的價值本來就是零微調、30 秒 prompt 就能上；需要先餵自己資料微調，那是另一種產品。這條被推到很高，也最難反駁。
實測翻車。兩位網友拿自己場景測：一位說 70% 對 Jev 的 94%，「分類用途不可接受」；另一位測職缺分類，0.8B「完全沒用」，2B 好一點但還是漏判工作型別。
技術解密派。Jev 到底怎麼做到的？留言裡的猜測很一致：encoder-only 模型加強化學習，輸出是固定數量的 logit 而非文字。有人直接講「沒有架構魔法，就是 prefill 加單 token 推理，加上不錯的行銷」，也有人從 40k context 上限推測底子是 BERT 系。這串的價值在於，它把 Jev 的神秘感拆掉大半。
成本側的題外話。「如果企業發現根本不需要完整 LLM，AI 支出會怎麼樣？」下面有人回「美股幾天內跌 20%」，也有人澆冷水：目前商業用量絕大多數是 coding，分類本來就跑在便宜小模型上。
作者 firelex 的首則回覆倒是另一回事。他主動列出 BBH 落後、JevBench 困難層落後、2B 遊戲輸 0.8B 等所有弱點，加上自己的 lessons learned。這種先自曝其短的姿態，在這種串裡通常換得到善意——整串確實沒有人身攻擊。
我的看法
Jeff 的位置有點尷尬，尷尬得很誠實。論 zero-shot 準度它輸 Jev（要準就自己微調，但那 Jev 的賣點就沒了）；論成本它輸傳統分類器（nico 的 <1 ms、<1 MB 就是最好的對照）；論使用門檻它輸雲端 API。它剩下的生態位是：開源權重、完全本地、跟 Jev API 相容、微調配方齊全，而且所有數字都公開。
對我來說這比 benchmark 分數更值得記。一個作者主動把 68 對 94 這種成績放在第一屏的專案，比一個把弱點藏進 footnote 的可信得多。至於「小模型是分類器不是規劃器」這句話，大概是這整件事最該被帶走的結論。
相關：