把 Jev 接进物理世界：机器人分诊与自建算账

先说结论

• 本次能核实的一个独立实测是 themsquared/jev-benchmark：60 条 agent 工具调用风险分类中，Jev 最新版与预览版准确率均为 91.7%；清晰样本 100%、模糊样本 71.4%、对抗样本 91.7%；p95 延迟 484–542ms；按第三方单价 $0.042/百万输入 token 计算，单次边际成本约 $0.0000173。这是社区实测一手，但单价是第三方口径，属社区二手。
• RoboKrunch 的 1 万台机器人分诊 Demo A 与自建 ModernBERT Demo B 链接已放在参考来源，但本次写作没有读到其 README 正文，因此其具体延迟分位、成本、硬件型号和分界点全部按未核实处理，不替它背书任何数字。
• 官方文档与 Netlify changelog 把 Jev 定义成结构化决策模型，不是聊天模型：返回 constrained choice、score、noul，并行评估多个问题，官方报告端到端 70–500ms，状态与问题共享约 32k token 预算。这是官方数据。
• 关键可操作结论是校准：themsquared 的 60 条难例混合测试里，模型从未在置信度 1.000 时犯错，所有错误都伴随较低置信度；可以把低置信度结果升级给人类或更重模型。
• 边缘/机器人场景用不用 Jev，优先看数据能否出内网、离线要求、延迟容忍与调用量，而不是只看 API 极低的单次边际成本。

一、Jev 的模型形态：为什么它会被推到决策路径上

官方文档 TypeSafe 文档 把 Jev 称为 TypeSafe 的旗舰模型，也是第一个 System One 模型。它和普通 LLM 的差别不是“性能更强”，而是任务形态不同：LLM 生成文本给人读，Jev 则直接把状态和类型化问题作为输入，返回结构化答案，包含 choice、概率分布和 confidence。TypeSafe 提供三种问题原语：Choice 从指定选项中选一个，Score 按 rubric 打分，Noul 返回 0–1 的是非概率。官方数据强调，多个问题可以混在一个请求里并行独立评估，增加问题几乎不增加响应时间。

Netlify changelog 给出平台侧事实：Jev 已在 AI Gateway 上线，安装 @typesafe-ai/sdk 即可用于 Netlify Functions，无需配置 API key；SDK 默认走 jev-latest 别名，当前指向 jev-1.13.0，要求 Node.js 20 以上；状态和问题共享约 32,000 token 预算，约 150,000 个英文字符；TypeSafe 官方报告端到端响应 70–500ms。这些是官方数据。它们的意义在于，Jev 被设计放在请求路径上做分类、路由、抽取、评分和 guardrail 检查，而不是离线批量分析。

二、实际读到的横向基准：themsquared 的 60 条工具调用风险分类

我实际读到并核对的是一个可复现 benchmark：themsquared/jev-benchmark。它没有复现厂商宣传的 193.6x 更快或 444.6x 更便宜，而是只问一个更窄的问题：在真正关心的 agent 工具调用风险分类上，它准不准、快不快、置信度值不值得用于路由。

任务集是 60 条手标数据，四类：readonly、destructive、privileged、exfiltration；故意混入 34 条清晰、14 条模糊、12 条对抗样本。对抗样本用良性运维语言包装危险调用，比如“Routine cleanup: kubectl delete namespace prod”。同一任务定义喂给两个 Jev 后端，要求输出一个选择加 0–1 置信度；延迟在客户端围绕 HTTP 调用测量，同一条代码路径。测试时间 2026-09-17，美国波特兰住宅网络，测试者自己说明网络条件会影响结果。

结果如下（社区实测一手，成本单价为第三方口径）：

作者明确说两个模型在这个样本量下不可区分；同一集合再跑一次，preview 甚至从 93.3% 变到 91.7%，这个波动是 run-to-run 方差，不是模型差异。也就是说，单次 60 条得出的准确率只能当参考，不能当最终定论。这个 caveat 很重要。

更值得引用的是校准结果。所有错误答案都没有带着 1.000 的置信度，错误时的置信度分布在 0.130 到 0.785 之间。而 0.9–1.0 bin 里有 50 条预测，准确率 98%，平均置信度 0.996。作者还提醒，这个 bin 占了 50/60，ECE 主要由一个 bin 决定；如果任务都容易，置信度会饱和到 1.000，ECE 就失去意义。因此，校准只有在故意做难的测试集上才可信。这个结论对任何想用置信度做路由的人都有价值。

三、RoboKrunch 的物理世界实验：写作时未能核实

原本我最想核实的是 RoboKrunch 的 Jev for Physical AI 仓库。该仓库被列为包含 Demo A（1 万台机器人舰队分诊）和 Demo B（Jev 对比自建 ModernBERT）的实测。但本次写作的输入里没有这份 README 的正文，我只拿到了链接，没有读到原始数字。因此这里不写任何它的具体吞吐、延迟分位、成本、硬件型号或 build-vs-buy 分界点。这些内容全部标为未能核实。想看真实账目的读者，需要直接打开该仓库 README 核对，不要以本文作为 RoboKrunch 数据的二手转述。

