导言
进程 A 已经在加速卡上生成一块数据，进程 B 能不能直接使用？把指针发过去是否就够了？把 UBMEM 和 CUDA IPC 放在一起看，最有价值的切入点就是这个问题。
本文面向知道进程、指针和设备内存，但尚未写过跨进程设备通信的读者。先用 CUDA IPC 建立“共享句柄 → 本地映射 → 同步访问 → 有序释放”的直觉，再沿 HCOMM 的真实实现解释 UBMEM。它们的交集是建立可访问的内存视图；地址有效、数据就绪和访问成本，仍是三个需要分别回答的问题。
导言
先理解设计解决什么问题，再看分组公式。 从两张卡直接发送开始，观察参与者增多后接收方的竞争，尝试分批、错开目的地与接收方许可，最后回到 MoonEP 的 64P group。交互容量是教学假设，源码映射是固定版本事实；本文不把模拟结果作为性能测量。
导言
我最初从外部技术资料了解到 Data-as-Flag 时，直觉上把它理解为三种省掉独立完成通知的方法：把 flag 塞进数据块、用数据校验值确认整批到达，或者先用特殊值填满接收区，再观察它是否被真实数据覆盖。
顺着这三个方向检查 NVIDIA 的公开资料后，答案很明确：NVIDIA 不但有相同思路，NCCL 的 LL/LL128 已经长期使用内嵌 flag；NCCL 2.31.2 的 LLA2A 又把它做成了面向低时延 All-to-All 的 payload + epoch 原子槽位。不过，公开实现更偏好显式 epoch，而不是让任意 payload 或 checksum 单独承担正确性。
导言
“WQE 和 Jetty SQ 还不能同时写？”这句话实际上混合了四个问题：软件和硬件能否同时访问队列、一个 SQ 能否挂多条请求、多个 Host 线程能否共享 Jetty、多个 AIV 能否直接驱动同一 QP。答案并不相同。本文先讲清提交与完成，再逐一划定并发边界。
导言
本文把 URMA 官方样例中的核心 WRITE 路径收缩成一个教学 Case。目标不是复制几百行初始化代码，而是让零基础读者看懂：程序要准备哪些资源、每个结构体字段是什么意思、一条请求如何提交和确认完成。文中的核心代码按官方接口整理；初始化和带外交换用伪代码表示，实际编译时应以所使用 UMDK 版本的头文件与官方样例为准。
导言
我刚开始接触 URMA 时，最容易卡住的问题不是某个函数不会调用，而是概念没有连成一条线：WQE 和 Jetty SQ 是什么关系，Segment 为什么要注册和导入，urma_post_jetty_send_wr() 提交之后又去了哪里。本文只做一件事：沿着一条 WRITE 请求的生命周期，把这些名词放回它们各自的位置。
导言
这是一篇用于验证 HTML 正文文章接入 的站内测试文章。它保留 Markdown front matter 和简短导言，让 MkDocs Blog 能继续生成文章 URL、首页摘要、分类、标签和搜索索引；实际正文则由同名 .preview.html 在文章详情页中展示。
核心判断是：HTML 只是正文表现形式，Markdown 文件仍然是站内文章身份和索引入口。因此读者可以从笔记、分类或标签进入本文，也可以从本文返回对应索引页面。
导言
一台服务器装有八张 400 Gbps NIC，不等于任意一张 GPU 都能拿到八张网卡的总带宽。现有 GPU 集群通常把 GPU 与“最近的”NIC 静态绑定；当 LLM 推理请求、MoE token 或推荐模型 embedding 产生不均衡流量时，热点 GPU 会堵在一张 NIC 上，旁边的 NIC 却可能空闲。
OSDI 2025 论文 FuseLink 的核心思想，是把 NVLink/NVSwitch 从“服务器内部的 GPU 互连”重新解释为“跨服务器网络的数据路径延伸”：流量先经 NVLink 到达更适合访问空闲 NIC 的中继 GPU，再通过 RDMA 发往远端。本文沿论文 Figure 1、2、3、4、5、8 还原这条设计链，并用其余实验结果说明收益、代价与边界。
导言
把 SSD 数据送进 GPU，最直观的优化似乎是“绕过 CPU”。但这句话混合了两个不同问题：数据是否经过 CPU 内存，以及 I/O 请求究竟由 CPU 还是 GPU 发起。NVIDIA GDS 解决前者，BaM 进一步改变后者；代价是原本由 CPU 承担的队列管理、并发和缓存压力转移到了 GPU。
本文整理 DaMoN 2025 论文 Path to GPU-Initiated I/O for Data-Intensive Systems：先沿 Figure 1 比较五条 GPU-centric Storage 路径，再还原 BaM、GDS 与 SPDK 的实验边界。核心结论不是“GPU 发起一定更快”，而是系统应根据 CPU、GPU、PCIe、SSD 与数据复用状态，选择由谁支付 I/O 控制成本。
导言
看到“应用必须持有 Transport*”时，我真正卡住的是：持有到底是什么意思？为什么直接保存一个后端指针就能工作，统一的 TransferEngine 反而走不通？
把这个词拆开后，Classic 与 TENT 的差异就不再只是两套接口。Classic 的公共 Batch 先于后端选择而创建，后端私有状态缺少稳定的安放位置；TENT 则在选定后端后，为每个 transport 创建独立 SubBatch，再由统一运行时协调提交、状态与回收。
因此，判断一个 Engine 是否容易扩展多个后端，不能只数有多少个 Transport 子类。真正要问的是：后端的私有状态放在哪里，由谁创建，又由谁保证它完成整个异步生命周期。