芯模协同不是喊口号，DeepSeek V4实测打脸了多少质疑

看到这个帖子，我忍不住要坐下来好好写点东西。作为在AI Infra和芯片生态里摸爬滚打了七八年的老家伙，从Pytorch适配寒武纪MLU270开始，到后来在昇腾910B上折腾过百卡级MoE训练，再到最近帮某大厂做芯片-模型联合设计咨询，对这个话题确实有不少话想说。你帖子里提到的“芯模协同不是喊口号”，我双手双脚赞同，但我也想从另一个角度来聊聊——这篇文章可能会有点长，但我会尽量把技术细节和工程踩坑都摊开来讲。

先说说你提到的AIGCode团队在昇腾上实现MoE模型MFU达65%这个数据。我第一反应也是“卧槽，真敢写”，但后来仔细看了他们公开的技术报告和部分代码片段，发现这个数字不是虚的。关键在于他们做了两件事：一是把MoE的动态稀疏计算和昇腾的达芬奇架构做了深度绑定，具体来说，是利用了昇腾Cube Unit对稀疏矩阵的硬件加速特性——达芬奇架构本身有一个叫做“AI Core”的单元，它支持一种叫做“矢量-标量-张量”的三级流水线，而MoE的专家网络正好可以被映射成多个小矩阵乘法，这些小矩阵在CUBE单元上做分块计算时，如果能把激活的专家数量控制在硬件支持的并行度内，就能避免大部分无效数据传输。AIGCode的做法是，在模型编译阶段，通过CANN的图编译优化，将动态路由的决策结果提前到编译期做静态剪枝——这不是完全动态的，而是半静态的，比如根据历史统计规律，把top-2路由的专家选择范围缩小到硬件友好的子集上，这样在运行时就不需要频繁做全量专家计算了。这其实是一种“软硬协同的近似最优解”，不是完美的动态，但在工程上可行。

但你说的“通信瓶颈”问题，我深有体会。之前我们团队在昇腾上跑一个8x7B的MoE模型，用的是MindSpore框架，那时候CANN还在5.x版本，通信库HCCL的all-to-all性能简直是噩梦。MoE的专家并行通信模式是典型的“全对全”模式，每个token需要把激活的专家ID和对应的hidden states发到对应设备上。昇腾原本的HCCL实现是采用环状拓扑，但MoE的通信模式是密集的、非对称的，导致在64卡以上时，通信时间占到了总训练时间的40%以上。后来我们参考了DeepSeek V4的思路（其实他们更早就在内部论文里提过），做了两件事：一是把专家并行的通信改成“分层All-to-All”，即先在同一节点内通过NVLink（昇腾也有类似的高速互联接口，叫HCCS）做局部聚合，再把聚合后的数据通过跨节点RDMA做全局交换；二是把路由策略改成“专家容量动态调整”，即在每个训练step前，根据历史负载预测当前batch的专家激活分布，然后提前做资源预留。这两招下来，MFU从30%提到了45%左右，但离65%还有差距。AIGCode能做到65%，我认为他们可能还做了更激进的事情，比如把部分路由逻辑从软件搬到了硬件——昇腾的达芬奇架构里有一个叫做“AI Core”的单元，它支持一种叫做“条件执行”的指令，可以在不中断流水线的情况下根据输入数据选择不同的计算路径。如果能把MoE的路由决策做成硬件原语，那确实能省掉不少软件开销。

现在回到你提出的核心问题：这种协同优化是否过度依赖特定硬件？我的回答是：是的，而且这既是优点也是风险。说它是优点，因为只有深度耦合才能榨出极致性能。举个例子，NVIDIA的Hopper架构引入的Transformer Engine，本质上也是把FP8训练和Transformer的算子做了深度融合，但NVIDIA的优势在于它的软件栈（CUDA、cuBLAS、TensorRT）是统一的，你不需要为每代架构重写一套。而昇腾的问题是，它的硬件迭代很快（从910到910B到910C），CANN的API也在频繁变，导致你针对某款芯片做的优化，换到下一代可能就要重来。我亲身经历过一个项目：2023年我们为昇腾910A优化了一套稀疏计算库，利用的是它特有的“稀疏压缩存储”格式（类似CSR但带硬件对齐），结果到了910B上，因为AI Core的缓存架构变了（从L1变成L2统一缓存），原有格式的访问模式变成了随机访问，性能反而下降了30%。这种“优化绑定”的风险，在国产芯片生态里特别突出，因为每一家的架构设计理念都不太一样。寒武纪的MLU系列走的是类SIMD路线，强调向量化；海光的DCU则更像AMD的CDNA架构，强调计算单元密度。你为昇腾做的“达芬奇架构对齐优化”，到了寒武纪上，可能连算子映射都做不了，因为寒武纪的指令集不支持那种条件执行的稀疏模式。所以我认为，芯模协同的下一步，不是把所有优化都绑定到一家，而是抽象出一个“硬件无关的模型描述层”，比如用MLIR或者Triton这样的中间表示，把模型的计算图先映射到硬件无关的原语上，再让各家芯片厂商提供自己的后端编译器。这样至少能保证模型逻辑可以复用，只是编译优化需要适配。DeepSeek V4在这方面做得不错，他们开源了部分CANN适配的算子库，但离真正可移植还有距离。

关于你提到的“模型引导芯片设计”，我觉得这是中国AI芯片突破CUDA生态的唯一路径。CUDA之所以强大，是因为它先有硬件（GPU），再有软件生态（CUDA库），然后模型（Transformer）去适应它。但国产芯片没有这个时间窗口，只能反过来——先有模型（比如DeepSeek、百川、智谱这些大模型），然后芯片设计去适配模型。我亲眼见过一个案例：某国产芯片公司在设计下一代架构时，直接拿DeepSeek V4的计算图做RTL仿真，把计算密集型和访存密集型的算子比例统计出来，然后调整了片上SRAM的容量和带宽配比。这种“模型驱动芯片设计”的思路，比过去“先做通用芯片再跑模型”要高效得多。但这里有一个陷阱：模型迭代太快了。2024年还是MoE的主流，2025年可能就变成了Mamba或者别的什么结构。如果芯片设计周期是18个月，等芯片流片回来，模型架构可能已经变了。所以芯片设计需要有一定的前瞻性，比如保留对动态稀疏、混合精度、可变序列长度的硬件支持能力，而不是死盯着一个模型。昇腾的达芬奇架构在这方面做得不错，它有一个“可编程的向量单元”，可以软定义一些特殊算子，但代价是性能不如硬化的算子高。

