上个月验收一个知识库问答 Demo我拉了下账单前后累计 92 次请求总共烧掉 1340 万 token。这个数字什么概念差不多相当于把一部一百万字的长篇小说从头到尾读了十遍。当时我下意识骂了一句“模型太贵”可第二天把请求日志一条条翻完才反应过来自己骂错了对象——真正费钱的不是 AI而是我的验收流程。更夸张的是92 次请求里只有 1 次真正触发了有效缺陷剩下 91 次全都属于低效甚至无意义的调用。这不是模型不行也不是 API 价格离谱是流程里默认了太多“反正多跑一次也无所谓”的动作。今天我把这笔账拆开来讲结合整改过程聊聊后续我是怎么把这类浪费压下去的。1. 账单出来那晚我发现问题不在模型在流程先交代一下背景。手上这个知识库问答 Demo目标是让用户用自然语言提问系统从内部文档里检索相关内容再生成一段带引用的回答。开发阶段大家都很兴奋功能跑通后进入验收测试同学提了一堆场景产品也时不时来问“这个你有没有测过”“换个说法是不是也行”。于是整个验收期间我们反复做着同一件事改一点提示词重跑一遍用例换一个问法再跑一遍发现某类历史记录没保留又从头跑了一遍。直到有天夜里我写了个统计脚本把请求日志里的 token 用量汇总才发现92 次请求1340 万 token。平均每次请求烧掉约 14.6 万 token这个数字大得离谱。因为普通一轮单轮问答输入加输出能控制在几千 token 就算不错14.6 万说明每次调用都在搬运一个非常臃肿的上下文。我第一反应是“商用模型太贵了”但顺着日志往下看就发现单次请求的模型响应时间并不夸张大部分在 3 到 8 秒之间。真正拖垮整个验收周期的是那 90 多次重复、等待、人工翻看输出、再修改提示词的过程。这件事给我的核心教训是在 AI 应用里谈成本不能只看模型单价要看你的调用习惯和验收设计。模型是按 token 计费的token 是按你输入多少、输出多少来算的。你把同样的背景资料翻来覆去塞进每次请求等于每次都在替过去买单。从工程角度说更值得反思的是“请求 — 人看结果 — 改提示词 — 再请求”这个循环。模型本身很快但人工判断一次输出是否合格可能要两分钟。92 次请求听起来不多但每一次都伴随一次完整的人肉 review整个验收战线就这样被拉到了近三天。2. 91251415128854一笔一笔拆开低效请求的构成为什么说 92 次里只有 1 次有效因为那次请求真的暴露了一个缺陷某个特定问法下检索模块会漏掉关键文档导致回答引用了错误章节。剩下的 91 次要么是重复验证要么是流程不合理造成的连环重试。为了说清楚问题我把它们按“最根本的浪费原因”归成了八类刚好对应题目里那串加法25、14、15、12、8、8、5、4。2.1 25 次提示词微调后的全量重跑这是最大的一笔浪费。验收期间只要有人觉得回答风格不对、语气太生硬、引用不够规范我就会改提示词然后顺手把整套测试用例从头跑一遍。一次改动跑二十个用例二十次模糊调整就是几百次调用。问题在于大部分提示词改动只影响表述风格或者局部行为根本不涉及检索逻辑或知识理解。你改了一句“请用简洁语言回答”理论上只需要跑 3 到 5 个代表性用例看风格是否符合预期就行了。全量回归应该留给真正动了核心逻辑的改动而不是每一次语法微调都动用整个测试矩阵。2.2 14 次换着花样问同一个问题验收中经常有这种情况产品同学说“用不同说法问同一个问题看看结果是不是稳定”。于是同一个知识点被翻来覆去测试了十几次比如“退款周期是多久”“钱什么时候退回来”“退款要等几天”。这类测试不是没有价值但价值密度很低。相似意图的用例留 2 到 3 个典型说法即可剩下重复验证完全可以交给自动化语义相似度来判断而不是人工一条条触发完整链路。14 次里至少有一半是重复劳动它们真实消耗的 token 一点不比新场景少。2.3 15 次上下文携带了全部历史记录我们的 Demo 支持多轮对话测试时也模拟连续提问。但这套轮次设计写得太简陋它把用户会话里的每一条历史消息都原封不动地塞进下一次请求。到第 8 轮、第 10 轮时历史消息加系统提示词叠加起来单次请求输入已经超过 8 万 token。这 15 次请求主要集中在多轮场景后半段。每一次都是把前面所有轮次的原文完整重发一遍而模型真正需要用到的核心信息——比如用户刚才确认过“企业客户优先”——可能只占其中几个片段。多余的历史消息全部变成了投入火炉的燃料。2.4 12 次无差别回归测试回归测试本身没错错的是无差别。我们当时把冒烟用例、功能用例、边界用例全放在一个执行脚本里只要跑就是全量 30 个用例。有一次只是调整了输出解析规则想让结果更干净结果把知识库检索、引用格式、多轮交互的用例全部重新跑了一遍。正确做法应当是建立用例分级。改动检索逻辑就只跑检索相关用例改动输出样式就只跑格式相关用例只有发布前才跑完整回归。这 12 次无差别回归里一大半调用跟实际改动点毫无关系属于流程偷懒。2.5 8 次历史裁剪太晚多轮对话还有一个常见坑不是不裁剪而是裁得太晚。我们的实现里只有会话超过 20 轮才触发摘要压缩可实际测试最多也就聊到十几轮等于裁剪策略在验收阶段根本没生效。于是每轮请求都在重复携带大量旧消息直到日志里 input_tokens 一路飙到十几万。正确的裁剪策略应该更早介入超过 4 到 6 轮就把更早的对话压缩成一段摘要超过 10 轮连摘要都要限制长度。剪晚了模型看到的是大量冗余历史消耗的是你的预算。2.6 8 次输出解析失败后的盲目重试这类浪费有点憋屈。我们要求模型输出 JSON但提示词里只写了“请输出 JSON”没有做结构化的格式强约束。结果某些带代码块标记、某些带额外说明文字解析脚本一跑就报错。报错后的第一反应是“重试一次”于是同样的请求、同样的上下文又发了一遍。8 次重试里有 5 次是纯浪费——只要在后端做一次去标记处理或者一开始就启用强制结构化输出结果根本不会失败。盲目重试是最容易忽视的 token 黑洞因为你只会看到调用次数变多不会注意到输入输出其实一模一样。2.7 5 次并发测试互相踩脚验收后期有人开了三个窗口同时测同一个会话 ID结果 A 窗口带上了 B 窗口刚插入的历史记录导致上下文错乱回答牛头不对马嘴。排查半天没查出模型问题最后发现是共享会话状态被覆盖了。这 5 次请求全是被迫重试的。测试环境和生产环境必须隔离每个测试终端要用独立会话 ID不然你的验收数据会被自己人污染。这类问题表面上和 AI 无关但它确确实实烧了 token。2.8 4 次空跑验证最后这 4 次最冤。为了确认服务还活着测试同学发了几次“你好”“在吗”“测试一下”这样的空消息。说它空是因为这些请求没有任何真实业务意图却完整走了一遍检索和生成链路照样带上下文、照样计费。服务存活验证本来就不应该走模型链路一个健康检查接口就够了。这种请求虽然没有几万 token但四舍五入下来也是白烧的钱更关键的是它会污染统计报表让你做成本分析时看不清真实业务开销。3. 体感慢的真凶预填充暗耗与“请求—人看—改—再请求”的循环聊完账目再说说为什么当时所有人都觉得“AI 很慢”。如果你把请求日志按耗时排序会发现一个有趣现象输入 token 越大响应越慢。这不是玄学而是 LLM 推理机制决定的。模型处理一次请求时会先把所有输入 token 整体过一遍生成一份内部状态在技术上通常叫预填充阶段。预填充的计算量几乎和输入长度成正比。输入 8 万 token 的请求预填充时间可能比输入 8000 token 的请求高出好几倍。之后才开始逐个生成输出 token这部分反而只和输出长度有关。用生活里的场景类比就像排队进景区队伍长度决定了你从队尾走到闸机要多久。哪怕闸机本身检票很快只要前面排了几万人你的体感就是“这个景区好慢”。我们每次请求都背着几万字历史记录相当于每次都在给队伍续命。我之后专门做过对照同一个问题携带 8 万字上下文时首字返回大约需要 8 到 12 秒把上下文精简到 6000 token 后首字延迟降到 1.5 到 2 秒。模型没换提示词几乎一样唯一的变量就是输入体积。所以很多团队抱怨“模型越用越慢”很多时候不是模型退化了而是你的上下文被自己塞满了。除了技术层面的预填充还有一层更隐蔽的慢人工反馈闭环。单次请求模型耗时顶多几秒钟但人看一眼输出是否合格可能要一两分钟。整个验收流程里我们人工翻看了 90 多次输出还有人来回讨论提示词怎么改、改了之后会不会影响其他用例。这些时间加在一起才是项目真正变慢的根源。模型只是在你每一次犹豫和返工时安静地把计费表又转了一圈。这也是为什么解决问题不能只靠换更快的模型。你换一个声称快三倍的接口但只要上下文还是八万 token、提示词还是频繁全量回归总耗费依然降不下来。先把输入做小把请求次数做少比选型更优先。4. 重新设计验收流程四个改动把 token 消耗打下来账单拆完之后我做的第一件事不是换模型而是重构验收流程。整套改动分四块每块都对应前面某几类浪费执行后再跑同样一轮验收总 token 从 1340 万降到了不到 200 万耗时也从三天压缩到半天。4.1 建立提示词版本库用增量 diff 替代全量重跑提示词本质上也是代码最怕的是没有版本概念。我们的处理是把所有提示词模板纳入版本管理每次改动都单独提交提交说明里写明动机比如“调整回答风格为简洁”或“强制引用必须带文档编号”。同时给测试用例打上标签按影响面分三类冒烟级、功能级、发布级。提示词只动了风格描述就跑冒烟级用例改了检索指令才需要跑功能级里的检索子集只有发布验收才执行完整回归。这样一个改动配套的用例数从 30 个直降到 5 到 8 个25 次全量重跑基本不会再出现。4.2 静态知识移出上下文命中片段动态注入之前每次请求都把所有文档背景塞进系统提示词这是 15 万 token 平均值的最大来源。我后来把知识库做了分段切块并接上向量检索。请求进来时只把命中的 2 到 3 个相关片段拼接进上下文同时标注这些片段来自哪个文档段落。单次请求从输入 8 万 token 降到 6000 到 10000 token效果立竿见影。需要注意的是这种做法要配合引用校验——模型必须基于片段回答如果回答内容与命中片段无关宁可拒绝也不要编造。否则为了省 token 牺牲准确率得不偿失。4.3 黄金用例集分层替换无差别回归我给项目重新定义了一套金字塔式用例集冒烟层5 个覆盖主链路提示词小改必跑功能层15 个覆盖知识检索、引用格式、多轮关键路径模块级改动时跑发布层30 个完整的边界与对抗用例只在上线前或整体架构调整时跑。这样处理之后日常改动不再触发全量回归数据上可以从每次跑 30 个用例降到每次最多 15 个。更重要的是每个用例都配有期望结果和失败标准不再是“跑一遍看它输出什么”而是“跑一遍断言它是否合格”。4.4 多轮历史动态裁剪结构化输出强约束针对历史记录膨胀我做了两档位裁剪对话轮次少于 4 轮时保留全部原始消息超过 4 轮后把更早的部分压缩成一段不超过 1000 token 的摘要超过 10 轮则进一步限制摘要长度。这样即使用户连续问 20 个问题单次输入也不会无限制上涨。输出格式方面不再只靠提示词约定而是启用接口侧的结构化输出能力强制返回带 schema 的 JSON。如果解析仍然失败后端先尝试剥掉代码块标记再解析还不成功才允许重新请求并且记录失败原因。这轮改完解析重试的 8 次浪费基本绝迹。5. 让消耗可见请求日志、token 预算与团队约定流程改了之后我发现光靠自觉不行还得让每笔消耗都看得见。现在这套项目里我固定了三个机制你也可以直接拿去用。第一个是给每次调用生成请求 ID日志里必须记录这些字段请求来源、场景标签、提示词版本号、上下文长度、输入 token 数、输出 token 数、耗时、结果状态。日志统一写到结构化文件里方便后续统计不是打印到控制台看看就完了。举个例子一条日志大致长这样{ request_id: demo-r7-0342, session_id: test-session-01, scene: multi_turn, prompt_hash: v25, context_len: 874, input_tokens: 6542, output_tokens: 1200, duration_ms: 2800, status: pass }第二个是设置场景级 token 预算。每类验收场景定义好预算上限比如“多轮测试单日不超过 50 万 token”“提示词试错单用例不超过 3 万 token”。超出自动触发告警阻止继续无节制调用。这不是为了卡死测试而是逼着团队在超额前先想清楚这次的调用是否必要。第三个是团队约定。我们定了两条硬规则修改提示词后不能立刻全量回归至少要先跑冒烟层任何一次人工查看的输出如果发现不符合预期第一步是记录原因而不是直接重试。这两条规则看起来很基础但对减少隐性 token 消耗非常有效。实际执行中还有一个容易踩的坑告警阈值设得太低天天被噪音骚扰大家很快就麻木了。建议阈值先放宽只统计明显异常的场景比如单次请求输入超过 5 万 token、一天内同一提示词版本同用例重复超过 3 次等数据稳定后再逐步收紧。好用的统计脚本也可以放一份在仓库里每天自动汇总各场景的 token 消耗变化。这样每月复盘时直接看趋势图就知道哪个环节又变成了漏水的桶不用再到日志里手工翻。6. 这次验收之后我给自己留的一份最短自查表现在每星期我都会不定期翻一眼请求日志不是为了心疼那笔钱而是为了确认旧问题没有复发的苗头。复盘到最后真正有用的其实是几个简单问题每次启动新的验收之前我都会过一遍这次请求的输入上下文为什么这么长哪些部分可以裁掉我是不是准备全量回归改动点真的影响所有用例吗刚才那次输出失败重试前有没有先修解析逻辑这条测试用例有没有自动化的判断标准还是说必须人肉看一遍我改了一句提示词到底需要用多少个用例来验证这几个问题看着不起眼但每一个背后都对应一笔真实开销。经历过这次 1340 万的教训我的体会是在 AI 应用里最大的成本往往不是模型定价而是那些默认“多跑一次也无所谓”的习惯。把这些习惯一个个揪出来预算自然就降下来了。