推理账单：每用户每月、每次调用与毛利下限

推理成本不会因为你看不见而消失，它只会以月底账单的形式一次性回来。

一、每个人都说「才几毛钱」

周牧一个人做客服摘要工具，按月收 19 美元，帮小电商把散落在邮件和聊天里的咨询整理成待办。上线 AI 摘要的第三个月，他第一次认真看供应商账单：当月 380 美元，比前两个月加起来还多。

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

他的第一反应是「是不是涨价了」。登录后台逐条看，单价没变，调用量却从每月 1.2 万次涨到 3.1 万次。再往下拆，46 个付费用户里有 3 个贡献了 58% 的调用：其中一个把摘要按钮接进了自己的定时脚本，每五分钟跑一次；另一个在批量导入历史会话；第三个则是因为重试逻辑写错，失败后不停重发。

「每个用户才几毛钱」是一句平均值。 周牧之前算的是总成本除以总用户，得出每人每月 8 美元左右，觉得还能承受。但平均值掩盖了两件事：少数用户的实际成本是平均值的十倍，而他们的套餐价和别人一样。毛利不是被所有人一起稀释的，是被少数几个用法异常的人一次性吃掉的。

账单里还有看不见的科目。 他最初只统计了输入和输出 token。实际上，检索索引每月固定收费，嵌入在导入时批量产生，内容审核对每条输出都跑一次，失败重试把同一段输入又计了一遍。这些科目单独看都不大，合起来接近总账单的三成。不把它们放进同一张表，任何「成本可控」的结论都不可信。

成本问题的背面是定价问题。 如果三个高用量用户贡献了 58% 的成本，却只付了 6.5% 的收入，那么问题不在模型太贵，而在套餐没有把用量差异传导出去。先看清账单结构，再谈涨价或限流；顺序反了，就会把正常用户一起赶走。

他先改的是重试逻辑，不是价格。 那个每五分钟跑一次的脚本，其实每次都在超时后重发，真实调用是日志里的三倍。加上最小间隔和失败退避后，这个用户的成本降到原来的三分之一，体验没有变差。这提醒他：在看单价之前，先看请求是不是本来就不该发生。

二、三层账单：调用、用户、功能

同一笔推理支出，至少要在三个粒度上各算一次。只看总额会漏掉异常，只看单次会低估规模，只看用户会说不清该改哪个功能。

每次调用要先拆输入与输出。 输入 token 乘 p_in，输出 token 乘 p_out，两者单价通常不同，长上下文还会触发阶梯计价。把每次调用记成「总 token 乘一个平均单价」，在输入输出比例变化时就会失真。日志里至少保留两个字段，不要只存合计。

重试必须单独计。 失败重试对用户是透明的，对账单是实的。重试率从 3% 涨到 15%，成本就多出约 12%，而调用量看起来没变。把 retry_rate 写进每用户月成本公式，比事后猜「是不是供应商变慢了」有效。

区分结果缓存与供应商提示缓存。 本地结果缓存可避免再次调用模型；提示缓存通常仍对写入、读取和未缓存输入分别计费，并不等于输入免费。按供应商实际 usage 字段与账单记录缓存类别、计费 token 和费率，再计算命中率变化的成本影响，不能只用一个 cache_hit 布尔值推导节省比例。

检索、嵌入、审核要分摊。 这三项往往按文档数、字符数或请求数单独计费，混不进 token 单价。做法是先算出每月总额，再按各功能的调用占比或文档占比分摊。分摊口径不必完美，但必须固定，否则每月数字无法比较。

fallback 会把成本藏在第二张账单里。 主供应商超时后切到备用模型，备用模型的单价可能更高，且这次调用的主模型请求也可能已经计费。把 fallback 次数和 fallback 后的 token 都记下来，才能知道降级预案的真实代价。

三层账要能互相勾稽。 所有单次调用成本相加，应该等于每用户成本之和，也等于每功能成本之和，差额只允许来自分摊口径。对不上时不要急着调公式，先查是不是有请求没打上 user_id 或 feature_id。勾稽不上，说明日志本身就不可信。

三、连续 7 天：从日志取 p50、p90 与分桶

