1. 乱序执行NPU/GPGPU设计的深水区与破局点这两年做AI芯片和通用加速器的朋友应该都有个明显的体感靠堆MAC阵列规模和加大SRAM容量换算力的路子边际收益已经越来越低了。尤其是做GPGPU或者类CUDA架构的团队几乎都会撞上同一个天花板——ALU和MAC阵列的利用率上不去DDR带宽明明还有富余但实际跑起来就是喂不饱算力。于是“Out-of-Order”这个词开始频繁出现在各种架构评审会上。我最早接触乱序执行是在做CPU后端的时候那时候觉得OoO是CPU的专利跟NPU这种以数据流为主、极度讲究确定性的硬件八竿子打不着。但后来做了几个NPU/GPGPU项目被调度器设计、流水线stall、bank conflict反复折磨之后我逐渐意识到一个问题NPU/GPGPU里的乱序并非简单抄袭CPU的Tomasulo算法它更像是把“指令发射顺序”从“程序顺序”中解放出来把“数据依赖”作为唯一执行约束的一套资源调度哲学。这篇文章不聊教科书上的定义我想从实际项目经历出发拆一拆我理解的Out-of-Order NPU/GPGPU到底在解决什么问题它的核心机制是什么以及如果你要自己动手做一颗这样的芯片或者用FPGA搭一个原型有哪些绕不开的坑。先说结论乱序执行的本质不是“打乱指令”而是“把等待阻塞的时间用起来”。在CPU里乱序解决的是Cache Miss、分支预测失败带来的长延迟在NPU/GPGPU里乱序解决的是数据搬运、SRAM bank冲突、 MAC流水线气泡、以及多任务并发时的资源争抢。当你的NPU里不止一个计算核不止一个DMA通道不止一级存储层次时乱序就不再是可选项而是性能爬升的必经之路。2. 为什么NPU/GPGPU需要乱序从流水线气泡到资源利用率2.1 传统NPU的“乖孩子”模式顺序发射的代价传统NPU设计里绝大多数都是顺序发射In-Order的。也就是指令按程序顺序进入流水线前一条指令没执行完后一条可能就要等着。这种设计的好处是硬件简单、时序好收敛、功耗低且行为完全可预测——这对AI推理芯片来说特别友好因为模型一旦固定算子序列和访存模式几乎不变顺序执行完全够用。但问题出在复杂场景。你跑一个Stable Diffusion或者多模态模型时算子之间有大量的矩阵乘法、归一化、残差连接、激活函数它们的数据依赖虽然存在但并非一条线性链。很多时候计算单元在等数据而DMA和ALU互不干扰的指令其实是存在的。如果硬件严格按顺序来那等待的时间就被白白浪费掉了。我做过一个实际测算在某个7nm工艺的NPU项目里如果采用全顺序发射运行ResNet-50时MAC阵列的利用率大概在65%左右而如果允许后一条计算指令在没有数据依赖的前提下提前发射利用率能直接干到85%以上。这中间差的20个点就是纯利润而且不需要改任何算法也不需要提升主频。2.2 GPGPU天然自带“乱序”基因从线程级并行到指令级乱序GPGPU跟NPU有一点本质不同GPGPU通过海量线程并行来隐藏延迟本质上是一种高级的“时间片轮转”。当一个Warp因为访存阻塞时调度器会立刻切换到另一个Warp这个过程虽然不叫乱序执行但它达到的效果同样是“让计算单元闲着的时间变少”。但真正的Out-of-Order GPGPU要做的是比Warp切换更细粒度的乱序。也就是说即使一个Warp内部的两条指令存在资源冲突只要它们没有真实的数据依赖硬件就应该想办法让它们互相错开执行。特斯拉的Dojo、AMD的CDNA系列架构都有类似的影子。它们不只是靠线程数量堆延迟容忍度还在指令调度层面做文章。这个趋势背后有个非常朴素的逻辑单位面积上的线程上下文存储是有物理上限的Warp数量的堆叠总有一天会碰到Register File的墙。当线程数量不再能线性增长时你就必须提高单线程的IPC也就是让每一条指令在流水线里待的时间更短、执行得更紧凑。这一条路就是乱序。2.3 数据流架构与乱序执行的暧昧关系说到这里必须澄清一个概念NPU里的“数据流架构”和“乱序执行”并不矛盾。数据流说的是计算模式——数据从Storage搬到MAC阵列算完再搬回去像水一样流乱序说的是调度模式——哪条指令先执行不一定按程序顺序来。两者完全可以共存。我见过有人在做脉动阵列Systolic Array时坚持认为乱序执行跟脉动式数据流天然冲突理由是脉动阵列要求数据必须按时钟节拍精准注入。这个担忧有一定道理但如果你的NPU是多核架构不同核之间的脉动阵列本来就可以独立工作跨核的任务调度完全可以用乱序来编排。也就是说乱序的粒度不一定在单条指令内部也可以在整个计算核的任务分发层面。3. Out-of-Order核心机制拆解从Scoreboard到分布式调度3.1 记分牌Scoreboard还是TomasuloNPU的取舍CPU乱序执行有两大经典流派Scoreboard和Tomasulo。Scoreboard是CDC 6600的方案集中式管理结构简单但缺点是它在检测到WAR写后读和WAW写后写冒险时会被迫停顿因为它没有寄存器重命名。Tomasulo用保留站Reservation Station配合寄存器重命名能绕过WAR/WAW冒险乱序能力更强但硬件开销也高。NPU/GPGPU的乱序执行器该选哪个我的实践经验是如果你做的是纯NPU算子级任务并行为主用Scoreboard就够如果你做的是GPGPU线程内指令并行为主Tomasulo更合适但必须配合寄存器重命名的成本控制策略。为什么这么分纯NPU的指令一般粒度很粗——一条矩阵乘指令可能执行几千个时钟周期。一个Core里同时在飞的计算任务通常也就4~8个用集中式Scoreboard完全可以管理过来没必要上Tomasulo那种复杂的保留站结构。而GPGPU的指令粒度细又一个Warp里有32条线程的掩码指令数量巨大如果没有寄存器重命名WAR/WAW冒险会频繁踩中性能和硬件复杂度双双失控。3.2 发射队列与操作数就绪检测真正决定乱序深度的组件乱序执行器里最有技术含量的部分个人认为是发射队列Issue Queue的设计。它的核心职责是每一拍检查所有等待发射的指令找出“操作数已就绪”且“执行单元空闲”的那一条然后把它发射出去。这个“查找”过程既是性能的源头也是时序的噩梦。经验做法是采用非阻塞式发射队列。即每条指令进入IQ后立刻检查操作数是否就绪并注册一个唤醒信号。每当前一条指令写回结果时通过一条Broadcast总线把所有等待该寄存器的指令全部唤醒。这个机制在CPU里叫Wakeup-Select在NPU里也一样好用只是NPU的“寄存器”可能是SRAM的某个地址段粒度不太一样。但这里有个工程难点NPU的操作数大小比CPU大得多。CPU一个寄存器128bitNPU一个操作数可能是128KB的Feature Map。你没法把一个128KB的数据块搬进保留站里等。所以NPU的乱序执行器等的是“数据搬运完成的信号”而不是“数据本身”。这意味着你的Scoreboard或者保留站里记录的不再是数据而是“数据所在的物理地址状态位”。这带来了新的问题数据在SRAM里被后续指令覆盖了怎么办这就需要在存储子系统里加状态跟踪。3.3 寄存器重命名在GPGPU中的低成本实现GPGPU做寄存器重命名比CPU难得多。CPU每个线程只有少量寄存器重命名表项小且集中管理GPU一个Warp可能占用几百个寄存器而且寄存器文件巨大做集中式重命名表简直寸步难行。业内常见的做法是分片式重命名把寄存器文件按Bank切分每Bank维护一个局部映射表指令发射时只在本Bank内做重命名。这样避免了全局广播极大降低了硬件复杂度。代价是跨Bank访存时需要额外一拍延迟但考虑到GPGPU的访存延迟动辄几十拍这一拍不值一提。如果你正在设计一颗GPGPU我的建议是别一开始就上完整Tomasulo先用分片重命名Scoreboard跑一轮性能仿真看看WAR/WAW冒险究竟在真实负载里出现得有多频繁。很多时候20%的硬件代价只能换回3%的性能提升这买卖不划算。3.4 访存指令的乱序窗口Memory-Level Parallelism的闸门NPU和GPGPU的乱序执行里访存指令的调度是最容易被忽视又最影响性能的。CPU里访存指令之间可以通过Load-Queue和Store-Queue做内存消歧推测执行。到了NPU里访存指令面向的是SRAM、HBM、DDR等不同层级延迟差异巨大。DMA搬运指令在乱序执行器里应该被看成“长延迟指令”它们像CPU里的Cache Miss Load一样不应该阻塞后续无关指令的执行。这里的关键是设计一个访存指令窗口Memory Instruction Window让DMA指令和数据搬运指令进入独立的队列并跟计算指令通过信号量或事件ID做同步而不是挂在统一发射队列里拖垮计算指令的发射速度。我见过多个项目在最初设计时把DMA和计算指令放在同一个队列里结果就是DMA等待HBM返回数据时整个队列被堵死计算单元全部空转。后来把DMA队列拆分为独立窗口后同样的Benchmark性能提升了30%以上。这个改动不大收益却非常直接。4. MAC阵列与乱序调度的协同主网格阵列的另一种思考4.1 MAC阵列的“税务问题”为什么利用率总是到不了100%不管你是用经典的乘累加单元MAC阵列、Systolic Array还是类Tensor Core设计MAC阵列的利用率都有一个永恒的敌人——数据供给不够及时。以最典型的Systolic Array为例左边喂Weight上边喂Activation中间每个PE做一次乘累加结果向右下流动。理想状态下每个时钟每个PE都在干活利用率100%。但实际情况是Weight需要从SRAM搬进PE阵列、Activation需要从上一级缓存搬来这两个数据流只要任何一方断了整个阵列就停下来等。这里就要提到热搜词里那个“npu主网格阵列main grid arrayMAC阵列工作原理”。我理解这个说法指的是主计算网格——也就是NPU核心中承担绝大多数矩阵运算的主体MAC阵列区别于一些辅助的小规模向量计算单元。它本质上是一个高密度的乘累加网格输入数据从边缘注入中间经过多层流水完成计算最后输出部分和Partial Sum。要让主网格阵列满负荷运转调度器必须保证每一拍都有数据送进阵列。传统办法是用双缓冲一块SRAM在算另一块在搬运交替进行。但双缓冲只能掩盖“连续搬运”的延迟掩盖不了“数据依赖切换”的延迟——比如上一个矩阵算完下一个矩阵需要的数据还在HBM里那中间就必然出现气泡。4.2 乱序调度如何填满MAC阵列气泡把乱序执行引入MAC阵列的控制逻辑后情况会发生质变。调度器不再死板地等当前矩阵乘完再发起下一条指令而是在当前矩阵计算进入后半段时就提前预取下一个算子的数据如果两条算子之间存在可并行的分支操作甚至可以让它们同时在不同子阵列上执行。具体说我会在主网格阵列前端加入一个指令预取与依赖判定单元Issue Prefetcher。它提前扫描后续若干条指令做依赖分析之后把“已经就绪、不依赖当前正在执行的算子”的指令提前发射到MAC阵列的配置寄存器里。配置寄存器的意思是MAC阵列的行数、列数、Weight基址、Activation基址、补零模式等参数这些本身都是走寄存器配置的所以提前写入完全可行。这一招在CSAConfigurable Systolic Array架构里尤其好用。因为CSA的行列可以根据算子形状动态调整如果在当前矩阵计算结束前的一拍配置寄存器已经预写好下一条指令的参数那么流水线切换代价几乎为零。实测下来切换代价从原来的十几拍压缩到两拍以内。4.3 降低MAC阵列切换代价预配置与影子寄存器的实战影子寄存器Shadow Register是做硬件流水切换的经典手法。在MAC阵列控制寄存器前方再加一组“影子配置寄存器”——只允许写入不直接输出到阵列。当调度器发出“Commit”信号时影子寄存器的内容在一个时钟边沿全部原子地替换正式配置寄存器。这样就可以彻底消除参数写入过程中的中间态即使某个配置寄存器需要多个周期逐个写入也不会产生半配置的错误计算。用这种方法乱序调度的收益才能真正落到MAC阵列的微观时序上。你可以在当前算子还在计算时花若干个周期慢慢把下一条算子的配置写进影子寄存器等当前算子算完的那一拍直接Commit。整个过程不需要MAC阵列停下来等待配置气泡被压缩到极限。我强烈建议做NPU设计的朋友无论是否上乱序执行都先把影子寄存器加上。这玩意儿成本极低只是一组寄存器但对流水线效率和时序收敛都有立竿见影的效果。5. 实操视角一个简单乱序调度器的硬件原型设计5.1 从RTL角度拆解发射队列、唤醒逻辑、仲裁器咱们从RTL设计的角度具象化一个小型乱序调度器。假设我们的NPU核支持4个并发计算任务那么发射队列Issue Queue深度设为8就够。每条指令在IQ里占据一个Entry其硬件字段大概长这样字段位宽说明Valid1该Entry是否有有效指令Opcode6指令类型矩阵乘、向量加、DMA等DestAddr20目的SRAM地址Src0Addr20源操作数0的SRAM地址Src1Addr20源操作数1的SRAM地址Src0_Ready1源操作数0是否已就绪Src1_Ready1源操作数1是否已就绪ExecUnit3指定使用哪个执行单元Age4指令年龄用于公平仲裁唤醒逻辑负责监视各执行单元写回操作当写回地址与IQ中某条指令的SrcAddr匹配时把对应Ready位置1。仲裁器每拍扫描IQ中Valid1且Src0_Ready1且Src1_Ready1的Entry按优先级选出一条发射。优先级策略可以是“最老优先”也可以加入简单的资源冲突避让。实际编写RTL时有个容易踩坑的点IQ的比较器网络规模会随Entry深度平方增长。Entry深度8时还好深度32以上时分立比较器就会成为时序瓶颈。如果你的项目需要更深IQ建议做成两级仲裁——先按4个Entry一组做本地仲裁再对组间做第二轮仲裁时序好收敛得多。5.2 胜利信号背后的关键细节为什么状态位独立于数据路径这里的Ready位必须用独立Flip-Flop维护不能直接读SRAM的某个状态位来判断数据是否就绪。原因很简单SRAM状态位更新与指令写回之间存在多拍延迟而且频繁轮询SRAM的Tag会增加存储端口的访问压力。独立的Ready状态位虽然占用一点面积但让唤醒逻辑能在一个时钟周期内完成全扫描这对乱序窗口的持续吞吐至关重要。它的逻辑很像CPU里Scoreboard的思想——只不过Scoreboard针对的是单周期访问的寄存器文件而我们面对的是延迟几十拍的SRAM/HBM访问。原理是一回事工程细节是另一回事。5.3 死锁与活锁乱序系统最容易翻车的地方乱序设计里最常见的bug有三类资源死锁两个任务各占用一个执行单元同时又在等对方释放的资源。比如任务A占着MAC阵列在等DMA通道0任务B占着DMA通道0在等MAC阵列。解决方法是加资源分配超时机制或者保证资源申请的顺序一致性。活锁仲裁器永远在服务“新来的”指令导致某些旧指令一直抢不到发射机会系统虽然没死但性能归零。解决方法是限定“每Entry最大等待周期”超时则强制仲裁器优先级提到最高。唤醒信号丢失当一条指令写回时它的目的地址与等待它的指令地址匹配逻辑有时序竞态导致Ready位没有置上。这个bug最难查因为它只在特定时序窗口下出现。我的排查经验是用UVM环境做定向约束的随机验证专门生成连续依赖链和极端背靠背写回序列最容易逼出这种问题。6. 从Intel NPU到自研GPGPU乱序技术栈的实践地图6.1 Intel NPU的调度策略给我的启发这几年很多人关注Intel的NPU产品线而Intel NPU最有意思的地方在于它采用了多核可配置数据流的方式去覆盖AI推理场景。虽然它并非以炒作“乱序执行”闻名但从公开资料来看它的调度器确实支持多个并行执行单元之间的动态任务分配与资源仲裁。换句话说即使没有完整的乱序发射逻辑Intel NPU也在“任务级乱序”这个层面做了文章。这个思路对做芯片的人特别有启发乱序的粒度不是越高越好而是看你的工作负载形态。如果你的主要负载是AI推理算子的数量少但单个算子计算量大任务级乱序就比指令级乱序性价比高得多如果你的负载是科学计算或图形渲染GPGPU风格的细粒度乱序才有必要。我自己做架构权衡时会拿真实模型做算子执行时间直方图统计两个指标相邻算子间的平均依赖距离以及可并行算子组的比例。如果可并行算子比例超过30%乱序设计就有肉吃低于10%上了乱序也白搭不如在存储带宽和MAC复用上多下功夫。6.2 从In-Order到Out-of-Order的渐进式改造路线如果你是接手一个老NPU项目想往里加乱序能力又不敢推倒重来我建议按下面三步走第一步任务级乱序。保留原有乘法和向量指令的In-Order发射逻辑只在多个计算任务Kernel之间做乱序调度。改动最小收益主要来自多任务并行时的资源复用。第二步访存指令乱序。把DMA和数据搬运指令从主流水线中解耦放到独立的访存指令窗口里与计算指令通过同步信号交互。这一步是性价比之王很多项目只做到这步就满足需求了。第三步计算指令乱序。完全引入发射队列和唤醒逻辑让不同类型的计算指令在无依赖时可互相跨越执行。这一步改动最大需要配合寄存器重命名或Scoreboard一般只在新一代全自研架构里才敢动。建议想入局的朋友不要一开始就冲着第三步去。先把前两步落地拿真实Benchmark测两轮你会对“乱序到底值多少性能”有个非常直观的判断再决定要不要梭哈第三步。6.3 工具链与仿真环境准备最后聊一下验证环境。做乱序执行的验证靠纯定向测试远远不够必须上随机约束激励。推荐用UVM搭一套轻量级验证环境指令序列生成器加入以下约束随机生成长依赖链每条指令都依赖前一条随机生成短依赖链大量无关指令随机生成WAR/WAW冒险随机注入DMA延迟抖动随机切换任务ID模拟多Kernel并发这些激励能让你的调度器在仿真阶段就暴露绝大多数调度bug。如果你有FPGA原型平台还能把相同激励灌进FPGA里做比对那验证置信度就非常高了。共勉一句乱序执行不是炫技它是用来踏踏实实解决“算力喂不饱”问题的工程手段。每个想做的团队都应该先想清楚自己的工作负载里有多少“可以被打乱的指令”再谈这个OoO值不值得做。