术语解构系列·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等工具链和训练经验，形成的是一整套能把低精度真正用起来的工程体系。低精度训练最怕的不是算力不够，而是数值不稳定、精度对不齐、训到一半才发现收益吃不到。 ...

B站专门做学术论文打假的UP主“耿同学讲故事”，他的风格很上头：一本正经地扒论文里的数据造假证据，配上大量吐槽和段子，把枯燥的学术不端问题讲成了相声。 看多了会发现一个问题：他每期都在讲不同的院长、教授、Nature子刊，但反复用的检测手法其实高度相似。只是每次都换了案例、换了段子包装，不容易一眼看出规律。 于是我起了个念头： 能不能把他全部投稿一次性扒下来，用本地AI帮我把这套隐藏的方法论提炼出来？ 整个过程走了三步：下载、转写、总结。除了从B站获取公开视频，后面的转写和模型分析都在本地电脑上跑完，没有调用云端AI接口。 准备数据 本地AI内容提炼流水线 这部分其实不是文章的重点，但它决定了后面分析能不能成立。视频要先完整拿到，语音要先转成可检索的文字，最后模型才有材料可总结。 第一步，批量下载全部投稿 先用一个基于yt-dlp的下载脚本，一次性抓取UP主视频列表页的全部视频。下载了所有的视频，在本地进行视频转音频、音频转文字操作。 耿同学封面墙 这里有两个实际坑。 第一个坑是B站风控。投稿列表页不带浏览器cookie直接访问，会被412拒绝。带上cookie之后，脚本才能正常拿到完整投稿列表。 第二个坑是下载策略。脚本第一次跑的时候，我设置成自动挑选最高画质。结果在正式下载前，yt-dlp会先对整个列表里的每一条视频做一次完整探测，导致跑了很久才真正开始下载。后来改成直接指定画质，跳过这一步，效率提升明显。 后面还有一次补漏。先前下载中断过，有些视频没下完整。这里用了yt-dlp自带的下载记录文件，也就是download archive机制：把已经下载好的视频ID写进记录文件，再次运行时自动跳过已完成的，只补齐缺的部分。 最后，155个投稿里成功拿到153个可用视频文件。 第二步，本地语音转文字 视频到手之后，下一步是把语音内容变成文字稿，方便后续做文本分析。 这一步用的是本地部署的语音识别模型faster-whisper，模型是large-v3，全程跑在自己电脑上，不依赖任何在线转写服务。 153个视频，平均单个模型推理耗时不短，累计跑了接近一整天。 中间出了两个挺有意思的乌龙。 一个是重复启动了两个进程。因为任务本身耗时很长，我没意识到之前已经有一个转写进程在后台跑了大半天，又手动开了一个新的。两个进程同时抢占了将近900%的CPU，电脑发烫严重，用上电风扇降温了。发现后赶紧把多余的那个关掉，只留一个继续跑。 另一个是日志假死。Python脚本把输出重定向到文件时，默认是整块缓冲，不是写一行就刷新一次。这导致我盯着日志文件，以为转写卡在了某一集长达一个多小时。实际上程序早就往前跑了十几个文件，只是日志内容还堆在内存缓冲区里没写盘。 后来不再盯日志，而是看实际产出的txt文件数量，才发现进度一直正常。 这个坑挺值得记一笔：监控长时间任务，不能只看它打印了什么，得看它实际产出了什么。 第三步，用本地模型做内容归纳 153份文字稿到手后，发现这位UP主的内容其实很杂。 除了论文打假，他还聊考研上岸率、读博的精神状态、相亲催婚、科研生活，也有不少直播带货式的科普。我粗筛了一遍，真正逐帧分析论文造假证据的硬核内容，大概40篇左右。 之后没有直接让模型“总结耿同学的观点”。那样很容易变成几句空话，比如“要重视学术诚信”“要加强科研监管”“要提升论文质量”。这些话都对，但没有用。 其实真正想知道的是另一件事： 如果把这些视频当成一个样本库，论文的“假”到底应该从哪些角度分析？ 于是就先让本地模型做关键词检索和初步聚类，重点看“造假”“撤稿”“图片重复”“数据造假”“临床”“代写”“重复实验”“原始数据”等词反复出现的位置。然后再人工抽查高频案例，避免模型把普通科普内容也混进论文打假里。 跑完之后，一个很清楚的框架浮出来了。 论文的“假”，不是一个点。它不是只有P图，也不是只有数据编造。真正的问题经常是一条链：图片可疑，数据异常，方法写不清，实验不可重复，结论往外跳，作者回应躲闪，最后学校和期刊再用一句“不规范”把事情盖过去。 得出的结论 有了这批文字稿之后，真正有价值的不是复述每一期视频讲了谁，而是把反复出现的判断动作抽出来。最后我把它整理成10层，从最容易观察的图片问题，一直推到论文背后的生产链和回应方式。 第一层，看图片 这是最直观的一层，也是耿同学视频里最常见的入口。 同一篇论文里，图片重复出现。不同论文里，图片重复出现。图片旋转180度以后还能重合。图片翻转、裁剪、调色以后，背景噪点、组织纹理、细胞形态还能对上。 这类问题最麻烦的地方在于，它不需要你完全懂论文的专业方向。你不一定知道这个信号通路是否成立，也不一定知道这个动物模型是否合理，但你能看出来两张图是不是同一张。 尤其是Western blot、细胞图、组织切片、肿瘤照片这些图，背景噪点和纹理就像指纹。它们一旦对上，就很难用“巧合”解释。 很多作者会把这类问题说成“图片误用”。但“误用”这个词只能解释一次，很难解释一串。如果一个团队的多篇论文、多个项目、多个年份反复出现图片重复，那就不是手滑，更像是一种生产方式。 第二层，看数据 假数据常常败在随机性 图片问题最直观，但数据问题往往更致命。 耿同学的视频里，数据统计类分析是很核心的一块。把论文里的原始数据整理出来，看小数点位数是否有跨行、跨列复制粘贴的痕迹，看某几列之间是否存在固定加减关系，看末位数字的分布是否接近随机。 在没有固定取整规则或仪器偏好的连续测量里，真实数据的末位数字通常不该高度集中在少数几个数字上。如果大量数据都挤在某几个末位，就可以用概率论算出这种巧合发生的概率有多低。 这类分析的杀伤力在于，它不是说“我觉得不像真的”，而是把问题转成一个统计学判断：这些小概率事件不应该同时发生。 耿同学吐槽某些论文时，经常会说“下次用随机数生成器”。这句话听起来像玩笑，但背后是一个严肃判断：很多假数据不是因为太复杂被发现，而是因为编得太粗糙。 真实实验数据通常有噪声。它不会那么听话。 第三层，看常识能不能对上 有些问题不需要复杂统计，常识就能先挡一遍。 比如测量精度是否合理，生物学机制是否说得通，实验动物和实验分组是否匹配，疾病和性别是否匹配，样本来源和结论外推是否匹配。 这类交叉验证看起来很朴素，但很有用。 论文最容易出问题的地方，往往是作者只盯着想要的结论，忘了现实世界还有很多约束。数据可以编，图片可以修，段落可以写得很漂亮，但常识有时候会从边角里露出来。 第四层，看原始材料 论文出问题以后，最关键的不是作者怎么解释，而是作者能不能拿出原始材料。 原始图片在哪里？原始表格在哪里？实验记录在哪里？样本编号在哪里？仪器输出文件在哪里？动物实验和临床研究的伦理审批在哪里？ 这些东西如果都能交代清楚，很多争议可以继续往下讨论。比如图片是否确实贴错了，统计方法是否可以修正，结论是否需要收窄。 但如果作者只给解释，不给材料，可信度就会迅速下降。 学术争议不是靠态度解决的。你说“我们没有造假”，这句话本身没有证据价值。真正有价值的是原始数据、实验记录和可以被第三方检查的材料。 第五层，看实验能不能重复 耿同学反复讲过一个意思：重复实验不是万能的，但重复不出来的实验一定要警惕。 这句话放在生命科学领域尤其刺耳。 很多生命科学实验确实复杂。样本来源、细胞状态、动物模型、菌群结构、试剂批次、操作人员都会影响结果。问题是，复杂不能变成免死金牌。 如果一篇论文的方法写得很模糊，关键材料拿不到，实验条件说不清，只有作者自己能做出来，别人一重复就失败，那它至少不应该被当成一个坚实结论。 科学研究当然允许失败，允许不确定，也允许后来被推翻。但如果一篇论文从发表那天起就无法被别人验证，它就更像一次性论文。 第六层，看方法设计有没有先天漏洞 有些论文不一定是直接伪造，但实验设计本身就撑不起结论。 ...

