NPU基础架构：硬件组成、计算单元与协同工作原理
在深入多模型并发调度与优先级控制之前，必须先建立对NPU硬件底座的清晰认知。NPU并非通用处理器的简单变体，而是围绕“矩阵运算密集化”与“数据搬运最小化”两大目标设计的专用加速引擎。本章将从硬件组成、计算单元、内存层次以及AI Core与AI CPU的协同机制四个维度展开，帮助学员建立从物理结构到执行逻辑的完整映射。理解这些底层机制，是后续分析并发冲突、设计优先级策略的前提——因为所有调度决策最终都要落到硬件资源的分配与争用上。
2.1 NPU硬件组成：从宏观到微观的模块划分
NPU的硬件组成可以划分为四个核心层次：外部存储接口、片上内存层次、计算阵列（AI Core集群）以及控制平面（AI CPU子系统）。外部存储接口通常支持DDR或HBM，负责与主处理器（如CPU）交换模型权重、输入特征图和指令流。片上内存层次则包括L2 Cache（多核共享）和L1 Buffer（AI Core私有），其设计目标是在计算单元附近构建高带宽、低延迟的数据供给通道。计算阵列由多个AI Core组成，每个AI Core内部又包含Cube单元（矩阵乘）、Vector单元（向量运算）、Scalar单元（标量控制）以及L0 Buffer（最靠近计算单元的数据暂存区）。控制平面则包含AI CPU、任务调度器、DMA控制器和同步单元，负责指令解析、任务分发和核间同步。
2.2 计算单元深度解析：Cube、Vector与Scalar的分工
AI Core内部的计算单元采用异构设计，各自承担不同类型的运算任务。理解这三者的分工，是理解NPU指令流水线的基础。
| 计算单元 | 核心功能 | 典型指令 | 数据精度 | 性能特征 |
|---|---|---|---|---|
| Cube单元 | 矩阵乘加运算（卷积、全连接） | MMAD、GEMM | FP16/INT8 | 极高吞吐，单周期完成16×16×16运算 |
| Vector单元 | 逐元素运算（激活、归一化、池化） | ADD、MUL、RELU、Softmax | FP32/FP16 | 中高吞吐，支持向量化并行 |
| Scalar单元 | 地址计算、循环控制、分支跳转 | MOV、CMP、JMP | INT32 | 低吞吐，但决定指令流执行顺序 |
在实际执行一个卷积层时，数据流通常为：L2 → L0 Buffer → Cube单元计算 → 中间结果暂存L0 → Vector单元做激活/池化 → 写回L2。Scalar单元则在整个过程中负责生成地址、控制循环次数以及处理边界条件。这种流水线设计使得Cube单元可以持续满负荷运转，而不会被非矩阵运算打断。
2.3 内存层次与数据搬运策略
NPU的内存层次设计遵循“越靠近计算单元，容量越小、速度越快、成本越高”的原则。典型的内存层次从外到内依次为：DDR/HBM（GB级）→ L2 Cache（MB级）→ L1 Buffer（KB级）→ L0 Buffer（KB级，寄存器级）。每一级之间的数据搬运由DMA控制器自动完成，但搬运的触发时机和方向需要由软件（编译器或运行时）显式控制。
在并发场景下，内存层次的管理变得尤为复杂。多个模型同时运行时，它们对L2 Cache的占用是动态竞争的。例如，模型A的权重可能占据L2 Cache的60%，而模型B只占据20%，剩余20%用于激活值缓存。如果调度器没有感知这种占用情况，可能导致模型A频繁发生L2 Cache缺失，被迫回DDR读取数据，造成严重的性能抖动。
2.4 AI Core与AI CPU的协同工作原理
AI CPU与AI Core之间并非主从关系，而是“控制-执行”的流水线协作关系。AI CPU负责宏观控制，AI Core负责微观计算。具体协同流程如下：
- 指令下发：AI CPU从外部存储读取任务描述符（Task Descriptor），解析后生成一系列微指令（Microcode），通过指令总线分发给对应的AI Core。
- 数据准备：AI CPU同时启动DMA控制器，将模型权重和输入数据从DDR搬运至L2 Cache，再进一步分发至各AI Core的L1 Buffer。
- 并行计算：AI Core收到指令后，Cube/Vector/Scalar单元开始并行工作。AI CPU不干预计算过程，而是继续处理下一个任务的指令分发。
- 同步与完成：AI Core完成计算后，通过中断或状态寄存器通知AI CPU。AI CPU收集所有AI Core的完成状态，进行同步（Barrier），然后触发下一轮任务。
这种协同模式的关键在于异步流水线：AI CPU在等待AI Core计算的同时，可以提前准备后续任务的数据和指令。在单模型场景下，这种流水线可以隐藏大部分数据搬运延迟。但在多模型并发时，多个AI CPU（或一个AI CPU的多个线程）需要同时管理多个任务流，此时任务调度器的仲裁策略就变得至关重要——它决定了哪个模型的任务优先获得AI Core资源，以及如何避免不同模型之间的指令流相互干扰。
2.5 案例拆解：单模型性能调优中的硬件感知
为了将上述原理落地，我们以一个实际案例说明如何利用硬件架构知识进行性能调优。假设某AI加速卡上部署了一个ResNet-50模型，初始性能为1200 images/sec，但预期目标为2000 images/sec。通过Profiling工具采集到的关键指标如下：
| 指标 | 当前值 | 理想值 | 分析 |
|---|---|---|---|
| Cube利用率 | 45% | >80% | Cube空闲时间过长，数据供给不足 |
| L2 Cache命中率 | 72% | >95% | 权重复用不足，频繁回DDR读取 |
| DMA带宽占用 | 68% | <50% | DMA搬运与计算重叠度不够 |
| AI CPU空闲率 | 30% | <10% | AI CPU等待AI Core完成，流水线未填满 |
分析过程：Cube利用率低且L2命中率低，说明模型权重在L2 Cache中的驻留时间过短。进一步检查发现，ResNet-50的卷积层权重总量约为25MB，而该NPU的L2 Cache容量为32MB。理论上可以完全容纳，但由于默认的数据布局是“按层加载、用完即弃”，导致每层计算完成后权重被立即淘汰。
优化操作：① 修改数据布局策略，将前几层卷积权重常驻L2 Cache（通过内存锁定API）；② 调整DMA预取距离，提前2层开始搬运下一层权重；③ 将Batch Size从4提升到8，增加权重复用次数。优化后，L2命中率提升至94%，Cube利用率达到82%，最终性能达到1950 images/sec，接近目标。
复盘经验：性能调优不能只看算子耗时，必须结合硬件架构特征。在本案例中，L2 Cache的容量感知是核心突破口。对于多模型并发场景，这种“缓存感知”的调度策略同样适用——调度器需要知道每个模型的工作集大小，并据此决定是否允许同时运行，以及如何分配L2空间。