65%的MFU在昇腾上确实是个里程碑，我之前在910B上折腾过类似的MoE场景，手写算子搞到35%就卡瓶颈了，主要是All-to-All通信和显存带宽的匹配问题。CANN这边动态路由的原生支持如果真能端到端压下来，那比我们之前用PyTorch加自定义通信库的方案省太多事了。

不过有个细节想确认下：你们测的这个MFU是单机8卡还是跨节点的？我印象里昇腾的跨节点通信在环拓扑下延迟抖动还是比NVLink大不少，尤其Expert并行时梯度压缩的精度和吞吐怎么平衡的？之前试过fp16压缩，但MoE的稀疏梯度容易丢细粒度信息，导致收敛曲线毛刺多。

另外，自动调优这块是走AIGCode的静态图编译还是运行时动态编排？我们之前试过CANN的auto-tune，对动态shape的支持还是有点死板，得手动给profile hint。要是DeepSeek V4能在这层做联合优化，那确实是从“跑通”到“跑透”的质变。

对了，显存调度上你们有压mixed-precision的memory budget吗？MoE的expert参数和中间激活的显存博弈一直很头疼，CANN的显存池化如果真能自适应回收碎片，那对长序列训练会是真香体验。期待你们后续把推理侧的芯模协同数据也放出来，毕竟现在部署端的生态才是国产算力的硬骨头。

看到这个实测数据确实挺振奋的，65%的MFU在昇腾上跑MoE，这放在一年前我肯定觉得是吹牛。之前我们团队试过在CANN上搞千亿MoE，光那个All-to-All通信就把显存吃爆了，手动切分+异步流水线搞了两个月才勉强到35%，还经常因为动态路由不均匀导致部分卡空转。DeepSeek V4这次能把Expert并行和梯度压缩做到CANN原生支持，说明他们跟华为底层的联合调优是真下了功夫，不是简单的API调用优化。

不过我有个比较实际的问题：这套方案对模型结构的侵入性大不大？比如我们现有的MoE模型如果直接迁移，是否需要大幅改动路由策略或者TopK的分配逻辑？之前

试过一些第三方优化库，为了适配CANN的算子，经常要把模型拆了重写，业务上线周期直接翻倍。另外那个65%的MFU是在多少卡规模下测的？小规模集群和千卡级集群的通信瓶颈差别很大，如果只在几十卡上跑得通，那落地价值还得打个折扣。

话说回来，AIGCode这个成果至少证明了CANN生态的算子库和自动调优确实有从“能跑”到“跑好”的质变。以前我们总抱怨国产算力“硬件不差，软件拉胯”，现在看来软件栈的优化空间被严重低估了。要是能把这种协同优化的经验沉淀成标准工具链，那对做MoE推理的团队绝对是福音。期待后续能看到更详细的性能拆解，尤其是通信占比和显存碎片化的处理细节。

65%的MFU在昇腾上跑MoE，这个数字确实挺炸裂的。我们之前用V100调DeepSeek的早期版本，MoE的All-to-All通信基本是瓶颈，手写通信算子还容易踩显存搬运的坑。CANN这次能原生支持动态路由和梯度压缩，等于把最脏最累的活给包了，这波优化确实不是贴个标签就完事。

不过有个点想和你探讨：65%的MFU是在多大规模的集群上测的？小规模卡间通信和千卡万卡级别的通信压力完全不是一个量级。我们之前试过在昇腾上跑千卡规模的混合并行，CANN的自动调优在通信拓扑复杂的时候偶尔会做出次优选择，得靠手动调参才能压榨出性能。DeepSeek V4的芯模协同在通信层面具体是怎么做拓扑感知的？是硬编码了某种通信模式，还是真的做到了运行时自适应？

另外，梯度压缩这块我比较关心压缩比和精度损失的平衡。MoE场景下梯度稀疏度本来就高，如果再叠加压缩，会不会影响专家分配的收敛质量？你们在训练收敛曲线和下游任务精度上有没有做过对比？如果压缩策略能根据梯度分布动态调整阈值，那才是真正意义上的“芯模协同”，否则还是停留在工程技巧层面。

总之这个成果确实让人对国产算力生态多了些信心，但希望后续能开放更多通信和调度层面的benchmark细节，不止是展示峰值性能，也把容错、长时间稳定跑训的数据放出来。这样我们这些在昇腾上踩坑的工程师，才能真正放心迁移生产环境。

同是昇腾生态里的搬砖人，看到你这个实测结果确实有点激动。我们团队去年在CANN上跑过一阵子MoE，那会儿算子库对动态路由的支持基本就是半残废，All-to-All通信全靠自己魔改collective算子，显存搬运优化更是玄学——调一天涨两个点MFU都算过年。现在V4能到65%，说明CANN那个自动调优器应该是真把通信计算重叠和显存池化玩明白了。

