Jev 1.13 解析：为什么模型以标签而非句子作答

Jev 1.13（typesafe/jev-1.13）不是聊天模型，而要理解它，最快的方式就是别再像读其他所有规格表那样去读它的规格表。TypeSafe 于 2026-09-15 发布它，作为该公司称为 System One 模型这一类别中的首个成员：你交给它一段状态和一组具名问题，它便为每个问题返回一个带类型的答案——一个来自你提供的列表的标签、一个在你定义的量表上的等级，或一个附带概率的真/假值。没有散文，没有代码，没有解释。这不是一篇发布报道。该模型本身出自 2026-09-15，已问世十五天，超出本博客所覆盖的七天窗口，因此它并不因自身发布而获得一篇文章。窗口期内发生的事是，OrcaRouter 于 2026-09-24 将 typesafe/jev-1.13 加入了自己的目录，并开设了 Jev 1.13 模型卡，地址为 https://www.orcarouter.ai/models/typesafe/jev-1.13——这是 Jev 首次可以通过第三方网关调用，而不只是通过 TypeSafe 自己的端点，也是 TypeSafe 之外任何人首次发布的关于它的实时服务数据。这才是值得一读的变化：这个模型在它此前无法运行的地方变得可运行了。

这一变化的实际形态小而具体。在 2026-09-24 之前，采用 Jev 意味着多出一段供应商关系——一个 TypeSafe 账户、一把 TypeSafe 密钥、一张 TypeSafe 发票，以及一套需要专门适配的定制请求格式。在此之后，Jev 与栈中其余部分共用同一把密钥：一个 API 即可覆盖200+ 个模型，0% 加价（按供应商标价原样透传，因此厂商降价当天即在此生效），且该模型可在 POST /v1/systemone 上通过 typesafe/jev-1.13 访问。你仍然要按它自己的形态来调用——该端点并非 OpenAI 的 chat-completions 路由，硬当作是它只会得到 404，而不是一个决策——但你签署的合同与轮换的密钥，就是你已有的那一套。

Jev 是什么类型的模型

TypeSafe 的发布文章用一句话点明了这一点：“我们的首个公开模型是 Jev，今天起以早期访问形式提供。”文章随后将该模型描述为“一次前沿智能的函数调用：输入非结构化状态，输出带类型的概率化决策。”这是对接口的恰当描述，也是一条重要的描述，因为几乎所有对 Jev 的错误预期，都来自把它当作一个小型语言模型来评估。它不是小型语言模型。它是一种具有固定输出语法的决策模型，而语法本身就是产品。

该接口恰好有两个输入。状态是待评判的素材：一封电子邮件、一张支持工单、一行日志、一条 JSON 记录、一个游戏坐标数组。问题是一个由具名项组成的地图，每一项都带有类型、自己的指令，并且——对于两种结构化类型——还带有自己的评判标准。每个问题都针对同一个状态进行评判，答案会以一个结构化 JSON 负载的形式返回。TypeSafe 的文档将这些问题描述为并发且独立地运行，并提出了两个源于这种设计而非调优的论断：增加问题几乎不会改变响应时间，而且增加问题不会造成上下文腐化，因为每个问题都是孤立评判的，而不是位于前一个问题下游。

TypeSafe 自家的设计指南值得重复一遍，因为它最清楚地阐明了这个模型究竟是用来做什么的。让每个问题保持原子化、边界清晰——"一位知识极其渊博的人能在几秒内做出的那类判断"。如果某个决策需要长时间推理，或者确实综合了若干相互独立的因素，就把它拆成几个独立的问题，再在你自己的代码里把它们重新组合起来。他们的例子是：与其用一条"给这份创业路演打分"的提示词，不如分别询问市场规模、技术可行性和差异化，然后套用你自己的权重。这一点之所以重要，是因为这样一来，权重就存在于一个你能修改的系数里，而不是存在于一个你必须重写的提示词里。

对于需要评估风险的工程师而言，这个模型在所有重要意义上都是封闭的。Jev 的架构、参数数量、训练算力和权重均未公开。TypeSafe GitHub 组织下没有权重仓库——那里的十一个公开仓库是工具、SDK、工作流以及三个无关的 fork，其中没有一个属于该模型。

“输入”就是整个产品

