让 GPT 打分还是让 Nimble 打分：决策延迟差 190 倍的账要这么算

让 GPT 打分还是让 Nimble 打分决策延迟差 190 倍的账要这么算当你的 Agent 需要判断这条工单该路由给谁这段回答值几分这条评论是否违规时最自然的做法是把它丢给大模型请根据以下标准打分输出 JSON。 结果往往是一个三秒的思考加一段冗长的论证最终只为了回答一个 yes/no。这就是 AI 决策里的延迟税——你用写作文的算力去付了一道判断题的钱。过去一个月围绕 Jev 式System One 决策模型的讨论在社区里密集发酵TypeSafe AI 的 Jev 宣称端到端响应 70–500ms、速度提升达 193.6 倍、输入成本低至每百万 token 0.042 美元Ollama 0.35 跟进支持本地运行这类模型单次决策中位延迟低至 33msBespoke Labs 则把 Nimble 以 Apache 2.0 协议开源其中 9B 版本就是一个可直接下载、可自托管、可审计的 LoRA adapter。这套数字背后的账到底怎么算哪些判断值得从生成式大模型迁移到一步概率输出哪些必须留在原地本文不引用任何营销口径直接从 Bespoke-Nimble-9B 仓库源码出发把延迟、成本、置信度三本账逐一摊开。同一判断任务两种根本不同的实现生成式打分把判断当写作执行让 GPT 打分本质是让一个自回归语言模型去生成答案。模型每输出一个 token都要完成一次完整的前向计算并做采样几十到几百个 token 的推理过程、JSON 包裹、解释性文字全部按输出 token 计费。更麻烦的是格式风险模型可能少写一个花括号、多给一个字段、或者把分数解释成一段话——下游解析层还得再兜一层。Nimble把打分重构为受限分类Bespoke-Nimble-9B 的训练任务被命名为schema_candidate_classification_v2见 schema_config.json它把判断建模为给定 context 与 schema字段类型 候选值从候选答案中选一个。README 的第一句话就点破了设计取向It scores the allowed answer tokens directly; the evaluated workflow does not generate reasoning or free-form answers.模型不做推理、不产自由文本只对允许的答案 token打分。以仓库自带的调用为例README.mdfrom inference import NimbleModel model NimbleModel(nimble-model) result model.score( contextThe store accepts returns within 30 days. This item was bought 12 days ago., schema{ eligible: { type: boolean, description: Is this item within the store return window? } }, ) print(result[output]) print(result[fields][eligible][probabilities])这一步的关键在推理实现inference.py模型只算一次前向取出最后一个位置对候选 token 的 logits然后 softmax 出概率def candidate_logits(model, inputs): 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)scaled_logits logits / temperature probs scaled_logits.softmax(-1) index logits.argmax().item()logits_to_keep1意味着只保留最后一个位置的 logitsuse_cacheFalse说明连 KV cache 都不需要——没有逐 token 解码循环没有采样没有格式解析。一次前向、一个 argmax判断结束。候选答案编码把选项变成一个 token为了让选 A 还是选 B落在概率空间里Nimble 使用了大写字母作为候选码parallel_schema.pyschema 里的每个字段渲染为带__PARALLEL_FIELD_TARGET__标记的提示词候选选项映射为 A–Z 的单 token 编码选项超过 26 个时则升级到 extended_schema.py 的宽候选方案从词表里筛选出 AA、AB……一直到 JT 共 255 个单 token大写编码见 serving_config.json 中的完整码表与 token id。每个候选码是否真的对应唯一 token在提示词的真实 assistant 边界处逐一验证编码不一致直接抛错——这是把生成式打分降维成受限分类的地基工程。支持三种字段类型恰好对应判断类任务的三类常见形态booleanyes/no 类判断额外返回probability_trueenum多选一分类选项上限 255 个可带choice_descriptions说明评分rubricenum取值限定为整数串如[0, 1, 2]并传入score_fields此时除选中的档位外还会输出按概率加权的期望分result model.score( context..., schema{ quality: { type: enum, description: Rate the answer quality on the rubric., choices: [0, 1, 2], choice_descriptions: { 0: Poor: irrelevant or wrong, 1: Acceptable: mostly correct, 2: Excellent: complete and accurate, }, }, }, score_fields[quality], ) print(result[fields][quality][expected_score])expected_score Σ int(v) × p(v)的实现就在 inference.py 的decision_result里——你不是只拿到一个档位而是拿到整个概率分布上的期望值这让打分从离散标签变成了可连续运算的量。延迟、成本、置信度三本账一起算延迟账写作型解码 vs 单次前向生成式打分的延迟由输出长度主导。一次典型的请打分并给出理由调用输出 80–200 token 很常见按 30–60 token/s 的 API 解码速度光生成就是 1.5–6 秒还没算排队与网络。而 Nimble 这类决策模型的延迟由输入长度 单次前向主导输出侧只有 1 个 token 的成本。社区数字提供了两个可交叉验证的锚点Jev 官方口径为端到端 70–500ms、较通用模型快 193.6 倍Ollama 0.35 本地跑同类决策模型单次决策中位 33ms、典型值 91ms。把 GPT 类模型一次结构化打分按 2 秒量级估算Nimble 本地单次前向按 10ms 量级估算190 倍的差距就是这么来的——它不是一个精确测量值而是两条技术路线在延迟构成结构上的量级差一个延迟随输出长度线性增长另一个与输出长度彻底解耦。仓库里还能找到一组佐证这个结构的细节schema_config.json 里最大上下文 8192 token、超限直接拒绝而非截断Nothing was truncated.因为截断会悄悄改变判断依据宁可报错也不能静默降质推理全程torch.inference_mode bf16 autocast训练时使用的温度策略在 temperature_config.json 中被明确锁定为softmax(candidate_logits / temperature)。成本账输出 token 是最大的隐藏账单生成式打分的成本大头往往不在输入而在输出一次 150 token 的打分作文按输出计费是纯写论文的开销。决策模型的账面上输出侧几乎为零——Jev 的定价直接把输出 token 设为免费输入端低至每百万 0.042 美元而开源侧的 Nimble 更激进adapter 本体只有约 165 MiBREADME.md跑在本地意味着 API 成本归零Ollama 0.35 的总结里直接写了零 API 成本。即便自托管单次前向 vs 上百 token 解码算力消耗的差距同样按输出长度比例放大。需要说明的是Nimble 是 LoRA adapterlora_rank16见 adapter_config.json需要 Qwen3.5-9B 基座权重仓库刻意不重复存放基座、只发布可审计的适配层与校验和SHA256SUMS——这是把成本透明做到位的一种工程姿态。置信度账口头自信 vs 可校准概率生成式模型的置信度是文字性的我认为很可能是……无法参与下游的阈值决策也无法做数学运算。Nimble 的每个字段返回完整的候选概率字典与 logitsinference.py 的decision_result布尔字段给probability_true评分字段给期望分。有了概率才能做置信度门槛、人机回退、集成聚合这类工程操作。但必须诚实指出置信度账上的两笔欠账。其一temperature_config.json 明示temperature_fitted: falseT1.0 是本 checkpoint 的评估默认值且不能复用旧版本拟合出的 2.179 校准参数——温度未做单独拟合意味着概率的绝对标定还有优化空间。其二社区对 8 个开源 Jev 复刻项目的核查涵盖 Nimble、Laya、SemIf 等指出结构化决策接口已高度复现但 RLCD 式概率校准、高基数选项的泛化、跨任务基准的统一仍是核心差距仓库里heldout_family_overlap: false与validation_order不洗牌等细节schema_config.json说明作者在刻意控制评估严谨性但校准工作确实尚未完成。用概率做排序没问题直接当绝对可信度用还需自己标定一轮。哪些判断值得迁移哪些必须留在大模型值得迁移有界、高并发、可枚举的判断迁移的充分条件是判断空间有界。结合仓库支持的类型与社区落地方案以下几类天然适配路由与分诊工单路由、意图分流、问题归类——多选一 enum选项数可控护栏与审核内容是否违规、回复是否越界、调用是否安全——布尔判断Ollama 0.35 的总结里明确点名了内容审核场景标准化评分答案质量、检索相关性、生成结果合规性——rubric 整数档 期望分恰好是score_fields的标准用法Agent 内部高频判断每一步决策前的小判断正是延迟税最痛的地方也是 Jev/Ollama 文章里反复强调的高并发场景。这些场景的共同特征判断可被 schema 表达、上下文在 8192 token 内、候选数在 255 以内、不需要解释性输出。Nimble 的训练数据构成也印证了这类泛化意图——schema_config.json 的数据审计显示12,026 行训练数据横跨 5,370 个任务族其中包含 Banking77、MultiNLI、BoolQ、AG News、DBpedia、TREC 等公开基准的混合另有 contrastive-addition对比增强与 retrieval-classification检索分类等自建组件heldout_family_overlap: false意味着评估时家族级隔离测试的不是背题而是迁移。注册的两个评估集bespoke-eval 324 行、jevbench-eval 534 行也指向跨任务判断而非单点刷分。必须留下开放生成与需要解释的判断反过来说以下情况不建议迁移需要推理链与解释客户要的是为什么拒绝退款不是refused两个字符——Nimble 的系统提示词刻意写着Return only that choices one-letter code, without reasoning or explanation它被设计成不说理由自由文本输出改写、总结、生成schema 模型完全覆盖不了超长上下文8192 token 上限且超限即拒长文档判断仍需留在大模型侧或先做检索降维高基数开放分类候选超过 255 个、或类别边界本身在漂移的任务硬编码候选码会拖垮泛化。社区对开源复刻的核查还有一条值得引用的结论25 类以内的小基数决策如意图路由、安全护栏是当前决策模型最扎实的舒适区而 77 类 Banking77 这类高基数任务表现会明显受限——迁移前先数数你的选项有多少个。混合架构才是终局把两本账合起来看结论不是用 Nimble 取代 GPT而是把判断从生成里拆出来先用轻量决策模型做高并发、有界的判断与预筛路由、护栏、初评把概率低或边界模糊的样本升级给大模型做深度推理与解释。Nimble 的概率输出恰好为这条流水线提供了天然的回退信号。Jev 论文里提出的LLM 验收 模型路由组合本质上就是这个分工的工程化System 1 快速判断System 2 慢思考兜底。谁负责什么取决于任务是要一个答案还是要一段思考——账算清楚之后这个选择并不难做。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考