小林在创业街上开了一家“AI 私厨”餐厅，招牌是用大模型现点现做。每做一道菜，都要从“云上菜市场”现买食材——那些按 token 计价的模型调用，输入是面粉，输出是奶油。开业头三个月，客人络绎不绝，可月底一算账，小林傻眼了：卖得越多，亏得越多。问题出在哪？他既没记清楚每道菜的食材成本，也没把“大胃王”和“小鸟胃”客人分开对待，菜单定价更是拍脑袋定的。这本“AI 餐厅经营指南”，就是要把成本归因、用户分级、配额、计费模式、免费额度、优化杠杆和数据复盘这七件事讲明白，让你做 AI 产品时，既给用户好体验，又能把毛利算正、把生意做长久。

岗位关联

对 AI 从业者而言，这是从“技术能跑”到“商业能赚”的关键一跃：会算 token 成本，才能设计出可持续的商业模式，让产品在市场竞争中活下来、活得好。

目录
  1. 可视化演示
  2. 成本归因：给后厨记一本明白账
  3. 用户分级管理：把“大胃王”和“小鸟胃”分开
  4. 配额机制：自助餐厅的“两小时”规则
  5. 计费模式抉择：单点还是自助餐？
  6. 免费额度平衡：试吃券的面额设计
  7. 成本优化杠杆：供应链的降本四板斧
  8. 数据驱动调优：每周经营复盘会
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示AI产品的Token成本控制的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI产品的Token成本控制：Toke Token成本构成与归因方法 用户用量分级与配额设计 核心机制可视化 AI产品的Token成本控制整体架构与关键组件

成本归因：给后厨记一本明白账

小林的后厨每天用掉面粉、奶油、巧克力，但他从没记过台账。月底看到账单才知道，原来那道招牌甜品每卖一份要亏 3 块钱——食材成本比售价还高。AI 产品也一样，不做成本归因，你根本不知道哪个功能是“利润黑洞”。归因的第一步，是搞清楚大模型 API 到底怎么收费。一次调用分成输入和输出两部分：你传进去的系统提示词、用户历史消息、工具返回结果，全算“输入”；模型吐出来的回答，算“输出”。主流模型中，输入和输出的单价通常在 1:3 到 1:5 之间——输出贵得多，因为生成内容更“费力”。

但很多人忽略的是，成本的大头往往不是答案本身，而是你每次都要带着的那坨历史记录。一个聊天机器人如果没做上下文裁剪，用户聊了 50 轮，每轮都把前 50 轮的消息重新发给模型，那单轮成本会随着对话轮数线性膨胀。真正专业的做法是：给每个请求打上用户维度、功能维度和会话维度的标签，再用监控平台把消耗分摊到每一笔业务上。这就相当于在每张点菜单上写清楚“这桌客人是谁、点了哪个菜、用了多少食材”。

归因的最终落点，是算出每个功能、每个用户的毛利。毛利 = 该用户贡献的收入 - 该用户消耗的 token 成本。只有把这本账记明白了，才知道该砍哪道菜、该给哪道菜提价。

记账本上的每个数字都在提醒小林：食材再贵，只要单价卖得对、用量控得住，利润就能挤出来。成本归因，就是 AI 生意从“凭感觉”走向“算得清”的第一步，也是后面所有策略的地基。

---

Creq=(Tin×Pin+Tout×Pout)×11000\displaystyle C_{\text{req}} = \left( T_{\text{in}} \times P_{\text{in}} + T_{\text{out}} \times P_{\text{out}} \right) \times \frac{1}{1000}
单次 API 调用的成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价，再除以 1000（因为 API 按“每千 token”计价）。
  1. 输入成本把本次请求传入的 token 数量与输入单价相乘，得到输入部分的花费。
    Tin×PinT_{\text{in}} \times P_{\text{in}}
  2. 输出成本把模型生成回复的 token 数量与输出单价相乘，得到输出部分的花费。
    Tout×PoutT_{\text{out}} \times P_{\text{out}}
  3. 归一化单位两者相加后乘以 1/1000，把结果换算成按“千 token”计价的账单金额。
    (Tin×Pin+Tout×Pout)×11000\left( T_{\text{in}} \times P_{\text{in}} + T_{\text{out}} \times P_{\text{out}} \right) \times \frac{1}{1000}