OrcaRouter 模型卡公布了三个原语，重要的是，还公布了每个原语的限制。你向 Jev 提出的每个问题都恰好是三种形态之一：

• noul ——一种真/假判断，返回的是经过校准的概率，而非单纯的布尔值，因此“很可能为真”与“肯定为真”是可区分的值。

• choice — 从最多 255 个带标签的选项中选取一个，每个选项都自带判定条件文本，以便模型了解你的标签之间有何区别。

• 评分——按 2–10 级的有序量表评定，等级定义作为标准提供。

这种限制带来的后果是：没有什么需要从散文中解析出来，也没有什么可以对照你希望模型遵循的模式进行验证。TypeSafe 的发布文章对这一保证异常直白：其图表中的“0%”模式不匹配数值“并非经验性的。模式匹配是有保证的，因此我们可以自信地把 0% 加进图表。”当你的答案空间是你提供的封闭集合时，返回的值要么在集合中，要么就不是来自模型——不存在第三种结果：模型写下了某种看似合理但形式错误的东西，而你的正则表达式悄悄接受了它。

这三种类型也是评审者无法像评估聊天模型那样评估 Jev 的原因。没有可比较的 MMLU-Pro 分数，没有可阅读的写作样本，没有可检查的推理轨迹。唯一有意义的问题是：那个带类型的答案是否正确，以及附加在它上面的概率是否诚实。这两者都是可测量的，但只能对照你的数据和标签来衡量。

一个已记录在案的差异值得指出，而不是去解决：TypeSafe 自己的文档展示了一个从零开始索引的 Score 示例，而 OrcaRouter 卡片则将量表公布为 2–10 级。供应商记录的是等级；我们的卡片公布的是 2–10。如果你要在 Score 之上构建评分标准，请阅读你自己回复中的等级定义，而不是假设某个索引。

为什么没有可计费的输出 token？

定价是该架构最纯粹的表达。Jev 在 OrcaRouter 上每百万输入 token 收费 $0.042，输出费率为每百万 $0.000000——不是折扣，也不是发布促销，而是不存在可计量的数量。生成式模型按其写出的文本计费；Jev 不写任何文本。它返回一个标签、一个级别和一个概率。输出端没有任何可计数的东西，因此那里不收取任何费用。

TypeSafe 在其主页上从另一个方向给出了同一个数字——“每十亿输入 token 42 美元”——并附上一句比较性宣称：“输入价格比 Claude Fable 5.1 低 238 倍”。这一比较与主页上的其他所有内容一样，都出自厂商之口，无人复现验证。但它所依据的算术，读者很容易拿自己的账单来核对，这才是它有用的地方。一项决策工作负载的规模，几乎完全取决于你推入多少状态，而状态的廉价程度，是生成的 token 所无法比拟的。

供应商的主打数字比价格行更大，理应得到同样的标注。TypeSafe 宣传“快 193.6 倍，便宜 444.6 倍”，并以脚注将其限定为“用于 System One 任务的工作流”，还在下方发布了一个示例：TypeSafe AI 以 0.000081 美元在 0.114 秒内完成，而 LLMs 以 0.013880 美元在 8.566 秒内完成。发布文章本身也承认这种表述有风险——193.6 倍和 444.6 倍被描述为可能处于“真实世界收益的较高端”——并指出并排演示使用了一个“高度简化”的查询，其中的可读键由供应商挑选，以“把我们的模型描绘得更有优势”。这些数字均未被独立复现，而供应商自己的基准测试卡也仍标记为待定。

“校准”是什么意思，以及 RLCD 是什么

TypeSafe 自己为其训练方法命名：“面向校准决策的强化学习”（Reinforcement Learning for Calibrated Decisions，RLCD）。RLCD 是 TypeSafe 自己的术语，而非早于该公司存在的通用机器学习缩写，其优化目标在发布帖的对比表中被表述为“校准决策：在 System One 任务上带有认识论上诚实概率的答案”。同一张表所对比的是 RLHF——它优化的是人类偏好，即评分者喜欢的文章和聊天回复——以及 RLVR，它优化的是可通过程序化方式验证的输出。RLCD 优化的则是第三样东西：一个答案准确表述模型自身不确定性时所附带的概率。

