国产GPU适配实战——五款二线主流AI加速卡深度评测

文章目录


前言

近期正在做国产卡的适配工作,前些天做了一些调研,并写了一篇:主流国产显卡调研报告

最近几天把能租到的卡都给实际验证了遍,于是写下这篇文章,分享适配经验,为后续选用国产卡的开发者提供参考。

首先,昇腾毋庸置疑国产第一梯队了,网上能找到的资源非常多,如果不知道选什么卡的,直接选昇腾就可以了,本文主要针对除昇腾以外的其它二线国产卡。

一、海光 DCU K100_AI —— 适配体验最佳

硬件规格

型号显存INT8 OPsFP16/BF16 FLOPsTF32FP32 FLOPs显存带宽PCIe 接口功耗
K100 AI版64GB392T196T96T49T896GB/s5.0×16350W
K10064GB200T100T-24.5T896GB/s4.0×16300W

生态资源

从生态包下载地址可以获取驱动、Python包、工具包等所有必需资源,资源丰富且组织清晰。

在这里插入图片描述

租用渠道

可以从超算互联网租到海光 K100_AI 显卡: https://www.scnet.cn/ui/mall/search/resource

在这里插入图片描述

适配体验

⭐ 最大亮点:对CUDA无缝兼容

海光K100_AI的整个使用过程十分顺畅。我们使用Qwen3-0.6B对其进行了验证,未遇到任何问题。更令人惊喜的是,它对CUDA实现了无缝兼容,不需要修改任何代码即可从NVIDIA GPU迁移过来。

在这里插入图片描述
在这里插入图片描述

这意味着:

  • ✅ 不需要像昇腾那样将 x.cuda() 改成 x.npu()
  • ✅ 现有的PyTorch代码可以直接运行
  • ✅ 迁移成本几乎为零

ONNX适配

对于ONNX Runtime,需要做少量适配,主要是添加对应的ExecutionProvider:

defselect_device():""" 选择可用的计算设备,优先级:NPU > 燧原GCU > DCU > CUDA > CPU 返回对应的 ONNX Runtime providers 列表 """ available_providers = ort.get_available_providers() logger.info(f"可用的计算设备: {available_providers}")# 优先使用昇腾NPU (CANN)if'CANNExecutionProvider'in available_providers: logger.info("使用昇腾NPU设备 (CANNExecutionProvider)")return['CANNExecutionProvider','CPUExecutionProvider']# 其次使用燧原GCUif'TopsInferenceExecutionProvider'in available_providers: logger.info("使用燧原GCU设备 (TopsInferenceExecutionProvider)")return['TopsInferenceExecutionProvider','CPUExecutionProvider']# 然后使用AMD GPU / 海光DCU (MIGraphX优先,ROCm备选)if'MIGraphXExecutionProvider'in available_providers: logger.info("使用AMD GPU/海光DCU设备 (MIGraphXExecutionProvider)")return['MIGraphXExecutionProvider','ROCMExecutionProvider','CPUExecutionProvider']if'ROCMExecutionProvider'in available_providers: logger.info("使用AMD GPU/海光DCU设备 (ROCMExecutionProvider)")return['ROCMExecutionProvider','CPUExecutionProvider']# 然后使用CUDAif'CUDAExecutionProvider'in available_providers: logger.info("使用CUDA设备 (CUDAExecutionProvider)")return['CUDAExecutionProvider','CPUExecutionProvider']# 默认使用CPU logger.info("使用CPU设备 (CPUExecutionProvider)")return['CPUExecutionProvider']

综合评价

海光DCU的适配速度甚至比昇腾还快,这得益于:

  1. 完善的文档和生态资源
  2. 对CUDA的无缝兼容
  3. 活跃的开发者社区支持
  4. 丰富的工具链支持(如Ctranslate2)

二、寒武纪 MLU370-M8 —— 需要技术支持

硬件规格

型号显存INT4 OPsINT8 OPsINT16 OPsFP16/BF16 FLOPsFP32 FLOPs显存带宽功耗
MLU59096GB HBM2e-628T-314T-2.76 TB/s-
MLU370-S4/S824GB/48GB LPDDR5384T192T96T72T18T307.2 GB/s75W
MLU370-X424GB LPDDR5512T256T128T96T24T307.2 GB/s150W
MLU370-X848GB LPDDR5512T256T128T96T24T614.4 GB/s250W

