全网对不上的数字：Jev 的速度倍数 193 倍还是 200 倍？成本 444 倍还是 400 倍？较真一下

【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction

9 月 15 日，前 OpenAI 研究员创办的 TypeSafe AI 发布了"不生成文本、只输出结构化决策"的模型 Jev，一天之内在 HN 冲到上千分、数百条评论，随后以 fast-jev-compaction 为代表的生态项目把热度延续到 Claude Code 插件圈。热度越高，数字越乱：同样是"比 LLM 快多少、便宜多少"，全网至少流传着三个版本——193 倍/444 倍、200 倍、40–200 倍/40–400 倍。本文不追热点，把三个版本的数字摆在一起，再结合 fast-jev-compaction 仓库源码，拆解这些倍数从哪来、能不能复现，以及爆款数字在传播中究竟经历了什么。

同一组数字，全网至少三个版本

先把流传的版本逐条列出来：

1. 微信公众号传播的文章标题："Jev 全量开放：速度快 193 倍、成本低 444 倍"，并称其"只做选择题"。
2. 虎嗅报道："OpenAI 前研究员创办 TypeSafe AI，推出非大语言模型 Jev，速度提升 200 倍"。
3. 掘金实测帖（给 Codex 配 Jev）："Agent 决策比 LLM 快 40-200 倍，便宜 40-400 倍"，即一个区间。

而如果把视线从"模型"挪到"压缩插件"本身，还有第二层数字：CSDN 多篇文章分别称"压缩耗时 5–20ms""实测 token 消耗降低近 100%""实现 91.5% 上下文压缩率"。

同一件事，速度 193 还是 200，成本 444 还是 400，区间还是端点？较真的第一步，是把它们当成四个不同的命题，而不是一个命题的四处抄写错误——它们的测量对象、测量时间和传播层级本来就不一样。

数字的"口径"是怎么裂开的

第一层裂口：原始测量 vs 转述转写

193/444 与 200 都是"Jev 对比 LLM"的结论，但原始口径多半是"特定基准、特定版本、特定计费档位"下的测量值。193 与 200 之间 3.5% 的差距，本身就在正常测量波动范围内——任何跑过基准的人都知道，一次模型更新、一个并发参数、一次网络抖动，结果差出几个百分点太正常了。所以"193 还是 200"很可能根本不是谁抄错了，而是两个时点、两套测量各自取了不同的结果；至于"444 还是 400"，更可能是"原始区间取端点"与"取整"的差别。

第二层裂口：模型快 ≠ 工程快

这是最容易被忽略的一层。Jev"单次决策比 LLM 快 200 倍"是模型命题；fast-jev-compaction"压缩上下文"是工程命题。把前者直接安到后者头上，就会产生"压缩也快了 200 倍"的暗示。看仓库源码就知道，一次压缩远不止一次模型调用：

• src/compact.ts 中，compact()先把全部历史装配成 state（fitState），再对每个候选工具调用拆出两个noul问题（questionsFor：这个 call 该不该留、它的 result 该不该留）；
• batchCalls按maxRequestTokens（默认 30000）把问题分批，每一批都把完整 state 原样重发一遍，然后用Promise.all并发请求；
• README.md 的 Limitations 里写得很直白："The full state is repeated with every request, so a history near the state ceiling costs one request per handful of questions"——历史接近 state 上限时，每十几个问题就要多付一次完整请求的输入 token。

所以"每次决策便宜 400 倍"和"每次压缩便宜 400 倍"是两个数字。前者成立不代表后者成立；后者还取决于历史长度、分批数量，以及reductionRatio是否达标——hooks/fast-jev.ts 里minReductionRatio默认 0.25，压缩率低于 25% 直接回退 Claude Code 内置摘要，连 Jev 的账都不让你付。

第三层裂口：推理时间 vs 墙钟时间

CSDN 文章说"压缩耗时 5–20ms"。这个数字在仓库里能对上号吗？看 src/compact.ts 里stats.ms的来源：

const started = Date.now(); // ... fitState、batchCalls、并发 askBatch、applyDecisions ... ms: Date.now() - started,

这是客户端墙钟时间，包含了 Jev API 的网络往返、并发调度和 JSON 序列化，不是模型推理时间。"5–20ms"更像是 Jev 单次小请求的推理延迟，把它说成"压缩耗时"，等于把两个口径缝在了一起——而这种缝法在传播中几乎必然发生。

"快多少"能不能复现：从仓库源码看基准的边界

