4、多模型调度概念：什么是多模型调度，与单模型推理的区别，典型应用场景（如AR、多任务）
在移动设备上部署深度学习模型时，开发者很快会遇到一个现实问题：真实应用几乎不会只运行一个模型。以智能手机为例，相机预览中的人脸检测、场景识别、超分辨率重建，往往同时或交替运行；AR眼镜需要同时处理SLAM定位、手势识别、物体追踪和渲染优化；智能座舱则要并行处理驾驶员疲劳监测、语音交互和车道线检测。当多个模型共享同一颗SoC（如高通骁龙、联发科天玑）的CPU、GPU、DSP和NPU资源时，如何让它们高效、稳定、低功耗地协同工作，就是多模型调度要解决的核心问题。SNPE（Snapdragon Neural Processing Engine）作为高通平台上的神经网络推理框架，提供了专门的多模型调度能力，帮助开发者在资源受限的移动设备上实现多任务AI应用。
上图展示了SNPE多模型调度的整体框架。从应用场景到底层硬件，调度器处于中间层，负责将多个模型的推理请求映射到CPU、GPU、DSP和NPU等异构计算单元上，同时必须满足功耗和温度约束。理解这一概念的关键在于：多模型调度不是简单的“排队执行”，而是基于资源状态、模型特性和实时约束的动态决策过程。
4.1 核心原理：从单模型推理到多模型调度的范式转变
单模型推理的流程相对简单：加载模型 → 准备输入 → 执行推理 → 返回输出。整个过程只涉及一个计算图，开发者只需关注单个模型的延迟和精度。但在多模型场景下，问题变得复杂得多。假设一个AR应用需要同时运行SLAM（每帧约15ms）、手势识别（每帧约8ms）和物体追踪（每帧约5ms），如果简单地按顺序执行，总延迟将达到28ms，超过16ms的帧预算（60fps），导致画面卡顿。更糟糕的是，如果三个模型同时争抢NPU资源，每个模型的推理时间可能因资源竞争而延长50%以上。
SNPE多模型调度的核心原理可以概括为三个层面：
- 资源感知调度：调度器实时监控各计算单元（CPU/GPU/DSP/NPU）的占用率、频率和温度，将模型分配到最合适的硬件上。例如，将计算密集型的SLAM模型分配到NPU，将I/O密集型的预处理分配到CPU。
- 优先级与抢占：每个模型可以设置优先级（如高、中、低）。高优先级模型（如手势识别用于交互响应）可以抢占低优先级模型（如后台场景分析）的资源，确保关键任务的实时性。
- 时间片轮转与批处理：对于相同硬件上的多个模型，调度器采用时间片轮转或动态批处理（batching）策略，减少上下文切换开销，提高硬件利用率。
SNPE通过zdl::DlSystem::RuntimeList和zdl::SNPE::SNPEBuilder提供多模型管理接口，开发者可以创建多个SNPE实例，并通过zdl::SNPE::SNPE::execute方法在独立线程中执行推理。调度器底层使用高通平台的资源管理框架（如QoS、DDR带宽控制）来协调资源分配。
4.2 判断方法：何时需要多模型调度，如何选择调度策略
并非所有多模型场景都需要复杂的调度。开发者需要根据应用特征判断是否引入调度器，以及选择何种调度策略。下表给出了判断依据和策略选择指南：
| 应用特征 | 单模型推理 | 多模型调度（串行） | 多模型调度（并行/混合） |
|---|---|---|---|
| 模型数量 | 1个 | 2-3个，但执行时间不重叠 | ≥3个，且存在时间重叠 |
| 延迟要求 | 单模型延迟达标即可 | 总延迟 = 各模型延迟之和，需满足帧预算 | 总延迟 ≈ 最长路径延迟，需并行化 |
| 资源占用 | 单一硬件单元 | 可复用同一硬件，但需排队 | 需多个硬件单元协同 |
| 典型场景 | 离线图片分类 | 先检测后识别（两阶段） | AR、实时多任务 |
| 调度复杂度 | 无 | 低（FIFO队列） | 高（需考虑依赖、优先级、资源竞争） |
选择调度策略时，可以遵循以下操作流程：
- 列出所有模型及其执行频率：例如，SLAM每帧执行，手势识别每2帧执行，场景分析每5帧执行。
- 计算总计算量：估算每个模型在目标硬件上的延迟和功耗，累加得到总需求。
- 对比硬件容量：查看NPU、GPU的峰值算力（如TOPS）和内存带宽，判断是否超出限制。
- 确定依赖关系：如果模型B需要模型A的输出作为输入，则必须串行；否则可并行。
- 选择调度模式：在SNPE中，通过
zdl::DlSystem::PerformanceProfile设置性能模式（如HIGH_PERFORMANCE、POWER_SAVER），并通过zdl::DlSystem::MultiThreading配置线程数。
4.3 案例拆解：AR眼镜中的多模型调度实战
我们以一个AR眼镜的实时交互系统为例，展示多模型调度的完整实施过程。该AR眼镜需要同时运行三个模型：SLAM定位（用于追踪用户头部姿态，模型A）、手势识别（用于识别用户点击、滑动等操作，模型B）、语义分割（用于识别环境中的物体，如桌子、椅子，模型C）。硬件平台为高通骁龙XR2芯片，包含1个NPU（算力15 TOPS）、Adreno 650 GPU和Hexagon DSP。
初始现象与目标：在原型机上，三个模型按顺序执行，每帧总延迟达到32ms，远超过16ms的帧预算（60fps），导致画面严重卡顿。目标是将总延迟控制在16ms以内，同时保持NPU温度低于80°C。
关键输入数据：
- 模型A（SLAM）：输入640×480灰度图，NPU延迟12ms，GPU延迟18ms，功耗1.2W
- 模型B（手势识别）：输入320×240 RGB图，NPU延迟6ms，GPU延迟9ms，功耗0.6W
- 模型C（语义分割）：输入1280×720 RGB图，NPU延迟15ms，GPU延迟22ms，功耗1.8W
分析判断过程：三个模型的总NPU需求为12+6+15=33ms，超过单帧16ms预算。但注意到模型B每2帧才执行一次（手势变化频率低），模型C每5帧执行一次（环境变化慢）。因此，实际每帧的NPU平均负载为：12ms（A）+ 6ms×0.5（B）+ 15ms×0.2（C）= 12+3+3=18ms，仍然超标。进一步分析发现，模型C可以降采样到640×480输入，NPU延迟降至8ms，平均负载变为12+3+1.6=16.6ms，接近预算。
实际操作步骤：
- 在SNPE中创建三个SNPE实例，分别加载模型A、B、C的DLC文件。
- 设置模型A为最高优先级（
zdl::DlSystem::Priority::HIGH），模型B为中优先级，模型C为低优先级。 - 将模型A分配到NPU（
Runtime::NPU），模型B分配到GPU（利用GPU的并行能力），模型C分配到NPU但使用低功耗模式（PerformanceProfile::POWER_SAVER）。 - 使用三个独立线程分别执行推理，线程间通过条件变量同步输入数据。
- 在调度器中加入温度监控：当NPU温度超过75°C时，将模型C的推理频率从每5帧降为每10帧。
结果对比：优化后，每帧关键路径延迟为模型A的12ms（NPU）+ 模型B的9ms（GPU，与A并行）= 12ms（因为并行），模型C在后台异步执行，不阻塞主路径。总延迟降至12ms，满足60fps要求。NPU温度稳定在72°C，功耗从3.6W降至2.4W。
风险与代价：模型C的降采样导致分割精度下降约3%（mIoU从0.72降至0.69），但AR场景中可接受。此外，并行调度增加了代码复杂度，需要处理线程同步和资源竞争问题。
4.4 常见误区与总结复盘
在多模型调度的实践中，开发者常陷入以下误区：
- 误区一：所有模型都追求最低延迟。实际上，非交互模型（如背景分析）可以容忍较高延迟，过度优化反而浪费资源。
- 误区二：忽略内存带宽瓶颈。即使NPU算力充足，多个模型同时读取大张量（如4K输入）也会耗尽DDR带宽，导致所有模型变慢。应使用
zdl::DlSystem::TensorShape合理设置输入尺寸。 - 误区三：静态分配硬件不调整。设备温度升高时，NPU频率会下降，原本分配好的模型可能需要迁移到GPU或DSP。SNPE的
zdl::DlSystem::RuntimeFallback机制可以自动降级到CPU，但开发者需提前配置。 - 误区四：忽视模型间的数据依赖。如果模型B需要模型A的输出，但调度器将两者并行执行，会导致数据竞争。必须使用同步原语（如
std::future）确保依赖关系。
总结：多模型调度是移动端AI应用从“单点功能”走向“多任务协同”的必经之路。SNPE提供了灵活的调度接口，但真正的优化需要开发者深入理解应用场景、硬件特性和模型特征。建议从串行调度起步，逐步引入并行和混合调度，并始终将温度控制作为调度决策的重要输入。在实际项目中，建议使用SNPE的性能分析工具（如snpe-net-run和snpe-benchmark）量化每个模型的延迟和功耗，再制定调度策略。