Posts

math: true title: “昇腾超节点CloudMatrix384论文拆解” date: 2025-08-07T10:40:12+08:00 tags: [“AIInfra”, “ascend”] —math: true 6.19发布的CloudMatrix384论文拆解，从宏观到基础概念 核心指标和计算方式 TPOT (Time Per Output Token) 公式： $$TPOT= \frac{Decode总耗时}{生成Token数量}$$ 测量方式： 从第一个输出Token开始计时，到生成结束（含MoE通信/KV读取） 为什么重要： 直接决定用户体验（如Chatbot响应速度），论文要求 <50ms（严格模式<15ms） 深层意义： 反映系统通信+计算综合能力，EP320下TPOT=42ms证明UB网络突破MoE通信墙 计算效率 (Tokens/s per TFLOPS) 公式： $$计算效率=\frac {吞吐量(tokens/s)} {NPU峰值算力(TFLOPS)}$$​ 论文数据： 阶段 值 对比基准 Prefill 4.45 超NVIDIA H100+SGLang(3.8) Decode 1.29 超NVIDIA H800+DeepSeek(0.9) 为什么重要： 揭示硬件利用率，1.0以上表明软硬件协同极致优化 深层意义： Decode阶段1.29 → 昇腾910的Cube引擎利用率达 86%（传统GPU仅60%) 缓存访问延迟 (KV Cache Access Latency) 公式： $$延迟=TMMU_{查询}+TUB_{传输}+TDRAM_{读取}​$$ 论文数据： 场景 延迟 对比传统 本地HBM命中 0.2μs - 远程DRAM访问(UB) 1.5μs >10μs (PCIe+IB) 为什么重要： 长上下文推理中70%时间花在KV缓存访问 深层意义： UB统一内存将远程访问性能提升至近本地水平，支撑百万Token上下文。 专家并行扩展性 (EP Degree) 定义：单个MoE层可分布的专家数量 论文突破：EP320（每个昇腾Die托管1个专家） 支撑公式： $$可扩展性=\frac {UB总带宽}{单个专家通信需求}$$ $$EPmax=\frac {384×392GB/s} {8B/token×10^6token/s}=320$$ 为什么重要： EP>100时传统网络崩溃，EP320证明UB突破通信可扩展性极限 INT8量化收益 公式：$$ 加速比=\frac {FP16吞吐}{INT8吞吐}×精度保持率$$ 论文数据： 吞吐提升：1.8倍 精度损失：<0.5%（16个基准测试） 为什么重要： Decode阶段内存带宽减少50%，解决NPU的“内存墙”问题 QA辅助理解 为什么用TPOT而非QPS？ TPOT剥离Batch Size影响，纯粹衡量单次生成效率 更直观反映SLA（用户感知的延迟） 为什么强调计算效率而非绝对吞吐？ 排除工艺优势（7nm vs 5nm），聚焦架构创新价值 1.29 tokens/s/TFLOPS → 证明UB+LEP设计优于NVLink+GPU 为什么测量远程DRAM访问延迟？ 验证内存池化的实际效果，这是打破“内存墙”的核心 1.5μs延迟 → 实现“全集群如单机”的硬件基础 超节点架构 三级网络平面的物理隔离 硬件隔离原理 ...

