模型够用之后，AI 应用真正卡在哪？聊聊 Agentic Coding、国产模型与算力

很多人看到 AI 圈的讨论，容易陷进一个误区：

模型参数越大，能力越强，产品就越有竞争力。

真做过产品的人会苦笑一下。

模型 Demo 跑得很惊艳，用户一多就开始排队；一段对话成本几毛钱，老板看完账单脸都绿了；本地部署刚起服务，显存已经报警。模型能力是一回事，让能力稳定地交付给用户，又是另一回事。

“模型已经够好，短板在算力”是一种很有代表性的行业判断。它不是说模型研发不重要，而是提醒大家：AI 应用进入落地阶段后，拼的不只是模型分数，更是推理成本、响应速度、并发能力和工程调度。

本文不聊空泛趋势，直接把这件事掰开讲清楚。

Agentic Coding 把“做出来”的门槛拉低了

以前做一个 AI 产品，常见画面是这样的：

产品经理写需求；
前端搭页面；
后端接接口；
算法同学调模型；
测试追着各种边界问题跑；
一个小功能，来回拉扯几周。

现在有了 Agentic Coding，流程变了。

你把需求讲明白：

做一个会议纪要工具。用户上传录音后，系统转写、提炼待办事项、按负责人归类，再生成一封能直接发出去的邮件。

编码 Agent 可以帮你搭页面、写接口、生成数据库表、补测试，甚至协助排查报错。人还是要盯着，但一个熟悉业务的人，配合靠谱工具，已经能把 MVP 很快推出来。

这带来一个很直接的结果：

“我能不能做出一个 AI 应用”，越来越不是核心壁垒。

大家都能接模型 API，都能用开源组件，都能让 Agent 帮忙写代码。几天搭出一个“AI 助手”不稀奇，难的是让它经得住真实用户折腾。

真正拉开差距的，是这四件事

你有没有独特数据
- 你掌握的业务文档、流程记录、标注数据、客户反馈，别人拿不到。
- 比如律师团队的历史合同审查意见，比一个通用提示词值钱得多。
你有没有接进真实流程
- 用户不想多开一个聊天窗口。
- 他想在飞书、企业微信、CRM、ERP、IDE 里顺手完成工作。
结果能不能被验证
- “模型说得挺像那么回事”没用。
- 财务对账要数字对得上，客服回复要符合规则，代码修改要能通过测试。
成本和速度能不能扛住
- 内部十个人试用，什么都好说。
- 一万用户同时涌进来，才是见真章的时候。

大模型壁垒没你想的那么绝对

过去，训练一个强模型像造航母。数据、算法、工程、集群，少一项都不行。

现在情况复杂了很多。

开源模型持续进步，训练方法逐渐公开，后训练、蒸馏、微调、推理优化也有了成熟工具链。很多场景根本用不上最顶级的闭源模型。

举个很现实的例子：

一家电商公司要做“商品标题改写”和“差评归因”。它真正关心的通常是：

中文读起来顺不顺；
能不能遵守指定格式；
价格、型号、日期会不会瞎编；
每天处理几十万条时，账单会不会爆；
私有商品数据能不能留在内部。

这类任务里，一个经过业务数据微调的中等规模模型，配合检索和规则校验，常常就够用了。

盯着排行榜最高分，未必能解决业务问题。排行榜像跑车百公里加速，业务现场更像送货：你得看油耗、载重、维修率，还要看路况。

国产模型追赶快，靠的是什么？

追赶并不神秘，核心路径很清晰：

利用公开研究成果，缩短试错周期；
在中文理解、本地知识、行业表达上持续打磨；
用蒸馏和合成数据，把强模型能力迁移到更小模型；
把模型部署、量化、推理框架做得更轻；
围绕企业需求做交付，而不是只刷公开榜单。

对开发者来说，这意味着一个好消息：模型选择更多了。

你不用默认把所有任务都扔给最贵的模型。简单任务交给小模型，复杂推理再升级到强模型，成本能砍掉一大截。

