别等这波 AI 算力浪潮过去才后悔:CANN 应该学什么?

别等这波 AI 算力浪潮过去才后悔:CANN 应该学什么?

别等这波 AI 算力浪潮过去才后悔:CANN 应该学什么?

在这里插入图片描述

昇腾 CANN 这几年是真在 “狂飙”,生态越做越大、功能越来越多、文档越写越厚…… 但问题也随之出现:

CANN 支持 Python、C++、AscendCL、TBE、MindSpore、PyTorch Frontend、Kernel DSL……这么多"语言",到底学哪个?从哪入门?

别急,今天就给你一次性讲透,看完不再迷茫。

CANN 语言体系到底有多复杂?

在这里插入图片描述

整个 CANN 软件栈由多层 API 和 Kernel 构成,所以才会出现一堆「看似不同,实则分工明确」的语言接口

为了简化理解,我们可以把它粗暴分成三层:

  • 高层:框架调用 — 类似 PyTorch、MindSpore 训练推理
  • 中层:算子 API 调用 — AscendCL、ACL Python、算子编写接口
  • 底层:kernel 语言 — TBE、C++ Kernel、融合算子 DSL

这么拆完,你会发现: 它们不是重复,而是分工不同。

那哪个是你一定要学的?下面直接给你一张"版本更新一样的简表",看完就知道你属于哪类!

如果你只是"做模型推理":Python(ACL Python)就够了

在这里插入图片描述

适用场景:

  • 部署 YOLO
  • 部署大模型
  • ONNX 转 OM
  • 简单前后处理

为什么它值首推? 因为 Python ACL 是官方主推、最简单、最快上手的一套部署 API。你不会接触复杂内存、流、Device buffer,也不用写 Kernel。

一句话总结:

你不是搞算子的,用 Python ACL 就够了。

如果你要做"深度部署 + 自定义流程":C++ AscendCL 必须学

在这里插入图片描述

适用场景:

  • 性能要求高
  • 大规模离线服务
  • 推理服务并发、异步、流水线
  • 自己写 DVPP / AIPP / Memory Pool 管理

为什么必学? 因为真实部署场景里:

  • Python 慢
  • 多线程不友好
  • 高并发时不稳定

C++ AscendCL 是 CANN 最稳、最强、最接近硬件的调用方式。

一句话总结:

做真正的工程化推理,C++ ACL 是你必须掌握的语言。

如果你是"算子开发者":TBE 或 C++ Kernel 必学

这类人最少,但工资最高(你懂的)

CANN 的算子开发分两类:

(1)TBE(Tensor Boost Engine) :偏向静态图 + 大量已有模板,适合:Conv2D、Softmax、MatMul、BatchNorm已有算子二次开发

(2)C++ AICore Kernel(更底层) :偏硬件、写 AI Core 的 kernel pipeline,适合:复杂融合算子手写 pipeline算子性能极限优化AICore scheduler 调优

一句话总结:

TBE = 快速开发;C++ Kernel = 极致性能。

如果你未来想往昇腾、GPU、NPU 算子岗发展,这块是必修课。

如果你是"框架训练端开发":MindSpore 或 PyTorch Adapter

CANN 的训练侧主要依托两条路线:

  • MindSpore(原生最佳) :CANN 和 MindSpore 一家亲 ,用原生能力、全栈功能,MindSpore 体验最好
  • PyTorch 前端(适合本来就用 PyTorch 的人) AutoGrad、OpBuilder、AOT、动态图转图优化都是可用的

总结一句:

训练:MindSpore 最稳;PyTorch 最方便。

到底该学哪个?给你一个最清晰的选型图

你只做模型部署?
学:Python ACL

你要做企业级推理服务?
学:C++ AscendCL

你要做自定义算子?
学:TBE + C++ Kernel

你搞训练?
学:MindSpore / PyTorch Frontend

你是科研学生?
学:Python ACL + PyTorch Frontend(最通用、性价比最高)

未来趋势:CANN 语言生态正在逐步"收敛"

在这里插入图片描述

未来几年 CANN 的语言路线会更清晰:

  • Python → 上层易用封装
  • C++ ACL → 核心部署接口(长期稳定)
  • TBE/C++ → 算子强相关,长期保持底层能力
  • MindSpore → 训练路径主力
  • PyTorch → 长期兼容前端生态

一句话总结:

路线已经很明确了:上层简单、底层增强、接口稳定。 不会出现 “学了白学” 的情况。

最后一句总结

在这里插入图片描述

作为正在入门 CANN、同时接触昇腾与 GPU/NPU 双生态的新手,我越来越能感受到:**CANN 之所以“语言多”,不是为了为难我们,而是因为每一层都有它存在的价值。**搞清楚自己要做什么,选对应的一两门开始学,完全不会走弯路。其实可以这样理解:

  • **如果你只是想把模型跑起来:学 Python ACL 就足够了。**上手快、成本低、不需要理解底层,完全新手友好。
  • **如果你想做真正能上线的工程部署:Python + C++ 是必须的组合。**Python 写流程、C++ 保性能与稳定性,后期维护也更放心。
  • **如果你未来想往深度技术、算子方向走:TBE + C++ Kernel + ACL 缺一不可。**这是最吃技术也最值钱的一条路线,但不需要一开始就全学。

