AI SaaS Metrics Token Costs: 7个基准拆解 LLM 毛利率与定价

本文由 Huifer 撰写

2024 年至 2026 年间，我上线了三款 LLM 产品，并眼睁睁看着我们在 GPT-4o 输出 Token 让 COGS 直接翻倍时，单季的毛利率从 82% 暴跌至 41%。在一个 1.24 万美元 MRR 的同期群（cohort）中，Token 支出在 31 天内达到了 4,870 美元——占收入的 39%——直到我们加入了 Prompt 缓存和更便宜的路由器。这篇拆解帖是我现在每次调整定价前都会运行的检查清单。

验证来源： OpenAI API Pricing，Anthropic Pricing，Google AI pricing，Vertex AI generative pricing，AWS Bedrock pricing，OpenAI prompt caching，Anthropic prompt caching，OpenAI tokenizer，Stripe usage-based billing，Stripe billing meters。

最后更新： 2026-05-06

更新日志： 2026-05-06 — 包含 OpenAI、Anthropic、Google Gemini 和 AWS Bedrock 目录价的初版 7 点拆解；新增了缓存和计量公式。

利益披露： 这是一篇独立评论，没有任何分销链接，也与文中提到的任何供应商没有实质性关联。

总结 (TL;DR)

请将 ai saas metrics token costs 视为 COGS（销货成本），而不是“研发云成本”，否则你的毛利率只是在自欺欺人。

在扣除模型支出后，目标是实现 70%+ 的用量毛利率；低于 55%，你的产品就只是个科研项目。

输出 Token 和 Agent 循环是支出的主力；缓存命中率和模型路由，是让我们将毛利率从 41% 提升回 72% 的两个杠杆。

为**结果或积分（credit）**定价，绝对不要直接为原始 Token 定价，然后在内部按照该价格来计量 Token 用量。

开出账单前监控并记录每一次请求；带 Stripe 计量器的模板（参见 TanStack Ship pricing）比自建账本更快落地。

如果你销售调用大语言模型的软件，ai saas metrics token costs 就不再是月末才需要核对的账目了。它们就是产品本身。经典的 B2B SaaS 的目标是 75–85% 的毛利率，因为 COGS 是托管和支持。LLM 产品颠覆了这一点：一次冗长的补全，就可能抹掉一个月的席位收入。本文对 Token 成本、毛利率和定价进行了 7 个基准的拆解，好让你能在发布 LLM 产品时依然保持盈利。

我不会向你推销虚幻的“AI wrapper（套壳）”估值倍数。我将向你展示我希望在那个亏掉 4,870 美元的月份出现之前就做过的算术题。

为什么 AI SaaS Metrics Token Costs 会打破经典 SaaS 毛利率

按席位计费的 SaaS 将可变成本隐藏在了丰厚的订阅费背后。多一次登录几乎不会影响 AWS 的账单。但在 GPT-4o 级别的模型上，多发一条聊天消息的成本可能比席位费还高。这就是为什么必须将 ai saas metrics token costs 与 MRR 放在同一个数据看板上，而不是留在数据科学家的笔记本里。

70% SaaS 毛利率的迷思与 LLM COGS

Bessemer 式的云指标假设软件的 COGS 为 15–25%。而 LLM 的 COGS 是一个函数：（输入 Token × 输入价格）+（输出 Token × 输出价格）+ 缓存 + 嵌入（embeddings） + 工具往返调用。在 OpenAI 的公开价格表上，4o 级别的模型每百万个输入 Token 依然收费数美元，输出的收费则是前者的数倍。Anthropic 和 Gemini 也采用了同样的定价模式：输出是昂贵的一端。如果你的应用搭配 2,000 个 Token 的系统 Prompt，还能源源不断地生成 1,200 个 Token 的回答，那么你根本不是一家具有 80% 毛利的 SaaS 公司。在更改 Prompt、更换模型或调整价格之前，你只是别人 GPU 的转销商。

我现在拒绝上线任何在模型成本上超过其预期附带收入 30% 的功能。仅仅这一条规则，就毙掉了两个在 Figma 里看起来非常炫酷的“神奇 Agent（magic agent）”增值服务。

输入 Token、输出 Token 与缓存 Token

