国产 AI 卡推理引擎工程对标调研（C++ CUDA + TensorRT → 国产栈）

国产 AI 卡推理引擎工程对标调研（C++ CUDA + TensorRT → 国产栈）

调研日期：2026-10-15　|　视角：C++ CUDA + TensorRT，含自定义 TensorRT Plugin 与自定义预处理/后处理 CUDA Kernel，YOLOv5/v8 在线检测，多路视频 + 大 batch

证据分级说明

• 【官方文档】= 厂商官网/开发者站点原页（本文已 HEAD 验证可达的标注"已验证可达"）
• 【社区实测】= CSDN / 掘金 / 技术博客，署名个人实践
• 【媒体转述】= 财经媒体转述的公司稿、券商研报解读、发布会报道
• 【未验证】= 二手来源提到但未能在官方源交叉确认

⚠️ 首要警告：中文互联网"迁移实战"内容污染严重

本次检索发现，相当比例标称"国产芯片迁移实战"的中文内容疑似 LLM 批量生成且含硬性事实错误。典型例证：

• 百度智能云《国产 AI 芯片与 PyTorch 生态融合》称昇腾"节点内通过 NVLink 模拟实现零拷贝通信"------昇腾无 NVLink，此为编造
• 同文称壁仞 PyTorch 插件源码在 GitHub: birensai/PyTorch-BR100，未找到该仓库
• 同文称华为通过 PyTorch-CANN 插件 将 conv2d 转为"达芬奇架构指令"，无此插件名
• CSDN《信创及国产化集成开发·昆仑芯适配》整篇为高度公式化结构，含大量无法交叉验证的性能断言（"vLLM 在昆仑芯仅 A100 ~60%"）

报告引用时必须逐条甄别，上述来源本报告均不采信其事实断言。

---

关键结论速览

路径判定（能否复用原 CUDA kernel）

定义：

• 路径 A = 源码级兼容，换编译器 / 少量宏即可编译
• 路径 B = API 级兼容，需改写调用但保留算法结构与优化思路
• 路径 C = 全量重写，须适应对方编程模型 / DSL

平台	路径判定	一句话理由
海光 DCU (HIP)	A→B	唯一真正的源码级迁移路径；hipify-clang 自动转换，同步原语/内建变量同名
沐曦 MACA	B（官方未背书，风险高）	官方口径仅"API 层面兼容 CUDA"；自研指令集；PyTorch 侧走 ONNX Runtime EP 而非 CUDA EP
摩尔线程 MUSA	B	torch_musa 后端字符串切换 + musaCC；MUSA Graph 声称接口兼容 CUDA Graph
天数智芯	B	IxDNN/IxRT + CUDA 兼容层；同为 GPGPU 路线，但无 kernel 级公开兼容承诺
昆仑芯	B 的语法外壳 / C 的实质	社区称"类 CUDA 三段式 <<<>>>"，但为自研指令集 + XPU 编程模型
昇腾 CANN	C	Ascend C 是 C++，但内存模型与执行模型完全不同；<<<>>>/__global__ 仅为语法外观
寒武纪 BANG C	C	C/C++ 扩展 + MLU 专属 DSL（tensor 描述符、NRAM/VRAM 分区）
壁仞 BIRENSUPA	C	媒体实测反馈需改底层 IR 代码
燧原 TopsRider	未验证	未找到公开的 kernel 级开发入口文档

对用户场景的直接含义

用户存量资产 = ①TensorRT Plugin（IPluginCreator + IPluginV2DynamicExt + enqueue() 内调 CUDA kernel）+ ②自定义预处理/后处理 CUDA kernel + ③.plan engine。

这三样东西在除海光 DCU 外的所有平台上都没有等价物。具体地：

• .plan engine 序列化机制 ：全平台均无等价物。昇腾是 .om（ATC 离线编译）、寒武纪是 .mm/torch_mlu（在线编译图）、沐曦是 ONNX 走 MacaEP、天数智芯是 IxRT engine。engine 加载→自定义 kernel 绑定这条链路全部需要重建。
• IPluginCreator / IPluginFactory 注册表模式 ：昇腾对应 ATC 的自定义算子描述文件（--singleop）+ 算子工程（msopgen/msopst）；沐曦有最接近的对应物 ------MacaRT 支持用户自定义非官方 ONNX 算子库，注册到 SessionOptions，官方文档明写"3.5. 自定义算子"。
• 预/后处理 CUDA kernel ：这是 CUDA kernel 复用问题的真正落点。海光 DCU 上可 hipify 后复用；昇腾需用 AIPP（把颜色空间转换、归一化、Crop/Padding 固化为配置文件，这是唯一官方提供的"免写代码"预处理路径）或重写 Ascend C；寒武纪需 BANG C/Triton 重写。

一处需要纠正的技术细节

用户原始需求写的 atc --framework=onnx，实际官方取值为 --framework=5（0=Caffe / 1=MindSpore / 3=TensorFlow / 5=ONNX）。多个独立来源一致确认 5 代表 ONNX。

---

1. 华为昇腾 CANN

1.1 推理引擎对标 TensorRT

结论：无 TensorRT 等价物，但存在能力对位物，概念映射不成立。

TensorRT 的核心抽象在昇腾侧的对应关系：

TensorRT 概念	昇腾对应物	性质
IBuilder / buildSerializedNetwork()	atc 命令行离线编译	形态不同：TensorRT 可 C++ 运行时编译，ATC 是纯离线命令行
IExecutionContext（动态 shape / binding 复用）	aclrtStream + aclrtExec 显式 mode；或 aclnn 算子 API	非等价 。ATC 离线固化图，动态能力靠 --dynamic_batch_size / --dynamic_dims 等编译期开关，不是运行时 context 级别的
IPluginFactory / IPluginRegistry（全局按名注册）	自定义算子工程（msopgen 创建 → 编译 → msopst ST 测试）	非等价 ：ATC 用 --singleop + 单算子描述文件，无运行时全局注册表
.plan engine 序列化 + 反序列化	.om 离线模型文件	语义不同 ：.plan 是绑定特定 GPU 架构的编译产物；.om 需 --soc_version 指定芯片型号
INetworkDefinition 层融合 / kernel 自动选优	ATC 内置图优化 + --fusion_switch_file / --precision_mode / AOE	能力对位
TensorRT FP16/INT8 QAT 对接	--precision_mode / --allow_hf32 / --keep_dtype	能力对位
CUDA Graph（隐式在 TensorRT backend 内）	未找到直接对标	未验证

关键架构差异：昇腾是 AICore + AICPU 异构 ，部分算子会自动落到 AICPU（CPU）执行。CANN 文档目录中有「开启 AI CPU Cast 算子自动插入特性」条目------这意味着某些算子会静默降级到 CPU 执行，是性能塌陷的隐藏来源，迁移时必须显式排查。

1.2 转换流程

【社区实测】ATC 命令行（昇腾社区 / 多个独立 CSDN 来源一致）：

atc --model=mogface.onnx --framework=5 \
    --output=mogface \
    --soc_version=Ascend310P3 \
    --input_format=NCHW \
    --input_shape="input:1,3,-1,-1" \
    --log=info

YOLOv8 静态化版本（【社区实测】）：

atc --model=modified_yolov8_static.onnx \
    --framework=5 \
    --output=yolov8_ascend_static \
    --soc_version=Ascend310B4 \
    --input_shape="images:1,3,640,640" \
    --insert_op_conf=./yolov8_static_aipp.cfg \
    --input_format=NCHW \
    --log=info

【官方文档】CANN 商用版 8.0.RC1 开发文档目录列出的 ATC 完整参数分类（已验证可达）：

• 输入选项：--model --weight --om --framework --input_format --input_shape --input_shape_range --dynamic_batch_size --dynamic_image_size --dynamic_dims --singleop
• 输出选项：--output --output_type --check_report --json
• 目标芯片：--soc_version --core_type --aicore_num --virtual_type
• 功能配置：--out_nodes --insert_op_conf --external_weight --op_name_map
• 算子调优：--precision_mode --precision_mode_v2 --op_select_implmode --optypelist_for_implmode --keep_dtype --customize_dtypes
• 调试：--dump_mode --log --debug_dir --op_debug_level --op_debug_config --display_model_info

