性能建模与仿真全面导论:从芯片到系统的系统性学习路径

本文基于知识库中 ~60 篇性能建模仿真相关的芯片建模、训练系统、推理系统、缓存系统和开源项目分析笔记编写而成,旨在为新接触本领域的同事提供从理论基础到前沿方法论的系统性入门指南。


一、为什么需要性能建模与仿真?

1.1 核心问题

在 AI 基础设施领域,我们面临一个根本性矛盾:

硬件/系统的设计空间增长 >> 实际部署/测试的能力增长

具体体现在:

场景问题举例
芯片设计流片前无法验证性能一次流片成本 $10M+,周期 12-18 个月
推理部署配置空间巨大模型×GPU×并行策略×批大小×调度策略 = 数万种组合
训练集群采购前需规划1024 GPU 集群需 $5-10M,跑一次基准测试需 42K GPU 小时
架构探索新方案评估难MoE 中专家数、Top-K 值、路由策略的联合搜索

性能建模与仿真就是解决这一矛盾的核心方法:用低成本的计算(CPU 仿真、解析公式、ML 模型)替代高成本的物理实验(GPU 运行、芯片流片、集群部署)。

1.2 核心权衡:精度 vs 速度

所有性能建模方法都面临同一个核心权衡:

精度 ↑ 速度 ↓
──────────────────────────────────────────
RTL/电路级仿真 (Verilog, SPICE)
    ↓
周期精确仿真器 (gem5, GPGPU-Sim)
    ↓
Trace 驱动仿真 (Accel-Sim, Chakra)
    ↓
解析分析模型 (Roofline, GenZ, MAESTRO)
    ↓
ML 预测模型 (Ithemal, NeuSight)
    ↓
启发式/经验公式 (Pollux WS Model)
精度 ↓ 速度 ↑

核心原则:没有最好的方法,只有最适合问题的方法。选择何种粒度取决于:

  • 决策类型:架构级(粗粒度)vs 实现级(细粒度)
  • 所需精度:趋势预测(~30%)vs 精确规划(<5%)
  • 计算预算:毫秒级(online scheduling)vs 小时级(design space exploration)

二、前置知识:构建概念基础

2.1 硬件架构基础

要理解性能建模,首先需要理解被建模的对象。

GPU 微架构关键概念

概念说明对建模的影响
SM / Streaming MultiprocessorGPU 的基本计算单元Tile 分解粒度、并发度
Warp / Wavefront32 线程的执行组SIMT 执行模型、分支发散
HBM / 高带宽内存GPU 片外显存内存带宽是核心瓶颈(DDR → HBM2e → HBM3)
NVLinkGPU-GPU 高速互联分布式训练的关键通信参数
Tensor Core专用矩阵乘累加单元FP16/INT8/FP8 算力
Systolic Array脉动阵列(TPU/NPU)数据流设计决定利用率
Tile 执行Kernel 输出拆分为 tile,每 tile 映射到 SM现代 GPU kernel 性能的核心决定因素

关键认知:GPU 是一个吞吐量设备(throughput-oriented),而非延迟设备(latency-oriented)。这意味着:

  • 并发度(occupancy)直接影响性能
  • 内存带宽瓶颈比计算瓶颈更常见(对 LLM 推理)
  • Tensor Core 的利用需要精心设计的数据布局

NPU 加速器架构概览

与 GPU 不同,NPU/DSA(领域专用架构)更偏向确定性执行

NPU 特性说明
脉动阵列确定性的数据流动模式,延迟可精确计算
AI Core昇腾 NPU 的计算单元,Cube Unit + Vector Unit + Scalar Unit
L1/L2 Buffer软件管理的 on-chip memory(类似 GPU shared memory)
任务调度器确定性任务下发(SQ/CQ 队列机制)

核心建模优势:NPU 的执行比 GPU 更可预测,因为:

  • 无复杂的 warp scheduling / branch divergence
  • On-chip memory 由软件显式管理
  • 算子执行路径确定性强

2.2 系统基础

分布式训练并行策略(五维空间)

并行策略切分维度通信模式典型场景
数据并行 (DP)Batch 维度切分AllReduce 梯度同步最基础、最常用
张量并行 (TP)层内权重矩阵切分AllReduce 激活同步大模型(>13B),需节点内高带宽互联
流水线并行 (PP)按层切分P2P 通信超大模型(>70B),有气泡率问题
序列并行 (SP)序列长度切分All-to-All / Ring长序列训练(>32K tokens)
专家并行 (EP)专家放置到不同 GPUAll-to-AllMoE 模型,负载均衡是核心挑战

关键洞察:实际训练中通常采用混合并行(如 TP=8 + PP=4 + DP=8),其性能建模复杂度远高于单一并行策略,因为计算-通信重叠模式多样化。

LLM 推理服务关键概念

