总览
围绕"做一个 cycle-approximate 级 AI 芯片 perf model(G5 建模)"展开:覆盖哪些资源域、用哪些精度档、怎么标定、何时升降档
核心要点:
- 本章目标是为构建一个 SystemC AT 级(cycle-approximate)的 AI 芯片 perf model(下称 G5 建模)提供概念骨架
- 主轴是资源域(compute / memory / interconnect / scheduler-as-workload),不是时间尺度
- 每个资源域内有 analytical → trace-replay → event-driven → cycle-approx 的精度谱系
- 业界主流 perf model 之间通过标定依赖互相喂养,真实结构是有向图而非分层堆叠
- SystemC AT(cycle-approx)跑不动 LLM 端到端,必须与上层 event-driven 模型分层协作
名词定义
| 名词 | 定义 |
|---|---|
| G5 建模 | 借 gem5 思想做 SystemC AT 级(cycle-approximate)的 AI 芯片 perf model,workload 为 LLM 推理 |
| perf model | 性能模型,关心延迟 / 吞吐 / 资源占用,必须建立在功能正确性上 |
| cmodel(功能模型) | bit-accurate 不带时序,与 perf model 正交关系 |
| SystemC AT | SystemC 的 Approximately-Timed 抽象级,cycle 近似,业界俗称 CA model |
| 资源域 | 被建模的硬件 / 系统资源类别,本章主轴 |
| 抽象层级 | 同一资源域内的建模精度档 |
| 标定依赖 | 一个 perf model 的参数由另一档实测或仿真产出 |
本章组织
主轴是资源域。计算 / 内存 / 互联 / scheduler 是被建模系统的本体维度,时间尺度(cycle / op / request)和精度档(analytical / DES / CA)是描述每个资源域的方式,不作为主轴。这避免了"把仿真器跑多快"误认为"建模对象的结构"。
每个资源域内,讨论它在 analytical → trace-replay → event-driven → cycle-approx 四档精度上各有什么建模手段、什么取舍、怎么标定。SystemC AT 是 cycle-approx 档的实现选择,只是谱系的一个点,不是 survey 的唯一锁定目标。
横切轴(workload spec / 验证 / 设计空间探索 / lifecycle)贯穿所有资源域,各篇引用,不单列。
建模精度阶梯
按"模拟一秒真实硬件需要多久 / 误差能压到多少 / 标定难度"三轴排,所有 LLM 推理 perf model 工具落在这条阶梯上:
| 档 | 代表工具 | 相对实时速度 | 绝对误差 | 标定难度 | 典型用途 |
|---|---|---|---|---|---|
| analytical(解析) | roofline、GenZ、Calculon | $10^6\times$ | $\pm 10\text{--}30\%$ | 低(datasheet + η) | 设计空间快速扫描 |
| trace-replay | profile-based 查表 | $10^5\times$ | $\pm 5\text{--}15\%$ | 中(需真机 trace) | 已上线硬件的部署评估 |
| event-driven | ASTRA-sim、Vidur | $10^3\text{--}10^4\times$ | $\pm 5\text{--}15\%$ | 中 | 端到端时序 / 并行策略评估 |
| cycle-approx(CA) | gem5、SystemC AT、G5 建模 | $10^0\text{--}10^2\times$ | $\pm 5\text{--}10\%$ | 高(microarch 参数) | 微架构探索 / kernel 级标定 |
| cycle-accurate(严格) | RTL sim(Verilator / VCS) | $10^{-3}\text{--}10^{-1}\times$ | $\pm 0\text{--}2\%$ | 最高 | RTL 验证 |
| functional(cmodel) | QEMU、Spike、ISS | $10^4\text{--}10^6\times$ | 不算时序 | 低 | 软件 bring-up |
@tbl-ipm-precision-ladder 建模精度阶梯与典型工具
每升一档,速度下降 10–1000 倍、标定难度跳一档,但绝对误差只小一档——这是体系结构仿真过去二十年的核心矛盾。任何 perf model 都在这条阶梯上选一个点(或几个点的组合),取舍由用途决定。
G5 建模锁在 cycle-approx 档。但 cycle-approx 单芯片 $10^9$ 指令量级一次 GEMM 仍需分钟到小时,$10^{12}$ 指令一次 prefill 物理上跑不动,所以必须与上层 event-driven 模型分层协作:cycle-approx 跑代表性 kernel 标定时间与资源画像,event-driven 用这些标量算端到端。
功能模型与性能模型的关系
容易混淆,提前澄清:正交关系,不是阶梯上下级。
| 维度 | 功能模型(cmodel) | 性能模型(perf model) |
|---|---|---|
| 关心 | 输出值是否正确 | 算多久 / 占多少资源 |
| 是否带时序 | 否 | 是 |
| 输出 | 输出张量 | 时序 / 吞吐 / 能耗 |
| 速度 | 极快 | 慢得多 |
| 用途 | 软件 bring-up、RTL 验证 | 架构探索、瓶颈分析 |
任何 perf model 隐含一个功能模型(必须知道指令算什么才能算它多久),因此 perf 是 functional 的超集。许多项目共享前端(ISA 解码、算子定义、内存抽象)分叉后端,gem5 的 AtomicSimpleCPU 和 O3CPU 即此结构。G5 建模同样需要考虑功能层的复用。
主流 perf model 的范式有向图
业界 LLM perf model 不是孤立点,而是通过标定依赖互相喂养的有向图。理解这个图比记住单个工具更重要——它决定了 G5 建模在生态里的位置:
边的含义:箭头表示"上游产出可被下游消费作为参数"。例如 Calculon 的算子时长闭式可喂给 ASTRA-sim 做端到端时序;profile-based 真机查表也能喂给同一位置;G5 / SystemC AT 反过来为算子级 DES 提升 kernel 级精度——它本身不做端到端,但提供"一个 kernel 多少 cycle"这个标量。
对 G5 建模的含义:它不是要替代 ASTRA-sim / Vidur,而是给它们提供更准的 compute / memory / interconnect 标定。设计 G5 建模时,输出格式必须可被上层算子级 DES 消费——这是"分层协作"的具体含义。
资源域 × 抽象层级矩阵
主轴(资源域)与副轴(抽象层级谱系)交叉,每格说明该资源域在该精度档的典型建模手段:
| 资源域 | analytical | trace-replay | event-driven | cycle-approx(G5 落点) |
|---|---|---|---|---|
| Compute | roofline + 效率因子 η | kernel 时间查表 | 算子级时长事件 | PE 阵列脉动节拍 / tile 调度 / SIMD 流水 |
| Memory | 带宽 roofline | profile 实测带宽 | KV cache 字节预算 + DMA 事件 | bank 冲突 / HBM ctrl 队列 / cache 命中 |
| Interconnect | alpha-beta + 集合通信闭式 | 集合通信实测查表 | 拓扑感知事件 | flit 级 NoC + c2c + router 仲裁 |
| Scheduler-as-workload | 排队论闭式 | 生产 trace 回放 | 请求级 DES(Vidur 内核) | 不在此档(作为 trace 输入接入上层) |
@tbl-ipm-domain-level-matrix 资源域与抽象层级的建模手段矩阵
Scheduler-as-workload 的特殊性:continuous batching / 请求分布 / PD 分离是被建模对象而非建模方法——它们作为 workload 生成器驱动其他三个域的建模,排队论是分析工具。所以 cycle-approx 档对它无意义,它在上层以 trace 形式喂入。
升降档判据
何时该升档(更准更慢)、何时该降档(更快更糙)?三条 cost-precision 准则:
- 目的导向:回答"哪个并行策略更快"用 analytical 够;回答"PE 配比改了怎样"必须升到 cycle-approx——精度需求由问题决定,不由"我能跑多准"决定。
- 关键路径精细,其余粗放:在 cycle-approx 仿真里,不是所有单元都同档。compute pipeline 走 cycle-approx,DRAM 控制器走 queue-based,NoC 走 flit 级——混合精度比统一精度有效得多。
- 标定数据决定上限:再细的模型也只能精确到标定数据允许的程度。datasheet 给的峰值有 ±10% 不确定性,模型再准也压不过这条线——除非自己测。
这三条判据贯穿后续各篇,具体应用见 08-标定 / 验证 / DSE。
子文档索引
| 篇 | 主题 | 状态 |
|---|---|---|
| 02-Compute 资源域 | 从 roofline 到 PE 阵列 CA 的谱系 | 待重写(现 8.2 Compute 资源域) |
| 03-Memory 资源域 | KV cache / bank 冲突 / HBM 控制器 / DMA 的谱系 | 待重写(现 8.3 Memory 资源域) |
| 04-Interconnect 资源域 | 片内 NoC + 片间 c2c + 拓扑路由 + 集合通信的谱系,自包含 | 待重写(现 8.4 Interconnect 资源域) |
| 05-Scheduler-as-workload | continuous batching / 请求分布 / PD 分离作为 workload 输入 | 待写 |
| 06-输入模式与 workload spec | trace-driven vs generative,采集 / 合成 / 混合 | 待写 |
| 07-多目标与异构 | Pareto 输出、异构 die / chiplet 建模 | 待写 |
| 08-标定 / 验证 / DSE | 各档标定方法、对标三要素、设计空间探索 | 待重写(现 8.7 建模精度与验证) |
| 09-G5 落地示例 | SystemC AT 在三域的具体选择、与上层算子级 DES 的耦合接口 | 待写 |
旧的 8.5 Scheduler-as-workload、8.6 输入模式与 Workload Spec 内容将拆分并入新结构(端到端时序进 02 / 03 / 04 各域,请求级建模进新 05)。
与硬件互联章节的关系
互联的底层机制(拓扑形态、路由算法、拥塞控制、死锁避免)有专门章节深入讲。本章 04 Interconnect 资源域按你的指定自包含重写,聚焦"互联机制如何作为 perf model 输入"——拓扑感知 α / β 怎么标、集合通信延迟闭式怎么用、片间链路在 cycle-approx 档怎么建——不指向硬件互联章。
开放问题
- L4 部署系统层是否预留接口:多集群 / 容错 / 扩缩属于 SRE 范畴,本章不进主线,但 G5 建模未来若扩到部署仿真需预留接口
- 9 篇是否仍偏多:06 输入模式与 07 多目标 / 异构内容量待写时再判合并可能性
- G5 落地示例的颗粒度:09 写概念还是写具体 SystemC class 设计示意,待 02–08 完成后定
维护信息
最后更新:2026-06-18。九篇规划已定,01 总览按资源域主轴 + 范式有向图重写完成,02–09 待按规划逐篇重写或新写。