ONNX opset 支持度 ：未找到官方明确的 opset 版本上下限声明。社区实践普遍用 opset 11~12 ，理由是更高 opset 会引入 ConstantOfShape 等 ATC 不支持的动态算子。→ 报告应写"未找到官方 opset 声明，社区实践用 11--12"。

1.3 自定义算子开发方式

【官方文档｜已验证可达】Ascend C（CANN 8.0.RC2.alpha002 社区版开发文档）：

• 语言：C/C++（官方称"原生支持 C 和 C++ 标准规范"）
• 核函数签名 ：extern "C" global aicore void add_custom(GM_ADDR x, GM_ADDR y, GM_ADDR z)
  • __global__ 标识核函数；__aicore__ 标识在 AI Core 上执行；__gm__ 标识 Global Memory 指针；GM_ADDR = gm uint8_t*
• 调用语法 ：hello_world<<<blockDim, nullptr, stream>>>() ------ 与 CUDA 的 <<<>>> 写法一致
• 核心接口 ：DataCopy（数据搬移）、Add（矢量双目指令）、AllocTensor/FreeTensor（内存管理）、EnQue/DeQue（Queue 队列同步）
• 头文件 ：#include "kernel_operator.h"，using namespace AscendC;
• CPU 侧调试 ：ICPU_RUN_KF 宏（官方称"孪生调试，CPU 侧模拟 NPU 侧行为"）------这是相对 CUDA compute-sanitizer 的体验优势
• 支持产品型号（文档原文）：Atlas 推理系列产品、Atlas 训练系列产品、Atlas A2 训练系列产品、Atlas 200/500 A2 推理产品
• 工程结构 ：CMakeLists.txt + Kernel 实现 + main + run.sh 一键编译运行

同族的 AICPU 算子开发 （用户提到的 opadvise）属另一条路径：TBE / AI CPU 算子开发，用 C++ 写在通用 CPU 上，是算子确实不适合 AI Core 时的兜底。→ 性能远低于 AI Core。

1.4 原 CUDA kernel 可复用程度：路径 C（全量重写）

判定依据（官方文档实证）：

Ascend C 保留了 C++ 语法外观，但内存模型与执行模型完全不同：

维度	CUDA	Ascend C
线程模型	warp（32 线程），threadIdx/blockIdx/blockDim	无 warp 概念 ；blockDim 语义是"参与运算的核数"（官方样例 blockDim = 8 即 8 个核）
存储层级	Global / Shared / Register	Global Memory → Local Memory（LocalTensor）→ AI Core 内部存储
显式搬运	不需要（编译器/缓存处理）	必须显式 DataCopy，Global↔Local 是强制步骤
计算单元	SM 内统一	Cube / Vector / Scalar 单元分离，需分别映射
同步原语	__syncthreads() / warp shuffle	EnQue/DeQue Queue 队列，无对应 shuffle
SIMT	是	__global__/__device__/__shared__ 关键字名相同但语义已变

→ 原 CUDA kernel 中任何依赖 threadIdx 索引、warp 内 shuffle、寄存器数组、隐式缓存行为的部分全部失效，必须按"拷贝进 Local → 分块计算 → 拷贝出"重写。

对用户具体场景 ：预处理/后处理 kernel 通常是逐像素/逐 box 的向量运算，在 Ascend C 里属于 Vector 单元 + Local Memory 编排 的典型任务，理论上可用 Vector 指令重写后性能可接受（比 AOE 调优更可控）。但 TensorRT Plugin 的 enqueue() 封装逻辑（tensor binding、stream 管理、序列化）需完全重建。

迁移成本参考：【社区实测】给出"昇腾 ~60 人天（CUDA → 重写算子(Ascend C) → torch_npu 适配）"，此为中等规模项目的估算，非本场景实测，仅供量级参考。

1.5 工具链与调试能力

【官方文档】开发工具矩阵（已验证可达）：

工具	用途	对标 NVIDIA
npu-smi	设备监控	nvidia-smi
msprof	算子上板调优 + 算子仿真调优	nsys / ncu
msdebug	上板调试算子，行断点、打印内存与变量、核切换	compute-sanitizer + 调试器
mssanitizer	内存检测、竞争检测	compute-sanitizer（memcheck / racecheck）
mskpp	指令性能建模（计算类/搬运类指令）	无直接对标，偏 ncu 指令级
msopgen	创建、编译和部署算子工程	无（工程脚手架）
msopst	ST 测试，生成单算子上板测试框架	无
opadvise	算子调优建议	无直接对标
AOE（Ascend RC）	自动调优（DNN 训练类模型为主）	无直接对标
MindStudio	IDE	Nsight Systems
MindIE	推理引擎（较新）	TensorRT
HCCL	集合通信	NCCL

【社区实测】某第三方评测称"npu-smi、MindStudio 在算子耗时、带宽利用率定位上基本覆盖 profiling 需求，整体功能可对标 nvidia-smi + Nsight 组合，但生态中尚不完整"------该句来自 chinasihan.com，属【媒体转述】，可信度中等。

1.6 已知踩坑

1. NMS 是动态输出算子，ATC 要求静态图 → 直接编译失败 。解决：导出时 nms=False 剥离 NMS，移到 CPU 后处理。【社区实测｜2048ai.net】
2. Gather / GatherND / ScatterND / ScatterElements 在 DFL 分支中报"动态索引不支持"------静态编译时索引必须确定，DFL 的索引是预测生成的。【社区实测｜2048ai.net】
3. TopK 输出维度 K 值动态，与静态图冲突，与 Gather/Scatter 组合后形成 ATC 无法解析的数据流。【社区实测｜2048ai.net】
4. Interpolate(align_corners=True) 参数匹配失败 ------硬件插值算子通常只支持一种模式（常为 False），模式不匹配导致特征图空间错位，检测精度静默下降（不报错，只掉点）。这是最危险的一类坑。【社区实测｜2048ai.net】
5. GridSample CANN 官方明确不支持。【社区实测｜2048ai.net】
6. SiLU/Hardswish 在 CANN 上支持有限或实现效率低，易导致数值精度溢出或图编译失败 ；社区方案是全局替换为 ReLU6 并重新微调恢复精度。【社区实测｜2048ai.net】
7. ConstantOfShape（opset 13+ 导出）违反静态形状要求导致编译失败 ；Expand/含 -1 维的 Reshape 同理。【社区实测｜2048ai.net】
8. 动态 Shape 支持度是重点验证项------人脸检测/工业检测输入分辨率常变。【社区实测｜CSDN MogFace 适配文】
9. AI CPU Cast 算子自动插入可能把算子静默落到 CPU 执行，造成"能跑但极慢"。官方文档目录中存在该特性开关，应显式关闭排查。【官方文档目录条目】
10. NPU 版本与驱动固件强绑定------op 调试文档 FAQ 明确列出"opp 安装版本问题导致加载单算子失败"。【官方文档 FAQ 条目】
11. 【社区实测】YOLOv8 后处理在 CPU 上做 FP32，"方便省事也不会因为 FP16 丢失太多阈值判断精度"------说明 FP16 下的阈值判断精度丢失是被观察到的实际问题。

---

2. 海光 DCU（DTK / ROCm 衍生）

本节是全报告中与用户现状最匹配的一节。

2.1 推理引擎对标 TensorRT

结论：存在三个层级的对位物，但没有一个是 TensorRT 的完整等价物。

【社区实测】海光软件栈分层（DTK 24.04.3 / K100 / 8100(Z100L)）：

驱动 (DTK) → HIP 编程接口 → hipcc 编译器 → rocblas / hipblaslt / rocsolver
            → rocfft / rocrand / rccl / rocprim / hipCUB / rocthrust
            → MIOpen（算子库，类 cuDNN）

对位关系：

TensorRT	海光对应物	性质
CUDA Runtime API	HIP API	近乎一一对应 （cudaMalloc→hipMalloc，见下方对照表）
nvcc	hipcc	直接对应
cuDNN	MIOpen	功能对位
cuBLAS	rocBLAS / hipBLASLt	功能对位
NCCL	RCCL	功能对位
nvidia-smi	dcu-smi	功能对位
Nsight Systems / ncu	rocprof	功能对位（rocprof --stats --timestamp on）
TensorRT 本身	MIGraphX / ONNX Runtime / 自研 DAS	⚠️ 见下

