欢迎来到 Ringi’s Log 👋

🏛️ 第10讲：AI Infra 性能工程方法论与三账本——FLOPs、显存与通信 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：一个顶级的 AI Infra 工程师与普通算法调包侠之间，最根本的分水岭是什么？不是看谁能背出更多的 PyTorch API，而是看谁拥有**“在写下第一行代码前，就能在草稿纸上精确算清整个系统算力、显存与网络通信物理账本”的硬核内功**！ 很多初入大厂的同学，面对一个全新的大模型训练或推理任务时，往往两眼一抹黑：不知道该申请 8 张卡还是 64 张卡、不知道 Batch Size 设多大才不会 OOM、不知道 nvidia-smi 里的 GPU-Util 99% 背后其实隐藏着极其严重的内存等待、更不知道集群训练速度慢究竟是卡在 Tensor Core 算力不足、显存带宽受限（Memory-Bound）还是被跨机 AllReduce 网络活活拖垮。 性能工程的本质就是“算账”。本讲作为 Module 00 的终极集大成篇，我们将彻底告别盲目试错，用极客大白话、生活直觉比喻、手把手极简数字算盘与 Roofline 物理模型，带你手撕大模型 算力账本（$2P/6P/8P$）、显存四账本与跨卡通信账本，彻底掌握千卡集群资源规划的最高心法！ ...

🏛️ 第12讲：GPU-Util 100% 算力却只有 15%？——SM 执行、Warp 调度、Tensor Core 与 Roofline 模型的第一性原理 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 01: GPU 硬件架构、数据搬运、集群通信与 Overlap 篇章范式：📐 硬件体系与性能建模篇（Hardware Architecture & Performance Modeling Paradigm） 核心导读： 刚进大厂做性能工程时，很多初学者看到终端里 nvidia-smi 实时跳动的 GPU-Util: 100%，就长舒一口气以为硬件算力已经被榨干了。然而，只要掏出 Nsight Compute（NCU）或 PyTorch Profiler 仔细一测，你往往会被残酷的技术现实泼一盆冷水——Tensor Core 的实际活动利用率（Tensor Core Active）可能连 15% 都不到！ 为什么明明一张价值数十万的旗舰计算卡显卡风扇狂转、监控利用率拉满，真正干核心矩阵计算的算力单元却大部分时间在“带薪摸鱼”？ GPU 硬件到底是以什么粒度在调度代码？流式多处理器（SM）内部除了算力，到底还在忙什么？数据在 Register、Shared Memory、L2 Cache、HBM 之间穿梭时，究竟付出了怎样令人绝望的时延代价？ 本讲我们将彻底撕开 GPU 硬件的物理黑盒，从硅片微架构第一性原理层层拆解 SM、Warp 调度器、Tensor Core 与存储金字塔的协同分工，并掌握大厂性能工程的终极试金石——Roofline 性能模型！ ...

🏛️ 第09讲：网络通信基础与集合通信 Collective 原语直觉——从物理网络拓扑到 Ring/Tree 算法与通信量第一性原理 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在单卡时代，算法工程师只需要关心“算力有多大、显存放不放得下”；然而一旦进入大模型时代，当我们需要调度单机 8 卡乃至跨机数千张 GPU 协同训练一个 70B/405B 大模型时，整个系统的性能瓶颈就会发生天翻地覆的转移——单卡算力再强，网卡慢也只能干等！ 很多初学者在接触分布式训练（DDP、Megatron-LM、DeepSpeed ZeRO、FSDP、MoE）时，常常被各种英文术语搞得晕头转向：一会儿是 AllReduce，一会儿是 AllGather，一会儿又是 ReduceScatter 和 AllToAll。如果你只把它们当作抽象的黑盒 API，你就永远无法理解为什么千卡集群的 GPU 利用率会离奇腰斩，无法手算每一步跨卡通信到底搬运了多少字节，更不知道为什么在 NVLink 域内和跨机网卡上要采用完全不同的算法。 集合通信（Collective Communication）是分布式系统必须掌握的通用世界语。本讲我们将彻底告别枯燥的公式堆砌，用极客大白话、生活直觉比喻、手把手极简数字算盘与拓扑图解，带你彻底穿透八大通信原语、Ring-AllReduce 环形流水线与 $\alpha$-$\beta$ 通信模型，手撕分布式训练背后的通信量账本！ ...