用户分级管理：把“大胃王”和“小鸟胃”分开

小林发现餐厅里有两类常客。一位小哥哥每次点两份战斧牛排外加三份甜品，食材成本拉满；另一位小姐姐只点一杯柠檬水，坐一下午。两人消费能力天差地别，却付差不多的钱。一个 AI 产品上线后，用户消耗呈典型的幂律分布：极少数重度用户消耗了绝大部分 token，大多数轻量用户几乎不产生成本。如果不做用户分级，一视同仁地给免费额度，那“大胃王”们会把你吃垮。

分级的第一步是筛选维度：按日调用次数、月度 token 消耗、是否高频调用昂贵模型等指标，把用户映射到不同层级。常见的四级模型是：免费体验层（新客尝鲜）、基础付费层（个人用户）、专业层（重度个人或小团队）、企业层（高用量高价值客户）。定级标准不是拍脑袋，而是看“单位用户的价值比”——用户每月贡献的收入除以他每月消耗的成本，这个比值大于 1 才有赚头。

分级之后是差异化策略分发：免费层给最基础的模型和最低配额；基础层加一些额度但限制峰值并发；专业层解锁快速模型和高阶功能；企业层走专属合同、私有化部署和账单后付。同时要用异常调用识别盯住“伪装成大胃王的小鸟胃”——比如凌晨每秒钟几十次调用的脚本流量，很可能是在盗用你的 API Key。通过按天聚合的消耗监控，把超出正常模式的调用单独捞出来，要么限流、要么提醒、要么封禁。

把“大胃王”请到楼上包间吃付费套餐，把“小鸟胃”留在大堂享受免费柠檬水，才是聪明的餐厅经营之道。用户分级不是歧视谁，而是让每个用户都获得与其价值匹配的服务，也让产品的成本结构保持健康。

---

Vuser=RuserCuser\displaystyle V_{\text{user}} = \frac{R_{\text{user}}}{C_{\text{user}}}
用户价值比 = 单用户月收入 ÷ 单用户月成本。比值大于 1 说明这个用户能带来利润，小于 1 则在持续失血。
  1. 分子用户收入：统计该用户当月实际支付的费用，作为他贡献的价值输入。
    RuserR_{\text{user}}
  2. 分母用户成本：统计该用户当月消耗的全部 token 成本，包括输入输出和缓存未命中的部分。
    CuserC_{\text{user}}
  3. 比值判断相除后得到价值比，用这个数决定该发多少免费额度、该不该引导升级。
    RuserCuser\frac{R_{\text{user}}}{C_{\text{user}}}

配额机制：自助餐厅的“两小时”规则

自助餐厅为什么限时两小时？因为“无限畅吃”意味着成本没有天花板——一个客人吃 50 只龙虾，餐厅就得亏 50 只龙虾的钱。AI 产品的免费层和低价层，本质上就是一场自助餐。要让这场自助餐开得下去，必须设计配额机制，给“无限畅吃”装上闸门。

配额类型通常按三个维度设计：按时间（每天/每周/每月的调用次数上限）、按用量（累计 token 数上限）、按功能（某个昂贵功能如长文生成、多轮对话的单独配额）。层级上则要分三层：用户级（单个账号的额度）、API Key 级（一个应用的全部额度）、功能级（特定接口的额度）。比如企业版用户一天可以调用 10 万次，但“深度分析”这个昂贵功能一天最多 500 次——这就是功能级配额在起作用。

