JH5

Posted on Oct 19

來訓練自己的 Jev 模型吧：)

#ai #machinelearning #llm #qwen

覺得在應用中頻繁呼叫 Microsoft-Decision-1 或 Jev 等決策模型 API 太昂貴嗎？在現代的 AI Agent 架構中，高達八成的判斷節點需要的其實是「System 1」的直覺反射，而非傳統語言模型耗時的自回歸生成。

接下來的文章將完整記錄如何利用手邊的消費級GPU，在本地環境訓練出與微軟同款 Decision Head 架構的 Qwen3.5 決策模型，紀錄完整的訓練流程、A/B 對照組的延遲數據、機率校準表現，以及實際的應用場景，適合不想被雲端 API 綁架、希望在私有環境建立毫秒級高吞吐決策節點的工程師參考。

微軟 Microsoft-Decision-1 與 Jev 到底在做什麼

微軟在 2026 年 10 月推出了 Microsoft-Decision-1，號稱決策速度比 GPT-6 快上 35 倍，目前也直接掛在 Azure Foundry 和 OpenRouter 上收費，翻開規格一看，微軟採用的底模其實就是阿里巴巴開源的 Qwen3.5-9B，把開源底座加上分類訓練結果直接開賣，在商業上的手腳超快。

就想我們上一篇提到的，vLLM Decision 3.0 地端實測，
過去我們要把一段 Log 或工單分類，標準做法是寫一段長長的 Prompt，請模型「請只回傳 JSON 格式 {"category": "billing"}」，接著祈禱它不要加上 markdown 語法，然後在應用端用 Pydantic 或正規表達式硬解，一個二選一的問題，模型在背後自回歸吐了數十到數百個 token，動輒花費數秒，偶爾還會吐出格式炸裂的字串導致系統噴錯。

決策模型走的則是完全相反的路線。它代表的是認知架構裡的「System 1」— 直覺反射神經。

傳統語言模型在最後一層要將隱藏狀態投影到高達 15 萬維度（Vocab Size 約 152,064）的詞表空間，計算成本極為昂貴，而像 TypeSafe AI 的 Jev、Cloudflare 的 Clef，或是 Unsloth 這次整合的 Decision Head，是把 Sequence 的最後隱藏狀態抓出來做 Pooling，直接接上一組精簡的 Decision Head 再做一次 Forward Pass，幾百個維度的選項機率就全部算完了，推論過程根本不需要 decoding 迴圈。

24GB VRAM 微調

我拿手邊這台有 24GB VRAM 的機器來進行完整訓練與驗證。

底模選擇 unsloth/Qwen3.5-4B，搭配 4-bit 量化與 LoRA（rank=16, alpha=16），資料集採用開源決策基準 LocalLLaMA/typed-decisions，包含 1,120 筆訓練樣本、80 筆驗證樣本以及 400 筆獨立測試樣本。

訓練與驗證的核心數據如下：

指標項目	基準數據 / 實測結果
底模與量化	Qwen3.5-4B (4-bit QLoRA)
訓練峰值 VRAM	7.95 GB
訓練耗時	910.6 秒（約 15 分鐘）
零樣本初始準確率	30.5%
訓練後驗證集準確率	80.5%
400 筆未見測試集準確率	74.9%
期望校準誤差（ECE）	0.187 → 0.036
單次前向傳播平均延遲	191.4 ms

VRAM 的花費滿省的，4B 模型在 4-bit 狀態下，整趟訓練跑完 VRAM 最高峰值只有 7.95 GB，換算一下微軟採用的 Qwen3.5-9B 的 base Model，換算下來 VRAM 大概落在 14 到 16 GB 之間，如果手邊機器資源允許的話也可以上9B模型。

對照推論速度

雖然知道決策模型一定快，但是為了驗證「到底快了多少」，我在相同的 GPU 上進行了嚴格的 A/B 測試，一邊用傳統 Prompt 叫 Qwen3.5-4B 吐 JSON，另一邊用微調後的 Decision Head 進行測試。

實測數據差距：

對比項目	傳統生成式 Prompt	決策模型（Decision Head）
平均推論延遲	3,679.8 ms（約 3.7 秒）	191.4 ms（0.19 秒）
運算機制	逐 Token 生成（耗損 64 tokens）	單次 Forward Pass
格式可靠性	頻繁冒出 `<think>` 思考鏈、未完結	保證 100% 符合 JSON 格式
信心度資訊	無	自帶校準機率分佈向量

