1. 从"等了八年"说起：昇腾软件栈到底卡在哪

"华为昇腾等了八年的软件栈，终于原地起飞"——这句话第一次看到的时候，我盯着"八年"两个字看了很久。作为一个从2019年就开始折腾昇腾310和910系列开发板的人，我太清楚这八年意味着什么了。硬件参数年年更新，算力数字一路往上飙，但真正让开发者头疼的从来不是芯片本身，而是芯片之上那层看不见摸不着的软件栈。

先把这个话题的背景说清楚。华为昇腾（Ascend）系列AI处理器从2018年前后正式对外亮相，配套的软件栈叫CANN（Compute 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），而写自定义算子又需要熟悉TBE（Tensor 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的模型结构里用了不少自定义的操作，比如MLA（Multi-head Latent Attention）和一些特殊的归一化层。这些操作在标准PyTorch里可能没有直接对应的算子，需要框架适配层做映射。如果映射做得不好，就会出现前面说的图切分问题。

实际操作中，我建议先用昇腾官方提供的模型适配脚本跑一遍，看看转换过程中有没有报错或者警告。转换完成后，用性能分析工具（比如昇腾的Profiling工具）看一下算子分布，确认关键算子都落在了昇腾上而不是CPU上。

3.2 推理引擎选型：MindIE还是自研

昇腾平台上跑大模型推理，官方主推的引擎是MindIE（Mind 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 常见算子优化手段与适用场景

针对昇腾平台的算子优化，常用的手段有这么几类：

算子融合是最常用也最有效的手段之一。比如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这次在昇腾上的表现，让我觉得那个节点可能已经到了。当然，具体到每个项目，还是要根据自己的实际情况做评估和验证，毕竟别人的经验替代不了自己的实测。