概念说明
Prefill 阶段处理完整 prompt,计算密集(GEMM),生成第一个 token
Decode 阶段自回归逐 token 生成,内存带宽密集(GEMV)
KV Cache存储 attention 的 Key/Value 向量,显存瓶颈
PagedAttention分页式 KV Cache 管理(vLLM),消除内部碎片
Continuous Batching迭代级批处理,新请求可插入正在执行的批次
Chunked Prefill将长 prefill 拆分为 chunk,避免阻塞 decode
PD 分离Prefill 和 Decode 在不同 GPU 上运行,优化资源利用
TTFT / TPOT / TBT首 token 延迟 / 每输出 token 时间 / token 间时间(SLO 指标)

推理建模的核心挑战:推理每次迭代的工作负载动态变化(新请求加入、旧请求完成、KV Cache 增长),这与训练中所有迭代相同的特性有本质区别。

2.3 性能分析基础工具

在深入建模之前,掌握以下分析工具和方法至关重要:

工具/方法用途对应建模层次
Roofline Model确定计算/内存哪一个是瓶颈最基础的分析模型
NVIDIA Nsight / CUPTI真实 GPU 性能 profiling数据采集
PyTorch Profiler算子级性能分析Model onboarding
NCCL 基准测试通信带宽和延迟测试分布式建模
Chrome Trace / Perfetto可视化执行的时序图瓶颈分析(计算-通信重叠)

三、方法论谱系:核心建模方法

这是本文的核心部分。我们将性能建模方法分为五大类,每一类有其适用场景和经典案例。

3.1 解析分析模型(Analytical Models)

核心思想:用数学公式直接计算性能,不依赖仿真运行。

代表公式

经典 Roofline: Attainable FLOP/s = min(Peak FLOPs, BW × Operational Intensity)
GenZ: T_op = max(C_op / (FLOPS × Eff_C), M_op / (BW_mem × Eff_mem))
Pollux WS Model: T(w) = w / (w · τ₀ + τ₁)

优点

  • ⚡ 极快(微秒到毫秒级)
  • 🔍 可解释性强(公式中的每项都有物理意义)
  • 🔬 适合 What-if 分析(“如果带宽翻倍会怎样?”)

缺点

  • 📉 精度有限(通常 10-30% 误差)
  • 🔗 无法捕获组件间的交互效应
  • 🚫 忽略动态行为(排队、竞争、抖动)

经典案例

工作公式精度应用
Roofline (2009)FLOP/s = min(Peak, BW × OI)~30%瓶颈分析,15,000+ 引用
GenZ (2024)带效率因子的 Roofline 扩展5.82%LLM 推理设计空间探索
Universal Perf Model (2024)三因子分离 + sigmoid 通信模型3-5%多 GPU 训练建模
DLRM Perf Model (2022)T = T_emb + T_mlp + T_interact<10%推荐系统训练建模

最佳实践:解析模型适合趋势分析初筛。在多阶段方法论中,通常先用解析模型缩小设计空间,再用更高精度的方法验证关键点。


3.2 周期精确仿真器(Cycle-Accurate Simulators)

核心思想:在软件中逐周期模拟硬件的每个微架构组件。

代表工具

工具目标精度速度适用
gem5CPU 全系统~15%1-5 MIPSCPU 微架构设计
GPGPU-SimGPU 微架构~20%10-50 KIPSGPU 架构研究(经典)
Accel-SimGPU(功能-时序解耦)<10%30-80 KIPSGPU 架构研究(现代)
SCALE-SimNPU 脉动阵列~15%10^5 cycles/sNPU 数据流设计
MAESTRONPU 数据流~10%秒级DNN 映射搜索
Ramulator 2.0DRAM 子系统<5%~500 kHz内存架构设计
McPATCPU 功耗建模~25%秒级功耗/面积估算

关键洞察

趋势 1:功能-时序解耦(Function-Timing Decoupling)

  • 早期仿真器(GPGPU-Sim)将功能正确性和时序模拟耦合在一起,导致:
    • 维护困难(新硬件架构需重新实现功能模型)
    • 速度瓶颈(功能模型拖慢时序模拟)
  • 现代仿真器(Accel-Sim)将二者分离:
    • 功能模型 → 使用真实 NVIDIA 驱动执行
    • 时序模型 → 独立可插拔的 timing model
    • 结果:精度从 20% 提升到 <10%,速度提升 2-4×

趋势 2:模块化设计

  • Ramulator 2.0 将 DRAM 仿真分为三层(Device / Controller / Protocol),层间完全解耦
  • LLMServingSim 采用插件式加速器引擎设计
  • 模块化使工具更易扩展、更易维护

适用场景判断

