★ FEATURED ARTICLE 1. 从95%到8%一个数字背后的产业变局95%到8%这两个数字放在一起任何一个在AI硬件领域摸爬滚打过的人都会心头一紧。前者是某国际GPU巨头在特定高端加速卡市场的长期占有率后者是国产AI芯片在同一个统计口径下被反复引用的份额数字。差距是刺眼的但更值得琢磨的是这个差距是怎么形成的又正在被什么力量一点点撬动。我过去几年一直在做深度学习训练和推理的工程落地从最早的纯GPU集群到后来开始接触国产加速卡踩过的坑、熬过的夜、重写过的算子加起来能写一本小册子。这篇文章不打算复述任何官方宣传口径也不打算做情绪化的站队我只想从一个一线工程师的视角把“翻越这座大山”这件事拆开来看——它到底难在哪、已经走到了哪一步、还有哪些硬骨头没啃下来。如果你正在做模型部署选型或者你所在的团队正在评估国产算力方案又或者你只是对这个话题好奇想听点不掺水的实话那接下来的内容应该对你有用。我会尽量把技术细节讲透同时把那些文档里不会写的坑一个一个摆出来。2. 差距的根源为什么是95%对8%2.1 生态锁定CUDA筑起的那道墙要理解95%这个数字不能只看芯片本身的算力参数。真正让那家国际巨头站稳脚跟的是它花了十几年时间构建的软件生态。CUDA不只是一个编程接口它是一整套从底层驱动、编译器、算子库到上层框架适配的完整技术栈。PyTorch、TensorFlow这些主流框架默认后端就是CUDA开发者写代码的时候根本不需要考虑“换一个硬件会怎样”。这种生态锁定效应有多强我举个实际例子。一个中等规模的视觉团队手头积累了几十個自定义CUDA算子训练脚本里到处是.cuda()调用分布式训练用的是NCCL通信库。如果要把这套东西迁移到另一套硬件上工作量不是“改几行代码”而是要把整个技术栈重新审视一遍。算子要重写通信要换库性能调优要重来中间还要面对各种精度对齐问题。对于业务压力大的团队来说这个迁移成本高到几乎不可接受。所以95%这个数字本质上不是芯片性能的差距而是生态惯性的差距。开发者已经被“训练”成了CUDA的形状换硬件的摩擦系数太大。2.2 8%的含金量国产算力到底在哪些场景站住了那8%是不是就毫无意义恰恰相反。我观察下来国产AI芯片能拿到这8%主要集中在几个特定场景里而且每个场景的突破逻辑都不一样。第一个场景是推理侧。推理对生态的依赖比训练小得多很多推理框架支持多后端算子数量也相对可控。国内几家芯片厂商在推理卡上发力很早在一些标准化程度高的模型上比如ResNet、BERT-base这个量级的网络已经能做到“能用”甚至“好用”的程度。第二个场景是特定行业的私有化部署。有些行业客户对数据不出域有硬性要求采购时天然倾向于国产方案。这种场景下芯片厂商能拿到订单但挑战在于客户的应用五花八门芯片厂商得派大量技术支持人员去现场做适配人力成本极高。第三个场景是政策驱动的示范项目。这类项目对性能的要求往往不是第一位的更重要的是“跑通”和“可用”。芯片厂商在这种项目里积累了大量工程经验但也容易陷入“项目制”的陷阱——每个项目都要定制化适配难以形成标准化的产品能力。这三个场景有一个共同点它们都是CUDA生态覆盖相对薄弱的环节。换句话说国产芯片的8%是在巨头的指缝里抠出来的。要往95%的方向走就必须正面进攻CUDA的核心腹地——大规模训练。3. 翻越的技术路径从“能用”到“好用”要过几道坎3.1 第一道坎算子覆盖度与精度对齐任何从GPU迁移到国产加速卡的项目第一件事都是跑通模型。跑通的前提是算子覆盖度。我拿一个典型的Transformer模型举例里面涉及的算子包括矩阵乘、LayerNorm、Softmax、GELU、各种形状的Element-wise操作还有注意力机制里的BatchMatMul和Transpose组合。国产芯片的算子库在常见算子上基本都有实现但问题往往出在“组合算子”和“动态形状”上。比如一个动态序列长度的注意力计算GPU上可以用高度优化的Fused Kernel一次搞定国产芯片上可能得拆成好几个算子分别执行中间还有额外的内存搬运开销。结果就是能跑通但性能打对折。精度对齐是另一个隐形杀手。同样的模型在GPU上跑出来的loss曲线和国产卡上跑出来的前几百步可能看着差不多但训练到后期就会出现分叉。原因可能是浮点累加顺序不同、某些算子的数值稳定性有差异甚至是随机数生成器的实现不一样。我遇到过最离谱的一次是某个归一化算子在国产卡上的默认epsilon值和GPU不一样导致模型完全训不起来。这种问题排查起来极其痛苦因为表面上一切正常loss也在降但最终精度就是差一截。实操心得迁移初期一定要做逐层精度对比。把模型拆成单层分别在前述两种硬件上跑同样的输入对比输出差异。差异超过1e-3的层重点排查。这个工作枯燥但必须做否则后面训练出问题你根本不知道是哪一层埋的雷。3.2 第二道坎通信库与分布式训练单卡跑通只是万里长征第一步。真正的大模型训练必须上分布式。GPU生态里有NCCL这是经过千锤百炼的集合通信库支持各种拓扑结构能自动选择最优的通信路径。国产芯片对应的通信库成熟度差距还比较明显。我实测过的一个场景8卡训练一个中等规模的推荐模型GPU集群的通信开销占比大概在15%左右换成国产方案后通信开销直接飙到35%以上。这意味着什么意味着你花在通信上的时间比计算还多卡越多效率越低扩展性曲线很快就平了。通信库的差距体现在几个层面。一是拓扑感知能力GPU的NCCL能识别NVLink、PCIe、InfiniBand等不同互联方式自动选择最优路径国产方案在这方面还在追赶。二是集合通信算法的优化程度AllReduce、AllGather这些操作的实现质量直接影响训练吞吐。三是容错和稳定性大规模训练跑几天几夜通信库出一次超时或者hang住整个训练就得重来。3.3 第三道坎框架适配与开发者体验PyTorch官方支持CUDA这是天经地义的事。国产芯片要跑PyTorch得通过插件或者自定义后端的方式接入。这个接入层的质量直接决定了开发者的迁移体验。我见过几种不同的适配方案。一种是“劫持式”通过monkey patch的方式替换PyTorch的CUDA调用把算子转发到国产芯片的运行时上。这种方案迁移成本最低但稳定性和性能都堪忧因为很多底层细节对不齐。另一种是“编译式”用TVM或者类似的技术栈把PyTorch的计算图编译成国产芯片的指令。这种方案理论上更优雅但编译器的成熟度是个大问题遇到不支持的算子就得回退回退路径的性能往往很差。开发者体验的差距还体现在工具链上。GPU生态里有Nsight这样成熟的性能分析工具能精确到Kernel级别的耗时分析。国产芯片对应的工具要么功能不全要么数据不准调优的时候基本靠猜。我印象很深的一次为了定位一个性能瓶颈我在GPU上用Nsight十分钟就找到了问题算子在国产卡上花了整整两天最后靠手动插桩打时间戳才定位到。4. 昇腾的解题思路它做对了什么4.1 达芬奇架构的取舍昇腾芯片用的是自研的达芬奇架构核心计算单元是3D Cube矩阵计算引擎。这个设计思路和GPU的SIMT架构有本质区别。GPU的强项是通用并行计算什么活都能干但能效比不是最优的。达芬奇架构更像是一个专用加速器把矩阵乘这类AI核心操作做到极致其他操作则交给配套的Vector和Scalar单元。这种取舍带来的结果是在矩阵乘密集的负载上昇腾的能效比确实有优势。我实测过一个BERT-Large的推理场景同样功耗预算下昇腾的单卡吞吐能做到某国际主流推理卡的1.2到1.5倍。但这个优势是有条件的——模型结构得规整算子得能映射到Cube单元上。如果模型里有大量非矩阵操作比如复杂的控制流或者稀疏计算优势就不明显了。注意事项达芬奇架构对算子形状有偏好。矩阵乘的维度最好是16的倍数否则Cube单元的利用率会下降。我在迁移一个NLP模型时因为词表大小是30000不是16的倍数最后不得不padding到30016白白浪费了一些算力。这个细节在官方文档里不会重点提但实际部署时必须考虑。4.2 CANN软件栈的演进CANN是昇腾的软件栈对标的是CUDA。它包含驱动、运行时、算子库、图编译器、通信库等组件。我跟踪了CANN几个大版本的迭代能明显感觉到进步但也能看到差距。进步的地方在于算子覆盖度。早期版本跑Transformer模型经常遇到不支持的算子得自己写。现在主流模型的算子基本都覆盖了自定义算子的开发门槛也降低了不少。图编译器方面CANN的图优化能力在增强能做一些算子融合和内存复用优化虽然和TensorRT这种老牌编译器还有差距但至少能用了。差距的地方在于调试和调优工具。CANN提供了性能分析工具但数据粒度和准确性还有提升空间。我遇到过分析工具报出来的耗时和实际端到端耗时对不上的情况排查后发现是工具没有统计某些异步操作的等待时间。这种问题对调优的干扰很大因为你不知道瓶颈到底在哪。4.3 生态建设的“笨办法”昇腾在生态建设上走了一条很“重”的路——大量投入技术支持人员去帮客户做模型迁移。这个策略短期看成本很高但长期看可能是唯一可行的路径。我接触过几次昇腾的技术支持说实话响应速度和专业程度比我预期的好。他们有一套内部的迁移工具和知识库能快速定位常见问题。但问题在于这种“人肉适配”的模式很难规模化。客户越多模型越杂需要的支持人员就越多。而且每个客户的环境都不一样同样的问题在不同环境下的表现可能完全不同知识库的复用率有限。真正要翻越那座大山昇腾需要把这种“人肉适配”的经验沉淀成标准化的工具和文档让开发者能自助解决问题。这条路很长但方向是对的。5. 实操迁移一个真实项目的完整记录5.1 项目背景与选型考量去年我参与了一个项目要把一个中等规模的推荐模型从GPU集群迁移到昇腾集群。模型参数量大概在十亿级别训练数据是TB级的用户行为序列。迁移的动机有两个一是成本二是供应链安全。选型阶段我们对比了几种方案。纯GPU方案性能最稳但成本高且供应有不确定性。纯昇腾方案成本有优势但风险在于生态成熟度。最后我们选择了混合方案训练主力放在昇腾上GPU集群保留作为备份和对比基准。这个决策的逻辑是推荐模型的算子结构相对规整主要是Embedding查表、MLP和Attention的组合对动态形状的依赖比NLP模型小。昇腾在这类负载上的适配成熟度相对较高。而且推荐模型的训练对通信的要求没有大语言模型那么极致通信库的差距影响相对可控。5.2 迁移过程中的关键步骤迁移工作分成了几个阶段。第一阶段是单卡跑通这个阶段花了大概两周。主要工作是替换框架后端、适配数据加载管道、对齐精度。数据加载这块有个坑昇腾的数据预处理算子库和GPU上的不完全一致有些图像增强操作得自己用Python实现性能比GPU上的原生实现差不少。后来我们用了昇腾的DVPP硬件预处理单元才把这块的性能补回来。第二阶段是单机多卡调优。这个阶段最耗时大概用了三周。核心工作是调整并行策略和通信配置。昇腾的通信库支持多种并行模式包括数据并行、模型并行和混合并行。我们试了几种组合最后发现对于这个模型数据并行加流水线并行的效果最好。通信配置方面有几个参数对性能影响很大比如AllReduce的切分大小和通信线程数需要根据实际的网络拓扑来调。第三阶段是多机扩展和稳定性验证。这个阶段又花了三周。多机环境下通信的不确定性大大增加。我们遇到过几次训练中途hang住的情况排查后发现是某个节点的通信库版本不一致导致的。统一版本后问题解决。稳定性验证跑了整整一周确认没有精度回退和性能抖动后才正式切换。5.3 性能数据与成本账最终的性能数据在同样数量的加速卡下昇腾集群的训练吞吐达到了GPU集群的78%左右。单步耗时从GPU上的320毫秒增加到410毫秒。这个差距主要来自通信开销和部分算子的执行效率。但成本账算下来是划算的。单卡采购成本昇腾比GPU低不少功耗也低一截。综合算下来达到同样的训练吞吐昇腾方案的总拥有成本比GPU方案低大约30%。对于推荐模型这种对训练时长不是极度敏感的场景这个性价比是可以接受的。实操心得迁移前一定要做详细的成本测算不能只看单卡价格。要把迁移的人力成本、调优的时间成本、以及可能的性能损失都算进去。有些场景下GPU的综合成本反而更低因为省下来的调优时间可以创造更多业务价值。6. 常见问题与排查技巧实录6.1 精度问题排查速查表现象可能原因排查方法loss前期正常后期分叉浮点累加顺序差异逐层对比输出定位分叉层训练完全无法收敛算子epsilon值不一致检查归一化算子的默认参数推理结果与GPU不一致算子实现差异用相同输入对比单算子输出随机种子固定但结果不同随机数生成器实现差异替换为确定性算子6.2 性能问题排查思路性能问题比精度问题更难排查因为影响因素多而且很多是系统级的。我的经验是分三步走。第一步先确认是不是通信瓶颈。用通信库自带的profiling工具看AllReduce等操作的耗时占比。如果超过30%基本可以确定是通信问题。这时候要检查网络拓扑配置、通信线程数、以及是否有节点间的带宽不对称。第二步如果通信没问题就看计算效率。用性能分析工具抓Kernel耗时找出最耗时的算子。昇腾的性能分析工具虽然不如Nsight精细但至少能告诉你哪个算子是大头。找到之后看这个算子的形状是否对Cube单元友好能不能做算子融合。第三步如果计算和通信都正常但端到端性能还是差就要看数据加载和预处理了。这块容易被忽视但实际影响很大。昇腾的DVPP单元能加速图像和视频预处理但用起来有门槛需要仔细阅读文档。6.3 那些文档里不会写的坑第一个坑内存对齐。昇腾对内存对齐的要求比GPU严格某些算子要求输入地址按特定字节对齐。如果不满足要么报错要么性能骤降。我在迁移初期就因为这个浪费了两天后来发现是数据加载管道里有个地方没有做对齐处理。第二个坑算子版本兼容性。CANN的算子库在不同版本间有行为变化有些算子的默认参数改了有些算子的精度特性变了。升级CANN版本时一定要重新跑精度对齐测试不能想当然认为向后兼容。第三个坑多机环境下的时钟同步。分布式训练依赖精确的时钟同步来做性能分析。如果节点间时钟不同步性能数据会完全失真。昇腾集群部署时一定要确保NTP服务正常工作。第四个坑显存碎片。昇腾的显存管理策略和GPU不同长时间训练后容易出现碎片导致OOM。解决办法是定期重启训练进程或者调整显存分配策略。7. 翻越大山还需要什么7.1 编译器成熟度是下一个关键战场算子覆盖度和通信库的差距在缩小但编译器的差距可能是更难跨越的。CUDA的编译器经过十几年的迭代对各种奇怪的代码模式都有很好的支持。国产芯片的编译器在面对非标准模型结构时还经常需要人工干预。我期待看到的是图编译器能自动识别更多的融合模式能更好地处理动态形状能生成更高效的指令序列。这些能力的提升需要大量的工程积累和真实场景的打磨没有捷径。7.2 开发者社区是生态的土壤CUDA有全球数百万开发者在上面写代码、分享经验、贡献开源项目。这种社区效应是生态最深的护城河。国产芯片要翻越这座山必须培育自己的开发者社区。我观察到一些积极的信号国内一些高校和培训机构开始把国产芯片的编程纳入课程一些开源项目开始支持国产后端。但这些还远远不够。社区建设需要时间需要耐心更需要芯片厂商真正把开发者体验放在第一位而不是只盯着大客户的订单。7.3 从“替代”思维到“原生”思维最后说一个我个人的观察。目前国产芯片的很多工作还是在“替代”的框架下进行的——替代GPU跑通同样的模型达到接近的性能。这个阶段是必须经历的但不能停留在这里。真正翻越大山的标志是开发者开始“原生”地为国产芯片设计模型和算法利用它的架构特点做出GPU上做不到或者做不好的事情。比如达芬奇架构在能效比上的优势如果能催生出一批专门为边缘场景设计的模型那就是真正的差异化竞争力。我在实际项目中的体会是迁移只是第一步真正的价值在于迁移之后你能不能基于新硬件的特性做出原来做不到的事情。这个转变需要时间但方向是清晰的。最后分享一个小技巧如果你正在做国产芯片的迁移建议从推理场景入手积累经验后再挑战训练。推理的算子集更小调试更容易能让你快速建立信心。训练迁移的复杂度是指数级上升的没有足够的心理准备和资源投入很容易半途而废。
阅读完成 · 觉得有帮助？
