在家訓練一個 30ms 的 Decision Model，這件事現在有多容易？

> Patch Note

Jeff 這個專案我第一眼看到的時候，反應是：「這個人家裡有什麼硬體？」

然後看了一下 README，Apple M4 Max 28ms、RTX PRO 6000 22ms，0.8B 參數，zero-shot classification，相容 Jev 格式。專案在 GitHub 上累積了 1.2k stars，fork 了 49 個。

這不是什麼大公司的研究，是個叫 firelex 的人自己做的 fine-tune 專案。但它點出了一件我覺得值得認真聊的事：小型 decision model 這個方向，現在已經到了個人開發者可以自己玩的程度了。

這篇我想把它拆開來看，不只是「哦很快很小」這樣的結論，而是看看它的設計決策是什麼、為什麼這樣做、以及身為開發者你應不應該把這個東西放進你的 toolbox。

---

它到底在解決什麼問題

先說清楚 Jeff 是什麼，因為「decision model」這個詞乍聽之下有點抽象。

簡單說：你給它一個情境描述，再給它一個 option list，它吐回每個 option 的機率。一次 forward pass 搞定，不生成文字，不需要 parsing。

這跟你拿 GPT-4 問「這句話是哪個 intent？」的差別在哪？差別很大：

1. 速度：GPT-4 你要等 token by token 生成，最後還要解析輸出的文字。Jeff 直接給你機率向量，22-28ms 就結束。
2. 成本：API 呼叫費用 vs. 本地跑，不用算就知道差多少。
3. 可預測性：LLM 的輸出格式你永遠不敢 100% 信任，Jeff 的輸出格式是固定的數字。

它的 target use case 是那種需要「快速分類判斷」的場景：客服 intent routing、語音指令識別、內容 moderation label、甚至棋局下一步決策。看 repo 裡有個 examples/chess 資料夾，作者真的拿它來做棋類決策示範。

---

架構概覽

Jeff 的技術底層是 Qwen3.5 0.8B 和 2B，以及 Gemma 4 的 fine-tune。不是從頭訓練，是在已有的 base model 上做的。

整個系統的資料流大概是這樣：

你的程式碼
    │
    ▼
Jeff API（本地）
    │  輸入：情境描述 + option list（純文字）
    ▼
Single Forward Pass
    │  不 decode token，直接看 classification head
    ▼
機率向量（calibrated）
    │  每個 option 對應一個機率值
    ▼
回傳給你的程式碼

最關鍵的部分是「不生成文字」這個設計。一般 LLM 做分類的做法是讓它輸出 "Option A" 這個 token sequence，你再 parse 回來。Jeff 跳過了這整段，直接把 classification 當成 logit 操作來做。

v1.1 支援最多 254 個 options（v1.0 只有 26 個）。這個升級很重要，因為 26 個 option 在很多實際場景根本不夠用，你的客服 intent 隨便就超過這數字了。而且根據 README，0.8B 在 long-list test 的表現從 40% 直接跳到 95%，這個提升幅度相當誇張。

Request format 跟 Jev 相容，所以如果你之前有用過 Jev，切換過來基本上不用改什麼。

---

三個核心設計決策拆解

1. Zero-shot，不是 few-shot 也不是 fine-tune per task

Jeff 主打 zero-shot：你的 option 不需要出現在 training data 裡，只要你用文字描述清楚，它就能做分類。

這是個很聰明的選擇，因為它解決了「分類任務每次都要重新 fine-tune」的痛點。以前你換一個產品線的客服系統，就要重新準備資料、重新訓練。Jeff 的做法是讓模型學會「讀懂描述然後做判斷」這件事本身，而不是記憶特定的 label。

trade-off 是什麼？精度。Zero-shot 就是在犧牲部分準確率換取靈活性。如果你有足夠的 labeled data，一個專門 fine-tune 過的 classifier 幾乎一定會贏過它。但問題是大多數人沒有足夠的 labeled data，而且需求還在變。

2. Single forward pass 做 calibrated probability

這是讓它快的關鍵。

一般做法是 auto-regressive decoding，一個 token 一個 token 生成，延遲隨長度線性增加。Jeff 把問題轉換成：我只需要在 vocabulary 上找到對應 option 的 token 機率，然後做 calibration。

根據 README，它在 RTX PRO 6000 上跑約 22ms，Apple M4 Max 上約 28ms。這兩台機器都不是消費級頂配（RTX PRO 6000 是工作站卡，M4 Max 是 MacBook Pro 旗艦），但也不是什麼伺服器等級的設備。

「Calibrated」這個詞值得多說一句。機率 calibration 的意思是：如果它說某個 option 有 80% 機率，那實際上它真的應該有約 80% 的時候是對的。很多模型吐出來的 confidence score 其實是沒有 calibration 的，只是 softmax 的原始輸出，不代表真實機率。Jeff 有做過 calibration 的處理，這讓它的輸出比較可以直接拿來做決策用。

# 大概的使用方式（根據 Jev 相容格式）
from jeff import Jeff

model = Jeff("jeff-qwen3.5-0.8b")

