如何构建财务可扩展的 AI 产品

100 个用户时的毛利率是一种错觉

早期 AI 产品的账单小到没人会认真看。100 个用户、每人每天 3 次调用，一个月的推理开销可能只有 40 美元，比域名和监控加起来还便宜。这个阶段谁都能报出 90% 的毛利率，因为分母里塞满了还没被激活的固定成本，分子里的可变成本还没长出形状。真正的问题在两年后才浮现：调用量涨到 3000 倍时，账单涨了多少倍。答案取决于你在没人关心成本的那半年里，把哪些结构写进了产品。

要回答这个问题，先得把账单拆成三种形状。线性的那部分最省心：日志、对象存储、出口带宽，每多一个用户加一份固定量，预测误差不会超过 10%。次线性的那部分是向量索引，10 万条向量和 100 万条向量的检索耗时差距远小于 10 倍，索引构建的固定开销摊到人头上反而越摊越薄。超线性的那部分才是杀手：人工审核、事故处理、以及任何被长上下文放大的东西。毛利工程的第一步是把每一项开销归进这三类，只有第三类会在你毫无察觉时把毛利率从 72% 拖到 41%。

把一次调用的成本算清楚

假设一次问答输入 1800 token、输出 400 token，用中档模型，输入每百万 token 3 美元、输出每百万 token 15 美元。单次成本 = 1800 / 100 万 × 3 + 400 / 100 万 × 15 = 0.0054 + 0.006 = 0.0114 美元。看着无所谓。一个中度用户每天 12 次、一个月 360 次，单人月推理成本 4.10 美元。订阅价 19 美元的话，推理已经占掉 21.6%，还没算检索、存储、以及支付通道的 2.9% 加 0.3 美元。

回到那次调用的单价：输入每百万 token 3 美元，输出 15 美元，输出是输入的五倍。可大多数产品在压成本时只盯着输入的提示词，放任模型输出长篇大论。一个把答案包在三段客套话里的回复，和一个直接给结论的回复，质量未必有差，成本却差出一截。让模型输出结构化结果而不是散文（要 JSON 就别要段落，要字段就别要解释）既省 token 又好解析。产品侧能做的是把「请简明作答」写进系统提示、给输出设硬上限、在需要长内容时改成分段生成。压输出的收益通常比压输入大，因为你动的是那个五倍单价的部分。

单次问答的成本好算，多轮对话是另一回事。每多说一轮，产品通常把之前的全部历史再塞回去当上下文，于是第十轮那次调用的输入 token，是把前九轮全带上的。对话越长，每一轮越贵，成本随轮数不是线性而是接近平方地涨。一个用户和客服机器人来回二十轮，最后几轮的单次成本可能是第一轮的十几倍，而这部分完全藏在「一次对话」这个笼统的口径里。控制手段是给上下文设一个滑动窗口，只保留最近若干轮加一份压缩过的早期摘要，而不是把整段历史无脑回传。测一下你的对话轮数分布，长尾那部分长对话往往吃掉了不成比例的推理预算。

没被算进单次成本的那些开销

把单次对话的价签算清楚之后，还有几项开销从不出现在那个数字里，却真实地记在账上。很多产品在主模型之外还挂了一层内容审核或安全护栏：判断输入是否违规、输出能不能放行。这层判断本身也是一次推理调用，成本要算进去，可它几乎从不出现在「单次成本」的估算里。当主调用便宜时，问题尤其明显：主模型用小模型只花 0.001 美元，护栏若用了一个不便宜的模型，可能比主调用还贵，单次成本被悄悄翻倍。对策有两个方向：护栏用专门的小型分类模型而不是通用大模型；对明显安全的短输入做规则前置过滤，只把可疑的那部分送去模型判断。先把这层的成本单独列出来，才知道它到底占了多少。