配额用尽后怎么办？直接报错是最粗暴的，会赶走用户。更好的做法是分层降级：第一个台阶是限速排队（把请求延后处理）；第二个台阶是降级到更便宜的模型（让简单问题交给小模型回答）；第三个台阶才是提示用户购买更多额度。同时要建立用量监控预警：当用户消耗达到配额的 70% 时发站内提醒，90% 时发短信，100% 时自动执行降级策略——这样既保护了用户体验，也保护了你的毛利。

自助餐的“两小时”规则，表面上是限制，本质上是对所有人的保护——没有规则，餐厅亏损倒闭，客人也没得吃。配额机制同样如此，它让免费用户有个稳定的预期，也让产品能长期活下来。

---

Qlimit=Dpeak×B\displaystyle Q_{\text{limit}} = D_{\text{peak}} \times B
配额上限 = 每日峰值调用量 × 缓冲系数。缓冲系数通常取 1.2～2.0，既要防超卖，也别限制正常增长。
  1. 峰值用量取过去 30 天里最高的一天调用量，作为设计基准。
    DpeakD_{\text{peak}}
  2. 缓冲系数乘以一个留有余量的系数，避免用户在某天突发增长时立刻撞墙。
    BB
  3. 上限设定两者相乘得到配额值，既能覆盖正常波动，又不会让成本无限放大。
    Qlimit=Dpeak×BQ_{\text{limit}} = D_{\text{peak}} \times B

计费模式抉择：单点还是自助餐？

菜单的定价方式，决定了餐厅的生存模式。如果只做“按道单点”，客人少时收入为零；如果只做“月卡畅吃”，碰到大胃王就亏本。AI 产品的计费模式，同样是在这几种选择之间做平衡。

按量计费（Pay-as-you-go）像单点：用多少 token 付多少钱，账目清楚、门槛低，适合用量波动大的轻量用户和开发者工具。但它的缺点是收入不稳定，而且用户对价格敏感，用完就走的比例很高。订阅制（Subscription）像自助餐月卡：先收月费、再让用户畅用一定额度，收入可预期，用户也会因为“已经付费”而更粘。但问题是高用量用户可能让你亏本——你必须用配额控制用量，或用分级套餐拉开差距。

混合计费是当下 AI SaaS 的主流解法：基础月费覆盖一部分额度（比如专业版 299 元/月包含 100 万 token），超出部分按量加价。它把订阅制的稳定性和按量的弹性结合在一起，相当于“入场券 + 单点加菜”。选择哪种模式，可以用一张决策矩阵：先画出你的用户消耗分布，如果大部分用户消耗集中在低区间，按量更合适；如果存在明显的高频重度用户，订阅+配额更好；如果两条曲线都有，就上混合。

小林的菜单上既有按份卖的小菜，也有“畅吃月卡”，还有“基础会员 + 大菜单点”的混合套餐。定价从来不是一道单选题，而是根据用户消耗分布画出的最优解。

---

GM=R−CR⇒P=C1−GM\displaystyle GM = \frac{R - C}{R} \quad \Rightarrow \quad P = \frac{C}{1 - GM}
毛利率 =（收入 - 成本）÷ 收入。给定目标毛利率，就能反推出应收的定价。比如目标毛利 70%，成本 10 元，那就该卖 33 元以上。
  1. 定义毛利用收入减去成本，得到赚到的钱。
    R−CR - C
  2. 归一化除以收入，得到毛利率，衡量每挣 100 元里有多少是利润。
    R−CR\frac{R - C}{R}
  3. 反推定价整理公式把 P 解出来，让定价从成本倒推，而不是拍脑袋。
    P=C1−GMP = \frac{C}{1 - GM}

免费额度平衡：试吃券的面额设计

新餐厅开业都要发试吃券，但面额要精心设计：太小了客人尝不出味道就走人；太大了客人天天来蹭饭，餐厅直接破产。AI 产品的免费额度，本质上就是一张试吃券，它的面额（每月免费 token 数）应该用公式算出来，而不是拍脑袋定一个“看起来挺大方”的数字。