生态资源

获取方式

从网上没找到公开的租用渠道。我们通过销售帮助,使用企业邮箱免费申请了一台 MLU370-M8 进行测试。

在这里插入图片描述

适配方式

寒武纪的适配方式与昇腾类似,需要将 x.cuda() 改成 x.mlu():

defselect_device():""" 选择可用的计算设备,优先级:NPU > MLU > GCU > MUSA > CUDA > CPU """# 尝试使用昇腾NPUtry: spec = importlib.util.find_spec('torch_npu')if spec isnotNone:import torch_npu from torch_npu.contrib import transfer_to_npu torch.npu.set_compile_mode(jit_compile=False) torch.npu.config.allow_internal_format =Falseif torch_npu.npu.is_available(): logger.info("使用昇腾NPU设备")return"npu"except Exception as e: logger.warning(f"初始化NPU设备失败: {e}")# 尝试使用寒武纪MLUtry: spec = importlib.util.find_spec('torch_mlu')if spec isnotNone:import torch_mlu if torch.mlu.is_available(): logger.info("使用寒武纪MLU设备")return"mlu"except Exception as e: logger.warning(f"初始化MLU设备失败: {e}")# 尝试使用燧原GCUtry: spec = importlib.util.find_spec('torch_gcu')if spec isnotNone:import torch_gcu if torch.gcu.is_available(): logger.info("使用燧原GCU设备")return"gcu"except Exception as e: logger.warning(f"初始化GCU设备失败: {e}")# 尝试使用摩尔线程MUSAtry: spec = importlib.util.find_spec('torch_musa')if spec isnotNone:import torch_musa if torch.musa.is_available(): logger.info("使用摩尔线程MUSA设备")return"musa"except Exception as e: logger.warning(f"初始化MUSA设备失败: {e}")# 尝试使用CUDAtry:if torch.cuda.is_available(): logger.info("使用CUDA设备")return"cuda"except Exception as e: logger.warning(f"初始化CUDA设备失败: {e}") logger.info("使用CPU设备")return"cpu"

遇到的问题

由于测试的MLU370-M8显卡较老,对大模型的支持不够完善:

  1. 不支持Qwen3系列模型
  2. 支持Qwen2.5系列,但需要使用float16类型(不支持bf16)

启动命令示例:

vllm serve ./Qwen2.5-0.5B-Instruct --served-model-name qwen --port 9000 --dtype float16 
在这里插入图片描述

ONNX支持

对于ONNX的适配,我们没有找到相关的直接支持。只看到有一个MagicMind可以解析ONNX模型,但没有找到使用ONNX Runtime直接推理的相关资料。

重要提醒

⚠️ 寒武纪的适配过程遇到了不少挑战:

  1. 开发者社区响应慢: 遇到问题基本没人帮你解决,都是让你找供应商要镜像
  2. 环境依赖镜像: 拿到的镜像没问题,适配会很快;反之会相当困难
  3. 缺少公开资源: 寒武纪没有公开那些适配好的torch包
  4. 网上资料有限: 即使网上有一些教程,但前提都是你能拿到可用的镜像

结论: 没有寒武纪官方技术支持的情况下,不建议独立使用。


三、沐曦 C500 —— 资源丰富的后起之秀

硬件规格

型号显存INT8 OPsFP16/BF16 FLOPsFP32 FLOPs显存带宽功耗
曦思 N10016GB160T80T---
曦云 C50064GB HBM2e560T280T36T1.8TB/s450W

生态资源

资源下载站点内容挺全,包含Python包、驱动等,类似海光,甚至比海光的资源更容易找一些。

租用渠道

可以从Gitee AI算力平台租用: https://ai.gitee.com/compute

在这里插入图片描述

适配体验

与海光类似,对CUDA无缝兼容,不需要修改代码。大模型验证过程十分顺畅。

在这里插入图片描述

ONNX支持

当时测试时没找到兼容的ONNX Runtime,但现在官网已经更新了相关的包。可以通过打印支持的ONNX provider,基于 select_device 函数简单修改即可兼容。

