Kev 每次给出相同答案，直到你进行批量处理

这是 jev-决策模型 系列的第二部分。第一部分将七款开源的 Jev 仿制品部署在单张 8 GB 显存的 GPU 上。本次跟进测试了冠军模型在重复运行中是否保持答案一致、“确定性”模型在高并发负载下的表现，以及我们对 headline（主要）数据的把握程度——此外还有一位新选手加入：Julia-1。

Mark Vange · Autom8ly · 2026年9月 · 7分钟阅读

主要由 AI 撰写。与第一篇文章一样，本文及其背后的分析 largely 由我们的 AI 助手（Autumn）生成，并由我指导。所有数据均来自真实运行，脚本和预测结果均已公开。

上周晚些时候，我写了关于在单张 8 GB GPU 上运行 Jev 仿制品的文章。其中表现最好的是 Kev-4B（量化至 4-bit），得分为 0.872，而 Jev 的得分为 0.968；其置信度看起来足够可信，可以自动化其约四分之三的决定。

Poisson Labs 创始人 Taylor Kolasinski 读了这篇文章并提出了关键问题。他们的团队刚刚发布了《两次相同的请求》，这是一项针对 Jev 的重放研究：发送多次相同的请求，看看答案是否保持一致。事实往往并非如此。在接近决策阈值的项目上，Jev 在 0.5 或 0.6 的截断值下有 18.5% 的决定发生了翻转，在 0.9 的截断值下有 5.3% 发生了翻转；由于翻转方向相反，聚合数据看起来完全稳定，但个体决定却在底层发生了变化。

Taylor 向我们提出的问题，转述如下：

1. 本地模型在重复运行中是否保持了概率的一致性？消费级 GPU 上的量化模型并不总是确定性的。
2. “75% 自动化”这一数字依赖于置信度阈值保持不变。它真的不变吗？
3. 0.872 是在多少问题上测量的？与 Jev 的差距区间是多少？

第一个问题竟然有两个答案，而第二个问题才是有趣的所在。

一次一个请求：逐次重复，完全相同

9 月 28 日，我们向 Kev-4B 4-bit 再次发送了同样的 866 个问题，每次仅发送一个请求，并将每个答案与 9 月 26 日的原始运行结果进行比较。

我们检查了没有伪造行为。我们的网关没有响应缓存，Kev 的服务器仅缓存最近四个输入，因此在重复之间涉及 866 个不同的输入，每个答案都是从头计算的。Kev 的 API 将概率四舍五入到小数点后四位，因此“相同”意味着在该分辨率下完全相同。

高负载下：批处理改变了数值

生产流量并非一次到达一个请求。Kev 的服务器会收集所有等待的请求，并将它们作为一批通过 GPU 一起运行。因此，我们再次运行了整个套件，分别以 2、4、8 和 16 个请求同时发送的方式，并在 8 个请求的情况下再运行一次，以查看批处理运行结果是否彼此一致。

按每个请求实际运行的批次大小分组，线条非常清晰。在第一次以 8 个请求运行的实验中，116 个单独运行或成对运行的请求中没有任何一个发生变化，而 735 个以 7 个为一组运行的请求中有 311 个发生了变化。在所有运行中，2,015 个单独运行或以两三个为一组运行的请求全部比特级一致；而在五个或更多为一组的批次中，2,315 个请求中有 1,223 个发生了变化。（恰好没有形成正好四个请求的批次。）

两次以 8 个请求进行的批处理运行在 866 个问题中的 403 个上存在分歧，因为哪些请求落入同一批次取决于时间因素。因此，在高负载下，Kev 不再可重放：同一个请求可能会返回略有不同的数值，具体取决于与其一同运行的其他请求。这与 Poisson Labs 在 Jev 上测量到的行为属于同一类，尽管规模小得多。

对决定的影响很小。在三次批处理运行中，2,598 个答案中有 2 个改变了首选选项，其中有一个将正确答案变成了错误答案，这就是为什么某次运行得分仅为 0.8707 的原因。这两次翻转都发生在两个选项几乎持平的问题上：在一个语法问题上，前两个选项的概率从 0.3013 和 0.3042 变为 0.3043 和 0.3040。没有任何答案跨越了 0.9 的界限。

批处理带来的收益 barely 抵消了成本。同时发出十六个请求虽然让 GPU 的吞吐量提高了 45%，但每个请求的等待时间却几乎延长了十倍。在这款小型显卡上，模型一次只处理一个请求时就已经能很好地利用 GPU 了。

至于原因，据我们推测，而非通过追踪得出：GPU 的算术运算并非完全满足结合律，较大的批次可能会以不同的顺序进行拆分和求和。Kev 的服务器也以不同方式处理更大的批次，这与我们观察到的陡峭曲线相符。

如果需要为审计员重新回放某个决策，请保持批次较小，或者记录模型实际返回的概率。安静服务器上的确定性并不等同于生产环境中的确定性。

75% 这一项并未使用 90% 的阈值，但它显得过于乐观

我们本应在第一次就解释清楚。“在 5% 错误率下可自动化”并不意味着使用 90% 的阈值。它是将答案按置信度从高到低排序，并在接受的答案中错误率保持在 5% 或以下的前提下，尽可能多地接受答案。阈值即为由此得出的数值。

Taylor 的直觉仍然是正确的：我们在用于评分的相同 866 个问题中选择了该阈值，这对其有利。如果正确操作，即在随机的一半数据上选择阈值，并将其应用于另一半数据，重复 2,000 次：