工具链的短板，你提得非常准。CANN从“幼儿期”到“青年期”这个比喻很形象，但我觉得它现在更像是“青春期”——功能在猛增，但稳定性、易用性和调试体验都还有不少痘痘。我举一个具体的例子：NVIDIA的Nsight Systems可以精确到每个kernel的启动延迟、SM占用率、显存带宽利用率，而CANN的profiling工具（叫msprof还是什么来着）只能给出一个粗粒度的算子级耗时，而且还经常因为buffer溢出导致数据丢失。去年我们排查一个MoE训练的性能抖动问题，发现每隔几十个step就会有一个step的MFU突然掉到20%以下。用CANN的profiler抓了半天，发现是HCCL通信的梯度聚合阶段出现了一个“异步等待”的bug——某些rank上的梯度计算完成了，但通信引擎没有及时收到信号，导致空等了一个调度周期。这种问题在Nsight的timeline上一眼就能看出来，但在CANN上我们只能靠加打印日志来猜。所以我认为，工具链的成熟度，可能比算子性能更重要，因为再快的算子，如果调试效率低，整体研发进度都会被拖慢。好消息是，昇腾最近在推一个叫“昇腾开发者社区”的平台，里面有一些性能分析案例，但和NVIDIA的生态比起来，差距至少还有3年。

现在来回答你抛出的两个问题。

第一个问题：MoE模型的动态路由在昇腾上如何避免负载不均？这是一个经典难题，也是我们踩坑最深的点。动态路由的负载不均，核心在于每个batch激活的专家数量可能差异很大，导致某些专家被频繁访问，而另一些专家空闲，进而造成计算和通信的严重倾斜。在昇腾上，我们试过三种方案：第一种是“专家容量限制”（Expert Capacity，类似Switch Transformer的做法），即限制每个专家最多处理的token数，超出的token被丢弃或重路由。这个方案在昇腾上效果一般，因为丢弃token会导致模型精度损失，而且昇腾的硬件对“条件丢弃”支持不好（需要额外的mask操作，增加开销）。第二种是“动态负载均衡调度”（Dynamic Load Balancing），即每个step前根据历史负载预测，预先调整专家在物理设备上的分布。这个方案在理论上很好，但实践中需要额外的通信开销来同步负载信息，而且在昇腾上，HCCL的all-gather操作在跨节点时延迟很高，导致预测的时效性不足。第三种是我们最终采用的方案，叫“层级式专家并行+静态路由剪枝”。具体做法是：把专家分成几个组，每个组内的专家在物理上放在同一个节点（比如8卡节点），组间通过跨节点通信做all-to-all；同时，在训练时强制每个batch的token数量是固定的，并且在路由层加入一个“均匀化约束”——即让路由器的输出概率分布尽量均匀，这样每个专家激活的token数就不会差异太大。这个约束是通过一个辅助损失函数实现的，类似GShard里的auxiliary loss。在昇腾上，这个方案的效果不错，MFU损失不到3%，但负载不均从原来的30%方差降到了5%以内。不过要注意，这个辅助损失会轻微影响模型收敛，需要调参。

第二个问题：芯模协同是否意味着未来模型发布要针对每款芯片做定制化优化？从短期来看，是的，而且这可能是未来3-5年内国产算力生态的常态。但我不认为这是坏事——相反，它会催生一个“模型-芯片适配服务”的新产业。想象一下，未来会有一类公司，专门做模型的硬件适配，比如把Llama-5优化到寒武纪上，把GPT-5优化到昇腾上。这些公司会开发一套“适配中间件”，里面包含算子库、编译优化、通信调度、负载均衡等模块，让模型研发团队可以专注于算法，而不必关心底层硬件。事实上，现在已经有这样的苗头了：比如“硅基流动”在做大模型的多芯片适配，他们的思路是用Triton语言写算子，然后通过不同的后端编译到不同芯片上。但Triton目前在昇腾上的支持还很初级，只能支持简单的element-wise操作，复杂算子如FlashAttention还得手写。所以我认为，更现实的路径是：每个芯片厂商提供自己的“模型优化工具链”，比如昇腾的MindSpore+CANN，寒武纪的MagicMind，海光的ROCm+DCU，然后模型团队根据目标芯片选择对应的工具链。但这里有一个巨大挑战：模型团队不可能为每个芯片都维护一套代码，所以最终会形成“基座模型+芯片插件”的模式——基座模型用PyTorch写，然后通过一个“芯片适配层”自动转换。这个适配层需要解决算子映射、内存管理、通信库替换等问题。我在业余时间尝试过用ONNX作为中间表示，把DeepSeek V4的MoE部分导出到ONNX，再通过昇腾的ONNX Runtime适配器跑，结果失败了——因为MoE的动态路由在ONNX里无法静态表达，运行时需要动态创建子图。所以这个适配层的核心难点，其实是“动态计算图的编译优化”。这可能是未来两三年AI编译领域最重要的研究方向之一。

最后，我想补充一点关于“芯模协同”的长期思考。你帖子标题说“打脸了多少质疑”，我其实觉得质疑是好事。如果没有质疑，就没有动力去突破。DeepSeek V4证明了在国产芯片上也能做出世界级的MoE性能，但这不是终点，而是起点。我注意到一个细节：AIGCode在实现中大量使用了CANN的“算子融合”功能，比如把多个小矩阵乘法融合成一个大的batch GEMM，这其实是NVIDIA cuBLAS早就有的能力。但昇腾的融合策略需要手动配置，不像NVIDIA那样有自动调优器（比如cuBLAS的heuristics）。这说明，国产芯片的软件栈还在补课阶段，但补课的方向是对的——不是在重复造轮子，而是在理解模型需求的基础上做差异化。比如，昇腾的“动态稀疏计算”能力，NVIDIA要到Hopper才支持，而昇腾在910B上就已经有了硬件原语（虽然软件支持还不好）。所以我的判断是：芯模协同的终局，不是模型去适应芯片，也不是芯片去适应模型，而是两者在“计算-存储-通信”的抽象层上达成共识，形成一套“硬件无关的AI计算范式”。到那个时候，我们就不用再纠结“换芯片要不要重写模型”了。