要计算三个存储桶，而不是一个。输入包含了 Prompt、检索内容（chunks）、工具返回结果和对话历史。输出则是补全结果，以及任何你通过 JSON 模式强制转储的结构化数据。缓存的输入——参见 OpenAI prompt caching 和 Anthropic prompt caching——是唯一一个随着我们的产品变得更聪明而成本下降的桶。我们固定了一个 1,800 Token 的策略前言（policy preamble），并看着重复活跃租户的缓存命中率攀升到了 61%。对于那个同期群（cohort），混合输入成本大约下降了一半。如果你没有从供应商的响应中记录 cached_tokens，那么你的单位经济学模型就全靠猜了。

在暂存环境（staging）中，请使用 OpenAI tokenizer（或各供应商在 usage 对象里的计数值）。绝对不要在生产计费中用 单词数 × 1.3 来估算 Token 数。输出哪怕偏差 15%，带来的也是 68% 和 52% 毛利率的天壤之别。

隐性成本：嵌入（embeddings）、重试与工具调用

让我吃惊的账单从来都不是聊天自动补全。而是 RAG 管道：写入时需要嵌入，分块器（chunker）变更时需要重新嵌入，每个“Agent”回合还需要进行三次工具调用，并在 JSON 解析失败时发起重试。在 Vertex 和 OpenAI 上，百万个嵌入调用的价格非常便宜，但在 4,000 万个 chunk 这个量级上就不再是免费的了。工具调用使得输出 Token 数成倍增加，因为模型会叙述、调用，然后再叙述一遍。重试则让昂贵的那部分成本直接翻倍。我现在将成本归因到了 feature 和 attempt，这样一来，一个不稳定的提取器就无法再藏身于“AI COGS”之中了。

Bedrock 客户也会遭遇同样的数学规律，只是标签不同罢了；AWS Bedrock pricing 仍然会按模型分别对输入和输出进行计费。货比三家挑选一下路由器吧，不要指望云服务商的折扣能拯救一个糟糕的 Prompt。

AI SaaS Metrics Token Costs 的 7 点拆解

在你发布定价页面之前，请务必先过一遍这 7 个数字。我习惯把它们放在同一个查询和同一个电子表格标签里。如果其中有任何一个单元格是空的，就说明该功能尚未定价。

基准 1 —— 每次成功请求的混合 Token 成本

成功意味着用户获得了他们所付费的结果（artifact），而不是指 HTTP 调用返回了 200 状态码。失败的请求依然会消耗 Token。公式如下：

cost = (fresh_input × pin + cached_input × pcache + output × pout) / 1e6

Pin、pcache 和 pout 分别来自该模型的供应商目录价，而不是某篇博客文章里的截图。在你发布上线的那一周，去重新读一遍 OpenAI、Anthropic、Google AI 和 Bedrock 上的价格，因为目录价会变动，而你的毛利率也会随之波动。

typescript

type TokenUsage = {
  model: string;
  inputTokens: number;
  outputTokens: number;
  cachedInputTokens?: number;
};

const PRICE_PER_MILLION: Record<
  string,
  { in: number; out: number; cachedIn?: number }
> = {
  "gpt-4o": { in: 2.5, out: 10, cachedIn: 1.25 },
  "gpt-4o-mini": { in: 0.15, out: 0.6, cachedIn: 0.075 },
  "claude-3-5-sonnet": { in: 3, out: 15, cachedIn: 0.3 },
};

export function tokenCostUsd(u: TokenUsage): number {
  const p = PRICE_PER_MILLION[u.model];
  if (!p) throw new Error(`unknown model ${u.model}`);
  const cached = u.cachedInputTokens ?? 0;
  const fresh = Math.max(0, u.inputTokens - cached);
  const cachedRate = p.cachedIn ?? p.in;
  return (fresh * p.in + cached * cachedRate + u.outputTokens * p.out) / 1_000_000;
}

export function grossMargin(revenueUsd: number, cogsUsd: number): number {
  if (revenueUsd <= 0) return 0;
  return (revenueUsd - cogsUsd) / revenueUsd;
}

在我们 1.24 万美元 MRR 的同期群（cohort）中，每次成功“起草”的混合成本在有缓存之前是 0.041 美元，缓存后是 0.018 美元。我把这个数字贴到了定价卡上，而不是去计算 Token 数量。

基准 2 —— 扣除模型 COGS 后的毛利率

这里的毛利率等于 (usage_revenue − model_cogs) / usage_revenue。千万不要用员工薪水来稀释它。如果你以 29 美元的价格出售了一个号称“无限量使用 AI”的席位，那就不存在 usage_revenue 了；你把整个席位的利润都搭了进去。我们将该方案调整到了 200 积分，立刻就看清了谁才是超级用户（power user）。在五周内，我们的用量毛利率从 41% 攀升到了 67%，因为那一小撮长尾的重度用户开始付费了。我再也不会卖包含无限次对话的 LLM 席位了。所谓“无限量”，就等于亲自将你们公司的资金跑道拱手送给模型供应商。

