前些天和一个做 AI 应用的朋友聊天他说自己的部门被 CFO 连续追问为什么大模型投入这么多收入却没有明显变化我的第一反应是这个场景我太熟了。过去两年我看到太多 AI 项目在演示环节惊艳一进入生产环境就开始吃钱。同一时间SpaceX 这类公司却靠商业发射和星链订阅把收入不断推高。媒体标题常把这种对比写成“SpaceX 收入飙升AI 支出烧掉数十亿”但真正值得关注的不是哪个行业更性感而是两种完全不同的成本逻辑。很多人把 AI 烧钱归因于“大模型太贵”。但我的判断是AI 项目的核心矛盾不是技术不够强而是成本没有被结构性地控制住。大量团队把资源花在模型训练和 API 调用上却没有建立起从“单次跑通”到“可重复低成本运行”的桥梁。这里我希望能从工程实践角度把几件事拆开说清楚AI 的钱到底烧在哪我们怎么判断该不该花以及一旦已经失控应该从哪里开始止血。1. 为什么 SpaceX 的收入增长和 AI 的巨额支出放在一起对比1.1 航天工程的收入增长靠的是“单位成本下降”SpaceX 的收入增长公开信息里主要来自两块一块是商业发射另一块是星链的订阅服务。商业发射能以更低价格拿到更多订单关键不是单纯降价而是通过火箭回收、高密度发射、垂直整合把单次发射的边际成本不断压低。星链则把一次性的设备销售变成了持续性订阅本质上把前期发射投资转化成了长期可复用的用户资产。这跟 AI 项目有什么关系关系非常大。任何一个高投入的技术项目如果不能让第二次使用比第一次便宜、让第一百次使用比第十次便宜那它本质上一直在“一次性烧钱”。可复用才是成本结构改善的核心。SpaceX 的火箭回收是一种复用AI 项目里的缓存、评估集、模板化提示词、自动化数据管线也是一种复用。从工程经验看评判一个技术投入有没有可能形成正向循环只需要看一个问题这项投入有没有沉淀成可复用的资产。火箭回收沉淀的是硬件资产和飞行数据AI 工程沉淀的是数据管道、评估集和部署经验。如果每次项目都以“新开一个实验”的状态运行那成本就永远停留在天花板。1.2 AI 行业为什么普遍处于高投入低回报阶段AI 行业的支出大头大体上有四类训练集群、推理资源、数据准备与标注、研发人力。这几项叠加起来往往是一个庞大的数字。问题还不在于绝对值高而在于很多支出没有沉淀。训练阶段很多团队反复实验却没有统一的实验记录经常出现同样的模型结构跑了很多遍只是参数略有不同推理阶段线上服务一旦上线每调用一次都要付一次费用如果没有缓存、没有批处理、没有分级模型费用会随用户量线性甚至超线性增长数据准备阶段是隐性成本最高的地方清洗、标注、质检、版本管理每一项都在消耗人力却常常没有计入模型的真实成本。更麻烦的是很多 AI 项目停留在“能力验证”阶段。模型展示出一个不错的效果就把预算申请下来了但到了生产环境输入数据变化、标注标准不一致、接口延迟、回归测试缺失一系列问题导致系统无法稳定运行。于是团队又回到人工处理。这个过程里钱已经花了业务价值却没有形成闭环。这也就解释了为什么一边是 SpaceX 的收入增长一边是 AI 领域的烧钱故事。这类现象并不是说 AI 没有用而是说 AI 的价值还没有被“工程化”。Demo 阶段证明的是可能性生产阶段考验的是可维护性、可观测性和成本结构。把两组对比放在一起不是为了唱衰 AI而是为了重新找回工程思维。2. AI 支出的真实结构烧掉的远不止 GPU2.1 显性成本算力、存储、API 调用如果打开一张云资源账单最容易看到的是 GPU/TPU 实例、对象存储、负载均衡和 API 调用费用。训练阶段实例单价高但使用时间相对集中推理阶段虽然单次价格低但它是持续性的随着用户量增长费用会稳定地占住预算。还有一个容易被忽略的点很多 API 调用其实是重复和无意义的。例如同一份文档被多个流程反复调模型解析没有加缓存或者页面加载时就触发一次大模型调用而实际用户根本没展开那个模块。这些开销不会在单个请求中体现但在月度账单里非常刺眼。所以第一件事不是换更贵的模型而是先看清楚哪些调用是必要的。从成本调优的路径看显性成本反而相对好处理。只要把调用日志打开按接口、按项目维度聚合就能快速找到那些持续空转的资源。真正让人头疼的是下一类成本。2.2 隐性成本数据清洗、标注、评估和返工隐性成本经常比显性成本更可怕。数据准备阶段团队需要收集原始数据、去重、清洗、转换格式、处理缺失值、定义标注规范。一个看起来简单的抽取任务往往要迭代好几轮标注才能让模型稳定复现。这个过程消耗的是人的时间而人的时间没有像 GPU 一样显示在账单上所以很容易被忽略。评估也是隐性成本。模型上线前你需要一个高质量测试集来测量准确率、召回率、鲁棒性每次换模型、改提示词、调参数都需要重新回归。没有评估集团队就只能靠肉眼一次次看输出耗时且不稳定。更昂贵的是返工功能上线后如果发现某个边界情况没有覆盖产品经理重新提需求算法重新调模型测试重新采集数据开发重新发布。一个小时的返工消耗的往往是一个团队一天的成本。我见过很多项目外部看起来调用成本不高但团队里有三四个工程师长期在“人工兜底”。模型给出一个结果再由人工判断能不能用、再手工修改。这种情况下AI 只是给原有流程加了一个“半自动草稿”并没有真正减少人力反而增加了系统复杂度和维护成本。2.3 成本失控的三个常见来源把显性和隐性成本放在一起AI 项目成本失控通常有三个来源。第一是重复实验而不记录。这就像是施工队每次砌墙都不留图纸拆了重砌。同一个方向今天调 prompt明天换模型后天重做数据但没有任何实验归档。结果大量时间花在重新探索上。第二是大材小用。让大模型做可以用规则或小模型完成的任务长期下来成本差很多。比如关键词匹配、固定格式抽取、黑白名单过滤完全用不上大模型的“智能”。第三是无限上下文。把不相关的历史对话、整篇文档、所有字段都塞进 prompttoken 消费快速上升而效果未必更好。上下文过长还会降低模型对关键信息的注意力。注意先别急着优化 prompt先检查你有没有把不需要的内容塞进 prompt。很多 token 账单不是模型造成的而是你的输入太长了。3. 控制 AI 支出先按四层结构重新设计链路3.1 场景分层规则能做的别让模型做在 AI 应用里不是所有任务都值得用大模型。固定格式表单校验、精确匹配、黑白名单、简单阈值判断用规则就能解决成本几乎为零。我们常说的“AI 要改变工作流”不等于“所有文本都要由大模型生成”。工程师需要养成一个习惯接到需求后先问一句“这个问题有没有非 AI 的解法”。如果没有再决定用多大的模型。场景分层可以按这个顺序规则/数据库查询 - 传统机器学习或小模型 - 大模型 API - 本地大模型。越靠前越便宜、越稳定越靠后能力越强、成本越高。把任务分层是控制 AI 支出的第一道闸门。在实际项目里这个分层最好画成一张流程图请求进来先走规则再走小模型最后才到大模型。每一层都带有置信度判断。如果前面的模型已经能给出可信结果就不需要继续向后传递。这个设计既能控制成本也能提高整体响应速度。3.2 模型选型从“最新最强”到“够用且便宜”很多团队选模型时只关注排行榜和参数规模却忘了自己的任务可能只需要基础能力。对于文本分类、情感分析、实体抽取、摘要生成中小尺寸模型在微调后往往能接近大模型效果但成本和延迟都低得多。如果任务确实需要复杂推理、开放域对话或多轮工具调用再考虑使用更大参数或更高级的 API。最优解不是单个模型而是一组模型。一个常见架构是先用规则或小模型做意图识别只有高难度样本才交给大模型处理。另一个做法是级联小模型给出初步结果当置信度低于阈值时再调用大模型。这样做可以显著减少大模型调用次数。落地时要注意每个模型都要设定自己的超时、重试和降级策略不要让某一个模型故障拖垮整体流程。3.3 调用优化缓存、批处理与上下文压缩大模型调用成本主要由 token 数量决定所以优化其实是在优化 token。结果缓存对同一种输入如果结果允许复用就用哈希或相似度索引缓存避免重复调用。批处理在非实时场景里把一批待处理任务合并成批量请求而不是一条条请求。上下文压缩只传入必要的字段和最近几轮对话用检索召回最相关片段而不是把整个知识库塞进 prompt。显式设置 max_tokens每个请求都给定最大输出长度同时控制 temperature避免模型产生过长且不确定的输出。还要注意重试策略。网络抖动时简单重试通常是合理的但要对重试次数和退避时间做限制否则一次超时可能导致请求风暴。批量跑任务前先用一条数据验证整个链路确认输入、输出和日志都正常再放开并发。3.4 评估兜底没有评估的优化都是碰运气改动 prompt、更换模型、调整参数如果只看一两个例子就判断效果这是最常见的返工来源。正确做法是把一小部分真实业务数据标成评估集每次改动后都跑一遍离线评估记录指标变化。线上的效果还要结合 A/B 测试或灰度对比不能只看离线的准确率。评估集不需要很大一百条高质量样本通常就能暴露大部分问题。关键在于固定标准定义清楚“成功回答”的标准是什么多人标注时怎么统一口径。评估集要不断更新把线上出现的失败案例补充进去防止同一个坑反复踩。4. 一套可复用的 AI 投入产出评估框架4.1 用业务指标替换技术指标只汇报“准确率提升 5 个点”决策层基本无感。要让 AI 投入可被理解必须翻译成业务语言。比如客服工单摘要项目看的是“平均处理时长减少了多少”和“一次性解决率有没有变化”内容生成项目看的是“可用内容数量增加了多少”和“人工审核时间缩短了多少”知识库问答项目看的是“用户自助解决率提升多少”。每个项目一开始就要定义 1 到 2 个业务指标并记录基线值。没有基线后面所有“提升”都是讲故事。这也是为什么很多关于“智能程度”的讨论距离工程实践很远你无法用主观感受做预算只能用“单位任务成本”和“业务效果”做预算。4.2 用“单位任务成本”统一度量AI 项目的支出结构很复杂但可以收拢成一个指标单位任务成本。公式为单位任务成本 (推理成本 训练/开发成本分摊 数据成本 人力成本) / 成功完成的任务数这个指标的好处是它同时反映了效果和成本。如果你花了很多钱但成功率很低单位任务成本会非常高。如果你想优化也只有两个方向降低分子或提高分母。如果日志里有 token 数和单价统计成本就是一个聚合过程。下面是一个结构示例字段名要按照你自己日志里的实际字段调整# 示例从 API 日志统计每个项目消耗的 token 与成本 import json total_cost 0.0 with open(api_requests.jsonl, r, encodingutf-8) as f: for line in f: record json.loads(line) prompt_tokens record[prompt_tokens] completion_tokens record[completion_tokens] prompt_price record[prompt_price_per_1k] / 1000 completion_price record[completion_price_per_1k] / 1000 total_cost prompt_tokens * prompt_price completion_tokens * completion_price print(f总成本: {total_cost:.2f})成本计入口径可以参考下面的表格项目阶段成本组成建议计入口径训练/开发GPU、人力、数据准备按项目周期摊销推理/调用API、GPU、存储按实际调用量计评估/返工人力、标注按工时折算基础设施网关、日志、监控按项目分摊4.3 先小规模验证再逐步放大很多团队犯的错误是一上来就做全量数据迁移或全量上线。更稳妥的路径是选一个业务场景准备 100 条真实样例先离线评估再小流量上线观察 3 到 5 天记录成本和效果。如果没有明显改善就停下来查原因而不是继续扩大调用量。小规模验证的阶段核心目标不是“证明模型能力有多强”而是“确认成本结构可接受”。因为一个 AI 功能如果在一百次调用时表现不错可能只是运气在一万次调用时仍然稳定才是工程。4.4 建立停止机制和预算红线在项目启动时就应该想好“什么时候算输”。比如当单位任务成本超过某个阈值或者业务指标在限定期限内没有达到预设提升时就暂停并复盘。这不是悲观念头而是对资源负责。建议设置两类红线成本红线月度 AI 总支出不能超过预算 X超过后自动告警核心接口降级到规则或小模型。质量红线核心场景的成功率低于阈值 Y 时不能继续放量必须回到评估集排查。同时每次预算评审都要看增量而不是看总量。一个项目去年花了 100 万今年申请 200 万不能简单用“业务增长”一笔带过要说明新增的 100 万对应哪些收入增长或成本节约。5. 如果已经失控按这条链路排查和止血5.1 先看账单和日志别急着换模型当你的 AI 项目看起来“很烧钱”第一步不是换模型也不是加更多 prompt 调优而是打开账单和日志。按项目、接口、时间段聚合费用找出成本最高的三个调用来源。很多时候问题一眼就能看到某个测试接口被自动化脚本每分钟调用几百次某个批处理任务因为异常不断重试某个大模型被用来处理只需要查字典的请求。如果日志不完整先补全日志。一个没有调用量、token 数、延迟、错误码、项目标识的 AI 系统本质上是不透明的你无法判断钱花到了哪里。5.2 按数据、环境、参数、架构逐层排查具体可以按四层排查数据层输入是否包含冗余信息有没有缓存文件编码和字段是否正常是否因为脏数据导致模型不停“理解失败”环境层依赖版本有没有锁定GPU 利用率为什么只有 5%并发数是不是太高导致限流服务是否因为内存不足反复重启参数层max_tokens 是否设置过大temperature 是否让输出不稳定超时和重试次数是否合理有没有开启流式输出架构层这个任务有没有走小模型或规则大模型是否只负责最复杂的部分接口是否有降级方案按照这个顺序排查基本能覆盖大多数异常成本。不要一上来就调 prompt这是大多数人的本能但往往不是根因。5.3 常见“烧钱但没效果”的现象与应对现象可能原因应对方向token 消耗高但输出质量一般prompt 太长、上下文未裁剪压缩上下文只保留关键字段调用量不大费用却很高使用了高价格模型评估是否可以用更便宜模型替换同样的任务多次失败缺少 few-shot 示例、评估标准不清补充示例整理失败样本功能上线后没人用流程没有嵌入业务路径回看用户场景调整入口模型效果时好时坏未固定模型版本、温度过高固定版本降低温度这张表不能替代排查但它能给你一个方向。真正定位问题时还是要回到日志和评估集。5.4 判断是否继续投入的四个问题如果项目已经烧了很多钱在砍掉和继续之间可以问四个问题这个任务本质上是“智能问题”还是“工程问题”如果是数据没洗干净、流程没打通那就别继续堆模型。有没有一个小成本方案能达到 80% 效果如果有先切换不要迷恋大模型的满分表现。单位任务成本有没有持续下降的空间随着规模增加如果成本没有下降趋势说明架构有问题。如果今天停掉这个项目业务会受到什么样的明确损失答不上来说明价值不清晰该停。6. 从烧钱到赚钱真正缺的是工程复利6.1 把每一次 AI 实验变成可复用资产SpaceX 的火箭回收不是每次发射都从零开始制造火箭而是把成功验证过的硬件拿回来复用。AI 工程也一样每一次 prompt 调试、每一个评估集、每一条数据清洗规则、每一个部署模板都应该沉淀成资产。下次遇到类似任务不是从头试而是直接调用已有能力。建议团队维护一个“AI 资产清单”包含可复用数据管道、提示词模板库、评估集、模型路由配置、成本监控看板。这些资产的价值会随着项目数量增加而复利增长。很多项目之所以持续烧钱就是因为每次都在重复生产“轮子”却没有把轮子装到同一辆车上。6.2 用产品思维管理 AI 成本成本不能等出了账单再复核而要在需求阶段就写进去。每个 AI 功能的需求文档都应该包含场景描述和用户价值输入输出定义成功标准成本预估按千次调用估算停用条件如果一块功能连“每完成一个任务需要多少钱”都算不清楚那就说明还没准备好上线。这就像发射火箭前不算燃料成本和质量约束注定会在某个环节失控。产品思维不是拒绝投入而是让每一笔投入都对应一个可验证的回报预期。6.3 进入 AI 行业前先学会算账不管你是开发者、产品经理还是技术决策者进入 AI 领域的第一课不是“学会 prompt”而是“学会建模”。这里的建模不是训练模型而是为业务建立成本-收益模型。AI 不是免费的魔法它是一台由 GPU、数据和人力驱动的复杂机器。你只有理解它的成本结构才有可能让它在商业上成立。SpaceX 给技术行业的启示不在于“太空很酷”而在于它证明了即使是极高投入的领域也能通过工程复用降低成本形成持续收入。AI 行业如果还想继续增长同样需要完成从“证明能力”到“控制成本”的跨越。下次你的团队再讨论 AI 预算时不妨先把账本打开哪些调用是必要的哪些实验是重复的哪些数据是脏的哪些流程还靠人肉补齐。不要急着下“AI 没有用”或者“AI 万能”的结论。让 AI 从烧钱变成赚钱不是靠信仰而是靠一层层把成本结构看清楚。这也是我从 SpaceX 的对比里读到的最值得 AI 工程师学习的一句话先算清楚再点火。