7 月的这轮 AI 资产调整给过去两年高歌猛进的行业节奏踩了一次刹车。对做技术的人来说市场怎么跌并不是最值得关注的事真正值得关注的是当资金从“听故事”切换到“算收入”AI 产业链上不同环节的真实价值正在被重新排序。这种排序不是简单的股价波动而是一轮技术价值的压力测试。这篇文章想从一个工程视角重新复盘这轮调整。我会把“AI 资产”拆成三层算力基础设施、模型与平台、AI 应用。然后逐一分析每一层在这轮调整中的表现逻辑以及它们接下来的三种命运——被商品化、持续分化、还是被淘汰。文章最后会落到技术团队最关心的部分如何用这套框架判断自己的 AI 项目、模型选型和基础设施投入而不是靠市场情绪做技术决定。适合的读者是正在做 AI 应用落地的工程师、负责技术选型的架构师以及需要在团队内部说清楚“AI 投入应该收缩还是加码”的技术管理者。文章只讨论技术资产的价值判断方法不构成任何投资参考。1. 先分清“AI 资产”在技术语境里到底指什么1.1 三层资产算力、模型、应用驱动逻辑完全不同当市场讨论 AI 资产下跌时很多人容易把它理解成“整个 AI 行业都不行了”。但 AI 产业链并不是一个整体。站在工程技术视角至少可以拆成三层算力层GPU 服务器、云资源、推理集群、网络与存储。模型层基础大模型、开源模型、模型 API、微调平台。应用层对话应用、Copilot 类工具、Agent 工作流、行业解决方案。每一层的价值来源完全不同。算力层的价值来自“使用本身”只要有人调用模型就会消耗算力使用量直接决定收入。模型层的价值来自“能力差异”能力差距明显时可以收取更高价格能力趋同时价格就会被打下来。应用层的价值来自“业务指标”包括留存率、任务完成率、付费转化而不是模型参数规模或榜单分数。这三层资产的命运自然不同。基础设施层跌的是估值不是需求模型层跌的是利润率不是使用率应用层跌的是存活率——大量应用根本没有真实用户调整一来最先被清理。1.2 为什么 7 月这轮调整本质是“估值重定价”7 月的调整从现象看是资金层面的事件但支撑这轮调整的技术背景很清楚模型能力增长不再像早前那样陡峭开源模型与闭源模型的能力差距明显缩小token 价格持续下调而应用层始终没有出现足够多的、可以证明收入质量的爆款产品。换句话说市场此前给 AI 资产的定价默认了“增长永远继续、毛利永远保持”。当这些假设逐步被证伪估值就需要重新计算。对技术团队来说这个变化的实际影响是以前论证一个 AI 项目可行可以说“大模型能力会持续提升所以这个方向一定有机会”现在必须回答“你的场景是否已经具备可用性、是否有人真的在持续使用、单位成本是否合理”。市场情绪只是外部背景真正决定项目去留的是这几个技术问题。1.3 三种命运对应三种价值模型先把三层资产的价值逻辑、核心指标和主要风险列成一张表后面所有章节都围绕这张表展开。资产层典型对象价值来源核心指标最大风险算力基础设施GPU 云、推理集群、分布式训练平台使用量和供给稀缺性集群利用率、单位 token 成本、毛利率供给过剩导致价格战模型与平台基础大模型、开源模型、API 服务能力差异和生态锁定基准分数、API 单价、开发者调用量能力趋同后商品化AI 应用对话产品、Copilot、Agent、行业方案业务指标提升和用户留存留存率、任务成功率、付费率缺少真实壁垒被淘汰三种命运不是随机发生的而是由“价值来源是否稳定”决定的。算力层的价值来源最稳定模型层正在从稳定走向不稳定应用层大部分从一开始就不稳定。理解了这一层再看 7 月的调整就会有更清晰的分析框架。2. 第一种命运基础设施层的需求是真的但定价权在转移2.1 基础设施层为什么是“真实需求”而不是“故事”一个基本的技术判断是大模型的使用量在过去两年经历了数量级增长只要模型被调用GPU 就会被消耗推理成本就是一张硬账单。算力基础设施不像应用层那样需要“爆款产品”来证明自己它的需求来自整条产业链最底层。所以当市场情绪退潮算力资产虽然也会出现波动但基本面不会出现断崖式恶化。但这里必须区分训练需求和推理需求。训练需求具有脉冲性大厂训练一个新模型时集中采购训练完成后需求回落推理需求具有持续性它跟着线上调用量走。这轮调整中市场更认可推理收入而不是训练订单本质上是在判断需求的可持续性。对技术团队来说自建集群前也要先想清楚你的需求是脉冲式的训练任务还是持续增长的推理流量。2.2 判断算力资产健康度的三个技术指标判断基础设施层资产是否健康不要看宣传口径要看下面三个技术指标。集群利用率平均利用率高说明供需紧张利用率低说明算力闲置投入产出比恶化。利用率需要按天、按周统计只看峰值没有意义。单位 token 成本包括电力、散热、折旧和运维是衡量算力效率的核心指标。不同机型的单位成本差异很大量化时要使用真实负载曲线。推理毛利率不是 API 标价而是扣除算力成本之后的毛利。价格战出现时毛利率下降最快的算力资产最危险。这三个指标共同回答一个问题算力资产到底是在创造利润还是在消耗资本。市场调整期答案会很快暴露。2.3 用单位经济模型估算一个推理服务的真实成本这里可以动手做一件很实际的事。假设你正在评估一个自建推理服务的成本可以用一段 Python 脚本粗略估算单次请求的 token 成本和毛利。# 单次请求的 token 费用估算 prompt_tokens 2000 # 用户输入 系统提示约 2000 token completion_tokens 500 # 模型输出约 500 token # 以某类 API 价格作为参照单位美元/百万 token input_price 3.0 output_price 15.0 input_cost prompt_tokens / 1_000_000 * input_price output_cost completion_tokens / 1_000_000 * output_price unit_cost input_cost output_cost # 假设单次请求对外收费 0.08 美元 unit_revenue 0.08 gross_margin 1 - unit_cost / unit_revenue print(f输入 token 成本: ${input_cost:.5f}) print(f输出 token 成本: ${output_cost:.5f}) print(f单次请求总成本: ${unit_cost:.5f}) print(f参考毛利率: {gross_margin * 100:.1f}%)这段代码的意义不是给出精确财务模型而是把“这个业务到底划不划算”变成一个可以每日追踪的数值。真实项目里input_price、output_price 要替换成实际合同价unit_revenue 要替换成产品真实定价还要把 GPU 折旧、机房电费和人力成本摊进去。这里有一个常见误区只看 API 单价不看实际调用结构。如果产品是“长输入、短输出”输入 token 占比极高按输入输出不同单价计算成本结构和直觉可能差很多。所以单位成本模型必须基于真实调用日志不能用估算值代替。注意成本模型的作用是建立可追踪的对比口径不是精确财务预测。学习环境可以用示例价格生产环境落地前必须使用真实合同价并包含折旧、电力和人力成本。3. 第二种命运模型层正在被商品化活下来的只有少数3.1 模型层正在经历什么开源追赶、闭源降价、基准趋同模型层的处境用三个现象可以概括。第一开源模型与闭源模型的能力差距不断缩小。在很多常见任务上开源模型已经接近甚至达到闭源模型早期版本的水平。第二闭源 API 价格持续下调。这不是个别厂商的短期促销而是竞争结构变化带来的必然结果。第三benchmark 分数趋于收敛。当多个模型都能达到接近的得分用户不会愿意为微小的分数差距付出数倍价格。这三个现象叠加在一起指向同一个结论模型层的稀缺性正在下降。模型能力仍然是重要的技术资产但它的“资产属性”正在从“能创造超额回报”变成“能维持基本使用门槛”。3.2 商品化困局能力差距缩小后价格成为第一竞争要素“商品化”是一个经济学概念通俗说就是一件产品无论哪家生产用户都觉得差不多于是只能拼价格。大模型正在进入这个阶段。对模型层资产来说商品化的后果很直接单纯卖模型能力的生意毛利率会被不断压缩。只有模型能力没有数据、生态或行业深度很难建立护城河。今天领先的模型可能在下一个版本就被追平。能力领先只是暂时状态不是长期资产。这并不意味着所有模型都会失败而是意味着“只做模型”的商业模式会越来越难。模型层能继续存在的形态一定是在模型能力之外还叠加了数据、生态或垂直场景。3.3 什么模型资产能活下来数据飞轮、生态和垂直能力在商品化背景下模型层资产能活下来的通常具备以下至少一种特征。数据飞轮用户在使用中持续产生数据模型通过反馈闭环不断改进。数据是别人拿不走的积累也是模型效果持续领先的根源。开发者生态不是“模型好所以有人用”而是工具链、插件、社区、兼容层都围绕这个模型建立起来用户迁移成本高。垂直能力在特定行业或特定任务上的表现显著优于通用模型例如代码、法律、医疗、工业设计。垂直优势来自数据和场景不来自参数规模。对技术团队来说选择模型时不要只比较 benchmark要问三个问题这个模型的能力是否能转化为我们业务中用户可感知的提升我们的使用是否会积累别人拿不到的数据如果明天出现一个更便宜且能力相同的新模型我们迁移的成本高不高如果三个问题的答案都是否定的那么这次模型选型很可能是“随时可替代”的不应该投入过多定制化开发。反之如果数据飞轮成立即使模型本身商品化你的资产仍然有独立价值。4. 第三种命运应用层会分化成“薄封装”和“真壁垒”4.1 应用层最容易证伪的原因应用层是离用户最近的一层也是叙事空间最大的一层。聊天助手类产品出现后大量产品只是把模型 API 包了一层界面本质上没有独立价值。这类产品在模型能力较差时还能提供“新奇的体验”当模型本身变得越来越好用、官方产品越来越完善后薄封装应用的用户会不断流失。应用层在调整期最先“现形”原因很简单市场可以容忍基础设施亏损因为它有明确的使用量和成本曲线可以容忍模型层低价因为模型还有迭代空间但应用层只有两个结果——有人长期用或者没人用。没有留存、没有复购、没有数据积累的应用无论包装得多么完善都会在资金退潮后迅速枯萎。4.2 薄封装应用为什么会在调整期最先出局薄封装应用通常有以下特征没有自研模型能力也没有数据积累。用户价值完全来自底层模型模型能力变化时用户直接流失。没有成本优势在 API 价格战中反而被挤压。没有工作流绑定用户随时可以切换到同类工具。判断一个 AI 应用是不是薄封装最直接的方式是观察“去掉大模型之后产品还剩什么”。如果只剩下一个输入框和一份聊天记录那它没有形成自己的资产。在 7 月这轮调整中最先被市场质疑的正是这类资产它们有流量故事但没有收入质量。4.3 真正壁垒工作流嵌入、数据资产和任务闭环能活下来的应用层资产通常满足下面三个条件之一。工作流嵌入产品嵌入了用户已有的工作流程例如客服系统、代码仓库、财务审批、供应链管理。离开产品会带来明显的中断成本用户不会轻易更换。数据资产应用在使用中积累了自己的数据包括用户反馈、标注数据和业务知识库。这些数据反过来让模型输出更准确形成“使用越多越难替代”的正循环。任务闭环应用不只回答问题而是能完成一个完整的业务任务例如自动生成报表并发送给指定人员。闭环越深替代成本越高。还有一个容易被忽略的指标应用对模型能力的“利用深度”。同一个底层模型有的应用只做简单问答有的应用做了复杂的工具调用、多轮校验和人工兜底。利用深度决定了产品在模型能力变化时的抗性也是区分薄封装和真壁垒的分界线。5. 技术团队怎么用“三种命运”框架做 AI 选型决策5.1 自研、采购、集成三条路线的适用边界对企业技术团队来说“三种命运”不只是一个分析视角它应该直接变成选型依据。算力层除非业务体量已经大到按调用付费不划算否则大多数团队不需要自建 GPU 集群。采购云服务是默认选择自建只适合“推理量极大、成本模型清晰、有运维能力”的团队。模型层优先使用 API不轻易微调。当业务数据积累到一定程度、领域效果差异明显时再考虑微调或私有化部署。不要为了“有自己的模型”而自研模型那是投入产出比最低的路线。应用层这是企业最值得投入的地方。只有应用层能接触业务、积累数据、改变工作流才有可能形成真正的壁垒。模型会商品化应用不会。三条路线不是一个选择题而是一个组合。绝大多数团队的最优组合是外部采购算力API 调用模型把全部自研精力投入应用层。5.2 一张可复用的 AI 资产评估表把前面拆解的判断标准合并成一张评估表可以在立项时逐项打分。每项 1 到 5 分总分越高说明这个 AI 资产更有机会进入“持续分化”而不是“被淘汰”。评估维度说明打分1-5使用频率用户每周是否频繁使用还是一周用一次尝鲜任务成功率模型在真实业务任务上的完成比例是否稳定数据积累每次使用是否产生可沉淀、可复用的数据工作流绑定去掉产品是否会造成用户明显的中断成本单位成本单次调用成本与业务收益相比是否站得住模型替代性换一个底层模型产品价值是否大量流失毛利结构成本是否会随着用户量增长而快速恶化一个粗略的参考阈值总分大于等于 28 分值得重点投入21 到 27 分需要先补齐短板低于 21 分谨慎投入优先做小规模验证。这个阈值不是标准答案但能避免团队凭感觉决定项目去留。注意评估表的价值在于让团队围绕同一组指标对话而不是得到一个绝对正确的分数。每个人对同一项打分的差异往往比分数本身更能暴露问题。5.3 成本结构拆解从 token 单价到月度预算选型不能只看单价还要把业务量级带进去。用下面这个示例估算一个 AI 功能的月度增量成本。# 估算一个 AI 功能的月度增量成本 daily_requests 5000 # 日均调用次数 avg_prompt_tokens 1500 avg_completion_tokens 400 input_price 3.0 # 美元/百万 token output_price 15.0 per_request_cost ( avg_prompt_tokens * input_price avg_completion_tokens * output_price ) / 1_000_000 monthly_cost per_request_cost * daily_requests * 30 print(f单次调用成本: ${per_request_cost:.4f}) print(f月度成本: ${monthly_cost:.2f})如果发现这个功能的月度成本已经超过它带来的业务收益就不要纠结“模型能力还不够好”的问题。在 AI 项目里成本失控与技术能力不足是同样致命的失败原因。生产环境还需要额外考虑限流、缓存、批处理和异常重试这些工程手段能显著降低成本但它们必须在设计阶段就纳入架构而不是上线后再补救。6. 复盘不能靠感觉六个指标和一套轻量复盘模板6.1 六个核心指标无论复盘一个产品、一个模型还是一个 AI 方向都建议盯住以下六个指标。调用量DAU 和 API 调用的真实曲线排除测试流量。留存率次周、次月留存。AI 产品普遍会遇到“第一次使用很惊艳第二周不再打开”的问题。任务成功率不是模型答对率而是业务任务完成率例如客服工单解决率、代码生成合并率。单位成本单次调用成本或单任务成本对应前面的成本模型。毛利率收入减去可变成本后的比例反映业务是否具备规模化条件。收入质量收入来自持续性订阅、按量付费还是一次性项目。收入来源越稳定资产价值越高。这六个指标要一起看。只看调用量会误判增长只看留存会忽略成本只看成本又可能错过用户的真实需求。6.2 五个常见误判复盘这轮调整有几个误判反复出现值得单独整理。误判表现为什么错把市场大跌等同于 AI 失效情绪化收缩所有 AI 项目不同层级的价值逻辑完全不同要分层判断把模型榜单排名当成技术壁垒只看 benchmark 选模型榜单分数与业务效果相关性有限把模型能力提升等同于产品价值提升以为换新模型用户就会回来产品价值来自工作流和数据不来自模型版本只看毛利率不看单位成本觉得毛利高就能规模化价格战会同时挤压收入和毛利用调用量代替留存有人用就认为验证成功一次性体验不是真实需求这些误判的共同根源是把“热闹”当成了“价值”。技术团队复盘时要时刻问自己我们盯着的指标到底反映的是外部热度还是内部业务质量。6.3 一套轻量复盘模板每月复盘时可以按下面的清单快速过一遍这个 AI 资产属于哪一层算力、模型还是应用它的价值来源是使用量、能力差异还是业务指标本月调用量环比、同比变化是多少是否包含测试流量留存率是上升还是下降用户离开发生在第几次使用单次任务成本有没有变化价格战是否影响收入如果底层模型明天被替换产品价值还剩多少我们的数据资产在增加还是止步不前下月保留什么、砍掉什么、验证什么这套模板不需要复杂系统一张表格就能维护。关键是把“感觉”替换成“数字”把“市场情绪”替换成“业务事实”。注意复盘时不要只汇报“模型能力提升”这类好消息。更重要的是记录失败样本、成本异常和用户流失节点这些才是调整期真正有价值的信号。7. 对长期技术判断的几点延展7.1 最重要的技术判断这轮调整之后最重要的判断不是“AI 行不行”而是“AI 分层了”。未来一段时间算力层会像水电一样成为基础设施需求长期存在但利润率被压制模型层会快速走向商品化只有少数具备数据飞轮和