月度汇总用于对账，逐次日志用于定位异常，两者都要保留。先取连续七天覆盖工作日与周末；遇到月末批处理、节假日或大规模导入，还需延长窗口。七天数据不能自动代表整个月的用量。

先取 p50 和 p90，不要只看平均。 平均值会被少数超长请求拉高，也会被大量短请求压低。p50 告诉你典型请求多贵，p90 告诉你尾部有多长。如果 p90 是 p50 的八倍，说明有 10% 的请求在吃掉不成比例的成本，先查这些请求的输入长度和重试次数。

按套餐分桶，而不是按全体。 免费、基础、专业三档的用量结构完全不同。把三档混在一起算平均毛利，会出现「整体健康、基础档亏损」的假象。每档单独算每用户月成本、ARPU 和毛利，再决定是提价、限额还是把某档下线。

找出成本最高的 3 个用户。 不是找调用最多的，而是找「成本减收入」最大的。一个每天跑 200 次但付 19 美元的用户，比一个每天跑 20 次付 99 美元的用户更值得处理。看完用户再看他们的行为：是正常高频，还是脚本、批量导入、死循环重试。

再找出成本最高的 3 个功能。 功能维度常被忽略，但它直接指向产品决策。摘要、改写、检索问答、自动分类的平均 token 和失败率差别很大。把最贵的三个功能列出来，逐个问：能不能换弱模型、能不能缩短上下文、能不能加缓存、能不能限制频率。

七天数据要能重放。 记录取样起止时间、日志版本和口径说明。下个月用同一套字段再跑一次，才能比较趋势。口径中途变化，数字就没有意义；这比成本本身更常见。

p90 异常要回到具体请求。 看到 p90 是 p50 的八倍，不要停在「尾部很长」。抽十条尾部请求，逐条看输入长度、是否带历史记录、是否触发重试、是否走了备用模型。通常两三个具体原因就能解释大部分尾部成本，改起来也比调单价快。

四、毛利下限：20%、10% 与 80% 告警

成本治理不是把账单压到最低，而是让每一档套餐的毛利可预测。先定下限，再定告警，最后定对账节奏。

20% 是 AI 成本率上限，不是毛利率下限。 仅扣 AI 支出后，剩余比例至少为 80%；这不是完整毛利率，因为支付、履约基础设施及其他计入销售成本的科目尚未扣除。先写清收入是否已扣退款、哪些费用属于可变销售成本，再算完整毛利；若采用内部经济口径计入自有支持工时，也要单独标明。

10% 的总收入线用于防止单点依赖。 当 AI 只是产品的一部分时，它不应该吃掉总收入的十分之一以上。超过这条线，说明你在用主业务的利润补贴一个尚未证明能独立成立的模块，应该先停下来算清楚。

80% 告警要配 100% 硬停。 只有告警没有硬停，等于把决定留给月底的自己。硬停不是关掉产品，而是暂停非核心功能、拒绝超额请求、给用户明确提示。提前写好停哪些、留哪些，比临时拍脑袋更不容易伤到付费用户。

每周 30 分钟对账，只看三件事。 本周总成本与预算的差距、成本最高的三个用户、成本最高的三个功能。每项只回答「是否异常、下周做什么」。超过 30 分钟，说明你在做分析而不是对账，分析应该另找时间。

对账要落到具体的人。 一个人做产品，负责人就是你自己，但动作要写清楚：谁在什么时候改额度、谁通知用户、谁复核下周数据。没有名字和日期的对账，第二周就会变成「上次好像看过」。

先限额，再提价，最后才换模型。 限额能立刻止住异常用量，且不影响大多数用户；提价需要提前通知并承受流失；换模型可能降低质量，还要重跑评测。顺序按「可逆性」排，先做撤回成本最低的动作，把不可逆的决策留到数据更清楚之后。

五、行动清单与复算验收

先把日志补齐，再谈优化。字段不全时算出来的毛利只是安慰剂，越算越放心，账单来的时候越被动。

