价格数据核对时间：2026年7月下旬。文中价格以官方定价页为准，第三方转述的地方我会单独标注。 一开始我以为这篇会写成“模型又便宜了几倍”。真把几家官方价格页翻完，结论反而没那么顺口：最强的那几档没有一路降价，有的主力模型输入价还在往上走。便宜得更明显的，是平时真正拿来写代码、跑客服、做摘要、批量处理文档的那一层。 不是所有模型都便宜了，是能干活的中间档位在往下沉。 过去一年，价格变化最集中的地方不在旗舰档，而在主力档、性价比档、缓存命中和批处理。也就是说，模型厂商没有简单把“最强模型”打折甩卖，而是把更便宜的入口拆得越来越细。 一、先看两张价格表 看价格表之前先统一口径：美元/百万token，输入/输出，不混人民币，不混包月订阅。表里优先用官方API列表价；如果是第三方聚合平台或媒体口径，会在后面单独说明。选型也定一条规则：每家只放它当前最常被开发者拿来干活的那一档，不拿旗舰去对标别家的性价比档，也不拿性价比档去对标别家的旗舰档。 表1：主力档，一年对比 厂商 一年前（2025年7月） 现在（2026年7月） 变化 Anthropic Claude Sonnet 4，$3 / $15 Claude Sonnet 5，首发价$2 / $10（8月31日后回到$3 / $15） 优惠期名义上降了约三分之一，但新tokenizer会让同样文本切出更多token，官方口径约多30%，实际省钱幅度要打折扣 OpenAI GPT-4.1，$2 / $8 GPT-5.6 Terra，$2.5 / $15 输入涨25%，输出涨近一倍 Google Gemini 2.5 Pro，$1.25 / $10 Gemini 3.1 Pro，$2 / $12 按当前价格算，输入涨60% DeepSeek DeepSeek V3，$0.27 / $1.10 DeepSeek V4-Pro，$0.435 / $0.87 输入涨61%，输出降21%，两头打平 表2：性价比档，一年对比 厂商 一年前 现在 变化 OpenAI GPT-4o mini，$0.15 / $0.60 同一型号仍在售，价格没动过 两年持平 Google Gemini 2.5 Flash-Lite，$0.10 / $0.40 Gemini 3.1 Flash-Lite，$0.25 / $1.50 涨150%～275% DeepSeek 一直是$0.14 / $0.28 还是$0.14 / $0.28 两年零变化 阿里 Qwen Plus，约$0.26 / $0.78（第三方聚合平台低价口径） Qwen3.7 Plus，$0.40 / $1.60（官方国际区，256K以内） 官方Plus档位抬高，但不同地域和渠道价差很大 模型价格没有一起下降，真正变化的是价格结构 “性价比档”这个名字听起来该一路走低，但表2里Gemini Flash-Lite反而是涨幅最大的一行。阿里的情况也要小心看，官方国际区、国内区、香港/美国节点、第三方聚合平台的价格并不完全一样，不能只拿最低渠道价当成全网统一价。 ...

先算两笔账。 同样是2000输入token加1000输出token的一次对话，跑500次： 用DeepSeek V4 Flash（输入0.14美元/输出0.28美元每百万token），成本约0.28美元。这时候如果某个应用收你$20/月，账面上就是71倍。 换成Claude Sonnet 5（首发价输入$2/输出$10每百万token），同样规模500次约7美元。这时候$20/月只是不到3倍。 同一句“10倍”，参照系不同，结论能从“离谱”摆到“合理”。这也是这篇文章想讲清楚的第一件事：判断一个AI应用贵不贵，不能只看倍数，要看它到底在用哪个价位的模型，以及这10倍里，哪些是看得见的产品成本，哪些是看不见的加价。 一、中间商加价链条：应用卖的不是一层API 先把这条链条从良性到恶性拆开看，不要一上来就骂“套壳”。 合理的那一层：产品能力叠加 模型API成本只是底层。上面还压着模型路由、并发池、失败重试、内容审核、RAG检索、文件解析、联网搜索、多模态工具、账单系统、客户端开发，最后还有支付通道和应用商店抽成——Apple标准佣金30%，小型开发者计划下，符合上一日历年App收益不超过100万美元等条件的开发者佣金可降到15%；Stripe美国本土卡标准费率是2.9%+30美分。这些都是真实存在、写在合同里的成本。 拿两个真实产品对照： Cursor卖的不是“转发一次对话”，是Agent能力、云端代码库理解、多模型路由——Pro $20/月、Pro+ $60/月、Ultra $200/月（2026年7月定价），价格分层对应的是包含的模型调用额度和优先级，不是纯粹的转发差价。 TypingMind是另一个方向的例子：一次性买断前端功能（Standard档一次性$39，终身授权；更贵的Extended档$79、Premium档$99解锁多模型面板等更多功能），API费用你自己用自己的key去付。这个模式很适合拿来对照——它把“应用费”和“模型费”彻底切开了，你能清清楚楚看到自己到底为界面和功能付了多少钱，用得越多，$39这个门槛摊得越薄。 AI应用加价链条 渠道成本产生的加价：国内的“中转站”生态 国内接大模型API，渠道选不同，价格差距是真实存在的，但多数属于走量折扣、支付便利和接入服务，不一定是欺诈。因为这类中转站价格变动很快，不适合引用几个月前的单一评测价。更稳妥的是看机制：如果渠道方明示模型、单价、发票、服务条款和可用性边界，价差通常属于商业服务；如果它不说明底层模型，还把低价模型包装成旗舰模型，就进入了后面要讲的风险区。 恶性的那一层：套壳与模型偷换 这一层的数据扎实到值得单独拎出来讲。 软件工程师Teja Kusireddy用三周时间逆向了200家拿到融资、公开宣称“自研AI”的创业公司，监控网络流量、反编译JS打包文件、比对API指纹。结果：73%的公司实际是套壳。 最典型的案例：一家号称“革命性自然语言理解引擎”的公司，融资时讲了23次“自研模型”，反编译后发现全部技术含量就是一个系统提示词——“请假装你不是GPT-4”。他们的真实成本约每次查询0.033美元（GPT-4 API输入0.03美元/千token、输出0.06美元/千token，平均一次查询500输入+300输出token），对用户收费每次查询2.50美元，或者$299/月200次——收入约为直接模型成本的75倍。 RAG套壳的情况更夸张：嵌入模型用OpenAI的text-embedding-ada-002，向量库用Pinecone或Weaviate，生成用GPT-4，全部原样调用第三方服务，包装成“先进神经检索+自研嵌入模型”。实际成本约0.002美元/次查询，用户实际支付0.50到2.00美元/次——收入约为直接成本的250到1000倍。调查里200家公司中，真正从零训练模型的只占7%。 这还只是消费级应用。学术界的情况更让人意外。CISPA亥姆霍兹信息安全中心的论文《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》（arXiv 2603.01919）追踪了17个被称为“影子API”的第三方代理服务，发现它们已经被引用进187篇学术论文，其中116篇（62.03%）发表在同行评审会议或期刊，包括ACL、CVPR、ICLR等。论文揭露了三种经济欺骗手段： 信息溢价：收旗舰版的钱，用能力相近但更便宜的旧版本模型顶替——某API标榜提供Gemini 2.0早期版本，实际用2.5版本的价差超过7倍来牟利 折扣替换：原价收费，后台把闭源大模型换成开源小模型——用户高价点名要GPT-5，指纹识别却发现后台跑的是GLM-4-9B 加价倒卖：在前两者基础上再加一层服务费 经过换算，在GPQA的1273次请求口径下，用户按官方标准费率约支付14.84美元，但实际拿到的等价token价值只有5.70到7.77美元——中间商在这个差价里就能赚走过半利润。 这节的结论：同样一句“加价10倍”，产品能力叠加是合理的（Cursor这类），渠道成本是可以理解的（国内中转站几倍以内），但套壳偷换模型这层，价差可以从75倍一路飙到上千倍，这已经不是“贵”，而是欺诈。 二、怎么判断一个AI应用是不是在割韭菜 给两套检查清单，一套给普通用户，一套给要认真评估的开发者/采购方。 普通用户能自己做的5件事 它是否说清楚具体模型版本。只写“顶级模型驱动”、“GPT级智能”而不说具体模型名和额度规则的，要多留心。 它是否说清楚额度口径。“无限使用”通常不是无限token，看有没有每日限额、高峰降级、慢速队列、积分过期这些细则。 它是否把基础转发包装成高级能力。如果只是转发一次对话，却收费接近专业工具的价格，又没有项目管理、文件解析、协作、历史管理这些配套，这个溢价就站不住。 是否存在未明示的模型降级路由。你以为一直在用旗舰模型，实际大量请求被悄悄路由到便宜模型——这不一定是坏事，但应该被告知。 是否有同类的BYOK方案可对照。允许你自带API key的工具（比如上面提到的TypingMind），最容易照出“前端功能”到底值多少钱，因为模型那部分的钱是你自己直接付给厂商的。 更直接的技术侦查（来自Teja Kusireddy的调查方法） 打开浏览器DevTools的Network标签，跟应用的AI功能互动，看有没有直连api.openai.com、api.anthropic.com——中间可以加一层业务逻辑，但AI能力本身不是它自己的。响应延迟也是一个信号：官方API的延迟通常稳定在一个区间，套壳中转站的延迟经常剧烈抖动。网页源码里搜一下有没有系统提示词残留的关键词，比如“永远不要说自己是OpenAI”这类指令。营销语言也是一个粗筛：具体的技术术语大概率是真的，“先进AI引擎”“智能核心”这类模糊词往往在掩饰什么都没有。 面向开发者/企业采购的审计标准 如果是要给生产环境或研究工作流选API，CISPA论文给出的审计协议值得参考：用LLMmap之类的指纹识别工具，通过输出的余弦距离比对判断模型真实身份——论文实测显示，被测的24个模型端点里，45.83%直接未通过指纹验证，另外12.50%表现出与官方模型的巨大偏差，合计过半的“影子API”偷换了底层模型。在高风险任务上验证更直观：官方Gemini-2.5-flash在MedQA医疗基准上准确率83.82%，影子API平均只有36.95%。这不等同于真实医疗诊断表现，但在该基准上已经显示出明显能力缺口。论文给出的最低审计门槛是：至少24次指纹探测、500样本分布测试比对p值、多次独立会话检查延迟和方差是否异常。 三、词膨胀现象：为什么应用的真实成本比你想的大 用户一句话背后的词膨胀税 前两节讲的是纯利润，这一节讲一笔真实存在、但用户从来看不到的成本。 你看到的是一句简单的提问，模型看到的可能是：系统提示词、角色设定、工具定义、历史对话、上传文件摘要、检索片段、格式约束、审查规则，最后才是你那句话本身。这层膨胀不是应用方故意坑你，而是为了让通用模型套上产品人设、遵守话术规范、能调用一堆功能，必须付出的真实代价。 这个现象在学术界有正式名字——prompt bloat（提示膨胀）。论文《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》（arXiv 2505.03275）专门研究了这个问题：当一个应用能调用的外部工具越来越多，把所有工具描述一次性塞进提示词，会导致模型在一堆干扰项里越来越难找到正确的工具——这个现象和“大海捞针”测试是同一个机制，工具池越大，选对工具的准确率下降得越明显。论文设计的检索增强方案，只把和当前任务相关的工具描述注入提示词，实测能把提示词token减少约49%，同时把工具选择准确率从13.62%提升到43.13%，提升超过3倍。反过来说，没做这个优化的应用，光是“膨胀”这一项就在吃掉将近一半的无效token——这些token你不会看到，但每次调用都在计费。 ...