实际上，"校准"（calibrated）是就置信度而言的主张，而不是对答案正确的保证。一个在一组问题上给出 0.8 的校准模型，在这组问题上的正确率应当约为 80%；但在其中任何一个具体问题上，它仍可能出错。要诚实地解读 TypeSafe 首页上那句话——"零幻觉——每一个 Jev 决策都附带一个置信度估计，因此你的软件可以在置信度高时采取行动，在置信度不高时升级处理。"——就必须做这种区分。它是一个关于置信度估计的主张，而不是零错误的证明；与之相权衡的是我们自己的数据：在截至 2026-09-30 的七天里，我们的卡片测得经 OrcaRouter 的 Jev 流量错误率为 0.49%——而同一时间窗口更早时这一数字为 0.57%，因为它是基于滚动七天的实时 playground 流量计算的，而不是基于固定的测试集。这两个事实属于同一段话：置信度正是这个模型的意义所在，而在我们的流量上，这个模型仍然大约每两百次调用就会失败一次。

校准说明还解释了一种否则会看起来像 bug 的延迟行为。TypeSafe 的发布文章写道：“对于基数更高的选择，我们会采用两阶段系统：先独立评分，再做出明确选择，因此偶尔会出现变慢。”一个有 255 个选项的选择并不是一次前向比较；供应商会先评分，然后再选择。如果你看到针对大型标签集的请求比空操作明显更慢，那就是文档中记载的机制，而不是拥塞。

你今天怎么称呼它？

在 OrcaRouter 上，模型为 typesafe/jev-1.13，在目录中名称为“TypeSafe: Jev 1.13”，上下文长度为 65,536 个 token，并且仅支持一种端点类型：systemone。你使用 OrcaRouter 密钥通过 POST /v1/systemone 调用它，发送 model 字段、state 字段（字符串、对象或数组），以及一个 questions 映射，其中每个条目都带有 type（noul、choice 或 score）、其 instructions 和其 criteria。响应是单个结构化 JSON 载荷，且不进行流式传输——没有可选择的流式模式。

卡片自身对合同的措辞是“文本输入，结构化 JSON 输出”，而公布的限额才是设计时所依据的：非流式，在合并的状态和问题中最多约 64K 输入 token，超过该限制的请求会在到达模型之前被拒绝。目录条目将标价列为每百万输入 token $0.042，并显示完成率为零。这些都是供应商的数字，未经更改地传递——这是我们定价方式的比例形式：对提供商标价加价 0%。

针对这个模型，流传着两种 token 预算，它们并不冲突，所以要把它们区分开。65,536 这个数字是模型卡的 context_length，文档中说明其为状态与问题合计约 64K 的输入。早期 OrcaRouter 文章引用的“大约 32,000 个 token”只是状态预算——也就是在问题分走各自份额之前，留给你的材料的空间。如果你是在为一个请求做预算，状态预算才是限制你所构建载荷的数字；合计数字则是整个调用的上限。

Jev 做不到的事，直白说明

它无法撰写散文、进行总结、翻译或对话。这是设计使然，而非需要为之致歉的局限：发布文章称 Jev“放弃字符串生成”，而 TypeSafe 自己的 jaggedness 页面将“Generation”列为一种具名失效模式，并在旁边给出“使用生成式模型”的指示。强制生成既缓慢又糟糕。如果你的流水线需要书面摘要，Jev 就是错误的组件，再多的提示词技巧也改变不了这一点。

它不是生成式模型的替代品。Jev 所属的工作流中有两个模型：一个以文本进行读取、写入和推理的生成式模型，以及坐在它旁边、在毫秒内完成类型化调用的 Jev。这才是对供应商主页上每一项成本比较的诚实框定——“LLMs”一栏并不是一个正在被取代的竞争对手，而是同一系统的另一半；而这一组合之所以有趣，是因为决策的那一半如今与生成的那一半共用同一把密钥，而不是被隔在自己单独的合同之后。

而“校准过的”并不意味着正确。它的意思是，附着在某个答案上的数字应当可以被读作一个概率。某个 noul 上的 0.62 是模型在告诉你它并不确定，这是有用的信息，而一个光秃秃的是/否会把这条信息毁掉——它并不承诺这个“是”就是对的。基于置信度构建升级逻辑才是预期的模式；把答案当作绝对真理则不是。

诚实地解读数字

