想让大模型替自己卖命，一查 Token 账单，却有一种 " 重生之我为大模型公司打工 " 的错觉。

这样的案例，已经开始在不少企业内部上演。

尽管过去一年里，每百万 Token 的推理成本大约下降了 75%，但成本下降的曲线远远比不过消耗量增长的斜率。

全球最大的大模型 API 聚合平台 OpenRouter 统计数据显示，截至 2026 年 3 月，其年化 Token 吞吐量呈现 10 倍增长。

与此同时，资本市场也用脚投票—— Anthropic 年化收入在短短三个月里突破 300 亿美元大关，增幅约为 233% ……

面对 Token 消耗量至少翻了一个数量级的现实，" 如何在高效使用 Token 的同时有效控制成本 " 的问题随之而来。为此，雷峰网邀请 3 位来自产业链不同环节的一线大佬共同解读 Token 膨胀背后的效率账本：

尚明栋：九章云极联合创始人兼 COO ，原微软服务器高可用集群文件系统核心开发工程师，曾参与发布 Windows 7 和 Windows 8，是 SMB 3.0 的主要拟草人之一。

肖嵘：云天励飞副总裁、首席科学家、正高级工程师，历任微软研究院高级研究员、微软必应搜索资深软件工程师、平安产险人工智能部总经理等。

关涛：云器科技联合创始人、CTO，分布式系统和大数据平台领域专家，曾任职于微软云计算和企业事业部，历任阿里云计算平台事业部研究员、阿里巴巴通用计算平台 MaxCompute 和 Dataworks 负责人、阿里巴巴和蚂蚁集团技术委员会计算平台领域组长、阿里云架构组大数据组组长。

在这场圆桌讨论中，身处产业一线的大佬们达成共识：在 Agent 介入生产环节的元年，成本暂时不是企业账单的第一位，真正值得关注的是——花在 AI 上的每一分钱，是否换来了足够分量的业务价值？

顺着这个共识追问，一个更实际的问题浮出水面：如何提高 Token 使用的性价比，让花在 AI 上的钱更好变现为业务价值？这正是本场讨论的核心所在。（关于 Token 消耗与成本优化，作者持续追踪。欢迎添加作者微信   Evelynn7778   交流你所在企业的 Token 账单故事。）

Token 消耗杀手：

路径错误、长上下文、模型超配

如何把 AI 接入工作流，已是当前许多企业都在关心的问题，然而，这背后有许多陷阱。

首先，高消耗未必等于高价值。

当前的 AI，并不能完全像人类一样基于环境的实时状态做出最快的选择。得到结果看似与人工相同，但 AI 在不经意间消耗的 Token 量却可能令人咋舌。

尚明栋举例，同样面对 " 缺乏管理员权限 " 等常规运维场景，码农简单输入类似 sudo（Linux/Mac 系统中用于临时获取管理员权限的指令）的命令就可以马上进入下一步。

但大模型却易出现路径冗余、方案绕远的问题，例如采用重新编译源码的复杂方式绕过简单权限限制，造成大量无效 Token 消耗。

其次，即便让 AI 做同一件事，路径选择也至关重要。

关涛曾经遇到一位客户在对话窗口里，要求大模型直接浏览一份一万行的访问日志并进行数据统计。他指出，这种做法不仅效率低，而且得到的结果极容易出错。

因为大模型的本质是概率预测，数学运算是其弱点。

面对这类计算任务，选择直接在对话窗口输入文本，相当于只让 AI 做文字阅读理解；只有通过上传文件的方式，才能调用 Python 等专业工具，实现真正有效的数据分析。

有时，为了彰显大模型的能力，客户会事无巨细地调用最高性能的大模型，但这是否有必要？

尚明栋的回答是否定的，因为简单的任务交由性能一般的模型也能完成。肖嵘认为，可以将不同性能的大模型比作不同能力的学生。复杂任务可让能力更强的大学生拆解后交由中小学生来完成。后者如果在执行时遇到困难或经多次尝试后仍无法交差，大学生再介入指导和兜底。

为了任务分配能符合学情，关涛还按照性价比与稳定性两个维度，进一步将不同场景划分为四个象限：

