国产 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 自动转换，同步原语/内建变量同名
沐曦 MACAB（官方未背书，风险高）官方口径仅"API 层面兼容 CUDA"；自研指令集；PyTorch 侧走 ONNX Runtime EP 而非 CUDA EP
摩尔线程 MUSABtorch_musa 后端字符串切换 + musaCC；MUSA Graph 声称接口兼容 CUDA Graph
天数智芯BIxDNN/IxRT + CUDA 兼容层；同为 GPGPU 路线，但无 kernel 级公开兼容承诺
昆仑芯B 的语法外壳 / C 的实质社区称"类 CUDA 三段式 <<<>>>"，但为自研指令集 + XPU 编程模型
昇腾 CANNCAscend C 是 C++，但内存模型与执行模型完全不同；<<<>>>/__global__ 仅为语法外观
寒武纪 BANG CCC/C++ 扩展 + MLU 专属 DSL（tensor 描述符、NRAM/VRAM 分区）
壁仞 BIRENSUPAC媒体实测反馈需改底层 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++ 语法外观，但内存模型与执行模型完全不同：

维度CUDAAscend C
线程模型warp（32 线程），threadIdx/blockIdx/blockDim无 warp 概念；blockDim 语义是"参与运算的核数"（官方样例 blockDim = 8 即 8 个核）
存储层级Global / Shared / RegisterGlobal Memory → Local Memory（LocalTensor）→ AI Core 内部存储
显式搬运不需要（编译器/缓存处理）必须显式 DataCopy，Global↔Local 是强制步骤
计算单元SM 内统一Cube / Vector / Scalar 单元分离，需分别映射
同步原语__syncthreads() / warp shuffleEnQue/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创建、编译和部署算子工程无（工程脚手架）
msopstST 测试，生成单算子上板测试框架无
opadvise算子调优建议无直接对标
AOE（Ascend RC）自动调优（DNN 训练类模型为主）无直接对标
MindStudioIDENsight 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 APIHIP API近乎一一对应（cudaMalloc→hipMalloc，见下方对照表）
nvcchipcc直接对应
cuDNNMIOpen功能对位
cuBLASrocBLAS / hipBLASLt功能对位
NCCLRCCL功能对位
nvidia-smidcu-smi功能对位
Nsight Systems / ncurocprof功能对位（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集群监管平台，十万卡级秒级采集
CNAnalyzeInsightGB 级日志秒级检索与根因诊断
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 将自定义算子库注册到 SessionOption[s]”

这是全报告中最接近 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 EPIxRTExecutionProvider ← 未验证

⚠️ 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 迁移的官方说明与实测
G6CNRT / MagicMind 的 C++ API 官方文档未找到寒武纪无法做 C++ 接入评估访问 neuware.cn 开发者站点
G7天数智芯 IxRT 的 API / 命令行 / .ixrt 格式：全部未验证无法评估官方站仅见产品页，技术文档可能需登录开发者社区
G8昇腾 ATC 支持的 ONNX opset 上下限：官方未声明影响导出策略查 CANN 官方"如何确定原始模型中的算子与昇腾支持的算子的对应关系"FAQ 条目

中优先级缺口

