1. 从等了八年说起昇腾软件栈到底卡在哪华为昇腾等了八年的软件栈终于原地起飞——这句话第一次看到的时候我盯着八年两个字看了很久。作为一个从2019年就开始折腾昇腾310和910系列开发板的人我太清楚这八年意味着什么了。硬件参数年年更新算力数字一路往上飙但真正让开发者头疼的从来不是芯片本身而是芯片之上那层看不见摸不着的软件栈。先把这个话题的背景说清楚。华为昇腾Ascend系列AI处理器从2018年前后正式对外亮相配套的软件栈叫CANNCompute Architecture for Neural Networks。CANN的定位类似于英伟达的CUDA是连接上层AI框架PyTorch、TensorFlow、MindSpore等和底层昇腾硬件的中间层。它负责算子编译、图优化、内存管理、任务调度这一整套脏活累活。理论上只要CANN做得好开发者就可以像用CUDA一样无感地使用昇腾算力。但现实是过去几年里很多团队在昇腾上跑模型的体验并不算顺畅。算子覆盖不全、自定义算子开发门槛高、框架适配版本对不上、性能调优文档零散——这些问题叠加在一起导致一个尴尬的局面硬件明明在那里算力明明够用但要把一个主流大模型完整、高效地跑起来往往需要投入大量人力去做适配和调优。这就是等了八年的由来不是硬件等了八年是软件栈的成熟度等了八年。而DeepSeek这次十一献礼的意义在于它作为一个现象级的开源大模型系列从模型架构到推理部署都对底层软件栈提出了很高的要求。当DeepSeek能够在昇腾平台上顺畅跑起来并且性能表现可圈可点的时候这背后反映的其实是CANN软件栈在算子库、图编译器、运行时调度等多个层面的实质性进步。换句话说DeepSeek成了检验昇腾软件栈成熟度的一块试金石而这次它通过了。这篇文章我想聊的不是简单的恭喜或者厉害了而是从一个实际做部署和调优的开发者角度把这件事拆开来看CANN到底解决了什么问题DeepSeek在昇腾上部署涉及哪些关键技术点算子优化和性能调优有哪些实操经验以及这套组合对后续的AI基础设施选型意味着什么。不管你是正在评估国产算力方案的架构师还是想在自己项目里试试昇腾的工程师希望这些内容能帮你少走一些弯路。2. CANN软件栈的底层逻辑它到底在做什么2.1 从CUDA的对照说起CANN的层级结构要理解CANN为什么这么重要最直接的办法是拿它和CUDA做对照。用过英伟达GPU的人都知道CUDA不是一个单一的东西它是一整套生态底层有驱动和运行时中间有cuDNN、cuBLAS这些加速库上层有NVCC编译器和各种框架插件。CANN的结构类似但有自己的命名体系。CANN最底层是驱动层负责和昇腾硬件的固件通信。往上是运行时Runtime管理设备内存、流Stream、事件这些基础资源。再往上是算子库包括NN算子、BLAS算子、FFT算子等这一层直接决定了模型能不能跑、跑得快不快。最上面是图编译器和框架适配层负责把PyTorch或TensorFlow的计算图转换成昇腾能执行的格式。这个层级结构听起来和CUDA差不多但实际使用中的差异很大。CUDA生态经过十几年的迭代算子覆盖极其全面几乎你想到的任何操作都有现成的高性能实现。而CANN早期最大的痛点就是算子覆盖不足很多在PyTorch里一行代码就能搞定的操作在昇腾上需要自己写自定义算子Custom Operator而写自定义算子又需要熟悉TBETensor Boost Engine编程模型学习曲线相当陡峭。2.2 算子开发的两条路TBE与Ascend C说到算子开发这是CANN软件栈里最核心也最劝退的部分。早期昇腾算子开发主要靠TBE它基于TVM框架做了定制用Python DSL来描述算子的计算逻辑然后编译成昇腾硬件能执行的二进制。TBE的好处是表达能力强坏处是调试困难一个算子编译报错可能给你甩出几百行中间代码定位问题非常痛苦。后来华为推出了Ascend C这是一种基于C/C的算子编程语言更接近硬件底层性能上限更高但开发效率相对低一些。Ascend C的编程模型需要开发者显式管理数据在各级存储之间的搬运包括Global Memory、L1 Buffer、L0 Buffer等对开发者的硬件理解要求比较高。提示如果你只是想把现有模型跑起来优先检查CANN版本自带的算子库是否已经覆盖了模型所需的所有算子。只有当确实遇到不支持的算子时才考虑自己开发。自己开发算子之前先去昇腾社区搜一下有没有人已经写过类似的能复用就复用。2.3 图编译器模型能不能跑起来的关键关卡图编译器是CANN里另一个容易被忽视但极其关键的组件。当你把一个PyTorch模型转到昇腾上运行时框架适配层会先把PyTorch的计算图转换成CANN的图表示GE Graph然后图编译器会对这个图做一系列优化算子融合、常量折叠、内存复用、并行调度等。这个过程里最常见的问题是图切分——当模型里有些算子昇腾不支持时图编译器会把这些算子切出来交给CPU执行其余部分留在昇腾上。这种混合执行虽然能让模型跑起来但性能损失往往很大因为数据在CPU和昇腾之间的搬运开销很高。所以判断一个模型在昇腾上的部署质量一个很重要的指标就是看有多少算子被切到了CPU上。DeepSeek这类大模型之所以对软件栈要求高就是因为它的模型结构里有大量Attention相关的复杂算子还有MoE混合专家结构带来的动态路由逻辑。这些如果都要切到CPU上执行推理速度会惨不忍睹。所以DeepSeek能在昇腾上跑出可用的性能说明CANN的算子库和图编译器在这些关键路径上已经有了实质性的覆盖和优化。3. DeepSeek在昇腾上的部署链路拆解3.1 模型格式转换从HuggingFace到昇腾可执行把一个DeepSeek模型部署到昇腾上第一步是模型格式转换。通常的流程是从HuggingFace下载原始权重通常是safetensors格式然后用昇腾提供的转换工具把权重和计算图转成CANN能识别的格式。这里有个细节值得注意DeepSeek的模型结构里用了不少自定义的操作比如MLAMulti-head Latent Attention和一些特殊的归一化层。这些操作在标准PyTorch里可能没有直接对应的算子需要框架适配层做映射。如果映射做得不好就会出现前面说的图切分问题。实际操作中我建议先用昇腾官方提供的模型适配脚本跑一遍看看转换过程中有没有报错或者警告。转换完成后用性能分析工具比如昇腾的Profiling工具看一下算子分布确认关键算子都落在了昇腾上而不是CPU上。3.2 推理引擎选型MindIE还是自研昇腾平台上跑大模型推理官方主推的引擎是MindIEMind Inference Engine。它封装了模型加载、KV Cache管理、连续批处理Continuous Batching、PagedAttention等大模型推理的常用优化。对于DeepSeek这种规模的模型直接用MindIE通常是最省事的路径。但MindIE也不是万能的。如果你的业务场景有特殊的调度需求或者你想对推理过程做深度定制可能就需要基于CANN的底层API自己搭推理框架。这条路的工作量很大但灵活性也更高。我见过一些团队为了极致性能自己实现了KV Cache的压缩和调度策略在特定场景下确实比通用引擎跑得快。注意选择推理引擎时不要只看峰值吞吐还要看首Token延迟和尾延迟。大模型推理场景下用户体验往往对首Token延迟更敏感而这恰恰是很多通用引擎优化不够的地方。3.3 KV Cache管理的实操细节DeepSeek这类模型参数量大、层数多KV Cache的内存占用非常可观。在昇腾上KV Cache的管理直接影响到能支持多大的批处理规模进而影响整体吞吐。昇腾的内存层级和GPU不太一样它有专门的片上缓存L1/L0 Buffer和片外内存HBM。KV Cache通常放在HBM里但访问HBM的延迟比访问片上缓存高不少。所以一些优化做得好的实现会把当前活跃的KV Cache块尽量往片上缓存搬减少HBM访问次数。另一个实操点是KV Cache的量化。把KV Cache从FP16量化到INT8内存占用直接减半能支持的批处理规模翻倍。但量化会带来精度损失需要根据具体业务场景评估是否可接受。我的经验是对于对话类应用KV Cache量化到INT8通常问题不大但对于需要精确长文本理解的任务最好还是保留FP16。4. 算子优化的实战经验从能跑到跑得好4.1 性能瓶颈定位先看Profiling再动手算子优化最忌讳的就是凭感觉猜瓶颈。昇腾提供了Profiling工具可以采集算子级别的执行时间、内存带宽利用率、计算单元利用率等指标。拿到这些数据之后你才能知道到底哪个算子是瓶颈瓶颈是计算密集还是访存密集。我的一般流程是先用Profiling跑一遍完整推理导出算子耗时排名。然后重点看排名前10的算子分析它们的理论性能上限和实际性能的差距。如果某个算子的实际耗时远高于理论值那就有优化空间。4.2 常见算子优化手段与适用场景针对昇腾平台的算子优化常用的手段有这么几类优化手段适用场景预期收益实施难度算子融合多个小算子连续执行减少访存开销提升20%-50%中等数据布局调整访存密集型算子提升带宽利用率10%-30%较低分块策略优化大矩阵运算提升缓存命中率15%-40%较高指令级优化计算密集型算子提升计算单元利用率10%-25%高混合精度精度容忍度高的场景吞吐翻倍精度略降较低算子融合是最常用也最有效的手段之一。比如Attention计算里QK^T、Softmax、加权求和这几个操作如果分开执行中间结果要反复读写HBM带宽压力很大。把它们融合成一个算子中间结果留在片上缓存里性能提升非常明显。4.3 自定义算子开发的避坑清单如果你确实需要开发自定义算子下面这些坑我基本都踩过存储对齐问题昇腾对数据地址的对齐要求比较严格不对齐会导致性能急剧下降甚至运行报错。开发算子时一定要确认输入输出的地址对齐符合要求。边界处理昇腾的向量计算单元一次处理固定长度的数据处理非对齐边界时需要特殊处理否则会读到越界数据。调试手段有限昇腾算子调试不像GPU那样有成熟的工具链很多时候只能靠打印中间结果来定位问题。建议在开发阶段多写单元测试每个小步骤都验证正确性。性能回归自定义算子开发完成后一定要和CANN自带的参考实现做性能对比。有时候自己写的算子虽然功能正确但性能还不如系统自带的。提示昇腾社区里有不少开源的算子实现可以参考开发之前先搜一搜能省很多时间。另外CANN版本更新比较快有些早期需要自定义的算子在新版本里可能已经内置了升级前先查一下Release Notes。5. 这套组合对AI基础设施选型的启示5.1 国产算力方案的真实成熟度评估DeepSeek在昇腾上跑通并且性能可用这件事的意义不只是又多了一个模型支持。它标志着国产AI算力方案在软件栈层面跨过了一个关键门槛从能跑demo到能跑生产。评估一个算力方案的成熟度我一般看几个维度算子覆盖率、框架适配完整度、性能调优工具链、社区活跃度、文档质量。昇腾在这几个维度上过去两年进步很明显。算子覆盖率从早期只支持主流CNN和基础Transformer到现在能覆盖MoE、MLA这些前沿结构框架适配从只支持MindSpore到现在PyTorch和TensorFlow都有比较完整的支持。但也要客观地说和CUDA生态相比CANN在开发者体验上还有差距。文档的完整性、错误信息的友好度、社区问答的响应速度这些软实力需要时间积累。不过对于很多业务场景来说只要核心链路的算子覆盖和性能达标这些差距是可以接受的。5.2 什么场景适合考虑昇腾方案基于我自己的项目经验以下几类场景比较适合考虑昇腾方案对供应链安全有要求的政企项目这是最直接的驱动力不多展开。推理负载为主、模型结构相对固定的业务昇腾在推理场景的能效比表现不错如果模型结构稳定一次适配好之后长期运行成本可控。有专门AI基础设施团队的公司昇腾方案需要一定的技术投入来做适配和调优如果团队里有熟悉底层优化的人能发挥出更大价值。反过来如果你的业务需要频繁尝试最新的模型结构或者团队里没有精力做底层适配那现阶段的昇腾方案可能会带来额外的工程负担。这不是说昇腾不好而是说任何技术选型都要匹配团队的实际能力。5.3 从DeepSeek适配看未来的软件栈竞争DeepSeek这次和昇腾的配合其实揭示了一个趋势未来AI算力的竞争硬件参数的重要性会相对下降软件栈的生态和易用性会越来越关键。因为当硬件算力普遍过剩的时候决定实际可用算力的是软件栈能把多少理论算力转化成实际性能。这对国产算力方案来说既是机会也是挑战。机会在于如果能在软件栈上做出差异化比如针对特定模型结构做深度优化就能在特定场景下实现超越通用方案的表现。挑战在于软件栈的积累需要时间和生态这不是靠单点突破能解决的。我个人的判断是未来两三年里CANN和CUDA的差距会继续缩小但不会完全消失。对于开发者来说多掌握一套技术栈不是坏事毕竟技术选型的自由度越大应对变化的能力就越强。6. 一些实操层面的补充建议如果你正准备在昇腾上部署DeepSeek或者类似的模型下面这些建议可能对你有用。第一版本匹配是重中之重。CANN版本、驱动版本、框架版本、模型转换工具版本这四者之间的兼容性一定要提前确认。我遇到过好几次因为版本不匹配导致的诡异问题排查半天最后发现是版本组合不对。建议直接参考官方文档里推荐的版本组合不要自己随意搭配。第二先跑通再优化。不要一上来就追求极致性能先用官方推荐的配置把模型跑起来确认功能正确然后再逐步做性能优化。优化过程中每次只改一个变量改完做性能对比这样才能准确判断每个优化的实际效果。第三重视Profiling数据。昇腾的Profiling工具能提供很详细的性能数据但很多人拿到数据之后不知道怎么分析。我的建议是重点关注三个指标算子耗时占比、内存带宽利用率、计算单元利用率。这三个指标能帮你快速定位瓶颈类型。第四保持对社区动态的关注。CANN的版本迭代速度比较快每个版本都会新增算子支持、优化性能、修复问题。定期看看Release Notes说不定你之前头疼的问题在新版本里已经解决了。最后说一点个人感受。我从最早在昇腾上跑一个简单CNN都要折腾半天到现在能比较顺畅地部署大模型这个变化是实实在在的。软件栈这东西进步往往不是线性的而是在某个节点之后突然变得可用。DeepSeek这次在昇腾上的表现让我觉得那个节点可能已经到了。当然具体到每个项目还是要根据自己的实际情况做评估和验证毕竟别人的经验替代不了自己的实测。 
长河君 · 2026/10/28 7:44:50 · 阅读 1.2k DeepSeek在昇腾上的部署实战：CANN软件栈算子优化与性能调优经验
1. 从等了八年说起昇腾软件栈到底卡在哪华为昇腾等了八年的软件栈终于原地起飞——这句话第一次看到的时候我盯着八年两个字看了很久。作为一个从2019年就开始折腾昇腾310和910系列开发板的人我太清楚这八年意味着什么了。硬件参数年年更新算力数字一路往上飙但真正让开发者头疼的从来不是芯片本身而是芯片之上那层看不见摸不着的软件栈。先把这个话题的背景说清楚。华为昇腾Ascend系列AI处理器从2018年前后正式对外亮相配套的软件栈叫CANNCompute Architecture for Neural Networks。CANN的定位类似于英伟达的CUDA是连接上层AI框架PyTorch、TensorFlow、MindSpore等和底层昇腾硬件的中间层。它负责算子编译、图优化、内存管理、任务调度这一整套脏活累活。理论上只要CANN做得好开发者就可以像用CUDA一样无感地使用昇腾算力。但现实是过去几年里很多团队在昇腾上跑模型的体验并不算顺畅。算子覆盖不全、自定义算子开发门槛高、框架适配版本对不上、性能调优文档零散——这些问题叠加在一起导致一个尴尬的局面硬件明明在那里算力明明够用但要把一个主流大模型完整、高效地跑起来往往需要投入大量人力去做适配和调优。这就是等了八年的由来不是硬件等了八年是软件栈的成熟度等了八年。而DeepSeek这次十一献礼的意义在于它作为一个现象级的开源大模型系列从模型架构到推理部署都对底层软件栈提出了很高的要求。当DeepSeek能够在昇腾平台上顺畅跑起来并且性能表现可圈可点的时候这背后反映的其实是CANN软件栈在算子库、图编译器、运行时调度等多个层面的实质性进步。换句话说DeepSeek成了检验昇腾软件栈成熟度的一块试金石而这次它通过了。这篇文章我想聊的不是简单的恭喜或者厉害了而是从一个实际做部署和调优的开发者角度把这件事拆开来看CANN到底解决了什么问题DeepSeek在昇腾上部署涉及哪些关键技术点算子优化和性能调优有哪些实操经验以及这套组合对后续的AI基础设施选型意味着什么。不管你是正在评估国产算力方案的架构师还是想在自己项目里试试昇腾的工程师希望这些内容能帮你少走一些弯路。2. CANN软件栈的底层逻辑它到底在做什么2.1 从CUDA的对照说起CANN的层级结构要理解CANN为什么这么重要最直接的办法是拿它和CUDA做对照。用过英伟达GPU的人都知道CUDA不是一个单一的东西它是一整套生态底层有驱动和运行时中间有cuDNN、cuBLAS这些加速库上层有NVCC编译器和各种框架插件。CANN的结构类似但有自己的命名体系。CANN最底层是驱动层负责和昇腾硬件的固件通信。往上是运行时Runtime管理设备内存、流Stream、事件这些基础资源。再往上是算子库包括NN算子、BLAS算子、FFT算子等这一层直接决定了模型能不能跑、跑得快不快。最上面是图编译器和框架适配层负责把PyTorch或TensorFlow的计算图转换成昇腾能执行的格式。这个层级结构听起来和CUDA差不多但实际使用中的差异很大。CUDA生态经过十几年的迭代算子覆盖极其全面几乎你想到的任何操作都有现成的高性能实现。而CANN早期最大的痛点就是算子覆盖不足很多在PyTorch里一行代码就能搞定的操作在昇腾上需要自己写自定义算子Custom Operator而写自定义算子又需要熟悉TBETensor Boost Engine编程模型学习曲线相当陡峭。2.2 算子开发的两条路TBE与Ascend C说到算子开发这是CANN软件栈里最核心也最劝退的部分。早期昇腾算子开发主要靠TBE它基于TVM框架做了定制用Python DSL来描述算子的计算逻辑然后编译成昇腾硬件能执行的二进制。TBE的好处是表达能力强坏处是调试困难一个算子编译报错可能给你甩出几百行中间代码定位问题非常痛苦。后来华为推出了Ascend C这是一种基于C/C的算子编程语言更接近硬件底层性能上限更高但开发效率相对低一些。Ascend C的编程模型需要开发者显式管理数据在各级存储之间的搬运包括Global Memory、L1 Buffer、L0 Buffer等对开发者的硬件理解要求比较高。提示如果你只是想把现有模型跑起来优先检查CANN版本自带的算子库是否已经覆盖了模型所需的所有算子。只有当确实遇到不支持的算子时才考虑自己开发。自己开发算子之前先去昇腾社区搜一下有没有人已经写过类似的能复用就复用。2.3 图编译器模型能不能跑起来的关键关卡图编译器是CANN里另一个容易被忽视但极其关键的组件。当你把一个PyTorch模型转到昇腾上运行时框架适配层会先把PyTorch的计算图转换成CANN的图表示GE Graph然后图编译器会对这个图做一系列优化算子融合、常量折叠、内存复用、并行调度等。这个过程里最常见的问题是图切分——当模型里有些算子昇腾不支持时图编译器会把这些算子切出来交给CPU执行其余部分留在昇腾上。这种混合执行虽然能让模型跑起来但性能损失往往很大因为数据在CPU和昇腾之间的搬运开销很高。所以判断一个模型在昇腾上的部署质量一个很重要的指标就是看有多少算子被切到了CPU上。DeepSeek这类大模型之所以对软件栈要求高就是因为它的模型结构里有大量Attention相关的复杂算子还有MoE混合专家结构带来的动态路由逻辑。这些如果都要切到CPU上执行推理速度会惨不忍睹。所以DeepSeek能在昇腾上跑出可用的性能说明CANN的算子库和图编译器在这些关键路径上已经有了实质性的覆盖和优化。3. DeepSeek在昇腾上的部署链路拆解3.1 模型格式转换从HuggingFace到昇腾可执行把一个DeepSeek模型部署到昇腾上第一步是模型格式转换。通常的流程是从HuggingFace下载原始权重通常是safetensors格式然后用昇腾提供的转换工具把权重和计算图转成CANN能识别的格式。这里有个细节值得注意DeepSeek的模型结构里用了不少自定义的操作比如MLAMulti-head Latent Attention和一些特殊的归一化层。这些操作在标准PyTorch里可能没有直接对应的算子需要框架适配层做映射。如果映射做得不好就会出现前面说的图切分问题。实际操作中我建议先用昇腾官方提供的模型适配脚本跑一遍看看转换过程中有没有报错或者警告。转换完成后用性能分析工具比如昇腾的Profiling工具看一下算子分布确认关键算子都落在了昇腾上而不是CPU上。3.2 推理引擎选型MindIE还是自研昇腾平台上跑大模型推理官方主推的引擎是MindIEMind Inference Engine。它封装了模型加载、KV Cache管理、连续批处理Continuous Batching、PagedAttention等大模型推理的常用优化。对于DeepSeek这种规模的模型直接用MindIE通常是最省事的路径。但MindIE也不是万能的。如果你的业务场景有特殊的调度需求或者你想对推理过程做深度定制可能就需要基于CANN的底层API自己搭推理框架。这条路的工作量很大但灵活性也更高。我见过一些团队为了极致性能自己实现了KV Cache的压缩和调度策略在特定场景下确实比通用引擎跑得快。注意选择推理引擎时不要只看峰值吞吐还要看首Token延迟和尾延迟。大模型推理场景下用户体验往往对首Token延迟更敏感而这恰恰是很多通用引擎优化不够的地方。3.3 KV Cache管理的实操细节DeepSeek这类模型参数量大、层数多KV Cache的内存占用非常可观。在昇腾上KV Cache的管理直接影响到能支持多大的批处理规模进而影响整体吞吐。昇腾的内存层级和GPU不太一样它有专门的片上缓存L1/L0 Buffer和片外内存HBM。KV Cache通常放在HBM里但访问HBM的延迟比访问片上缓存高不少。所以一些优化做得好的实现会把当前活跃的KV Cache块尽量往片上缓存搬减少HBM访问次数。另一个实操点是KV Cache的量化。把KV Cache从FP16量化到INT8内存占用直接减半能支持的批处理规模翻倍。但量化会带来精度损失需要根据具体业务场景评估是否可接受。我的经验是对于对话类应用KV Cache量化到INT8通常问题不大但对于需要精确长文本理解的任务最好还是保留FP16。4. 算子优化的实战经验从能跑到跑得好4.1 性能瓶颈定位先看Profiling再动手算子优化最忌讳的就是凭感觉猜瓶颈。昇腾提供了Profiling工具可以采集算子级别的执行时间、内存带宽利用率、计算单元利用率等指标。拿到这些数据之后你才能知道到底哪个算子是瓶颈瓶颈是计算密集还是访存密集。我的一般流程是先用Profiling跑一遍完整推理导出算子耗时排名。然后重点看排名前10的算子分析它们的理论性能上限和实际性能的差距。如果某个算子的实际耗时远高于理论值那就有优化空间。4.2 常见算子优化手段与适用场景针对昇腾平台的算子优化常用的手段有这么几类优化手段适用场景预期收益实施难度算子融合多个小算子连续执行减少访存开销提升20%-50%中等数据布局调整访存密集型算子提升带宽利用率10%-30%较低分块策略优化大矩阵运算提升缓存命中率15%-40%较高指令级优化计算密集型算子提升计算单元利用率10%-25%高混合精度精度容忍度高的场景吞吐翻倍精度略降较低算子融合是最常用也最有效的手段之一。比如Attention计算里QK^T、Softmax、加权求和这几个操作如果分开执行中间结果要反复读写HBM带宽压力很大。把它们融合成一个算子中间结果留在片上缓存里性能提升非常明显。4.3 自定义算子开发的避坑清单如果你确实需要开发自定义算子下面这些坑我基本都踩过存储对齐问题昇腾对数据地址的对齐要求比较严格不对齐会导致性能急剧下降甚至运行报错。开发算子时一定要确认输入输出的地址对齐符合要求。边界处理昇腾的向量计算单元一次处理固定长度的数据处理非对齐边界时需要特殊处理否则会读到越界数据。调试手段有限昇腾算子调试不像GPU那样有成熟的工具链很多时候只能靠打印中间结果来定位问题。建议在开发阶段多写单元测试每个小步骤都验证正确性。性能回归自定义算子开发完成后一定要和CANN自带的参考实现做性能对比。有时候自己写的算子虽然功能正确但性能还不如系统自带的。提示昇腾社区里有不少开源的算子实现可以参考开发之前先搜一搜能省很多时间。另外CANN版本更新比较快有些早期需要自定义的算子在新版本里可能已经内置了升级前先查一下Release Notes。5. 这套组合对AI基础设施选型的启示5.1 国产算力方案的真实成熟度评估DeepSeek在昇腾上跑通并且性能可用这件事的意义不只是又多了一个模型支持。它标志着国产AI算力方案在软件栈层面跨过了一个关键门槛从能跑demo到能跑生产。评估一个算力方案的成熟度我一般看几个维度算子覆盖率、框架适配完整度、性能调优工具链、社区活跃度、文档质量。昇腾在这几个维度上过去两年进步很明显。算子覆盖率从早期只支持主流CNN和基础Transformer到现在能覆盖MoE、MLA这些前沿结构框架适配从只支持MindSpore到现在PyTorch和TensorFlow都有比较完整的支持。但也要客观地说和CUDA生态相比CANN在开发者体验上还有差距。文档的完整性、错误信息的友好度、社区问答的响应速度这些软实力需要时间积累。不过对于很多业务场景来说只要核心链路的算子覆盖和性能达标这些差距是可以接受的。5.2 什么场景适合考虑昇腾方案基于我自己的项目经验以下几类场景比较适合考虑昇腾方案对供应链安全有要求的政企项目这是最直接的驱动力不多展开。推理负载为主、模型结构相对固定的业务昇腾在推理场景的能效比表现不错如果模型结构稳定一次适配好之后长期运行成本可控。有专门AI基础设施团队的公司昇腾方案需要一定的技术投入来做适配和调优如果团队里有熟悉底层优化的人能发挥出更大价值。反过来如果你的业务需要频繁尝试最新的模型结构或者团队里没有精力做底层适配那现阶段的昇腾方案可能会带来额外的工程负担。这不是说昇腾不好而是说任何技术选型都要匹配团队的实际能力。5.3 从DeepSeek适配看未来的软件栈竞争DeepSeek这次和昇腾的配合其实揭示了一个趋势未来AI算力的竞争硬件参数的重要性会相对下降软件栈的生态和易用性会越来越关键。因为当硬件算力普遍过剩的时候决定实际可用算力的是软件栈能把多少理论算力转化成实际性能。这对国产算力方案来说既是机会也是挑战。机会在于如果能在软件栈上做出差异化比如针对特定模型结构做深度优化就能在特定场景下实现超越通用方案的表现。挑战在于软件栈的积累需要时间和生态这不是靠单点突破能解决的。我个人的判断是未来两三年里CANN和CUDA的差距会继续缩小但不会完全消失。对于开发者来说多掌握一套技术栈不是坏事毕竟技术选型的自由度越大应对变化的能力就越强。6. 一些实操层面的补充建议如果你正准备在昇腾上部署DeepSeek或者类似的模型下面这些建议可能对你有用。第一版本匹配是重中之重。CANN版本、驱动版本、框架版本、模型转换工具版本这四者之间的兼容性一定要提前确认。我遇到过好几次因为版本不匹配导致的诡异问题排查半天最后发现是版本组合不对。建议直接参考官方文档里推荐的版本组合不要自己随意搭配。第二先跑通再优化。不要一上来就追求极致性能先用官方推荐的配置把模型跑起来确认功能正确然后再逐步做性能优化。优化过程中每次只改一个变量改完做性能对比这样才能准确判断每个优化的实际效果。第三重视Profiling数据。昇腾的Profiling工具能提供很详细的性能数据但很多人拿到数据之后不知道怎么分析。我的建议是重点关注三个指标算子耗时占比、内存带宽利用率、计算单元利用率。这三个指标能帮你快速定位瓶颈类型。第四保持对社区动态的关注。CANN的版本迭代速度比较快每个版本都会新增算子支持、优化性能、修复问题。定期看看Release Notes说不定你之前头疼的问题在新版本里已经解决了。最后说一点个人感受。我从最早在昇腾上跑一个简单CNN都要折腾半天到现在能比较顺畅地部署大模型这个变化是实实在在的。软件栈这东西进步往往不是线性的而是在某个节点之后突然变得可用。DeepSeek这次在昇腾上的表现让我觉得那个节点可能已经到了。当然具体到每个项目还是要根据自己的实际情况做评估和验证毕竟别人的经验替代不了自己的实测。