关于海光是否有 TensorRT 对标物 ：本次检索中出现了 MIGraphX（NVIDIA 开源的图编译工具，本身即 TensorRT 的开源近亲），出现在海光 DAS 的"框架工具层"列表中，与 ONNX Runtime 并列（【社区实测｜CSDN DevPress】）。同时该文称 DAS ≈ "CUDA + cuDNN + TensorRT + NCCL 的集合体"。

⚠️ 但 ：任务给定的候选名 TENSOR_RTX 我未能在任何来源找到 （含官方站）。此前检索"海光 DCU TENSOR_RTX"返回的结果中没有出现该标识符。→ 海光是否存在名为 TENSOR_RTX 的 TensorRT 兼容库：未找到证据，请勿写入报告。

【社区实测】DAS（DCU AI Software Stack）三层架构：

• 基础算子层：LightOP 融合算子库、HYT LASS 算子模板库、AI 编译（Triton / XLA / TVM / TileLang）
• 框架工具层：PyTorch / TensorFlow / JAX / PaddlePaddle、FastPT 快速适配 、LayerCheck 精度检测 、ONNXRuntime、MIGraphX
• 扩展组件层：训练 Apex/DeepSpeed/Megatron/FlashAttention/TransformerEngine...

⚠️ 注意 HYT LASS 疑为 LightASS 或 HYTORCH 的讹传，未验证。该文来源为 CSDN DevPress（内容形态疑似 AI 辅助生成），仅可作线索。

2.2 转换流程

海光的转换路径与 TensorRT 逻辑一致------ONNX 是通用中间格式，与昇腾/寒武纪的"专用离线格式"路线根本不同。

【社区实测】CMake 配置（完整可复制）：

cmake_minimum_required(VERSION 3.18)
project(MyDCUProject HIP CXX)

set(DTK_PATH /opt/dtk CACHE PATH "DTK installation path")

set(CMAKE_HIP_COMPILER ${DTK_PATH}/bin/hipcc)
set(HIP_PATH ${DTK_PATH})

include_directories(${DTK_PATH}/include
                    ${DTK_PATH}/include/hip
                    ${DTK_PATH}/include/rocblas
                    ${DTK_PATH}/include/MIOpen)
link_directories(${DTK_PATH}/lib ${DTK_PATH}/lib64)
target_link_libraries(MyProject
    ${DTK_PATH}/lib/libamdhip64.so
    ${DTK_PATH}/lib/librocblas.so
    ${DTK_PATH}/lib/libMIOpen.so
    ${DTK_PATH}/lib/librccl.so)

set_source_files_properties(kernels.cpp PROPERTIES LANGUAGE HIP)
target_compile_options(MyProject PRIVATE --amdgpu-target=gfx906 -O3)

⚠️ --amdgpu-target=gfx906 为 AMD GCN 架构代号，海光 DCU 微架构不同，该 flag 对海光是否适用：未验证，须查海光官方编译手册。

环境变量（社区实测，完整）：

export DTK_HOME=/opt/dtk
export PATH=${DTK_HOME}/bin:${PATH}
export LD_LIBRARY_PATH=${DTK_HOME}/lib:${DTK_HOME}/lib64:${LD_LIBRARY_PATH}
export HIP_PATH=${DTK_HOME}
export ROCM_PATH=${DTK_HOME}      # 部分软件靠这个找 rocm

2.3 自定义算子开发方式

语言：HIP（C/C++） 。这是唯一一个用户原有 .cu 文件可以直接继续用的路径。

【社区实测】批量转换命令：

hipify-clang my_cuda_kernel.cu -o my_hip_kernel.cpp
find . -name "*.cu" -o -name "*.cuh" | xargs -I{} hipify-clang {} -inplace

【社区实测】API 对照表（完整）：

内存:  cudaMalloc→hipMalloc    cudaFree→hipFree
       cudaMallocHost→hipHostMalloc(ptr,size,0)   cudaFreeHost→hipHostFree
       cudaMemcpy→hipMemcpy    cudaMemset→hipMemset
设备:  cudaSetDevice→hipSetDevice
       cudaGetDeviceCount→hipGetDeviceCount
       cudaDeviceSynchronize→hipDeviceSynchronize
       cudaGetDeviceProperties→hipGetDeviceProperties
流/事件: cudaStreamCreate→hipStreamCreate
       cudaStreamSynchronize→hipStreamSynchronize
       cudaEventCreate→hipEventCreate
       cudaEventRecord→hipEventRecord
       cudaEventElapsedTime→hipEventElapsedTime
编译指令: __global__→__global__（相同）
       __device__→__device__（相同）
       __shared__→__shared__（相同）
       threadIdx.x→hipThreadIdx_x（或直接 threadIdx.x，HIP 兼容）
       blockDim.x→hipBlockDim_x（或直接 blockDim.x）

结论：绝大多数预/后处理 CUDA kernel（逐像素、归一化、NMS、anchors decode）hipify 后可直接编译，性能需实测但结构无需重构。

⚠️ 任务给定的 DtkOperator 一词未在任何来源找到 。海光公开的算子开发入口是 HIP + hipify-clang + MIOpen 。→ 报告中不应出现 DtkOperator。

2.4 原 CUDA kernel 可复用程度：路径 A→B（全平台最优）

这是本次调研中唯一一个能给出"源码级兼容"肯定答案的平台。

判定依据：hipify-clang 是自动化源码转换工具 （非 API 仿真层），转换后仍是真实 HIP C++ 源码；__global__/__device__/__shared__/threadIdx/blockDim 关键字同名。

但必须提示以下语义差异 （基于 HIP/AMD 架构通用常识，非本次检索所得，需实测确认）：

• warp vs wavefront：AMD wavefront 常为 32 或 64，NVIDIA warp 恒为 32 → 依赖 warp 内隐式同步的代码（如无显式 __syncthreads() 的 warp-level 归约）语义改变
• __shfl_* 系列 API 语义与宽度相关
• bank conflict 模式、global memory coalescing 行为不同 → 同样的源码在不同卡上性能差异可能很大
• 原子操作（atomicAdd 等）的内存序语义与性能特性不同

对用户具体场景：

• 预处理/后处理 kernel：可直接 hipify 复用（推荐路径）
• TensorRT Plugin：❌ 无对应物 。海光没有 TensorRT 兼容库，Plugin 模式需整体改造------最接近的是 ONNX Runtime 自定义算子（EP 层）或 MIGraphX 融合自定义节点，两者与 IPluginCreator 机制均不匹配
• .plan engine：无对应物

2.5 工具链与调试能力

【社区实测】性能调优工具：

rocprof --stats --timestamp on python3 my_script.py   # 算子级性能数据
watch -n 1 dcu-smi                                       # 实时监控

MIOpen 缓存预生成：

export MIOPEN_USER_DB_PATH=/tmp/miopen_d
export MIOPEN_DISABLE_CACHE=0

YOLO/vLLM 官方适配镜像：image.sourcefind.cn:5000/dcu/admin/base/pytorch:2.0.1-dtk24.04.3-py38-ubuntu20.04（光合开发者社区）。

PyTorch 层兼容的关键事实 （社区实测，明确表述）：DTK 让 torch.cuda.* 接口直接映射到 DCU 设备 ------torch.cuda.is_available() 返回 True 且指向 DCU。这是"为降低迁移成本刻意设计的 CUDA 接口兼容层"。对纯 PyTorch 推理几乎零成本，但对用户的 C++ TensorRT 栈无直接帮助。

2.6 已知踩坑

