3. 建模方法论：四种模型的适用场景
做性能建模这么多年，我最大的体会就是：没有万能模型。
你想想看，一个加速器从概念到流片，不同阶段需要回答的问题完全不同。早期你可能只想知道「这个架构能不能跑到1TOPS」，到了后期你得精确到「每拍时钟能处理几个像素」。
所以，建模方法论说白了就是在正确的时间用正确的工具。我个人习惯把模型分成四类：分析模型、模拟模型、经验模型、混合模型。今天咱们就聊聊它们各自的脾气秉性。
核心观点：模型的选择本质是精度与速度的权衡。没有最好的模型，只有最合适的模型。
3.1 分析模型：快，但别太当真
分析模型，就是用数学公式来描述系统行为。比如计算一个卷积层的延迟：
Latency = (H × W × C_in × K_h × K_w × C_out) / (MAC_units × Frequency)这种模型我用的最多的时候是在架构探索阶段。那时候参数还没定，你只需要知道「把MAC阵列从128改成256，吞吐能翻倍」这种趋势性结论。
适用场景：
- 早期设计空间探索（几十个参数组合快速筛选）
- 系统瓶颈的粗略定位（比如发现DDR带宽是天花板）
- 学术论文中的理论分析
我的经验：分析模型最适合回答「如果...会怎样」这类问题。我曾经用分析模型在半天内评估了20种不同的数据复用策略，最终锁定了最优方案。模拟模型的话，一周都跑不完。
但要注意：分析模型假设太多。比如它假设内存访问没有冲突，假设数据流完全理想。实际硬件中，这些假设往往不成立。
避坑指南：我曾经犯过一个错误——用分析模型预测的延迟和实际RTL仿真差了40%。原因是我没考虑bank冲突导致的内存stall。所以记住：分析模型看趋势，别信绝对值。
3.2 模拟模型：准，但慢得让人抓狂
模拟模型，就是搭一个软件版的硬件。比如用SystemC写一个cycle-accurate的加速器模型，每个时钟周期都模拟一遍。
这种模型精度最高，但速度也最慢。我记得有一次跑一个ResNet-50的模拟，整整跑了三天三夜。
适用场景：
- 设计验证阶段（需要精确到cycle的时序）
- 微架构优化（比如比较两种调度策略的优劣）
- 软硬件协同验证（跑真实workload）
模拟模型又分几个层次：
| 层次 | 精度 | 速度 | 典型工具 |
|---|---|---|---|
| 功能模型 | 低（只关心对不对） | 快 | Python/C++ |
| 时序模型 | 中（近似周期数） | 中 | SystemC TLM |
| Cycle-Accurate | 高（精确到每个cycle） | 慢 | SystemC RTL |
我的建议：别一上来就搞cycle-accurate。先问自己：我真的需要每个cycle都精确吗？很多时候，时序模型就够用了。我一般先用功能模型验证算法正确性，再用时序模型评估性能，最后才上cycle-accurate做精细调优。
3.3 经验模型：老司机的直觉
经验模型，说白了就是基于历史数据总结出来的规律。比如「DDR带宽利用率一般在60%-70%之间」，这就是经验。
这种模型听起来不「科学」，但实际工作中特别有用。尤其是当你面对一个全新的架构，没有现成的分析公式，也没有模拟器的时候。
适用场景：
- 快速估算（比如「这个设计大概需要多少面积」）
- 缺乏详细设计参数时
- 作为其他模型的校准基准
举个例子，我做过一个NPU项目，早期没有RTL代码，但需要给客户报性能。我就根据之前三个项目的经验，总结了一个公式：
实际吞吐 = 理论峰值 × 0.7 × (1 - 0.1 × 稀疏度)这个0.7就是经验系数。后来RTL仿真出来，误差在5%以内。
注意：经验模型不能外推。你基于28nm工艺总结的经验，到了7nm可能完全不适用。我曾经吃过这个亏——用老工艺的经验去估算新工艺的功耗，结果差了2倍。
3.4 混合模型：取长补短
实际项目中，我很少只用一种模型。更多时候是混合使用。
比如我最近做的一个视频编解码加速器项目：
- 用分析模型快速筛选了10种不同的流水线结构
- 选出3种候选后，用时序模拟模型做详细评估
- 最后用cycle-accurate模型验证关键路径
- 过程中用经验模型校准参数（比如内存延迟的分布）
这种混合策略的好处是：在关键路径上花时间，在非关键路径上省时间。
我的经验法则：
- 80%的设计空间用分析模型探索
- 15%的候选方案用模拟模型验证
- 5%的关键模块用cycle-accurate模型精调
3.5 如何选择？一张图说清楚
下面这张图总结了我对四种模型的理解。它展示了精度、速度和适用阶段的关系：
嗯，这张图其实想表达一个意思：从左下到右上，精度在提升，但代价是时间和投入也在增加。混合模型之所以在中间，是因为它试图在两者之间找到平衡点。
3.6 我的选择框架
最后，分享一个我实际工作中用的决策框架。当你面对一个建模任务时，问自己三个问题：
- 我需要多高的精度？（趋势性结论就够了，还是需要cycle精确？）
- 我有多长时间？（明天就要出结果，还是可以跑一周？）
- 我有什么数据？（有RTL代码吗？有历史项目数据吗？）
根据答案，你大概就能判断该用哪种模型了。我个人习惯是：能用分析模型解决的问题，绝不动模拟器。因为时间才是最宝贵的资源。
一个小技巧：如果你不确定该用哪种模型，先花10分钟写一个分析模型。如果分析模型给出的结论已经足够你做决策，那就没必要往下走了。如果分析模型说「不确定」，再上模拟模型也不迟。
好了，关于四种模型的适用场景，今天就聊到这儿。记住：模型是工具，不是目的。别为了建模而建模，你的目标是回答那个核心问题——这个加速器，到底能不能达到性能目标？