问:你需要知道的是"这个设计好多少"还是"这个设计具体多少"?
  ├─ "好多少" → 解析模型(Roofline, GenZ)
  └─ "具体多少" →
       问:你有硬件样品/可做 profiling 吗?
         ├─ 有 → Profile-driven 模型(Vidur, LLM-Emu)
         └─ 无 →
              问:你需要精确到微架构级吗?
                ├─ 是 → 周期精确仿真器(gem5, Accel-Sim)
                └─ 否 → 分析/ML 模型

3.3 Trace 驱动与 Profile-driven 方法

核心思想:在真实硬件上采集执行 trace(操作序列、时间戳),然后用 trace replay 或 profile-based 预测模拟不同的配置和负载。

三种模式

模式方法代表精度速度
Trace Replay 仿真录制执行图 + 参数化回放Chakra + ASTRA-sim中等
Profile-driven 预测采集算子级执行时间 → 查表预测Vidur, LLMServingSim 2.0
Online Emulation替换真实 GPU 前向传播LLM-Emu最高

Chakra 标准化执行 Trace

Chakra(Meta, 2023)的核心贡献:

  • 定义统一的执行轨迹图格式(节点类型:COMP/MEM_LOAD/COMM_SEND/COMM_RECV/COMM_COLL)
  • 支持从 PyTorch Profiler 自动采集
  • 提供生成式 AI 合成轨迹能力:学习生产轨迹统计特性,生成无 IP 泄露风险的合成轨迹

Profile-driven 方法的核心流程(以 Vidur 为例):

模型 onboard 阶段:
  模型规范 → 识别算子集合 → 硬件 profiling → Runtime Estimator (随机森林)
  
仿真执行阶段:
  部署配置 + 工作负载 → 事件驱动引擎 → Hierarchical Scheduler → 输出指标

Vidur 算子三分类方法论(LLM 推理仿真的里程碑):

算子类型依赖预测策略
Token-level当前 batch 总 token 数随机森林回归插值
Sequence-level每个请求的 KV Cache 历史Prefill: 等效单序列近似;Decode: 总 KV Cache 读取量
Communication传输数据量提前对不同拓扑 profiling

关键洞察:Profile-driven 方法的核心优势在于一次 profiling,多次复用。采集 profile 需要 GPU 时间,但仿真运行时完全无需 GPU。

精度-开销对比

方法精度Profiling 开销仿真速度
LLM-Emu (Online Emu)<5%~3 小时 GPU实时(无 GPU)
LLMServingSim 2.0 (Profile)0.95%~2 小时 GPU~10 分钟
Vidur (Profile+ML)<9%数小时 GPU分钟级
GenZ (Analytical)5.82%无需~30ms

3.4 ML 驱动的性能预测

核心思想:用机器学习模型学习从硬件/模型参数到执行时间的映射关系,避免手工建模的复杂性。

三阶段演进

阶段代表工作方法精度
1. 纯 MLIthemal (2018)LSTM + MLP 预测 IPC<10%(基本块级)
2. ML + 物理约束NeuSight (2025)ML 预测利用率 + Roofline 约束2.3-9.7%
3. 跨厂商/代际预测NeuSight (2025)从旧 GPU 预测新 GPU8.1%(未见 GPU)

NeuSight 的核心创新(ASPLOS 2025 方法论的标杆):

传统方法: 直接预测 kernel 延迟
  Input → [ML Model] → 延迟预测
  问题: 滞后于过拟合,无法泛化到未见 GPU

NeuSight 方法: 预测利用率 + Roofline 约束
  Input → [MLP] → utilization → [Roofline Law] → 延迟预测
  优势: 物理定律约束确保预测合理性,泛化能力强

关键公式

ML 方法在性能建模中的定位

不是替代传统方法,而是与它们结合
  ┌────────────────────────────────────────────┐
  │  ML 的强项:                                │
  │  1. 捕获复杂非线性关系(CUDA kernel 调优)   │
  │  2. 从数据中自动学习(无需手工公式)          │
  │  3. 泛化到未见配置(跨 GPU/跨模型)          │
  ├────────────────────────────────────────────┤
  │  ML 的弱项:                                │
  │  1. 需要足够训练数据                        │
  │  2. 纯 ML 外推能力差(H100 预测曾 724% 误差)│
  │  3. 可解释性不足(黑盒预测难归因)            │
  └────────────────────────────────────────────┘

最佳实践:使用领域知识 + ML 的混合方法,而非纯 ML。NeuSight 的”tile 分解 + 性能定律约束”范式是当前最成功的案例。


3.5 调度感知的集群级建模

核心思想:当建模对象是整个集群而非单设备时,调度决策(资源分配、并行度配置、任务放置)成为性能的关键决定因素。

三类方法

方法代表核心
Goodput 优化Pollux (OSDI 2021)统计效率 × 系统吞吐量 = Goodput
异构调度Gavel (OSDI 2020)异构 GPU 性能模型驱动的调度
带宽感知调度Themis (2021)拓扑感知 Collective 调度

