大模型投入产出失衡：AI成本结构、ROI测算与工程实践

如果你关注大模型、云基础设施或者 AI 应用落地，最近应该注意到了 Aswath Damodaran 那篇观点非常直白的评论：Big Tech Has No Idea How AI Pays Off。这位纽约大学金融学教授、估值领域公认的权威，直接点名了硅谷大厂在 AI 上“先砸钱再想办法”的现状。他不是说不该投 AI，而是说：以目前各大公司披露的财务信息，根本看不出这笔巨额 AI 资本支出什么时候能变成利润。

这篇文章真正让人不安的地方在于，它戳破了科技行业过去十多年信奉的“增长叙事”——只要用户规模和技术指标向上，利润可以以后再说。在 AI 时代，这套逻辑遇到了一个前所未有的问题：模型能力提升和商业回报之间，出现了巨大的、短期无法弥合的裂缝。

对于做技术的人来说，Damodaran 的批评不是纸上谈兵的财务理论。它直接关系到我们每天在做的事情：要不要接入大模型、选哪个档次的模型、做出来的 AI 功能到底怎么算收益、公司敢不敢为一个新模型持续投入。这篇文章我会从技术与财务交叉的视角，把 Damodaran 的核心论点拆开讲清楚，然后落到开发者能用的层面：AI 项目的成本结构长什么样、ROI 怎么拆、什么样的 AI 工程更可能赚到钱。

1. Damodaran 到底在批评什么

Damodaran 的核心判断可以概括成三句话：

第一，大科技公司目前对 AI 的投入，是一种“信仰驱动”的资本配置。几乎所有头部云厂商和互联网公司都在大幅增加资本开支，理由是“AI 是未来”“不投入就会被淘汰”，但这个理由本身无法被财务模型量化。

第二，AI 的回报周期和回报路径高度不确定。传统企业投资建厂、扩产线、开店，测算回报的逻辑很简单：投入多少、产能多少、毛利多少。但 AI 基础设施投入巨大，产出却是 token、模型能力、自动化流程这些难以直接对应收入的东西。

第三，估值已经跑在了盈利前面。在过去一年多的市场定价中，AI 相关公司的市值隐含了极高的未来增长预期。Damodaran 的估值模型显示，部分明星 AI 个股的股价已经把未来十年的高增长都提前定价了，任何一次盈利不及预期都可能引发剧烈回调。

这三个论点放在一起，指向一个核心矛盾：AI 是生产力工具，但生产力不等于收入，更不等于利润。

从技术角度看，这个矛盾更加具体。企业部署一个 AI 客服机器人，确实节省了人力成本，但节省出来的成本能不能覆盖 GPU 服务器、推理 API、数据清洗、标注团队、提示词调优这些新增支出？答案在不同场景下差距极大。这就是 Damodaran 所说的“Big Tech 不知道 AI 如何回报”的根本原因——不是因为工程师不行，而是因为整个行业还没有建立起一套成熟的“AI 投入产出核算体系”。

2. 为什么 AI 的回报率这么难算

Damodaran 批评的核心是财务层面对 AI 资本支出的“不可知”。但从工程师视角看，AI 项目回报难算，是因为它的成本结构和传统软件项目有本质差异。

传统 SaaS 项目的成本曲线是边际递减的：开发一套 CRM 系统，前期研发成本固定，后期每增加一个客户，边际成本几乎为零，毛利率可以做到 80% 以上。

AI 项目完全不同。它的成本由三个部分构成：

训练成本（一次性）。从零训练一个大模型，算力消耗惊人。公开报道显示，前沿大模型的单次训练成本已经达到数亿美元量级。而且这个成本不只是训练那几周的电费，还包括前期的数据工程、人工反馈对齐、实验试错。今天绝大多数企业其实不需要从头训练模型，更多的是微调，但微调同样需要 GPU 资源，成本依然不低。

推理成本（持续发生）。模型部署之后，每一次用户请求都会产生真实算力消耗。这是 AI 应用和传统软件最本质的区别：传统软件的用户请求可以忽略不计，但大模型的每次推理都要调用大量计算资源。即便使用了量化、蒸馏、缓存这些优化手段，推理成本依然与用户规模线性相关。