正常该有的下限是：中位数租户要实现 70% 的用量毛利率，P95 租户则要有 55%。如果 P95 租户的毛利率低于 40%，那就加一个硬性上限或者推销一个更高阶的积分包。P95 租户往往是产生 Agent 循环的地方。

基准 3 —— 扣除 GPU、向量库及可观测性工具后的贡献利润率

模型 COGS 并不是唯一的可变成本。必须加上向量存储（vector storage）、评估追踪（eval traces）、日志存储量以及任何专属的推理服务。贡献利润率等于 usage_revenue 减去（模型 + 向量库 + 追踪 + 出网流量）。可观测性工具吓了我们一跳：按每次调用 8k Token 计算，仅仅记录冗长的 Prompt 日志的内容，就占了整块 AI 支出的 9%。你可以采用记录样本（sample）、哈希值或存储异同（diffs）的方式。在这方面，自带多租户隔离特性的单薄 feature set，往往能秒杀一堆一次性调用的 Lambdas ——你总归需要找个统一的地方来给每个租户打上成本标签。

基准 4–7 —— 附加率、回本周期、积分消耗与价格围栏

基准 4 是指附加率（attach rate）：即 14 天内消耗了任意数量 AI 积分的付费席位占比。如果低于 30%，那你定价的就仅仅是一个博眼球的奇技淫巧。基准 5 是附赠积分的回本周期：包含在套餐里的 COGS 应当在开出的第一张发票里收回，而不是第三张。基准 6 是指积分消耗速度：每一个活跃日的积分消耗中位数。如果它的消耗呈现出多刺的峰值，那你需要加上异常封顶（请参见下文）。基准 7 是价格围栏：提供一个用来起草的廉价模型、将更昂贵的模型藏在开关后面，并设定每日消耗的硬性上限。围栏才是我们在不惹恼超级用户的情况下将 P95 毛利率维持在 55% 以上的诀窍所在。

所有这 7 点正好塞进一个数据看板里。如果你现在使用的模板项目（boilerplate）无法向 Stripe 发送携带租户维度信息的用量事件，那你只能苦哈哈地填表格了。这是一个产品问题，而不是财务核算问题。

如何能在不烧钱的前提下给 LLM 产品定价

定价，往往是你手中唯一比模型升级奏效更快的杠杆。我在同一个代码库上针对席位制、纯用量计费以及混合计费进行过测试。不管是回笼的资金还是客户支持工单（support tickets）的表现，混合计费都略胜一筹。

席位制 vs 纯用量 vs 混合定价

席位制非常容易卖，但也很容易让你破产。纯按用量计费（让 Token 成本直接透传给用户）是非常坦诚的，但完全卖不出去；因为买方毫无预期，而且你还会变成一个 UX 体验比 OpenAI 还要烂的复制品。混合计费则是在席位中包含一个额度包（credit bundle），超出部分再单独计费。积分隔离了供应商的具体收费，但你在内部依然要按 Token 计量用量。Stripe usage-based billing 和 billing meters 便是那根计费轨道；你的应用程序必须按时输出相应数量。我把 1 积分 ≈ 1 次成功的“文档操作”进行了对应，此类操作的混合 COGS 大约是 0.02 美元，然后我加价 3–4 倍捆绑出售，这样即使在扣除折损用量后，整体用量毛利率仍能稳定在 70% 左右。

别藏着计量器不让人看。直截了当地把剩余的积分展示在应用里。对于那些看着这个数字的用户，他们的消耗行为会远比那些真以为这是一场魔术的用户理智得多。

Token 加价，还是针对 AI 特性的基于结果定价

粗暴的 Token 加价兜售（“我们比 OpenAI 贵 4 倍”）在销售环节往往会碰壁，这是因为买方根本不以 Token 来思考问题。而基于结果进行定价（“若接受合同条款，每条收 1.50 美元”，“每一单已被分类的工单收 0.20 美元”）直接挂钩到了实际价值上，这也让你能在无需应对价目表争执的情况下自由更换模型。只不过在内部，你依然需要把结果转化回 Token 的计费体系去跑，好让你知道这笔买卖到底亏不亏。当 Claude 的目录价在 Anthropic 的页面上发生变动时，我们的条款单价依然纹丝不动；因为是路由器变阵换将了。这就叫为结果定价。