写到这里，我想起几年前在知乎上看过一个问题：“国产AI芯片什么时候能追上NVIDIA？”当时我觉得是5年，现在我觉得可能更快，但前提是——模型团队和芯片团队必须坐在一起写代码，而不是各自为战。DeepSeek V4和AIGCode的合作，就是一个很好的样板。希望未来有更多这样的案例，也希望国产芯片的工具链能早日从“青年期”进入“成年期”。如果你也在踩类似的坑，欢迎一起交流，我有一些昇腾MoE训练的调优脚本和性能分析工具，可以共享出来。

MFU能到65%确实挺炸的，我去年在昇腾上搓过一个简化版的MoE验证，通信调度那块的坑踩得想骂娘，算子融合稍微没对齐，带宽就卡死在20%出头。CANN这次能把动态稀疏计算和达芬奇架构的tiling策略对上，说明他们内部对模型结构和芯片微架构的联动理解确实上了一个台阶，不是以前那种“我给你个算子库你自己看着办”的态度了。

不过你担心的硬件绑定问题，我也有同感。DeepSeek这套芯模协同，说白了是把MoE的expert路由、sparse计算模式和昇腾的cube单元结构做了深度耦合，甚至可能连memory hierarchy的预取策略都调过。换到寒武纪的MLU或者海光的DCU，指令集、缓存层级、甚至memory bandwidth的分布都不一样，这套优化大概率要重做。我猜他们内部做这种深度耦合的时候，可能把一部分计算图层面的优化写成了针对昇腾IR的pass，那跨平台复用的难度就很大了。

但换个角度想，这种“单点突破”未必是坏事。现阶段国产芯片生态本来就碎片化严重，与其搞一套谁都跑不动的通用优化，不如先在昇腾上把天花板打穿，给行业一个可参考的工程标杆。等大家看到“65% MFU”是能实现的，自然会有动力去对齐各自平台的优化接口。不过说真的，要是DeepSeek后续能把这套协同策略抽象出一层中间表示，只把硬件相关的部分做成plugin，那才是真正从“能用”走向“可迁移”。不然现在这个65%，就真成了昇腾独占的showcase了。

这个MFU数据确实挺炸的，我反复琢磨了一下，65%在MoE模型上意味着他们肯定把通信和计算重叠做到极致了。之前我们自己在昇腾上试过类似的优化，光是解决AlltoAll的带宽利用率就折腾了好久，最后MFU也就勉强到40%左右。所以看到这个数字第一反应是：他们到底在算子融合上做了什么改动？是改了数据排布还是直接在CANN层做了定制化调度？

你提的那个硬件依赖性问题我也在想。现在昇腾的达芬奇架构对动态稀疏计算支持比较好，但换成寒武纪的MLU或者海光的DCU，底层指令集和内存层次结构完全不一样。比如寒武纪的局部存储容量和带宽特征跟昇腾差别挺大的，那个“对齐”策略大概率要重写。我猜DeepSeek可能是在算子层做了抽象，把硬件相关的部分封装成可替换的胶水代码？但如果是这样，性能损耗又会是多少？

另外，这种芯模协同另一种风险是：如果未来昇腾出了新架构，比如达芬奇3.0，这套优化还能丝滑迁移吗？还是说每次硬件迭代都要重新对齐一次？毕竟模型架构和芯片深度耦合之后，升级成本就从纯软件变成了软硬一体，这对团队维护要求太高了。感觉他们要么是赌昇腾架构会长期稳定，要么是内部有专门的硬件适配团队在兜底。有没有可能他们把一部分优化思路开源出来，让社区一起探索跨平台方案？这比闷声搞黑科技更有价值吧。

这个MFU数据确实离谱，之前我们在昇腾上折腾MoE，通信优化搞到吐也就30%出头。不过你提的硬件锁定问题很关键，我猜DeepSeek这套动态稀疏和达芬奇架构的耦合，换到寒武纪的MLU架构上大概率要重构算子调度逻辑，除非他们提前做了硬件抽象层。建议看看他们的论文有没有提编译器中间表示层面的兼容方案。

这个数据确实挺震撼的，65%的MFU在MoE模型上实现，说明CANN这几年优化没白费。之前我们团队试过在昇腾上跑小规模的MoE，光是通信拓扑调整就折腾了两周，算子融合更是手动改到吐，最后MFU也就勉强到35%左右。V4这种动态稀疏计算和达芬奇架构的深度对齐，感觉是把硬件特性吃透了才能做到的。

不过你提的那个硬件依赖问题我也很在意。现在国产芯片各自为战，昇腾有达芬奇，寒武纪有MLU，海光用的是DCU，指令集和内存层次差异太大了。这种芯模协同如果只是针对昇腾做了手工调优，那换到其他芯片上，可能不光要改算子库，连模型层面的稀疏策略都得重新设计。比如昇腾的达芬奇架构对稀疏计算有专门的硬件支持，但寒武纪的MLU可能更擅长密集矩阵运算，那动态稀疏的收益就会打折扣。

我比较好奇的是，DeepSeek有没有在论文或者技术报告里提到过这种优化的通用性？比如他们是否抽象出了一套硬件无关的调度接口，或者只是对昇腾做了极致压榨？另外，这种协同优化如果换到英伟达的H100上，理论上MFU还能更高，但会不会因为CUDA生态太成熟，反而不容易做这种硬件和模型深度耦合的定制？感觉这其实是个生态选择问题，押注单一硬件路线还是多平台适配，挺考验工程团队的。

这个MFU 65%确实亮眼，但更值得关注的是动态稀疏计算与达芬奇架构的对齐方式——这其实是在用模型结构反向定义芯片的调度逻辑，一旦换到寒武纪的MLU或者海光的DCU，算子映射和访存模式几乎得重来。我个人觉得这种深度耦合是把双刃剑，短期能冲性能指标，但长期看，如果国产芯片生态不能统一一套可移植的算子抽象层，每换一家硬件就相当于重新做一次芯模适配，那“协同”就成了绑定。

