导言
我最初从外部技术资料了解到 Data-as-Flag 时，直觉上把它理解为三种省掉独立完成通知的方法：把 flag 塞进数据块、用数据校验值确认整批到达，或者先用特殊值填满接收区，再观察它是否被真实数据覆盖。
顺着这三个方向检查 NVIDIA 的公开资料后，答案很明确：NVIDIA 不但有相同思路，NCCL 的 LL/LL128 已经长期使用内嵌 flag；NCCL 2.31.2 的 LLA2A 又把它做成了面向低时延 All-to-All 的 payload + epoch 原子槽位。不过，公开实现更偏好显式 epoch，而不是让任意 payload 或 checksum 单独承担正确性。
导言
“GPU-aware” 很容易让人产生一个错觉：只要通信库能够接收 GPU buffer，数据就会完全绕开 CPU，通信也已经由 GPU 自主推进。现实并没有这么整齐。API 可能从 CPU 发起，数据却直接流向 NIC；GPU 也可能负责触发传输，但报文仍由 CPU 预先构造。
The Landscape of GPU-Centric Communication 给出的关键视角，是把通信拆成 API、报文构造、触发和数据路径，再观察每项责任究竟落在 CPU、GPU 还是 NIC。沿着这套坐标回看二十年演进，会发现主线不是“带宽越来越高”，而是先消除冗余拷贝，再缩短数据路径，最后把控制权逐步迁到 GPU。