Kev-0.8B

模型摘要

Kev-0.8B 是一個決策模型。它讀取一份文件（狀態）和一組關於它的帶型別問題，並在一次前向傳播裡返回每個問題所帶選項上的校準機率分佈，不生成文本。它實現 TypeSafe 公開的 System One API（POST /v1/systemone），所以 TypeSafe SDK 可以原樣對它使用。它是最小的 Kev：Qwen3.5-0.8B-Base 上的一個 LoRA 介面卡和一個指標頭，能跑在筆記本或 4 GB GPU 上。它適用於記憶體或成本排除了更大規模的場景，且任務與它訓練過的相似；域外它明顯不如 Kev-4B 準確。本卡描述 Kev 1.0 中的這個 checkpoint，首次釋出於 2026-09-24。

模型詳情

輸入。 一個 state（文本，或渲染為帶標籤文本的 JSON 物件或陣列）和任意數量的具名問題，每個問題屬於三種類型之一：

每個問題都作為它自己的一行作答，從共享 state 續接，所以問題之間不能相互影響；state 只計算一次並快取。

預期用途

• 與它訓練家族相近的帶型別決策（文件分類、路由、基於明示規則的政策檢查），跑在裝不下 Kev-4B 的硬體上：筆記本、L4 或 4 GB GPU。
• 在訓練成本重要的場景下，作為在使用者自己標籤上微調的起點（kev.train --init_from jaredpalmer/kev-0.8b）。
• 在轉向更大的 Kev 之前，對著 System One API 做原型。

範圍外用途

• 文本生成、對話、摘要或開放式問答。模型只對它被給出的選項打分。
• 工具呼叫路由（是否呼叫工具、請求缺失參數還是拒絕）：它的 When2Call 準確率低於隨機（見 侷限）。
• 未經人工複核、對人有法律、醫療、金融、僱傭或類似後果的全自動決策。
• 知識密集型問題、日期算術、超過 65,536 tokens 的 state，以及英語以外的語言。

如何使用

用 Kev 倉庫服務它。在 CUDA 上它以 bf16 執行，帶融合 DeltaNet 核心和 CUDA graphs（一張 L4 就夠）；在 Apple Silicon 上同一命令會通過 MLX 服務它，自動選擇。

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-0.8b --port 8008        # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-0.8b@v1.0 --port 8008   # the same weights, pinned

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

校準溫度預設施加；KEV_TEMPERATURE=1.0 返回原始機率。KEV_DTYPE=fp32 選擇用於評測的確切路徑。超過 65,536 tokens 的 state 會被拒絕，返回 422 並給出其 token 數。

訓練資料

兩個微調階段分別回放 decision-v7 的 2,000 和 6,000 條記錄。沒有使用任何 Jev（TypeSafe 的託管決策模型）的輸出。CodeReviewer 和 FlakeFlagger 來自 Zenodo；CFPB 敘述是美國政府作品；逐來源許可證和 revision 記錄在套件 manifest 裡。下面的評測專用套件（breadth-v1、tasksource-heldout-v1、transfer-v4、longdoc-v1，以及 devtools-v1 的 When2Call 和 prompt-injection 來源）從不進入訓練。

訓練流程

1. 基礎配方。 從基座在 decision-v7 上兩個 epoch：LoRA rank 16，α 32；學習率 1e-4，one-cycle 排程；batch 8；bf16 autocast；seed 2。損失是在每個問題的選項上的交叉熵。選項順序打亂，隨機插入「none of the above」選項和干擾項，另有四分之一的 choice 記錄產生一個最小對（帶「none of the above」選項的那個問題，一次把正確選項放進去、一次把它移除）。
2. 日期與缺失證據。 從階段 1 起一個 epoch，學習率 4e-5，回放 2,000 條記錄。
3. 文件與技能。 從階段 2 起，在三個訓練集上一起一個 epoch，學習率 2e-5，回放 6,000 條記錄；batch 4 × 2 累積；state 最多 7,552 tokens；梯度 checkpointing；seed 1；2,818 個最佳化器步。
4. 校準。 單個溫度，T = 2.35，在階段 3 試驗的 decision-v7 開發行（1,264 個問題）上最小化負對數似然。這些是一個訓練語料的留出條目。在留出資料集上的一次重擬合經過評測但未採用（見 校準）。

評測

方法。 除非另有說明，每個數字都是釋出溫度下的 fp32 評測路徑。開發劃分用於選擇；測試劃分為本 checkpoint 讀過一次；transfer-v4 測試是鎖定的（每個候選讀一次），並對照事先固定的門檻評判。配對區間是 95 % bootstrap，重取樣整條記錄（2,000 次重取樣），所以共享同一 state 的問題一起移動。差值以百分點（pp）計。Jev（TypeSafe 的託管模型，經 Vercel AI Gateway 查詢）只在與它讀過同一批條目的地方給出。套件如下：