我们卡片上的每一项服务指标，都来自我们自己在 OrcaRouter 的 playground 中、基于滚动七天窗口产生的流量，而不是来自厂商的基准测试；而且这篇文章写作期间，这个窗口还在移动——请把它当作一次读数，而不是一份规格说明。截至 2026-09-30 的七天：首 token 中位时间 151 毫秒，p95 247 毫秒，输出吞吐约每秒 349 个 token，错误率 0.49%，共服务 7,620 万个 token。该窗口内每日 p50 依次为 175、170、163、161、170、147 和 143 毫秒——一条缓慢改善的曲线。09-28 的 p95 为 2,448 毫秒，是那一序列中真实存在的单日离群值；把它当作常态来引用是错的，而完全把它丢掉则同样不诚实。

关于流量数值，还有一点需要说明：每秒 349 个输出 token 听起来像是生成式模型的吞吐量，但别忘了，Jev 并不产生任何生成文本。这个指标衡量的是，对于结构化负载，我们的 playground 在响应侧所统计的任何内容；它更适合用来发现不同日期之间的退化，而不是用来把 Jev 与聊天模型进行比较。

那些是我们的数字。供应商的数字是 193.6x、444.6x、$0.000081 的演算示例，以及与 Claude Fable 5.1 的 238x 对比——全都出自 TypeSafe 自己，没有一个经过独立复现，而且它们的脚注都把这些数字限定为仅适用于 System One 任务工作流。TypeSafe 提出的唯一一个根本算不上基准测试、却比那些倍数更有价值的性能主张，是一项结构性的主张：因为答案是类型化的，集成过程没有解析步骤，也没有模式验证步骤，而这项成本不会出现在任何延迟表中。

什么是开放的，什么不是

于 2026-09-30 核查时，TypeSafe 的 GitHub 组织发布了十一个仓库。其中没有一个包含 Jev。对于集成该模型的开发者来说，真正重要的那些仓库全部采用 MIT 或 Apache-2.0 许可：skills（MIT）、system-one-adapter-python（MIT，被描述为“由 LLM API 支持的即插即用型 TypeSafeClient 替代品”）、typesafe-sdk-js（MIT）、typesafe-sdk-python（MIT）、daggerverse（Apache-2.0）、WorkflowEvals（Apache-2.0，工作流代码发布在 evals.typesafe.ai）、n8n-nodes-typesafe-ai（MIT）、typesafe-ai.github.io 和 pulumi-clickhouse。Star 数和推送日期会变化，所以如果你以后读到这段内容，请重新核查，不要直接相信这份列表。

这十一个中有三个是无关项目的分叉，完全无法说明 Jev 是如何运作的：一个最后推送于 2025 年 5 月的 vLLM 分叉，一个来自 2025 年 6 月的 LLaDA 分叉——LLaDA 是一个无关的扩散语言模型发布版本——以及一个面向 ClickHouse Cloud 的 Pulumi provider。人们很容易从分叉列表中读出架构。不要这么做：关于 Jev 的设计，从这三个中推不出任何东西，尤其是 Jev 并不是扩散模型，尽管 LLaDA 分叉的存在可能让人这么联想。

对“Jev 是否开源”这个问题，诚实的一句话回答是：工具链是开源的，模型则不是。对一个托管的前沿模型来说，这是一种常见的安排，而当你围绕 Jev 做规划时，也应该假定正是这种安排：一个有公开价格的 API、一份有文档说明的合同，以及一个未公开的参数数量。

在供应商称 Jev 不可靠的地方

TypeSafe 发布了其针对 jev-1.13 的参差性页面，最后审阅于 2026-09-17，其中指出了模型会在哪些地方失灵。它异常坦诚，也是开始撰写局限性部分的合适起点，因为这是供应商自己的清单，而不是竞争对手的：

• 字面解读——它按字面意思理解措辞。范围限定词、否定词和隐含条件都不会被推断出来；它"回答的是你写下的问题，而不是你想问的问题"。供应商的解决之道是写出确切的条件以及每个选项的评判标准。

• 数学和数字——它不是计算器，也不能可靠地计数。把算术运算留在代码里做。

• 日期和时间比较——日期被当作文本读取，而不是有序数量，因此排序、间隔和窗口都不可靠，混合格式时更糟。

