eaiadmin
67297c66bf
Consolidate the research materials into numbered overview, framework, planning, partner, deliverable, and archive sections so the repository reflects the current RTOS-focused narrative and reading order.
414 lines
16 KiB
Markdown
414 lines
16 KiB
Markdown
# 方向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*
|