导言
GLM-5/5.2 已公开模型权重、技术报告、slime 大模型 RL 框架和部分昇腾训练/推理能力，但这些材料处在不同层次。论文公开、仓库中有同名函数、存在可运行 recipe、能够复现 GLM-5.2、已经打通 NPU 端到端，是五件不同的事。
本文不重复上一篇《GLM Post-Training Beyond SFT》的公式推导，而是把 Reasoning/Agentic/General RL、IcePop、TITO、DIS、DSA Indexer、Cross-Stage OPD、MOPD、SAO 与 CompactionRL 逐项落到公开仓库，回答三个工程问题：slime 里有什么、昇腾 NPU 到了哪一层、智谱/THUDM 还有哪些相关开源仓。
导言
部门要突破 GLM 模型的 NPU 原生训练，真正困难的不是把一个 GRPO loss 搬到 NPU，而是让 Actor 训练、推理 Rollout、Teacher Prefill、Verifier、权重同步和低精度数值形成闭环。
本文以 GLM-5 技术报告为主线，并补充 GLM-5.2 已公开的 SAO、CompactionRL 和十多个专家的并行 OPD。重点解释非 SFT 后训练中的 RL、OPD/MOPD，同时单独澄清 QAT 与量化：GLM-5 明确把 INT4 QAT 放在 SFT 阶段，它对 NPU 后训练很重要，但不是非 SFT RL 的一个阶段。
导言
我的长期职业目标可以收束为一句话：理解软件计算逻辑，把它映射到计算、通信、存储和容量受限的硬件上，通过拆分、掩盖、流水和协同设计提高有效利用率；再把这套理解变成可扩展的性能模型、硬件建议与团队分工。
这不是“会调几个 Kernel”或“熟悉某个训练框架”的目标。我要培养的是从工作负载、系统、软件到硬件的完整判断力：知道数据从哪里来、何时产生、在哪里停留、被谁消费、为什么等待，以及增加哪一种资源才真正缩短端到端关键路径。
导言
“模型优化”“框架优化”“算子优化”和“软硬协同”经常出现在同一段讨论里，却不一定在回答同一个问题。本文建立一张七层诊断地图：先确认被控制的对象、真正变化的物理量和最后采用的验收指标，再判断优化属于哪一层。这个分层不是唯一的行业标准，而是一套避免跨层归因错误的工作方法。
导言
最近我对应该长期研究什么技术产生了迷茫。我不喜欢人员管理：每个人的诉求和心思不同，统一理解、共情和换位思考会持续消耗精力。我更希望别人因为我的技术判断、工程能力和解决方案付费。
但“越底层越关键”“越难越值钱”“卖价越高工资越高”都不是可靠规律。AI 应用背后横跨算法、训练系统、推理服务、框架、操作系统、驱动、芯片、封装和晶圆制造；每一层的交易单位、商业模式、资本强度和劳动议价方式完全不同。本文用截至 2026 年 7 月 29 日可公开核验的价格、收入和工资数据，回答两个问题：钱在技术栈中如何流动，以及我应该站在哪个位置积累长期能力。
导言
科技初创公司的 offer 往往把现金、成长和期权包装成一个总数，但三者面对的是完全不同的风险。本文先澄清国内初创公司融资、退出与失败数据的统计边界，再梳理智谱、MiniMax、月之暗面、阶跃星辰和上海人工智能实验室的融资、模型与上市事件，并以科大讯飞星火 X1、智谱、MiniMax、商汤和第四范式的公开披露区分研发工资与算力单位成本，最后拆解一份 月薪 68,000 元、两年 160 万元期权、模型 Infra 优化、11-10-6 的阶跃星辰 offer。结论不把媒体估值、内部价格或上市计划冒充现金，而是给出可复查的事实、主观情景区间和签约前问题清单。
导言
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 的四个关键机制。