免费额度 26 分钟被烧穿：一次「日志骗人」的成本排查
自建的记忆服务跑得好好的：LLM 抽事实用小米 mimo，向量与重排用阿里云百炼。某天傍晚用户一句「免费额度用完了」，我直觉是提问太多——直到把账单和日志摆在一起，才发现两者差了一个数量级。文中时间均为北京时间。 一、对不上的两个数字 直接打重排 API 复现，返回的是： {"code":"Arrearage","message":"Access denied, please make sure your account is in good standing."} HTTP=400 注意错误码是 Arrearage（账号欠费），不是「免费额度用尽」，而且嵌入 API 报同样的错——整个账号级被拒，不是单个模型的问题。 阿里云百炼控制台显示：嵌入模型 593 次调用、重排模型 100 多次调用（两个模型的免费额度各 100 万 token）。而服务端日志里我只能数到 19 次重排调用，候选合计 1092 个。 ⚠️ 这里踩了本次排查最大的一个坑：看到「593 次」就默认它是重排的调用数，于是按「593 次重排」一路归因，中途甚至把刷新次数算成了 79 次。直到有人指出「590 是嵌入的、重排只有 100 多次」，才回头把整条链重算——结论方向没错，但中间的数字错得离谱。教训见第八节第 8 条。 这 19 次倒是每一次都能对应到一条真实的用户提问： 18:14:48 <某组件的查询参数该用什么>... → 171 个候选 18:14:55 <某项配置改在哪>... → 157 个候选 18:15:11 <某个路径约定的坑>... → 172 个候选 18:22:43 <某条阶梯计价规则>... → 102 个候选 ... 18:39:59 <一次流程变更>... → 95 个候选 Starting recall 后面紧跟 Reranking 的日志在 18:40 之后就再没出现——额度是在 18:14~18:40 这 26 分钟里烧穿的。可 19 次、1092 个候选，按每次 1.7K token 估也就几万，离 100 万差一个数量级。所以这只是冰山一角。 ...