• 间接性——双重否定与多跳推理会降低准确性。减少跳数，直接指向相关状态。

• 庞大的状态中充满无关细节——无关内容会充当干扰项，随着状态增长，准确率会下降。先过滤。

• 对抗性内容——状态不会被视为敌对，因此注入的指令或误导性框架可能会改变答案。

• 相互矛盾的指令与标准——当二者提出不同要求时，模型“可能会感到困惑”。

• 常识性结构不变量——P(noul) 与 1 − P(not noul) 并不保证一致。每个决策只按一种方式提问，并在代码中强制实施恒等式。

• 生成 — 前面已经介绍过，而且供应商自己的建议就是使用生成式模型。

其中有两点值得强调。对抗性的那一点很重要，因为 Jev 的全部价值主张就是判断不受信任的材料，而一个包含指令的状态可以改变答案；如果你的状态来自用户，那就是一个与其他任何提示注入面形态相同的提示注入面。结构不变量的那一点很重要，因为一个“校准过的”模型会诱使你对它的概率做算术，而供应商是在告诉你，不要假定这种算术是闭合的。

发布帖承诺了什么，以及没有承诺什么

本文引用的几乎每一条厂商说法都可追溯到同一页：TypeSafe 自己的公告，归入“公司新闻”栏目，日期为 2026-09-15，由创始人 Diogo Almeida 署名。直接读原文值得花这两分钟，因为其中一句话的措辞为此后的一切设定了条件。“我们的首个公开模型是 Jev，今日起以早期访问形式提供。”早期访问是厂商对自家平台上可用性的自行描述，而且它是一项比表面看来更狭窄的陈述——它使 TypeSafe 承诺向获批用户提供该模型，却对还有谁可以提供只字未提。这正是 2026-09-24 的目录新增内容所填补的空白，也是对于今天任何评估 Jev 的人来说，模型卡比那篇公告更重要的原因。

同一页面对其自身的局限也同样清楚，这正是上文引用原文而非转述的原因。它没有公布参数量，除“一种新的模型架构”之外没有架构描述，没有训练算力，也没有权重仓库，并且没有给出正式开放使用的日期或条件。这些缺失正是规划中的约束条件：一边是价格已公布的 API，另一边是内部结构无从检视的技术栈。该文章对模型的表述也足够诚实，使其可作为规格说明使用——“一次前沿智能函数调用：输入非结构化状态，输出带类型的概率性决策”——这是全文中唯一一句描述接口而非愿景的话。

这个界面引发的问题

当一个选项集包含超过 255 个选项时会发生什么？它会受到上限限制——255 个带标签的选项是选择题的上限，而厂商那种两阶段“先评分、后选择”的做法，正是当基数攀升时所采取的应对方式，这也是文档中记载的大规模标签集上偶尔变慢的原因。如果你的分类体系比这更大，设计上的解决办法就是把它拆解为若干个问题，再在代码中重新组合，这也是 TypeSafe 针对复合判断给出的同一建议。

65,536 token 的上下文是否意味着 65,536 token 的状态？不是。官方公布的预算是状态与所有问题合计约 64K token，而较早的报道中出现的“约 32,000 token”这一数字只是状态部分单独的预算。请按状态部分的数字而非合计数字来规划你的载荷，并且要记住：超出限制的请求会在到达模型之前就被拒绝。

这个该怎么办

Jev 1.13 值得一看，原因很具体，而非泛泛而谈。如果你的流水线中有某个环节，目前是让一个聊天模型返回标签，并指望它能以正确的格式返回——比如路由器、评分器、策略检查、应用于成千上万条记录的评分标准打分——那么这个模型取代的正是这个环节，价格为每百万输入 token 0.042 美元，输出侧不计费。如果你有某个环节需要写出成文的答案，Jev 就不是合适的工具，其厂商自己也这么说。

过去一周改变的不是模型本身，而是试用它不再需要建立第二家供应商关系。八天前，评估 Jev 意味着要单独开一个账户、单独做一次集成；如今，它只是已有密钥上的一个模型 ID，而这个密钥已经能访问 200 多个模型，厂商的标价原样沿用，返回的打字答案也和其他一切来自同一个地方。对于这样一个不同寻常的模型，能够用自己的标签来测试它、而无需承诺签订新合同，这本身就是决策的大部分依据。