在这里插入图片描述


下载后直接通过wheel安装即可

增加以下判断即可适配:

# 然后使用沐曦MACAif'MACAExecutionProvider'in available_providers: logger.info("使用沐曦GPU设备 (MACAExecutionProvider)")return['MACAExecutionProvider','CPUExecutionProvider']

与海光的对比

虽然沐曦在很多方面表现不错,但相比海光仍有差距:

对比项海光DCU沐曦C500
CUDA兼容✅ 完美✅ 完美
生态工具✅ 支持Ctranslate2❌ 不支持Ctranslate2
社区维护✅ 有专人解答❌ 论坛无人维护
资源获取✅ 容易✅ 容易

结论: 整体而言,海光优于沐曦,但沐曦也是一个不错的选择。


四、摩尔线程 S4000 —— 环境配置较复杂

硬件规格

型号显存核心数INT8 FLOPsFP16/BF16 FLOPsFP32 FLOPs显存带宽功耗
MTT S400048GB GDDR6-200T100T-768 GB/s450W
MTT S300032GB GDDR64096--15.5T448 GB/s-
MTT S200032GB4096--10.4T-150W

生态资源

论坛接入的是ZEEKLOG论坛,基本无人维护。

租用渠道

可以从AutoDL租用摩尔线程S4000: https://www.autodl.com/market/list

在这里插入图片描述
在这里插入图片描述

适配方式

使用时需要将 x.cuda() 换成 x.musa() 即可。

综合评价

整体相比沐曦、海光差距较大:

  • ❌ 环境不好配置
  • ❌ 兼容性不如海光
  • ❌ 文档和社区支持较弱

五、燧原 S60 —— 大模型推理表现良好

硬件规格

型号显存INT8 OPsFP16/BF16 FLOPsTF32 OPsFP32 FLOPs显存带宽功耗
S6048GB-392T--672 GB/s-
云燧i20-256T-128T---

生态资源

租用渠道

可以从Gitee AI算力平台租用: https://ai.gitee.com/compute

在这里插入图片描述


在这里插入图片描述

适配体验

大模型推理: 用于大模型推理时十分顺畅,没有遇到任何阻碍。

小模型推理: 遇到了一些问题,主要是ONNX相关的包安装困难。

存在的问题

  1. 没有开发者论坛
  2. 官网信息有限: 除了镜像外,找不到其他信息
  3. 自行安装包困难: 文档比摩尔线程还要少
  4. ONNX支持不明确: 没找到具体的安装和使用方法

总结

根据我的实战经验,适配难易程度从易到难排序为:

🥇 海光 K100_AI > 🥈 沐曦 C500 > 🥉 摩尔线程 S4000 > 燧原 S60 > 寒武纪 MLU370-M8

个人觉得海光K100_AI适配要比昇腾还容易,昇腾主要的问题是显卡型号多,名字不统一,文档烂,看的人云里雾里,并且需要修改代码才能适配,海光环境搞好后,除了onnx需要修改下代码,其它地方基本无缝兼容。

最后想说的是,这些国产显卡,各家软件生态互不兼容,没有统一的软件框架,是很难真正替代英伟达的,好在已经看到有类似的工作正在做了:https://github.com/flagos-ai

鼓励大家去给项目点波 Star 支持一下。

FlagOS 是一个统一的开源人工智能系统软件栈,专为多芯片场景设计。它由十多家国内外机构联合发起成立,包括芯片公司、系统制造商、算法及软件相关实体、非营利组织和研究机构。
针对多样化人工智能芯片应用中的核心痛点,FlagOS 构建了一个全面的系统软件生态系统,有望打破不同芯片软件栈之间的生态壁垒,有效降低开发者的迁移成本。

相关资源汇总

GPU厂商文档中心开发者社区租用平台
海光DCUdeveloper.sourcefind.cndeveloper.sourcefind.cn超算互联网
寒武纪MLU-developer.cambricon.com需联系销售
沐曦developer.metax-tech.com/softnova-Gitee AI
摩尔线程docs.mthreads.comblog.mthreads.comAutoDL
燧原support.enflame-tech.com--

注: 本文写作时利用了AI基于初稿整理,所有内容经过人工审查。

Read more

