rtos_llm_opt/10-研究框架/01-推理图任务调度.md

方向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：

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│  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

优先级分配策略：

# 基于延迟敏感度的优先级分配
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

// 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