#缺口平台
G9profiler 工具的具体名称与 CLI 用法未验证沐曦、天数智芯、燧原
G10自定义算子开发入口的完整 API 未验证壁仞、燧原
G11动态 Shape / 大 batch 性能塌陷的一手实测记录（尤其昇腾、寒武纪）严重不足全部
G12"原 CUDA kernel 源码编译到国产卡"的一手实测（编译成功/失败 + 性能对比）几乎全网缺失全部
G13大 batch / 多路视频并发场景的性能对比数据缺失（现有数据均为单流 LLM 或 CV 单帧）全部
G14hipify-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.htmlCANN 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.htmlCANN 商用版 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/159479379hipify-clang、API 对照表、DTK≠ROCM、环境变量、rocprof、踩坑表｜2026-03-26
海光DCU接入Kubernetes完整指南https://blog.csdn.net/weixin_29234509/article/details/164893238rocm-smi、dcu-device-plugin、vDCU、内核/glibc 绑定、非法指令
花几十万买加速卡，利用率不到50%？拆解海光DAShttps://devpress.csdn.net/amd/6a55d24010ee7a33f28d4de6.htmlDAS 三层架构、LightOP、FastPT、LayerCheck、MIGraphX｜内容疑似 AI 生成，仅作线索
YOLO部署避坑指南：算子兼容性解决方案https://2048ai.net/6a06df5c10ee7a33f272ce4e.html昇腾算子不兼容清单、静态化导出、AIPP cfg
Atlas 300V 部署 YOLOv8 全流程http://www.sheratonhq.com/news/122033ATC 实战、后处理 FP32、型号区分
MogFace-large 部署：国产昇腾/寒武纪芯片适配进展https://ascendai.csdn.net/69d4e8f272111d255bf80f62.htmlatc --framework=5、acl Python、magicmind Python、动态 Shape 风险
实战指南：用 MagicMind 在寒武纪 MLU 上部署 YOLOv5https://blog.csdn.net/weixin_28025327/article/details/158559703magicmind docker、torch-1.9.0、export.py --dynamic
摩尔线程率先完成 YOLO26 深度适配https://www.nxrte.com/zixun/64571.htmlMUSA 推理引擎、torch_musa/torchada、AutoDL 镜像
摩尔线程正在把 MUSA 变成一场可移植性测试https://cronfeed.work/zh/ai-china-moore-threads-musa-field-signal-synthesis-runtime-portability-2026q2MUSA SDK v5.1.0、vllm-musa 组件与版本、后端切换局限｜2026-06-11
壁仞BIRENSUPA CUDA迁移成本3-5倍https://m.toutiao.com/article/76529199634310600221600+ 算子、BR106/166 无 FP8/FP4、改 IR 代码｜自媒体，可信度中等
TensorRT 自定义算子插件实战（一）customScaledTanhhttps://blog.csdn.net/weixin_43719763/article/details/166849598IPluginCreator/IPluginV2DynamicExt/enqueue() 机制（本报告用作对照基线）

【媒体转述】

标题URL关键内容日期
CUDA 再见了！寒武纪亮出软件全家桶https://t.cj.sina.com.cn/articles/view/5703921756/153faf05c01902oxgkBANG 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.htmlDeepSeek-V3.2-Exp 适配、vLLM-MLU 开源、Triton+BangC2025-11-13
深度拆解沐曦 MXMACA 软件栈功能https://news.qq.com/rain/a/20251229A03E8E00?id=20251229A03E8E004490 仓库 / 4173 通过 = 92.94%；PyTorch 2.8 2650 算子；mcBLAS/mcDNN/mcFlashAttention；“自主指令集…自己的编程模型”2025-12-29
沐曦股份：GPU 产品销量增长推动收入提升（半年报）https://chenjingqiu@stcn.com/article/detail/4161705.htmlMXMACA 支持超 6000 个 CUDA 应用、超 1000 模型原生适配2026-08-30
沐曦在 WAIC 吸引十大开源社区入驻展台https://wanyr.com/2026/07/muxi-attracts-top-ten-open-source-communities-to-settle-in.html92% 开源项目零改动；单机 64 卡2026-07
沐曦 MXMACA 软件栈研报解读（华创证券）https://www.sgpjbg.com/labelsyh/muxigufenmxmacaruanjianzhanjianrongcuda.html6000+ CUDA 应用、2200+ 算子、30 万+ 用户、5591 万 API、200+ 文档2026-03
国产 GPU 突破！摩尔线程发布 Torch-MUSA v2.0.0https://i.ifeng.com/c/8jDikrsdrZBFP8、MUSA Graph 兼容 CUDA Graph、Triton-MUSA、PyTorch 2.2/2.52025-05-09
燧原科技對比華爲昇騰（技術架構與生態全景）https://www.mexc.fm/zh-TW/crypto-pulse/article/enflame-vs-huawei-ascend-138663GCU 架構、馭算 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.shtml400+ 模型、數千算子、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芯片适配01https://blog.csdn.net/weixin_49199313/article/details/163829729高度公式化，内部数字自相矛盾（128 TFLOPS@FP16 与 256 TOPS@INT8 并列），疑似 AI 生成
# GPU
Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

cover

10月19日16点直播丨鲲鹏+昇腾+灵衢协同的Agentic RL参考实践

avatar 人工智能6S服务平台

DBX 的 OpenHarmony / HarmonyOS PC 适配记录

DBX基于Tauri 2、Rust与Vue 3，成功适配OpenHarmony/HarmonyOS PC端。通过切换至支持OHOS的Tauri修订，解决“被误判为Linux”问题，精准控制平台依赖与编译目标。构建链路复现于Windows环境，使用devecocli与ohrs工具链，实现ArkTS Ability、ArkWeb页面、系统文件与窗口接口的原生集成。实测在API 26 2in1真机上完成

avatar 人工智能6S服务平台
cover

开源聚力，筑梦鸿蒙 PC｜高校开源项目鸿蒙化适配与上架实践沙龙圆满收官

avatar 人工智能6S服务平台