CUDA 内存一致性模型与同步原语深度解析：从弱内存序、作用域可见性到异步代理栅栏的 GPU 并发正确性底层原理

CUDA 内存一致性模型与同步原语深度解析：从弱内存序、作用域可见性到异步代理栅栏的 GPU 并发正确性底层原理

• 核心痛点：多个 warp、多个 CTA 乃至多张 GPU 协作时，一个执行单元写入的数据另一个执行单元"看不到"或读到旧值------编译器重排、硬件乱序与 per-SM 非相干缓存共同把并发代码推向未定义行为，而 GPU 官方内存模型的细节分散在 PTX 手册、CUDA 编程指南与形式化论文中，缺少一条从硬件微架构直达代码写法的完整因果链。
• 适配人群：CUDA 内核开发者、AI 推理与训练框架底层工程师、算子库（CUTLASS / FlashAttention / FlashInfer / Triton）与集合通信（NCCL / NVSHMEM）研发人员、需要编写跨 CTA 或跨 GPU 同步逻辑的系统工程师，以及对 GPU 体系结构感兴趣的高阶读者。
• 收获能力：掌握 PTX 内存一致性模型的 memory order 与 scope 两个正交维度；理解 L1 非相干缓存与 L2 原子单元如何决定可见性的性能代价；正确使用 atomic / fence / __syncthreads / mbarrier / cooperative groups / libcu++ 全谱同步原语；在 Hopper / Blackwell 的 TMA 与 tcgen05 异步代理模型下构建无竞态、无死锁且高性能的流水线内核；用 compute-sanitizer 与压力测试定位同步缺陷。

技术背景与演进逻辑

• CUDA 的并发模型从一开始就是"块内共享、块间独立、网格间无序"：同一 CTA 内的线程可以通过共享内存和 __syncthreads() 协作，不同 CTA 之间没有任何默认的执行顺序或内存可见性保证，跨网格更是如此。这个设计不是疏漏，而是让硬件可以自由地把并发规模放大到十万级线程的必要前提。
• 背景线索一：内存层次越深，一致性越弱
• 寄存器与共享内存 -> 与线程或 CTA 生命周期绑定，可见性规则简单直接
• L1 与统一缓存 -> per-SM 私有，不参与全局一致性协议，弱读可能拿到旧副本
• L2 -> 全 GPU 汇聚点，原子操作在此执行，跨 SM 的可见性在此建立
• HBM -> 容量与带宽层，由堆叠工艺与接口宽度决定延迟上限
• NVLink 与 PCIe -> 跨 GPU 可见性需要系统作用域，代价再上一个台阶
• 推演结论 -> 每一次"把数据交给别人看"都要显式跨越一个可见性边界，边界越深代价越大
• 背景线索二：编译器与硬件同时在重排
• 编译器优化 -> 把一个反复读取的 flag 提升到寄存器，循环里不再访问内存
• 写缓冲 -> store 先进入缓冲，稍后才落到 L2，别的 SM 看到的顺序与发射顺序可能不同
• 多 L2 slice -> 不同地址的写在不同 slice 上并行完成，全局观察顺序不定
• 推演结论 -> 不加约束时，"先写数据再写 flag"在别的线程看来可能变成"先看到 flag 再看到旧数据"
• 背景线索三：性能诉求与正确性诉求的张力
• 顺序一致性 -> 每次写都要等全局可见，L2 往返量级数百周期，十万级并发线程下吞吐不可接受
• 弱内存模型 -> 默认允许重排，把"何时保证可见"的决定权交给软件
• 同步原语 -> 在必要的位置、必要的作用域内，把弱语义按需升级为强语义
• 推演结论 -> GPU 选择弱内存模型不是偷懒，而是把性能自由度留给软件，代价是程序员必须理解这套契约
• 演进时间线（text 树表达）：

GPU 内存模型演进
├── 2006 -> G80/CUDA 诞生：共享内存 + __syncthreads()，全局内存无跨线程保证
├── 2008 -> GT200：全局原子操作与 __threadfence()，语义先靠口头约定
├── 2010 -> Fermi：L2 集中式原子单元、统一寻址，atom/red 成为可编程同步原语
├── 2012 -> Kepler：__threadfence_system()，支撑 GPUDirect 与多 GPU 可见性
├── 2017 -> Volta + PTX ISA 6.0：独立线程调度；首次发布形式化 scoped 内存模型
├── 2019 -> ASPLOS：Lustig 等给出 PTX 模型的公理化定义与验证
├── 2020 -> Ampere：cp.async 异步拷贝、mbarrier 普及，warp-specialized 编程兴起
├── 2022 -> Hopper：TMA + async proxy，fence.proxy.async 成为流水线正确性刚需
├── 2024 -> Blackwell：tcgen05 / TMEM 异步指令族，commit-wait 与代理栅栏细化
└── 2025-2026 -> PTX ISA 9.x：cluster / 2-CTA 作用域扩展，异步语义持续收紧

