AI Infra on CctoctoFX

Ascend Profiling Analysis Skill 设计深度解析

Thu, 28 May 2026 00:00:00 +0000

Ascend Profiling Analysis Skill 设计深度解析

本文深度解析一个用于分析 Ascend NPU torch profiler 产出的 skill，涵盖其设计哲学、Pipeline 架构、昇腾核心知识体系和先验知识体系。

一、背景与动机

为什么需要 profiling 分析？

在昇腾 NPU 上运行 LLM 推理时，的性能调优需要回答几个关键问题：

Step 时间去哪了？ attention/FFN/MoE 各占多少？
瓶颈在哪？ Cube 计算还是 Vector 内存搬运？
EP/TP 负载均衡吗？ 有没有 rank 掉队？
通信是否拖后腿？ HCCL collective 是否慢于预期？

传统的分析手段面临几个问题：

工具	问题
CANN Studio Timeline	只能看时序，无法聚合统计
`trace_view.json`	数据稀疏，难以关联到 kernel 语义
`kernel_details.csv`	数据量级 GB，需要专门解析逻辑

设计目标

这个 skill 的核心目标：从原始 profiling 数据出发，产出带证据链的可追溯报告。

每一条诊断结论都必须能追溯到原始 CSV 的行号
支持跨 rank 对齐和异常检测
输出 Markdown / Excel / HTML 三种格式

二、设计哲学：证据链优先

核心理念

每个 claim 必须能追溯到原始 row。

[Deterministic RL] 确定性问题的来源 & Reproducible RL

Thu, 20 Nov 2025 11:30:12 +0800

理解LLM推理中deterministic问题来源

Wiki上对deterministic算法的定义是:

“a deterministic algorithm is an algorithm that, given a particular input, will always produce the same output.”

而我们在文中要讨论的，即对于LLM这个context下的deterministic问题，我会先从inference角度（即重复给定一个确定的input，模型的推理为什么无法给定确定的输出）进行问题的理解，再进一步讨论RL工程中的training & inference之间差异，可能会导致RL训练的崩溃问题，并继续讨论业界现在已有的解决方案、与还在working-in-progress的工作。

浮点数的非结合性

thinking machines lab针对batch invariant讨论的文章，详细地解释了在LLM推理中不确定性的来原，即因为精度有限，GPU浮点数运算中的结合性通常不成立：

$$(a+b)+c \neq a+(b+c) $$

这篇arxiv文章，则更深入得说明了这个问题：

Floating-point arithmetic in GPUs exhibits non-associativity, meaning (a+b)+c≠a+(b+c) due to finite precision and rounding errors. This property directly impacts the computation of attention scores and logits in the transformer architecture, where parallel operations across multiple threads can yield different results based on execution order.

[vLLM-Ascend] MC2技术深度解析：从MoE架构到通信融合优化

Sat, 20 Sep 2025 11:30:12 +0800

源码分析依赖vllm-ascend在2025/9/20号的main分支，阅读请注意时效性。
阅读建议:

了解MoE基本架构和关键推导

初步了解集合通信各原语的含义

对通算掩盖这类性能优化有基础的了解

概述

MC2（Merged Compute and Communication）是vLLM Ascend项目中针对昇腾NPU优化的核心技术，专门解决MoE（Mixture of Experts）模型在专家并行推理中的通信瓶颈问题。本文档从MoE架构基础出发，深入分析MC2的设计原理、技术实现和性能优化。

1. MoE架构基础与挑战

1.1 MoE模型基本原理

1.1.1 什么是MoE？

**MoE(Mixture of Experts)**是一种神经网络架构，通过将模型参数分散到多个"专家"网络中，根据输入动态选择部分专家进行计算。这种架构在保持高模型容量的同时，降低了计算复杂度。

1.1.2 MoE的数学表达

给定输入 $\mathbf{x} \in \mathbb{R}^{d}$，MoE层的输出可以表示为：

$$ \mathbf{y} = \text{MoE}(\mathbf{x}) = \sum_{i=1}^{N} g_i(\mathbf{x}) \cdot E_i(\mathbf{x}) $$

其中：

$N$ 是专家总数
$E_i(\cdot)$ 是第 $i$ 个专家网络
$g_i(\mathbf{x})$ 是门控网络对专家 $i$ 的权重

1.1.3 稀疏激活机制

为了提高效率，MoE通常采用稀疏激活机制，只选择 Top-K 个专家：