如果你连结果都无法定义出来，那说明你还没准备好把这个模型产品化。你可以上线某种点数（credit），但绝对不能去卖 Token；因为前者可以定义为你成功完成该任务所需的最小作业量。

护栏：封顶、缓存与模型路由

以下三大护栏在第一个月就轻松赚回了自身的本钱：

每日租户级别封顶。到了上限，应该给对方抛出一个友好的 429 报错加额外推销，而不是用暴涨的账单给人带去惊吓。
为静态前言以及需要经常载入的 Schema 设计 Prompt 缓存；方法就是利用上述供应商提供的那些关于缓存 API 的调用。
一个路由机制：使用 mini/flash/haiku 处理分类或者起草环节，而最终版的内容生产则留给 sonnet/4o-class 上场。

Gemini 和 Vertex 上的 flash 级别模型让廉价通道成为了现实。而 Bedrock 之所以举足轻重，是因为我们有两个需要 VPC 部署落地方案的企业级租户，而不是说它能比别人更便宜。所谓按任务路由，意思是千万别被所谓的品牌忠诚捆绑。当目录价变动时，你必须去重新考量路由——所以给自己设个日程提醒，而不是根据 Slack 里讨论出来的感觉去定夺。

监控仪表盘检查清单：在出账之前就把 Token 计入表中

如果你不能在一个查询之中找出“X 租户昨天花费了多少钱”的答案，那你们现在拥有的不叫 AI SaaS metrics 后台；你们大概只是怀揣着某种希望。务必在数据流开始前计费，在收回厂商提供的 usage 对象之后持久化，并基于相同的事件去计算账单。

用于统计 Token 的事件 Schema

要存储厂商实际记录的用量，而不是你自己的预估值。当你在写入时，记得要把 model、feature、attempt、tokens、cache，及其实时算出的 cost_usd 持久化，这样历史图表就不会因厂商调价而损坏。价格表会变；但在特定事件上留下的快照不可改变。

typescript

export type LlmMeterEvent = {
  tenantId: string;
  requestId: string;
  model: string;
  feature: "chat" | "agent" | "embed" | "eval";
  inputTokens: number;
  outputTokens: number;
  cachedInputTokens: number;
  costUsd: number;
  billedUnits: number;
  at: string;
};

billedUnits 是面向客户的点数或积分（credit）。costUsd 则是你的 COGS。永远不要试图让它们混入同一列。我会在记录工件（artifact）的同一个数据库事务中去派发该事件记录——以防系统崩溃导致有任务漏算计费，或有任务计了费却未入账。

Stripe 计量器与 TanStack Ship 账单钩子

Stripe 所要的无非便是一个承载度量值和客户对应关系的计量事件。而你的职责则是按照与订阅匹配的时间表（按小时执行足矣），把 billedUnits 转换成该值推过去。读一遍 Stripe’s usage-based guide 与 meters 即可，别再搁那重造账单系统了。在我们的技术栈上，与其要在模型账单疯狂暴涨时，火急火燎地在一个处于绿地（greenfield）初始期未完善的 Next.js 项目中连线这种计费管线，我情愿选择一个一上来就已经自带 Auth、租户以及 Stripe 钩子机制的 SaaS 模板。这是我对 TanStack Ship 坦率的推荐：它不会神奇地算出 LLM 毛利率，但它能给你租户和计费的骨架，让这个计量器只是一项 feature，而不是一场重构。如果你在对比各种开发包，带有怀疑眼光去看看 compare page 是有好处的——挑一个在 webhooks 上不会和你作对的开发包即可。

sql

SELECT
  date_trunc('day', at) AS day,
  tenant_id,
  SUM(cost_usd) AS token_cogs,
  SUM(billed_units) * 0.02 AS usage_revenue,
  1 - (SUM(cost_usd) / NULLIF(SUM(billed_units) * 0.02, 0)) AS usage_gross_margin
FROM llm_meter_events
WHERE at >= now() - interval '30 days'
GROUP BY 1, 2
HAVING SUM(cost_usd) / NULLIF(SUM(billed_units) * 0.02, 0) > 0.45;

那个查询语句是 P95 的绊马索。把它定点发送到你自己的邮箱里。别等到供应商发来账单时才后知后觉。

针对失控 Prompt 与 Agent 循环的异常检测

Agent 循环是一夜之间令毛利率跌到 41% 的元凶。限制每次请求的工具往返次数（我们使用了 6）。在 API 调用中限制 output token 的上限，而不是写在服务条款（Terms of Service）段落里。当某个租户不到中午其 cost_usd 就超过过去 7 天中位数的 3 倍时，系统一定要发出警报。我们捕捉到的多数事件都是在 JSON 解析失败时深陷重试泥潭，而不是恶意用户造成的。tokenizer 在这帮不上忙；能救命的是 max_tokens 参数和一个断路器。把断路器放在计费器旁边，而不是放在周末才看的仪表盘里。

如果你正在将这套系统接在身份验证与组织机构旁边，而不是随意写一个一次性脚本，在我们的 blog 中还能找到更多剧本。

常见问答：关于 AI SaaS Metrics Token Costs、毛利率与定价

AI SaaS 目标应该设定为多少毛利率？

我的目标是：对于中位数租户，维持 70% 的用量毛利率；在扣除模型 COGS 后，绝不能容许 P95 租户低于 55%。只有在套餐附带积分极少、缓存命中率非常实在，且对昂贵模型做好防范围栏的前提下，昔日标榜的 80% SaaS 毛利润才有可能重现。如果你把“无限量 GPT-4-class”捆绑进区区 49 美元的席位里，你手里拿的就不是利润目标。你拿着的是一个倒计时炸弹。

我如何将 Token 转换为面向客户的积分单位？

挑选一个最小的成功作业（比如一次起草、一张被分类好的工单、一条带有修改痕迹的协议条款）。计算在一周真实运行环境下（含重试在内）该项作业消耗的混合 Token COGS 成本。将 1 积分的 COGS 占比锚定在其零售价的 25–30% 左右。一定要按包（packs）出售，而不是兜售百万 Token 这样的区块。将 Token 计算保留在内部与事件表上（即区分 costUsd 和 billedUnits）。当 OpenAI 或 Anthropic 目录价变动超过 20% 时，重新校准即可。

我是否应该将模型价格的变更转嫁传递？

应当在同一天就转嫁传递至你的 COGS 数据表中。但除开你卖的是原始 Token，否则千万不要在同一天将变动转交给向客户报出的零售价。基于结果或积分进行定价应伴随着日志更新按季度节奏去推动变局。去利用这份滞后时间差去将请求流转引至底层更为便宜的模型。毕竟已经接受了某个积分点价位的买家们绝不会心平气和地接受 30% 这种意外的 Token 调涨；他们肯定会退订并把应用截图发出来。

TanStack Ship 在用量计费方面有何帮助？

TanStack Ship 不会帮你挑选模型或定好加成比例。它只会为你提供 SaaS 的骨架——包括身份验证、多租户机制以及类 Stripe 的计费体系——所以你只需要上报那些计量事件即可，不需要重新发明订阅模式。如果目前的阻碍在于“我连个能用来挂载 costUsd 的 tenant id 都没有”，那么就从这里开始。如果你的阻力是“我都不知道 token 是个什么玩意儿”，那么上面的这 7 点拆解就是你该干的活；而这个代码模板仅仅是让你在完成工作以后不需要再重写一遍就能上线发布。带着这一层差异去品一品 features 与 pricing 吧。

先发货计量器，再上线产品

AI 的定价并不是幻灯片上的一行字。它是一个计费器、一层利润下限，更是围绕着昂贵模型筑起的防护围栏。我是靠着在一个收入为 1.24 万美元 MRR 却产生出高达 4,870 美元 Token 账单教训里痛领悟出的道理，比起让你重蹈覆辙，我宁愿你在这 7 点拆解里就能看透。针对每个租户精细化追踪 ai saas metrics token costs 数据，为所消耗结果或对应积分信用值去定下一个好价钱，然后如同去落地一项产品硬性的需求指标那般去死抓 70% 的用量毛利率生命线——因为它本身就是你的生死线。

如果你需要一个现成的开箱即用去沟通交流那些有关于多租户和顺畅打通向 Stripe 那套结账环节计费管线的 SaaS 起点框架项目首选，使得能将本周精力留着优化路由或攻坚异常封盖的上限逻辑上而非去编写鉴权 Auth 代码的话，TanStack Ship 正是针对这种痛点我会选用的实战化工具套件。没有推销返利、未收厂商红包，并承诺一个模版代替不了你自身的核心单位经济核算。它不过是将你刚刚拍板设计完成的定价结构赋予上线产出的能力罢了。