人力维护与迭代成本。模型效果监控、提示词更新、RAG 知识库维护、数据回流清洗、评估脚本维护，这些隐性成本在成本核算中经常被忽略。很多团队只算了 GPU 和 API 账单，没有把数据工程师、训练工程师、评估工程师的工时算进去。

这三种成本结构，导致 AI 项目很难用传统的 LTV/CAC（用户生命周期价值/获客成本）模型来衡量。一个 AI 产品的收入逻辑是清晰的，但它的成本结构里有太多“非标准”的变量：模型选型、上下文长度、缓存命中率、输入输出 token 比例、降级策略，每一个变量都直接影响毛利。

3. 训练成本、推理成本与单位经济学

要理解 AI 企业为什么难赚钱，必须拆开看单位经济学（Unit Economics）。

先看推理成本。假设一个 AI 应用每天有 100 万用户请求，每个请求平均消耗 5000 个输入 token 和 1000 个输出 token。按当前主流大模型 API 的价格区间来计算，即便有折扣，一天仅推理成本就非常可观。如果这个应用还是免费的，那么每增加一个用户，公司就在增加一份真实亏损。

这就是 Damodaran 提到的“回报路径不清晰”在微观层面的真实体现——很多 AI 产品可以快速获得用户增长，但增长本身没有补贴单位经济学，反而在放大亏损。

再看训练成本。对于头部模型厂商，训练成本是沉没成本，但必须通过后续的 API 调用和产品化来分摊。问题在于，开源模型和商业模型的竞争把 API 价格一路推低。价格战会让模型厂商陷入一个典型困境：要么降价换市场，但毛利承压；要么维持高价，但用户转向开源模型自部署。

对应用层公司来说，这个问题同样致命。应用层公司要么调用 API（成本随用量线性增长），要么自部署开源模型（前期有基础设施投入但边际成本更低）。从财务角度看，这不是简单的技术选型，而是成本结构的选择。

单位经济学的结论很清楚：AI 应用的毛利率取决于你能否把成本和收入之间的每个环节都量化，并在架构层面做出可控制的取舍。哪些请求用旗舰大模型处理，哪些请求用小模型或规则系统兜底，这不只是技术细节，而是最终决定项目会不会亏钱的关键决策。

4. 收入转化路径：AI 到底怎么赚钱

Damodaran 问“AI 如何回报”，其实是在问 AI 的收入转化路径是什么。从具体场景拆，AI 赚钱的路径只有三类：

第一类：直接卖 AI 能力。典型的如 API 服务、模型订阅、SaaS 产品中的 AI 功能付费升级。这条路径收入清晰，但竞争惨烈。

第二类：用 AI 提升存量业务的效率。比如客服替代、代码辅助、内容生成提效、营销自动化。这类路径不直接产生收入，但压缩成本或提升人效。它的核心指标是“替代了多少人工”或“节省了多少时间”。

第三类：通过 AI 体验带动核心业务增长。比如搜索引擎加入 AI 摘要后用户时长增加，电商的 AI 推荐提升转化率，办公软件的 AI 助手提升付费转化。这类路径最接近传统互联网的“体验带动增长”模型，但也是最难验证的。

Damodaran 的批评在于，目前大厂在汇报 AI 成果时，大量使用第三类逻辑，但第三类逻辑很难归因。比如微软说 Copilot 提升了 Office 365 的黏性，但这个提升到底有多少是 AI 带来的，有多少是产品本身更新带来的？财务分析师无法从财报里找到答案。

从技术角度看，这也提示了一个做 AI 工程的原则：AI 功能最好做成可衡量的独立单元，而不是附属于核心产品的一个“增强”。如果 AI 功能能单独成为一个 SKU、单独计量收入，它的 ROI 就清晰；如果只是作为一个模糊的“体验增强”，即便技术做得好，商业价值也说不清楚。

5. 从财务视角看 AI 工程预算

理解了上述逻辑，可以给出实际的 AI 工程预算与验收框架。下面的测算表是我建议团队在做 AI 项目立项时使用的模板，它源于 Damodaran 的估值逻辑——先明确回报，再规划投入。