$$ \mathbf{y} = \sum_{i \in \text{Top-K}(\mathbf{x})} \frac{g_i(\mathbf{x})}{\sum_{j \in \text{Top-K}(\mathbf{x})} g_j(\mathbf{x})} \cdot E_i(\mathbf{x}) $$

详见附录A.1 MoE输出公式推导

其中 $\text{Top-K}(\mathbf{x})$ 表示根据门控权重选择的 Top-K 个专家索引。

[VeRL,SGLang] RL训推显存管理优化

Wed, 17 Sep 2025 11:30:12 +0800

SGLang团队的博客：https://hebiao064.github.io/rl-memory-management

Overview

上述是简化的在线RL训练流程，隐去了reference和critic model，并且用基础的reward function而非reward model来说明流程。实际上就是policy model存在的training engine和rollout engine上需要进行优化。

从简化的PPO流程开始：

for prompts, pretrain_batch in dataloader:
    # Stage 1: Rollout generation (inference)
    batch = actor.generate_sequences(prompts)
    # Stage 2: Prepare experience
    batch = reference.compute_log_prob(batch)
    batch = reward.compute_reward(batch)  # Reward function or model
    batch = compute_advantages(batch, algo_type)
    # Stage 3: Actor training
    actor_metrics = actor.update_actor(batch)

每一个iter相当于是actor model进行一次rollout再进行training，而veRL因为rollout和training共部署，所以两边可能不用version的actor model是在相同的GPU组上的，这导致了虽然资源共享但是显存管理会变得更复杂。

显存问题

训练阶段显存

FSDP（fully sharded + full activation checkpointing）下，每个GPU占据显存：

每个GPU的峰值显存：~48GB

推理阶段显存

During inference, the full model is typically loaded (not sharded):

[AIInfra] FlashAttention 深度解析：从数学原理到工程实现

Mon, 15 Sep 2025 11:30:12 +0800

本文从数学原理出发，深入分析FlashAttention的核心思想、算法设计和各版本演进，通过详实的数学推导、直观的流程图表和具体的数值示例，帮助读者真正掌握这一革命性的Attention优化技术。

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$ 的矩阵。

[VeRL] DataProto介绍

Mon, 25 Aug 2025 11:30:12 +0800

Verl DataProto 实现原理与数据流动分析

1. 概述

Verl 是一个基于 HybridFlow 论文的开源强化学习训练框架，专门为大语言模型的后训练优化而设计。其核心创新在于将控制流和计算流分离，通过 DataProto 协议实现高效的数据交换。

2. DataProto 核心架构

2.1 数据结构设计

DataProto 是 verl 框架中用于数据交换的核心协议，所有在 Worker 之间流转的数据，都被统一封装在一个名为 DataProto 的数据结构中。它不仅仅是一个字典，更承载着 RLHF 流程中所有的信息演变, 基于 PyTorch 的 TensorDict 构建：

@dataclass
class DataProto:
    batch: TensorDict = None              # 张量数据容器
    non_tensor_batch: dict = field(default_factory=dict)  # 非张量数据
    meta_info: dict = field(default_factory=dict)         # 元信息

核心特性：

统一接口: 提供标准化的数据容器，支持张量和非张量数据
设备管理: 自动处理 GPU/CPU 设备间的数据移动
内存优化: 支持分块处理和内存复用
序列化: 支持高效的序列化和反序列化

2.2 数据一致性检查

def check_consistency(self):
    """检查 DataProto 的一致性"""
    if self.batch is not None:
        assert len(self.batch.batch_size) == 1, "只支持 num_batch_dims=1"
    
    if self.non_tensor_batch is not None:
        for key, val in self.non_tensor_batch.items():
            assert isinstance(val, np.ndarray)
            
    # 检查批次大小一致性
    if self.batch is not None and self.non_tensor_batch is not None:
        batch_size = self.batch.batch_size[0]
        for key, val in self.non_tensor_batch.items():
            assert val.shape[0] == batch_size

3. HybridFlow 设计理念

3.1 设计动机

传统 RL 系统面临的问题：

[VeRL] AgentLoop源码走读

Thu, 14 Aug 2025 11:30:12 +0800

最近 RL sys 圈子的吴锡斌老师在 verl 上设计了将 rollout 与 tool 调用解耦的 AgentLoop，实现了自由灵活的 mutli-turn RL。在每个 AgentLoop 内部，rollout engine 只对外提供一个 token-in-token-out 的接口，而 tool 调用则通过 ToolAgentLoop 来实现。我个人比较喜欢这样解耦的设计，同时，AgentLoop 的代码结构也比较清晰。我个人学习了一次整个代码后，觉着 AgentLoop 的设计甚是不错，但是 ActorRolloutRefWorker 的历史包袱还是很重。