免费额度的设计思路是：把你获取一个付费用户的成本（广告投放、内容营销、销售人力）折算成 token 价值。如果获客成本是 100 元，单位 token 的边际成本是 0.00002 元，那么你可以承受的免费额度是 500 万 token——超过这个数，还不如拿这笔钱直接去投放广告。但这个值还要叠加一个上限，防止被批量注册的“羊毛党”薅走。

梯度设计上，建议按“2-3 档阶梯”切分：免费层给一个能完整体验核心功能的量（比如每月 10 万 token）；注册即送首月加倍额度（引导完整体验）；额度用完后不是硬切断，而是弹出“升级专业版解锁更多额度”的转化引导。最后是防薅羊毛机制：手机号/邮箱验证是第一道门槛，设备指纹和调用模式风控是第二道，检测到异常高频调用就触发人工审核或封禁。

试吃券的终极目标不是让客人免费吃饱，而是让客人记住味道、心甘情愿下次掏钱。免费额度是获客杠杆，不是慈善拨款，每一分免费预算都要能追溯它带来了多少付费转化。

---

Qfree=min⁡(CacqCˉunit,  Qmax⁡)\displaystyle Q_{\text{free}} = \min\left( \frac{C_{\text{acq}}}{\bar{C}_{\text{unit}}},\; Q_{\max} \right)
免费额度上限 = 获客成本 ÷ 单位 token 成本，但同时设一个安全上限。它回答了一个关键问题：这笔“免费预算”花得值不值。
  1. 获客成本计算平均获取一个付费用户花的市场费用，这是免费额度的“预算来源”。
    CacqC_{\text{acq}}
  2. 单位成本算出每个 token 的边际成本，用来把“元”换算成“token 数”。
    Cˉunit\bar{C}_{\text{unit}}
  3. 取安全上限换算结果与人为设定的最大值取较小者，避免换算值过大导致被薅羊毛。
    min⁡(CacqCˉunit,  Qmax⁡)\min\left( \frac{C_{\text{acq}}}{\bar{C}_{\text{unit}}},\; Q_{\max} \right)

成本优化杠杆：供应链的降本四板斧

餐厅降本不是偷工减料，而是换供应商、用边角料、改菜谱。AI 产品的成本优化也有四板斧：模型分层、缓存复用、上下文压缩、批处理降本。

模型分层是性价比最高的杠杆：简单任务（意图识别、实体抽取、格式整理）交给小模型，复杂推理（代码生成、深度分析）才用大模型。一个翻译功能用 mini 模型就能完成，没必要每次都召唤旗舰模型。缓存复用则是把客人点过的同一道菜“提前做好放冰箱”：同样的查询、同样的结果，第二次来直接上菜，不再麻烦大厨。对于 FAQ 类场景，缓存命中率可以到 60% 以上，意味着 60% 的 token 成本瞬间归零。上下文压缩解决的是“历史包袱”问题：限制 system prompt 长度、滑动窗口截断历史消息、把长对话总结成摘要再传给模型——每一轮能省下的输入 token 非常可观。批处理降本则是把不紧急的任务（日报生成、批量打标签）攒起来，走平台的批量 API，单价通常比实时调用便宜一半。

这四个杠杆组合起来的效果，用缓存命中率举个例子：完全不用缓存的成本是 C，命中率 60% 后，有效成本会降到原来的四成左右。

四板斧齐上阵，小林餐厅的食材采购成本降了三成，菜的品质却没降。成本优化不是让用户吃得差，而是让每一分钱都花得更聪明。

---