1. DTK ≠ ROCm------最常见误区。直接装社区 ROCm 镜像到海光服务器会踩很多坑。【社区实测】
2. 路径绝对不能混用 ：DTK 在 /opt/dtk/，ROCm 在 /opt/rocm/。【社区实测】
3. libhip_hcc.so: cannot open shared object file ------不设 ROCM_PATH=/opt/dtk 时，路径探测型软件（某些版本 vLLM）找不到库。【社区实测】
4. 算子结果不一致 / 推理输出乱码 / 训练 loss 异常 → MIOpen 内核缓存污染 ，解决 rm -rf ~/.cache/。【社区实测】
5. RCCL 通信初始化失败 → 网络接口配置错误，需 export NCCL_SOCKET_IFNAME=eth0。【社区实测】
6. pip install torch 覆盖了 DTK 版本导致 is_available() 返回 False → 必须装海光适配版 torch 或用容器隔离。【社区实测】
7. MIOpen 初次运行非常慢（几分钟到十几分钟生成内核缓存）→ 属正常现象，需预热。【社区实测】
8. BF16 支持不完整 ，较老 DTK 版本建议用 FP16，vLLM 用 --dtype half 而非 bfloat16。【社区实测】
9. K8s 接入踩坑 （社区实测）：nvidia-smi 无对应物（用 rocm-smi）；资源名不能写 nvidia.com/gpu；nvidia-device-plugin 不能复用；MPS/MIG 在 DCU 上叫法与实现都不同，vDCU 有两条完全不同的虚拟化路径 ；DTK 版本与操作系统内核版本 + glibc 版本绑定 ，Ubuntu 20.04 换 22.04 需升 DTK 版本，直接解压大概率 insmod 失败；用户态库版本与内核驱动不匹配会导致容器内矩阵乘法报非法指令（该团队实测踩过）。
10. 镜像命名易错 ：拉 ROCm 版本 PyTorch 会导致 hipSetDevice 阶段失败。

---

3. 寒武纪 Neuware / MLU

3.1 推理引擎对标 TensorRT

结论：MagicMind 是最接近 TensorRT 的对位物，但生态重心已明显迁移。

【官方文档】MagicMind 官方产品页（cambricon.com，catid=378）：

• 自称"业界首个基于 MLIR 图编译技术达到商业化部署能力的推理引擎"
• "支持跨框架的模型解析、自动后端代码生成及优化"
• "用户使用 MLU、GPU 或者 CPU 训练好的算法模型，借助 MagicMind 仅需投入极少的开发成本，即可将推理业务部署到寒武纪全系列产品上"
• 插件化设计 ："通过 MagicMind 插件化的设计，还可以满足在性能或功能上追求差异化竞争力的客户需求" ← 这是与 TensorRT Plugin 最接近的设计意图
• 精度：FP32 / FP16 / INT16 / INT8，支持用户指定不同层级计算精度以及定义量化方法细节
• "原生支持动态张量输入，具有完备动态张量表达能力"
• 官方对比数据使用 MagicMind v0.6 （MLU370-S4/X4）------该页面数据陈旧

⚠️ 任务给定组件名 CNCERT 未在任何来源找到。寒武纪公开的组件为：CNRT （运行时）、CNNL （计算库）、CNNL-Extra 、CNCV （计算机视觉库）、CNCL （通信库）、CNCC （编译器）、CNPerf / CNPerf-GUI 、CNSantizer 、CNAdvisor 、CntrainKit-Accu / CntrainKit-Monitor 、CNCE 、CNAnalyzeInsight 、TorchDump 、Cambricon HLO。→ CNCERT 与 bnnc 均未验证存在，请勿写入报告。

⚠️ 重大趋势变化（对选型判断关键）：

【媒体转述｜中国财富网】2025-09-29 寒武纪宣布适配 DeepSeek-V3.2-Exp 时，"开源大模型推理引擎 vLLM-MLU 源代码 "，并"通过 Triton 算子开发实现快速适配，利用 BangC 融合算子开发实现极致性能优化"。

【媒体转述｜NeuWare 全家桶稿】寒武纪当前对外叙事重心是：torch_mlu（支持 PyTorch 2.1--2.8）、vLLM-MLU 、MLU Graph、AOTInductor、Triton 算子开发语言、"GPU Migration 一键迁移工具" （"帮助用户近乎零成本将模型从 GPU 迁移到 MLU"）。MagicMind 在 2025--2026 的官方材料中已不再被重点提及。

→ 报告结论建议 ：对新增的 C++/TensorRT 栈项目，评估寒武纪应以 vLLM-MLU + torch_mlu + Triton/BANG C 为当前主线，把 MagicMind 作为历史方案标注。

3.2 转换流程

【社区实测】MagicMind Python API 转 TorchScript（注意：该文写 --precision_mode force_float32）：

import magicmind as mm
from magicmind.python.runtime import ModelKind, Network, Builder

builder = Builder()
network = Network()
assert network.parse_from_torchscript("mogface_trace.pt").ok()
build_config = BuilderConfig()
build_config.parse_from_string('--precision_mode force_float32')
model = builder.build_model("mogface", network, build_config)
model.serialize_to_file("mogface.mm")

⚠️ parse_from_string 用单引号包字符串，跨版本可能要求双引号（社区文章混用）。建议报告中标注"以官方 magicmind-python 文档为准"。

【社区实测】CNRT Python 推理接口：

import cnrt
dev = cnrt.device(); dev.id = 0; cnrt.init(dev)
model = cnrt.Model(); model.load_model("mogface.mm")
engine = model.create_engine()
engine.inference(inputs, outputs)

⚠️ 未找到 CNRT 的 C++ API 官方文档 。用户场景需要 C++ 接入，这是一处明确的信息缺口。

【社区实测】环境准备（YOLOv5 部署）：

docker load -i magicmind_0.13.1-1_ubuntu18.04.tar.gz
docker run -it --name=mlu_yolov5 --network=host --cap-add=sys_ptrace \
  -v /your/local/code:/workspace \
  -v /usr/bin/cnmon:/usr/bin/cnmon \
  --device=/dev/cambricon_dev0:/dev/cambricon_dev0 \
  -w /workspace magicmind:0.13.1-1-ubuntu18.04 /bin/bash

3.3 自定义算子开发方式

两条路径，语言完全不同：

1. BANG C【媒体转述】"寒武纪 BANG 异构并行编程模型的编程语言，在 C/C++ 语言基础上针对 MLU 架构特点进行扩展，可以高效编写在 MLU 上运行的并行程序"。编译优化包括 LTO、基于 Profiling 反馈优化（PGO）、函数级片上空间复用、Device 侧动态链接、编译器静态推导访存指令地址空间、任务内并行指令流自动同步等。
2. Triton 【媒体转述】"持续快速迭代 Triton 算子开发语言，支持 Triton 3.4 所有特性，包括 FP8/FP4 的数据类型 "。Triton 后端优化涵盖软件流水片上 RAM 占用、指令调度、多目标自动调优、自动循环合并、基于算子语义的访存和计算优化（transpose 穿透合并、slice、broadcast 穿透）、指令融合。"部分热点算子已经与手写算子性能相当"。

⚠️ 未找到 BANG C 的实际语法示例 （__mlu_func__ / bangs / __nram__ 等关键字仅见于我的一般知识，本次检索未获得来源，按诚实性要求不予写入）。

3.4 原 CUDA kernel 可复用程度：路径 C（全量重写）

判定依据：BANG C 是"在 C/C++ 语言基础上针对 MLU 架构特点进行扩展"，即保留 C++ 语法骨架但替换执行模型------与 Ascend C 同类（MLU 同样有各自的片上存储分区概念、指令集、并行原语）。用户的 TensorRT Plugin 封装逻辑与 CUDA kernel 均需重写。

可行的替代路径（降低工作量）：

• Triton 路线：Triton 是 CUDA 生态原生产物，若原 kernel 逻辑可表达为 Triton tile 算子，迁移摩擦最小。且官方称热点算子性能已与手写算子相当。
• CNCV 计算机视觉库：寒武纪有专门的 CV 库，YOLO 类任务应先查 CNNL/CNCV 是否已有现成算子，避免自行开发。

3.5 工具链与调试能力

【媒体转述】工具矩阵相当完整（这是寒武纪相对较强的部分）：

工具	能力
CNPerf	极低跟踪开销下全维度性能数据采集；捕获主机侧/设备侧执行流、PMU 指标、函数调用栈；支持 Kernel 计算/内存拷贝/通信任务追踪
CNPerf-GUI	适配 Linux/macOS/Windows；支持 CNPerf、PyTorch Profiler、TensorFlow Profiler、CNTrainKit 日志格式；支持上亿函数记录的日志；内置专家建议系统自动检测设备空泡/利用率不足/集合通信等待；支持 GHz 级采样
CNSantizer	运行时插桩：多核间竞争访问检测、单核内多指令流竞争检测、Device 侧内存越界检测、未定义行为检测、未初始化内存检测
CNAdvisor	性能问题自动定位并标记对应源代码位置
算子 core dump	"支持算子 core dump，实现异常现场的核心转存...提供 core dump 文件解析工具"
CntrainKit-Accu	万卡训练端到端精度定位，NaN/Inf 异常检测与秒级溯源
CntrainKit-Monitor	集群实时通信与算子性能画像
CNCE	集群监管平台，十万卡级秒级采集
CNAnalyzeInsight	GB 级日志秒级检索与根因诊断
TorchDump	精度调试
cnmon	设备监控（对标 nvidia-smi）

