跳转至

笔记

AI 辅助写作与幻觉风险

本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写,包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本,但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。

因此,除非特别标注,我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策,请务必自行查证原始资料,并结合上下文判断其可靠性。

劝退指南:不是博客,而是笔记,甚至是草稿

写笔记是为了让自己看懂,写博客是为了让别人看懂,不一样的,认真做好后者对自己各方面能力的提升会非常大(比如表达能力),其实很多时候记笔记就是写几段自己能看懂的表达,很随性,但写博客更像是写一篇论文,需要自己先彻底搞明白一个东西后才能输出1

我一直努力将内容写成博客。但是后来发现,根本没有时间和心思,来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听,让我还能快速看懂。能达到这点,这些内容的意义对于我就已经足够。

现在拥抱 AI 之后,我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛,但它并不会自动替代人的理解:一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立,仍然需要自己反复判断、实践和修正。

所以,我仍然会继续更新这些文档。它们不是面向所有读者的完整教程,而是我在某个阶段借助 AI、资料阅读和个人实践,对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容,这也是笔记存在的意义。

从读者的角度,我并不会推荐任何人阅读这个网站的内容:因为你会遇到以下令人烦躁的场景

  1. 完整性差:某些笔记写着写着就没有了,内容是残缺的。甚至只有一个标题。(这是因为我没有时间填充内容,或者我的研究和注意力转变方向了,弃坑了弃坑了~)
  2. 可读性一般:很少有起承转合的解释语句,笔记的内容逻辑几乎全部靠多级标题维持.
  3. 笔记间关联性低:从读者的角度是看不到本人是如何使用多级文件夹,来组织划分笔记间的内容逻辑。如果你在搜索栏找不到你想要的关键词,那大概率我没接触到这方面的内容。
知识是自然聚类和融合的,但需要两级的文档来过滤内容和撰写正文。小而全、无懈可击的内容应该是所追求的

导致这种情况,其实和我对知识产出过程的理解有关,我认为过程是 知识是自然聚类和融合的

  1. 接触到领域对象(新建文件夹)
  2. 阅读各种文献网站(零散的知识进行简单的聚类)
  3. 上手实践和研究(踩了许多坑,有或多或少的感悟)。

而且三者的占比是前面远大于后面,这样看来我这网站大部分的内容岂不是都是笔记的草稿

我以这样的方式撰写我的正式的毕业论文时,发现这样的处理有利有弊:

  1. 优势:
    1. 速度?:能快速的罗列出内容,填充了大量垃圾内容
    2. 完备性:保留所有必要的相关信息,
  2. 劣势:
    1. 对工作进度的误判:罗列的大量页数迷惑了自己,以为进度很快。其实仔细思路内容的有效性、逻辑关联性。核心观点的提炼。遣词造句都极其耗费时间。
      1. 最重要是导致只看页数的领导对你工作速度的误判导致的嫌弃:一周前就看见里论文写了60页了,怎么两周了还没写完。或者你都60页了快结束了,来帮帮我弄这个~阿米诺斯~
    2. 需要返工:重新整理罗列的垃圾内容,至少需要三倍以上的时间才能整理好。

总结:知识是自然聚类和融合的思想是没错的,但是在实际生产应用时需要两级的信息筛选过滤体系:区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用,正文精心撰写每一句话保证不需要大量返工。

Building Large-Scale AI Systems on Ascend: Training, Inference, and Multimodal Optimization

导言

谭邵杰,中国科学技术大学本硕毕业,现任华为昇腾训练开发工程师,专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。

AI 训练推理框架与异构加速优化工程师,长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。

AI Documentation Workflow

导言

这篇文章记录我当前的 Work with AI 文档工作流:不是把一段 prompt 扔给模型、得到一篇孤立文章,而是把调研、来源管理、论文图表、正文插图、图片上传、Hugo 写作规范、可复用 skill 和 git 发布串成一个可验证的流水线。

这条流水线的关键变化来自 Karpathy 的 LLM Wiki 思路:把知识库视作一个由 LLM 维护的 Markdown 代码库。原始资料进入 raw 层,结构化理解进入 wiki 层,Hugo 文章只是最终发布层。这样每次写作都会沉淀可复用记忆,而不是从聊天记录里重新发明一次。

VeRL Async Policy

导言

