只判断不生成：Jev 的 70–500ms 端到端，到底省掉了什么

只判断不生成Jev 的 70–500ms 端到端到底省掉了什么【免费下载链接】Bespoke-Nimble-9B项目地址: https://ai.gitcode.com/hf_mirrors/bespokelabs/Bespoke-Nimble-9B2026 年 9 月TypeSafe AI 推出的 System One 模型 Jev 刷屏端到端响应 70–500 毫秒、输入每百万 Token 低至 0.042 美元、输出 Token 永久免费、社区对比某些生成式 API 时宣称快 193.6 倍、便宜 444.6 倍。外行看到的是速度与价格内行看到的是一个反直觉的设计决策——它不生成任何内容。Jev 把判断从生成中剥离了出来你给它一段上下文和一组合法选项它只返回一个选项和一组概率连一个字的解释都不写。本文以 Jev 的开源平替 Bespoke-Nimble-9B 仓库为解剖样本逐行拆解这个设计。这个仓库是一个 Qwen3.5-9B 的 LoRA 适配器约 165 MiB附带精确的 prompt 构造器、参考推理代码与全套校验合约。它没有复制 Jev 的权重但完整复刻了只判断不生成的服务协议。看懂它你就看懂了 70–500ms 的延迟账到底记在谁的头上。System One从生成答案到给答案打分先澄清一个容易误读的点System One 模型在架构层面没有任何魔法。adapter_config.json 显示Bespoke-Nimble-9B 就是标准的 Qwen3.5-9B 加 LoRApeft_type: LORAr: 16目标模块覆盖全部 QKV 与 MLP 投影。所谓去掉生成改的是推理协议与训练目标不是模型结构。服务侧读一次只打一个分官方 README 用一句话概括了这套协议Serving reads the prompt once and then scores one answer token per question。落到代码上是三步一次 prefill把 context schema 渲染成的 prompt 灌进模型KV cache 只填充一次只取最后一个位置的 logits并从中抽出候选 token 的分值softmax 归一化成概率直接返回。inference.py 里的candidate_logits是这套协议最核心的三行logits model(input_idsinputs[input_ids], attention_maskinputs[attention_mask], use_cacheFalse, logits_to_keep1).logits[:, -1, :].float() selected logits.gather(1, inputs[candidate_ids]) return selected.masked_fill(~inputs[candidate_mask], -torch.inf)注意logits_to_keep1——整个前向只保留最后一个位置的输出。之后在decision_result里做一次除法与 softmax温度由 temperature_config.json 固定为 T1.0temperature_fitted: false明确标注prior releases calibration does not apply即旧版本拟合的 2.179 温度不适用于本 checkpointscaled_logits logits / temperature probs scaled_logits.softmax(-1)训练侧只对答案 token 算损失只判断不生成要想成立训练目标必须同步收敛。schema_config.json 把任务登记为schema_candidate_classification_v2训练只在允许的候选 logits 上计算交叉熵而不是标准的预测下一个 token全词表损失。训练配置本身是克制而常规的LoRA rank 16、学习率 5e-5、有效 batch size 8、1 epoch、12026 行训练数据、max_length: 8192。训练数据的构造方式更值得玩味——README 称之为contrastive data curation写一对几乎相同的例子只改动一个事实比如退款授权签署人从 Mira 换成 Noah让正确答案翻转其余全部不变。模型从这样的配对里学会哪条证据应该改变决策而不是学会接着往下写。这正是判断与生成在数据层面的分水岭判断模型的训练信号来自判别不是来自续写。候选必须是一个 Token打分成立的前提是每个候选答案必须编码成恰好一个token这样所有候选才能共享同一次前向、同一位置。parallel_schema.py 对此做了硬校验if combined[:len(ids)] ! ids or len(suffix) ! 1 or suffix[0] in tokenizer.all_special_ids: raise ValueError(fChoice code {code} is not one ordinary token at the answer boundary.)26 个以内用 A–Z扩展到 255 个时extended_schema.py 会从 Qwen 词表中筛选两个或三个大写字母且独立成词的编码AA、AB、…、JT逐段校验它们在实际答案边界处确实只占一个 token。这个设计也顺带解释了 Jev 家族普遍存在的选项上限不是模型读不了更多选项而是词表里干净的单 token 大写编码是有限资源。一步输出与自回归的本质区别要理解省掉了什么得先精确地说出自回归做了什么。自回归生成把输出写成条件概率的连乘p(y₁…y_T | x) ∏ₜ p(y_t | x, y_t)。每生成一个 token都需要一次完整的前向计算、一次 KV cache 扩展、一次采样、一次终止判断。生成一段 300 token 的思考链意味着 300 次串行前向而思考链越长每次前向扫过的上下文越大单位成本反而越高。一步概率化判断把问题整个换掉了决策被定义为一个封闭候选集上的条件分布 p(c | x)。所有候选共享同一个输入上下文一次前向同时得到全部候选的 logitssoftmax 一次归一化即告完成——没有串行依赖、没有采样、没有 EOS。这个区别带来的并不只是快而是三个工程性质的变化第一概率成为一等公民。inference.py 的decision_result不仅返回prediction还逐候选返回probabilities与logits对打分型字段Score额外计算expected_score Σ int(v)·p对布尔字段返回probability_true。下游拿到的是一份可直接参与阈值判断、加权聚合的数据而不是一段需要二次解析的文本。第二输出协议被类型化。返回值直接由 Python 代码构造为 dict{output: {...}, fields: {...}, temperature: 1.0, ...}README 原话是there is no generated JSON to parse。生成式模型那一整套JSON schema 约束解码 → 解析 → 校验失败 → 重试的成本在这里从协议层面消失了。第三prefill 可以共享。parallel_schema.py 用__PARALLEL_FIELD_TARGET__这个 marker 把 schema 渲染一次然后在 Requested field: 处替换不同的字段名得到 N 个只差一个字段名的 promptmarker __PARALLEL_FIELD_TARGET__ content safe_json({context: context, schema: fields}) \n\nRequested field: marker构造完成后代码计算 N 个 prompt 的公共 token 前缀prefixMLX 版 scorer 据此只 prefill 一次、再并行给多个字段打分。多个判断共享一次上下文阅读——这对同一个工单要判优先级、判是否需审核、判类别这类多字段场景是实打实的倍数级收益。还有一处容易被忽略的细节chat_template.jinja 在enable_thinkingFalse时输出空思考块think\n\n/think。也就是说Qwen3.5 系模型引以为傲的思考链在这套协议里被显式置空——它不是被跳过了而是被从计算路径上移除了。70–500ms 的延迟账省的是 decode还是整条链路答案是decode 是最大头但省掉的远不止 decode。官方在 324 条留出样本上的实测延迟毫秒/例可以摊开看这笔账模型中位数均值p95运行环境Qwen3.5-9B未调优同协议打分58.159.875.8H100Bespoke-Nimble-9B106.0110.1119.8H100Bespoke-Nimble-9B444.0546.0981.0M5 Pro 64GBMLXJev 1.13.0246.7267.0347.4TypeSafe API含网络DeepSeek-V4.1-Flash生成式2896.45238.015065.4OpenRouterQwen3.8 2.4T A95B生成式2792.33108.05110.5OpenRouter注未调优模型同样以打分方式评测故 58ms 可视为一次 prefill 打分的基线成本LoRA 层与 BF16 计算把 Nimble 推高到 106ms 量级。这笔账可以拆成四层1. 省掉的是 decode 的乘法效应。生成 300 个 token 的推理链 300 次 decode 前向每次都要扫过不断增长的 KV cache判断模型只做 1 次 prefill。这不是省掉 300 毫秒的问题而是把输出长度 × 每 token 成本的乘法结构整个删掉了——延迟与上下文长度的关系从随输出线性增长变成随输入一次性线性。2. 省掉的是思考链的整段开销。空think块意味着模型不对内部推理分配任何 token 预算也不需要为推理内容做一致性校验。生成式方案里想太多、想歪、幻觉三种最常见的失败模式在这条链路上根本没有落点。3. 省掉的是输出侧的协议税。没有 JSON 生成就没有 JSON 解析没有约束解码就没有重试没有输出 token 就没有输出侧 KV cache 增长。这也直接解释了 Jev 的定价结构输出 Token 永久免费、输入每百万 Token 0.042 美元——因为计费维度上输出这个量纲已经不存在了。4. 没有省掉的是 prefill。值得诚实地说max_length: 8192schema_config.json意味着长上下文下 prefill 依然是主要成本仓库对超长 prompt 的策略是直接拒绝而不是截断Nothing was truncated。社区报道里快 193.6 倍是与特定生成式 API 的对比数字量级上成立但准确的表述是Jev 的 70–500ms 是网络 排队 一次 prefill 一次打分的总和而生成式方案的 2.8–5.2 秒里绝大多数时间花在了它根本没有在做的那件事上。代价与边界省出来的延迟对应着什么样的取舍任何架构取舍都有另一面。这套协议省掉的生成能力恰恰也是它的边界官方 README 逐条写得很清楚只能从你给的选项里选。枚举字段 1–255 个选项布尔字段二选一模型不能输出自由文本、不能解释理由、不能截取原文片段。如果真实答案不在候选集里必须由调用方预留无匹配选项。字段彼此独立。每个字段单独打分一个字段看不到另一个字段的答案跨字段一致性只能由业务层校验。概率不是正确率的承诺。README 的原话是A probability of 0.9 still does not mean that the answer is right 90% of the time on your data。概率可以在统计意义上被校准旧版曾拟合 T2.179 以把 ECE 从 0.128 压到 0.066但在具体业务数据上任何阈值都需要自行重新验证。质量数据同样要放在这个背景下看官方 324 条留出样本上Bespoke-Nimble-9B 对参考标签的命中率为 90.12%同协议下的 Jev 1.13.0 为 93.21%而未经调优的 Qwen3.5-9B 只有 66.36%。差距不在架构——两者执行的是同一种打分协议——而在训练数据的规模与概率校准的打磨程度。这恰好解释了为什么 Jev 发布后三天内就出现了 LayaModernBERT 编码器路线、32.8ms 延迟、以及 Nimble、Verdict、OpenJev 等至少八个开源复刻项目Ollama 0.35 也把这类决策模型塞进了本地推理实测中位延迟 33–91ms。开源社区达成的共识是一致的只判断不生成不是 Jev 的专利而是一套可复现、可工程化、可本地化的推理范式。回到标题的问题70–500ms 的端到端省掉的不是速度这一个变量而是自回归生成作为决策工具时的那整套心智模型——串行 decode、思考链、采样、JSON 协议税、输出计费。判断被从生成中剥离出来之后剩下的链路干净得近乎朴素读一次、打一个分、返回概率。对 Agent 里大量有界判断场景——请求路由、策略执行、内容审核、工单评分——这恰恰是性价比最高的分工慢思考交给 System Two快判断交给 System One。【免费下载链接】Bespoke-Nimble-9B项目地址: https://ai.gitcode.com/hf_mirrors/bespokelabs/Bespoke-Nimble-9B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考