Kernel 吞吐【媒体转述】："通过细粒度的并行技术...Kernel 函数调度吞吐可达每秒几十万个任务"。设备切分：visible cluster（运行时可编程弹性拆分）/ sMLU（时分复用，Docker 快速部署）/ MIM（物理划分，对标 MIG）。

3.6 已知踩坑

1. 驱动版本与 MagicMind 版本不匹配是部署失败最常见原因之一。【社区实测】
2. 动态 Shape 支持程度需重点验证（人脸检测输入尺寸常变）；MagicMind 官方称"原生支持动态张量"，但社区适配文章仍将其列为挑战。【社区实测 vs 官方存在张力，报告应同时呈现】
3. MogFace 模型中 HCAM 模块的特定操作可能 ATC/MagicMind 不支持，需算子开发------【社区实测】
4. 【社区实测】某百度云文章称 MLU370-X8 经优化"端到端推理延迟从 12.7ms 降至 5.3ms，达到 NVIDIA A100 的 89%"------该来源疑似 AI 生成，不采信。

---

4. 沐曦 MACA

4.1 推理引擎对标 TensorRT

结论：MacaRT 是本次调研中唯一找到的、API 形态上真正贴近 TensorRT 的对位物------但它是 ONNX Runtime Execution Provider，不是独立推理引擎。

【官方文档｜已验证可达】MacaRT C++ API（developer.metax-tech.com）：

• 定位：基于 ONNX Runtime 的 EP，MacaRT

• Session 创建：

  #include <onnxruntime_cxx_api.h>
  std::string ep_name = "MacaEP";
  Ort::Env env(OrtLoggingLevel::ORT_LOGGING_LEVEL_INFO, ep_name.c_str());
  OrtMACAProviderOptions maca_options;
  maca_options.device_id = 0;
  Ort::SessionOptions sessionOptions;
  sessionOptions.AppendExecutionProvider_MACA(maca_options);
  Ort::Session session(env, your_onnx_model_path, sessionOptions);

• 自定义算子 （目录 "3.5. 自定义算子"）："MacaRT 支持用户定义非官方的 ONNX 算子进行推理。操作步骤：使用 C++ 的 API 构建自定义算子库。通过使用 C++ API 或 Python API 将自定义算子库注册到 SessionOptions"

这是全报告中最接近 TensorRT Plugin 语义的对位物 ：同样是"宿主推理引擎 + 用户注册自定义算子实现"。差异是注册粒度在 ONNX 层（须先把自定义 kernel 包装成 ONNX custom op），而非 TensorRT 的 IPluginCreator layer 级。

⚠️ 重要架构信号 ：沐曦的推理链路走 ONNX Runtime EP ，而非 CUDA EP。这说明其内部未提供 CUDA API 仿真层------"兼容 CUDA" 的成色需要打折看待。

MACA 整体软件栈【媒体转述｜机器之心解读 23 页技术报告】：mcBLAS（对标 cuBLAS）、mcDNN（对标 cuDNN）、mcFlashAttention、MCCL（集合通信）、MetaXLink（硬件互连）、性能分析工具（系统级追踪 + kernel 指标采集）。

4.2 转换流程

未找到 MXMACA 官方格式转换命令 （如 mcc --convert onnx ...）。官方口径是"MACA 支持模型训练后的轻量化转换与直接部署，无需二次适配。通过统一的模型格式与接口规范"【媒体转述】，但未给出具体 CLI。

【官方文档】已确认的是 MacaRT 路径：ONNX 模型 → Ort::Session + MacaEP。

⚠️ 信息缺口 ：用户给定的 mcc 编译器（任务描述称"mcc 编译器"），本次检索未找到其独立文档或命令行用法。媒体报道中的编译器表述为"MACA C/C++、Fortran 等语言"的编译器，无具体命令。

4.3 自定义算子开发方式

• 官方确认：MacaRT 自定义 ONNX 算子库（C++ API 构建 → 注册到 SessionOptions）【官方文档】
• 语言 ：mcc（C/C++ 编译器，推测），未验证细节
• 媒体称 MACA"编译器工具支持 MACA C/C++、Fortran 等语言，能将高级语言转化为高效的可执行程序"【媒体转述】

4.4 原 CUDA kernel 可复用程度：路径 B（且官方未背书，风险显著）

这是用户问题里明确要求查证的一项。查证结果：

【媒体转述｜华创证券研报】"MXMACA 软件栈兼容 C/C++/Python 主流异构计算语言及 6,000 多个 CUDA 应用...开发者无需过多修改现有代码即可将应用快速部署到沐曦的 GPU 产品上运行"

【媒体转述｜机器之心解读 23 页技术报告】适配测试数据：

• 筛选 4,490 个含 CUDA 关键字的活跃 GitHub 仓库
• 4,173 个可直接适配运行，成功率 92.94%
• 260 个需微小调整，占比不足 6%，且修改主要涉及编译配置优化，而非核心业务逻辑
• PyTorch 2.8 覆盖全部 2,650 个核心算子（其中 GPU 算子 2,410 个）
• MACA 3.3.0.X 发布日期：2025-12（机器之心文）；WAIC 2026 现场口径为"近 5000 个热门开源项目，92% 无需修改任何代码"（玩亦可及）

【媒体转述｜半年报 + WAIC】"MXMACA 软件栈高度兼容国际主流生态，已支持超过 6,000 个 CUDA 应用，与超过 1,000 个模型原生适配"；"92% 开源项目无需修改代码即可运行"

必须同时呈现的反向证据 ：

【媒体转述｜腾讯新闻】明确写道："与部分厂商选择兼容 CUDA 或基于现有开源 ISA 进行微调的方式不同，沐曦选择了最具挑战但也保证了长期安全性的路线：自主指令集 。MACA 软件栈具有自己的编程模型和使用范式，但也深度兼容 CUDA 生态。"

结论：这是 API 兼容，不是源码级兼容

判断依据：

1. 官方/媒体口径统一为"无需过多修改代码 "、"修改主要涉及编译配置 "------从未声称 CUDA 源码可直接编译
2. 明确声明"自主指令集 "、"自己的编程模型和使用范式"
3. PyTorch 侧走 ONNX Runtime EP（MacaEP） 而非 CUDA EP------若能提供 CUDA EP 仿真层，无此必要
4. "92.94% 直接适配"的分母是 GitHub 开源仓库 （以 PyTorch/科学计算应用为主，几乎不含自定义 CUDA kernel 的 C++ 推理服务 ）。此数据不能外推到用户场景 ------用户的 .cu 文件中恰恰是官方测试集里最少见的那一类资产

⚠️ 信息缺口（重要） ：本次检索未找到任何 "CUDA kernel 直接编译 / mcc 编译 .cu 文件"的官方文档、实测记录或踩坑帖。任务给定的"是否支持 CUDA kernel 直接编译"这一关键问题，答案是：未验证，且现有证据倾向于否。

4.5 工具链与调试能力

【媒体转述】"MACA 的性能分析工具提供了系统级追踪和 kernel 指标采集功能，能够帮助开发者定位计算瓶颈"------功能描述模糊，未给出工具名称与命令行。

⚠️ 信息缺口 ：未找到沐曦 profiler 的具体名称/用法。对标 nsys 的工具名未验证。

生态数据【媒体转述｜华创证券】：注册用户及实际使用客户 >30 万（截至 2026-03-13），网络 API 调用 >5,591 万次，公开 200+ 份开发文档和手册，覆盖 >50% 中国 C9 高校。开源社区自 2025-02-14 开放。

4.6 已知踩坑

未找到沐曦的公开踩坑记录（GitHub Issue / CSDN 实战帖均无有效命中）。

1. 官方宣传口径与独立实测之间存在缺口：92.94% 的测试集是开源仓库，未覆盖 C++/自定义 kernel 场景。【本报告的证据分析】
2. ⚠️ 任务给定的"MXMACA 声称 API 层面兼容 CUDA"已查证属实，但兼容层级被宣传材料模糊化。

---

5. 摩尔线程 MUSA

5.1 推理引擎对标 TensorRT