在此基础上，AI 项目立项时建议先回答四个问题：

AI 功能的增量收入是多少？如果一个新功能只是把原有功能做得更好，很难单独收费，那它的价值就必须通过“节省成本”来体现。

增量成本是多少？不仅算 API 账单和 GPU 资源，还要算团队工时、数据成本、监控成本。AI 项目不存在“开发完就结束”，它像运维系统一样，上线只是开始。

相比现有方案，AI 方案的实际提升是什么？把原有方案做 5% 的提升，和有 AI 才能做、没有 AI 完全做不到，是两种完全不同的立项逻辑。

如果 AI 方案失败了，团队有没有回退路径？AI 方案的评估不像传统功能那样明确，需要设定明确的“不再继续投入”的止损线。

6. 开发者应该怎样做 ROI 测算

在做 AI 功能 ROI 测算时，可以使用下面这个简化的增量公式：

增量收益 = (节省成本 + 新增收入) - (AI 运行成本 + 人力成本 + 机会成本)

新建项目文件如roi_calculator.py，用一个很简单的脚本就能完成估算：

def estimate_ai_roi( tokens_per_request: int, requests_per_month: int, cost_per_token: float, saved_hours_per_month: float, hourly_cost: float, extra_revenue_per_month: float = 0, dev_cost: float = 0, ): """ 估算一个 AI 功能每月的 ROI - tokens_per_request: 单请求平均 token 消耗 - requests_per_month: 每月请求量 - cost_per_token: 输入+输出 token 的混合单价 - saved_hours_per_month: 每月节省的人工工时 - hourly_cost: 人工时薪成本 - extra_revenue_per_month: 每月新增收入（可预留为 0） - dev_cost: 一次性开发总成本（分摊到每月按业务需要） """ ai_cost = tokens_per_request * requests_per_month * cost_per_token saved_labor = saved_hours_per_month * hourly_cost net_benefit = saved_labor + extra_revenue_per_month - ai_cost payoff_months = dev_cost / net_benefit if net_benefit > 0 else float('inf') print(f"AI 运行成本/月: {ai_cost:.2f} 元") print(f"节省人力成本/月: {saved_labor:.2f} 元") print(f"新增收入/月: {extra_revenue_per_month:.2f} 元") print(f"净收益/月: {net_benefit:.2f} 元") print(f"开发成本回本周期: {'不盈利' if payoff_months == float('inf') else f'{payoff_months:.1f} 个月'}") return net_benefit, payoff_months # 示例：客服机器人，单次请求 3000 token，月 10 万次请求 estimate_ai_roi( tokens_per_request=3000, requests_per_month=100000, cost_per_token=0.000015, saved_hours_per_month=500, hourly_cost=80, )

这个脚本输出示例：

AI 运行成本/月: 45000.00 元 节省人力成本/月: 40000.00 元 新增收入/月: 0.00 元 净收益/月: -5000.00 元 开发成本回本周期: 不盈利

从这个结果就能直观看到 Damodaran 说的“AI 回报难”在工程层面的含义：一个技术上非常成功的客服机器人，如果单次请求成本压不下去，经济上可能就是亏的。

所以 AI 工程不只是做功能，更是做单位成本控制。控制成本的技术手段包括：

• 模型路由：用一个分类器判断简单问题和复杂问题，简单问题走小模型，复杂问题才走旗舰模型。
• 缓存机制：把高频、重复的请求结果缓存起来，避免每次请求都调用大模型。
• 提示词压缩：减少 context 中冗余内容，直接降低输入 token 数量。
• 批量推理：非实时场景下用批量处理方式，享受更低单价。

这些手段组合起来，往往能把单次请求成本降低 50% 以上。而 50% 的成本差，就是一个 AI 项目从亏损到盈利的分界线。

7. 不同层级公司的 AI 投资策略

Damodaran 批评的对象是“Big Tech”，但对不同规模的公司来说，AI 投资的策略和风险差异很大。

7.1 头部云厂商和模型厂商