Ceff=Cfull×(1−h)+Ccache×h\displaystyle C_{\text{eff}} = C_{\text{full}} \times (1 - h) + C_{\text{cache}} \times h
有效成本 = 全价成本 ×（1 - 缓存命中率）+ 缓存命中后的成本 × 缓存命中率。当缓存命中率高时，有效成本大幅下降。
  1. 未命中部分命中率之外的请求仍按全价计费，成本是全价乘以未命中比例。
    Cfull×(1−h)C_{\text{full}} \times (1 - h)
  2. 命中部分命中缓存的请求只花少量查询费用，是缓存成本乘以命中比例。
    Ccache×hC_{\text{cache}} \times h
  3. 加总得有效成本两部分相加，就是加了缓存优化后的真实账单。
    Ceff=Cfull×(1−h)+Ccache×hC_{\text{eff}} = C_{\text{full}} \times (1 - h) + C_{\text{cache}} \times h

数据驱动调优：每周经营复盘会

小林的餐厅每周一晚上打烊后开复盘会：看营业额、翻台率、食材损耗率、差评关键词，然后决定下周的菜单怎么调。AI 产品的成本管理同样需要这样的复盘闭环——靠感觉经营，迟早关门；靠数据调优，才能持续赚钱。

核心指标要盯四个：总 token 消耗（看大盘趋势）、单功能成本（找利润黑洞）、单用户成本（盯大胃王）、毛利曲线（看生死线）。把这些指标做成看板，按日更新，每周拉一次周报。更进一步的，是把“策略迭代”也纳入数据闭环：这个月把免费额度从 50 万降到 30 万 token，会不会影响转化率？把专业版价格从 199 涨到 299，付费用户流失多少？每次调整都做一个 A/B 实验，用数据验证假设，而不是拍脑袋。

数据闭环的最终落点，是验证你的商业模型是否成立。用一个经典的 SaaS 指标——LTV（用户生命周期价值）：一个用户从开始付费到流失，平均能带来多少毛利。如果 LTV 远大于获客成本，说明模型健康；如果 LTV 小于获客成本，说明每拉一个新用户都在亏钱。每月复盘时问自己一句：老用户还在吗？成本涨了吗？毛利正了吗？三个答案都是肯定的，这门 AI 生意才算真正跑通了。

每周的复盘会上，小林盯着看板上的毛利曲线，心里踏实了。数据不会骗人，它会告诉你哪道菜该下架、哪个套餐该调价、哪类客人该重点维护。AI 产品的商业模型，就是在这一次次复盘中被修正和验证的。

---

LTV=Rmonth×GMchurn\displaystyle \text{LTV} = \frac{R_{\text{month}} \times GM}{\text{churn}}
用户生命周期价值 = 月收入 × 毛利率 ÷ 月流失率。这个公式告诉你：留住一个老用户，比拉来一百个新用户更值钱。
  1. 月收入统计一个活跃付费用户平均每月贡献的收入。
    RmonthR_{\text{month}}
  2. 毛利率修正乘上毛利率，得到月毛利而不是月流水。
    Rmonth×GMR_{\text{month}} \times GM
  3. 考虑流失除以月流失率，把“每月毛利”放大成“整个生命周期的总毛利”。
    Rmonth×GMchurn\frac{R_{\text{month}} \times GM}{\text{churn}}

AI 应用场景

智能客服 SaaS 的成本看板与分级配额

阶段：商业化运营与成本管控

解决的问题：传统客服外包按坐席收费，成本固定但体验不稳定；AI 客服接入大模型后体验上去了，但每个用户的问题长度不同、调用频率不同，token 成本飘忽不定，月底一算可能倒贴。

具体案例：某电商 SaaS 服务商给 200 家商家提供 AI 客服。他们在后台搭了成本看板，按“商家维度”归因 token 消耗，把调用量 Top 10% 的商家划入高消耗分组，单独设置日配额——超过 5000 次/天后自动降级到小模型。同时商家付费套餐绑定混合计费：基础版含 50 万 token，超出部分按量加价。三个月后，该服务商毛利率从 12% 提升到 41%。

文档摘要工具的模型分层与缓存复用

阶段：推理优化与成本工程