SQL 代码迁移等低性价比、高稳定性的场景不适合大模型直接下场，应该利用大模型搭建专门的解决工具；AI Coding 等高性价比、低稳定性场景，鼓励使用最好的模型，以效率换取价值；而 " 双低 " 场景不宜强行用 AI 替代；" 双高 " 场景建议先用最好的模型把场景跑通，验证效果后再逐步切换至性价比更优的模型。

但关涛也坦言，当前每家大模型的迭代周期基本压缩至三个月，模型的能力和性价比因此变得难以预测。对此，云器科技通过内部打造的可观测系统，追踪每个模型的调用成功率、Token 消耗状态、Tool Calling 能力等指标，帮助用户找最适合特定场景的那一款模型。

此外，对长上下文的追求，也是很多用户使用性能强大的模型的根本原因之一。但尚明栋指出，一旦内容过度堆积，反而导致大模型在处理新任务时不断重复回忆此前的对话内容，造成 Token 的浪费。

关涛补充道，如果每次对话都携带大量历史，尤其上下文内容还被反复修改时，会导致缓存失效，对推理成本和响应性能来说都是巨大损耗。

对此，他给出了一个简单却有效的原则：确保上下文内容是围绕同一任务的，这样才更符合模型最初始的设定，且不仅能提升响应速度，还能增加命中缓存的概率——而服务商针对后者所收取的输入 Token 费用，一般会比标准单价低。

此外，尚明栋的团队实测数据显示，仅通过缓存机制这一项，就能避免至少 10% 的重复计算。当前行业内也已经实现这种 " 外挂 "，例如通义千问 3.5 等新一代模型，已在架构层面自带 KV Cache 压缩机制。

降本的三个技术切口：

低精度、稀疏架构、数据升维

当用户能够保持高效的使用习惯，Token 账单的压力，便传导到技术层面。

从算力供给方的角度，尚明栋回忆，去年上半年自家销售团队还在四处兜售算力，到了今年就已经开始抱怨 " 无算力可卖 "。供给的短缺和需求的大幅上升，倒逼算力供给方优化技术。

尚明栋分享了九章云极在算力云建设中的工程实践——基于随机算法推理等策略，实现 PD 分离、四层存储架构设计、将计算、存储与管理网络进行物理分离等目标。

具体到模型架构层面，方法之一，是尚明栋提到的 MoE（混合专家）设计：当万亿参数规模的超大模型内置这种架构时，每次推理实际只需触发 2 至 3 个专家模型，这相当于只调用了二十分之一的参数规模即可完成任务。

此外，肖嵘还提到 DeepSeek 下一代旗舰模型 V4 可实现记忆剥离的核心架构之一 Engram。

这一创新设计提供了一种扩展模型规模的全新思路，将大模型的参数拆分为传统大模型网络的参数（例如 Transformer 参数、嵌入层参数）和存储 " 知识 " 的参数。前者参数规模的增大会显著增加计算的开销，后者则无影响。

来到硬件底层，肖嵘以英伟达 Blackwell 架构 B300 为例，指出了一个关键趋势：业界越来越倾向于使用低精度计算。一个明显的指标对比是，FP4 比 FP8 的算力吞吐量提高了约 3 倍。

但肖嵘也提醒，低精度计算并非 " 免费的午餐 " ——它会引入量化和反量化等一系列额外操作。如果没有硬件层面的专门加速支持，实际收益会大打折扣。

另一方面，Agent 技术的普及对大模型的推理延迟提出极高要求。肖嵘指出，当前大模型推理很难做到极高 TPS（Token 每秒处理速度）的根本原因在于：推理过程中需要高频访问大规模模型参数以及 KV Cache，这对内存带宽造成巨大压力。

以 Meta 的 LLaMA 70B 为例，假设模型参数以 FP16 形式存储在 HBM 中，经粗略估算，在 1000 TPS 场景下，仅模型参数从 HBM 向计算核心供数所对应的带宽需求就可达到百 TB/s 量级，这一数量级已远超当前主流硬件的实际带宽能力。

正因如此，英伟达才在下一代 Rubin 架构中引入了基于 Groq LPU 的 LPX 推理加速系统，构建 GPU 与 LPU 协同的异构推理架构。

