如果你关注大模型、云基础设施或者 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 项目立项时建议先回答四个问题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(fAI 运行成本/月: {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_request3000, requests_per_month100000, cost_per_token0.000015, saved_hours_per_month500, hourly_cost80, )这个脚本输出示例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量级上来后再评估自部署的性价比。问题现象可能原因排查方式解决方案模型 API 账单远超预算每次请求输入 token 过多统计请求日志中的 token 消耗分布增加缓存、减少 prompt 冗余、加装模型路由自部署模型响应慢GPU 规格不足或并发配置不当查看 GPU 利用率和推理耗时调整 batch size、升级硬件或切换量化策略人工标注和评估成本高评估流程依赖人工判断统计每周评估耗时建立自动化评估集业务规则能覆盖的问题不要人工打分ROI 模型显示亏损单位成本过高或收入路径不清晰拆解成本项和收入项调整方案成本结构或砍掉功能9. 总结与后续参考方向Damodaran 给大科技公司提了一个很难回答的问题你们花出去的钱到底什么时候能赚回来对技术人来说这个问题不应该只是 CFO 的事。工程决策里的每一次模型选型、每一条 prompt 设计、每一次缓存命中的优化都在最终决定 AI 投资回报率的数字。这不是在否定 AI 的价值而是在提醒所有人AI 项目的账要算清楚不能再靠概念和预期驱动。如果你想沿着这个方向继续深入可以考虑三步先拿一个实际业务场景做成本拆解对照本文的 ROI 框架算一笔账然后针对高成本环节去做模型路由和缓存优化最后把项目的完整成本曲线和收入指标沉淀成团队的标准化复盘模板。这是把 Damodaran 的财务批判变成工程优势的最直接路径。