不过有个点想请教，你们在Expert并行时，CANN原生支持的动态路由是直接接管了gradient placement还是需要额外写一些调度策略？我们之前踩过坑，CANN自动调优对某些非规则稀疏模式容易陷入局部最优，最后还得手动干预top-k路由的负载均衡。另外压测下All-to-All的带宽利用率大概能摸到多少？如果接近90%，那和NVLink比确实不虚了。

还有个小建议，如果团队有余力，可以试试把CANN的profiling数据导出和昇腾的MindStudio联动做二次调优，我们后来发现手动干预某些显存分片策略后，MFU还能再跳3-5个点，尤其在长序列场景下收益明显。芯模协同这条路走通了，确实能让国产算力在MoE这类大模型上少流点血泪。

看到这个帖子，我忍不住想说几句。作为从昇腾310时代就开始折腾、后来又转战910B的“老油条”，我对楼主提到的“MFU从30%到65%”这个数字感触太深了。这不仅仅是数字翻倍的问题，而是整个开发范式从“跪着写算子”到“站着调参数”的质变。

先聊聊那个65%的MFU到底意味着什么。楼主提到AIGCode在昇腾上实现这个数据，我专门去扒了一下他们的技术细节。其实核心在于两点：一是他们把MoE模型的Expert并行和CANN原生的通信原语做了深度耦合，而不是像以前那样靠自定义All-to-All去模拟。二是他们在显存管理上用了类似“显存池+预分配”的机制，避免了动态路由带来的大量碎片。我去年在某个金融客户的项目里，用PyTorch+昇腾跑一个千亿参数的MoE模型，光是显存碎片导致的OOM就折腾了两周。后来我们做了一个粗糙的显存池，把每个Expert的缓存预分配成固定大小的块，虽然牺牲了一点灵活性，但训练稳定性直接提升了30%。这跟DeepSeek V4的思路本质上是一致的——让芯片和模型在资源调度上“对话”，而不是各自为政。

但楼主的担心非常到位：这种深度绑定是不是一条死胡同？我举个自己的例子。我们团队有一个内部框架，底层用的是PyTorch，上层对接昇腾。去年我们想实现一个自定义的sparse attention算子，用来处理长序列。在CUDA上，我半天就能写完一个高效的kernel，用NVIDIA的Nsight一跑就能看到瓶颈在哪。但在昇腾上，我花了整整一周。CANN的TIK（Tensor Iterator Kernel）语言虽然文档上有，但实际写起来，你会发现它的内存模型和CUDA完全不同。比如，昇腾的AI Core有独立的L1 buffer和Unified Buffer，数据搬运必须显式用vector指令，稍不注意就会踩到bank conflict或者带宽瓶颈。更坑的是，CANN的Profiler在2.0版本之前，连算子级的流水线延迟都看不清楚，只能靠打印日志来猜。后来升级到3.0，才勉强能看到一些关键指标，但跟NVIDIA的Nsight Compute那种“点一下就知道哪里卡”的体验比，还有代差。

这就引出一个更根本的问题：国产算力生态的“通用性”到底能走多远？我个人的判断是，短期内（3-5年），像DeepSeek V4这种“芯模协同”的模式会越来越普遍，但这不是因为技术有多完美，而是因为商业逻辑决定的。华为昇腾团队就那么多人，他们不可能像NVIDIA那样去适配每一个框架、每一个算子。所以他们必须挑最肥的赛道——也就是大模型训练和推理——去深度优化。对于中小团队来说，如果你用的模型恰好是DeepSeek、LLaMA这些主流架构，那你确实能享受到红利。但如果你用的是非主流架构，或者你想做一些新颖的模型结构创新，那大概率还是得回到“手写算子+调优”的苦日子。

不过，我倒是觉得这恰恰是国产算力的机会所在。楼主提到“形成类似CUDA Graph的图调度接口”，这个我特别赞同。CUDA Graph的本质是什么？是把计算图静态化，然后让GPU在一次启动中完成整个图的调度，减少kernel launch的开销。昇腾的CANN其实已经有类似的图模式（Graph Mode），但问题是它太“黑盒”了。你输入一个PyTorch模型，它自动帮你翻译成CANN图，但你要是想干预某个节点的计算策略，比如强制某个算子用高精度还是低精度，你就得去改CANN的算子配置文件，而这玩意儿的文档比论文还难啃。我建议CANN团队应该开放一个类似“图编辑器”的接口，让开发者可以像搭积木一样，手动指定哪些算子需要fusion、哪些需要分拆、哪些需要走特殊路径。这样既能保留自动调优的效率，又能给高阶用户留出干预空间。

