Kev 1.0

Kev 1.0 是整個 Kev 家族的首個帶版本號的釋出：四個決策模型讀取一份文件和一組帶型別的問題，在一次前向傳播裡返回各選項上的校準機率，執行在 TypeSafe 的 System One API 之後。其中沒有任何新訓練的內容。它把下一代 Kev 用來對標的 checkpoint、模型卡、評測套件和服務程式碼固定下來，每個 Hub 倉庫都打上同一個 tag（v1.0）。

1.0 裡有什麼

頭條數字（fp32 評測路徑，每個模型都在其釋出的溫度下；transfer-v4 測試是鎖定的，每個模型只讀一次）：

hard-v1、devtools-v1 和 documents-v1 的訓練劃分是每個 Kev 都訓練過的：那幾行測的是已訓練家族的留出條目，不是遷移。breadth-v1 和 transfer-v4 那幾行是沒有任何 Kev 訓練過的資料集。Jev 只在開發劃分和 breadth-v1 測試上讀過。每個數字都通過 docs/claims.json 追溯到一份提交的報告；模型卡（docs/model-cards/）裡有其餘部分，附帶區間。

自上個家族釋出以來有什麼變化

以 2026-09-24 為當前家族首次整理時的 GitHub release kev-family 為基準（Kev-27B v1、Kev-9B v1，以及與此處相同的 Kev-4B 和 Kev-0.8B）。它 2026-09-30 的更新（Kev-27B v2、Kev-9B v2）也列在這裡，因為 1.0 正是它們成為帶版本號釋出一部分的地方。

• Kev-27B v2：完整權重。 把 Qwen3.8-27B 的每一個權重在一個 145,840 條記錄的語料上微調一個 epoch，再與 v1 按 0.85 / 0.15 平均。在測試上與 v1 相比：留出資料集 +1.2 pp [+0.3, +2.2]，留出任務家族 +5.3 [+3.7, +6.8]，技能、工具與文件 +8.9 [+7.5, +10.3]；鎖定的域外測試 0.889 對 0.896，Brier 0.154 對 0.160。在長合同上更差且過度自信（CUAD ECE 0.053 對 0.007）。v1 在 jaredpalmer/kev-27b@v1-lora。
• Kev-9B v2。 v1 加上在 Kev-4B 和 Kev-0.8B 已有的 documents 與 skills 資料上訓練一個 epoch。在測試上與 v1 相比：hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8]，documents-v1 +7.1 [+4.7, +9.2]；在鎖定的域外測試上持平（兩者都是 0.852），Brier 0.199 對 0.224。v1 在 jaredpalmer/kev-9b@v1。
• 不再靜默截斷。 伺服器過去會無聲地截斷超過限制的 state。現在它對超過 65,536 tokens 的 state 返回 422，並給出 token 數與限制；KEV_TRUNCATE_STATES=1 可以退回到截斷，而這樣一臺伺服器的每次響應都會帶上 truncated。deploy 與 fine-tune 技能把 KEV_REF 固定到包含此修復以及下面長文件和 MLX 改動的某個 commit（71d4829），Space 也在修復後重新發布。
• 每個規模的長期文件。 評測路徑對數學核心上的長行保留 fp32 注意力，所以 Kev-0.8B、4B 和 9B 在 32k–64k token 的 state 上會耗盡 GPU 視訊記憶體。現在長行在 fp32 下走省視訊記憶體核心：Kev-4B 在 H100 上以 17.2 s 讀取一個 61k token 的 state，權重之上佔用 17.2 GiB，而較短的行逐 bit 保留其 logits。正是這一點讓上面的已驗證上下文長度變得可測。
• Apple Silicon。 MLX 後端按儲存的樣子載入完整權重 checkpoint，不做合併，從而給 Kev-27B 一條 Mac 路徑（預計需要約 51 GB 加工作記憶體；尚未在該規模上跑過）。長期 state 以每次 1,024 tokens 預填充，快取會在一次前向之前逐出，所以 Kev-4B 在 32 GB M5 上以 13.0 GB 峰值服務一個 65,000 token 的 state（新 state 84.5 s，命中快取 716 ms）。
• 核心溯源。 每個評測報告和試驗現在都記錄其 logits 所依賴的核心集（包版本、GPU、dtype、注意力與 DeltaNet 實現），起因是發現評測映象裡的一次核心變更讓 Kev-27B v1 的讀出機率移動了 0.03–0.06，而 Kev 自身程式碼沒有任何改動。
• 評測審計。 三個套件因不適合用於選模型而被移除：scienthoon（模板化工單，有一個問題文本無法回答）、WANLI-v2 / WANLI-v1（四分之一的 gold 標籤是兩位標註者中一位的）以及 TypeSafe 的公開評測（gold 來自兩個閉源模型，問題太少）。頭條面板排除了審計認為無法回答或未標註的條目。過去幾次釋出在這些套件上的數字保留在其記錄裡，不在 1.0 的模型卡上。
• 校準。 Kev-4B 和 Kev-0.8B 釋出的是在其訓練資料留出條目上擬合的溫度。在留出資料集上的一次註冊重擬合對兩者都做了評測，也都沒有采用：它沒有改善 Kev-4B（Brier 差 −0.0001 [−0.0005, +0.0003]），還讓 Kev-0.8B 在其文件與技能家族上校準變差，超出註冊的容差。Kev-9B 和 Kev-27B 釋出的已經是留出資料集溫度。
• 訓練資料已公開。 documents-v1 和 hard-v1 的訓練劃分在 jaredpalmer/kev-suites 資料集中，所以小模型的訓練資料可以抓取並做 hash 校驗。
• 已驗證上下文長度。 每張模型卡現在都給出：在 CUAD 合同上的準確率與同一模型在 8k token 時相比保持在 3 pp 以內（95 % 下界）的最長 state。Kev-27B 保持到 65,536 tokens，即服務上限（其 64k 下界為 −2.4 pp）。Kev-0.8B、4B 和 9B 只驗證了它們訓練過的 8,192：三者在 16k 時都已超出容差（下界 −8.5、−3.4 和 −3.7 pp），所以超過 8k token 後，它們對長文件的回答不在該測量的覆蓋範圍內。
• 正式模型卡。 四張卡都遵循同一結構：摘要、詳情、預期用途與範圍外用途、如何使用、訓練資料與流程、評測、侷限、風險、算力、溯源。

