资源解耦与细粒度任务执行：从独立任务对到 Megakernel
独立任务配对首先需要控制谁使用哪种资源、何时等待和何时完成。当执行范围扩大到算子链或任务图，关键是把完整算子边界拆成资源类型明确、依赖可追踪的工作单元。本页区分已有系统的观察与方法，以及适合我们采用的设计。
1. VDCores：按照真实依赖推进计算与搬运
VDCores，2026 预印本[1]。重点读 §4 的执行抽象与 §6.2.1 的 Auto Overlapping 消融。
观察。 GPU 已有异步矩阵计算与数据搬运能力，但传统 kernel 仍将它们装在同一个控制流里；程序员需要手工组织角色、流水和同步。若完成条件按整个任务处理，后续任务已经就绪的微操作仍可能无法发射。更细的异步硬件需要更细的依赖与资源描述。
优化思路。 将工作表达为带依赖的微操作流，映射到独立的软件虚拟执行单元：virtual memory cores（VMC）负责搬运，virtual compute cores（VCC）负责计算。runtime 按依赖是否满足和资源是否可用推进执行；通过虚拟流让 ready 微操作绕过其他流中停顿的操作，缓解队头阻塞。编译和执行器共同减少依赖检查及控制开销。
抽象边界。 当前主要拆分的是内存与计算；VCC 同时涵盖 SIMT 和矩阵计算。它没有直接验证 Hexagon 的 HMX、HVX、DMA 三域执行器。我们可以借鉴依赖与资源解耦，再按目标后端建立三类需求；不必机械地将每个引擎命名为一个虚拟核。
最值得借鉴的消融。 作者在同一 runtime 内把微操作依赖扩大为任务级发射屏障，禁止后续任务提前发射；恢复细粒度依赖后，跨任务重叠贡献了主要收益。再启用虚拟流，进一步减少队头阻塞。这为我们提供了清楚的评估方法：共用计算实现和入口，改变等待边界，观察性能与时间线。
对我们一期的启发。 首先把“发起”和“完成”分开，让矩阵、向量、搬运可以独立推进；两个固定任务不必先引入完整微操作生成器。更大的 ready task 集合和多流调度属于后续扩展。
2. HyperParallel-MoE：NPU 的物理资源解耦仍需软件暴露
HyperParallel-MoE，2026 预印本，本文依据 v2[2]。重点读 §2.3、§4.3–4.4 及 §5 的消融。
观察。 Ascend 提供矩阵导向的 AIC/Cube 和向量导向的 AIV/Vector，以及跨队列事件同步。但在作者所测的 Ascend MoE 训练路径中，完整 kernel 边界使矩阵与向量算子顺序运行，造成两类资源交替闲置。粗粒度通信同步也阻止了部分数据已经到达时提前开始计算。
优化思路。 将 MoE 算子分解为保留依赖的 tile 任务，根据资源类型生成 Cube Task Queue（CTQ）和 Vector Task Queue（VTQ）。编译期确定队列顺序、事件与完成阈值；同类工作按队列推进，跨队列用显式事件连接。在统一 kernel launch 内，AIC 和 AIV worker 独立领取对应工作，满足事件阈值后执行并发布完成信号。
这里选择静态调度：图结构、主要 shape 和并行配置较稳定，运行时主要承担取任务、等待和发布事件，避免对小 tile 反复进行动态选择。向量队列还承载部分数据搬运与通信；不能将论文中的通信全部解释为独立 DMA 引擎工作。
与我们的问题对应。 它是 NPU 上打破完整算子边界、显式驱动不同资源的直接先例。第一阶段可以借鉴“固定任务顺序＋独立执行域＋最小事件”的方式，先验证多引擎重叠。进一步的研究差异应具体体现为更通用的独立任务配对、资源份额选择、原 kernel 保留方式或存储规划。
收益边界。 整体系统覆盖分布式 MoE 的通信、矩阵、向量与依赖流水，整体加速不能直接当作独立矩阵＋向量横向融合收益。其串行观察也只对应所测软件路径，不表示所有 Ascend 后端都无法异构并发。
3. Rammer：统一算子间与算子内调度
Rammer，OSDI 2020[3]。
观察。 框架把算子视为不透明库调用，先调度算子，再依赖另一层调度处理算子内部并行。这种分层会隐藏跨算子的细粒度机会，并产生调度开销。
优化思路。 用硬件中立的 rTask 和硬件抽象暴露更丰富的调度空间，编译期联合利用算子间与算子内并行，生成静态时空调度。
与我们的问题对应。 若完整 GEMM 的预处理和矩阵计算使用不同资源，就可以进一步拆为任务片段，与其他 ready 工作联合组织。Rammer 的后端包括 NVIDIA GPU、AMD GPU 和 Graphcore IPU；其中 AMD GPU 结果不构成 AMD XDNA NPU 的证据。
4. PipeThreader：明确资源类型，再搜索流水
PipeThreader，OSDI 2025[4]。
观察。 Tensor Core、Tensor Memory Accelerator 等专用单元暴露了不同执行能力。高效流水需要同时理解计算依赖和资源结构，手工组织成本较高。
优化思路。 用 sTask 图表达细粒度计算，结合描述专用单元能力的分层硬件抽象与调度原语，将流水调度交给编译器搜索。原始任务仍保留依赖，软件负责决定各执行单元如何交错推进。
与我们的问题对应。 后续编译表示应能表达矩阵、向量、搬运的需求与完成条件，同时显式记录 buffer。独立任务对是一个简化实例；有依赖的 tile 流水扩大了优化空间，也增加了事件与存储规划成本。
5. MPK：把任务图放入持续运行的设备执行范围
MPK，OSDI 2026[5]。
观察。 逐算子 kernel 执行边界限制跨算子软件流水、细粒度通信—计算重叠以及全局任务调度。
优化思路。 编译器构建 SM 级任务图并生成任务实现，设备侧并行 runtime 在单个 persistent megakernel 内按依赖和分散调度执行，覆盖更大的推理程序与多 GPU 工作。
与我们的问题对应。 MPK 为未来处理依赖图和持续领取任务提供参照。一期静态任务对主要验证多引擎互补，其成立并不要求已经完成 MPK 式整模型编译。长期驻留能够减少外部任务边界，内部任务仍需有合适的资源与同步组织。
6. 为我们的执行器保留哪些信息？
以下是根据上述文献提出的设计建议，尚待在目标 NPU 上验证。
| 信息 | 一期最小需求 | 以后扩展时的用途 |
|---|---|---|
| 就绪条件 | 输入已就绪，任务对互相独立 | 由 tile 完成事件维护动态 ready 集合 |
| 资源需求 | HMX/HVX/DMA 使用、worker 与带宽需求 | 选配对、配额与原始/融合版本 |
| 缓冲区区间 | 输入、输出、scratch 分离，覆盖并发生命周期 | 与执行顺序联合规划、提前释放 buffer |
| 发起与完成 | 可继续推进其他任务；完成按任务记录 | 支持流水、多队列和后续任务释放 |
| 进度 | 长任务允许在合适边界分块 | 缓解拖尾、回填短任务与服务 QoS |
推进顺序可以是：固定独立任务对 → 独立三任务与配额搜索 → 多任务静态队列 → 动态 ready task 与依赖图。每一步都应测量新增管理成本与现有并发路径的增量收益，具体对照见一期实验。
7. 阅读证据范围
VDCores 和 HyperParallel-MoE 的动机、执行与消融描述已通过全文关键章节和页面图核验；Rammer、PipeThreader、MPK 此处依据 USENIX 正式论文页面与摘要，只概括其核心任务抽象，不据此推断未核查的底层实现。
参考文献
[1] HE Z, SAMPSON A, ZHANG Y, et al. VDCores: resource decoupled programming and execution for asynchronous GPU[J/OL]. arXiv preprint arXiv:2605.03190, 2026. https://arxiv.org/abs/2605.03190
[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] MA L, XIE Z, YANG Z, et al. Rammer: enabling holistic deep learning compiler optimizations with rTasks[C]//14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020: 881–897. https://www.usenix.org/conference/osdi20/presentation/ma
[4] CHENG Y, WANG L, SHI Y, et al. PipeThreader: software-defined pipelining for efficient DNN execution[C]//19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). 2025: 767–783. https://www.usenix.org/conference/osdi25/presentation/cheng
[5] CHENG X, ZHANG Z, ZHOU Y, et al. MPK: a compiler and runtime for mega-kernelizing tensor programs[C]//20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26). 2026: 1909–1926. https://www.usenix.org/conference/osdi26/presentation/cheng
© 2026 Yang Huan · yanghuan9812@qq.com