本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
本系列最后把视角移到 cann/shmem 的 UDMA Device 数据面：AIV 如何找到某个 PE/QP 的队列资源，为什么 WQE 常先在 UB 中组装，st_dev 到底做了什么，以及“指定 QP 就能并行”成立的条件。这里的代码用于展示机制，底层结构和接口必须与目标 CANN、ops 包、SoC 和 SHMEM revision 成套使用。
导言
原生 URMA 要显式管理 Context、Segment、Jetty、WR 和完成队列。cann/shmem 提供了更高层的 PGAS 编程模型：程序主要面对“对称地址、目标 PE、put/get 和同步”。本文先解释 aclshmem_my_pe()、aclshmem_n_pes() 和 aclshmemx_udma_put_nbi()，再用两 PE 的 put-with-signal Case 说明数据和通知如何配合。
导言
“WQE 和 Jetty SQ 还不能同时写？”这句话实际上混合了四个问题：软件和硬件能否同时访问队列、一个 SQ 能否挂多条请求、多个 Host 线程能否共享 Jetty、多个 AIV 能否直接驱动同一 QP。答案并不相同。本文先讲清提交与完成，再逐一划定并发边界。
导言
本文把 URMA 官方样例中的核心 WRITE 路径收缩成一个教学 Case。目标不是复制几百行初始化代码，而是让零基础读者看懂：程序要准备哪些资源、每个结构体字段是什么意思、一条请求如何提交和确认完成。文中的核心代码按官方接口整理；初始化和带外交换用伪代码表示，实际编译时应以所使用 UMDK 版本的头文件与官方样例为准。
导言
我刚开始接触 URMA 时，最容易卡住的问题不是某个函数不会调用，而是概念没有连成一条线：WQE 和 Jetty SQ 是什么关系，Segment 为什么要注册和导入，urma_post_jetty_send_wr() 提交之后又去了哪里。本文只做一件事：沿着一条 WRITE 请求的生命周期，把这些名词放回它们各自的位置。
导言
阅读 4357 行 deepep_moe_dis_dispatch.h 时，最大的困难不是找到某个函数，而是持续维护 E2E 阶段、函数调用和具体源码行之间的对应关系。静态长文适合建立概念框架，却不便于在多条并行执行路径之间反复定位。
本页将同一份 Ascend C 参考实现组织为三轨联动工作区：左侧展示 Full-Mesh dispatch 的端到端执行 DAG，中间拆解当前函数的调用和分段逻辑，右侧保留完整源码。读者可以从阶段进入函数、从调用跳转到被调函数，也可以通过搜索和行号反向追踪同步协议与数据流。
导言
MoE dispatch 的困难并不只是把 token 从一张卡搬到另一张卡，而是要在 Top-K 路由运行时才确定的前提下，同时解决槽位分配、跨核协作、远程写入、完成通知和接收端连续排布。如果只盯着某个拷贝循环，很容易忽略控制面和同步协议才是这份实现的骨架。
本文以 deepep_moe_dis_dispatch.h 的 4357 行 Ascend C 参考实现为对象，从 SIMT 线程模型和 Full-Mesh 通信窗讲起，沿“本地打包 → 生成并提交 URMA WQE → doorbell 触发 → flag/count 对账 → 前缀和定位 → 输出重排”还原完整执行路径。页面把关键函数、内存布局、时序约束和可验证的优化方向放到一张连续地图中，帮助初学者建立从源码行号到通信机制的对应关系。
导言
这是一篇用于验证 HTML 正文文章接入 的站内测试文章。它保留 Markdown front matter 和简短导言，让 MkDocs Blog 能继续生成文章 URL、首页摘要、分类、标签和搜索索引；实际正文则由同名 .preview.html 在文章详情页中展示。
核心判断是：HTML 只是正文表现形式，Markdown 文件仍然是站内文章身份和索引入口。因此读者可以从笔记、分类或标签进入本文，也可以从本文返回对应索引页面。
导言
一次 64 B 远端读取，数据在链路上只需要约 200 ns，端到端却可能超过 2 μs；当 1024 个本地发起上下文连接 1024 个远端端点时，按 Queue Pair（QP）组织的连接状态又会膨胀到约 537 MB。OpenURMA 认为这不是某个 RDMA Kernel 写得不够快，而是 QP over PCIe 这一抽象同时制造了状态乘积和外围设备往返。
OpenURMA 是 Unified Bus（UB）传输层与事务层的 clean-room 开放实现。它用 Jetty / TP Channel 拆开应用状态与可靠传输状态，把 UB Controller 放到片上总线，并为短同步操作提供绕过 Work Queue 的 Load/Store 路径。本文沿这条依赖链解释方案，同时把 500 ns / 2186 ns 放回论文的模拟条件：这组结果证明新抽象值得继续做成硅，不等于 Ascend 950 或任意商用 UB 产品已经交付同样数字。