前两篇分别拆了缓存怎么算钱（《同一份材料，为什么第二次交给AI只收1/10？缓存计费拆解》）和这笔钱到底省在哪张显存上（《KV Cache：每读1个token，就要交一笔“显存税”》）。这一篇把两条线合到一起——问题往往不出在缓存机制本身，而出在你喂给缓存的那份提示词，正在悄悄变胖。 一、系统提示词正在膨胀 很多团队的系统提示词，都是这样长起来的。 一开始可能只有一句话：你是一个专业助手，请按用户要求完成任务。后来慢慢补角色设定、输出格式、禁用事项、工具说明、异常处理、合规边界、历史经验、项目背景、风格要求。半年下来，这句话变成了一份几千字的说明书。 系统提示词是怎么变胖的 看起来很专业，像是把模型管住了。问题是，这些字每一轮都要进上下文，每一轮都可能被计费，每一轮也都可能影响缓存命中。 这不是错觉，而且不是哪一家的孤例。 Anthropic在2026年4月30日发过一篇官方博客《Lessons from building Claude Code: Prompt caching is everything》，作者Thariq Shihipar是Claude Code团队成员。他复盘了几个具体翻车案例：曾经把一个很详细的时间戳放进静态系统提示词，曾经让工具定义的排序变得不稳定，还改过工具参数（比如Agent工具可以调用哪些子Agent）——这些看似很小的改动，都破坏过缓存。这条材料很硬，因为不是外部用户猜测，而是做Claude Code的人自己说的。 用户侧也能看到类似现象。anthropics/claude-code的一个GitHub issue（#45188）里，有用户报告Claude Code在2.1.89到2.1.96版本之间，首次缓存创建量从约38-52K token涨到112-119K token，5天左右涨了约7万token。作者说这让可用上下文明显变小，多步任务还没跑完就要频繁手动/compact。他还做过排除法：关掉自定义hook、拔掉候选MCP、删掉过期插件，重新测量体积都没变——说明这次膨胀来自版本本身的迭代。这是一条用户实测个案，不是Anthropic官方确认的数字，引用时需要标清楚。 OpenAI Codex的用户也报告过类似现象（issue #19212）：只问一句“2+2等于几”，就消耗了约1.3万token。他让Codex自己估算这些开销来自哪里，得到的拆解是：系统指令、网页浏览策略、编码风格开发指令、工具schema、以及AGENTS.md和环境上下文。这同样是用户观察，不是官方统计，但说明一件事：Agent类产品的系统开销，很大一部分发生在用户输入第一个字之前。 这不是单一厂商的问题，而是Agent工作流的共同代价。OpenRouter联合a16z在2025年12月发布的实证研究《State of AI: An Empirical 100 Trillion Token Study with OpenRouter》（Aubakirova等人，arXiv:2601.10088）分析了平台上超过100万亿token的真实调用数据，其中一个发现是：平均提示词长度从约1,500token涨到超过6,000token，涨幅接近4倍，驱动因素是工具调用和多步推理这类智能体工作流的兴起。这条数据来自OpenRouter平台的真实流量，是一手实证研究，但样本边界是“OpenRouter平台”，不代表全行业所有调用场景，引用时应保留这个限定。 膨胀本身不一定是错误。真正的问题是，很多膨胀不是因为任务变复杂了，而是因为大家习惯把所有东西都塞进同一份不断变化的系统提示词里。 二、膨胀为什么会拖累缓存 要理解膨胀为什么烧钱，得先理解Prompt Caching到底在缓存什么。 Claude官方文档写得很清楚：缓存层级是tools→system→messages，某一层发生变化，这一层以及它后面的所有层都会一起失效。也就是说，工具定义一变，系统提示词和后面的对话历史都可能要重算；系统提示词一变，后面的对话历史缓存也会被连带打掉。 缓存不认“差不多一样”，只认前缀是否逐字节一致。前面动一个地方，后面内容再长也要重新处理一遍。这时候，系统提示词越胖，一次失效的代价就越大：如果你把当前时间、随机trace、用户ID这类临时信息塞进了本该稳定的前缀里，这个前缀每一轮都不一样，缓存自然吃不到，模型还要反复处理这段越来越胖的上下文。 Prompt Caching 只认稳定前缀 更麻烦的是，缓存写入本身也不是免费的，而且这件事正在变得更贵。Anthropic的写入计费是：5分钟有效期收标准输入价的1.25倍，1小时有效期收2倍，只有命中读取才是0.1倍。而OpenAI在2026年7月9日GA的GPT-5.6系列上，第一次对缓存写入收费——同样是标准输入价的1.25倍，最短缓存生命周期30分钟。更准确地说，OpenAI在GPT-5.6系列开始把缓存写入单独计价；Anthropic侧则早已把5分钟写入、1小时写入和缓存读取分成不同倍率。两边的共同信号是：缓存失效不再只是性能问题，而是可以在账单字段里被直接看见的成本问题。 膨胀还会拖慢响应。前一篇《KV Cache》讲过，模型处理请求分Prefill和Decode两个阶段：Prefill阶段要把完整输入过一遍、把每个token的K和V算出来存好，这一步耗时随输入长度增长；命中缓存时，这一整段Prefill会被直接跳过。NVIDIA NIM的官方基准测试文档里也确认了同一个规律：提示词越长，首字延迟（TTFT）通常越高，因为注意力机制要先处理完整输入、建立好KV缓存，才能开始生成第一个token。用户看到第一个字之前，模型已经先读了一大堆前文——这笔延迟账，跟token计费账是并行发生的两笔账。 一个量级参照：Claude Code官方博客提到，一次100轮的Opus长会话，不靠缓存要花50-100美元输入token费用，靠缓存能压到10-19美元，差距接近5倍。这个量级基本就是“膨胀又频繁失效”和“精简且稳定命中”之间的现实落差。 长上下文还有一重更隐蔽的代价：不一定让模型变聪明。Chroma Research 2025年7月发布的论文《Context Rot: How Increasing Input Tokens Impacts LLM Performance》测试了18个主流模型（含GPT-4.1、Claude 4、Gemini 2.5、Qwen3等），发现即便是很简单的任务，模型表现也会随输入变长而下降，而且这种下降不均匀、因模型而异，跟“待检索信息在上下文里的位置”“是否存在语义相似的干扰内容”这些因素都有关系。换句话说，“模型看得到”和“模型能稳定用好”不是一回事——这也是很多Agent跑到后半程会变得犹豫、绕路、反复确认的原因之一：上下文还在，有效上下文已经被稀释了。 三、怎么写“缓存友好”的提示词 原理和坑都清楚了，落地按优先级排。 ...