65%的MFU确实夸张，我们之前调MoE通信拓扑头都大了，CANN这波优化至少把算子下发延迟降了一个量级。不过你说的硬件绑定问题我也在纠结，昇腾的达芬奇架构对动态稀疏有天然优势，换到寒武纪的MLU架构可能得重新设计稀疏路由策略，代码层面估计得大改，希望官方能出个硬件抽象层隔离一下。

这个MFU 65%的数据确实挺震撼的，之前在昇腾上跑MoE，通信和算子适配的坑我踩过不少，尤其动态稀疏那部分，数据搬运和计算穿插的调度一不小心就卡在带宽上。V4这个做法说白了就是把模型的计算图拆得更细，直接对准达芬奇架构的流水线特性，让稀疏计算尽量贴合硬件的数据流，减少无效搬运，这个思路在工程上确实比单纯堆算子优化要彻底。

不过你提的那个硬件依赖问题，我个人觉得短期看是绕不开的。芯模协同本身就是个强耦合的事，你要在昇腾上做到接近两倍的MFU，肯定在算子调度、显存管理甚至编译器的IR层做了大量针对性的定制，这些优化换到寒武纪的MLU架构或者海光的DCU上，大概率要重写一部分。毕竟不同芯片的缓存层级、互联拓扑、甚至指令集的并行度都不一样，V4这套策略本质上是把模型的计算图“雕刻”成了昇腾的形状，换块芯片可能就水土不服了。

但换个角度想，这也不一定是坏事。如果DeepSeek能把这套协同方法论抽象出一套可配置的接口，比如定义好芯片特性描述文件和模型架构的映射规则，那后续适配其他国产芯片就能走个半自动化的流程，不用从零开始。现在国产芯片生态最大的痛点就是各自为战，缺的就是这种能拉通“模型-芯片”两层设计的工程框架。V4至少证明了这个方向能跑通，剩下的就看能不能把经验沉淀成工具链了。

这数据看得我直接坐起来了，65%的MFU在昇腾上跑MoE，之前想都不敢想。我们组去年在华为云上试过类似的稀疏MoE部署，卡在通信拓扑优化上，CANN的算子融合当时还没那么成熟，调了两个月也就勉强到40%左右，那会儿真是边吐槽边肝。V4这波确实把“芯模协同”从PPT里拽出来了，动态稀疏计算和达芬奇架构的适配思路挺野的，等于把模型的计算流硬生生掰成了芯片最舒服的形状，无效数据传输砍掉之后，算力利用率肯定上台阶。

不过你那疑问我也特别有共鸣。这种深度耦合的代价就是绑定太死，换个硬件环境可能直接水土不服。我猜DeepSeek在昇腾上这么下功夫，可能也是看中了华为现在国产化替代的生态位，毕竟服务器采购现在优先考虑信创，昇腾出货量确实大。但往远了说，如果哪天寒武纪或者海光也出类似的高性能方案，这套优化逻辑大概率要推倒重来，因为底层内存层次和并行机制完全不一样——比如海光那块更像英伟达的CUDA core结构，昇腾的达芬奇是三维Cube阵列，算子映射策略就不通用。

我倒觉得这反而是行业该讨论的：芯片厂商是不是也该反过来主动适配主流模型架构？而不是总让算法团队去迁就硬件。V4这一步走得挺漂亮，但不该是唯一的路。建议你可以看看他们开源的那个CANN适配层代码，里面应该有部分硬件抽象接口，说不定能剥离出一些通用逻辑。

65%的MFU确实亮眼，说明CANN在算子融合和通信拓扑上下了硬功夫，MoE场景下能把动态稀疏做到这个程度不容易。但你说的硬件绑定问题我也一直关注，昇腾的达芬奇架构本身对稀疏计算友好，换到寒武纪的MLU或者海光的DCU，这套动态稀疏调度策略大概率要重写算子映射层。不过换个角度想，这种深度优化可能正是国产芯片生态各自突围的必经阶段，先在某条路上跑通比追求通用性更务实。

同感，看到MFU 65%这个数据确实挺震撼的。我们之前自己在昇腾上折腾MoE的时候，光通信拓扑就调了快两周，算子融合更是各种踩坑，最后MFU也就30出头，离理论峰值差得远。所以这次V4能拉到这个水平，说明CANN底层的算子库和通信库确实打磨到位了，不是光靠堆算力就能实现的。

不过你最后那个疑问我也特别在意。这种把模型结构和芯片特性深度绑定的做法，从工程角度看肯定是高效的，毕竟减少了无效数据传输和计算浪费。但问题在于，如果昇腾的达芬奇架构有自己的独特设计，比如特定的稀疏计算单元或者内存层次，那这套优化策略大概率是hardcoded进去的。换到寒武纪或者海光，它们的指令集和内存模型不一样，同样的动态稀疏策略可能就得重写，甚至可能因为硬件不支持而直接失效。

我比较好奇的是，DeepSeek有没有在论文或者技术报告里提到过这种协同优化是否做了某种抽象层？比如定义了一套硬件抽象接口，让模型架构的优化逻辑可以部分适配不同芯片？还是说现阶段就是完全针对昇腾做的深度定制，未来再考虑迁移？如果后者，那国产芯片的生态碎片化问题就还是没解决，大家各玩各的，很难形成合力。要是能有个统一的优化框架就好了，哪怕性能差一点，至少能跑起来。

这个MFU 65%的数据确实硬核，说明CANN在算子融合和通信拓扑上下了真功夫，之前昇腾跑MoE那个通信阻塞的坑我太熟了。不过你担心的点我也有同感，这种深度耦合的优化往往是双刃剑，换到寒武纪的MLU或海光的DCU，指令集和缓存层次全变，动态稀疏的调度策略大概率要重写。如果DeepSeek能在芯模协同层抽象出一套硬件无关的中间表达，那才是真正能复用的技术底座。