Pollux 的 WS 吞吐模型(仅两个参数的优雅模型):

T(w) = w / (w · τ₀ + τ₁)

τ₀ = Wall-clock time per iteration (不随 w 缩放部分)
τ₁ = Linear overhead (与 w 线性相关部分)

关键洞察

  • 复杂的集群问题不需要复杂的方法
  • 在线更新使简单模型自适应集群负载变化
  • 模型多用于比较相对性能(哪个配置更好)而非绝对性能预测

3.6 互联性能模型(Interconnect Performance Modeling)

核心问题:在大规模分布式训练中,通信开销可能占总时间的 30-70%。互联性能模型的目标是准确预测给定拓扑、通信算法和消息大小下的通信延迟

网络拓扑分类与建模

拓扑关键特性典型规模建模挑战
Fat-Tree / Clos无阻塞多级交换,带宽均匀DGX SuperPOD (1K GPU)ECMP 哈希冲突导致的不均衡
Torus低维环形连接,每节点度数固定TPU v4 (4096 chip, 2D/3D Torus)多跳延迟、链路竞争
Dragonfly组内全连接 + 组间单跳Cray EX (Slingshot)组间路径选择、全局拥塞
NVSwitch + NVLinkGPU 节点内全互联DGX H100 (8 GPU × 400GB/s)拓扑关系清晰,主要建模带宽分配

基本延迟公式

T_comm = α + β × m + γ × H(m, topology)

其中:
- α = 启动延迟 (latency, ~1-10µs)
- β = 每字节传输时间 (bandwidth inverse)
- m = 消息大小 (bytes)
- γ = 跳数 / 拥塞因子
- H(m, topology) = 消息大小和拓扑相关的拥塞延迟

集合通信算法与建模

算法操作延迟公式 (P 个节点)适用场景
Ring AllReduceAllReduce2 × (P-1) × (α + β × m/P)大消息,节点间 IB/RoCE
Recursive Halving-DoublingAllReduce2 × log₂P × (α + β × m)中消息,节点内 NVLink
Ring AllGatherAllGather(P-1) × (α + β × m/P)TP 激活同步
All-to-All (Personalized)All-to-Allα + β × m (每对)EP 负载重分配
Send/RecvP2Pα + β × mPP 阶段间传输

Key Insight:环形 AllReduce 的带宽利用率为 O(1/(P-1))——节点越多,单个节点分摊的消息量越小,但总轮次增加。当 P 很大时,启动延迟 α 成为瓶颈。

拓扑无关的通信建模(Universal Perf Model 方法)

这是当前最实用的工程方案。核心观察:无论通信操作类型和拓扑如何,带宽-消息大小曲线永远划分为三个区域

     带宽
     ↑
饱和区│ ───────────────────────────── BW_max
     │                              /
过渡区│                         /
     │                    /   (sigmoid 拟合)
     │               /
小消息区│─────── (启动延迟主导,带宽线性增长)
     │
     └──────────────────────────────────→ 消息大小 m
          m₁           m₂
    
T_comm = {
  t_s                      (m ≤ m₁)             小消息:启动延迟主导
  f(m, sigmoid_params)     (m₁ < m < m₂)        过渡区:sigmoid 拟合
  t_s + m / BW_max         (m ≥ m₂)             饱和区:带宽瓶颈
}

这一方法的优势:拓扑无关——同一公式适用于 NVLink、PCIe、InfiniBand、Ethernet,只需重新拟合 8 个参数。Universal Perf Model 用此方法在 DLRM 上达到 5.21% 误差,在 NLP 上达到 3.00% 误差。

层次化网络仿真:ASTRA-sim 2.0 方法论

ASTRA-sim 2.0 (ISPASS 2023) 是目前最全面的分布式训练网络仿真框架:

用户输入 (模型 + 并行策略 + 网络拓扑 + 内存层次)
          │
          ▼
┌─────────────────────────────────────────────┐
│  ASTRA-sim 2.0                               │
│                                              │
│  1. Graph-based Training-Loop                │
│     → 支持任意模型并行策略组合 (DP×TP×PP×SP×EP) │
│                                              │
│  2. Multi-dimensional Heterogeneous Topology │
│     → 参数化拓扑生成 (节点内 NVLink → 机架     │
│        Leaf-Spine → 集群 Core)               │
│     → 每层带宽/延迟独立配置                    │
│                                              │
│  3. Advanced Memory System                   │
│     → 解聚化内存 (CXL-based disaggregation)  │
│     → In-network collective modeling         │
│                                              │
│  4. Analytical Performance Model             │
│     → 每维度 bandwith + latency 解析估算      │
└─────────────────────────────────────────────┘
          │
          ▼
输出: per-iteration 延迟、通信-计算重叠分析