重试是另一项隐形开销。一次 60 秒超时后的自动重试，付两遍钱却只交付一次结果。假设超时率 4%、重试成功率 80%，实际单次成本要乘以 1.04 再加上 0.8% 的二次重试，等于凭空多出 4.8% 的开销。更贵的是流式输出被用户中途关掉的情况：token 已经生成完并计费，价值归零。测一下你的产品里"生成到一半被放弃"的比例，超过 15% 就该把长输出改成分段确认——先给 200 token 的提纲，用户点继续再生成正文，这一步在报告类产品里能省掉 20% 到 30% 的输出 token。重试的成本还会在高峰被供应商的速率上限放大：请求被限流打回 429，客户端退避重试，同一个请求排队试好几次才成功——延迟拉长的同时，失败的那几次尝试也在消耗配额和时间。这件事最坏的地方在于它专挑高峰爆发，正是你最不希望体验变差的时候。缓解要分两层：给基线流量买一份预留吞吐，别让日常请求去挤共享配额；给客户端加带抖动的退避和请求队列，避免所有重试在同一秒撞上来。把限流当成容量规划的一部分，而不是等它在大促当天第一次教育你。

token 计价对长度是线性的，但注意力计算和显存占用随长度平方增长，供应商把这部分折进阶梯价：超过 12.8 万 token 后单价翻倍。用户把一份 200 页 PDF 拖进来时，单次成本从 0.0114 美元跳到 0.9 美元，80 倍。产品里每一个"把文件拖进来"的入口都是一个没封顶的成本敞口。切块检索加重排能把 200 页压回 6000 token，质量损失集中在需要跨章节比对的问题上，占比通常低于 8%——用这 8% 换 80 倍成本是划算的，前提是你在界面上诚实地说明检索范围。

多模态把这个量级又换了一次。加一个「把图片传进来」的入口，看起来只是多一个功能，实际是换了一个成本量级。图像和音频的单次推理成本通常比纯文本高出一个数量级，一张高分辨率图的处理费，可能顶得上几十次文本对话。用户对此毫无感知——他们只是随手拖了张图，账单却跳了一档。和长文档一样，每一个多模态入口都是一个没封顶的成本敞口。要么在入口处限制分辨率和数量、先降采样再送模型，要么把重度多模态功能放进更高档位单独计价。把多模态调用和文本调用混在同一个「单次成本」里平均，会让这个数字彻底失去意义。

规模曲线不是乘以 1000

同一套产品在三个规模下的月度开销，按上面的单价和一个真实的重度用户分布估算：

用户数涨了 1000 倍，账单涨了约 1600 倍。多出来的 600 倍全部来自最后两行：它们在 100 用户时是零。日志与追踪那一行也值得单看：给每个请求记全量日志、存下完整的输入输出和链路追踪，在一百个用户时几乎免费，到十万用户时是账单上实实在在的一行，就是从 5 美元涨到 8000 美元的这部分。全量留存既贵又其实用不上——真正需要逐字复盘的是出问题的那一小撮请求，而不是每一次成功的调用。可行的做法是对正常请求按比例采样，对报错、超时、低分和被投诉的请求全量留存，并给日志设一个短得多的冷存储周期。观测是为了排查问题，不是为了把每一个 token 都抄一遍存起来。

省钱的手段，代价各不相同

不是每个调用都需要用户盯着屏幕等结果。日报生成、批量摘要、夜间回填、离线打标，这些工作没有实时性要求，却常常和实时对话走同一条按标准价计费的通道。多数供应商为异步批处理开了半价档，条件是允许结果在若干小时内返回。把这类工作挑出来挪到异步通道，单价直接砍一半，而用户毫无感知。判断标准很简单：如果结果晚 6 小时到不影响体验，它就该走异步。反过来，把本可以异步的报表硬塞进实时通道，等于为一份没人当场看的文档付了双倍的钱。

缓存的收益取决于用户重复自己的程度。前缀缓存的机制是把不变的系统提示留在服务端，命中后按原价的 10% 上下计费。上面那次调用里如果 1800 token 输入中有 1200 token 是固定系统提示，命中缓存后输入成本从 0.0054 美元降到 0.0022 美元，单次总成本降到 0.0082 美元，省 28%。语义缓存的收益差异要大得多：客服和文档问答类产品的命中率能做到 35%，自由写作类产品低于 4%。上线语义缓存前先跑一遍历史请求的近似去重，命中率算不到 15% 就别做，维护一致性的代价会超过省下的钱。

系统提示很少一次写坏，它是慢慢胖起来的。这个团队加两条规则，那个团队塞三个示例，为了修某个边角 case 再补一段说明，几个月下来系统提示从 300 token 长到 1500 token。问题在于这部分是每一次调用都要付的固定开销：一条为了极少数情况加的示例，会在之后每一个请求上都收一次钱。few-shot 示例尤其贵，它们让每次输入凭空多出上千 token。值得每季度审一次提示词，把不再起作用的规则和示例删掉，能用检索动态注入的就别常驻在系统提示里。命中缓存能压掉一部分这个成本，但最干净的办法还是让提示词本身别那么长。