本文简单分析了 agent loop 的源码，并给出了一些自己的看法。

如果我们把整个 ActorRolloutRefWorker 当做一个 sgl.Engine 的话，AgentLoop 里面包装的两层 AsyncSGLangServer 和 AsyncLLMServerManager。AsyncSGLangServer 相当于在 sgl.Engine 上包装了 fastapi 成了 server，而 AsyncLLMServerManager 是在 server 上包了一层 router 做 load balance，相当于 sglang 的 router。这两层设计都是合理的，主要麻烦的是 ActorRolloutRefWorker，层层调用，最后一共经过 7 个 class 才调到 sgl.Engine，最近 verl 团队也在致力于对这块 worker class 的重构，敬请期待。最后，AgentLoopManager，AgentLoopWorker 和 AgentLoop 这三层，我觉得 AgentLoopWorker 可能未必有必要，其他两层挺合理的。

[VeRL] 参数速览

Thu, 14 Aug 2025 10:20:12 +0800

VeRL框架的参数众多，基于当前（2025.8.5）主线分支整理，附带了相关的理解，一些描述不一定完全正确，供学习参考。

Batch Size

参数名称	详细解释
`data.train_batch_size`	作用：定义了单次训练发送给 Rollout Engine 的样本数量，也即这是在每个 PPO 迭代开始时，从训练数据集中采样的提示（Prompt）数量。详细解释：这个值是 RL 训练中的基本样本数量。例如，设置为 1024 意味着在一次迭代中会： 1. 从数据集中随机抽取 1024 个 prompt。 2. 将这 1024 个 prompt 发送给当前的 Rollout Engine 中，从而得到 1024 组完整的 trajectories（prompt, response）。 3. 接下来，这 1024 个 trajectories 进行经验计算（make experience），后续用于 Actor 和 Critic 模型的更新。影响与权衡：影响总共训练的样本量。
`data.val_batch_size` （Deprecated)	作用：在 Validation 阶段使用的批次大小。详细解释：这与 `train_batch_size` 类似，但仅用于评估模型性能，不参与训练。如果设置为 `null`，会使用验证集的大小作为默认值。Note: 已经deprecated，推荐设置为 null。此时，整个 validation dataset 一次性发给 SGLang engines，自行进行内存管理。
`actor_rollout_ref.actor.ppo_mini_batch_size` `critic.ppo_mini_batch_size`	作用：定义了 PPO 训练更新中的 mini-batch 大小。详细解释：`data.train_batch_size` 收集到的全部经验数据将被分割成多个 mini-batch，每块的大小就是 `ppo_mini_batch_size`。模型每处理完一个 mini-batch，才会进行一次参数更新。例如，如果 `train_batch_size = 1024`，`ppo_mini_batch_size = 256`，那么在一个 PPO Epoch 中，模型会进行 `1024 / 256 = 4` 次参数更新。影响与权衡：增大 mini-batch，单次更新的梯度更稳定，但更新频率更低，更新次数减少。
`actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu` `critic.ppo_micro_batch_size_per_gpu`	作用：定义了在单个 GPU 上进行一次 forward/backward 的数据大小。详细解释：这是实现梯度累积的核心参数。mini-batch 会被再次切分为若干个 micro-batch。例如，在单卡上，`ppo_mini_batch_size = 256`，`ppo_micro_batch_size_per_gpu = 32`，那么梯度累积的步数就是 `256 / 32 = 8`。这意味着模型会运行 8 次 forward 得到 loss，然后 backward 的到 gradient。每次处理 32 个样本，直到累积完整个 mini-batch 计算出的梯度。此时，使用累积的总梯度，对模型参数进行一次更新（`optimizer.step()`）。这个值必须根据显存大小来严格调整，是防止 OOM 的关键。影响与权衡：增大此值，减少了梯度累积的次数，可以提高训练的吞吐量，增大显存消耗。
`actor_rollout_ref.actor.ppo_micro_batch_size` `critic.ppo_micro_batch_size`（Deprecated)	作用：已弃用，被 `per_gpu` 版本取代，因为它能更好地适应分布式训练环境。

Dynamic Batch Size

当样本长度差异很大时，按样本数量划分批次可能导致不同批次的计算量极不均衡，而基于 token 总数来控制 batch size 是一种平衡每个 batch 训练时间的方案。

[SGLang] 后端代码速览

Wed, 13 Aug 2025 10:30:12 +0800