关键能力:支持 5 维层次化拓扑(GPU → NVSwitch → Node → Rack → Cluster),每维可独立配置带宽、延迟和协议。

互联性能建模的核心挑战

挑战说明当前最佳实践
多维层次拓扑节点内 NVLink + 节点间 IB/RoCE + 跨集群 WANASTRA-sim 2.0 参数化拓扑生成
计算-通信重叠ML 训练中计算与通信可流水线化Universal Perf Model 关键路径算法
网络拥塞多作业共享网络时的带宽竞争ATLAHS (htsim 包级仿真)
集合通信分解AllReduce 可拆分为 RS + AG,每段可调整 chunkThemis 动态 chunk 调度
通信草图合成用户只需描述意图,自动生成最优通信序列TACCL (OSDI 2022)
异构互联GPU-CPU/CXL/PIM 等新互联技术LLMServingSim 2.0 多层内存建模

经典文献

论文会议核心贡献
ASTRA-sim 2.0ISPASS 2023层次化网络建模 + 任意并行策略
ATLAHSarXiv 2025应用级网络仿真,GOAL 中间格式,<5% 误差
TACCLOSDI 2022通信草图→最优算法合成,比 NCCL 快 1.5-5×
ThemisISCA 2022多维带宽感知的 Collective 调度,95% 利用率
Universal Perf ModelarXiv 2024拓扑无关的 sigmoid 通信建模
GenZarXiv 2024AllReduce/All-to-All/AllGather 解析建模
LogGOPSim经典消息级网络仿真,支持大规模

3.7 负载建模(Workload Modeling)

核心问题:性能仿真需要知道”系统在处理什么样的输入”。负载建模的目标是准确刻画真实生产环境中的请求到达模式、特征分布和动态行为

请求到达模型

模型描述适用场景局限
Poisson 过程间隔时间指数分布,无记忆性稳态在线服务无法模拟突发流量
Geometric / ON-OFF 模型突发和非突发状态交替聊天应用参数需从 trace 拟合
Markov Arrival Process (MAP)多状态转移矩阵复杂流量模式参数估计困难
实际 Trace 回放录制真实请求序列生产系统验证数据获取受限
Generative 模型GAN/Diffusion 合成 trace无 IP 泄露的风险场景合成质量依赖训练数据

Poisson 过程为什么仍是默认选择

  • 对于中低负载率(系统容量 <70%),Poisson 足以捕捉核心性能趋势
  • 所有仿真器(Vidur、LLMServingSim、甚至工业界 capacity planning)都默认使用 Poisson
  • 性能差异往往在高负载点(>85% 利用率)才显著,此时排队效应的非线性涌现比到达分布细节更重要

请求特征分布建模

LLM 推理请求的五个关键特征维度:

特征典型分布对性能的影响
Prompt 长度 (prefill tokens)幂律 / 长尾(均值 ~500-1000,P99 ~4K-32K)决定 prefill 阶段算力需求
生成长度 (decode tokens)几何分布或幂律(均值 ~200-1500,P99 ~2K-8K)决定 KV Cache 占用和 decode 阶段负载
请求到达率 QPS日间波动的泊松过程系统负载率和排队延迟
批量汇聚度 (burst factor)突发间静默期长尾分布SLO 违例的主因
前缀共享率长对话中系统提示词占比高Prefix Caching 命中率决定

三大经典工作负载 Trace(来自 Vidur-Bench):

1. LMSys-Chat-1M (对话型)
   短 prefill (均值 686 token),短 decode (均值 197 token)
   高 P:D ratio (2.3) → 计算密集

2. Arxiv-Summarization (摘要型)
   长 prefill (均值 2588 token),短 decode (均值 291 token)
   极高 P:D ratio (15.7) → prefill 主导

3. Bilingual-Web-Book (翻译型)
   中等 prefill (均值 1067 token),极长 decode (均值 1612 token)
   低 P:D ratio (0.65) → decode/KV Cache 主导

关键洞察:同样一个模型在不同工作负载上,最优部署配置可能完全不同(Vidur 发现差异最多可达 2× 成本)。因此负载感知的配置优化应成为生产部署的标准实践。

Workload Trace 采集与合成

真实 Trace 采集

方法工具数据内容
请求日志Nginx / vLLM metrics到达时间、prompt/decode 长度、SLO 满足状态
Profiling TracePyTorch Profiler + CUPTI算子级执行时间、内存占用
系统级 TraceNsight SystemsGPU 流活动、NCCL 通信信息

合成 Trace 生成(适用于 IP 受限场景,来自 Chakra):

Chakra 合成轨迹方法论:
  1. 从 N 条真实轨迹提取统计特征
  2. 将 N 轨迹压缩为一条"主轨迹" (无损重构)
  3. 分层生成模型:
     通信类型生成器 → 消息大小生成器 (GMM 拟合) → 依赖关系建模
  4. 输出合成的 Execution Trace (保留分布特征,混淆原始数据)