🏛️ 第08讲：为什么 Attention 算力没少算，FlashAttention 却能快 3 倍？——从 Decoder Block 算子图、RoPE 复数旋转到显存四账本的第一性原理 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：📐 模型架构、算法与显存建模篇（Model Architecture & Memory Ledger Paradigm） 核心导读：你手里有一张 80GB 显存的 A100，输入 4096 长度的 Prompt，做一次 Attention 矩阵乘法只需要 0.05 秒；但一旦上下文拉长到 32K，显存瞬间像决堤的海啸一样暴涨 64 倍直接 OOM 炸机！更奇怪的是：后来出现的 FlashAttention 在数学上一次浮点运算都没少算（FLOPs 完全相同），为什么端到端速度却能暴涨整整 3~5 倍？ Attention 真正昂贵的，到底是算力，还是慢速 HBM 显存的数据搬运？ 学习 Transformer 的终极目的，绝不是死记硬背公式，而是建立起清晰的数据流动直觉（Tensor Flow）、算力与显存账本（Arithmetic & Memory Ledger） 与 底层硬件执行心智模型（Hardware Execution Mapping）。从前向 GEMM 矩阵乘法到反向梯度回传，从 $O(S^2)$ 的 Attention 显存海啸到 FlashAttention 的片上 SRAM 算子融合，从 MHA 到 GQA 的 KV Cache 显存瘦身，从绝对位置编码到 RoPE 的 2D 复数旋转魔术——每一个看似精妙的算法改进，背后都深刻交织着计算机体系结构的算力受限（Compute-Bound）与带宽受限（Memory-Bound）的物理博弈！ 本讲我们将彻底告别死板的数学堆砌，用极客大白话与手把手推导，拆透 Transformer 的每一颗齿轮与每一个张量 Shape，带你亲手白板手算出 7B/70B 模型的全部参数与显存四账本！ ...

🏛️ 第07讲：PyTorch 异步执行流——CUDA Stream 与 CUDA Graph 原理 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在很多刚接触 GPU 编程或大模型训练的同学眼中，代码的执行逻辑总是理所当然地被当作“同步串行”的：Python 解释器读到第 1 行矩阵乘法，GPU 就把第 1 行算完；读到第 2 行激活函数，GPU 再接着算第 2 行。然而，这种朴素的直觉在现代 GPU 计算体系中是彻底错误的！ GPU 本质上是一个独立于 CPU 的极致并发、完全异步的协处理器（Asynchronous Coprocessor）。当你在 Python 中调用 c = torch.matmul(a, b) 时，CPU 仅仅是把一条计算指令装填进硬件队列后就瞬间扬长而去，实际的计算可能要在几十微秒之后才会在 GPU 内部的流式多处理器（SM）上真正运转。这种异步设计赋予了系统极高的并行吞吐，但也带来了重重致命暗礁：为什么用 time.time() 测出的模型耗时只有 0.1 毫秒？为什么随手写一句 print(loss.item()) 就会导致 Serving 吞吐暴跌 70%？为什么在没有调用 tensor.record_stream() 时多流并发会出现静默的数据踩踏（Data Corruption）？为什么在大模型单 Token 生成（Decode）阶段，算力强劲的 H100 显卡有 80% 的时间在饥饿等待 CPU 下发指令？ 本讲将带你穿透 Python 运行时与 CUDA 驱动层，手拆 Host-Device 异步流水线、CUDA Stream/Event 硬件调度模型、Launch Overhead 微秒级账本，并彻底掌握大模型推理引擎（如 vLLM、TensorRT-LLM）性能翻倍的终极大杀器——CUDA Graph 录制与重放机制！ ...

🏛️ 第11讲：GPU 利用率 99% 的卡，为什么训练还是跑不快？——从 Kineto 底层探针、Trace 时间线四重病灶到 PyTorch Profiler 性能体检实战 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在 AI Infra 性能工程中，最容易让初学者陷入绝望的怪象莫过于：nvidia-smi 里的 GPU-Util 明明已经彪到了 99%~100%，但模型的单步训练耗时依然慢如蜗牛，吞吐量连理论上限的 30% 都达不到！ 很多工程师遇到性能瓶颈时，第一反应往往是凭经验瞎猜：“是不是 Attention 矩阵乘法太慢了？要不要手写个 Triton 融合算子？”——结果吭哧吭哧死磕了两周，端到端吞吐仅仅提升了 2%，最后用 Profiler 拍出一张时间线 X 光片才发现：整整 85% 的时间全在被 Python 端单进程数据加载（DataLoader）阻塞，GPU 核心绝大部分时间其实在发呆等数据！ 调优千万条，Profiling 第一条！ 性能优化的本质，往往不是“让 GPU 算得更快”，而是“让 GPU 少等”。PyTorch Profiler 就是我们手中的工业级全身 CT 机。本讲我们将彻底告别盲目摸黑调优，从 Kineto / CUPTI 硬件时间戳探针的第一性原理出发，带你掌握四阶 Schedule 采样周期、Chrome Trace / Perfetto 时间线四大典型病灶排障、TensorBoard 性能看板，亲手完成一次工业级大模型训练系统的深度性能体检！ ...

