模型训练建模不是先问“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 训练与量化优化。

之前学习 Data-as-Flag 时，我们讨论过把 flag 塞进数据块：每个 512 B 块中，480 B 是有效数据，32 B 用来证明“这一块已经到达”。现在希望减少这部分控制开销，改成“前面 relaxed order 发送，最后一个 strong order”。

这个改动的核心，是把“每块都带证明”改成“用队列末尾的有序操作，为前面一批传输提供完成证明”。 但必须解释清楚：最后一个是什么、保证覆盖哪条队列、接收方如何得知完成，以及何时可以复用 buffer。本文沿实际代码逐层回答。

如果目前只知道“URMA 是组 WQE、敲 doorbell”，下一步需要补上三个问题：请求可以发给谁、资源由谁准备、什么时候才算完成。 RM 主要回答第一个问题；SHMEM 的 Ascend 950 UDMA 示例把后两个问题串成了可阅读、可编译的 Ascend C 程序。本文从定义走到两卡示例，并给出原生 URMA 显式选择 RM 的办法。

all-to-all 要让每个参与者给其他参与者发送数据，为什么还要分 group？分组可以控制同时争用有限资源的请求，让通信更接近硬件能稳定处理的速度；但它是否能“防止阻塞”，取决于分的是什么，以及阻塞发生在哪一层。本文从四个 rank 的调度例子出发，解释限流、错峰、接收许可和拓扑分层，再区分 NCCL group 的并发推进语义。目标是看懂通信实现的设计动机，并知道怎样验证收益；文中的容量与规模例子均为推导，没有集群性能实测。

进程 A 已经在加速卡上生成一块数据，进程 B 能不能直接使用？把指针发过去是否就够了？把 UBMEM 和 CUDA IPC 放在一起看，最有价值的切入点就是这个问题。

本文面向知道进程、指针和设备内存，但尚未写过跨进程设备通信的读者。先用 CUDA IPC 建立“共享句柄 → 本地映射 → 同步访问 → 有序释放”的直觉，再沿 HCOMM 的真实实现解释 UBMEM。它们的交集是建立可访问的内存视图；地址有效、数据就绪和访问成本，仍是三个需要分别回答的问题。

先理解设计解决什么问题，再看分组公式。 从两张卡直接发送开始，观察参与者增多后接收方的竞争，尝试分批、错开目的地与接收方许可，最后回到 MoonEP 的 64P group。交互容量是教学假设，源码映射是固定版本事实；本文不把模拟结果作为性能测量。