群聊整理成论坛帖子，大模型成本估算被推翻了几次

我在做一个依托 QQ 群的论坛，叫鼠洞。群里每天有上千条消息，其中不少是有价值的问答，可惜聊过就沉了。所以我想让机器人把值得留下的问答和讨论自动整理成论坛帖子，我把这个功能叫“收录”。

做法并不复杂。每隔一段时间，把新增的群消息交给大模型，让它判断哪些值得收、分成几个帖子、谁回复了谁，再写成主楼和回复发到论坛。真正让我没底的是账单。我用的是一个共享的大模型接口，按积分计费，每周有固定额度，输出（包括思考过程）的单价是输入的 4 倍，白天 8 点到 18 点还要翻倍。一天到底会花掉多少，没人说得清。

先小范围回放几轮

收录功能还没有在真实群聊上跑过，我先让 AI 助手（我平时用 Claude Code 开发这个项目）写了一个回放工具。它读取群聊的导出文件，按照和线上完全相同的规则切成一轮一轮，调用大模型，但不往论坛发帖。

助手第一次启动，就打算把一整天的消息全部回放一遍。我看到以后马上叫停，这样跑下来花多少钱完全没数，应该先小范围试。回放工具随后加了两处小改动，一是可以指定只跑几轮，二是每跑完一轮就往文件里追加一行结果，中途停掉也不会白跑。

当时的设计是每 10 分钟或每 30 条消息切一轮，先让本机的一个小模型筛掉闲聊，剩下的才交给大模型，估计一天 60 轮左右。

用夜里的 5 轮消息试了一下，整理出 2 个帖子、8 层楼，质量没有硬伤，只有一处多了原话里没有的“也”字，一处回复挂错了位置，一处漏收。花了约 5.6 积分（按白天的翻倍价），平均每次调用要 45 秒。

比质量更让我在意的是另一个数字，其中有一轮什么都没收，模型照样输出了大约 900 个 token。

一天不是 60 轮

我接着用真实聊天一天的记录重新切了一遍，结果是 94 轮，而不是估计的 60 轮，平均每轮只有 18 条有效消息。

一轮的上限	每天轮数	每轮平均消息数
30 条或 10 分钟（当时的规则）	94	18
50 条或 15 分钟	62	28
80 条或 30 分钟	36	47

按试跑测到的单次花费粗算，哪怕每一轮都调用大模型，一天大约 100 积分，一周约 700，占每周额度的 3.5%，看上去并不吓人。但那 900 个 token 提醒我，花钱的单位可能不是消息，而是调用。

通俗比喻：每次到场都要先翻一遍资料的顾问

可以把大模型想成按次请来的顾问。不管这次要看的合同是一页还是十页，他每次开工前都要先把相关的规定重新翻一遍、想一遍，这段时间同样要计费。

所以请他来十次、每次看一页，和请他来一次看十页，后者通常更便宜。群里一轮只有几条闲聊，他照样要把“收录标准、已有版块和标签、正在跟进的帖子”重新读一遍。

初筛并没有那么有用

既然每次调用都有固定开销，减少调用次数就成了首选。我先看了本机小模型的初筛。拿白天的一段消息对照，有内容的 4 轮里，按设计的门槛会漏掉 3 轮，真正的闲聊反而被放了过去。样本很小，下不了定论，但它起码没有证明自己有用。

另一条路是把一轮放大。同一段白天消息，用 50 条一轮对比 30 条一轮，每天的调用次数从约 94 次降到约 62 次，估计每天从约 100 积分降到约 60 积分，省了四成，在这段样本里整理质量没有变差。

关掉思考，反而出了硬伤

输出里大部分是思考，那把思考关掉不就省钱了吗？我用同一段 4 小时、387 条消息，分别开着低档思考和关掉思考各跑了一遍。

关掉思考之后速度明显快了，也不再超时，花费还差不多，13.7 积分对 12.3 积分（低档思考还有 3 次超时的调用，费用不明，没有算进去）。但仔细看结果，出了几类按验收标准必须为零的硬伤。

• 有一层楼里写进了别人提的问题，而这段话根本不在这个人的消息里。
• 有两轮里的 8 个帖子，被代码检查判定为“一层里混进了好几个人的话”，全部丢掉，这两轮什么也没收到。
• 有人只是在抱怨自己的成绩，被写成了一个“保研难吗”的提问；一句闲话被当成了讨论帖。

同一批内容，低档思考整理出的是一个 7 层楼的问答帖，谁回复谁、每层是谁说的都对得上。关掉思考的另一个副作用是收得过多，要跟进的帖子变多，输入涨到每轮 5 到 6 千 token，总花费最后和低档差不多。所以思考保持开着。

估算被推翻了

上午我估过一次，开着低档思考时每条消息大约 0.04 积分。但傍晚重跑的时候，只跑了 4 轮就花掉了 20.4 积分，照这个速度把两种切法跑完要 150 积分左右，是原先估计的 5 倍。

原因出在上午的样本。最贵的几轮都因为超时失败了，根本没有算进平均值。按重新测到的数字，有内容的时段每条消息要 0.1 积分左右，一天将近 1900 条，估计要 150 到 200 积分，占每周额度的 5% 到 7%。

