术语解构系列·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个为零，模型通常需要经过剪枝和微调，才能满足这个模式并尽量恢复精度。不做这一步，硬件的稀疏加速路径就用不上。所以对很多直接部署、没有专门做稀疏化处理的生产模型来说，实际更接近表格左边那一列，稠密算力。 ...

上一篇聊完“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家公司里真正吃到红利的只有个位数——从数据飞轮的启动成本和整机良率的连乘账，看机器人为什么是系统工程竞争最极端的样本。

一、先讲一个今年最好的“芯模协同”案例 今年4月24日，DeepSeek发布V4系列（V4-Pro和V4-Flash），总参数1.6万亿，原生支持100万token上下文。这次发布有一个容易被忽略、但比跑分更重要的细节：昇腾实现了Day0适配——模型发布当天，昇腾超节点全系列产品就完成了支持验证。 更关键的是适配的深度。V4这一代的核心架构创新，是CSA（压缩稀疏注意力）与HCA（重度压缩注意力）的混合交错设计：CSA把每4个token的KV合并成1条再做稀疏筛选，HCA更激进，128:1压缩后直接做全量密集注意力，两种层在网络里隔层交替。配套的还有KV缓存混合精度存储、异构KV缓存管理这些工程细节。这不是“拿一个现成模型移植到另一块芯片上”，而是注意力机制的设计本身就考虑了目标硬件的计算与访存特性——DeepSeek官方文档也确认，细粒度专家并行（EP）方案同时在英伟达GPU和昇腾NPU上完成了验证。 CSA/HCA混合注意力与硬件协同 再加上一个价格信号：DeepSeek官方明确表示，预计下半年昇腾950超节点批量上市后，V4-Pro的价格还会大幅下调——而在此之前，V4-Pro已经把75%的限时折扣转成了永久价格，输入$0.435/百万token、输出$0.87/百万token。芯片的量产节奏，直接写进了大模型的降价路线图。这就是2026年本届WAIC上被反复引用的“芯模协同”叙事的由来。 这个案例确实好。但正因为它太好了，在这一篇里做一件相反的事：给这个叙事踩一脚刹车，看看“能跑起来”和“生态护城河”之间，到底还隔着多少东西。 二、“生态协同”和“单纯能跑”，不是一回事 “单纯能跑” 指的是：模型权重能加载、算子能执行、推理结果数值正确、benchmark能出分。这件事的技术门槛真实存在，但它是一次性的、可以靠攻坚团队突击完成的。厂商发布会上的“完成适配”，绝大多数指的是这一层。 “生态协同” 指的是另一回事：主流框架原生支持、算子库覆盖长尾场景、编译器能自动优化而不是靠人肉调优、出了问题有工具能定位、社区里搜得到答案、第三方开发者愿意在没有厂商驻场支持的情况下自己把系统跑起来。这一层没有发布会，只有日复一日的issue、PR和版本迭代。 打个比方：前者相当于一辆车通过了出厂测试，后者相当于全国有加油站、有4S店、有二手市场、有路边随处能找到的修车铺。买车的人真正依赖的是后者，但发布会只会展示前者。 三、生态成熟度的批判性检验清单 如果你想判断一个算力生态到底走到了哪一步，媒体通稿帮不了你。下面这份清单是一个可用的检验框架，每一条都对应一个媒体很少报道、但工程团队天天面对的现实。 1. 推理适配 ≠ 后训练适配 ≠ 完整预训练 这是三件难度完全不同的事。推理适配只需要前向计算正确、吞吐达标，新闻里说的“已完成适配”绝大多数停在这一层。后训练适配的战线立刻拉长：LoRA微调、SFT、RLHF/DPO、模型量化、蒸馏、检查点格式转换——每一项背后都是一批工具链要重新适配，反向传播、优化器状态、混合精度全链路都不能出错。而完整预训练——几千甚至上万张卡、连续运行数周到数月、checkpoint稳定保存、通信不掉链、编译器和调度器不抽风、节点故障后还能恢复续训——是对整个软硬件栈的终极压力测试。“DeepSeek能在昇腾上跑推理”是事实，但它不等于“昇腾已经能扛起大模型的全生命周期”。V4本身的预训练在什么硬件上完成，官方技术报告里写得很清楚，这个信息差值得每个读者自己去核对，而不是从“适配成功”四个字里自行脑补。 2. CANN对CUDA：目前是“补课”，还不是“超越” 很多人把CUDA理解成一个开发工具，实际上它更像一整套AI操作系统：编译器、Runtime、驱动、算子库、数学库、通信库（NCCL）、Profiling与Debug工具，再加上庞大的第三方生态，共同构成了今天AI开发最成熟的软件平台。CANN是华为对标这套体系的异构计算架构，覆盖图编译、算子融合、内存优化、并行策略。客观地说，CANN这几年进步的斜率很陡。但要认清生态位关系：CUDA有近二十年的积累，全球几乎所有AI论文的参考实现默认写给它，PyTorch的每一个新特性第一时间在它上面验证。CANN目前做的大部分工作，本质是把CUDA生态里已经存在的能力补齐，让开发者迁移时少踩坑——这是必要且艰难的补课，但补课和超越是两个阶段，混为一谈对谁都没好处。 3. 框架适配深度、算子库完整度、编译器成熟度——开发者体验的核心，却几乎没人报道 通常我们看到的是“模型快不快”，而工程团队关心的是另一串问题：PyTorch支持是否完整、动态图有没有暗坑？算子库对主流模型结构覆盖良好，但碰到一个论文里的新算子、一个非标准的attention变体，是不是要自己写Ascend C算子？编译时间是否稳定，图编译器在偏离标准路径后的性能悬崖有多陡？OOM了能不能快速定位到是哪层、哪个张量？PyTorch在昇腾上的支持走的是torch_npu插件路线，而不是上游原生后端，这意味着版本跟随总有时间差。这些才是决定一个工程团队愿不愿意长期使用这套平台的核心，但它们无法浓缩成一条新闻标题，于是在公共讨论里近乎不存在。 4. 迁移成本：从英伟达搬到昇腾，工程团队要付出什么 一次真实的迁移，账单大致包括：环境与驱动栈重建、依赖库逐个排查替换、自定义算子重写、数值精度逐层对齐（同一个模型在两种硬件上输出不完全一致是常态，定位差异来源可能耗掉数周）、性能重新调优（在A卡上调好的并行策略在N卡上未必最优，反之亦然）、以及CI/CD和监控体系的重做。对一个中型团队，这不是“改几行代码”，而是以人月为单位的工程投入。厂商的迁移工具能覆盖多少比例，剩下的长尾要靠多少驻场工程师填，这才是采购决策里真正该问的问题。说到底，企业真正要算的从来不是采购价，而是未来三年的总体拥有成本（TCO）——这些迁移账单不会因为芯片便宜就自动消失，只有当迁移成本持续下降、生态摩擦持续减少，价格优势才能真正转化为规模化部署优势。这一点，正是第一篇TCO讨论在生态层面的延伸。 5. 看不见的软件基建：调试、稳定性、可观测性 profiler好不好用？训练到第37天集群里一块卡静默出错，能不能快速定位到是哪个节点、哪层通信？日志和监控指标的粒度够不够做根因分析？长时间运行的稳定性MTBF是多少？这些“看不见”的能力，恰恰是生态是否真正成熟的试金石——因为它们无法靠一次发布会攻坚补齐，只能靠大规模真实负载长年累月磨出来。CUDA生态里的Nsight、NCCL调试经验、无数StackOverflow问答，都是二十年真实故障喂出来的。这个过程没有捷径。 6. 一个容易被忽略的风险：低价的另一面是什么？ 客户在享受“75%降价”和国产算力补贴红利的同时，值得冷静问一句： 我是否正在被绑定进一个相对封闭的技术栈？ 如果两年后需要迁回，或者迁向第三种硬件，成本几何？当模型迁移困难、工具替换困难、开发接口差异越拉越大，新平台同样会形成新的锁定效应（Vendor Lock-in）——锁定从来不是靠合同条款实现的，而是靠迁移成本的自然堆积。开源兼容是这个问题的部分答案，但只是部分：开源降低了“理论上可迁移”的门槛，却不自动消除上面第4条列出的那些实际工程成本。开源是生态成长的必要条件，不是生态成熟的终点 ——能否持续维护、能否快速跟进主流框架、社区是否足够活跃、能否切实降低企业迁移成本，这四件事才是开源之后真正的考题。 能跑起来 ≠ 生态成熟 三点五、两个可验证的背景事实 需要注意区分的是“这次WAIC的新进展”和“更早就存在、这次只是被反复提及的背景”。有两件事属于后者，容易被当成新料： 第一，CANN的开源不是WAIC的新闻。“CANN全面开源开放”早在2025年8月的昇腾生态大会上就已官宣。本届WAIC上它被反复提及，是作为既成事实的背景板，不是新进展。 第二，vLLM-Ascend是一个可以自己去看的观察对象。 它是GitHub上真实、持续更新的开源项目（vllm-project/vllm-ascend），有独立的安装文档、发布说明和中文社区支持；同类的还有torch_npu、MindSpore等。与其空泛地说“华为在做生态”，不如定期去看这些仓库：issue的响应速度、版本跟随上游主线的时间差、支持的模型列表增长曲线——生态成熟度不需要相信谁的判断，它是可以被持续观测的。 四、换个视角：本届WAIC的Agent产品群像，在争夺什么？ 把镜头从芯片层拉高，本届WAIC（7月17日—20日，上海，1100余家企业、超300款产品全球首发）最密集的火力，其实集中在另一个层面——调度层。 扫一眼产品群像：努比亚发布了AI智能体手机（联合豆包），倪飞的表态很直白——AI手机的下半场要从“功能叠加”走向“原生智能体”；阶跃星辰拿出了全球首个智能体原生操作系统Step AOS，配套的智能体手机STEPX Neo拿了“镇馆之宝”；MiniMax展出了6月开源的M3——原生多模态、百万token上下文，配合MiniMax Code能直接完成编程和调研报告；百度这边，“芯云模体”全栈矩阵发布升级，通用智能体“百度搭子”同样入选“镇馆之宝”，主打自然语言下达任务后自主拆解、调用工具、一站式交付。 Agent调度层：AI时代的安卓/iOS 之争 这些产品形态各异，但争的是同一个位置：未来竞争的不只是模型，而是谁来调度模型——那个理解用户意图、拆解任务、调度底层能力的入口。这个逻辑我们并不陌生——移动互联网时代，安卓和iOS真正建立优势，不是因为内核更先进，而是因为它们掌握了应用生态和开发者入口，硬件厂商再强也要按平台的规则玩。现在同样的剧本在AI上重演：芯片和模型是底层能力，但谁掌握了Agent调度层，谁就掌握了流量分发和价值分配的规则制定权。这也是为什么手机厂商、模型厂商、云厂商会同时挤进这条赛道。 五、Token经济：给“生态能力”一个可量化的商业指标 本届WAIC把“Token经济”列为核心议题之一，这是把前面所有讨论收拢到一起的那根线。 “Token正在成为AI商业的新语言”——这个判断值得认真对待。往下拆会发现，越来越多AI企业本质上在做同一件事：卖Token。算力厂商在卖Token（把单位Token的生产成本压到比客户自建更低，靠规模和降本获利），云平台在卖Token，大模型厂商无论表面上卖API还是卖订阅、本质也是在卖Token，Agent平台还是在卖Token。于是竞争焦点变得非常朴素：谁能更便宜地生产Token、谁能让市场消耗更多Token、谁能把Token消耗转化成实际收入。 这就和第一篇讨论的TCO与单位Token成本接上了。生态能力听起来抽象，但它最终会沉淀为一个可以算的数字：同样一个模型、同样的服务质量，在你这套软硬件栈上，每百万token的全摊成本是多少？ DeepSeek把V4-Pro压到输出$0.87/百万token并预告随昇腾950量产继续下调，就是在用价格公开宣示自己这套协同栈的单位Token成本曲线。生态成熟度的所有细节——算子效率、编译器优化、集群稳定性、故障率——最后都会算进这个数字里。Token单价，就是生态能力的财务报表。 单位Token成本构成瀑布图 六、结论：适配成功是起点，不是终点 回到标题的问题。 一个旗舰模型能在国产芯片上完成Day0适配，甚至在架构设计阶段就做了协同优化——这是真实的、值得肯定的进展，它证明这条路走得通。但“走得通”是生态建立的起点，不是终点。一颗优秀的芯片，可以解决算力问题；一个成熟的生态，才能解决产业问题。 ...