你可能遇到过这种情况：让一个Agent改个bug、整理一份竞品资料，或者帮你写一篇文章。你只发了一句话，等账单出来，却发现费用比想象中高很多。 这通常不是平台多算。你看到的“一句话”，在后台已经变成了几十次模型调用。Agent要先理解任务，再查资料、读文件、调工具、看结果；发现不对，还要回头改；改完再跑一遍验证，最后才把结果总结给你。你发出去的是一句话，它执行的是一串来回。 更麻烦的是，Agent自己也很难提前估准这次任务会花多少钱。密歇根大学、斯坦福大学等团队做过一个实验：让Agent动手前先估算自己接下来会用多少token。结果不管换哪个模型，估出来的数字普遍低于实际消耗，预测值和真实值的相关性最高也只有0.39。这笔账连模型自己都很难算准。 这篇文章想讲清楚三件事：Agent的token到底花在哪，为什么它天然比普通对话贵得多，以及一条真实Agent任务的账单拆开后长什么样。 一、先看懂账单里的四个科目 一次API调用里的四类Token 在讲Agent为什么贵之前，先把账单里的几个科目认清楚。不管是OpenAI还是Anthropic，API返回的用量数据里，token通常会拆成几类： input tokens：你喂给模型的上下文，包括系统提示词、历史对话、工具返回内容 output tokens：模型生成出来的内容 reasoning tokens：部分模型在回答前用于内部推理的token，你看不到内容，但通常按输出token计费 cached tokens：命中缓存的重复上下文，单价比普通input低 这些都会出现在每次API调用返回的usage元数据里，是追踪用量和拆账的基本单位。 有个细节很容易被忽略：只要请求里带了tools参数，账单的起点就已经变了。费用不一定等到工具真正调用之后才发生，工具定义本身就会进入请求上下文。哪怕这一轮模型最后没有调用任何工具，这部分内容也可能已经算进input。 Anthropic文档里有个很直观的例子。Claude Sonnet 5只要请求里传了tools，就会多出一段tool use system prompt。如果tool_choice是auto或none，这段是354个token；如果是any或tool，也就是强制模型调用工具，这段会变成474个token。这类费用写在官方文档里，只是很多人在估Agent成本时不会把它算进去。 二、Agent贵在反复读上下文 Agent比普通对话贵，核心原因是它常用的ReAct模式，也就是思考、行动、观察循环。这个循环有个很要命的特点：每一轮都要把前面的历史重新塞回上下文。上一轮的推理过程、工具调用记录、工具返回结果，都会跟着进入下一轮输入。 拆开看，大概是这样： 规划阶段，模型要读任务描述、约束条件和项目背景，先判断从哪里下手。这一步还没真正动工具，但已经开始产出推理和计划。 工具调用阶段，工具定义、调用参数、执行结果都会进入上下文。工具返回的内容不是读完就结束，它会变成下一轮input的一部分。 反思和重试阶段，失败日志、测试输出、之前试过的路径又会被喂回模型。排查越久，历史越厚，下一轮输入就越贵。 Agent贵在反复读上下文 密歇根大学、斯坦福大学等团队基于OpenHands框架，跑了SWE-bench Verified里的真实编程任务。实验覆盖8个前沿模型、500个任务，每个任务独立跑4次。结果很夸张：Agentic Coding任务平均消耗约417万token，是单轮代码推理任务的约3500倍，是多轮代码聊天任务的约1200倍。输入输出token比例达到153.85，也就是模型每生成1个输出token，平均要读153个输入token。普通多轮代码聊天的这个比例只有1.33。 Agent贵，主要贵在模型读得多。历史上下文越滚越厚，账单里最大的一块也跟着越滚越大。 如果再叠上Plan-and-Solve这类架构，成本还会继续放大。它会先生成一份多步计划，再逐步执行每个子任务；而每个子任务里，又可能各自跑一轮完整的ReAct循环。看起来只是任务拆得更清楚了，账单上却可能变成循环套循环。 三、一条真实轨迹里，钱花在了哪几轮 说“Agent会滚账单”还不够，直接看一条真实轨迹更清楚。 还是上面那篇研究，里面公开了一条任务轨迹：任务编号astropy-7336，用Claude Sonnet 4.5跑，一共31轮才完成。研究者把整条轨迹按功能分成五个阶段： 阶段 对应的工作 占总轮次 Setup（规划） 任务理解、环境初始化、复现问题 9.98% Explore（检索） 代码搜索、文件检查、根因分析 30.37% Fix（执行/反思） 代码修改、调试迭代、补丁完善 33.53% Validate（校验） 测试、回归检查 16.59% Closeout（总结） 最终检查、清理、总结输出 9.53% 一条Agent任务的31轮账单轨迹 Explore和Fix加起来接近三分之二。也就是我们平时感觉最耗时间的“查文件”和“改了又改”，确实也是Agent最容易消耗轮次的地方。 再往细看，每一轮的成本主因会来回切换。第1轮主要贵在输出token，因为模型在做初始规划；第10轮主要贵在未缓存输入token，因为它在读测试文件、创建复现脚本；第17轮又变成输出token为主，因为模型在写调试脚本；第23轮和第28轮再次由未缓存输入主导，用在跑测试、清理临时文件；最后第31轮主要是输出token，用来生成总结。 单轮看，输入和输出会交替成为成本大头。拉长看，输入token，尤其是反复带入的历史，才是总账单里最重的部分。即便很多历史命中了缓存，单价已经便宜很多，量一旦大到一定程度，便宜的input照样会超过高单价但数量少的output。 下面这张表可以直接拿去套自己的Agent任务。如果手头有真实usage日志或trace数据，就把数字填进去；如果暂时没有实测数据，也可以先用公开定价做模拟账，但一定要标清楚是模拟，不要写成实测。 阶段 模型回合 工具调用 主要Token来源 容易滚账单的原因 规划 1-2 0 任务、系统提示、项目约束 一开始就带全量规则 检索 5-10 10-30 文件内容、搜索结果、工具返回 工具结果进入下一轮上下文 执行 3-8 5-20 patch、命令输出、错误日志 每次失败都会增加历史负担 反思 2-6 0-5 失败路径、测试输出、候选方案 模型会带着前面的错误继续判断 总结 1-2 0 全部变更和验证结果 输出不多，但输入已经很厚 模型档位也会明显影响同一条轨迹的账单。OpenAI在2026年6月预览、7月正式开放的GPT-5.6系列就是一个例子：Sol每百万token输入5美元、输出30美元；Terra输入2.5美元、输出15美元；Luna输入1美元、输出6美元。同样的token轨迹套进去，最贵和最便宜相差5倍。 ...