其中，GPU 主要负责高吞吐的预填充与注意力计算，而 LPU 则针对延迟敏感的解码路径进行加速。

此外，LPU 还采用高带宽、低延迟的片上 SRAM 以及数据流执行架构，显著降低访存开销，提升单次推理响应速度，并提高单位时间内的 Token 生成密度。（更多算力与算法层面的技术优化，欢迎添加作者微信   Evelynn7778   探讨）

而对于不具备改造算法和算力能力的中小企业而言，数据是撬动 AI 能力最现实的支点。

关涛所在的云器科技坚持 " 数据——信息——知识 " 三级数据体系： 首先确保当前企业的数据能够被 AI 所用，再将企业的数据转化为可共享的知识库。在这个过程中，同时搭建好反馈链路，引领企业 AI 化转型。

每人每月 1000 美元：

Token 经济学的第一笔账

当 Token 利用率尽可能提高之后，从 Token 经济学的角度出发，企业应该如何看待员工的 " 账单 "？

三位嘉宾对于在 Token 上的预算把握已有初步的判断。

肖嵘透露，一旦处理稍显复杂的项目，150 美元可能瞬间见底。因此，云天励飞给研发人员每人每月配备了一定额度的 AI 费用。

他认为这笔投入极其划算。因为相比研发人员动辄三四十万甚至百万年薪，Token 成本只是人力成本的零头。

关涛也印证了这一投入逻辑：当前云器科技没有设置 Token 消耗的上限，员工每月在 AI 辅助开发上的花销约 500 至 1000 美元，目前已有约 20% 的员工能做到高效利用。

作为算力供应商，九章云极自身的员工外部 Token 花费月均成本也已达到 2000 元。

在肖嵘看来，目前仍处于大模型使用的早期阶段，远未达到理想的效率峰值，  企业还没到 " 卷成本 " 的阶段，此刻应全面、大胆地拥抱大模型。

当然，这并不意味着对成本放任自流。肖嵘建议，当大模型使用真正进入普及阶段后，在面对如何摊薄时间成本的问题时，企业可利用晚间等低负载时段错峰提交任务，或通过多 Agent 并行执行任务来提升效率。

此外，订阅制也是一种选择。不过尚明栋提醒，有些时候订阅制只是看起来划算，因为一旦大模型服务负载不稳定，性价比反而可能不如按量付费。他强调，企业一定要从业务价值反推 Token 消耗的性价比。

关涛指出，当前业界主流的消耗量是此前的 10 倍，若没有达到这个增长数字，企业需要反思在 AI 转型上是否已经落后；然而，如果超过了，就要认真审视成本结构。

他以一个极其微小的动作为例：大模型每次哪怕是对 "Hello" 这样简单的交互进行回复，背后都需要一次 API 调用。而单次接入成本约 5 毛钱，当每个 API 都计费、用户高频调用时，这笔原本不起眼的花销瞬间被数量级放大。

基于此，就不难理解为什么当下 " 养龙虾 " 这件事能和 " 破产 " 挂钩。关涛团队实测发现，按照标准 OpenClaw 的使用习惯，每人每月的 API 花费平均值高达 400～500 元。

这意味着，为了养一个数字分身，光调用 API 的开销就已占据每人月可支配收入的约 10%。

除了 API 的调用频率，肖嵘指出，用户具体使用的大模型也在影响 Token 账单。（使用侧还有哪些因素影响 Token 消耗，欢迎添加作者微信   Evelynn7778   交流）

他解释道，参数规模越大，大模型处理复杂任务的能力越强，所能承载的上下文长度也随之增加，因此所消耗的 Token 数量就越多，对应的成本自然水涨船高。

此外，即便处理一样的 Token 数量，参数越大的模型背后涉及的计算量也越大，这也是中美大模型之间价格悬殊的根源。

肖嵘指出，中国模型倾向于采用极端的稀疏化和轻量化设计，在大多走免费路线的情况下，力求用尽量少的训练和推理成本实现较强的智能；而美国企业的模型在参数规模上则要激进得多，价格自然也高出一截。

