4、调度器基础：调度器在NPU软件栈中的位置、作用，以及与操作系统调度的区别

在NPU（神经网络处理单元）的软件栈中，调度器（Scheduler）是连接上层AI框架与底层硬件执行引擎的关键枢纽。对于从事AI芯片驱动开发、推理引擎优化或异构计算平台构建的工程师而言，理解NPU调度器的设计哲学与运作机制，是掌握多模型并发调度与优先级控制的前提。本章将首先厘清调度器在NPU软件栈中的精确位置，剖析其核心职责，并重点对比其与操作系统（OS）进程/线程调度的本质差异——这种差异直接决定了NPU资源管理的独特策略。

4.1 调度器在NPU软件栈中的位置与核心职责

4.1.1 软件栈分层架构

NPU软件栈通常自顶向下分为四层：AI框架层、图编译器层、运行时/调度器层以及驱动/固件层。调度器位于第三层，即运行时（Runtime）内部，是唯一同时感知"上层计算图语义"与"下层硬件资源状态"的组件。其输入是图编译器产出的、已绑定硬件资源的执行单元（如Task、Command Buffer或Kernel描述符），输出是对NPU多核、DMA通道、片上内存等资源的时序分配指令。

从工程视角看，调度器需要维护至少三类核心数据结构：待调度任务队列（Pending Queue）、运行中任务表（Active Task Table）和资源状态位图（Resource Bitmap）。任务队列按优先级和依赖关系排序，运行中任务表记录当前占用NPU核心的任务及其占用的资源范围，资源状态位图则实时反映每个NPU核心、每块SRAM、每个DMA通道的忙闲状态。

4.1.2 调度器的三大核心职责

第一，任务时序编排。调度器必须保证有依赖关系的算子严格按照拓扑序执行。例如，在YOLOv5推理任务中，Backbone的卷积输出必须等待前一层的BatchNorm和激活完成。调度器通过有向无环图（DAG）的拓扑排序，将无依赖的算子（如分支检测头）分配到不同NPU核心并行执行。

第二，资源分配与切分。当多个模型并发请求NPU时，调度器需要决定是采用"时间分片"（多个模型轮流独占全部核心）还是"空间切分"（将NPU核心组划分为多个partition，每个模型独占一个partition）。这取决于NPU硬件是否支持核心组隔离（如Ascend的AI Core Group、NVIDIA的MIG技术）。

第三，优先级抢占与公平性保障。调度器必须响应高优先级任务（如实时检测告警）的插队请求，同时避免低优先级任务发生"饥饿"（Starvation）。这需要设计老化机制（Aging），即低优先级任务等待超过阈值后自动提升优先级。

4.2 与操作系统调度的本质区别

4.2.1 调度对象与粒度差异

操作系统调度器（如Linux CFS）的调度对象是线程（Thread），调度粒度通常为毫秒级时间片，且线程之间是"抢占式"关系——高优先级线程可以立即打断低优先级线程的执行。而NPU调度器的调度对象是计算图（Graph）或算子（Op），调度粒度从微秒级（单个算子）到百毫秒级（整个推理任务）不等。更重要的是，NPU算子一旦开始执行，通常不可被抢占——因为NPU硬件执行单元没有保存/恢复上下文（Context Switch）的能力，强行中断会导致片上SRAM中的中间结果丢失。

4.2.2 资源模型差异

OS调度器管理的资源是CPU核心和内存页，资源是同质化的——每个CPU核心执行能力相同。而NPU调度器管理的资源是异构的：AI Core负责矩阵运算，Vector Core负责向量运算，DMA通道负责数据搬运，片上SRAM是稀缺的高速暂存资源。这种异构性要求调度器必须做多维资源联合分配，而非简单的"找一个空闲核心"。

4.2.3 同步与通信机制差异

OS线程通过互斥锁、条件变量等同步原语协作，而NPU任务之间通过事件（Event）和栅栏（Fence）同步。调度器需要管理这些同步原语的状态，确保一个算子的输出事件被后续算子正确等待。此外，NPU任务的数据依赖不仅体现在逻辑上，还体现在物理内存位置上——调度器必须保证数据在DDR和SRAM之间的搬运（DMA操作）与计算操作在时间上重叠（Pipeline），这比OS的"锁等待"复杂得多。

4.3 调度器的工作流程与关键判断方法

4.3.1 调度决策流程

一个典型的NPU调度周期包含以下步骤：

