前两篇分别拆了缓存怎么算钱（《同一份材料，为什么第二次交给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等工具链和训练经验，形成的是一整套能把低精度真正用起来的工程体系。低精度训练最怕的不是算力不够，而是数值不稳定、精度对不齐、训到一半才发现收益吃不到。 ...

三年前，一张旗舰显卡要加价才能买到。 三年后，同一张卡挂上二手平台，买家问的第一句话往往不是性能怎么样，而是：挖过矿吗？还有没有保？同价位的新卡能不能打？ 没人怀疑它还能不能亮机。真正的问题是，它还值不值这个价。 显卡的寿命很容易被误解。很多人一说寿命，脑子里想的是风扇坏没坏、显存爆没爆、还能不能开机。可市场给显卡定价时，看的是另一套东西：同价位有没有更新的卡，软件还支不支持新特性，保修还剩多少，拿它赚钱的窗口期还剩多久。 所以，三年后显卡不值钱，通常不是它坏了，是价格先死了。 一、显卡身上有四种寿命 一张显卡身上有四种寿命 一张显卡至少有四种寿命。 物理寿命，看风扇、电容、显存颗粒、供电模块还能不能稳定工作。这是最朴素的坏没坏。 性能寿命，看同价位新卡出来以后，它还算不算快。显卡自己不会因为过了三年就自动变慢，但别人会变快。 软件寿命，看新驱动、新编码器、新游戏特性、新模型推理框架还支不支持它。AI场景里尤其明显，有些卡不是慢一点，而是显存不够、算子不合适、部署链路不再优先照顾。 资产寿命，看账面上、云市场里、二手平台上，它还能不能卖出一个说得过去的价格。 这四种寿命不是同步结束的。物理寿命常常最长，资产寿命常常最短。一张显卡还能跑游戏、还能剪视频、还能跑小模型，但市场已经不愿意为它的过去溢价买单。 二、新卡一出，旧旗舰就失去旗舰身份 RTX 4090 与 RTX 5090 改变旧旗舰价格锚 先看最容易理解的消费级例子：RTX 4090和RTX 5090。 NVIDIA官方规格里，RTX 4090是24GB GDDR6X，显存带宽1008GB/s，起售价1599美元，Tensor Core AI算力标为1321 AI TOPS。RTX 5090是32GB GDDR7，显存带宽1792GB/s，起售价1999美元，AI TOPS标到3352。 这些数字不应该被简单理解成游戏性能直接翻了多少倍。AI TOPS是特定计算口径下的理论指标，和游戏帧率、本地模型吞吐、真实工作负载之间还有一段距离。可它对二手价格有一个很实际的影响：新旗舰出现后，旧旗舰的价格锚会被拔掉。 旧卡不再只和自己当年的发售价比较。它会被拿去和新一代中高端卡、同代二手旗舰、云端按小时租用的GPU放在一起算账。 买家不会因为你当年原价甚至加价买它，就继续按当年的旗舰身份给它估值。二手市场只关心现在这笔钱能买到什么。 显卡不是古董。它不会因为曾经贵就保值，它会被新一代的显存容量、带宽、功耗、驱动周期和软件特性重新定价。 三、三年这个时间点，卡在几个现实边界上 显卡三年后为什么变成一个价格坎 三年不是一个精确的技术报废点，但它确实很敏感。 消费级显卡这边，保修是一个很硬的边界。NVIDIA对自家Founders Edition显卡的保修期是三年，并且条款明确写着，这个保修只覆盖原始购买者，不延伸给二手购买者。不同AIB品牌会有自己的政策，但对二手买家来说，保修确定性下降这件事本身就会压价。 产品迭代也是一个边界。旗舰显卡通常不会每年换代，但两三年足够让一代新架构、新显存、新DLSS或新编码器进场。到了这个时间点，旧旗舰往往还很强，但它已经不再代表最新体验。 还有一个容易被忽略的边界：心理账户。 第一年，买家愿意为旗舰溢价买单，因为它代表最新。第二年，价格开始回到理性区间。第三年以后，买家开始把它当旧卡看，哪怕性能还不错，也会把风险折进去：风扇寿命、显存温度、矿卡嫌疑、保修缺口、未来软件支持。 这就是为什么很多显卡不是坏了才掉价，而是在确定性变差的时候掉价。 四、数据中心GPU也在算同一笔账 消费级显卡贬值还只是个人买卖。到了数据中心GPU，这件事会变成财报问题。 一张H100、H200、B200或同级AI加速卡，不是几千块的配件。它是云厂商和大模型公司资产负债表上的大额硬件。问题就变成了：这些GPU该按几年折旧？ 微软2025年年报里，计算机设备的估计使用寿命是2到6年。Alphabet公开说明，服务器和网络设备通常按6年折旧，并会持续评估技术过时、计划用途和利用率。Meta在2025年把多数服务器和网络资产的估计使用寿命延长到5.5年。Oracle在2025财年把服务器和网络设备使用寿命从5年延到6年。 但亚马逊给了一个反方向信号。它2024年把服务器寿命从5年延到6年，随后又从2025年开始，把一部分服务器和网络设备从6年缩回5年，理由是技术发展加快，尤其是AI和机器学习领域。 这些披露放在一起看，比单独看某家公司更有意思：大公司并没有一个统一答案。有人相信服务器可以用得更久，有人开始承认一部分硬件会更快过时。 数据中心 GPU 的账面寿命和经济寿命 这里要分清两个词。 折旧年限是会计核算方法，用来把硬件成本分摊进财报。经济寿命看的是这张卡还能不能以有竞争力的价格提供算力。前者可以是五年、六年，后者可能被新架构、新能耗比、新租赁价格提前压缩。 公司账上可以慢慢折，市场心里会提前折。 五、AI给旧卡续了命，也给旧卡设了新门槛 AI 让旧卡续命，也让旧卡台阶式失效 AI让显卡市场变得更复杂了。 ...