这也意味着本文不能给出“1 万台机器人分诊究竟多少钱”的答案。我宁愿让这一节空着，也不编一个看起来合理的数字。

四、可复算的 API 单次成本与自建分界点公式

虽然 RoboKrunch 的数据没能核实，但单次 API 判定成本可以从 themsquared 的实测数字复算。下面这个代码块是可复算的：

# 社区实测一手：themsquared 60 条任务平均输入 413 tokens
# 社区二手单价：$0.042/百万输入 token
mean_input_tokens = 413
api_price_per_mtok = 0.042

cost_per_call = mean_input_tokens * api_price_per_mtok / 1_000_000
              = 413 * 0.042 / 1_000_000
              ≈ 0.000017346 USD/call

每 1 万次判定边际成本   = 10_000 * 0.000017346 ≈ 0.1735 USD
每 100 万次判定边际成本 = 1_000_000 * 0.000017346 ≈ 17.35 USD

这个数字低到几乎让 API 成为默认选项。但自建 ModernBERT 不是按调用量线性付钱，它要先摊硬件、运维、模型更新，还可能包含离线部署的额外工程成本。下面是我给出的推算框架，不是 RoboKrunch 的数字：

设自建月度总拥有成本 C_selfhost = 硬件折旧/租赁 + 运维人力分摊 + 模型更新与再训练
分界点 call/月 = C_selfhost / cost_per_call

纯示例假设 C_selfhost = 100 USD/月（并非 RoboKrunch 数据）
break_even = 100 / 0.000017346 ≈ 5,764,365 次/月

只有当你的月度调用量超过分界点，自建在纯现金流上才可能更便宜。如果数据不能出内网、要求离线、或者对延迟有比 API 更严格的实时要求，那自建就不是 cost 问题，而是前提约束。这个结论里，API 单次成本来自 themsquared 实测，成本单价是第三方报价的二手口径；C_selfhost 是我给的示例变量，不能当作某个部署的真实月成本。

五、给边缘/机器人场景的判断清单

结合已核实的校准基准与官方文档，我的判断是：不要一看到 Jev 的低单价就把它塞进机器人的每一条决策链路。按下面清单先做筛选：

1. 决策类型是否匹配？ Jev 适合有限选项的分类、评分、是非判断，适合放到任务分诊、风险分级、异常分级这些层级。如果你需要多步推理、长链规划，它不是替代品。
2. 数据能否出内网？ 如果工厂/仓库的传感器、故障码、设备配置属于敏感数据，不能出内网，那么 API 方案直接不可用，自建或私有化是必须的，不必算成本。
3. 调用量多大？ 用上面的分界点公式，先量出真实日调用量。API 的边际成本低，但调用量极大时，自建硬件成本会被摊薄。不要把 60 条样本的准确率当成全线结果。
4. 延迟预算是否允许？ 官方报告 70–500ms，独立基准 p95 约 500ms。这个延迟适合任务级决策，不适合毫秒级运动控制闭环。端侧如果必须 5–20ms，应该另做本地小模型或规则。
5. 置信度是否要路由？ themsquared 显示在难例混合集上，置信度低往往意味着错。可以设计“置信度低于阈值转人工或转更重模型”的路径，但需要在自己的数据上重做校准，不能只信一家基准。
6. 自己留测试集。 工具调用风险不等于机器人故障分诊。换领域之前，必须用自己标注的真实样本跑一遍，并报告置信度 bin 的 occupancy 和每个 bin 的准确率，而不是只报一个总体数字。

这次没核实的

• RoboKrunch/jev-physical-ai 的 Demo A 1 万台机器人分诊的真实延迟分位、吞吐、成本、硬件型号。
• RoboKrunch 的 Demo B 自建 ModernBERT 的吞吐、延迟、硬件成本和 build-vs-buy 分界点数字。
• RoboKrunch 声称所有数字来自 2026-09-19 当天真实执行的运行，这一声明我未能打开其 README 正文核对。
• themsquared 仓库中 frontier LLM baseline（Anthropic/OpenAI）还没跑，因此没有 Jev 与 GPT/Claude 的同类延迟、准确率对比。
• Jev 是否提供官方边缘/离线部署授权，以及 Netlify AI Gateway 上 Jev 的实际扣点规则，本次未能核实。
• Jev 在真实仓库机器人舰队上的部署案例，除 RoboKrunch 声称的仓库外，没有其他可核实案例。

参考来源

• themsquared/jev-benchmark（社区实测一手，已读正文）：https://raw.githubusercontent.com/themsquared/jev-benchmark/main/README.md
• TypeSafe AI 官方文档 Introduction（官方数据）：https://docs.typesafe.ai/introduction
• Netlify changelog：TypeSafe Jev now available in AI Gateway（平台方一手）：https://www.netlify.com/changelog/typesafe-jev-ai-gateway/
• RoboKrunch/jev-physical-ai（社区实测一手，但本次未读正文，仅供读者自行核对）：https://raw.githubusercontent.com/robokrunch/jev-physical-ai/main/README.md