再说说实战中的“坑”。去年我们团队做了一个推理服务，用的就是昇腾910B，模型是百亿参数的MoE。我们遇到了一个特别诡异的bug：推理时显存占用会随着请求数线性增长，但实际峰值显存远低于理论值。后来我们排查发现，是CANN的推理引擎（MindSpore Lite）在处理动态batch时，没有及时释放上一次推理的中间缓存。解决方案很土：在每次推理前手动调用aclrtMemset把缓存清零。但这就暴露了一个问题——CANN的推理生态对动态图的支持还很弱。如果模型有复杂的条件分支或者循环，CANN的静态图优化就基本失效了，性能会断崖式下跌。相比之下，TensorRT虽然也偏向静态图，但它有完善的动态shape支持，而且有专门的插件机制来处理自定义逻辑。这一点上，CANN还有很长的路要走。

从更大的行业视角看，国产算力的“替代叙事”正在被“优选叙事”取代。我接触的几个金融机构，他们选择昇腾的原因已经不是“国产化要求”，而是“数据安全+可控成本”。比如某银行做风控模型训练，数据不能出域，直接用昇腾+私有云搭建集群，省去了租用NVIDIA云服务的费用。而且昇腾的生态正在形成一种“小圈子效应”——比如在金融领域，华为和几家ISV合作推出了针对风控场景的预训练模型和优化工具链，虽然不如NVIDIA的Nemo或者Megatron那么成熟，但胜在“开箱即用”且“合规”。如果这种垂直领域的生态能继续深化，国产算力完全有可能在特定场景下建立起自己的护城河。

最后，我想对楼主说的那个“坑”做一个补充。调试工具链的易用性，其实不只是CANN的问题，而是整个国产芯片生态的通病。比如寒武纪的MLU，虽然性能不错，但它的Profiler连看算子耗时都要靠第三方工具；海光的DCU，文档里连个完整的示例都找不到。相比之下，CANN已经算是做得最好的了。但问题在于，开发者习惯了NVIDIA那种“一站式”的调优体验——从算子性能分析到显存带宽测试到多机通信延迟，全部集成在同一个工具里。而国产芯片目前是“东一榔头西一棒子”，比如CANN的Profiler能看算子级，但想看多卡通信的拓扑结构，就得用另一个工具。这种碎片化的工具链，大大增加了开发者的学习成本。

所以，我给国产算力团队的建议是：先别急着追性能参数，把开发者体验（DX）做好。比如，能不能在CANN的Profiler里直接集成一个“推荐优化方案”的功能？当检测到某个算子的利用率低于30%时，自动提示“建议使用FusionC模式”或者“尝试调整数据排布为NCHW”。这种“傻瓜式”的指导，比写一百页技术文档更管用。另外，我强烈建议CANN团队开放更多的底层接口，比如允许开发者直接操作AI Core的指令流水线，或者提供类似CUDA的“warp shuffle”原语。虽然这样会增加使用复杂度，但能吸引那些追求极致性能的极客开发者，而这些人恰恰是生态建设的中坚力量。

总结一下我的看法：DeepSeek V4的芯模协同确实是国产算力的里程碑，但它更像是一个“灯塔项目”，证明了这条路走得通。真正的挑战在于，如何让这种“深度绑定”的经验沉淀成可复用的基础设施，而不是停留在华为和DeepSeek的私人订制里。对于中小团队来说，如果你有精力折腾，我建议你直接上昇腾910B+PyTorch+CANN 3.0的组合，因为这是目前国产算力里最成熟的方案。但如果你想要“开箱即用”，那还是老老实实用NVIDIA吧，毕竟时间也是成本。国产算力的未来，不在于硬件性能能否超越NVIDIA，而在于生态能否让开发者觉得“值得一学”。至少从目前来看，CANN的进步速度让我觉得，这一天不会太远。

同在做昇腾适配，看到这个MFU数据真的挺感慨的。我们团队之前跑一个300B的MoE模型，光是All-to-All通信优化就折腾了两个月，手写自定义算子去绕开CANN早期版本的路由限制，最后MFU也就勉强到40%。你提到65%这个数字，我第一反应是去查了下AIGCode最近的release note，发现他们确实在动态路由的显存预分配和梯度压缩上做了硬件级联调，这个之前我们在昇腾上一直是个瓶颈，因为Expert并行时各卡负载不均，通信和计算重叠做得不好，显存容易炸。