模型能力够了，为什么算力会变成硬骨头？

训练很烧算力，推理同样烧。

而且对多数 AI 应用来说，真正持续花钱的，往往是推理。

用户每发一次消息，系统都要完成一串动作：

接收请求；
拼接上下文、知识库内容和工具说明；
模型逐 token 生成结果；
可能调用搜索、数据库、代码执行等工具；
校验结果，再返回给用户。

用户只有十个时，这套流程很丝滑。用户到了十万，问题就来了：

GPU 显存够不够？
高峰期请求怎么排队？
首字返回要等几秒？
长上下文把吞吐拖垮了怎么办？
模型服务挂了，有没有降级方案？
每百万 token 的成本，业务扛不扛得住？

这就是算力问题的本质：不是“有没有一张卡”，而是能不能持续、稳定、低成本地供给计算。

一个常被忽略的事实：Agent 会放大推理消耗

普通聊天，一问一答就结束了。

Agent 不一样。它会拆任务、反复思考、调用工具、读取网页、改代码、运行测试，失败后还可能再来一轮。

比如让 Agent 修一个线上 Bug，它可能会：

阅读仓库结构；
搜索相关文件；
分析日志；
修改代码；
运行测试；
根据报错继续修；
生成变更说明。

一次任务消耗的 token，可能是普通问答的几十倍甚至更多。

这也是为什么很多团队的 AI 产品刚上线时感觉“效果真不错”，过两周就开始焦虑：用户越喜欢用，服务器和账单越难看。

芯片差距，差的不是一张卡的跑分

谈国产芯片时，讨论很容易滑向两个极端：

“已经完全替代了。”
“完全不能用。”

这两种说法都太粗糙。

芯片能力不是一个单点分数。一个 AI 芯片能不能真正跑进生产环境，要看一整套东西：

算力密度：同样机房空间，能塞下多少有效计算；
显存容量与带宽：大模型和长上下文都很吃这一项；
能耗表现：电费不是小数目，机房散热也不是摆设；
通信能力：多卡、多机协同训练与推理，卡间通信慢就很难受；
软件生态：编译器、算子库、驱动、框架适配、调试工具，缺一个都可能让工程师抓狂；
供货和运维：能不能稳定买到，出现故障谁来处理，周期多长。

很多项目卡住，不是芯片完全跑不动，而是迁移成本高。

原本一套基于成熟 GPU 生态写的训练脚本，换硬件后，算子不支持、精度对不上、性能跑不满、排错没工具。研发团队本来想省成本，结果几个月都耗在适配上。这个坑，真不是靠一句“国产替代”就能填平的。

不过，差距存在不等于没有机会。

在固定模型、固定任务、固定部署环境里，国产算力方案可以通过软硬件协同、模型量化和专门优化，拿到不错的性价比。企业内部知识库问答、文档处理、质检、客服辅助这类任务，就很适合认真评估。

做 AI 应用，别只问“哪个模型最强”

更实用的问题是：

我的任务，到底需要多强的模型？

下面这套分层方式，拿去就能用。

1. 把任务按难度拆开

| 任务类型 | 常见例子 | 推荐方案 | | --- | --- | --- | | 规则明确、重复量大 | 分类、抽取字段、格式转换、标签生成 | 小模型 + 规则校验 | | 有业务知识要求 | 合同问答、产品咨询、内部制度查询 | 中等模型 + RAG | | 多步骤执行 | 查库存、生成报价、创建工单、代码修改 | 强模型 + 工具调用 + 审批机制 | | 高风险决策 | 医疗建议、金融审批、法律结论 | 模型辅助 + 人工复核 + 审计记录 |

别用大炮打蚊子。

让顶级模型去判断“这条评论是物流问题还是质量问题”，就像开跑车去菜市场买葱。能买到，代价也确实有点离谱。

2. 建一条“模型路由”

一个成熟系统，不该只有一个模型入口。

可以这样设计：

用户请求
  ↓