三年前，一张旗舰显卡要加价才能买到。 三年后，同一张卡挂上二手平台，买家问的第一句话往往不是性能怎么样，而是：挖过矿吗？还有没有保？同价位的新卡能不能打？ 没人怀疑它还能不能亮机。真正的问题是，它还值不值这个价。 显卡的寿命很容易被误解。很多人一说寿命，脑子里想的是风扇坏没坏、显存爆没爆、还能不能开机。可市场给显卡定价时，看的是另一套东西：同价位有没有更新的卡，软件还支不支持新特性，保修还剩多少，拿它赚钱的窗口期还剩多久。 所以，三年后显卡不值钱，通常不是它坏了，是价格先死了。 一、显卡身上有四种寿命 一张显卡身上有四种寿命 一张显卡至少有四种寿命。 物理寿命，看风扇、电容、显存颗粒、供电模块还能不能稳定工作。这是最朴素的坏没坏。 性能寿命，看同价位新卡出来以后，它还算不算快。显卡自己不会因为过了三年就自动变慢，但别人会变快。 软件寿命，看新驱动、新编码器、新游戏特性、新模型推理框架还支不支持它。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个为零，模型通常需要经过剪枝和微调，才能满足这个模式并尽量恢复精度。不做这一步，硬件的稀疏加速路径就用不上。所以对很多直接部署、没有专门做稀疏化处理的生产模型来说，实际更接近表格左边那一列，稠密算力。 ...

