Hexo

LLM 推理优化学习主干道前置差距分析 分析日期：2026-03-29 前置能力 是否具备 处理方式 Transformer / Attention 基本概念 ❌ 缺失 纳入主干道节点 01 C++ 基础（指针、内存模型、RAII） ❌ 缺失 纳入主干道节点 02-03 CUDA 执行模型（thread/warp/block/shared memory） ❌ 缺失 纳入主干道节点 04-05 GPU 内存层级（HBM/SRAM/带宽瓶颈） ❌ 缺失 纳入主干道节点 06 LLM 推理系统（KV cache、batching、调度） ❌ 缺失 纳入主干道节点 07-11 OS 底层（内存管理、进程、调度） ✅ 已具备 节点 06、08 直接复用 向量化执行引擎经验（Gluten） ⚠️ 部分相关 节点 05、09 作为理解锚点 Java / Spark Infra 经验 ✅ 已具备 节点 11 系统设计时复用 核心抽象LLM 推理优化是一个 在有限硬件资源上最大化语...

03 · C++ 编译模型与 CMake 目标：理解 C++ 从源文件到可执行文件的完整流程，以及 .h/.cpp 分离的原因，能独立用 CMake 构建多文件项目 一、编译流程总览1234567源文件 (.cpp) ↓ 预处理器翻译单元（纯文本） ↓ 编译器目标文件 (.o) ↓ 链接器可执行文件 每个 .cpp 文件独立编译成一个 .o，链接器最后把所有 .o 合并。 二、第一步：预处理器输入：原始 .cpp 源文件（含 #include、#define 等指令） 做了什么： 展开 #include：把头文件内容直接复制粘贴到 #include 的位置 1234567// 原始 main.cpp#include "add.h"int main() { ... }// 展开后int add(int a, int b); // add.h 的内容被复制进来int main() { ... } #include <iostream> 同理，展开后有几千行。 展开 ...

04 · CUDA 执行模型 目标：理解 GPU 和 CPU 的执行模型根本差异，掌握 thread/warp/block/grid 四层层级，理解 warp divergence 和延迟隐藏机制 一、GPU 和 CPU 的根本差异高层抽象： 12345CPU：少量强大的核心（8-32），每个核心有复杂的分支预测、乱序执行、大缓存 → 设计目标：让单个任务跑得尽可能快GPU：大量简单的核心（3080 Ti 有 10240 个 CUDA core），每个核心只做简单的乘加 → 设计目标：让海量任务同时跑 矩阵乘法天然适合 GPU——拆成几万个独立的乘加操作，同时计算。 为什么 GPU 核心可以这么多： 每个 GPU 核心没有复杂的控制逻辑（分支预测、乱序执行），省下来的晶体管全部用来堆计算单元。代价是编程模型受限——程序员必须显式组织并行。 二、四层执行层级Thread（线程）最小执行单元，执行一次 kernel 函数调用。每个 thread 有独立的寄存器和局部变量。 例：矩阵加法 C[i] = A[i] + B[i]，每个 ...

01 · Transformer 结构与 Attention 计算 目标：理解 LLM 推理时到底在算什么——从 token 输入到新语义向量输出的完整计算流程 一、推理的本质：一切都是矩阵乘法神经网络是一个函数：输入一组数字，输出一组数字。推理（Inference）就是执行这个函数，不涉及任何参数更新。 LLM 推理： 输入：一串 token（文字被切分并编码成数字序列） 输出：下一个 token 的概率分布 整个推理过程中，绝大部分计算量只有一种运算：矩阵乘法（GEMM）。这是 GPU 适合做推理的根本原因——GPU 专为大规模并行矩阵乘法设计。 二、Attention 出现之前：RNN 的问题RNN 处理语言序列的方式是逐词传递隐状态： 123"猫" → [RNN] → h₁"喜欢" → [RNN, 读入 h₁] → h₂"鱼" → [RNN, 读入 h₂] → h₃ 问题：隐状态每传一步就被压缩一次，越早的词信息越难保留。处理”鱼”时，”猫”的信息已经被稀释了两次。这叫长程依赖问题。 另一个问题：必须...

02 · C++ 必要基础 目标：理解 C++ 的内存模型和对象生命周期管理，能看懂推理框架 host 代码里的指针、智能指针、模板用法 一、指针与引用C++ 在 C 的指针基础上增加了引用： 123int x = 42;int* p = &x; // 指针：存储 x 的地址int& r = x; // 引用：x 的别名，本质是语法糖，编译器实现上通常也是地址 指针 引用 是否可以为 null 可以 不行，必须绑定到对象 是否可以改变指向 可以 不行，绑定后不能换 语法 *p 解引用 直接用 r，和用原变量一样 函数传参的三种方式： 123void foo_value(int x) { x = 99; } // 复制，不影响外部void foo_ptr(int* x) { *x = 99; } // 传地址，可修改外部void foo_ref(int& x) { x = 99; } // 传引用，可修改外部，语法更干净 推理框架...

