昇腾AI算力实战：从大模型训练到推理部署的守正与开放

1. 大模型淘金热背后的算力焦虑

1.1 为什么所有人都在谈"淘金"

这两年跟同行聊天，话题绕来绕去最后总会落到同一个点上：算力。不管你是做NLP的、搞CV的，还是原来跟AI八竿子打不着的传统行业开发者，只要沾上大模型，第一反应都是"卡够不够用"。

这个局面特别像当年的淘金热。1848年旧金山河边发现金子的消息传开之后，涌进来的不只是矿工，还有卖铲子的、卖牛仔裤的、开旅馆的。真正靠挖金子发财的人其实没那么多，但围绕淘金这件事做基础设施的，反而活得挺滋润。现在的大模型赛道一模一样——大家都在抢着训练自己的模型、微调自己的模型、部署自己的模型，但真正稀缺的不是想法，是能把想法跑起来的算力底座。

我身边就有个很典型的例子。一个做智能客服的小团队，去年下半年决定从原来的规则引擎切换到基于大模型的方案。想法很好，demo也跑通了，但一算推理成本，直接傻眼。他们原本预估的GPU采购预算，在实际询价之后发现只够撑三个月。后来他们开始认真评估各种替代方案，包括不同厂商的AI加速卡和配套的软件栈。这个过程让我意识到一个问题：大模型淘金热里，真正决定谁能活下来的，不是谁的模型参数多，而是谁能把算力这件事算明白。

1.2 算力供给的"守正"逻辑

说到算力供给，就不得不提一个核心矛盾：通用性和专用性之间的拉扯。

早期大家做AI训练，基本是英伟达的GPU一统天下。CUDA生态太成熟了，PyTorch、TensorFlow默认就是为它优化的，你几乎不需要考虑底层适配的问题。但问题是，当大模型把算力需求推到一个新的量级之后，单纯依赖一种算力供给方式，无论从成本还是从供应链安全的角度看，都开始变得不太现实。

这就引出了"守正"这个概念。所谓守正，我的理解是：在核心能力上不妥协，在基础架构上不走捷径。具体到AI芯片和软件栈这个层面，守正意味着几件事：

第一，计算精度不能降。大模型训练对浮点运算精度的要求极高，BF16、FP16这些格式的支持必须是原生的、高效的，不能靠软件模拟来凑合。第二，互联带宽要跟得上。大模型训练不是单卡能搞定的事，多卡之间的通信效率直接决定了整体训练速度。第三，软件栈要完整。从底层的驱动、编译器，到上层的框架适配、算子库，缺一环都会让开发者用起来磕磕绊绊。

我见过一些团队在选型的时候只看纸面算力参数，结果实际跑起来发现算子覆盖率不够，很多自定义层跑不了，最后不得不回退到原来的方案。这就是典型的"不正"——基础没打牢，上层建筑再花哨也没用。

1.3 "开放"为什么是必选项

光有守正还不够。AI这个领域变化太快了，没有任何一家能靠闭门造车跟上节奏。开放的意义在于：让整个生态的力量都来帮你完善这个平台。

开放体现在几个层面。最直接的是框架兼容。开发者习惯用什么框架，你就得支持什么框架。PyTorch、TensorFlow、MindSpore，甚至一些自研的训练框架，都得能跑起来。其次是算子开放。大模型的结构日新月异，今天流行这个注意力机制，明天可能就换了另一种。如果算子库是封闭的，每次都要等官方更新，那开发者的节奏就被拖死了。最后是社区共建。让开发者能贡献算子、贡献优化、贡献工具链，这个平台才有生命力。

我个人的观察是，一个AI计算平台能不能成，短期看硬件参数，中期看软件成熟度，长期看生态开放度。硬件参数可以堆，软件成熟度可以迭代，但生态这个东西，一旦形成正循环，后来者就很难追了。

2. 昇腾AI的架构拆解：从芯片到软件栈

2.1 达芬奇架构的核心设计思路

昇腾AI处理器的底层是达芬奇架构，这个架构最核心的特点是面向矩阵运算的专用设计。跟通用GPU不同，达芬奇架构里有一个专门做矩阵乘法的计算单元，叫Cube单元。这个设计选择背后的逻辑很直接：大模型的计算负载里，矩阵乘法占了绝对大头。