• 总结：从"靠经验约定"到"公理化模型"，GPU 内存模型用了近二十年才把并发正确性变成可推理、可验证的工程契约；今天写高性能内核，必须同时理解模型语义与它背后的硬件实现，二者缺一不可。

核心原理深度解析

顺序一致性为什么不可行

• 顺序一致性要求所有线程看到所有内存操作的同一个全序，等价于"每一条写在其后的任何读写之前就全局可见"。在 CPU 多核上，一致性协议要维护缓存行的独占与失效广播，核数有限尚可承受；而在 GPU 上，同时活跃的线程动辄十万级，若每个 SM 的 L1 都要参与全局一致性目录，仅目录通信就足以吞噬全部带宽。
• 硬件商的折中方案是：只在 L2 这一层维护单地址的修改顺序（coherence），放弃跨地址的全局顺序（consistency），再把跨 SM 的可见性交给软件显式建立的同步边。于是 GPU 的默认语义是弱的：单地址的原子性有保证，两个不同地址之间的相对顺序没有任何保证。
• 这解释了为什么一个看似无懈可击的"先写数据、再写标志位"流程在 GPU 上会失败：数据与标志位是不同地址，落在同一个或不同 L2 slice 上，观察者可以先看到标志位、后看到数据。正确性不是靠硬件更努力，而是靠 release 与 acquire 这对同步边把两个地址的写"打包"成一次有因果关系的传递。
• 设计思想：把一致性从一个"全局属性"降级为一种"局部契约"，契约的建立权与成本都交给软件，硬件只保证单地址的修改顺序与强操作的原子性。

两个正交维度：Memory Order 与 Scope

• PTX 内存模型把每个内存操作的语义拆成两个正交维度：排序强度（memory order）与可见范围（scope）。二者必须成对理解，只写对一半的代码在多数测试中通过、在压力下偶发失败，是 GPU 并发 bug 最经典的形态。
• 语义坐标（text 树）：

PTX 内存操作的语义坐标
├── Memory Order（排序强度，从弱到强）
│   ├── weak（默认）: 无同步含义，编译器与硬件可任意重排
│   ├── relaxed: 仅保证原子性与单地址修改顺序，不建立跨地址因果
│   ├── acquire: 读侧，阻止其后的读写被重排到它之前
│   ├── release: 写侧，阻止其前的读写被重排到它之后
│   ├── acq_rel: 读改写原子同时具备两者
│   └── sc: 顺序一致，最强也最贵
├── Scope（可见范围，从小到大）
│   ├── cta: 线程块内（共享内存与块内线程）
│   ├── cluster: 线程块簇内（SM90+，分布式共享内存）
│   ├── gpu: 本 GPU 全部线程，经 L2 汇聚
│   └── sys: 系统级，跨 GPU、对 CPU 与外设可见
└── 组合规则
    ├── acquire 只对"作用域相交"的 release 写建立同步边
    ├── 强操作 + 同地址 + 作用域相交 = morally strong
    └── release 写与其值被 acquire 读观察到 = synchronizes-with

• 关键推论一：relaxed 原子不建立跨线程的顺序保证。它只解决"读改写不可分割"的问题，常用于计数器、统计量与不需要顺序的部分和累加；把 relaxed 当 acquire 用，是自旋等待永远等不到标志位的常见根因。
• 关键推论二：scope 是同步边的"高度"。一个 cta 作用域的 release 写不会对另一个 CTA 产生任何承诺；跨 CTA 必须升到 gpu 作用域，跨 GPU 或对主机、网卡可见必须升到 sys 作用域。作用域每升一级，硬件需要走的路就更长、更贵。
• 关键推论三：acquire 与 release 必须成对出现在"同一对地址的读写关系"上。只加栅栏不加配对操作，或者配对的两个操作作用于不同地址、不同作用域，都无法构成同步边。
• 形式化视角下的 happens-before：如果线程 A 对地址 x 做 release 写，线程 B 对 x 做 acquire 读且读到了该写的值（或该写之后同一地址的写），则 A 在 release 之前的所有内存操作 happens-before B 在 acquire 之后的所有内存操作。这条边加上程序序（po）的传递闭包，就是一切跨线程可见性的来源。

硬件的可见性真相：L1 非相干与 L2 汇聚

