GPU 横向融合：资源互补的观察与调度方法

本页整理与独立矩阵、向量和搬运任务共执行最接近的 GPU 工作。阅读重点是原来闲置的资源在哪里、融合怎样暴露并行、哪些竞争会抵消收益。这些机制与 Hexagon 的 HMX/HVX 有结构类比，但线程组织、异步队列和资源上限需要按 NPU 后端重新设计。

1. Tacker：整体忙碌掩盖了两类计算资源交替闲置

Tacker，HPCA 2022^[1]。论文 §III 的动机与 §IV–V 的设计最直接对应矩阵和向量互补。

观察。 在论文所测的任务共享策略中，Tensor Core kernel 与 CUDA Core kernel 常被串行或交替执行。总体活跃时间较高，但两类计算单元没有同时活跃；作者称之为 false high utilization。然而，直接把两个 kernel 的线程块拼起来也不一定有效：线程、寄存器、shared memory 的总需求可能降低共驻留，cache 竞争会使各任务变慢，统一返回时刻还可能拉长延迟敏感任务的时延。

优化思路。 Tacker 将 Tensor Core 与 CUDA Core 任务静态融合，并用 Persistent Thread Block 将原始工作映射到固定数量的 worker block，适应运行时输入对应的不同工作量。在资源限制下调整两类工作的份额，配合融合时长预测与 QoS-aware runtime，选择合适的融合版本；没有合适配对时执行原始 kernel。在线决策选择已准备的版本，静态编译负责构建融合实现。

与我们的问题对应。 HMX 和 HVX 的活跃时间要分别测量，整体 device busy 不能证明资源互补已经被利用。最值得迁移的设计是：把工作量与 worker 数量解耦、显式控制任务配额、计入共享资源竞争，并保留回退路径。一期可以先固定输入与任务对，暂时不引入完整的服务 QoS 管理。

2. Aker：互补性与最佳融合版本随工作量变化

Aker，IEEE Transactions on Computers 2025，2024 年在线发表^[2]。它扩展了 Tacker 的问题与方法。

观察。 互补资源不只出现在 Tensor Core 与 CUDA Core 之间：都使用 CUDA Core 的任务，也可能分别偏计算和偏访存。同一算子的资源特征还会受输入规模影响。融合增加并行的同时改变资源压力，因此一个固定版本未必适用于全部输入。

优化思路。 先按实际资源使用分类，优先考虑 Tensor Core＋CUDA Core、偏计算＋偏访存的配对；静态生成多个融合版本，预测其执行时间，再由自适应选择器与 QoS-aware manager 决定工作份额和原始/融合路径。其 runtime 还允许仅执行原始任务的一部分工作，避免必须把两个完整任务绑定到同一结束时刻。

与我们的问题对应。 “矩阵任务”“向量任务”是初始标签，画像应包含预处理、带宽、片上存储与时长。GEMM 如果需要大量 HVX packing，就可能与独立向量任务竞争同一资源。后续可以搜索 tile 大小、HVX worker 数和并发窗口；一期先测清固定配比的可行区间。

3. HFuse：划分工作份额，也划分同步域

Automatic Horizontal Fusion for GPU Kernels，CGO 2022^[3]。重点读 §II-B 的横向融合定义、§III 的变换与搜索、§IV-A 的实验基线。

观察。 GPU warp scheduler 可以在一个任务等待指令结果时发射另一个可执行 warp。独立任务拥有不同指令与资源需求时，共同执行可能增加 eligible warps，隐藏计算或访存延迟。若把两个任务的 barrier 扩大到整个融合 CTA，原本独立的工作就会被迫相互等待。

优化思路。 在同一 CTA 内为两个任务分配不同的线程区间，重映射各自的索引、区分临时状态，并将 barrier 限制到各自参与的线程集合。通过 profiling 搜索线程空间划分和寄存器使用配置，平衡并行度与资源压力。

对照观察。 HFuse 的实验将原始 kernel 放在不同 CUDA streams 中并发运行；还比较直接顺序组合和不经搜索的等份划分。它提供的证据是融合相对已有并发路径的增量，而非仅相对逐个串行 launch。

与我们的问题对应。 CUDA 线程区间需要换成 NPU 的 worker 或引擎配额，但独立同步域仍是关键：等待矩阵结果不应同时阻止无关的向量或 DMA 工作。线程数、缓冲区和任务长度都不能只按 1∶1 处理。

