复盘7月暴跌我看到了AI资产的三种命运如果把7月这轮AI资产的大幅回调只看作一次情绪波动那很可能错过一个更重要的信号市场对AI资产的定价逻辑正在切换从“技术想象空间”切换到“业务造血能力”。之前很多团队习惯用“我们训练了一个多大的模型”“我们买了多少张卡”“我们接入了多少个Agent”来衡量自己在AI领域的积累但真正经过这轮下跌后就会发现这些标签式资产在大环境逆转时并不一定能帮你抵御风险。换句话说算力、模型、应用、数据这些被统称为“AI资产”的东西正在经历一次明显分层。有人手里握着的是能持续创造价值的资产有人手里握着的其实是成本高昂的负债。这篇文章不讨论任何具体股票我也不会妄下“该不该抄底”的结论而是站在技术人和技术决策者的视角复盘这轮AI资产价值迁移背后的逻辑。重点回答三个问题你团队手头的AI投入到底属于哪一类资产这些资产在市场调整中会走向什么命运以及作为开发者下一步应该怎么调整自己的技术布局。我把AI资产大致分成三种类型基础设施型资产、模型型资产、应用与Agent型资产。它们在暴跌中展示出了完全不同的韧性也对应着完全不同的技术管理策略。下面我们逐一拆开来看。1. 暴跌背后AI资产的价值锚点正在迁移先回到一个基本判断为什么这轮AI资产会迎来集中调整而不是像前两年那样“逢跌必反弹”我的观点是整个AI产业链的技术供给结构已经发生了实质变化市场正在从“预期定价”切换到“业绩定价”。过去两年AI行业的核心叙事是“能力跃迁”。每次大模型版本升级都会带动一轮算力需求预期、应用创新预期和估值抬升。但到今年产业链的情况已经明显不同通用大模型的选择变得极其丰富无论闭源还是开源在对话、写作、代码、摘要这类高频场景上模型之间的差距正在肉眼可见地收窄。当“模型能力”不再稀缺市场就不会再为“我们接下来能做什么”支付溢价而是开始追问“你目前做出来的东西到底有没有人持续使用有没有真实的单位经济模型”。这个转变对技术团队的影响非常直接。以前做AI项目大家习惯的思路是先把模型做大做强先把算力储备到位把基础设施铺好然后再想应用场景。但现在如果一项AI投入不能指向明确的用户价值不能带来留存、转化或成本结构改善它在报表上和实际工程管理中就只是成本项而不是资产项。更准确地说这轮调整的本质是“资产重分类”大量之前被归类为成长型资产的东西正在被重新归类为需要持续投入、回报周期不明确的成本中心。这种重分类不会在一夜之间完成但它会沿着技术栈从上到下层层传导。先传导到估值最敏感的资本市场然后传导到企业技术采购决策最终传导到每一个做AI应用、做模型选型、做算力规划的开发者身上。所以与其担心“AI是不是泡沫破灭了”不如把这次调整当作一次强制体检。接下来要做的不是恐慌而是把手里的AI投入逐项盘点判断每一块资产处于什么生命周期属于哪种命运。2. AI资产可以分为三种类型在讨论命运之前先把分类说清楚。我把AI资产按照技术价值链拆成三层分别对应基础设施、模型能力、应用场景。这里的“资产”不是会计意义上的资产而是指团队为构建AI能力而投入的算力、代码、模型、数据、流程和产品它们能否在未来持续创造价值。资产类型典型形态核心价值来源主要风险点基础设施型AI资产GPU集群、推理平台、向量数据库、特征平台、模型部署服务提供可复用的计算和存储能力降低上层应用开发门槛重资产、固定成本高、利用率波动大模型型AI资产自研基础模型、微调模型、开源模型、模型API接入层提供智能能力是上层效果的来源能力壁垒收窄、边际收益递减、评测和治理成本高应用与Agent型AI资产AI应用、垂直Agent、流程编排、知识库系统、用户交互产品直接满足业务需求沉淀数据形成场景闭环场景分散、留存难、单位经济模型难以跑通这个分类的价值在于它把“AI资产”从一个模糊概念变成了可以逐项讨论的工程对象。不同的资产类型在暴跌中面对的压力完全不同。基础设施型资产承受的是周期性重估压力模型型资产承受的是同质化竞争压力而应用与Agent型资产考验的是真实的用户留存和单位经济模型。三类资产没有绝对好坏但它们需要的管理方式、评价指标和资源配置逻辑截然不同。如果用一句话总结三类资产的命运基础设施型资产会被重估但不会消失模型型资产会被大规模“水电化”而应用与Agent型资产才是下一阶段最有可能穿越周期的价值区。3. 命运一基础设施型AI资产——重资产常态化的考验算力与基础设施是AI行业最先被市场重新定价的资产也是这轮调整中最“受伤”的一类。原因不难理解算力基础设施的建设周期长、投入规模大、固定成本高。当市场从激进扩张转入保守验证阶段最先被审视的就是资本开支的效率。但这里有一个容易误判的地方。基础设施型资产并不会因为短期调整就失去价值AI推理和训练对算力的需求依然是刚性增长的。真正发生变化的是算力资产的价值衡量标准从“峰值算力”转向“利用率”和“单位成本”。你有100张卡但平均利用率只有20%和你有20张卡但利用率稳定在80%后者的资产质量反而更高。从工程角度说提升算力资产质量的核心不在于采购更多硬件而在于让已有算力变成可动态调度的资源池。现代推理服务已经形成了一套比较成熟的做法使用vLLM、SGLang这类推理框架提升吞吐使用Kubernetes或Docker Compose做资源编排使用弹性扩缩容应对流量波动。下面是一个很常见的推理服务编排配置示例既能解释资源组织方式也展示了基础设施资产管理的核心思路。# 文件路径docker-compose.inference.yaml # 说明这是一个面向GPU推理服务的编排示例具体镜像和版本请以实际环境为准 services: vllm-server: image: vllm/vllm-openai:latest command: - --modelQwen/Qwen2.5-7B-Instruct - --served-model-nameqwen-7b - --max-model-len8192 - --gpu-memory-utilization0.9 - --enforce-eager ports: - 8000:8000 shm_size: 2g deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] restart: unless-stopped这个配置的关键点有三处。第一gpu-memory-utilization0.9表示允许推理引擎尽可能利用GPU显存防止内存碎片浪费第二shm_size2g解决了容器内共享内存不足的问题这在多进程数据加载时经常出现第三deploy.resources.reservations显式声明了GPU资源告诉编排系统这个服务没有GPU就无法工作。如果这套服务部署在Kubernetes中同样思路还可以配合HPA自动扩缩容让Pod数量跟着请求量走。在基础设施型资产的管理上稳定性比单纯堆算力更重要。生产环境里GPU驱动版本、CUDA版本、推理框架版本、模型版本这几个东西经常出现互相不兼容的情况。常见的做法是在镜像中固化这些组合做成可复用的部署单元。还要建立GPU利用率的监控面板关注的不只是显存占用还有算力利用率、请求延迟分位数和排队时间。如果一块GPU长期处于低利用率状态就要考虑合并服务或切换成按量计费模式把固定成本转成可变成本。基础设施型资产的最终状态是像云计算一样成为“按需取用”的资源池。短期来看市场会压缩对算力扩张的预期但中长期来看能高效调度算力、能持续降低单位推理成本的基础设施依然是整个AI产业链里最坚硬的那层资产。4. 命运二模型型资产——能力壁垒在加速收窄模型型资产是过去两年最受追捧的AI资产类型。无论是自研大模型、行业微调模型还是基于开源模型做的私有化部署团队都曾经把“我们拥有一个模型”看作最重要的技术壁垒。但经过这轮下跌模型型资产正在经历一个无法回避的现实通用模型的供给已经过剩模型能力本身能带来的竞争壁垒正在快速收窄。为什么会这样因为模型层出现了三个结构性变化。第一开源模型和闭源模型的能力差距肉眼可见地缩小很多垂直场景用开源模型微调后效果已经逼近顶级闭源API。第二模型能力的边际收益递减从GPT-4级别到GPT-4.5级别的能力提升对大多数真实业务场景的影响远小于从“不能用”到“能用”的跨度。第三模型行业本身也在“水电化”大量API厂商以极低价格提供优质模型能力模型从稀缺品变成了商品。这三个变化集中指向一个结论如果你团队的模型资产只是“我们能用某个开源模型跑出结果”那它很难构成真正的技术护城河。真正有持久价值的模型层资产是围绕模型构建的数据回流机制、领域评测集、安全对齐方案和灰度发布流程。换句话说模型本身正在被重新定价但“模型运营”的能力越来越值钱。面对这个局面团队在模型选型时最值得做的一件事就是建立成本对比机制。这里的成本不只是API价格还包括自建推理的人力成本、硬件成本、运维成本和迭代成本。下面这段Python脚本是一个简化版成本对比工具可以用来评估“调用外部API”和“自建开源模型推理”两种方案在给定月活规模下的成本区间。# 文件路径ai_cost_compare.py # 功能对比外部API调用与自建开源模型推理的预估成本 # 注意以下价格仅为示意请填入你实际拿到的价格参数 def estimate_api_cost( monthly_tokens: int, price_per_1k_tokens: float, extra_rate: float 1.2, ) - dict: 估算调用外部API的月度成本。 real_tokens monthly_tokens * extra_rate cost real_tokens / 1000 * price_per_1k_tokens return { monthly_tokens: monthly_tokens, estimated_tokens: real_tokens, api_monthly_cost: round(cost, 2), } def estimate_self_hosted_cost( gpu_count: int, monthly_cost_per_gpu: float, ops_headcount: int, monthly_salary_per_head: float, utilization: float 0.6, ) - dict: 估算自建推理服务的月度总成本utilization表示GPU平均利用率。 gpu_cost gpu_count * monthly_cost_per_gpu labor_cost ops_headcount * monthly_salary_per_head total_cost (gpu_cost labor_cost) / max(utilization, 0.1) return { gpu_count: gpu_count, gpu_cost: gpu_cost, labor_cost: labor_cost, adjusted_total_cost: round(total_cost, 2), } if __name__ __main__: # 示例假设月调用token总量约5000万外部API每千token价格0.02元 api_result estimate_api_cost( monthly_tokens50_000_000, price_per_1k_tokens0.02, ) print(API方案预估成本:, api_result) # 示例假设自建需要4张GPU每张月成本3000元运维人力0.5人月薪3万元 self_result estimate_self_hosted_cost( gpu_count4, monthly_cost_per_gpu3000, ops_headcount1, monthly_salary_per_head30000, utilization0.6, ) print(自建方案预估成本:, self_result)这个脚本的逻辑很简单API方案直接按token量和单价算自建方案则把GPU硬件成本、运维人力成本和利用率折算进去。运行之后你会发现当模型调用量不大时API方案通常更划算一旦调用量增长到某个阈值自建的边际成本开始下降。但脚本没有计算的部分往往才是真正决定成败的自建方案需要团队具备模型运维能力遇到显存溢出、推理延迟劣化、模型幻觉率升高时能不能快速定位和修复。很多团队在计算成本时把人力成本低估了一半。因此模型型资产的正确管理方式是把模型看作一个持续迭代的产品而不是一个一次性的技术成果。模型选型不是越强越好也不是越便宜越好而是要在效果、成本、可控性和演进速度之间找到平衡点。更关键的是要把模型的评估和灰度机制建立起来每次切换模型或更新版本都要用自己业务里的真实数据集做回归测试防止能力提升但业务效果反而下降的情况。5. 命运三应用与Agent型资产——价值向场景和数据收缩三类资产中我最看好的是应用与Agent型资产。这听起来像是一个保守的判断但它背后有明确的技术逻辑只有当AI能力变成用户可感知、可操作、可付费的完整产品时价值链条才真正闭合。模型和算力再强如果到不了用户手里就只是库存。这轮暴跌中最真实的信号是资本市场对“AI应用没有留下用户”这件事失去了耐心。过去两年大量AI产品靠着新鲜感获得了第一批流量但留存率数据并不好看。这个现象说明应用层资产的核心问题不在于用没用AI而在于有没有真正解决用户任务。AI也好Agent也好只是技术手段用户关心的是任务完成效率。这也正是Agent和工作流成为应用层新焦点的原因。相比单纯的聊天机器人Agent能把大模型与工具调用、业务系统、数据查询、人工审核流程连接起来形成可重复执行的自动化流程。一个设计良好的Agent不再是一个“会说话的接口”而是一个能完成任务的系统。它创造的资产价值体现在三个地方任务完成率、单位任务成本和沉淀下来的用户行为数据。那么如何判断自己手里的Agent应用是不是有价值的资产最直接的办法是看数据和日志。下面是一个简化版的Agent会话日志分析脚本它读取JSONL格式的Agent运行日志统计会话总数、任务完成率和平均交互轮次帮助你判断应用是否具备正向资产特征。# 文件路径agent_value_analysis.py # 功能从Agent运行日志中提取核心价值指标 import json from collections import defaultdict from pathlib import Path def load_logs(path: str): logs [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue logs.append(json.loads(line)) return logs def analyze_agent_logs(log_path: str): logs load_logs(log_path) total_sessions len(logs) completed_sessions 0 total_turns 0 scene_counter defaultdict(int) for log in logs: scene log.get(scene, unknown) scene_counter[scene] 1 total_turns log.get(turn_count, 0) # 约定statuscompleted 表示任务完成 if log.get(status) completed: completed_sessions 1 completion_rate completed_sessions / total_sessions if total_sessions else 0 avg_turns total_turns / total_sessions if total_sessions else 0 return { total_sessions: total_sessions, completed_sessions: completed_sessions, completion_rate: round(completion_rate, 4), avg_turns: round(avg_turns, 2), top_scenes: sorted( scene_counter.items(), keylambda x: x[1], reverseTrue )[:5], } if __name__ __main__: result analyze_agent_logs(agent.log.jsonl) print(json.dumps(result, ensure_asciiFalse, indent2))运行这个脚本前你需要一份包含scene、turn_count、status字段的JSONL日志。如果完成率低于50%大概率是Agent的任务拆解或工具调用链设计不合理这时候优化的方向不是换更大的模型而是梳理流程和补充工具如果平均交互轮次过高说明用户每次都要反复纠正Agent产品的自主性有待提升。应用与Agent型资产的价值最终会落在“能不能被规模化复制”上。一个针对某个垂直场景跑通的Agent流程如果可以通过配置化、可视化编排复用到相似场景它就不再是单个项目的人力投入而是能够复利增长的产品资产。数据回流也是同样的道理每次用户行为、每次任务失败都应该变成系统自我改进的养料。只有形成这种“使用—反馈—改进—再使用”的闭环应用层资产才能确立真正的壁垒。6. 团队AI资产体检清单复盘不能停留在概念层面必须落到可执行的清单上。这里我给出一个可以直接在项目周会上使用的AI资产体检清单按资产类型逐项检查。每一项都对应一个具体动作而不是空泛的“关注质量”。资产维度核心检查问题如果存在问题建议动作算力基础设施GPU利用率是否长期低于40%合并低负载服务引入弹性调度优化推理框架参数模型选型现有模型是否经过业务数据集评测建立离线评测集每季度做一次模型能力回归模型运营模型版本变更是否有灰度流程搭建影子模式或金丝雀发布机制应用效果AI功能的次日留存和任务完成率是否持续提升建立业务指标看板设置周度复盘Agent流程Agent失败日志是否有人定期分析建立日志分析pipeline每周输出Top失败原因数据资产用户使用数据是否回流到业务知识库设计数据回写流程定期清洗和更新知识库成本结构单位AI任务成本是否在下降引入成本监控对API和自建成本按月对比这个清单的核心目的是把“AI资产”这个务虚概念转化成团队可以共识的度量指标。如果你发现某个维度的答案长期是“否”那对应的投入就应该被当成待优化风险而不是继续按原先方向追加资源。尤其是在市场调整期快速识别并剥离低效资产比持续加码更重要。7. 实操搭建一个最小可验证的AI应用资产在三类资产的关系里最理想的状态是用基础设施型资产承载模型用模型能力支撑应用用应用沉淀数据再反哺基础设施和模型优化。为了让你直观理解这个过程下面搭建一个最小可验证的AI应用资产示例。它不复杂但涵盖了一条完整的价值链路模型调用、业务API、成本日志和业务指标。先准备好基础环境一台安装Python 3.10及以上的机器建议准备虚拟环境。硬件上如果没有GPU也可以用CPU方式运行一个小模型完成演示更推荐的方式是接入一个兼容OpenAI格式的本地推理服务或云端API这样代码可以通用。# 创建并激活虚拟环境 python3 -m venv venv source venv/bin/activate # 安装依赖 pip install fastapi uvicorn pydantic openai python-dotenv核心代码如下实现一个非常简单的“文章摘要Agent”API。它接收用户输入的文章调用模型生成摘要同时把调用耗时、token用量和业务场景写入本地JSONL日志。这个日志文件就是后续做成本分析和价值分析的原始数据。# 文件路径app/main.py import json import os import time import uuid from datetime import datetime from fastapi import FastAPI, HTTPException from pydantic import BaseModel # 兼容OpenAI格式的客户端可对接vLLM部署的本地推理服务或第三方API from openai import OpenAI app FastAPI(titleMinimal AI Asset Demo) client OpenAI( api_keyos.getenv(OPENAI_API_KEY, EMPTY), base_urlos.getenv(OPENAI_BASE_URL, http://localhost:8000/v1), ) LOG_FILE os.getenv(AGENT_LOG_FILE, agent.log.jsonl) SYSTEM_PROMPT 你是一个专业的文章摘要助手请用不超过200字概括文章核心观点。 class SummaryRequest(BaseModel): article: str scene: str article_summary class SummaryResponse(BaseModel): summary: str session_id: str cost_tokens: int latency_ms: int def write_log(record: dict): with open(LOG_FILE, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) app.post(/summarize, response_modelSummaryResponse) def summarize(req: SummaryRequest): session_id str(uuid.uuid4()) start time.time() try: resp client.chat.completions.create( modelos.getenv(MODEL_NAME, qwen-7b), messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: req.article[:3000]}, ], temperature0.3, ) summary resp.choices[0].message.content latency_ms int((time.time() - start) * 1000) cost_tokens resp.usage.total_tokens write_log({ session_id: session_id, scene: req.scene, status: completed, turn_count: 1, cost_tokens: cost_tokens, latency_ms: latency_ms, created_at: datetime.utcnow().isoformat(), }) return SummaryResponse( summarysummary, session_idsession_id, cost_tokenscost_tokens, latency_mslatency_ms, ) except Exception as e: latency_ms int((time.time() - start) * 1000) write_log({ session_id: session_id, scene: req.scene, status: failed, turn_count: 1, error: str(e), latency_ms: latency_ms, created_at: datetime.utcnow().isoformat(), }) raise HTTPException(status_code502, detailfModel call failed: {e})运行服务uvicorn app.main:app --host 0.0.0.0 --port 8080然后打开另一个终端调用APIcurl -X POST http://localhost:8080/summarize \ -H Content-Type: application/json \ -d {article:这里的文章内容可以用任意一段技术文档代替。,scene:article_summary}预期返回一个JSON对象包含摘要、session_id、cost_tokens和latency_ms字段。同时agent.log.jsonl文件中会追加一条日志。这就是最小的AI应用资产雏形它有业务入口有模型能力有成本记录有业务场景标记。下一步可以把它接入数据看板按天分析单位任务成本、延迟趋势和失败率这就是第5节那个日志分析脚本的数据源。这个最小示例最有价值的地方在于它可以快速回答一个关键问题你的AI应用到底是用成本换体验还是已经形成了可量化的业务效率提升如果连token成本和延迟都没有记录那你手里的AI应用就不能称为资产只能算实验。8. 常见认知误区与避坑指南在AI资产的判断上有几个认知误区相当普遍这里集中梳理一下。第一个误区是“模型越强资产越值钱”。模型能力确实重要但它不等于业务价值。你换成最强模型后用户留存没有变化成本却涨了五倍这就不叫资产增值叫成本升级。正确做法是模型能力与业务指标绑定先定义清楚“换强模型到底要改善哪个指标”再决定是否升级。第二个误区是“开源一定比闭源便宜”。开源模型没有API费用但自建推理需要算力、存储、运维和模型治理投入。小流量阶段自建开源模型经常比直接调API更贵这是很多团队踩过的坑。更理性的方式是用成本脚本动态测算流量达到阈值后再切换。第三个误区是“应用层没有壁垒”。很多人认为AI应用只是包了一层壳换个团队也能做。但真正做过应用的人知道壁垒来自三个地方对具体业务场景的理解深度、对工作流和工具链的编排能力、以及长期运营沉淀的数据和用户反馈。这三者都是时间堆积出来的不是单纯靠调用一个API能复制。第四个误区是“算力越多越安全”。在市场调整期囤积算力反而可能成为包袱。算力资产只有在被高效利用时才有价值闲置的GPU不仅是资金沉淀还伴随折旧和运维成本。更稳妥的做法是采用混合策略日常流量用稳定的固定资源突发流量用弹性资源同时持续压缩单次推理成本。最后还要提醒一个生产环境的安全边界问题。凡是涉及模型API调用、知识库上传和Agent工具执行的系统都要遵循最小权限原则。模型能访问的数据范围要最小化Agent能调用的工具要显式授权日志中涉及个人信息时要脱敏。这些不是纸上谈兵而是AI应用真正进入生产环境后必然要面对的合规要求。9. 如何在波动中守住真正有价值的AI资产复盘这轮暴跌我最深的感受是AI行业的资产定义正在从“你拥有什么”转向“你能持续产生什么”。拥有算力仓库、拥有大模型参数、拥有大量API调用量这些都不再自动等于资产优势。真正有价值的AI资产是团队把技术能力转化为业务结果的组织能力是围绕场景构建的数据闭环是能够在模型快速迭代中灵活切换而不至于推倒重来的系统设计。对技术团队来说可以按照“固定成本最小化、可变成本精细化、价值指标显性化”这条原则来做调整。固定成本尽可能用弹性资源替代避免为一个不确定的需求囤积重资产可变成本要通过成本监控和模型选型不断优化让每一块钱的推理支出都能对应用户价值价值指标要从“我们用了多少AI能力”转向“AI帮助用户完成了多少任务”。这篇文章提供的三种命运分类不是为了给AI资产贴标签而是为了帮助你在下一次市场波动时有一个可以对照的思考框架。下次再遇到大幅调整先别急着讨论“AI是不是不行了”而是把你负责的算力、模型、应用逐项拿出来看看它到底在创造用户价值还是在消耗资源。答案自然会告诉你哪些资产值得继续投入哪些资产应该果断调整。希望这份复盘能给你带来一些可落地的判断依据。建议收藏本文等市场再次出现剧烈波动时再回头对照这份清单会发现很多信号其实早已出现。