数据核对时间：2026年7月下旬。文中标注“网络测算”的数字均非官方数据，仅供方向参考；具体以各厂商官方文档为准。 你可能也遇到过这种情况：豆包平时用得好好的，某天突然弹出一句“今日额度已用完”。你没觉得自己做了什么特别重的操作，但服务就是停在这里了。 免费额度看起来像一个产品规则，其实背后是一笔账。厂商每天都在算：一个免费用户最多可以消耗多少算力？这些消耗能不能被转化、数据、生态位或者广告收入补回来？一旦这笔账变了，额度就会跟着变。 这篇文章聊的就是这件事：AI工具的免费额度到底是怎么算出来的，为什么有时会突然收紧。 一、免费额度先看成本账 免费额度是一笔账 免费不是厂商一拍脑袋决定的。更接近真实情况的算法，大概是这样： 免费额度上限 ≈ 厂商愿意为每个免费用户承担的成本上限 = 这个用户能带来的预期回报（数据反哺、转化概率、生态位、广告收入）− 服务这个用户的边际成本 右边任何一个变量变了，左边的免费额度就会被重新算一遍。所以免费额度很少是一个永远不动的承诺，它更像一个会随成本和商业压力调整的预算线。 这个成本也不轻。网络上有过一组针对豆包的粗略测算，口径不是官方数据，只能看方向：假设日活用户500万，其中30%的人每天用5次生成、转写、解析这类核心功能，日均调用量就是750万次。只算这几类基础操作，硬件成本每天就可能到六位数。这里还没把模型训练、内容安全审核、峰值并发预留的冗余算力算进去。 所以，免费不是技术天然带来的结果，更多时候是厂商用资本、生态位或者增长目标换来的让利。融资节奏变慢、算力成本变高、商业化压力上来，免费额度就很难一直按原来的尺度给。 二、厂商不会告诉你花了多少钱，只会改规则 厂商不会在页面上写“你今天最多只能消耗X元算力”。它会把这笔预算翻译成几种你能感知到的产品规则：几点重置、还能问多少次、还能不能用最强模型。 第一种，是时间窗口。Claude免费版和Pro版都不简单按“每天0点重置”来算，而是用滚动的5小时窗口，再叠加每周总量。规则看起来复杂，目的其实很直接：把用户请求摊到全天，避免大家卡在同一个重置点一起涌进来。 第二种，是按模型分层给次数。Gemini走的是这条路。综合多个独立开发者社区对Google官方限额页面的追踪，口径有差异，但方向一致：轻量级的Flash系列免费额度比较宽，可能到每天1500次请求；旗舰级的Pro系列就收得很紧，每天可能只有50次左右，每分钟请求数也被压到个位数。同样叫免费版，背后用的算力并不是同一档，越贵的模型，免费额度越少。 第三种，是模型降级。很多人以为免费层只是“同一个模型，少给几次机会”，实际更常见的是限次再加降级。你仍然在同一个入口提问，但系统可能已经把你切到更便宜的模型、更低的推理深度，或者更弱的功能组合上。ChatGPT免费版就是类似逻辑：消息数、文件上传、图像生成分别计数，默认模型和推理能力也会受限，免费用户很难稳定使用最强推理模式。 机制 代表产品 逻辑 滚动时间窗口 Claude免费版（5小时+每周） 平滑并发，不按自然日重置 按模型分层的固定次数 Gemini（Flash系列约1500次/天，Pro系列约50次/天） 越贵的模型，免费额度收得越紧 消息数/功能项独立计数+模型降级 ChatGPT免费版 各项功能分别限额，且默认模型和推理深度打了折扣 还有一层更隐蔽：厂商会把功能拆到免费墙和付费墙两侧，而不是简单地对整个产品收费。以豆包为例，免费层保留了大量高频但单次价值密度不高的功能，比如日常聊天、简单文案；长文档精读、批量视频生成、深度数据分析这类明显提高单次产出质量、也更耗资源的功能，则更容易被放进付费区。 免费额度的三种产品化方式 轻度用户每天聊几句、改几段文字，基本感受不到这堵墙。会撞上它的，通常是消耗远高于平均值的重度用户。 三、豆包为什么走到收费这一步 回头看豆包的调整，它不是一次孤立的商业新闻，更像是免费额度这笔账算到某个阶段后的结果。 多方媒体报道显示，2026年5月4日，字节跳动旗下豆包在苹果App Store上线三档付费方案：标准版68元/月、加强版200元/月、专业版500元/月。官方口径是“基础功能永久免费+高阶增值付费”，日常聊天、简单文案、简单翻译等核心功能承诺永久免费且不限次。 这个消息之所以引发讨论，不只是因为豆包开始收费，而是用户马上会担心：免费版会不会变慢？会不会排队？会不会把好模型藏起来？官方没有宣布免费额度缩水，但用户的反应说明了一件事，额度收紧很多时候不会写在公告里，而是慢慢体现在体验上。 第一，用户规模已经大到不能忽略成本。据QuestMobile数据，2026年第一季度豆包月活跃用户约3.45亿。到了这个体量，单个免费用户哪怕只多消耗几分钱，乘起来也是很大的成本。 豆包收费背后的三股压力 第二，上游成本也在变贵。2026年5月9日起，腾讯云宣布AI算力相关产品价格上调5%；阿里云部分产品价格出现上调，公开报道中的最高涨幅达到34%；智谱AI相关订阅和API价格也在年内多次调整，2月GLM Coding Plan提价超过30%，3月GLM-5-Turbo API价格上调20%，4月GLM-5.1继续提价10%。 智谱这几次调价可以单独看一下。假如是在同一条产品线上连续上调，复合涨幅会是： 1 1.30 × 1.20 × 1.10 ≈ 1.716 这意味着同一产品连续涨三次，理论累计涨幅会接近72%。但这里要把边界说清楚：这三次提价分别对应GLM Coding Plan、GLM-5-Turbo API、GLM-5.1，不是同一个SKU连续涨价，所以不能直接写成“同一件商品涨了72%”。更稳的说法是，这几次调价方向一致、间隔很近，反映出2026年上半年模型服务成本在收紧。 第三，收费也是一种用户分层。豆包3.45亿月活里，大量消耗算力的深度用户只占一小部分，但他们的token消耗会远高于平均水平。三档定价的作用，就是把这部分重度用户筛出来，让高消耗和付费对应起来。绝大多数轻度用户每天聊几句、翻译几段文字，可能几乎感觉不到变化。 免费额度收紧最常见的样子，大多不是全面砍掉免费版，而是先卡高消耗场景。ChatGPT从免费版到Go、Plus、Pro多档分层，背后也是同一条路，轻度用户尽量留住，重度用户自然进入付费层。 写在最后 免费额度很难看成厂商的长期承诺，它更像一套会被反复重算的成本模型。算力成本涨了，用户规模大了，变现压力来了，任何一个变量变化，额度都会被重新评估。 只不过这个过程通常不会直接告诉你。它更多会变成限速、排队、次数减少、模型降级，最后落到你的使用体验里。 所以下次再看到一款AI工具说自己完全免费，可以换个角度看：它的用户增长和算力成本是不是越拉越开。两条曲线背离得越明显，免费额度被收紧的可能性就越高。 ...

