AREX Feed Article
OpenRouter 发布 Ori Eval 评测：Jev 评判中位延迟 154 毫秒，比第二快模型快逾 5 倍
模型分发平台 OpenRouter 于 9 月 19 日 20 时 47 分（UTC）发布七条推文的推文串，公布其评测工具 Ori Eval 对 TypeSafe AI 决策模型 Jev 的测试结果。在“读入请求并标注为 30 类任务之一”的评判（judging）任务上，，Jev 比第二快的模型快 5 倍以上，连它最慢的请求都快过其余所有受测模型的中位数。评测图表显示，Jev 1.13 的中位延迟为 154 毫秒，第二快的 GPT-5.6 Luna 为 860 毫秒。评测还称，Jev 的准确率与最常用的分类大型语言模型（LLM）相当，成本在五个受测模型中仅高于 Qwen3.8 Flash。
Jev 是 TypeSafe AI 创始人 Diogo Almeida 于 9 月 14 日在中官宣的首个 System One 模型——按该公司的定义，这类模型不生成文本，而是接收问题和选项列表，为每个选项返回带概率的结构化决策；博客自述团队为此隐身了两年。9 月 18 日，Jev 1.13 上线 OpenRouter，标价输入 0.042 美元/百万 token（词元）、输出免费。OpenRouter 在推文串开头写道，这款模型发布后已经“引发了一波项目和讨论”。
任务设计：五个模型顺序跑完同一组 200 个合成案例
五个模型拿到的是同一个任务：读一条进入系统的请求，把它标注为 30 种任务类型中的一种。，这是“作用域很紧、在生产系统中反复做出的决策”，所以延迟和成本在这里影响最大。四个受测 LLM 是 GPT-5.6 Luna、GLM 5.3 Flash、DeepSeek V4.1 Flash 和 Qwen3.8 Flash，都是 OpenRouter 上常被用于分类和评判的模型（给出了这份名单）；五个模型跑同样的 200 个案例，顺序执行、无状态，不携带上下文。
方法注意事项也写进了推文串（）：200 个案例是合成的，且在 30 类任务上均匀分布；四个 LLM 均关闭推理，唯独 GLM 5.3 Flash 因模型本身要求推理而以低推理强度运行；DeepSeek 和 GLM 走默认供应商路由，分别分布在 10 家和 16 家供应商上，因此它们的尾部延迟反映的是供应商组合的差异。
推文串最后一条介绍了 Ori Eval 本身：OpenRouter 说做这个工具是为了“量化地、而不是凭感觉”回答“哪个模型最适合我的用例”，用户安装后在自己的项目目录里运行 ori eval 即可（）。称，它会固定测试框架与所用模型，让多次运行的分数差异只来自模型本身。
图表里的完整结果：四个 LLM 的中位延迟都在 860 毫秒以上
评测图表给出的其余四个中位延迟是：GPT-5.6 Luna 860 毫秒，DeepSeek V4.1 Flash 911 毫秒，Qwen3.8 Flash 914 毫秒，GLM 5.3 Flash 1,544 毫秒；图表副标题注明，这是每个决策的中位延迟，任务为 30 类打标、每个模型 200 个案例。以 Jev 的 154 毫秒为基准，它比第二快的 GPT-5.6 Luna 快约 5.6 倍，比最慢的 GLM 5.3 Flash 快约 10 倍。
回复区里有人拿这两个数字做算术：GLM 5.3 Flash 的 1,544 毫秒对 Jev 的 154 毫秒“是 10 倍差距，不是 5 倍”（）。按图表口径，5 倍的对比对象是第二快的 GPT-5.6 Luna，GLM 5.3 Flash 是五个模型中最慢的那个。也有回复认为 154 毫秒意味着 Jev 处于“另一个延迟档位”，而不只是小幅领先（）。
准确率方面，回答了“速度是否牺牲了准确率”：“在这个任务上，没有。Jev 追平了最常用于分类的 LLM，五个模型彼此只差几个案例——一个决策模型和完整的 LLM 一样正确。”成本方面，称 Jev 排第二便宜，仅高于 Qwen3.8 Flash、低于另外三个 LLM，并借此重申 TypeSafe 的论点：决策模型“快、准，最重要的是便宜”。
回复区的质疑：校准指标、案例分布与适用范围
推文串下的回复集中在三类没被覆盖的问题。
第一是概率校准。Jev 的卖点是每个决策都附带“认识论上诚实”的概率——这是 TypeSafe 博客里 RLCD（面向校准决策的强化学习）训练方法的目标——但有回复直接指出“你忘了测它是否校准”（）；另一条引用帖说，如果 RLHF（基于人类反馈的强化学习）奖励自信、而自动化需要诚实的不确定性，那有意思的应该是校准指标，而不只是延迟（）。这次评测公布的是准确率，没有校准指标。
第二是案例分布。有回复指出，200 个合成案例在 30 类上均匀分布，“真实流量从来不会这么整齐”——少数类型占大头、长尾很细——并追问在偏斜分布下这个准确率是否还站得住（）。
第三是适用范围。有回复说，打标任务的输出只有几个 token，成本排名基本上是输入价格的竞赛，Jev 输出免费的优势在这次评测里没有机会体现，建议在输出密集型任务上再跑一次（）；还有人问 5 倍优势在带工具调用的任务上是否成立，还是只适用于短打标（）。
评测发布几小时内，也有人把 Jev 接进了自己的工具：一位回复者称，他用 Jev 给 OpenRouter 的测试框架做了个代码搜索工具，自报初期测试中 token 消耗最多减少 46%——这一数字未经独立验证（）。
平台自测的边界：TypeSafe 更大的宣传数字未进入这次对比
这份评测由 OpenRouter 自己完成并发布，而 OpenRouter 同时是 Jev 的分发渠道——0.042 美元/百万输入 token 的价格就出自它的模型页。推文串公开的是结果图表和方法注意事项，链接指向 Ori Eval 的安装命令与介绍页，没有附原始计时数据或复现脚本。
评测证实的内容有明确边界：一个合成打标任务上的速度、准确率和相对成本。TypeSafe 博客里更大的口径都没有进入这次对比——端到端 70～500 毫秒、较 LLM 快 40～200 倍、主页工作流评测得出的“快 193.6 倍、便宜 444.6 倍”，以及“不会幻觉”。TypeSafe 自己也在博客里注明了两点：这些工作流数字“处于真实世界收益的高端”；而零幻觉不是实测结果，是由 schema（结构模式）匹配在结构上保证的。
Ori Eval 面向公众开放，OpenRouter 的定位是让开发者在自己的项目上做量化评测。回复区给这场评测留出的待办包括：校准指标、偏斜分布下的成绩、带工具调用的任务；TypeSafe 博客里那些更大的倍数，目前也只有厂商自己的工作流评测作支撑。