CANN 不需要你一次学会所有语言,选对起点更重要。随着项目深入,你自然会从"会用"走向"能调",越学越强,价值也就越高。

最后我想说:

互联网的每一波技术浪潮,都曾给无数新人机会:

HTML 出来的时候,你可能没赶上

Java 崛起的时候,你可能还在观望

但这一次不一样——AI 架构下的算力语言体系正在重新洗牌,CANN 正处在“从小众到主流”的关键窗口。

现在入场,不算晚,甚至恰恰是最好时机

抓住这一波,你学到的不止是 API,而是一整套面向未来的算力思维方式

技术浪潮不会等人,但这一次,你完全来得及。

Read more

【图文】Windows + WSL + Ubuntu 安装 OpenClaw 全套流程(飞书机器人 + 百炼模型)

目录 * 一、安装 WSL * 二、安装基础组件 * 三、安装 Node.js(通过 nvm) * 1 安装 nvm * 2 安装 Node * 四、安装 OpenClaw * 五、OpenClaw 初始化配置 * 六、Hooks 配置(重要) * 七、打开 Web UI * 八、安装飞书插件 * 九、第三方飞书插件(备用方案) * 十、飞书权限配置(注意先做好飞书机器人设置,再配置channel) * 十一、配置飞书channel * 十二、配置飞书回调事件 * 十三、重启 OpenClaw * 十四、配置百炼模型

机器人标准DH(SDH)与改进DH(MDH)

机器人标准DH(SDH)与改进DH(MDH)

首先说一下为什么要写这一篇博客,就是为了提醒大家要明确区分标准DH和改进DH。很多机器人初学者只知道用DH法建立串联机器人连杆坐标系,然后在看书或者使用DH的时候很糊涂的就模糊了这标准DH和改进DH的区别,最大的坑就是:一些比较老的机器人学教科书用的是标准DH,而现在比较新的机器人书或者说我们大部分用的都是改进DH,这就导致老的教科书里面的一些公式推导和新的网上找的代码不一致,就会比较麻烦。 一:改进DH法 建立连杆坐标系: 使用改进D-H参数,将 坐标系定义在i 连杆的前端关节: 二:标准DH与改进DH法的区别 我们知道一个连杆有两端,一端离基座近,一端离基座远。简单的来说,标准DH将坐标系i建立在连杆i离基座近的一端,改进DH建立在离基座远的一端。 2.1 机器人连杆与关节的标号 先标号,再建系。 连杆编号:基座为杆0,从基座往后依次定义为杆1,杆2,…,杆i; 关节编号:杆i离基座近的一端(近端)的关节为关节i,远的一端(远端)为关节i+1。 为便于理解,这里我把连杆的近端用绿色表示,远端用橙色表示,且远端驱动近端转动。大家只要记住一句话,连杆近端关节

【全网最全・保姆级】Stable Diffusion WebUI Windows 部署 + 全套报错终极解决方案

大家好,我是在部署 SD WebUI 过程中把几乎所有坑都踩了一遍的选手,从 Git 报错、模块缺失、依赖冲突到虚拟环境异常,全部踩完。今天把完整安装流程 + 我遇到的所有真实错误 + 一行一解全部整理出来,写成一篇能直接发 ZEEKLOG 的完整文章。 一、前言 Stable Diffusion WebUI 是目前 AI 绘画最主流的本地部署工具,但 Windows 环境下因为 Python 版本、虚拟环境、Git 仓库、依赖包、CLIP 编译 等问题,90% 的新手都会启动失败。本文包含: * 标准 Windows 一键部署流程 * 我真实遇到的 10+ 种报错 * 每一种报错的 原因 + 直接复制可用的命令 * 最终测试出图提示词(

高原无人机测试:稀薄空气下的飞行控制算法

高原无人机测试:稀薄空气下的飞行控制算法

高原环境的独特挑战与测试必要性 高原环境(如青藏高原)以稀薄空气、低温、强风切变和低氧条件著称,这些因素对无人机飞行控制算法构成极端考验。空气密度仅为海平面的50%-60%,导致升力不足、动力衰减和传感器漂移,直接影响姿态稳定性和导航精度。软件测试从业者需关注算法在高海拔下的鲁棒性验证,因为传统测试方法无法覆盖这些动态干扰场景。例如,稀薄空气会放大控制延迟和误差累积,可能引发失控事故。通过专业化测试,可确保算法在真实高原场景中的可靠性,避免因环境变异导致的系统失效。 一、高原环境对飞行控制算法的影响机制 高原的物理特性直接影响飞行控制算法的核心模块: * 动力与升力衰减:稀薄空气降低螺旋桨效率,需更高转速维持升力,但电池在低温下(如-20℃)放电效率下降30%-40%,导致算法需动态调整动力输出阈值。测试中需模拟空气密度梯度(如从海拔0m到5000m),验证PID控制器能否实时补偿扭矩失衡。 * 传感器干扰与导航漂移:低氧和强紫外线加剧IMU(惯性测量单元)的噪声漂移,GPS信号在高山峡谷中易被遮挡,造成位置误差放大。例如,稻城高海拔测试中,无人机在3500米处GPS定位漂