4. POD-Attention：真实独立任务与共驻留位置

POD-Attention，ASPLOS 2025^[4]。重点读 §3 的并发方法比较、§4 的调度与实现，以及 §4.4 的 persistent 实现讨论。

观察。 LLM serving 中，不同请求的 prefill attention 通常偏计算，decode attention 通常偏带宽；它们可以组成独立且互补的工作。普通 kernel 并发或简单 CTA 融合，无法保证两类任务落到同一 SM；细粒度组合还可能受 barrier 和长任务拖尾影响。同为 attention，并不意味着资源特征相同。

优化思路。 在同一 kernel 内组织 prefill 与 decode CTA。CTA 被放置到 SM 后，再依据所在 SM 的状态选择工作类型，使每个 SM 按合适比例推进两类任务。独立 CTA 保留自己的同步范围，配合 tile、shared memory 与 decode 分组调整，限制资源争用和拖尾。

与我们的问题对应。 应从图中独立分支、多请求或多 micro-batch 寻找真实任务对，并扫描工作量比例。GPU 的 SM-aware 放置机制不能直接用于 Hexagon；可迁移的是让互补工作使用同一已分配执行范围，并管理好各自的份额与完成状态。

论文还讨论了 persistent thread 实现：长期领取任务可以缓解拖尾，但仍需要知道应在何处运行哪类工作。驻留方式和资源调度是两个设计维度。

5. GoPTX：从共同执行推进到指令交织

GoPTX，DAC 2025^[5]。重点读 §III 的控制流合并与延迟感知 weaving，以及 §IV–V 的基线与资源分析。

观察。 两个任务已经处于共同执行范围，内部指令仍可能因为数据依赖而等待。只增加并发线程，并不保证指令发射持续有可执行工作。

优化思路。 在 PTX 层合并两个 kernel 的控制流图，再在保持各自依赖的条件下交织指令。用一个任务的独立指令填充另一个任务的等待区间，同时处理分支、同步和寄存器压力。涉及 barrier 的控制流合并必须避免形成相互等待。

实验边界。 论文在 A100 上比较双 stream 并发、顺序组合和 HFuse，采用标准化 launch 配置。测试包含毫秒级 kernel。因此，它支持“指令组织能带来额外收益”，不能把其配置或收益直接推广到原生调优的 NPU kernel。

与我们的问题对应。 一期先验证引擎级重叠。只有时间线显示进一步受指令发射或任务内部依赖等待限制时，才需要设计目标 NPU 的更细编译变换；PTX weaving 的具体实现不可直接迁移。

6. 共同方法与 NPU 迁移边界

可迁移原则	GPU 工作中的体现	NPU 原型需要回答的问题
按资源画像配对	Tacker/Aker 的异构计算与计算—访存互补	HMX 任务的 HVX/DMA 阶段是否与搭档竞争？
控制工作份额	PTB、线程区间、CTA 配比	worker 数、tile 和队列深度怎样分配？
缩小同步域	HFuse barrier、POD 独立 CTA	等待是否阻止了无关引擎继续执行？
控制共同驻留资源	寄存器、shared memory、cache	VTCM 和 DDR 带宽能否同时容纳任务？
保留回退与独立进度	原始/融合选择、任务片段、拖尾处理	短任务完成后能否释放 buffer，继续领取工作？
比较已有并发	HFuse、GoPTX 的 stream 基线	相对 QNN 图内重排或后端最佳并发，多暴露了什么？

Orion^[6] 为保留独立 kernel 的干扰感知调度提供参照。实验应同时比较“改善调度”与“融合后内部调度”，具体设置见一期实现与实验设计。

7. 核验范围

本次整理通过本地 Zotero 全文与作者公开 PDF 核查了上述五组工作的相关章节，并将关键设计及基线页渲染为 PNG 复核。Tacker/Aker 的描述包含本次可取得的全文设计，已不局限于摘要。本文按论文解释机制，不用未核查的源码标识符补充实现细节。

参考文献

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

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

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

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

[5] WU K, LIN Z, XI M, et al. GoPTX: fine-grained GPU kernel fusion by PTX-level instruction flow weaving[C]//Proceedings of the 62nd Annual ACM/IEEE Design Automation Conference (DAC). 2025: 1–7. https://doi.org/10.1109/DAC63849.2025.11132627

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

GPU 横向融合前序