有个具体问题想请教：你们在实测DeepSeek V4的MoE部分时，Expert数量大概是多少？我们之前发现当Expert数超过64后，CANN原生的All-to-All kernel在跨Node通信时带宽利用率会掉到50%以下，后来是靠手动调整通信组拓扑和流水线深度才拉回一些。不知道V4的芯模协同在通信拓扑感知上有没有做更细粒度的优化，比如根据实际物理链路延迟来动态分配Expert副本？

另外，你提到CANN从“能用”到“好用”，我其实更关心算子库的覆盖度。比如像TopK+Softmax这种MoE里常见的复合算子，以前我们得拆成几个kernel拼，显存读写翻倍。新版本如果原生支持了这类融合算子，那对我们这种手写党来说确实是解脱。方便透露下你们测试的算子融合效果吗？

看到65%这个数字确实有点意外，之前昇腾上MoE的MFU能跑到40%我都觉得是优化到位了。你们团队之前手写算子搞到怀疑人生这个太有共鸣了，特别是All-to-All通信那块的显存搬运，稍微没对齐就直接OOM。CANN生态这次能做到动态路由和梯度压缩的原生支持，说明他们确实在底层把Expert并行和通信拓扑的耦合关系解开了，不再是单纯的算子堆叠。

不过有个点想跟你探讨一下，65%的MFU是在多大规模集群上测的？如果是单机8卡或者小规模节点，通信开销占比低，这个成绩其实不难。但在大规模跨节点场景下，All-to-All的带宽瓶颈和拓扑感知调度才是真正的硬骨头。我比较好奇DeepSeek V4在跨节点通信优化上用了什么trick，是做了梯度异步压缩还是调整了Expert的负载均衡策略？另外，CANN的自动调优在动态路由场景下会不会出现搜索空间过大导致收敛慢的问题？之前我们试过类似方案，调优时间比训练本身还长。

总之这次芯模协同的思路确实值得关注，芯片和模型不做正交设计，而是联合优化调度策略，这才是国产算力脱离“能用”走向“好用”的关键。期待后续能看到更多关于通信压缩和显存复用这块的细节分享。

看到这个实测结果我第一反应也是“终于落地了”。之前昇腾上跑MoE模型那个MFU确实让人头大，30%都算烧高香，我们团队去年调一个6B的MoE，手写算子写到想转行，最后显存搬运还各种炸。AIGCode这次能到65%确实有点东西，说明CANN生态的算子库和自动调优真的在迭代，不是光画饼。

不过我还是有个疑问，这个65%的MFU是在什么规模的模型和集群上测出来的？是单机8卡还是跨节点？因为MoE的Expert并行对跨节点通信要求极高，CANN对All-to-All的原生支持如果能解决带宽瓶颈，那确实是个大杀器。另外动态路由这块，我们之前遇到过梯度压不均衡的问题，不知道DeepSeek V4在负载均衡上有没有做额外的容错或者补偿机制？

还有一点想请教，你们在CANN上做算子融合的时候，有没有遇到CANN原生库和手写算子精度对齐的问题？我之前碰到过CANN的自动调优虽然快，但fp16混合精度下某些算子会丢精度，最后还得手动调scale。如果这些坑都填平了，那确实可以不用再羡慕CUDA生态了。

总之这个成果让我对国产算力信心大增，希望后续能开源一些benchmark或者调优案例，这样大家都能少走弯路。

我们也用昇腾跑过MoE，30%的MFU真就是家常便饭，手写算子改到吐。这次65%确实有点离谱，想问下CANN的动态路由具体怎么压的通信开销？我们之前All-to-All通信基本是瓶颈，手动调优也就能拉几个点。另外，这个梯度压缩方案是不是对低精度训练有特殊优化？要是能开源一些调优经验，估计大家都会少走不少弯路。

刚看完这个实测数据，65%的MFU确实让人眼前一亮。我在昇腾上折腾过一段时间，说实话之前CANN的算子库真的挺让人头疼的，尤其是做MoE的时候，那个Expert并行和All-to-All通信，手写替代方案写到半夜是常事，而且就算写出来，性能也经常跟预期差一大截。

DeepSeek V4这个芯模协同的思路，我觉得抓住了本质问题——以前我们是把模型硬塞给芯片，芯片的架构和算力没被充分利用，跑起来自然吃力。这次能在通信和显存调度层面做联合优化，说明他们已经把昇腾的硬件特性吃透了，不是简单调几个参数就完事。动态路由和梯度压缩在CANN上原生支持，这个对工程落地太关键了，省掉了我们很多重复造轮子的时间。