负载的动态行为建模

排队模型与 SLO 分析(系统级性能的核心基础之一):

Single-server queue (M/G/1):
  T_response = T_service + T_queue
  T_queue = (λ · E[S²]) / (2 · (1 - ρ))
  
其中:
  λ = 请求到达率
  E[S²] = 服务时间的二阶矩
  ρ = λ · E[S] = 负载率 (utilization)

三个关键动态效应

  1. 突发-队列级联:短时突发 → 队列累积 → 排队延迟爆发 → SLO 违例

    • 这是为什么真实系统不能运行在 >85% 利用率的原因
    • 仿真中捕获这一效应需要事件驱动而非静态分析
  2. 冷启动效应:新部署系统前缀缓存为空 → 前几个请求的 prefill 延迟显著更高

    • Vidur 的 Poisson 到达模型中,初始阶段的 TTFT 往往偏移
  3. 吞吐-延迟拐点:系统在某个负载率附近出现突然的性能下降

    • 这一拐点位置取决于 KV Cache 容量、调度策略、batch size 的联合作用
    • 这是仿真最重要的预测输出之一(capacity planning 的决策基础)

多租户负载混合建模

LLM 推理服务中日益常见的场景:同一 GPU 集群同时服务多个模型、多个客户

负载混合类型建模挑战代表工作
同模型多客户KV Cache 隔离/共享策略GORGO/KVShare, Oneiros
多模型混合GPU 时间片分配、模型切换开销LLMServingSim 2.0 Multi-MSG
训练+推理混合GPU 资源竞争(不同优先级)开放问题

经典文献

论文年份核心贡献
Vidur-Bench2024三类标准负载+评估指标集
ShareGPT / Arxiv Trace2023-2024实际 LLM 请求分布公开数据
LMSys-Chat-1M2024最大规模开源对话请求 trace
Chakra Generative Trace2023生成式 AI 合成执行轨迹
GORGO / KVShare2025多租户 KV Cache 共享调度
Mooncake2024生产级 KV-centric 分离式推理负载
AIConfigurator2026框架无关的负载感知配置优化 (30s 搜索)

四、三域并置:芯片级 / 训练系统 / 推理系统

4.1 宏观关系

性能建模与仿真按抽象层次可分为三个域:

芯片级仿真          训练系统仿真          推理系统仿真
(周期精确)          (迭代级/Op 级)       (请求级/Token 级)
│                    │                    │
▼                    ▼                    ▼
gem5, Accel-Sim     Chakra, ATLAHS       Vidur, LLMServingSim
SCALE-Sim, MAESTRO  Universal Perf Model GenZ, LLM-Emu, APEX
Ramulator, McPAT    Pollux, Gavel        Splitwise, Mooncake
│                    │                    │
└────────────────────┼────────────────────┘
                     ▼
        共同构成芯片→系统的完整设计验证链

4.2 各域核心挑战对比

维度芯片级训练系统推理系统
建模粒度周期级/指令级迭代级/算子级请求级/token 级
仿真对象Pipeline/Cache/NoC计算-通信重叠调度-排队-KV Cache
核心瓶颈微架构设计通信 vs 计算显存带宽 vs 计算
动态性低(指令流确定)中(负载均衡)(动态 batching)
典型速度1-50 KIPS分钟级秒-分钟级
精度10-25%3-15%0.95-14.7%
成熟度★★★★★(30+ 年)★★★☆☆(薄弱)★★★★☆(快速成熟)

4.3 关键空白与趋势

训练系统仿真严重落后于推理系统

推理已有:
  - GenZ: 5.82% 误差 (30ms)
  - LLMServingSim 2.0: 0.95% 误差 (10min)
  - Vidur: 600+ GitHub Stars
  - LLM-Emu: <5% 误差 (Online Emulation)

训练尚缺:
  - 无类似 Vidur 的开源端到端训练仿真器
  - Chakra 提供 Trace 格式但缺少完整仿真器
  - ATLAHS 侧重网络,未覆盖计算
  - 3D 并行建模仍是开放问题

跨层融合趋势

  • LLMServingSim 2.0 已经融合了芯片级(加速器建模)+ 系统级(ASTRA-sim)
  • 未来方向:统一的芯片→系统多层级仿真框架

五、经典论文全景导览

5.1 必读基础(每个新员工的首选)

#论文年份为什么必读
1Roofline Model (CACM)2009性能建模的”第一性原理”,理解计算/内存瓶颈的本质
2Roofline 扩展 (Cache-aware)2014将缓存层次引入 Roofline 分析
3GPGPU-Sim (MICRO)2009GPU 周期精确仿真的奠基之作,理解 GPU 微架构建模
4McPAT (MICRO)2008功耗建模的经典框架,理解功耗-性能联合优化

