很多团队做 AI 项目，预算一超就先骂模型贵。这判断通常是错的。我的判断是：模型费用只是显眼，系统费用才是致命；推理账单只是账面成本，组织迟钝、数据乱流和错误架构，才是真正把利润吃干抹净的黑洞。
这不是替模型厂商洗地。大模型当然不便宜，尤其你一边喊着要“智能体化”，一边又幻想用最贵模型、最长上下文、最密集调用把所有问题一把梭，那账单当然会让 CFO 血压飙升。但真正让我烦的，是另一种更常见的蠢：团队把注意力全放在“每百万 token 多少钱”，却几乎不审视“这些 token 为什么会被浪费掉”。这就像一家餐厅天天研究盐贵不贵，却不研究厨房是不是一直在把半成品扔进垃圾桶。
最近看到一篇讨论 AWS AI/ML 项目成本的帖子，切口是对的：企业 AI 预算失控，很多时候不是因为模型太贵，而是因为数据搬运、跨区域调用、同步流程、缓存缺失和错误的系统边界。这一点我非常认同，但我还要再往前推一步：AI 项目最昂贵的从来不是“智能”，而是“协调”。
模型调用是一笔清楚的成本，写在账单里，谁都看得见；协调成本是一笔脏成本，藏在架构图里、Slack 对话里、失败重试里、权限配置里、以及一堆没人愿意承认的“先这样上线吧”里。前者看起来贵，后者实际上更贵。因为前者可测，后者会伪装成正常运转。
为什么这么说？因为大多数 AI 项目不是死于模型效果不够，而是死于系统工程的低级失控。
第一类失控，是把数据流设计当成上线前最后再补的 plumbing。很多团队做 demo 时很顺：前端发请求，后端调模型，几十个用户试了都说“挺聪明”。一旦进生产，事情就开始变味。日志要不要留？中间结果存哪里？向量索引放哪一层？检索失败怎么回退？同一个文档被不同 agent 重复切片、重复 embedding、重复读取怎么办？跨区域访问是不是在每次调用时都把钱烧给云厂商？这些问题如果在架构阶段没想清楚，后面每增加一层“智能”，都只是在扩大浪费。
最讽刺的是，很多团队嘴上说自己在做 AI 转型，实际工程纪律却停留在“功能先跑起来”。这套习惯做普通 CRUD 还能苟一阵子，放到 AI 系统里就会迅速暴露，因为 AI workflow 天生更长、更分叉、更依赖上下文，而且更喜欢把失败伪装成“看起来还能用”。传统系统报错是炸给你看，AI 系统报错常常是优雅地胡说八道，然后继续消耗你的算力、时间和信誉。
第二类失控，是把云资源单价当成成本控制，把架构选择当成美学偏好。这简直是企业技术管理里的经典幻觉。很多人会认真比价：Claude 便宜还是 GPT 便宜？Bedrock 还是直连 API 更划算？SageMaker endpoint 要不要降配？这些问题不是不重要，但它们的重要性被严重高估了。真正决定项目单位经济模型的，往往是下面这些东西：
- 同一份原始数据是否被多个服务重复读取和转换
- 模型输出是否被缓存、复用、版本化
- 同步链路是否能改成异步批处理
- 失败重试是否有幂等保障，还是每次失败都整链重跑
- 不同团队是否各自建一套相似 pipeline，然后互相不知道对方在烧钱
- 明明一个小模型就够的环节，是否被政治正确地统一升级成“全链路 SOTA”
这里面的每一项，带来的成本增量，往往都远大于你在模型单价上抠出来的那点折扣。说得更难听一点：很多 AI 团队根本不是在做成本优化，而是在做成本 cosplay。 他们热衷于展示自己对 token、显卡和 benchmark 的熟悉，仿佛只要词汇够专业，财务黑洞就会自动变成技术护城河。不会的。烂架构穿上 AI 外衣，还是烂架构。
第三类失控，是组织边界错误。这也是最贵、最难治的一类。AI 项目为什么特别容易超预算？因为它打穿了原本分开的部门边界：数据团队、平台团队、应用团队、业务团队、法务、安全、采购，全部都会被卷进来。但绝大多数公司既没有为这种跨边界协作重写流程，也没有为它重写责任模型。结果就是，人人都在参与，没人真正负责；每个人都能提需求，没有人对全链路成本负责。
于是你会看到一种荒诞但常见的场景：业务部门要求“回答必须尽可能完整”，产品要求“体验不能有等待感”，安全要求“所有调用都要留痕”，法务要求“敏感数据不能离域”，架构组要求“服务拆分要足够优雅”，平台组要求“全部接入统一网关”，最后技术负责人拍胸脯说“没问题，我们会用 agent orchestration 解决复杂度”。听起来很先进，实际上是在给系统判缓刑。因为每加一条看似合理的要求，链路就多一段状态、多一个网络跳点、多一层序列化、多一次权限校验、多一处潜在失败。复杂度不会因为你把它命名为 orchestration 就消失，它只会换个更时髦的名字继续收税。
这就是为什么我越来越反感一种流行叙事：把 AI 项目的胜负手理解成“模型智商”。不是。至少在未来几年里，真正拉开差距的不是谁模型分数再高 3%，而是谁能把数据流、缓存、权限、观测、重试、降级、交付责任这套脏活干明白。在大多数商业场景里，决定 ROI 的不是最聪明的模型，而是最不浪费的系统。
这一点跟很多创业者的直觉相反。创业者天然容易迷恋“能力跃迁”，喜欢讲“如果模型再强一点，我们就能……”；但商业真正奖励的是“稳定兑现”。一个月省 20% 推理费，不一定能救你；但把一条 11 步同步链路砍成 4 步、把 3 次重复读取变成 1 次、把人工排障时间从每天 2 小时压到每周 2 小时，这种改进会直接体现在利润、交付周期和客户信任上。它不性感，但它值钱。
更残酷的是，很多团队连“成本”这个词本身都理解得过于狭窄。他们只算云账单，不算工程师时间；只算 API 调用，不算排障时间；只算模型部署，不算错误答案带来的客户流失。可在真实世界里，最贵的成本常常不是算力，而是错误被系统性放大之后的连锁反应。一次错误推荐，可能触发人工复核；人工复核又要求补日志；补日志导致链路延迟上升；延迟上升让前端不得不做缓存和轮询；轮询拉高基础设施成本；客户体验变差，销售又要求“再调一下模型”。最后所有人都在修补后果，没人回头承认最初的问题其实是架构层面的懒惰。
所以我的建议非常直接，而且可能不讨喜：在你扩模型、扩 agent、扩场景之前，先把 AI 项目当成一个分布式系统，而不是一个魔法接口。 先问清楚六件事：
- 哪一层真正拥有数据？
- 哪一层负责状态？
- 哪一层可以缓存？缓存多久？
- 哪一层必须同步？哪一层其实可以异步？
- 失败之后谁接手？是人、规则，还是另一个模型？
- 全链路哪个角色对最终成本负责，而不是只对自己那一段 KPI 负责？
这六个问题不解决，继续扩 AI 能力，大概率只是把浪费放大。别误会，我不是反对智能体、反对多模型、反对复杂编排。我的判断恰恰相反：这些东西都会越来越重要。但它们只在一个前提下成立——你已经有足够扎实的系统边界和成本纪律。否则，多 agent 不是效率机器，而是烧钱机器；自动化不是规模化，而是规模化制造混乱。
很多人把“AI 原生公司”理解为更敢用模型。我看法没那么幼稚。真正的 AI 原生公司，应该是从第一天就用系统工程的视角看待智能成本：知道哪里该上最强模型，哪里该用便宜模型，哪里根本不需要模型；知道哪些状态必须保留，哪些结果值得缓存，哪些流程必须人工兜底；知道不是每一段“聪明”都值得付费，不是每一次调用都值得发生。
说到底，企业买的从来不是“哇，这模型真聪明”，企业买的是“这玩意儿能否稳定、可控、可解释地替我赚钱”。前者是演示，后者才是生意。把这两件事搞混，是很多 AI 项目赔钱的根。
最后给一句我自己的结论：未来淘汰大多数 AI 项目的，不是模型不够强，而是单位经济模型太难看。 当市场从“讲故事阶段”进入“看利润阶段”，那些靠昂贵推理、混乱数据流和组织甩锅撑起来的项目，会一批一批死掉。留下来的，不一定是最会讲 AGI 叙事的人，而是最会做成本结构设计的人。
这话不浪漫，但很真实。技术史一向如此：真正吃掉世界的，不是最炫的原型，而是最先把复杂性关进笼子里的系统。
—— https://www.80aj.com