覆盖率依然稳固。需要关注的是错误率部分：目标是 5%，而在大约 430 个新样本的决策中，结果可能落在 2% 到 8.7% 之间。如果 5% 是硬性限制，请在您自己的标注数据上设定更低的预算。

有多少问题，以及我们的把握有多大

该套件包含 49 个任务共 866 个问题，每个案例一个问题。对案例进行重采样可得这些 95% 置信区间：

与 Jev 的差距是真实的：即使在区间的边缘，差距也超过七个百分点。Kev 的 0.1% 置信错误率仅对应一次错误，因此真实错误率有可能高出数倍。它仍然很低；只是不像小数所暗示的那样精确。

矩阵中的新成员：Julia-1

Supersonic Labs 于 9 月 26 日发布了 Julia-1：这是一个拥有 1.44 亿参数的决策模型，基于多语言 ModernBERT 编码器构建，采用 Apache-2.0 许可证，体积小巧，可在笔记本电脑 CPU 上运行。其模型卡片报告称在 Supersonic 自家的键入式决策基准测试中击败了 Jev（73.2% 对比 72.7%）。我们使用官方检查点和运行时，对其进行了与其他模型完全相同的测试。

在我们独立的套件中，Julia-1 得分为 0.450，且在其至少 90% 确信的情况下，有 30% 的答案是错误的。它在三次重跑中表现出确定性且速度非常快，但其“是/否”答案完全没有区分度：当正确答案为“是”时，其平均 P(yes) 为 0.36；当正确答案为“否”时，平均 P(yes) 为 0.37。此外，它对措辞非常敏感，而其他模型则不然。在一个明确的退款问题上，作为裸问题提问时，它给出 P(yes) 为 0.005；加上简单的“是/否”描述后，P(yes) 变为 0.997。在整个套件的所有“是/否”问题中添加“No”和“Yes”的描述，使其准确率保持在 0.449 不变，但翻转了 101 个单独的答案。

在发布前，我们检查了可能导致这是我们失误的因素：权重文件与 Supersonic 自身结果上的校验和匹配，输入长度设置没有产生差异，且他们的 README 示例路由正确。我们最好的解释是，Julia-1 针对其训练和评估所用的基准分布进行了调整。Supersonic 称其为“我们训练系统的首次发布测试”，而首次发布理应被如此评判。就目前发布版本而言，我们不会将其用于重要的决策。

我们从中学到了什么

可重复性是部署的属性，而非模型的属性。Kev 在逐次请求以及最多三个的批量中实现了比特级精确（bit-exact），但在五个或更多的批量中出现了漂移。请在你实际运行的负载下测试确定性。

漂移幅度很小；关注关键之处。在 2,598 个批量回答中仅有两处顶级答案发生变化，且均发生在势均力敌的边缘情况。正如 Poisson Labs 为 Jev 所建议的那样，将阈值附近的狭窄区间视为“重新询问或交由人工处理”。

在保留数据上选择阈值。我们公布的覆盖率通过了严格的划分测试，但实际实现的错误率波动比单一数值所暗示的要大。

在别人已有的基准测试上测试新模型。Julia-1 自身的数字与我们的数据讲述了截然不同的故事。

再次感谢 Taylor Kolasinski 和 Poisson Labs。他们的问题促成了迄今为止我们对这些模型最有价值的认识。我们列表中的下一个目标是 imajev，这是一个开放的、兼容 Jev 且同样接受图像输入的模型。

关于本文。本文及其背后的代码主要由人工智能生成（主要来自 Anthropic 的 Claude，配合 Autom8ly 的内部提示词和技能），由我进行指导。所有 Kev 的运行均于 2026 年 9 月 26 日和 28 日在一块 NVIDIA RTX 4060（8 GB）上进行，Kev-4B 使用 bitsandbytes 以 4 位加载，并使用我们工具无关的 gutcheck 评分器在 jabr/classifier-benchmark v2 上进行评分。Julia-1 是 SupersonicLabs/Julia-1 的 a85b1273 版本（权重 SHA-256 df853bf7…），在其自带的 Python 运行时中以 CPU 严格编码方式运行。我们与 TypeSafe、Poisson Labs、Supersonic Labs 或任何被测试的项目均无隶属关系。

方法细节。并发运行通过我们的网关发送 N 个同时请求的突发流量，速率控制在每分钟约 55 个请求。每个请求的批量大小是根据在同一突发中报告相同服务器模型时间的请求推断得出的。接近阈值的集合是指原始运行中最高概率落在 [0.45, 0.55) 或 [0.85, 0.95) 区间内的问题；翻转是指答案改变或跨越截止线。区间是基于案例的 95% 百分位自助法置信区间；保留覆盖率使用 2,000 个随机 50/50 划分。对于 Kev 的 transfer-v4 套件，其中某些选项没有描述，我们的 Julia-1 适配器使用该选项的名称，正如 Jev 所做的那样。

代码和数据。所有内容均在 github.com/Autom8ly/gutcheck-bench：包括重跑和并发客户端、每次运行的预测结果以及 stability/ 目录中的分析脚本、adapters/julia_server.py 中的 Julia-1 适配器，以及 results/ 目录中与其他每种设置并列的结果。运行 python stability/analyze.py 可复现重跑、批处理和区间图表。