实测Jev对比三款廉价模型：成本优势没那么大

一次“较真”的基准测试

关于 TypeSafe 的 Jev 决策模型，市面上流传的数字大多来自厂商自己。为了拿到独立数据，一位开发者在同一网关上对 Jev 1.13、Mistral Small 3.2、Gemini 2.5 Flash Lite 和 GPT-5 nano 做了同场对比：八个固定测试用例，每个模型跑五轮，合计每模型 40 次请求。

结论没有传闻中那么夸张：Jev 确实更便宜也更快，但倍数远没有“100 倍”那么惊人。更耐人寻味的是，作者在测试过程中发现自己最初的两个结论站不住脚，最终公开了两条更正。这种“先质疑厂商、再质疑自己”的过程，比单一跑分更有参考价值。

成本与延迟：真实差距是 1.4 到 1.7 倍

先看硬数据。在成本维度上，Jev 1.13 的平均单次成本为 $0.0000188，Mistral Small 3.2 为 1.4 倍，Gemini 2.5 Flash Lite 为 1.7 倍。也就是说，面对同样廉价的聊天模型，Jev 的成本优势只有个位数倍数区间，而不是营销话术里的量级差距。

延迟方面，Jev 的中位响应时间为 352 ms，Mistral 为 1,343 ms，Gemini 为 877 ms，GPT-5 nano 则高达 7,504 ms。GPT-5 nano 的成本是 Jev 的 18.3 倍，其中绝大部分消耗在推理 token 上。只有在对比推理模型和前沿模型时，Jev 的倍数才会变得夸张——某个测试用例中，GPT-5.6 Sol 的成本是 Jev 的 32.5 倍，Opus 5 达到 184.9 倍。

这提示了一个容易被忽略的选型逻辑：Jev 的性价比优势，主要出现在“你本来打算用推理模型”的场景，而不是“你本来就在用廉价聊天模型”的场景。

准确率：Jev 并没有赢

在 27 条带有明确正确标签的支持工单上，每个模型跑三遍。Jev 1.13 和 Mistral Small 3.2 都拿到了 27/27，Gemini 2.5 Flash Lite 和 GPT-5 nano 为 26/27。换句话说，“Jev 更准确”这一说法在本轮测试中得不到支持。

Jev 真正区别于聊天模型的地方，是它输出了一个置信度数值。在清晰工单上置信度为 0.979，在六条刻意设计的模糊工单上降到 0.841。方向是对的，但落差比“按阈值路由”所需的幅度要小——如果你打算靠置信度做流量分发，这个区分度可能不够用。

置信度校准与阈值路由

置信度（confidence）是分类或决策模型对自身判断给出的概率估计，取值范围通常在 0 到 1 之间。它本身不提升准确率，价值在于支持“按置信度分流”：高置信度请求自动处理，低置信度请求转人工或升级到更强的模型。

这套机制能否奏效，取决于置信度是否“校准”——即模型说 0.9 时，实际正确率是否真的接近 90%。如果模型在清晰样本上给 0.98、在模糊样本上仍给 0.90，区分度不足，阈值路由就退化为随机分流，反而增加系统复杂度。

文章观察到清晰工单置信度 0.979、模糊工单 0.841，方向正确但落差偏小，正是校准不足的典型信号。评估置信度时，常用的手段是可靠性图（reliability diagram）与期望校准误差（ECE），而不是只看平均值。对打算用置信度做流量分发的团队，建议先在自有数据上画出这条曲线，再决定阈值取在哪里。

两条更正：结构化输出和温度才是元凶

作者最初得出的两个结论，后来都被自己推翻了，这也是整篇文章最值得读的部分。

更正一：“类型不可靠”是测试配置问题。 初版文章称聊天模型无法稳定返回声明类型，比如 Gemini 在被要求输出概率时返回了 true，GPT-5 nano 返回了字符串。真相是结构化输出没有开启。仅加上 response_format: { type: "json_schema", strict: true } 这一处改动，Gemini 从 2/5 提升到 5/5，GPT-5 nano 从 4/5 提升到 5/5。类型安全只是请求体里的一行配置，不构成选择 Jev 的理由。

更正二：轮次间漂移来自采样。 在默认温度下，聊天模型在完全相同的输入上给出了不同答案（Gemini 为 26、25、26，GPT-5 nano 为 24、26、26）。把 temperature 设为 0 之后，所有模型三轮得分完全一致。所谓“不稳定”，其实是采样随机性，而不是模型能力缺陷。

两项更正之后依然成立的，只有延迟和成本。在开启 schema 的支持工单用例上，Jev 耗时 386 ms，Gemini 896 ms，Mistral 1,672 ms，GPT-5 nano 7,006 ms。

这份测试能说明什么，不能说明什么

作者本人对局限性的交代相当克制：一台机器、一个下午、一个网关、每格五次运行；27 条工单由作者自己撰写，只覆盖单一任务，且仅限英文。用他的话说，这足以推翻一个泛化结论，但不足以建立一个泛化结论。

对技术选型者而言，这份测试的价值不在于给出“该不该用 Jev”的答案，而在于示范了一种方法：把厂商数字放到自己的网关和任务上复现，把请求参数（结构化输出、温度）纳入变量控制，并且在结果不利于自己的初始判断时，愿意公开更正。

完整的表格、逐用例延迟、厂商原始数字以及若干独立复现，都放在 jev-agent.com/benchmarks；复现脚本可通过 python3 -m bench.headtohead --repeats 5 和 python3 -m bench.accuracy 运行。作者也声明自己运营 jev-agent.com，与 TypeSafe AI 无关联。

背景补充

结构化输出与 JSON Schema 严格模式

结构化输出（Structured Outputs）是当前主流大模型 API 提供的一项能力：开发者可以在请求中附带一个 JSON Schema，要求模型返回的 JSON 必须符合该 schema 的字段、类型和必填约束。OpenAI 的 response_format: { type: "json_schema", strict: true } 就是这一机制的具体实现，strict: true 表示服务端会对模型输出做语法层面的强制校验，不满足 schema 时直接拒绝或重试，而不是仅在提示词里“建议”模型遵守。

这与传统的“在 prompt 里写请返回 JSON”有本质区别：后者依赖模型自觉，类型漂移、多余字段、布尔与字符串混淆都很常见；前者把约束下沉到解码或后处理层，可靠性大幅提升。文章中的更正之所以成立，正是因为初版测试只用了提示词约束，而没有启用 schema 严格模式，导致把配置缺失误判为模型能力缺陷。

需要注意的是，严格模式通常要求 schema 本身足够简单（避免过深的嵌套和复杂的联合类型），且各厂商对支持范围的差异较大，跨模型对比时必须逐一确认是否真正生效。

温度参数与采样随机性

大模型生成每个 token 时，会对词表输出一个概率分布，再按某种策略从中采样。temperature 控制的就是这个分布的“陡峭程度”：温度越高，低概率 token 被选中的机会越大，输出越发散；温度趋近 0 时，采样退化为近似贪心解码，每次选择概率最高的 token，因而在相同输入下结果高度可复现。

因此，默认温度（常见为 1.0 或 0.7）下同一输入多次运行得到不同答案，是采样机制的正常表现，而非模型“不稳定”或“能力退化”。文章把温度设为 0 后三轮得分完全一致，正是这一机制的直接验证。

实践含义有两点：其一，做基准测试或需要可复现结果的场景，应显式设置 temperature: 0（部分厂商还提供 seed 参数进一步固定随机源）；其二，面向用户的对话产品反而需要保留一定温度，否则回答会显得刻板重复。混淆这两个场景，就容易把设计选择误读为质量缺陷。