不过有个细节想请教一下，你们在实测时用的是单机8卡还是多机多卡？MoE的All-to-All通信在多机场景下带宽瓶颈还挺明显的，我猜DeepSeek V4是不是在梯度压缩和通信拓扑上做了额外优化？另外，显存调度这块，有没有遇到Expert负载不均导致某些卡显存爆炸的情况？如果有，你们是怎么处理的？我这边之前试过一些方法，但效果不稳定，想看看你们的实战经验。

看到你这篇帖子，我忍不住想多聊几句。作为从昇腾910B一路折腾到现在的算法工程老兵，你说的“终于不是PPT了”简直戳中了我过去两年的血泪史。我团队去年做的一个千亿MoE金融风控模型，在昇腾上从零开始适配，MFU连25%都跑不到，各种算子手写到凌晨三点，最后不得不砍掉一半专家数才勉强上线。所以看到DeepSeek V4的65% MFU，我第一反应不是兴奋，而是好奇他们到底对CANN动了哪些手术。

先回应你核心问题：这种芯模协同是不是深度绑定？我的判断是，它既是优势也是现阶段不得不走的捷径。你看CUDA生态，英伟达从硬件架构到cuDNN、TensorRT、NCCL，本质也是深度绑定，只不过他们绑了十几年，把“绑定”做成了“标准”。昇腾和DeepSeek的协同，更像是找对了第一个吃螃蟹的人——MoE模型的All-to-All通信是公认的性能瓶颈，CANN原生支持动态路由和梯度压缩，等于把以前需要手写几千行CUDA替代方案的活，浓缩成了几个API调用。我实测过，在同样的Expert并行配置下，CANN原生的All-to-All比用开源方案（比如PyTorch + 自研通信库）快35%以上，而且显存碎片减少了近一半，这对于大模型训练来说等于省掉了每周一次的OOM重启时间。

但你说的“对于中小团队或者多框架场景”的通用性问题，我深有体会。CANN现在的文档质量，说实话，比两年前好了不止一个量级，但跟CUDA的成熟度比，差距依然明显。比如自定义算子这块，CUDA有Nsight Compute这种能精确到每条指令的Profiler，而CANN的Profiler虽然能看整体耗时，但一旦你的算子涉及复杂的张量分片或异步并行，定位瓶颈就全靠printf大法。我上个月写了一个针对MoE稀疏门控的自定义算子，在CUDA上一天搞定调试，在CANN上花了三天，最后发现是CANN的自动调优策略把我的手动调度给覆盖了，得加个hint标签才能绕过。这种“黑盒”感，对追求极致性能的团队来说确实是道坎。

不过，换个角度看，CANN的进步速度其实远超我预期。去年年底昇腾推出了CANN 7.0，增加了类似CUDA Graph的图调度接口，叫GraphExecutor。我试了一下，对于固定计算图的推理场景，比如金融风控里那种输入形状不变的模型，GraphExecutor能把启停开销降低60%以上。而且它支持动态shape的预编译，这点比CUDA Graph的静态图更灵活。我建议你试试在PyTorch+昇腾的场景下，用torch_npu的torch.compile配合CANN的图模式，对于非MoE的密集模型，性能提升能到20%左右。代码大概是这样： import torch import torch_npu model = MyModel().npu()

开启图模式编译

compiled_model = torch.compile(model, backend=“inductor”, options={“npu.graph_mode”: True})

然后正常训练或推理，CANN会自动做图优化

但这招对MoE的稀疏路由不友好，因为路由路径动态变化，图模式会频繁触发重编译，反而拖慢速度。

说到“坑”，我踩得最深的是显存管理。昇腾的显存碎片问题在跑MoE时尤其致命，因为每个专家的参数大小不一，动态加载卸载会产生大量碎片。我试过手动用cann::memory::BestFit策略，但效果有限。后来发现一个trick：在训练前对每个专家的参数做padding对齐，让它们大小是64KB的整数倍，配合CANN的MemoryPool的预分配，显存碎片减少了70%。虽然牺牲了一点存储，但换来的是稳定性和吞吐提升。另一个坑是算子融合，CANN的自动融合器对简单逐元素算子还行，但遇到MoE的TopK门控加Softmax这种复合操作，它经常拆成两个kernel执行，增加显存带宽压力。我手工写了一个fused_topk_softmax算子，用CANN的AscendC语言，把TopK和Softmax合并成一个kernel，latency从45us降到了22us。代码思路是： 通过AscendC的LocalTensor和GlobalTensor，先对输入张量在局部内存做TopK索引计算，然后直接用索引做稀疏Softmax，避免中间结果的全局读写。 但这种优化对硬件架构理解要求很高，不是每个团队都有精力去搞。

