AI 行业的利润到底来自客户还是来自投资人这几年技术圈和投资圈反复在争论这件事。核心判断是一部分 AI 公司在账面上增长很快但收入并不是从真实客户那里赚来的而是由投资人资金间接撑起来的。投资人把钱投给 AI 创业公司创业公司把钱花在算力、云服务和产品推广上这些支出又变成云厂商和基础设施厂商的收入而云厂商的成长又反过来回报了同一批投资人。钱在一个封闭体系里循环却没有真正从外部客户那里产生持续利润。下面从工程视角拆解这条资金链路讲清楚如何用成本结构、单位经济和留存数据判断一个 AI 产品究竟是“客户付费”还是“投资人供血”并给出一套可以在项目里落地的计算和排查方法。无论你做的是大模型应用、AI Agent、AI 编程工具还是 AI 视频生成产品这套方法都适用。1. 先理解“利润来自投资人”这句话背后的资金链路1.1 一句话判断的本质“AI 的利润是由投资人出钱而不是客户赚来的”这句话的意思不是 AI 公司没有收入而是收入没有转化为可持续利润或者收入来源本身不健康。技术团队要理解这件事需要把公司财务简化为一个模型收入客户购买产品或服务支付的钱。成本训练算力、推理算力、人力、数据、销售等支出。利润收入减去成本后的剩余。当一家 AI 公司的产品或服务定价长期低于成本时每卖出一单都在亏钱。公司账面增长越快亏损越大。这时候钱从哪里来只能从投资人那里来。投资人注入的资金被用来补贴客户价格、支付算力账单和人力工资于是公司账上表现为收入增长但利润来自投资人出资而不是客户付费。这在商业上不等于一定失败。很多公司早期都靠融资补贴市场例如外卖、网约车都经历过类似阶段。问题在于 AI 产品是否能最终把补贴成本降下来建立客户愿意按合理价格持续付费的闭环。如果补贴停止客户就流失那就说明需求不是真实的而是价格补贴制造出来的。1.2 投资人资金如何变成账面收入理解这条链路的关键在于“资金从哪来到哪去”。以一个常见模式为例投资机构向 AI 创业公司注资。创业公司采购 GPU、云服务、模型 API 和数据标注服务。云厂商和基础设施厂商确认收入相关股票估值上升。投资机构持有这些厂商的股份账面收益增加。创业公司为了冲收入可能以低于成本的价格卖出 API 调用量或订阅服务或者在宣传中把“免费用户”算进业务增长。客户因为价格便宜而使用但这部分需求对价格极其敏感一旦提价就离开。在这个循环中最值得警惕的是第五步。如果一家 AI 公司的收入增长主要来自“低价获客”和“大额免费额度”那么这些收入本质上还是投资人出的钱只是换了个方式进入公司账户。真实客户付费意味着客户认为产品价值高于价格而投资人资金撑起的收入只意味着产品价格低于成本。1.3 为什么工程师也要关心这件事很多技术同学觉得商业判断是 CEO 和财务的事自己只管把功能做出来。这个想法在 AI 项目里很危险。原因在于 AI 产品的成本高度依赖技术决策。模型选型决定了单位 token 成本推理是否做缓存、是否量化、是否批处理直接决定毛利。同样一个聊天助手有人用 7B 开源模型自部署推理成本可以做到很低有人每个请求都调用大参数闭源模型成本高出好几个数量级。技术团队的选择从第一天起就在决定产品能不能从客户身上赚到钱。另外AI 应用开发中最容易被忽略的坑是“功能上线了但不知道每个用户每次操作花多少钱”。等到月底账单出来才发现成本比收入还高再想优化模型、调缓存、改计费往往要返工。下面从成本结构开始把这件事拆开。2. 从技术视角拆解 AI 产品的真实成本2.1 训练、推理和运营三块成本AI 产品的成本可以分成三类它们的发生频率和优化空间差别很大。成本项发生频率是否随用户量线性增长优化方向模型训练一次性或按版本迭代否数据质量、并行策略、低精度训练、增量训练推理算力每次请求是模型压缩、批量推理、缓存、选择更小模型数据与标注周期性低频数据管线、合成数据、人工复核工程与运维持续弱相关自动化、监控、降本策略销售与市场持续前期高、后期降低自然增长、自服务、内容获客训练成本虽然绝对值高但它是摊销成本可以分摊到很长一段时间。推理成本才是杀人于无形的地方。用户量增长推理成本就跟着涨用户不用成本为零但收入也为零。所以判断 AI 产品能不能从客户赚钱首先要盯住推理成本。2.2 一次推理到底花多少钱计算示例推理成本可以用一个很简单的公式估算每 1K token 成本 每小时 GPU 成本 / 每小时可处理 token 数 × 1000其中“每小时可处理 token 数”取决于模型大小、单请求生成速度、并发数和算力利用率。下面用 Python 写一个可复用的估算函数。def cost_per_1k_tokens(gpu_hourly_cost, tokens_per_second, concurrency, utilization0.7): effective_tps tokens_per_second * concurrency * utilization tokens_per_hour effective_tps * 3600 if tokens_per_hour 0: return float(inf) return (gpu_hourly_cost / tokens_per_hour) * 1000 # 示例单卡在线推理场景所有数值仅用于说明思路 gpu_cost 2.5 # 每小时租用成本单位元 tps 80 # 单请求输出速度单位token/秒 concurrency 4 # 同时处理的请求数 cost cost_per_1k_tokens(gpu_cost, tps, concurrency) print(f每 1K token 推理成本约: {cost:.4f} 元)这个示例没有考虑输入 token 的预填充成本、输出 token 的采样成本差异也没有考虑显存占用和批处理带来的吞吐变化但用来做数量级判断足够了。实际项目中模型每输出一个 token 都要做一次前向计算输出长度直接决定成本。这也是为什么很多 AI 应用对输出长度做限制或者优先引导模型给出短回答。学习阶段可以不用在意这些数字但一旦产品进入生产环境就必须在每次请求中记录 token 数和成本。生产环境还要额外考虑 GPU 利用率、峰谷流量、多租户隔离带来的资源浪费以及不同模型版本之间的成本波动。2.3 用表格建立成本基线建议每个 AI 项目都建立一张成本基线表把关键假设写清楚。这样无论后期换模型还是调价格都有据可查。项目示例值说明模型名称自研 7B / 闭源大参数模型不同模型成本差异巨大平均输入 token 数1500受系统提示词和上下文影响平均输出 token 数350决定推理成本的主要因素单请求推理成本0.003 元示例用上面的公式计算单请求对外价格0.01 元示例必须高于成本加上其他分摊缓存命中率30%命中缓存的请求成本接近零请求失败率0.5%失败请求也要消耗成本这张表里的数字要根据实际项目替换。重点是定价必须覆盖“推理成本 其他成本分摊 必要毛利”否则单位经济永远是负的。3. 用单位经济模型判断是否“从客户身上赚到钱”3.1 毛利不是收入减去营销费用那么简单判断一家 AI 公司是否从客户身上赚到钱不能只看总收入要看单位经济模型Unit Economics。最基础的指标是毛利率毛利率 收入 - 服务成本/ 收入 × 100%这里的服务成本是 COGSCost of Goods Sold也就是直接服务于客户产生的成本包括推理算力、云资源、客服支持、数据成本但不包括研发和管理费用。很多 AI 产品对外报价很高但扣除推理成本和云资源后毛利很低甚至为负。这是最典型的“投资人供血”信号。因为客户支付的价格连服务成本都覆盖不了公司每增加一个付费用户就亏一笔钱。这种模式下用户越多亏越多只能用新融资去填窟窿。3.2 一个虚拟 AI SaaS 产品的单位经济计算示例假设有一个 AI 助手产品按月订阅收费每月 99 元目标用户是小型内容团队。需要计算平均每月每个用户产生多少次请求。每次请求消耗多少 token。每次请求的推理成本。每月服务成本。每个用户的获客成本CAC。用户平均能留存几个月。用表格整理一个示例指标数值计算方式月订阅价99 元产品定价每月请求数600 次按活跃用户平均估算每次请求推理成本0.02 元按模型和 token 估算每月推理成本12 元600 × 0.02每月其他服务成本8 元存储、带宽、客服分摊单用户月服务成本20 元12 8单用户月毛利79 元99 - 20毛利率79.8%79 / 99单个客户获客成本 CAC300 元营销费用 / 新增客户数客户平均留存月数6 个月按历史数据客户生命周期价值 LTV474 元99 × 6 或按毛利 79 × 6这个示例里毛利率看起来不错但如果 CAC 高达 300 元而客户平均只留 6 个月LTV 只有 474 元扣掉获客成本后每个客户只贡献 174 元再扣掉研发、管理和销售费用公司依然很难盈利。真实的单位经济还要更细。要区分订阅费里有多少是首次订阅、多少是续费要区分按量计费客户和包月客户的成本差异要评估大客户折扣对毛利的影响。技术团队可以搭档数据库和账务系统用请求日志和订单数据算出真实的单用户毛利。3.3 现金流与利润技术团队最容易忽视的差异会计上的利润和手上的现金不是一回事。一家 AI 公司可能账面盈利但现金持续流出。常见原因包括客户预付了一整年费用公司确认收入时按月度摊销但钱已经花在采购 GPU 上。大客户采用年度框架合同收入集中确认但回款周期很长。云厂商账单按日或按月结算客户订阅费却有 30 到 90 天账期。免费额度和退款占用了实际现金流但收入报表上没有体现。技术团队在做成本监控时不要只盯“收入”和“成本”还要看账单支付周期。如果你的产品大量依赖预付费额度credits那么 credits 的消耗速度、过期规则和实际兑换率都要纳入分析。credits 在 AI 计费里不是简单的“用户充了多少钱”而是用户预先支付、未来换取算力服务的计量单位。它既是收入也是负债因为用户没有用完的 credits 随时可能要求退款或兑换成真实算力。4. 识别投资人资金撑起的需求和真实客户需求4.1 常见信号补贴、免费额度、自我采购判断一个 AI 产品的需求是否真实可以从几个信号入手。信号更像投资人供血更像客户付费定价长期低于成本覆盖成本且有合理毛利免费额度大额、无限制、长期补贴有限试用按时间或用量限制客户来源单一投资人或关联方多元化、自然增长大单构成投资人或生态内公司集中采购客户按业务需求分散采购留存月活高但付费留存低付费续费和留存稳定退款退款率高、争议多退款率正常有一个常见现象是创业公司拿到融资后为了冲收入规模把 API 服务以低于成本的价格卖给生态内的其他公司或者直接给自己控股的关联公司下单。业务数据看起来增长很好但实际上是投资人左口袋进右口袋。技术团队不一定能看到全部交易背景但可以从客户结构、毛利率和续费数据里发现异常。4.2 用留存、续费和支付意愿做验证验证需求真实性的核心不是新用户数量而是两个字留存。如果一个用户在第一周用了很多次 AI 功能但第二个月完全不付费说明产品对用户的真实价值不高。反过来如果一个用户虽然使用频次不高但连续 12 个月续费说明产品解决了某个真实问题。推荐的验证指标付费用户 3 个月留存率。客户续费率按年或按季度统计。净收入留存率NRR也就是老客户在原有收入基础上加上加购和升级后还能剩下多少收入。免费用户转化为付费用户的转化率。用户主动升级套餐的占比而不是靠客服电话逼单。其中净收入留存率尤其关键。NRR 超过 100% 意味着老客户在持续贡献更多收入这是产品自我造血的重要信号。如果 NRR 长期低于 80%说明产品在靠不断拉新维持收入规模拉新一旦停下来收入就会快速下滑。4.3 收入来源分析钱从哪里来建议每季度做一次收入来源拆解按以下维度切分按客户类型企业客户、个人开发者、渠道合作。按行业互联网、教育、金融、制造等。按渠道自然搜索、内容营销、销售团队、生态合作。按付费方式订阅制、按量计费、预付费 credits、一次性项目。按客户规模大客户、中小客户。如果前 3 个客户贡献了 60% 以上的收入这个产品本质上还不是一个“客户付费”的业务而是“大客户定制”或“关系驱动”的业务。这类业务不是不可以但不能拿“大规模客户增长”的故事去掩盖真实情况。技术团队在做容量规划时也要留意大客户流量一波动整体成本波动会非常剧烈。5. 工程上如何把商业判断变成可执行指标5.1 建立成本监控与单位成本看板商业判断不能停留在开会讨论要变成每天都能看到的数据。技术团队最应该做的一件事把成本和收入拉到同一个表里。推荐的数据模型是每次请求一条记录包含用户、产品、模型、token 数、估算成本、实际价格和是否付费。下面是一个示例计费事件结构{ event_id: evt_20250101_001, user_id: u_1024, product: assistant_pro, model: engine-x-small, input_tokens: 1200, output_tokens: 640, engine_cost_usd: 0.00342, price_usd: 0.00900, is_paid: true, created_at: 2025-01-01T10:20:30Z }有了这张表就能用 SQL 算出关键指标WITH per_request AS ( SELECT date, model_name, COUNT(*) AS request_count, SUM(input_tokens output_tokens) AS total_tokens, SUM(engine_cost_usd) AS total_cost, SUM(CASE WHEN is_paid THEN 1 ELSE 0 END) AS paid_requests FROM usage_events WHERE date 2025-01-01 GROUP BY date, model_name ) SELECT date, model_name, request_count, total_tokens, total_cost, total_cost / request_count AS cost_per_request, total_cost / NULLIF(total_tokens, 0) AS cost_per_token, paid_requests * 1.0 / NULLIF(request_count, 0) AS paid_ratio FROM per_request ORDER BY date, model_name;这张表里最关键的是cost_per_request和paid_ratio。前者告诉你每次调用是否在亏钱后者告诉你有多少调用是真正的付费用户产生的。如果付费请求占比很低但免费用户调用量巨大说明免费策略吸引了大量薅羊毛流量。生产环境建议把这个查询做成定时任务每天输出到监控看板并设置阈值告警。例如单请求成本超过定价的 80% 时告警付费占比连续一周下降时告警。5.2 用功能开关和计量系统验证付费意愿技术团队另一个重要贡献是让产品具备“可计费、可开关”的能力。这样才能低成本验证付费意愿。具体做法每个功能模块做成独立计量单位例如“每次回答消耗 1 个 credit”“每次图片生成消耗 5 个 credit”。用功能开关控制新功能灰度先给免费用户试用再灰度到付费用户。在计费系统里记录所有扣费事件避免“用户用了但没扣费”的情况。支持按量计费和订阅套餐切换方便后续做价格实验。对异常调用做风控例如单用户短时间内高频调用要自动限流防止恶意刷量导致成本失控。价格实验是验证“客户是否真的需要这个功能”的最直接手段。同一个功能在 A 组用户中消耗 1 个 credit在 B 组用户中消耗 2 个 credit观察两组用户的留存和续费差异。如果不涨价组留存反而上升说明该功能有真实价值如果涨价后用户几乎全部流失说明原来靠的就是补贴。5.3 一份可直接使用的项目自查清单检查项通过标准常用方法每次请求成本可计算请求日志包含 token 数和成本字段中间件或 SDK 埋点单请求成本低于定价成本长期低于定价的 70%成本看板 告警付费用户占比合理免费调用不至于压垮成本用量限额 风控客户续费可观测有留存和 NRR 统计数据分析平台收入来源多元化前 3 客户收入占比低于 40%财务月报拆解预付费 credits 有负债视图未消耗 credits 每周统计账务系统模型成本有缓存兜底高重复请求命中缓存缓存层 命中率监控价格变更可灰度支持按用户组配置价格功能开关 分账这个清单同时适用于学习项目和生产项目。学习项目可以只做前两项但要把数据埋好生产项目必须全部覆盖。6. 常见误判与排查路径6.1 三个常见误判第一个误判把“收入增长”当成“利润健康”。收入增长可能来自低价促销、一次性大单或关联交易。判断标准是看毛利率和续费率不看单月流水。第二个误判把“免费用户活跃”当成“产品被市场接受”。AI 产品尤其容易陷入这个误区因为免费用户使用成本为零任何人都会点一下试试。真正有效的指标是付费转化和付费留存免费用户数量只能说明“有人知道这个产品”不能说明“有人愿意为其买单”。第三个误判把“市场份额”当成“护城河”。很多 AI 公司靠融资补贴拿下大量份额但并没有形成数据壁垒、网络效应或成本优势。一旦竞争对手以更高补贴进入或者资本环境变差份额会快速流失。护城河要看成本结构、数据飞轮和客户锁定程度而不是单纯的用户数。6.2 排查路径从收入倒推成本如果怀疑自己负责的 AI 产品没有真实利润可以按下面顺序排查。先拆收入本月收入里多少来自新客户多少来自老客户续费多少来自预付款和 credits 消耗。再算成本把按量计费请求的 token 消耗和成本统计出来和收入做对比。检查毛利率毛利率是否稳定是否因为模型升级或流量变化而波动。检查用户结构前排大客户是否关联投资方单一客户收入占比是否过高。看留存曲线付费用户进入第二个月、第三个月后的留存率。看现金账面利润为正但银行余额是否持续下降应付云账单是否越堆越高。最后交叉验证免费额度有没有被大量套现refund 和争议订单是否异常增长。每一步都要用数据回答不能靠感觉。很多项目排查到最后会发现问题不是“产品没人用”而是“有人用但每一单都在亏”。6.3 给 AI 产品团队的实践建议回到最开始那句话AI 利润是投资人出的还是客户赚来的这个判断不应该只停留在投资人的 PPT 上。它应该成为每个 AI 产品团队日常工作的一部分。对技术团队建议把“单请求成本”当作和“接口延迟”“错误率”同等重要的核心指标来监控。对产品团队建议把“付费留存”和“NRR”作为北极星指标而不是单纯的日活和调用量。对管理者建议每月看一眼收入来源拆解确认增长不是靠融资补贴和关联交易撑起来的。如果要给初学者一个练习方向可以选一个自己常用的 AI API记录一周的调用量按本文的公式算一次单位经济再把产品售价代入得出真实的毛利率。这个练习做一遍比读十篇行业分析都更能理解“投资人供血”和“客户付费”的区别。AI 行业还在快速发展模型能力会继续提升推理成本会继续下降。但商业规律没有变一个产品只有让客户觉得“值这个价”并且价格能覆盖成本才能在补贴结束后活下来。技术团队越早理解这一点越能在 AI 应用开发中做出既能用好模型、又能守住成本的技术决策。