路由最便宜，也最容易自欺。把 70% 的请求交给单价只有 1/10 的小模型，账面成本变成 0.7 × 0.1 + 0.3 × 1 = 0.37，省 63%。但置信度不够时要回退到大模型，如果 12% 的请求走了这条路，这部分要付两遍钱，实际成本 0.49，净省 51%。差出来的 12 个百分点是路由器自身的税。隐性成本还有两套提示词、两套评测、两倍的回归面积，以及一个没人愿意背的问题：线上出错时，是模型错了还是路由错了。

用自己微调的 8B 模型替掉旗舰模型，单价能降到原来的 1/15，这个数字很诱人，代价却分三笔：3 万条左右的标注样本、一套必须一直维护的评测集、以及上游每次发新版后的回归验证。质量损失不是均匀分布的：主流意图上差 1 到 2 个百分点，长尾意图上可能差 15 个百分点，而长尾意图恰好是用户最容易记住的失败。合理的做法是只蒸馏那些意图封闭、输出格式固定的环节，比如意图分类、字段抽取、摘要压缩，把开放式生成留给大模型。换 embedding 模型是另一笔类似的隐性账：向量检索这块平时省心，一旦要换 embedding 模型，隐藏成本立刻冒出来。新旧模型的向量空间不通用，换模型等于把库里所有文档重新算一遍向量、重建整个索引。几百万条文档的重算既是一笔一次性的推理开销，也意味着迁移期间要同时维护两套索引、保证检索不中断。这笔账在选型时几乎没人算，却会在供应商调价或质量升级时突然砸下来。务实的做法是把 embedding 模型当成一个有迁移成本的长期承诺来选，而不是像换生成模型那样随时切；同时保留原始文本，别只存向量，否则重算时连源都找不回。

预留算力是又一种拿承诺换单价的手段。供应商给长期预留的吞吐量报折扣，单价能比按量低不少，代价是你得先承诺一个用量下限。这笔账划不划算，取决于用量有多平稳。基线部分（那条无论如何都会有的日常流量）用预留很合适，省下的是实打实的。可如果把预留买在了波峰上，平峰期用不满的那部分就成了纯浪费，闲置的承诺照样要付钱。务实的切法是只给能稳定预测的基线买预留，波动和增量部分留给按量，两者叠起来。承诺期越长、折扣越深，但也越赌未来的用量曲线，早期产品用量还没定型时，别急着签长约把自己锁死。

这些手段里，缓存、蒸馏、路由、缩短提示词全都在拿质量换成本，区别只是换多少。没有一套 300 到 500 条、覆盖主流意图和长尾意图的评测集，你无法回答"省了 40% 成本，质量掉了几个点"，只能靠客服工单事后发现。评测集的建设成本是两周人力加持续维护，回报是让每一次成本优化变成可撤销的决策。顺序不能反：先有评测，再动模型；先量化质量基线，再谈单价。

用量分布决定谁在补贴谁

典型的付费用户用量分布：P50 每月 40 次调用，P95 每月 900 次，P99 每月 6000 次。1000 个付费用户、每人 19 美元，月收入 1.9 万美元。成本侧：950 个普通用户平均 2 美元，共 1900 美元；50 个重度用户平均 55 美元，共 2750 美元。重度用户占人数 5%，占推理成本 59%，毛利率被压到 75.5%。把重度用户的月均成本从 55 美元压到 20 美元，总成本降到 2900 美元，毛利率回到 84.7%。这 8 个百分点不需要动其余 95% 的人。