失败的调用也会花钱

超时断开之后，服务端有可能还在继续生成，生成的部分照样计费。统计成本时，只看成功的调用会把平均值压得很低。

超时设在了错误的地方

这次重跑还暴露出另一个问题。这个接口生成得很慢，实测每秒只有 14 到 39 个 token。我把输出上限设成 16384 个 token，按每秒 20 个算，写满需要 820 秒，按最慢的每秒 14 个算要 1170 秒。

我用的是普通的非流式请求，模型全部写完才一次性返回，所以超时只能设得比最长的生成时间还要长。设短了，就会出现“我这边断开了，对方照常生成、照常扣钱”的情况。先从 180 秒调到 300 秒，又调到 900 秒，都像在打补丁。

通俗比喻：等整件快递和看物流更新

非流式像等一整件快递，你只知道它什么时候到，中间没有任何消息，超时只能按“最慢的一件可能多久”来设。

流式像看物流更新，只要一直有新的节点出现，就说明包裹还在路上。超时只需要管“多久没有新消息”，两分钟没动静再去查就够了。

最后改成了流式输出（请求里打开 stream），超时只管“多久没有收到新数据”，设成 120 秒。正常生成多久都不会被打断，服务端真卡住了，两分钟内就能发现。

让它少想的几种办法

改成流式之后重跑，我把回放缓存里的思考文本翻出来读了一遍。一次 50 条消息的调用，输出了 12763 个 token，其中约九成是思考，花了 6 分钟。模型在思考里把消息逐条复述了一遍，先打了一遍正文草稿，又对着规则反复推敲。

既然看到了，就顺着试了几种办法。

办法	结果
在提示词里要求“思考简短，别复述，别打草稿”	没有效果，输出反而更长
拆成两步，先分段（开思考），再写正文（关思考）	分段这一步照样想了一万多 token
分段这一步也关掉思考	便宜，但结构很乱，把闲聊也收了进来
换成更强的模型并关掉思考	很快，但几乎每一层都混进好几个人的话
把收录范围限定在升学和学业相关的话题	有效

唯一见效的是最后一条。同一批闲聊为主的消息，输出从 6199 和 12763 个 token，降到了 133 和 1186。模型扫一眼发现不在范围内，很快就判完了。真正在讨论升学的轮次仍然想得很久，比如 29 条消息想了 9199 个 token，但这部分是内容本身需要的，花得值得。

换一家服务再试一遍

后来要把之前积累的群聊历史导入论坛，我改用了另一家按额度计费的服务，趁机把“便宜模型初筛，贵模型整理”的两级方案认真测了一遍。这次用的是同样的三个时段、532 条消息，下表是每千条消息的花费。

做法	每千条消息	备注
单级，直接用较强的模型整理	8.8 元	作为基准
思考档位调到低	9.4 元	质量差不多，但不省钱
便宜模型先挑消息，再交给较强的模型	9.4 元	收得略少，不省钱
较强的模型只分帖分层，正文交给便宜模型	思考量反而多 7%	没有收益
较强的模型关闭思考	参数被忽略	照样长篇思考
全部交给便宜模型	2.3 元	质量不合格，不能用

初筛本身相当准，挑出约六成的消息，漏掉的有用内容约 4%，每千条才 0.2 元。可它没能省钱，因为较强的模型的思考量并不随消息条数减少。同一段对话从 46 条筛到 17 条，思考的 token 反而从 1.08 万涨到了 1.87 万。看起来它的思考主要花在怎么分帖、怎么分层、字段怎么填这些“要收的内容”上，而不是逐条否掉闲聊。

同样的输入，两次的思考量能差一倍，有一次想到了 3 万多 token 的上限被截断。档位、提示词、关闭开关，没有一个能稳定地控制它。

至于缓存，我用第一个接口最近 120 次调用的用量算过。输出占总花费的约 85%，输入只占 15%。输入里最大的一块是每次相同的系统提示词，约占六成，已经有一半左右命中了缓存。缓存只保留三到六分钟，而每轮之间的间隔往往更长。就算命中率提到极限，也只能省 2% 到 3%。

这和我之前写过的 Batch API 那次正好相反。那次的输入是固定的大头，缓存是关键；这次大头在输出，缓存几乎帮不上忙。

最后留下的做法

这一连串实验并没有找到“让模型少想”的办法，最后留下来的都是在“少调用、少浪费”上做文章。

• 把一轮放大，减少调用次数，同时避免把一场讨论从中间切开。
• 收录范围只限于升学和学业相关的话题，闲聊几句话就判完。
• 日常收录继续用较便宜的模型，思考保持低档。换成更强的模型，试了一段，整理得确实更忠实，但价格是三倍，一天要占掉周额度的近三成，没有采用。
• 历史导入避开涨价的白天时段。

按这套做法，两个群都开、白天按翻倍价算，估计一天 250 到 300 积分，约占每周额度的 10%。

适用边界

这些结论来自两个模型、两段聊天样本，且都是“长上下文、结构化输出、要求严格归属”的整理任务。我只能说明在这类任务里，思考量由内容决定，靠提示词和档位压不下去；换成别的模型或任务，结论不一定成立。