0
0

昇腾软件栈分层：Firmware、Driver、CANN 与 Tiling 下沉

2026-10-17
硬件、算子与编译

整理日期：2026-09-14。来源：当天可见聊天摘要；原理说明为整理时补充，非完整对话逐字稿。未取得的设备参数与未验证的结论明确保留为待核实。

用职责理解软件栈

Firmware 负责设备侧底层运行与管理的一部分；Driver 建立 Host 操作系统与设备的控制、内存和任务交互通道；CANN 提供上层 AI 计算所需的运行时、算子与编译等能力。三者协同工作，简单比喻不能替代具体模块边界。

框架之上还有推理引擎的调度、KV 管理与并行策略。性能优化不是只能在最底层发生。

今天安装命令的含义

  • mkdir -p：创建目录，父目录不存在时一并创建。
  • cd：切换到保存安装包的目录。
  • wget：下载指定文件；URL 中 %20 表示空格。
  • chmod +x：赋予执行权限。
  • ./xxx.run --full：执行当前目录的安装包并选择该包定义的完整安装模式。

文件名中的 aarch64 表示 Host CPU 架构，不是 NPU 型号。26.1.1 与固件版本号属于不同版本体系，不能要求字符串相同。

**安装顺序不能仅凭聊天命令固定下来。**官方文档区分首次安装和覆盖升级，应查看当前 A3 包的配套关系、安装要求及是否需重启。官方安装说明

“是否都开源”应怎么查

应逐个确认仓库、许可证、对应版本、构建路径，以及是否仍依赖二进制组件。发布源码、提供安装包、开放 API 是不同的事实。

此次整理未完成 Driver/Firmware/CANN 全组件的许可证审计，因此不将“昇腾软件全面开源”扩写成“这三个层次的所有实现均可修改并完整重建”。这是今天问题中的待核实项。

Tiling 是什么

矩阵或张量往往大于片上缓冲，算子需要决定每次搬多少、每核处理哪部分、循环次数与尾块如何处理。Tiling 参数就是这类执行切分决策的一部分。

Tiling 计算本身也需要时间，并可能依赖运行时输入的具体数值。

Tiling 下沉为什么有意义

华为文档描述的具体方案，是将需要运行时计算的 Tiling 逻辑放到设备侧 AI CPU，减少整图下沉过程中返回 Host 的交互。它不是“把张量搬到更低级缓存”，也不是“让 AI Core 自动完成所有调度”。Tiling 调度优化官方说明

静态 shape 情况下，一些 Tiling 可在编译阶段预先完成；值依赖场景则可能需要运行时计算。这解释了为什么“已经有图模式”之后仍会出现下沉优化。CANN 模型下沉说明

极致优化是否必须研究固件

不必把“更底层”当作“必然更有收益”。应先用时间线定位：是 Host 调度间隙、算子访存、通信、KV 读取还是设备调度限制？

针对你的推理方向，先掌握 profiler、图执行、算子与通信之间的关系；只有证据指向固件职责、且具备接口和开发条件时，才深入该层。

**实验思路：**对比相同模型、shape 与负载下优化前后的 Host 活动、设备空闲段、算子时长、E2E 延迟，并同时校验输出。

合并补充：具体安装包与源码证据

当天提供的包名为：

Atlas-A3-hdk-npu-firmware_9.0.0.9.220.run
Atlas-A3-hdk-npu-driver_26.1.1_linux-aarch64.run

本次没有执行安装。--full 的具体行为以该包帮助为准，不应当作可以无条件重复执行的更新命令。

华为开源公告描述过分阶段开放计划；Runtime README提供运行时组件范围。公开组件源码与两个 HDK 包可完整重建是不同结论，后者仍待核实。

Tiling 优化、缓存、下沉与图执行

Tiling 优化决定如何分块；Tiling 缓存复用已有参数；Tiling 下沉改变计算位置；图执行改变任务组织与提交方式。下沉并不自动找到最优分块。

长矩阵计算已经占满设备时，下沉收益可能有限；短算子之间频繁等待 Host 时更值得分析。对照实验固定 batch、输入输出长度、版本和预热，检查 TTFT、token 间隔与正确性。

CUDA Graph 与昇腾图执行都涉及降低提交开销，但不是相同实现。端到端优化还需区分访存、通信、计算、调度和同步瓶颈。