解决的问题：文档摘要产品每天处理大量重复文档（合同模板、周报格式），每次都调用旗舰模型做全量摘要，成本高且延迟大。

具体案例：一个文档智能摘要工具引入了语义缓存：对上传文档先做 Hash 和相似度比对，相同文档直接返回历史摘要，不重复调用大模型。命中率约 45%。同时按文档类型做模型分层：短合同用 mini 模型，长研报用旗舰模型。整体 token 成本下降了 58%，用户无感，摘要质量不变。

陪伴型 AI 产品的免费额度风控与转化

阶段：用户增长与商业化设计

解决的问题：陪伴类 AI 产品聊天轮次深、上下文长，单用户成本高。如果免费额度给得太大方，会被薅羊毛；给得太少，用户还没体验到情感价值就流失。

具体案例：某 AI 陪伴 App 设计了三档免费梯度：新用户首周 10 万 token（体验核心对话），后续每周 3 万 token（维持基本互动），深度功能（语音、记忆）仅对付费用户开放。同时接入设备指纹 + 调用频率风控，封禁了 12% 的批量注册账号。免费转付费率从 1.8% 提升到 3.5%。

Python 演示

python46 行
# -*- coding: utf-8 -*-"""Token cost & pricing simulator for AI SaaS products.""" UNIT_PRICE = 0.02        # CNY per 1K tokensTOKENS_PER_CALL = 1500   # avg tokens per API call  def monthly_cost(calls, cache_hit):    """Monthly token cost for one user. cache_hit in [0, 1]."""    billed = calls * (1 - cache_hit)    return billed * TOKENS_PER_CALL * UNIT_PRICE / 1000  def simulate(users, mode, cache_hit=0.2, included=800):    """Compute monthly revenue & cost by pricing mode."""    price_map = {"basic": 99, "pro": 299, "enterprise": 999}    calls_map = {"basic": 800, "pro": 2500, "enterprise": 8000}    revenue = 0    cost = 0    for tier, count in users.items():        for _ in range(count):            c = monthly_cost(calls_map[tier], cache_hit)            cost += c            if mode == "payg":                revenue += c * 2.0            elif mode == "flat":                revenue += price_map[tier]            elif mode == "mixed":                revenue += price_map[tier]                extra = max(calls_map[tier] - included, 0)                revenue += extra * TOKENS_PER_CALL * UNIT_PRICE / 1000 * 1.6    return revenue, cost  def main():    users = {"basic": 800, "pro": 200, "enterprise": 30}    print("mode     revenue   cost    profit   margin")    for mode in ("payg", "flat", "mixed"):        rev, cost = simulate(users, mode)        profit = rev - cost        print("%-7s %8.0f %8.0f %8.0f %6.1f%%" %              (mode, rev, cost, profit, profit / rev * 100))  if __name__ == "__main__":    main()
目的：模拟一个 B 端 AI SaaS 产品（800 个基础版、200 个专业版、30 个企业版用户）在三种计费模式下的月度收入、成本、毛利和毛利率，帮你在定价决策前快速试算。
  1. billed = calls * (1 - cache_hit)缓存命中的请求不再计费，这是降本的第一杠杆。
  2. price_map = {"basic": 99, "pro": 299, "enterprise": 999}订阅月费表，按用户等级设置不同定价。
  3. revenue += c * 2.0按量计费模式下，以边际成本 2 倍的价格向用户收取 API 费用。
  4. extra = max(calls_map[tier] - included, 0)混合计费中，只有超过基础包含额度的部分才按量加价。
  5. profit / rev * 100输出毛利率，验证每种计费模式的商业健康度。

常见误区

误区我一直以为 token 数就是用户看到的内容字数。用户问 50 个字，模型回 200 个字，那这一轮就是 250 个 token 的成本。系统提示词和聊天历史不是钱，只有“回复内容”才是钱。

