把推理成本写进价格：额度、超额与升级触发

价格不是成本的加法，而是把「用多少」翻译成「付多少」的一份可预测合约。

一、一晚烧掉整月预算的那个用户

周野一个人做会议纪要工具，套餐每月 29 美元，卖点是「AI 纪要无限量」。某天早上他打开账单，发现一个六人销售团队在前一晚批量上传了三小时录音，触发四百多次调用，单夜推理成本 61 美元，超过该客户整月付费的两倍。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他第一反应是加限流，把每分钟请求数压下去。但日志给出的分布更刺眼：中位用户每月只调用 22 次，八成成本来自三个账号。也就是说，他一直在用中位用户的价格，补贴尾部用户的行为，而「无限量」这三个字把这种补贴写成了承诺。

第二个月他改成「包含 60 次、超出后每次 0.40 美元、硬上限 200 次」，同时给仪表盘和 80% 提醒。退款没有增加，反而有七个用户升到了更高档，因为他们终于知道自己用了多少。限流解决的是系统别被打垮，额度解决的才是这个用户这个月该付多少。 两件事混在一起，就会既得罪重度用户，又守不住毛利。

这一篇只谈第二件事：怎么把推理成本翻译成用户能预测、你能守住的价格结构。对外 API 的令牌桶、突发额度与 429 语义不在本文范围内，那是另一层保护，不该拿来当计费方案。

二、先选一个用户能预测的计量

计量的第一标准不是「和成本最贴近」，而是「用户能不能在点击之前估出这次要花多少」。估不出来的计量，最后都会变成账单惊吓。

先上「包含额度 + 超额」，不要直接上纯按量。 纯按量把预算风险全部转给用户，早期需要大量教育，转化会被「不知道要花多少」拖住。包含额度让用户先有一个固定心理账户，超额只处理尾部，既保留可预测性，又给你一条成本上限。

同一功能只设一个主计量。 同时按次数和 token 收费，用户无法心算，客服也无法解释。选一个和成本最相关的单位作为主计量，其他因素折进单价里。会议纪要按「小时音频」比按「千 token」更好懂，因为用户知道自己开了多久的会。

计量单位要能被日志直接聚合。 如果你按「份」卖，但日志里只有 token 和调用次数，每次对账都要人工换算，月底一定对不上。先确认这个单位在埋点里存在，再拿去定价。

免费额度是试用，不是慈善。 它要够用户完整跑通一次真实任务，否则他体验不到价值；但也不该够他跑完一整周的工作。教学刻度可以设成「一次典型任务 + 两次重试」，用完必须看到升级入口。

档位之间要让「刚好够用」可计算。 用户应该能根据自己的历史用量，在三档里选出一档，而不是靠猜。每档的包含额度最好落在该档目标用户 p50 到 p75 之间，让多数人不超额，尾部自然向上迁移。

不要用「无限」做卖点。 无限量在营销上省事，在成本上是一场没有上限的看跌期权：你收固定费用，却把尾部的全部风险留给自己。真想表达慷慨，用「足够 95% 用户使用」加一个明确的硬上限，比「无限」更可信，也更可守。

计量的颗粒度要能对应用户的工作单位。 用户知道一场会议多长、一份合同几页、一个工单几条消息，但不知道一次请求消耗多少 token。把计量挂在工作单位上，提醒才有意义；挂在技术单位上，用户只会觉得你在收一笔看不懂的钱。

三、四件事：免费额度、包含额度、超额单价、硬上限

一个能落地的额度结构只有四个变量。把它们写进价格页，比写十句「按实际使用计费」有用。

包含额度按 p50 用户设，不要按均值。 均值会被少数重度用户拉高，导致多数人付了用不完的额度，而尾部仍然亏。按 p50 设，再让超额单价承担尾部成本，定价会更接近真实分布。

超额单价由毛利反推，不是成本加一点。 先定目标毛利率，再用单位推理成本除以一减毛利率，得到单价下限。低于这个数，越多人超额你亏得越快；高于它太多，用户会转向竞品或干脆不用。

硬上限保护双方。 没有硬上限，一个脚本循环或一次误操作就能造出三位数账单，最后多半是你退款。硬上限要写在价格页，并且在达到前就能看到剩余次数。

100% 时升级或暂停，留 10% 宽限。 达到包含额度时，不要立刻掐断正在生成的内容；允许 10% 的宽限把当前任务做完，再进入超额或暂停。这个细节能消掉大部分「刚好写到一半」的投诉。

超额单价可以随档位递减，但别太陡。 团队档便宜一点是合理的批量折扣，但如果递减太多，用户会为了单价升级到用不完的档位，反而增加流失。价差应该对应真实的服务成本差异，而不是惩罚低档。

四件事要同时上线。 只写包含额度不写超额单价，用户不知道超了会怎样；只写超额单价不写硬上限，账单没有天花板；有硬上限却没有 80% 提醒，用户只会觉得被突然掐断。四个变量是一套合约，拆开任何一件都会制造新的支持工单。

额度不是惩罚工具。 它的作用是让成本可预测，不是让用户少用。如果数据显示用户因为怕超额而不敢用核心功能，说明额度设得太紧，或者提醒话术太像警告。宁可把包含额度调高一点，也不要把一个有价值的功能变成用户需要提防的东西。

四、防账单惊吓与升级触发

账单惊吓的根源不是价格高，而是「我不知道会到这个数」。三个动作能消掉大部分：提前提醒、硬上限、老用户保护。

仪表盘要按功能拆，不要只给一个总数。 用户想知道的是「哪个功能在吃额度」，而不是「我用了 137 次」。按功能展示次数与预估费用，他才能自己做取舍。

