本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
理解 elastic dispatch，需要把 Python 接口、native 调用链、对称内存申请和 device kernel 放在同一条执行路径中阅读。本页基于源页面收录的 cf9f87a51854ac20d608f683979171cb1fc65c69 版本证据，通过交互式 DAG、函数下钻和源码定位建立这些层次之间的对应关系。
核心边界是：host 路径与容量预算不代表 device 数据搬运已经实现。页面保留占位 kernel、缺失的数据布局与同步风险提示，帮助读者辨认已有实现和待补齐部分。
导言
本系列最后把视角移到 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 文件仍然是站内文章身份和索引入口。因此读者可以从笔记、分类或标签进入本文，也可以从本文返回对应索引页面。