模型训练建模不是先问“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 文章只是最终发布层。这样每次写作都会沉淀可复用记忆，而不是从聊天记录里重新发明一次。

谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 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 请求的生命周期，把这些名词放回它们各自的位置。