发布会上，厂商介绍自己产品说：“这张卡有20P算力。” 台下鼓掌，媒体标题写“史上最强”。 但如果你去翻这张卡的官方数据表，会在某些Tensor Core算力项目旁边发现一个不起眼的星号（*），点开脚注可能写着一句话：这些数字采用稀疏（with sparsity）口径，不开稀疏时规格减半。 也就是说，发布会现场说的“20P”，实际稠密算力可能只有10P，甚至更低。这不是哪家厂商偷偷作弊，而是官方规格表里公开写明、但作为读者很容易忽略的口径差异。稀疏算力到底是怎么把数字翻倍的，各家发布会都是怎么报的，你自己该怎么一眼识别。 一、稀疏矩阵：先搞懂“挑重点做事”是什么意思 2:4 结构化稀疏到底在跳过什么 想象一张100道题的试卷，你负责批改。 如果学生认认真真答满了100道题，你就得老老实实判100道。这叫稠密（dense）——矩阵里的每一个格子都有实际数值，硬件必须逐一参与计算，一个都不能少。 但现在硬件支持一种更规整的做法：如果模型权重已经满足每连续4个数里，至少2个是0，硬件就可以跳过这些0，只处理剩下的非零值。于是同样一张卡，理论吞吐量能翻一倍。这套规则在业内有个专门的名字，叫 2:4结构化稀疏（structured sparsity）：每4个权重里，至少2个被清零，硬件按这个固定模式压缩权重，再用专门的稀疏Tensor Core路径做乘加运算。 这里有个关键点很容易被忽略：试卷本身还是100道题，矩阵的规模一点没变。稀疏拿到的“2倍算力”，本质上是“跳过一半计算量”换来的相对加速比，而不是芯片真的凭空多长出一倍的晶体管。而且，这活儿不是白捡的——想让权重乖乖满足“每4个里至少2个是0”这个苛刻条件，通常需要专门用稀疏化训练或剪枝去“驯服”模型，很多实际生产模型并不会做这一步，也就吃不到这个加速。这也是为什么行业里有个粗暴但好用的经验：只要数据表里出现“稀疏”字样，这个数字大概率要打对折才是普通任务能拿到的真实水平。 二、稀疏vs稠密算力对照表：以H100、B200为例 这套“稀疏=稠密两倍”的写法，其实不是从H100、B200才开始的，往前翻一代就能找到源头。NVIDIA官方A100规格页上，同一类Tensor Core算力经常以稠密和稀疏两个口径出现：比如BF16/FP16可以看到312 TFLOPS和624 TFLOPS这一组数字，脚注专门标注了“With sparsity”。也就是说，从Ampere架构这一代开始，“稀疏峰值”就已经是NVIDIA官方规格表里的正式口径了，H100、Blackwell只是把这套写法延续了下去。 不用猜，直接看NVIDIA自己的官方规格页怎么写。H100 SXM的BF16/FP16 Tensor Core写成1979 TFLOPS，FP8写成3958 TFLOPS，脚注说明这些数字采用稀疏技术显示，不采用稀疏技术时规格降低一半。换成稠密口径，H100 SXM的BF16/FP16大约是989.5 TFLOPS，FP8大约是1979 TFLOPS。到了Blackwell一代，NVIDIA GB200 NVL72的规格表延续同样的写法，直接把sparse和dense并排列出，GB200 Grace Blackwell Superchip的NVFP4张量算力写成“40 | 20 PFLOPS”，脚注同样注明稠密规格是稀疏规格的一半——这里的40 PFLOPS是稀疏口径，20 PFLOPS才是稠密口径，而且它背后其实叠了两层变化：一层是从FP16/FP8换到更激进的FP4（精度每降一档，算力翻一倍），另一层才是稀疏本身。两层叠在一起，喊出来的最大数字很容易比一张卡在常规模型里能用上的算力高很多。 不止NVIDIA一家这么标。AMD Instinct系列的官方规格页也会把“普通峰值”和“结构化稀疏峰值”分开列：8卡MI300X平台的FP16矩阵算力，官方给的是稠密约10.5 PFLOPS、带结构化稀疏约20.9 PFLOPS；更新的MI355X单卡上，FP16/BF16矩阵算力是稠密2.5 PFLOPS、稀疏5 PFLOPS，INT8则是稠密约5 POPS、稀疏约10.1 POPS。可以看到，AMD的倍率关系和NVIDIA完全一致，都是稀疏正好翻一倍，只是AMD官方页面通常把两栏都摆在明面上，读者不用扒脚注就能看到对比。 稀疏算力 vs 稠密算力，为什么总是 2× 芯片 / 精度 稠密算力（真实基线） 稀疏算力（发布会/宣传常用） 倍率 A100 SXM · BF16/FP16 312 TFLOPS 624 TFLOPS 2× H100 · FP16/BF16 约990 TFLOPS 约1980 TFLOPS 2× H100 · FP8 约1980 TFLOPS 约3960 TFLOPS 2× B200 SXM · FP8/FP6 约4.5 PFLOPS 约9 PFLOPS 2× B200 SXM · FP4 约9 PFLOPS 约18 PFLOPS 2× GB200 Grace Blackwell Superchip · NVFP4 20 PFLOPS 40 PFLOPS 2× AMD MI300X（8卡平台）· FP16 约10.5 PFLOPS 约20.9 PFLOPS 2× AMD MI355X（单卡）· FP16/BF16 2.5 PFLOPS 5 PFLOPS 2× 这里要提醒一句：稀疏加速不是“想用就用”。2:4结构化稀疏要求每连续4个权重里至少2个为零，模型通常需要经过剪枝和微调，才能满足这个模式并尽量恢复精度。不做这一步，硬件的稀疏加速路径就用不上。所以对很多直接部署、没有专门做稀疏化处理的生产模型来说，实际更接近表格左边那一列，稠密算力。 ...