一位经营 AI 写作助手的创始人告诉我，他的"软件成本"是每月 $40,000。当我们拆解这个数字时，其中 $34,000 是 OpenAI 和 Anthropic 的 API 账单——但这部分完全没有计入他的销货成本。它被塞进了一个笼统的"软件与订阅"科目里，紧挨着他那个每月 $19 的项目管理工具。他对外报告的毛利率是 91%。而在把推理成本放回它该在的位置之后，他真实的毛利率其实只有 58%。
这不只是记账上的技术性问题。它是"看起来像软件公司"和"实际运作方式像工厂"之间的区别——工厂里每卖出一件产品都会消耗真实的、可变的投入。如果你是在 GPT-5、Claude、Gemini 或任何托管模型之上构建产品，你的 LLM 账单就不是运营开支，而是销货成本；如果不这样处理，你其实并不知道自己到底赚了多少钱。
为什么这个错误如此容易发生
传统 SaaS 让一代创始人习惯于把软件成本当作固定成本来看待。你为托管付费，为 CRM 付费，为 Slack 付费——这些账单都不会随着某个客户对产品的使用量而同步变动。所以当第一张来自 OpenAI 的账单出现时，很自然地会把它归入同一个心理账户："我们为运营这家公司而支付的工具费用"。
问题在于，LLM API 账单的行为方式和 SaaS 订阅完全不同。它的行为更像原材料。每当客户发送一次提示词，你就会消耗 token，而每个 token 都有价格。一个每天发出 50 次请求的客户，服务成本要显著高于一个每天只发 2 次请求的客户。这正是销货成本的教科书定义：一种随着产品交付给特定客户而直接扩张的成本，而不是无论使用量多少、你为了维持公司运转都要支付的成本。
行业数据印证了这一点变得多么重要。ICONIQ 2026 年 1 月发布的《AI 状态报告》发现，在处于规模化阶段的 AI B2B 公司中，推理成本目前平均占总收入的 23%，而 84% 的公司报告称，毛利率因 AI 基础设施成本而直接被侵蚀了 6 个百分点或更多。这不是一个可以被归入"其他运营支出"就消化掉的舍入误差，它往往是公司里单一最大的成本驱动因素，理应被当作一项独立成本来对待。
正确划分销货成本与运营开支的界限
区分销货成本与运营开支的原则，并不会因为投入品从一仓库的零件变成了模型 API 而有所改变：用于把产品交付给付费客户的成本属于销货成本；用于构建产品本身的成本属于研发（计入运营开支）。 应用到一个 AI 套壳产品上，这个划分大致如下：
属于销货成本：
- 生产环境推理成本 —— 你上线产品代表付费客户发起的每一次 API 调用，无论是一次对话补全、一次嵌入调用、一次分类任务，还是一个 agent 的工具调用循环
- 模型托管 / GPU 算力 —— 如果你是在自有或租用的基础设施上运行开放权重模型，而不是调用托管 API，那么用于服务客户请求的这部分算力时间
- 配套的推理基础设施 —— 专门为服务生产请求而存在的向量数据库查询、嵌入流水线运行和编排开销
- AI 专属的支持成本 —— 一位专职为客户排查模型输出问题的支持工程师，其成本属于交付产品的成本，而不是笼统的 SG&A（销售、总务与管理费用）
属于运营开支（通常是研发）：
- 开发与测试阶段的推理调用 —— 工程师在迭代功能、调试回归问题或评估新模型版本时发出的每一次提示词
- 微调与评估运行 —— 构建或改进模型本身属于研发，而不是交付
- 内部 AI 工具 —— 团队使用的 ChatGPT Enterprise 席位或 GitHub Copilot 许可证，是一项生产力支出，而不是服务客户的成本
让这种划分真正可执行的关键做法枯燥却至关重要：从第一天起，就为生产环境和开发环境流量使用不同的 API key 或计费项目。 如果你的工程师是用产品在生产环境中使用的同一个 key 去测试提示词，你事后就没有办法准确地分摊这笔账单，每个月你的真实毛利率不是被高估就是被低估。
AI 产品的"真实"毛利率是什么样子
一旦完成这种划分，得出的数字很可能和你过去习惯看到的不一样。传统 SaaS 公司几乎理所当然地把 70–80% 的毛利率当作目标。AI 原生产品做不到用同样的方式达到那个水平。Bessemer Venture Partners 2026 年 2 月发布的定价指南显示，典型 AI 产品的毛利率为 50–60%，远低于传统 SaaS 常见的 80–90% 区间；而 ICONIQ 的数据显示，行业平均的 AI 产品毛利率正在攀升——但也只是升到了 52%，相比 2024 年的 41% 和 2025 年的 45% 有所提高。
从密切管理这件事的运营者身上总结出的一条实用经验法则是：如果你想要一个可持续、可扩展的商业模式，把 LLM 成本控制在总销货成本的 20% 左右以内。 一旦越过这个门槛，毛利率的压缩往往会随着规模增长而加速，而不是缓解，因为大客户只会更多地使用产品，而不是更少。一些 AI 密集型品类——比如编程助手、文档处理 agent——LLM 成本占销货成本的比例达到 30–40% 依然可以维持可行，但那是因为它们围绕这一现实刻意做了定价，而不是被动地承受结果。
真正重要的数字不是你公司整体的混合毛利率，而是每个客户的成本。同样订阅档位下，一个 AI 功能的重度用户在原始推理上的服务成本，可能是轻度用户的 50 到 100 倍。如果你没有追踪这一点，你就不知道哪些客户是盈利的，又在每个月悄悄补贴哪些客户。一个在最初十个客户身上看起来没问题的统一定价套餐，一旦其中一个客户把某个工作流推上生产环境、把请求量放大 20 倍，就可能立刻开始亏钱。
构建单次请求成本模型
你不需要一开始就上复杂的工具——你需要的是在每次请求中都严格记录正确数字的纪律。核心公式很简单：
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_million按单位计算，输出 token 的成本通常是输入 token 的 2–5 倍，因为生成过程比读取提示词更消耗算力——所以一个只统计 token 总数、不区分输入与输出的请求成本模型，会系统性地为任何长回复内容定价错误。举一个 2026 年年中价格水平下的实际例子：一次包含 2,000 个输入 token、500 个 token 回复的请求，针对一个主流中端模型（输入约 $3、输出约 $15，每百万 token），成本大约是 $0.0135。把同样形态的请求每月运行 50,000 次，这一单项功能的推理成本大约是 $675——如果它被埋在一个五位数的"云成本"科目里，这笔钱是看不见的，但一旦按功能和产生它的客户细分打上标签，它就会变得非常显眼。
要让这一切真正落地：
- 记录每次请求的 token 数量，而不只是成本——大多数模型提供商本身就会在 API 响应中返回输入/输出 token 数，所以这只是一个日志记录上的改动，而不需要新的数据来源。
- 为每次请求打上客户 ID 和功能标识，这样你就能按账户、按产品功能维度汇总成本，而不只是按月汇总。
- 计算每个客户在每个计费周期内的成本，并与该客户向你支付的金额做对比。这个数字会告诉你，你的定价档位是否真的匹配你的交付成本，而不是你笼统的平均毛利率。
- 在质量允许的情况下，把请求路由到更便宜的模型。 不是每个请求都需要用你能力最强（也最贵）的模型——分类、抽取和简单的格式化任务，往往用一个更小、更便宜的模型也能有可接受的表现；而模型路由是你能完全掌控的少数几个利润杠杆之一，这一点和你无法掌控的供应商定价不同。
用定价保护你刚刚找回的利润
一旦推理被正确归类为销货成本，你关于定价的讨论方式就会改变。运营者常用的一个定价锚点，是按单位 token 成本的大约 3–5 倍来收费，让一个成本 $0.30 的任务定价在 $1.00 或更高——这个倍数并不是什么魔法数字，而是因为它留出了空间去吸收使用量波动、模型价格波动，以及伴随原始推理而来的支持与基础设施成本。
按使用量计费已经成为 AI 公司让定价与销货成本保持同步的标准做法：按 token、按请求或按完成的任务收费，你的收入就会随着驱动你成本的同一个变量一起扩张，而不会像统一订阅制那样，在用量激增时和成本渐行渐远。如果你还没准备好完全转向按使用量计费，至少也要搭建"承诺最低消费 + 超量费用"的档位结构，这样一个用量远超典型水平的客户，就不会在当月剩余时间里悄悄变成一个亏本引流品。
让你的成本结构像代码一样可审计
这一切都不是可有可无的记账习惯——区别在于：你是清楚地知道自己的商业模式是否成立，还是要等到融资尽调电话里，投资人的分析师帮你搭出了那个你本该在六个月前就建好的按客户成本模型，才发现它不成立。能避开那种局面的创始人，是从第一次 API 调用起就把推理成本打上客户和功能标签的人，而不是等到 OpenAI 账单大到无法忽视才后知后觉的人。
Beancount.io 为你提供纯文本、版本控制的记账方式，让你可以轻松地把推理支出打上正确的科目标签、区分生产环境与开发环境的 API 使用量，并且每个月都能把你真实的销货成本与收入对账——没有黑箱分类，也没有供应商锁定。免费开始使用，看看为什么开发者和 AI 原生创始人正在转向纯文本记账。