看到这篇帖子，确实有共鸣。我在AI芯片和模型优化这个交叉领域摸爬了五六年，从英伟达的CUDA生态一路折腾到国产芯片的适配，中间踩过的坑、流过的泪，怕是能写一本《国产算力血泪史》。你提到的DeepSeek V4在昇腾上实现MoE模型MFU 65%，这个数据我反复看了几遍，说实话，第一反应是“有点东西”，但紧接着就是“这背后得有多少工程妥协”。

先说说这个65% MFU。在昇腾上跑MoE，我太熟悉那种绝望了。去年我们团队做过一个类似的实验，用一个中等规模的MoE模型（8个专家、每专家约1B参数）在昇腾910B上做推理优化。初期MFU只有22%，后来我们花了整整三个月，把算子融合、通信拓扑、内存复用这些环节全部手撕了一遍，才勉强提到35%。你提到的“通信瓶颈”和“算子适配”，我太有体会了。MoE的All-to-All通信在昇腾上简直是噩梦——它的HCCS互联带宽虽然标称很高，但实际传输时，由于路由算法的调度粒度不够细，经常出现部分链路满载、部分链路空闲的情况。我们当时用NCCL的PXN模式做参考，在昇腾上改了一版基于环拓扑的通信原语，把专家间的数据交换从全连接改成了分阶段流水线，才把通信延迟压下来。而DeepSeek V4能做到65%，说明他们在算子层面做了更极致的定制——比如动态稀疏计算与达芬奇架构的“脉动阵列”对齐，这不仅是算法层面的稀疏化，更是把计算流图里的无效数据搬运彻底剪掉了。我猜他们可能用了一种“稀疏感知的算子调度器”，在运行时根据专家激活的稀疏模式，动态调整计算核的加载顺序和内存访问模式，避免因为稀疏导致的硬件利用率下降。

不过，你提的那个“绑定风险”问题，恰恰是我最担心的。这种优化本质上是在“把模型架构焊死在芯片特性上”。举个例子，昇腾的达芬奇架构有一个特点——它对“小矩阵乘法”的吞吐支持很差，因为它的计算单元是为大块连续数据设计的。而MoE模型的动态路由，会频繁产生小矩阵乘法（比如专家权重和输入向量的点积），如果直接跑原生代码，性能会暴跌。DeepSeek V4大概率是通过“权重预分块+计算合并”来规避这个问题的：他们把专家的权重矩阵按维度拆成固定大小的块，在计算时把多个小矩阵乘法合并成一个大矩阵乘法，从而利用升腾的高带宽。但这套优化逻辑，放在寒武纪的MLU架构上就不一定成立——寒武纪的计算单元更擅长处理非连续的内存访问，但它的缓存一致性协议比较弱，大规模稀疏计算会导致缓存抖动。你如果原封不动把昇腾上的优化搬过去，可能MFU直接掉到20%。我去年帮一家公司做过从昇腾到寒武纪的模型迁移，他们在昇腾上优化后的MoE模型，换到寒武纪上，通信和计算的重叠率从85%降到了40%，就是因为寒武纪的流处理器对异步操作的硬件支持不够深。所以，芯模协同的代价就是“模型发布要针对每款芯片做定制化优化”，这几乎不可避免。但这不是坏事——它反而倒逼芯片厂商把工具链和生态文档做扎实。你看英伟达的CUDA生态，为什么能一统天下？不是因为它硬件最强，而是它给开发者提供了“一套代码多硬件跑”的抽象层，以及像Nsight这样能精确定位瓶颈的调试工具。CANN现在虽然从“幼儿期”到了“青年期”，但离“成熟期”还有几个版本的距离——我最近做性能分析时，发现它的Profiling工具在采集算子级时间戳时，会漏掉部分异步执行的事件，导致你看到的瓶颈可能是假的。这点上，我建议团队去参考TensorBoard的XLA Profiler设计，把硬件事件和模型层的执行流做双向映射。

回到你提的两个具体问题。第一个，MoE动态路由在昇腾上如何避免负载不均？这其实是个系统性问题。我们在实际部署中遇到过一种情况：某个专家因为承接了高频激活的token，计算负载是其他专家的3倍以上，导致整个推理过程被那个慢专家卡住。昇腾的调度器默认是“先到先服务”的，不会主动做负载均衡。我的解决方案是两阶段：第一，在训练阶段引入“专家负载正则化”，让损失函数里加入专家激活频率的方差惩罚项，强制模型把流量打散；第二，在推理阶段，用“动态专家分组”策略——把多个计算能力弱的专家合并成一个虚拟专家，在昇腾的tensor core上做批处理。具体实现上，我们写了一个自定义的triton kernel，在专家路由阶段先统计每个专家的当前负载，然后根据负载阈值动态调整token分配策略。比如，当某个专家的请求队列长度超过100时，后续token会被随机分配到负载最低的专家上，而不是严格按照路由权重。这虽然会轻微损失模型精度（我们的实验显示perplexity上升约0.3%），但能把推理延迟降低40%以上。昇腾的硬件有一个好处——它的内存带宽足够大，支持在运行时动态重排专家权重，所以这个“动态分组”策略是可行的。如果是寒武纪，因为它的显存带宽只有昇腾的60%左右，重排成本太高，反而得不偿失，只能走训练阶段的正则化路线。

第二个问题，芯模协同是否意味着未来模型发布要针对每款芯片做定制化优化？从我看到的行业趋势来看，答案是“短期是，长期可能不是”。短期来看，国产芯片百花齐放，每家的计算单元、内存层次、互联拓扑都不一样，比如昇腾是“大核+高带宽”路线，寒武纪是“小核+高并行”路线，海光则是“类CUDA + 通用计算”路线。模型发布如果不做芯片级适配，性能差距可能达到3-5倍。但长期来看，我相信会形成一套“中间表示层”：比如用MLIR或者Triton这样的编译器基础设施，把模型计算图表示为与硬件无关的IR，然后针对每款芯片的后端做自动代码生成。我在做开源项目时，尝试过把MoE的专家路由逻辑写成Triton kernel，然后在昇腾上用CANN的TBE接口做后端编译，效果还不错——虽然手写了200行Triton代码，但编译出来的二进制在昇腾上跑，MFU比纯CANN实现高了8%。这表明，只要编译器后端能理解芯片的硬件原语，是可以做到“一次编写、多芯片部署”的。所以，未来模型发布时，可能不是针对每款芯片做定制化优化，而是训练一个“硬件感知的模型骨架”，在部署时通过编译器自动适配。这听起来很理想，但前提是芯片厂商愿意开放底层硬件描述——比如昇腾的“脉动阵列宽度”和“缓存行大小”这些参数，目前CANN的文档里是保密的，导致编译器无法做精确的指令调度。如果这一点不放开，定制化优化就是唯一的出路。

