NPU 上的 Kernel Fusion：HVX↔HMX 的职责迁移与横向融合

本页讨论手机 NPU（以 Qualcomm Hexagon 为代表）上两个相互独立、又彼此耦合的问题：

1. 职责迁移：某个原本跑在 HVX（向量单元）上的计算，能否改写后交给 HMX （矩阵单元）执行，从而缓解 HVX 瓶颈？
2. 横向融合：能否把互不依赖的两个 kernel——一个偏重 HVX、一个偏重 HMX—— 合并到一次设备执行里并行运行？

前者是单算子内部的计算重映射，后者是跨算子的执行组合。已有文献分别覆盖了 两者，但把二者放到同一个 Hexagon 运行时里联合决策，仍是需要验证的研究方向。

1. 背景：Hexagon 的双计算引擎与 bubble

Hexagon NPU 内部有两类可用的计算资源，外加 DMA：

典型的推理流水里，HMX 计算前后往往夹着 HVX 的解包、反量化和输出转换。当这些阶段 串行执行时，时间线上会出现三类 bubble：

• HMX 等待 HVX 反量化 / 布局转换完成；
• HMX 在 softmax 阶段空闲（矩阵单元等向量单元）；
• HMX 等待权重从 DDR 搬入 VTCM。

llama.cpp 的 Hexagon 后端已经把 HMX 计算做成异步任务：hmx_queue_push() 提交后 立即返回，由专用 QuRT 工作线程执行，主流程继续组织 HVX 与 DMA；hmx_queue_pop() 按 FIFO 等待最早尚未取回的任务源码。

在 Hexagon 上做异步与流水已有工程和论文基础：EStream 在 MoE prefill 中把 DMA / HVX / HMX 逐 tile 流水，用双缓冲隐藏 UFS 加载^[3]；BigMoMo 借投机解码的 多 token 验证窗口聚合专家、交替权重缓冲，把 DMA 搬运与 HMX 计算重叠^[4]； Hexagon-MLIR 用 MLIR Async 表达 HVX 多线程并自动双缓冲^[2]；llada.cpp 面向 diffusion LLM 做 CPU–NPU 协同与内存流水^[5]。它们共同说明："在 Hexagon 上做异步/流水" 本身已有基础，但"跨独立任务在线融合 HVX/HMX"仍缺直接证据（见 §5）。

2. 方向一：把 HVX 的工作量转移到 HMX

2.1 哪些结构可以矩阵化

把向量计算改写成矩阵乘，依赖三类数学结构：

(a) 对角缩放 → 对角矩阵乘。 对整块输出做 per-row 系数缩放，可写成

$O_{\text{new}} = \mathrm{diag}(\alpha)\,O_{\text{old}} + PV$

llama.cpp 的 Hexagon attention 已经把 online-softmax 的重标定 $\alpha$ 与最终归一化 $1/\ell$ 交给 HMX 执行（hmx_fa_o_update_tile() / hmx_fa_o_norm_tile()）， HVX 只负责较小的非线性与归约状态（max、exp、sum、倒数、系数构造）源码。

(b) 归约 / 扫描 → 与全 1 向量或三角矩阵相乘。 求和可写成 $X\mathbf{1}$；更一般的 reduction / scan 可用张量单元表达，在矩阵单元空闲时借助其带宽收益^[10]。

(c) 算法重分块 → 把递推矩阵化。 不是替换单条指令，而是改变计算组织方式。例如 Gated Delta Net 在 Hexagon 上被组织成 chunk：状态相关乘法与分块三角求解的一部分交给 HMX，HVX 保留 prefix scan、exp、部分递推求解源码。

FlashAttention-T 是"把 softmax 交给矩阵单元"最直接的方法先例：它观察到矩阵单元 等向量单元造成的 vector interval，于是用 operand value assignment 复用张量 MMA 指令执行 softmax primitive（如逐元素缩放），再设计 tensor/vector 并行调度。在 Ampere 上 vector interval 比基线低 $1.17\text{–}2.18\times$，在 H100 上降到 2.7%^[6]。

2.2 与"减少 HVX 工作量"互补的另一条路

