导言
进程 A 已经在加速卡上生成一块数据，进程 B 能不能直接使用？把指针发过去是否就够了？把 UBMEM 和 CUDA IPC 放在一起看，最有价值的切入点就是这个问题。
本文面向知道进程、指针和设备内存，但尚未写过跨进程设备通信的读者。先用 CUDA IPC 建立“共享句柄 → 本地映射 → 同步访问 → 有序释放”的直觉，再沿 HCOMM 的真实实现解释 UBMEM。它们的交集是建立可访问的内存视图；地址有效、数据就绪和访问成本，仍是三个需要分别回答的问题。
导言
读到 Tutti 的 GPU io_uring 一节时，我几乎完全没看懂。SQ、CQ、IOCB、CUDA Event 和 Green Context 挤在一起，很难看出它们各自解决什么问题。
本文先用取餐叫号解释核心直觉，再用 Linux io_uring 的 SQ、CQ、SQE、CQE 和 SQPOLL 建立准确模型，最后把这些对象放回 Tutti：为什么队列能把发起请求和等待结果拆成两个时间点，以及为什么还需要 CUDA Event、Green Context 和 slack-aware Scheduler 才能真正减少 GPU 停顿。
导言
我最初把 HCCL 理解成集合通信，把 HiXL 理解成单点通信。这个分法可以作为起点，却会让 SHMEM 无处安放：它既能一对一 Put/Get，也能做原子操作与同步，为什么还需要“对称内存”这套约束？
关键在于，HCCL、HiXL 和 SHMEM 并不只是在争夺同一种通信 API。HCCL 更接近“我要完成什么群体操作”，HiXL 更接近“我要把哪段数据传到哪里”，SHMEM 则把问题改写成“我要访问哪个 PE 上的哪个内存坐标”。它用跨 PE 的布局约束，换取设备侧可以低开销地定位和操作远端数据；但当各 PE 的容量需求严重不均时，这份约束也确实可能造成浪费。
导言
昇腾通信栈总图从上到下列出了语义、资源、提交者、搬运引擎和互联五部分。看到五个编号，很自然会追问：它们是否正好对应 OSI 七层、互联网五层或 TCP/IP 四层？答案是否定的。经典网络模型按协议功能分层，这张图则按一次通信如何从程序意图落到字节搬运划分责任。本文把两套分类放到同一张坐标系中，说明哪些位置可以近似对应，哪些位置必须保留“无对应”的边界。
导言
希望在华为 A3/A5 上实现 InferenceX 中 DeepSeek-R1 在 B200、H100 上的效果，首先需要明确“效果”究竟指什么。它不是一个孤立的峰值吞吐数字，而是由推理引擎、集群调度、并发负载、单用户速度和服务成本共同构成的性能曲线。
本文先解释 Dynamo TRT-LLM 的分层，再辨析 Conc、Interactivity、TTFT 和 Throughput/Chip，最后说明 AgentX 为什么把测试单位从独立请求升级成持续演化的 Agent 会话树。
导言
DeepSpeed 的五个观测工具不是重复功能：FLOPs Profiler 回答“理论计算在哪”，PyTorch Profiler 回答“时间实际花在哪”，Communication Logging 回答“哪类 collective 在拖慢”，Autotuning 回答“哪个配置在当前目标上更好”，Monitor 回答“实验长期发生了什么”。
导言
“异步”只说明调用可以提前返回，不说明后台工作一定能被隐藏。DeepNVMe、Ulysses-Offload、ZenFlow 和 DataStates 分别搬运参数/状态、Attention 工作集、优化器更新与 checkpoint；判断它们是否有效，必须同时检查前台关键路径和后台队列是否稳定。
导言
能否把 MOV A, B 的直觉扩展到跨 device、跨节点甚至跨超节点：应用只给出源地址和目标地址，系统自动选择 HCCS、RDMA 等路径，把大 tensor 直接搬到消费者附近？可以把它做成 verl TransferQueue 的可插拔数据面，但不应把这件事直接称为“MTE 跨超节点”。MTE 是 Ascend 内存层级和部分 HCCS 路径上的搬运引擎；真正向应用提供远端地址、单边 put/get、注册和完成语义的是 SHMEM、MemFabric 一类软件层；样本字段、ready、consumed、staleness 和恢复仍应由 TransferQueue 管理。