Jev vs. Kev：开源Jev替代方案并排测试

# Jev 对比 Kev：一款开源 Jev 替代方案的并行测试报告 来源：https://opper.ai/blog/jev-vs-kev-open-decision-model 作者：Jose Sabater | 2026年9月25日 TypeSafe 于 9 月 15 日发布了 Jev (https://opper.ai/typesafe/jev-1-13-0)。这是一种新型模型：它不生成文本，而是读取一段状态信息，并针对类型化问题（是/否、选择一项、按标准评分）给出每个选项的概率答案。TypeSafe 尚未公开其架构或训练数据。发布后一周内，仅凭 API 规范就出现了约 30 个开源复现项目。 我们想了解这些复制品的实际效果究竟如何。因此，我们选取了由 Jared Palmer 开发的开放模型 Kev 4B (https://huggingface.co/jaredpalmer/kev-4b)，它是讨论度最高的复现版本之一。我们将其自主部署在欧盟地区，并将其接入与 Jev 在 Opper 上相同的端点。随后，我们用相同的问题测试了这两个模型。 **简而言之，我们的发现如下：** - **准确率相近。** 在两个模型发布后编写的 362 个问题上，两者在每个任务上的得分差距均在 2 个百分点以内，对于此规模的样本而言，这属于噪声范围。 - **令牌计数方式差异显著。** 相同的请求、相同的标价，但 Jev 在每个请求上都固定多计算约 257 个输入令牌。 - **速度相似。** 通过 Opper 平台，Kev 的回答时间约为 220 毫秒，Jev 约为 275 毫秒。 ## 统一端点，仅更换模型标识 Kev 使用与 Jev 相同的通信格式，因此对比测试只需更换模型名称： 将 `opper/kev-4b` 替换为 `typesafe/jev-latest`，其他一切保持不变：请求体、响应结构、概率结果以及每次调用的成本头部信息。 ## 关于 Kev Kev 4B（模型卡见 Hugging Face (https://huggingface.co/jaredpalmer/kev-4b)，代码见 GitHub (https://github.com/jaredpalmer/kev)）是 Jared Palmer 对阿里巴巴 Qwen3.5-4B-Base (https://huggingface.co/Qwen/Qwen3.5-4B-Base) 的微调版本，增加了一个小型头部，通过单次前向传播读取答案。该模型采用 Apache-2.0 许可证，并为每个选项返回概率值。我们将其部署在欧盟。 ## 为何我们构建自有测试集 通常会选择知名的公开数据集作为基准测试。问题在于，Kev 的训练数据已包含其中许多：AG News、Banking77、BoolQ、MNLI、SST-5、Yelp 评论、IMDb、Amazon 评论、DBpedia、TREC、ARC、OpenBookQA 和 CommonsenseQA。 我们尝试了部分数据集，正如预期，Kev 在多数任务上表现持平或优于 Jev。 因此，我们基于两个模型发布后公开的文本构建了一个小型新数据集：来自 arXiv 的最新论文、Stack Exchange 问题和 GitHub issues。两个模型都不可能见过这些数据。 ## 测试方法 **统一端点，每次请求一个问题。** 所有项目通过 Opper 平台的 `POST /v3/compat/v1/systemone` 端点以完全相同的请求体发送至两个模型，仅 `model` 字段不同：`typesafe/jev-latest` 或 `opper/kev-4b`。每个请求包含一个问题，同时进行 8 个请求，我们记录答案、延迟时间和 Opper 在每次调用返回的成本头部信息。 **数据集为模型未见内容。** 核心数据来自 362 个于 2026-09-20 之后发布（即 Jev 1.13 [2026-09-15 发布] 和 Kev 4B 均已上线后）的条目。真实标签来自原始出处，而非模型预测： | 任务 | 数据来源 | 问题 | 答案来源 | 数量 | |------|----------|------|----------|------| | arXiv 分类 | arXiv API (https://info.arxiv.org/help/api/index.html)，8 个类别的最新论文 | “这篇论文的主要研究领域属于哪个 arXiv 分类？”（8 个选项） | 论文的主要分类 | 160 | | Stack Exchange 站点 | Stack Exchange API (https://api.stackexchange.com/)，6 个站点的最新问题 | “这个问题发布在哪个问答社区？”（6 个选项） | 发布站点 | 120 | | GitHub 缺陷或功能 | VS Code、Godot、Rust、Windows Terminal、Ollama、Flutter 的新建 issues | “此问题属于缺陷报告还是功能请求？”（是/否） | 维护者标签 | 82 | 分类和站点数量已均衡（每项 20 个），GitHub 缺陷样本已下采样以匹配 41 个功能请求，并使用固定随机种子冻结数据集以确保所有模型看到相同的项目。两个实际示例： *发布在 Mathematics 站点的问题。Jev 回答 `math`，概率 1.00；Kev 回答 `math`，概率 0.93。一个 Rust issue (https://github.com/rust-lang/rust/issues/163145) 标题为“`f16b.rs` 在 LoongArch 上失败”，被维护者标记为缺陷。Jev 以 0.97 的概率判断为缺陷，Kev 则以 0.48 的概率犹豫不决，恰好落在判断线的错误一侧。* **评分标准。** 准确率统计首位答案（概率 >0.5 的是/否判断）。校准误差比较模型声称的置信度与实际命中率，基于 10 个区间计算，值越低越好。每千次调用成本为 Opper 每次调用成本头部信息的平均值乘以 1000，按测试时（2026 年 9 月）标价计算：两个模型均为每百万输入令牌 0.042 美元，输出免费。 辅助验证使用了 Kev 未训练的五个较旧数据集（emotion (https://huggingface.co/datasets/dair-ai/emotion)、offensive tweets (https://huggingface.co/datasets/cardiffnlp/tweet_eval)、QNLI (https://huggingface.co/datasets/nyu-mll/glue)、PAWS (https://huggingface.co/datasets/google-research-datasets/paws)、SciQ (https://huggingface.co/datasets/allenai/sciq)）。 ## 准确率与置信度 | 任务 | Jev 准确率 | Kev 准确率 | Jev 校准误差 | Kev 校准误差 | Jev 每千次调用成本 | Kev 每千次调用成本 | |------|------------|------------|--------------|--------------|--------------------|--------------------| | arXiv 分类（8 选项，n=160） | 96.9% | 95.0% | 0.032 | 0.044 | $0.030 | $0.015 | | Stack Exchange 站点（6 选项，n=120） | 97.5% | 98.3% | 0.027 | 0.125 | $0.026 | $0.012 | | GitHub 缺陷或功能（是/否，n=82） | 95.1% | 93.9% | 0.049 | 0.137 | $0.025 | $0.013 | 准确率差距仅几个百分点，处于此规模样本的噪声范围内。更明显的差异在校准性：Jev 声称的概率能较好反映其实际准确率，而 Kev 的偏离更大，在 Stack Exchange 和 GitHub 任务上尤为明显。 在五个较旧的公开数据集上，Jev 在复述检测（PAWS：87.0% vs 74.5%）以及 QNLI 和 SciQ 上略有优势；Kev 在情绪分类和冒犯性推文上领先。Kev 未曾训练这些数据，但其作者曾使用它们来选择最佳训练轮次，因此我们将结果视为次要参考信号。 ## 令牌计数的意外发现 两个模型在我们测试时（2026 年 9 月）标价相同：每百万输入令牌 0.042 美元，输出免费，且接收完全相同的请求。差异在于计费的令牌计算方式。我们将相同请求直接发送至 TypeSafe 和通过 Opper，计数结果一致，表明这是 Jev 自身的计费方式，而非我们的误差。文本长度增加对两个模型增加的令牌数相同，但 Jev 在每个请求上都固定增加约 257 个输入令牌（很可能是其内部提示词）。一条包含一个问题的单行消息在 Jev 上计为 280 个令牌，在 Kev 上仅为 23 个。 因此，每次调用的成本差距完全取决于输入长度： | 请求类型 | Jev 令牌数 | Kev 令牌数 | Jev 成本 vs Kev | |----------|------------|------------|-----------------| | 单行消息，1 个问题 | 280 | 23 | 12 倍 | | arXiv 摘要，1 个问题 | 约 720 | 约 360 | 2 倍 | | 长消息（约 40 句），1 个问题 | 960 | 703 | 1.4 倍 | | 长消息，1 次请求包含 5 个问题 | 1,030 | 777 | 1.3 倍 | 此开销是按请求计算，而非按问题计算。因此，在单次请求中对同一文本提问多个问题可摊薄开销。我们的基准测试采用每次请求一个问题，这对 Jev 是最不利的情况。 ## 速度测试 从斯德哥尔摩通过 Opper 逐一发送请求时，Kev 的响应时间约为 180-200 毫秒，Jev 约为 265 毫秒。在同时进行 8 个请求的情况下，Kev 的中位响应时间约为 220 毫秒，Jev 约为 275 毫秒。对两个模型而言，大部分时间消耗在网络传输而非模型本身。Kev 在空闲时会缩减资源，因此静默期后的首次调用会较慢。 ## 核心结论 一个开源复现项目，仅发布一周，且无法获取 Jev 的架构或训练数据，却在简单分类任务上达到了惊人的接近程度。其不足之处也完全符合预期：一个基于少量公开数据集训练的小模型，会在校准置信度、细微语义理解和长文档处理上表现欠佳。对比测试还揭示了一个我们未曾预料的发现：Jev 令牌计数中的每次请求固定开销。 两个模型均已上线 Opper 平台，位于相同端点，因此您可以自行用问题测试两者，看哪个更适合您的需求。 ## 注意事项 * 每个测试套件仅运行一次，项目数量为数百个。低于约 5 个百分点的差异属于噪声范围。 * 新数据集对两个模型而言都相对容易（准确率 95% 以上），这压缩了差异空间。更具挑战性的新任务可能会放大差异。 * 新数据不等于新任务类型：Kev 曾训练过主题分类、意图识别和是/否分类任务，尽管它未见过这些具体数据。Jev 的训练数据未公开。 * 在较旧数据集上，Kev 的作者曾使用 emotion、offensive tweets、QNLI、PAWS 和 SciQ 来筛选训练轮次，因此 Kev 在这些数据上的结果并非完全独立。 * Kev 为短输入（状态长度上限 384 个令牌）训练，会遗漏深藏在长文档中的细节。 * 延迟时间通过 Opper 平台从单一地理位置测量。 ## 相关链接 * Jev：docs.typesafe.ai (https://docs.typesafe.ai/models) 及 Opper 平台 (https://opper.ai/typesafe/jev-1-13-0) * Kev 4B：权重文件见 Hugging Face (https://huggingface.co/jaredpalmer/kev-4b)，代码见 GitHub (https://github.com/jaredpalmer/kev)，Opper 平台 (https://opper.ai/community/kev-4b) * 基础模型：阿里巴巴 Qwen3.5-4B-Base (https://huggingface.co/Qwen/Qwen3.5-4B-Base) * 端点地址：`POST https://api.opper.ai/v3/compat/v1/systemone` ## 复现方法 基准测试代码、测试项目列表及我们的结果已发布至 github.com/opper-ai/jev-vs-kev (https://github.com/opper-ai/jev-vs-kev)。拥有 Opper API 密钥后，可运行 `python3 fetch_texts.py`，然后执行 `SUITE=fresh python3 jev_vs_kev.py`。