• 导出连续 7 天的调用日志，确认 request_id、user_id、plan 三个字段齐全。
• 补齐 input_tokens、output_tokens、retry_count、cache_hit 与 fallback_model。
• 把检索、嵌入、审核的独立账单按功能分摊进同一张表。
• 按套餐分桶，算出每档的 p50、p90 调用次数与 token 数。
• 列出成本最高的 3 个用户与 3 个功能，标注异常行为。
• 写下 AI 归因收入 20%、总收入 10% 两条 AI 成本率上限，以及 80% 预算告警的动作。
• 约定每周 30 分钟对账，固定只看总成本、前三用户、前三功能。
• 把复算结果同步到定价与额度草案，标出需要提价或限额的档位。

验收标准：每档套餐的用量、收入与完整成本科目能相互对账，AI 成本率、毛利率和覆盖固定费用的人数各用明确公式计算。 七天日志只用于初步外推，月度结算以完整账期核对；高成本用户触发内部复核阈值，不自动等同于应限流。

每用户月 AI 可变成本 = 首次调用次数 × (平均输入token × p_in + 平均输出token × p_out) × (1 + 额外重试次数/首次次数) + 可变检索/嵌入/审核费
示例：60 × (1800 × 0.000002 + 500 × 0.000006) × 1.08 + 0.35 = 0.78 美元
重试部分假设单次成本相同；若日志已逐次计费求和，不再乘重试因子
AI 成本率 = 0.78 ÷ 9 = 8.7%；仅扣 AI 后的收入剩余比例 = 91.3%
另设每用户其他可变销售成本 0.22 美元，完整可变销售成本约 1.00 美元
本例毛利率 = (9 − 1.00) ÷ 9 = 88.9%（假设无其他销售成本）
月固定费用 300 美元，未计入上述每用户可变费用
覆盖固定费用人数 = 向上取整(300 ÷ (9 − 1.00)) = 38 人
结论：本例 AI 成本率低于 20% 上限；最高成本用户 3.34 ÷ 9 = 37.1%，需查用法与账单

使用边界与实操验收

本文算的是「已经上线或准备上线的 AI 功能」的推理成本，不涉及模型训练、微调或自建推理集群。它假设你能拿到供应商的用量明细；如果只能看到月度总额，先用一至两周补齐日志，再谈毛利。

• LLM 成本治理与 Token 优化 ：它讲计费模型、缓存、路由与输入压缩的通用手段，本文讲一个人如何把这些科目落成三层账单与毛利下限。
• 推理成本核算与 FinOps ：它讲组织级的成本分摊与预算流程，本文把同一套口径收缩到单人产品的套餐与用户粒度。
• 定价是一本账：四个锚、一个区间与一条下限 ：它讲定价锚点与价格区间，本文只提供成本侧输入，不替代定价决策。

实操验收分两步。第一步，用上面的复算块填一次真实数字，检查结果是否与账单总额对得上，差额超过 10% 就说明有科目漏记；第二步，把最高成本用户和最高成本功能各处理一个，观察一周后成本曲线是否下降。两步都完成，再把阈值写进每周对账模板。

本文阈值是教学刻度。 20%、10%、80%、30% 都不是行业标准，而是为了让「什么时候该动作」可判断。你的支付费率、退款政策和服务器成本不同，毛利下限应当重算，但计算口径要保持稳定。

三种情形需要另一套模型。 一是按结果收费、单次成本波动极大的产品；二是需要长上下文或大量检索的重度场景；三是自托管模型，成本主要是 GPU 折旧与运维工时，不能直接套 token 单价。

关键参考与核验范围

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

• Claude：Prompt caching : 用于核对提示缓存写入、读取与未缓存输入的计量区别，不引用当前单价。

使用边界。 供应商提示缓存不等于免费输入；本文的单价、0.78 美元、0.22 美元、300 美元及阈值均为教学假设。不同供应商须分别取实际 usage 与账单。

如何自行复核。 按首次与重试逐次汇总实际费用，区分结果缓存和提示缓存，再加入其他可变成本；固定费用不要重复分摊进保本公式。

系列导航

• 上一篇：该不该给产品加 AI：四道判据、三种替代与退出条件
• 下一篇：模型供应商选择：五维打分、两条备选与迁移成本
• 回到目录：一个人给产品加 AI：判据、成本、护栏与验收
• 相关阅读：模型路由与选型：大小模型分层调度 、模型网关与多模型路由