AI SaaS 毛利率能不能直接套 70% 目标？

不能直接套。先算单用户收入和 p50、p90、p99 成本分布，再定目标毛利。文档摘要、客服、代码 Agent 的输出 token 和重试率差异很大，一个统一数字会误导定价。

模型官方单价应该多久更新一次？

每次改套餐前都要查看官方 pricing page，平时至少每月看一次账单差异。文章里的价格只能当示例，真正上线要把模型、地区、缓存、Batch 和企业折扣拆成变量。

prompt caching 应该写进价格页承诺吗？

不要把缓存收益承诺给所有用户。缓存只对重复的系统提示词、工具定义、文档前缀和多轮工作流有效；新产品先按无缓存成本定价，再把命中率当毛利改善项。

AI SaaS 毛利怎么算 | Unit Economics

很多 AI SaaS 的毛利表坏在第一列：只填了月收入和模型账单，没有把 token 类型、重试、缓存命中、后台任务、滥用和固定成本分开。这样算出来的毛利看起来很高，等 p99 用户、爬虫或批量导入任务出现，账单才会露出真实形状。

这篇只讨论产品自己的 unit economics。relay、proxy、gateway 都不是商业模式本身；它们最多改变 API 调用成本、可用性、错误透明度和账单导出质量。

AI SaaS 毛利到底算什么？

最小公式先写清楚：

单用户毛利 = 单用户收入
  - 模型/API 成本
  - 支付与退款成本
  - 存储、向量库、队列和日志分摊
  - 失败重试、超时和人工回补成本
  - 滥用、免费额度和促销额度损耗

毛利率 = 单用户毛利 / 单用户收入

如果你要和传统 SaaS 对齐，支付费、客服和基础设施归类可能会有差异。早期独立开发者不用纠结会计科目，先保证同一张表每个月口径一致。

更重要的是不要只看平均用户。AI 产品的成本常见长尾来自三类人：上传超长文档的人、反复重试的人、把免费额度脚本化调用的人。价格表要能覆盖 p90 用户，风控要拦住 p99 异常用户。

一次请求要拆成哪些成本项？

LLM 请求不是一个总 token 数。Anthropic 的 pricing 和 prompt caching 文档把输入、输出、cache write、cache read 分开计价；这正好也是 SaaS 成本表该采用的口径。

成本项	记录字段	为什么单独算
普通输入 token	`input_tokens`	用户问题、检索片段、未缓存上下文都在这里
输出 token	`output_tokens`	通常比输入更贵，也是长回答烧钱来源
缓存写入	`cache_creation_input_tokens`	第一次写入会产生额外成本，不能误当免费
缓存读取	`cache_read_input_tokens`	命中后成本下降，但只对重复前缀有效
工具与系统开销	`tool_name`, `tool_tokens`	function/tool schema、系统提示词会进入输入成本
重试与失败	`retry_count`, `error_code`	429、5xx、超时会让同一用户成本翻倍
离线任务	`job_type`, `batch_id`	Batch 成本和同步请求不同，SLA 也不同
通道倍率	`provider`, `channel_multiplier`	官方直连、云平台、relay/proxy 都要落成一个倍率

只要日志里缺这几列，毛利优化就会变成猜谜。你可能以为用户在消耗模型，实际是某个失败重试循环在烧钱。

能不能用一个示例算清楚？

下面是一个假设的文档摘要 SaaS 单用户月账。模型价格使用 Anthropic pricing page 在 2026-05-22 可见的 Claude Sonnet 4.6 示例口径：普通输入 3 美元/MTok、输出 15 美元/MTok、5 分钟 cache write 为 1.25 倍输入价、cache hit 为 0.1 倍输入价；Batch API 在该页列为输入和输出 50% 折扣。你的产品必须回到官方页面和自己的账单后台重算。

项目	假设	计算	单用户月成本
月收入	Pro 套餐 29 美元	收入	29.00 美元
支付费	示例占位 3%，以上线账户为准	29 × 3%	0.87 美元
同步普通输入	80 次 × 1,000 tokens	80k × 3 / 1M	0.24 美元
同步输出	80 次 × 500 tokens	40k × 15 / 1M	0.60 美元
缓存写入	10 次 × 8,000 tokens	80k × 3.75 / 1M	0.30 美元
缓存读取	70 次 × 8,000 tokens	560k × 0.30 / 1M	0.17 美元
离线 Batch	20 个后台任务	30k input × 1.5 / 1M + 6k output × 7.5 / 1M	0.09 美元
存储与日志分摊	向量库、队列、监控、邮件	内部分摊	1.20 美元
重试/滥用缓冲	模型成本约 10%	约算	0.14 美元
合计成本	不含客服与税	成本合计	3.61 美元
单用户毛利	29 - 3.61	25.39 / 29	87.6%

这个结果不是行业均值，只是计算口径。只要用户行为变成 20 次长文档、10 次 Agent 工具链、输出 token 放大 5 倍，毛利会立刻变形。

上线前至少再做三档压力测试：p50 普通用户、p90 重度用户、p99 异常用户。套餐只按 p50 定价，等于把亏损用户交给运气。

token metering 应该怎么落库？

不要等账单来了再倒推。每一次模型调用都应该写一条成本事件，至少包含这些字段：