参考：CANN Tiling 下沉、Ascend C Tiling 优化。

2026-09-16 增量：Runtime、HAL、算子并发与 FlashAttention

今天的问题链是：CANN Runtime 是否开源 → 暴露什么能力 → HAL 如何抽象硬件 → 数学简单为何 kernel 难 → 并发是否争抢资源 → Tri Dao 的 FA 在昇腾对应什么。

本次确认的开源范围

公开 Runtime README 明确列出设备、流、Event、内存和任务调度，以及性能采集、Dump、日志等组件。由此可以确认这些公开源码范围；不能扩展成“全部 Driver/Firmware 实现和固件构建链均已开放”。Runtime 仓库（2026-09-16）

学习调用链时，可按框架/算子调用、运行时任务组织、驱动交互、设备执行分层。HAL 的作用是把设备资源和提交/完成机制组织成软件接口；具体队列、地址空间、内存映射及同步结构，应按目标版本源码逐项确认。本次不把先前列出的所有 HAL 函数名视作已核实 API 清单。

算式短，数据与执行约束并不简单

kernel 除了实现数学，还需安排分块、布局、片上容量、搬运、同步、尾块、数值稳定及各种 shape。教学分析：同一 GEMM 算式，不同分块会改变复用次数和搬运量；过大的块也可能降低并发或超出片上资源。

不同 Stream 允许表达可并发任务，并不保证完全同时执行。计算单元、内存带宽、缓存和搬运引擎都是共享资源；两条单独很快的任务并发后，可能互相拖慢。应在同一时间线对比单跑与并跑，测总完成时间和关键路径，而不是把两项单跑吞吐直接相加。

FlashAttention 在昇腾的对应层次

Tri Dao 相关 FlashAttention 项目提供高效的精确注意力实现；核心研究对象是减少注意力的内存读写，并非把标准注意力替换成线性注意力。不同浮点执行顺序仍可能产生数值差异。官方项目

CANN 的 ops-transformer 提供 attention、MoE 和通算融合算子；可沿 FlashAttentionScore、prompt/incre/fused infer attention 等相关实现继续阅读。它们与 FlashAttention 在计算目标上相关，但不是 CUDA kernel 的逐行翻译，训练/推理、输入布局、KV 分页和量化支持必须逐项核对。最新仓库还包含其他注意力变体，不能把全部模型归到一个 FIA 路径。算子库；FlashAttentionScore 官方运行示例

实践从一个固定 shape 的注意力算子开始：核对数值参考，再找 tiling、数据搬运和计算流水，最后用 profiler 确认瓶颈。当前未在你的 910C 上执行 benchmark，也未核定某个服务实际选中了哪个 kernel。

2026-09-21—22 深化：从CMake找包失败追到运行时

问题起点包括找不到ASC配置、旧新构建写法、驱动25.0.rc1.2与CANN配套，以及ACL/aclnn/pybind11。

CMake configure阶段解析工程、定位依赖并生成构建规则；build阶段调用编译器；链接阶段解析符号；运行阶段才涉及动态库和设备。find_package的Config模式寻找包提供的配置文件，找不到不等价于驱动不支持算子。CMake官方find_package。

排查先记录CMakeLists写法与样例commit，确认安装包实际有没有对应Config.cmake，再检查搜索路径、环境脚本和旧CMakeCache。仅改路径无法让旧包凭空包含新构建接口。npu-smi版本不能代替CANN toolkit版本，也不能单独回答能否装CANN9.2；本次没有取得该组合官方配套矩阵，保持待确认。

ACL/AscendCL侧负责设备、内存、流等运行时调用；aclnn用于调用算子接口；Ascend C描述自定义设备计算；pybind11将C++接口暴露给Python。不存在“使用pybind11便自动把CPU NumPy变成NPU零拷贝张量”的保证。

NumPy的dtype/stride/生命周期和连续性必须满足绑定契约；forcecast或连续化可能分配副本。Tensor接口还要检查device与框架所有权，避免无意CPU↔NPU往返。pybind11 NumPy文档。

Tiling数据宏是生成声明/序列化等样板的源码机制，不是运行时动态魔法。若要确认BEGIN_TILING_DATA_DEF具体展开，读取当前toolkit头文件并看预处理输出；不把另一版本宏实现当当前事实。