上一篇聊完“1P算力”到底是什么，初次接触这个概念，可能还会常被问到一句话： “那这1P，跑起来是不是真的能打满？” 答案可能有点扎心：大概率打不满，而且差得不少。 一个标称1P（FP16）的顶级AI卡，真正拿去训练大模型时，能稳定发挥出0.3P到0.5P，就已经算是业内的好成绩了。 更让人困惑的是：打开 nvidia-smi 看，GPU利用率不低，风扇在转，功耗上去了，账单更是一秒没停。但模型每秒吃进去的token，就是比按峰值算出来的少一大截。这中间差掉的0.5P到0.7P，去哪儿了？ 一、先认识这个词：MFU MFU，全称 Model FLOPs Utilization，模型算力利用率。这个词是Google在2022年的PaLM论文里正式提出并普及开的，计算公式如下： MFU = 模型每秒真正完成的理论计算量 ÷ 硬件每秒的理论峰值计算量 它问的不是“GPU忙不忙”，而是一件更直接与成本相关的问题：你花钱买来的理论峰值算力里，有多少真的变成了模型前向和反向传播里的有效数学计算。 这里有个容易搞混的地方：MFU算的是“训练模型真正需要的那部分计算”跑了多快，不包括为了省显存而做的“重计算”（rematerialization，也叫activation checkpointing）。那部分计算确实发生了，但只是拿计算换显存，并不产出“新的模型进展”。业内还有个更宽松的指标叫硬件算力利用率（HFU），会把这部分也算进去，数字自然更好看一些。 PaLM论文里正好给了一组可以直接对比的数字：PaLM 540B的MFU是46.2%，HFU是57.8%，两者相差11.6个百分点。这11.6个百分点，就是重计算占用掉、但没有直接产出“新模型进展”的那部分算力——PaLM团队为了拿到更高的可行batch size，主动选择了用重计算换显存，这笔账在HFU里被算成“有效利用”，但在MFU里被刨除了。同一次训练，换一个统计口径，利用率数字能差出十几个百分点。这也是为什么看到“算力利用率”这个词时，第一件事该问的是：这个数字算的是MFU还是HFU？ 两者不是一回事，混着比较容易被数字表面的高低误导。也就是说，MFU算的是一笔“最不掺水”的账。 GPU利用率 ≠ MFU GPU utilization ≠ MFU 第一次接触这个话题时会犯一个错：把 nvidia-smi 里的 GPU utilization 当成了MFU。 NVIDIA官方文档对 utilization.gpu 的定义是：在采样周期内，有一个或多个kernel正在GPU上执行的时间占比。也就是说，只要有kernel在跑，它就可能显示“很忙”，但这不代表Tensor Core被充分喂满，更不代表这些计算都在实实在在地推进模型训练。 这有点像餐厅后厨：灯一直亮着，不代表每口锅都在高效出菜。有人在切菜，有人在等外卖单，有人在找调料，后厨确实没闲着，但出菜速度还是上不去。MFU看的是出菜速度，GPU utilization只是看后厨灯亮没亮。 二、真实世界的数字长什么样 通过几个业内公开的训练案例，感受一下差距： 模型/系统 硬件 MFU GPT-3 V100 约21.3% Gopher TPU 约32.5% Megatron-Turing NLG 530B A100 约30.2% PaLM 540B TPU v4（6144卡） 约46.2%（HFU约57.8%） Llama 3 405B 最高16K张H100 约38%–43%（BF16） NVIDIA Megatron-Core 弱扩展基准 H100集群 约42%–50%（模型变大MFU会升高） MegaScale（字节，175B模型，12288卡） GPU 约55.2% DeepSeek-V3（671B MoE，FP8） H800 约21%–23%（不同估算口径） 公开训练案例里的 MFU PaLM之所以被反复拿出来当标杆，是因为它把MFU这个概念系统化了，46.2%在当时是相当亮眼的跃升，代表着“标称1P的卡，实际发挥出了0.46P”。 ...

WAIC 2026上具身智能参展企业一年翻倍、真机超300台，但2744家公司里真正吃到红利的只有个位数——从数据飞轮的启动成本和整机良率的连乘账，看机器人为什么是系统工程竞争最极端的样本。