本文档为开发者提供 SGLang 后端代码的代码梳理，按照一个请求从输入到最后输出的顺序进行讲解。下图简要介绍了这一流程：

具体而言，请求的处理过程如下：

用户启动 Server ，初始化 FastAPI App、TokenizerManager、DetokenizerManager 和 Scheduler，每个组件运行各自的无限事件循环（infinite event loop）。
用户向 FastAPI Server 发送 /v1/chat/completions 请求，Server 通过 v1_chat_completions endpoint 将请求转发到 TokenizerManager。
v1_chat_completions 函数将请求转换为 ChatCompletionRequest，再转换为 GenerateReqInput，并调用 TokenizerManager 的 generate_request 方法。
TokenizerManager 对请求进行 tokenization，并以 Python 对象（pyobj）形式将其转发给 Scheduler，同时调用 TokenizerManager 的 _wait_one_response 方法。
Scheduler 在事件循环 event_loop_normal 中处理请求：
- Scheduler 通过 recv_requests 接收请求，调用 process_input_requests 处理输入，通过 handle_generate_request 管理生成请求的逻辑，并将其加入 waiting_queue。
- 从 waiting_queue 中，Scheduler 使用 get_next_batch_to_run 为即将处理的请求创建 ScheduleBatch。
- Scheduler 执行 run_batch 函数，将 ScheduleBatch 转换为 ModelWorkerBatch。
- Scheduler 调用 TpModelWorker 的 forward_batch_generation，等待 logits_output 和 next_token_ids。
- TpModelWorker 初始化 ForwardBatch，将其转发至 ModelRunner，并等待 logits_output。
- ModelRunner 处理 ForwardBatch，调用 forward_extend 执行模型的前向计算（forward pass）。
- 模型通过 AttentionBackend 加速生成 logits，返回给 ModelRunner，进而返回给 TpModelWorker。
- TpModelWorker 从 ModelRunner 接收 logits_output，调用 ModelRunner 的 sample 方法生成 next_token_ids，并将其发送回 Scheduler。
- Scheduler 通过 process_batch_result 处理批次结果，使用 tree_cache.cache_finished_req(req) 缓存请求，并通过 check_finished 验证完成状态。对于未完成的请求，Scheduler 继续其事件循环，直到这个请求满足结束条件；对于已完成的请求，则转发到 Scheduler 的 stream_output。
- 在 stream_output 函数中，Scheduler 处理输出，将其包装成 BatchTokenIDOut，并发送给 DetokenizerManager。
DetokenizerManager 在其事件循环中接收 BatchTokenIDOut，处理后生成 BatchStrOut 并返回给 TokenizerManager。

[RL4LLM] 异步RL框架: Slime

Thu, 07 Aug 2025 17:10:12 +0800

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

Thu, 07 Aug 2025 14:40:12 +0800

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论文拆解

Thu, 07 Aug 2025 10:40:12 +0800

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）

Sun, 03 Aug 2025 17:30:12 +0800

在 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）

Sun, 03 Aug 2025 15:30:12 +0800

该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，核心逻辑如下：

AI Infra：颠覆性创新，还是经典工程范式的华丽转身？

Fri, 01 Aug 2025 10:05:12 +0800

近期看到一些关于传统基础设施（Traditional Infrastructure）与人工智能基础设施（AI Infrastructure，尤其大模型领域）差异的评论。其核心观点直指两者间的巨大鸿沟：许多精于网络、计算、存储等传统领域的工程师，在面对GPU集群、KV Cache管理、3D并行等全新概念时，常感过往经验难以直接套用，甚至产生踏入一个全然不同技术体系的“割裂感”。

这些看法颇具代表性，精准捕捉了工程师初探AI Infra时的普遍印象：陌生、高门槛、范式迥异。本文旨在分享我对此的一些初步思考：AI Infra究竟是颠覆传统的全新体系，抑或是既有Infra经验在智能时代的一次深度演化？

（免责声明：本文纯属个人观点，旨在抛砖引玉，欢迎指正谬误！）

我的核心论点：AI Infra并非平地起高楼，它实质上是传统Infra工程智慧在新场景下的重构与系统性延展。

表象差异：新术语与新挑战带来的“视觉冲击”

乍看之下，AI Infra与传统Infra确实分野明显：