结论：官方名称是"MUSA 推理引擎"，无独立于 PyTorch 的 TensorRT 对位物。对标关系为 torch_musa（PyTorch 后端）+ MATE（大模型推理加速）。

【社区实测｜nxrte.com】"MUSA 推理引擎 ：原生支持 YOLO26，在检测、分割、姿态、旋转框等场景实现无 NMS 端到端推理，推理延迟降低 30% 以上"

【社区实测｜cronfeed.work】vllm-musa 组件栈包含：

• torchada --- CUDA 到 MUSA 兼容
• mthreads-ml-py --- 设备管理
• MATE --- 大模型推理加速
• torch_musa --- 原生 MUSA 设备支持
• 支持版本表：仅 vLLM v0.22.0、PyTorch 2.7.1，仅支持 V1 engine

⚠️ MATE 与 torchada 的具体 API 未找到官方文档。

5.2 转换流程

模型转换工具链 ：兼容 ONNX 等主流格式【社区实测】。具体命令未找到。

YOLO26 快速上手（官方仓库）：

• torch_musa：https://github.com/MooreThreads/torch_musa
• torchada：https://github.com/MooreThreads/torchada
• AutoDL 预置镜像：https://www.autodl.art/i/ultralytics/ultralytics/yolo26-musa

MUSA SDK 版本矩阵（【社区实测｜cronfeed.work，2026-06-11】）：

• MUSA SDK v5.1.0，面向 MTT S5000 与 MTT S4000
• CPU 平台：Intel、AMD、海光
• OS：Ubuntu、Alinux、openEuler、TencentOS、VesselOS、麒麟
• 打包：RPM 与 DEB
• 社区构建版本另覆盖 MTT S80/S3000/X300

5.3 自定义算子开发方式

语言：musaCC （任务给定，本次检索未找到其独立文档或命令行用法，标未验证）。

Torch-MUSA v2.0.0 能力【媒体转述｜凤凰网/快科技】：

• FP8 原生支持（基于 MUSA Compute Capability 3.1 架构）
• 虚拟内存管理
• MUSA Graph ：将多个 MUSA kernel 整合到一图，单次 CPU 调度，"与 CUDA Graph 接口高效兼容" ← 唯一找到的显式 CUDA 接口兼容声明
• torch.compile 增加 Triton-MUSA 后端
• 支持 PyTorch 2.2.0（完整）+ 2.5.0（新增）

5.4 原 CUDA kernel 可复用程度：路径 B

判定依据（本次检索证据较薄，须在报告中声明证据强度）：

• 支持路径 B 的证据 ：①torch_musa 设计为后端字符串切换（cpu/cuda→musa）；②torchada 明确定位为"CUDA 到 MUSA 兼容"；③存在 musaCC 编译器；④MUSA Graph 声称接口兼容 CUDA Graph；⑤官方称"CUDA 兼容...自定义算子和内存管理改进"
• 限制该判定的证据 ：【社区实测｜cronfeed.work】明确警告："后端名称切换不能保证每个 CUDA 扩展、自定义算子、混合精度路径或分布式训练模式都原样运行。它确实描述了正确目标。"

→ 对用户场景：PyTorch 后端切换这一优势不适用 （用户是 C++ TensorRT）；torchada / musaCC 能否编译用户 .cu 中的自定义 kernel，未验证。

5.5 工具链与调试能力

【社区实测｜cronfeed.work】较有价值的批判性观察，直接引用：

"MUSA 的实践考验在于国产 GPU 栈能否进入服务器房里的软件、运行时和部署工作......MUSA 页面没有证明它已经广泛达到 CUDA 等价。它显示的是，厂商正在发布真实采用所需要的那类乏味集成表面。"
"成功条件落在 attention kernel、量化路径、自定义 op、多模态预处理器和分布式服务组件能否在模型变化时继续工作。"

⚠️ 信息缺口：未找到 MUSA profiler 工具名。

5.6 已知踩坑

1. 版本滞后：需持续观察 torch_musa、vLLM-MUSA、MUSA SDK、容器工具链是否长期落后于主流 PyTorch 与服务版本。【社区实测｜cronfeed.work 的"继续观察什么"第 1 条】
2. vllm-musa 支持版本极窄（vLLM 0.22.0 + PyTorch 2.7.1 + 仅 V1 engine）------"插件存在只说明一条路径已经打开，尚不能推导出能广泛兼容每一个 vLLM/PyTorch/模型服务路径"。【社区实测｜cronfeed.work】
3. 后端切换不保证 CUDA 扩展/自定义算子/混合精度/分布式模式原样运行。【社区实测｜cronfeed.work】
4. 算子覆盖是核心风险：成功条件取决于 attention kernel、量化路径、自定义 op、多模态预处理器。【社区实测｜cronfeed.work】
5. GPUStack 集成仅覆盖 MTT S80/S3000/S4000 + Linux x86_64 + Ubuntu 20.04/22.04。【社区实测｜docs.gpustack.ai】

---

6. 天数智芯 NeuWare / CoreX IR

6.1 推理引擎对标 TensorRT

结论：IxRT 是命名上最直接的对位物，IxDNN 对标 cuDNN。但均未在官方站获得交叉确认。

⚠️ 证据强度说明 ：以下关于 IxRT / IxDNN 的信息仅来自一篇掘金技术博客，未在 iluvatar.com 官方站找到对应产品页（官方站检索到的仅为天垓100/智铠100 产品介绍与 DeepSpark 社区介绍）。→ 报告中应标注【未验证】。

【未验证｜掘金】天数智芯生态：

项目	说明
架构	自研 GPU，兼容 CUDA 生态
软件栈	IxRT（对标 TensorRT）+ IxDNN（对标 cuDNN）
PyTorch	通过 CUDA 兼容层运行，模型迁移成本低
ONNX	支持 ONNX Runtime 或转 IxRT
命令行	ixrtexec --onnx=dcgan.onnx --saveEngine=dcgan.ixrt ← 未验证
ONNX Runtime EP	IxRTExecutionProvider ← 未验证

⚠️ CoreX IR 未在任何来源找到技术细节 。任务给定的 "CoreX IR" 概念未验证。

⚠️ "异构算力平台兼容 CUDA 生态，客户迁移成本降低 50% 以上"------来自中国日报网企业报道【媒体转述】，无技术细节支撑。

6.2 转换流程 / 6.3 自定义算子 / 6.4 CUDA kernel 复用

均未找到可靠来源。

⚠️ 天数智芯是本报告中信息缺口最大的平台 ：IxRT 的真实 API、命令行、.ixrt engine 格式、自定义算子开发方式、profiler 名称，全部未验证。

唯一可确认的是【媒体转述｜中国新闻网上海 2026-01-26】："目前已稳定运行 400 余种模型、数千个已有算子与 100 余种定制算子 "，"国内 15 种新的大模型发布当天便能跑通"，"大模型适配上达成 95% 算子复用"。以及【媒体转述】"已开发近百个加速库，并形成覆盖通信、编译、驱动、量化和性能分析的工具体系"。

6.5 已知踩坑

未找到。

⚠️ 商业侧【媒体转述】"天垓通用 GPU...互联网 AI 领域实现单机性能翻倍、Token 成本减半"、"研报生成效率提升 70%"------均为企业宣传数据，不构成技术事实。

---

7. 壁仞科技 BIRENSUPA

7.1--7.4 综合

⚠️ 本节信息质量最差，且必须标注。

任务表格中的 "BANG C / biue " ------ BANG C 是寒武纪的语言，不是壁仞的 ；biue 在任何来源均未找到。→ 报告中不应出现"壁仞 BANG C"。

壁仞实际软件栈为 BIRENSUPA ，历史上与 BLADE-SDK 相关联【媒体转述，来源疑似 AI 生成，未验证】。

【社区实测｜今日头条，可信度需谨慎】"壁仞 BIRENSUPA CUDA 迁移成本 3-5 倍，企业部署有哪些隐性坑？"：