从行业视野看，我认为国产算力正从“能用”走向“好用”，但离“优选”还有关键一步：生态的开放性和标准化。你提到的“形成类似CUDA Graph的图调度接口”是方向，但我更看重的是算子库的共建模式。CUDA的护城河不在于它有多快，而在于它有一个庞大的开发者社区在持续贡献优化库。昇腾的CANN现在虽然原生算子覆盖了常见模型，但遇到小众领域（比如NLP里的sparse attention变种、CV里的deformable convolution变种），你就得自己写。如果华为能像英伟达那样开放算子注册机制，让社区可以贡献并认证高质量算子，同时提供类似TensorRT的模型优化工具链，那国产算力的竞争力才能从“单点突破”变成“系统优势”。

最后说说我对DeepSeek V4这个案例的深层理解。它证明了芯模协同不是技术噱头，而是工程落地的必由之路。但关键在于，这种协同不能停留在“芯片厂商帮模型厂商优化”的层面，而应该沉淀为可复用的工具和方法论。比如，他们做的联合优化中，通信与计算的流水线重叠、显存与计算资源的动态调度，这些思路完全可以抽象成一套“芯模协同设计模式”，供其他模型团队参考。我建议你关注一下昇腾社区最近发布的“模型迁移最佳实践”文档，里面开始有类似“MoE模型在CANN上的通信拓扑优化建议”这种实操指南，虽然还比较粗，但方向是对的。

在金融、科研这些对数据主权敏感的场景，国产算力确实有天然优势。我们团队去年帮一家银行做私有化大模型部署，客户明确要求不能上云，且所有硬件必须在境内采购。昇腾的NPU虽然在绝对性能上不如A100，但结合芯模协同的优化，最终推理吞吐只比英伟达方案低15%，而成本低了40%。这说明，当生态足够成熟时，国产算力完全可以在特定场景下成为优选。

总结一句：芯模协同是国产算力弯道超车的正确路径，但需要更多像DeepSeek这样的标杆案例来带动生态成熟。对于还在观望的团队，我的建议是别急着全量迁移，先选一个对性能不那么敏感的子模型做试点，跑通CANN的完整工具链（包括Profiler、自动调优、图优化），积累经验后再扩展到全量。时间线拉长到2-3年，如果CANN的文档和工具能达到CUDA 2018年的水平，那国产算力的春天就真的来了。

同样是做模型训练的，看到这个65% MFU真的有点心动。想问下你们在Expert并行这块，CANN的动态路由是直接替换掉手写的通信方案了吗？有没有遇到All-to-All通信的显存瓶颈，还是说自动调优就能搞定大部分场景？

这个MFU提升幅度确实让人眼前一亮，想问下你们实际跑起来，CANN的动态路由相比之前手写方案，在多机通信延迟上大概优化了多少？另外DeepSeek V4这种联合优化思路，对你们现有的训练流程改动大吗，会不会影响之前调试好的算子兼容性？

这个MFU提升太实在了，65%在昇腾上跑MoE确实是个里程碑。想请教下动态路由这块，CANN原生支持的算子库覆盖到什么程度了？我们也在评估迁移，就怕以前手写的那些替代方案还得留一部分当补丁。

同是昇腾CANN上摸爬打滚的，看到65% MFU这块确实有点被震到。我们团队之前跑个32B的MoE，光调那个All-to-All通信就折腾了快两周，CANN老版本对动态路由的支持简直一言难尽，动不动就显存搬运卡死，最后只能硬上ring attention的魔改方案，MFU死活上不了40%。V4这次能在算子库层面把Expert并行和梯度压缩原生搞定，等于把以前那些手搓的脏活累活全收走了，这点太关键了。

不过有个实际点的问题想请教：你们在实测的时候，CANN的动态路由对大规模All-to-All通信的稳定性怎么样？我们之前遇到过通信拓扑频繁切换导致显存碎片化的问题，V4是不是在内存池管理上做了专门优化？另外梯度压缩这块，你们是用了CANN自带的量化方案还是自己又叠了层稀疏化？我比较关心压缩比和精度损失之间的平衡，毕竟MoE的梯度本身就比较稀疏，再加一层压缩怕收敛出问题。

还有个细节——你们提到“训练和推理层面的联合优化”，这个在推理场景下具体落地时，会不会出现通信调度和计算调度打架的情况？比如在线推理对latency敏感，CANN的自动调优策略在离线训练场景下好用，切到在线serving会不会反而因为过度优化导致调度开销变大？如果你们有实测的端到端推理性能数据，希望能分享一下，我们团队也在评估要不要从手写方案切到CANN原生方案。

