在 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 中，我们观察这个函数： ...

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

近期看到一些关于传统基础设施（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），极致优化昂贵显存的利用率。这绝非凭空创造，而是经典系统原理在特定约束下的卓越应用。 ...

LaTeX 渲染测试 基础测试 行内公式：$E = mc^2$ 块级公式： $$E = mc^2$$复杂公式测试 原始问题公式1（更稳妥写法，拆成两条显示公式） $$ \mathbf{y} = f\left(\mathbf{x}\, \big[\,\mathbf{W}^{(A)}_1\; \mathbf{W}^{(A)}_2\; \cdots\; \mathbf{W}^{(A)}_n\,\big]\right) \begin{bmatrix} \mathbf{W}^{(B)}_1 \\ \mathbf{W}^{(B)}_2 \\ \vdots \\ \mathbf{W}^{(B)}_n \end{bmatrix} $$ $$ \mathbf{y} = \sum_{i=1}^n f\big(\mathbf{x}\mathbf{W}^{(A)}_i\big)\,\mathbf{W}^{(B)}_i $$ 其他常见LaTeX测试 分数和根号： $$\frac{\sqrt{x^2 + y^2}}{2}$$积分： $$\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}$$矩阵（确保每行使用 \ 换行）： $$ \begin{pmatrix} a & b \\ c & d \end{pmatrix} \begin{bmatrix} x \\ y \end{bmatrix} = \begin{bmatrix} ax + by \\ cx + dy \end{bmatrix} $$ 求和和乘积： $$\sum_{i=1}^n i = \frac{n(n+1)}{2}$$$$\prod_{i=1}^n i = n!$$上下标组合： $x^{2^3}$, $x_{i_j}$, $x^{(a)}_{(b)}$ ...

本文旨在记录对中间件、编排组件容器化部署后，实现kubernetes扩展组件Controller的过程。 Third-Parties kubernetes-client: javascript client-go kube-rs client-go源码分析 目录结构 kubernetes: contains the clientset to access Kubernetes API. discovery: discover APIs supported by a Kubernetes API server. dynamic: contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects. transport: set up auth and start a connection. tools/cache: useful for writing controllers. informers: informer group listers: lister group 代码实例 1 2 3 4 git clone https://github.com/huweihuang/client-go.git cd client-go #保证本地HOME目录有配置kubernetes集群的配置文件 go run client-go.go client-go.go ...