AI Infra

FLOPs 完整估算：从矩阵乘法到 Attention 到 FFN，覆盖 Full Attention / MSA / MLA / Mamba-2 / GDN 六种注意力架构。

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。 ...

理解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在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 个专家索引。 ...

SGLang团队的博客：https://hebiao064.github.io/rl-memory-management Overview 上述是简化的在线RL训练流程，隐去了reference和critic model，并且用基础的reward function而非reward model来说明流程。实际上就是policy model存在的training engine和rollout engine上需要进行优化。 从简化的PPO流程开始： 1 2 3 4 5 6 7 8 9 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): ...