岗位分支 · Systems

定位：优化推理引擎、GPU Kernel、显存、吞吐，压榨硬件最后一丝性能 对应主路线：Ch3（推理性能优化）深入 + 本附录专项 典型团队：推理引擎团队、Kernel 优化团队、AI Infra 核心研发

核心能力领域#

1. CUDA 编程基础#

• Grid / Block / Thread：CUDA 线程层次
• 内存层次：Global Memory → L2 Cache → Shared Memory → Register
• Occupancy：SM 上同时驻留的 warp 数
• Bank Conflict：Shared Memory 的 bank 冲突

CUDA 内存层次与延迟：

优化核心：减少 HBM 访问，把数据尽量留在 SRAM。

2. FlashAttention 原理#

标准 Attention 的瓶颈：QK^T 的结果太大（seq_len × seq_len），无法放进 SRAM，必须写回 HBM（高带宽显存），再读回来做 softmax 和 × V——多次 HBM 往返。

FlashAttention 的做法：

• 将 Q、K、V 分块（tiling），每块小到能放进 SRAM
• 在 SRAM 内完成 softmax + attention 计算
• 大幅减少 HBM 读写：H100 HBM 带宽 3TB/s vs SRAM 带宽 19TB/s，减少访问次数是关键

FlashAttention 的核心优化：

标准 Attention：
  Q, K, V 从 HBM 加载 → 计算 QK^T → 写回 HBM
  → 读回 QK^T → softmax → 写回 HBM
  → 读回 softmax(QK^T) → × V → 写回 HBM
  → 3 次大矩阵的 HBM 读写

FlashAttention：
  Q, K, V 分块加载到 SRAM → 在 SRAM 内完成全部计算 → 只写回最终结果
  → 1 次 HBM 写（结果）
  → HBM 读写减少 5-10x

FlashAttention 2 vs 3：

• FlashAttention 2：A100 优化，支持 FP16/BF16
• FlashAttention 3：H100 优化，支持 FP8，利用 Hopper 的异步拷贝和 TMA

3. PagedAttention 与 RadixAttention 源码理解#

需要在 vLLM/SGLang 源码层面理解：

• KV Cache Block 的分配和回收逻辑
• Block Table 映射
• Prefix Caching 的命中检测机制
• Radix Tree 的插入/查找/淘汰

vLLM PagedAttention 源码结构：

vllm/
├── core/
│   ├── block_manager.py    # Block 分配与回收
│   └── scheduler.py        # Continuous Batching 调度
├── attention/
│   └── backends/           # PagedAttention kernel
└── worker/
    └── model_runner.py     # 前向传播执行

4. Kernel 优化关注指标#

CUDA Graph 在 decode 阶段效果显著——小 batch 下 kernel launch overhead 可占 20-40%，CUDA Graph 基本消除这一开销。

Nsight 分析方法：

Nsight Systems（看 timeline）：
├─ kernel launch 间隔（overhead）
├─ CPU-GPU 同步点
├─ 数据拷贝（H2D/D2H）
└─ 多 GPU 通信（NCCL）

Nsight Compute（看单个 kernel）：
├─ Occupancy（SM 驻留率）
├─ Memory Throughput（HBM 带宽）
├─ Compute Utilization（SM 吞吐）
├─ Bank Conflict（Shared Memory）
└─ Stall Reasons（停顿原因）

5. 量化实现#

• FP8：H100/H200 原生支持，权重 + 激活 + KV Cache 都可以 FP8
• INT4/AWQ：Activation-aware Weight Quantization，通过分析激活分布确定量化参数
• FP4：B200/昇腾 950PR 原生支持，需重新编译 kernel

量化对精度和性能的影响：

6. Speculative Decoding 实现#

• Medusa：在模型上添加额外的"草稿头"，一次前向出多个候选 token
• EAGLE：用特征预测代替草稿模型，精度更高
• 与 Continuous Batching 的兼容性处理

EAGLE 原理：

标准 Decode：每次 1 token，串行
  token_t → 模型 → token_t+1

EAGLE Decode：小模型猜 + 大模型验证
  1. Draft model 一次猜 4-8 个 token
  2. Target model 一次 forward 验证全部
  3. 正确接受的 token 直接输出
  4. 第一个错误的 token 之后重新猜