正解Token 是模型对文本的分片单位，一个中文字可能对应 1～2 个 token，英文一个单词往往被切分成多个 token。更关键的是，输入部分的 token（系统提示词、历史记录、工具返回结果）每一轮都会重新计费。一次用户提问看似只有几十字，但背后携带的上下文可能长达几千 token。所以真正要优化的不只是回复长度，而是每一轮请求的总 payload。

为何常见：因为大家习惯用“字数”衡量文本，而 API 账单按 token 计费，两者并不等价。加上各家模型分词规则不同，凭感觉估算自然偏差很大。

误区选模型当然选便宜的。GPT-4o mini 每千 token 几分钱，比旗舰模型便宜十倍，那我就全换 mini，成本自然就降下来了。

正解模型单价的比较必须放在“完成同一业务任务”的语境下。便宜的 mini 模型可能一次写不对、要调用三次重试，而旗舰模型一次就成功。单位任务的综合成本 = 单价 × 平均调用次数。更隐蔽的是：如果使用了缓存、批处理、上下文压缩，实际有效成本会远低于原始单价。只看单价不看总账，反而是最贵的省法。

为何常见：因为单价是最容易被感知、最容易横向比较的指标，而“平均调用次数”需要打点统计、需要数据积累，大多数人懒得算。

误区免费层是获客利器，额度给得越多，用户体验越好，口碑传播越快。所以我把每月免费额度定得高高的，等用户爱上产品再收费。

正解生成式 AI 的边际成本不为零，每个免费用户都在实打实地消耗你的现金。免费额度的本质是用钱买用户，买不买得值要看转化率。科学做法是用“获客成本 ÷ 单位 token 成本”倒推额度上限，并配合梯度设计（首月多送、后续恢复），让用户在体验完核心价值后自然步入付费层。无限额度的结果往往是羊毛党吃饱，真实用户没转化，公司先倒地。

为何常见：受互联网“免费获客-广告变现”旧模式影响，很多人忽略了 AI 产品有真实的边际成本，免费不再是“零成本”获客。

误区订阅制收入稳定、用户忠诚度高，是 SaaS 的标配。做 AI 产品就该全部转向订阅制，把按量计费砍掉。

正解订阅制对“用量稳定”的用户是双赢，但对“用量波动大”的用户并不友好——他们可能一个月用 3 次，下个月用 3000 次。如果你把价格定在覆盖高用量用户的水平，低用量用户会觉得太贵而流失；定在覆盖低用量用户的水平，高用量用户会把你吃垮。正确做法是看用户消耗分布：分布峰度越高越适合按量，越平缓越适合订阅，两者并存时用混合模式各取所长。

为何常见：把传统 SaaS 的订阅逻辑直接套用到 AI 产品上，忽略了 AI 产品“每多服务一个用户都要多付模型费”的成本结构差异。

面试题

Q1. 大模型 API 计费的最小计价单位通常是？

单选题 · easy

  • A.每千次请求为计费单位
  • B.每千个 Token 为计价单位← 正确答案
  • C.每分钟调用时长为计费
  • D.每兆字节传输量为计费

答案：B。主流大模型 API 都按 token 计费，并以 1000 个 token 为一个计价单位，而不是按请求次数、时长或流量计费。理解这一点是成本归因的第一步，就像买菜按斤算而不是按颗算。

Q2. 判断用户“值不值得服务”，最直接的财务指标是？

单选题 · easy

  • A.注册天数与活跃度
  • B.界面停留的总时长
  • C.单用户的月毛利额← 正确答案
  • D.用户评价的星级数

答案：C。单用户月毛利 = 用户贡献收入 - 用户消耗成本，直接反映这个用户是赚钱还是亏钱。活跃度和停留时长是过程指标，毛利才是结果指标。

Q3. 哪种用户最适合订阅制？

单选题 · easy

  • A.用量波动剧烈的散户
  • B.注册后从不使用的用户
  • C.仅试用一次就流失的新客
  • D.用量稳定的重度用户← 正确答案

