4、推理调度基础：推理任务特性（延迟敏感、批量处理、实时性）、调度器角色与常见调度策略
在 Sleep Mode 唤醒延迟与推理调度平衡的工程实践中，调度器是连接硬件功耗状态与上层推理负载的核心枢纽。唤醒延迟并非孤立存在的硬件参数，而是与推理任务的到达模式、执行时间、优先级以及调度策略深度耦合的系统行为。本章将系统梳理推理任务的三大核心特性——延迟敏感、批量处理与实时性，明确调度器在其中的角色定位，并对比分析常见调度策略的适用场景与权衡点，为后续章节中“延迟-功耗”联合优化奠定理论基础。
4.1 推理任务特性：延迟敏感、批量处理与实时性
推理任务的负载特征直接决定了调度器的设计目标与约束条件。与训练任务不同，推理任务通常具有明确的在线服务属性，其执行时间短、到达频率高、对响应时间敏感。理解任务特性是选择调度策略的前提，也是平衡唤醒延迟与推理效率的基础。
4.1.1 延迟敏感任务（Latency-Sensitive Tasks）
延迟敏感任务以交互式推理为代表，例如语音助手唤醒词检测、实时翻译、自动驾驶目标识别等。这类任务的核心指标是尾延迟（Tail Latency），通常以 P99 或 P999 分位数衡量。用户可感知的延迟阈值因场景而异：语音交互通常要求端到端延迟小于 300ms，而自动驾驶感知模块的推理延迟必须控制在 50ms 以内。延迟敏感任务对调度器的要求是：优先响应、最小化排队时间、避免被长任务阻塞。在 Sleep Mode 场景下，唤醒延迟本身就会叠加到任务响应时间中，因此调度器必须将唤醒开销纳入任务调度决策，例如提前预唤醒或采用预测式唤醒机制。
4.1.2 批量处理任务（Batch Processing Tasks）
批量处理任务以离线分析、数据挖掘、批量图像识别为代表。这类任务对单次延迟不敏感，但追求高吞吐量和资源利用率。批量任务通常具有明确的开始和结束时间，可以容忍等待。调度器在处理批量任务时，可以采用攒批（Batching）策略，将多个小请求合并为一个大请求，利用 GPU 或 NPU 的并行计算能力提高整体效率。然而，攒批策略会引入额外的等待延迟，因此需要设置合理的批大小和最大等待时间，避免延迟敏感任务被过度延迟。
4.1.3 实时性任务（Real-Time Tasks）
实时性任务具有明确的截止时间（Deadline）约束，分为硬实时和软实时两类。硬实时任务（如工业控制、医疗设备）错过截止时间将导致灾难性后果；软实时任务（如视频流处理、在线游戏）错过截止时间只会降低服务质量。实时性任务要求调度器提供可预测的响应时间，通常采用静态优先级或 EDF（Earliest Deadline First）算法。在 Sleep Mode 场景下，实时性任务需要调度器在唤醒延迟与截止时间之间进行精确计算，确保任务在截止时间前完成推理并输出结果。
| 任务类型 | 核心指标 | 典型场景 | 对调度器的要求 | 与Sleep Mode的关系 |
|---|---|---|---|---|
| 延迟敏感 | P99/P999延迟 | 语音助手、在线推荐 | 低排队延迟、快速响应 | 唤醒延迟直接影响用户体验，需预唤醒 |
| 批量处理 | 吞吐量、资源利用率 | 离线分析、批量识别 | 攒批合并、负载均衡 | 可容忍唤醒延迟，利用Sleep Mode节能 |
| 实时性 | 截止时间满足率 | 自动驾驶、工业控制 | 可预测调度、优先级保证 | 需精确计算唤醒延迟与截止时间的关系 |
4.2 调度器的角色定位与核心职责
调度器在推理系统中扮演着“交通警察”的角色，负责协调多个推理任务对计算资源的竞争。其核心职责包括：任务排队、优先级管理、资源分配、功耗状态决策。在 Sleep Mode 场景下，调度器还需要额外承担唤醒决策的职责，即决定何时从低功耗状态唤醒、唤醒哪个处理单元、以及唤醒后如何快速恢复推理流水线。
4.2.1 任务排队与优先级映射
调度器维护一个或多个任务队列，根据任务特性将其映射到不同的优先级层级。例如，延迟敏感任务可以映射到高优先级队列，批量任务映射到低优先级队列。优先级映射需要避免优先级反转问题——即低优先级任务持有高优先级任务所需的资源。在推理场景中，可以通过优先级继承或优先级天花板协议来缓解。
4.2.2 资源分配与负载均衡
调度器需要将任务分配到合适的计算单元（CPU、GPU、NPU 或异构组合）。资源分配需要考虑任务的计算需求、内存带宽、以及各计算单元的当前负载。在 Sleep Mode 场景下，调度器还需要考虑计算单元的功耗状态——例如，将延迟敏感任务分配到已唤醒的计算单元，而将批量任务分配到可以延迟唤醒的计算单元。
4.2.3 功耗状态决策与唤醒管理
这是 Sleep Mode 场景下调度器的独特职责。调度器需要根据任务到达模式、队列长度和延迟要求，决定计算单元进入何种低功耗状态（如浅睡眠、深睡眠、关机），以及何时触发唤醒。唤醒决策需要权衡唤醒延迟与功耗节省。例如，如果预测到未来 10ms 内将有高优先级任务到达，调度器可以选择保持浅睡眠状态（唤醒延迟 1ms），而不是进入深睡眠（唤醒延迟 10ms）。
调度器角色总结：调度器不仅是任务分配器，更是功耗与性能的协调器。在 Sleep Mode 场景下，调度器需要将唤醒延迟作为调度决策的一等公民，而非事后补偿。优秀的调度器应当具备预测能力（基于历史任务到达模式）和自适应能力（根据实时负载调整策略参数）。
4.3 常见调度策略对比与选型
不同的调度策略在延迟、吞吐、公平性和功耗方面各有优劣。以下分析四种常见策略，并给出在 Sleep Mode 场景下的选型建议。
4.3.1 先来先服务（FCFS）与非抢占调度
FCFS 是最简单的调度策略，按照任务到达顺序依次执行。优点是实现简单、公平性好；缺点是短任务可能被长任务阻塞，导致延迟敏感任务体验恶化。在推理场景中，FCFS 仅适用于任务执行时间相对均匀的批量处理场景。在 Sleep Mode 下，FCFS 无法感知任务优先级，可能导致高优先级任务等待低优先级任务完成，从而增加唤醒延迟的负面影响。
4.3.2 优先级抢占调度（Priority Preemptive Scheduling）
每个任务分配一个静态或动态优先级，高优先级任务可以抢占低优先级任务。这种策略能够保证延迟敏感任务的及时响应，但可能引发低优先级任务饥饿问题。在推理场景中，可以通过老化（Aging）机制逐步提升低优先级任务的优先级，避免饥饿。在 Sleep Mode 下，优先级抢占调度需要与唤醒机制配合——当高优先级任务到达时，调度器需要立即唤醒计算单元，即使当前正在执行低优先级任务。
4.3.3 最早截止时间优先（EDF）
EDF 是实时调度中的经典算法，按照任务的绝对截止时间排序，截止时间最早的任务优先执行。EDF 在理论上能够实现最优的 CPU 利用率（对于可抢占的周期性任务），但在过载情况下会出现多米诺效应——多个任务同时错过截止时间。在推理场景中，EDF 适用于具有明确截止时间的实时性任务，但需要精确的任务执行时间估计。在 Sleep Mode 下，EDF 需要将唤醒延迟计入截止时间计算，例如：如果任务截止时间为 T，唤醒延迟为 W，则任务必须在 T-W 时间内开始执行。
4.3.4 批处理合并调度（Batching-Aware Scheduling）
这种策略专门针对批量任务优化，通过攒批、合并、流水线化来提高吞吐量。调度器设置一个批窗口（Batch Window），在窗口内收集到达的任务，达到批大小或窗口超时后统一执行。批处理合并调度可以显著提高 GPU/NPU 利用率，但会增加延迟敏感任务的等待时间。在 Sleep Mode 下，批处理合并调度可以与延迟唤醒结合——在批窗口期间保持低功耗状态，窗口结束时唤醒并执行整个批次。
| 调度策略 | 延迟表现 | 吞吐表现 | 公平性 | Sleep Mode适配度 | 适用场景 |
|---|---|---|---|---|---|
| FCFS | 差（长任务阻塞） | 中 | 好 | 低（无法感知优先级） | 纯批量、任务均匀 |
| 优先级抢占 | 优（高优先级） | 中 | 中（可能饥饿） | 中（需配合预唤醒） | 混合负载、交互式 |
| EDF | 优（截止时间保证） | 中高 | 中 | 高（可精确计算唤醒延迟） | 实时推理、自动驾驶 |
| 批处理合并 | 差（攒批等待） | 优 | 中 | 高（可延迟唤醒） | 离线分析、批量识别 |
4.4 案例拆解：混合负载下的调度策略选型与调优
为帮助理解调度策略的实际应用，以下通过一个智能摄像头 SoC 的推理调度案例，展示如何根据任务特性选择调度策略并优化 Sleep Mode 唤醒延迟。
4.4.1 场景背景与约束
某智能摄像头 SoC 集成了 ISP、NPU 和 CPU，运行三类推理任务：实时目标检测（延迟敏感，P99 < 80ms）、夜间降噪（批量处理，可容忍 500ms 延迟）、异常事件上报（实时性，截止时间 200ms）。SoC 支持 Sleep Mode，浅睡眠唤醒延迟 2ms，深睡眠唤醒延迟 15ms。当前调度器采用 FCFS，导致目标检测任务经常被降噪任务阻塞，P99 延迟达到 150ms，超出规格。
4.4.2 问题分析与策略选型
通过 profiling 发现：降噪任务平均执行时间 80ms，目标检测任务平均执行时间 15ms。FCFS 下，目标检测任务平均等待 40ms，最坏等待 80ms。分析后决定采用优先级抢占调度 + 批处理合并的混合策略：目标检测任务映射到高优先级队列，降噪任务映射到低优先级队列并启用攒批模式（批大小 4，最大等待 100ms），异常上报任务使用 EDF 调度。
4.4.3 实施步骤与参数配置
# 调度器配置示例（伪代码）
scheduler:
policy: hybrid
queues:
- name: high_priority
type: preemptive
tasks: [object_detection]
aging_time: 50ms
- name: low_priority
type: batching
tasks: [denoise]
batch_size: 4
max_wait: 100ms
- name: realtime
type: edf
tasks: [event_report]
deadline_margin: 20ms # 预留唤醒延迟余量
sleep_mode:
shallow_latency: 2ms
deep_latency: 15ms
policy: predictive_wakeup
history_window: 100ms关键调整点：为异常上报任务预留 20ms 的唤醒延迟余量，确保即使从深睡眠唤醒也能满足 200ms 截止时间；目标检测任务采用预唤醒策略，根据历史到达模式提前 2ms 唤醒 NPU。
4.4.4 结果对比与复盘
| 指标 | 优化前（FCFS） | 优化后（混合策略） | 改善幅度 |
|---|---|---|---|
| 目标检测 P99 延迟 | 150ms | 65ms | ↓ 56.7% |
| 降噪任务吞吐量 | 12.5 帧/s | 18 帧/s | ↑ 44% |
| 异常上报截止时间满足率 | 92% | 99.5% | ↑ 7.5% |
| NPU 平均功耗 | 850mW | 620mW | ↓ 27% |
复盘经验：单一调度策略无法满足混合负载需求，必须采用分层混合策略。优先级抢占保证了延迟敏感任务的响应，批处理合并提升了吞吐，EDF 确保了实时性。Sleep Mode 的唤醒延迟必须作为调度参数显式建模，而非事后补偿。预唤醒机制虽然增加了少量功耗，但显著降低了延迟敏感任务的响应时间。
常见误区提醒：
- 误区一：认为调度策略与 Sleep Mode 无关，将两者独立优化。实际上，唤醒延迟是调度决策的一部分，忽略它会导致延迟敏感任务频繁超时。
- 误区二：过度追求吞吐量而采用大攒批窗口，导致延迟敏感任务被阻塞。批窗口必须设置上限，并允许高优先级任务插入。
- 误区三：静态优先级设置后不再调整。任务特性会随负载变化，需要引入动态优先级调整或老化机制。
- 误区四：忽略任务执行时间的波动。EDF 等实时调度算法依赖精确的执行时间估计，实际执行时间波动过大时需预留安全余量。
4.5 总结与设计要点
推理调度是连接任务特性与硬件功耗状态的桥梁。本章的核心结论如下：
- 任务特性决定调度目标：延迟敏感任务追求低尾延迟，批量任务追求高吞吐，实时任务追求截止时间满足率。混合负载需要分层调度策略。
- 调度器是功耗与性能的协调器：在 Sleep Mode 场景下，调度器必须将唤醒延迟作为调度决策的输入参数，而非事后补偿。
- 策略选型需权衡：优先级抢占适合延迟敏感，批处理合并适合吞吐优化，EDF 适合实时保证。实际系统通常采用混合策略。
- 参数调优是持续过程：批窗口大小、优先级层级、唤醒余量等参数需要根据实际负载特征进行在线调优。