NPU 多引擎执行：Hexagon 机制与平台边界
横向融合需要先确认目标后端已有的并发能力、资源获取范围和同步语义。本页以 Hexagon 为一期原型对象，再对照 Ascend 与 AMD XDNA。执行接口异步、两个任务同时提交、设备内部引擎重叠，是需要分别验证的三件事。
1. Hexagon：按阶段核对资源需求
| 资源 | 典型工作 | 横向融合前的检查 |
|---|---|---|
| HMX | GEMM、卷积、attention 矩阵乘 | 操作数布局与 VTCM 驻留是否准备好？获取资源后会保留多久？ |
| HVX | 反量化、packing、softmax、归约、逐元素运算 | 矩阵任务是否也需要这些阶段？worker 配额与等待是否影响 HMX？ |
| DMA | DDR 与 VTCM 间搬运、预取和结果传回 | 能否独立推进？完成事件与可见性语义是什么？ |
| 共享存储与控制 | VTCM、DDR 带宽、队列、调度线程 | 同时存活的 buffer、带宽与队列控制是否容纳两个任务？ |
矩阵任务可能包含向量预处理，向量任务可能受访存限制，copy 也可能实际使用 HVX。资源互补应依据测得的阶段画像，而非算子名称。已有编译基础中，Hexagon-MLIR[1] 使用 megakernel 改善 TCM 局部性，并组织多线程与 DMA 双缓冲；其展示范围与任意独立 HMX/HVX/DMA 任务的通用横向调度仍有差别。
2. 已有 Hexagon 后端中的异步与等待
以下只分析一个具体实现：llama.cpp Hexagon 后端固定提交 b9acf138a1e28ce1fc23b5a4fc4b12444b50f7ea。队列和上下文相关原始文件已按该 commit 抓取，核对了以下行号。
| 机制 | 源码证据 | 对原型的含义 |
|---|---|---|
| HMX 入队后返回 | hmx_queue_push() |
可以提交矩阵工作，再组织其他资源的任务；仍需处理队列满 |
| 独立 HMX worker | 任务执行和 QuRT 线程 | 队列中的矩阵任务按顺序推进；跨引擎重叠不等于多个矩阵任务同时运行 |
| FIFO 完成等待 | hmx_queue_pop_one() 与 hmx_queue_pop() |
取回等待最早任务；应避免在无关工作发起前就进入等待 |
| HMX 资源获取与释放 | 资源锁及队列控制处理 | 应核对锁的生命周期，以及其他执行路径使用资源的条件 |
| 向量工作队列调用包含等待 | work_queue_run_async() |
调用线程执行第一个子任务，并等所有子任务完成才返回；名称含 async 不能证明调用立即返回 |
| 执行状态集中在上下文中 | htp_context |
包含 HMX/worker 队列、每线程 DMA 状态和 VTCM 状态；并发调用完整算子需先验证这些状态的使用方式 |
上述机制支持一个可测试的原型：单一调度生产者先发起 HMX 工作，再推进独立 HVX 工作与搬运，最后在需要完成语义的位置等待。它没有自动证明两个完整算子可以并发调用，也没有证明共享 buffer 可以安全复用。
原有 attention 与 GEMM 的 tile 流水及运算迁移实例见五类收益与配套优化。这些实现提供引擎重叠的基础；一期还需单独验证独立任务之间的编排。
3. QNN HTP：已有图内重排，需要建立当前并发基线
QNN 的调度与分配文档qnn-scheduling说明：部分可使用后台资源的算子会拆成 launch/wait；分配 VTCM 后，最终调度器进一步重排运行列表，增加并行度。因此，不能把“所有 QNN op 都顺序执行”作为起点。应查明目标任务未重叠是因为未暴露异步能力、数据或地址冲突、资源需求、还是当前调度策略。
同一文档明确指出：不同时存活的 VTCM 数据可以分配重叠地址，这可能阻止原本可任意重排的两个算子交换顺序。扩大并行窗口就需要同步扩大 buffer 生命周期；额外存储与 spill/fill 成本应计入收益分析。
HTP 的 linting profiling 文档qnn-profile提供以下事件。表中名称是完整事件名前缀 QNN_HTP_PROFILE_EVENTTYPE_ 后的部分；具体可用性应按目标 SDK 与设备确认。
| 事件 | 官方含义 | 能回答的问题 |
|---|---|---|
NODE_OVERLAP |
main thread 上的 op 执行期间，至少一个后台 op 运行的时间 | 原路径是否已经存在后台重叠？ |
NODE_WAIT_OVERLAP |
main thread 等待某 op 时，其他未被等待的后台 op 运行的时间 | 等待期间其他工作是否仍推进？ |
NODE_RESOURCEMASK |
op 使用资源的 bitmask | 资源声明是否支持互补判断？ |
NODE_CRITICAL_BG_OP_ID |
与 main thread 或 HMX 上的 op 并行的 op ID | 应定位哪些并行任务？ |
这些事件用于理解后端调度；精确的 HMX/HVX/DMA 三引擎重叠仍需设备侧时间线和适用的计数器核对。仅能执行封装 graph binary 的应用，也未必具有修改内部 kernel、worker 和临时存储的权限。
4. 其他 NPU：调度范围需要分别定义
4.1 Ascend：AIC/AIV 队列与事件
HyperParallel-MoE[2] 将 tile 工作映射到 AIC 与 AIV，静态编码事件，在统一 launch 中驱动两类 worker。它提供了矩阵/向量异构资源显式编排的直接先例，设计分析见资源解耦与任务执行。
需要进一步对照目标后端已经支持的异构执行路径，再说明新方法增加的任务选择、配额、依赖或存储控制能力。整体 MoE 训练的通信与依赖流水不能直接作为独立任务对的收益证据。
4.2 AMD XDNA：空间分区、tile 与显式数据流
AMD XDNA 驱动文档xdna描述了按列划分的空间分区、workload context 和混合空间/时间共享，列上有用于 DDR 与 memory tile 间传输的 DMA。它的执行边界首先是分区和 tile fabric，不能直接照搬 HMX/HVX 的资源划分。
Dato[3] 在 AMD Ryzen AI NPU 和 FPGA 上将工作表达为任务图，以 stream/layout 类型显式描述通信与 sharding，先做虚拟映射，再生成符合硬件约束的物理映射。这说明任务与数据流已有编程基础；尚需单独证明目标 tile 上哪些计算通路具有可利用的资源互补。
XDNA 上对应的研究问题可以是：在同一执行分区内部，细粒度任务与 DMA 编排能否相对现有分区和多 context 路径获得额外收益？
4.3 Cloud AI 100：workload 限制与端侧 kernel 边界不同
Cloud AI 100 驱动文档qaic规定每个包含 HVX/HMX 的 NSP 同时运行一个 workload，多个 NSP 可以承担不同 workload。它支持分析“已分配 NSP 内部还有空闲资源”的可能性。该限制针对 Cloud AI 100 的 workload/NSP；不能扩大为 Snapdragon 上单 kernel 独占整颗 NPU。
5. 原型开始前需要回答的机制问题
| 问题 | 所需证据 | 对设计的影响 |
|---|---|---|
| 闲置在哪个边界产生？ | 提交、执行、wait 与引擎时间线 | 决定改提交路径、内部等待还是资源配额 |
| 发起后控制线程能否继续推进？ | 接口语义和最小并发实验 | 决定是否需要独立 worker 或拆分 launch/wait |
| buffer 是否同时有效且不冲突？ | 读写区间、scratch 与 VTCM 生命周期 | 决定独立分配、tile 大小及最大并发窗口 |
| 原路径已经能做到多少重叠？ | QNN 重排或后端最佳并发测量 | 决定融合的增量贡献 |
| 融合后短任务如何完成？ | 独立事件、资源释放与取工作行为 | 决定完成状态和后续调度粒度 |
截至本次整理，纳入的资料尚未确证一套面向 Hexagon、完整覆盖独立 HMX/HVX/DMA 三类任务通用横向调度并隔离其收益的方案。这个边界不排除厂商内部能力或其他未纳入的研究；贡献需要由具体机制与对照实验支持。
qnn-scheduling. Qualcomm. Scheduling and Allocation. https://docs.qualcomm.com/doc/80-63442-10/topic/scheduling_and_allocation.html （访问日期：2026-10-11）。 ↩
qnn-profile. Qualcomm. QNN HTP profiling 事件的官方定义与说明。https://docs.qualcomm.com/doc/80-63442-10/topic/api-rst_program_listing_file_include_QNN_HTP_QnnHtpProfile_h.html （访问日期：2026-10-11）。 ↩
xdna. The Linux Kernel documentation. AMD NPU and XDNA architecture，包含空间分区与 mixed spatial and temporal scheduling。https://docs.kernel.org/accel/amdxdna/amdnpu.html （访问日期：2026-10-11）。 ↩
qaic. The Linux Kernel documentation. Qualcomm Cloud AI 100，NSP 与 workload 执行范围。https://docs.kernel.org/accel/qaic/aic100.html （访问日期：2026-10-11）。 ↩
参考文献
[1] ABSAR M J, BASKARAN M, SHARMA A, et al. Hexagon-MLIR: an AI compilation stack for Qualcomm's neural processing units (NPUs)[J/OL]. arXiv preprint arXiv:2602.19762, 2026. https://arxiv.org/abs/2602.19762
[2] JIN Z, AI C, ZHANG G, et al. HyperParallel-MoE: multi-core interleaved scheduling for fast MoE training on Ascend NPUs[J/OL]. arXiv preprint arXiv:2605.23764, 2026. https://arxiv.org/abs/2605.23764v2
[3] FANG S, CHEN H, ZHANG N, et al. Dato: a task-based programming model for dataflow accelerators[J/OL]. arXiv preprint arXiv:2509.06794, 2025. https://arxiv.org/abs/2509.06794
© 2026 Yang Huan · yanghuan9812@qq.com