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 在上次发布后改过，否则无需重新发布。