Autoresearch成本实战：1293个实验烧掉779M tokens的经验与排查指南

Autoresearch 这类自动研究任务最让人兴奋的是“一句话需求变成一批实验”最让人头疼的是 token 像水一样烧。最近我在 GPUMode 下跑完了第三轮自动研究批次累计 1293 个实验消耗 779M tokens。先给结论它适合做广度探索不适合当标准答案生成器。真正进入最终报告的有效实验并没有想象中多大量 token 消耗在中间检索、上下文累积和失败重试上。下面按实际落地顺序拆一遍。如果你也在跑多智能体自动研究或者正准备尝试可以直接照着这个思路做成本预估、批次规划、参数控制和问题排查。1. 一句话需求如何变成 1293 个实验Autoresearch 的任务切分逻辑先说明一个很容易误解的点Autoresearch 不是再开一个对话框和模型长聊而是一条完整的任务流水线。输入研究目标后系统通常会让规划智能体拆出子任务让检索智能体去找资料和数据集让代码智能体去写实验脚本让评估智能体去判断结果是否有效最后再由汇总模块整理成报告。每一步都要和模型反复交互每一步都会消耗 token。这套流程适合谁适合做 AI 应用开发、做模型评测、做数据实验以及想用多智能体自动跑实验但不知道成本怎么控制的人。不适合只想给一个 Prompt 就生成一份标准报告的场景那种需求用普通对话模型更直接也更省。标题里的 Another Typical Autoresearch Post我现在觉得 typical 不是自嘲而是这类自动研究任务已经越来越常见。1293 个实验说明任务被切得很细779M tokens 说明切得细并不等于算得准。实验数量看起来很多但真正能支撑结论的可能只是其中一小部分。1.1 Autoresearch 不是单个模型对话而是一条多智能体流水线我一般会把自动研究流程拆成四类角色规划器把研究目标改写成具体步骤和假设。检索器收集相关资料、数据集和参考实现。执行器写代码、跑实验、记录输出。评估器判断实验结果是否支持假设决定是否继续迭代。有的流程还会加一个调度器负责管理任务队列、并发数量和失败重试。只要角色一多一个问题就变得非常明显每往下一个环节传递上下文前面所有历史都会被重复携带。比如执行器在写代码时不仅要看到规划器给的目标也可能要看到检索器找到的资料等到评估器介入时它又要读取执行器产生的完整日志。上下文越带越长token 消耗自然成倍上涨。这也是为什么“什么任务消耗的 token 大”这个问题没有简单答案。看起来最长的任务不一定最费 token真正费 token 的是那些上下文重复次数多的任务。一次普通对话大概只需要携带当前聊天记录一次自动研究任务却可能需要把研究目标、检索结果、代码、报错信息、修复方案、实验输出全部重新读一遍。GPUMode 第三轮里我特别观察过这种累积效应。同一个实验如果连续失败三次第三次请求的输入 token 可能比第一次多一大截因为前两次失败时的日志和修复尝试都被带上了。如果这个实验只是随机种子不同那这部分 token 基本等于浪费。1.2 为什么一次研究会被拆出这么多实验1293 个实验听上去很多但拆开看其实很常见。主要来源有这么几个。第一是假设拆解。一个研究目标往往不是单一问题。比如“比较两个模型在小样本分类任务上的表现”这个目标本身就包含模型 A、模型 B、不同数据量、不同评估指标等多个维度。规划器把这些维度展开后很容易得到几十甚至上百个组合。第二是参数变体。同一个实验换一个随机种子、换一个学习率、换一段 Prompt就被记录成一个新实验。参数变体是必要的但也是最容易膨胀的地方。如果每个参数组合都要跑全量数据实验数量很快会过千。第三是数据切片。把数据按数量、比例、类别切分后每一种切法都对应一个实验。数据量和批次不同实验之间的结果不一定可比所以系统可能需要额外跑一组基准确认稳定性。第四是失败重试和回归验证。代码报错会导致重跑结果不合理会导致再次验证。这些动作在日志里会成为多条实验记录但本质上可能只是在重复同一件事。更关键的一点是实验数量与 token 消耗并不是线性关系。同一个实验跑三次因为每次上下文里都带上了前一次的计划、代码、报错信息和修复方案单次消耗往往会递增而不是保持同一个数。所以不要看到实验数量没有涨多少就觉得 token 消耗也应该稳定。2. 779M tokens 到底烧在哪成本分布比总数更重要很多人看到 779M tokens 会下意识问一句怎么这么高但只看总数没有意义更值得关心的是这些 token 到底被谁吃掉了。同样一组实验如果消耗集中在检索环节和消耗集中在评估环节优化方式完全不同。从我这轮复盘的观察来看Autoresearch 的成本大头通常不是最终生成报告那一段而是中间环节的反复读取和重试。你在最终报告里看到的可能只有几千字但为了得到这几千字系统可能已经把几十份资料、几十段代码、几十个报错日志都读了一遍。2.1 四个主要消耗环节规划、检索、代码执行、评估汇总下面这张表是我在 GPUMode 第三轮里用来对账的框架按环节拆分后很多问题会清楚很多。环节典型消耗低效点规划每轮几百到几千 token多轮修正后可能上万研究目标不清晰时会反复改计划检索每个资料几十万字符多个资料累积后非常可观重复抓取、全文塞入上下文不做截断代码执行生成代码、执行报错、修复、重跑单次可能几万到十几万 token一行报错触发整段代码重新读取评估汇总读取所有实验结果再写总结消耗随实验数量上涨把全部日志塞进最终总结没有分层抽样这里最容易被忽略的是代码执行环节。很多人以为 AI 编程只是让模型写一段代码输出量不大。但自动研究里的代码执行不是一次写完就结束而是写完要跑跑完要看结果结果不对要改改完要重跑。每一次循环输入里都会带上之前的代码和错误信息输出量看起来不大输入量却会越来越高。检索环节也容易失控。检索器找到一个网页或一份文档后如果直接把全文塞给模型一个资料可能就消耗上万 token。如果检索器没有按章节截断没有只取关键段落那么检索几个资料后后续任务还没开始上下文就已经很臃肿了。2.2 输入 token、输出 token 与 tpm怎样判断烧钱速度token 的计量方式需要先搞清楚。大多数平台会把输入 token 和输出 token 分开看最终账单是两者之和。tpm 也就是 tokens per minute按分钟统计输入 token 加输出 token 的总和。tpm 不只决定费用速度还会影响接口限流。如果一分钟内请求太密集模型服务端可能直接拒绝新请求任务就会开始重试重试又会继续消耗 token。有一个常见误区是只看生成结果长度。有朋友看到 58k tokens 不觉得多其实 58k 已经相当于中英文混合的几万字文本具体字数取决于 tokenizer。但在多智能体流程里一次工具调用返回十几页资料加上历史上下文58k 可能只够两三轮动作还没正式开始跑实验就已经用完了。GPUMode 第三轮里我特意盯过 tpm 曲线。峰值不是出现在生成报告时而是出现在多智能体并行检索结束、执行代码开始前。因为这个时候每个实验的上下文里都塞进了规划结果和检索资料输入 token 被撑到很大。如果此时并发还高tpm 很容易突破限流阈值任务开始排队或重试。所以要判断一个任务烧不烧钱不能只看最终报告字数也不能只看实验数量。要看单次请求的输入 token 是否持续上涨以及每分钟请求总量是否稳定。2.3 送的 token 额度为什么扛不住自动研究很多平台注册后会送一些体验 token我自己也领过几次。做普通对话或者写一段测试代码送的额度确实够用。但放到 Autoresearch 这种任务里情况就不一样了。自动研究的消耗模型是“多智能体多次往返”。一个完整流程可能包括几十次模型调用而不是一次。送的 token 也许能支撑一两个实验但很难支撑完一轮完整的多智能体闭环。不是说免费额度没用而是应该先用它做小样本验证把单次实验的 token 成本测出来再决定要不要继续投入。更需要注意的是一些平台送的 token 可能有有效期、速率限制或模型限制。直接拿大任务去跑很可能跑到一半被限流触发重试后 token 消耗反而更大。我的建议是免费额度只用来做链路验证不做全量实验。3. GPUMode 第三轮复跑我的批次流程和参数控制第三轮我不再像前面那样直接把任务扔进去就跑而是把流程拆成了四个阶段目标压缩、单任务验证、小批次试跑、全量批次。这样做的原因很简单自动研究最大的风险不是跑不出来而是跑到一半才发现成本失控或输出完全不可用。很多项目第一次跑都能跑通一两个实验于是觉得全量也没问题。这是最容易踩坑的地方。单任务能跑通只说明链路完整不代表大批量稳定。批量任务会遇到更多并发、限流、日志累积和输出冲突问题。3.1 先把研究目标压缩成可验收的假设列表这一轮跑之前我做的第一件事是把研究目标改写成假设列表。不要只写“对比模型效果”而是写“模型 A 在数据量 500 条时准确率是否高于模型 B”“加入某种提示词后能否减少无效输出”。每个假设对应一组实验实验数量可预期token 预算也好算。别小看这一步。没有可验收的假设规划器会把同一个问题反复拆成不同写法等于用更多 token 制造重复工作。我见过一个没有压缩目标的任务规划器连续生成几版计划实验数量没有增加但规划环节已经消耗了大量 token。假设列表还有一个作用它让后续的实验命名和结果判断更清晰。比如假设编号 H1实验可以叫 H1_data500_seed1。输出结果一出来直接对应到假设上的哪一个维度。不这样做最后面对上千个实验结果时根本分不清哪个实验回答的是哪个问题。3.2 三步走单任务验证、小批次试跑、全量批次我不会直接把 1293 个实验全部丢进队列。流程分三步。第一步单任务验证。选一个最简单、最接近现有经验的假设跑通输入、输出、日志整条链路。这一步要确认的是任务能不能启动、输出目录能不能写、日志能不能正常记录、最后结果文件长什么样。第二步小批次试跑。选 10 到 30 个实验观察单任务平均 token、失败率、运行时间、资源占用。这一步最关键。如果平均每个实验消耗 30 万 token那么一千个实验就是几亿 token。小批次数据会让你提前发现预算问题。第三步全量批次。根据小批次数据估算总成本再决定全量跑还是继续缩减。如果估算结果超出预期不要硬跑。先把假设列表压窄把数据量调小把重试次数降下来然后再试。这里有个判断标准可以记住小批次试跑阶段如果失败率高于 30%或者单任务平均 token 消耗比预估值高出一倍以上就不要开全量。全量只会把小问题放大不会自动修正。3.3 控制 token 的五个关键参数GPUMode 第三轮里我主要控制五个参数上下文窗口上限、输出 token 上限、并发数、重试次数、中间结果保存策略。下面是一个示例配置具体数值要按你的实际任务调整。{ research_goal: 比较两个模型在小样本分类任务上的差异, context_window_limit: 64000, max_output_tokens: 2048, max_parallel_experiments: 1, max_retries: 2, save_intermediate_results: true, log_level: INFO }参数作用建议context_window_limit防止上下文无限膨胀先按 32000 到 64000 试观察输出完整性max_output_tokens限制单次回答长度写代码任务可稍大总结任务可以小一点max_parallel_experiments控制同时运行的实验数新手先设 1稳定后再到 2 或 3max_retries失败重试上限2 次比较合理次数越多 token 消耗越高save_intermediate_results中间结果落盘开启后即使上下文被截断也能恢复为什么先小并发因为很多耗时不是模型算不动而是并发任务同时读取上下文显存、内存占用和接口限流会叠加。开 8 个并发不一定比 2 个并发快 4 倍反而容易触发超时重试。每次重试都在重复消耗 token最终成本可能翻倍。我见过有人把 max_parallel_experiments 拉到很高GPU 利用率确实上去了但输出文件开始乱写日志顺序错乱失败任务反复重启。最后查下来真正能用的实验结果反而不如低并发时多。3.4 中途检查日志和资源占用批量任务跑起来之后不要放着不管。至少每隔一段时间看一眼日志和输出目录。tail -f logs/autoresearch_round3.log检查内容主要有四个当前在跑哪个实验是否和预期顺序一致。上一次工具调用返回是否为空有没有连续重试。输出目录里有没有新增结果文件文件命名是否冲突。日志里 token 消耗是否出现异常上涨。资源占用方面主要看显存和内存。GPUMode 下如果 GPU 利用率长期很低多半是卡在检索或等待接口响应不是模型推理慢。如果内存持续上涨可能是某个评估器把大量日志一次性读进了内存。判断标准可以这样设连续 20 分钟没有新的实验输出或者重试次数超过设定值就应该停掉检查。不要等到所有任务跑完再看结果那时发现问题前面烧掉的 token 已经收不回来了。4. 1293 个实验的结果怎么判断有效实验、重复实验和无效消耗实验跑完只是第一步真正难的是从一千多个实验里筛出有效结论。如果只看“有没有输出文件”很多失败实验和重复实验会被误当成有效结果。第三轮复盘时我给自己定了三个筛选指标。如果你也是第一次跑大批量实验建议先不要追求自动化手动抽 50 个实验看看输出质量。知道什么样算好什么样算坏再交给程序去批量筛。4.1 判断实验有效性的三个指标指标定义怎么看完成率实验是否成功结束并产出结果低于 70% 说明流程不稳定或输入有问题成功率结果是否符合假设、代码是否正常运行不等于完成率完成但结果为空也算失败结果变化率改变参数后输出是否出现实质变化多个实验结果都差不多说明实验设计或评估标准有问题完成率解决的是“能不能跑完”的问题。如果大量实验没有输出文件或者日志停留在中间步骤说明链路还不稳定。这时不要急着分析结果先去修流程。成功率解决的是“结果能不能用”的问题。一个实验可能成功结束但输出是一个空列表或者代码执行报错但没有触发重试。这类实验看起来完成了实际没有意义。结果变化率是我最看重的指标。自动研究如果跑了一大堆实验结果都差不多说明当前实验设计缺少区分度。要么是参数范围没有拉开要么是评估指标不敏感要么是任务本身不适合这个模型。结果变化率太低时继续增加实验数量没有意义。4.2 重复实验从哪来怎么识别重复实验是 token 消耗的隐形杀手。常见来源有三种。第一种输入近似。两个实验只是随机种子不同或者数据切片方式稍微不同结果很可能没有实质差异。这种实验不是完全没用但不需要跑几十次。第二种失败重试。每次重试都会重新提交一次完整上下文失败日志本身可以说明问题但如果系统把每次重试都记成一个独立实验统计时就要把它们合到一起看。否则实验数量看着很多有效信息很少。第三种全量回归。每改一个参数都把之前所有结果重新评估一遍。评估器的消耗经常超过实验本身。特别是当评估器把全部日志读进上下文时一次回归可能比真正跑实验还贵。识别重复实验最简单的方法是看输入列表。如果同一模型、同一数据集、同一提示词只是某个数值不同那么它们大概率是同一族实验。统计时可以按“实验族”聚合而不是按单个实验计数。聚合之后再看哪些族贡献了主要结果哪些族基本可以忽略。4.3 探索型任务和稳定型任务要分开验收自动研究里有两类实验验收标准完全不同。探索型任务比如看不同提示词对输出风格有什么影响、不同数据规模对模型能力有没有非线性变化。这种任务适合多跑结论是“发现了什么差异”。它的价值在于覆盖足够多的组合结果变化率越高越说明有发现。稳定型任务比如看模型在固定测试集上的准确率、固定输入下是否复现同样的代码输出。这种任务重复次数越多越好结论是“结果是否可靠”。它更看重稳定性而不是多样性。把两类实验混在一起统计会带来两个问题一是探索型实验里大量的不稳定输出会被当成错误二是稳定型实验里正常的小波动会被夸大。第三轮跑完以后我把两种任务分开标记再做综合报告才终于能比较清楚地看到每个假设的结论。4.4 低配置环境的取舍如果 GPU 显存或内存不足不建议直接跑全量批次。低配置能跑通一个实验不代表能稳定跑完一千个实验。我在本地和 GPUMode 上都跑过感受很直接资源不足时最先出问题的不是模型推理而是并发任务的内存占用和日志读写。低配置环境可以这样降成本用小规模数据代替全量数据先看趋势再决定是否加量。降低 max_output_tokens让单次请求输出更短。关掉非必要评估器只保留一个核心结果判定模块。把中间结果及时写盘不长期保留在内存里。不要指望低配置跑大批量还能和完整环境一样稳定。先跑小批次用数据说话。5. token 超支、任务卡住、输出不稳定我的排查链路自动研究跑久了一定会遇到 token 超支、任务卡住、输出不稳定这三类问题。很多人的第一反应是调并发、调重试、调模型参数但我更建议先定位再优化。大多数问题的根源不在参数而在输入准备和任务设计。下面这条排查链路是我的固定顺序。不管问题表现是什么都按这个顺序过一遍通常能找到原因。5.1 先看 token 账单再改业务参数遇到 token 超支先拉账单别急着把并发调低。账单会告诉你大头在规划、检索、代码执行还是评估汇总。如果大头在检索查是不是重复抓取如果大头在评估查是不是把所有日志都塞进了最终总结如果大头在重试查是不是接口限流或超时导致同一批任务反复执行。改参数之前先定位很关键。有人发现 token 消耗高直接把 max_tokens 调低。结果输出被截断代码执行失败重试次数增加总消耗反而更高。这就是典型的没看账单就改参数。要看几个维度输入 token 和输出 token 的占比。单任务平均消耗有没有随时间上升。失败重试带来的额外消耗占比。并发高峰期的 tpm 是否接近限流阈值。这些数据不一定都在账单里有些需要从日志重新算。如果日志里没有记录单次请求 token 数建议从下一轮开始补上。没有这个数据后面很难做成本优化。5.2 排查顺序输入、上下文、并发、重试、输出目录我自己固定用六步排查顺序如下看现象是直接报错、卡住不动、没有输出还是输出结果为空。看输入文件路径、编码、格式、数据切片是否完整有没有路径权限问题。看上下文日志里请求 token 是否持续上涨有没有因为超长而被截断。看并发同时跑的任务数量、接口限流、GPU 和内存占用是否异常。看重试同一实验是否被反复提交失败原因是不是网络或接口返回错误。看输出目录结果文件是否生成命名是否冲突目录是否可写。这个顺序能覆盖大多数问题。很多人一上来就改 max_tokens 或者换模型问题可能仍然存在是因为根因没有被处理。比如输入文件编码错误导致代码报错代码报错导致重试重试导致 token 暴涨。这时改模型没用直接把文件编码转换掉就够了。5.3 三个典型坑第三个批次里我踩过几个很典型的坑列出来给你参考。第一个坑是网络超时导致的重复提交。任务系统没有做幂等控制同一个实验因为一次接口超时被重新提交。第一次其实可能已经成功了但客户端没收到响应于是又跑了一遍。最终账单里出现了大量重复实验实验数量虚高token 消耗翻倍。第二个坑是评估器吃满上下文。评估器负责读取实验日志并生成结论。如果某个实验日志特别长评估器一次性把所有内容读进上下文单次请求直接超过上下文上限。系统以为请求失败触发重试重试时又继续读那段日志。结果评估环节的 token 消耗甚至比实验本身还高。第三个坑是日志缺失。没有记录每次输入摘要、输出文件路径和重试次数失败时只能靠猜。等你发现某个实验有问题日志里只写了“报错”没有具体原因那这次实验的 token 就白白烧掉了。第三轮里我把日志改成结构化格式每一条都带上任务 ID、环节、输入 Token、输出 Token、重试次数问题定位速度快了很多。6. 下一轮再跑 Autoresearch我会先做这三件事1293 个实验跑完以后我对 Autoresearch 的判断没有变它能解决部分探索性问题但必须把成本控制和结果筛选当作一等公民对待。如果再来一轮我大概率会先做三件事而不是直接把目标交给系统。6.1 缩小目标减少自由探索下一轮我不会再让规划器自由发挥而是先把研究目标人工切成 3 到 5 个可验证假设每个假设只允许 1 到 2 种数据规模和参数变体。自动研究应该做的是把假设跑出结果而不是自己发明假设。发明假设越多token 越不可控结果也越难收束。判断标准是如果每个假设需要超过 50 个实验才能回答说明这个假设仍然太大。先把它拆到可以用 10 到 20 个实验回答再考虑是否合并。6.2 中间结果落盘别让长上下文替你做记忆多智能体最费 token 的地方是为了让后续步骤记住前面步骤不断把历史塞进上下文。改成中间结果落盘后每个环节只读取自己需要的文件不再携带全部历史。这个改动比任何模型调参都省 token。具体做法是规划器输出的计划保存成计划文件检索器保存资料摘要执行器保存代码和结果评估器只读取结果文件。这样即使某一个环节发生上下文截断后续也能从文件里恢复不需要重新生成全部上下文。如果你现在正在跑自动研究第一步就把“保存中间结果”打开。这个开关通常不会影响输出质量但对 token 消耗影响很大。6.3 把人工检查点放到批次中间我会在每 100 到 200 个实验后插入一个人工检查点检查完成率、成功率、结果变化率和 token 消耗。如果某一项明显异常先处理再继续。检查点会打断自动化但能避免后面几十万 token 被无效浪费。检查点是一种必要损耗。不设检查点可能等全部跑完才发现某个阶段出了问题然后整个批次推倒重来。设了检查点最多损失 100 个实验的 token远比全部重跑便宜。GPUMode 第三轮跑完我最大的感受是自动研究不缺实验数量缺的是从实验数量里筛出有效结论的判断力。779M tokens 不是用来证明“跑了很多实验”的而是用来回答少数几个值得回答的问题。只要目标足够聚焦哪怕实验数量少一半最终结论质量反而可能更高。