在測試傳統生成式模型時，新一代推理模型甚至在 Prompt 中自動冒出 <think> 思考標籤，寫到一半就撞上 max_tokens 限制，根本連 JSON 閉合括號都沒吐出來。而決策模型在 191 ms 內就交出乾淨的機率字典。

壓測多元任務並行

由於現實的情境通常沒那麼單純，我整理了幾種情況來測試它在多任務擴展與面對異常資料時的表現。

1. 多題擴展邊際成本：每題僅多 16 ms

在很多場景中，我們常希望同一段文字能同時回答多個問題（例如同時判斷「負責組別」與「緊急程度」）。

實測推論延遲的拆解結果：

單一問題（只問 team）：平均 175.28 ms
雙重問題（同時問 team + priority）：平均 191.35 ms
多問一個問題的邊際耗時：16.07 ms

主要原因還是因為整個context的 Backbone 特徵編碼只需要算一次，後面掛載的 Decision Head 只是非常輕量級的線性投影，這也意味著就算一次掛載 5 個分類判斷（組別、急迫性、情感、PII 洩漏、語言），推論延遲頂多增加 60 到 80 ms。

2. 面對無關垃圾訊息與歧義的機率反應

當我們丟入完全不相干的文字（例如抒情詩句「秋風穿過月光下的金黃落葉」）時，模型會亂問亂答嗎？

實測顯示，模型的最高信心度直接從原本的 99.9% 暴跌至 54.3%，機率被分散到各個選項中（billing 15.7%、technical_support 30.0%、account_management 54.3%）。

這個結果剛好可以用簡單的門檻值過濾異常輸入，避免LLM服務上線時被拿來亂戳亂打。

驗證跨領域場景

訓練完成後，我挑了兩個跨領域的實際情境來踹踹

情境一：高爭議客服工單路由

輸入情境：

"Hi, I was charged twice for invoice #4411. Please refund the duplicate transaction today."

模型輸出結果：

{
  "team": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.9997,
    "probabilities": {
      "billing": 0.9997,
      "technical_support": 0.0001,
      "account_management": 0.0002
    }
  },
  "priority": {
    "type": "choice",
    "choice": "high",
    "confidence": 0.8931,
    "probabilities": {
      "high": 0.8931,
      "medium": 0.1053,
      "low": 0.0016
    }
  }
}

模型毫不猶豫地給出 99.97% 的 billing 機率，並且把牽涉到重複扣款的問題評定為 89.31% 的 high priority。

情境二：生物資訊管線次世代定序（NGS）品質異常警報

在我們的基因檢測分析管線中，定序批次的品質檢測往往需要工程師人工看圖判斷。我給了模型一段真實的品質異常描述：

"Sample HG002 WGS sequencing run finished. FastQC reports mean Phred score Q18 at read cycle 120-150, duplication rate 42%, GC content abnormal spike at 65%. DeepVariant call rate dropped by 28%."

要求模型給出處置動作與風險評估：

{
  "action": {
    "type": "choice",
    "choice": "manual_bioinfo_review",
    "confidence": 0.7721,
    "probabilities": {
      "resequence": 0.2215,
      "manual_bioinfo_review": 0.7721,
      "pass_to_pipeline": 0.0063
    }
  },
  "risk_level": {
    "type": "choice",
    "choice": "moderate",
    "confidence": 0.847,
    "probabilities": {
      "critical": 0.1527,
      "moderate": 0.847,
      "low": 0.0002
    }
  }
}

這個結果滿有意思的，模型沒有直接放行（pass 機率只有 0.63%），但也沒有武斷地要求重跑，而是給出 77.21% 的信心度要求人為介入複查。

專模專用的 System 1 架構

過去兩年，我們習慣依賴大型語言模型解決「複雜邏輯推理」與「表達」的問題。但回到真實的系統架構中，每天成千上萬次的意圖路由、資安過濾或狀態判斷，需要的只是快、準、省資源的「條件反射」。

在我的實測經驗中，如果系統每天需要吞吐大量決策，完全不值得承擔雲端 API 的 Token 費用與動輒數百毫秒的網路延遲。只要有一張消費級顯卡，我們就能在本地端完成 Decision Head 訓練與部署。特別是對於需要處理機敏資料或病患資訊（如前述的基因定序品質檢測）的場景，資料不落地且自帶機率信心度的決策模型，才是企業級 AI 應用真正具備高性價比的架構選擇。

DEV Community