math: true title: “[RL4LLM] 异步RL框架: Slime” date: 2025-08-07T17:10:12+08:00 tags: [“framework”, “LLM”, “RL”] series: [“rl4llm”] —math: true https://github.com/THUDM/slime 一个异步实现但是非完全异步的RL框架 总体架构 从源码模块划分，有三大核心模块： training（Megatron）：主训练流程，负责模型参数更新。 rollout（SGLang + router）：负责采样、奖励/验证生成，产生训练数据。 data buffer：桥接训练与采样，管理数据流、缓存与生成方式。 分布式调度：关于资源分配、actor启动、任务调度都由于Ray管理，支持异步训练和采样 插件机制：支持自定义buffer、模型、模型格式转换（mbridge） flowchart LR subgraph Ray[Ray 分布式调度] A1[Actor Group<br>训练 Actor] A2[Rollout Group<br>采样/生成 Actor] A3[Placement Group<br>资源分配] end subgraph Training[Training <Megatron>] T1[模型训练] T2[权重同步] T3[评估/保存] end subgraph Rollout[Rollout <SGLang+Router>] R1[采样/生成] R2[奖励模型] R3[过滤器] end subgraph Buffer[Data Buffer] B1[数据缓存] B2[数据流转] B3[Offload/Onload] end subgraph Plugins[插件机制] P1[Buffer 插件] P2[Model 插件] P3[mbridge 格式转换] end A1-->|训练数据|B1 A2-->|生成数据|B1 B1-->|数据流|A1 B1-->|数据流|A2 A1-->|权重同步|A2 A1-->|评估/保存|T3 A2-->|采样/奖励/过滤|R1 R1-->|奖励|R2 R1-->|过滤|R3 B1-->|插件扩展|P1 A1-->|模型扩展|P2 A1-->|格式转换|P3 A3-->|资源分配|A1 A3-->|资源分配|A2 各模块视角的关系图 slime/rollout 组件图 rollout 负责采样、奖励、过滤，支持多种采样/奖励/过滤策略。 ...

math: true title: “[VeRL] Multi-Turn RL训练源码走读（1）” date: 2025-08-03T15:30:12+08:00 tags: [“framework”,“verl”,“sglang”] series: [“verl”] —math: true 该part主要聚焦相关模块初始化部分 还是以 verl 出发，分析其 end to end mutli-turn RL 训练的全过程。整体上，我希望覆盖所有重要的 class 以及函数，更细粒度的代码不再展开。 为了前后内容的一致性，基于 76f63cffa5 的 commit 进行分析。 虽然本文以分析 verl 的代码为主，写完之后我才意识到，系统设计问题是非常通用的。诸如“log probs 重计算”，“Rollout Engine 显存管理”等等系统设计，是各大 RL 框架都需要考虑的核心问题。 此外因为最近在学习SGLang的实现，本文的推理后端选择的是SGLang展开分析。 —math: true 整个训练的示意图如下，我们会具体展开每个部分。 flowchart LR subgraph W2["Initialize"] WP[Process Data] --> A direction TB D1[Data Prepare] --> A A[TaskRunner] --> B1[RayPPOTrainer] B1 --> Workers subgraph Workers["Workers"] direction TB WA[ActorRolloutWorker] --> WD[FSDP Engine] WB[CriticWorker] --> WD WC[RewardModelWorker] --> WD WD --> WE[SGLang Engine] end Workers --> C1[Hybrid Engine] end subgraph W3["Train Loop"] direction TB E[DataLoader] --> RolloutBox subgraph RolloutBox["Rollout"] F1[Prepare Data] --> F2[SGLang Async Rollout] F2 --> F3[Multi-turn Chat Process] end RolloutBox --> ExpBox subgraph ExpBox["Make Experience"] G1[Recompute Log Probs] --> G2[Compute Reward] G2 --> G3[Compute Advantage] end ExpBox --> UpdateBox subgraph UpdateBox["Train The Model"] H1[Load FSDP Model Weight] --> H2[Compute Gradient] H2 --> H3[Weights Update] H3 --> H4[Sync Weights] end UpdateBox --> E end W2 --> W3 数据预处理 以 GSM8K 为例，预处理脚本是 examples/data_preprocess/gsm8k_multiturn_w_tool.py。整个脚本只做了经典的 huggingface datasets mapping，核心逻辑如下： ...