• 理解模型之后要回到硅片：为什么弱读可能永远读不到新值？因为全局读默认经过 L1，而 L1 是 per-SM 私有、不参与一致性协议的缓存。一个 SM 的 L1 里可以长期保留某个地址的旧副本，硬件没有义务因为别的 SM 写了该地址就去失效它。
• 一次全局写的可见性路径（text 树）：

一次全局写从发射到可见的路径
├── SM 发射 store
│   ├── 弱 store -> 写穿 L1，进入 L2 写队列
│   └── release/atomic -> 绕过 L1，直达 L2 原子单元
├── L2 slice 接收
│   ├── 普通写 -> 更新数据行，按单地址 coherence 顺序排队
│   └── 原子写 -> 在原子单元内读改写，同地址操作串行化
├── 跨 SM 可见
│   └── 其他 SM 的弱读仍可能命中其 L1 旧副本
└── sys 作用域
    └── 经 NVLink / PCIe 到达对端 GPU 或主机内存，延迟再升一档

• 在 SASS 层面可以直接看到语义的代价：acquire 读被编译为带 STRONG.GPU 修饰的 LDG，release 写被编译为可重试的 STG 序列，sys 作用域则对应 STRONG.SYS。强语义操作在硬件上意味着绕过本地缓存、在 L2 排队、甚至把请求送出 GPU，这也是"一个多余的 fence 拖慢整个内核"的微观原因。
• 原子操作的硬件落点是 L2 的原子单元。对同一地址的原子请求在该地址所属的 L2 slice 内严格串行化，对不冲突的地址则可以跨 slice 并行。这个实现决定了争用型原子的吞吐上限： m a t h r m t h r o u g h p u t m a x a p p r o x d f r a c 1 m a t h r m l a t e n c y m a t h r m L 2 mathrm{throughput}{max} approx dfrac{1}{mathrm{latency}{mathrm{L2}}} mathrmthroughputmaxapproxdfrac1mathrmlatencymathrmL2
• 量级上，同一地址的高争用原子每秒只能完成千万次级别，而把写聚合到每 warp 一次（warp 级归约后再发一个原子），吞吐可以提升十几到三十几倍。这不是库的魔法，而是对 L2 串行化瓶颈的工程绕行。
• PTX 还区分 atom 与 red 两种原子指令：atom 返回旧值，必须等待 L2 往返；red 是 fire-and-forget，不返回结果，延迟显著更低。凡是"只累加不读取旧值"的场景（统计、计数器、部分和），都应当优先用 red 或对应的 CUDA 封装。
• 历史原语 volatile 的角色：它保证每次访问都真实落到内存、编译器不得跨它重排，从而在弱模型时代勉强支撑自旋等待；但 volatile 不在 PTX 内存模型里提供 acquire 与 release 语义，也不携带作用域信息。现代代码应当用 atomic 加显式 memory order 替代裸 volatile，把意图写进语义，而不是依赖编译器的历史行为。

公理化模型速览

• 要用模型推理而不是靠试错，需要认识它的公理化骨架。把一次执行展开为所有线程的操作集合，定义四类关系与四条公理，即可判定一段并发代码是否存在数据竞争。
• 模型骨架（text 树）：

公理化模型的四类关系与四条公理
├── 关系
│   ├── po（program order）：单线程内的指令序
│   ├── rf（reads-from）：每个读的值来自哪个写
│   ├── co（coherence order）：单地址上所有写的全序
│   └── fr（from-read）：读之后、在 co 序中更晚的写
├── 公理
│   ├── Coherence：单地址上满足顺序一致，硬件兜底
│   ├── Atomicity：morally strong 的操作对不可交错
│   ├── No-Thin-Air：读到的值必须来自真实发生的写
│   └── Causality：happens-before 链上不许出现环
└── 工程意义
    ├── 逐条找"哪条边把写传播到读"：po + rf + 同步边
    └── 找不到边 = 数据竞争 = 未定义行为

• morally strong 是模型里最重要的判定条件：两个内存操作必须都是强操作（atomic 或 fence）、作用于同一地址、且作用域相互覆盖（scope-inclusive），它们之间才享有原子性并建立同步。一个弱读去读一个强写，永远得不到同步边------这就是"我在写入端加了 fence，为什么读者还是读到旧值"的答案：问题出在读者端缺少 acquire。
• No-Thin-Air 排除了"凭空出现值"这种理论上的怪象；Causality 则把 happens-before 的传递性钉死。Lustig 等人在 ASPLOS 2019 的论文中不仅给出这套公理的形式化定义，还构建了覆盖数百个微测试的执行校准流程，用真实 GPU 行为反向验证模型。这也是为什么今天可以在纸面上推理一段并发代码是否安全，而不必在每块卡上跑百万次压测。