我做过一个粗略的统计，在一个典型的Transformer模型里，矩阵乘法相关的运算能占到总计算量的90%以上。注意力机制里的QKV计算、前馈网络里的两层全连接，本质上都是矩阵乘法。所以把矩阵乘法做快、做省电，整个芯片的效率就上去了。

Cube单元的设计思路跟Google的TPU有些类似，都是走专用加速的路线。但昇腾的不同之处在于，它在专用和通用之间做了一个平衡。除了Cube单元，还有Vector单元和Scalar单元，分别处理向量运算和标量运算。这种异构设计的好处是，不同类型的计算任务可以分配到最合适的单元上，不会出现"用大炮打蚊子"的浪费。

2.2 软件栈的分层逻辑

昇腾的软件栈从下到上大致可以分成几层，每一层解决不同的问题。

最底层是驱动和固件，负责管理硬件资源、处理中断、做基础的调度。这一层开发者一般接触不到，但它决定了整个系统的稳定性。

往上一层是CANN，全称是Compute Architecture for Neural Networks。这一层是整个软件栈的核心，相当于英伟达的CUDA。CANN里面包含了编译器、算子库、通信库、运行时等一系列组件。开发者写的模型最终要经过CANN的编译和优化，才能在昇腾硬件上高效运行。

再往上是框架适配层。PyTorch、TensorFlow、MindSpore这些框架通过适配层跟CANN对接。适配层的工作是把框架里的计算图转换成CANN能理解的中间表示，然后再由CANN做进一步的优化和调度。

最上面是应用层，也就是开发者直接打交道的部分。模型训练脚本、推理服务、微调工具，都在这一层。

这个分层设计的好处是解耦。硬件升级了，只要CANN适配好，上层框架和应用基本不用动。框架版本更新了，只要适配层跟上，底层硬件也不用改。这种解耦对于快速迭代的AI领域来说非常重要。

2.3 昇腾的"守正"体现在哪

回到守正这个话题，昇腾在几个关键点上的选择很能说明问题。

精度支持方面，昇腾原生支持FP16、BF16、INT8等多种数据格式。BF16这个格式在大模型训练里特别重要，因为它既有足够的动态范围，又比FP32省一半的存储和带宽。昇腾对BF16的支持是硬件级的，不需要额外的转换开销。

互联方面，昇腾有自己的高速互联技术，叫HCCS。在多卡训练场景下，卡间通信带宽直接决定了梯度同步的效率。HCCS的设计目标就是让多卡之间的通信不成为瓶颈。

算子覆盖方面，CANN的算子库一直在扩充。我查过一些公开的资料，目前主流的大模型算子基本都能覆盖，包括各种注意力机制的变体、各种归一化层、各种激活函数。当然，新出的算子可能还需要等一段时间，但整体覆盖度已经相当可观了。

实操心得：在评估一个AI计算平台的时候，不要只看它支持哪些算子，还要看它对新算子的响应速度。大模型领域每个月都有新东西出来，如果算子更新周期超过一个月，实际用起来就会很痛苦。

3. 大模型训练场景下的实操要点

3.1 环境搭建与基础配置

假设你现在要在昇腾平台上跑一个大模型训练任务，第一步是环境搭建。这个过程跟GPU平台有一些相似之处，但也有不少需要注意的地方。

首先是驱动和CANN的安装。昇腾的驱动和CANN版本之间有严格的对应关系，装错了版本会导致各种奇怪的问题。我的建议是，在开始之前先查清楚你的硬件型号对应的推荐版本组合，不要盲目追新。新版本可能有一些性能优化，但也可能引入新的bug。

安装完成之后，用npu-smi info命令可以查看硬件状态。这个命令相当于GPU平台上的nvidia-smi，能看到每张卡的利用率、显存占用、温度等信息。

# 查看昇腾硬件状态 npu-smi info # 查看CANN版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg

然后是框架适配。如果你用的是PyTorch，需要安装对应的昇腾适配版本。这个适配版本不是简单的pip install就能搞定的，通常需要从源码编译或者使用官方提供的whl包。编译过程可能会遇到依赖问题，建议在干净的容器环境里操作。

3.2 模型迁移的关键步骤

把一个在GPU上跑通的模型迁移到昇腾平台，大致需要经过这几个步骤。

第一步是算子映射检查。用昇腾提供的工具扫描你的模型，看看有没有不支持的算子。如果有，要么找替代实现，要么自己写一个自定义算子。这一步是最耗时的，尤其是对于结构比较特殊的模型。

第二步是精度对齐。同样的模型，在不同硬件上跑出来的结果可能会有细微差异。这个差异可能来自浮点运算的顺序不同，也可能来自某些算子的实现细节不同。你需要设置一个可接受的误差范围，然后逐层对比输出，定位差异来源。

第三步是性能调优。模型能跑通之后，接下来就是让它跑得快。昇腾提供了一些性能分析工具，可以帮你定位瓶颈。常见的优化手段包括：调整batch size、优化数据加载 pipeline、使用混合精度训练、调整通信策略等。

# 混合精度训练配置示例（基于MindSpore） from mindspore import amp # 定义混合精度策略 mp_level = "O2" # O2表示使用BF16混合精度 model = amp.build_train_network( network=model, optimizer=optimizer, level=mp_level, loss_fn=loss_fn )

注意事项：混合精度训练虽然能省显存、提速，但不是所有模型都适合。有些模型对精度特别敏感，用了混合精度之后收敛会变差。建议先在小规模数据上验证效果，再全量跑。

3.3 多卡训练的通信优化

大模型训练离不开多卡并行。昇腾平台上的多卡训练主要有两种并行策略：数据并行和模型并行。

数据并行是最常用的方式，每张卡上放一份完整的模型副本，数据分成多份，各自计算梯度，然后同步。这种方式实现简单，但对显存的要求高，因为每张卡都要放下整个模型。

模型并行是把模型切开放到不同的卡上，适合参数量特别大的模型。但模型并行的通信开销更大，因为每层计算都需要跨卡通信。

在实际操作中，我一般会先用数据并行试试，如果显存不够再考虑模型并行或者混合并行。昇腾的通信库对这两种模式都有支持，关键是要配置好通信组和通信策略。

# 数据并行配置示例 import mindspore.dataset as ds from mindspore.communication import init # 初始化通信环境 init() # 设置并行模式 context.set_auto_parallel_context( parallel_mode=ParallelMode.DATA_PARALLEL, gradients_mean=True, device_num=8 # 使用8张卡 )

通信优化的一个关键点是梯度压缩。在多卡训练中，梯度同步的通信量跟模型参数量成正比。如果模型有几十亿参数，每次同步的通信量就是几十GB。梯度压缩技术可以把通信量降低一个数量级，代价是可能损失一点精度。这个取舍需要根据实际情况来定。

4. 推理部署的实战经验

4.1 推理场景的特殊考量

训练和推理对硬件的要求很不一样。训练看重的是算力和显存带宽，推理看重的则是延迟和吞吐。而且推理场景更加多样化，有的是在线服务，要求低延迟；有的是离线批处理，要求高吞吐。

在昇腾平台上做推理部署，有几个点需要特别注意。

模型转换是第一步。训练好的模型需要转换成昇腾能高效执行的格式。昇腾提供了一个叫ATC的工具，可以把ONNX、TensorFlow等格式的模型转换成om格式。转换过程中会做算子融合、量化等优化。

# 使用ATC转换模型 atc --model=model.onnx \ --framework=5 \ --output=model_optimized \ --soc_version=Ascend310 \ --input_shape="input:1,3,224,224" \ --precision_mode=allow_mix_precision

量化是推理优化的重头戏。把FP16的模型量化成INT8，理论上能带来2-4倍的性能提升，同时显存占用减半。但量化会带来精度损失，需要做校准。昇腾提供了量化工具，可以基于一小批校准数据自动完成量化参数的搜索。

4.2 服务化部署的架构选择

推理服务化部署有几种常见的架构模式。