最后，我想补充一个帖子没提到但同样关键的点：芯模协同对模型训练的影响。你提到的MFU 65%应该是指推理场景，如果是训练，MoE模型的动态负载和梯度同步会更噩梦。我们在昇腾上试过用ZeRO-3加MoE分布式训练，结果因为昇腾的集合通信库对稀疏梯度同步支持不好，每轮通信的额外开销占了30%以上。后来我们借鉴了DeepSpeed的Mixture-of-Experts优化思路，在昇腾上实现了“专家级梯度分桶”策略：把每个专家的梯度按大小分成多个桶，然后根据昇腾的通信链路利用率动态调整桶的合并粒度。比如，当链路利用率低于70%时，把多个小桶合并成一个大桶发送；高于85%时，拆分成更小的桶以减少等待延迟。这个优化让训练吞吐提升了22%，但代码复杂度增加了不止一倍。所以，芯模协同在训练场景下，更像是一场“工程妥协的艺术”——你必须在模型效果、训练效率、硬件利用率之间反复权衡，没有银弹。

总之，DeepSeek V4的成果值得肯定，但它揭示了一个更深刻的挑战：国产算力生态要真正成熟，不能只靠一家公司的“极致优化”，而是需要建立一套让所有芯片都能“公平竞争”的标准化工具链和硬件抽象层。否则，我们每换一款芯片，就要重新发明一次轮子——这对整个行业的健康发展可不是好消息。希望我这些踩坑经验能给你一些启发，也欢迎你对我的观点提出反驳，毕竟，这种讨论本身就是在推动我们一起往前走。

这帖看得我直拍大腿。你说的MFU 65%这个数字，我第一反应也是反复确认了好几遍——之前我们团队在昇腾上折腾MoE，通信算子自己手搓，调度策略全靠调参玄学，MFU能摸到35%就已经烧高香了。AIGCode这波能把动态稀疏计算和达芬奇架构对齐，说明他们确实把底层流水线吃透了，不是拿现成框架跑个benchmark就交差。

不过你那个疑问我也一直在琢磨。这种深度耦合的优化，说白了就是把模型的计算图、数据搬运、甚至算子排布都绑死在特定芯片的特性上。昇腾强在Matrix算子和HCCS互联，但寒武纪的MLU架构走的完全是另一套并行逻辑，海光的DCU更接近AMD的CDNA路线。如果这套协同策略是靠大量手写汇编或者CANN底层的trick堆出来的，那迁移成本可能高到吓人。我猜他们可能用了一层抽象，比如把芯模协同的接口标准化，但具体到指令级优化还得重新适配——这就要看DeepSeek团队愿不愿意把这块“黑盒”拆开共享了。

另外我倒是好奇，他们在昇腾上跑MoE的通信拓扑是怎么设计的？之前我们试过Ring AllReduce和Hierarchical AllReduce，负载不均衡的时候抖动特别大，不知道V4是不是用了某种动态路由策略来规避热点。要是能公开这部分细节，对其他国产芯片的适配会很有参考价值。毕竟大家都想看到生态百花齐放，而不是单一硬件绑死。

这帖子看得我直拍大腿，MFU 65%这个数字确实太提气了。之前我们在昇腾上搞MoE，通信卡得死死的，动态稀疏算子的适配简直是玄学，调优调到头秃也就勉强到30%出头，稍微跑个大batch就直接崩。DeepSeek V4这次能把架构和芯片抠得这么细，说明CANN那套底层确实打通了，不再是以前“接口能用但性能稀碎”的状态了。

不过你最后那个疑问我太有同感了。这种深度耦合说白了就是拿硬件特性当“特化调优”，比如动态稀疏计算跟达芬奇架构的绑定，换个芯片可能连稀疏计算的核心思路都得推倒重来。我瞎猜一下，他们可能是用了一套中间表示层来抽象硬件差异，类似TVM或者MLIR那种思路，但实操中要做到跨芯片自动调优，工程量不是一般的大。尤其是寒武纪和海光，指令集和内存体系完全不同，就算能跑起来，估计MFU得腰斩。

我倒觉得，与其担心复用性，不如先把昇腾这条线榨干。毕竟国产AI芯片生态里，昇腾现在算是最完整的了，CANN的工具链、算子库和社区支持都在快速迭代。如果V4能把这套方案开源出来，让社区针对不同芯片做二次适配，反而可能更快推动国产芯片的协同进化。就怕这东西是商业机密，那大家就只能等着看后续的适配报告了。

话说回来，你们团队之前跑MoE时，通信瓶颈具体出在哪？是AlltoAll还是参数同步？我这边试过改流水线策略勉强提升了一点，但代价是显存暴涨，不知道你们有没有更好的解法？

这个帖子看得我热血沸腾，终于有人把芯模协同这件事从“玄学”拉回到“工程”层面来讨论了。你提到的MFU 65%这个数字，我第一反应也是去查了AIGCode的官方披露，确认不是测试集过拟合或者刻意选取的稀疏场景——如果这个数据是在端到端训练任务中稳定跑出来的，那确实意味着CANN生态在MoE模型上的调度能力已经摸到了硬件极限的边。我在去年年中帮客户做过一次昇腾910B上的MoE模型适配，当时用的还是CANN 5.0.x，那个痛苦程度我现在想起来还头皮发麻。我们选的是DeepSeek MoE 16B的简化版，模型结构基本一致，但为了踩坑方便把专家数量砍到了8个。结果第一个月几乎全在跟通信算子搏斗：昇腾的HCCS在跨节点通信时，默认的拓扑感知策略对MoE的all-to-all模式支持极差，我们不得不手动写了一套基于rank映射的通信分组方案，把每个token的专家路由先做本地聚合，再通过reduce-scatter跨节点分发。即便如此，MFU也只勉强到28%，而且负载极度不均——某些专家收到的token数超过均值的3倍，而另一些几乎闲置。后来我们分析发现，昇腾的达芬奇架构在动态稀疏计算上有个隐藏缺陷：它的Cube单元对非对齐的稀疏矩阵乘法支持并不好，当MoE路由出来的token分布不均匀时，实际的计算密度会断崖式下跌，因为硬件不得不频繁做padding和无效计算。后来我们改用了top-2路由加辅助损失来强制负载均衡，但代价是模型精度掉了0.3个点，而且推理延迟反而增加了，因为路由决策变得复杂了。