较真的核心问题是：这份仓库能不能复现"200 倍/400 倍"？答案藏在三个文件里。

第一，单元测试根本不联网。tests/fast-jev-compaction.test.ts 全程用fakeJev替身回答问题，README.md 也明说："The unit tests use a fake Jev and never contact TypeSafe. The demo is the live network check." 也就是说，仓库内唯一能给出真实延迟与成本的入口是npm run demo（examples/demo.ts），而它只打印一次压缩的stats.ms和字符缩减率，并不与 LLM 对照。

第二，演示是"演的"。仓库自带的 macOS 动画演示 demo/JevDemo/main.swift 是一个 SwiftUI 小应用，README 对它介绍得很坦率："It never calls the API; it exists to be screen recorded"——脚本化、戏剧化、专为录屏而存在。它是传播视频里的"效果演示"，不是基准测试。

第三，token 数字本身是估算值。src/state.ts 的estimateTokens用字符规则估算 token（一个单词按每 6 个字母计 1 token、数字按半个、其他符号按 0.9），注释承认它是校准出来的近似值，"calibrated to land 2–18% above the true count"。连仓库自己的计数都要靠校准逼近真实值，社区里那些整齐到吓人的百分比，可信度可想而知。

所以结论是："200 倍/400 倍"在这份代码里既无法证伪，也无法复现——因为它根本不是这份代码承诺的东西。这份代码承诺的是保真：不重写、只删除、保留的内容逐字不动（README 第一段："everything kept stays verbatim"）。把模型的倍数安到工程头上，是传播中的错位。

比倍数更该较真的：压缩率的三个口径

顺手把"91.5% 压缩率"也验算一遍。仓库里reductionRatio的定义在 src/compact.ts：

export function reductionRatio(result: Pick<CompactResult, 'stats'>): number { const { charsBefore, charsAfter } = result.stats; return charsBefore === 0 ? 0 : (charsBefore - charsAfter) / charsBefore; }

这是字符口径。而stats里同时有消息条数、调用数、state 估算 token 数、请求数——任何一个都能算出自己的"压缩率"。同一个压缩过程，字符可能省 91.5%，消息条数却省不了这么多，因为文本消息在输出里永不删除（README Limitations："Only tool calls and results are candidates; text messages are never removed"），真正被删的只有工具调用及其结果。至于"token 消耗降低近 100%"，本仓库每次压缩都要为完整 state 付输入 token——"近 100%"顶多指"不再为摘要生成付输出 token"，绝不是总成本归零。三个口径，三个结论，都出自同一份代码。

爆款数字该不该先验算

回到最初的问题：193 还是 200、444 还是 400？较真之后的答案不是二选一，而是承认"它们可能都对，只是都不完整"。事实上，在 Jev 刷屏的一周里，质疑声并不少——InfoQ 报道过 Redis 之父直说"绝大多数开发者其实不需要它"，掘金上也有《别吹 Jev 了》这样的反向文章。热度与口水齐飞的时候，一套可落地的验算清单比立场更有用：

1. 找原始出处，而不是转载链。转载每过一手，"区间"变"端点"、"实测"变"宣称"的概率就大一分。
2. 看区间，别看端点。"40–200 倍"比"200 倍"诚实；任何把单一整数写进标题的结论，都应该先问测量边界在哪。
3. 分清模型命题和工程命题。Jev 快，不等于 fast-jev-compaction 快；后者还要算上分批重发完整 state 的代价。
4. 区分推理时间与墙钟时间。单次推理 5–20ms 和一次压缩 5–20ms 是两回事。
5. 警惕演示与生产的距离。录屏动画 demo/JevDemo/main.swift 是戏剧化脚本；真实数字要看联网 demo 和线上压测。
6. 自己跑一遍是最便宜的验算。这个仓库npm install && npm test全程不联网不花钱（fake Jev 兜底），npm run demo才需要TYPESAFE_API_KEY——验算成本低到没有理由不验。

Jev 值不值得关注，和"它到底快多少倍"是两件事。值不值得关注，可以由代码质量判断——src/state.ts 里fitState那套多级收缩策略（输入截断 → 文本缩写 → 旧消息折叠 → 调用单行化 → 无调用消息剔除 → 连续调用合并）确实扎实；而"快多少倍"，只能由可复现的基准回答。下一次再看到"XX 倍"的标题，先问一句：这个倍数，在哪份代码、哪次测量、哪个口径下成立？

【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction