跳转到主要内容

经营 API 封装业务?为什么在上加价模式下上游 API 账单属于 COGS——以及供应商涨价时你的利润率会怎样

发布日期 阅读需 2 分钟Mike ThriftMike Thrift
经营 API 封装业务?为什么在上加价模式下上游 API 账单属于 COGS——以及供应商涨价时你的利润率会怎样
本页总览

你的仪表盘说毛利率是 81%。你的银行账户不同意。在你六个月前写的定价页面和今早到账的供应商发票之间的某个地方,算术变了:一个重度用户发现了你的产品,上游模型重新定价了,或者两件事发生在同一周。如果你卖的是建立在别人 API 之上的产品——一个 AI 功能、一条消息流、一次数据增强、一个结账流程——你最重要的成本是一张你无法控制的账单,而你的账本需要在它那样对待你之前,先这样对待它。

这是一份关于诚实地记录 API 封装业务的指南:为什么上游发票是销货成本,什么时候会计准则说你的"收入"只是你的加价,重新定价那天你的利润率究竟会发生什么,以及四种防御措施,让一次供应商公告不至于吃掉你一个季度。

一段话说清加价模式​

API 封装业务以批发价买入按量计费的输入,再以零售价卖出成品。供应商按 token、按分钟、按查询次数或按消息向你收费;你向客户收取订阅费、按席位费、用量积分,或者你自己加价后的计量表。你的毛利润就是这两个计量表之间的差价,而你整个业务就是押注这个差价在每个客户的使用水平上都能保持为正。

代理机构和封装服务商会落到几种定价形态上:按单位透传加价、带用量上限的固定预付费、基础费加超量的混合模式,或按交付结果计价的成果定价。每一种本质上都是伪装起来的加价模式,因为每一种都用你事先设定的客户价格来支付一张可变的上游账单。你忘记上游计量表存在的那一刻——固定不限量套餐是经典方式——你就等于给客户开了一张从你的供应商账户兑现的空白支票。

为什么上游账单是 COGS,而不是间接费用​

供应商发票在你的账本里落在哪里,决定了你的毛利率是否说真话。判断标准很简单:这项成本是否随服务客户而增减?如果多上一个客户,或一个客户把产品用量翻倍,都会让这张账单变大,那它就是交付产品的直接成本。那就是销货成本。

面向软件企业的行业 COGS 指南明确说了这一点:生产环境托管、支付处理、支持,以及产品所依赖的第三方 API,全都位于毛利线之上。为付费客户提供服务的推理和 API 费用是 COGS,仅此而已。你的封装业务没有上游调用就无法交付一单位价值,所以客户消耗的每个 token、每分钟、每次查询,都是一单位收入成本。

间接费用是没人使用任何东西时你也要付的钱。 房租、营销、开发下季度功能的工程师、你自己的薪水——这些是运营费用,因为它们不随使用量变动。对任何模棱两可的科目提这个挑战性问题:如果每个客户都暂停一个月,这张账单会归零吗?用量计量表会。固定的平台费或预留容量承诺不会,这就是为什么很多商家把供应商发票拆成按量计费的可变 COGS 和承诺容量的固定 COGS——两者都在毛利线之上,分开跟踪,让单位经济保持干净。

错误分类会撒两次谎。 把 API 账单扔进间接费用,你的毛利率看起来就像经典 SaaS——75% 到 85%——而运营费用悄悄吸收了每个客户行为的成本。这美化了投资者用来做基准的那个数字,而 AI 原生企业并不活在那里:把推理算进 COGS 后,它们集中在 40% 到 60% 的毛利率。更糟的是,这个谎言掩盖了你的定价底线。相信 80% 这个数字的创始人以为还有空间给批量折扣;看到真实 50% 的创始人清楚知道在每个新客户开始亏钱之前价格最多能降多少。第二个创始人能挺过第一个企业单。

总额还是净额?藏在你收入行里的 ASC 606 问题​

这是大多数封装服务商从不问的会计问题:上游成本到底算不算费用,还是它根本不该出现在你的利润表上?根据 ASC 606,答案取决于一个词——控制权。如果你在服务转移给客户之前控制了该服务,你就是主要责任人(principal):你把客户付款全额确认为收入(总额),并把供应商账单记为 COGS。如果你只是安排别人提供服务,你就是代理人(agent):你只把自己的费用或加价确认为收入(净额),透传部分通过资产负债表科目流转。

控制权的判断指标是实际的,不是哲学的。客户价格是你定还是供应商定?你是否处理支持并在服务失败时承担责任?你是否承担库存风险——无论客户用不用都要付的承诺容量?一个有自己定价、自己支持队列和承诺供应商支出的封装服务商看起来像主要责任人,按总额报告。一个薄透传、按供应商价格转发请求并收取固定促成费的服务商开始看起来像代理人,代理人按净额报告。

为什么这在你大到需要审计之前就重要。 总额报告抬高顶线收入、压缩利润率百分比;净额报告显示更小的收入但高得多的利润率。两者都不"更好"——但发现你选错了的投资者、贷款人和收购方会重述你的数字,而被重述的增长故事正是交易失败的方式。如果你的产品确实很薄——请求进、响应出、定价接近供应商自己的计量表——问问你的会计师你记的收入是不是你从未控制过的。在第一年修正政策,比在第三年解释一次重述要便宜得多。

供应商涨价的那一天​

供应商重新定价不是假设;它是 API 经济的背景节奏。2025 年 10 月到 2026 年 10 月之间,在追踪的 14 个模型层级中有 10 个的每 token 标价上涨,供应商把涨价与能力声明挂钩——每个新旗舰每 token 都比上一个贵,因为每 token 做更多事。旗舰定价甚至在同一个世代内来了个 U 型转弯:在多年大幅下降之后,顶级通用模型现在的成本是前代的数倍。而且涨价并不总是以新闻稿的形式到来;有时它们以日历日期的形式到来,比如某大型供应商在 12 月 1 日把某个模型的 API 费率翻倍,提前几周在客户永远不会读的更新日志里宣布。

与此同时,你的客户价格从不自己重新定价。你承诺的任何东西——每席位 $29、每套餐 $49、每积分 $0.10——都是合同、定价页面和预期。你在签约时建模的差价,就是你要出资维持的差价,直到你改变它,而三股力量同时从两侧挤压它。

固定套餐遇上重度用户。 一个不限量套餐上的重度用户可能产生普通用户十倍的上游成本——从业者报告单个席位在 $29 订阅下烧掉数百美元的推理费用。一位数据 SaaS 创始人的经验法则:按每用户每月 $49 预算 20,000 次调用,纸面上利润率看起来像 59%,直到一个客户周末跑了个回填脚本,在周一站会之前烧掉六个月的利润。平均值会撒谎;分布才开出账单。

聚合商遇上高峰定价。 2026 年 10 月,一家固定费率 AI 订阅聚合商在高峰 API 定价和重度 token 消耗击穿其固定套餐经济性之后,将用户在一个热门模型上的配额削减了最多 75%——一个在 $10 套餐下烧掉 $60 透传积分的订阅者,就是平台每月要补的 $50 赤字。配额削减就是当你无法重新定价时重新定价的样子:供应商的计量表继续跑,于是产品缩水。客户体验到的就是同样的钱买到更差的产品,因为事实如此。

技术栈分层重新定价。 你的封装服务很少只依赖一个计量表。语音、推理、存储、投递和支付通道各自单独计费,各自按自己的时间表重新定价。你最常用的输入涨 20%,可能比你几乎不碰的输入翻倍抹掉更多利润。如果你说不出哪个上游科目是你每客户最大的成本,你会从发票上学到,那是最贵的老师。

四种让差价保持为正的防御措施​

你无法阻止供应商重新定价。你可以建立一个让重新定价成为例行事件而非紧急状况的业务。四种做法,按杠杆大小排序:

1. 按单位、按客户、按模型跟踪利润率。 汇总 COGS 告诉你上个月很糟;按单位跟踪告诉你为什么糟、是谁的错。记录每个客户和每个供应商计量表的上游成本——按模型记录 token、按方向记录分钟、按端点记录查询——并每月审查利润率最差的客户。转售平台很早就学到了这一点:一旦目录混合了缓存和未缓存 token、批量和实时费率,或协商价和标价,单一混合加价就会崩掉。如果你的账本产不出每客户成本,你的定价就是穿着电子表格外衣的猜测。纯文本账本让起步很便宜:给每条供应商发票行按客户群打标签,利润率报告就是一次查询,文档会一步步带你走一遍。

2. 通过用量透传计费,加上加价——而不是绕开它。 透传计费按每个客户的实际消耗比例收取你的 API 成本,再加上你的平台费或百分比。客户的账单随供应商的计量表变动,所以重度用户为自己的重度买单,供应商涨价流向客户发票而不是你的利润。对可变输入的纯固定费率定价是会失败的结构;解决办法是计量超量、会耗尽的积分包,或基础费加用量的混合套餐。注意会计在这里跟随经济实质:你的价格越紧跟供应商的计量表,你就越应该和会计师仔细重审上面的主要责任人对代理人的问题。

3. 在合同里封住下行风险。 每个固定或捆绑价格都需要一道围栏:包含的用量额度、带数字牙齿的公平使用条款、在触发前公布的超量费率,以及允许你在底层供应商费率变化时调整价格的条款。30 天价格变更通知条款正是因此成为代理合同的标准条款。谈判重新定价权的时机是签约时,客户想要你的产品——而不是续约时,那时他们有筹码而你有一张发票。

4. 绕开昂贵的计量表。 多模型路由、缓存、批量端点,以及用更小的模型处理简单任务,能在不碰你价格的情况下削减每次客户行为的上游成本。缓存的输入 token 成本可能只有新鲜 token 的十分之一;批量 API 以大幅折扣换取你通常负担得起的延迟。把推理效率当作一个有负责人和月度目标的利润杠杆,就像餐厅对待食材成本一样。当供应商宣布涨价时,已经建好路由的团队从强势地位谈判;其他所有人从发票谈判。

如何记账:封装业务的一个月生活​

假设你经营一个小封装业务:11 月订阅收入 $4,900,10 月用量的上游推理发票 $2,100,支付处理费大约 3%。这个月的账本看起来是这样:

2026-01-01 open Assets:Checking:Operating USD
2026-01-01 open Income:Subscriptions:Wrapper USD
2026-01-01 open Expenses:COGS:Upstream-API USD
2026-01-01 open Expenses:Fees:Payment-Processing USD
2026-01-01 open Liabilities:Provider-Payable USD
 
2026-11-01 * "November plan revenue" "Customer subscriptions"
  Assets:Checking:Operating  4900.00 USD
  Income:Subscriptions:Wrapper  -4900.00 USD
 
2026-11-05 * "Upstream inference bill" "October provider invoice"
  Expenses:COGS:Upstream-API  2100.00 USD
  Liabilities:Provider-Payable  -2100.00 USD
 
2026-11-05 * "Payment processing" "November processor fees"
  Expenses:Fees:Payment-Processing  147.00 USD
  Assets:Checking:Operating  -147.00 USD

有两点值得注意。第一,供应商发票记入 Expenses:COGS:Upstream-API,在毛利线之上——11 月毛利润是 $4,900 减去 $2,100,57% 的利润率,说出了推理业务的真相。第二,发票记入应付账款,而不是直接从支票账户支出:你会按供应商的条款(通常月中)付款,而客户在签约时就付给了你,应付账款让这个时间差可见,而不是让瞥一眼银行余额就假装现金全是你的。

从这里开始,每月例行公事是三个查询:含供应商科目和不含供应商科目的毛利率、每活跃客户成本对照套餐价格,以及利润率最差的五个客户。在 Fava 这样的仪表盘里看趋势,压缩的差价会在变成危机之前几周就显现为一条斜线。看到斜线的创始人会提高超量费率、收紧上限,或路由到更便宜的模型。把一切都记成间接费用的创始人会看到 80% 的利润率,一直看到钱花光的那一个季度——而且永远不明白发生了什么。

来源:https://beancount.io/zh/blog/2026/11/09/api-wrapper-upstream-api-bill-cogs-markup-model-margin-guide

发布日期: 2026年11月9日