模型 · System One

地板比问题更贵

一个宽大的象牙色托盘,里面堆满炭灰色棋块,旁边一个小碟只放了一枚孤零零的棋块,中间隔着一根琥珀色玻璃棒
受一个托盘里许多物件启发的原创抽象编辑插画。

每次网络调用都有一个在任何工作发生之前就要支付的固定价格。通常它小到可以忽略。但当一个模型在几十毫秒内就能回答时,它不再小,而变成了账单的大部分。

一项于2026年9月20日发布的、预先注册的 Jev 独立评测,测量了这块地板,然后测试了填满一次调用时会发生什么。这些数字支持一种特定的系统形态,而那不是多数人最先构建的形态。Ciyo 不运行 Jev——它不生成图像,也不生成视频——所以这是一篇对公开测量的解读,而非产品说明。

测量了什么

该评测在 21 项实验中收集了 5,721 次调用,并在数据收集开始前对 50 个预测打了时间戳。它通过 OpenRouter 从西欧运行了 `typesafe/jev-1.13-20260917`,并公开了原始数据。

两个发现驱动了其余一切。每次调用有约 430 毫秒的固定成本。把 800 个类型化判定放进一次调用,在 985 毫秒内完成,成本为 0.00075 美元。

把这两点合起来,算术就很刺眼。第一个判定花费约 430 毫秒。其后 799 个合计花费约 555 毫秒,也就是每个约 0.7 毫秒。

两根柱状图,比较一个含1个判定、约 430 毫秒的调用,和一个含 800 个判定、985 毫秒的调用
由预先注册的 priorbench/jev 评测测量,2026年9月20日,经 OpenRouter 从西欧。Ciyo 制图。

作者自己的保留意见,而这很关键

他们明说,无法把模型延迟从网关延迟中分离出来。430 毫秒是测量值;而「它是模型的属性而非路由的属性」这一说法只是假设,他们也这么说。任何拥有原生 API 访问权限的人都能很快判定。

这个保留意见并不会削弱设计建议。无论地板由什么构成,你每次调用只付一次,所以填满调用在两种情况下都是那个杠杆。但它确实意味着,在拿别人的数字搭建延迟预算之前,你应该从自己的地域测量自己的地板。

它也只是一个地点、一天、针对一个模型版本。把它当作事物的形态,而非一份规格。

这支持什么

不要构建那种发送一个 state 和一个问题、等待、再发送下一个的循环。那种设计几乎把所有时间都花在反复支付地板上。

从同一测量中得出两种更好的形态。把问题摊开:把 state 发一次,带上你可能想要答案的每一个问题,包括你很可能会丢弃的那些,因为边际问题近乎免费。再把状态批处理:如果你是在分类积压工作而非响应实时事件,就把许多条目放进一次调用,而不是在一分钟内发起许多次调用。

第二种形态有一个与延迟无关的限度:一次携带 800 个判定的调用,携带的是 800 个判定份量的 state,而你必须能把每个答案归因回它的那一行。让你的问题标识有意义,让你的映射显式。

并发,以及它在何处不再有帮助

同一运行考察的是调用之间的并行,而非调用之内。它发现 8 个并发请求是最佳工作点,吞吐量在约 11 个请求每秒时饱和。

这是个很小的数字,在你设计扇出工作池之前值得知道。超过 8 个在途请求后,运行没有完成更多工作;只是有了更多排队的请求。那 5,721 次调用在该设置下花了约 25 分钟,总成本 0.176 美元。

如果你需要的不只是约 11 个请求每秒,这些数字给出的答案不是更多的工作线程,而是更少、更满的调用。

所测运行的表格:5,721 次调用、25 分钟、0.176 美元、8 个并发请求、约 11 个每秒
数字来自 priorbench/jev 代码仓库,2026年9月20日 发布,2026年9月21日 阅读。Ciyo 制表。

一份你真正能写下来的预算

取这些数字的形状,把它用到真实工作负载上,而不是用到基准测试上。假设你想评估每一次智能体运行的每一步,而你每天有 50,000 步,每步四个问题。

若每步一次调用,那就是 50,000 次调用,在测得的地板和并发下约 6 小时的挂钟时间,以及大量调度。若每批比如说 200 步一批地批量调用,则是 250 次调用。令牌成本两种方式相同,因为你发送的是同一个 state;崩塌掉的是支付地板所花的时间。

这就是整个设计教训。对这类模型,你该问的问题不是「一次调用有多快」,而是「我一次能塞进多少」。

示例,使用测得数字和一个虚构的工作负载
设计每天调用次数每天支付的地板
每步一次调用50,000约 6 小时的固定成本
每次调用批量 200 步250低于 2 分钟的固定成本
两种方式令牌相同你付钱买的是 state

在承诺前该测量什么

你的地板,来自你的地域,走你的路由。它是一段脚本和 20 分钟,它是你预算所依赖的那个数字。

你每次调用的天花板。把判定数往上推,直到响应时间或错误率拐弯,然后待在它下面。

你的归因。批量调用只有在每个答案都能回到正确的那一行时才有用,而那是一类值得写测试、而不是靠碰运气的缺陷。

还有你自己的准确率,因为如果判定错了,速度就毫无意义。速度是用这类模型的原因;与你自己标签的一致,是留住它的原因。

吞吐量的问题

一次调用能塞进多少判定

文档没有公布每次请求的提问上限。一次独立运行把 800 个放进一次调用,在 985 毫秒内完成,花费 0.00075 美元。

430 毫秒的地板是模型还是网络

未知。作者们测量了地板,并明确说他们无法在自己的路由上把模型延迟与网关延迟分离开。

我一次能跑多少个请求

在那次运行中,8 个并发请求是最佳工作点,吞吐量在约 11 个每秒时饱和。在给工作池定规模前,先测你自己的。

批处理会改变令牌成本吗

不会。你为发送的 state 付费。批处理压扁的是每次调用的固定成本,不是令牌。

继续阅读

Ciyo 撰写关于创意与智能体工具背后的模型,并测试那些它能运行的模型。