课程导入：学习目标、核心概念、整体框架——理解多模型调度在移动端AI中的重要性
随着端侧AI能力的快速演进，智能手机、智能眼镜、车载座舱等移动设备已不再满足于运行单个神经网络模型。现代移动端AI应用——如实时视频风格化、多模态语音助手、AR导航与物体识别融合——往往需要同时或交替执行多个深度学习模型。以旗舰级智能手机为例，一颗SoC中集成的NPU、GPU、DSP和CPU需要协同处理视觉、语音、传感器等多路推理任务。然而，移动设备的物理约束极为严苛：散热能力有限（通常被动散热）、电池容量受限（典型3000-5000mAh）、芯片功耗预算紧张（持续负载下SoC封装温度需控制在85°C以内）。在这种背景下，如何高效地调度多个模型，在保证用户体验（时延、精度）的同时，将功耗与温度控制在安全边界内，成为端侧AI工程化的核心挑战。本章作为整个课程的开篇，将明确学习目标、厘清核心概念，并搭建起贯穿后续29章的整体知识框架。
1.1 学习目标：从“能跑”到“跑得好”
本课程的学习目标并非仅仅让读者了解SNPE（Snapdragon Neural Processing Engine）的API调用方式，而是建立一套完整的工程化思维——在资源受限的移动设备上，将多个深度学习模型的组织、调度、执行与温控视为一个整体系统问题。具体而言，完成本章及后续课程后，学习者应达到以下能力层级：
- 理解层：能够解释多模型调度的本质矛盾——计算需求无限增长与物理资源（功耗、散热、内存带宽）有限之间的冲突；能够描述SNPE中模型执行的基本生命周期（加载→准备→执行→释放）。
- 分析层：能够根据实际应用场景（如实时视频处理流水线），识别出哪些环节存在多模型并发或交替执行的机会；能够分析模型间的依赖关系（数据依赖、资源依赖、时序依赖）。
- 设计层：能够设计合理的调度策略——包括静态优先级表、动态负载感知调度、基于温度反馈的降级方案；能够选择合适的SNPE运行时配置（CPU/GPU/NPU/DSP异构分配）。
- 调优层：能够通过性能剖析工具（如Snapdragon Profiler、Perfetto）定位调度瓶颈；能够调整调度参数（如批量大小、流水线深度、频率锁定）以优化时延-功耗-温度三角关系。
核心认知转变：传统AI部署关注“单模型时延”，而多模型调度关注“系统级吞吐与热稳定性”。一个模型跑得快不算成功，多个模型在持续负载下不触发热降频、不导致卡顿、不缩短电池寿命，才是端侧AI工程化的真正目标。
1.2 核心概念：多模型调度的关键术语与定义
在深入调度策略之前，必须统一术语体系。以下概念将贯穿整个课程，并在后续章节中反复使用：
| 概念术语 | 定义 | 工程意义 |
|---|---|---|
| 模型实例（Model Instance） | 一个已加载到内存中的神经网络，包含权重、图结构和运行时状态 | 多个实例可共享权重（内存复用），但执行上下文独立 |
| 调度单元（Scheduling Unit） | 一次完整的模型推理任务（一次前向传播） | 调度器以“推理任务”为粒度进行资源分配 |
| 资源域（Resource Domain） | SoC中可独立控制的计算单元（NPU、GPU、DSP、CPU集群） | 不同模型可映射到不同资源域，实现并行 |
| 热预算（Thermal Budget） | 在不超过结温上限的前提下，SoC可消耗的总能量 | 调度器需将热预算分配到各模型执行时段 |
| 优先级反转（Priority Inversion） | 低优先级任务占用资源导致高优先级任务阻塞 | 需通过优先级继承或资源预留避免 |
| 模型流水线（Model Pipeline） | 多个模型按数据流顺序执行，前一个输出作为后一个输入 | 流水线深度影响端到端时延与吞吐 |
理解这些概念的关键在于认识到：多模型调度不是简单的“排队执行”，而是对计算资源、内存带宽、功耗预算和热容量的多维分配问题。例如，当NPU正在执行语义分割模型时，GPU可能空闲——调度器需要决定是否将另一个轻量级分类模型同时调度到GPU上，以提升整体吞吐，但这也意味着总功耗上升，可能加速温度攀升。
1.3 整体框架：从任务到执行的五层视图
为了系统化地理解多模型调度，我们将其拆解为五个层次，每一层都有明确的职责和接口。这个框架将作为后续所有章节的组织主线：
- 应用层（Application Layer）：定义业务逻辑——哪些模型需要运行、触发条件是什么、期望的时延/精度指标。例如，AR导航应用需要同时运行SLAM模型（30FPS）和语义分割模型（15FPS）。
- 图管理层（Graph Management Layer）：负责模型的加载、解析、优化（如量化、算子融合）以及多个模型之间的依赖关系构建。SNPE中对应
SNPEBuilder和SNPE容器的管理。 - 调度决策层（Scheduling Decision Layer）：这是本课程的核心。该层根据模型优先级、当前SoC温度、剩余电量、帧率要求等输入，决定“下一个执行哪个模型”“在哪个资源域执行”“以什么频率执行”。
- 运行时执行层（Runtime Execution Layer）：实际驱动NPU/GPU/DSP执行推理，处理内存分配、缓存刷新、同步与异步操作。SNPE的
execute调用和回调机制属于此层。 - 硬件抽象层（Hardware Abstraction Layer）：封装SoC的电源管理、时钟控制、热传感器读取等底层能力。调度决策最终通过DVFS（动态电压频率调整）和热管理单元落地。
这五层之间通过明确的接口交互：应用层通过异步回调接收推理结果；调度层读取温度传感器数据（如thermal_zone节点）；执行层向调度层反馈实际执行时间和功耗。理解这个分层有助于在调试时快速定位问题——例如，如果模型执行变慢，可能是调度决策问题（优先级配置不当），也可能是执行层问题（缓存未命中），还可能是硬件层问题（热降频触发）。
1.4 多模型调度的核心挑战与工程约束
移动设备上的多模型调度远比服务器端复杂，原因在于以下四个硬性约束：
- 热约束（Thermal Constraint）：手机没有主动散热风扇，SoC的结温一旦超过设计阈值（通常85°C-95°C），系统会强制降频甚至关机。多模型并发执行会迅速积累热量，调度器必须在性能与温度之间做动态权衡。
- 功耗约束（Power Constraint）：电池的放电能力有限，瞬间大电流会导致电压跌落，触发系统保护。调度器需要控制同时活跃的计算单元数量，避免功耗尖峰。
- 内存带宽约束（Memory Bandwidth Constraint）：多个模型同时执行时，对DDR的读写竞争激烈。NPU和GPU共享内存控制器，带宽不足会导致所有模型性能下降。
- 时延抖动约束（Latency Jitter Constraint）：交互式应用（如相机取景框实时滤镜）要求稳定的帧间隔，不能因为调度了后台模型而导致前台的时延突然增加。
常见误区：初学者往往认为“只要NPU够快，就能同时跑多个模型”。实际上，NPU的计算吞吐只是瓶颈之一。内存带宽、缓存容量、电源管理IC（PMIC）的响应速度、甚至PCB走线的寄生电感都会成为制约因素。多模型调度是一个典型的“木桶效应”问题——最短的那块板决定了系统整体表现。
1.5 案例拆解：智能座舱多模型场景的调度困境
为了将抽象概念具象化，我们分析一个典型的智能座舱场景。该场景来自某车规级平台的实际需求，但已做简化处理：
背景与约束：座舱域控制器需要同时运行以下模型：驾驶员疲劳检测（DMS，基于红外摄像头，30FPS）、乘客手势识别（基于ToF深度相机，15FPS）、语音唤醒（基于麦克风阵列，持续监听）、以及AR导航的车道线检测（基于前视摄像头，30FPS）。硬件平台为高通SA8155P（8核Kryo CPU + Adreno 640 GPU + Hexagon DSP，无独立NPU）。热设计功耗为15W，结温上限为95°C，环境温度为40°C（夏季车内暴晒后）。
初始现象：所有模型独立运行时均满足时延要求。但并发运行时，系统在5分钟内触发热降频，CPU从2.4GHz降至1.5GHz，导致DMS模型帧率从30FPS跌至18FPS，触发安全告警。
分析过程：通过Snapdragon Profiler采集数据发现：
- DMS模型（CNN结构）在GPU上执行，功耗约3.2W；
- 手势识别模型在DSP上执行，功耗约1.8W；
- 语音唤醒模型在CPU小核上持续运行，功耗约0.5W；
- 车道线检测模型在GPU上执行，与DMS共享GPU资源，导致GPU负载超过90%，功耗达到5.5W。
总功耗峰值达到11W，加上SoC其他部分（内存控制器、显示、ISP），整颗芯片功耗接近15W TDP上限。由于GPU持续高负载，热点集中在GPU区域，温度传感器检测到局部温度达到98°C，触发全局降频。
调度优化方案：
- 资源域隔离：将车道线检测模型从GPU迁移到DSP执行（利用DSP的向量扩展指令），GPU仅保留DMS模型，负载降至45%。
- 时间片交错：语音唤醒模型改为“事件驱动”模式——仅在检测到声音能量超过阈值时才执行推理，而非持续运行，CPU占用从15%降至2%。
- 动态降频策略：当温度超过85°C时，优先降低手势识别模型的帧率（从15FPS降至10FPS），而非降低DMS的帧率——因为DMS涉及安全，优先级更高。
- 内存带宽优化：将DMS模型的输入分辨率从640×480降至512×384（精度损失<1%），减少内存读取量约35%。
结果对比：优化后，系统在40°C环境温度下持续运行30分钟，温度稳定在88°C，未触发降频。DMS帧率稳定在30FPS，车道线检测帧率保持28FPS（原为30FPS，但精度满足要求），手势识别帧率在温度超过85°C时自动降至10FPS，语音唤醒响应延迟从200ms降至80ms（事件驱动模式减少了无效计算）。
复盘经验：该案例揭示了多模型调度的三个关键原则：第一，资源域映射比单纯调整频率更有效——将模型分配到不同的计算单元（GPU/DSP/CPU）可以避免热点集中；第二，优先级必须与安全等级挂钩——DMS涉及驾驶员安全，其帧率不可妥协，而手势识别属于舒适性功能，可以降级；第三，温度反馈必须进入调度决策环——不是等到降频发生后才被动响应，而是根据温度趋势提前调整负载。
1.6 常见误区与总结复盘
在课程开始阶段，有必要澄清几个常见误区，这些误区会在后续实践中导致严重问题：
| 误区 | 错误认知 | 正确理解 |
|---|---|---|
| 误区一 | “多模型调度就是排队执行” | 需要并行化、流水线化、资源域隔离，而非简单串行 |
| 误区二 | “NPU越快，能跑的模型越多” | 内存带宽、热预算、PMIC供电能力同样关键 |
| 误区三 | “温度降频是硬件自动处理的，软件无需关心” | 软件调度策略直接影响温度曲线，好的调度可以避免触发降频 |
| 误区四 | “所有模型都用最高优先级” | 必须区分安全关键型、交互型、后台型，并设置不同降级策略 |