对拥有基础设施的大厂而言，AI 投入是一种“基建级”投资。它们不仅要建数据中心、买 GPU，还要持续投入模型研发。这些投入的回报周期更长、不确定性更大，但一旦形成规模效应，壁垒也极高。

对大厂来说，Damodaran 的批评其实指向一个更深刻的产业问题：如果 AI 基础设施成为类似水电的基础服务，那么整个行业的利润率会不可避免地被压缩。早年云计算的发展历程已经证明，基础设施竞争到最后是价格战和规模战，而非高利润生意。

7.2 中型技术公司

对中型公司而言，最理性的策略是“跟随者策略”。不要在基础模型上投入过重，而是聚焦于场景适配。选型上，优先考虑成熟的商业 API 和开源模型的组合。

中型公司最大的风险是技术负债：今天用 A 厂商的 API 快速上线，等业务跑通了，发现成本太高想迁移到开源模型，结果发现代码里满是厂商锁定的集成逻辑。所以在做技术选型时，一定要在业务代码和模型 API 之间加抽象层，哪怕前期多一层开发和维护成本也是值得的。

7.3 创业公司和小团队

创业公司最怕的不是技术落后，而是单位经济学跑不通。如果你做的是一个 AI 原生应用，那么在第一天就要把推理成本纳入定价模型，而不是先免费获客再慢慢优化成本。

从 Damodaran 的观点看，创业公司比大厂更危险的地方在于：大厂用亏损换市场份额还能靠融资和市值支撑，创业公司如果烧不起钱，连等待回报的机会都没有。

所以创业公司的 AI 应用要尽量选择“低推理成本 + 高用户价值”的场景。所谓低推理成本，是指不需要每次请求都调用大模型，很多功能可以提前用模型批量离线生成结果，在线服务时只做检索和匹配。

8. AI 应用层常见误区与工程建议

结合 Damodaran 对“AI 投入产出不匹配”的批评，这里整理开发者在 AI 应用项目中常见的几个误区。

误区一：把所有功能都做成 AI 功能。很多产品经理把“能不能接入大模型”当作功能立项的标准，导致产品复杂度增加，成本失控。正确的姿势是：先明确业务目标，再看 AI 是否是达成目标的最优手段。如果规则系统能解决 80% 的问题，就不要为了“AI 化”而引入不确定性和成本。

误区二：只看模型效果，不看成本和延迟。大模型评测分数高，不代表它适合你的业务。实际业务中，模型响应时间和成本同样是核心指标。推荐的做法是为每个场景设定明确的 SLO（服务等级目标），包括响应时间、成本上限、效果下限。任何一个指标不达标，这个方案就要重新选型。

误区三：忽略评估消耗的成本。很多团队只盯着训练成本，没有把评估环节的成本计入。评估一个模型需要测试集、人工打分、对比基准，这些都会消耗人力和算力。更高效的路径是建设自动化的离线评估流水线，减少人工参与，也让模型迭代从“拍脑袋”变成可复现的实验。

误区四：认为开源模型一定是低成本方案。自部署开源模型看似每 token 成本低，但 GPU 服务器折旧、运维人力、弹性扩缩容这些成本容易被低估。流量波动大的业务，自部署模型要保持响应速度就必须常备算力，空闲时段的算力浪费会吃掉 API 方案的成本优势。稳妥的做法是小流量阶段用 API，量级上来后再评估自部署的性价比。

9. 总结与后续参考方向

Damodaran 给大科技公司提了一个很难回答的问题：你们花出去的钱，到底什么时候能赚回来？对技术人来说，这个问题不应该只是 CFO 的事。工程决策里的每一次模型选型、每一条 prompt 设计、每一次缓存命中的优化，都在最终决定 AI 投资回报率的数字。这不是在否定 AI 的价值，而是在提醒所有人，AI 项目的账要算清楚，不能再靠概念和预期驱动。

如果你想沿着这个方向继续深入，可以考虑三步：先拿一个实际业务场景做成本拆解，对照本文的 ROI 框架算一笔账；然后针对高成本环节去做模型路由和缓存优化；最后把项目的完整成本曲线和收入指标沉淀成团队的标准化复盘模板。这是把 Damodaran 的财务批判变成工程优势的最直接路径。