同步原语全景

• CUDA 生态的同步原语可以按"执行屏障、内存栅栏、原子操作、隐式顺序"四层排布。理解每一层的确切语义与作用域，是避免"过度同步拖慢性能、同步不足偶发崩溃"的前提。
• 原语全景（text 树）：

CUDA 同步原语层次
├── 执行屏障（execution barrier）
│   ├── __syncthreads() -> bar.sync，块内执行 + CTA 作用域内存栅栏
│   ├── __syncwarp() -> Volta 独立线程调度后 warp 内的显式会合
│   ├── mbarrier -> 相位式异步屏障，arrive 计数 + 完成量追踪
│   └── cooperative groups grid.sync() -> 全网格屏障，需协作启动
├── 内存栅栏（memory fence）
│   ├── __threadfence_block() -> membar.cta，等价 fence.sc.cta
│   ├── __threadfence() -> membar.gl，等价 fence.sc.gpu
│   ├── __threadfence_system() -> membar.sys，跨 GPU 与主机可见
│   └── fence.proxy.async / tcgen05 栅栏 -> 跨代理排序
├── 原子操作（atomic）
│   ├── atom.{relaxed,acquire,release,acq_rel,sc}.{cta,cluster,gpu,sys}
│   ├── red -> 无返回值归约，延迟更低
│   └── libcu++ cuda::atomic / atomic_ref / barrier / pipeline
└── 隐式顺序（stream 与运行时）
    ├── 同一 stream 内 kernel 严格顺序执行
    └── cudaMemcpyAsync 与前序 kernel 保持 stream 序

• __syncthreads() 的完整语义是"执行会合 + CTA 作用域内存栅栏"：它既等待块内所有线程到达，也保证此前所有线程对共享内存与全局内存的访问在栅栏之后对块内线程可见。经常被忽略的是后半句：它等价于一次 cta 作用域的 acquire/release，而不是单纯的屏障。反过来，它也仅限 cta 作用域，对块外线程没有任何承诺。
• __syncwarp() 是 Volta 之后必须显式书写的原语。Volta 引入独立线程调度，同一个 warp 的 32 条线程可以在分支处各自推进、不再锁步执行，过去依赖"同 warp 隐含同步"的代码会出现读取未初始化共享数据的竞态。迁移老代码时，凡是假设 warp 锁步的地方都要补 __syncwarp() 或改为 *_sync 系列 warp 原语。
• __threadfence() 的三个层次对应三种作用域：block、gpu、sys。它们只排序、不阻塞执行，是"写数据、栅栏、写标志位"模式的骨架。fence 不会替你传播任何东西，它只是给编译器与硬件画一条不可跨越的排序线；真正让对端看到数据的是随后配对的 acquire。
• mbarrier 是 Hopper / Blackwell 时代的核心同步原语。它以相位（phase）为单位工作：初始化时设定期望到达数，线程通过 arrive 递减计数或附带完成量（expect-tx），等待方用 try_wait.parity 轮询相位翻转。与 __syncthreads() 不同，mbarrier 可以跨 warp 角色使用、可以在任意时刻留下未会合的到达、还能直接追踪 TMA 传输的字节完成量，因此成为 warp-specialized 流水线的标准配置。
• cooperative groups 的 grid.sync() 提供全网格屏障，但要求协作启动（cudaLaunchCooperativeKernel）且所有块同时驻留------这意味着网格规模受 occupancy 约束。它适合迭代型算法与小规模持久化内核，不适合任意规模的训练内核。
• libcu++ 把上述能力封装为 C++ 类型：cuda::atomic<T, cuda::thread_scope_device> 对应 gpu 作用域，thread_scope_system 对应 sys，thread_scope_block 对应 cta；cuda::atomic_ref 可以在不拥有内存的前提下给普通变量加原子语义；cuda::barrier 映射到 mbarrier。生产代码优先用这些类型而不是裸 PTX，编译器会为不同架构选择正确的指令序列。

核心模块 / 流程 / 机制详解

模式一：Release/Acquire 标志位握手

• 最基础的跨线程可见性模式是"数据加标志位"：生产者先写数据、再以 release 语义写标志位；消费者以 acquire 语义轮询标志位，看到非零后读取数据。这对操作在内存模型里构成 synchronizes-with 边，数据写的可见性由这条边传递。
• 等价的手写内联 PTX 如下（避免编译器把轮询提升到寄存器，也避免流水线乱序）：

__device__ __forceinline__ void store_release_gpu(unsigned int* p, unsigned int v) {
    asm volatile("st.release.gpu.global.u32 [%0], %1;" :: "l"(p), "r"(v) : "memory");
}

