Fleet提出多芯片GPU巨型内核层次化任务抽象

背景

随着大语言模型（LLM）等内存密集型工作负载的兴起，GPU 的计算能力需求持续攀升。为克服单芯片制造的良率和成本瓶颈，现代 GPU 普遍采用多 Die（chiplet）设计，例如 AMD Instinct MI350 等产品。每个 chiplet 拥有独立的私有缓存层级（如 private L2 cache），通过片间互连（如 Infinity Fabric）构成统一地址空间。

然而，当前主流的 GPU 编程模型（如 CUDA 和 HIP）依然暴露一个扁平的执行层次：线程（thread）→ 线程块（thread block / CTA）→ 网格（grid）。这种模型无法表达 chiplet 级别的局部性——程序员无法显式地将计算任务与特定的缓存域绑定，也无法在 chiplet 内部进行高效的协同同步。其后果是：在内存受限的 LLM 推理场景中，不同 chiplet 上的线程可能频繁访问相同的数据块，但由于缺乏感知，这些请求会各自拉取数据，造成冗余的 HBM（高带宽内存）流量，并导致 L2 缓存利用率低下，从而显著增加解码延迟。

核心内容

针对上述问题，来自研究机构的团队提出了 Fleet——一种面向多 Die GPU 的分层任务抽象系统。Fleet 的核心思路是引入一个与内存作用域（memory scope）对齐的多级任务模型，让计算在正确的缓存层级上进行协作和重用。

具体地，Fleet 定义了以下任务层级：

• Device-level tasks：对应整个 GPU 设备级别的全局任务，沿用现有抽象。
• Chiplet-tasks（新增）：这是 Fleet 最关键的新抽象。一个 Chiplet-task 将一组工作负载及其所需数据的访问权限绑定到某个特定的 chiplet。同一 chiplet 内的多个工作者（workers）可以通过该 chiplet 的共享 L2 缓存进行协调和数据复用。Chiplet-tasks 暴露了此前未被编程模型覆盖的层次。
• CU-level tasks：对应计算单元（Compute Unit）级别，与现有线程块概念一致。
• Wavefront-level tasks：对应波前（warp）级别。

Fleet 的实现基于持久化内核（persistent kernel）运行时，每个 chiplet 拥有独立的调度器。当运行时调度一个 Chiplet-task 时，它会将任务及其关联的数据绑定到对应 chiplet 的线程池。工作者们可以合作执行任务，并在 chiplet 内部通过共享 L2 实现缓存友好的数据流。

为了验证效果，团队在 AMD Instinct MI350 上使用 Qwen3-8B 模型进行了解码延迟测试，并与广泛使用的推理引擎 vLLM 进行了对比。实验结果表明：

• 小批次（batch size 1-8）：Fleet 通过持久化内核执行和按 chiplet 调度，将解码延迟降低了 1.3-1.5 倍。
• 大批次（batch size 32-64）：Fleet 采用协作式权重分块（cooperative weight tiling）策略，大幅提升 L2 缓存命中率。在 batch size 为 32 时，L2 命中率从 12% 提升至 54%；在 batch size 为 64 时，从 39% 提升至 61%。这使得 HBM 流量减少了 37%，相较于不感知 chiplet 的大内核（megakernel）基线，速度提升了 1.27-1.30 倍。

关键要点

• 问题根源：chiplet GPU 存在多级私有缓存，但现有 CUDA/HIP 模型只提供扁平执行层次，缺乏 chiplet 级别的局部性与同步表达，导致缓存无效和 HBM 带宽浪费。
• 创新抽象：Fleet 引入 Chiplet-task，将计算与数据绑定到特定 chiplet，使同一 chiplet 内的工作者可以共享 L2 缓存协作。
• 实现机制：基于持久化内核运行时，每个 chiplet 拥有独立调度器；任务按 chiplet 作用域分配，支持协作式执行和缓存感知调度。
• 性能提升：
  • 小 batch（1-8）下解码延迟降低 1.3-1.5x（对比 vLLM）。
  • 大 batch（32-64）下 L2 命中率从 12%→54%（batch 32），39%→61%（batch 64），HBM 流量减少 37%，速度提升 1.27-1.30x（对比 chiplet-unaware megakernel 基线）。
• 兼容性：Fleet 对齐已有的 wavefront/CU/device 抽象，仅增加 Chiplet-task 层，可逐步集成到现有编程模型中。

意义与影响

Fleet 的工作揭示了现代多 Die GPU 架构与编程模型之间的断层，并提供了一个务实的解决路径。其意义体现在以下方面：

1. 架构的必然趋势：随着芯片复杂度提升，chiplet 设计将成为高性能 GPU 的主流。Fleet 证明，软件必须主动感知硬件缓存拓扑，才能充分利用多 Die 的带宽和本地性优势。这一思路对于下一代数据中心 GPU（如 NVIDIA 的 NVLink-C2C 或 AMD 的 MI400 系列）也具有参考价值。

2. LLM 推理的实时性：LLM 推理对延迟敏感，且常处于 memory-bound 状态。Fleet 在小 batch 场景下直接降低延迟 1.3-1.5x，意味着可以在相同硬件上支持更强的实时交互体验；在大 batch 下减少 HBM 流量则意味着更高的吞吐和更低的功耗，对云服务成本优化有直接帮助。

3. 编程模型的演进方向：Fleet 的 Chiplet-task 抽象并非推翻现有模型，而是补充一个缺失的层级。这种渐进式方案更容易被工业界采纳。未来，CUDA/HIP 或更高级的领域特定语言（如 Triton）可能借鉴类似的多级任务概念，使程序员在不失灵活性的前提下获得硬件感知的自动优化。

4. 持久化内核的复兴：持久化内核（persistent kernel）以往主要用于减少内核启动开销，Fleet 将其与 chiplet 调度结合，实现了协作式执行。这重新唤醒了社区对持久化内核在高利用率场景下潜力的关注。

总体而言，Fleet 是多 Die GPU 编程模型向“硬件-软件协同设计”迈出的重要一步，尤其在 LLM 推理这一关键负载上展现了显著收益。后续工作可进一步扩展到更复杂的芯片互连拓扑（如 mesh 或 crossbar）以及支持动态负载均衡的调度策略。