做了十多年GPU相关工作经常有朋友拿着芯片发布新闻来问我“这代GPU是不是新一代微架构”其实这是个很难回答的问题。因为“新”有很多种改个名字叫新加几个硬件单元也叫新真正能称之为“一代新微架构”的必须是在微架构层面做出了结构性改变并且用仿真和实测数据证明这种改变带来了质的提升。今天这篇文章我想从GPU仿真和微架构设计者的视角把“什么才算一代新微架构”这个问题彻底拆开聊清楚背后的判断标准、设计方法论和仿真验证过程。如果你正准备入手GPU架构方面的研究或开发这篇文章可以给你一个比较清晰的起点。1. 什么才算一代新GPU微架构1.1 快速重温微架构与指令集的区别聊GPU微架构之前得先把“微架构”和“指令集架构ISA”这两个概念分清楚。指令集架构是程序员和编译器能看到的接口包括指令集、寄存器、内存模型、数据类型等。比如NVIDIA的PTX、AMD的CDNA指令集这些定义了你可以调用的指令、变量的存储方式、内核的调度模型。而微架构是硬件内部为了执行这些指令而采用的具体组织结构流水线怎么分、执行单元怎么排布、缓存层级怎么设计、调度器怎么分发指令、内存子系统如何并行。同一套指令集架构可以对应完全不同的微架构。以NVIDIA为例从Volta到Turing再从Ampere到Ada LovelaceCUDA指令集是向前兼容的但内部微架构变化很大。Volta开始引入Tensor CoreTuring增加了RT CoreAmpere改进了Tensor Core的稀疏化能力Ada Lovelace则大幅增强了光流与DLSS相关的硬件。这些改动都涉及核心计算结构的变化属于“代”的范畴。相比之下不同型号之间仅仅提高一下频率、加大一下L2缓存那就只能算是修修补补的“Refresh”算不上新一代。AMD那边也一样GCN到RDNA是微架构甚至半指令集级别的重设计。RDNA引入了wave32改变了wave64的执行调度方式这就不只是换了个名字而是SIMT执行模型层面的改道。这种改变是能直接影响底层性能和功耗特征的。1.2 我心中的三条“代际门槛”那么评价一个微架构是否有资格称得上“新一代”我通常看三条硬指标结构性创新不是调参而是硬件组织方式、执行模型、指令路径、内存层级发生了本质变化。比如从纯SIMT改为混合SIMTMIMD引入独立路径的专用算子单元重构缓存一致性协议等。非线性性能或能效跳跃在同代工艺、相近频率、相同功耗预算下综合性能IPC或吞吐量提升至少25%~30%以上能效比性能/瓦有类似幅度的提升。如果只有5%~10%那是日常优化超过30%往往意味着微架构有质变。开放新能力或新生态接口新增的硬件能力能否开通新的编程范式、新的编译路径、新的运行时特性。比如Tensor Core带火了CUDA的矩阵运算库RT Core让光线追踪走入了实时渲染。如果硬件改了但没有暴露编程接口只能在内部模块上受益那可能只是内部重构。这三条没有一条是孤立存在的。真实产品往往同时满足才敢在发布会上说自己“新一代”。所以我们在设计阶段就需要从一开始锁定这三条作为立项的验收标准。2. 面向工作负载的微架构需求拆解2.1 先找瓶颈再谈创新每一次微架构换代都不是凭空拍脑袋想出来的。以我参与过的一些GPU架构预研项目来看第一阶段永远是“找瓶颈”。怎么找用数据说话。先选几类目标工作负载。现代GPU早已不单是游戏渲染芯片AI推理、科学计算、光线追踪、视频编解码、大语言模型微调、云游戏等等每一类负载的脾性完全不同。比如大模型微调主要卡在矩阵乘法和显存带宽光追负载卡在BVH遍历和材质求交渲染负载卡在纹理访存和三角形光栅化。为了定位瓶颈我会同时用两层工具硬件计数器和Roofline模型。硬件计数器可以告诉你每个执行单元、寄存器文件、缓存端口、内存控制器的利用率是多少哪条路径排队严重哪些指令发射占用了大量流水线槽位。Roofline模型则从算力FLOPS和带宽两个维度画出理论性能上限再把实际运行点放在图里就能直观看出你的负载是“算力受限”还是“带宽受限”。2.2 从瓶颈推导架构目标假设我们从负载分析中发现了两个严重问题张量计算单元利用率很高但在稀疏场景下有一半的输入为零依然有大量时间在做“无效乘法”说明架构没有细粒度跳过零值的机制。对于小尺寸矩阵如4x4、8x8矩阵单元过宽反而浪费因为数据填充不满指令发射开销占比太高。那么“新一代”的目标可能就清晰了一方面要支持稀疏感知的数据路径另一方面要引入可变形状的矩阵运算指令。这个目标不是看别人做了什么我们跟着做而是从自己的工作负载行为曲线里“逼”出来的。有了目标才能开始做微架构的顶层设计也才能让后续仿真有明确的对照物。2.3 先建模画出版图级规划微架构设计在初期不一定需要直接去写RTL。我会先用高级语言或电子表格构建一个粗略的宏观模型估算每个新结构单元的面积和功耗预算。例如在40个SM流式多处理器里增加一组稀疏索引解析器面积大约增加25mm²按某制造工艺折算功耗约4W可承受但若每个SM再塞一个全速专用张量路径面积直接翻倍预算肯定是超的。这个阶段的价值在于快速排除不可行的狂想保留那些值得在周期级仿真器里验证的方案。GPU微架构的核心矛盾永远是面积、功耗、频率三者之间的取舍仿真阶段不考虑这些等RTL出来再发现超标就晚了。3. GPU仿真微架构设计验证的四大层次3.1 仿真层次怎么选GPU仿真在微架构设计中不是可有可无而是核心决策工具。我一般把它分成四个层次各有各的用场。第一层指令级/功能仿真。典型的如QEMU配合CUDA仿真二进制或者直接用编译器把kernel编译成主机代码执行。这种仿真只关心程序逻辑对不对不关心时钟周期。速度极快适合在架构方案还不稳定时快速验证新指令的语义、新数据类型的处理方式。第二层周期级架构仿真。这是微架构设计的重头戏。工具如gem5-gpu、gpgpu-sim它们会把一条条的GPU指令按微架构定义的流水线、缓存、调度器、内存控制器模拟到“周期”粒度。你可以修改硬件拓扑、调度策略、缓存容量、线程块调度方式然后跑一个benchmark统计出来的IPC、延迟、活跃线程数、显存带宽占用都很接近真实硬件。gpgpu-sim甚至支持用类似CUDA的代码跑应用。这种仿真精度中等速度慢一个量级但已经足以支撑微架构设计决策。第三层RTL仿真。这是把用Verilog、SystemVerilog或者Chisel写出的硬件设计放到仿真器里跑。RTL仿真能验证信号级时序、流水线握手、缓存一致性协议等比如验证新增的稀疏化硬件会不会和旧的存储请求冲突。但速度极慢跑几个时钟周期就是几秒钟所以只适合做功能验证不适合大规模性能评估。第四层物理设计阶段仿真。包括带寄生参数的网表仿真、时序分析、功耗分析。这个层次更多是后端环节但芯片能不能跑出目标频率、功耗墙高不高最后都得回到这个层面确认。这四个层次里周期级仿真在微架构创新验证中承担了最多的决策责任。因为它是唯一能在你还在“纸上谈兵”阶段就以合理的成本告诉你“这个设计行不行”的手段。3.2 周期级仿真器的搭建与校准很多人一上来就去改仿真器代码结果发现跑出来的数据严重偏离实际硬件。我踩过最大的坑就是没有校准。校准的意思是应该先在仿真器里建模一个“基线架构”——一个和上一代真实产品配置一致的仿真模型。然后把标准benchmark跑一遍对比真实芯片上测得的性能统计量比如IPC、cache命中率、L2带宽。如果偏差在5%以内这个基线就是可靠的如果偏差超过20%不要急着开始新设计先找仿真器的模型参数哪里不合理比如memory scheduling策略、branch divergence处理方式、cache替换策略等。只有基线校准可信之后我们修改微架构所得到的仿真结果才具备相对比较的意义。因为微架构研究最看重的是“相对上一代的提升”如果基线自己就是虚的那后面的所有对比都是空中楼阁。4. 在仿真器中微架构级别的实操改动4.1 典型场景为一个GPU核心加入稀疏Sparse加速单元说个具体的例子这也是我亲自做过的一个预研项目。当时的目标是让GPU在执行某些带有大量零值的神经网络卷积时能跳过无效乘加操作。从微架构角度需要动三块点指令集层面要新增一条“稀疏卷积”指令或者扩展现有指令的操作数编码数据通路层面稀疏张量以某种格式存储硬件需要额外的地址解析器和零值检测模块调度与寄存器需要增加一组寄存器来存放稀疏索引信息。在gpgpu-sim里做这种改动我会分四步走第一步先扩展指令描述。gpgpu-sim用类似ISA描述文件定义每条指令的操作数、执行单元类型、延迟。新增一个SPARSE_MM指令操作数包括两个矩阵地址、一个索引地址、输出地址。第二步改造执行流水线。稀疏加速单元挂在通用ALU旁路还是挂到Tensor Core路径上我偏向于扩展现有Tensor Core路径因为在同一个数据通路上便于复用矩阵乘法的累加网络。仿真器里我需要新增一个执行单元对象定义它的每个周期能处理多少个输入元素需要多少流水线级数。第三步修改内存请求生成逻辑。传统的矩阵加载是按块连续加载但稀疏格式需要按索引逐个地址取数。我写了一个非连续访存模型让仿真器能识别这类访问模式并统计它们对缓存和内存调度器的影响。第四步在benchmark里调用新指令。可以用PTX的近似模拟器接口或者写一段CUDA代码然后通过编译脚本生成仿真器可识别的指令流。这套改动大约花了两周时间。最终仿真结果显示在典型的ResNet-50稀疏卷积上端到端性能提升27%而片上缓存命中率下降了9%。为什么命中率反而下降因为随机稀疏索引带来的访存局部性变差。如果我们只看最终性能提升27%就觉得大功告成那就太天真了。这里必须权衡新增的稀疏路径需要额外加载索引访问模式不符合常规预取器这会在真实芯片上带来更高的功耗。所以我又跑了一组基于不同稀疏度60%、80%、50%的实验把访存开销和吞吐量画成曲线最后才敢拍板说“值得做”。4.2 性能仿真中经常被忽略的“分支发散”问题GPU是SIMT模型一条线程束warp里的32个线程理论上执行同一条指令。如果遇到if-else不同线程走不同分支那这个warp就必须串行执行两个分支这就是分支发散。在大规模并行计算中发散是性能杀手但在仿真阶段它往往被低估。我当年在仿真器里设计稀疏单元时就是没注意稀疏索引可能让线程访问完全不连续的地址导致有的是cache hit、有的是miss进而发生分支发散。仿真跑完性能不佳我一度以为是数据通路建模有问题。后来在统计每个warp的branch divergence event时发现发散率高达43%。解决办法是在数据预处理阶段做索引重排把相同cache line内的索引聚到一起从而降低发散率。这个问题的发现完全是靠仿真器里事件统计帮助定位的如果是直接写RTL排查起来会痛苦得多。5. 怎么通过关键指标和数据判断“新一代”成立5.1 性能、能效、面积和频率的“永恒四角”微架构设计永远在四个维度之间周旋性能通常用IPC或吞吐量能效性能/功耗面积决定成本频率决定核心时钟能跑多高。我们判断一个设计是不是新一代不能只看一个指标。比如有些人搞了个超大缓存把核心面积翻倍IPC提升了40%但功耗也涨了60%能效反而下降这就不配称为新一代。同理如果把频率拉高20%IPC提升10%但功耗增加100%那也只是表面光鲜。我习惯在做完仿真后把所有结果汇总成一张表指标上一代基线新架构方案变化IPC平均12.516.834.4%能耗比FPS/W1.01.3535%核心面积mm²55062012.7%频率GHz1.651.6-3%内存带宽利用率58%71%22.4%这张表里IPC和能效比都有接近35%的提升面积只涨了12.7%频率轻微下降说明新的微架构走的是“加硬件资源换吞吐量”的路线方向顺。如果频率掉了很多而IPC提升主要靠堆面积那就要再回头想想成本值不值得。另外还有“可扩展性”这个指标把SM数量从32加到64甚至128性能应该接近线性增长。如果架构在16SM时效率不错一翻倍就出现跨核心互连瓶颈那这个新架构部署到高端产品线时会很尴尬。所以仿真阶段必须做多组“规模扫描”实验比如在4SM、8SM、16SM、32SM下分别跑同一套负载画出吞吐量-规模曲线。5.2 用Benchmark矩阵做参照不搞单一跑分我在做微架构评估时不会只跑一个应用。GPU工作负载五花八门三四个典型AI模型ResNet-50、YOLOv8、GPT-2、几个传统HPC基准HPCG、Stream、渲染场景基于光栅和光追各一。每个benchmark都有自己的倾向HPCG用稀疏矩阵和很多不规则访存对cache敏感Stream纯测内存带宽跟计算单元关系不大YOLOv8里卷积层层叠主要以矩阵乘法和内存搬运为主光追场景就看RT Core和BVH遍历的协同效率。如果新架构只在其中一个负载上提升30%而在其他负载上甚至倒退那我只能说它是一颗为特定任务优化的专用芯片但算不上“通用GPU微架构的新一代”。真正有资格称为新一代的是在绝大多数负载上都有8%~10%以上的整体改善在核心侧重的几类负载上有20%~30%的提升。6. 仿真阶段最常见的六个坑与排查办法这里直接整理一份速查表每个都是我实际踩过或帮别人排过的参考价值很高。现象可能原因解决思路仿真跑完性能忽高忽低没有固定随机种子或基准输入规模太小固定随机种子使用多套输入并取置信区间输入规模至少覆盖短、中、长三档某个微架构改动在仿真中无效基线校准未达标仿真模型过度理想化回退到原始配置重新校准cache命中率、带宽延迟等参数到真实误差内新指令在仿真器里报错指令编码扩展与旧模拟器不兼容单独编译一个带新指令的PTX补丁用功能仿真先验逻辑再接周期级仿真缓存命中率下降严重但吞吐量提升稀疏/不规则访存引入的碎片化引入地址随机化或偏斜缓存skewed cache或在调度器加访存合并策略多SM扩展性差从16SM到32SM性能停滞互连或一致性协议瓶颈在仿真器中加大L2分片数量测试多个域domain切分策略仿真功耗数字离大谱没有接入功耗模型或者负载时长太短导致漏电流占比失真使用MCpat/GEM5功耗扩展跑足够长的暖机周期后再统计功耗这些坑有一个共通点绝大多数不是微架构本身的问题而是仿真环境的“偏见”导致的。仿真器给出的结果只要有一处偏差就可能会误导整个决策。所以我不太建议只依赖一款仿真器有条件的话可以做“交叉验证”。比如周期级仿真器结果和纯RTL仿真器结果对比几个关键计数器再跟一个近似物理模型对比。如果三方都能对上这个结论才算可靠。7. 个人经验如何避免“伪创新的自我安慰”最后说点心里话。我见过一些团队为了把PPT故事讲圆强行给微架构加入一堆新硬件模块比如加了一个看起来很厉害但没人调用的“统一计算队列”或者为了对标友商把所有缓存做得超级大。仿真结果乍一看很好看但追问一下“这个功能解决了哪个真实负载的哪个具体痛点”往往答不上来。这种就属于典型的“伪创新”。避免这种问题我的个人经验有两条第一所有微架构改动必须能回溯到一条具体的性能瓶颈曲线。每一条新特性都要写一个“问题-假设-方案-仿真验证”的闭环。如果这个改动在仿真试验中无法让至少一个真实基准有明显的收益那就当它不存在。第二一代新微架构的诞生不只是在仿真器里跑一个“赢”的结果就完了。它需要忍受无数次的“不确定”新设计能不能编译进新的驱动、能不能被编译器生成高效的代码、边缘情况下会不会死锁。我在最后阶段一定会拉一份“用户程序兼容性”清单把上一代能跑的老二进制放到新仿真器里去跑。如果老程序都能照常运行而且还能因为新硬件获得部分自动加速那我才敢拍胸脯说这是一代新的GPU微架构。仿真器里的数字永远只是近似但它永远是我们在流片之前唯一的理性向导。希望这篇文章能让准备进入GPU微架构设计领域的同学少走一点弯路多看清一点方向。