单模型单服务是最简单的模式，一个模型起一个服务进程。这种模式适合模型数量少、流量稳定的场景。优点是隔离性好，一个模型出问题不影响其他模型。缺点是资源利用率低，每个服务都要预留一定的资源。

多模型共享服务是把多个模型放在同一个服务进程里，共享底层资源。这种模式适合模型数量多、单个模型流量不大的场景。昇腾的推理引擎支持多模型加载，可以在一个进程里管理多个模型。

流水线服务是把多个模型串联起来，形成一个处理流水线。比如一个OCR服务，可能包含检测模型、识别模型、后处理模型。这种模式需要处理好模型之间的数据传递和同步。

实操心得：在部署推理服务的时候，一定要做压力测试。我见过不少团队在开发环境跑得好好的，一上生产就崩了。原因往往是并发量上来之后，显存不够或者请求队列积压。建议用wrk或者ab这类工具做一下基准测试，心里有个底。

4.3 性能调优的常见手段

推理性能调优有几个常用的手段，我按效果从大到小排一下。

Batch size调整是最直接的。增大batch size能提高硬件利用率，但会增加延迟。需要根据业务对延迟的要求来找到平衡点。一般来说，在线服务batch size设小一点，离线批处理设大一点。

算子融合是编译器层面的优化。把多个小算子合并成一个大算子，减少kernel launch的开销和中间结果的存储。昇腾的编译器会自动做一部分融合，但也可以通过图优化接口手动指定。

内存复用是减少显存占用的有效手段。推理过程中，很多中间张量的生命周期是错开的，可以复用同一块内存。昇腾的内存管理支持这种复用，但需要正确配置。

多流并行是把不同的计算任务分配到不同的流上，让它们并行执行。比如数据预处理和模型推理可以放在不同的流上，重叠执行。

5. 生态开放的实际价值

5.1 开发者能获得什么

一个平台的生态开放度，最终要落到开发者能获得什么实际好处上。

首先是选择权。开放的生态意味着开发者不会被绑定在某一个框架或者某一种工具上。你今天用PyTorch，明天想换MindSpore，底层硬件不用动。这种灵活性在快速变化的AI领域特别重要。

其次是问题解决的速度。开放生态里，你遇到的问题很可能别人已经遇到过了。社区里有现成的解决方案，或者至少有人能帮你指个方向。封闭生态里，你只能等官方支持，那个周期可能是几周甚至几个月。

第三是参与感。开放的生态允许开发者贡献代码、贡献算子、贡献工具。你写的一个优化可能被合并到主线，惠及所有人。这种正反馈循环是生态繁荣的关键。

5.2 社区共建的几种模式

昇腾生态的社区共建主要有几种模式。

算子贡献是最直接的一种。开发者如果实现了某个新算子的高效版本，可以贡献到CANN的算子库。官方会做review和测试，通过之后就会合入。

模型库共建是另一种模式。昇腾有一个模型库，里面收录了各种主流模型的昇腾适配版本。开发者可以把自己适配好的模型贡献进去，其他人就可以直接拿来用，不用重复踩坑。

工具链贡献是更高级的一种。有些开发者会基于昇腾的接口开发一些辅助工具，比如性能分析工具、模型转换工具、调试工具。这些工具虽然不是核心组件，但对提升开发效率很有帮助。

教育内容贡献也很重要。写教程、录视频、做分享，这些看似不直接产生代码贡献，但对降低新开发者的入门门槛非常关键。

5.3 开放与守正的平衡

开放和守正看起来有点矛盾，但实际上是一体两面。

守正守的是核心能力和基础架构。计算精度、互联带宽、软件栈的稳定性，这些是不能妥协的。如果为了开放而牺牲了这些基础，那开放出来的生态也是建在沙滩上。

开放开的是接口和生态。让更多的框架能接入，让更多的开发者能参与，让更多的工具能集成。这些不会动摇核心架构，反而会让核心架构更有生命力。

我个人的判断是，一个AI计算平台能不能长期存活，关键看它能不能在守正和开放之间找到平衡点。守正太死，生态起不来；开放太滥，质量控不住。这个平衡点的把握，考验的是平台方的战略定力。

6. 常见问题与排查实录

6.1 环境配置类问题

