导言
模型训练建模不是先问“MFU 有多高”,而是先把模型结构、硬件账本、并行切分、调度路径和实测校准放到同一个估算器里。MFU 是其中最干净的计算口径:它把模型理论必需 FLOPs、设备峰值和实测步时连在一起;但显存能不能放下、通信会不会卡住、padding 是否浪费、EP/TP/SP 是否合适,必须另算。
导言
模型训练建模不是先问“MFU 有多高”,而是先把模型结构、硬件账本、并行切分、调度路径和实测校准放到同一个估算器里。MFU 是其中最干净的计算口径:它把模型理论必需 FLOPs、设备峰值和实测步时连在一起;但显存能不能放下、通信会不会卡住、padding 是否浪费、EP/TP/SP 是否合适,必须另算。
导言
Scaling Law 不只是“模型越大越好”的经验总结,而是一套算力预算分配语言:在固定训练预算下,参数量、训练数据、序列长度和训练时长互相竞争;在固定推理预算下,模型大小、生成 token、采样策略、工具调用和 agent rollout 也互相竞争。本文只记录论文中可追溯的公开披露;没有披露的数据明确标为“未披露”,不从参数规模反推训练成本。
导言
多局点、多任务、多角色同时推进时,真正稀缺的不是勤奋,而是 判断力、取舍能力和可复用记录。均匀响应所有任务只能保证不出明显纰漏,却很难形成个人优势;优势通常来自少数高风险、高杠杆、高不确定、强依赖的局点。
本文把工作链路整理成一个可执行系统:先识别重点风险局点,再拒绝低优先级任务;先快穿刺关键假设,再并行派活和紧跟踪;先用原理、显存、性能 MFU 和投产约束做建模,再用实践验证、详细记录和持续修正形成历史;最后把优势进展、后续风险和必要求助稳定汇报出去。
导言
这篇文章记录我当前的 Work with AI 文档工作流:不是把一段 prompt 扔给模型、得到一篇孤立文章,而是把调研、来源管理、论文图表、正文插图、图片上传、Hugo 写作规范、可复用 skill 和 git 发布串成一个可验证的流水线。
这条流水线的关键变化来自 Karpathy 的 LLM Wiki 思路:把知识库视作一个由 LLM 维护的 Markdown 代码库。原始资料进入 raw 层,结构化理解进入 wiki 层,Hugo 文章只是最终发布层。这样每次写作都会沉淀可复用记忆,而不是从聊天记录里重新发明一次。
Building Large-Scale AI Systems on Ascend: Training, Inference, and Multimodal Optimization
导言
谭邵杰,中国科学技术大学本硕毕业,现任华为昇腾训练开发工程师,专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师,长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
我最初从外部技术资料了解到 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 上编译运行。
Ascend DeepEP V2 Elastic Dispatch
导言
理解 elastic dispatch,需要把 Python 接口、native 调用链、对称内存申请和 device kernel 放在同一条执行路径中阅读。本页基于源页面收录的 cf9f87a51854ac20d608f683979171cb1fc65c69 版本证据,通过交互式 DAG、函数下钻和源码定位建立这些层次之间的对应关系。
核心边界是:host 路径与容量预算不代表 device 数据搬运已经实现。页面保留占位 kernel、缺失的数据布局与同步风险提示,帮助读者辨认已有实现和待补齐部分。
导言
刚理解 WQE 时,我看到一份 MoE dispatch 头文件没有调用 aclshmemx_udma_put_nbi(),也没有在发送热路径调用 aclshmemx_udma_quiet()。第一反应是:它是不是用 SIMT 加速了 WQE 下发,又用 Data-as-Flag 代替了完成通知?本文先沿标准接口追踪 Tensor 如何被降成地址、长度与 WQE,再把它与头文件中的批量直驱实现逐项比较。最后得到的边界是:SIMT 加速的是提交,Data-as-Flag 加速的是接收端就绪判断;二者都没有让 UDMA、SQ/CQ 生命周期或源 buffer 完成语义消失。
导言
原生 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 说明数据和通知如何配合。