不迁移到 HMX，也可以直接减少 HVX 的工作量。这类工作与方向一正交：

• VFA 通过 key-block 重排与全局最大值预计算，降低 online-softmax 里 rowmax / 行和 归约与 rescale 链的频次，避免重复归约^[9]；
• FlashAttention-4 用软件模拟 exp 与条件 rescale，减少非 matmul 操作，把瓶颈从 softmax 移到片内带宽^[8]；
• FlashAttention-3 用 warp specialization 与跨迭代流水，交错 block-wise matmul 与 softmax，并把数据搬运与计算重叠^[7]；
• 在 Hexagon 上，Scaling LLM Test-Time Compute 指认了 softmax 与低比特权重的运行时 反量化是最重的 HVX 工作，并用 LUT 与硬件友好的 tile 量化去优化 HVX 本身 （混合精度 GEMM 最高 19.0×、softmax 2.2×）^[1]。

另外两类可作参照：Rake 用程序合成系统整理了一批 HVX 向量 kernel（Gaussian/box/ median 滤波、Sobel、dilation、色彩校正、softmax、normalization），可作为视频/CV 侧的 实验负载清单^[11]；FlashAttention-V 则说明当平台只有可伸缩向量架构（RVV/SVE）而 没有矩阵单元时，优化重点转向提高向量利用率与跨 head 打包——这与"迁移到 HMX" 是两条相反的应对路线^[12]。

2.3 能力边界与代价

两条特别重要的边界：

• 按输出通道的参数 ≠ 任意逐行动态系数。 HMX 的原生收尾支持 per-channel bias / scale 与 identity、ReLU 等 shaping，但 attention 的逐行缩放要靠 diagonal GEMM 单独实现。
• "HMX 原生低比特路径" ≠ "让 HMX 解包任意 GGUF 格式"。 沿 $K$ 维分组的 scale 一般不能简单挪成整次 GEMM 结束后的一份输出 scale，必须保留量化语义。

2.4 先估算收益上限

把同一流水任务在 DMA、HVX、HMX 上的资源服务时间记为 $D,V,M$。忽略启动/排空：

$S_{\text{ideal}} \le \frac{D+V+M}{\max(D,V,M)}$

若某两阶段任务中 HVX 占串行时间的 80%、HMX 占 20%，即使重叠得再理想，上限也只有 $(0.8+0.2)/0.8 = 1.25\times$。HVX 已是绝对瓶颈时，减少其工作量比增加重叠更关键。

3. 方向二：把独立的 HVX / HMX kernel 融合成一个 kernel

3.1 GPU 上的先例

"把矩阵单元任务与向量单元任务横向融合"本身不是新概念，GPU 上已有成熟系统：

其中 Tacker/Aker 最接近"跨任务 + 互补资源 + 在线 QoS"的系统目标；作者公开了 共同代码仓库（sjtu-epcc/Tacker）可作实现对照。 Orion 则是"只调度、不融合"的对照——用于回答"融合到底比充分并发多带来多少收益"。

3.2 Hexagon 上的执行语义

在 Hexagon 后端上，现有原语提供了基础，但不能直接并发调用两个完整算子：

• hmx_queue_* 允许提交不同的 {func, data} 任务，由 worker 顺序执行源码；
• work_queue_run_async() 实际是同步语义（见 §1 注意）；
• 同一 htp_context 的完整算子复用上下文、DMA 与 VTCM。

因此可行的工程路线是：

保留一个调度 producer
  └─ 把算子拆成可调度的 leaf kernels
       ├─ 为在飞任务分配独立的 VTCM 区间与 job 状态
       └─ 把 ready 的 HMX 阶段与 HVX 阶段组合执行

若只能调用封装好的 QNN graph binary、无法控制内部 kernel/线程/scratch，则现有公开证据 不足以支持"在线融合两个 binary"。研究原型更适合放在能控制 DSP 侧执行的 backend 中。

3.3 配对依据是"阶段资源需求"，不是两个标签

一个"HMX-heavy"的完整算子往往仍需 HVX 做前后处理，未必给另一任务留下 HVX 余量。 应为每个 tile/stage 建立 profile：