__device__ __forceinline__ unsigned int load_acquire_gpu(const unsigned int* p) {
    unsigned int v;
    asm volatile("ld.acquire.gpu.global.u32 %0, [%1];" : "=r"(v) : "l"(p) : "memory");
    return v;
}

• 更推荐的 libcu++ 写法把语义集中到类型上，编译器与硬件各司其职：

#include <cuda/atomic>

__device__ void producer(int* data, cuda::atomic<int, cuda::thread_scope_device>* flag) {
    *data = 42;
    flag->store(1, cuda::memory_order_release);
}

__device__ int consumer(const int* data, cuda::atomic<int, cuda::thread_scope_device>* flag) {
    while (flag->load(cuda::memory_order_acquire) == 0) {
    }
    return *data;
}

• 为什么不能只靠 volatile：volatile 能阻止轮询被优化掉，但它不提供作用域，也不阻止编译器把 data 的读挪到 flag 的读之前。acquire 同时解决这两个问题------它既阻止优化，也阻止数据读取被提前。
• 握手流程（text 树）：

release/acquire 握手时序
├── 生产者 CTA
│   ├── st data = 42（弱写）-> 进入 L2
│   ├── st.release.gpu flag = 1 -> 建立排序线后写入 L2
│   └── 两次写的相对顺序被 release 固定
└── 消费者 CTA
    ├── ld.acquire.gpu flag 轮询 -> 每次直接从 L2 取
    ├── 读到 1 -> 同步边成立
    └── 读 data -> 保证看到 42

模式二：Split-K 归约与"最后一个块"检测

• 大模型推理里的 Flash-Decoding、训练里的 split-K GEMM 都需要把一次归约拆给多个 CTA，再由"最后一个完成的块"负责合并。判定谁最后完成依赖一个经典三元组：原子累加、栅栏、原子计数。
• CUB 风格的骨架代码：

__device__ void last_block_combine(float* partials, int* counter, int num_blocks) {
    __shared__ bool is_last;

    if (threadIdx.x == 0) {
        __threadfence();
        unsigned int ticket = atomicInc((unsigned int*)counter, num_blocks);
        is_last = (ticket == num_blocks - 1);
    }
    __syncthreads();

    if (is_last) {
        for (int i = 1; i < num_blocks; ++i) {
            for (int j = threadIdx.x; j < TILE; j += blockDim.x) {
                partials[j] += partials[i * TILE + j];
            }
        }
    }
}

• 正确性要点有三：第一，partials 的写入必须先于计数，atomicInc 之前的 __threadfence() 保证前面所有写对拿票的线程可见；第二，atomicInc 的返回值是旧值，等于 num_blocks - 1 的线程即最后完成者，天然获得"所有块的 partials 已经写完"的全局视图；第三，最后块内的归约需要 __syncthreads() 先广播 is_last 再执行，否则只有 tid 0 知道结果。
• 性能要点在于把"每线程一个原子"改为"每 warp 一个原子"：先用 __reduce_add_sync 或 redux.sync.add 做 warp 内归约，再由 lane 0 发一个 red 累加。争用从 32 倍降到 1 倍，是 split-K 内核最常见的优化。

模式三：Warp-Specialized 生产者消费者流水线

• Hopper 之后的 GEMM 与注意力内核普遍采用 warp-specialized 结构：一部分 warp 专职搬数据（producer），另一部分 warp 专职计算（consumer），二者通过 mbarrier 交接。这套结构的正确性依赖两点：共享内存缓冲的"满"与"空"用 mbarrier 相位表达；异步拷贝（TMA 或 cp.async）的完成通过 expect-tx 直接计入 mbarrier，而不是轮询数据。
• libcu++ 风格的双缓冲骨架：

#include <cuda/barrier>
#include <cuda/pipeline>

using block_barrier = cuda::barrier<cuda::thread_scope_block>;

__shared__ block_barrier full[2];
__shared__ block_barrier empty[2];
__shared__ float buffers[2][TILE];

if (threadIdx.x == 0) {
    init(&full[0], blockDim.x);
    init(&full[1], blockDim.x);
    init(&empty[0], blockDim.x);
    init(&empty[1], blockDim.x);
}
__syncthreads();

auto full_token = full[0].arrive();
cuda::memcpy_async(buffers[0], gmem + offset, cuda::aligned_size_t<16>(TILE_BYTES), full[0]);
full_token.wait();

