很多 AI 项目不是死于效果，是死于账单。演示阶段没人算成本——一天几百次调用，几美元的事。上线后流量涨三个数量级，财务拿着账单来问的时候，才有人回头算这笔账。架构师的基本功，是在写第一行代码之前就把这笔账算出来。
账单的结构：输入便宜是假象
模型 API 按 token 计费，输入和输出的单价不同，输出通常贵好几倍。原因是生成是自回归的——每产出一个 token 都要把整个模型跑一遍，而读输入可以并行。这个定价结构直接塑造架构：
- 让模型少说话。「只输出结论，不要解释」这种约束，省钱效果立竿见影。一个爱写三段解释的回答，成本可能是「输出一个 JSON」的十倍。
- 输入端的大头是重复。每次请求都带着同样的系统提示、同样的检索资料，这些重复输入是缓存的主战场。
把账算细的公式很简单：单次成本 = （输入 token 数 × 输入价 + 输出 token 数 × 输出价）。但真正的功夫在于搞清楚「我的平均一次请求到底是多少 token」——去日志里量，别拍脑袋。量的结果经常让人吓一跳：那个你以为「很轻」的功能，因为塞了整份检索资料，单次成本是预期的八倍。
缓存：同一笔钱不付第二次
主流提供商都支持前缀缓存：如果本次请求的开头部分和上一次完全相同，这部分输入按折扣价计费（甚至接近免费）。工程含义：把不变的内容放在提示词最前面，把变动的（用户问题、当次检索结果）放在最后。顺序反了，缓存全部失效——这是「排列顺序值多少钱」的直接体现。
再往上是应用层缓存：同一个用户问题（或其嵌入相近的问题）之前答过且答案仍有效，直接返回旧答案，根本不调用模型。 FAQ 类场景里，这一层常常能挡掉三到五成的调用。
模型路由：贵的脑子只用在难的题上
旗舰模型和轻量模型的单价能差一两个数量级，但绝大多数请求根本不需要旗舰。模型路由用一个便宜的前置判断（可以是小模型，也可以是规则）把请求分流：简单的走小模型，只有复杂的上大模型。这和一个团队的分工一模一样——你不会让资深专家去回复「你们几点上班」。
路由的底气来自第六章的评估：你得先知道「小模型在这类请求上的通过率是 97%」，才敢把流量切过去。没有评估的路由是赌博，有评估的路由是算术。
延迟：用户感受到的那一面
成本账的另一面是时间账。生成的延迟大致正比于输出 token 数——又是「让模型少说话」。两个工程手段值得知道：流式输出（边生成边推给前端，用户感知延迟从「全部生成完」变成「第一个字出现」）和批处理接口（非实时任务如夜间跑报告，用离线批量 API，价格通常打对折）。实时交互用流式换取体验，离线任务用批处理换取折扣，各取所需。
当省钱省到尽头
把这一章的手段全用上——缓存、路由、少说话、批处理——成本能砍掉大半。但有些场景会发现：剩下的成本来自「每次都要用大模型处理本可以固化下来的模式」。当同一个模式被调用几百万次，一个新的选项开始进入视野：把大模型的本事蒸馏进一个自己训的小模型，推理成本降一个数量级。这是第九章到第十二章的主题。但在掏钱训练之前，先得回答一个更根本的问题：你怎么知道提示词这条路真的走到头了？