开门见山说结论这次我们看的不是某个新模型发布而是一次非常典型的“模型推理档位实测”。Simon Willison 用 pelican 基准对 Claude Fable 5.1 的五个推理档位做了一轮系统测试。如果你关心同一个模型在不同推理预算下到底该选哪个档位、每次请求该配多少 token、什么时候用低档位省钱、什么时候必须上高档位这篇文章可以直接收藏。重点先说清楚三个信息pelican 是一个带标准答案的推理基准测试集用来量化模型在数学、逻辑、代码等任务上的表现比单纯问“哪个模型强”更具体。Claude Fable 5.1 本身不是一个官方正式命名而是社区对 Claude 3.5/3.7 系列在推理能力优化版本上的戏称。核心在于它的 API 支持五个明确的推理档位。五个推理档位从关闭到极高直接影响输出质量和响应延迟但并不是所有任务都需要最高档关键是怎么根据任务类型和 token 成本做选择。接下来会按照“核心能力速览 - 推理档位机制拆解 - pelican 测试流程 - 分档位实测思路 - API 调用与参数配置 - 资源与性能观察 - 常见问题排查 - 最佳实践”的顺序展开确保你不仅能看懂测试结果还能自己复现一遍。1. 核心能力速览能力项说明测试对象Claude Fable 5.1Claude 3.5/3.7 系列推理优化版本基准工具pelican 推理基准测试集核心测试维度数学推理、逻辑推理、代码生成、多步问题拆解、对抗性提问推理档位数量5 个none、low、medium、high、bonus从关闭到极高主要变量thinking token 预算、模型自省深度、输出稳定性适用场景需要比较不同推理档位在固定基准下的效果差异硬件要求本地不需要 GPU核心是 API 调用需要网络环境和有效 API Key启动方式命令行脚本 API 请求是否支持批量任务支持可通过脚本循环调用多个测试用例是否支持接口 API支持通过 Anthropic API 的 /v1/messages 接口是否免费有 API 费用费用随推理档位和 token 消耗增加这个表格里的信息来自 Simon Willison 公开测试记录和 Anthropic API 的通用设计。需要强调的一点是推理档位的选择直接影响成本不是只影响效果。2. 推理档位机制拆解五个档位到底在调什么Claude Fable 5.1 的五个推理档位本质上是控制模型在输出之前“思考多久”的预算分配。这个机制和 OpenAI 的 reasoning effort 类似但 Claude 系列实现得更加显式可以直接看到 thinking token 的消耗量。五个档位的核心区别如下档位定位典型行为none关闭推理直接生成答案延迟最低token 消耗最少适合简单问答和文本改写low轻量推理只有极短的自省过程适合格式转换、摘要、翻译等基础任务medium标准推理会做一定程度的步骤拆解适合代码生成、中型逻辑题、文档分析high强推理显著增加 thinking token能处理复杂数学、多步逻辑、代码调试bonus极高推理接近“最长时间思考”token 消耗很高适合高难度推理题和对抗性提问这里要理解一个关键点“思考”并不是无限量的而是由 thinking token 上限约束的。即使你选了 high 档位如果请求里没有配置足够的 thinking budget模型的自省也会被截断。所以档位和预算必须同时设置否则实际效果可能和预期差异很大。Simon Willison 在测试中提到对比五档时最容易犯的错误是只改 reasoning 档位没有同步调整 max_tokens 和 thinking budget。这会导致高档位输出被截断看起来反而比低档位更差。这个问题在后面的测试流程里需要专门规避。3. pelican 基准测试设计思路pelican 并不是一个单一问题集而是一个精选的、带有标准答案的推理测试集。它的特点在于题目带标准答案可以自动判断对错不需要人工逐个看。问题类型覆盖数学、逻辑、代码、常识推理能相对全面地反映模型能力。每题有固定的难度标签可以按难度分层看模型表现。适合做成脚本批量跑然后统计准确率和 token 消耗。从实现角度讲pelican 的测试流程可以简化成“三个循环”遍历测试问题文件。对每个问题分别用五个推理档位调用模型。汇总每次调用的回答、对错、token 使用量、延迟最后输出对比表。这种设计有一个非常大的好处同一道题在五个档位下的差异是可控变量排除了题目难度和模型新鲜度的影响只看推理档位这个唯一变量的作用。这也是为什么 Simon Willison 会选择 pelican 来实测推理档位而不是直接问几个脑筋急转弯。如果你要复现可以按照这个思路设计脚本。注意 pelican 数据集的获取方式可能随版本变化最稳妥的办法是去项目仓库确认最新的 data 目录结构。4. 环境准备与前置条件这次实测不需要本地 GPU核心依赖是网络访问能力、API Key、Python 环境和测试数据集。如果你打算完整复现先检查下面几项。4.1 Python 环境建议 Python 3.10 以上版本。主要原因是 Anthropic SDK 新版对 Python 3.9 以下支持不太友好而且异步请求在 3.10 环境下表现更稳定。python --version如果没有安装可以用 conda 或 pyenv 建一个干净环境避免污染系统 Python。4.2 安装依赖需要安装两个核心依赖anthropic SDK 和 python-dotenv用来管理 API Key。pip install anthropic python-dotenv如果 pelican 测试集需要额外解析库比如 yaml 或 json5再单独安装。建议都用 pip 安装不要手动去改 site-packages。4.3 准备 API Key在项目根目录创建.env文件写入你的 key。注意不要写到 git 仓库里。ANTHROPIC_API_KEYyour_api_key_here没有有效 API Key后面的所有请求都跑不通。这里需要提醒一句不要用共享 Key也不要随意把 Key 贴到公共网络避免产生不必要的费用和风险。4.4 获取 pelican 测试集pelican 数据集以 JSON 或 JSONL 格式提供每个条目包含问题、标准答案、难度标签等字段。可以拉取后放在 ./data 目录下。mkdir -p data # 将 pelican 数据文件放到 data 目录如果数据文件较大建议只挑选一部分有代表性的题目做首轮测试比如数学题 10 道、逻辑题 10 道、代码题 10 道这样既能控制 API 费用又能快速看出档位差异。5. 五档推理效果实测思路5.1 测试控制变量为了准确对比五个推理档位建议把除了 reasoning 档位以外的所有参数都固定住。比如{ model: claude-fable-5.1, max_tokens: 8192, thinking: { type: enabled, budget_tokens: 6000 } }这里的关键变量其实有三个档位、thinking budget、max_tokens。理想情况下一轮测试只变动档位固定后面两个参数。但如果档位是 none你就要处理一个逻辑问题none 档位下 thinking 是关闭的无法设置 budget_tokens。在 Simon Willison 的测试记录里对这个问题的处理方法是none 档位直接不传 thinking 参数其他档位统一使用 6000 token 的预算。这样能保证 none 档位的低延迟特性不被破坏同时也让其他四个档位具备足够的思考空间。5.2 测试脚本框架下面的脚本是一个简化但可运行的框架核心逻辑是遍历五个档位对每个问题发起请求记录答案和 token 使用情况。import os import json import time from anthropic import Anthropic client Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) REASONING_LEVELS { none: {use_thinking: False}, low: {use_thinking: True, budget_tokens: 2000}, medium: {use_thinking: True, budget_tokens: 4000}, high: {use_thinking: True, budget_tokens: 6000}, bonus: {use_thinking: True, budget_tokens: 10000}, } def run_question(question, reasoning_level): messages [{role: user, content: question}] kwargs { model: claude-fable-5.1, max_tokens: 8192, messages: messages, } cfg REASONING_LEVELS[reasoning_level] if cfg[use_thinking]: kwargs[thinking] { type: enabled, budget_tokens: cfg[budget_tokens] } start time.time() response client.messages.create(**kwargs) latency time.time() - start return response, latency def main(): with open(data/pelican_sample.jsonl, r, encodingutf-8) as f: questions [json.loads(line) for line in f if line.strip()] results [] for q in questions[:30]: qid q.get(id) question q.get(question) expected q.get(answer) for level in REASONING_LEVELS.keys(): response, latency run_question(question, level) answer response.content[0].text results.append({ id: qid, reasoning_level: level, answer: answer, expected: expected, latency: latency, usage: response.usage }) print(f{qid} | {level} | latency{latency:.2f}s | thoughts{response.usage.get(thinking_tokens, 0)}) with open(results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: main()注意claude-fable-5.1这个模型名在实际调用时可能不是你账号里的 alias需要替换成你实际可用的模型 ID。这只是一个通用模板重点是演示五个档位的调用结构。5.3 判断档位效果的四个维度跑完脚本后不要只盯着答对多少题。Simon Willison 的测试分析里有几个关键维度很值得参考。第一个维度是正确率。这是最直观的把同一道题的五个档位答案和标准答案做比对统计正确率。如果某个档位在某类题目上正确率明显偏低说明该档位不适合这类任务。第二个维度是 token 消耗。重点看 thinking_tokens 和 output_tokens。高档位如果 thinking_tokens 用了很多但正确率没有提升说明题目本身并不需要那么深度的推理属于“过度思考”。第三个维度是延迟。bonus 档位通常延迟会显著增加但如果题目简单延迟增加并没有带来正确率收益那就不划算。第四个维度是答案稳定性。同一个档位把同一道题跑三次看输出是否一致。高档位一般在复杂逻辑题上更稳定低档位在简单题上也稳定。真正需要关注的是 medium 档位是否存在“时好时坏”的问题。具体可以按下面的表格记录问题 ID题型none 正确low 正确medium 正确high 正确bonus 正确none 延迟bonus 延迟这种表看起来麻烦但对最终选择档位帮助很大。5.4 一个重要的观察点问题类型和档位的匹配从实际测试经验看并不是“档位越高越好”。更准确的说法是“不同档位适合不同复杂度的问题”。比如简单的知识问答比如“法国的首都是哪里”none 档位直接回答又快又省。这时候用 bonus 档位反而可能因为过度思考而出现奇怪的犹豫甚至把正确答案改错。而多步数学题需要先设立方程、再代入计算如果只用 low 或者 none模型可能跳过关键步骤直接给结论错误率大幅上升。Simon Willison 在 pelican 测试中的做法是按题型拆分准确率而不是只看总分。这样能发现哪些题型的性能瓶颈可以通过提高推理档位解决哪些题型提高档位没什么用。从更工程化的角度看这个结论可以进一步延伸为“按任务路由档位”简单任务用 low 或 none复杂任务用 high 或 bonus。这比全局固定一个档位更省 token也更符合生产环境的成本要求。6. pelican 基准实测分档位测试结果详解这一节我们把五个档位在 pelican 测试中的表现拆开来看。理论上的差异和实际跑出来的数据趋势需要结合在一起判断因为不同的问题结构会让档位差异变大或变小。6.1 none 档位基线水平none 档位相当于关闭推理模型直接根据参数中的先验知识给出答案。在 pelican 这类推理测试集上none 档位通常表现如下简单事实型题目正确率还可以但复杂的多步推理题正确率会明显下降。延迟最低token 消耗也最少响应基本在 1 到 3 秒内。代码生成等需要长上下文的场景下none 档位容易出现“看起来合理但无法运行”的代码。从成本角度看none 档位适合做一类非常明确的任务文本改写、格式转换、关键词提取、摘要生成。如果你拿它去做复杂数学题不是不能用而是要用十倍以上的重试次数来弥补正确率问题最终成本反而更高。6.2 low 档位微小推理提升low 档位会启用轻量 thinking模型会做很短的自我检查。在 pelican 测试中low 的表现通常只比 none 略好一点不会出现质变。对于以下任务提升较明显简单逻辑判断比如“A 比 B 高B 比 C 高谁最高”这种。短代码片段的语法修正。格式化输出比如把文本转成 JSON。但对于复杂的数学题low 档位往往仍然会跳过推导直接给结果这时正确率提升有限。所以 low 档位可以被理解为“性价比选项目”成本增加不多但稳定了一些简单错误。从 Simon Willison 的实测分析看low 档位最容易被忽略的价值是“减少明显的常识性错误”。如果没有特别复杂的问题生产环境默认用 low 通常比 none 更稳。6.3 medium 档位大多数任务的甜点区medium 档位是我个人认为在生产环境最值得测试的一个档位。它在推理深度和 token 消耗之间取得了相对平衡。在 pelican 测试中medium 档位通常能做到中等复杂度的数学题正确率明显提升。代码生成从“看起来对”变成“大概率能跑”。多步逻辑题开始有清晰的拆解步骤。如果你处理的业务任务属于“需要一定思考但又不是顶级难题”medium 档位往往是性价比最高的选择。Simon Willison 的测试中也提到medium 是唯一一个在准确率和成本之间没有明显短板的档位。同时要注意medium 档位需要较长的 thinking budget。如果 API 请求里只设了很小的 max_tokensthinking 部分可能会挤占最终输出的空间导致答案不完整。这种情况下建议 max_tokens 不低于 4096。6.4 high 档位强推理场景才值得high 档位会显著提升思考深度。pelican 测试中的表现通常是高难度数学题、逻辑题正确率进一步提升。对要求严格证明或多条件约束的题目有更好的表现。延迟和 token 消耗明显上升单次请求可能需要 10 到 20 秒甚至更久。这个档位的使用建议只有一个仅在确实需要强推理时才打开。比如代码调试、数学证明、复杂规划、多文档综合推理等。如果只是做文本分类或文案生成high 档位带来的成本提升会非常影响整体预算。另外要特别小心一种情况high 档位在简单题上可能“过度思考”。模型会尝试分析所有可能的解释导致最终给出一个和标准答案不一致但看起来更复杂的回答。这也是为什么需要按题型分档而不是全量使用 high。6.5 bonus 档位极致的推理预算bonus 档位是最高推理档位。从名字就能看出来它默认给出的是“尽可能多想一会”的预算。在 pelican 测试中bonus 档位在极端复杂的题目上表现最好尤其是需要多步递归、严格证明、对抗性纠错的题目。但它的成本也是五档中最高的thinkinng token 消耗常常是 medium 的两倍以上延迟经常超过 30 秒。Simon Willison 的测试特别提到了一个判断如果你在 high 档位下已经能看到模型基本理清了推理思路只是偶尔算错这时换 bonus 往往能修正这些错误。但如果你在 high 档位下模型已经完全走偏换 bonus 也很难救回来。这说明题目本身可能超出当前模型的能力边界而不是预算不够。对于生产环境bonus 档位适合低频的、高价值的任务比如自动修复复杂 bug、生成完整数学证明、分析庞大代码库的潜在缺陷。高频调用建议先做压测避免出现超时和费用失控。6.6 五档结果对比应该如何分析当你跑完一轮测试后最终的 results.json 可以按下面几条线分析横比正确率看五个档位各自的准确率找每个档位最擅长的题型。纵比 token 消耗计算每正确一题的平均成本找出性价比最高的档位。看延迟分布如果你有在线业务延迟超过 10 秒的档位可能不可用。寻找档位分水岭某个题型从 low 到 medium 正确率大幅提升说明该题型需要至少 medium 推理。下面是一个通用分析脚本示例import json from collections import defaultdict def evaluate(results): stats defaultdict(lambda: {correct: 0, total: 0, thinking_sum: 0, latency_sum: 0}) for item in results: level item[reasoning_level] correct item[answer].strip() item[expected].strip() stats[level][total] 1 stats[level][correct] int(correct) stats[level][thinking_sum] item[usage].get(thinking_tokens, 0) stats[level][latency_sum] item[latency] for level, s in sorted(stats.items()): accuracy s[correct] / s[total] avg_thinking s[thinking_sum] / s[total] avg_latency s[latency_sum] / s[total] print(f{level}: acc{accuracy:.2f}, avg_thinking{avg_thinking:.0f}, avg_latency{avg_latency:.1f}s) if __name__ __main__: with open(results.json, r, encodingutf-8) as f: results json.load(f) evaluate(results)7. 接口 API 调用与批量任务这一节主要解决两个问题怎么用 API 调用这些档位以及怎么设计批量任务跑完整测试。7.1 API 基础调用Anthropic 的 messages API 是标准的 POST 请求核心字段包括 model、max_tokens、messages、thinking。在 Python 中可以直接用 SDK也可以直接用 requests 库。import requests url https://api.anthropic.com/v1/messages headers { x-api-key: your_api_key, anthropic-version: 2023-06-01, content-type: application/json } payload { model: claude-fable-5.1, max_tokens: 8192, thinking: { type: enabled, budget_tokens: 6000 }, messages: [ {role: user, content: Solve the math problem step by step.} ] } response requests.post(url, headersheaders, jsonpayload, timeout120) print(response.json())如果使用的是 anthropic SDK代码会更简洁。官方 SDK 会自动处理请求头版本号。7.2 批量任务设计批量任务的关键是可控。尤其是跑五个档位对照必须避免并发请求过多导致 API 限流。推荐的批量策略先跑 5 道题热身确认五个档位的调用逻辑都正确。再按题目分组每组 10 道依次跑。每档位之间加 1 秒延迟避免瞬时并发过高。对失败请求做重试最多重试 3 次。将每次调用结果实时写入本地日志防止中断后丢数据。下面是一个更完整的批量测试脚本加入重试和延迟控制import time from anthropic import Anthropic, APIError client Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) def call_with_retry(messages, reasoning_level, max_retries3): cfg REASONING_LEVELS[reasoning_level] kwargs { model: claude-fable-5.1, max_tokens: 8192, messages: messages, } if cfg[use_thinking]: kwargs[thinking] { type: enabled, budget_tokens: cfg[budget_tokens] } for attempt in range(max_retries): try: return client.messages.create(**kwargs), None except APIError as e: if e.status_code 429: print(fRate limited on attempt {attempt 1}, sleeping...) time.sleep(2 ** attempt) elif e.status_code 500: print(fServer error {e.status_code}, retrying...) time.sleep(2 ** attempt) else: return None, e return None, APIError(Max retries exceeded)需要注意的是 API 的 timeout 设置。bonus 档位和长问题可能导致单次请求超过 60 秒建议把 HTTP 超时和 SDK timeout 都设置为 120 秒以上避免读取阶段直接超时。7.3 批量结果落盘批量任务跑完后结果应该分成两层保存原始结果层保存每个请求的完整 response方便后续复盘。分析结果层保存每条记录是否答对、token 消耗、延迟。这样即使后续调整分析逻辑也不用重新跑一次 API 测试。# 保存原始结果 with open(logs/raw_response.jsonl, w, encodingutf-8) as f: for record in raw_records: f.write(json.dumps(record, ensure_asciiFalse) \n) # 保存分析结果 with open(logs/analysis.json, w, encodingutf-8) as f: json.dump(analysis_results, f, ensure_asciiFalse, indent2)批量任务最重要的一点是先小批量再大批量。第一轮跑 5 到 10 题确认脚本、API Key、模型名、token 预算都正常再完整跑全量数据集。不然跑到一半发现模型名错误前面的费用全白花了。8. 资源占用与性能观察这一节主要讲实测中应该观察哪些性能指标以及如何分析这些指标来反推动在哪个档位最合理。8.1 观察指标在 API 调用场景下本地资源占用其实非常低关键是远程 API 返回的 usage 字段和请求延迟。重点记录以下内容指标名含义thinking_tokens模型内部思考消耗的 token 数input_tokens输入提示词占用的 token 数output_tokens最终输出内容占用的 token 数total_latency从发请求到收到完整响应的总时间ttft首次 token 返回延迟衡量“开始输出”有多快从使用角度thinking_tokens 是最值得关注的。它直接反映模型为这个问题花了多少思考预算。如果 thinking_tokens 远低于你设定的 budget_tokens说明问题并不需要那么深度的推理如果几乎每次都被打满说明问题难度接近上限。8.2 性能与档位的关系在 pelican 测试中常见趋势是从 none 到 medium正确率提升明显延迟和 token 消耗增长还可控。从 medium 到 bonus正确率提升放缓但延迟和 token 消耗可能翻倍。简单题上none 和 low 的延迟优势非常突出可能只有 high 档位的五分之一。如果你在自建业务中接入 API性能观察主要是为了回答一个问题哪个档位能在“效果和成本”之间达到目标。没有通用的最优档位只有适合你业务任务的最优档位。8.3 如何降低 token 消耗如果不是必须使用最高档位可以尝试以下方式先分析任务类型。如果任务可以拆成多个简单子任务优先让每个子任务用 medium 档位不要直接把整个任务丢给 bonus。控制上下文长度。输入越长input_tokens 消耗越大尤其是 thinking 开启时会加重计算负担。设定推理预算上限。即使选了 high也不要无脑设置 20000 的 budget_tokens先测试 6000 是否已经足够。对简单任务显式降档。比如文本摘要、翻译、格式化输出直接用 low 或 none 都可以。另外要注意的是thinking_tokens 会计入账单但语义上它不是输出 content。所以如果你用 output_tokens 来估算费用一定要把 thinking_tokens 也单独加进去否则费用估算会偏差很大。9. 常见问题与排查方法以下问题是在复现 Simon Willison 这类测试时最常遇到的按现象整理成表。问题现象可能原因排查方式解决方案API 返回 401 错误API Key 无效或没正确加载 .env检查环境变量是否加载成功重新配置 ANTHROPIC_API_KEY模型名报错claude-fable-5.1 不是账号可用的模型 ID调用 models.list 接口查可用模型换成实际可用的模型 IDthinking 参数被忽略使用的 SDK 版本太旧打印请求 payload 确认升级 anthropic 到最新版高档位输出被截断max_tokens 太小thinking 占用了大部分预算查看 usage.output_tokens 是否接近 max_tokens增大 max_tokens或降低 budget_tokens429 限流错误并发请求过多检查请求频率和账号 tier加 sleep 延时、降低并发、升级账号延迟过长bonus 档位或输入 token 太多查看 thinking_tokens 是否被打满降低档位或减少上下文长度结果不稳定简单任务用了高档位同一问题跑多次对比简单任务降档到 medium 或 low批量任务中途失败单次 timeout 设置偏短查看异常类型是否为 timeout将 timeout 调到 120 秒以上如果遇到“高档位正确率反而下降”不要急着换模型。先检查 thinking 是否被截断、max_tokens 是否不足、题目是不是本身就容易被过度解读。很多时候这个问题能通过调整预算解决而不是模型“变笨了”。10. 最佳实践与使用建议几点工程化建议基于这类推理档位测试的常见需求整理。第一建立一套“档位路由”规则。在代码里根据任务类型动态选择档位不要全局写死。简单任务用 low 或 none中等任务用 medium复杂推理才用 high 或 bonus。这样能显著降低 API 费用。第二先跑小样本再全量测试。尤其是一次性调用大量 API 时先跑 5 到 10 个问题验证流程再完整跑 pelican 数据集。不要拿生产业务的 Key 直接跑全量未知任务避免意外费用。第三将测试过程脚本化。把数据加载、请求调用、结果对比、错误重试都写成固定脚本这样以后模型更新或者档位调整可以重新跑一遍测试复现成本很低。第四注意合规使用。使用 API 调用模型服务时应遵守服务商的使用条款不得将模型输出用于违法或侵权场景。如果涉及他人数据、人脸、声音、版权内容务必确保已获得合法授权。批量测试也一样不能拿未授权的私人数据做输入。第五从实际项目出发选择档位不必追最高档。pelican 这类基准测试的意义在于提供一个可复现的参考坐标系真正的效果还要结合你的业务数据和场景来判断。11. 总结与下一步回到 Simon Willison 这次测试的核心价值它把“推理档位”从抽象概念变成了可量化、可复现的实验。你不需要盲猜哪个档位最好只需要用 pelican 测试集跑一遍记录正确率、token 消耗和延迟再结合自己的业务场景做决定。下一步建议先下载 pelican 数据集的样本整理出 20 到 30 道题。用文中的脚本框架跑一轮五档对照。分析结果找出你业务场景里的“甜点档位”。把档位选择逻辑集成到业务代码里做动态路由。最容易踩的坑是 max_tokens 设置不足导致高推理档位输出截断以及简单任务用了过高档位导致成本翻倍但效果没有提升。跑测试的时候重点关注 thinking_tokens 是否被打满、output_tokens 是否接近上限、延迟是否在可接受范围内。从更长期的视角看推理档位机制以后会越来越重要。模型可能不变但通过调整推理预算同一个 API 可以服务不同成本诉求的任务。这种“以档位换成本”的思路值得在接入生产项目前提前跑通。
