AI Infra

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

在 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），极致优化昂贵显存的利用率。这绝非凭空创造，而是经典系统原理在特定约束下的卓越应用。 ...