已知侷限

• 分佈內增益。 去年的巨大增益出現在訓練劃分就在訓練資料裡的套件上。在沒有任何 Kev 訓練過的資料集上，Kev-27B 在 breadth-v1 測試上比 Jev 低 1.7 個指數點，較小的規模低 13–31 個點。
• 未訓練的長度。 Kev-0.8B、4B 和 9B 訓練時最多 7,552 tokens，Kev-27B 最多 32,768；伺服器接受 65,536。請使用已驗證上下文長度，而不是服務上限。
• Kev-27B 在長合同上不如 v1 準確且過度自信（CUAD 測試 ECE 0.053 對 0.007）；在自己的文件上重擬合溫度，或做合同審查時改用 @v1-lora。
• Kev-0.8B 與工具路由。 它的 When2Call 準確率在 documents-and-skills 階段後跌破隨機（測試 0.133）；不要用它做工具呼叫路由。
• 日期算術是 27B 以下每個規模最弱的家族（deadline 策略準確率 0.35 / 0.65 / 0.725，對 Jev 的 0.95）；KEV_DATE_FACTS=1 有幫助。
• 知識由基座決定（MMLU-Pro 0.230–0.675，對 Jev 的 0.840）。
• Kev-9B 在 Mac 上尚未測量，Kev-27B 在 Mac 上預計能裝進 96–128 GB，但尚未執行。
• 選擇。 Kev-27B v2 和 Kev-9B v2 是在已知更早的開發讀數的情況下，按審計後的規則重新選出的；它們的測試餘量偏樂觀。
• 每個模型只有一個溫度，無法重排置信度順序，所以在 5 % 誤差預算下，這些模型在域外自動處理的決策比 Jev 少。

如何執行

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-4b@v1.0 --port 8009    # CUDA, or MLX on Apple Silicon

從 release tarball：

shasum -a 256 -c SHA256SUMS.txt
tar -xzf kev-4b.tar.gz
uv run --extra serve python -m kev.serve --run kev-4b --port 8009

TypeSafe SDK 原樣可用：TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest")。Kev-27B 需要一張 B200、H200 或 H100 80 GB：--run jaredpalmer/kev-27b@v1.0。要在 Modal 上部署 HTTPS 端點，見 skills/kev-deploy。

資產

每個 tarball 裝著一個 checkpoint 在其權重 revision 上的樣子（LoRA 介面卡、帶溫度的 head.pt、tokenizer 檔案、訓練試驗的 result.json、provenance.json、training_config.json、training_metrics.json 和日誌），Kev 1.0 模型卡作為 README.md，以及鎖定的 transfer-v4 讀數為 locked_test.json。它們由 scripts/build_release_assets.py 從 docs/releases/kev-1.0-assets.json 構建，重新構建得到相同的位元組。其中每個檔案的日期都是 2026-10-01 00:00 UTC，kev.serve 會把它報告為解包 checkpoint 的釋出日期。首批於 2026-10-01 附上的 tarball 把檔案日期標成 1970-01-01，於是 kev.serve 報出 1969-12-31；它們在同一天被這批替換。權重和所有其他檔案逐位元組相同；只有 tarball 的 hash 變了。

Kev-27B 未附帶，因為它 51 GB 的權重超過了 GitHub 每個資產 2 GB 的上限。從 Hub 下載：jaredpalmer/kev-27b@v1.0（權重 commit 28be62e9，head.pt 7968f17b…）。