任务分类器
  ├─ 简单任务 → 小模型
  ├─ 知识问答 → RAG + 中等模型
  ├─ 复杂推理 → 强模型
  └─ 高风险内容 → 人工审核队列

这套机制能直接控制成本。

例如，80% 的简单请求交给低成本模型，剩下 20% 的难题再调用强模型。用户看起来没什么区别，团队每月的推理账单可能差很多。

3. 给 Agent 设置“刹车”

Agent 最怕两件事：乱调用工具，死循环消耗 token。

建议至少加上这些限制：

单次任务最大步骤数；
单次任务最大 token 预算；
工具调用白名单；
涉及删除、付款、发信时必须二次确认；
连续失败后的自动终止；
每一步的日志和可追溯记录。

别把 Agent 放进生产环境后说：“你自己看着办。”

这不是授权，这是给事故写邀请函。

一套能落地的算力成本计算方法

别等账单来了才算成本。上线前就该估。

你可以先盯住这四个数字：

日活用户数
每位用户每天请求次数
单次请求平均输入/输出 token 数
每百万 token 的价格或自建推理成本

粗略公式：

每日 Token 消耗 = 日活 × 人均请求次数 × 单次平均 Token

举个例子：

日活：10,000 人
每人每天：8 次请求
每次平均：3,000 token

那么：

10,000 × 8 × 3,000 = 2.4 亿 token / 天

如果你的 Agent 会多轮调用工具，实际消耗还要乘上任务轮次系数。比如平均一次任务要跑 4 轮，成本很快就翻倍。

三个省算力的狠招

缩短无效上下文：别把整份 100 页文档塞进提示词。先检索，再只传相关片段。
做缓存：重复问题、固定模板、热门知识库问答，缓存命中一次，就少一次推理。
模型量化：在可接受的精度损失下，用更低位宽运行模型，显存占用和成本都会下降。

很多产品不是模型不够强，而是上下文管理太粗暴。用户问一句“退款流程是什么”，系统把全部公司制度、历史聊天、产品目录统统塞进去，纯属拿显卡当柴烧。

避坑清单：这几种做法很容易把项目带沟里

只看公开榜单，不做业务测试

榜单高分不等于你的业务高分。

拿 50 到 200 条真实任务做盲测。检查准确率、格式遵从、幻觉率、响应时间和单次成本。真实数据一跑，很多“神模型”就现原形了。

把 RAG 当成万能药

RAG 能减少模型胡编，却不能自动保证答案正确。

检索到错误文档、切分质量差、引用内容过期，模型照样会一本正经地答错。知识库要有版本管理、权限控制和更新机制。

只算 API 单价，不算完整链路

模型调用只是成本的一部分。

向量数据库、对象存储、日志、监控、带宽、人工审核、工程维护，都会写进账单。尤其是 Agent，工具调用链一长，隐藏成本很容易冒头。

一开始就自建大规模集群

如果你的需求还没验证，别急着买一堆卡。

前期用 API 或托管服务验证场景；请求量稳定后，再评估私有化部署和混合架构。别把“技术自主”变成“昂贵的闲置资产”。

给团队的一份行动清单 ✅

如果你正在做 AI 产品，建议这周就把下面几件事排进计划：

拉出过去一周的真实请求，按任务类型分类。
给每类任务标记准确率、时延、token 消耗和人工介入率。
选 2 到 3 个模型做盲测，不要只看宣传页。
给简单任务配置低成本模型，复杂任务再升级。
给 Agent 加步骤上限、预算上限和高风险审批。
建立模型调用监控：错误率、P95 延迟、缓存命中率、单用户成本都要看。
在业务稳定后，再决定是否迁移到私有算力或国产算力方案。

AI 应用的下半场，不是谁把模型名字挂得更大，谁就能赢。

真正能跑出来的团队，会把模型当作发动机，把数据、流程、算力和交付能力当作整辆车。用户不关心你用了几千亿参数，他只关心一件事：这工具能不能替我把活干了，还别太慢、别太贵、别犯傻。