🏛️ 第06讲：PyTorch 计算图与 Autograd 显存生命周期——动态 DAG、反向求导机制与 Activation 显存优化 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：很多做深度学习开发的同学都有过这样的痛苦经历：明明自己的模型只有 7B 参数，按照 FP16 精度手算权重只有 14GB，理论上一张 80GB 的 A100/H100 显卡能够轻轻松松塞下，然而只要把训练的 Batch Size 从 2 调到 4，或者把序列长度 Sequence Length 稍微拉长一点，终端就会瞬间无情地抛出 torch.cuda.OutOfMemoryError（俗称 OOM 爆显存）！ 显存到底被谁吃掉了？为什么前向计算时显存会一路飙升，反向传播时显存又逐步回落？PyTorch 在后台悄悄创建的“动态计算图（DAG）”究竟是什么数据结构？为什么有些张量在前向计算完后必须死死留在显存中不能被释放？为什么随手写一句 losses.append(loss) 就能瞬间引发吞噬上百 GB 显存的静默内存泄漏？本讲将带你彻底穿透 Python 外壳，深入 PyTorch C++ 核心库（torch/csrc/autograd），手拆动态图构建、反向求导流水线、张量显存生命周期与 Activation Checkpointing（激活值重计算）的底层奥秘！ ...

🏛️ 第03讲：计算机体系结构前置——CPU 存储层次、Cache Line 与 NUMA 架构 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在大模型分布式训练与高并发推理中，GPU 算力利用率（MFU）低下往往不是因为 GPU 算子写得不够好，而是因为主机 CPU 端与数据流水线发生了严重阻塞（CPU Bubble）！从 CPU 存储金字塔（L1/L2/L3/DRAM）、64 字节 Cache Line、MESI 缓存一致性与伪共享风暴，到内存自然对齐、NUMA 跨 Socket 拓扑绑定以及 Pinned Memory 锁页 DMA 传输，本讲带你用大厂工程师的第一性原理彻底击穿 CPU 与内存架构，消灭数据搬运瓶颈。 ...

🏛️ 第04讲：Linux 系统基线与性能分析核心工具箱 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在 AI Infra 领域，“排查性能瓶颈绝不能靠猜”！当千卡集群训练突然 Hang 住、GPU 算力利用率（MFU）从 95% 暴跌至 0%、某个 DataLoader Worker 变成无法 kill -9 的 D 状态（Uninterruptible Sleep）、或者单卡显存爆满但 CPU 利用率只有 5% 时，缺乏操作系统底层观测能力的工程师往往束手无策。本讲从 Linux 进程调度与上下文切换物理开销、Load Average 内核指数衰减模型、四大黄金资源（CPU/内存/磁盘/网络）的 USE 监控体系，一路深入到硬件 PMU 计数器、perf 堆栈采样与 On-CPU / Off-CPU 火焰图实战，带你亲手打造大厂生产级系统听诊器。 ...

🏛️ 第05讲：PyTorch 底层系统机制——Tensor 内存布局、Stride 与 Contiguous 主讲人：👓 Ringi（大厂 AI Infrastructure 工程师） 所属模块：Module 00: 性能工程与系统前置 篇章范式：🏛️ 性能工程与系统前置篇（Performance Engineering & System Baseline） 核心导读：在许多深度学习初学者的直觉中，Tensor 就像一个立体透明的"多维魔方"，我们在 Python 中调用 transpose、permute、view 似乎是在三维甚至高维空间中随意旋转和切割这个魔方。但在底层物理硬件和操作系统眼中，物理内存和显存永远都只是一条从低地址向高地址线性延伸的一维连续字节数组（1D Storage Buffer）！ PyTorch 究竟用了什么精妙的元数据机制，让这个一维数组在 Python 上层呈现出任意维度的几何形态？为什么一个看似人畜无害的 x.t().view(-1) 会引发 RuntimeError 运行时崩溃？为什么随手加一句 .contiguous() 能解决报错，却可能在千卡集群上引发数十 GB 显存的隐式拷贝风暴与 GPU 吞吐腰斩？本讲带你从 C10/ATen 源码与计算机体系结构第一性原理出发，彻底穿透 Tensor 内存布局、Stride 步长投影与 GPU 访存合并（Memory Coalescing）的底层奥秘！ ...