字段	示例	用途
`user_id` / `workspace_id`	`u_123`, `ws_9`	单用户和团队分摊
`feature`	`doc_summary`, `chat`, `agent_run`	找到烧钱功能
`model`	`claude-sonnet-4-6`	不同模型单价不同
`input_tokens` / `output_tokens`	`1000`, `500`	成本基础
`cache_read_input_tokens`	`8000`	计算缓存命中收益
`cache_creation_input_tokens`	`8000`	识别写入成本
`is_batch`	`true/false`	区分离线任务和同步体验
`retry_count`	`0`, `1`, `2`	找出网络、限速和模板问题
`provider_status`	`200`, `429`, `529`	判断失败成本来源
`charged_units`	`1 summary`, `3 credits`	对外计费单位

成本看板不要只给总账单。至少每周看四张表：用户成本排行、功能成本排行、模型成本排行、失败重试排行。只要某一张表突然集中到一个用户或一个功能，就先加配额和告警，再谈降模型。

prompt caching 什么时候能救毛利？

缓存适合重复前缀，不适合每次都变化的短请求。Anthropic 文档里，prompt caching 可以覆盖 tools、system、messages 的完整前缀，并把 token 分成 cache creation、cache read、普通 input 三类。

适合缓存的内容：

长系统提示词、输出格式和安全规则。
稳定的 tool schema。
同一个 workspace 反复使用的文档前缀。
多轮 Agent 工作流里的固定上下文。

不适合缓存的内容：

用户每次随手输入的短问题。
每次召回都不同的 RAG 片段。
还在频繁改的 prompt 模板。
命中率无法按 workspace 稳定复现的内容。

定价上要保守，按无缓存成本能活来设计套餐，再把稳定命中率视为额外毛利。把缓存收益写进价格承诺，会让一次 prompt 改版变成一次毛利事故。

Batch jobs 应该放进同一张毛利表吗？

要放进同一张表，但不能和同步请求混在同一行。Batch 更像后台生产任务：便宜、慢、可重跑，也更依赖队列、状态机和失败回补。

适合进 Batch 的任务：

任务	用户是否等待	成本处理
夜间摘要	不等待	低优先级队列，单独预算
批量分类	不等待	按 job 计成本，失败行单独重跑
历史数据重算	不等待	放低峰期，设置日预算
聊天回复	正在等待	不进 Batch，走同步或短异步
付款后首屏生成	正在等待	不进 Batch，避免体验断裂

产品上要给用户一个人能理解的状态：已接收、排队中、处理中、完成、部分失败、失败。后台再保留供应商原始状态和 batch id。

用户 tiers 怎么约束毛利？

AI SaaS 不适合真正的无限量。更稳的结构是每一档都有成本上限，超出后升级、降速或购买用量包。

套餐层级	成本护栏	适合放的模型策略
Free	邮箱验证、低月额度、日限速、禁止批量导入	小模型、短输出、无 Batch 优先级
Starter	月请求数或任务数上限、超额提示	主力模型 + 输出长度限制
Pro	更高额度、workspace 级预算、可购买用量包	主力模型 + 缓存 + 少量高阶模型
Team	seat + 用量池、预算告警、管理员报表	模型路由、Batch 优先级、审计日志
Enterprise	合同额度、单独限额、人工支持	可谈私有折扣和 SLA

定价时不要把内部 token 直接丢给普通用户。开发者工具可以显示 token，业务用户更容易理解「文档页数」「摘要次数」「项目额度」「团队用量池」。内部照样按 token 算，外部用用户懂的单位卖。

滥用和重试为什么是毛利问题？

免费额度、失败重试和爬虫调用不是安全团队的边角料，它们会直接打穿 COGS。尤其是 Agent 类产品，一次用户点击可能触发检索、工具调用、模型调用和回写，多重试两次就不是小数。

基础护栏要早于增长投放：

每用户、每 workspace、每 IP 维度的日预算。
免费用户限制并发、长文档和高价模型。
失败重试使用指数退避，并设置最大重试次数。
高成本动作前给用户确认，例如全库重算或超长文档分析。
输出 token 设置上限，允许用户手动继续，而不是默认生成到最大值。
异常用量触发软停机：暂停高成本功能，保留登录和账单页。

这些规则会牺牲一点转化，但能换来可预测毛利。早期产品最怕的不是用户少，而是少数异常用户把每月现金流吃掉。

relay/proxy 什么时候只是 ops 变量？

如果你做的是终端 AI SaaS，用户买的是结果，不是 token。relay/proxy 只是后端通道变量，应该写进成本表，而不是写进价值主张。

可以这样建模：

实际 API 成本 = 官方模型价 × 通道倍率
  + 通道导致的失败重试成本
  + 账单差异和人工比对成本

评估一个通道只看四件事：错误码是否透明、token 明细能否导出、是否支持你需要的缓存/批处理/流式能力、故障时能不能快速切回。它如果只是便宜，但让你看不到每个用户的真实用量，长期会伤害毛利模型。

换通道不会修复错误定价。9 套餐没有额度、免费用户能跑高价模型、Batch 没有日预算，这些问题不会因为 endpoint 变化而消失。

价格护栏怎么写进上线清单？

上线前给自己一张红线表：

护栏	触发线	动作
单用户月模型成本	超过套餐收入的 30%	限速、提示升级或购买用量包
workspace 月成本	超过团队预算 80%	管理员邮件和站内提醒
失败重试率	单功能一周超过 5%	暂停自动重试，排查错误码
cache hit rate	连续两周低于预期	取消缓存收益假设，重算套餐
Batch backlog	快到承诺完成时间	提高付费任务优先级
免费额度消耗	单日异常集中	加验证码、邮箱验证或人工审核

真正可运营的 AI SaaS 毛利模型，不是一次 Excel 测算，而是产品里的配额、日志、告警和价格页一起工作，把每个 token 归到用户、功能和任务，再决定要涨价、降模型、开缓存、上 Batch，还是调整套餐限制。