问题一：CANN版本与驱动版本不匹配

这是最常见的问题。症状通常是npu-smi能正常显示硬件信息，但跑模型的时候报各种奇怪的错误，比如算子找不到、内存分配失败等。

排查方法：先确认驱动版本，再确认CANN版本，然后查官方文档里的版本对应表。如果不匹配，要么升级驱动，要么降级CANN。

# 查看驱动版本 cat /usr/local/Ascend/driver/version.info # 查看CANN版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg

问题二：Python环境冲突

昇腾的Python适配包对Python版本有要求，而且可能跟其他包有依赖冲突。建议用conda创建一个独立的环境，不要在系统Python里直接装。

问题三：权限问题

昇腾的一些操作需要root权限，比如加载驱动、修改设备配置等。如果是在容器里跑，需要确保容器有足够的权限。

6.2 模型迁移类问题

问题一：算子不支持

症状是模型转换或者执行的时候报"Op not supported"之类的错误。

解决方法：先用昇腾提供的算子查询工具确认哪些算子不支持。对于不支持的算子，有几个选择：找功能等价的替代算子、用多个支持的算子组合实现、自己写自定义算子。

问题二：精度对不齐

症状是模型能跑通，但输出跟GPU上的结果差异较大。

排查方法：逐层对比输出。先对比第一层的输出，如果第一层就对不上，说明是输入处理或者第一个算子的问题。如果第一层对得上，就继续往后对比，直到找到差异出现的层。

问题三：性能不达预期

症状是模型能跑，但速度比预期慢很多。

排查方法：用性能分析工具抓一下profile，看看时间花在哪里。常见的原因包括：数据加载成为瓶颈、算子没有融合、通信没有重叠、batch size太小等。

6.3 推理部署类问题

问题一：显存溢出

推理时显存溢出通常是因为batch size太大，或者模型没有做量化。

解决方法：减小batch size、启用量化、使用内存复用。

问题二：延迟波动大

推理延迟波动大通常是因为请求队列积压，或者有其他的计算任务在抢资源。

解决方法：增加服务实例、限制并发数、做资源隔离。

问题三：精度下降明显

量化之后精度下降是正常现象，但如果下降太多就不能接受了。

解决方法：调整量化策略、增加校准数据、对敏感层保持高精度。

避坑技巧：在昇腾平台上做开发，建议养成两个习惯。第一，每次遇到问题先查日志，昇腾的日志系统比较完善，大部分问题都能从日志里找到线索。第二，保持环境干净，不要在一个环境里混装多个版本的CANN和驱动，那是自找麻烦。

7. 一些个人体会

我在这个领域摸爬滚打了一段时间，踩过的坑不算少。最大的体会是：不要用GPU的思维来用昇腾。两者虽然都是AI加速硬件，但设计哲学和软件栈都不一样。用GPU的习惯来套昇腾，往往会觉得别扭。

正确的做法是，先花时间理解昇腾的架构特点和软件栈设计，然后按照它的方式来组织你的代码和流程。比如昇腾对算子融合的支持很好，那你就应该尽量让编译器有融合的机会，而不是手动拆得很细。再比如昇腾的通信库对特定拓扑有优化，那你就应该按照推荐的拓扑来组织多卡训练。

另一个体会是：社区的力量比想象的大。我遇到过好几个问题，官方文档里没写，但在社区论坛里找到了答案。有些是其他开发者踩过的坑，有些是官方工程师的补充说明。所以遇到问题不要闷头死磕，先去社区搜一搜，大概率有人已经遇到过了。

最后说一个具体的技巧。昇腾的性能分析工具里有一个功能叫"算子耗时统计"，能列出每个算子的执行时间。这个功能在调优的时候特别有用。我一般会先跑一遍，看看哪些算子耗时最多，然后针对性地优化。有时候优化一个热点算子，整体性能就能提升百分之十几。这个投入产出比是很划算的。

大模型淘金热还在继续，算力这件事的重要性只会越来越高。昇腾AI的守正和开放，本质上是在回答一个问题：怎么让更多的人用上、用好AI算力。这个问题的答案，不在参数表里，在每一个开发者的实际体验里。