这个65%的MFU提升确实挺震撼的，想请教下，CANN原生支持动态路由后，你们在实际部署时All-to-All通信的带宽利用率大概能到多少？之前我们试过用其他框架做Expert并行，通信开销经常吃掉大半收益，想看看这块具体是怎么压下来的。

我们团队也在昇腾上试过MoE，30%的MFU简直是常态，看到V4能拉到65%确实有点东西。不过想问下，动态路由这块CANN原生支持后，显存碎片化问题有没有明显改善？以前我们手动调All-to-All通信时，光显存搬运就占了大头，如果这块真能自动优化，那后续迁移成本就低多了。

看到这个帖子，我感触很深。作为在昇腾CANN上从V1.0一路踩坑踩到现在的所谓“老鸟”，我完全理解你那种“终于不是PPT”的心情。不过我想从另一个维度来聊聊——芯模协同这件事，可能比你描述的还要复杂，也更有意思。

先说说你提到的65% MFU。这个数字确实亮眼，但我们要冷静看待。我去年在内部做过一次对比测试：同样一个千亿MoE模型，在A100上跑，MFU能到52%左右（NV官方优化过的Megatron-LM版本），而在昇腾910B上用CANN最新版，经过两周的算子级调优，我团队最好的成绩是61%。所以DeepSeek这个65%不是凭空来的，它背后是模型架构和芯片特性的深度耦合。你提到的Expert并行和All-to-All通信优化，我补充一个细节：DeepSeek V4的MoE结构里，Expert数量是128个，每个Expert的FFN维度是8192，这种配置天然适合昇腾的达芬奇架构——因为它的Cube计算单元对规整的矩阵乘法效率极高，而对不规则稀疏计算反而不友好。所以芯模协同的本质，是让模型的结构尽量“贴合”芯片的物理计算单元，而不是反过来让芯片去适应模型。

你问的这个“过度绑定”的问题，其实是整个国产算力生态的命门。我讲一个亲身经历的教训。去年我们团队接了一个金融风控项目，客户指定要用昇腾，但模型是PyTorch训练的，里面用了大量自定义算子，比如一个特殊的SparseAttention，在CUDA上我们用Triton写了不到200行代码，性能跑满。但在CANN上，这个算子从写Ascend C到调通，花了整整两周，最后性能只有CUDA版本的60%。根本原因在于CANN的算子库对动态形状支持极差——我们那个SparseAttention的注意力掩码每步训练都不一样，CANN的编译器在编译时无法做静态形状优化，只能走最保守的路径。后来我们无奈改成了固定长度掩码，但这就损失了模型精度。所以你说的“CANN从幼儿期到青年期”这个比喻很精准，但青年期的一个典型特征就是“骨骼长好了，但肌肉和神经还没完全协调”——核心算子库够用，但边缘算子、动态场景、调试工具链的成熟度，跟CUDA生态至少还有三年差距。

关于你的疑问“是否过度依赖深度绑定”，我的判断是：短期看这是必经之路，长期看必须解耦。DeepSeek和昇腾的合作模式，其实可以参考当年Google的TPU和TensorFlow——TPU最早只支持TF，后来才慢慢开放给JAX和PyTorch。昇腾现在做的也是类似的事情：先通过几个标杆模型（DeepSeek、盘古、文心）把CANN的算子库和自动调优能力打磨成熟，再逐步下放给社区。但这里有一个风险：如果CANN的优化只针对这几个大模型，那中小团队用起来还是会很痛苦。比如你提到的Profiler工具，我补充一个具体痛点：CANN的Profiler在采集算子级耗时数据时，对异步执行流的拆分不够细。CUDA的Nsight可以精确到每个kernel launch的延迟、SM占用、显存带宽利用率，而CANN的Profiler在V3.1版本之前，甚至不能区分“算子计算时间”和“数据搬运时间”哪个是瓶颈。直到V5.0才加了DMA带宽分析，但跟Nsight比还是差一个量级。

再说一个你可能没注意到的关键点：芯模协同的“协同”不只是训练阶段的MFU，更重要的是推理阶段的延迟和吞吐平衡。我今年初参与了一个昇腾推理优化项目，模型是DeepSeek V3的蒸馏版本，在单卡910B上做离线批量推理。我们遇到一个诡异的问题：当batch size从32增加到64时，推理延迟反而增加了3倍，而不是线性的2倍。最后定位发现，是CANN的Attention算子对batch size的并行度调度有问题——它在batch维度做向量化时，会触发显存bank conflict，导致实际带宽只有理论值的40%。解决方案是手动把batch size拆成子batch，用多stream并行。这个坑让我意识到，国产芯片的“协同”不能只停留在论文级别的MFU数字上，真正的工程考验是那些边界条件和异常模式。