$p_i = (\text{HVX 需求},\ \text{HMX 需求},\ \text{VTCM 占用},\ \text{DMA 流量},\ \text{预计时长},\ \text{截止时间})$

运行时至少判断四件事：

1. 是否真正独立：输入/输出别名、状态更新、缓冲区回收依赖；
2. 是否有资源余量：给外部 HVX 任务分配后，不能饿死 HMX 任务自己的数据准备；
3. 存储与带宽：VTCM 地址不重叠只是正确性条件，不代表访问不争用；
4. 是否值得等待配对：没有合适伙伴时应能直接执行，不能让短任务空等。

对视频流，应预测整条链路而非只比较重叠区间：

$T_{\text{排队}} + T_{\text{等待配对}} + T_{\text{并发执行}} + T_{\text{剩余链路}} \le \text{deadline}$

4. 两个方向的耦合

方向一与方向二并非彼此孤立。当 HMX 空闲、HVX 繁忙时，把某段计算矩阵化可缓解 HVX； 但当另一任务已高度占用 HMX 时，同一段计算留在 HVX 反而更好。因此可以为同一算子 保留多个版本，运行时联合选择：

$\{\text{HVX 版本},\ \text{HMX 版本},\ \text{HVX/HMX 混合版本}\} \times \{\text{配对任务},\ \text{tile 大小},\ \text{HVX/VTCM 分配}\}$

目标是满足时延约束下的系统吞吐，而非单个算子最快。这解释了为何"统一迁移到 HMX" 不是正确答案：一个单独跑稍慢、但释放了紧缺 HVX 的版本，可能让更多视频任务满足截止时间。

5. 证据强度与空白

6. 建议的实验对照

1. 串行执行：基本参照；
2. 原 runtime 能提供的合法并发：现有能力已覆盖多少收益；
3. 相同在线调度 + 不融合 kernel：分离调度收益与融合收益；
4. 静态配对 / 固定资源比例：判断在线策略是否必要；
5. 在线配对 + 复合执行：验证方向二；
6. 再加入 HVX↔HMX 版本选择：验证方向一与方向二联合的增量。

指标应覆盖视频帧 p95/p99 时延、deadline miss rate、各任务 slowdown、总吞吐与能耗； 并用设备侧 trace 观察 HVX/HMX 空闲、HMX 等待数据、DMA 争用与 VTCM 压力。若引入 JIT，还需分别报告首次执行与缓存命中的结果。

源码与提交

本页涉及的 llama.cpp Hexagon 后端实现，固定到本次核查的提交 b9acf138 （b9acf138a1e28ce1fc23b5a4fc4b12444b50f7ea）：

• hmx-queue.c / hmx-queue.h： 独立 QuRT 工作线程、HMX 资源锁、异步提交与完成等待；
• matmul-ops.c： hmx_mm_2d_f32() 的 pipeline 分支、权重与输出双缓冲；
• flash-attn-ops.c 与 hmx-fa-kernels.h： QK、O-update 与 HVX softmax 的交错执行，以及对角 rescale / 归一化的 HMX tile；
• work-queue.c： work_queue_run_async() 的实际同步语义；
• gated-delta-net-ops.c： GDN 的分块 HMX 实现。

相关 PR：

• #21554（异步 HMX mat_mul）；
• #26049（消除 HVX/HMX/DMA pipeline bubble）；
• #29199（HMX 优化的 Gated Delta Net）。

参考文献

[1] HAO Z, WEI J, WANG T, et al. Scaling LLM test-time compute with mobile NPU on smartphones[J/OL]. arXiv preprint arXiv:2509.23324, 2025. https://arxiv.org/abs/2509.23324

[2] 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

[3] ZHANG J, ZHENG Z, WU F, et al. EStream: fast and memory-efficient MoE prefill through expert virtualization on mobile NPUs[J/OL]. arXiv preprint arXiv:2609.06551, 2026. https://arxiv.org/abs/2609.06551