免费用户是同一笔账的另一面。免费用户不产生收入，成本却和付费用户同源。转化率 3% 意味着每个付费用户要背 32 个免费用户的推理账单。免费额度定成每月 20 次调用时，32 × 20 × 0.0114 = 7.3 美元，直接从 19 美元的订阅里扣掉，毛利率少 38 个百分点。把额度改成 6 次、并把最贵的长文档功能挡在注册墙之后，这个数降到 2.2 美元。免费额度的正确算法不是"看竞品给多少"，而是"转化率 × 单人成本 ≤ 可接受的获客成本"。试用和促销同样把可变成本前置了：传统 SaaS 的免费试用几乎不花钱，多一个试用账号只是多一份边际接近零的服务，AI 产品不一样——试用期里每一次调用都在烧真金白银的推理费，而收入还没来。一个慷慨的 14 天全功能试用，配上不设限的用量，很容易在转化发生之前就把这个用户的几个月毛利先垫进去。更稳的试用不是按时间放开，而是按任务数放开——给足够体验产品价值的次数，而不是无限次；把最贵的长文档、多模态这类功能留到付费后再开。促销同理：打折拉来的用户如果用量还高，等于用更低的价格背更重的成本，这笔账要在做活动之前就算清楚。

管住这些用户的工具是上限，而上限怎么写决定它像不像惩罚。能用的上限有三个性质：用户在触发之前就看得到剩余量；触发之后功能降级而不是消失，比如换成小模型、缩短输出、排进异步队列；重置周期和计费周期同一天。不能用的上限是静默限流和一句"系统繁忙"。把上限画在 P95 用量的 1.5 倍处，受影响的用户不到 2%，砍掉的却是长尾里 60% 的成本。给触顶用户一个当场加购的按钮，比让他去翻定价页多转化 3 到 4 倍。而所谓"公平使用"要真能执行，光写进条款等于没写，得给三个数：窗口（滚动 30 天，不是自然月）、指标（成功完成的任务数，不是 token，用户看不懂 token）、后果（降速、降模型、还是自动转按量计费）。再配一条机器可判的滥用特征：单账号并发超过 5，或者请求间隔的标准差低于 200 毫秒。这些特征只能作为自动化使用的排查线索，不能单独作为封号依据。把规则写死并公开，比事后逐个封号省下的申诉工单更值钱。

定价结构怎么定

成本结构变了、或者当初的额度定得太亏，迟早要调价。真正棘手的不是新用户的价目表，而是那批按旧价签进来的老用户——尤其是用量最重、最亏钱的那些，他们恰恰最有动力留在旧价上。一刀切涨价会激起流失和口碑反弹，永远保留旧价则让最贵的那批用户一直亏下去。折中的做法是给老用户一个有期限的过渡：提前足够长时间通知，保留旧价若干个月，同时把新档位的额外价值讲清楚，让升级看起来是换更多东西而不是单纯多掏钱。对那些严重亏损的重度老用户，与其硬涨价，不如给一个更贵但更合适的档位，把他们平移过去。

调价之前，先确认计价单位选对了，否则后面的优化全是白做。按席位计价的产品碰上 AI 会立刻错配，同一个席位的用量能差 100 倍。按 token 计价对用户不可预测，没人知道 100 万 token 够干什么。折中方案是按"完成的任务"计价：一次报告生成、一次代码审查、一次合同比对。这个单位对用户有意义，和真实成本的相关系数通常能到 0.8 以上，而且允许你在后台换模型、加缓存而不用改价目表。定价页上写"每月 500 次分析"，比写"每月 2000 万 token"少一半的售前答疑。

还有一件常被自欺的事：把自助档和企业档的成本合并成一个数字。企业客户客单价 2000 美元、月推理成本 180 美元，毛利率 91%；自助用户客单价 19 美元、月推理成本 6 美元，毛利率 68%。合并报表算出来 86%，看着体面，掩盖的是自助档在获客成本之后其实是负的。拆开看还会发现另一件事：企业客户的成本大头不是推理，是私有化部署、合规审计和专属支持，这部分不随用量下降，压推理成本对他们没有意义。

功能取舍与供应商依赖

把功能挪进更高档位，判据不是这个功能贵不贵，而是它的成本分布有没有长尾。平均 0.3 美元、P99 也只有 0.5 美元的功能，放在基础档很安全。平均同样 0.3 美元但 P99 是 12 美元的功能，必须往上挪，或者配一个硬上限。第二条判据是渗透率：只有 8% 的用户在用，把它做成加价项，剩下 92% 的人不会有任何感觉，而这 8% 里愿意付钱的比例通常高于 40%。两条判据同时成立时，往上挪几乎没有风险。删掉一个功能则需要更硬的证据：过去 90 天渗透率低于 3%；单次成本高于它带来的留存增量；关掉之后不会引发工单增长。第三条必须用实验验证，而不是靠会议表决——对 5% 的新注册用户直接不上线这个功能，观察 30 天留存的差异，差异在 1 个百分点以内就可以删。删除前给存量用户 60 天通知和一个数据导出入口。留着一个没人用但每月烧 4000 美元的功能，代价不只是那 4000 美元，还有它在每次模型升级时占用的回归测试时间。