术语解构系列·MoE路由 文中模型参数数据查证于2026年7月，主要来自官方模型卡片、GitHub仓库或官方博客。模型规格和API价格都可能变化，具体以厂商最新发布为准。 消费级显卡到底能不能拿来做点正经AI的活？ 这个问题不能只看显卡型号，也不能只看模型名字里那个很吓人的参数量。真正要拆成两件事：模型能不能装下，以及装下以后每生成一个token要算多少。 很多人看到DeepSeekV3标着671B参数，Qwen3-235B-A22B标着235B参数，Qwen3-Coder-480B-A35B标着480B参数，第一反应是：这肯定不是消费级设备能碰的东西。 但真实情况没这么简单。 这些模型名字里还有一个更容易被忽略的后缀：A3B、A22B、A35B。它说的不是模型下载包有多大，而是每个token大约激活多少参数。 这篇文章要讲的不是“消费级显卡能不能挑战大厂机房”，而是把这笔账拆清楚：为什么有些大模型看起来很大，跑起来却没那么夸张；为什么有些模型激活参数很小，本地还是很难装下。 一、消费级显卡先看两笔账：装不装得下，跑不跑得动 把几个真实模型摆在一起看： 模型 架构 总参数 激活参数 每token激活比例 DeepSeekV3/R1 MoE 671B 37B 约5.5% Qwen3-235B-A22B MoE 235B 22B 约9.4% Qwen3-Coder-480B-A35B MoE 480B 35B 约7.3% Qwen3-30B-A3B MoE 30.5B 3.3B 约10.8% Qwen3-32B（对照） 稠密 32B 32B 100% 最后一行放了一个稠密模型做对照。Qwen3-32B没有专家、没有路由，32B参数每次都参与计算，激活比例就是100%。 这才是很多人习惯里的“参数量≈计算量”。 但MoE模型不一样。上面几个MoE模型每次真正参与计算的参数，只占总参数的大约5%到11%。 如果DeepSeekV3是一个671B的稠密模型，不管是显存占用还是算力消耗，都会是另一种级别。仅按FP16权重粗略算，671B参数就需要超过1TB空间。可它每个token激活的是37B参数，粗略看主要前馈计算量，更接近一个几十B激活规模的模型，而不是完整671B稠密模型。 这就是消费级显卡选本地模型时最容易混淆的地方：总参数决定你要准备多大的显存/内存去装它，激活参数影响它每个token大概要算多少。 消费级显卡先看两笔账 MoE（Mixture-of-Experts，混合专家）架构做的就是这件事：模型可以有很大的参数池，但每次只用其中一部分。 二、一个类比：医院不需要让全体医生会诊 理解MoE，最直接的类比是医院分诊。 一家大医院可能有几百名医生，覆盖内科、外科、儿科、皮肤科、精神科等几十个科室。这是医院的规模，对应模型的总参数量。 但病人来了，医院不会让所有医生一起会诊。分诊台会先判断这个病人的情况，再派几个对口医生处理。这对应模型的激活参数量。 MoE路由机制：不是所有专家都上场 医院的规模决定了它能覆盖多广的问题；但看一个病人要花多少医疗资源，主要取决于实际出诊的那几位医生，而不是医院挂牌的医生总数。 这套机制翻译回模型架构，对应两个部件： 专家（Experts）：模型里的一组前馈网络模块，可以理解成一批科室。Qwen3-30B-A3B有128个专家，Qwen3-Coder-480B-A35B有160个专家，DeepSeekV3的专家规模更大，还额外设置了所有token都会用到的共享专家。 路由器（Router/Gating Network）：一个很小的判断网络，负责给每个token打分，决定它该交给哪几个专家处理。它就是模型里的分诊台。 路由不是人工写死的规则。不是程序员规定“中文交给1号专家，代码交给2号专家”，而是模型在训练过程中自己学出来的。它会逐渐学会什么样的token该送去哪些专家。 而且这个决策是逐层、逐token做的。同一句话里的不同字词，甚至同一个词在不同层，都可能被路由到不同的专家组合。 三、路由器怎么决定派谁出诊？ 路由器的工作可以拆成三步。 第一步，打分。每个token经过路由器时，路由器会对全部专家各算出一个分数，表示这个专家有多适合处理当前token。 第二步，选择Top-K。模型只保留分数最高的K个专家，其余专家不参与这次计算。模型名里的A3B、A22B、A35B，说的就是每个token大约会激活多少参数。 第三步，加权合并。被选中的几个专家分别处理这个token，再按路由分数把结果加权合并，作为这一层的输出。 几个真实模型的Top-K配置如下： 模型 专家总数 每次激活 Qwen3-30B-A3B 128 8 Qwen3-235B-A22B 128 8 Qwen3-Coder-480B-A35B 160 8 DeepSeekV3 256个路由专家+1个共享专家 8个路由专家+共享专家 这里有个容易误解的地方：A22B不是说这个模型只有22B参数，也不是说下载包只有22B大小。它说的是每个token大约激活22B参数。 ...

