去年底我在一台搭载了海光DCU的国产服务器上装PyTorch。动手之前其实我是抱着“得折腾一周”的心理准备去的。毕竟过去几年国产GPU留给我的印象很割裂纸面参数越来越漂亮真到了跑模型的时候驱动装不上、框架不认卡、算子报错看不懂每一步都像在开盲盒。但这次有点意外。从装驱动到把Stable Diffusion的推理demo跑通前后只花了一个下午。不是因为我变熟练了而是这一轮国产GPU在软件生态上的投入跟两年前已经完全不是一个量级。这篇文章不打算写成“国产GPU全面超越”的吹捧稿那种话我们自己都不信。我想结合最近这一两年在国产卡上做迁移、部署、调优的实际经历聊聊这次突破到底“破”在哪硬件端的产品分层、软件栈从驱动到算子的补齐、真实落地时的部署流程以及从N卡切换到国产卡之后一定会踩的那几个坑。内容对准备做国产化适配的技术团队、正在评估算力选型的算法工程师还有对GPU生态感兴趣的朋友会比较有用。全程用大白话能抄作业的步骤我会尽量写清楚。1. 为什么说这是“重大突破”硬件、软件和生态的三重变化1.1 硬件分层从训练卡到推理卡都拿得出手了“国产GPU”不是一个卡而是一整排不同定位的产品线。昇腾有面向训练和推理的910系列、面向边缘的310系列海光有深算系列的DCU走的是类ROCm路线寒武纪有思元系列摩尔线程、沐曦、壁仞也都有自己的产品。以前我们聊国产GPU基本只能盯着某一两款“明星卡”看选择极少很多时候是“有啥用啥”。现在的情况是从超大集群训练、单机推理、边缘部署到图形渲染基本都能找到对应定位的卡。训练卡和推理卡的分工越来越清晰这是成熟生态的一个重要标志。训练卡追求的是高算力、高显存带宽、强互联让它能扛住大规模并行计算推理卡则更看重单位功耗下的吞吐量、延迟和性价比。昇腾910系列在训练场景的能效比已经有不少公开测试数据支撑海光DCU在科学计算和高性能计算领域有天然优势寒武纪则在大模型推理加速上有针对性设计。硬件端不再只是“有一个能用的国产GPU”而是开始形成规模化的产品矩阵。另一个容易被忽略的突破是板卡形态的多样化。PCIe插卡、OAM模组、液冷整机柜甚至面向桌面和工作站的半高卡、被动散热卡都有厂商在做。这意味着国产GPU能进数据中心也能进实验室的桌面工作站还能进信创整机。对做算力规划的人来说这种“有的选”本身就是重要进展。1.2 软件栈从“能亮机”到“能训练”硬件只是第一步真正的分水岭在软件。过去很长一段时间国产GPU被吐槽最多的就是“驱动稀烂、框架不支持、生态空白”。显卡插上去能显示桌面已经算成功想跑CUDA程序基本等于做梦。现在的局面完全变了。昇腾有CANN异构计算架构上层通过torch_npu直接对接PyTorch海光DCU走的是ROCm兼容路线DTK工具链里包含了HIP编译器很多CUDA程序改改就能跑寒武纪有Neuware摩尔线程有MUSA沐曦有MXMACA。虽然各家的生态路线不同——有人选择做CUDA兼容层降低迁移成本有人选择自建完整软件栈——但共同点是主流AI框架的适配已经不再是“有没有”的问题而是“好不好用”“性能损多少”的问题。这个转变非常关键。GPU的竞争力从来不只是芯片本身的算力而是整个软件生态的合力。CUDA之所以难以撼动不是因为它性能最好而是因为它积累了二十年的库、工具、教程和踩坑文档。国产GPU这几年的“重大突破”本质上是在这片最难的阵地上啃下了硬骨头——把软件栈从零搭起来让开发者愿意来用、用得下去。1.3 被低估的一环工具链和开发者社区硬件和软件之外还有一个很容易被忽视的维度工具链的完整度和开发者社区的活跃度。最近我在搜索资料时注意到已经有高校开设“GPU架构与编程”相关课程并且直接使用国产GPU作为教学平台。这个信号比任何发布会PPT都重要。当国产GPU进入教材、进入课堂意味着新一代开发者从一开始接触的就是国产异构计算体系而不是先学CUDA再“平迁”过来。调试工具方面各家也在快速补齐。性能分析器、内存检测工具、算子profiling工具陆续开放出来。以前遇到性能问题只能靠“猜”现在至少能拿到火焰图、算子耗时分布、显存占用曲线这些数据去定位问题。别小看这些“辅助工具”没有它们开发和调优效率会低一个数量级。也正是这些无声的基建构成了“重大突破”里最扎实的部分。2. 从驱动到算子国产GPU软件栈是怎么长出来的2.1 驱动和运行时GPU和操作系统之间的“翻译官”很多人对GPU驱动的认知停留在“装个软件让显卡能显示”但对我们这些做异构计算的人来说驱动是整套软件栈的根基。GPU驱动不只是把画面输出到显示器它还要负责显存管理、命令调度、上下文切换、中断处理以及跟计算框架的底层交互。驱动写得不好上面再好的框架也白搭。最近热词里有不少关于“gpu驱动开发”的讨论这确实是国产GPU绕不过去的一道坎。一个完整的GPU驱动栈通常包含内核态驱动KMD和用户态驱动UMD。内核态驱动负责硬件资源的分配和安全管理用户态驱动则直接跟CUDA、ROCm这类运行时库打交道。多进程场景下还需要处理好显存隔离和调度公平性否则一个进程就能把整卡资源吃干榨净导致其他任务直接崩溃。国产GPU驱动这几年的一个务实策略是做兼容层的“翻译”。既然CUDA生态根深蒂固短期内不可能让所有软件厂商都重新适配一套新标准那就让驱动和运行时在底层把CUDA的调用“翻译”成自家硬件的指令。这样用户层面感觉不到太大差异开发者原有的代码和习惯都能保留。这个思路跟当年Wine模拟Windows API的思路有些类似——不是说兼容层完美无缺而是它能在生态发展早期把迁移成本降到最低让更多人愿意先“用起来”。2.2 Kernel与算子大模型背后的“乐高积木”再说说“算子”。这个词这两年因为AI框架的火爆频繁出现在大众视野里但很多人对它的理解还比较模糊。简单说算子Kernel就是GPU上执行的一个计算函数是整个计算图的基本执行单元。卷积、矩阵乘法、归一化、注意力机制每一个AI模型训练或推理步骤最后都会被拆解成成百上千个算子在GPU上依次执行。热词里提到一个非常专业的问题“cooperative thread arrayCTA在GPU计算中是个什么概念跟warp是什么关系”。这里顺便给不太熟悉GPU编程的朋友科普一下。在NVIDIA的编程模型里warp是硬件线程调度的基本单位典型的宽度是32个线程它们在同一时刻执行同一条指令。CTA则是一个由多个warp组成的线程块是程序员可以控制的协作单位同一个CTA内的线程可以通过共享内存通信、通过同步原语协作。在国产GPU上硬件调度单位的宽度可能不是32比如AMD系是wavefront 64但“硬件调度宽度软件协作线程块”的设计思想是相通的。理解这一层再去看算子性能优化思路会清晰很多——很多时候性能瓶颈不是算力不够而是线程组织方式不合理导致并行度没有被充分挖掘。国产GPU在算子层面做了大量补课。一方面是把高频算子卷积、GEMM、FlashAttention等一个个手工调优做成高性能算子库另一方面是开发自动调优工具通过编译期搜索最佳的分块参数、向量化宽度、访存策略减轻人工优化的压力。这个过程非常像“用软件工程的方法补硬件的课”——密集、枯燥、但必须做。没有这些算子的积累模型跑起来性能可能连CPU都打不过。2.3 框架集成PyTorch、DeepMD、FunASR这些全家桶是怎么跑起来的再往上层看是AI框架的适配。以PyTorch为例国产GPU厂商的主流做法是维护一个“设备后端插件”比如昇腾的torch_npu、海光的torch_dcu或ROCm版PyTorch。这个插件的作用是让PyTorch在感知不到底层硬件差异的情况下完成算子分发、显存管理、设备同步等操作。用户代码里通常只需要把cuda换成对应的设备名或者设置一下环境变量就能在国产卡上跑起来。热词里有“deepmd-kit的gpu和cpu版本速度”“funasr部署gpu”这类具体应用问题说明国产GPU已经开始渗透到分子动力学、语音识别这类细分领域。DeepMD是一个典型的科学计算AI交叉应用对算子的精度和性能要求都很高FunASR是阿里开源的语音识别工具部署场景通常是推理服务。这些软件能在国产GPU上顺利运行并不是因为厂商一家一家去适配的而是因为PyTorch等框架层面的适配做好了框架之下的应用自然跟着迁移。这就是生态的杠杆效应。再比如ComfyUI这类AI绘画工具热词里提到“on windows we are currently forcing single gpu mode due to a nvidia”这类限制这在N卡上是一个常见约束。国产GPU在适配AI绘画应用时同样需要关注多卡协同、显存共享这类问题。好消息是目前主流AI应用基本都已有国产GPU的部署案例且社区讨论热度明显在上升。2.4 Kernel在GPU上的完整执行流程从一行代码到显存里的结果既然聊到算子和Kernel顺便把“一个Kernel在GPU上执行的全流程”完整捋一遍。很多人写代码时只看到kernelgrid, block(args)这一行却不太清楚后面发生了什么。第一步应用程序通过运行时API发起Kernel启动请求把线程栅格Grid、线程块Block尺寸和参数打包成一个启动命令。第二步用户态驱动把这个命令翻译成硬件能理解的命令格式写入一个叫“命令缓冲区”的环形队列然后通过系统调用通知内核态驱动。第三步GPU前端处理器从环形队列取命令解析后将任务分发给后端的计算单元。第四步计算单元内部的线程调度器按硬件调度宽度warp或wavefront把线程块分发到各个执行引擎。第五步是真正的计算每个线程执行自己的那部分指令访存、计算、同步。执行完后再通过中断或轮询的方式通知CPU“我干完了”CPU端的事件同步机制解除阻塞整个调用返回。理解这个流程对排查很多莫名其妙的报错非常有帮助。比如“程序卡死”可能是命令队列堵塞也可能是显存访问越界导致设备侧hang住“crash dump triggered”这类问题往往不是代码语法错误而是Kernel执行中触碰了非法地址或触发了硬件看门狗。调试这类问题常规思路是缩小问题范围——先用空Kernel排除启动链路再逐层增加复杂度定位到具体算子。3. 一次真实迁移麒麟V10海光GPU装PyTorch的全流程3.1 动手前先确认机器上到底有什么卡理论聊再多不如一次实操来得实在。这一节我完整记录一次在麒麟系统V10上给海光DCU装PyTorch的过程希望能给正在做国产化迁移的朋友提供一份可以直接参考的记录。第一步永远是确认硬件和系统环境。用lspci | grep -i processing或者lspci | grep -i accelerator看PCIe设备列表确认系统实际识别到的显卡型号。有些机器可能同时插着N卡和国产卡这种情况下要特别注意默认设备的选择后续驱动的安装和环境的配置都要确保针对正确的目标卡。系统方面麒麟V10基于Linux内核操作习惯跟Ubuntu、CentOS比较接近但包管理器的源和部分依赖库的位置会有差异不能完全照搬通用教程。推荐的硬性条件检查项包括内核版本是否符合驱动要求、是否已安装基础的编译工具链gcc、make、Secure Boot是否关闭、BIOS里的Above 4G Decoding和Resizable BAR是否开启。这些配置对GPU的显存映射和DMA访问有直接影响很多人装完驱动后性能不对回头查才发现是BIOS里这几个开关没打开。3.2 装驱动和DTK比想象中省事但有几个开关必须开对海光DCU的软件栈核心是DTKDCU Toolkit安装方式一般是先装驱动再装DTK。驱动方面海光提供了适配麒麟系统的安装包流程跟装NVIDIA驱动类似解压、执行安装脚本、重启。实际的坑在于依赖库。麒麟系统的包管理器里可能缺少某些开发库安装前最好先把kernel-devel、dkms等组件装好并且确认内核头文件版本跟当前内核完全一致否则驱动模块编译会失败或者加载时报版本不匹配。DTK装完后关键一步是设置环境变量。DTK_HOME、PATH、LD_LIBRARY_PATH这些都需要正确指向DTK的安装目录。HIP是海光DCU的编程模型基础跟NVIDIA CUDA非常相似所以编译代码时可以用hipcc作为编译器也可以直接用支持HIP的nvcc兼容方案。有一点必须注意不同版本的海光DCU硬件可能需要不同版本的DTK两者有对应关系表装错版本就会出现“identify device failed”之类的怪问题。注意驱动安装前建议先看官方文档里的内核适配列表。麒麟V10的版本号很多不同小版本的内核配置可能差异巨大。图省事直接强装大概率会收获一个“驱动已安装但无法加载”的烂摊子。3.3 装PyTorch并验证看到True的一瞬间才算真正落地接下来就是PyTorch的安装了。海光的PyTorch适配版支持通过pip/conda直接安装也可以基于源码自行编译。如果你是第一次接触强烈建议先用官方编译好的wheel包跑通流程不要一上来就挑战源码编译——编译耗时几小时不说过程中还容易因为依赖库版本冲突而卡住对排查问题没经验的人来说非常劝退。安装完成后验证代码只有一行import torch print(torch.cuda.is_available()) # 这里需要确认海光DCU在PyTorch中暴露的设备名不同版本的海光PyTorch适配设备名的设置方式有差异有的通过环境变量HIP_VISIBLE_DEVICES控制可见设备有的沿用CUDA_VISIBLE_DEVICES的兼容逻辑。如果你在代码里用的是.cuda()大概率没问题如果是手动指定设备类型一定要先确认文档中当前PyTorch版本支持的设备名写法。当is_available()返回True的那一瞬间“国产GPU也能跑PyTorch”从口号变成了现实。但验证不该止步于True。建议再跑一个真实模型比如用ResNet50或一个小规模的BERT做推理确认输出结果正常、耗时合理。这能暴露很多“环境能加载但实际计算链路有问题”的情况比如算子没有真正落到DCU上执行、而是在CPU上兜底跑了这种问题从is_available()是看不出来的。3.4 跑通之后别忘了查性能别只用“能跑”安慰自己“能跑”和“好用”之间的差距往往体现在性能数据上。迁移完成之后至少要做一个基准测试。如果之前在同规格N卡上有过相同模型的数据做个对照就很有价值。性能对照通常看三个指标端到端的推理耗时或训练吞吐、算子的执行时间分布、显存占用和访存带宽。拿到profiling数据后重点关注耗时占比最高的几个算子看看它们的实现是否走了优化路径。比如矩阵乘法是否调用了高度优化的GEMM库而不是落回到naive实现注意力计算是否使用了显存友好的分块策略而不是把整个注意力矩阵都驻留在显存里。这个环节的经验是国产GPU的峰值算力其实不低但实际利用率经常取决于算子库的匹配程度。遇到性能不理想时先检查算子是否走对实现再考虑是不是驱动或调度层面出了问题不要一上来就怪硬件不行。4. 常见报错速查从N卡切到国产卡最容易踩的坑4.1 一张表看懂高频报错迁移过程中总会遇到报错。有些是环境没配对有些是硬件特性差异导致还有些是驱动栈的位置问题。我把最近两年在社区里高频出现的GPU相关报错和排查思路整理成一张表虽然很多报错的原始文本来自N卡驱动的输出但排查思路对国产GPU同样适用。报错/现象常见原因排查方向Error code 43设备状态异常驱动与硬件通信失败查驱动版本是否匹配、供电是否不足、BIOS设置、dmesg日志Xid 79: GPU has fallen off the busPCIe链路异常板卡掉线查物理插槽接触、供电稳定、PCIe速率协商是否降级GPU crash dump triggeredKernel执行中触发异常或看门狗超时缩小到具体算子检查显存越界、同步逻辑、驱动bugCompute capability not compatible编译产物与硬件算力不匹配重新编译并指定正确的算力参数或下载匹配版本的wheelGPU not support acceleration浏览器或应用层判断设备能力失败检查GPU驱动是否正常加载、显存是否充足、硬件加速开关配额/资源不足K8s场景集群GPU资源分配策略限制检查Device Plugin上报资源、确认SQL配额、优化分片策略表格之外多说一句很多国产GPU用户遇到报错时第一反应是“这卡不行还是换回N卡吧”。但实际排查下来相当大比例的“不行”其实跟硬件无关——要么是驱动和硬件版本号的对应关系搞错了要么是程序里写死了NVIDIA特有的API调用要么是编译时算力参数指定错误。建议迁移前先做一轮代码层面的体检把所有硬编码的CUDA假设替换成可配置项再用最小用例逐步验证。4.2 资源调度和显存分配多卡、虚拟化、K8s里的实际教训聊完单个卡的报错再说说集群层面的问题。热词里“hami gpu 虚拟化”“k8s调用gpu”“gpu计算资源分配”“gpu租用”都是云原生环境下的高频话题。国产GPU在集群场景的适配这几年进步明显但坑也不少。K8s调度GPU依赖Device Plugin机制。NVIDIA官方有成熟的插件国产GPU厂商也各自维护自己的Device Plugin。但这里有个实际风险如果你同时用不同厂商的卡混部Device Plugin之间的资源报告可能互相冲突调度器会拿到两份“显卡”资源导致分配的卡跟实际使用的卡不一致。所以我们组的经验是要么物理隔离分池要么通过节点标签做强约束绝对不要让调度器在同一个节点上跨厂商分配GPU。虚拟化方面HAMI这类GPU虚拟化方案解决的是“一张卡怎么切成多份分给不同任务”的问题。国产GPU的虚拟化能力正在快速追赶显存隔离、计算切片、优先级调度这些功能逐渐补齐。但要注意虚拟化通常会带来几个百分点的性能损耗而且对显存占用波动大、频率高的任务隔离效果需要实测验证。GPU租用服务方在选择底层卡型时也要评估好超卖比例——超卖太多会导致延迟毛刺严重用户侧体验很差。5. 弄完这一圈说说我的真实体会这一轮体验下来我的结论是国产GPU的突破是真的在发生但它更像是“持续补课后的量变积累”而不是某个早晨突然出现的质变奇迹。硬件层面的产品矩阵越来越完整软件栈从驱动、运行时到算子库、框架适配逐步打通真实业务场景的部署案例越来越多这些都是可以触摸到的变化。当然不足和差距也依然存在。生态迁移的成本客观存在不是所有软件都能无痛跑在国产卡上大模型训练场景的稳定性和互联性能还需要更多真实集群数据验证工具链的完善度和社区内容的丰富度距离CUDA生态还有明显差距。这些都是同行在做技术选型时应该理性看待的。如果让我给准备迁移到国产GPU的团队一句话建议那就是控制节奏、稳步验证。先选一个小而完整的业务跑通全链路再逐步扩大范围。迁移过程中驱动版本是个“玄学”般的高频坑源方案是先固定一个官方确认过的组合不要随手升级遇到莫名报错养成先看dmesg、再看应用日志的习惯能省掉很多本可以避免的瞎折腾。国产GPU这条路还有很长的路要走但至少现在我们可以在上面认真跑起模型、讨论问题、沉淀经验而不是对着“即将发布”的PPT望洋兴叹。这就是我认为最有分量的“突破”。