AI产品定价数学：固定费率如何悄悄亏损

AI 产品定价页面上有一种模式反复出现：某个计划写着"19 美元/月，包含 1000 万 tokens"，表面上看很合理——直到你真正跑一遍成本数学。

三周后，创始人盯着比 MRR 还高的 LLM 账单，想找出是哪个重度用户闯的祸。

以下是你在一个定价方案上线前就应该算清楚的数学。

AI 计划亏损的三种方式

1. 混合成本比预期高。

输入 tokens 和输出 tokens 成本并不相同。输出通常贵 3–8 倍。直接用厂商的标称价格定价，意味着每个 token 的真实成本从一开始就错了。

2. 超额费用定价低于成本。

某个计划包含 500 万 tokens，超出部分收取"每 100 万 0.50 美元"——看起来很大方——直到你算出实际混合成本是每 100 万 3.60 美元。每个重度用户都会入不敷出。

3. 支付手续费吃掉低价计划。

Stripe 收取 2.9% + 0.30 美元。一个 19 美元的计划，手续费就是 0.85 美元——还没用掉一个 token 就损失了 4.5% 的营收。平台费（Creem、Gumroad、Lemon Squeezy 收取 5–10%）能把低价计划的利润空间完全吃掉。

核心数字是每 100 万 tokens 的混合成本：

blended_cost_per_M = 0.8 * input_price + 0.2 * output_price

4:1 这个比例是聊天类产品的合理默认值。偏摘要的产品应该接近 10:1；偏生成的产品接近 1:1。这个比例应该与实际流量相匹配。

用 2026 年的模型价格跑一遍，差距非常显著：

最便宜和最贵的路由方案之间相差 30 倍。一个"19 美元 = 1000 万 tokens"的计划不可能覆盖所有方案。如果定价假设所有用户都用预算模型，而用户实际上把所有请求都路由到旗舰模型——那每个订单都在亏钱。

SAFE/UNSAFE 检查加上支付手续费和最低利润率：

net_revenue = price - payment_fees
cost_of_included_quota = included_tokens * blended_cost
margin = (net_revenue - cost_of_included_quota) / net_revenue

当利润率低于 15%，或者超额价格低于混合成本的 1.6 倍时，计划被标记为 UNSAFE。

一种零依赖的检查方式

上面的数学可以在电子表格里手算，但很容易在细节上出错——尤其是 Decimal 处理。每 100 万 tokens 的价格比如 0.28 美元/100 万，换算成小数是 0.00000028；四舍五入到分就变成了 0.00 美元。这是一个静默的营收泄漏。

有一个小的零依赖 Python 库封装了这个检查：

pip install ai-token-pricing

from ai_token_pricing import validate_plan_economics, PLAN_CATALOG

r = validate_plan_economics(
    PLAN_CATALOG["budget-pro"],
    blended_cost_per_m=0.40
)

print(r["status"])                    # SAFE
print(r["max_safe_included_tokens"])  # the real ceiling
print(r["break_even_overage_price"])  # the floor for overage

指向一个糟糕的计划，它会返回 UNSAFE，而不是悄无声息地允许一个亏本卖家的存在。CLI 在 UNSAFE 时以非零退出码退出，所以一个糟糕的定价变更可以让部署失败：

ai-token-pricing check --plan flagship-pro --blended-cost 9.00

金钱计算使用 Decimal 而不是 floats。库内部处理了转换，不需要手工敲字符串。

这没有覆盖什么

这只能检查 token 经济性。它不计入基础设施、支持费用、重试、退款、拒付，以及其他开销。SAFE verdict 是盈利的必要非充分条件。

计费实现层——Stripe 按量计费、权重配额、使用量上限，以及 Stripe 文档跳过掉的边缘情况——在另一篇文章中有详细讨论：Usage-based billing for AI SaaS: what the Stripe docs don't tell you。

部分评论可能仅对登录访客可见。登录后可查看所有评论。