result = model.decide(
    situation="用戶說：我要退款，你們的產品根本不能用",
    options=[
        "退款申請",
        "技術支援",
        "投訴處理",
        "一般詢問"
    ]
)
# result: {"退款申請": 0.72, "投訴處理": 0.21, ...}

3. 選 Qwen3.5 0.8B 而不是其他 base model

Qwen3.5 是阿里巴巴的模型系列，0.8B 這個 size 在 edge deployment 上很常見。為什麼選它？

幾個可能的原因：

• 0.8B 在消費級硬體上跑起來沒什麼壓力，記憶體佔用小
• Qwen 系列對多語言支援不錯，不是英文優先的設計
• 授權相對友善，可以商用

同時也有 Gemma 4 的版本，Gemma 是 Google 的開源模型。兩個版本並存這個策略我覺得很務實，讓使用者根據自己的場景選。

---

商業背景：這是誰做的、為什麼做

firelex 是個人開發者，不是公司。repo 用 MIT license，完全開源，模型放在 Hugging Face 上。

Jev 是什麼？README 提到 Jeff 的 request format 跟 Jev 相容，但目前沒有公開太多關於 Jev 背景的資訊。從命名和格式相容性來看，Jev 應該是一個更早存在的 decision model 規範或服務。Jeff 選擇相容它，代表作者在往「可以直接替換現有方案」的方向走，而不是建立一個完全獨立的生態系。

這種策略我在開源社群看過很多次，通常意思是：「我不是要幹掉誰，我是要讓你更容易遷移過來。」

商業模式目前看起來是零。沒有付費版、沒有 API 服務、沒有公司。純粹是「有人覺得有用就做了」的那種開源專案。

這對投資者來說吸引力基本上是沒有的，畢竟沒有任何商業化跡象。但對開發者社群來說，1.2k stars 在這麼短的時間內累積，說明需求是真實的。如果這個方向繼續發展，不排除之後有人會把類似概念包成服務來賣。

---

Meta 判讀：這是個 Patch Note，不是 Meta Shift

我把 Jeff 歸類成 Patch Note 而不是 Meta Shift，原因是它改善的是一個已知問題，而不是開創了新方向。

「用小模型做快速分類」這件事不是 Jeff 發明的。你去看任何 NLP production system，這都是基本操作。Jeff 的貢獻是把這件事的門檻再壓低了一層：

• 你不需要自己設計 fine-tune pipeline
• 你不需要準備 labeled training data
• 你不需要懂 classification head 的設計
• 你只需要 pip install，然後描述你的場景

這是工具層的進步，不是範式轉移。但工具層的進步累積起來，才是讓「個人開發者可以做以前需要 ML team 才能做的事」的根本原因。

跟歷史上類似的事做個比較：這讓我想到 2017-2018 年 fastai 剛出來的時候，把 fine-tuning 的流程包成幾行 code。那時候也有人說「這沒什麼了不起，研究者早就在幹這個了」，但最後它讓整個社群的實驗速度快了一個數量級。Jeff 的量級沒那麼大，但方向是一樣的。

---

實戰建議：什麼時候該用

適合的場景：

• Latency 敏感的 routing 邏輯：你有一個 pipeline，需要在 50ms 以內決定這個 request 要送去哪裡處理。Jeff 的 28ms 留給你充分的 buffer。
• Option 會頻繁變動的場景：你的分類 label 每個月都在改，不想每次都重新訓練一個 classifier。
• 本地部署、不能呼叫外部 API：資料敏感的場景，或是需要 offline 運作的系統。
• 原型快速驗證：你想先確認「這個分類任務是否可行」再決定要不要投入更大資源。

不適合的場景：

• 你有大量 labeled data 且精度要求極高：這種情況專門訓練的 classifier 會贏。
• Option 數量超過 254 個：v1.1 的上限在這裡，超過就要想別的辦法。
• 你需要多語言且中文為主的場景：Qwen 系列對中文支援不錯，但 zero-shot 在中文的表現我沒看到具體 benchmark，需要自己測。

坑：

v1.0 到 v1.1 有個東西要注意 — 2B 模型的 benchmark score 從 83.1% 微降到 82.0%。這個 trade-off 是用來換取支援更多 option 的能力。如果你的場景 option 數量不多（26 個以內），v1.0 在精度上可能稍微好一點，Hugging Face 上還保留著 v1.0 的版本。

30ms 的數字是在 M4 Max 和 RTX PRO 6000 上測的，如果你跑在更普通的硬體上，數字會不一樣，需要自己測過再決定架構。

---

這個專案本身不會改變什麼大格局，但它是一個很好的信號：個人開發者自己在家 fine-tune、跑 inference、包成可用工具，這整個流程已經沒什麼神秘感了。下一個這樣的東西可能就是你做的。

延伸閱讀

• Raycast CEO：AI 時代每個工程師都應該自己做工具 — 這不是在開玩笑
• 為什麼 AI Agent 還取代不了程式設計師 — 約束衰減問題解析
• AI Agent 跑到一半沒 token 了 — token budget 問題沒人在講，但很重要