本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
W8A8、W8A4、W16A8 看似只差两个数字，实际可能对应完全不同的对象、尺度粒度、在线流程和硬件 kernel；FP8 与 MXFP8 都是八位元素，却又因块尺度而具有不同的数据布局。更容易误解的是，量化位宽、检查点大小和最低运行显存是三个不同问题。
本文先建立一套可复用的阅读方法，再用物理结构、实现逻辑、流程、时序和张量数据流解释常见路径，最后核对截至 2026-07-28 的 Qwen3.5、Kimi K3 和 GLM-5.2 开放权重。所有“多大”均来自当前 Hugging Face 仓库中 .safetensors 文件的实际字节和，而不是用参数量乘标称位宽反推。
导言
训练万亿参数模型时，几千甚至上万张 NPU/GPU 不是各算各的。每一步训练都会反复交换梯度、激活和专家 token，网络就像一座每秒要分拣海量包裹的城市：包裹搬得慢，昂贵的计算卡只能停下来等路。
UB-Mesh 的关键想法不是发明一条“无限快”的网线，而是承认通信具有局部性：把最频繁、最大量的通信放到近处的短链路，把较少的远程通信留给远层网络，再让路由、集合通信和容错都理解这张不对称的地图。
导言
本文逐段精翻并解释 xDeepServe 团队的论文 Huawei Cloud Model-as-a-Service on the CloudMatrix384 SuperPod。全文以 arXiv v6 为准，把摘要、正文、结论与贡献者段落编号为 P001–P129，并完整收录论文的 20 幅原图。除忠实翻译外，本文还从物理拓扑、因果链、运行流程、组件时序与张量流五个视角解释 XCCL、FlowServe、Transformerless 和可靠性机制。原论文采用 CC BY 4.0 许可；本文对图像做了裁切，对文字做了中文翻译、结构化重排与解释性扩写，改动不代表原作者观点。
导言
一台加速卡跑不下、几百张卡又容易互相等待时，问题就不再只是“算力够不够”，而是谁负责算、谁负责搬、状态放在哪里、下一步在等什么。本文以知乎学习笔记为线索，回到原始论文逐项核验，用“超级厨房”“专家快递”和“共享图书馆”三个直觉，解释 CloudMatrix384 服务 DeepSeek-R1 的四个关键机制。
导言
MPI、RDMA 和内存语义都能搬运数据，但它们让应用表达的是不同对象：MPI Point-to-Point 表达 rank、tag 和消息，RDMA Verbs 表达 QP、WQE 和完成记录，内存语义则尽量让应用只表达 地址、长度、读写方向和数据依赖。
后一种方式的收益不是“凭空消灭通信”，也不是“任何场景都比 RDMA 带宽高”。它真正改变的是通信契约：把外围队列事务下沉为更接近计算流水的地址访问与 tile 可见性，使 Scale-Up 域内的短操作、细粒度生产消费和异步流水更容易表达。
导言
小 batch LLM 推理并不总是被矩阵乘法本身限制。数十到数百个 kernel 的启动边界、kernel 尾部气泡、中间张量写回 HBM，以及 MoE 的 Dispatch/Combine 通信，都可能让计算单元等数据、让内存等指令、让互联等计算。MegaKernel 的核心不是“把代码写得更大”，而是把 host 侧的算子调度下沉为 GPU 内部的任务系统。
本文沿三条路线展开：Hazy Research 的手写整模型 MegaKernel、MPK 的编译器与常驻运行时、DeepSeek MegaMoE 的 expert-wave 通信计算流水。结论是：这类优化用更强的静态专用化和片上资源约束，换取更少的启动边界与更细的就绪事件；收益必须与寄存器、共享内存、HBM、互联、功耗和动态路由一起核算。
导言
“降低显存”不是一种动作。它可能是在减少对象大小、限制同时在途的对象数量、把对象搬到 CPU、缩短对象生命周期，也可能只是把 allocator 中未占用的缓存块归还给驱动。
本文固定到 XTuner 397b 分支 commit e949653，从一个第一次接触训练显存优化的读者视角，拆解原始清单中的 13 个技术点。每项都回答：大对象是什么、为什么形成峰值、执行时序怎样、数据流经过哪里、伪代码如何写、适用于什么条件，以及效果边界在哪里。
导言
DeepSpeed 的五个观测工具不是重复功能：FLOPs Profiler 回答“理论计算在哪”，PyTorch Profiler 回答“时间实际花在哪”，Communication Logging 回答“哪类 collective 在拖慢”，Autotuning 回答“哪个配置在当前目标上更好”，Monitor 回答“实验长期发生了什么”。
导言
MoE 和模型压缩看似方向相反：前者扩大总参数，后者缩小部署对象。它们实际都在重写“每个 token 访问哪些参数”。DeepSpeed-MoE/MoE Inference 管理稀疏路由和专家放置；Model Compression/MoQ 管理层、权重和精度的删减。