答案：D。订阅制靠“稳定用量”摊平成本：用量稳定的重度用户付费意愿强、消耗可预测，订阅方和用户双方受益。波动剧烈的用户更适合按量计费。

Q4. 某用户每天调用 3000 次、单次 1500 Token，模型单价 ¥0.02/千 Token，日成本约？

单选题 · mid

  • A.每日约四十五元
  • B.每日约九十元整← 正确答案
  • C.每日约三百元整
  • D.每日约四百五十元

答案：B。日调用量 3000 × 单次 1500 token = 450 万 token/日，按千 token 计费：450 万 ÷ 1000 × 0.02 = 90 元/日。掌握这个换算方法，才能快速评估一个用户的成本量级。

Q5. 请求命中 Prompt 缓存后，成本行为是？

单选题 · mid

  • A.按原价全额计费收取
  • B.输出部分变为零成本
  • C.输入部分费用显著降低← 正确答案
  • D.额外加收缓存管理费用

答案：C。Prompt 缓存的机制是：相同的输入前缀在短时间内再次出现时，输入 token 的费用大幅降低（很多平台降为原来的 10%）。输出部分因为是新生成，仍然正常计费，也不会额外收管理费。

Q6. 降低 Token 成本的有效杠杆包括？

多选题 · mid

  • A.对重复请求开启缓存← 正确答案
  • B.压缩上下文精简 Prompt← 正确答案
  • C.无条件提高模型输出长度
  • D.简单任务选用小模型← 正确答案

答案：ABD。缓存复用减少重复计算的 token，上下文压缩减少每轮请求的输入量，小模型完成简单任务单价更低——三者都是经典降本手段。无条件提高输出长度反而增加成本，且可能引入更多幻觉。

Q7. 防止免费层被薅羊毛，最有效的组合是？

单选题 · hard

  • A.不设任何免费额度直接关闭
  • B.无限提升新用户免费额度
  • C.身份绑定加调用模式风控← 正确答案
  • D.仅靠用户手动填写手机号

答案：C。身份绑定（手机号、设备指纹）解决“一个人注册多账号”的问题，调用模式风控解决“脚本高频刷量”的问题，两者组合才是完整的防薅体系。只靠手机号可被接码平台绕过，完全不设免费额度则失去了获客入口。

Q8. 为什么不能只凭模型单价选模型？

多选题 · hard

  • A.输入输出单价本身不同← 正确答案
  • B.调用次数影响总价成本← 正确答案
  • C.缓存命中会改变真实成本← 正确答案
  • D.高单价模型效果必然更好

答案：ABC。模型真实的成本 = 单价 × 调用次数 - 缓存/批处理等优化节省。输入输出单价差异、不同任务的重试率、缓存命中率都会让“名义单价”和“真实成本”严重偏离。高单价不等同于效果好，必须按业务场景实测对比。

Q9. 混合计费模式设计中，最关键的业务平衡是？

单选题 · hard

  • A.提高免费额度来压制付费
  • B.彻底放弃按量计费通道
  • C.让订阅价覆盖所有成本
  • D.基础费与超量费率的联动← 正确答案

答案：D。混合模式的核心是“基础月费 + 超量按量”。基础费定得多高、包含多少额度、超量费率定多少，三者必须联动校准，避免“订阅费覆盖不了重度用户成本”或“超量费贵到吓跑用户”两头失衡。

Q10. 数据驱动调优看板应重点监控的指标有？

多选题 · extreme

  • A.单用户单月成本变化← 正确答案
  • B.成本收入比的趋势线← 正确答案
  • C.模型输出字数的波动
  • D.缓存命中率与降级次数← 正确答案

答案：ABD。单用户成本暴露“大胃王”，成本收入比反映整体商业健康度，缓存命中率和降级次数则直接体现成本优化杠杆是否生效。输出字数波动本身不构成业务指标，还需结合功能价值判断，不单列监控。