1. 任务解析：从框架层接收执行请求，解析出计算图、优先级标签、QoS要求（如最大延迟、最小吞吐）。
2. 资源预检：查询资源状态位图，判断当前是否有足够的空闲AI Core、SRAM和DMA带宽满足任务需求。
3. 调度决策：根据调度策略（如优先级抢占、加权公平队列）从待调度队列中选择下一个任务，并分配具体资源。
4. 指令下发：将任务拆分为硬件可执行的指令序列，写入命令队列（Command Queue），通知驱动层启动硬件执行。
5. 状态监控：监听硬件完成中断，更新资源状态位图，唤醒等待该任务完成的下游任务。

4.3.2 判断调度策略优劣的量化指标

在实际工程中，评估调度器设计是否合理，通常关注以下指标：端到端延迟（P99 Latency）、系统吞吐量（Throughput）、资源利用率（AI Core Utilization）以及调度开销（Scheduling Overhead）。其中，调度开销必须控制在任务执行时间的1%以内，否则调度本身会成为瓶颈。

4.4 实战案例：边缘服务器上的多模型并发调度

4.4.1 场景背景与约束

某智慧园区部署了一台搭载昇腾310P NPU的边缘服务器（8个AI Core，片上SRAM 192KB，DDR 8GB）。需要并发运行三个推理服务：人脸识别（高优先级，QoS要求P99延迟小于50ms）、车辆检测（中优先级，P99延迟小于200ms）、环境监控（低优先级，无严格延迟要求，但需持续运行）。初始方案采用简单的"先来先服务"（FCFS）调度，导致人脸识别服务频繁超时。

4.4.2 问题分析与调度策略调整

通过日志分析发现，车辆检测任务每次执行需要占用全部8个AI Core约80ms，期间人脸识别任务只能等待。虽然人脸识别任务本身只需20ms执行时间，但平均等待时间达到60ms，导致P99延迟超标。

调整方案如下：

• 空间切分：将8个AI Core划分为两组：Group A（6个Core）专用于人脸识别，Group B（2个Core）用于车辆检测和环境监控。
• 优先级队列：在Group B内部，车辆检测优先级高于环境监控，采用可抢占式调度（但仅限任务边界处抢占，即当前任务执行完后再切换）。
• DMA带宽预留：为Group A预留30%的DMA带宽，确保人脸识别任务的数据搬运不被车辆检测的大块数据传输阻塞。

4.4.3 实施结果与复盘

复盘发现，环境监控任务在车辆检测持续繁忙时出现饥饿。后续引入老化计数器：环境监控任务每等待10秒，优先级自动提升一级，直至获得执行机会。同时，将车辆检测的DMA传输拆分为更小的块（256KB），允许环境监控任务在DMA间隙插入执行，进一步降低饥饿概率。

4.5 常见误区与设计总结

4.5.1 误区一：将OS调度算法直接移植到NPU

Linux CFS等OS调度算法基于"公平时间片"模型，假设任务可随时切换。直接移植到NPU会导致：频繁的上下文切换开销（NPU上下文保存/恢复代价极高）、资源碎片化（不同任务对SRAM需求不同，时间片切换导致SRAM利用率下降）。正确做法是采用资源感知的协同调度，将任务按资源需求分类（计算密集型、访存密集型、混合型），再决定空间切分还是时间分片。

4.5.2 误区二：忽略DMA带宽的调度

许多初版调度器只关注AI Core的分配，忽略DMA带宽争抢。实际上，在数据密集型模型（如视频分析）中，DMA带宽往往比算力更早成为瓶颈。调度器必须将DMA视为"一等资源"，在分配任务时同时预留DMA通道和带宽配额。

4.5.3 误区三：静态优先级导致饥饿

固定优先级调度（如实时任务永远优先）虽然保证了高优先级任务的延迟，但会导致低优先级任务完全饿死。工程上必须引入动态优先级调整机制，包括老化提升、带宽补偿（低优先级任务在空闲时段获得额外资源）等策略。

4.5.4 总结：调度器设计的核心原则

• 资源异构感知：调度决策必须基于AI Core、Vector Core、DMA、SRAM的多维资源视图。
• 任务边界抢占：利用DMA与计算的重叠窗口实现"软抢占"，避免硬件上下文切换。
• QoS分级保障：通过空间隔离（核心组切分）为高优先级任务提供确定性延迟，通过时间分片为低优先级任务提供尽力而为服务。
• 可观测性设计：调度器必须暴露任务排队时间、执行时间、资源利用率等指标，便于调优和排障。

理解NPU调度器与OS调度器的本质区别，是设计高效多模型并发系统的第一课。下一阶段，我们将深入探讨多模型并发场景下的资源切分策略与优先级控制的具体实现技术。