术语解构系列·有效算力成本 文中数据来源、查证时间见文末“资料来源”与“资料边界说明”。 一、报价单上少写了一个分母 云厂商的算力报价页，通常只写一行数字：每卡每小时多少钱。 这行数字回答的是，这张卡开着，一小时收你多少钱。它没有回答另一个问题：这一小时里，这张卡有多少时间、以多高效率，真正变成了你的训练吞吐、推理token和业务结果。 这中间少写的分母，就是有效利用率。 这里先把口径说清楚。本文说的有效利用率，不是单一监控面板里的GPU使用率，也不是MFU。它更接近一个算账口径：一张GPU的标称能力，经过工程效率、任务排布和时间满载之后，最后有多少变成了有效产出。 上半年，这个问题被重新摆到台面上。腾讯云运营商解决方案总经理张晋在2026年MWC上海智能数据中心峰会上，给出过一个判断：相关研究数据显示，国内智算中心GPU平均利用率不足30%。他同时用一个公式拆解这个数字： 算力生产力 = 标称算力 × 效能系数 × 满载系数 标称算力是规格书上的数字。效能系数看GPU跑得快不快，报道中给出的平均值约0.6。满载系数看GPU跑得满不满，平均值约0.5。两个系数相乘，100%的标称算力，最终只剩下约30%的有效产出。 30%不是单一监控指标 这不是说所有智算中心的每张GPU监控面板都只有30%。它说的是更综合的算力生产力：既包括卡有没有在工作，也包括跑起来以后有没有被网络、显存、调度、计算气泡拖慢。 还有几条公开信息可以放在旁边看。韦乐平在2025云网智联大会上提到，国内智算中心超过280个，GPU利用率很不均衡，平均不到30%。中国信通院云大所刘如明在2025万卡AI集群建设论坛上给过一组卡时口径：2025年国内智算共算量约38亿卡时，同期用算量约14亿卡时，用算占比36.8%。另有媒体文章转引浪潮人工智能研究院测算，称我国智算中心平均算力使用率约30%。 这些数字不是同一个指标，不能互相当作严格校验。它们共同指向的是一个趋势：很多智算资源建起来了，但还没有稳定转化成足够高的有效产出。 作为对照，并行科技COO乔楠在媒体报道中称，公司算力利用率在90%到95%之间。这个数字是公司口径，不是行业统计，但它提供了一个头部算力运营平台的参照：同样是算力资源，经过跨区域调度和运营管理后，利用率可以和行业平均说法拉开很大差距。 这篇文章要拆的就是这个差距。不是为了证明某个30%一定精确，而是想让读者建立一个核算习惯：GPU报价不能只看每小时多少钱，还要看这份报价背后有多少有效算力真的被用出来。 二、同样报价，单位有效成本可能差三倍 先把公式写出来： 单位有效算力成本 = 实例小时价 ÷ 有效利用率 这里的有效利用率，可以是你自己业务里的GPU非空闲时间，也可以是更严格的有效吞吐口径，比如tokens/s/GPU、样本/s/GPU、每百万token成本。文章前面引用的30%，属于综合有效产出率口径。为了让账算得直观，下面先把它近似代入这个公式。 假设某型号GPU的报价是每卡每小时100元。这个数字只是为了方便心算，不对应任何具体厂商的真实报价。 同样报价，分母不同，成本差三倍 如果有效利用率是30%： 1 单位有效算力成本 = 100 ÷ 30% ≈ 333元/有效GPU小时 如果有效利用率是90%： 1 单位有效算力成本 = 100 ÷ 90% ≈ 111元/有效GPU小时 两者相除，约等于3倍。 这就是标题里的意思。价格表上都是100元一小时，但一边只有三成有效产出，另一边接近九成有效产出，摊到每个有效GPU小时上，成本就不在一个层级。 所以，客户比较GPU云服务器时，只看A厂每小时多少、B厂每小时多少，意义有限。真正该问的是：我的任务在这套平台上能跑到多少有效利用率？能不能排队？能不能错峰？能不能批处理？能不能被更细粒度地切分？能不能和别的任务混部？ 报价只在分子上做文章，利用率决定分母。 这里再补一个容易混的概念：利用率不等于MFU。之前拆1P算力时讲过，MFU衡量的是模型训练实际FLOPS相对硬件峰值FLOPS的比例，回答的是卡在跑任务时算得快不快。本文讲的有效利用率，更关心资源有没有持续产生业务结果。一张卡可以MFU不低，但每天只跑几个小时；也可以一直有任务在跑，但因为通信等待、显存碎片、批量太小，单位时间产出不高。新闻稿和报价表经常把这些词混着用，读者自己算账时要先分清口径。 三、低利用率不是浪费两个字能解释 看到30%这个数字，第一反应很容易是管理不善、资源浪费。但如果把镜头拉远一点，会发现它通常是几类结构性问题叠在一起。 第一，峰谷负载。 之前讲DeepSeek峰谷定价时算过这笔账：GPU集群一天24小时都在产生折旧、电费、制冷和运维成本，但用户请求不是平均来的。上午和下午是高峰，凌晨大量空闲。按平均负载建集群，高峰扛不住；按峰值负载建集群，大部分时间会闲。平台用峰谷价格引导客户错峰，本质上就是在处理这条负载曲线。 第二，采购提前量。 智算中心建设周期以季度、年计，业务需求却是逐步爬坡的。批项目、建机房、采购服务器时，往往按远期规划报规模。落地初期真实负载接不住这么多卡，生命周期前半段自然会压低平均利用率。再叠加GPU架构更新、租赁价格变化和折旧压力，运营方不能只看硬件还能不能用，还要看它在未来几年还能不能以有竞争力的成本产出算力。 第三，工程效率。 张晋公式里的效能系数，讲的是GPU跑起来以后还有多少标称能力能释放出来。网络丢包、通信等待、显存碎片、KV Cache膨胀、Prefill和Decode阶段错配，都会让标称算力打折。它不是满载系数，但会影响最终有效产出。 ...