80% 的邮件要带一个具体动作。 只写「您已使用 80%」没有用，要写「按当前速度将在 6 天后用完，升级到团队档可覆盖到月底，或购买 50 次加油包」。提醒的价值在于让用户在还有选择时做决定。

老用户要 grandfather。 改价或缩减额度时，给现有付费用户至少三个月原条件，涨价提前 30 天通知。这不是道德选择，而是算过账的：一次集中退款和口碑损失的修复成本，通常高于这几个月的差额。

每档都要算最坏情况成本。 假设这一档所有用户都用满硬上限，乘上超额单价与单位成本，看这一档会不会整体亏损。如果会，说明硬上限设得太松，或者档位价格需要上调，而不是指望用户「不会都用满」。

升级触发点写在 80%，不是 100%。 等用户撞到上限才提示升级，他感受到的是被阻断；在 80% 提示，他感受到的是提前规划。两者转化率差别很大，而成本几乎一样。

账单页要显示「本月预计」，不是「本月已用」。 已发生金额只能让人后悔，预计金额才能让人行动。按当前速度外推月底费用，再给出「按此速度将在 6 天后触及上限」的判断，用户才有机会在还能选的时候选。

支持团队要有一张额度解释卡。 卡上写清四件事：当前额度、超额单价、硬上限、如何购买加油包。用户来问时不解释模型、不解释 token，只回答「你现在用了多少、接下来怎么算」。把技术细节留在内部，把选择留给用户。

五、行动清单与复算验收

先把最近 30 天的日志按套餐分桶，算出每桶的 p50 与 p95 用量、每用户月成本、超额人数占比。没有这三个数，任何额度都是拍脑袋。

用一档做小范围验证。 选一个套餐改成「包含额度 + 超额 + 硬上限」，观察四周：升级率、退款率、支持工单里关于「额度」的比例。三项都可接受，再推到其它档。

每季度重算一次，不要一次定终身。 单位推理成本、用户用量分布和套餐结构都会变。把重算写进日历，用同一张表更新四个变量；如果某个季度成本降了两成，可以选择降低超额单价或提高包含额度，把省下的钱换留存，而不是默默变成自己的利润。

• 从日志导出最近 30 天每用户调用次数与 token，按套餐分桶。
• 算出每用户月成本的中位数与 p95，标出成本最高的三个账号。
• 选定一个主计量单位，确认它能在日志里直接聚合。
• 按 p50 用量设定每档包含额度，并写下对应的硬上限。
• 用单位推理成本除以一减目标毛利率，算出超额单价下限。
• 配置 80% 提醒、100% 切换、10% 宽限与硬上限四个节点。
• 给现有付费用户写 grandfather 期限与提前 30 天的涨价通知。
• 每档按「全部用满硬上限」复算一次最坏情况毛利。

验收标准：任取一个付费用户，你能用他的真实用量算出本月费用、毛利和下一次升级提示出现的时间，且三个数字与账单一致。

超额单价下限 = 单位推理成本 ÷ (1 − 目标毛利率)
示例：0.24 ÷ (1 − 0.70) = 0.80 美元/次 → 定价 0.80 才守住 70% 毛利
每用户毛利 = ARPU − 每用户推理成本 = 29 − 7.4 = 21.6 美元
保本用户数 = 固定成本 ÷ (ARPU − 成本) = 1800 ÷ 21.6 ≈ 84 人
升级触发点 = 套餐额度 × 80% = 60 × 0.8 = 48 次
结论：84 个付费用户覆盖固定成本；第 48 次起提示升级，200 次硬上限封顶

使用边界与实操验收

本文假设你已经有一个能跑通的 AI 功能，并且能从日志里拿到每用户用量与成本。若还没有这三样，先回到第 02 篇把三层账单建起来；在没有成本数据时定额度，只是把亏损换一种形式藏起来。

• 配额与限流：免费层、突发额度与超额计费 ：它讲对外 API 的每分钟请求、突发桶与 429 语义，本文讲产品内 AI 功能的月度额度与商业定价，两者不是同一层。
• SaaS 行业观察：基于使用量的定价模式探索 ：它讲按量计费的模式与行业案例，本文只取「包含额度 + 超额」这一种适合一人产品的过渡形态。
• 三档套餐：把「刚好够用」写成一张表 ：它讲三档套餐的功能切分，本文补上每档的推理额度、超额单价与硬上限。

实操验收建议做一次「反向账单」：挑三个真实用户，用他们的用量按新结构重算，再和旧账单对比。如果三个里有任何一个的费用跳涨超过 30% 却没有对应的价值增加，就先调额度而不是直接上线。

这套结构不适用于两种情况。 一是企业合同已经把用量写死，额度只能作为内部告警；二是功能本身是免费的获客入口，此时该用的是总预算上限与滥用防线，而不是向用户收费。

关键参考与核验范围

核对日期：2026-10-25。下列来源仅支持明确标注的机制或原则。

• Claude：Prompt caching : 用于提醒计费应区分缓存写入、读取与其他输入，不能只用总 token 数猜成本。

使用边界。 额度、0.24 美元成本、0.80 美元价格与毛利目标都是教学假设，不引用供应商现价，也不构成实际盈利承诺。定价公式需使用已覆盖全部相关变动费用的单位成本。

如何自行复核。 检查免费、套餐内与超额的计量一致性；单价下限算完后再核对支付费、退款、支持及固定费用，不把仅扣模型费用的剩余比例称为完整毛利。

系列导航

• 上一篇：供应商故障时的降级：超时、限流与三层预案
• 下一篇：AI 功能验收：质量、成本、延迟与信任四张表
• 回到目录：一个人给产品加 AI：判据、成本、护栏与验收
• 相关阅读：推理账单：每用户每月、每次调用与毛利下限 、LLM 成本治理与 Token 优化