• breadth-v1：五個領域（知識、語言、檢索、工具、藝術）的 14 個留出公開資料集，從未訓練。
• tasksource-heldout-v1：一個公開多工集合的 24 個整任務家族，從未訓練（家族名不公開）。
• transfer-v4：來自六個從未訓練的公開來源（QNLI、SciQ、TweetEval-offensive、PAWS、MMLU、Emotion）的域外決策，加上留出的政策和規則結構。
• hard-v1：上述技能家族；測試劃分留出已訓練生成器的模板。
• devtools-v1：來自六個經許可證核查的來源的開發者工具決策（四個訓練，兩個僅評測）。
• documents-v1 / documents-v2：CFPB 投訴敘述；v2 是私有的留出測試集。
• longdoc-v1：CUAD 商業合同和生成的協議包，state 4k 到 64k tokens。

標為「audited（審計）」的頭條面板排除標籤審計認為不健全的條目¹；每次排除都會從比較雙方移除相同的行。

留出資料（從未訓練）。

已訓練家族（留出條目與模板）。

Jev 的 devtools-v1 數字是在全部 1,074 個開發問題上；Kev 的行去掉了一個被套件構建器複用到兩條記錄（2 個問題）上的 CodeReviewer id。

對照上一版本（tag night2-du-release，在其自身溫度 2.41 下；註冊的判據，每個測試讀一次）：

長期文件。

• 已驗證上下文長度：8,192 tokens，即訓練長度。16k 桶超出容差：其下界為 −8.5 pp，低於 −3 pp，所以沒有更長的長度被驗證。
• 規則，讀數之前固定：已驗證長度是從 16,384 tokens 起向下的最大桶的名義大小，使得它以及它與 8,192 之間的每個桶都在容差內。在容差內意味著與 8k 桶（state 6,553–7,618 tokens，即訓練長度）相比 CUAD 準確率差，在同一合同、重複和問題上配對，其 95 % 下界至少為 −3 pp，且每條記錄都被作答。若 16k 桶失敗，已驗證長度為 8,192 tokens。

按名義 state 長度的 CUAD 準確率、ECE 和與 8k 桶的配對差（longdoc-v1 開發）：

在釋出溫度 T = 2.35 下的 ECE。Δ 在兩種長度上問及同一合同的 445–447 個問題上配對。4k 桶裝著不同的合同，不是該規則的參考。來源：runs/r28-readout/context.json（第 28 輪註冊的讀數，runs/r28-08b-r15-longdoc）。

校準（期望校準誤差，ECE，在釋出溫度 T = 2.35 下；越低越好）：

釋出的溫度是在一個訓練語料的留出條目上擬合的，專案規則已不再允許用於新發布。在來自留出資料集的 648 個問題上的一次註冊重擬合（transfer-r3 的校準劃分，八個來源，加 200 個 MMLU-Pro 問題）給出 T = 2.52（90 % bootstrap 區間 [2.19, 2.83]）。在 4,468 個審計過的 breadth-v1 和 tasksource-heldout-v1 開發問題上它校準更好：ECE 0.037 對 0.048，Brier 低 0.0020 [0.0014, 0.0025]。它在已訓練家族上更差，各自都超出註冊容差 0.005：hard-v1 ECE 0.124 對 0.112，devtools-v1（審計）0.099 對 0.092，documents-v1 0.078 對 0.059。因此這次重擬合不合格，T = 2.35 保留。工作負載更像留出公開資料集而非 Kev 訓練家族的使用者，可以用 KEV_TEMPERATURE=2.52 以重擬合值服務它；答案不依賴 T。

其他結果。

服務。 CUDA，bf16 配融合核心和 CUDA graphs，在一張 L4 上；每個請求的模型時間（20 次中位數），新 state / 重複 state：短 state 六個問題 22.7 / 16.1 ms，2,200-token state 五個問題 108.6 / 32.3 ms；64 個客戶端下 62.8 請求/s。常駐 GPU 視訊記憶體 3.8 GB。在 280 個問題上，服務的機率與 fp32 評測路徑保持在 0.017 以內，有 1 個答案改變。

Apple Silicon（MLX，bf16，32 GB 的 M5；三個問題，其中一個問一個種在 60 % 深度的事實；state 以 1,024-token 塊預填充）：

與同樣請求下 CPU 上的 fp32 PyTorch 相比，MLX 的答案在 8k 時最多差 0.0076、在 16k tokens 時差 0.0052，沒有答案改變。在 100 個短 state 問題上，MLX 路徑與 fp32 評測路徑保持在 0.020 以內，有 1 個答案改變。

¹ 從審計面板中排除：四個 breadth-v1 資料集（routerbench，其 state 缺少所問的資訊；cfcolor 和 humicroedit，對每個系統都處於隨機水平；chessbench，對每個系統都處於下限）；七個標籤無效或無法恢復的 tasksource-heldout-v1 家族（名字不公開）；兩個 state 無法決定其標籤的 devtools-v1 任務（flakeflagger、commit 變更型別）。