5.2 芯片级建模

#论文会议/年份核心贡献
5gem5ISCA 2011最广泛使用的开源全系统 CPU 仿真器
6Accel-SimMICRO 2020功能-时序解耦 GPU 仿真,<10% 误差
7SCALE-SimISPASS 2020脉动阵列开源周期精确仿真器
8MAESTROHPCA 2018DNN 数据流建模,数据重用距离理论
9Ramulator 2.0CAL 2023模块化 DRAM 仿真器,~500 kHz 速度
10IthemalMICRO 2018ML 预测指令吞吐,<10% 误差
11TimelooparXiv 2019DNN 加速器映射搜索(与 MAESTRO 互补)
12SimPointMICRO 2002仿真加速:选取代表性代码片段

5.3 训练系统建模

#论文会议/年份核心贡献
13Universal Perf ModelarXiv 2024多 GPU 训练通用性能模型,3-5% 误差
14ChakraHotOS 2023标准化执行 Trace 格式,AI 合成轨迹
15ATLAHSarXiv 2025AI/HPC/存储网络模拟器
16PolluxOSDI 2021Goodput 优化的集群调度,WS 二参数模型
17GavelOSDI 2020异构加速器性能模型驱动的调度
18ThemisE2DC 2021带宽感知 Collective 调度
19NeuSightASPLOS 2025GPU 性能预测(跨代跨厂商,2.3% 误差)
20DLRM Perf ModelISPASS 2022推荐系统首个解析式训练性能模型
21瞬时云训练建模ICAC 2020抢占式实例的收敛时间-成本权衡

5.4 推理系统建模

#论文会议/年份核心贡献
22GenZarXiv 2024解析式 Roofline LLM 分析,5.82% 误差
23VidurMLSys 2025算子三分类仿真框架,<9% 误差,598⭐
24LLMServingSim 1.0IISWC 2024迭代级 HW/SW 协同仿真
25LLMServingSim 2.0arXiv 2026异构+解聚统一建模,0.95% 误差
26LLM-EmuarXiv 2026Profile-driven 在线仿真,<5% 误差
27FrontierarXiv 2025精细化算子仿真,支持 MoE
28APEXarXiv 2024动态感知并行策略搜索
29SplitwisearXiv 2023Prefill/Decode 分离奠基
30MooncakeFAST 2025KV-centric 分离式推理(Best Paper)
31Sarathi-ServearXiv 2024Chunked-prefill 调度
32FlexGenarXiv 2023KV Cache 卸载性能模型(IO-aware 调度)

5.5 缓存系统建模

#论文/工具年份核心贡献
33vLLM/PagedAttention2023KV Cache 分页化管理,消除内部碎片
34H2O2023Heavy-Hitter Oracle 逐出策略
35ScissorHands2023”重要性持续性”假设的 KV Cache 逐出
36KVTuner2025层级别混合精度 KV Cache 量化
37MicroRec2020推荐系统推理的 Codebook Cache
38GORGO/KVShare2025跨用户 KV Cache 共享

六、工具链推荐

6.1 按角色推荐

角色推荐学习顺序
芯片架构师Roofline → MAESTRO+Timeloop → SCALE-Sim → gem5 (CPU) / Accel-Sim (GPU) → McPAT (功耗)
推理系统工程师Roofline → GenZ (快速 DSE) → Vidur (配置搜索) → LLMServingSim 2.0 (精确验证) → LLM-Emu (Online Emulation)
训练系统工程师Chakra (Trace 格式) → Universal Perf Model (解析模型) → ATLAHS (网络) → Pollux (调度)
算法研究员Roofline → GenZ (模型-硬件匹配) → NeuSight (跨 GPU 预测) → LLM-Emu (无 GPU SLO 验证)
推荐系统工程师DLRM Perf Model → MicroRec → Merlin HugeCTR
系统研究者全栈:芯片级 (gem5) → 训练 (Chakra) → 推理 (Vidur + LLMServingSim + LLM-Emu) → 调度 (Pollux)

6.2 仿真器工具链示意图

                ┌─────────────────────────────────┐
                │        Roofline 模型             │
                │  (瓶颈初筛,微秒级决策)           │
                └────────────────┬────────────────┘
                                │
            ┌───────────────────┼───────────────────┐
            ▼                   ▼                   ▼
    ┌───────────────┐   ┌───────────────┐   ┌───────────────┐
    │  芯片级仿真    │   │  训练系统仿真  │   │  推理系统仿真  │
    │               │   │               │   │               │
    │ gem5 (CPU)    │   │ Chakra +      │   │ GenZ (解析)   │
    │ Accel-Sim(GPU)│   │ ASTRA-sim     │   │ Vidur (仿真)  │
    │ SCALE-Sim(NPU)│   │ ATLAHS (网络) │   │ LLMServingSim │
    │ Ramulator(DDR)│   │ Pollux (调度) │   │ LLM-Emu (在线)│
    │ McPAT (功耗)  │   │               │   │ APEX (搜索)   │
    └───────────────┘   └───────────────┘   └───────────────┘
                                │
                    ┌───────────┴───────────┐
                    ▼                       ▼
            ┌───────────────┐       ┌───────────────┐
            │  缓存系统建模  │       │  推荐系统建模  │
            │  H2O, KVTuner │       │  DLRM Perf    │
            │  FlexGen,     │       │  MicroRec     │
            │  PagedAttn    │       │  Merlin/HugeCTR│
            └───────────────┘       └───────────────┘