math: true title: “[AIInfra] FlashAttention 深度解析：从数学原理到工程实现” date: 2025-09-15T11:30:12+08:00 tags: [“flashattention”] series: [“aiinfra”] —math: true 本文从数学原理出发，深入分析FlashAttention的核心思想、算法设计和各版本演进，通过详实的数学推导、直观的流程图表和具体的数值示例，帮助读者真正掌握这一革命性的Attention优化技术。 —math: true 1. 问题的本质：传统Attention的根本瓶颈 1.1 传统Attention机制的计算模式 传统的Self-Attention机制遵循如下计算流程： $$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$让我们用具体数值来理解这个过程的复杂性： 示例场景：考虑一个典型的语言模型场景 序列长度：$n = 2048$（如GPT-2的上下文长度） 特征维度：$d_k = 64$（每个attention head的维度） 输入张量形状：$Q, K, V \in \mathbb{R}^{2048 \times 64}$ 第一步：计算注意力得分矩阵 $$S = \frac{QK^T}{\sqrt{d_k}} \in \mathbb{R}^{2048 \times 2048}$$这一步产生了一个 $2048 \times 2048 = 4,194,304$ 个元素的矩阵，以FP16精度存储需要约8MB内存。 第二步：Softmax归一化 $$P = \text{softmax}(S) \in \mathbb{R}^{2048 \times 2048}$$Softmax计算需要： 计算每行的最大值：$m_i = \max_j S_{i,j}$ 计算指数和：$l_i = \sum_j e^{S_{i,j} - m_i}$ 归一化：$P_{i,j} = \frac{e^{S_{i,j} - m_i}}{l_i}$ 这又需要存储另一个 $2048 \times 2048$ 的矩阵。 ...

math: true title: “Docker Fundamentals: Namespace” date: 2021-04-01T11:22:18+08:00 hero: /images/posts/k8s-docker.jpg menu: sidebar: name: Docker Fundamentals (Namespace) identifier: docker-namespace parent: cloud-computing weight: 10 draft: false —math: true 容器技术出现已经很久，只不过Docker容器平台的出现它变火了。Docker是第一个让容器能在不同机器之间移植的系统，它简化了打包应用的流程，也简化了打包应用的库和各种依赖。思考下整个OS的file system能直接被打包成一个简单的可移植的包，一开始的时候概念上还是很有趣的。 有时候我认为自己的阅读比较碎片化(short-term memory越来越少)，所以我想把之前学习容器知识的一些基础技术再整理出来，也算是给自己学习的反馈。这个基础系列从Linux Namespace开始，后续会陆续介绍比如cgroup、aufs、devicemapper等技术。 参考 Namespace in operation Linux namespace man page Introduction to linux namespace 什么是Namespace 简单来说，linux namespace是Linux提供的一种内核级别环境隔离的方法。在早期的Unix中，提供了一种叫做chroot的系统调用：通过修改root目录把用户关到一个特定的目录下面。这种就是简单的隔离方式，也就是chroot内部的file system无法访问外部的内容。Linux Namespace在此基础之上，提供了对UTS、IPC、mount、network、PID、User等隔离机制。 这里可以简单举例，比如Linux的超级父进程的PID为1，如果我们可以把用户的进程空间关到某个进程分支之下，并且像chroot那样能够让下面的进程看到那个超级父进程的PID为1，而不同PID Namespace中的进程无法看到彼此，这样就能达到进程隔离。 Linux Namespace有以下的种类，供给后续参考（刚看有个印象就行）： 分类 系统调用参数 相关内核版本 Mount namespaces CLONE_NEWNS Linux 2.4.19 UTS namespaces CLONE_NEWUTS Linux 2.6.19 IPC namespaces CLONE_NEWIPC Linux 2.6.19 PID namespaces CLONE_NEWPID Linux 2.6.24 Network namespaces CLONE_NEWNET 始于Linux 2.6.24 完成于 Linux 2.6.29 User namespaces CLONE_NEWUSER 始于 Linux 2.6.23 完成于 Linux 3.8) 其主要涉及到三个系统调用： ...