很多人想象大模型训练，会想到几千张GPU同时开跑。这个画面没错，但少了一个关键细节：这些GPU不是各干各的，而是在同一个训练节拍里一起往前走。 每一步训练，大家都要先算完自己那份，再把结果对齐，然后一起进入下一步。一张卡慢了、断了、通信异常了，受影响的通常不是它自己那一点算力，而是整个训练作业的节奏。 这也是为什么在大模型训练里，掉卡是个很麻烦的词。它不只是少了1/16000的算力，更可能让另外15999张卡一起等。 一、分布式训练不是各跑各的流水线 在同步训练中，每张GPU拿到一小批训练数据，算出一份梯度。梯度可以简单理解为：模型参数下一步应该往哪个方向调整。 问题在于，模型副本分布在很多张卡上，但训练逻辑要求这些副本保持一致。每张卡不能按自己的梯度单独更新，否则很快就会训练出一堆互相不一样的模型。 所以同步数据并行里通常会做这样一件事：每张卡先算出自己的梯度，然后所有卡把梯度汇总、求和或求平均，得到一份全局结果，再一起更新参数。 这个过程很像一桌人AA制。每个人先报自己花了多少钱，等所有人都报完，才能算总账和人均。如果有人迟迟不报、报错了，或者干脆走了，其他人只能等。 同步训练：所有GPU必须一起进入下一步 大模型训练里的这种等待不是偶发插曲。只要采用同步训练，每一步参数更新都绕不开类似的同步动作。卡越多，整体算力越大，但也越容易遇到某个环节掉队。 二、All-Reduce到底在做什么？ 刚才说的“汇总梯度、再让每张卡拿到同一份结果”，在分布式训练里最典型的通信动作叫All-Reduce。 一句话说，All-Reduce就是每个rank都拿出一份数据，系统把这些数据做归约运算，比如求和，然后把结果放回每个rank。训练场景里，这份数据常常就是梯度。 All-Reduce：先汇总，再把同一份结果发回每张卡 NVIDIA NCCL官方文档对All-Reduce的描述也是这个意思：每个rank提供输入数组，经过归约后，每个rank都收到相同的输出结果。NCCL文档还强调，集合通信操作必须由每个rank用相同的数据量、相同的数据类型调用，否则结果属于未定义行为，可能hang、crash，甚至造成数据损坏。 这里的rank可以先粗略理解成参与训练的一个计算进程，很多场景下一个rank对应一张GPU。严格说，rank和GPU不总是一一对应，但对这篇文章要解释的问题来说，这个简化足够用了。 再看PyTorch的DistributedDataParallel。DDP在反向传播时会把梯度按bucket分组，某个bucket准备好后就触发通信，把不同进程里的梯度同步起来。PyTorch文档也提醒过，如果不同进程之间的collective调用顺序对不上，backward过程可能直接卡住。 所以，All-Reduce的关键不是“通信很慢”这么简单，而是它有一个很强的前提：参与者要按同一套顺序、同一套形状、同一套节拍一起做事。有人掉线，或者有人走到了另一套通信流程里，整个作业就可能卡住。 现代大模型训练当然不只用All-Reduce。FSDP、张量并行、流水线并行里还会大量出现all-gather、reduce-scatter等集合通信。但只要理解All-Reduce，就能理解同步训练为什么怕掉队。 三、掉卡为什么会拖住几千张卡？ 理解了前面的同步逻辑，再看掉卡，就不会把它理解成“少一张卡继续跑”。 第一种情况是直接掉卡。GPU报错、显存出现不可纠正错误、NVLink或RoCE网络异常，都可能让某个rank掉出通信队伍。集合通信等不到它，训练就可能停在某一次通信上。后面要做的不是简单跳过这张卡，而是超时检测、故障定位、重建通信组、重新调度，再从checkpoint恢复。 这里有个容易混淆的点：超时不是NCCL自己天然帮你把训练恢复好。NCCL是底层通信库，真正的超时检测和错误处理通常还要依赖上层框架和训练系统。以PyTorch为例，ProcessGroupNCCL有watchdog机制，公开文档里提到NCCL后端默认超时时间是10分钟，其他后端默认是30分钟。也就是说，如果训练系统没有额外的监控和更快的失败处理，一次通信挂住可能会白白占住很多GPU时间。 一张卡掉线，为什么几千张卡都要等 第二种情况是慢卡，也就是straggler。它比直接掉卡更难排查。卡没有彻底坏，任务还在跑，但它就是比其他卡慢一拍。可能是硬件状态不稳定，可能是链路异常，也可能是某个节点的系统侧问题。 同步训练的麻烦就在这里：下一步要等所有人都到齐。一张慢卡会把所有快卡都拖到自己的节奏上。Meta在Llama 3技术报告里专门提到过这类问题：有些硬件故障会表现成慢节点，表面上像通信问题，但根因可能是某个GPU或主机组件出了问题。 第三种情况是恢复成本。掉卡之后，训练通常不能无损地从故障那一刻继续。系统要判断故障源，决定是否剔除节点，重新拉起作业，再加载最近一次checkpoint。 checkpoint又有自己的两难。存得太少，故障后要回退更远，丢掉更多已经算过的token；存得太频繁，训练又会被保存模型状态这件事打断，还会占用存储和网络带宽。 慢卡比掉卡更隐蔽 AWS的checkpoint文章给过一个直观算例：4000张加速卡的集群，如果一次同步checkpoint暂停3分钟，就相当于200个GPU-hours的集群空转。如果每30分钟做一次这样的同步checkpoint，一天会损失9600个GPU-hours。这个数字不是说所有训练都会这样，而是提醒我们：几分钟的停顿，乘上几千张卡之后，就不是小数。 四、Llama 3的数据说明了什么？ Llama 3 405B训练：故障是日常，不是偶发 Meta训练Llama 3 405B的数据很适合拿来做参照。 按照Meta技术报告，Llama 3 405B预训练最多用到16384张H100。每张H100是80GB HBM3显存、700W TDP。报告还披露，在一个54天的预训练窗口里，训练作业一共发生466次中断，其中47次是计划内中断，419次是非计划中断。 这419次非计划中断里，约78%被归因于确认或疑似硬件问题，包括GPU、主机组件、静默数据损坏，以及非计划的单机维护。GPU相关问题是最大类，占所有非计划问题的58.7%。 换算一下，54天是1296小时，419次非计划中断平均下来大约每3.1小时一次。这个平均数不能理解成故障真的每3小时均匀发生一次，但它足够说明一个事实：到了万卡规模，故障不是极端偶发事件，而是训练系统日常要处理的东西。 Meta同一份报告里还有一句很关键的话：同步训练本身不太容错，一张GPU故障可能要求整个作业重启。即便如此，他们仍然把effective training time做到90%以上，靠的是减少启动和checkpoint时间，自动化诊断和问题处理。 这里值得注意的是，90%以上有效训练时间并不意味着故障少。恰恰相反，它说明在故障很多的情况下，训练系统能不能快速发现、快速恢复，会直接决定最终效率。 五、掉卡真正暴露的是训练系统能力 大模型训练拼的是系统工程 把这些机制和数据放在一起看，大模型训练最怕掉卡，不是因为硬件不能坏。任何足够大的集群都会遇到硬件故障。 真正的问题是，同步训练把大量GPU绑在同一个节拍上。单卡故障、慢卡、通信错位、checkpoint回退，都会被集群规模放大。单看一张卡，可能只是停几分钟；放到几千张卡上，就是几千张卡一起等。 所以，大模型训练拼的不只是GPU数量。GPU越多，单卡算力越不能解释最终效率。通信、同步、慢节点检测、checkpoint策略、故障恢复和任务调度，都会变成训练成本的一部分。 一张卡掉线本身不可怕。更难的是系统能不能快速判断：它是真坏了，还是只是慢了；是GPU问题，还是网络问题；要不要重启整个作业，还是只需要剔除问题节点。能不能把这套判断和恢复流程做快，决定了大规模训练到底是在有效计算，还是在让昂贵的GPU排队等人。 参考资料： Meta，《The Llama 3 Herd of Models》技术报告 NVIDIA，NCCL Collective Operations官方文档 PyTorch，DistributedDataParallel官方文档 与 torch.distributed官方文档 PyTorch Blog，《Flight Recorder: A New Lens for Understanding NCCL Watchdog Timeouts》 AWS Storage Blog，《Architecting scalable checkpoint storage for large-scale ML training on AWS》