加速比：取决于 draft model 准确率
  准确率 80% → 2-3x 加速
  准确率 60% → 1.5-2x 加速

7. MoE 推理优化#

• EPLB：动态重映射 expert 到 GPU，解决路由不均衡
• Expert 缓存：热门 expert 保留多副本，冷门 expert 共享
• 通信优化：EP 的 all-to-all 通信融合

加分方向#

• Triton 编写自定义 Kernel
• FlashMLA（MLA 的高效 CUDA 实现）
• 通信融合（将多个小 AllReduce 合并为一次大 AllReduce）
• 算子融合（将 MLP 的两个 GEMM + 激活函数融合为一个 kernel）
• 自定义 Attention Kernel（针对特定模型架构优化）

技能树#

基础（必备）
├── C++ / CUDA 编程
├── PyTorch 源码理解
├── Python（性能测试脚本）
└── Linux 性能分析

GPU 编程
├── CUDA（Grid/Block/Thread，内存层次）
├── Triton（Python 写 GPU kernel）
├── CUTLASS（矩阵乘模板库）
└── cuBLAS / cuDNN API

推理引擎源码
├── vLLM 源码（PagedAttention / Scheduler）
├── SGLang 源码（RadixAttention / 调度）
├── FlashAttention 源码
└── TRT-LLM（加分）

性能分析
├── Nsight Systems（timeline）
├── Nsight Compute（kernel 级）
├── PyTorch Profiler
└── DCGM（GPU 监控）

Kernel 优化
├── FlashAttention / FlashMLA
├── CUDA Graph（消除 launch overhead）
├── 算子融合
├── 通信融合
└── 量化 kernel（FP8/INT4/FP4）

学习路径建议#

1. 先掌握 CUDA 编程基础：Grid/Block/Thread，内存层次
2. 再学 FlashAttention 原理与实现：tiling，减少 HBM 读写
3. 然后读 vLLM/SGLang 源码：PagedAttention/RadixAttention
4. 最后学 Nsight 性能分析：Systems + Compute
5. 加分：Triton Kernel、FlashMLA、Speculative Decoding 实现

项目经验建议#

简历表达参考：

LLM 推理引擎性能优化，针对 vLLM/SGLang 深度调优：
- 自定义 Triton Kernel 优化 MoE expert 路由，吞吐提升 30%
- FlashMLA 集成，DeepSeek-V4 长上下文（1M）推理显存降低 40%
- CUDA Graph 消除 decode 阶段 launch overhead，小 batch TPOT 降低 25%
- FP8 量化 kernel 实现，权重+激活+KV Cache 全 FP8，吞吐 2x
- Nsight Systems 分析定位 NCCL 通信瓶颈，AllReduce 带宽利用率从 60% 提升到 85%

典型面试题方向#

1. FlashAttention 为什么快？核心优化点是什么？

   • 答题思路：tiling 把 Q/K/V 分块放进 SRAM，在 SRAM 内完成 softmax + attention，减少 HBM 读写 5-10x

2. PagedAttention 的核心思想？为什么能提升显存利用率？

   • 答题思路：类比 OS 虚拟内存分页，KV Cache 按 Block（16 token）分页，不要求连续显存，利用率 60% → 96%

3. 如何用 Nsight 分析推理性能？

   • 答题思路：Systems 看 timeline（kernel launch/同步/通信），Compute 看 kernel 级（occupancy/bandwidth/bank conflict）

4. MoE 推理为什么难优化？MLA 怎么实现 KV 压缩？

   • 答题思路：MoE 难在专家路由不均衡（EPLB）+ 全 expert 权重加载（显存大）；MLA 用低秩投影压缩 KV 到 1/8~1/16

5. Speculative Decoding 为什么能加速？

   • 答题思路：串行 decode → 小模型猜多个 + 大模型批处理验证，把串行变批处理，GPU 利用率提升

6. CUDA Graph 为什么对 decode 有效？

   • 答题思路：decode 阶段小 batch，kernel launch overhead 占 20-40%；CUDA Graph 捕获 kernel 序列，消除 launch overhead