你提到的“动态稀疏计算和达芬奇架构对齐”，我深有体会。DeepSeek V4这次能在昇腾上把MFU推到65%，大概率是在算子层面做了两件事：一是把MoE的专家计算拆成了细粒度的“微批次”，利用昇腾的AI Core支持多流水线并行的特性，让不同专家在同一时刻处理不同长度的token序列，从而抵消负载不均带来的计算空洞；二是对路由算法做了硬件感知的剪枝，比如只保留top-2中置信度最高的那个专家，另一个专家用低精度量化后的近似计算来替代，这样虽然牺牲了一点精度，但大幅减少了通信量。我甚至怀疑他们可能用到了昇腾的“动态shape”特性——在CANN 6.0之后，昇腾支持了运行时根据输入tensor的形状动态调整Cube单元的配置，这在以前的版本里根本做不到。不过，我在实际测试中发现，这个动态shape特性在跨卡场景下会引发一个严重的同步问题：当不同卡的专家接收到的token数量差异过大时，CANN的运行时调度器会频繁触发全局同步，反而导致通信开销飙升。我们当时用了一招笨办法：在模型forward函数里插入一个自定义的同步点，手动检查每个rank的token数量是否在预设阈值内，如果偏差超过10%就强行做一次负载重分配。这个方案虽然土，但确实把MFU从30%提到了38%，不过对代码侵入性太强，维护成本极高。

回到你提出的第一个问题：MoE模型的动态路由在昇腾上如何避免负载不均？我的实操经验是，单纯靠辅助损失强制均衡是不够的，因为路由决策本身受输入数据分布影响极大。我们试过几种方案：第一种是基于历史统计的静态路由表，在训练初期收集每个样本的专家选择偏好，然后固化到路由层，但这样模型很快过拟合，因为数据和专家之间的映射关系会随着训练动态变化。第二种是引入“专家缓存”机制，把每个专家当前处理的token数量作为一个可学习的权重加到路由logits里，让路由倾向于选择负载更低的专家——这个在论文里叫“load-aware routing”，但昇腾的CANN对自定义算子支持极差，我们不得不把整个路由层用TBE（Tensor Boost Engine）重写，前后花了三周，最终效果也就把负载方差降低了15%左右。第三种方案是我目前觉得最有潜力的：利用昇腾的“硬件事件触发”机制。昇腾的AI Core在计算过程中可以抛出硬件事件（比如计算单元利用率低于阈值），如果能把这个事件信号直接反馈给路由层，让路由在硬件空闲时主动增加对该专家的token分配，就能实现真正的“计算感知路由”。但这个需要CANN开放更底层的硬件接口，目前我还没看到相关文档，估计DeepSeek团队和华为有深度合作才能拿到这些能力。

你第二个问题才是真正的灵魂拷问：芯模协同是否意味着未来模型发布要针对每款芯片做定制化优化？我的答案是：大概率会，而且这可能是国产算力生态必须跨过的“窄门”。你提到的“绑定风险”非常关键——如果DeepSeek V4的优化高度依赖昇腾的达芬奇架构，那么换到寒武纪的MLU或者海光的DCU上，这套策略几乎要推倒重来。我去年在寒武纪MLU370上做过类似的MoE适配，结果堪称灾难：寒武纪的硬件对稀疏计算的支持比昇腾还弱，它的矩阵乘法单元要求输入必须是规则形状，所以MoE的专家计算只能通过逐个token的循环来实现，性能直接掉到个位数。更致命的是，寒武纪的CNNL生态对动态图的支持几乎是零，我们只能把所有路由逻辑用静态图表达，但MoE的路由天然就是动态的，最后不得不把所有专家都实例化成固定的计算节点，然后通过条件判断来跳过不参与的专家——这相当于把动态路由退化成了静态选择，MFU从昇腾上的28%掉到了12%。海光的情况稍好一点，因为它的DCU兼容ROCm生态，至少可以复用一些PyTorch的原生算子，但海光的显存带宽只有HBM2e级别，而MoE模型对显存带宽极其敏感，因为专家参数需要频繁加载和卸载，带宽不足直接导致计算单元大量时间在等待数据。我们在海光DCU K100上跑同样的MoE模型，MFU只有22%，而且显存占用比昇腾高了40%，因为海光不支持昇腾那种细粒度的显存复用策略。

但反过来看，这也正是国产算力生态的机会。如果每一家芯片厂商都能像DeepSeek和华为这样，在模型发布阶段就深度介入硬件适配，那么最终形成的不是“绑定”，而是“共生”。我最近在关注一个趋势：模型架构设计开始主动考虑硬件特性，比如让MoE的专家数量等于芯片的物理核心数，这样每个专家天然映射到一个核上，通信路径最短；或者让路由的top-k选择与芯片的并行粒度对齐，比如昇腾的AI Core一次处理64个token，那就让路由每次输出64个token的专家分配结果，而不是逐token决策。这些做法听起来很激进，但DeepSeek V4已经证明了这条路行得通。我甚至觉得，未来可能会出现一种“硬件感知的模型编译器”，它接受模型定义和芯片spec作为输入，自动生成最优的计算图和内存分配方案。CANN的下一代版本据说已经在做类似的事情，叫“CANN AutoTune”，但我在内测群里看到的效果还不稳定，有时候自动生成的图反而比手写的慢30%。