for (int step = 0; step < STEPS; ++step) {
    int cur = step % 2;
    int nxt = (step + 1) % 2;
    auto empty_token = empty[cur].arrive();
    compute(buffers[cur]);
    empty_token.wait();
    auto next_full = full[nxt].arrive();
    cuda::memcpy_async(buffers[nxt], gmem + next_offset, cuda::aligned_size_t<16>(TILE_BYTES), full[nxt]);
    next_full.wait();
}

• 为什么这里几乎看不到显式 fence：mbarrier 的 arrive 与 wait 在模型里就携带 cta 作用域的 release/acquire 语义，异步拷贝的完成量（tx-count）在 arrive 时被原子地计入，等待方一旦通过相位检查，数据已经对 generic proxy 可见。正确性由原语承担，而不是靠程序员记忆"这里该加 fence"。
• 流水线时序（text 树）：

mbarrier 双缓冲时序
├── 阶段 k：consumer 等 full[cur] -> 相位翻转 -> 计算 buffers[cur]
├── 阶段 k 尾部
│   ├── consumer arrive empty[cur] -> 释放缓冲区
│   ├── producer 等到 empty[cur] -> 重新填充
│   └── TMA 完成量 tx-count 计入 full[nxt] -> 自动唤醒等待者
└── 阶段 k+1：consumer 等 full[nxt]，循环推进

模式四：跨 CTA 与跨 GPU 同步

• 持久化内核（如 DeepGEMM 风格）需要在网格内做阶段间同步，但 cooperative launch 的驻留约束往往不满足。工业界常用"原子计数 + 栅栏 + 自旋"自己实现网格屏障。一个正确的单次屏障至少要包含：先到达者原子加一、最后到达者把计数清零并翻转相位、其余者自旋等待相位，最后以 __syncthreads() 广播结果。

__device__ void grid_barrier(int nblocks, int* count, int* phase, int target) {
    __syncthreads();
    if (threadIdx.x == 0) {
        __threadfence();
        int ticket = atomicAdd(count, 1);
        if (ticket == nblocks - 1) {
            *count = 0;
            __threadfence();
            atomicExch(phase, target);
        } else {
            while (atomicAdd(phase, 0) < target) {
            }
        }
    }
    __syncthreads();
}

• 这段骨架只能保证"同一次屏障"的正确性：相位目标必须随轮次递增，计数清零必须发生在翻转相位之前。生产环境更推荐直接使用 cooperative groups 或 mbarrier 组合，手写网格屏障是死锁高发区，任何一条路径提前返回都会让其余块永久自旋。
• 跨 GPU 的可见性把作用域推到 sys。gpu 作用域的原子只保证本 GPU 的 L2 汇聚；要让对端 GPU 的 kernel 看到本卡写入，必须使用 sys 作用域的原子或栅栏，硬件会把请求送出 NVLink 并在对端建立可见性。P2P 直写、GPUDirect RDMA、NVSHMEM 的 GPU 发起通信全部遵循这条规则：sys 作用域不是可选项，而是跨设备正确性的定义域。
• SM90 之后多了 cluster 作用域：同一线程块簇内的 CTA 可以通过分布式共享内存（DSMEM）互相读写，cluster.sync() 与 cluster 作用域原子负责簇内可见性，范围介于 cta 与 gpu 之间。Blackwell 的 2-CTA 协作 MMA（cta_group::2）正是依赖簇内共享的 TMEM 与簇作用域同步，把两个 SM 组成一个逻辑计算单元。

模式五：异步代理与 TMEM 的同步语义

• Hopper 与 Blackwell 把内存访问按"谁执行"分成多个代理：generic proxy 执行普通 ld/st；async proxy 执行 TMA 与 cp.async.bulk 等批量异步拷贝；Blackwell 的 tcgen05 指令族则通过 tensor 通道访问 TMEM。跨代理的写不会自动对彼此可见，必须用代理栅栏或完成量追踪建立排序。
• 规则可以浓缩为两条。第一，generic proxy 写共享内存后要让 async proxy 读取（例如构造 TMA 描述符后发起拷贝），需要在两者之间插入 fence.proxy.async。第二，async proxy 写入共享内存后要让 generic proxy 读取，则通过 mbarrier 的完成量追踪自动建立顺序，等待方通过相位检查即可安全读取。
• Blackwell 的 tcgen05 把这条规则推进到张量存储器。典型流程是：MMA 指令异步写 TMEM；tcgen05.commit（CUTLASS 中封装为 umma_arrive）让 mbarrier 观察此前所有 UMMA 的完成；消费者等待 mbarrier 相位后，用 tcgen05.ld 读 TMEM；再以 tcgen05.wait::ld 等待读操作落盘，最后才使用数据。
• 当 TMEM 需要在 warp 之间共享时，还有一对专门的排序原语：写方在 __syncthreads() 之前插入 tcgen05.fence::before_thread_sync，读方在之后插入 tcgen05.fence::after_thread_sync，把异步的 tcgen05 操作锚定到执行屏障的两侧。Triton 在 2025 年就修过一类真实缺陷：TMEM 基地址槽位被 async proxy 复用前缺少代理栅栏，导致偶发的地址污染------这不是理论风险，而是每天都在内核里上演的工程问题。
• TMEM 交接流程（text 树）：

