昇腾950系列AI加速卡架构解析与选型部署实践

1. 从“算力焦虑”说起昇腾 950 系列到底在解决什么问题这两年跟做 AI 基础设施的朋友聊天绕不开的一个话题就是“算力不够用”。模型参数从十亿级跳到千亿级训练集群从几十张卡扩到几千张卡大家突然发现瓶颈不只是“有没有卡”而是“卡和卡之间能不能高效协同”“数据喂不喂得饱计算单元”“功耗和散热扛不扛得住”。昇腾 950 系列产品就是在这样的背景下进入视野的。我第一次接触昇腾 950 系列是在一个推理集群的选型讨论会上。当时团队面临一个很现实的问题已有的加速卡在跑大模型推理时单卡吞吐上不去多卡扩展又受限于互联带宽整体性价比算下来不划算。有人提了一句“要不要看看昇腾 950 系列”于是就有了后面一系列的调研、测试和踩坑。这篇文章我就把这段时间对昇腾 950 系列的认知梳理出来从它是什么、解决什么问题、核心架构怎么设计、实际部署要注意什么到选型时容易忽略的细节尽量讲透。先给不太熟悉的朋友一个定位昇腾 950 系列是面向 AI 计算场景的高性能处理器产品系列覆盖训练和推理两类负载主打的是高算力密度、高互联带宽和相对完善的软件栈生态。它不是一个孤立的芯片而是一整套包含芯片、板卡、服务器、集群互联和软件工具链的解决方案。你如果只是买一张卡插到普通服务器上大概率发挥不出它的全部实力——这是我在实际项目中体会最深的一点。适合谁来读这篇内容如果你是 AI 基础设施工程师、算法团队的工程化负责人、或者正在做算力集群选型的技术决策者这篇会比较对路。如果你只是好奇“昇腾系列有哪些 GPU”这类问题我也先澄清一个常见误解昇腾系列严格来说不是 GPU而是NPU神经网络处理单元架构的 AI 加速产品它的设计思路和传统 GPU 有相似之处但在计算单元组织、内存层次和数据流调度上有自己的逻辑。这个区别在后面讲架构时会展开。2. 昇腾 950 系列的产品定位与家族脉络2.1 它在昇腾产品线里处于什么位置要理解 950 系列得先把它放回昇腾整体的产品演进脉络里看。昇腾的产品线大致可以按“代际”和“面向场景”两个维度来划分。早期大家熟悉的是 310 系列偏推理、边缘和低功耗场景910 系列则是面向训练和高性能推理的主力。950 系列可以理解为在 910 基础上进一步强化算力和互联能力的一代产品面向的是更大规模、更高密度的 AI 计算需求。这里有个容易被忽略的点产品系列的“代际”不完全等同于“性能高低”更多是面向不同负载的重新设计。比如同样是 950 系列不同型号在算力、内存容量、互联接口上会有差异有的偏向训练集群有的偏向高吞吐推理。选型时如果只看“是不是 950”很容易买错型号。我在调研阶段就吃过这个亏一开始以为 950 系列只有一款后来才发现型号细分挺多必须对着具体规格表看。从网络上的讨论热度看“昇腾 950 系列”和“昇腾 960”经常被放在一起提。这其实反映了一个现实AI 芯片的迭代节奏很快大家在选型时不仅关心当前这一代能做什么还关心下一代会不会很快替代、当前投入会不会打水漂。我的建议是不要为了等下一代而无限期推迟当前项目因为软件生态的成熟度往往比硬件峰值算力更影响实际落地效果。950 系列目前的软件栈已经相对可用这一点比单纯看算力数字更重要。2.2 训练型和推理型负载的差异昇腾 950 系列在训练和推理两类场景下的表现逻辑是不一样的这一点必须分开看。训练场景的核心诉求是高算力 高互联带宽 大内存。训练一个大模型需要把参数、梯度、优化器状态都放在内存里还要在卡与卡之间频繁同步梯度。如果互联带宽不够计算单元就会“饿着”算力利用率上不去。950 系列在互联上做了专门设计这是它面向训练集群的关键卖点。推理场景的核心诉求则是低延迟 高吞吐 能效比。推理不一定需要那么大的内存但对批处理效率、量化支持、动态 shape 处理要求更高。同一个 950 系列的型号用在训练和推理上配置策略和调优手段完全不同。我见过有团队把训练卡直接拿去做推理结果发现吞吐还不如专门的推理卡原因就是没有针对推理做量化和批处理优化。提示在选型阶段就要明确你的主要负载是训练还是推理或者两者混合的比例。混合负载对集群调度和资源隔离的要求更高不能简单按“训练卡”或“推理卡”一刀切。2.3 和常见加速方案的对比思路很多人会拿昇腾 950 系列和市面上其他 AI 加速方案做对比。我的经验是不要只比峰值算力TFLOPS这一个数字那个数字在实际业务里往往只能达到理论值的百分之几十。真正要对比的是几个维度对比维度为什么重要昇腾 950 系列的关注点互联带宽决定多卡扩展效率卡间互联和集群互联的设计内存容量与带宽决定能跑多大模型大模型训练的内存墙问题软件栈成熟度决定落地速度算子库、框架适配、工具链能效比决定长期运营成本功耗与算力的平衡生态兼容性决定迁移成本对主流框架和模型的支持这张表不是让你去背而是提醒你选型是一个多目标决策问题任何单一指标都不能代表全部。我在实际项目里见过因为只看算力数字而选错方案、后期迁移成本巨大的案例所以这一节特意展开讲。3. 核心架构拆解950 系列的计算、内存与互联设计3.1 计算单元的组织逻辑昇腾 950 系列的核心计算单元采用的是达芬奇架构的演进版本。达芬奇架构的一个关键特点是“矩阵计算 向量计算 标量计算”三类单元协同工作。矩阵单元负责大规模的乘加运算这是深度学习里最密集的计算向量单元处理激活函数、归一化等操作标量单元则负责流程控制和地址计算。为什么要这样分因为深度学习负载的计算模式差异很大。卷积和全连接层是典型的矩阵运算适合专用矩阵单元而像 LayerNorm、Softmax 这类操作用矩阵单元反而效率低交给向量单元更合适。把不同计算模式分给不同单元是提升整体利用率的关键设计。这一点和传统 GPU 用统一着色器处理所有计算任务的思路不同各有取舍。实际调优时理解这个分工很有用。比如你发现某个算子性能不达预期可以先判断它主要落在哪类单元上再针对性优化。如果是一个矩阵密集的算子跑得慢可能是矩阵单元利用率不够如果是一个归一化算子慢可能是向量单元和矩阵单元之间的数据搬运成了瓶颈。3.2 内存层次与数据搬运AI 芯片的性能瓶颈很多时候不在计算而在数据搬运。昇腾 950 系列在内存层次上做了分级设计片上缓存、片上高速内存、片外高带宽内存HBM。数据从片外搬到片上、在片上各级之间流转每一步都有带宽和延迟的代价。我打个比方计算单元是厨房里的厨师片外内存是仓库片上缓存是灶台旁边的备菜区。厨师做菜再快如果备菜区总是空的或者从仓库拿菜的速度跟不上出菜速度就上不去。优化内存访问模式本质上就是让备菜区尽量不空、让仓库到备菜区的搬运尽量少。具体到实操有几个常见手段算子融合把多个小算子合并成一个大算子减少中间结果的搬运、数据复用让同一份数据在片上多停留一会儿被多个计算复用、以及合理的数据布局比如把卷积的输入按特定格式排布提升访问效率。这些手段在昇腾的软件栈里都有对应的工具和接口支持后面讲软件栈时会提到。3.3 互联设计多卡协同的关键多卡训练的效率很大程度上取决于卡间互联。昇腾 950 系列在互联上支持高带宽的卡间通信这是它面向大规模训练集群的核心能力之一。为什么互联这么重要因为数据并行训练时每张卡算完梯度后要和其他卡同步这个同步操作如果带宽不够就会成为整个训练流程的瓶颈。举个具体的场景假设你有 64 张卡做数据并行训练每张卡每轮迭代要同步几百 MB 的梯度。如果卡间带宽是每秒几十 GB同步时间可能只占迭代时间的一小部分但如果带宽只有每秒几 GB同步时间可能比计算时间还长扩展效率就崩了。互联带宽决定了你的集群能扩展到多大规模而不显著掉效率。昇腾 950 系列在互联上的设计包括卡间高速互联和集群级互联两个层面。卡间互联解决的是同一节点内多卡通信集群级互联解决的是跨节点通信。实际部署时网络拓扑的设计比如用什么样的交换结构、怎么规划通信域会直接影响训练效率。这部分内容偏工程但选型时至少要确认你的集群规模对应的互联方案是否成熟、是否有实际案例验证过。4. 软件栈与工具链决定落地速度的隐形战场4.1 从框架到硬件的适配链路硬件再强如果软件栈不好用落地速度就会大打折扣。昇腾 950 系列的软件栈大致可以分成几层底层是驱动和运行时中间是算子库和通信库上层是框架适配和开发工具。对大多数算法工程师来说最关心的是上层框架能不能无缝用。目前主流的深度学习框架昇腾都有对应的适配版本。但这里有个现实问题适配版本和原生版本之间可能存在算子覆盖度、性能表现、API 行为上的差异。我在项目里遇到过某个算子在原生框架上跑得好好的迁移到适配版本后精度有细微偏差排查了很久才发现是算子实现细节不同。注意迁移到新硬件平台时一定要做精度对齐测试不能只看 loss 曲线大致收敛就认为没问题。有些偏差在训练早期看不出来到后期才暴露。4.2 算子开发与自定义算子如果你的模型里有自定义算子或者用了比较新的算子可能需要自己开发。昇腾提供了算子开发工具链支持用类 C 的语言编写算子并在硬件上运行。这个过程有一定的学习成本但一旦跑通后续复用就比较方便。我的经验是优先用官方算子库实在没有再自己写。自己写算子不仅要考虑功能正确还要考虑性能优化怎么利用矩阵单元、怎么安排内存访问调优周期可能比预期长。如果时间紧可以先看官方算子库里有没有功能相近的算子可以改造或者看社区里有没有人已经实现过类似算子。4.3 性能分析工具的使用性能调优离不开工具。昇腾提供了一套性能分析工具可以采集算子级别的执行时间、内存占用、计算单元利用率等指标。这些数据是定位瓶颈的依据。我通常的排查顺序是先看整体吞吐和延迟判断是计算瓶颈还是通信瓶颈如果是计算瓶颈再看是哪个算子耗时最多然后针对那个算子看它的计算单元利用率和内存访问效率。不要一上来就盯着最底层的细节先定位大方向再逐层深入。这个思路在任何硬件平台上都适用。5. 实际部署中的坑与应对来自一线的经验5.1 环境配置里最容易忽略的细节部署昇腾 950 系列环境配置是第一步也是最容易出问题的一步。我踩过的坑包括驱动版本和固件版本不匹配、容器环境和宿主机环境的库版本冲突、多卡环境下设备编号和实际物理卡对应不上。其中设备编号问题特别隐蔽。在多卡服务器上系统给每张卡分配的编号不一定和物理插槽顺序一致。如果你在代码里写死了设备编号换一台机器可能就跑错了卡。我的做法是在代码里通过环境变量或配置文件指定设备而不是硬编码部署前先用工具确认每张卡的物理位置和逻辑编号的对应关系。另一个容易忽略的是内存和显存的配额。容器环境下如果没正确配置显存配额可能出现容器内看到的显存和实际可用不一致的情况导致 OOM 报错但排查方向完全错误。5.2 多卡训练的效率调优多卡训练的效率问题我总结下来主要有三类通信瓶颈、负载不均、以及数据加载跟不上。通信瓶颈前面讲过核心是互联带宽和通信策略。昇腾的通信库支持多种通信算法比如 ring all-reduce、tree all-reduce不同算法在不同集群规模下的表现不一样。小规模集群可能 ring 算法更优大规模集群可能 tree 或分层算法更优这个需要实测。负载不均通常出现在模型并行场景。如果模型切分不合理某些卡的计算量明显大于其他卡整体效率就被最慢的那张卡拖累。解决办法是重新设计切分策略让各卡计算量尽量均衡。数据加载跟不上是另一个常见问题。如果数据预处理在 CPU 上做而 CPU 处理速度跟不上 NPU 的计算速度NPU 就会“饿着”。解决办法包括增加数据加载的并行度、把部分预处理放到 NPU 上做、或者用更高效的数据格式比如把数据预先转成二进制格式减少解析开销。5.3 推理场景的批处理与量化推理场景和训练场景的调优重点不同。推理最关心的是单位时间能处理多少请求所以批处理策略很关键。批处理太大延迟高批处理太小吞吐低。找到一个平衡点需要根据业务的实际延迟要求来定。量化是提升推理吞吐的另一个手段。把模型从 FP16 量化到 INT8理论上吞吐能翻倍但精度可能下降。我的经验是先做量化感知训练或训练后量化评估精度损失是否可接受再决定是否上线。有些模型对量化很敏感强行量化会导致效果明显变差有些模型则几乎无损。这个必须用实际业务数据验证不能只看论文里的数字。6. 选型决策什么场景该考虑昇腾 950 系列6.1 适合的场景特征根据我这段时间的观察昇腾 950 系列比较适合以下几类场景第一类是大规模训练集群尤其是对互联带宽要求高、需要扩展到几十张卡以上的场景。950 系列的互联设计在这类场景下优势比较明显。第二类是对能效比有要求的推理集群。如果机房功耗和散热有硬约束能效比就成了关键指标这时候需要重点对比不同方案在相同吞吐下的功耗。第三类是已有昇腾生态积累的团队。如果团队已经在用昇腾的其他产品迁移到 950 系列的学习成本相对低工具链和运维经验可以复用。6.2 需要谨慎评估的场景反过来有些场景需要谨慎。比如模型里有大量自定义算子且短期无法迁移的场景迁移成本可能很高。再比如对特定框架版本有强依赖的场景如果适配版本还没跟上可能要等。还有一个容易被忽略的点运维体系的适配。新硬件平台的监控、告警、故障排查流程和原有体系可能不同需要提前规划。我见过硬件买回来了、但运维团队不熟悉、出问题时排查效率低下的情况。6.3 一个简单的选型检查清单最后给一个我在实际项目中用的检查清单供参考主要负载是训练还是推理比例如何模型规模多大需要多少内存和互联带宽集群规模规划是多少张卡互联方案是否支持模型里的算子是否都在官方算子库覆盖范围内团队是否有昇腾平台的使用经验运维监控体系是否需要改造长期运营的功耗和成本预算是多少这个清单不是让你逐条打勾就完事而是提醒你选型是一个系统工程硬件只是其中一环。把这些问题想清楚比单纯比较算力数字有价值得多。我在实际使用中的体会是昇腾 950 系列是一套需要“配套使用”的产品——配套的软件栈、配套的集群设计、配套的运维体系。单独看某一张卡或某一个型号很难判断它是否适合你。反过来如果你愿意花时间把整个链路跑通它在特定场景下能带来的效率提升是实实在在的。后续如果大家感兴趣我可以再写一篇关于具体调优参数和实测数据的分享。