05 · CUDA 内存优化 目标：理解 GPU 内存层级，掌握 Shared Memory Tiling 优化 GEMM 的原理，理解 bank conflict 和延迟隐藏机制 一、GPU 内存层级高层抽象： 123寄存器（Register） → Shared Memory → L2 Cache → HBM（显存） 最快 最慢 最小 最大 层级 作用域 延迟 容量（3080 Ti） 寄存器 每个 thread 私有 ~0 极小 Shared Memory block 内共享 ~5ns 每个 SM 约 100KB L2 Cache 所有 SM 共享 中等 6MB（4090D 72MB） HBM 所有 SM 共享 200-800 时钟周期 12GB 核心推论： 同一时刻需要被多次读取的数据，应该先从 HBM 搬到 Shared...

06 · GPU 性能模型与分析工具 目标：理解 Roofline Model，能计算 kernel 的算术强度，判断瓶颈在带宽还是算力，知道该往哪个方向优化 一、两个硬件上限GPU 的性能受两个硬件上限约束： 12算力上限：GPU 每秒能做多少次浮点运算（TFLOPS）带宽上限：GPU 每秒能从显存搬多少数据（TB/s） 4090D 的参数： 算力峰值：82.6 TFLOPS（FP32）= 82600 GFLOPS 显存带宽：1008 GB/s 二、算术强度算术强度（Arithmetic Intensity）：kernel 的固有属性，由计算量和数据量的比值决定： 1算术强度 = 总浮点运算次数（FLOP） / 总显存访问字节数（Byte） 不需要运行就能算出来，只需数清楚 kernel 做了多少次运算、读写了多少数据。 Vector Add 的算术强度： 123456C[i] = A[i] + B[i]，N 个元素浮点运算：N 次加法 = N FLOP显存访问：读 A（4N Byte）+ 读 B（4N Byte）+ 写 C（4N Byte）=...

07 · 自回归生成与 KV Cache 目标：理解 LLM 推理的完整时序过程，掌握 KV Cache 的作用和显存代价，理解 Prefill 和 Decode 两个阶段的本质差异 一、Transformer 完整计算图（回顾）12345678910111213141516171819token 序列 ↓ Embedding 层[seq_len, d_model] ↓ Transformer Block × N 层（每层结构相同） ├── Multi-Head Self-Attention │ x → Q,K,V（各乘权重矩阵） │ → reshape 成 [num_heads, seq_len, head_dim] │ → 每个 head 独立做 Attention │ → 拼接 + W_O 投影 │ → 残差连接 + LayerNorm └── FFN → W₁ 升维（×4）→ ReLU → W₂...

08 · Batching 与调度 目标：理解 Batching 的本质收益，掌握 Static Batching 和 Continuous Batching 的区别，理解 vLLM scheduler 的核心调度逻辑 一、为什么需要 BatchingDecode 阶段每步只处理 1 个 token，GPU 有上万个 CUDA core，但只有 1 个 token 的计算量——绝大多数算力在空转。 Batching 的本质收益：让多个请求分摊读取模型权重矩阵的开销，提升算术强度。 用 roofline 语言： 123456789单请求 decode： 计算量：1 × d_model² 数据量：d_model²（读权重矩阵） 算术强度 ≈ 1 FLOP/Byte ← 极低，memory-boundbatch size = N： 计算量：N × d_model² 数据量：d_model²（权重矩阵只读一次，N 个请求共用） 算术强度 ≈ N FLOP/Byte ← 随 batch size 线性增长 batch size 越大，算术强度越高，在 roofli...

01 · Core Concepts 目标：理解 Kafka 的四个核心抽象及其关系，能画出消息从 produce 到 consume 的完整路径 核心概念TopicTopic 是逻辑概念，是消息的命名分类单位（如 order-events、user-clicks）。Topic 本身不存储数据，真正存储数据的是 partition。 PartitionPartition 是物理存储单元。每个 partition 在磁盘上是一个目录，目录下包含多个 segment 文件（.log、.index、.timeindex）。Kafka 按大小或时间把数据切割成多个 segment，避免单个文件无限增长。 Partition 解决两个问题： 并行度：多个 partition 分布在不同 broker 上，读写可以同时进行，吞吐量线性扩展。消费端同理，N 个 partition 最多支持 N 个消费者并行消费。 水平扩展：partition 是 Kafka 的最小分布单元，不同 partition 可以在不同 broker 上，单个 topic 的数据量不受单台机器限制。 注意：pa...