七、学习路径建议

第一阶段:夯实基础(1-2 周)

  1. 阅读 Roofline Model 原文(CACM 2009)— 理解计算 vs 内存瓶颈
  2. 动手使用 Nsight / PyTorch Profiler — 真实 profiling 体验
  3. 阅读知识库综述
    • [芯片性能建模与仿真深度综述]
    • [LLM推理系统深度综述]
    • [训练系统性能建模仿真综述]

第二阶段:掌握方法论(2-3 周)

  1. 理解解析模型:阅读 GenZ 和 Universal Perf Model
  2. 理解 Profile-driven 方法:阅读 Vidur 和 LLMServingSim 2.0
  3. 理解 ML 方法:阅读 NeuSight 和 Ithemal
  4. 理解调度建模:阅读 Pollux 和 Gavel

第三阶段:动手实践(2-4 周)

  1. 试用开源工具
    • 运行 GenZ-LLM-Analyzer(30ms 前向传播)
    • 尝试 Vidur 仿真(GitHub 598⭐)
    • 体验 LLM-Emu(无 GPU 运行 vLLM)
  2. 搭建自己的小型仿真:选择一个模型(如 LLaMA-7B),profile 几个算子,构建简单的延迟预测模型

第四阶段:深入方向(持续)

  1. 根据工作方向深入
    • 芯片设计:gem5 + Accel-Sim + SCALE-Sim
    • 推理系统:Vidur + LLMServingSim 2.0 + LLM-Emu
    • 训练系统:Chakra + Universal Perf Model + ATLAHS

八、核心思维法则

法则 1:精度 vs 速度的帕累托前沿

没有免费的午餐。更高精度必然付出更慢速度或更复杂的代价。关键是找到问题的精度需求拐点——对于配置搜索,知道”配置 A 比配置 B 好”可能就足够了,不需要精确的绝对性能值。

法则 2:Always Profile First

不要猜测性能瓶颈,要测量它们。任何建模工作的第一步都是在真实硬件或已有仿真器上 profiling,获取数据驱动的洞察。Roofline 模型的价值就在于此——它帮你在建模之前先确定瓶颈在哪里。

法则 3:领域知识 + ML > 纯 ML

NeuSight 已经证明了这一点:纯 ML 方法在未见 GPU 上误差高达 724%,而加入”tile 执行 + 性能定律约束”的领域知识后,误差降至 2.3%。领域知识是 ML 泛化能力的关键保障

法则 4:模型的价值在于决策

性能建模的最终目标不是预测数值,而是辅助决策

  • 芯片架构师:这个缓存大小是否合理?
  • 部署工程师:用 A100 还是 H100?
  • 调度器:这个 job 分 4 个 GPU 还是 8 个 GPU?
  • 算法研究员:MoE 用 64 个专家还是 128 个专家?

评价模型好坏的最终标准是:它帮助做出的决策是否正确?

法则 5:从简单开始,逐步复杂

不要一开始就搭建 gem5 全系统仿真器!
正确的路径:
  Step 1: Roofline 分析 → 确定瓶颈方向 (5 分钟)
  Step 2: 解析模型 -> 快速估算数量级 (1 小时)
  Step 3: Profile-driven 方法 → 精细建模 (1 天)
  Step 4: 周期精确仿真 → 验证关键配置 (1 周)

九、结语

性能建模与仿真是一个”跨层次”的领域——从芯片的微架构门级到数据中心规模的集群调度,每一层都有自己独特的方法论和工具。但贯穿始终的核心理念只有一个:

用低成本的计算替代高成本的实验

当前这个领域正处在快速演进的阶段:

  • 芯片级:已经非常成熟(30+ 年积累)
  • 推理系统:快速成熟中(Vidur, LLMServingSim 2.0 达到 <1-9% 精度)
  • 训练系统:尚处早期,缺少端到端仿真框架

下一个突破口:训练系统端到端仿真、跨层融合建模、AI-native 仿真器(如 NeuSight 式的 ML+物理约束混合方法)。

希望这份导论能为你的性能建模之旅提供一个系统化的起点。


相关笔记