我在纸上写过一道题：给一个月费三十块的写作助手，估算一千个日活的推理成本，再说说这个价格能不能撑住。
多数人第一反应是问模型单价，然后乘 token 数。算术没错，但这么做的人一般算不到点子上，因为他漏掉了调用结构里那些固定开销，也漏掉了用量分布的长尾。
我更想看的是：他会不会先把一次请求拆开。
一次请求里，用户输入往往不是大头
把一次调用摊开，大概是这么几块：系统提示、几个示例、用户输入、检索回来的材料、输出。
用户输入通常是最小的一块。系统提示和示例才是隐形大头，因为它们每一次调用都要付，而且写的时候没人会计较长度。我见过一个客服场景的系统提示写到三千多字，里面塞了话术、禁答范围、格式要求、六条示例——单次看不贵，乘以每天的调用量，它比用户输入贵出好几倍。
更麻烦的是它会随着需求长大。每次有人提「加一条规则」，就往里追加一段，三个月后你面对一份没人敢删的提示词。这时候成本问题和技术债问题是同一个问题。
所以我的第一版估算从不写单价，只写结构：一次请求带多少固定 token、多少可变 token、输出多长、一天多少次。单价单独列一行，标注日期。价格一年变好几次，结构不会。这样供应商降价或者换模型，只需要改一行，不用重做整张表。
这张表还有个用处：反推预算。给定毛利目标和订阅价，单次请求的 token 上限是可以算出来的。这个数字会反过来约束产品设计——提示词能写多长、检索塞几条、要不要做多轮。先有约束再设计，比设计完了发现不赚钱要好。
隐藏的倍数比单价更致命
真正让成本失控的，往往不是单次价格，是调用次数。
第一层是重试。格式解析失败要重试，超时要重试，被安全策略拦了要改写再试。工程上通常会写「最多重试三次」，这句话在成本表里就是三倍。
第二层是多轮。用户一句「再短一点」，背后可能是完整的一次调用，带着全部历史。聊到第十轮，输入 token 是第一次的好几倍，而用户感觉只是说了句话。
第三层是工具调用。一次任务里模型要判断调哪个工具，拿到结果再判断，来回几趟，每一趟都是一次完整的上下文。Agent 类产品的成本结构和聊天产品完全不是一回事，拿聊天的单价去估 Agent，会差出数量级。
第四层是并行采样。为了让答案稳一点，生成三个候选再挑一个，成本直接乘三。这个设计在小流量场景很划算，在大流量场景就是自杀。
我的习惯是在成本表里单独列一行「每次任务的调用次数」，写下中位数和 p95。这两个数字的差距，基本决定了一个产品是「可预测的成本」还是「随时会炸的账单」。
每一个省钱动作，都在某个维度上做减法
省钱的招数不多，难的是知道代价。
前缀缓存是最干净的。系统提示固定、内容顺序稳定，命中率就高。代价是提示词结构要被约束：动态内容必须放后面，不能把时间戳插在开头。这条约束会一直影响后面所有改动，属于一次性付出的设计成本。
语义缓存便宜得诱人，风险也直接：相似的问题被判定为同一个问题，返回一个不完全适用的答案。事实型、答案稳定的查询适合，带用户上下文的请求不适合。判断标准不是相似度阈值调到多少，而是「答错了会不会被用户发现」，以及发现了会不会出事。
小模型分流是长期正确的事，但要接受它偶尔分错。用户不知道背后有两档模型，他只知道「今天这个产品有点笨」。所以分流策略必须有监控：某一类请求被误判的比例，要能单独看到。
减少检索条数、缩短输出长度、降低示例数量，这些都会在评测集上画出曲线。省钱的位置应该由曲线决定，不是由直觉决定。我见过把检索从五条砍到两条、召回率掉了一截、但没人发现的方案，因为没人跑评测。
流式输出是个例外：它不省钱，省的是感知。首字快了，用户愿意等完整答案，成本一分没少。把这两件事混为一谈，很容易做出「优化了成本」的幻觉。
订阅制在高频用户身上会倒挂
固定月费加无限用量，等于把用量的方差全部留给自己。
推理成本是幂律分布的：少数重度用户消耗掉大部分额度，多数人用得很少。平均值看着健康，一算分位就难看。月费三十块，若有人每天跑几十次长文档改写，他一个人的成本能吃掉几十个轻度用户的毛利。
可选的手段就那么几种：给配额、软限速、按用量加购、把重任务挪到异步和低谷时段。每一种都会改变用户行为。配额定得太紧，用户不敢用，产品价值直接下降；定得太松，等于没有。这条线要靠真实用量分布去调，不是拍脑袋定一个「每天五十次」。
我更倾向的做法是把「贵」和「便宜」的路径分开：默认走便宜路径，需要更高质量时明确告诉用户「这次会用更强的模型」，让他自己选。这样成本波动有了解释，用户也不会觉得被偷偷降级。
还有一层是定价单位。按席位卖，重度用户越多亏得越多；按用量卖，轻度用户会觉得自己在为别人的消耗买单。这不是纯数学问题，是把成本波动塞给谁的问题，我在另一篇里单独写过。
成本会改写产品设计
这是我最想在面试里听到的一句话。
贵的时候，产品会做成一次生成、少量候选、人工兜底；便宜之后，同一个需求可以被重新设计：后台预生成、一次给三个方向、失败自动换一种思路重试。很多今天看起来不合理的交互，是被当时的单价逼出来的。单价降下来而设计没变，就是浪费。
反过来也成立。曾经因为便宜而做出的铺张设计——每次都塞满上下文、每个请求都跑最强模型——会在流量涨起来的那天变成负债。这时候再改，改的是已经形成习惯的交互。
我会怎么追问
第一个问题：你这个数字里，哪个假设最不确定。
一般答案是人次和输出长度。能说清楚「人数涨一倍我能扛，输出长度涨一倍我扛不住」的人，比报一个精确数字的人可靠得多。
第二个问题：如果实际用量是估算的三倍，你怎么办。
先看是哪种用户涨了，再决定是限流、改价还是改架构。直接说「加机器」的答案通常没算过账，因为瓶颈可能在供应商的速率限制，不在自己的服务器。
第三个问题：如果明天模型价格降九成，你的产品会怎么变。
这题没有对错，但有没有想过，一听就知道。
会算账的人不一定能做产品，但不会算账的人做 AI 产品，最后是账单替你做决定。
我自己也不是每次都算得准。估算的意义不是命中，而是让你知道自己押在哪个假设上，以及这个假设错了的时候，还有多少余地。
评论