本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
我最初把 HCCL 理解成集合通信，把 HiXL 理解成单点通信。这个分法可以作为起点，却会让 SHMEM 无处安放：它既能一对一 Put/Get，也能做原子操作与同步，为什么还需要“对称内存”这套约束？
关键在于，HCCL、HiXL 和 SHMEM 并不只是在争夺同一种通信 API。HCCL 更接近“我要完成什么群体操作”，HiXL 更接近“我要把哪段数据传到哪里”，SHMEM 则把问题改写成“我要访问哪个 PE 上的哪个内存坐标”。它用跨 PE 的布局约束，换取设备侧可以低开销地定位和操作远端数据；但当各 PE 的容量需求严重不均时，这份约束也确实可能造成浪费。
导言
在昇腾通信栈的第五轴中，PCIe、片内 NoC、HCCS、RoCE 与 UnifiedBus 被放在同一行。看到这些概念，一个很自然的疑问是：它们为什么没有统一？是不是每一种新互联，都是为了解决上一代的缺陷，并最终取代前者？
这个问题抓住了技术演进，却预设了一条并不存在的替换链。这些概念分别工作在芯片内部、服务器 I/O、节点内 Scale-Up 和集群 Scale-Out 等不同范围，提供的事务与内存语义也不相同。本文从无法绕开的物理约束出发，沿历史纵轴梳理它们出现的契机，再用同一组维度比较其设计取舍，最后说明：什么时候一种新思想只需要增加后端，什么时候它会形成新的编程契约和代码仓。
导言
在昇腾通信栈的第二轴中，HCOMM、SHMEM Runtime、IPC、CANN VMM 与 Fabric Memory 被放在同一个“资源、地址与运行时”区域。它们都在帮助程序访问另一进程、另一设备甚至另一节点的内存，因此很容易被理解成五套重复方案：既然目标相同，为什么不统一成一套 API？
这个问题真正触及的是系统抽象如何演进。五个概念共享“让数据可达”的目标，却分别承诺资源组织、PGAS 编程、进程共享、虚拟内存管理和内存池化；它们不是五代同类技术，而是从五个不同矛盾长出的责任边界。本文从第一性原理拆出这些不可互换的契约，再沿时间纵轴和能力横轴梳理其提出契机、公开时机、新仓库形成条件与未来收敛方向。
导言
《Ascend Communication Stack》把 HCCL、HiXL、CANN SHMEM 和 Mooncake UBShmem 放在第一轴。既然它们最终都在昇腾设备之间搬数据，也会复用相似的 Runtime、内存和硬件资源，一个很自然的问题是：为什么没有统一成一个库？
关键不在名字，也不在 payload 最后走 HCCS、RoCE 还是 UB，而在调用者究竟声明了什么契约。HCCL 声明 collective，HiXL 声明一批 buffer transfer，CANN SHMEM 声明 PE 对对称对象的 RMA/AMO，Mooncake UBShmem 则服务项目自己的映射型 KV 快路。本文沿公开时间线还原四条路线的提出契机与设计转折，再横向判断哪些差异必须保留、哪些历史包袱可以收敛。研究截止日为 2026 年 8 月 26 日。
导言
在昇腾通信栈的第四轴里，ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 被放在相邻位置。看到这么多搬运相关名词，一个很自然的判断是：它们大概是同一种能力的不同代际，后来者之所以出现，是因为前一代不够好。
这个判断抓住了技术演进的一部分，却把几类不同对象混在了一起。这些概念不是七代同类传输引擎，而是地址能力、操作表达和执行后端在不同距离、粒度与控制路径下的组合。本文从无法绕开的物理成本出发，再沿历史纵轴和技术横轴解释它们为何没有统一，以及什么时候一种新思想才真正值得形成新的代码仓。
导言
昇腾通信栈总图从上到下列出了语义、资源、提交者、搬运引擎和互联五部分。看到五个编号，很自然会追问：它们是否正好对应 OSI 七层、互联网五层或 TCP/IP 四层？答案是否定的。经典网络模型按协议功能分层，这张图则按一次通信如何从程序意图落到字节搬运划分责任。本文把两套分类放到同一张坐标系中，说明哪些位置可以近似对应，哪些位置必须保留“无对应”的边界。
导言
解释 Scratchpad 时，我们很快会遇到一个新问题：数据由 DMA 显式搬入片上 SRAM，但它从 HBM 到计算核心附近的 Scratchpad，究竟经过了什么？答案里反复出现的 NoC，又是什么概念？
这篇文章沿着一次数据搬运，把几个容易混在一起的对象摆回各自的位置：Scratchpad 负责本地存取，NoC 负责片上运输，DMA 负责执行显式搬运。