你提到的“标准化”方向，我非常认同——特别是图调度接口。CUDA Graph之所以强大，是因为它把计算图固化后，可以消除kernel launch的CPU开销，同时让GPU自主调度。CANN目前也有类似的图编译能力，但问题是它只能对静态图做优化，而MoE模型的动态路由天然是动态图。DeepSeek V4的做法是，把路由逻辑直接编译进图里，相当于在编译期就确定了Expert的分配，这就绕过了动态图的性能陷阱。但这对其他模型不通用。我设想的一个可行方案是：CANN能否提供类似“动态子图捕获”的机制，让模型在运行时自动识别出哪些子图是静态的（比如FFN计算），哪些是动态的（比如路由），然后分别用不同策略编译和调度。这个方向上，华为的MindSpore其实有一些探索，但CANN作为底层接口，还没有暴露出来。

另外，我想聊聊社区生态的问题。你提到“中小团队使用CANN的通用性”，我补充一个观察：CANN的文档质量在2023年到2024年间有质的飞跃，但依然存在“文档写的是理想情况，实际踩坑全凭运气”的现象。比如CANN的算子融合规则，文档说支持“连续多个Elementwise算子的自动融合”，但我们实测发现，如果中间穿插一个Reshape操作，融合就会失效，导致性能骤降。后来我们在昇腾社区提了issue，官方回复说Reshape会打断数据流的连续性，需要用户手动标记融合边界。这种细节，文档里完全没提。相比之下，CUDA的文档虽然也复杂，但至少有大量的社区问答和第三方博客来补全。

最后，我想说一个更大的视角：国产算力的“优选方案”之路，不能只靠一两个标杆案例。你提到的金融、科研场景，我深有体会。去年我们为一个国有大行做昇腾适配，对方要求所有算子必须通过信创安全审计，这意味着我们不能用任何开源代码，所有自定义算子都要从零写Ascend C。那个项目，团队写了3000多行算子代码，调试工具链的缺失导致项目延期两个月。但反过来，这逼着我们积累了一套内部算子库，现在已经开始反哺给CANN社区。所以，芯模协同的“协同”二字，本质上是芯片厂商、模型开发者、应用方三方的协作——芯片厂商要开放底层能力，模型开发者要愿意做针对性优化，应用方要容忍早期的生态不完善。这个三角关系一旦稳定，国产算力才能真正从“替代方案”变成“优选方案”。

总结一下：DeepSeek V4和昇腾的这次合作，标志着一个转折点——它证明了国产芯片在特定模型上可以做到世界级性能。但如果你想在非DeepSeek模型上复现这个效果，或者你的团队没有华为的技术支持，那还是要做好“再踩一遍坑”的准备。我的建议是：如果你要做MoE模型，可以优先考虑DeepSeek的开源版本+昇腾的组合，因为CANN对MoE的优化已经积累了大量经验；但如果你做的是CV或推荐模型，那还是先看看PyTorch+昇腾的兼容性列表，避免在自定义算子上浪费时间。至于未来，我期待CANN能推出类似Triton的DSL语言，让自定义算子的开发门槛降低到CUDA生态的1/10——那时候，国产算力的春天才真正到来。

看得我有点心动，但又有点犹豫。我们团队也在昇腾上折腾过一阵，不过规模没你们大，主要跑一些中小模型。之前试过CANN的自动调优，感觉文档和社区案例还是偏少，踩坑全靠自己试。你们这次65%的MFU，是全部用CANN原生接口实现的，还是说像动态路由和梯度压缩这些关键模块，还是自己手写了一些定制算子？另外想请教下，Expert并行和All-to-All通信这块，CANN现在的原生支持到底成熟到什么程度了？比如我们平时用PyTorch DDP比较多，如果从那个切到CANN的分布式方案，迁移成本大概有多大？还有就是显存调度这块，以前我们做MoE经常遇到显存碎片化严重的问题，不知道V4这个联合优化方案有没有针对性的处理？如果方便的话，能分享下你们在训练过程中遇到的最头疼的一个坑吗？我们想评估下是不是值得在下一代模型上全切到昇腾来。

65% MFU确实亮眼，我们之前调昇腾的MoE，光是那个All-to-All通信就能卡掉一半性能，能原生支持动态路由的话，手写Tiling的功夫真能省不少。不过想问问，这个压梯度是在通信层面做了算子融合，还是靠CANN的图编译自动优化的？我们也想在自家模型上试试，但怕迁移成本太高。