在每個 Hub 倉庫上，v1.0 tag 指向上傳 Kev 1.0 模型卡的那個 commit。該 commit 只改了 README.md，所以它的權重與第一張表裡的權重 revision 是相同的位元組：kev-0.8b bf75a6a8、kev-4b 6cfce5c2、kev-9b db029f08、kev-27b af0e6d55。

釋出計劃（給維護者；不屬於已釋出的說明）

已於 2026-10-01 完成（記錄 runs/release/kev-1.0.json；PLAN.md「Released: Kev 1.0」）。第 3 步和第 4 步：只改模型卡的 commit，每個模型卡 commit 上打 v1.0（0.8B bf75a6a8、4B 6cfce5c2、9B db029f08、27B af0e6d55；所有其他檔案不變）。第 5 步和第 6 步：資產生成兩次，hash 相同，release 已釋出並標記為 Latest。第 7 步：保留 kev-family，移除其資產，正文改成指向 kev-1.0 的指標，舊說明放在 runs/release/kev-family-notes-retired.md。第 8 步：pin 不變。第 9 步：collection 和 Space 已檢查；Space 未重新發布。釋出前寫就的計劃如下。順序：

1. 佔位符：已填（2026-10-01），來自第 28 輪註冊的上下文讀數 runs/r28-readout/context.json（scripts/longdoc_report.py --context-margin -0.03，作用於 runs/r28-{4b-r10,08b-r15}-longdoc、runs/r29-9b-r18a-longdoc 和 runs/r23-27b-k-w85-longdoc；原始 runs/r28-context，在釋出溫度下的 ECE runs/r28-context-served），數字在 docs/claims.json 中。

2. 合併本 PR。

3. Hub 模型卡。 每張 1.0 卡只作為 README.md 上傳（不帶權重）：只改模型卡的 commit 不需要 kev.publish；hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)"。用 HfApi().model_info(..., files_metadata=True) 檢查 adapter_model.safetensors / head.pt（27B：model.safetensors.index.json 和每個分片）的 hash 如下。

4. Hub tag。 四個倉庫上都打 v1.0。預設（如規定）：打確切的權重 revision；若第 3 步先跑了，就改打模型卡 commit，這樣 @v1.0 顯示的是 1.0 卡（權重逐位元組相同；兩個 commit 都記到 PLAN.md）。

   倉庫	v1.0 目標（權重）	介面卡 / 指標頭 sha256
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main（今天是 ef78cc8a34d5f426fb229c52089db189218cfe5c：權重 28be62e9，其後三個只改模型卡的 commit）	權重 d27af6ab… / 指標頭 7968f17b…

   hf repos tag create jaredpalmer/kev-0.8b v1.0 --revision 9a45d25eb2ab761841196625383fa1dff0e56c1e -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-4b   v1.0 --revision 139fdd94f1b6a6ad80cc15e08fcb99cac885a101 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-9b   v1.0 --revision b5d8c18e44c60888d138b65cb6507ff0a5a448a0 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-27b  v1.0 --revision <main at release> -m "Kev 1.0"

5. 資產。 uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets 構建 kev-0.8b.tar.gz、kev-4b.tar.gz、kev-9b.tar.gz（各自含：上述 revision 上的 Hub 快照，即介面卡、帶溫度的 head.pt、tokenizer 檔案、試驗的 result.json、provenance.json、training_config.json 和 training_metrics.json；1.0 卡作為 README.md；鎖定的讀數作為 locked_test.json），以及 SHA256SUMS.txt 和 manifest.json（每個成員的 sha256）。若某次下載的介面卡或指標頭 hash 與規格不符，它會拒絕。Kev-27B 不是資產（51 GB；GitHub 單個資產上限 2 GB）：說明指向 Hub。

6. GitHub release。 在合併 commit 上打 tag kev-1.0；以這些說明中已釋出的部分（本節以上全部）為正文建立 draft release，附上三個 tarball 和 SHA256SUMS.txt，下載回來跑 shasum -a 256 -c SHA256SUMS.txt，解包一個並服務它，然後釋出並標記為 Latest。

7. 每個規模一個 release。 釋出策略在一個 GitHub release 裡只保留每個規模的最佳版本。kev-1.0 釋出後，kev-family 與它重複：刪掉它的三個 tarball 和 SHA256SUMS.txt，正文改成指向 kev-1.0 的指標（或刪除該 release；由 Jared 定）。更早的版本留在各模型卡列出的 Hub tag 上。

8. 部署 pin。 skills/kev-deploy 和 skills/kev-finetune 固定 KEV_REF 71d4829；1.0 的 checkpoint 不需要更新的程式碼。只有當後續的服務修復應隨 1.0 一起釋出時，才移動這個 pin。

9. Collection 與 Space。 Kev collection 已經列出四個倉庫。Space 從 main 服務 Kev-4B 和 Kev-0.8B，那就是 1.0 權重；除非 kev/model.py、kev/api.py 或 kev/checkpoint.py 在上次釋出後改過，否則無需重新發布。