至于工具链的成熟度，你提到CANN不如Nsight顺手，我完全同意。Nsight的profiling能做到指令级的热点分析，而CANN的msprof现在还停留在算子级，而且对异步执行流的追踪经常丢数据。我去年在昇腾上遇到一个bug：某个算子的计算时间在profiling里显示只有2ms，但实际端到端延迟却多了50ms，后来排查发现是CANN的运行时在算子启动前做了一次隐式的显存碎片整理，但这个事件在profiling里完全不记录。这种黑盒问题在调试时极其痛苦，我们只能通过插入时间戳来手工定位，效率极低。华为的CANN团队其实已经在改进，比如6.0版本加了算子级时间线视图，但和Nsight的差距至少还有两代。不过好消息是，华为最近开源了部分CANN的运行时源码，虽然只是冰山一角，但至少让我们看到了底层调度的逻辑，比如显存池的管理策略、任务队列的调度优先级等。我猜DeepSeek团队能拿到65%的MFU，很可能就是基于对这部分源码的深度理解，绕过了CANN的某些默认行为。

最后，我想补充一个你可能没提到的视角：芯模协同对模型压缩和量化策略的影响。我们团队在昇腾上做MoE量化时发现，不同专家对量化精度的敏感度差异极大——某些专家用INT8量化后精度几乎不掉，而另一些专家用FP16都扛不住。传统的量化策略是全局统一设置，但芯模协同的思路下，完全可以根据每个专家的计算特征和硬件特性做差异化量化。比如让频繁被选中的专家（热点专家）保留FP16精度，而冷门专家用INT4量化，这样既节省了显存带宽，又不影响整体精度。昇腾的达芬奇架构其实原生支持混合精度计算，但CANN的量化工具只支持逐层设置，不支持逐专家设置。我们手动改了一版，在量化过程中把每个专家的权重单独处理，然后通过路由表动态切换计算精度——这个方案在离线评估时MFU又提升了5个百分点，但训练稳定性成了问题，因为量化误差会随着训练累积。后来我们引入了知识蒸馏，让高精度版本的模型作为teacher指导量化版本的训练，才把这个坑填上。

总之，DeepSeek V4这次在芯模协同上的突破，最大的价值不是那个65%的数字，而是证明了“模型引导芯片设计”这个方向是可行的。接下来就看其他芯片厂商能不能跟上——如果寒武纪和海光也能在V5发布前推出类似的协同优化，那国产算力生态就真的活了。但工具链和调试体验的短板，需要整个社区一起推动，不能只靠华为一家。我已经在计划写一个昇腾MoE调优的踩坑指南，到时候发到社区里，希望更多人能少走弯路。

昇腾上我们之前试过类似的优化，通信开销确实是硬骨头，65%的MFU能落地说明CANN在算子融合和显存调度上应该下了真功夫。不过你说的硬件绑定问题我也在琢磨，动态稀疏计算这个思路其实跟达芬奇架构的特定数据流强相关，换到寒武纪的MLU架构可能得重新梳理计算图，复用率估计得打折扣。要是官方能出一份跨芯片适配的抽象层规范，大家迁移起来会踏实很多。

65%的MFU在昇腾上确实挺炸的，我们之前在910B上试过类似的MoE模型，通信优化没做透，MFU死活卡在35%左右，后来发现是All-to-All的拓扑没对齐芯片的ring buffer特性。V4这个成绩说明他们肯定把CANN底层的算子融合和流水线排布啃下来了，不是光靠吹。

不过你提的那个硬件绑定的问题，我也有同感。这种深度耦合说白了就是拿昇腾的达芬奇架构当“锚点”去设计模型结构，比如动态稀疏的路由策略肯定针对了昇腾的SIMD指令集做了特化。换到寒武纪的MLU或者海光的DCU，指令集和内存层次都不一样，这套优化大概率要推倒重来。我猜DeepSeek可能是赌昇腾会成为国产主力，先跑通标杆案例，后续再考虑跨平台适配——但这对我们这种需要多供应商备选的企业来说，确实是个隐忧。

另外有个点想问下，他们这个65%是单机8卡还是跨节点？如果跨节点的话，通信拓扑和计算流的重叠是怎么做的？我之前试过把专家并行和昇腾的HCCL做适配，发现跨机通信延迟波动比较大，靠纯静态调度很难压住。要是V4能分享一下动态负载均衡的细节，那才是真正造福社区。

干过昇腾上MoE的表示，65%的MFU确实有点离谱，我之前调通信和算子调度搞到35%就开始掉头发了。动态稀疏计算跟达芬奇架构对齐这个思路，说白了就是让模型去“迁就”芯片的脾气，减少数据搬移浪费，这点在工程上挺实在的。

但你提的那个问题很要命。这种“深度耦合”一旦做深了，基本就是对着昇腾的spec做定制优化，比如缓存策略、算子融合的粒度，甚至可能连通信拓扑都是跟着昇腾的HCCL走的。换到寒武纪或者海光，除非它们在架构思路上有类似的特性（比如也支持某种动态稀疏模式或者有相似的显存层级），否则这套优化大概率要重写。我之前在某个国产芯片上移植过一套针对Tensor Core优化的算子，结果对方连矩阵乘法指令都不同，几乎等于从零开始。

而且更现实的问题是，现在很多厂商的芯片生态还在追赶期，CANN好歹有大厂在推，寒武纪和海光的工具链成熟度、社区文档、踩坑案例都差一截。你就算想复用逻辑，可能连对应的算子库或者profiling工具都没有。

所以我的感觉是，DeepSeek V4这次更像是给昇腾生态打了个样，证明这条路能走通，但真要普惠到国产芯片全栈，可能还得靠更上层的编译器和中间件来抽象一层。不然每换一家芯片，工程师就得脱层皮。

65%的MFU确实夸张，我们之前在昇腾上折腾MoE时，通信拓扑和算子切分调得头秃也就40%出头，这次深度耦合的思路看着像把底层流水线全打通了。不过你提的硬件绑定问题我也在想，达芬奇架构的稀疏计算单元和动态路由的匹配度太高，换到寒武纪的MLU或者海光的DCU，这套黑魔法估计得重写大半，到时候可能得看各家有没有类似的算子级协同接口了。