这两年看智算中心新闻，经常会看到一个很大的数字：千P、万P、多少EFLOPS。 这个数字当然不是假的。它背后通常有真实的机房、服务器、GPU、交换机、电力和冷却系统。但它也不是一个完整答案。一个智算中心说自己有1000P，只能说明它有一批账面峰值资源，不等于这些资源在训练大模型时都能高效跑起来。 国家数据局指导下，全国数据标准化技术委员会在2025年6月发布过一组《全国一体化算力网》技术文件征求意见稿。里面有一个很值得注意的变化：算力衡量已经不只看峰值计算能力，还要看计算负载率、网络带宽利用率、时延、丢包率、吞吐率、存储IOPS、访问延迟等指标。 这说明，连标准口径都已经不满足于一个孤立的P数了。 普通读者看智算中心，不需要马上钻进所有工程细节里。抓住三个数字就够了： 这个P是什么精度算出来的？ 卡和卡之间用什么网络连起来？ 真实任务跑出了多少有效算力？ 这三个数字连起来，才比较接近一个智算中心真实的训练能力。 峰值P数是怎么加出来的 同一张GPU，为什么能写成接近2P，也能写成接近1P P是peta的缩写。1P FLOPS，大约就是每秒1000万亿次浮点运算。一个智算中心说自己有1000P，最朴素的算法通常是： 1 总峰值算力 = 单卡峰值算力 × 卡数 这个公式看起来很直观，麻烦在于“单卡峰值算力”本身有很多口径。 以NVIDIA H100 SXM为例，NVIDIA官方规格页写的是：FP16/BF16 Tensor Core为1979 TFLOPS，FP8 Tensor Core为3958 TFLOPS，NVLink带宽为900GB/s。但同一个表格下面有脚注：这些带星号的Tensor Core数字是采用稀疏技术显示的，不采用稀疏技术时规格降低一半。 也就是说，同一张H100 SXM，如果按FP16/BF16稀疏口径看，接近2P；如果按不采用稀疏的稠密口径看，大约接近1P。 这不是文字游戏，也不是博客作者的猜测，而是官方规格表里的口径差异。 再往下看，精度口径也会让数字变化很大。大模型训练常见的是FP16、BF16、FP8这些低精度格式；科学计算常看FP64；推理场景又经常出现INT8、INT4、FP4。它们都可能被折算成某种OPS或FLOPS，但不能直接混在一起比较。 可以粗略记成这张表： 精度口径 常见场景 读者需要注意什么 FP64 科学计算、高性能计算 不等于大模型训练主口径 FP32 通用单精度计算 常被用于统一折算 TF32 NVIDIA Tensor Core计算 主要是张量核心相关口径 FP16/BF16 大模型训练主力 看清是稠密还是稀疏 FP8 新一代训练和推理 不能直接和FP16数字混比 INT8 量化推理 更偏推理，不宜直接代表训练能力 INT4/FP4 更低精度推理 数字会更大，但适用任务更窄 所以，看到一个千P集群，第一反应不要是“强不强”，而是补一句：千P@什么精度？ 更严谨的写法应该像这样： 1 2 3 1000P@FP16 dense 1000P@FP16 sparse 1000P@FP8 少了精度和稀疏口径，这个P数就只讲了一半。 ...

一个问题：昇腾910C到底能打H100的几成？ 这个问题看着简单，实际很容易问偏。推理、小规模部署、大模型训练、千卡集群，根本不是同一场比赛。910C在每一场里的表现都不一样。 先把结论摆在前面：如果只看公开报道里的特定推理任务，可以谈6成左右的口径；如果看大模型训练和大规模集群，答案要保守得多；如果看FP8这类前沿训练能力，差距会更明显。 这篇文章不是要证明国产芯片行不行，而是想把一件事讲清楚：910C的价值不是无损替代H100，而是在AI基建很难稳定获得H100的现实里，提供一块可规模部署、可系统堆叠、可持续优化的算力底座。 一、纸面参数对比表，先把口径摆正 先看硬件规格。这张表只放最核心的几项，后面每一个结论都要能回到这里。 规格 昇腾910C NVIDIA H100 SXM FP16/BF16算力 约752-800 TFLOPS，来自Atlas 900 A3整机规格和CloudMatrix论文口径反推 约989.5 TFLOPS稠密；1,979 TFLOPS为稀疏口径 FP8算力 公开权威资料未给出可直接对标的910C单卡FP8峰值 约1,979 TFLOPS稠密；3,958 TFLOPS为稀疏口径 片上内存容量 128GB，见Atlas 900 A3和CloudMatrix相关资料 80GB HBM3 片上内存带宽 最高约3.2TB/s，见Atlas 900 A3和CloudMatrix相关资料 3.35TB/s 芯片/节点内互联 Atlas 900 A3标注D2D双向784GB/s；CloudMatrix论文给出UB平面每NPU约392GB/s单向 NVLink 900GB/s 系统形态 Atlas 900 A3最多384张NPU组成超节点 HGX/DGX H100常见为8卡节点，并可通过NVLink/NVSwitch与InfiniBand扩展 参数表不能直接给出答案 这张表后面必须加三条提醒，不然很容易被数字带偏。 第一，H100的1979 TFLOPS和3958 TFLOPS不是稠密口径。NVIDIA官方规格表在这些Tensor Core峰值后面标了星号，说明是with sparsity，也就是带稀疏加速。要和没有明确稀疏口径的数据比较，H100的FP16/BF16稠密峰值应按约989.5 TFLOPS看，FP8稠密峰值应按约1979 TFLOPS看。 第二，910C的单卡数据目前最稳妥的公开来源，不是华为单独发布的一张芯片规格表，而是Atlas 900 A3、CloudMatrix384这类系统级资料。Atlas 900 A3官方页写的是384张NPU、48TB片上内存、片上内存带宽最高3.2TB/s、FP16总算力307.2/288.7 PFLOPS。按这个口径反推，单NPU大约是128GB片上内存、最高3.2TB/s带宽、约800/752 TFLOPS FP16算力。 第三，网上常见的96GB、1.8TB/s、HCCS 400GB/s等数字，有些来自分析机构、媒体或早期推断，有些可能对应不同板卡、不同可用容量或不同互联层级。它们不是完全没有参考价值，但不适合写成已经核实确认的统一官方规格。本文后面会尽量用公开来源更清楚的系统级数据，同时把推断和报道口径分开。 如果只看FP16稠密峰值，910C和H100的差距没有很多文章写得那么夸张；如果看FP8训练、生态成熟度和大规模集群效率，参数表又会显得太乐观。这就是这篇文章要展开的地方。 二、真实差距一：FP8，不只是一个数字 FP8是这轮AI芯片竞争里很关键的一项。它不是把精度从16位砍到8位这么简单，而是牵扯训练稳定性、损失缩放、算子实现、框架支持和模型配方。 H100的优势不只是官方表里有FP8峰值。NVIDIA把FP8做进了Hopper架构和Transformer Engine，再配上CUDA、cuDNN、NCCL、TensorRT-LLM、Megatron等工具链和训练经验，形成的是一整套能把低精度真正用起来的工程体系。低精度训练最怕的不是算力不够，而是数值不稳定、精度对不齐、训到一半才发现收益吃不到。 ...