供应商依赖是另一笔看不见的账。把提示词、参数、输出解析全都调到贴合某一家供应商的脾气，短期最省事，长期埋了一笔看不见的账。真到要换供应商时（涨价、限流、质量倒退），才发现所有东西都是按旧模型的行为调的，迁移成本高到让你宁可忍着。保留一点可移植性是有代价的：多维护一层抽象、定期在备选模型上跑一遍评测集。这层保险平时不产生收益，只有在被迫切换的那天，它才是你能不能不受制于人的唯一依据。反过来，供应商降价也不算你的业绩：两年里单位 token 价格降了一个数量级，一批团队的毛利率就这么自己涨了 10 个点，这不是工程成果。价格下降会停，用量增长不会。做预算时把供应商降价按 0 计入，把用量增长按实际曲线计入，你会发现原本"已经解决"的成本问题回来了。真正属于你的优化是那些在单价不变的假设下仍然省钱的动作：更短的提示词、更少的失败重试、更早的停止条件、更严的输出长度约束。

谁对毛利率负责，盯哪几个数

先说目标该定在哪。60% 以下，下一轮融资的每一次尽调都会卡在这个数上。70% 到 75% 是 AI 原生产品的现实区间，多数团队能守住。80% 以上通常说明你的产品其实没那么依赖模型，AI 只是一层薄壳。把目标硬定在 78% 会逼团队做出伤害体验的选择：砍输出长度、换更差的模型、把用户赶进更贵的档位。先选一个守得住的数，写进每个功能的评审清单，让每个提案自己回答"这会让毛利率动几个点"。

有了目标，还得有人负责。成本挂在工程账下、定价挂在市场账下、留存挂在产品账下，三方各自最优的结果就是没人对毛利率负责。可行的做法是把这个数写进产品经理的季度目标，并给他两项真实权限：否决单次成本超过阈值的功能提案，以及在不改价目表的前提下调整额度与路由策略。再配一份每周自动生成的账单归因表，按功能、按档位、按用户分位拆开。看不到归因的团队只能整体砍预算，而整体砍预算永远先砍掉最有价值的那部分体验。

负责人手上值得盯的是四个数，每个都有各自的盲区。单次成功任务成本：分母只算成功的任务，失败重试的钱要摊进分子；盲区是它对任务难度不敏感，用户结构一变这个数就失真。每一美元收入对应的推理成本：盲区是被高价档位掩盖，企业客户的高客单价会盖住自助档的亏损。P95 与 P50 用户成本比：超过 20 就该动限额了；盲区是它不区分滥用者和高价值重度用户，后者往往是续费率最高的一群。缓存命中率：盲区最大，命中的如果全是本来就便宜的短请求，命中率 60% 也省不下 5%。

几个不太好听的回答

毛利率 55% 的 AI 产品还值得做吗？值得，前提是你能说清它靠什么变好，并且给出时间表。靠供应商降价不算，靠"规模上来就好了"更不算——上面那张表说明规模只会让超线性的那两行更难看。至于缓存和路由先做哪个，先做缓存：缓存不改变输出质量，风险只在一致性；路由会改变输出质量，需要评测集兜底。没有评测集就上路由，等于把成本问题换成了一个更贵的质量问题。

按量计费会吓跑一部分用户，主要是无法预估用量的新用户。混合结构更稳：一个包含明确额度的固定价，加上超额部分的按量，并且在界面上把剩余额度做成一个用户随时看得见的数字。重度用户该不该赶走，则要先分清是滥用还是深度使用——深度使用的用户续费率高、口碑价值大，正确动作是给他一个更贵的档位而不是限流；真正该赶走的是那种把你的接口当成免费算力转卖的账号，它们的行为特征在日志里很容易辨认。

至于什么时候该自建推理，把托管账单和自建的全部固定成本（显卡租用、值班人力、模型更新、闲置率）画在一张图上找交点。交点通常落在每月 3 万到 5 万美元推理开销附近，而且要求用量足够平稳。低于这个数自建，省下的钱换不回你多雇的两个人。