最近关于 AI 资本开支的争论很多但大部分讨论都停留在“谁的模型参数多、谁的榜单分数高”上。纽约大学斯特恩商学院的金融学教授 Aswath Damodaran 最近一篇公开文章直接把问题换了个方向大科技公司其实并不清楚 AI 会以什么方式、在什么时候产生回报但已经在按“一定会回报”的方式花钱。这篇内容我们不聊模型评测也不聊训练技巧而是认真拆一下这个判断背后的逻辑以及它对做 AI 应用、AI 平台、企业模型部署的人到底意味着什么。Damodaran 在估值圈的知名度不用多说长期做企业价值分析说话比较直接。他这篇文章的核心标题可以概括成一句话Big Tech 在 AI 上的巨额资本开支目前看不到清晰的变现闭环。这个观点的价值不在于“唱多还是唱空”而是把 AI 从一个技术竞赛问题拉回到经济学问题——GPU 是资本开支数据中心是沉没成本推理是运营成本收入必须来自真实的用户付费或效率提升。如果这几项对不上再强的模型也只是成本中心。这篇文章会做三件事。第一拆解 Damodaran 的核心论证逻辑看他的判断依据是什么第二从工程角度把 AI 的成本结构、变现路径和回报验证串起来第三给出一套技术负责人可以直接套用的 AI 项目 ROI 评估框架和成本观测方法。适合正在做大模型应用、企业 AI 平台或者需要向管理层交代“AI 投入到底值不值”的读者。1. 核心论点速览先给一张总表把 Damodaran 公开讨论中的核心观点和技术团队的落地关注点对应起来维度Damodaran 的公开观点对技术团队的直接影响资本开支 vs 价值创造大厂在 AI 基础设施上投入巨大但开支不等于创造价值申请算力预算时要带业务回报假设不能只谈参数竞赛变现路径模型能力与真实付费场景之间存在明显断层立项时先定义指标降本、增收、提效三选一机会成本巨额 AI 投入挤占了其他研发方向的资源资源分配要对比 AI 项目与非 AI 项目的边际回报时间维度回报周期可能远长于市场预期做三年现金流测算而不是只看一个季度 Demo竞争格局谁都能调用基础模型护城河不在参数在数据和场景应用层价值、数据闭环和交付能力才是差异点这张表的右侧是这篇文章重点展开的部分。左侧的逻辑如果你熟悉 Damodaran 以前的文章会发现和他对互联网泡沫、铁路狂热、电信基础设施过度建设的判断思路是一脉相承的。2. 背景为什么这位“估值院长”的判断值得技术人注意先说背景方便不熟悉他的读者判断这条信息的可信度。Damodaran 是纽约大学斯特恩商学院的金融学教授长期从事企业估值和投资分析公开课和估值模型被很多分析师当作工具书用。他的研究方式不是看概念而是看现金流一家公司到底赚多少钱、什么时候赚、需要投入多少资本才能赚到。和很多只看 AI 潜力的分析师不同他习惯把故事翻译成数字再问数字成不成立。他对 AI 的态度不是否认技术能力。从他近两年的公开文章和访谈看他承认大语言模型的能力进步是真实的也承认 AI 会改变部分行业的成本结构。他质疑的是另一件事投入和产出的时间轴严重不匹配。具体来说云厂商和互联网大厂现在以季度为单位增加 GPU 集群和数据中心资本开支的绝对值已经达到行业历史罕见水平但下游能看到的、愿意为 AI 功能持续付费的用户场景规模和确定性都远配不上这笔开支。这个判断对技术团队有一个很实际的提醒公司 CEO 和 CFO 看的不是模型榜单而是资本开支回报率。如果技术部门只会汇报“我们训练了更大的模型”而不回答“这个模型在什么业务场景下每季度能带来多少收入、节省多少成本”下一轮预算审批会越来越难。3. Damodaran 的核心论证逻辑拆解把他的公开观点整理一下论证链条大致有四环。3.1 资本开支不等于价值创造这是最核心的一环。他的框架里资本开支只有在两种情况下才创造价值要么降低了未来的单位成本要么带来了新的收入来源。如果只是为了防止落后而买 GPU、建机房那本质上是防御性开支防御性开支很难产生超额回报。现在的问题恰恰在这里。各家的 AI 资本开支很大一部分是“军备竞赛”性质的——对手买了我就必须买否则下一轮模型能力掉队。这种开支的回报逻辑不是由需求决定的而是由竞争决定的。从会计上看它是资本开支从价值创造上看它更像一种不断膨胀的入场费。对技术团队来说这意味着你在写算力申请文档时不能只写“需要 1000 张卡训练下一个版本”要写清楚这批卡在训练完成后有多少比例继续用于推理、多少比例闲置、预期多长时间能把成本摊销回来。3.2 变现路径的空洞第二环指向收入端。目前 AI 的直接变现方式大致能数出来ChatGPT 这类订阅产品、API 按 token 收费、云厂商的模型服务、嵌入办公软件后的功能订阅、以及广告和推荐系统的质量提升。但这里面存在一个分层问题卖铲子的赚到钱了用铲子挖矿的还没找到稳定的矿脉。模型层的收入是真实的因为基础模型是刚需谁都要调 API但应用层的收入是分化和不确定的。大部分 To C 的 AI 助手功能用户愿意试用但付费转化率远低于初期预期。To B 的 AI 功能企业愿意采购的是能直接省人力的场景比如客服、文档处理、代码辅助如果只是给现有产品加一个“AI 总结”按钮很难单独收费。这就是 Damodaran 说的“不知道 AI 怎么赚钱”的具体含义上游的收入看得见下游的付费场景还在验证阶段中间的落差由资本开支填补。3.3 历史类比基础设施狂热中的位置他在公开讨论中多次用过历史类比铁路建设期铺铁轨的公司股价暴涨但真正靠铁路运输赚钱的货运公司很多年都没有稳定利润电信泡沫时期光纤铺完之后大量带宽闲置最后以白菜价卖给内容公司。AI 基础设施有类似的影子。GPU 和算力网络铺完以后如果应用层的需求增速跟不上供给算力价格就会快速下跌前期高价买卡、建机房的公司的资产回报率就会被摊薄。这是资本开支周期里最常见的剧本最先建产能的人承担了折旧最后建完的人吃到低价。这个类比不是说要停止建设而是提醒一点算力供给的扩张速度远快于应用需求验证的速度。先发优势只有在应用需求同步落地时才成立。3.4 竞争格局护城河不在参数他还有一个容易被技术人忽略的观点如果基础模型越来越同质化大厂烧钱烧出来的模型能力很快就会变成“公共设施”无法形成定价权。真正能形成壁垒的是专有数据、分发渠道、用户习惯和工程交付能力。这对做应用的人反而是利好。它意味着基础模型能力的差距会缩小应用层玩家的空间会变大。你的竞争优势不取决于你能不能训练出一个 300B 参数的模型而取决于你能不能把现有模型和业务场景结合做出用户愿意持续付费的产品。4. 从工程视角看 AI 的真实成本结构把上面的宏观逻辑落到工程层面AI 项目的成本结构其实比很多人想的要细。一个典型的企业 AI 功能成本由四块构成。第一块是算力采购与折旧。GPU 服务器价格高折旧周期通常按三年到五年算。如果你买了一批卡只用来训练训练完了接不到推理流量这批卡的折旧就会直接吃掉项目利润。所以评估算力需求时训练峰值和推理稳态必须分开算。第二块是推理成本。这是最容易低估的部分。训练是一次性成本推理是每次调用都发生的持续成本。一个模型哪怕再强如果每次问答消耗的 token 太多、响应太长单位成本就会失控。模型选型时要从“谁的评测分高”回到“每千 token 的成本和在这个场景下的准确率”。第三块是数据与标注成本。模型能力只有接上业务数据才有效但数据清洗、标注、评测集的维护都需要人力和时间。很多项目模型没花多少钱数据管道反而烧掉了大半预算。第四块是工程维护成本。模型部署、监控、版本迭代、安全加固、合规审计这些都要人。这个成本不会随模型能力提升而消失反而会因为接入业务越多越重。把这四块加在一起才能回答“AI 功能到底贵不贵”这个问题。只看 GPU 采购价是不完整的。5. AI 变现的几条真实路径和验证方法结合 Damodaran 的质疑我们把 AI 变现路径分成两层已经验证的和还在预期阶段的。已经验证得比较好的是这三类按调用计费的 API 服务。基础模型厂商直接向开发者收费收入与调用量挂钩模式清晰。开发者工具和代码辅助。这类工具直接嵌入研发流程节省的是程序员的时间付费意愿很强而且效果容易量化——省了多少小时、提了多少发布速度。客服和文档处理等知识密集型环节。企业采购时可以直接对比人力成本ROI 算得出来不容易受大模型“幻觉”的叙事影响。还在预期阶段的包括AI 原生硬件、通用 AI 助手的大规模订阅、以及“AI 自动完成整条业务流程”的智能体。这些方向的用户价值是真实的但付费转化、任务复杂度和出错成本还没有完全跑通。对于技术团队判断一个 AI 功能能不能变现有一个很朴素的方法看这个功能是不是替换了一项原本有人付费的工作。替换客服省的是坐席工资替换初级程序员省的是研发成本替换内容审核省的是审核人力。如果一项 AI 功能只是“锦上添花”用户夸完就走那它大概率不是变现路径而是品牌预算。6. AI 项目 ROI 评估框架技术负责人可以直接套用回到实操。不管 Damodaran 的判断对不对技术团队都绕不开一个问题怎么在立项时就算清楚 AI 项目的回报。6.1 先定义成功指标立项时只写“提升用户体验”是不够的。每个 AI 功能必须绑定一个可量化指标三类选一降本单位订单的客服成本下降多少单位内容的审核成本下降多少。增收AI 功能直接带来的新付费用户数或老用户升级付费的比例。提效研发、运营、销售流程的吞吐量提升多少。如果这个指标没法定义项目就应该押后直到能定义为止。6.2 用单元经济模型做测算定义了指标之后用单元经济模型验证。下面是一个通用的 Python 计算模板参数需要按你的实际服务账单替换# AI 功能单元经济模型示例参数按实际项目调整 def ai_feature_unit_economics( monthly_inference_tokens: int, # 每月推理 token 总量 cost_per_1k_tokens: float, # 每千 token 的推理成本 monthly_fixed_cost: float, # 固定成本GPU 折旧、人力摊销、数据成本 paying_users: int, # 每月付费用户数 price_per_user: float, # 每个用户的月付费金额 ): inference_cost monthly_inference_tokens / 1000 * cost_per_1k_tokens total_cost inference_cost monthly_fixed_cost revenue paying_users * price_per_user break_even_users total_cost / price_per_user if price_per_user else None return { total_cost: total_cost, revenue: revenue, monthly_profit: revenue - total_cost, break_even_users: round(break_even_users, 0) if break_even_users else None, } # 示例参数请以真实账单为准 result ai_feature_unit_economics( monthly_inference_tokens50_000_000, # 5000 万 tokens cost_per_1k_tokens0.002, # 每千 token 推理成本 monthly_fixed_cost5000, # 固定成本按月摊销 paying_users2000, # 付费用户数 price_per_user30, # 月付费金额 ) print(result)这个模型的输出就是管理层最关心的问题每个月赚不赚钱、需要多少用户才能回本。如果 break_even_users 远高于你的付费用户预测说明项目要么降成本要么提价格要么不做。6.3 小规模验证再规模化ROI 模型只能算纸面账真正的验证要靠小规模灰度。具体做法是先在一个低风险业务场景上线 AI 功能比如单一渠道的客服助手、单纯的文档分类任务跑两到四周把真实调用量、token 消耗、业务指标变化记下来再用实际数据回填单元经济模型。这个阶段重点观察三个数据调用量与业务量的比例、单次任务的平均 token 数、以及业务指标的增量是否达到预期。如果小规模场景都达不到回本线扩大规模只会放大亏损。6.4 用接口日志做持续观测ROI 不是立项时算一次就完事的。服务上线后要持续观测 token 消耗和业务指标。下面是一个简单的调用与用量记录示例import requests import time url http://127.0.0.1:8000/v1/chat/completions payload { model: your-deployed-model, messages: [{role: user, content: 测试用例}], } start time.time() resp requests.post(url, jsonpayload, timeout60) latency_ms (time.time() - start) * 1000 data resp.json() usage data.get(usage, {}) print(latency_ms:, latency_ms) print(prompt_tokens:, usage.get(prompt_tokens)) print(completion_tokens:, usage.get(completion_tokens))在真实生产环境这些数据会汇入监控系统按天统计总 token 数、成本、调用失败率再和业务侧的转化率、留存率做关联分析。只有把成本数据和业务数据放在同一个报表里AI 项目的 ROI 才是可管理的。7. API 服务与批量任务的成本摊销思路Damodaran 讨论的是宏观资本开支但同一个逻辑在 API 服务和批量任务上一样成立固定成本高单位成本低所以必须摊满。如果你的 AI 服务是通过 API 提供给内部或外部用户成本摊销的关键是提高 GPU 利用率和吞吐量。常见做法包括弹性伸缩按调用量峰值扩容低谷缩容避免 GPU 长期空转。批量任务错峰把离线分析、批量生成这类不要求实时响应的任务放到低峰期执行摊薄电力。模型分级简单任务用小模型复杂任务才用大模型不搞一刀切。量化与缓存用量化降低单次推理的显存和计算开销对高频重复问题做缓存直接返回结果。批量任务还有一个容易忽略的问题失败重试和断点续跑。一个几千条的批量生成任务跑了一半因为 API 限流失败如果没有断点记录重跑一次就浪费一倍成本。工程上要按任务维度记录进度每处理完一条就标记完成重跑时跳过已完成条目。下面是一个简单的批量任务日志统计思路# 假设日志按行记录: timestamp, task_id, prompt_tokens, completion_tokens, status # 统计成功任务的总 token 数和失败任务数 awk -F , $5 success {sum $3 $4} END {printf success_tokens: %d\n, sum} task_log.csv awk -F , $5 ! success {count} END {printf failed_tasks: %d\n, count} task_log.csv这些手段不会改变“AI 能不能赚钱”的宏观判断但决定了同一笔资本开支在不同团队手里的回报率。在模型能力趋同之后工程效率就是利润本身。8. 资源占用与性能观察把成本变成可见指标把 Damodaran 的质疑翻译成工程语言就是一句话资本开支的回报取决于资源利用率。技术团队需要让“算力变成收入”的过程可见。至少要监控这几个指标GPU 利用率训练和推理的利用率分开看。如果推理阶段利用率长期低于 30%说明需求没跟上供给。单位 token 成本每个模型、每个场景单独核算不要混在一个平均数字里。单次任务延迟延迟过高会影响用户体验导致调用量上不去间接压低利用率。显存占用模型部署时的 batch size、并发数和显存占用直接相关。显存不够时要么降 batch要么换更小的模型要么上量化。弹性扩缩容效率扩缩容响应不够快高峰期会丢请求低谷期会浪费算力。这些指标最终要汇成一张“成本报表”按周、按月对比。只要成本报表和业务报表放在同一个看板里AI 项目的健康度就一目了然。需要注意显存占用和 token 成本没有统一的“标准答案”不同模型、不同量化等级、不同并发数下差异很大必须按实际测试数据为准不要拿别人的数字当自己的预算线。9. AI 投资评估的常见误区与排查方法结合 Damodaran 的论证和技术项目踩坑经验把常见的评估误区整理成一张排查表误区表现排查方式调整方向把训练当交付模型训练完成但没有业务接入看生产环境真实调用量先做产品接入再定模型训练计划只看模型指标评测集分数高业务指标无变化对比上线前后的转化率、成本、留存建立 A/B 实验直接测业务指标低估推理成本上线后单位成本远超预算核算每千 token 成本与单次任务 token 数换小模型、做量化、限制上下文长度算力过剩GPU 利用率长期偏低监控推理阶段利用率共享集群、弹性伸缩、承接内部批量任务回报周期错配用一年回本的标准要求三年变现的项目重做现金流测算调整管理层预期或缩小项目范围变现路径不清晰功能上线但无法定义付费点回归立项时的降本/增收/提效指标砍掉无法量化收益的功能忽视合规与授权使用未授权数据或生成违规内容检查数据来源和生成内容审核流程建立数据合规审查和生成内容过滤这张表的核心是AI 项目的失败很少是因为模型不够强更多是因为成本、变现和周期三项没对上。10. 最佳实践让 AI 投入经得起财务视角的追问结合前面的分析给出几条可以直接执行的最佳实践。第一建立成本红线。每个 AI 功能上线前必须算出单次任务成本的上限超过红线就触发降级换更小的模型、缩短上下文、或者限制并发。没有成本红线的 AI 项目上线即失控。第二先验证付费意愿再扩大投入。用最小可行版本跑通付费闭环哪怕只有几十个用户也比做一个没有用户的大平台强。用户愿意为哪个功能付钱是唯一可靠的判断依据。第三优先做可量化的降本场景。客服、审核、文档处理、代码辅助这类直接替换人力成本的场景ROI 容易计算也更容易在组织内部获得支持。先在这些场景建立信用再逐步扩展到更难量化的创新场景。第四模型、数据、应用三层分离管理。不要把所有赌注押在一个模型上。接口层做成可替换数据层自己掌控应用层根据业务需求灵活切换模型。这样即使模型价格战开打你的成本结构和竞争力也不会被某一个厂商拖累。第五涉及数据授权、内容生成、人脸和声音等敏感能力时必须先确认授权和合规边界。测试环境可以随便跑上线前必须过内容安全和隐私审查。第六保留一套最小可运行配置。不管上层怎么迭代都要保存一套能稳定复现、成本最低、依赖最简单的最小配置用于日常回归和成本对比。这既是为了稳定性也是为了在预算紧张时能快速降级。11. 总结与下一步回到 Damodaran 的那句话。它真正值得记住的地方不是“AI 不赚钱”这个结论而是它提醒所有人资本开支只是一张入场券不是回报本身。模型能力、GPU 数量和资本开支解决的是供给问题需求是否真实存在、用户是否愿意付费、单位经济是否成立才是决定这笔投入最终是资产还是费用的关键。对技术团队来说最先应该做的不是争论这个判断对不对而是把自己手上的项目按本文的框架过一次明确指标、核算单位成本、跑通小规模验证、建立成本观测。如果你现在就能说清楚每个 AI 功能的单次成本、每月调用量、业务增量三组数据下一轮预算审批你会比大多数团队从容。最容易踩的坑是用评测分数代替业务指标用算力规模代替变现验证。这两条如果没想清楚项目规模越大回头成本越高。下一步可以做的事把本文的单元经济模型脚本改成你自己项目的参数接上真实接口日志跑一个月看看实际数据和你立项时的假设差多少。这个差距就是 Damodaran 说的“不知道 AI 怎么赚钱”在工程层面的具体位置。把这个差距解决掉比追任何一篇观点文章都有用。