本篇选取 3 篇相关论文，覆盖 persistent megakernel + chiplet-aware L2 优化、GPU DMA 引擎通信 offload、chiplet NUMA-aware attention 调度，与 GPUOS 在 "GPU 执行效率优化" 这一核心问题上形成多维对比。三篇论文从不同角度回应了同一时代命题——当 GPU 架构从 monolithic die 演进到 chiplet、当 workload 从大 batch 训练演进到 micro-batch serving 时，传统的 "one operation = one kernel launch" 编程模型和 "L2 cache = uniform shared resource" 的假设同时失效，各论文分别在调度层、通信层、存储层提出解法。
Fleet: Hierarchical Task-based Abstraction for Megakernels on Multi-Die GPUs (2604.15379) — 与 GPUOS 共享 persistent kernel 的核心哲学（"launch once, dispatch many"），但目标完全不同：Fleet 以 chiplet-aware L2 cache 复用为主要优化轴，通过 M-major 协作式 tiling 让同 XCD 内多个 worker 共享权重列，在 AMD MI350 8-XCD 架构上实现 bs=32 时 L2 hit rate 从 39% 提升到 51%、HBM 读降 37%；GPUOS 以 CPU-GPU launch boundary 消除为主要优化轴，通过 ring buffer + device function dispatch 将 per-op 提交延迟从 3-7 μs 压缩到 <100 ns。两者消除 kernel launch 开销的路径截然不同——Fleet 用静态编译的 megakernel + task graph 预定义所有 operator，GPUOS 用 NVRTC JIT + dual-slot aliasing 实现 runtime 动态 operator injection。Fleet 绑定 AMD CDNA3/4 的 XCD 拓扑和 per-instruction cache modifier，GPUOS 绑定 NVIDIA 的 NVRTC/PTX/CUDA Driver API。Kind: related。
Optimizing ML Concurrent Computation and Communication with GPU DMA Engines / ConCCL (2412.14335) — 与 GPUOS 解决同层级问题（GPU 执行效率），但切入点正交：ConCCL 解决计算-通信并发时 CU 资源竞争，将 collective 操作 offload 到 DMA 引擎以消除 compute interference（baseline 21% → ConCCL 72% of ideal speedup）；GPUOS 解决 host-device 边界的高频穿越开销，将调度从 host 迁移到 device 以消除 launch overhead。两者都属于"减少协调开销"的大论题——ConCCL 减少的是 GPU 内部 CU-to-CU 的资源争抢协调，GPUOS 减少的是 CPU-to-GPU 的命令下发协调。在 multi-GPU serving 中两者可组合使用：GPUOS 消除单 GPU 内的 per-op launch 开销，ConCCL 消除 GPU 间通信对计算的干扰。Kind: related。
Optimizing Attention on GPUs by Exploiting GPU Architectural NUMA Effects / NUMA Attention (2511.02132) — 与 GPUOS 共享"利用 GPU 架构特性消除性能瓶颈"的方法论，但在架构层级上完全不同：NUMA Attention 利用 MI300X 8-XCD 的 L2 cache 分区特性，通过 workgroup swizzle 将同一 attention head 的 blocks 映射到同一 XCD 以实现 L2 复用（L2 hit rate 从 ~1% 提升到 90-97%，性能提升 50%）；GPUOS 利用 CPU-GPU 边界的固有开销结构，通过 persistent kernel 将 per-op 调度从 μs 级降到 ns 级。NUMA Attention 的优化是"让数据流向正确的缓存"，GPUOS 的优化是"让命令不再穿越昂贵的边界"。两者针对不同的架构瓶颈——一个是存储层级的 NUMA 效应，一个是控制路径的 launch 开销。Kind: related。
GPUOS 的核心 delta 是 persistent kernel + runtime dynamic operator injection 的组合——在消除 kernel launch overhead 的同时保持了 production-grade 的灵活性（零停机热更新 operator、PyTorch eager mode 透明集成）。相比 Fleet 的静态 megakernel（需要编译时确定所有 operator）和 CUDA Graphs 的 capture-replay（需要 shape 稳定），GPUOS 用 NVRTC JIT + dual-slot aliasing + version counter 实现了"消除 launch 但不牺牲动态性"的独特价值定位。相比 ConCCL 和 NUMA Attention 这类"单一维度优化"，GPUOS 提出了一个更通用的 device-side scheduling primitive——理论上任何适合在 persistent kernel 上执行的 micro-op 都可以通过 ring buffer 注入。
| 维度 | GPUOS | Fleet | ConCCL | NUMA Attention |
|---|---|---|---|---|
| 优化目标 | 消除 kernel launch overhead | Chiplet-aware L2 cache 复用 | 消除 C3 compute interference | Chiplet NUMA-aware attention 调度 |
| 核心技术 | Persistent kernel + ring buffer + JIT operator injection | Persistent megakernel + M-major tiling + 两级事件同步 | DMA engine offload collectives | Workgroup swizzle (head-first mapping) |
| Persistent kernel 用法 | 轻量级 dispatcher（每 SM 1 block，2-4% 线程），接收 ring buffer 命令分发到 device function | 重量级 megakernel（256 CU 全占），融合所有 decode ops | 无（不使用 persistent kernel） | 无（不使用 persistent kernel） |
| Hardware target | NVIDIA H100 / RTX 5090 / GB10 | AMD MI350X (8 XCD, CDNA4) | AMD MI300X (8 XCD, CDNA3) | AMD MI300X (8 XCD, CDNA3) |
| Launch overhead 方案 | 完全消除（<100 ns device dispatch vs 3-7 μs host launch） | 完全消除（single megakernel lifetime = decode sequence） | 不解决（DMA 仍由 CPU 编排） | 不解决（不改变 launch 模式） |
| Runtime flexibility | 极高：NVRTC JIT 零停机注入新 operator | 低：task graph 编译时确定，新 op 需重编译 | 中等：collective 算法可配置 | 低：swizzle 参数需手动调整 |
| Scope | 单 GPU micro-batch inference（element-wise, small matmul, attention, cache ops） | 单 GPU LLM decode（linear GEMM 为主） | 单 node 多 GPU 训练/推理 | 单 GPU attention forward/backward |
| 实现平台 | PyTorch TorchDispatch plugin (3793 行 C++/Python) | Mirage MPK AMD 后端（未开源） | AMD HSA API PoC | Triton FA2 (~15 行 swizzle) |
| 加速幅度 | 15.3× element-wise, 8.7× attention, 23.1× mixed (H100) | 1.3-1.56× decode TPOT (MI350) | 最高 1.67× C3 speedup | 最高 1.50× attention (MI300X) |
| 能耗影响 | 20-22% 节省（消除 idle power） | 未量化 | 未评估 | 未评估 |
GPUOS 和 Fleet 代表了 persistent kernel 范式的两种极端设计选择：轻量级 dispatcher vs 重量级 megakernel。
资源分配哲学的根本分歧。GPUOS 的 persistent kernel 极其保守——每 SM 仅 1 个 thread block（2-4% 总线程），不饱和 shared memory / registers，明确定位为"填谷"而非"占满"。大 GEMM 仍走传统 cuBLAS launch 路径，persistent kernel 只处理 launch-overhead-dominated 的微操作。Fleet 走向另一个极端——persistent megakernel 占满所有 256 CU（减 3.1% scheduler），将整个 decode forward pass 的所有 operator（GEMM、attention、RMSNorm、SiLU）融合为一个不退出的 kernel。这两种选择反映了不同的 workload 假设：GPUOS 假设 workload 是"大量异构操作的混合流"（大 GEMM + 小 elementwise + attention），需要 hybrid execution；Fleet 假设 workload 是"规则的 LLM decode pipeline"，所有 operator 类型已知且可预编译。
动态性 vs 静态性的 trade-off。GPUOS 的 NVRTC JIT + dual-slot aliasing 实现了零停机 operator 热更新——新 operator 从编译到全设备可调用仅需 ms 级。这对 production ML 系统中频繁的模型迭代（新 attention variant、novel activation function）至关重要。Fleet 的 megakernel 在编译时确定所有 task 类型和 task graph，添加新 operator 需要重新编译 Mirage task graph 和 megakernel binary。在 ML 生态快速迭代的现实下（PyTorch 每 2 周一个版本、新论文每天引入新算子），GPUOS 的动态方案更适合 "exploration-heavy" 的研发阶段，Fleet 的静态方案更适合 "deployment-stable" 的生产阶段。
加速机制的本质差异。GPUOS 的加速来自纯"消除固定开销"的算术效果——baseline 中 launch 占 62.5%（5/8 μs per op），消除后 per-op 从 8 μs → 3.1 μs。Fleet 的加速来自两个独立机制：(1) 小 batch 下消除 250 次/token 的 launch overhead（1.15×-1.56×），和 (2) 大 batch 下 M-major 协作式 L2 复用（额外 1.27×）。两者的加速曲线在不同 workload 区间有交叉——GPUOS 在 micro-op 密集的 mixed pipeline 中获益最大（23.1×），Fleet 在 bs≥32 的 memory-bound decode 中获益最大。
互补而非竞争。两者实际上解决了同一个 persistent kernel 设计空间的不同子问题：GPUOS 回答了"如何让 persistent kernel 兼容动态 workload"，Fleet 回答了"如何让 persistent kernel 在 chiplet 架构上高效利用 L2"。如果将两者结合——在 GPUOS 的 persistent kernel 框架中引入 Fleet 的 chiplet-aware task routing——可能产生一个既动态又 L2-friendly 的方案。但实现上的挑战在于：GPUOS 绑定 NVIDIA，Fleet 绑定 AMD。
GPUOS 和 ConCCL 代表了"减少 GPU 协调开销"这一大论题的两个正交维度。
开销的物理位置不同。GPUOS 消除的开销位于 CPU-GPU 边界——每次 cudaLaunchKernel 需要穿越 user space → kernel mode → driver → stream queue → hardware scheduler 的完整链路。ConCCL 消除的开销位于 GPU 内部 CU 之间——当 GEMM kernel 和 communication kernel 同时占用 CU 时产生的 cache pollution 和 compute contention。两种开销在物理路径上完全不重叠——前者是 PCIe/NVLink 控制路径上的 latency，后者是 SM/CU 数据路径上的 bandwidth contention。
解法的对称性。GPUOS 的核心 insight 是"调度不需要穿越 host-device 边界"——把 dispatcher 搬到 device 端。ConCCL 的核心 insight 是"通信不需要占用计算单元"——把数据搬运搬到 DMA 引擎。两者都是"将不属于该硬件单元的工作 offload 到更合适的执行器"：GPUOS 把调度从 CPU（不适合高频小任务调度）offload 到 GPU device threads（ns 级 function call）；ConCCL 把数据搬运从 GPU CU（过于昂贵的搬运工）offload 到 DMA 引擎（专用搬运硬件）。
CPU 编排的矛盾。有趣的是，ConCCL 的 DMA offload 仍然由 CPU 编排（通过 HSA API hsa_amd_memory_async_copy_on_engine），在小传输 (<32MB) 时因 CPU launch/sync overhead 慢 4×。GPUOS 正好解决了这类 CPU 编排开销问题——如果 ConCCL 的 DMA 调度也能通过 GPUOS 的 ring buffer 从 device 端触发，小传输的 CPU overhead 可能被消除。这暗示了一个潜在的组合方案：GPUOS 的 device-side scheduler 不仅分发 compute tasks，还分发 DMA transfer descriptors。
Multi-GPU 组合的想象空间。在 multi-GPU micro-batch serving 中，两者的组合覆盖了完整的开销谱：GPUOS 消除单 GPU 内每 token 上百次 micro-op 的 launch overhead（500 μs → ~16 μs per token），ConCCL 消除 GPU 间 collective 对 GEMM 的 interference（21% → 72% of ideal overlap）。但 GPUOS 目前未评估 multi-GPU 场景，其 persistent kernel 如何与 NCCL/RCCL 的 GPU kernel + proxy thread 模式共存是一个未解的工程问题。
GPUOS 和 NUMA Attention 都属于"利用 GPU 架构特性消除性能瓶颈"，但在架构层级树上的位置完全不同。
瓶颈层级的差异。NUMA Attention 的瓶颈在 存储层级——MI300X 的 per-XCD 4MB L2 cache 是物理分区且不 coherent 的，round-robin workgroup 调度导致同一 attention head 的 K/V 数据在 8 个 XCD 上各加载一份，L2 hit rate 暴跌至 ~1%。GPUOS 的瓶颈在 控制路径——kernel launch 的固有开销（driver 调用 + kernel mode 切换 + stream queue 更新 + hardware scheduler 编程）在 3-7 μs，当操作本身仅需 3-10 μs compute 时，控制开销占 30-100%。两者揭示了 GPU 同时存在多个并行的性能悬崖——即使解决了 launch overhead（GPUOS），如果 L2 cache NUMA 效应未处理（NUMA Attention），attention kernel 仍会退化；反之亦然。
代码改动量的戏剧性对比。NUMA Attention 的解法极其轻量——~15 行 Triton swizzle 代码，不修改 FA2 的计算逻辑，纯调度优化。GPUOS 的解法是一个完整的 runtime system——3793 行 C++/Python，包含 ring buffer、persistent kernel executor、NVRTC JIT compiler、dual-slot operator table、TorchDispatch integration。这反映了两种截然不同的优化范式："精确手术刀"（NUMA Attention：找到一个 swizzle 映射就解决问题）vs "系统重构"（GPUOS：重新定义 host-device 交互的基本抽象）。
硬件厂商的分立。NUMA Attention 明确只适用于 AMD MI300X/MI350（NVIDIA Blackwell 在硬件层面维持跨 die cache coherency，不暴露 NUMA）。GPUOS 明确绑定 NVIDIA（NVRTC、CUDA Driver API、PTX）。这两个优化在当前 GPU 生态中属于不同阵营的"必修课"——AMD 用户需要 NUMA-aware scheduling，NVIDIA 用户需要 launch overhead elimination。但如果未来 AMD GPU 也面临 launch overhead 问题（当前证据不足），或 NVIDIA GPU 走向多 chiplet（Rubin Ultra 可能是 4 die），两类优化的边界可能模糊化。
组合可能性。在一个假设的全栈优化系统中：GPUOS 的 persistent kernel 消除 launch overhead + NUMA Attention 的 swizzle 确保 attention 的 K/V 数据在正确的 L2 分区 + Fleet 的 M-major tiling 确保 linear 权重在 XCD 间协作复用。三者在同一个 persistent kernel 框架内可以共存，但这需要一个统一的跨硬件抽象层——目前不存在。
GPUOS 论文报告的 $15.3\times$ element-wise 加速在数学上等价于"消除 62.5% 的固定开销"（baseline 8 μs/op 中 5 μs 是 launch → 消除后 3.1 μs/op）。这个数字的含义是：在纯 micro-op 流中，每个操作节省 4.9 μs。但在实际 LLM inference pipeline 中，element-wise micro-ops 的累计时间仅占端到端延迟的一部分——大 GEMM（占 compute 的 60-80%）仍走传统 launch 路径不受影响。
与 Fleet 的对比使这一攻击更有说服力：Fleet 在完整 LLM decode pipeline（linear 占 95% 时间）上报告 1.56× end-to-end 加速——这是一个更"诚实"的数字，因为它反映了 pipeline 中所有组件的加权平均。GPUOS 的 $23.1\times$ mixed pipeline 数字可能膨胀在于：(1) "mixed pipeline" 的组成未明确——如果全由 micro-ops 构成（无大 GEMM），则不代表实际推理负载；(2) 论文未提供 end-to-end LLM inference 的加速数字（如 TPOT、TTFT），而这正是 production 最关心的指标。
证据对比：Fleet 明确报告了 Qwen3-8B 的 TPOT（6.73 ms vs 10.51 ms baseline = 1.56×）；NUMA Attention 报告了 DeepSeek-V3 prefill 的 attention kernel 加速（1.35-1.50×）。两者都在实际模型上做了 end-to-end 验证。GPUOS 缺乏等价的 full-model benchmark——它的数字停留在 microbenchmark 级别。
GPUOS 在 NVIDIA Digit Spark (GB10) 上加速仅 $2.1\times$–$3.1\times$，论文解释为 GB10 的 CPU-GPU fabric 已硬件优化 launch path。这个数据点具有深刻的战略含义：如果 NVIDIA 在 consumer/edge 产品上已经部分解决了 launch overhead，那么 datacenter GPU 的未来架构（Blackwell Ultra、Rubin）很可能也会引入类似硬件优化。
对比 NUMA Attention 的论证：NUMA Attention 明确指出 NVIDIA Blackwell 已在硬件层面维持跨 die cache coherency——这是硬件厂商"抢先解决"软件优化目标的直接先例。GPUOS 面临同样的风险：如果 Rubin 代 GPU 将 launch overhead 从 3-7 μs 压缩到 <500 ns（通过 on-chip task queue 或 dedicated launch accelerator），GPUOS 的 ring buffer + persistent kernel 方案将变得无关紧要。论文缺乏对这一战略风险的量化评估——从 GB10 的 $2.8\times$ 推算，当硬件 launch latency 降到 ~1 μs 时，GPUOS 的加速将不足 $3\times$，此时系统复杂性（persistent kernel 管理、TorchDispatch hook、JIT 编译）的成本可能超过收益。
论文在 related work 中提及 LithOS (SOSP 2025) 但未提供直接性能对比。LithOS 同样做 device-side task scheduling 用于 ML workload，是 GPUOS 最直接的竞争者。这个缺失极为关键：
论文声称 GPUOS 的差异化在于：(1) NVRTC-based dynamic operator injection，(2) 轻量 PyTorch 集成，(3) production 导向的安全设计。但如果不与 LithOS 做 head-to-head 对比，读者无法判断：(a) LithOS 的 device-side scheduling 在相同 workload 上性能如何？(b) GPUOS 的 ring buffer + function pointer dispatch 是否比 LithOS 的 task queue 更高效？(c) dynamic operator injection 的额外灵活性在实际 workload 中是否转化为性能优势？
对比 Fleet 论文的处理方式：Fleet 明确给出了与 Mirage MPK（最接近的 prior art）的 head-to-head 对比，精确量化了 chiplet-aware scheduling 相对于 chiplet-unaware megakernel 的增量收益。GPUOS 缺乏等价的对比使得其"新颖性"无法被独立验证。
GPUOS 的 dynamic operator injection 限于 "template-based compilation"——只能实例化预定义模板的参数变体（如不同 size 的 element-wise op），而非任意 CUDA code。这个安全-灵活性 trade-off 产生了一个隐含的覆盖率天花板：
对比 Fleet 和 ConCCL：Fleet 的 megakernel 虽然静态编译，但编译时可以使用完整的 HIP 语义（包括 cache modifier、ISA-level atomic、自定义同步原语）。ConCCL 虽然受限于 DMA 引擎的功能集，但在其适用范围内（all-gather, all-to-all）提供了接近硬件极限的性能。GPUOS 的 template-based JIT 处于一个尴尬的中间地带——比 Fleet 灵活（不需要重编译）但比真正的自定义 kernel 能力弱。
实际影响：当 production 系统需要引入一个真正新的 kernel（如 Flash-MLA、paged attention variant、custom sparse attention），GPUOS 的 template 系统无法直接注入这类需要精细控制 shared memory layout 和 warp-level primitive 的 kernel。此时要么 fallback 到传统 launch（恢复 3-7 μs 开销），要么等待模板库更新——这使得 GPUOS 的"零停机热更新"承诺在最需要它的场景（真正的 novel operator）上失效。
GPUOS 的全部评估在单 GPU 上完成，而 production LLM serving 必然是 multi-GPU（至少 TP=2-8）。Persistent kernel（每 SM 1 block 永不退出）与 NCCL collective kernel（需要占用所有 SM 做 AllReduce/AllGather）之间的资源竞争是一个严重的未知。
对比 ConCCL：ConCCL 的 DMA offload 方案专门解决了 compute-communication 共存问题——正是因为 collective 不再占 CU，GEMM 才能全速运行。如果 GPUOS 的 persistent kernel 的 1 block/SM 与 NCCL 的 full-SM collective 冲突（NCCL 期望 SM 全部可用），可能导致 NCCL 性能退化或需要特殊的共存协议。论文声称"每 SM 仅 1 block，不与大 kernel 争资源"——但这未在 NCCL collective + persistent kernel 同时运行的场景下验证。
证据空白：Fleet 虽然也仅评估单 GPU，但明确承认"未评测多卡 TP"并将其列为 limitation。GPUOS 论文同样列了这个 limitation，但问题更严重——因为 GPUOS 的目标场景（micro-batch inference）在 production 中几乎必然是 multi-GPU 的（LLM > 7B 都需要至少 TP=2），而 Fleet 的目标场景（single-GPU decode for 8B model）确实可以单 GPU 完成。
范式定位：GPUOS 代表了从"优化每次 launch"到"消除 launch 概念"的范式跳跃。传统优化路径（CUDA Graphs、torch.compile kernel fusion、CUTLASS persistent GEMM）都在"减少 launch 次数或降低 per-launch 成本"的框架内工作。GPUOS 跳出这个框架——"进程启动时 launch 一次，此后永远不再 launch"。这个思路与 Fleet 的 persistent megakernel 共享同一个哲学基础（"launch once"），但 GPUOS 的独特贡献在于用 runtime injection 保持了灵活性。
定位判断：GPUOS 在"NVIDIA GPU + micro-batch inference + 高度动态 workload（shape 变化、新 operator 频繁引入）"的三重交集中价值最大——此时 CUDA Graphs 退化（shape 变化）、torch.compile 难以覆盖（新 operator）、传统 eager mode 被 launch overhead 主导。对外部团队的核心可移植思想：(1) "don't launch, call"——device-side function dispatch 取代 host-device 边界穿越；(2) "dual-slot + version counter"——lock-free 零停机更新的通用模式；(3) "hybrid execution"——四维 filter 决定路由，大 kernel 走传统路径不强求。
竞争方案生态位对比：
| 生态位 | 方案 | GPUOS 优势 | GPUOS 劣势 |
|---|---|---|---|
| Micro-op launch elimination | CUDA Graphs | 动态 workload 不退化（15.3× vs 2.1× under shape change） | 比 CUDA Graphs 更复杂的部署模型（persistent kernel 管理） |
| Persistent kernel scheduling | Fleet megakernel | Runtime operator injection（零停机热更新） | 无 chiplet-aware L2 优化能力；绑定 NVIDIA |
| Persistent kernel scheduling | LithOS (SOSP'25) | PyTorch transparent integration + lighter weight | 无 head-to-head 性能对比证明优越性 |
| GPU execution optimization | ConCCL (DMA offload) | 消除 launch overhead（比消除 CU contention 影响范围更广） | 不解决 multi-GPU collective overhead |
| Chiplet-aware optimization | NUMA Attention | 更通用（不限于 attention kernel） | 不解决 L2 NUMA 问题（但 NVIDIA GPU 也不需要） |
| Compiler-based fusion | torch.compile / TVM | 保持 eager semantics + 支持动态 shape | 加速有硬限（仅消除 launch，不做 cross-op fusion） |
| Eager execution acceleration | CUDA Graph + management | 无 graph variant 管理开销 | 系统复杂性更高（ring buffer、JIT、persistent kernel 生命周期） |
方向 1: GPUOS + Fleet 的统一 persistent kernel runtime——动态注入 × chiplet-aware dispatch。GPUOS 的 ring buffer + device function dispatch 和 Fleet 的 chiplet-aware task routing 理论上可以统一为一个跨厂商的 device-side scheduling 框架。核心设计：persistent kernel 的每个 SM/CU block 不仅按 GPUOS 的方式 poll ring buffer 获取 task descriptor，还按 Fleet 的方式感知自己所在的 chiplet/XCD 并只处理该 chiplet 亲和的 task。在 NVIDIA 上 chiplet 概念映射到 GPC (Graphics Processing Cluster)——Blackwell 的 2 die 各有多个 GPC，L2 在 GPC 间有 NUMA 效应（虽然逻辑 coherent 但物理 NUMA 延迟不同）。这个方向的技术挑战：(1) NVIDIA 不暴露等价于 AMD HW_ID 的 GPC affinity 信息——需要通过 SM index 推断；(2) GPUOS 的 operator table 需要扩展为 "chiplet-local operator table"——让不同 chiplet 上的 persistent thread 执行 chiplet-affine 的 operators；(3) dual-slot aliasing 需要与 chiplet-scope cache modifier 交互（新 operator 加载时的 cache flush 策略需要 chiplet-aware）。
方向 2: Device-initiated DMA——用 GPUOS 的 persistent kernel 解决 ConCCL 的 CPU 编排开销。ConCCL 的核心局限是 DMA 传输由 CPU 编排（HSA API call），小传输 (<32MB) 时 CPU launch/sync overhead 导致 4× 退化。如果 GPUOS 的 persistent kernel 不仅分发 compute tasks 到 device function，还能分发 DMA descriptors 到 DMA 引擎——即 device-initiated DMA——则可以消除 CPU 编排开销。具体实现路径：在 NVIDIA 上通过 cudaLaunchHostFunc 或 persistent kernel 内的 memory-mapped I/O 触发 copy engine（H100 的 copy engine 可通过 cudaMemcpyAsync 在 stream 上排队，但能否从 device thread 直接触发尚未公开文档）；在 AMD 上利用 MI300X 的 14 SDMA 引擎的 doorbell register（理论上 device thread 可以 MMIO 写 doorbell）。这将 ConCCL + GPUOS 统一为一个完全 device-side 的 scheduling + communication runtime。
方向 3: Multi-scale persistent kernel——按操作粒度动态调整 persistent thread 数量。GPUOS 固定使用每 SM 1 block（2-4% 线程）的保守配置。但不同操作对并行度的需求差异巨大：element-wise add 仅需 1 warp、attention decode 可能需要多个 block 协作、softmax 需要 cross-block reduction。Fleet 的方案是把所有 SM 都给 persistent kernel——牺牲了与非 persistent 工作负载的共存。中间方案：persistent kernel 维护一个 "thread pool" 可以动态扩展/收缩——当 ring buffer 中出现需要高并行度的 operator 时，persistent kernel 通过 cooperative group 的 dynamic parallelism 或 simple device-side malloc + kernel launch 临时扩展 thread 数（从 2-4% 扩展到 50-100%）；当大 GEMM 需要全部 SM 时，persistent kernel 缩减到最小状态（仅保留 polling thread）。这需要解决的核心问题是 NVIDIA 的 thread block scheduling 是否允许 persistent thread block 主动"让出"SM（当前 CUDA 不支持 cooperative thread block yield）。
方向 4: GPUOS 的 ring buffer 协议扩展——从单 GPU scheduler 到 multi-GPU distributed scheduler。当前 GPUOS 的 ring buffer 是 host-to-device 单向通信。在 multi-GPU serving 中，可以扩展为 device-to-device ring buffer——GPU 0 的 persistent kernel 可以直接向 GPU 1 的 ring buffer 写入 task descriptor（通过 NVLink P2P 访问 device-mapped memory），实现跨 GPU 的 device-side task routing。这消除了 multi-GPU 调度中 CPU 参与的需要——当前 NCCL 的 proxy thread 仍在 CPU 上做跨 GPU 调度。结合 GPUOS 的 dynamic operator injection：每个 GPU 的 operator table 独立更新，但 task descriptor 中的 op_id 跨 GPU 统一——实现了一个 "分布式 GPU function call" 的抽象。与 NUMA Attention 的潜在协同：如果 ring buffer descriptor 中包含 "target chiplet" 字段，不同 XCD 的 persistent thread 可以选择性处理映射到自己 L2 分区的 task，实现跨 GPU + 跨 chiplet 的双层亲和调度。
方向 5: Adaptive filter 学习——从四维 heuristics 到 learned routing policy。GPUOS 当前的 TorchDispatch 四维 filter（operation type × tensor size × execution context × ring buffer load）使用手动 heuristics 决定是否路由到 persistent kernel。这些 heuristics 的最优参数高度依赖 model architecture、serving pattern、hardware generation。可以用 lightweight RL（如 contextual bandit）在线学习路由策略：state = (op type, tensor shape, current ring buffer occupancy, recent dispatch latency moving average)；action = route to persistent kernel vs traditional launch；reward = -wall_clock_time。学习可以在 warmup phase 完成（数千次操作后收敛），之后固定 policy。Fleet 论文中 bs=32 是 M-major 协作的"拐点"（Table 4 清晰证明）；GPUOS 的等价拐点（"tensor size 多大时 launch overhead 不再主导"）缺乏量化分析——learned policy 可以自动发现这个拐点并适应不同硬件。