tcgen05 提交与等待
├── producer warp
│   ├── tcgen05.mma 异步写 TMEM
│   └── tcgen05.commit -> 把完成信号投递给 mbarrier
├── mbarrier
│   └── 相位翻转 -> 所有等待者观察到完成
└── consumer warp
    ├── tcgen05.ld 读 TMEM 到寄存器
    ├── tcgen05.wait::ld 等待读完成
    └── 跨 warp 共享前：tcgen05.fence::before_thread_sync + bar.sync

三种写法的等价性与代价

• 同一段"写数据再置标志"的逻辑至少有四种写法，语义强度与代价依次上升：weak 写加配对的 acquire/release 是最低正确成本；relaxed 原子加显式 fence 稍贵且更容易写错；sc 原子最贵，在没有特殊理由时不必使用；而"volatile 加 __threadfence()"是老代码兼容路径，语义上等价于 sc.gpu 栅栏，性能与可读性都不占优。
• 选型原则：需要跨线程建立因果的地方用 release/acquire；只需要原子性的计数与统计用 relaxed 或 red；需要与主机或外设交互才升到 sys；sc 仅用于教学示例或极少数无法推理的场景。每多一级强度，都是在为"省心"支付延迟与带宽。

技术优缺点与适用场景

• 语义强度与代价总览（text 树）：

同步语义的代价阶梯
├── 核心优势
│   ├── release/acquire: 以最小代价建立因果，GPU 同步的默认选择
│   ├── relaxed/red: 只买原子性，吞吐最高
│   └── sys 作用域: 唯一能跨 GPU 与主机建立可见性的手段
├── 主要局限
│   ├── 弱模型默认值: 任何遗漏同步的代码都是未定义行为
│   ├── 作用域易错: cta/gpu/sys 选错，测试通过但生产偶发失败
│   └── 异步代理: TMA/tcgen05 把同步点从指令序变成代理与相位
├── 性能特征
│   ├── 弱写: L1 命中，纳秒级
│   ├── L2 原子: 数百周期，同地址串行化
│   ├── gpu 栅栏: 排空存储流水，微秒级开销的源头
│   └── sys 栅栏: 跨 NVLink/PCIe，最贵
└── 适用规模
    ├── cta 作用域: 块内流水线、共享内存协作
    ├── gpu 作用域: 全卡归约、持久化内核
    └── sys 作用域: 多卡通信、GPU 直连网络

• 适用场景
• ✅ 自定义归约与 split-K 内核：部分和跨 CTA 合并必须用原子加栅栏的 last-block 模式
• ✅ 持久化内核的阶段同步：网格屏障把多阶段算法压进一次启动，省去 kernel 间空隙
• ✅ Warp-specialized 流水线：mbarrier 加 TMA 把搬运与计算完全重叠，是 Hopper/Blackwell GEMM 的标配
• ✅ 多卡通信与 GPU 发起网络：NVSHMEM、GPUDirect RDMA 的信号语义全部依赖 sys 作用域
• ✅ 框架层自定义算子：PyTorch custom op 与多 stream 场景下，流间依赖与事件同步是正确性边界
• 禁忌场景
• ❌ 能用高层 API 解决的绝不用裸 PTX：libcu++、cooperative groups、CUB 已覆盖绝大多数需求
• ❌ 高频小同步：细粒度 fence 会排空流水线，能合并就合并、能 warp 聚合就聚合
• ❌ 在热循环中使用 sc 原子：顺序一致在 GPU 上几乎总是过度设计
• ❌ 依赖测试通过来证明并发正确性：竞态在低负载下大概率不触发，必须用工具与压力测试

实战落地

• 调试工具链与验证流程（text 树）：

同步缺陷的定位流程
├── compute-sanitizer --tool memcheck -> 越界与非法访问
├── compute-sanitizer --tool racecheck -> 共享内存竞态为主
├── compute-sanitizer --tool synccheck -> 分支中的非法 __syncthreads()
├── compute-sanitizer --tool initcheck -> 未初始化共享内存
└── 压力测试
    ├── 多流并发 + 随机化抢占
    ├── 微调 occupancy 制造不同调度序
    └── 跨架构回归（Volta/Ampere/Hopper/Blackwell）