出于长期成本、低延迟或数据安全的考量，肖嵘认为企业还可以采用本地部署。他介绍，最新的模型量化压缩技术可以在精度无损的情况下，把模型参数和 KV cache 参数分别压缩至 4 比特和 3.5 比特，从而支撑百亿规模的大模型在本地运行。

而具体到硬件选择，值得一提的是最近因 OpenClaw 卖爆的 Mac mini。它之所以备受青睐，正是因为其统一内存和高性能的 M 系列芯片，以及 4000 多块钱的亲民成本。

有了 Token，单一程序员可掌控的代码体量跃升十倍，演讲者长达两周的资料准备时间被大幅压缩，十几岁的孩子可以超前学习竞赛知识、写程序优化游戏代理延迟……

然而，Token 账单的高低，本质是 API 调用频次、模型选型与技术路线共同作用的结果。不过，比起省钱，现阶段更重要的，或许是建立一条将 Token 变现为业务价值的通路。

以下是此次圆桌讨论的精彩分享，雷峰网进行了不改原意的编辑整理：

谈 Token 成本及消耗现状：用量激增 10 倍，账单烧不起

雷峰网 · 胡敏：从去年开始研究怎么用 AI，到今年用上小龙虾，我自己最大的感受是 Token 消耗真的有点 " 烧不起 "。想问问三位嘉宾，有没有感受到 Token 消耗量的变化？以及让你们比较 " 肉疼 " 的案例？

尚明栋：因为我们既是算力提供者，也是消纳者，所以我从两个视角出发来谈。

从供需曲线看，去年行业还在探索算力需求的落地场景，今年高质量算力资源已成为驱动 AI 创新的核心战略资产，需求呈现爆发式增长。

从消纳端看，我认为第一个 Killer APP 可能就是 AI Coding。去年年底 Claude 4.5 出来后，代码生成质量已经能支撑 " 一人公司 "。一个资深程序员原来能管理的代码上限大概 2 万～3 万行，现在借助 AI Coding 可以轻松突破十几万行。

我们公司内部也大量使用，比如每晚做一次全代码审核，包括静态代码的扫描、端口的扫描、安全策略扫描，代码量几百万行，一次扫描消耗六七千万 Token ——但折算成钱，成本其实并不大。

但也有 " 坏例子 "：比如用人工智能去做代码生成的时候，装 Homebrew 遇到权限警告，AI 不懂用 sudo 绕过，反而建议你去下载开源代码重新编译，这一步可能消耗几百万甚至上千万 Token，而实际上人工用一个简单命令就能跳过。这说明需要人工必要介入，不能全部交给 AI 决策。

关涛：我给大家分享两个数字。第一个是我们接主流模型时做的实验：测试 API 是否通畅，说一句 "hello"，模型回一句 " 我能帮你做什么 " ——这一个 API 调用就要 5 毛钱。

第二，如果用标准版的 OpenClaw（未经优化），每人每月的 API 消耗平均在 400～500 元。对比一下，我国人均月可支配收入也就 4000 多人民币，养一个 " 龙虾 " 要花掉十分之一，这个账单确实夸张。

但也有两个趋势：一是每百万 Token 成本从去年到今年大概降了 75%，从 10 美元降到 2 美元左右；二是 OpenRouter 流量增长约 10 倍，Anthropic 收入增长 14 倍。成本降了 3～4 倍，但用量增长了十几倍。所以企业如果感觉 AI 账单在快速增长，一点也不奇怪。

肖嵘：我们公司给研发人员每人配了每月较高额度的 quota。为什么高？因为一个复杂任务跑下来，调用 API 搜索分析下来，150 美元可能就没了。

Token 消耗未来会增加得更厉害——不只 Coding，协同办公领域消耗也很可怕。以前做 PPT 可能需要两周，还要多人帮忙。现在我把框架搭好，告诉大模型我的观点，让它批判或接受，多个 Agent 同时跑，一天就能产出 70 多页专业 PPT。

再说个例子，我们董事长陈宁博士的初中生儿子，他把书丢给大模型，让模型用更形象、交互的方式解释，还生成动画，两天就学完了一本三角函数教材。他玩美国原神网络延迟，找大模型聊完天，模型直接写程序优化掉了。所以没有科班背景的人，借助 AI 能做出很多想象不到的事情。