VeRL async 的核心问题不是“开异步就一定更快”,而是把 rollout 长尾、训练更新、参数同步和旧样本容忍度放到同一个队列系统里调参。这篇笔记梳理 VeRL 老版 one_step_off_policy / fully_async_policy 与新版 trainer v1 的关系,解释 staleness 的真实语义,并给出 64P、128P NPU 场景下选择训推资源比例的第一轮计算方法。

NPU Training Operators - GDN

导言

这篇笔记记录一次很窄的接入设计:在 verl release/v0.8.0 的 Qwen3.5 GRPO + FSDP 路径里,NPU 已经有 RMSNorm、RoPE、MoE GMM 等 patch,但 Gated Delta Net / GDN 仍然落在原始 eager 路径。目标不是改 GRPO 算法,而是给模型 forward 里的 chunk_gated_delta_rule 加一个可配置的 Triton 优先路径。

参考对象是 MindSpeed-MM 提交 5aaf0791d00abcbf5dd16af10091f4391030ad00:它把 Qwen3.5 的 GDN 计算模式显式化为 gdn_compute_mode,并区分 tritonascendceager。本文给出的 verl 方案先接入 Triton,保留 eager 回退;AscendC 自定义算子作为后续扩展。

NPU Training Operators - RoPE MRoPE

导言

MindSpeed core_r0.16.0--use-fused-rotary-pos-emb 是普通 RoPE 路径:freqs -> cos/sin -> npu_rotary_position_embedding(x, cos, sin, mode)torch_npu 另有 npu_rotary_mulnpu_interleave_ropenpu_mrope,其中 npu_mrope 可以覆盖推理侧多模态 MRoPE;这和 Megatron Bridge 的 config.apply_rope_fusion 不是同一个开关。

客户报错 Qwen3VLMultimodalRotaryEmbedding has no attribute get_rotary_seq_len 的直接含义是:Qwen3-VL 的 MRoPE 对象被送进了 Megatron Core 的普通 rope 分支。先修正分支:position_embedding_type="mrope"apply_rope_fusion=False。如果要用 NPU MRoPE fused,应在 q/k rotary apply 处显式接 torch_npu.npu_mrope,不是打开普通 apply_rope_fusion

NPU Training Operators - GMM

导言

GMM 在 Qwen3.5 MoE 里的接入点是 routed experts 的两次矩阵乘hidden -> gate/upintermediate -> hiddenshared_expert 仍是普通 Qwen3_5MoeMLP,attention 不动,Dense 版 Qwen3.5 的普通 MLP 也不是替换对象。

PR #2664 的公开 diff 主要是给 mindspeed_mm.fsdp.ops.moe_ops.gemm.grouped_matmul 增加 fused/eager 一致性 UT,并放宽 unpermute UT 容差;它可以作为 GMM wrapper 接口被测试覆盖的证据,不能写成完整功能接入 PR。12

NPU Training Operators - MC2

导言

MC2 的核心不是异步通信,而是 fused operator 内部的计算/通信切分与流水。MindSpeed-LLM 文档里的典型场景是 TP/SP 下的 matmul + all_reduce/all_gather/reduce_scatter;MindSpeed-MM PR #2480 接入的是 MoE expert parallel 下的 AllToAllv + GroupedMatmulGroupedMatmul + AllToAllv

本文只记录可迁移信息:PR 改了哪些文件、ep_mc2_forward 怎么跑、迁移前检查什么、怎么验证、哪些结论不能从公开资料直接外推。

VeRL TransferQueue

导言

TransferQueue 不是普通 FIFO queue,也不只是 rollout 侧的 token queue。它更像 RL 后训练的数据系统:controller 仍然负责编排训练流程,但大 tensor 的读写、字段就绪状态、样本消费记录和跨 worker 数据传输被拆到独立 data plane 中。

VeRL Router Replay

导言

Router Replay 的核心不是让 MoE 路由更快,而是把 rollout、old logprob 重算和 new logprob 更新三段路径的专家选择对齐。MoE 的 top-k routing 是离散分叉,微小数值差异会导致 expert 集合突变;一旦 old/new logprob 的差异混入“路由换了”而不是“策略变了”,PPO / GRPO 的 ratio、clip 和 KL 都会失真。

VeRL Speculative Decoding

导言

RL rollout 中的 speculative decoding 不是普通推理加速的简单移植。普通 serving 只关心 latency、throughput 和用户体验;RL rollout 还必须保证 response、old logprob、reward、advantage 和 policy loss 都对应同一个 verifier policy。

换句话说,draft model 可以帮助系统更快地产生候选 token,但训练语义必须仍然属于 target / verifier policy。