• "已经能照着做全 500 多道主流菜"（指 500+ 模型适配）
• "1600+ 已验证算子"
• "CUDA 那边随便调个现成的配方，到了 BIRENSUPA 这边，1600+ 已验证算子的料仓就不太够用了，经常得自己动手挖食材、搓调料"
• "一天过去了，模型还没跑起来------编译报错，你的工程师不得不钻进底层 IR 代码手动改逻辑"
• BR106/BR166 不支持 FP8/FP4；2026 Q4 BR20X 计划支持原生 FP8/FP4
• 千卡级集群通信库存疑；长周期训练任务有效运行占比比成熟 CUDA 集群低约 10%~15%
• 非热门场景（传统 CV 小模型、推荐系统、小众长尾推理）单卡利用率可能普遍低于 50%
• 最大公开部署：上海智算中心万卡级集群（政府主导）；2026 招股书在手未完成订单 8.22 亿元

⚠️ 同一来源称"海光 DTK 迁移兼容度超 95%、算子覆盖率超 99%"、沐曦"MACA 适配 6000+ 应用和 2200+ 算子"------这些数字与前述券商研报口径一致（沐曦部分可交叉验证），但海光的 95%/99% 未找到其他来源佐证。

⚠️ "GitHub: birensai/PyTorch-BR100"【媒体转述，来源疑似 AI 生成】------未找到该仓库，不应引用。

7.5 CUDA kernel 复用：路径 C

依据上述【社区实测】"编译报错...改底层 IR 代码"、"算子覆盖不足需自行开发"。该来源为今日头条自媒体，可信度中等，但方向性判断（需重写）与"自主指令栈"厂商的普遍情况一致。

---

8. 燧原科技 TopsRider

⚠️ 本节几乎全是未验证内容。

【媒体转述｜MEXC，来源质量存疑】：

• 架构：GCU（General Computing Unit），"完全去除了传统图形显示所需的渲染硬件模块"
• 软件平台：馭算 TopsRider，"采取了积极拥抱主流开源生态的策略，深度适配 PyTorch、TensorFlow 和 PaddlePaddle"
• "通过内置的自动化图优化引擎与算子融合工具，开发者无需深入重构底层 CUDA 代码，即可将已有的大模型训练与推理任务迁移至燧原硬件"
• 第三代邃思芯片支持 FP32/TF32/FP16/BF16/INT8
• 千卡与万卡级集群工程化落地

⚠️ 未找到：

• TopsRider 的推理引擎名称（是否有 TensorRT 对位物）
• 模型转换的具体工具链与命令
• 自定义算子开发方式与语言（任务表格中的 TopsRider 只是平台名，非算子开发入口）
• profiler 工具名
• 任何 CUDA kernel 迁移的实测记录
• 官方开发者文档

【媒体转述｜中国经济网】IDC 数据：2024 年寒武纪出货 2.6 万片，燧原出货 1.3 万片。

⚠️ 对用户场景的判断：燧原是本次调研中证据最不足的平台，不建议在报告中给出路径判定。

---

9. 昆仑芯 XTDK

9.1 推理引擎对标 TensorRT

⚠️ 唯一信息来源为 CSDN 疑似 AI 生成文章，整体标未验证，仅列组件名供后续查证。

【未验证】昆仑芯 SDK 软件栈（自下而上）：

• XRE （XPU Runtime Environment）：内核驱动 kmd + 用户态运行时 + xpu-smi
• XDR：可源码编译的驱动适配层
• XTDK ：LLVM 基础工具链，自定义 Clang 前端 + XPU 后端，支持 AOT/JIT
• XDNN：深度学习高性能算子库
• XBLAS / XHPC：基础线性代数与 HPC 数学库
• XCCL：集合通信库
• 图编译引擎：基于 TVM 0.7，对接 PaddlePaddle / PyTorch / TensorFlow / ONNX
• 大模型：vLLM-Kunlun

芯片侧【未验证】：昆仑芯 2 代 XPU-R 架构，7nm，256 TOPS@INT8；SDNN（Software Defined Neural Network Engine，对标 Tensor Core）+ Cluster（通用计算单元，对标 CUDA Core）；Cluster "支持 SIMD"。

9.2--9.4 转换 / 自定义算子 / CUDA 复用

【未验证】关键论断："实际适配以昆仑芯 SDK 软件栈为入口，C++ 扩展 + 类 CUDA 三段式 <<<>>> 启动语法"。

⚠️ 该来源另有大量无法交叉验证的性能断言（如"昆仑芯 Cluster...8 个 Cluster，每 Cluster 64 core"、SDNN 提供 128 TFLOPS@FP16、"128 TOPS@FP16 算力"与前述"256 TOPS@INT8"并列等），内部数字互相矛盾，判定为 AI 生成内容，不采信。

若"类 CUDA 三段式语法"属实 ，则语法层可复用，但执行模型（SDNN 张量单元 + Cluster 通用单元分离，类达芬奇架构）意味着 kernel 仍需重构 → 倾向路径 B/C 之间，须实测。

9.5 已知踩坑

【媒体转述｜新华网 2026-08-28】"目前已开发近百个加速库，并形成覆盖通信、编译、驱动、量化和性能分析的工具体系"（该句在天数智芯语境，昆仑芯无对应）。

---

信息缺口（必须在报告中显式列出）

高优先级缺口（直接影响选型结论）

#	缺口	影响	建议动作
G1	没有任何平台提供 TensorRT Plugin 的对位物。 唯一近似是沐曦 MacaRT 的自定义 ONNX 算子注册	用户 30--50% 的工程量在此	必须专项 PoC：选 1 个最简单的 plugin，在目标平台重建
G2	没有任何平台提供 .plan engine 的对位物。 所有平台都需重建 engine 构建/加载链路	序列化方案需重新设计	评估各平台 engine 文件的版本绑定与分发机制
G3	海光是否存在 TensorRT 兼容库（TENSOR_RTX）：未找到任何证据	决定海光能否低成本承接 TensorRT 栈	向海光销售/光合社区直接确认
G4	海光 TENSOR_RTX / 壁仞 biue / 寒武纪 CNCERT+bnnc / 海光 DtkOperator / 燧原 kernel 开发入口：均未找到存在证据	任务表格中的组件名可能不准	逐项向厂商确认后再写入报告
G5	沐曦 mcc 是否支持直接编译 .cu CUDA 源码：未验证，且现有证据倾向于否	用户最关心的问题	索取 MACA 开发者文档，要求提供自定义 CUDA kernel 迁移的官方说明与实测
G6	CNRT / MagicMind 的 C++ API 官方文档未找到	寒武纪无法做 C++ 接入评估	访问 neuware.cn 开发者站点
G7	天数智芯 IxRT 的 API / 命令行 / .ixrt 格式：全部未验证	无法评估	官方站仅见产品页，技术文档可能需登录开发者社区
G8	昇腾 ATC 支持的 ONNX opset 上下限：官方未声明	影响导出策略	查 CANN 官方"如何确定原始模型中的算子与昇腾支持的算子的对应关系"FAQ 条目

中优先级缺口

#	缺口	平台
G9	profiler 工具的具体名称与 CLI 用法未验证	沐曦、天数智芯、燧原
G10	自定义算子开发入口的完整 API 未验证	壁仞、燧原
G11	动态 Shape / 大 batch 性能塌陷的一手实测记录（尤其昇腾、寒武纪）严重不足	全部
G12	"原 CUDA kernel 源码编译到国产卡"的一手实测（编译成功/失败 + 性能对比）几乎全网缺失	全部
G13	大 batch / 多路视频并发场景的性能对比数据缺失（现有数据均为单流 LLM 或 CV 单帧）	全部
G14	hipify-clang 对含 warp shuffle / 原子操作 / 复杂 template 的 kernel 转换成功率未验证	海光
G15	--amdgpu-target=gfx906 对海光 DCU 是否适用未验证	海光

方法论建议（给报告作者）

1. 不要引用百度智能云系列"国产 AI 芯片与 PyTorch 生态融合/融合生态"文章------已验证含硬性事实错误（昇腾 NVLink）
2. 不要引用 CSDN《信创及国产化集成开发·昆仑芯适配》------公式化生成，内部数字自相矛盾
3. 公司财报 / 招股书 / 发布会稿中的性能数字（如"单机性能翻倍"、"Token 成本减半"、"95% 算子复用"）应全部标注为厂商自述，不可作为工程判断依据
4. 本报告的"路径 A/B/C"判定应配一份"证据强度"标注：海光 = 强（社区实测 + 官方工具链自洽）；昇腾/寒武纪 = 强（官方文档实证）；沐曦/摩尔线程 = 中（厂商口径为主，缺一手 kernel 实测）；天数智芯/燧原/昆仑芯 = 弱

