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。