² 社群 Decision Index 0.2 的隨機校正指數：每個資料集 (score − chance) / (1 − chance)，在每個領域內取平均，然後 100 × 五個領域的均值。Jev 的指數來自對同一批測試條目的單獨一次讀取。

侷限與取捨

• 域外它是一個 sub-1B 模型。 在 transfer-v4 開發上它落後 Jev 21 個點，在 breadth-v1 指數上落後 31 個點；知識（MMLU-Pro 0.230）和複述接近未訓練的基座。準確率重要時請用 Kev-4B。
• 它的增益在分佈內。 documents-v1、hard-v1 和 devtools-v1 的訓練劃分就在其訓練資料裡；在 JevBench 公開 hard 檔這個分佈外檢查上，documents-and-skills 階段讓它 +2.7 pp [−1.8, +7.2]，與零不可區分。
• 工具呼叫路由變差了。 When2Call 這個僅評測來源，在開發上從 0.260 掉到 0.167，在測試上從 0.233 掉到 0.133，低於其四個選項中四分之一的猜測率。不要用它做工具呼叫路由。
• 一個 devtools-v1 結果無法解釋。 FlakeFlagger 在開發上從 0.500 變到 0.520，但在測試上從 0.507 變到 0.813，每個劃分 150 個問題；把它當作無法解釋，而非一項技能。
• 日期算術是它最弱的家族：在 deadline 政策問題上 0.35，對 Jev 的 0.95；KEV_DATE_FACTS=1 前處理器對更大的模型幫助比對它更大。
• 規則組合很弱：留出政策最小對的兩兄弟都答對 0.422 的時間。
• 校準是一個分佈內溫度（見 校準）。它無法重排置信度順序：域外 ≤ 5 % 誤差下的覆蓋率為開發上的 0.145，對 Jev 的 0.70，所以在嚴格誤差預算下能自動化的決策很少。
• 未訓練的長度。 訓練 state 最多 7,552 tokens。更長的 state 可服務到 65,536 tokens；準確率保持多遠就是上面的已驗證上下文長度。
• 選項順序可能改變答案；問題隔離並不能阻止這一點。

偏見、風險與倫理考量

• 校準機率可能製造不當的信任。溫度是在訓練分佈的開發行上擬合的，不遷移到每個工作負載；在設閾值之前，在你自己的標註樣本上測量準確率與校準，並在那裡重擬合溫度（python -m kev.calibrate）。
• 準確率和校準會隨領域變化而偏移，在這個規模上比在更大規模上更明顯。請監控生產錯誤率，而不是依賴上面的數字。
• 未經人工複核，不要用它做關於人的有後果的自動決策。基座模型和訓練資料的偏見（包括其他模型產生的標籤）未被測量。
• state 可能包含個人或機密資料。自託管把輸入留在你自己的硬體上；除非設定了 KEV_API_KEY，伺服器是開放的，所以請應用你自己的訪問控制與資料處理策略。

算力

• 基礎配方：在一張 NVIDIA H100 上約 20 分鐘。日期階段：9 分鐘。
• 文件與技能階段：在一張 NVIDIA H200 上 52 分鐘（峰值 23.9 GB）。
• 評測與服務檢查：Modal 上的單張 H100 / H200 / L4 GPU；MLX 測量在一臺 Apple M5 上。

溯源與可復現性

• 程式碼、套件與評測報告：github.com/jaredpalmer/kev。釋出數字：runs/release/kev-08b-r15.json（scripts/release_numbers.py --release kev-08b-r15），鎖定讀數 runs/locked/kev-08b-r15-ungated/，2026-09-30 家族讀數 runs/fam-08b-breadth/、runs/fam-08b-breadthtest/ 和 runs/fam-breadth-test-report/，校準重擬合 runs/r28-readout/round28.json，服務 runs/serve-08b-l4/、runs/mlx-long-states/、runs/mlx-full-0.8b/。
• 階段：基礎試驗 q35-08b/02-trial-2（tag v7-base）；日期 night2-08b-du2/00-trial-0（tag night2-du-release）；文件與技能第 15 輪 r15-08b/00-trial-0（experiments/round15/joint.json，規則 experiments/rounds/r15.json）。校準重擬合：第 28 輪臂 08b-r15（experiments/rounds/r28.json）。
• 釋出的權重：Hub revision 9a45d25e；介面卡 sha256 9b908623…，head.pt sha256 f400bd12…（T = 2.3511）。
• 釋出歷史：2026-09-24 作為第 15 輪確認的候選釋出；在 Kev 1.0 中原樣包含。它是如何被選出的記錄，包括此後作為不健全而退役的套件（scienthoon、WANLI-v2、TypeSafe），是 Hub revision 9a45d25e 上的 README 和 git tag research-archive-2026-09-24 上的 PLAN.md。

引用

@misc{palmer2026kev08b,
  title        = {Kev-0.8B: a calibrated decision model on Qwen3.5-0.8B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-0.8b}},
  note         = {Kev 1.0}
}

聯絡

問題與 issue：github.com/jaredpalmer/kev/issues。