CctoctoFX

[RL4LLM] 异步RL框架: Slime

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 负责采样、奖励、过滤，支持多种采样/奖励/过滤策略。 ...

[RL4LLM] 异步RL框架: Areal

https://github.com/inclusionAI/AReaL 纯异步RL方案异步PPO训练调用流程 graph TD A[用户执行: examples/run_async_ppo.sh] --> B[training/main_async_ppo.py] B --> C[AsyncPPOMATHConfig配置解析] C --> D[training/utils.py: run_experiment] D --> E[Ray初始化] E --> F[exp_cfg.initial_setup] F --> G[AsyncRLExperimentConfig.initial_setup] G --> H[创建ExperimentConfig] H --> I[启动Workers] I --> J[MasterWorker] I --> K[ModelWorker] I --> L[GenerationServer] I --> M[GserverManager] I --> N[RolloutWorker] %% MasterWorker训练流程 J --> J1[MasterWorker._poll_async] J1 --> J2[FunctionExecutor.execute_step] J2 --> J3[执行数据流图遍历] J3 --> J4[发送训练请求到ModelWorker] %% ModelWorker处理流程 K --> K1[ModelWorker._poll] K1 --> K2[接收MasterWorker请求] K2 --> K3[处理训练/推理请求] K3 --> K4[执行模型前向/反向传播] %% Rollout流程 N --> N1[RolloutWorker._poll_async] N1 --> N2[load_next_data] N2 --> N3[allocate_new_rollout] N3 --> N4[agent.collect_trajectory] N4 --> N5[env.step计算奖励] N5 --> N6[推送数据到训练端] %% 生成服务器流程 L --> L1[GenerationServer._poll] L1 --> L2[启动SGLang子进程] L2 --> L3[处理生成请求] %% 生成服务器管理器 M --> M1[GserverManager._poll] M1 --> M2[HTTP服务线程] M2 --> M3[请求调度和权重更新] %% 数据流 N6 --> O[stream_dataset.py] O --> J4 %% 异步通信 J4 -.->|异步请求| K2 N3 -.->|HTTP请求| M2 M2 -.->|调度请求| L3 %% 权重更新 K4 --> P[参数更新] P --> Q[权重同步] Q --> M3 M3 --> R[更新生成服务器权重] style A fill:#e1f5fe style J fill:#f3e5f5 style K fill:#e8f5e8 style L fill:#fff3e0 style M fill:#fce4ec style N fill:#f1f8e9 用户入口到配置解析 examples/run_async_ppo.sh → training/main_async_ppo.py ...

昇腾超节点CloudMatrix384论文拆解

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延迟 → 实现“全集群如单机”的硬件基础超节点架构三级网络平面的物理隔离硬件隔离原理 ...

[VeRL] Multi-Turn RL训练源码走读（2）

在 Part 1 中，我们介绍了 verl 的初始化过程，我们进一步介绍 verl 的训练过程，包括rollout部分、make experience部分以及training部分。在 GRPO 中，单个 step 包含四个阶段：load data -> rollout -> make experience -> update model。区别于前一节的详述，本节会使用伪代码结合源码的方式进行阐述。 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 数据加载与预处理 verl 通过 DataProto 和 RLHFDataset 来实现数据处理。具体来说，在 main_ppo.py 中，我们观察这个函数： ...

[VeRL] Multi-Turn RL训练源码走读（1）

该part主要聚焦相关模块初始化部分还是以 verl 出发，分析其 end to end mutli-turn RL 训练的全过程。整体上，我希望覆盖所有重要的 class 以及函数，更细粒度的代码不再展开。为了前后内容的一致性，基于 76f63cffa5 的 commit 进行分析。虽然本文以分析 verl 的代码为主，写完之后我才意识到，系统设计问题是非常通用的。诸如“log probs 重计算”，“Rollout Engine 显存管理”等等系统设计，是各大 RL 框架都需要考虑的核心问题。此外因为最近在学习SGLang的实现，本文的推理后端选择的是SGLang展开分析。整个训练的示意图如下，我们会具体展开每个部分。 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，核心逻辑如下： ...