我是小兵，一个动手派AI架构师。「AI工程化实战」系列第 9 篇。
月初对账单：模型没涨价，账单却翻了一倍
月初我对账单，厂商后台那个总额吓我一跳。查下来模型没调价、业务量也没暴涨，可账单比上月翻了快一倍。问题不是模型贵，是没人算过账。
第 8 篇《OTel + LangFuse 全链路 Trace》把 token 计数打进了 span——只记账，没算账。我把那堆计数拉出来，乘上价目表一摊：钱大头不在“干活”的输出，在每次重发的 system 前缀、在 RAG 拖回的那堆文档、在 fallback 到大模型的几条链，还有重试把调用翻倍。
结论先放这儿：省钱第一步不是省，是建账本；账本摊开，最烧钱那条链自己就浮出来，再谈怎么压。
三种省钱姿势，我全踩空
先说我见过的三种省钱姿势，全踩空。
第一种，只盯模型单价。谁便宜换谁，结果质量崩了，第 7 篇《JSON Schema 强约束》的重试把省下的钱成倍烧回去——省单价的钱，从重试里还。
第二种，只砍 prompt 字数。system 从 800 压到 300，输入省了，效果丢了，检索文档还是整段往里塞。砍错了地方，等于没省。
第三种，最要命——没有账本先谈优化。“哪条链贵”全靠猜：是重发的前缀贵，还是检索文档贵，还是输出贵？猜不准，优化就是玄学，六七个技巧轮着试，账单纹丝不动。
成本其实就由三个因数撑着：一天的成本 ≈ 调用次数 × 单次调用烧的 token 数 × 单价。任何单个技巧只摁住一个因数，另外两个在漏。而三个因数全在黑盒里，根子只有一个：没人把第 8 篇记下的 token 计数算成账。
账本怎么建：计数 × 价目表，成本现算
账本怎么接上第 8 篇埋的钩子？一句话：计数 × 价目表 = 每笔调用的成本。两个设计决策要钉死。
第一，成本不进 span、不靠厂商给。第 8 篇核实过，OTel 的 GenAI 语义约定里没有标准 cost 属性，成本想进 span 得自己定业务属性。所以成本是账本层现算的业务属性。好处是价目表可以换——今天用 A 厂，明天切 B 厂，span 上一行不改，账本层换张价目表就行。
第二，账本按三个维度聚合，得能回答三句话：按模型看，哪个模型在烧；按链路看，哪条链最贵；按因数看，单价、数量、次数各贡献多少。第三句最容易被忽略，却是六维优化的地图——因数账一摊，就知道该上减量还是降价还是减次。
最烧钱那条链，是怎么摊出来的
拿我线上最肉疼的“订单抽取”举例。它每次请求长这样：一大段逐字不变的 system 指令重发一遍、RAG 拖回一堆文档、模型输出一段长 json、主路超时后 fallback 到大模型、失败再重试几次。
按 mock 价目表拆一次调用，一眼看出三件事：
一是输入占大头，输出只占一小块。输入里最肥的是 RAG 拖回来的那堆检索文档，其次是每次逐字重发的 system 前缀——全是“每次都在重复付钱”的输入。
二是重试在成倍放大。一次失败就 fallback 到单价最贵的大模型，再重试几次，单次请求的钱成倍滚上去。
账本没摊开之前，这钱我根本不知道花哪了。拆解里带的具体 token 和价目是 mock 的，但“输入是大头、重复发送的前缀和文档最肥、重试成倍放大”这个结构，真实账单上只会更明显。
六维动作表：每两维打同一个因数
账本建完，怎么压？按三个因数分三组：减量掐数量、降价掐单价、减次掐次数，每两个维度打同一个因数。这张表可以直接抄走。
组 A 减量——单次调用少烧：
① 上下文裁剪 / RAG 检索精简：top-k 从 8 收到 3，加相关度阈值过滤，每篇只送命中段落。输入能降 70%~80%，裁对常常还更准——多余上下文本来就是噪音。
② 输出长度控制：输出单价通常是输入的 2~8 倍、典型 3~5 倍，话痨尾巴是单价最贵的一块。按任务用途设 max_tokens 上界，结构化任务按 schema 算输出上界。输出能降 30%~60%，代价是截断，见取舍点③。
组 B 降价——同一需求烧更便宜：
③ 提示词缓存命中：恒定前缀（system、工具 schema、检索指令）放最前、逐字节稳定，动态内容全放后缀，把命中率当指标盯。命中的输入各厂普遍折 50%~90%，90% off 那档折合 1 折。
④ 模型分级路由：任务分 easy、medium、hard 三级，小模型先试，边界外级联升级大模型兜底。大小模型单价差一到两个数量级，60%~80% 流量路由到小模型，综合能降 50%~80%。
组 C 减次——一天少调几次：
⑤ 重试与采样预算：max_retries 设上限，加指数退避、幂等去重，Agent 自省轮数也设上限。把“无限重试”的 4~5 倍调用压回有界，成本近乎等比例降。
⑥ 批处理与离线错峰：报表、批量抽取、离线摘要这些非实时任务，迁异步队列 + batch API + 低峰跑。batch 档约半价，挪走 30%~50% 非实时流量，综合降 15%~25%，还削峰降 P99。
（上表里缓存折扣区间、batch 半价、大小模型价差是市场已核实口径；输入降 70%~80%、综合降 50%~80%、4~5 倍这些是方向量级或 demo 的 mock 值，不是对真实账单的承诺。）
为什么按“减量 → 降价 → 减次”的顺序动刀
不是六个技巧随机挑，动刀顺序本身有讲究。
先减量。单次请求里可控性最高、风险最低——裁掉的是检索噪音和话痨尾巴，常常裁完效果还更好。
再降价。缓存和路由动的是“给哪个模型、按什么价计费”，省得多但碰质量红线，必须配质量闸。
后减次。重试预算动的是“一天调几次”，跟可用性强相关——砍重试不能裸奔，得让第 3 篇《灰度发布 + 自动熔断》的退避接住抖动，否则为了省钱砍重试，会把瞬时抖动放大成真实失败率。
给你一条可执行的时间线：第一周先上③缓存 + ①裁剪，低风险高确定性，账本上立刻见数；第二周再上④路由，因为它要先在评测集上画出“小模型能扛的边界”；⑤重试预算和⑥批处理随手就做。
三个取舍点，每个都有代价
每动一刀都回答同一个问题：省了多少？质量掉没掉？前者用账本数字说话，后者用第 2 篇《Golden Set 评测》的评测集说话。省 token 不是越多越好，省到“再压就伤质量”的边界就该停。三个取舍点：
① 缓存省的是 input 大头，但“可缓存的恒定前缀”会跟语义一致性打架。别为了追命中率把租户名、会话变量、实时数据硬塞进前缀——那会同时打碎缓存和语义正确性；更危险的是把第 6 篇《OWASP LLM 安全护栏》挡掉的 PII 塞进可共享的缓存前缀，等于从缓存侧绕开脱敏闸。我的判断：只有版本化、已脱敏、与单次请求无关的内容，有资格进前缀。
② 小模型路由能省一大截单价，但质量劣化会从重试和返工里加倍烧回去。路由不是按“看起来简不简单”拍脑袋，是在评测集上画出“小模型能扛的边界”，劣化率设 budget，超了自动收窄。账本上要单列一行“小模型劣化成本”，否则省没省是笔糊涂账。我的守门就一条：hard 级任务永远不许路由给小模型。
③ 压 max_tokens 省钱立竿见影，但截断坏结果比多吐几颗 token 贵得多。max_tokens 不是省钱旋钮，是“下游消费的边界”——压到 schema 下界之下，长 json 被截断，解析失败重试，截断省的钱从重试里加倍烧回去，还搭上下游报错。我的判断：省输出 token，要用“下游真的只消费到这儿”来定义边界，绝不全局一刀切。
回到账单那页
回到开头那个对账单的早晨：同样的 trace，这次把 token 计数摊成了账，最烧钱那条链自己浮出来——钱大头在重复发送的前缀和 RAG 拖回的文档，不是输出。这套动作我落成了可离线跑的迷你成本引擎（账本 + 六维省钱纯函数 + mock 日流量，纯标准库、无 API 密钥）：同一份 mock 日流量，按“缓存 + 裁剪 + 路由 + 重试预算”四刀压完，省了 81.8%——mock 价目表 + mock 流量上的确定性结论，不是对真实账单的承诺。真实省多少取决于你的链路；“先摊账本 → 找出最烧钱链 → 六维压 → 每刀测试钉死”这套动作和价目表无关，可以原样搬走。
但省钱有个看不见的天花板：再压就伤质量，而“伤没伤”不能只靠评测集拍板——线上真实用户觉得行不行，得有人把话递回来。下一篇《Human-in-the-Loop 反馈闭环》：把点赞点踩接进 golden set，让质量底线跟着真实反馈走。
这篇是脱水版。完整版约 7600 字，含可离线跑的 mini_cost.py + test_mini_cost.py 全量代码（6 个断言）、六维动作大表、三个取舍点在代码里的守门落点、三个付费踩坑、选型对比和附录价目核对，已同步发布在 CSDN。点文末「阅读原文」看完整代码和可跑 Demo。
评论区聊聊：你们月结对账时，最肉疼的是哪条链？是 RAG 拖回来的一堆文档，还是每次重发的 system 前缀，还是无限重试？有没有哪次发现，省下的钱从重试里加倍烧回去了？
我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。