核心任务不同： 传统Infra聚焦于处理海量Web请求（毫秒级、无状态）、保障数据持久化存储、实现分布式服务协调。而AI Infra（尤以大模型为甚）则围绕GPU驱动的模型训练/推理、KV Cache的高效管理、百亿/千亿级参数的分布式执行框架展开。
请求形态迥异： Web请求追求瞬时响应（毫秒级）、天然无状态。大模型（LLM）推理则常承载持续的会话交互（秒级乃至更长，随上下文窗口扩展而递增），需动态维护细粒度的Token级状态（KV Cache）。
技术栈迭代： 熟悉的Kubernetes + Docker堆栈旁，涌现出GPU硬件抽象、vLLM、DeepSpeed、FlashAttention、Triton、NCCL等专为AI设计、名号“高深”的组件。

由此观之，认为传统经验难以直接迁移，确有其表象依据。但这仅仅是“水面之上的冰山”，远非其底层基石。

本质共性：工程核心挑战的永恒回归

拨开“AI专属”的面纱，工程实践的核心命题依然如故：系统设计与资源调度的精妙艺术。 我们面临的，仍是那些传统Infra领域中反复锤炼的同类问题，只是约束条件和优化目标发生了变化：

资源调度： 核心资源从CPU/内存/磁盘IO，转向了更稀缺、更昂贵的GPU显存与算力。
负载处理： 承载对象从HTTP资源请求，变为密集的Prompt请求与大规模训练任务。
核心目标： 高效、稳定、低成本地协调跨节点资源的核心诉求丝毫未变。

概念的映射：经典范式的AI实践

这种延续性，清晰地体现在关键概念的对应关系上：

传统 Infra 概念	AI Infra 对应实践	核心思想应用
数据分片 (Data Sharding)	数据并行 (Data Parallelism)	数据集拆分，多副本并行处理
负载均衡 (Load Balancer)	MoE Router (Mixture of Experts)	动态分配请求（Token）至专家网络，避免热点
操作系统分页 (OS Paging)	vLLM KV Cache Paging	虚拟化显存空间，高效管理请求状态

以vLLM为例： 其核心创新在于将操作系统经典的内存管理机制（分页、交换），创造性地应用于管理LLM推理中关键的KV Cache状态。它如同为LLM定制了一个“显存操作系统”，管理“进程”（推理请求）和“内存页”（KV Cache Blocks），极致优化昂贵显存的利用率。这绝非凭空创造，而是经典系统原理在特定约束下的卓越应用。

AI Infra on CctoctoFX

Ascend Profiling Analysis Skill 设计深度解析

Ascend Profiling Analysis Skill 设计深度解析

一、背景与动机

为什么需要 profiling 分析？

设计目标

二、设计哲学：证据链优先

核心理念

[Deterministic RL] 确定性问题的来源 & Reproducible RL

理解LLM推理中deterministic问题来源

浮点数的非结合性

[vLLM-Ascend] MC2技术深度解析：从MoE架构到通信融合优化

概述

1. MoE架构基础与挑战

1.1 MoE模型基本原理

1.1.1 什么是MoE？

1.1.2 MoE的数学表达

1.1.3 稀疏激活机制

[VeRL,SGLang] RL训推显存管理优化

Overview

显存问题

训练阶段显存

推理阶段显存

[AIInfra] FlashAttention 深度解析：从数学原理到工程实现

1. 问题的本质：传统Attention的根本瓶颈

1.1 传统Attention机制的计算模式

第一步：计算注意力得分矩阵

第二步：Softmax归一化

[VeRL] DataProto介绍

Verl DataProto 实现原理与数据流动分析

目录

1. 概述

2. DataProto 核心架构

2.1 数据结构设计

2.2 数据一致性检查

3. HybridFlow 设计理念

3.1 设计动机

[VeRL] AgentLoop源码走读

[VeRL] 参数速览

Batch Size

Dynamic Batch Size

[SGLang] 后端代码速览

[RL4LLM] 异步RL框架: Slime

总体架构

各模块视角的关系图

slime/rollout 组件图

[RL4LLM] 异步RL框架: Areal

异步PPO训练调用流程

用户入口到配置解析

昇腾超节点CloudMatrix384论文拆解

核心指标和计算方式

TPOT (Time Per Output Token)

计算效率 (Tokens/s per TFLOPS)

缓存访问延迟 (KV Cache Access Latency)

专家并行扩展性 (EP Degree)

INT8量化收益

QA辅助理解

为什么用TPOT而非QPS？

为什么强调计算效率而非绝对吞吐？

为什么测量远程DRAM访问延迟？

超节点架构

三级网络平面的物理隔离

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

数据加载与预处理

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

数据预处理

AI Infra：颠覆性创新，还是经典工程范式的华丽转身？

表象差异：新术语与新挑战带来的“视觉冲击”

本质共性：工程核心挑战的永恒回归