---

附录：来源清单

【官方文档】

标题	URL	日期/版本
基于 Kernel 直调工程的算子开发（Ascend C 入门）CANN 社区版	https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/80RC2alpha002/devguide/opdevg/ascendcopdevg/atlas_ascendc_10_0005.html	CANN 8.0.RC2.alpha002｜HTTP 200 已验证
配置环境变量 - AOE 调优（AOE 工具 Ascend RC）/ ATC 参数总表	https://www.hiascend.com/document/detail/zh/canncommercial/80RC1/devaids/auxiliarydevtool/aoerc_16_0009.html	CANN 商用版 8.0.RC1
寒武纪推理加速引擎 MagicMind（产品页）	https://cambricon.com/index.php?a=lists\&catid=378	未标注日期
MagicMind 产品页（备用域名）	https://www.cambricon.com/index.php?m=content\&c=index\&a=lists\&catid=378	未标注日期
MacaRT C++ API（沐曦开发者文档）	https://developer.metax-tech.com/api/client/document/preview/1360/split_files/macart_c_api.html	未标注｜HTTP 200 已验证
天数智芯官网（未找到 IxRT 页）	https://iluvatar.com/	---

【社区实测】

标题	URL	关键内容
国产化GPU信创适配海光篇：DCU系列DTK环境ROCm迁移实战	https://blog.csdn.net/wayle123/article/details/159479379	hipify-clang、API 对照表、DTK≠ROCM、环境变量、rocprof、踩坑表｜2026-03-26
海光DCU接入Kubernetes完整指南	https://blog.csdn.net/weixin_29234509/article/details/164893238	rocm-smi、dcu-device-plugin、vDCU、内核/glibc 绑定、非法指令
花几十万买加速卡，利用率不到50%？拆解海光DAS	https://devpress.csdn.net/amd/6a55d24010ee7a33f28d4de6.html	DAS 三层架构、LightOP、FastPT、LayerCheck、MIGraphX｜内容疑似 AI 生成，仅作线索
YOLO部署避坑指南：算子兼容性解决方案	https://2048ai.net/6a06df5c10ee7a33f272ce4e.html	昇腾算子不兼容清单、静态化导出、AIPP cfg
Atlas 300V 部署 YOLOv8 全流程	http://www.sheratonhq.com/news/122033	ATC 实战、后处理 FP32、型号区分
MogFace-large 部署：国产昇腾/寒武纪芯片适配进展	https://ascendai.csdn.net/69d4e8f272111d255bf80f62.html	atc --framework=5、acl Python、magicmind Python、动态 Shape 风险
实战指南：用 MagicMind 在寒武纪 MLU 上部署 YOLOv5	https://blog.csdn.net/weixin_28025327/article/details/158559703	magicmind docker、torch-1.9.0、export.py --dynamic
摩尔线程率先完成 YOLO26 深度适配	https://www.nxrte.com/zixun/64571.html	MUSA 推理引擎、torch_musa/torchada、AutoDL 镜像
摩尔线程正在把 MUSA 变成一场可移植性测试	https://cronfeed.work/zh/ai-china-moore-threads-musa-field-signal-synthesis-runtime-portability-2026q2	MUSA SDK v5.1.0、vllm-musa 组件与版本、后端切换局限｜2026-06-11
壁仞BIRENSUPA CUDA迁移成本3-5倍	https://m.toutiao.com/article/7652919963431060022	1600+ 算子、BR106/166 无 FP8/FP4、改 IR 代码｜自媒体，可信度中等
TensorRT 自定义算子插件实战（一）customScaledTanh	https://blog.csdn.net/weixin_43719763/article/details/166849598	IPluginCreator/IPluginV2DynamicExt/enqueue() 机制（本报告用作对照基线）

【媒体转述】

标题	URL	关键内容	日期
CUDA 再见了！寒武纪亮出软件全家桶	https://t.cj.sina.com.cn/articles/view/5703921756/153faf05c01902oxgk	BANG C、Triton 3.4、CNPerf/GUI、CNSantizer、CNAdvisor、CNNL/CNCV/CNCL、CntrainKit、CNCE、CNAnalyzeInsight、GPU Migration、PyTorch 2.1--2.8	---
抢占 AI 算力先机：寒武纪技术与业绩双突破	https://www.cfbond.com/2025/11/13/wap_991110426.html	DeepSeek-V3.2-Exp 适配、vLLM-MLU 开源、Triton+BangC	2025-11-13
深度拆解沐曦 MXMACA 软件栈功能	https://news.qq.com/rain/a/20251229A03E8E00?id=20251229A03E8E00	4490 仓库 / 4173 通过 = 92.94%；PyTorch 2.8 2650 算子；mcBLAS/mcDNN/mcFlashAttention；"自主指令集...自己的编程模型"	2025-12-29
沐曦股份：GPU 产品销量增长推动收入提升（半年报）	https://chenjingqiu@stcn.com/article/detail/4161705.html	MXMACA 支持超 6000 个 CUDA 应用、超 1000 模型原生适配	2026-08-30
沐曦在 WAIC 吸引十大开源社区入驻展台	https://wanyr.com/2026/07/muxi-attracts-top-ten-open-source-communities-to-settle-in.html	92% 开源项目零改动；单机 64 卡	2026-07
沐曦 MXMACA 软件栈研报解读（华创证券）	https://www.sgpjbg.com/labelsyh/muxigufenmxmacaruanjianzhanjianrongcuda.html	6000+ CUDA 应用、2200+ 算子、30 万+ 用户、5591 万 API、200+ 文档	2026-03
国产 GPU 突破！摩尔线程发布 Torch-MUSA v2.0.0	https://i.ifeng.com/c/8jDikrsdrZB	FP8、MUSA Graph 兼容 CUDA Graph、Triton-MUSA、PyTorch 2.2/2.5	2025-05-09
燧原科技對比華爲昇騰（技術架構與生態全景）	https://www.mexc.fm/zh-TW/crypto-pulse/article/enflame-vs-huawei-ascend-138663	GCU 架構、馭算 TopsRider、PyTorch/TF/PaddlePaddle 適配｜來源質量存疑	---
從「能用」邁向「好用」國產算力發展如何「闖關」	http://sh.xinhuanet.com/20260829/e6d1e4e7b6994235ab009f71d5ffc3f7/c.html	國產算力生態現狀、npu-smi/MindStudio 對標 nvidia-smi+Nsight、遷移成本高企共性問題	2026-08-29
天數智芯重磅公佈芯片四代架構路線圖	https://www.sh.chinanews.com.cn/swzx/2026-01-26/144270.shtml	400+ 模型、數千算子、100+ 定製算子、95% 算子復用、近百個加速庫	2026-01-26
天數智芯：解碼通用 GPU 領軍者的成長密碼	https://cnews.chinadaily.com.cn/a/202512/17/WS69426de6a310942cc49972cf.html	「兼容 CUDA 生態，客戶遷移成本降低 50% 以上」	2025-12-17
國產算力芯片如此被看好 產業鏈底氣何在	https://www.ce.cn/macro/more/202508/t20250827_2455523.shtml	兩條路線分類（GPGPU vs 自主生態）、IDC 出貨數據	2025-08-27
【實戰】CUDA 到 CANN 遷移踩坑和模型選型	https://blog.csdn.net/u014354882/article/details/159894559	遷移難度分層表（設備管理/數學庫/算子庫/通信庫/內存管理）；注意：該文含大量非技術內容（GPT-6 爆料等），僅取遷移難度表	2026-04

【明确排除的来源（事实错误）】

标题	URL	排除原因
国产AI芯片与PyTorch生态融合	https://cloud.baidu.com/article/4501086	称昇腾"节点内通过 NVLink 模拟实现零拷贝通信"------昇腾无 NVLink；birensai/PyTorch-BR100 仓库不存在
国产AI新势力：深度解析支持PyTorch的加速卡生态	https://cloud.baidu.com/article/4501350	同一作者，同类编造（CNTool/CNCC/CNAnalyzer 命名可疑）
【信创及国产化集成开发】第六篇 昆仑芯GPU芯片适配01	https://blog.csdn.net/weixin_49199313/article/details/163829729	高度公式化，内部数字自相矛盾（128 TFLOPS@FP16 与 256 TOPS@INT8 并列），疑似 AI 生成