• 使用要点：racecheck 的强项是共享内存竞态，对全局内存的跨块竞态覆盖有限，后者必须靠代码推理与压力测试；synccheck 专门抓"部分线程提前返回、其余线程仍在屏障内"的经典死锁；initcheck 则能发现被 __syncthreads() 掩盖的未初始化读。
• 性能守则
• 把 fence 放在最外层而不是最内层：一段循环只需要一次栅栏时，绝不逐迭代加
• 用 red 代替 atom：不需要旧值的累加一律走 red 或 __reduce_add_sync
• 用 warp 聚合压平争用：每 warp 一次原子，先归约再提交
• 用 mbarrier 相位替代轮询标志位：相位翻转本身就是硬件层面的完成通知，避免空转读 L2
• 优先 scope 最小化：块内能解决的用 cta，不要顺手写 gpu，更不要习惯性 sys
• 避坑清单
• 只加 __threadfence() 不加配对 acquire：栅栏只是排序线，同步边需要两端
• 把 __syncthreads() 当成块间同步：它只管一个 CTA，跨块必须原子或网格屏障
• 在 Volta 及以后假设 warp 锁步：独立线程调度会让老代码读到未初始化数据，需补 __syncwarp()
• TMA 写完共享内存直接弱读：必须等 mbarrier 相位或插代理栅栏
• tcgen05 读 TMEM 前缺 wait::ld：异步读尚未完成就使用寄存器，产生不可复现的错误数据
• 跨 GPU 用 gpu 作用域原子：对端永远看不到，必须升级到 sys
• 混用不同宽度访问同一地址：原子性与别名规则被打破，属于未定义行为
• 手写网格屏障缺相位设计：第二次复用立即死锁，生产代码优先 cooperative groups
• 线上隐患与复盘：某推理服务在 Flash-Decoding 的合并阶段偶发精度异常，最终定位为 partials 写入后直接 atomicInc、缺少 threadfence，低负载时 L2 恰好有序、高并发时乱序暴露；另一例是 Triton 内核在高 occupancy 下偶发错误，根因是 TMEM 基地址槽位被异步代理复用前缺少代理栅栏。两例的共同教训是：并发正确性不能靠观察，只能靠模型。
• 核心代码速查（一个安全的最小闭环）：

#include <cuda/atomic>

struct Flag {
    cuda::atomic<unsigned int, cuda::thread_scope_device> v{0};
};

__device__ void publish(float* data, Flag* flag) {
    *data = 1.0f;
    flag->store(1u, cuda::memory_order_release);
}

__device__ float wait_and_read(const float* data, Flag* flag) {
    while (flag->load(cuda::memory_order_acquire) == 0) {
    }
    return *data;
}

全文总结

• 核心原理：PTX 内存模型用 memory order 与 scope 两个正交维度定义可见性，release 与 acquire 的配对是跨线程因果的唯一来源，栅栏只排序不同步。
• 关键结论：GPU 的弱内存语义是性能设计而非缺陷；L1 非相干与 L2 原子串行化决定了每一次强同步的真实价格，作用域每升一级代价显著上升。
• 落地重点：默认用 libcu++ 的原子类型表达意图；归约用 red 加 warp 聚合；流水线用 mbarrier 相位与 TMA 完成量；跨卡通信升到 sys；永远用工具与压力测试验证，而不是靠"跑通一次"。
• 技术本质：并发正确性是一份由内存模型、硬件实现与同步原语共同签署的契约------理解了契约的边界与价格，才能既写出正确的内核，又不在不必要的栅栏上浪费每一纳秒。

系列说明

• 本文为《AI 深度解析》系列文章之一，该系列长期更新 AI 底层原理、架构机制、工程实战与前沿技术解读，聚焦从软件运行时、编译器、算子内核、指令集、硬件微架构一路下沉到数字电路、半导体物理与制造工艺的最底层原理。

专栏推荐

• AI 工程与安全深度实战
• TypeScript 从入门到精通
• LangChain/LangGraph 从入门到精通
• Rust 从入门到精通

参考资料

• PTX ISA 9.4 Documentation - Memory Consistency Model
• A Formal Analysis of the NVIDIA PTX Memory Consistency Model (ASPLOS 2019)
• CUDA C++ Programming Guide - Memory Model and Synchronization
• libcu++ Documentation - cuda::atomic and cuda::barrier
• ThunderKittens 2.0: Even Faster Kernels for Your GPUs
• CUTLASS Tutorial: Writing GEMM Kernels Using Tensor Memory for NVIDIA Blackwell GPUs
• Triton PR 12340: Fence the TMEM base-address slot before async-proxy reuse