[4] LI M, ZOU H, HAN T, et al. BigMoMo: efficient inference of large-scale MoE with speculative decoding on mobile devices[J/OL]. arXiv preprint arXiv:2609.14643, 2026. https://arxiv.org/abs/2609.14643

[5] WANG T, SUN Y, REN J. Efficient on-device diffusion LLM inference with mobile NPU[J/OL]. arXiv preprint arXiv:2606.13740, 2026. https://arxiv.org/abs/2606.13740

[6] XU J, WEN Y, BI J, et al. FlashAttention-T: towards fully tensorized attention by exploiting tensor-vector parallelism[C]//Proceedings of the 31st ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming (PPoPP). 2026. https://doi.org/10.1145/3774934.3786425

[7] SHAH J, BIKSHANDI G, ZHANG Y, et al. FlashAttention-3: fast and accurate attention with asynchrony and low-precision[C]//Advances in Neural Information Processing Systems (NeurIPS). 2024. https://arxiv.org/abs/2407.08608

[8] ZADOURI T, HOEHNERBACH M, SHAH J, et al. FlashAttention-4: algorithm and kernel pipelining co-design for asymmetric hardware scaling[J/OL]. arXiv preprint arXiv:2603.05451, 2026. https://arxiv.org/abs/2603.05451

[9] SUN Y, LI Y, ZOU Z, et al. VFA: relieving vector operations in flash attention with global maximum pre-computation[J/OL]. arXiv preprint arXiv:2604.12798, 2026. https://arxiv.org/abs/2604.12798

[10] DAKKAK A, LI C, XIONG J, et al. Accelerating reduction and scan using tensor core units[C]//Proceedings of the ACM International Conference on Supercomputing (ICS). 2019: 46–57. https://doi.org/10.1145/3330345.3331057

[11] AHMAD M B S, ROOT A J, ADAMS A, et al. Vector instruction selection for digital signal processors using program synthesis[C]//Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 2022: 1004–1016. https://doi.org/10.1145/3503222.3507714

[12] GUPTA S R, PAPADOPOULOU N, PERICÀS M. FlashAttention for scalable vector architectures[J/OL]. arXiv preprint arXiv:2608.18656, 2026. https://arxiv.org/abs/2608.18656

[13] ZHAO H, CUI W, CHEN Q, et al. Tacker: tensor-CUDA core kernel fusion for improving the GPU utilization while ensuring QoS[C]//Proceedings of the 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA). 2022: 800–813. https://doi.org/10.1109/HPCA53966.2022.00064

[14] ZHAO H, DENG J, CUI W, et al. Adaptive kernel fusion for improving the GPU utilization while ensuring QoS[J]. IEEE Transactions on Computers, 2025, 74(2): 386–400. https://doi.org/10.1109/TC.2024.3477995

[15] LI A, ZHENG B, PEKHIMENKO G, et al. Automatic horizontal fusion for GPU kernels[C]//Proceedings of the 2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). 2022: 14–27. https://doi.org/10.1109/CGO53902.2022.9741270

[16] KAMATH A K, PRABHU R, MOHAN J, et al. POD-Attention: unlocking full prefill-decode overlap for faster LLM inference[C]//Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 2025. https://arxiv.org/abs/2410.18038

[17] PÉREZ V, SOMMER L, LOMÜLLER V, et al. User-driven online kernel fusion for SYCL[J]. ACM Transactions on Architecture and Code Optimization, 2023, 20(2): 1–25. https://doi.org/10.1145/3571284

[18] YADAV R, SUNDRAM S, LEE W, et al. Composing distributed computations through task and kernel fusion[C]//Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 2025. https://arxiv.org/abs/2406.18109

[19] STRATI F, MA X, KLIMOVIC A. Orion: interference-aware, fine-grained GPU sharing for ML applications[C]//Proceedings of the Nineteenth European Conference on Computer Systems (EuroSys). 2024: 1075–1092. https://doi.org/10.1145/3627703.3629578

[20] ZHANG Z, MO Z, ZHAO Y, et al. Deep kernel fusion for transformers[C]//Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (ACL). 2026: 166–173. https://doi.org/10.18653/v1/2026.acl-short.15

© 2026 Yang Huan · yanghuan9812@qq.com