三篇官方 cookbook 里的 Jev 省钱法
先说结论
- 官方 parallel questions 显示，把 13 个问题合并到一次 TypeSafe 请求，比逐个问便宜 12.2 倍、快 10 倍，答案不变。
- autoformat 的省钱方式不是让模型改写，而是把格式拼接、分类之外的结构判断留在代码里，模型只回答窄问题。
- sde cascade 给出一种分级管道：便宜模型先抽、TypeSafe 做字段级验证、验证信号触发时才升级到贵推理模型。
- 省的主要是输入 token；置信度门控、低置信度人工兜底、升级模型费用要一起算总账。
- 我的落地顺序：先合并同 state 问题，再精简 state，最后才用置信度阈值拦截低价值流量。
官方三篇分别讲什么
Parallel questions：同一文档的多个问题一次问
Parallel questions cookbook 官方文档写明：“You have one document and N questions about it. You can send one request with all N questions, or N requests with one question each.” 这里的关键是，同一份文档作为 state 被反复发送，是重复成本。该 cookbook 用 GDPR 维基百科条目（53,777 字符）和 13 个合规问题做测试，官方结论是：“batching every question into one TypeSafe call is 12.2x cheaper and 10.0x faster with no change in answers.” 官方还解释，答案不变是因为每个问题都单独按文档评分：“each question is scored on its own against the document, so its answer doesn’t depend on what else is in the request.”
这不是“把相关问题简单拼在一起”的包装术。我的理解是，它省的地方在于输入 token：一份长文档，逐个问要付 13 次文档输入；合并问只用付 1 次。官方虽然没说“这是推荐省钱法”，但这个 cookbook 把成本差异直接做成了可复算实验。
Autoformat：结构恢复中把确定性动作留在代码
Autoformat / Structure recovery 这页处理的是一个常见场景：一段纯文本失去了 Markdown 标记，被硬换行切碎，需要恢复标题、段落、列表、引用、代码块等结构。许多人的第一反应是让生成模型“改写”成 Markdown。官方 cookbook 的原话是：“A text-generation model could rewrite the text into Markdown, but a rewrite can also change the words. Here the model never generates text: it answers narrow questions about the document… and code does the rendering, so every character of the output comes from the input, and every judgment carries a probability.”
这里的省钱含义需要从工程上看。官方示例把行拼接、空行追踪、行 ID 标注都放在代码里；模型只收到代码无法回答的问题，例如“这个换行是否把一句句子切成两半”“这个块是标题、段落还是列表”。官方写的是：“Direct evidence stays in code. Blank lines and explicit markers ( – , 1. , # ) are read in code, never sent to the model to reconsider.” 我的判断是：这类结构判断如果让文本生成模型做，常会额外生成和改写；改成窄问题后，输出从“任意字符串”压缩成一个概率分布，同时保持原文每个字符可溯源。对成本更直接的是，该页给出这个 memo 的官方数据：“two round trips, 10,211 tokens, 0.8s, $0.0015 for this memo.”
SDE cascade：便宜模型先跑，验证不过再升级
SDE cascade 页面官方概述为：“Uses a 2-stage structured-data-extraction cascade (mini → verify → reasoning) to get most of the quality of a big reasoning model at a fraction of the cost.” 它的算法逻辑官方写得很短：“Extract with a cheap/small model. Verify with TypeSafe primitives… Escalate to an expensive reasoning model if a verifier signal fires; otherwise keep the cheap answer.”
这个思路与常见的“先上小模型，失败再上大模型”一致，但验证层不是简单看 JSON 是否合法，而是用 TypeSafe 的逐字段 Noul 问题，问“这个值是否在原文中不存在”“这个值是否从不相关文本里提出来”，每个字段返回一个 P(something is wrong)。触发升级的阈值写在代码里：FIRE_T = 0.7，意思是任一字段 P(wrong) 超过 0.7 就升级。官方明确写了，两个抽取 rung 使用 text-mode OpenAI，且不用 structured outputs、tool calls、json mode，原因是“a schema following mistake is not the mistake we expect an LLM to make”。我的判断是，这个选择把成本花在模型真正会错的地方，而不是花在格式化约束上。
算账：逐条问 vs 分批问
下面的代码块是本文的可复算骨架。价格是官方数据，文档长度和问题数来自官方 parallel questions cookbook。字符到 token 的换算不是官方数字，这里按 4 字符/token 作为工程假设，读者可以替换成自己的观测值。
# 官方数据：$42 per billion input tokens（typesafe.ai 首页）
# 官方 cookbook 代码中 PRICE = (0.042, 0.00) $ per 1M tokens，两者等价
PRICE_INPUT_PER_TOKEN = 42 / 1_000_000_000
# 官方 parallel questions cookbook 示例：GDPR 维基百科文章字符数
DOC_CHARS = 53_777
# 官方示例把 13 个问题合成一次请求；逐条问则发送 13 次同一文档
QUESTIONS_PER_BATCH = 13
# 本文推算假设，非官方：4 字符约 1 input token
CHARS_PER_TOKEN = 4
doc_tokens = DOC_CHARS / CHARS_PER_TOKEN
one_by_one_input_tokens = doc_tokens * QUESTIONS_PER_BATCH
batched_input_tokens = doc_tokens
saved_tokens_per_round = one_by_one_input_tokens - batched_input_tokens
saved_cost_per_round = saved_tokens_per_round * PRICE_INPUT_PER_TOKEN
for rounds in [10_000, 1_000_000]:
saved_tokens = saved_tokens_per_round * rounds
saved_cost = saved_cost_per_round * rounds
print(f"{rounds:>8} rounds: saved {saved_tokens:,.0f} input tokens, ${saved_cost:,.2f}")
# 输出（自己推算）：
# 10,000 rounds: saved 161,331,000 input tokens, $67.76
# 1,000,000 rounds: saved 161,331,000,000 input tokens, $6,775.90这个简化估算只扣掉文档重复输入，不把问题本身、输出 token、以及批量请求可能的变化算进去。按官方实测，13 个问题合并请求是 12.2 倍更便宜；我上面只算文档部分得到约 13 倍，能对上量级，说明这个场景里文档输入确实是成本大头。要强调的是，$67.76 和 $6,775.90 是我按官方定价和假设 token 换算推出来的结果，不是官方页面直接给出的金额。
三招落地次序（我的建议）
下面是我建议的顺序，不是官方推荐，也不是三篇 cookbook 的发布顺序。标注“工程做法”的地方，是实践选择，需要在自己场景里验证。
第一，先把同 state 的问题合并。 如果同一份文档、同一段上下文要回答多个判断，优先把这些问题放进一次 TypeSafe 请求。官方 parallel questions 已给出证据：合并不改变答案，但输入 token 少付多倍。合并前先确认这些问题共享同一个 state；不共享的内容不要强行凑单。
第二，再缩短 state，只送相关片段。 这是工程做法，不是上述三篇 cookbook 的直接官方指示。Autoformat 给了可迁移思路：不要把确定性工作也交给模型；代码能判断的行拼接、空行、显式标记就不进模型。实际批量判断长文档时，如果一个大 state 里只有一小段与问题相关，可以检索或切块，只送相关片段。但注意，官方 autoformat 里没有做检索或切块的示例，这段属于我的工程建议。
第三，最后才用置信度阈值把低价值流量挡在模型之外。 Confidence 官方文档说明 Choice 和 Score 回答带有 confidence 属性，是从概率分布算出的 0 到 1 单值。官方写：“A confidence threshold is not one number. Different actions within the same system should be gated at different levels depending on the consequences of getting it wrong.” 官方给了高/中/低三段路径，低置信度时不动作、转人工或换系统。我的顺序是：先把确定性高的合并和 state 精简做掉，再上置信度门控，否则门控会拦住很多本可便宜处理的流量，或者在不必要的 token 上花完预算。
反模式清单
- 把整篇文档塞进 state，只问一个是非题。 这是把固定成本付满，产出却只有 1 bit。如果同一文档未来还有问题，尽量批量问；如果只有一两个问题，先看能否把 state 缩小到相关段落。
- 对同一 state 反复发多次请求，每次只问一个问题。 官方 parallel questions 已经显示，文档主导的请求里，逐个问接近为文档输入重复付 N 次钱。
- 把决策模型当开放文本生成器。 Autoformat 官方 cookbook 写得很清楚：“the model never generates text… every character of the output comes from the input”。首页也写明：“Jev returns typed decisions with calibrated probabilities”。如果让它生成解释、长文或改写，既偏离 typed decisions 的设计，还容易把成本结构推向不透明的文本生成。
- 省 token 省到丢掉验证。 SDE cascade 里便宜模型不是终点，verifier 和触发升级才保证质量。为了省钱砍掉验证，可能只是把成本转移到错误率上。
便宜有边界：省输入 token，不等于省到零风险
官方首页写 Jev 定价：“$42 Per Billion input tokens.” 这是输入 token 价格，所以本文所有节省都围绕输入侧；输出、中间重试、升级到其他模型的钱不在这里。Parallel questions 官方只承诺答案不变，不承诺比单独逐个问更准确。SDE cascade 官方原话也承认：“small models are cheap, but make mistakes”。因此把便宜模型接入生产线时，验证信号、升级昂贵推理模型的比例、人工复核成本要一起算。Confidence 文档的“low confidence: Do not act. Route to a human”也要作为成本项而不是免费功能。我的判断是，如果只看每百万输入 token 的降价，却忽略升级和人工兜底，总成本可能反而上升。
这次没核实的
- TypeSafe 官方未给字符到 token 的精确换算；本文代码块中的
CHARS_PER_TOKEN = 4是工程假设，不是官方数据。 - SDE cascade cookbook 中提到“shows the tradeoff across 100 prompts”的完整结果，本稿未能逐项核实其成本/质量曲线数字。
- 官方首页出现“193.6x Faster, 444.6x Cheaper”等营销性对比，其 workload 口径和可复算细节未能在本稿核到，本文没有采用该数字做成本推断。
参考来源
评论区
登录后可评论。