Token 成本上升的原因我总结一下：模型越大越好用，上下文越长效果越明显，这两个维度都让 Token 成本高涨。不同上下文的成本基本呈线性增长。为了服务效率，比如写 PPT 开十几个 Agent 也得跑 20 分钟，最舒服的是 1 分钟出结果。所以另一个趋势是：为了生产效率，成本加倍也愿意。

谈 Token 降本策略：不是所有事都该 AI 干，分层路由 + 上下文精简是关键

雷峰网 · 胡敏：那么企业到底怎么省 Token？先从使用侧聊起，有没有实操方法或手册？

尚明栋：省 Token 首先要搞清楚 Token 花在哪，才能对症下药。从企业算账角度，Token 消耗量和效率提升、价值增值要建立映射关系。首先人群在扩大，最早从技术人员扩展到全员使用，这是正向的，但要避免浪费：

第一，模型滥用，不是所有任务都需要万亿参数的大模型，简单查询用小模型即可；

第二，避免上下文堆积——历史对话和检索结果反复投喂，每轮都在重复支付成本；

第三，优化低效工作流，比如刚才那个 Homebrew 的例子，人工一个 sudo 命令就能解决，AI 却绕了一大圈。

从使用者角度，提示词要短、清晰，能走规则化流程的就不让大模型做；控制输出长度，避免无效重试。

从技术角度，可以做模型分层路由、KV 缓存（至少能避免 10% 以上的重复计算），以及优化 Agent 结构减少调用次数、降低失败率。

肖嵘：我补充四个方向：使用侧、平台侧、大模型侧、硬件侧都有优化空间。

使用侧最简单的方法是 " 分层 "：把模型能力分成大学生、中学生、小学生。让最强模型（大学生）做任务拆解和规划，中小模型（中学生和小学生）执行具体任务，效果不好再让大模型指导或亲自上手。整体效果差不多，但成本大幅下降。

另外，本地部署 7B～14B 的小模型也是省钱路子，比如用 Mac mini（4000 多人民币）就能跑不错的模型。最新技术如 Google 的 TurboQuant，可以把 KV Cache 压缩到 1/4 或 1/5，结合模型的低精度量化技术，本地部署越来越可行。

还有，控制上下文——不相关的历史对话可以压缩或另开话题。

最后，一定要有自己的提示词模板，就像公司给新员工发员工手册一样，把常见场景的 prompt 固化下来，能省大量重复消耗。会用大模型的人一个人能干 5 个人的活，差别就在这。

关涛：我举三个可避免 Token 浪费的例子：

第一，用法错误——不是所有事情都应该交给 AI，比如把一万行访问日志直接丢给 AI 做统计，又慢又错。正确做法是让 AI 写 Python 程序来处理，或者把数据放在专业系统里用工具做。

第二，上下文信息不足或不准确——比如问 " 上个月 GMV 增长原因 "，数据库里有几十张表都含 GMV 字段，模型不知道用哪张，再贵的模型也解决不了。这是数据问题，不是模型问题。

第三，上下文过分臃肿——每次对话都携带大量历史，不仅浪费 Token 还影响模型效果。特别是当 Context 被修改过、不符合模型设计时，会导致缓存失效，价格和性能都受到伤害。要保证 Context 足够精确，尽量在同一 Session 内追加，这样更符合模型设计，能大幅提升速度、节省 Token。

谈模型采购与分层：性价比不是看单价，而是看 " 单位业务结果成本 "

雷峰网 · 胡敏：从采购侧呢？模型选型、计费方式、购买渠道上，大家有什么心得或踩过什么坑？

尚明栋：采购不能只看单价，要看单位业务结果成本。便宜的模型如果效果不稳定、需要多次重试、人工复核，总成本反而更高。要根据实际应用场景做模型分层和动态路由，简单任务给小模型，复杂有规划的给大模型。

计费方式上，订阅制看起来划算，但如果负载不稳定，综合成本未必如意。还要考虑数据安全、资源稳定等综合因素，最终要回到业务价值来反推性价比。不同部门、不同场景差异很大，需要有专门的小团队来赋能。

