本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
任务是用 msprof 测量 elastic_dispatch.cpp 的通信性能，再用 MindStudio Insight 分析 icache miss 等问题。实际环境是 昇腾 950、最新 CANN、多机多卡。第一次接触这套工具，最容易卡住的不是参数，而是分不清“整个分布式调用慢”“某个核慢”和“某类指令停顿”分别需要什么证据。
本文按 确认 V2 调用入口 → 建立延迟基线 → 采集系统时间线 → 检查 ICache 与 SIMT 停顿 → 对照实验展开。内容来自截至 2026-09-16 的公开官方文档和固定版本源码，没有在目标 950 集群实测；涉及通信重放的命令是能力探测模板，不承诺该自定义算子已被工具支持。
导言
之前学习 Data-as-Flag 时，我们讨论过把 flag 塞进数据块：每个 512 B 块中，480 B 是有效数据，32 B 用来证明“这一块已经到达”。现在希望减少这部分控制开销，改成“前面 relaxed order 发送，最后一个 strong order”。
这个改动的核心，是把“每块都带证明”改成“用队列末尾的有序操作，为前面一批传输提供完成证明”。 但必须解释清楚：最后一个是什么、保证覆盖哪条队列、接收方如何得知完成，以及何时可以复用 buffer。本文沿实际代码逐层回答。
导言
如果目前只知道“URMA 是组 WQE、敲 doorbell”，下一步需要补上三个问题：请求可以发给谁、资源由谁准备、什么时候才算完成。 RM 主要回答第一个问题；SHMEM 的 Ascend 950 UDMA 示例把后两个问题串成了可阅读、可编译的 Ascend C 程序。本文从定义走到两卡示例，并给出原生 URMA 显式选择 RM 的办法。
导言
all-to-all 要让每个参与者给其他参与者发送数据，为什么还要分 group？分组可以控制同时争用有限资源的请求，让通信更接近硬件能稳定处理的速度；但它是否能“防止阻塞”，取决于分的是什么，以及阻塞发生在哪一层。本文从四个 rank 的调度例子出发，解释限流、错峰、接收许可和拓扑分层，再区分 NCCL group 的并发推进语义。目标是看懂通信实现的设计动机，并知道怎样验证收益；文中的容量与规模例子均为推导，没有集群性能实测。
导言
进程 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 单独承担正确性。
导言
我是零基础的算子开发初学者。第一次面对混合了 C++、Ascend C、SIMT 和 SHMEM 的通信算子，难点并不只是某个 API 不认识，而是同一行里往往同时出现模板参数、地址空间、数据搬运和同步语义。我想迁移这样的文件，就需要先回答四个问题：数据在哪里、谁在执行、这一句改变什么、下一步何时能使用结果。
这篇文章从实际遇到的代码片段出发，把接口拆成尽量小的学习单元，再逐项解释模板参数、普通参数、返回值、地址偏移和同步范围。内容核对了 CANN 官方文档及 CANN/asc-devkit、CANN/shmem 公开源码。尚未取得原算子完整文件，因此不虚构原文件行号，也不把业务封装的推测写成 API 定义。 文中的示意代码用于理解语义，未在 NPU 上编译运行。
导言
理解 elastic dispatch，需要把 Python 接口、native 调用链、对称内存申请和 device kernel 放在同一条执行路径中阅读。本页基于源页面收录的 cf9f87a51854ac20d608f683979171cb1fc65c69 版本证据，通过交互式 DAG、函数下钻和源码定位建立这些层次之间的对应关系。
核心边界是：host 路径与容量预算不代表 device 数据搬运已经实现。页面保留占位 kernel、缺失的数据布局与同步风险提示，帮助读者辨认已有实现和待补齐部分。