Flutter 三方库 shelf_cors_headers 的鸿蒙化适配指南 - 实现具备跨域安全访问策略的服务端拦截器、支持端侧微服务网关与分布式请求治理实战

Flutter 三方库 shelf_cors_headers 的鸿蒙化适配指南 - 实现具备跨域安全访问策略的服务端拦截器、支持端侧微服务网关与分布式请求治理实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 shelf_cors_headers 的鸿蒙化适配指南 - 实现具备跨域安全访问策略的服务端拦截器、支持端侧微服务网关与分布式请求治理实战 前言 在进行 Flutter for OpenHarmony 的桌面端辅助开发或基于 shelf 的嵌入式轻量级服务器开发时,如何解决不同起源(Origin)请求带来的跨域(CORS)限制?尤其是在构建用于管理鸿蒙本地资源的数据面板时,跨域策略是确保浏览器或 App 能够安全访问本地 HTTP 服务的基础。shelf_cors_headers 是专为 shelf 服务器设计的中间件。本文将探讨如何在鸿蒙端构建极致、安全的请求治理层。 一、原直观解析 / 概念介绍 1.1 基础原理 该中间件作为 shelf 处理链条中的一个“

By Ne0inhk
【MySQL】数据库的 “红绿灯”:非空、主键、外键到底管什么?

【MySQL】数据库的 “红绿灯”:非空、主键、外键到底管什么?

表的约束:表中一定要有各种约束,通过各种约束,保证未来数据库中的数据的准确的;约束的本质是:通过技术手段倒逼程序员,插入正确的数据,进而保证数据库中的数据的正确的; 一、非空约束 两个值:null(默认的)和not null(不为空) 数据库默认字段基本都是字段为空,但是实际开发时,尽可能保证字段不为空,因为数据为空没办法参与运算。 null Vs ''  null : 表示什么都没有; '' :有,但是为空; 二、default 约束 default : 跟 C++ 的缺省值一样; not null  and default: 注意:如果我们的表中没有设置 default 和 not null 约束,他默认 default

By Ne0inhk
Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构

Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构 前言 在鸿蒙(OpenHarmony)生态迈向政务办公、智慧医疗及大型企业级管理系统等重定义表单交互的背景下,如何实现高度解耦的表单校验逻辑、提升超长表单的录入效率,已成为决定应用用户体验(UX)的“核心命门”。在鸿蒙设备这类强调分布式协同与流畅性能(Fluidity)的终端上,如果表单逻辑依然堆砌在 UI 层的 setState 之中,由于由于复杂的字段联级校验与高频的视图重绘,极易由于由于主线程阻塞导致虚拟键盘弹出时的严重掉帧。 我们需要一种能够实现逻辑与视图彻底分离、支持基于流(Stream)的状态监控且具备严密规则校验能力的表单治理框架。 lyform 为 Flutter 开发者引入了基于 BLoC 模式的高阶表单管理方案。它将每一个输入字段抽象为独立的 InputBloc,并由 FormBloc 进行全局状态统筹。在适配到

By Ne0inhk
SpringBoot + Vue 前后端分离项目实战:权限 + 工作流 + 报表

SpringBoot + Vue 前后端分离项目实战:权限 + 工作流 + 报表

✨道路是曲折的,前途是光明的! 📝 专注C/C++、Linux编程与人工智能领域,分享学习笔记! 🌟 感谢各位小伙伴的长期陪伴与支持,欢迎文末添加好友一起交流! 📚 目录 * 前言 * 一、项目背景与技术选型 * 二、系统架构设计 * 三、权限管理模块 * 四、工作流引擎集成 * 五、报表系统实现 * 六、核心代码实现 * 七、部署与运维 * 八、总结 前言 前后端分离架构已成为企业级应用开发的主流选择。本文将通过一个完整的企业管理系统实战项目,详细介绍如何使用 SpringBoot + Vue 技术栈,实现权限管理、工作流引擎和报表系统三大核心功能。 项目特色 * 前后端分离:RESTful API 设计,便于扩展和维护 * RBAC权限模型:细粒度的权限控制体系 * Flowable工作流:可视化流程设计与执行 * 动态报表:灵活配置的数据可视化方案 一、项目背景与技术选型 1.

By Ne0inhk