肖嵘：我完全同意，目前 Token 是生产力工具，产生的效益远大于成本，建议尽量采用符合需求的模型，成本不是最重要。等大家都用上大模型、效率都上来了，再考虑降本。现在社会变革还没到卷成本的时候，大家都用上大模型后，那时降本就很重要了。

降本的具体方法：一是模型分层（大学生 / 中学生 / 小学生）；二是利用波峰波谷——离线任务放在晚上提交，成本更低；三是订阅制保证用量。

关涛：我们有个方法论：把场景分成两个维度——高性价比 / 低性价比，以及稳定确定性 / 探索不确定性。

高性价比 + 不确定的场景（比如核心代码开发），直接用最好的模型，因为相比人力成本，Token 成本微不足道；

高性价比 + 确定性的场景，先用好模型跑通，再逐步降低模型能力，找到性价比平衡点；

这需要两个系统支持：一个 AI Gateway（灵活切换模型），一个可观测系统（监控成功率、Token 消耗等）。

低性价比 + 确定场景，用模型构建工具形成流水线，而不是每次都靠模型；

低性价比 + 不确定场景：通常用不起来，需要探索其他方式或人工补位；

现在每家模型基本上每三个月就迭代一次，不管是美国还是中国，隔几个月就会有一个新模型达到当前 SOTA 水平。所以很难说哪个模型一定最好——有的性价比好一点，有的能力强一点。可能大家唯一的共识是从 Coding 视角看，Anthropic 的模型更好一些。剩下的，甚至包括最新的视频生成模型，现在很难讲谁是第一名。

所以我们通常建议企业接一个或自己做一个 AI Gateway，能够灵活切换模型。这比现在死磕某一个模型更合理，毕竟整个模型迭代还处在非常高速的发展期。

谈供给侧优化：从平台、模型、硬件、数据四个层面 " 卷 " 成本

雷峰网 · 胡敏：三位都身处 AI 产业链，你们各自在做哪些事来帮企业降 Token 成本？

尚明栋：作为算力供给方，我们在工程化上做了很多：算力云建设的选型配置、PD 分离架构、四层存储架构、计算存储网络分离、随机算法推理优化等，最终提升 Token 产出率。

同时我们也在做模型动态路由，但核心观点是：不要只关心 Token 贵不贵，要关心 Token 花得值不值。这需要把 Token 成本从技术问题变成产品、采购、财务共同管理的经营指标。要建立评估体系，看投入是否值得。

另外，AI 能力要匹配组织管理变革，这放大了人与人之间的差距——有人效率提升 3～5 倍，有人只有 30%，团队里会出现 " 木桶原理 "。现在团队更扁平化，开发工程师变成全栈工程师，一专多能。这不只是工具问题，更是团队组织管理方式的变革。

肖嵘：从平台层、模型层、硬件层三个层次来说：

平台层：做模型分层调度、记忆压缩、任务反思总结，让 " 养龙虾 " 的过程更智能。

模型层：通过更稀疏的架构（如 MoE）、新的注意力机制（如线性注意力、混合注意力），以及类似 DeepSeek 的 Engram 外挂记忆，让模型更快、更聪明、知识面更广。

硬件层：低精度计算（英伟达 Blackwell 引入 FP4，精度降 8 倍但模型精度不跌）、协处理器（如 Groq 的方案，把参数直接放在芯片 SRAM 里，实现极低时延、高 TPS）。这些方向都在让 Token 成本持续下降。

关涛：我们更偏重数据侧。AI 三要素包括算法、算力、数据。对大多数企业来说，前两者通常是买来的，数据是企业提升 AI 能力的关键。我们做三件事：

第一，让企业现有数据平台能被 AI 用好——做语义层（Semantic Layer）、MCP 连接等，让结构化数据成为 AI 的 Ground Truth；

第二，帮企业构建统一、可共享的知识库——把数据升级为信息，信息升级为知识，避免每个 Agent 都重复沉淀记忆和 Skill；

第三，建立反馈链路——通过数据平台采集分析，让企业看清楚 AI 的投入产出比，并能灵活调整模型、Prompt、上下文。

作者持续关注 AI 算力芯片上下游，更多信息可添加作者微信   Evelynn7778   交流。