# 方向1: LLM推理图任务调度与混合调度算法 ## 1. 问题陈述 LLM推理是一个**有向无环图(DAG)计算图**,包含多个阶段,每个阶段有不同的: - 计算特征(计算密集 vs IO密集) - 延迟敏感度(TTFT vs TPOT) - 内存访问模式(顺序 vs 随机) - 输出依赖性(串行 vs 可并行) RTOS需要将这个DAG映射为task集合,并设计调度策略保证: 1. **吞吐最大化** — 单位时间内处理最多token 2. **延迟最小化** — TTFT和尾延迟最小 3. **确定性保证** — 满足硬实时约束(如语音对话的<200ms抖动) ### 1.1 本方向在总课题中的角色 本方向聚焦: - 如何把人工智能目标负载拆解为可由 RTOS 管理的任务图; - 如何让人工智能目标负载与关键保障负载在同一系统中同时达标; - 如何把 SylixOS 的调度能力转化为可观测的系统收益与对照差异。 因此,这一方向服务的是总课题中的“任务图建模与调度保障”主线。 ### 1.2 与验证矩阵的对应关系 这一方向在 `T5~T1` 五类部署形态中都成立,但关注重点不同: | 部署形态 | 调度侧重点 | |---|---| | `T5` 控制端 | 小任务集、强实时、极低抖动 | | `T4` 终端设备 | 单路智能任务与本地控制任务并存 | | `T3` 边缘节点 | 多源输入与多任务竞争下的任务图调度 | | `T2` 单机工作站 | 高吞吐推理与关键任务隔离并行 | | `T1` 服务器/集群 | 多请求队列、跨核与跨设备调度协同 | ## 2. LLM推理图的分解 ### 2.1 推理阶段分析 ``` Input Sequence = [SOS, t1, t2, ..., tn, EOS] Phase 1: Prefill (编码阶段) ┌─────────────────────────────────────────────────────┐ │ Tokenizer → Embedding → [Attention + FFN] × N_Layers │ │ 计算量: O(n × d × N_layers) │ │ 延迟: 高(计算密集) │ │ 依赖: 串行(每层依赖上一层) │ │ RTOS优先级: HIGH(影响TTFT) │ └─────────────────────────────────────────────────────┘ Phase 2: Decode (解码阶段, 逐token生成) ┌──────────────────────────────────────────────────────┐ │ [Attention + FFN] × N_Layers → Sample → Next Token │ │ 计算量: O(1 × d × N_layers) per step │ │ 延迟: 中(每步一次全网络推理) │ │ 依赖: 串行(每步依赖上一步输出) │ │ RTOS优先级: HIGH-MEDIUM(影响TPOT) │ │ 特殊: KV Cache写入(IO密集) │ └──────────────────────────────────────────────────────┘ Phase 3: Output (后处理) ┌──────────────────────────────────────────────────────┐ │ Logits → Top-K/Top-P Sample → Detokenize → Output │ │ 计算量: O(1 × vocab_size) │ │ 延迟: 低 │ │ 依赖: 前序Decode完成 │ │ RTOS优先级: LOW │ └──────────────────────────────────────────────────────┘ ``` ### 2.2 阶段特征矩阵 | 阶段 | 计算密集度 | IO密集度 | 延迟敏感度 | 确定性要求 | 推荐RTOS优先级 | |-----|-----------|---------|-----------|-----------|--------------| | Tokenizer | 低 | 中 | 低 | 软实时 | LOW | | Embedding | 高 | 低 | 高 | 硬实时 | HIGH | | Attention | 高 | 高 | 极高 | 硬实时 | MAX | | FFN | 高 | 低 | 高 | 硬实时 | HIGH | | KV Cache Write | 低 | 高 | 中 | 软实时 | MEDIUM | | Sample/Detoken | 低 | 低 | 低 | 软实时 | LOW | ## 3. 调度模型 ### 3.1 Task建模 每个推理阶段建模为RTOS task: ```c typedef struct { uint32_t id; // Task ID char name[32]; // 名称 uint8_t priority; // RTOS优先级 uint32_t wcet; // 最坏执行时间(μs) uint32_t period; // 执行周期(μs) uint32_t deadline; // 截止时间(relative to release) uint32_t memory_footprint; // 内存占用(bytes) uint32_t bandwidth_req; // 内存带宽需求(MB/s) enum task_type { TASK_TOKENIZER, TASK_EMBEDDING, TASK_ATTENTION, TASK_FFN, TASK_KV_CACHE, TASK_SAMPLE, TASK_CONTROL } type; bool preemptible; // 是否可抢占 bool pinned_core; // 是否绑定特定核心 uint8_t target_core; // 绑定的核心ID } llm_task_t; ``` ### 3.2 任务依赖图(DAG) ``` ┌──────────────┐ │ Tokenizer │──→┐ └──────────────┘ │ ├──→┌──────────────┐ ┌──────────────┐ │ │ Embedding │ │ Control │───┤ └──────┬───────┘ └──────────────┘ │ │ ├──→┌──────┴───────┐ │ │ Attention │ │ │ (Layer 1..N) │ │ └──────┬───────┘ │ │ ├──→┌──────┴───────┐ │ │ FFN │ │ │ (Layer 1..N) │ │ └──────┬───────┘ │ │ └────────→┌──────────┐ │ KV Cache │ │ Write │ └────┬─────┘ │ ┌▼──────────┐ │ Sample │ └────┬──────┘ │ ┌▼──────────┐ │ Detoken │ └──────────┘ ``` ### 3.3 调度问题分析 **问题1: 阶段间依赖的延迟** - 每个阶段完成后需等待前一阶段全部完成才能启动 - 串行依赖导致pipeline stall - **RTOS手段**: barrier synchronization, event queue **问题2: KV Cache的内存带宽竞争** - Attention和FFN都大量读取/写入KV Cache - 与tokenizer的输入读取竞争内存带宽 - **RTOS手段**: bandwidth-aware scheduling, DMA batching **问题3: 多beam的调度** - Multi-beam decoding需要同时管理多个beam的task - beam之间优先级相同,但需要保证全局吞吐量 - **RTOS手段**: priority grouping, round-robin within group ## 4. 调度算法设计 ### 4.1 Hybrid Priority Scheduling (混合优先级) 核心思想:不同推理阶段使用不同优先级策略 ``` ┌─────────────────────────────────────────────┐ │ Fixed Priority (硬实时部分) │ │ ┌───────────────────────────────────────┐ │ │ │ MAX: Attention (所有Layer) │ │ │ │ HIGH: FFN, Embedding │ │ │ │ MEDIUM: KV Cache Write │ │ │ │ LOW: Tokenizer, Sample/Detoken │ │ │ └───────────────────────────────────────┘ │ │ │ │ EDF (软实时部分) │ │ ┌───────────────────────────────────────┐ │ │ │ Dynamic Deadline: │ │ │ │ - Next beam's attention deadline │ │ │ │ - Current KV Cache timeout │ │ │ └───────────────────────────────────────┘ │ │ │ │ Preemption Rules: │ │ ┌───────────────────────────────────────┐ │ │ │ Attention can preempt FFN & KV │ │ │ │ KV Cache can be preempted by Attention│ │ │ │ Non-preemptable: Attention computation│ │ │ └───────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ ``` **优先级分配策略**: ```python # 基于延迟敏感度的优先级分配 def assign_priority(stage, deadline_ms): if stage == ATTENTION: return PRIORITY_MAX # 最延迟敏感 elif stage in (FFN, EMBEDDING): return PRIORITY_HIGH elif stage == KV_CACHE_WRITE: return PRIORITY_MEDIUM else: return PRIORITY_LOW # 基于deadline的EDF动态优先级 def edf_priority(task): return -task.deadline # 更早deadline = 更高优先级 (负值越小优先级越高) ``` ### 4.2 流水线并行调度 对于N层Transformer,可以设计Layer-level的pipeline: ``` Time → Layer 1: [Attention][FFN ] Layer 2: [Attention][FFN] Layer 3: [Attention][FFN] ... Layer N: ...[Attention][FFN] ``` **Stage Bubble问题**:Layer间有气泡时间 - **缓解策略**: 1. 将Attention和FFN的task分别独立调度 2. Attention完成即触发FFN,不等同层所有Attention 3. 使用RTOS mutex保护共享数据,减少stall ```c // Layer Pipeline Scheduling void schedule_layer_pipeline(llm_context_t *ctx) { // Step 1: Launch all Attention tasks in parallel for (int layer = 0; layer < N; layer++) { xTaskNotify(layer_attn_task, layer, eIncrement); } // Step 2: Launch FFN for each layer when Attention completes // This is done in RTOS ISR/notify callback // when Attention layer i completes: // xTaskNotify(layer_ffn_task, i, eNoAction); } ``` ### 4.3 多流调度 当同时服务多个请求(batched inference)时: ``` Request A: [Embedding][Attn→FFN]×N → [Attn→FFN]×M_tokens Request B: [Embedding][Attn→FFN]×N → [Attn→FFN]×K_tokens Request C: [Embedding][Attn→FFN]×N → [Attn→FFN]×P_tokens ``` **调度策略**: | 策略 | 描述 | 优点 | 缺点 | |-----|------|-----|-----| | FIFO | 按arrival order处理 | 公平,易实现 | 短请求被长请求阻塞 | | SRTF (Shortest Remaining Time First) | 优先剩余token少的请求 | 平均延迟低 | 长请求可能饿死 | | Priority Queue | 按SLA优先级 | 满足SLA | 需额外管理 | | Round Robin | 轮流处理每个请求 | 公平+低延迟 | 上下文切换开销 | **建议**: SRTF for latency-critical, Priority Queue for SLA guarantee, RR for fairness. ## 5. 实时性分析 ### 5.1 Response Time Analysis (RTA) 对于固定优先级调度,每个task的response time: ``` R_i = C_i + Σ_{j∈hp(i)} ⌈R_j / T_j⌉ × C_j 其中: - R_i: task i的最坏响应时间 - C_i: task i的最坏执行时间(WCET) - hp(i): priority高于i的task集合 - T_j: task j的周期 ``` **LLM特例**:Attention的WCET取决于input sequence length,需要动态计算。 ### 5.2 调度可调度性判据 **Condition 1: 所有Attention任务在deadline前完成** ``` R_attention + overhead ≤ D_attention (typically 50ms for voice) ``` **Condition 2: 吞吐量不饿死低优先级任务** ``` Σ(U_high) < 1 - U_low_margin 其中U_low_margin为低优先级任务预留的CPU时间份额 ``` **Condition 3: 无priority inversion** ``` 使用Priority Inheritance Protocol (PIP)或Enhanced PIP ``` ### 5.3 端到端延迟分析 ``` E2E Latency = max(Prefill Latency, Decode Latency × M) + Overhead 其中: - Prefill Latency = Σ(T_embed + T_attn_l + T_ffn_l for l=1..N) - Decode Latency per token = T_attn + T_ffn + T_kv_write + T_sample - M = output sequence length - Overhead = context_switch + barrier_sync + DMA_transfer ``` ## 6. 各硬件平台的调度差异 ### 6.1 MCU级 (STM32H7等) ``` 约束: - 单核或双核(Cortex-M7 + M4) - 无NPU,纯CPU推理 - RAM 256KB~2MB - 64KB~512KB L1/L2 Cache 调度策略: - 单核: 静态优先级(Fixed Priority) - 多核: 多核固定优先级(MFPA) - 无pipeline,串行执行Attention→FFN - 关键优化: 减少context switch,pin任务到核心 ``` ### 6.2 SoC级 (骁龙/天玑) ``` 约束: - 多核(CPU + NPU + GPU) - NPU驱动封闭,接口有限 - 内存带宽~10GB/s - 存在ISP、Modem等其他实时任务 调度策略: - 异构多核调度(HMP) - CPU负责Control + Attention部分 - NPU负责矩阵乘(FFN/Attention) - 关键挑战: NPU状态不可见,需估算延迟 ``` ### 6.3 Edge盒子 (Jetson等) ``` 约束: - 多CPU Core + 专用NPU - 大内存(8-16GB) - PCIe连接NPU,带宽~16GB/s - 功耗较高(15-60W) 调度策略: - 多核+NPU协同调度 - CUDA Stream可视为RTOS task的扩展 - 可做的调度粒度更细 ``` ### 6.4 Server级 ``` 约束: - NUMA架构,多GPU - PCIe/NVLink互联 - 可做的调度粒度最细 RTOS角色: - 轻量调度器,管理GPU进程 - vLLM等框架已做了大部分调度工作 - RTOS主要提供实时中断响应 ``` ## 7. 本方向的验证关注点 为了让本方向与总课题的双目标评价框架对齐,调度机制至少要回答下面三个问题: 1. 人工智能目标负载的 `TTFT`、`TPOT` 和端到端响应时间是否改善; 2. 关键保障负载的 `deadline miss ratio`、`P99/P99.9 jitter` 是否仍受控; 3. 在多任务并存、到达率变化和伴生竞争负载存在时,系统是否仍保持可解释的调度边界。 ## 8. 关键设计决策 | 决策点 | 选项 | 推荐 | 理由 | |-------|------|-----|------| | 调度策略 | FP / EDF / Hybrid | **Hybrid** | 不同阶段需求不同 | | 抢占策略 | 可抢占 / 不可抢占 | **分级抢占** | Attention可抢占FFN | | 任务粒度 | Stage / Layer / Token | **Stage + Layer** | 平衡调度开销与并行度 | | 核心绑定 | 全局 / 亲和性 / 固定 | **固定绑定** | 减少cache thrashing | | 同步机制 | Semaphore / Mutex / Notify | **Notify + Barrier** | 低开销,实时性可分析 | | 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 | ## 9. 开放研究问题 1. **动态WCET估计**:LLM的WCET随input长度变化,如何在线估计? 2. **Adaptive Priority**:运行时根据系统负载动态调整优先级? 3. **Cross-layer Optimization**:调度与量化精度联合优化? 4. **Predictive Scheduling**:根据输入预测计算量,提前调度? 5. **Fault Tolerance**:任务失败后的recovery调度策略? --- *最后更新: 2026-09-17*