Merge remote-tracking branch 'origin/main' into moyixin-patch-1
# Conflicts: # 10-研究框架/README.md # 项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md # 项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md
This commit is contained in:
Mo1s
@@ -0,0 +1,283 @@
|
||||
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
|
||||
|
||||
## 0. 核心问题
|
||||
|
||||
本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
|
||||
|
||||
> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
|
||||
|
||||
这里有三个基础判断：
|
||||
|
||||
1. **研究对象是实时操作系统平台**；
|
||||
2. **人工智能推理在系统中承担目标负载角色**；
|
||||
3. **硬件条件以验证矩阵形式组织研究证据**。
|
||||
|
||||
本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
|
||||
|
||||
在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，RTOS 对人工智能目标负载与关键保障负载双目标达标能力的支撑边界。
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
|
||||
|
||||
### 1.1 五类部署形态
|
||||
|
||||
`T5~T1` 五类部署形态构成验证环境与证据组织框架。
|
||||
|
||||
| 部署形态 | 系统角色 | 典型环境 | 主要验证重点 |
|
||||
|---|---|---|---|
|
||||
| T5 控制端 | 极紧资源预算下的任务关键控制节点 | MCU、控制器、轻量控制盒 | 强实时、低功耗、极小内存预算 |
|
||||
| T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
|
||||
| T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
|
||||
| T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
|
||||
| T1 服务器 / 集群 | 面向任务关键场景的分布式协同计算平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式协同与规模扩展 |
|
||||
|
||||
这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
|
||||
|
||||
其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
|
||||
|
||||
### 1.2 五种算力基础
|
||||
|
||||
| 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
|
||||
|---|---|---|---|
|
||||
| 控制型算力基础 | 极小内存、低主频、弱加速或无加速 | STM32H7、ESP32-S3、RK3568 控制盒 | 资源极紧、预算刚性、模型必须极小 |
|
||||
| 设备端 SoC 型算力基础 | CPU + NPU/GPU + 统一内存一体化 | RK3588、i.MX93、车规 SoC | 统一内存争抢、驱动封闭、加速器与 CPU 协调 |
|
||||
| 边缘节点型算力基础 | 较大 DDR/显存 + 专用加速器 + 近源部署 | Jetson AGX Orin、IGX、边缘工控机 | 多任务并发、热稳定性、I/O 与 DMA 压力 |
|
||||
| 工作站单机型算力基础 | 多 GPU/加速卡 + 单机大内存 | 4×V100、RTX 工作站、4×H100 单机 | 多卡拓扑、显存分片、单机高密部署 |
|
||||
| 服务器/集群型算力基础 | 多节点 CPU + 多 GPU/NPU + 高速互联 | V100/H100 集群、ARM/x86 集群 | NUMA、跨卡通信、分布式协同调度 |
|
||||
|
||||
### 1.3 三类系统负载
|
||||
|
||||
后续所有设计和评估都以三类负载为基本单元。
|
||||
|
||||
| 负载类型 | 定义 | 典型例子 | 主要评价点 |
|
||||
|---|---|---|---|
|
||||
| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 | 时效性、功能有效性、长时间稳定性 |
|
||||
| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、状态采集、联锁、执行控制 | 截止期、抖动、观测最大响应时间 |
|
||||
| 伴生竞争负载 | 不属于核心功能但会争抢资源的任务 | 日志、更新、后台通信、模型加载、I/O | 干扰强度、资源占用、可隔离性 |
|
||||
|
||||
本研究重点评估：
|
||||
|
||||
> **在人工智能目标负载与关键保障负载并存时，RTOS 对双目标达标能力的支撑效果与成立条件。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 统一技术体系：五层技术栈 + 一条横向治理线
|
||||
|
||||
无论部署形态如何变化，系统描述都统一采用同一套技术栈。
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────┐
|
||||
│ L5 模型与任务语义层 │
|
||||
│ AI 模型、量化、KV Cache 组织、输出质量与服务约束 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L4 运行时与负载编排层 │
|
||||
│ 任务图、队列、准入控制、内存池、流水线、隔离策略 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L3 资源抽象与设备协同层 │
|
||||
│ CPU/NPU/GPU/DMA/PCIe/RDMA 抽象、带宽管理、设备状态暴露 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L2 实时操作系统核心层 │
|
||||
│ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L1 硬件与互联层 │
|
||||
│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联、PTP │
|
||||
└───────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
|
||||
|
||||
### 2.1 这套技术栈的意义
|
||||
|
||||
这套表达用于把三个维度彻底拆开：
|
||||
|
||||
- `T5~T1` 回答**在哪里验证**；
|
||||
- 五种算力基础回答**基于什么资源形态验证**；
|
||||
- 五层技术栈回答**系统内部怎么组织与保障**。
|
||||
|
||||
这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
|
||||
|
||||
### 2.2 人工智能目标负载到 RTOS 任务的映射
|
||||
|
||||
```
|
||||
人工智能目标负载阶段 RTOS 侧任务/事件
|
||||
──────────────── ──────────────────
|
||||
输入处理 / Tokenization → 低优先级辅助任务
|
||||
Embedding / Prefill → 计算密集任务
|
||||
Attention / KV Cache → 延迟敏感任务
|
||||
FFN / 设备计算 → 可流水化计算任务
|
||||
采样 / 输出决策 → 中优先级服务任务
|
||||
结果封装 / 输出通路 → 接口与通信任务
|
||||
```
|
||||
|
||||
关键点在于：
|
||||
|
||||
- 哪些阶段必须优先保障；
|
||||
- 哪些阶段可以延迟或限流；
|
||||
- 哪些资源需要隔离；
|
||||
- 哪些竞争会直接破坏关键保障负载。
|
||||
|
||||
这里还要明确区分两类执行单元：
|
||||
|
||||
- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
|
||||
- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
|
||||
|
||||
---
|
||||
|
||||
## 3. 研究主线：实时保障机制
|
||||
|
||||
项目后续所有子方向都服务于同一个主命题：
|
||||
|
||||
> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
|
||||
|
||||
围绕这个主命题，系统机制可以分为六个方向：
|
||||
|
||||
1. **推理图任务调度**
|
||||
2. **KV Cache 与内存管理**
|
||||
3. **加速器协同调度**
|
||||
4. **量化与精度感知调度**
|
||||
5. **中断与实时性保障**
|
||||
6. **能耗与热管理**
|
||||
|
||||
这六个方向共同服务于一个判断：
|
||||
|
||||
> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
|
||||
|
||||
### 3.1 面向小型化与低功耗方向的应用副课题
|
||||
|
||||
在六个机制方向之外，项目设置一条面向应用落点的专题线：
|
||||
|
||||
> **面向小型化与低功耗方向的应用副课题。**
|
||||
|
||||
这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
|
||||
|
||||
1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
|
||||
2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
|
||||
3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
|
||||
4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
|
||||
|
||||
这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
|
||||
|
||||
- 小型化与低功耗系统是否仍能承载人工智能目标负载；
|
||||
- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
|
||||
- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
|
||||
|
||||
因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
|
||||
|
||||
### 3.2 研究方法总述
|
||||
|
||||
为了回答这个问题，研究方法采用一条统一证据链：
|
||||
|
||||
1. **准入**：先完成设备、测量、加速器、模型与混合负载的 `G0~G4` 准入；
|
||||
2. **对照**：在同硬件、同负载、同预算下组织 `O0/O1/O2/O3` 公平对照；
|
||||
3. **建模**：把系统统一拆成人工智能目标负载、关键保障负载与伴生竞争负载三类负载；
|
||||
4. **机制**：围绕调度、隔离、内存、中断、能耗等机制进行实现与配置；
|
||||
5. **实测**：用双目标达标、长稳、恢复与消融实验验证机制有效性、稳定性与适用边界；
|
||||
6. **跨档位分析**：再把结论放回 `T5~T1` 五类部署形态中观察规律、边界与收窄区间。
|
||||
|
||||
因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。
|
||||
|
||||
这套统一框架统一的是研究对象定义、负载建模、评估指标与对照方法，不预设同一套机制会在所有档位取得同等收益。研究结论将以有效区间、失效边界和贡献来源的形式展开。
|
||||
|
||||
---
|
||||
|
||||
## 4. 评价框架：双目标达标 + 系统协同稳定
|
||||
|
||||
### 4.1 人工智能目标负载指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| `TTFT` | 首 token/首结果响应时间 |
|
||||
| `TPOT` | 连续输出阶段的平均时延 |
|
||||
| 端到端响应时间 | 从请求进入到结果可用的总时长 |
|
||||
| 功能有效性 | 精度、成功率、任务完成率、结果可用性 |
|
||||
| 长时间稳定性 | 长稳运行中的退化、漂移和失败情况 |
|
||||
|
||||
### 4.2 关键保障负载指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| `deadline miss ratio` | 截止期违约比例 |
|
||||
| `P99/P99.9 jitter` | 高频尾部抖动 |
|
||||
| 观测最大响应时间 | 运行窗口内最大响应值 |
|
||||
| 外部接口响应 | GPIO、CAN、RS485、网络回路的端到端响应 |
|
||||
|
||||
### 4.3 系统协同指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| 有效吞吐 | 满足时效与质量约束后的真实吞吐 |
|
||||
| `E/token` / `tokens/J` | 满足约束前提下的能效 |
|
||||
| 温度与热漂移 | 热稳定性及降频影响 |
|
||||
| 恢复能力 | 过载、重启、故障后的恢复时间 |
|
||||
| 公平性与隔离效果 | 多模型、多任务并发下的资源分配行为 |
|
||||
|
||||
因此，本研究的成功标准是：
|
||||
|
||||
> **人工智能目标负载、关键保障负载与系统协同三层指标同时达标。**
|
||||
|
||||
---
|
||||
|
||||
## 5. 对照关系：普通 Linux、PREEMPT_RT 与 RTOS
|
||||
|
||||
后续所有实验和论文叙事都以三层 OS 对照为主线：
|
||||
|
||||
| 对照组 | 含义 | 作用 |
|
||||
|---|---|---|
|
||||
| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
|
||||
| `O1` PREEMPT_RT Linux | 实时增强型通用 OS | 作为最关键的系统对照 |
|
||||
| `O2/O3` SylixOS | 大型跨平台 RTOS 默认与优化配置 | 主实验样例 |
|
||||
|
||||
这条对照线用于区分两类系统收益来源：
|
||||
|
||||
- RTOS 相对普通 Linux 的差异，对应实时性基础带来的系统收益；
|
||||
- RTOS 相对 PREEMPT_RT 的差异，对应专用 RTOS 机制带来的系统收益。
|
||||
|
||||
---
|
||||
|
||||
## 6. 与已有工作的关系
|
||||
|
||||
| 已有工作 | 其关注点 | 与本研究的差异 |
|
||||
|---|---|---|
|
||||
| vLLM / TGI / TensorRT-LLM | 高吞吐推理服务 | 主要关心服务效率，不以任务关键系统为中心 |
|
||||
| 微型模型 / TinyML / 模型压缩 | 压缩模型规模 | 关注模型适配，不解决系统级实时保障 |
|
||||
| 厂商 SDK 调度 | 封闭设备路径 | 缺乏跨平台可分析的 OS 机制比较 |
|
||||
| PREEMPT_RT 相关工作 | 提高 Linux 可预测性 | 很少同时纳入 AI 目标负载与关键保障负载双目标 |
|
||||
|
||||
本研究的独特性体现在：
|
||||
|
||||
1. 把**人工智能目标负载**引入任务关键系统研究；
|
||||
2. 把**大型跨平台实时操作系统**作为研究主角；
|
||||
3. 用 `T5~T1` 五类部署形态与 `11` 个代表档位建立完整验证矩阵；
|
||||
4. 同时比较 **普通 Linux / PREEMPT_RT / RTOS**；
|
||||
5. 用双目标达标和系统协同稳定构成证据链。
|
||||
|
||||
---
|
||||
|
||||
## 7. 文档结构索引
|
||||
|
||||
| 文档 | 内容 |
|
||||
|-----|------|
|
||||
| [01-推理图任务调度.md](01-推理图任务调度.md) | 人工智能目标负载的任务图拆解与调度策略 |
|
||||
| [02-KV-Cache与内存管理.md](02-KV-Cache与内存管理.md) | KV Cache 生命周期、内存池与带宽竞争 |
|
||||
| [03-加速器协同调度.md](03-加速器协同调度.md) | CPU、NPU、GPU、DMA 等异构资源协同 |
|
||||
| [04-量化精度感知调度.md](04-量化精度感知调度.md) | 精度、质量与调度决策联动 |
|
||||
| [05-中断与实时性保障.md](05-中断与实时性保障.md) | 中断路径、线程化、隔离与关键保障负载保护 |
|
||||
| [06-能耗与热管理.md](06-能耗与热管理.md) | 能耗、温度、频率与长时间稳定性 |
|
||||
| [07-方法论与评估工具链.md](07-方法论与评估工具链.md) | 方法论、对照设计、采样与评估工具链 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 预期研究成果
|
||||
|
||||
1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
|
||||
2. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
|
||||
3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
|
||||
4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
|
||||
5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
|
||||
6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
|
||||
7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-21*
|
||||
@@ -0,0 +1,413 @@
|
||||
# 方向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*
|
||||
@@ -0,0 +1,396 @@
|
||||
# 方向2: KV Cache 与内存管理
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
KV Cache是LLM推理中**最大的内存消费者**，也是RTOS内存管理的核心痛点：
|
||||
|
||||
```
|
||||
KV Cache Size ≈ 2 × N_layers × batch_size × seq_len × hidden_dim × 2 bytes
|
||||
|
||||
Example (Qwen2.5-7B, batch=32, seq_len=4096):
|
||||
= 2 × 32 × 32 × 4096 × 4096 × 2 bytes
|
||||
≈ 6.8 GB
|
||||
|
||||
Example (Qwen2.5-1.5B, batch=8, seq_len=2048):
|
||||
= 2 × 32 × 8 × 2048 × 2048 × 2 bytes
|
||||
≈ 2.2 GB
|
||||
```
|
||||
|
||||
RTOS场景下KV Cache管理的关键问题：
|
||||
1. **内存碎片** — 频繁分配/释放导致碎片化
|
||||
2. **带宽竞争** — KV读写与计算同时竞争DDR
|
||||
3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
|
||||
4. **多请求KV Cache隔离** — 多流场景下的内存隔离与复用
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何让人工智能目标负载在受限容量下保持可持续服务；
|
||||
- 如何避免 KV Cache 动态增长破坏关键保障负载的实时边界；
|
||||
- 如何把内存确定性、带宽隔离和准入控制纳入 SylixOS 的实时保障机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“容量边界与内存确定性”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
KV Cache 与内存管理在 `T5~T1` 中的约束差异很大，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 内存管理侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 极低内存预算下的模型裁剪与静态预分配 |
|
||||
| `T4` 终端设备 | 小模型多会话下的碎片与带宽竞争 |
|
||||
| `T3` 边缘节点 | 多请求并发下的 KV 隔离与带宽准入 |
|
||||
| `T2` 单机工作站 | 大上下文与高吞吐下的容量边界 |
|
||||
| `T1` 服务器/集群 | NUMA、多设备与跨节点缓存协同 |
|
||||
|
||||
## 2. KV Cache结构分析
|
||||
|
||||
### 2.1 KV Cache布局
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ KV Cache Layout │
|
||||
│ │
|
||||
│ Layer 0: [K_0 | V_0] → Shape: [batch, head, seq, hd] |
|
||||
│ Layer 1: [K_1 | V_1] → Shape: [batch, head, seq, hd] |
|
||||
│ ... │
|
||||
│ Layer N: [K_N | V_N] → Shape: [batch, head, seq, hd] |
|
||||
│ │
|
||||
│ Total = 2 × N_layers × batch × seq × hidden × dtype |
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
Attention计算公式:
|
||||
Output = Softmax(QK^T / √d_k) × V
|
||||
|
||||
Q, K, V均为实时维护的Tensor。推理过程中：
|
||||
- Prefill阶段: K, V一次性填充
|
||||
- Decode阶段: K, V逐tokenappend
|
||||
```
|
||||
|
||||
### 2.2 KV Cache的内存访问特征
|
||||
|
||||
```
|
||||
Access Pattern | Read | Write | Latency | Bandwidth
|
||||
------------------------|-------|-------|---------|----------
|
||||
Prefill K/V init | Low | High | Low | Very High
|
||||
Decode K append | High | Medium| Medium | Medium
|
||||
Attention QK^T | High | Low | Medium | High
|
||||
Attention SV | High | High | Medium | High
|
||||
```
|
||||
|
||||
**关键洞察**：Attention是 **memory-bound** 的，内存带宽比计算算力更容易成为瓶颈。
|
||||
|
||||
## 3. 内存管理策略
|
||||
|
||||
### 3.1 Memory Pool 设计
|
||||
|
||||
**核心思路**：为KV Cache预分配固定大小的内存池，避免运行时malloc/free。
|
||||
|
||||
```c
|
||||
// KV Cache Memory Pool
|
||||
typedef struct {
|
||||
uint8_t *base; // 内存池基地址
|
||||
size_t total_size; // 总大小
|
||||
size_t used_size; // 已使用
|
||||
size_t max_block; // 最大block大小
|
||||
uint32_t n_blocks; // block数量
|
||||
uint32_t *free_map; // 空闲块位图
|
||||
uint32_t alloc_count; // 当前分配次数
|
||||
} kv_cache_pool_t;
|
||||
|
||||
// Block结构 — 每个layer一个block
|
||||
typedef struct {
|
||||
struct kv_cache_pool_t *pool;
|
||||
uint8_t *data; // 数据指针
|
||||
size_t size; // 大小
|
||||
uint32_t layer_id; // 所属layer
|
||||
uint32_t batch_id; // 所属batch
|
||||
bool locked; // 是否锁定(防释放)
|
||||
} kv_block_t;
|
||||
```
|
||||
|
||||
**Pool设计决策**：
|
||||
|
||||
| 策略 | 描述 | 优点 | 缺点 |
|
||||
|-----|------|-----|-----|
|
||||
| **Fixed-size pool** | 预分配固定大小，不动态扩容 | 零碎片，O(1)分配 | 可能浪费或不够用 |
|
||||
| **Buddy system** | powers-of-2分块 | 低碎片 | 内碎片最多50% |
|
||||
| **Slab allocator** | 预分配固定类型cache | 高效同类分配 | 不同size需多个slab |
|
||||
| **Region pool** | 按请求分配region | 便于多请求隔离 | region间可能碎片 |
|
||||
|
||||
**推荐**: 在嵌入式场景用Fixed-size pool，在边缘场景用Slab + Region组合。
|
||||
|
||||
### 3.2 分层KV Cache管理
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────┐
|
||||
│ L1: SRAM Cache (芯片内, ~100KB) │
|
||||
│ 最近访问的KV block, 超低延迟(<10ns) │
|
||||
│ 策略: LRU, hardware-managed │
|
||||
├──────────────────────────────────────────────┤
|
||||
│ L2: DDR Memory Pool (RAM, 2-8GB) │
|
||||
│ 所有KV Cache, 中延迟(~100ns) │
|
||||
│ 策略: Slab allocator + region per request │
|
||||
├──────────────────────────────────────────────┤
|
||||
│ L3: Flash/SSD (持久化, 10-100GB) │
|
||||
│ 冷KV Cache, 高延迟(~100μs) │
|
||||
│ 策略: 按需swap, 预读 │
|
||||
└──────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.3 多请求KV Cache隔离
|
||||
|
||||
```
|
||||
Request A: [Layer 0 Block | Layer 1 Block | ...] → Pool Region A
|
||||
Request B: [Layer 0 Block | Layer 1 Block | ...] → Pool Region B
|
||||
Request C: [Layer 0 Block | Layer 1 Block | ...] → Pool Region C
|
||||
|
||||
Region管理:
|
||||
┌──────────┬──────────┬──────────┬──────────┐
|
||||
│ Region A │ Region B │ Region C │ Free │
|
||||
│ 256MB │ 128MB │ 256MB │ 512MB │
|
||||
└──────────┴──────────┴──────────┴──────────┘
|
||||
|
||||
每个Region包含:
|
||||
- Header: 大小、引用计数、是否锁定
|
||||
- Data: KV Cache数据
|
||||
- Metadata: 序列长度、是否有效、引用task
|
||||
```
|
||||
|
||||
## 4. 内存带宽优化
|
||||
|
||||
### 4.1 带宽竞争模型
|
||||
|
||||
```
|
||||
总带宽 = DDR Bandwidth (e.g., LPDDR5: 6400 Mbps × 4 = 25.6 GB/s)
|
||||
|
||||
带宽分配:
|
||||
KV Cache Read (Attention): █████████████████████ 40%
|
||||
KV Cache Write (Append): ████████████ 25%
|
||||
Weight Read (FFN/Attn): ████████████████████ 30%
|
||||
Input/Output: ████████ 5%
|
||||
|
||||
问题: KV Cache读+写 = 65% 带宽
|
||||
加上Weight Read = 95% 带宽
|
||||
仅剩5% 给其他任务
|
||||
```
|
||||
|
||||
### 4.2 带宽调度策略
|
||||
|
||||
**策略1: 错峰访问**
|
||||
|
||||
```
|
||||
Time →
|
||||
KV Cache Write: [████████][ ][████████]
|
||||
Weight Read: [ ][████████████][ ]
|
||||
Input/Output: [███████][ ][ ]
|
||||
t0 t1 t2
|
||||
```
|
||||
|
||||
**策略2: DMA Batching**
|
||||
|
||||
```
|
||||
Before (no batching):
|
||||
KV Write 1 → DMA → DDR (small chunk)
|
||||
KV Write 2 → DMA → DDR (small chunk)
|
||||
KV Write 3 → DMA → DDR (small chunk)
|
||||
Total DMA overhead: 3 × overhead
|
||||
|
||||
After (batching):
|
||||
KV Write 1,2,3 → DMA burst → DDR (large chunk)
|
||||
Total DMA overhead: 1 × overhead
|
||||
|
||||
RTOS实现:
|
||||
1. KV Write task将多个小DMA请求放入队列
|
||||
2. DMA Controller task批量处理
|
||||
3. 使用RTOS queue传递DMA描述符
|
||||
```
|
||||
|
||||
**策略3: Bandwidth-aware Scheduling**
|
||||
|
||||
```c
|
||||
typedef struct {
|
||||
uint64_t bandwidth_allocated; // 已分配带宽
|
||||
uint64_t bandwidth_used; // 已使用带宽
|
||||
uint64_t peak_bandwidth; // 峰值带宽
|
||||
uint64_t window_ms; // 滑动窗口大小
|
||||
} bandwidth_tracker_t;
|
||||
|
||||
// 任务请求带宽时的检查
|
||||
bool can_allocate_bandwidth(task_t *task, uint64_t required_bw) {
|
||||
if (bandwidth_tracker.used + required_bw <= BANDWIDTH_LIMIT) {
|
||||
bandwidth_tracker.used += required_bw;
|
||||
return true;
|
||||
}
|
||||
// 等待或排队
|
||||
vTaskSuspend(task);
|
||||
return false;
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 In-Place KV Update
|
||||
|
||||
减少KV Cache的write bandwidth：
|
||||
|
||||
```
|
||||
Before (old):
|
||||
for each new token:
|
||||
allocate new KV block // 分配+写
|
||||
write new KV values // 写
|
||||
update pointer // 写
|
||||
|
||||
After (in-place):
|
||||
for each new token:
|
||||
KV_buffer += step_size // 指针移动(O(1))
|
||||
write KV values in-place // 只写一次
|
||||
```
|
||||
|
||||
**实现要点**：
|
||||
- 预分配连续的KV内存(避免碎片)
|
||||
- 使用环形buffer管理seq_len(自然复用)
|
||||
- 维护valid长度指针，不实际移动数据
|
||||
|
||||
## 5. KV Cache替换策略
|
||||
|
||||
### 5.1 缓存淘汰算法
|
||||
|
||||
```
|
||||
当KV Cache满时，需要选择替换策略：
|
||||
|
||||
策略 | 复杂度 | 命中率 | 适用场景
|
||||
----------------------|--------|--------|---------
|
||||
LRU | O(1) | Good | 通用
|
||||
LFU | O(log n)| Better | 长对话
|
||||
Sliding Window | O(1) | Good | 固定上下文
|
||||
Hybrid (Window+LFU) | O(1) | Best | 生产环境
|
||||
```
|
||||
|
||||
**RTOS友好实现** (LRU with doubly-linked list):
|
||||
|
||||
```c
|
||||
typedef struct kv_cache_node {
|
||||
uint32_t layer;
|
||||
uint32_t token_pos;
|
||||
struct kv_cache_node *prev;
|
||||
struct kv_cache_node *next;
|
||||
uint8_t *data;
|
||||
uint64_t last_access;
|
||||
} kv_cache_node_t;
|
||||
|
||||
// LRU: 访问时移动到链表头部
|
||||
void kv_cache_access(uint32_t layer, uint32_t pos) {
|
||||
kv_cache_node_t *node = find_node(layer, pos);
|
||||
if (node) {
|
||||
node->last_access = get_tick_ms();
|
||||
move_to_head(&lru_list, node); // O(1)
|
||||
}
|
||||
}
|
||||
|
||||
// Evict: 从链表尾部淘汰
|
||||
void kv_cache_evict(void) {
|
||||
kv_cache_node_t *victim = lru_list.tail;
|
||||
remove_from_list(victim);
|
||||
free_block(victim);
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 压缩策略
|
||||
|
||||
```
|
||||
策略 | 压缩比 | 精度损失 | 带宽节省 | 计算开销
|
||||
--------------|--------|----------|----------|---------
|
||||
Float16 | 1.0x | 0% | 基准 | 无
|
||||
Int8 | 2.0x | ~2% | 50% | 低
|
||||
Int4 | 4.0x | ~5% | 75% | 中
|
||||
Sparsification| 2-8x | 1-10% | 50-87% | 中-高
|
||||
Paged KV | variable| 0% | variable | 低
|
||||
```
|
||||
|
||||
## 6. 各硬件平台的内存管理差异
|
||||
|
||||
### 6.1 MCU级 (256KB~2MB)
|
||||
|
||||
```
|
||||
约束:
|
||||
- 内存极小，无法容纳完整KV Cache
|
||||
- 通常只支持一个请求
|
||||
- 模型参数也需压缩
|
||||
|
||||
策略:
|
||||
- KV Cache固定大小(如256 token)
|
||||
- 使用连续内存池，零碎片
|
||||
- KV Cache满后触发OOM处理(丢弃 oldest)
|
||||
- 可能需要在Flash上swap
|
||||
```
|
||||
|
||||
### 6.2 SoC级 (2-8GB)
|
||||
|
||||
```
|
||||
约束:
|
||||
- 内存有限但可容纳小模型KV Cache
|
||||
- 多请求时内存竞争严重
|
||||
- NPU有独立的memory pool
|
||||
|
||||
策略:
|
||||
- 分区管理: CPU pool + NPU pool
|
||||
- 使用Paged Memory (类似vLLP)
|
||||
- NPU-Shared Memory通过DMA同步
|
||||
```
|
||||
|
||||
### 6.3 Edge盒子 (8-16GB)
|
||||
|
||||
```
|
||||
约束:
|
||||
- 内存充足但带宽可能受限
|
||||
- 多请求+大模型场景
|
||||
|
||||
策略:
|
||||
- 分层缓存: SRAM(热点) + DDR(主流) + SSD(冷数据)
|
||||
- 预读策略: 预测下一个token的KV位置
|
||||
- 多流隔离: CGroup级别内存限制
|
||||
```
|
||||
|
||||
### 6.4 Server级
|
||||
|
||||
```
|
||||
约束:
|
||||
- 内存充足(NVMe/DDR)
|
||||
- 主要问题是带宽和NUMA
|
||||
|
||||
策略:
|
||||
- NUMA-aware KV placement
|
||||
- NVMe作为KV Cache扩展
|
||||
- 多GPU间KV Cache同步
|
||||
```
|
||||
|
||||
## 7. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，KV Cache 与内存管理至少要回答下面三个问题：
|
||||
|
||||
1. 人工智能目标负载在不同上下文长度和并发度下是否仍保持可接受的 `TTFT`、`TPOT` 与成功率；
|
||||
2. 关键保障负载是否因内存碎片、带宽争用或回收抖动而出现 `deadline miss` 或尾部抖动放大；
|
||||
3. 内存池、分页、压缩和准入机制是否建立了可预测的容量边界与准入边界。
|
||||
|
||||
## 8. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
| 内存分配器 | malloc/free / Pool / Slab | **Slab + Region** | 零碎片+多请求隔离 |
|
||||
| KV Cache布局 | 连续 / Paged / Sparse | **Paged** | 灵活+低碎片 |
|
||||
| 替换策略 | LRU / LFU / Sliding | **Sliding Window** | 计算复杂度O(1) |
|
||||
| 压缩策略 | FP16 / Int8 / Int4 | **Int8** | 精度-带宽权衡最优 |
|
||||
| 带宽管理 | 固定分配 / 动态 | **Bandwidth-aware** | 避免带宽饱和 |
|
||||
| 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
|
||||
|
||||
## 9. 开放研究问题
|
||||
|
||||
1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
|
||||
2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？
|
||||
3. **KV Cache Compression**: 有损压缩的RTOS友好实现？
|
||||
4. **Predictive Allocation**: 预测最大seq_len，预分配最优大小？
|
||||
5. **KV Cache Migration**: 请求迁移时的KV Cache热迁移？
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,457 @@
|
||||
# 方向3: 加速器协同调度 (CPU + NPU/GPU)
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
任务关键系统中的人工智能目标负载往往依赖专用加速器(NPU/GPU/DSP)与 CPU 协同完成计算。RTOS 需要协调 CPU 与加速器协同工作。核心问题：
|
||||
|
||||
1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
|
||||
2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
|
||||
3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
|
||||
4. **同步开销**: barrier/semaphore的实时性分析复杂
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何让 RTOS 对人工智能目标负载的设备计算阶段建立可管理的节拍；
|
||||
- 如何避免 CPU、加速器、DMA 和中断之间的协同开销侵蚀关键保障负载边界；
|
||||
- 如何把异构设备协同从黑盒调用，转化为可分析、可限流、可恢复的系统机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“设备协同与异构执行可预测性”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
加速器协同在 `T5~T1` 中的实现方式差异很大，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 加速器协同侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 无加速器或轻量 DSP/NPU 下的简化协同 |
|
||||
| `T4` 终端设备 | SoC 内 CPU 与片上 NPU 的同步与拷贝开销 |
|
||||
| `T3` 边缘节点 | 多核 CPU 与外设/NPU/GPU 的流水线协同 |
|
||||
| `T2` 单机工作站 | CPU 与独立 GPU 的队列、DMA 与中断协同 |
|
||||
| `T1` 服务器/集群 | 多 GPU、多 NUMA 域与多进程协同执行 |
|
||||
|
||||
## 2. 加速器架构分析
|
||||
|
||||
### 2.1 常见加速器类型
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Accelerator Types │
|
||||
├──────────────────┬───────────────────────────────────┤
|
||||
│ NPU │ Neural Processing Unit │
|
||||
│ │ • 专为矩阵乘设计 │
|
||||
│ │ • 低精度(INT8/FP16) │
|
||||
│ │ • 固定function, 可编程interface │
|
||||
│ │ 例: 骁龙Hexagon, RK3588 NPU │
|
||||
├──────────────────┼───────────────────────────────────┤
|
||||
│ GPU │ Graphics Processing Unit │
|
||||
│ │ • 通用并行计算 │
|
||||
│ │ • 高带宽, 高功耗 │
|
||||
│ │ • 成熟软件栈(CUDA/OpenCL) │
|
||||
│ │ 例: Adreno, Mali, PowerVR │
|
||||
├──────────────────┼───────────────────────────────────┤
|
||||
│ DSP │ Digital Signal Processor │
|
||||
│ │ • 向量/标量并行 │
|
||||
│ │ • 低功耗, 适合小模型 │
|
||||
│ │ 例: Hexagon DSP, Kryo │
|
||||
├──────────────────┼───────────────────────────────────┤
|
||||
│ DPU │ Deep Learning Processing Unit │
|
||||
│ │ • 固定功能, 低延迟 │
|
||||
│ │ • 适合known architecture │
|
||||
│ │ 例: Xilinx DPU, 平头哥玄铁 │
|
||||
└──────────────────┴───────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 CPU-加速器通信路径
|
||||
|
||||
```
|
||||
CPU Accelerator
|
||||
┌─────────────┐ ┌──────────────┐
|
||||
│ │ DMA/Bus │ │
|
||||
│ Task Queue │─────────────→│ Command Q │
|
||||
│ │ │ │
|
||||
│ Memory │←──DMA/Bus───│ Memory │
|
||||
│ Pool │ │ Pool │
|
||||
│ │ │ │
|
||||
│ Event Q │←────────────│ Interrupt │
|
||||
└─────────────┘ └──────────────┘
|
||||
|
||||
通信机制:
|
||||
1. Shared Memory: 零拷贝，通过DMA传递数据
|
||||
2. Command Queue: CPU写入命令，加速器执行后完成
|
||||
3. Interrupt: 加速器完成后的异步通知
|
||||
4. Memory Barrier: 保证CPU和加速器看到的内存一致性
|
||||
```
|
||||
|
||||
## 3. 协同调度模型
|
||||
|
||||
### 3.1 典型LLM推理的CPU-加速器交互
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Phase: Prefill (Batch Inference) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ CPU: Accelerator: │
|
||||
│ ┌──────────┐ ┌──────────────────┐ │
|
||||
│ │Tokenizer │ DMA→ │ │ │
|
||||
│ └──────────┘ │ Embedding │ │
|
||||
│ ↓ └────────┬─────────┘ │
|
||||
│ ┌──────────┐ ┌────────┴─────────┐ │
|
||||
│ │Control │──Cmd──→ │ Attention L1..N │ │
|
||||
│ │ (plan) │ └────────┬─────────┘ │
|
||||
│ └──────────┘ ┌────────┴─────────┐ │
|
||||
│ ↓ │ FFN L1..N │ │
|
||||
│ ┌──────────┐ └────────┬─────────┘ │
|
||||
│ │Monitor │←──IRQ──│ │ │
|
||||
│ │ (wait) │ ┌────────────┐│
|
||||
│ └──────────┘ ┌───────────────────┐│ Output ││
|
||||
│ │ KV Cache Write │└─────┬──────┘│
|
||||
│ └───────────────────┘ │ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
|
||||
Timeline:
|
||||
CPU: | Tokenize | Plan | Wait | Monitor | Process Output |
|
||||
NPU: |-------- Embedding + Layers + Output --------|
|
||||
Time: 5ms 20ms (NPU compute) 5ms
|
||||
Total E2E: ~30ms (mostly dominated by NPU)
|
||||
```
|
||||
|
||||
### 3.2 解码阶段的流水线
|
||||
|
||||
```
|
||||
Decode Phase (逐token生成):
|
||||
|
||||
Step i: Step i+1:
|
||||
───────── ─────────
|
||||
CPU: Send Cmd NPU: Execute Layer 1..N
|
||||
Wait ←───────────────→ CPU: Send Cmd
|
||||
NPU: Execute Layer 1..N
|
||||
|
||||
问题: CPU SendCmd 和 NPU Execute 之间有gap
|
||||
原因: NPU完成前CPU需等待
|
||||
|
||||
优化: Double Buffering
|
||||
──────────────────────────────
|
||||
CPU: Send(i) Send(i+1) Send(i+2)
|
||||
NPU: Exec(i) Exec(i+1) Exec(i+2)
|
||||
|
||||
实现:
|
||||
- 两个buffer: buf_A, buf_B
|
||||
- CPU写buf_A时，NPU读buf_A
|
||||
- 完成后swap: CPU写buf_B，NPU读buf_B
|
||||
- 需要RTOS semaphore管理buffer swap
|
||||
```
|
||||
|
||||
## 4. 同步与通信机制
|
||||
|
||||
### 4.1 同步原语
|
||||
|
||||
```c
|
||||
// NPU协同同步原语
|
||||
typedef struct {
|
||||
// 命令同步
|
||||
SemaphoreHandle_t cmd_complete; // 命令完成信号
|
||||
SemaphoreHandle_t data_ready; // 数据就绪信号
|
||||
|
||||
// 双缓冲管理
|
||||
uint8_t *buffers[2]; // 双buffer
|
||||
uint8_t active_buf; // 当前active buffer
|
||||
SemaphoreHandle_t buf_swap; // buffer交换信号
|
||||
|
||||
// 事件通知
|
||||
EventGroupHandle_t events; // 事件组
|
||||
} npu_sync_t;
|
||||
|
||||
// 同步流程
|
||||
void npu_sync_wait(npu_sync_t *sync) {
|
||||
// 等待NPU完成当前命令
|
||||
xSemaphoreTake(sync->cmd_complete, portMAX_DELAY);
|
||||
// 交换buffer
|
||||
xSemaphoreTake(sync->buf_swap, portMAX_DELAY);
|
||||
}
|
||||
|
||||
void npu_sync_signal(npu_sync_t *sync) {
|
||||
// NPU完成中断回调
|
||||
xSemaphoreGiveFromISR(sync->cmd_complete, NULL);
|
||||
xSemaphoreGiveFromISR(sync->buf_swap, NULL);
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 中断处理策略
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ Interrupt Hierarchy │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ Level 0: Hard IRQ (NPU完成中断) │
|
||||
│ 动作: 提升task优先级, 触发barrier │
|
||||
│ 时间: <10μs │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ Level 1: SW IRQ (NPU驱动层) │
|
||||
│ 动作: 释放semaphore, 唤醒task │
|
||||
│ 时间: <50μs │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ Level 2: Soft IRQ (任务调度) │
|
||||
│ 动作: 调度下一个task │
|
||||
│ 时间: <100μs │
|
||||
└─────────────────────────────────────────────┘
|
||||
|
||||
关键设计:
|
||||
- NPU完成中断 → 直接唤醒attention task (不经过软中断)
|
||||
- 使用Interrupt-to-Semaphore模式, 避免context switch开销
|
||||
- 中断处理函数最小化, 尽量defer到task层
|
||||
```
|
||||
|
||||
## 5. 调度策略
|
||||
|
||||
### 5.1 Pipeline并行调度
|
||||
|
||||
```
|
||||
Layer Pipeline (各层在加速器上流水执行):
|
||||
|
||||
Layer: L1 L2 L3 L4
|
||||
[Attn][FFN][Attn][FFN][Attn][FFN][Attn][FFN]
|
||||
CPU: [Plan] [Plan] [Plan] [Plan] [Collect]
|
||||
Time: ↓ ↓ ↓ ↓
|
||||
|
||||
Scheduling:
|
||||
1. CPU先plan Layer 1的Attention
|
||||
2. L1 Attn执行时, CPU plan L2 Attn
|
||||
3. L1 Attn完成 → L1 FFN启动
|
||||
4. CPU plan L3 Attn
|
||||
...
|
||||
|
||||
RTOS实现:
|
||||
- 每个Layer的Attn/FFn是一个task
|
||||
- CPU上跑"planner" task
|
||||
- 加速器上跑"compute" task
|
||||
- 通过barrier同步相邻Layer
|
||||
```
|
||||
|
||||
### 5.2 Cross-device Scheduling (多加速器)
|
||||
|
||||
```
|
||||
Example: SoC with both NPU + GPU
|
||||
|
||||
Request A: Large matrix → NPU (矩阵乘优化)
|
||||
Request B: Conv/Embed → GPU (并行度高)
|
||||
Request C: Small ops → DSP (低功耗)
|
||||
|
||||
调度问题:
|
||||
- 哪个加速器处理哪个请求?
|
||||
- 资源冲突时如何仲裁?
|
||||
- 数据在设备间传输的开销?
|
||||
|
||||
调度策略:
|
||||
1. Capability-based: 根据加速器能力分配
|
||||
2. Load-based: 根据当前负载分配
|
||||
3. Hybrid: capability + load
|
||||
|
||||
RTOS实现:
|
||||
typedef struct {
|
||||
enum accel_type { ACCEL_NPU, ACCEL_GPU, ACCEL_DSP } type;
|
||||
uint32_t utilization; // 当前利用率
|
||||
uint32_t queue_depth; // 排队深度
|
||||
uint64_t avg_latency_us; // 平均延迟
|
||||
SemaphoreHandle_t lock; // 资源锁
|
||||
QueueHandle_t cmd_queue; // 命令队列
|
||||
} accel_resource_t;
|
||||
|
||||
accel_resource_t* select_accelerate(task_t *task) {
|
||||
// 1. Filter by capability
|
||||
if (task->compute_type == MATRIX_MUL) return npu;
|
||||
if (task->compute_type == CONV) return gpu;
|
||||
|
||||
// 2. Pick least loaded
|
||||
return min_utilization(all_accelerators);
|
||||
}
|
||||
```
|
||||
|
||||
### 5.3 Async Pipeline Scheduling
|
||||
|
||||
```
|
||||
CPU side (RTOS task):
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Task: NPU Dispatcher (priority: HIGH) │
|
||||
│ │
|
||||
│ while (running) { │
|
||||
│ cmd = dequeue_command(); │
|
||||
│ send_to_npu(cmd); │
|
||||
│ wait_for_irq(); │ // 阻塞等待
|
||||
│ if (complete) { │
|
||||
│ process_result(); │
|
||||
│ dispatch_next(); │
|
||||
│ } │
|
||||
│ } │
|
||||
└────────────────────────────────────────────┘
|
||||
|
||||
NPU side (hardware):
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Command Queue (FIFO): │
|
||||
│ ├─ Cmd 1: Attention Layer 1 │
|
||||
│ ├─ Cmd 2: FFN Layer 1 │
|
||||
│ ├─ Cmd 3: Attention Layer 2 │
|
||||
│ └─ ... │
|
||||
│ │
|
||||
│ Execution: Sequential (FIFO) or │
|
||||
│ Out-of-order (with dependencies)│
|
||||
└────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 6. 数据传输优化
|
||||
|
||||
### 6.1 DMA策略
|
||||
|
||||
```
|
||||
传输类型 | 策略 | 优化手段
|
||||
---------------------|------------------------|------------------
|
||||
CPU→NPU (weights) | 一次性批量DMA | PCIe burst
|
||||
CPU→NPU (input) | 流水线DMA | 预读
|
||||
NPU→CPU (output) | 完成中断+DMA pull | 零拷贝
|
||||
NPU→NPU (cross) | 共享内存 + cache sync | invalidate+clean
|
||||
|
||||
DMA Descriptor设计:
|
||||
typedef struct {
|
||||
uint32_t src_addr; // 源地址
|
||||
uint32_t dst_addr; // 目的地址
|
||||
uint32_t size; // 传输大小
|
||||
uint32_t flags; // 同步/异步/中断
|
||||
uint32_t completion_irq; // 完成后是否触发中断
|
||||
uint32_t next_desc; // 链式DMA描述符
|
||||
} dma_desc_t;
|
||||
|
||||
// 链式DMA: 多个描述符连成链, 一次性提交
|
||||
// 减少RTOS调用次数, 提高DMA效率
|
||||
void dma_chain_submit(dma_desc_t *head) {
|
||||
// Submit chain to DMA controller
|
||||
// No RTOS calls needed during transfer
|
||||
// Only interrupt on last descriptor
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2 零拷贝技术
|
||||
|
||||
```
|
||||
Before:
|
||||
CPU alloc: malloc(input) // 分配
|
||||
memcpy: copy(input) // 拷贝到临时buffer
|
||||
DMA: transfer(temp) // DMA从temp传输
|
||||
Total: 2 copies + 1 DMA
|
||||
|
||||
After (zero-copy):
|
||||
CPU alloc: mmap(shared_mem) // 共享内存
|
||||
Direct: write(shared) // CPU直接写
|
||||
DMA: transfer(shared) // DMA直接从shared传输
|
||||
Total: 0 copies + 1 DMA
|
||||
|
||||
RTOS实现:
|
||||
- 使用mmap或共享内存驱动
|
||||
- CPU和NPU使用同一块物理内存
|
||||
- 通过memory barrier保证一致性
|
||||
- 使用RTOS semaphore管理访问权限
|
||||
```
|
||||
|
||||
## 7. 各平台的加速器协同差异
|
||||
|
||||
### 7.1 MCU级
|
||||
|
||||
```
|
||||
典型: STM32H7 + Cortex-M7 (CPU) + DSP (协处理器)
|
||||
- 无NPU, 纯CPU/DSP矩阵运算
|
||||
- 共享SRAM, 无DMA或简单DMA
|
||||
- 协同简单: CPU调用DSP函数, 等待完成
|
||||
|
||||
关键优化:
|
||||
- DSP的并行化调度
|
||||
- 内存bank切换减少bank冲突
|
||||
- 无共享内存, 需手动memcpy
|
||||
```
|
||||
|
||||
### 7.2 SoC级
|
||||
|
||||
```
|
||||
典型: 骁龙8 Gen + Kryo CPU + Hexagon NPU
|
||||
- NPU驱动封闭, 使用QMI接口通信
|
||||
- 共享内存通过RPMsg (Remote Processor Messaging)
|
||||
- 中断: ARM GIC → Hexagon
|
||||
|
||||
关键挑战:
|
||||
- NPU状态不完全可见
|
||||
- QMI通信有固定开销(~100μs)
|
||||
- 需估算NPU延迟, 不能精确测量
|
||||
|
||||
RTOS策略:
|
||||
- 使用QMI异步API
|
||||
- 通过Event FD等待NPU完成
|
||||
- 双Buffer管理QMI传输
|
||||
```
|
||||
|
||||
### 7.3 Edge盒子
|
||||
|
||||
```
|
||||
典型: Jetson Orin + ARM CPU + NVIDIA GPU
|
||||
- GPU驱动开放, CUDA API可用
|
||||
- 成熟的stream/executor模型
|
||||
- PCIe x16连接
|
||||
|
||||
关键优势:
|
||||
- 可精确控制GPU调度
|
||||
- CUDA Stream可映射为RTOS task
|
||||
- NVLink多GPU调度成熟
|
||||
|
||||
RTOS集成:
|
||||
- CUDA Runtime作为RTOS task的一部分
|
||||
- GPU completion → RTOS event
|
||||
- DMA between CPU↔GPU via PCIe
|
||||
```
|
||||
|
||||
### 7.4 Server级
|
||||
|
||||
```
|
||||
典型: x86 + 多GPU + NVLink
|
||||
- 成熟的vLLM/TGI框架
|
||||
- PCIe/NVLink互联
|
||||
- NUMA拓扑
|
||||
|
||||
RTOS角色:
|
||||
- 管理GPU进程
|
||||
- 处理NVLink中断
|
||||
- 提供实时性保证给GPU inference
|
||||
|
||||
调度:
|
||||
- vLLM already does PagedAttention scheduling
|
||||
- RTOS主要保障中断响应
|
||||
```
|
||||
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，加速器协同机制至少要回答下面三个问题：
|
||||
|
||||
1. 设备协同是否降低了人工智能目标负载的等待时间、传输开销和端到端抖动；
|
||||
2. DMA、中断和共享内存竞争是否会冲击关键保障负载的响应时间边界；
|
||||
3. 当加速器状态不可见、延迟波动或发生故障时，系统是否仍具备准入、限流和恢复能力。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
| 同步模式 | Sync / Async / Event | **Async + Event** | 最大化并行度 |
|
||||
| 缓冲策略 | Single / Double / Triple | **Triple** | 最大化流水线效率 |
|
||||
| 数据传输 | Copy / DMA / Shared | **DMA + Shared** | 零拷贝+低CPU占用 |
|
||||
| 加速决策 | Static / Dynamic | **Dynamic** | 根据负载自动选择 |
|
||||
| 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
|
||||
| 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
|
||||
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
|
||||
2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？
|
||||
3. **Accelerator Fault Recovery**: 加速器故障时的降级调度？
|
||||
4. **Predictive Pipeline**: 预测NPU延迟, 优化pipeline stall？
|
||||
5. **Heterogeneous Memory**: CPU/NPU共享内存的一致性管理？
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,544 @@
|
||||
# 方向4: 量化与精度感知调度
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
LLM的量化(Int8/Int4)不仅影响计算精度和模型大小，还直接影响RTOS调度层面的行为：
|
||||
|
||||
```
|
||||
量化精度 → 内存占用 → 数据传输量 → 计算周期 → 调度时间片 → 优先级调整
|
||||
```
|
||||
|
||||
量化不仅是模型层面的优化，更是**调度层面的参数**。调度器需要感知量化精度，动态调整：
|
||||
1. 任务的执行时间估计
|
||||
2. 内存带宽需求
|
||||
3. 精度切换时的同步策略
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何把量化精度纳入 RTOS 可分析的调度参数；
|
||||
- 如何在人工智能目标负载时效性与输出有效性之间建立可控权衡；
|
||||
- 如何避免精度切换、校准开销和 MoE 负载波动破坏关键保障负载的实时边界。
|
||||
|
||||
因此，这一方向服务的是总课题中的“质量-时效联合调度”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
量化与精度感知调度在 `T5~T1` 中的作用方式不同，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 精度调度侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 固定低精度、静态校准与可预测执行时间 |
|
||||
| `T4` 终端设备 | Int8/Int4 下的质量-时延平衡 |
|
||||
| `T3` 边缘节点 | 负载波动下的动态精度与服务模式切换 |
|
||||
| `T2` 单机工作站 | 多精度混合与大上下文推理的联合优化 |
|
||||
| `T1` 服务器/集群 | 多模型、多租户下的精度策略编排 |
|
||||
|
||||
## 2. 量化层级分析
|
||||
|
||||
### 2.1 LLM各组件的量化粒度
|
||||
|
||||
```
|
||||
Component | Typical Precision | Quantization Method
|
||||
-------------------|-------------------|---------------------
|
||||
Embedding | FP16 | None (high sensitivity)
|
||||
Attention Q/K/V | FP16 / Int8 | Per-tensor / Per-channel
|
||||
Attention Out Proj | FP16 / Int8 | Per-tensor
|
||||
FFN Gate | FP16 / Int8 | Per-channel
|
||||
FFN Up | FP16 / Int8 | Per-channel
|
||||
FFN Down | FP16 / Int8 | Per-tensor
|
||||
LM Head | FP16 | Per-tensor
|
||||
KV Cache | FP16 / Int8 | Per-token
|
||||
|
||||
Recommendation for Edge:
|
||||
- MCU/Edge: QAT (Quantization-Aware Training) Int8
|
||||
- SoC: AWQ (Activation-aware Weight Quantization) Int4
|
||||
- Server: FP8 / FP16 (abundant compute)
|
||||
```
|
||||
|
||||
### 2.2 量化对调度参数的影响
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ 量化精度 → 调度参数映射 │
|
||||
├──────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ FP16 (基准): │
|
||||
│ C_attention = 100μs (base WCET) │
|
||||
│ BW_attention = 2.0 GB/s │
|
||||
│ Memory = 2.0 GB (KV Cache) │
|
||||
│ │
|
||||
│ Int8: │
|
||||
│ C_attention = 80μs (-20% latency, 2x less bits) │
|
||||
│ BW_attention = 1.5 GB/s (less bandwidth) │
|
||||
│ Memory = 1.0 GB (half KV Cache size) │
|
||||
│ │
|
||||
│ Int4: │
|
||||
│ C_attention = 70μs (-30% latency) │
|
||||
│ BW_attention = 1.2 GB/s │
|
||||
│ Memory = 0.5 GB (quarter KV Cache) │
|
||||
│ │
|
||||
│ Impact on Scheduling: │
|
||||
│ - WCET decreases → can increase priority │
|
||||
│ - Bandwidth decreases → less contention │
|
||||
│ - Memory decreases → more concurrent requests │
|
||||
│ - BUT: calibration needed → adds overhead │
|
||||
│ │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 3. 量化感知调度模型
|
||||
|
||||
### 3.1 精度-调度联合建模
|
||||
|
||||
```c
|
||||
// 扩展task模型, 加入精度感知
|
||||
typedef struct {
|
||||
// 原有字段
|
||||
uint32_t priority;
|
||||
uint32_t wcet;
|
||||
|
||||
// 精度感知字段
|
||||
uint8_t precision; // 0=FP16, 1=Int8, 2=Int4, 3=FP8
|
||||
uint8_t quant_method; // 0=PTQ, 1=QAT, 2=AWQ
|
||||
uint32_t calibration_cost_us; // 校准成本
|
||||
float accuracy_loss; // 精度损失百分比
|
||||
|
||||
// 动态字段
|
||||
uint32_t current_precision; // 当前运行精度
|
||||
bool precision_locked; // 精度是否锁定
|
||||
} quant_aware_task_t;
|
||||
|
||||
// 动态WCET计算: 基于精度
|
||||
uint32_t calc_wcet(quant_aware_task_t *task) {
|
||||
// Base WCET at FP16
|
||||
uint32_t base_wcet = task->wcet;
|
||||
|
||||
// Precision scaling factor
|
||||
float scale = 1.0f;
|
||||
switch (task->current_precision) {
|
||||
case 1: scale = 0.80f; break; // Int8: 20% faster
|
||||
case 2: scale = 0.70f; break; // Int4: 30% faster
|
||||
case 3: scale = 0.90f; break; // FP8: 10% faster
|
||||
}
|
||||
|
||||
// Quantization method overhead
|
||||
switch (task->quant_method) {
|
||||
case 0: break; // PTQ: no calibration overhead
|
||||
case 1: return base_wcet * scale + task->calibration_cost_us;
|
||||
case 2: return base_wcet * scale + task->calibration_cost_us;
|
||||
}
|
||||
|
||||
return (uint32_t)(base_wcet * scale);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 动态精度调度
|
||||
|
||||
**核心思路**：根据系统负载和延迟需求，动态调整推理精度
|
||||
|
||||
```
|
||||
High Load Scenario (CPU/NPU saturated):
|
||||
→ 降低精度(Int8→Int4)
|
||||
→ 减少计算量, 降低WCET
|
||||
→ 提高系统吞吐量
|
||||
|
||||
Low Load Scenario (plenty of resources):
|
||||
→ 提高精度(Int4→Int8→FP16)
|
||||
→ 提高输出质量
|
||||
→ 满足SLA要求
|
||||
|
||||
Low Latency Requirement:
|
||||
→ 降低精度(Int8→Int4)
|
||||
→ 降低WCET
|
||||
→ 优先满足延迟SLA
|
||||
|
||||
High Quality Requirement:
|
||||
→ 提高精度(Int4→FP16)
|
||||
→ 牺牲部分性能
|
||||
→ 优先满足质量SLA
|
||||
```
|
||||
|
||||
### 3.3 精度感知优先级调整
|
||||
|
||||
```
|
||||
调度策略: 精度作为优先级的输入参数
|
||||
|
||||
Priority = f(urgency, precision, deadline)
|
||||
|
||||
Where:
|
||||
urgency: 任务的紧急程度 (TTFT vs TPOT)
|
||||
precision: 当前精度级别 (FP16 > Int8 > Int4)
|
||||
deadline: 截止时间
|
||||
|
||||
When precision drops:
|
||||
WCET decreases → task finishes faster → priority can be increased
|
||||
BUT accuracy_loss increases → may need to boost back later
|
||||
|
||||
Dynamic Priority Adjustment:
|
||||
1. Monitor system load (CPU/NPU utilization)
|
||||
2. If load > threshold, reduce precision
|
||||
3. Recalculate WCET with new precision
|
||||
4. Update task priority based on new WCET
|
||||
5. Adjust scheduling to maintain SLA
|
||||
|
||||
RTOS Implementation:
|
||||
void adjust_priority_for_precision(task_t *task) {
|
||||
uint32_t wcet = calc_wcet_with_precision(task);
|
||||
task->priority = wcet_to_priority(wcet);
|
||||
|
||||
// High precision = higher priority (quality-critical)
|
||||
if (task->precision == FP16) {
|
||||
task->priority += PRECISION_BOOST;
|
||||
}
|
||||
|
||||
// Update scheduling parameters
|
||||
task->deadline = task->period - wcet;
|
||||
reschedule_with_edf(task);
|
||||
}
|
||||
```
|
||||
|
||||
## 4. 精度切换的RTOS同步
|
||||
|
||||
### 4.1 同步原语
|
||||
|
||||
```
|
||||
精度切换流程:
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 1. Control task decides to change precision │
|
||||
│ 2. Signal all inference tasks │
|
||||
│ 3. Wait for barrier (all tasks at sync point) │
|
||||
│ 4. Apply new precision to weights/KV │
|
||||
│ 5. Resume inference with new precision │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
|
||||
RTOS Barrier实现:
|
||||
// 精度切换barrier
|
||||
SemaphoreHandle_t precision_barrier; // 计数barrier
|
||||
EventGroupHandle_t precision_sync; // 事件同步
|
||||
|
||||
// Control task
|
||||
void switch_precision(Precision new_prec) {
|
||||
// 1. Signal all tasks
|
||||
xEventGroupSetBits(precision_sync, SYNC_PRECISION_CHANGE);
|
||||
|
||||
// 2. Wait for all tasks to acknowledge
|
||||
EventBits_t bits = xEventGroupWaitBits(
|
||||
precision_sync,
|
||||
SYNC_ALL_ACK,
|
||||
pdTRUE, // 清除bits
|
||||
EVENT_BITS_ALL_COMPLETED,
|
||||
portMAX_DELAY
|
||||
);
|
||||
|
||||
// 3. Apply precision change
|
||||
apply_precision(new_prec);
|
||||
|
||||
// 4. Release barrier
|
||||
for (int i = 0; i < N_TASKS; i++) {
|
||||
xSemaphoreGive(precision_barrier);
|
||||
}
|
||||
}
|
||||
|
||||
// Inference task
|
||||
void inference_task(void *params) {
|
||||
for (;;) {
|
||||
// Wait for precision change signal
|
||||
EventBits_t bits = xEventGroupWaitBits(
|
||||
precision_sync,
|
||||
SYNC_PRECISION_CHANGE,
|
||||
pdTRUE,
|
||||
pdFALSE,
|
||||
portMAX_DELAY
|
||||
);
|
||||
|
||||
if (bits & SYNC_PRECISION_CHANGE) {
|
||||
// Acknowledge
|
||||
xEventGroupSetBits(precision_sync, SYNC_ALL_ACK);
|
||||
|
||||
// Wait at barrier
|
||||
xSemaphoreTake(precision_barrier, portMAX_DELAY);
|
||||
|
||||
// Apply new precision
|
||||
apply_precision(current_precision);
|
||||
|
||||
// Release barrier
|
||||
xSemaphoreGive(precision_barrier);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 精度切换开销建模
|
||||
|
||||
```
|
||||
精度切换开销 = Preparing new precision + Swapping weights + Syncing
|
||||
|
||||
Preparation: 50-200μs (量化参数准备)
|
||||
Weight Swap: 100-500μs (内存拷贝, 取决于模型大小)
|
||||
Sync: 50-100μs (barrier同步)
|
||||
Total: 200-800μs
|
||||
|
||||
Impact on Scheduling:
|
||||
- 精度切换期间所有推理task暂停
|
||||
- 切换时间需要计入RT调度分析
|
||||
- 切换频率需控制 (避免频繁切换导致的调度抖动)
|
||||
|
||||
Scheduling Adjustment:
|
||||
- 将切换时间计入task的overhead
|
||||
- 切换期间的task挂起不消耗调度时间片
|
||||
- 切换完成后的task恢复需保持原有优先级
|
||||
```
|
||||
|
||||
## 5. MoE (Mixture of Experts) 调度
|
||||
|
||||
### 5.1 MoE架构分析
|
||||
|
||||
```
|
||||
MoE Layer Structure:
|
||||
Input (d_model) → Router → Expert Selection → Expert Computation → Combine
|
||||
|
||||
Router: TopK routing (e.g., Top2 = 2 experts per token)
|
||||
Expert: FFN with shared weights
|
||||
Load Balance: Each expert has capacity limit
|
||||
|
||||
Example (Qwen2.5-72B-MoE):
|
||||
- 64 experts, each FFN = 8B params
|
||||
- Top2 routing → 16B active params per token
|
||||
- Effective compute: 16B / 72B = 22% of full model
|
||||
|
||||
MoE Scheduling Challenge:
|
||||
- Router decision is dynamic → task graph changes at runtime
|
||||
- Different experts have different execution times
|
||||
- Expert capacity limits → queuing when overloaded
|
||||
```
|
||||
|
||||
### 5.2 MoE的RTOS调度
|
||||
|
||||
```
|
||||
MoE Layer Scheduling:
|
||||
┌──────────────────────────────────────────────────────┐
|
||||
│ Input Token → Router Task (LOW priority) │
|
||||
│ ↓ │
|
||||
│ Expert Tasks (MEDIUM priority) × K_experts │
|
||||
│ [Expert A] [Expert B] [Expert C] [Expert D] │
|
||||
│ ↓ ↓ ↓ ↓ │
|
||||
│ Combine Task (HIGH priority) │
|
||||
└──────────────────────────────────────────────────────┘
|
||||
|
||||
Scheduling Strategy:
|
||||
1. Router: 最低优先级, 可延迟, 不影响关键路径
|
||||
2. Expert: 中优先级, 并行执行, 独立task
|
||||
3. Combine: 高优先级, 等待所有expert完成
|
||||
|
||||
RTOS Implementation:
|
||||
// Expert调度使用parallel task pool
|
||||
void schedule_moe_layer(uint32_t *expert_ids, int k) {
|
||||
for (int i = 0; i < k; i++) {
|
||||
xTaskNotify(expert_tasks[expert_ids[i]],
|
||||
token_data, eIncrement);
|
||||
}
|
||||
|
||||
// Wait for all experts
|
||||
for (int i = 0; i < k; i++) {
|
||||
xEventGroupWaitBits(complete_bits,
|
||||
(1 << expert_ids[i]),
|
||||
pdTRUE, pdFALSE, portMAX_DELAY);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.3 Expert负载均衡
|
||||
|
||||
```
|
||||
问题: 某些expert可能被过多token激活, 造成排队
|
||||
|
||||
负载不均衡:
|
||||
Expert A: ████████████████████ (loaded)
|
||||
Expert B: ████ (unloaded)
|
||||
Expert C: ████████ (half-loaded)
|
||||
Expert D: █ (nearly idle)
|
||||
|
||||
RTOS负载均衡策略:
|
||||
1. Capacity Tracking: 每个expert维护capacity counter
|
||||
2. Priority Adjustment: 排队超限时, 临时提升priority
|
||||
3. Queue Migration: 将排队中的task迁移到空闲expert
|
||||
4. Load-aware Routing: Router感知负载, 调整TopK选择
|
||||
|
||||
RTOS实现:
|
||||
typedef struct {
|
||||
uint32_t capacity; // 总容量
|
||||
uint32_t queued; // 当前排队数
|
||||
uint32_t executing; // 当前执行数
|
||||
uint32_t max_queue; // 最大排队数
|
||||
uint32_t priority_base; // 基础优先级
|
||||
} expert_load_t;
|
||||
|
||||
void adjust_export_priority(expert_load_t *load) {
|
||||
// 排队越多, 优先级越高 (防止饿死)
|
||||
uint32_t priority_boost = load->queued / load->max_queue;
|
||||
task_priority = load->priority_base + priority_boost;
|
||||
}
|
||||
```
|
||||
|
||||
## 6. 精度与调度的联合优化
|
||||
|
||||
### 6.1 优化目标
|
||||
|
||||
```
|
||||
Maximize: Throughput (tokens/sec)
|
||||
Subject to:
|
||||
- WCL ≤ 200ms (硬实时约束)
|
||||
- Accuracy ≥ 95% (质量约束)
|
||||
- Power ≤ 5W (功耗约束)
|
||||
|
||||
Decision Variables:
|
||||
- Precision per layer (FP16/Int8/Int4)
|
||||
- Scheduling strategy (FP/EDF/Hybrid)
|
||||
- Batch size (concurrent requests)
|
||||
- KV Cache size
|
||||
|
||||
Trade-off:
|
||||
Lower precision → Lower latency → Higher throughput
|
||||
BUT → Lower accuracy → May violate quality constraint
|
||||
|
||||
Higher precision → Higher accuracy → Lower throughput
|
||||
BUT → May violate latency constraint
|
||||
|
||||
Solution: Multi-objective optimization
|
||||
- Find Pareto frontier of (latency, accuracy, throughput)
|
||||
- Select operating point based on system mode
|
||||
```
|
||||
|
||||
### 6.2 运行时模式切换
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ System Modes │
|
||||
├──────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ MODE PERFORMANCE (性能模式): │
|
||||
│ - Precision: Int4 (lowest precision) │
|
||||
│ - Scheduling: Max throughput, aggressive batching │
|
||||
│ - KV Cache: Large pool, aggressive eviction │
|
||||
│ - Power: Max freq, no thermal limit │
|
||||
│ - Use: Real-time response, latency-critical │
|
||||
│ │
|
||||
│ MODE BALANCED (均衡模式): │
|
||||
│ - Precision: Int8 (balanced) │
|
||||
│ - Scheduling: Balanced throughput + latency │
|
||||
│ - KV Cache: Moderate pool, moderate eviction │
|
||||
│ - Power: Medium freq, thermal-aware │
|
||||
│ - Use: General purpose │
|
||||
│ │
|
||||
│ MODE ACCURACY (精度模式): │
|
||||
│ - Precision: FP16 (highest precision) │
|
||||
│ - Scheduling: Lower throughput, prioritize quality │
|
||||
│ - KV Cache: Large pool, conservative eviction │
|
||||
│ - Power: May throttle for stability │
|
||||
│ - Use: High-quality output required │
|
||||
│ │
|
||||
│ MODE POWER (省电模式): │
|
||||
│ - Precision: Int4 + DVFS low freq │
|
||||
│ - Scheduling: Aggressive idle, power-saving │
|
||||
│ - KV Cache: Minimal pool, aggressive eviction │
|
||||
│ - Power: Min freq, aggressive sleep │
|
||||
│ - Use: Battery-powered, standby │
|
||||
│ │
|
||||
│ Mode Transitions (RTOS-aware): │
|
||||
│ 1. Mode change signaled by control task │
|
||||
│ 2. All tasks synchronize at barrier │
|
||||
│ 3. Parameters updated (precision, priority, etc.) │
|
||||
│ 4. Resume with new parameters │
|
||||
└──────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 7. 各硬件平台的精度-调度差异
|
||||
|
||||
### 7.1 MCU级
|
||||
|
||||
```
|
||||
约束:
|
||||
- 仅支持INT8 (硬件限制, 无FPunit)
|
||||
- 无动态精度切换
|
||||
- 精度固定, 调度简单
|
||||
|
||||
策略:
|
||||
- 静态精度(Int8), 固定优先级调度
|
||||
- 关注: 精度校准对WCET的影响
|
||||
- 量化开销: 固定, 可预先计算
|
||||
```
|
||||
|
||||
### 7.2 SoC级
|
||||
|
||||
```
|
||||
约束:
|
||||
- 支持INT8/INT4/FP16 (取决于NPU)
|
||||
- 动态精度切换可能有限
|
||||
- NPU驱动可能不支持运行时精度调整
|
||||
|
||||
策略:
|
||||
- 静态精度选择, 启动时配置
|
||||
- 精度影响调度参数(WCET)
|
||||
- 可能支持精度切换但非无缝
|
||||
```
|
||||
|
||||
### 7.3 Edge盒子
|
||||
|
||||
```
|
||||
约束:
|
||||
- GPU支持FP16/FP32/INT8动态切换
|
||||
- 丰富的精度选项
|
||||
- 成熟软件栈支持
|
||||
|
||||
策略:
|
||||
- 运行时动态精度调整
|
||||
- 基于负载的精度自适应
|
||||
- 精度感知调度优化
|
||||
```
|
||||
|
||||
### 7.4 Server级
|
||||
|
||||
```
|
||||
约束:
|
||||
- 全精度支持, 动态调整
|
||||
- 丰富的软件生态
|
||||
- 调度算法成熟
|
||||
|
||||
策略:
|
||||
- 精细化精度调度
|
||||
- 各层不同精度
|
||||
- 量化感知 serving (vLLM FP8 support)
|
||||
```
|
||||
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，量化与精度感知调度至少要回答下面三个问题：
|
||||
|
||||
1. 不同精度策略下，人工智能目标负载的 `TTFT`、`TPOT`、成功率和输出质量如何共同变化；
|
||||
2. 精度切换、同步和校准开销是否会把关键保障负载推过实时边界；
|
||||
3. 精度模式切换是否可以被准入控制和运行模式管理，并保持可预测的抖动边界。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
| 精度选择 | 静态 / 动态 | **Hybrid** | 启动静态+运行时微调 |
|
||||
| 精度粒度 | Layer-level / Token-level | **Layer-level** | 实现简单+精度可接受 |
|
||||
| 切换开销 | 计入WCET / 不计入 | **计入WCET** | 实时性分析准确 |
|
||||
| 负载均衡 | 静态 / 动态 | **动态** | MoE负载不均衡常见 |
|
||||
| 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
|
||||
| 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
|
||||
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
|
||||
2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？
|
||||
3. **MoE Load Balancing in RT**: MoE的负载均衡如何满足实时约束？
|
||||
4. **Precision-aware Memory**: 精度变化时的内存自动伸缩？
|
||||
5. **Cross-model Precision**: 多模型共存时的精度分配？
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,451 @@
|
||||
# 方向5: 中断管理与实时性保障
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
RTOS 上的人工智能目标负载与传感、通信、控制等关键保障负载共存于同一个 RTOS 内核中。核心问题：
|
||||
|
||||
1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
|
||||
2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
|
||||
3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
|
||||
4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何保证关键保障负载在人工智能目标负载进入系统后仍拥有明确的中断优先权；
|
||||
- 如何把加速器完成中断、DMA 中断和外设中断纳入统一的实时边界分析；
|
||||
- 如何让 SylixOS 的中断管理能力成为双目标达标的硬支撑。
|
||||
|
||||
因此，这一方向服务的是总课题中的“关键路径实时保障”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
中断管理与实时性保障在 `T5~T1` 中都重要，但关键矛盾不同：
|
||||
|
||||
| 部署形态 | 中断保障侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 控制回路、看门狗和安全联锁优先级最高 |
|
||||
| `T4` 终端设备 | 传感器、通信与本地 AI 推理中断并存 |
|
||||
| `T3` 边缘节点 | 多外设、多链路和加速器完成中断叠加 |
|
||||
| `T2` 单机工作站 | GPU/网络/存储中断与关键任务隔离 |
|
||||
| `T1` 服务器/集群 | 多队列网络、存储和设备中断亲和治理 |
|
||||
|
||||
## 2. 中断层级设计
|
||||
|
||||
### 2.1 中断优先级映射
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ IRQ Hierarchy (示例: 基于ARM GIC) │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ Priority 255 (最高): Hard fault, Reset │
|
||||
│ Priority 254: Watchdog, Critical error │
|
||||
│ Priority 253: Real-time control (motor, actuator) │
|
||||
│ Priority 252: Hard comm (ethernet MAC) │
|
||||
│ Priority 251: Sensor interrupt (IMU, camera) │
|
||||
│ Priority 250: Network interrupt (TCP timeout) │
|
||||
│ ────────────────────────────────────────────── │
|
||||
│ Priority 200: NPU/GPU completion interrupt │
|
||||
│ Priority 199: DMA completion │
|
||||
│ Priority 198: Timer interrupt (tick) │
|
||||
│ ────────────────────────────────────────────── │
|
||||
│ Priority 100: Software interrupt (task notification) │
|
||||
│ Priority 50: Low-priority I2C/SPI │
|
||||
│ Priority 0 (最低): Idle interrupt │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
|
||||
Design Rule:
|
||||
Real-time control tasks > NPU completion > DMA > Timer > Software
|
||||
```
|
||||
|
||||
### 2.2 中断类型与处理策略
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ IRQ Type | Handling Strategy │
|
||||
├────────────────────┼────────────────────────────────────────┤
|
||||
│ NPU Completion | 立即唤醒Attention task, 不延迟 │
|
||||
│ DMA Complete | 标记完成, 通过event通知task │
|
||||
│ Timer Tick | 标准tick, 用于调度时间片 │
|
||||
│ Sensor Data | 高优先级, 触发数据处理task │
|
||||
│ Comm Timeout | 中优先级, 可能触发重连task │
|
||||
│ Control Command | 最高优先级, 触发控制task │
|
||||
│ Error/Exception | 最高优先级, 触发error handling task │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 3. NPU/GPU完成中断处理
|
||||
|
||||
### 3.1 中断处理流程
|
||||
|
||||
```
|
||||
NPU完成指令 → Interrupt Controller → RTOS IRQ Handler
|
||||
|
||||
1. NPU完成当前层 → 触发IRQ
|
||||
2. ARM GIC收到中断 → 保存寄存器, 跳转到ISR
|
||||
3. ISR: 读取NPU状态寄存器 → 确认完成 → 清中断
|
||||
4. ISR: xSemaphoreGiveFromISR() → 唤醒等待task
|
||||
5. ISR: 如果有更高优先级task ready → portYIELD_FROM_ISR()
|
||||
6. 返回 → 恢复寄存器 → 执行task
|
||||
```
|
||||
|
||||
### 3.2 ISR设计原则
|
||||
|
||||
```c
|
||||
// NPU完成ISR (简化版)
|
||||
volatile uint32_t npu_status_reg; // 硬件寄存器
|
||||
SemaphoreHandle_t npu_done_sem; // RTOS信号量
|
||||
|
||||
void NPU_IRQ_Handler(void) {
|
||||
// 1. 读取并确认NPU状态 (纯硬件操作)
|
||||
uint32_t status = npu_status_reg;
|
||||
if (status & NPU_STATUS_COMPLETE) {
|
||||
// 2. 写寄存器清除中断标志
|
||||
npu_status_reg &= ~NPU_STATUS_COMPLETE;
|
||||
|
||||
// 3. 释放信号量 (中断上下文)
|
||||
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
|
||||
xSemaphoreGiveFromISR(npu_done_sem, &xHigherPriorityTaskWoken);
|
||||
|
||||
// 4. 如果有更高优先级task ready, 立即切换
|
||||
if (xHigherPriorityTaskWoken) {
|
||||
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// ISR设计原则:
|
||||
// 1. 最小化: ISR中只做最少的操作 (<10μs)
|
||||
// 2. 不阻塞: ISR中不使用sleep/等待
|
||||
// 3. 用FromISR版本: 所有RTOS API都用ISR版本
|
||||
// 4. 状态寄存器直接访问: 硬件寄存器直接读写
|
||||
// 5. 事件通知为主: 优先使用event/group, 避免queue拷贝
|
||||
```
|
||||
|
||||
## 4. Priority Inversion处理
|
||||
|
||||
### 4.1 经典场景分析
|
||||
|
||||
```
|
||||
Priority Inversion in LLM Inference:
|
||||
|
||||
Task A (HIGH): Real-time control (needs NPU results)
|
||||
Task B (MEDIUM): LLM Attention (uses NPU, holds mutex)
|
||||
Task C (LOW): Background logging (locks NPU mutex)
|
||||
|
||||
Timeline:
|
||||
t0: Task C acquires NPU mutex
|
||||
t1: Task B starts, wants NPU → BLOCKED (waiting for C)
|
||||
t2: Task A starts, wants NPU result → BLOCKED (waiting for B)
|
||||
t3: Preemptive? No - C is LOW, B is MEDIUM
|
||||
→ A waits for B, B waits for C
|
||||
→ A is blocked by lower-priority C = PRIORITY INVERSION
|
||||
|
||||
Solution: Priority Inheritance Protocol (PIP)
|
||||
t0: Task C acquires NPU mutex
|
||||
t2: Task A blocked by B, B blocked by C
|
||||
t3: C inherits A's priority → C becomes HIGH
|
||||
t4: C releases mutex → C returns to LOW, A can proceed
|
||||
```
|
||||
|
||||
### 4.2 RTOS中的PIP实现
|
||||
|
||||
```c
|
||||
// PIP扩展: 适用于LLM推理的分级PIP
|
||||
typedef struct {
|
||||
uint32_t mutex_id;
|
||||
uint32_t base_priority; // 持有者的基础优先级
|
||||
uint32_t current_priority; // 继承后的优先级
|
||||
TaskHandle_t holder; // 持有者
|
||||
StackType_t *saved_stack; // 保存的栈指针
|
||||
} pip_mutex_t;
|
||||
|
||||
void pip_take(pip_mutex_t *m) {
|
||||
// 保存原始优先级
|
||||
uint32_t orig_priority = task_get_priority(m->holder);
|
||||
m->base_priority = orig_priority;
|
||||
m->current_priority = orig_priority;
|
||||
|
||||
// 提升持有者优先级到最高等待者
|
||||
uint32_t max_waiter = find_highest_waiting_priority(m->mutex_id);
|
||||
task_set_priority(m->holder, max_waiter);
|
||||
m->current_priority = max_waiter;
|
||||
}
|
||||
|
||||
void pip_give(pip_mutex_t *m) {
|
||||
// 恢复基础优先级
|
||||
task_set_priority(m->holder, m->base_priority);
|
||||
m->current_priority = m->base_priority;
|
||||
}
|
||||
|
||||
// LLM特例: NPU mutex的PIP
|
||||
// NPU mutex持有者通常是DMA task或NPU驱动
|
||||
// 提升为Attention task的优先级
|
||||
```
|
||||
|
||||
### 4.3 Enhanced PIP (ePIP) for LLM
|
||||
|
||||
```
|
||||
Standard PIP的问题: 只继承一次, 可能传递到更高级
|
||||
|
||||
Enhanced PIP: 继承所有等待者的最高优先级
|
||||
|
||||
Scenario:
|
||||
Task A (MAX): Control → waiting for NPU
|
||||
Task B (HIGH): Attention → waiting for NPU
|
||||
Task C (MED): KV Cache → waiting for NPU
|
||||
Task D (LOW): DMA → holding NPU mutex
|
||||
|
||||
Standard PIP:
|
||||
D inherits MAX (A's priority)
|
||||
Problem: B (HIGH) may starve
|
||||
|
||||
Enhanced PIP:
|
||||
D inherits MAX (A's priority)
|
||||
B inherits MAX too (via queue, not mutex)
|
||||
All high-priority tasks preempt D
|
||||
|
||||
RTOS Implementation:
|
||||
// 使用Priority Queue记录所有等待者
|
||||
typedef struct {
|
||||
pip_mutex_t base;
|
||||
PriorityQueueType_t wait_queue; // RTOS wait queue
|
||||
uint32_t max_wait_priority; // 最高等待优先级
|
||||
} epip_mutex_t;
|
||||
|
||||
void epip_take(epip_mutex_t *m) {
|
||||
uint32_t max_prio = max_priority_in_queue(m->wait_queue);
|
||||
task_set_priority(m->holder, max_prio);
|
||||
m->max_wait_priority = max_prio;
|
||||
}
|
||||
```
|
||||
|
||||
## 5. 中断屏蔽与上下文切换
|
||||
|
||||
### 5.1 中断屏蔽策略
|
||||
|
||||
```
|
||||
Critical Section (中断屏蔽):
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Level 0: Global IRQ Disable │
|
||||
│ 使用: 极短的critical section (<5μs) │
|
||||
│ 场景: 写硬件寄存器, 更新共享计数器 │
|
||||
│ 开销: 所有IRQ被屏蔽, 可能错过中断 │
|
||||
│ │
|
||||
│ Level 1: Task-level IRQ Disable │
|
||||
│ 使用: task内critical section (≤50μs) │
|
||||
│ 场景: 原子更新task状态, 修改task control block │
|
||||
│ 开销: 只屏蔽当前task的中断, 其他task不受影响 │
|
||||
│ │
|
||||
│ Level 2: No IRQ Disable (锁+原子操作) │
|
||||
│ 使用: 大多数critical section │
|
||||
│ 场景: 修改共享数据结构, 使用atomic操作 │
|
||||
│ 开销: 最小, 但需要确保原子性 │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
|
||||
LLM推理中的critical sections:
|
||||
1. Attention结果写入 (原子操作即可, 不需要全局disable)
|
||||
2. KV Cache更新 (lock-free queue, 不需要disable)
|
||||
3. Scheduler state update (task-level disable)
|
||||
4. Precision change flag (global disable for <10μs)
|
||||
```
|
||||
|
||||
### 5.2 上下文切换开销
|
||||
|
||||
```
|
||||
Context Switch in RTOS:
|
||||
1. Save current task registers (R0-R12, LR, PC, PSR)
|
||||
2. Save/restore stack pointer
|
||||
3. Update task control block
|
||||
4. Restore next task registers
|
||||
5. Restore stack pointer
|
||||
6. Execute 'BX LR' (return from exception)
|
||||
|
||||
Cost:
|
||||
Cortex-M7: ~10-50 cycles (with DCBP) ≈ 1-5μs @ 400MHz
|
||||
ARM Cortex-A: ~100-500 cycles ≈ 50-250ns @ 2GHz
|
||||
With MMU: ~2-10μs (TLB flush)
|
||||
|
||||
LLM Impact:
|
||||
- 频繁context switch增加E2E延迟
|
||||
- 每个switch增加 ~5μs (M7) ~2μs (A72)
|
||||
- 假设每token 10次context switch: +50μs
|
||||
|
||||
Reduction strategies:
|
||||
- Pin critical tasks to core (reduce switch)
|
||||
- Use task notification instead of queue (reduce overhead)
|
||||
- Batch task switches (wait for multiple events)
|
||||
```
|
||||
|
||||
## 6. 实时性分析
|
||||
|
||||
### 6.1 Response Time Analysis (RTA) with Interrupts
|
||||
|
||||
```
|
||||
Modified RTA for LLM with interrupts:
|
||||
|
||||
R_i = C_i + I_i + Σ_{j∈hp(i)} ⌈R_j / T_j⌉ × C_j
|
||||
|
||||
Where:
|
||||
R_i: response time of task i
|
||||
C_i: execution time of task i
|
||||
I_i: interrupt-induced latency (中断导致的额外延迟)
|
||||
Σ: interference from higher priority tasks
|
||||
|
||||
Interrupt-induced latency:
|
||||
I_i = Σ_{k∈interrupts} (ISR_time_k + preemption_delay_k)
|
||||
|
||||
ISR_time_k: 中断k的处理时间
|
||||
preemption_delay_k: 中断k导致的preemption开销
|
||||
|
||||
For LLM:
|
||||
I_attention = ISR_time(npu_complete) + ISR_time(dma_complete)
|
||||
+ preemption(attention → higher_priority_control)
|
||||
|
||||
Typical:
|
||||
ISR_time(npu) ≈ 2μs
|
||||
ISR_time(dma) ≈ 1μs
|
||||
Preemption ≈ 5μs
|
||||
Total interrupt overhead ≈ 8μs per inference step
|
||||
```
|
||||
|
||||
### 6.2 中断导致的Jitter
|
||||
|
||||
```
|
||||
Jitter来源分析:
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Source | Latency (μs) | Probability │
|
||||
├──────────────────────────┼──────────────┼────────────────┤
|
||||
│ NPU completion IRQ | 2-5 | 100% (predictable) │
|
||||
│ DMA completion IRQ | 1-3 | 100% (predictable) │
|
||||
│ Timer tick | 1-2 | 100% (predictable) │
|
||||
│ Preemption by control | 5-10 | Low (<5%) │
|
||||
│ Preemption by comm | 5-15 | Medium (<20%) │
|
||||
│ ISR overhead variance | 1-5 | High │
|
||||
│ Cache miss (interrupt) | 10-50 | Variable │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
|
||||
Worst-case Jitter:
|
||||
Jitter = Max(R_i) - Min(R_i) across all inference steps
|
||||
|
||||
Predictable jitter: NPU/DMA IRQ (deterministic)
|
||||
Unpredictable jitter: Preemption, Cache miss (stochastic)
|
||||
|
||||
Scheduling strategy:
|
||||
- Minimize unpredictable jitter sources
|
||||
- Bound predictable jitter through analysis
|
||||
- Design with worst-case jitter in mind
|
||||
```
|
||||
|
||||
## 7. 各平台的中断差异
|
||||
|
||||
### 7.1 MCU级
|
||||
|
||||
```
|
||||
中断控制器: NVIC (ARM) / SCB (RISC-V)
|
||||
中断数量: 10-50
|
||||
中断优先级: 3-8 bits
|
||||
特点:
|
||||
- 中断延迟低 (<1μs)
|
||||
- 中断嵌套简单 (固定层级)
|
||||
- 无中断向量表动态重定位
|
||||
- RTOS成熟, 中断集成简单
|
||||
|
||||
关键中断:
|
||||
- SysTick (tick)
|
||||
- NPU/ISP (如有)
|
||||
- GPIO (传感器)
|
||||
- UART/SPI (通信)
|
||||
- DMA (数据传输)
|
||||
```
|
||||
|
||||
### 7.2 SoC级
|
||||
|
||||
```
|
||||
中断控制器: GICv3/v4 (ARM) / PLIC (RISC-V)
|
||||
中断数量: 100-1000+
|
||||
中断优先级: 8 bits
|
||||
特点:
|
||||
- 中断虚拟化支持 (但NPU驱动可能不暴露)
|
||||
- 中断路由复杂 (多个master)
|
||||
- MSI/MSI-X支持
|
||||
- 中断聚合 (coalescing)
|
||||
|
||||
关键中断:
|
||||
- ARM CPU cores (each has IRQ)
|
||||
- NPU (interrupt via GIC)
|
||||
- DMA controllers (multiple)
|
||||
- Ethernet (MAC interrupt)
|
||||
- Modem/Radio (connectivity)
|
||||
- ISP (camera)
|
||||
```
|
||||
|
||||
### 7.3 Edge盒子
|
||||
|
||||
```
|
||||
中断控制器: GICv4 (Jetson Orin)
|
||||
中断数量: 1000+
|
||||
中断优先级: 8 bits
|
||||
特点:
|
||||
- 丰富的中断源
|
||||
- PCIe MSIX支持
|
||||
- GPU中断丰富 (渲染/计算)
|
||||
- 中断亲和性可配置
|
||||
|
||||
关键中断:
|
||||
- GPU (CUDA completion)
|
||||
- NVLink (multi-GPU)
|
||||
- PCIe (SSD/NPU)
|
||||
- Ethernet
|
||||
- Timer
|
||||
```
|
||||
|
||||
### 7.4 Server级
|
||||
|
||||
```
|
||||
中断控制器: GICv4 / MSI-X
|
||||
中断数量: 数千
|
||||
特点:
|
||||
- 中断亲和性精细控制
|
||||
- 中断聚合
|
||||
- RSS (Receive Side Scattering)
|
||||
- 中断向量池
|
||||
|
||||
RTOS角色:
|
||||
- 主要处理网络/存储中断
|
||||
- GPU中断由用户态处理
|
||||
- RTOS保证关键路径上的中断响应
|
||||
```
|
||||
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，中断与实时性机制至少要回答下面三个问题：
|
||||
|
||||
1. 关键保障负载在人工智能目标负载并存时，是否仍满足 `deadline miss ratio`、观测最大响应时间和尾部抖动约束；
|
||||
2. 加速器完成中断、DMA 中断和外设中断是否形成可分析的干扰上界，并维持可控的中断行为；
|
||||
3. 优先级继承、IRQ 亲和和中断屏蔽策略是否降低了关键路径不确定性并形成可分析上界。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
| PIP/ePIP | PIP / ePIP / No | **ePIP** | LLM场景优先级复杂 |
|
||||
| ISR策略 | Minimal / Full | **Minimal** | ISR尽量短 |
|
||||
| Critical Section | Global / Task-level / Lock-free | **混合** | 按场景选择 |
|
||||
| Interrupt Mask | Disable / Priority / Vector | **Priority** | 灵活+实时 |
|
||||
| Timer | Tick / Event | **Event** | 降低开销 |
|
||||
| IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
|
||||
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
|
||||
2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？
|
||||
3. **Predictable Jitter**: 如何分析和保证jitter的确定性？
|
||||
4. **Cross-core Interrupt**: 多核间的中断传播与同步？
|
||||
5. **Interrupt-less Inference**: 轮询模式下的LLM调度？
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,493 @@
|
||||
# 方向6: 能耗感知调度与热管理
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
当人工智能目标负载进入任务关键系统后，能耗和热会直接进入实时保障约束：
|
||||
|
||||
```
|
||||
LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
|
||||
|
||||
Example (Qwen2.5-1.5B, 100 tokens):
|
||||
Compute (CPU): ~50mW × 2s = 100mJ
|
||||
Memory (DDR): ~30mW × 2s = 60mJ
|
||||
NPU (if used): ~200mW × 0.5s = 100mJ
|
||||
Total: ~260mJ per inference (~200ms, 100 tokens)
|
||||
|
||||
Constraints:
|
||||
- Battery: 3000mAh @ 3.8V = 40.68Wh = 146kJ
|
||||
- Thermal: Tj < 85°C (Junction temperature)
|
||||
- Form Factor: Passive cooling (no fan)
|
||||
```
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何避免热漂移、降频和功率封顶破坏人工智能目标负载的时效性；
|
||||
- 如何避免功耗控制策略反向侵蚀关键保障负载的实时边界；
|
||||
- 如何把能耗与热管理纳入 SylixOS 的长期稳定运行机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“长稳运行与热功率边界”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
能耗与热管理在 `T5~T1` 中的表现差异显著，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 能耗与热管理侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 电池/电源预算、深睡眠与快速恢复 |
|
||||
| `T4` 终端设备 | 被动散热下的持续推理与温升控制 |
|
||||
| `T3` 边缘节点 | 多核+加速器协同下的热热点迁移 |
|
||||
| `T2` 单机工作站 | 长时间高负载下的降频与风扇策略 |
|
||||
| `T1` 服务器/集群 | 机架功率、PUE 与多设备热耦合 |
|
||||
|
||||
## 2. 能耗模型
|
||||
|
||||
### 2.1 各组件的能耗模型
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Component | Power (mW) | Active | Idle | Sleep │
|
||||
├────────────────┼────────────┼────────┼──────┼───────────────┤
|
||||
│ CPU Core | 80-200 | Active | 5 | 0.1 │
|
||||
│ NPU | 100-500 | Active | 10 | 1 │
|
||||
│ DDR | 50-150 | RW | 20 | 5 │
|
||||
│ NPU Memory | 20-50 | Active | 5 | 1 │
|
||||
│ Interconnect | 10-30 | Active | 2 | 0.5 │
|
||||
│ GPU | 100-800 | Active | 15 | 5 │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
|
||||
Total Active Power: 300-1300mW
|
||||
Total Idle Power: 40-100mW
|
||||
Total Sleep Power: 1-10mW
|
||||
|
||||
Energy per inference step:
|
||||
E = P_active × t_active + P_idle × t_idle + P_sleep × t_sleep
|
||||
```
|
||||
|
||||
### 2.2 DVFS (Dynamic Voltage and Frequency Scaling) 模型
|
||||
|
||||
```
|
||||
DVFS States (以Cortex-A72为例):
|
||||
|
||||
State | Frequency | Voltage | Power | Latency
|
||||
-------|-----------|---------|---------|---------
|
||||
S0 | 2.0 GHz | 1.2V | 200mW | 1x (baseline)
|
||||
S1 | 1.5 GHz | 1.1V | 150mW | 1.33x
|
||||
S2 | 1.0 GHz | 1.0V | 100mW | 2.0x
|
||||
S3 | 0.5 GHz | 0.9V | 50mW | 4.0x
|
||||
S4 | 100MHz | 0.8V | 15mW | 20x
|
||||
|
||||
Switching overhead: ~10-100μs (frequency ramp time)
|
||||
|
||||
Power-Frequency relationship:
|
||||
P ∝ f × V² ∝ f × f^α ≈ f^(1+α)
|
||||
|
||||
where α ≈ 1-2 (depends on architecture)
|
||||
|
||||
So doubling frequency ≈ 2-4x power increase
|
||||
```
|
||||
|
||||
### 2.3 能耗-延迟权衡
|
||||
|
||||
```
|
||||
DVFS State | Latency | Power | Energy (per step) | Throughput
|
||||
-----------|---------|-------|-------------------|----------
|
||||
S0 (max) | 10ms | 200mW | 2.0mJ | 100 tok/s
|
||||
S1 | 13ms | 150mW | 1.95mJ | 77 tok/s
|
||||
S2 | 20ms | 100mW | 2.0mJ | 50 tok/s
|
||||
S3 | 40ms | 50mW | 2.0mJ | 25 tok/s
|
||||
S4 (min) | 200ms | 15mW | 3.0mJ | 5 tok/s
|
||||
|
||||
Insight:
|
||||
- S1-S3 energy per step is similar (better power efficiency)
|
||||
- S0: highest throughput, highest energy rate
|
||||
- S4: lowest throughput, higher energy per step (overhead)
|
||||
- Optimal: S1-S2 for latency-constrained, S2-S3 for energy-constrained
|
||||
```
|
||||
|
||||
## 3. 能耗感知调度策略
|
||||
|
||||
### 3.1 静态调度策略
|
||||
|
||||
```
|
||||
Strategy 1: Frequency Provisioning (固定频率)
|
||||
1. Offline: Analyze workload, determine required frequency
|
||||
2. Run at fixed DVFS state for entire inference
|
||||
3. Simple, deterministic, but may waste energy
|
||||
|
||||
Example: Qwen2.5-1.5B inference at S1
|
||||
- Guaranteed to meet 500ms deadline
|
||||
- Uses 150mW instead of 200mW → 25% energy saved
|
||||
- No runtime adaptation
|
||||
|
||||
Strategy 2: Power Capping
|
||||
1. Set maximum power budget (e.g., 500mW)
|
||||
2. Monitor power consumption
|
||||
3. Scale frequency if exceeding budget
|
||||
4. Reactive, but guarantees thermal safety
|
||||
|
||||
Example:
|
||||
Power: ████████████████████░░░░░
|
||||
^ ^
|
||||
Starts at S0 Hits cap → Drops to S2
|
||||
```
|
||||
|
||||
### 3.2 动态调度策略
|
||||
|
||||
```
|
||||
Strategy 3: Adaptive DVFS (运行时调整)
|
||||
1. Monitor: CPU load, temperature, battery level
|
||||
2. Decide: Adjust DVFS state
|
||||
3. Act: Switch frequency
|
||||
4. Repeat: At each inference step
|
||||
|
||||
Decision variables:
|
||||
- Current temperature (T)
|
||||
- Battery level (B)
|
||||
- Latency requirement (D)
|
||||
- Thermal headroom (T_junction_max - T_current)
|
||||
|
||||
Decision function:
|
||||
DVFS_state = f(T, B, D, thermal_headroom)
|
||||
|
||||
Pseudo-code:
|
||||
if (temperature > 75°C):
|
||||
drop_to_dvfs_state(S2)
|
||||
elif (temperature > 70°C):
|
||||
drop_to_dvfs_state(S1)
|
||||
elif (battery < 20%):
|
||||
drop_to_dvfs_state(S2)
|
||||
elif (latency_requirement == strict):
|
||||
run_at_dvfs_state(S0)
|
||||
else:
|
||||
run_at_dvfs_state(S1) # balanced
|
||||
|
||||
Strategy 4: Prediction-based Scheduling
|
||||
1. Predict: Future workload (based on input size, sequence length)
|
||||
2. Schedule: Set DVFS state in advance
|
||||
3. Reduce: Switching overhead (pre-emptive adjustment)
|
||||
|
||||
Example:
|
||||
Input: 2048 tokens (long input)
|
||||
Predict: Prefill will be heavy → Set S0
|
||||
During decode: Predict lighter → Drop to S1/S2
|
||||
Before output: Predict completion → Drop to S3
|
||||
|
||||
Implementation:
|
||||
Use RTOS timer + callback for predictive scheduling
|
||||
```
|
||||
|
||||
### 3.3 任务级功耗控制
|
||||
|
||||
```
|
||||
Task Power Profiling:
|
||||
Task | Avg Power (mW) | Active Time (ms) | Energy (mJ)
|
||||
--------------------|----------------|------------------|------------
|
||||
Attention | 150 | 10 | 1.5
|
||||
FFN | 180 | 8 | 1.44
|
||||
KV Cache Write | 50 | 5 | 0.25
|
||||
Tokenizer | 20 | 2 | 0.04
|
||||
Control | 10 | 1 | 0.01
|
||||
|
||||
Task-level power control:
|
||||
- Scale specific task's frequency based on urgency
|
||||
- Attention: High frequency (latency-critical)
|
||||
- KV Cache: Low frequency (IO-bound, less compute)
|
||||
- Tokenizer: Variable (depends on input size)
|
||||
|
||||
RTOS Implementation:
|
||||
void task_set_power_profile(task_t *task, PowerProfile profile) {
|
||||
switch (profile) {
|
||||
case PERFORMANCE:
|
||||
task->frequency = MAX_FREQ;
|
||||
task->voltage = MAX_VOLTAGE;
|
||||
break;
|
||||
case BALANCED:
|
||||
task->frequency = MID_FREQ;
|
||||
task->voltage = MID_VOLTAGE;
|
||||
break;
|
||||
case POWER_SAVING:
|
||||
task->frequency = LOW_FREQ;
|
||||
task->voltage = LOW_VOLTAGE;
|
||||
break;
|
||||
case ULTRA_LOW:
|
||||
task->frequency = MIN_FREQ;
|
||||
task->voltage = MIN_VOLTAGE;
|
||||
break;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. 热管理
|
||||
|
||||
### 4.1 热模型
|
||||
|
||||
```
|
||||
Thermal Model (Simplified):
|
||||
|
||||
T_junction = T_ambient + P_total × R_thermal
|
||||
|
||||
Where:
|
||||
T_junction: 芯片结温
|
||||
T_ambient: 环境温度
|
||||
P_total: 总功耗
|
||||
R_thermal: 热阻 (package + heatsink + air)
|
||||
|
||||
Example (RK3588, passive cooling):
|
||||
T_ambient = 40°C
|
||||
R_thermal = 5°C/W
|
||||
P_total = 5W (typical)
|
||||
|
||||
T_junction = 40 + 5 × 5 = 65°C
|
||||
|
||||
At P_total = 10W (LLM heavy):
|
||||
T_junction = 40 + 5 × 10 = 90°C → Too hot!
|
||||
|
||||
Solution: Throttle to P_total = 6W
|
||||
T_junction = 40 + 5 × 6 = 70°C → Acceptable
|
||||
```
|
||||
|
||||
### 4.2 热感知调度
|
||||
|
||||
```
|
||||
Thermal Throttling Strategy:
|
||||
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Temperature Zone | Action │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Zone 1: < 60°C (Cool) | Full performance │
|
||||
│ Zone 2: 60-70°C (Warm) | Light throttle (S1) │
|
||||
│ Zone 3: 70-80°C (Hot) | Aggressive throttle (S2) │
|
||||
│ Zone 4: 80-85°C (Hot) | Max throttle (S3) │
|
||||
│ Zone 5: > 85°C (Critical)| Emergency shutdown │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
Implementation:
|
||||
Thermal Zone Controller (low-priority RTOS task):
|
||||
|
||||
void thermal_controller_task(void *params) {
|
||||
for (;;) {
|
||||
float temp = read_temperature_sensor();
|
||||
ThermalZone zone = classify_temperature(temp);
|
||||
|
||||
// Adjust DVFS based on zone
|
||||
switch (zone) {
|
||||
case ZONE_COOL:
|
||||
set_dvfs_state(S0);
|
||||
break;
|
||||
case ZONE_WARM:
|
||||
set_dvfs_state(S1);
|
||||
break;
|
||||
case ZONE_HOT:
|
||||
set_dvfs_state(S2);
|
||||
reduce_llm_priority();
|
||||
break;
|
||||
case ZONE_HOTTER:
|
||||
set_dvfs_state(S3);
|
||||
reduce_llm_priority();
|
||||
break;
|
||||
case ZONE_CRITICAL:
|
||||
emergency_shutdown();
|
||||
break;
|
||||
}
|
||||
|
||||
vTaskDelay(pdMS_TO_TICKS(100)); // Check every 100ms
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 热-调度联合优化
|
||||
|
||||
```
|
||||
Joint Thermal-Scheduling Optimization:
|
||||
|
||||
Objective: Minimize energy, subject to thermal constraints
|
||||
|
||||
Variables:
|
||||
- DVFS state per time slot
|
||||
- Task scheduling per time slot
|
||||
- Task placement (core assignment)
|
||||
|
||||
Constraints:
|
||||
- T_junction(t) ≤ 85°C for all t
|
||||
- Latency ≤ deadline
|
||||
- Throughput ≥ minimum
|
||||
|
||||
Solution approach:
|
||||
1. Model thermal dynamics (heat equation)
|
||||
2. Predict temperature profile for each scheduling option
|
||||
3. Select scheduling that minimizes energy without thermal violation
|
||||
|
||||
Simplified approach (RTOS-friendly):
|
||||
- Use PID controller for temperature
|
||||
- Setpoint: 75°C (target), 85°C (max)
|
||||
- Control variable: DVFS state
|
||||
- Disturbance: Task load changes
|
||||
```
|
||||
|
||||
## 5. 空闲与低功耗状态管理
|
||||
|
||||
### 5.1 推理间隙的低功耗
|
||||
|
||||
```
|
||||
LLM推理的idle间隙:
|
||||
|
||||
Prefill (20ms) → Decode (10ms × 100) → Idle
|
||||
|
||||
Decode间隙: 每层计算之间有微秒级间隙
|
||||
Prefill-Decode间隙: 20ms的完全空闲
|
||||
|
||||
Power-down opportunities:
|
||||
- NPU can enter sleep during decode间隙
|
||||
- DDR can enter self-refresh during间隙
|
||||
- CPU cores can sleep (if no pending tasks)
|
||||
|
||||
RTOS低功耗策略:
|
||||
|
||||
1. Tickless idle: 不使用固定tick, 动态调整tick间隔
|
||||
2. Deep sleep: 推理间隙进入深睡眠
|
||||
3. Clock gating: 禁用未使用外设的时钟
|
||||
4. RAM retention: 深睡眠时保持RAM内容
|
||||
|
||||
Implementation:
|
||||
// 推理间隙功耗管理
|
||||
void manage_inference_power(void) {
|
||||
if (npu_idle && cpu_idle) {
|
||||
// Enter low-power mode
|
||||
enter_deep_sleep();
|
||||
|
||||
// Wake on NPU interrupt or timer
|
||||
sleep_until(wake_source);
|
||||
|
||||
// Restore state
|
||||
restore_from_deep_sleep();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 动态功耗监控
|
||||
|
||||
```
|
||||
Power Monitoring (RTOS Task):
|
||||
|
||||
void power_monitor_task(void *params) {
|
||||
for (;;) {
|
||||
// Read power sensors
|
||||
float cpu_power = read_power_sensor(CPU);
|
||||
float npu_power = read_power_sensor(NPU);
|
||||
float ddr_power = read_power_sensor(DDR);
|
||||
float total_power = cpu_power + npu_power + ddr_power;
|
||||
|
||||
// Update power model
|
||||
update_power_model(total_power);
|
||||
|
||||
// Check thresholds
|
||||
if (total_power > POWER_LIMIT) {
|
||||
trigger_throttling();
|
||||
}
|
||||
|
||||
if (battery_level < BATTERY_WARN) {
|
||||
notify_low_battery();
|
||||
}
|
||||
|
||||
vTaskDelay(pdMS_TO_TICKS(10)); // Check every 10ms
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 6. 各平台的功耗-调度差异
|
||||
|
||||
### 6.1 MCU级
|
||||
|
||||
```
|
||||
功耗特性:
|
||||
- Sleep: < 1μW (deep sleep)
|
||||
- Active: 50-200mW
|
||||
- DVFS: 有限 (2-4 states)
|
||||
- 热: 被动散热, R_thermal ~10°C/W
|
||||
|
||||
策略:
|
||||
- 大量使用sleep模式
|
||||
- 计算密集型任务集中执行, 然后sleep
|
||||
- DVFS简单, 调度变化小
|
||||
```
|
||||
|
||||
### 6.2 SoC级
|
||||
|
||||
```
|
||||
功耗特性:
|
||||
- Sleep: ~10mW (peripheral sleep)
|
||||
- Active: 300-1300mW
|
||||
- DVFS: 丰富 (8+ states)
|
||||
- 热: 被动散热, R_thermal ~5°C/W
|
||||
|
||||
策略:
|
||||
- 精细的DVFS控制
|
||||
- 多核独立频率
|
||||
- NPU专属低功耗模式
|
||||
- 热感知调度 (关键)
|
||||
```
|
||||
|
||||
### 6.3 Edge盒子
|
||||
|
||||
```
|
||||
功耗特性:
|
||||
- Sleep: ~50mW (standby)
|
||||
- Active: 500-2000mW
|
||||
- DVFS: 丰富 (10+ states)
|
||||
- 热: 主动+被动散热
|
||||
|
||||
策略:
|
||||
- 精细的热管理
|
||||
- CPU-NPU负载均衡
|
||||
- 功耗capping
|
||||
- 预测性调度
|
||||
```
|
||||
|
||||
### 6.4 Server级
|
||||
|
||||
```
|
||||
功耗特性:
|
||||
- Sleep: ~1W
|
||||
- Active: 100-500W
|
||||
- DVFS: 极丰富
|
||||
- 热: 主动散热 (fan + heatsink)
|
||||
|
||||
策略:
|
||||
- PUE优化
|
||||
- GPU NVLink功耗管理
|
||||
- NUMA功耗均衡
|
||||
- 数据中心级功耗管理
|
||||
```
|
||||
|
||||
## 7. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，能耗与热管理至少要回答下面三个问题：
|
||||
|
||||
1. 人工智能目标负载在长稳运行下的 `TTFT`、`TPOT` 和吞吐是否因降频与热保护发生持续退化；
|
||||
2. 关键保障负载是否会因为 DVFS、休眠唤醒或热限额而出现额外抖动和截止期违约；
|
||||
3. 功率与热管理机制是否能把 24 h 稳定性、恢复时间和能效指标变成可测量、可复现的证据。
|
||||
|
||||
## 8. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
| DVFS粒度 | Global / Per-core / Per-device | **Per-core** | 灵活性+实时性可接受 |
|
||||
| 热管理 | PID / Rule-based / ML | **PID** | 确定性+可分析 |
|
||||
| 空闲管理 | Tickless / Deep-sleep / Clock-gate | **混合** | 按场景选择 |
|
||||
| 功耗监控 | Hardware / Software | **Hardware** | 精度+低开销 |
|
||||
| 热感知 | Reactive / Predictive | **Predictive** | 减少延迟抖动 |
|
||||
| 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
|
||||
|
||||
## 9. 开放研究问题
|
||||
|
||||
1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
|
||||
2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？
|
||||
3. **Battery-aware Scheduling**: 电池电量变化时的调度策略自适应？
|
||||
4. **Cross-component Thermal**: CPU+NPU+DDR的联合热建模？
|
||||
5. **Power-perf SLA**: 同时满足性能和功耗SLA的调度？
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,294 @@
|
||||
# 方向7：方法论与评估工具链
|
||||
|
||||
## 1. 方法论总框架
|
||||
|
||||
本研究的方法论围绕下面这个核心判断展开：
|
||||
|
||||
> **在五类部署形态下，大型跨平台实时操作系统在任务关键系统中支撑人工智能目标负载、维持关键保障负载实时边界的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。**
|
||||
|
||||
因此，方法论采用 **“准入 → 对照 → 建模 → 机制实现 → 实测验证 → 跨档位分析”** 的闭环。
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Step 1: 平台与测量准入 │
|
||||
│ - 设备、OS、加速器、模型、计时链路、功率计 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 2: 公平对照设计 │
|
||||
│ - O0 普通 Linux / O1 PREEMPT_RT / O2-O3 SylixOS │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 3: 负载建模 │
|
||||
│ - 人工智能目标负载 / 关键保障负载 / 伴生竞争负载 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 4: 机制实现 │
|
||||
│ - 调度、隔离、内存、中断、准入、能耗与热管理 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 5: 实测验证 │
|
||||
│ - 双目标达标、长稳、恢复、消融、统计显著性 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 6: 跨档位分析 │
|
||||
│ - T5~T1 五类部署形态、11 个代表档位的规律与边界 │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 2. 研究对象、对照对象与验证矩阵
|
||||
|
||||
### 2.1 研究对象
|
||||
|
||||
主研究对象是：
|
||||
|
||||
- **大型跨平台实时操作系统这一类平台**
|
||||
- 其中 `SylixOS` 是主实验样例
|
||||
- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本
|
||||
- 其实时调度、资源隔离、中断管理、内存管理和恢复机制
|
||||
|
||||
### 2.2 对照对象
|
||||
|
||||
后续所有实验统一采用三层 OS 对照：
|
||||
|
||||
| 编号 | 对照对象 | 作用 |
|
||||
|---|---|---|
|
||||
| `O0` | 普通 Linux | 通用系统基线 |
|
||||
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
|
||||
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
|
||||
| `O3` | SylixOS 优化配置 | 主实验样例优化组 |
|
||||
|
||||
必要时可增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，容器或虚拟机仅作为部署方式记录，不单独列为新的“内核类别”。
|
||||
|
||||
### 2.3 验证矩阵
|
||||
|
||||
硬件承担关键验证矩阵角色。
|
||||
`T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
|
||||
|
||||
这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
|
||||
|
||||
对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
|
||||
|
||||
- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
|
||||
- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
|
||||
|
||||
前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
|
||||
|
||||
## 3. 负载建模：三类负载
|
||||
|
||||
### 3.1 三类负载定义
|
||||
|
||||
| 负载类型 | 定义 | 例子 |
|
||||
|---|---|---|
|
||||
| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
|
||||
| 关键保障负载 | 维持任务关键系统边界的核心任务 | 1 ms 控制回路、联锁、状态采集、执行闭环 |
|
||||
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、存储、网络 I/O、模型加载 |
|
||||
|
||||
### 3.2 建模目标
|
||||
|
||||
本研究统一评估三项内容：
|
||||
|
||||
1. 人工智能目标负载是否按时并有效地完成；
|
||||
2. 关键保障负载是否仍满足截止期与抖动边界；
|
||||
3. 系统在两类目标并存时是否保持稳定、可解释和可恢复。
|
||||
|
||||
### 3.3 任务图抽象
|
||||
|
||||
```
|
||||
人工智能目标负载：
|
||||
输入处理 → Prefill / 前处理 → 设备计算 → 输出决策 → 结果返回
|
||||
|
||||
关键保障负载：
|
||||
周期释放 → 传感采集 → 控制计算 → 执行输出 → 状态确认
|
||||
|
||||
伴生竞争负载：
|
||||
日志写入 / 网络收发 / 模型加载 / 存储 I/O / 管理服务
|
||||
```
|
||||
|
||||
后续所有调度建模，都围绕这三类负载的竞争关系来分析。
|
||||
|
||||
## 4. 评价框架：双目标达标 + 系统协同
|
||||
|
||||
### 4.1 人工智能目标负载指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 时效 | `TTFT`、`TPOT`、端到端响应时间 |
|
||||
| 有效性 | 精度、成功率、任务完成率、输出可用性 |
|
||||
| 稳定性 | 长时间运行退化、失败率、热漂移影响 |
|
||||
|
||||
### 4.2 关键保障负载指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 截止期 | `deadline miss ratio` |
|
||||
| 尾部行为 | `P99/P99.9 jitter`、观测最大响应时间 |
|
||||
| 外部接口 | GPIO / CAN / RS485 / 网络回路端到端响应 |
|
||||
|
||||
### 4.3 系统协同指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 效率 | 有效吞吐、拒绝率、恢复时间 |
|
||||
| 能效 | `E/token`、`tokens/J`、整机功耗 |
|
||||
| 稳定性 | 温度、降频时间比例、24 h 长稳表现 |
|
||||
| 公平性 | 多任务 / 多模型并发下的资源分配与隔离效果 |
|
||||
|
||||
因此，论文与实验的通过标准应统一为：
|
||||
|
||||
> **人工智能目标负载达标 + 关键保障负载达标 + 系统协同稳定。**
|
||||
|
||||
## 5. 准入机制
|
||||
|
||||
为了保证后续对照具有可信度，所有平台必须通过分阶段准入：
|
||||
|
||||
| 门槛 | 核心内容 |
|
||||
|---|---|
|
||||
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑正确 |
|
||||
| `G1` 测量准入 | 单调时钟、日志、功率计、外部测量链路 |
|
||||
| `G2` 加速器准入 | 驱动加载、最小算子、结果回读 |
|
||||
| `G3` 模型准入 | 模型转换、加载、推理、释放、重复运行 |
|
||||
| `G4` 混合负载准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
|
||||
|
||||
任何准入失败都要作为研究记录保留。
|
||||
|
||||
对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
|
||||
|
||||
## 6. 对照原则
|
||||
|
||||
### 6.1 固定不变项
|
||||
|
||||
为了保证 OS 对照公平，以下变量必须冻结：
|
||||
|
||||
- 模型版本、量化格式、tokenizer、输入长度与输出长度；
|
||||
- CPU 核数量、优先级、内存预算、加速器数量；
|
||||
- 到达流、随机种子、预热时间、采样窗口；
|
||||
- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
|
||||
- 环境温度、散热、驱动与框架版本。
|
||||
|
||||
### 6.2 允许变化项
|
||||
|
||||
允许作为自变量扫描的内容包括：
|
||||
|
||||
- OS 类型与配置；
|
||||
- 调度策略与核隔离；
|
||||
- IRQ 亲和与中断线程化；
|
||||
- 内存限额、KV Cache 预分配与准入控制；
|
||||
- 功率与频率策略；
|
||||
- 并发度、到达率和背景干扰强度。
|
||||
|
||||
## 7. 建模与分析方法
|
||||
|
||||
### 7.1 可调度性与响应时间分析
|
||||
|
||||
关键保障负载优先使用固定优先级与响应时间分析：
|
||||
|
||||
```
|
||||
R_i^(0) = C_i
|
||||
R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
- `C_i` 为关键保障任务的执行时间；
|
||||
- `T_j` 为高优先级任务周期；
|
||||
- `R_i` 为响应时间。
|
||||
|
||||
人工智能目标负载根据其服务目标与预算，被建模为：
|
||||
|
||||
- 可限流的服务任务；
|
||||
- 可准入的队列任务；
|
||||
- 可隔离的设备任务；
|
||||
- 必要时具有阶段性优先级的任务图。
|
||||
|
||||
当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
|
||||
|
||||
### 7.2 容量与热稳定性分析
|
||||
|
||||
对人工智能目标负载，需要同时分析：
|
||||
|
||||
- 模型权重占用；
|
||||
- KV Cache 增长；
|
||||
- 中间激活与工作区；
|
||||
- 运行时与驱动保留区；
|
||||
- 温度导致的频率变化。
|
||||
|
||||
因此，容量与热是实时保障能否成立的前提条件。
|
||||
|
||||
### 7.3 消融分析
|
||||
|
||||
系统机制收益通过逐项消融来解释，例如：
|
||||
|
||||
1. 去掉 CPU 核隔离；
|
||||
2. 去掉 IRQ 亲和；
|
||||
3. 去掉内存预分配；
|
||||
4. 去掉推理准入控制；
|
||||
5. 去掉功耗感知策略。
|
||||
|
||||
每次只移除一个机制，观察双目标达标边界的变化。
|
||||
|
||||
## 8. 工具链
|
||||
|
||||
### 8.1 采样与追踪工具
|
||||
|
||||
| 类别 | 代表工具 |
|
||||
|---|---|
|
||||
| OS 追踪 | RTOS trace、ftrace、事件日志 |
|
||||
| 性能分析 | perf、设备 profiler、定制采样脚本 |
|
||||
| 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
|
||||
| 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
|
||||
| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
|
||||
|
||||
下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
|
||||
|
||||
| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
|
||||
|---|---|---|---|
|
||||
| 人工智能目标负载时效 | `TTFT`、`TPOT`、端到端响应时间 | 应用层时间戳、推理引擎日志、设备 profiler | 判断智能功能是否按服务时限完成 |
|
||||
| 人工智能目标负载有效性 | 精度、成功率、任务完成率、输出可用性 | 数据集回放脚本、结果校验脚本、业务判分程序 | 避免只优化时延而牺牲输出质量 |
|
||||
| 关键保障负载实时性 | `deadline miss ratio`、观测最大响应时间 | RTOS trace、GPIO 打点、示波器、逻辑分析仪 | 判断关键任务是否仍满足实时边界 |
|
||||
| 尾部抖动行为 | `P99/P99.9 jitter`、突发峰值延迟 | 高精度事件日志、外部时序测量、分位统计脚本 | 识别平均值掩盖下的尾部失稳 |
|
||||
| CPU 与调度行为 | 核占用、上下文切换、迁核、中断干扰 | perf、ftrace、调度事件日志 | 解释不同 OS 机制下的调度差异 |
|
||||
| 内存与容量行为 | 峰值内存、KV Cache 增长、分配失败率 | `/proc`、驱动日志、运行时统计、定制采样脚本 | 判断容量边界与动态分配抖动来源 |
|
||||
| 功率与热稳定性 | 整机功耗、芯片温度、降频时间比例 | 外部功率计、PDU、板载传感器、温度记录 | 判断长稳阶段是否因热或供电触发退化 |
|
||||
| I/O 与外设链路 | GPIO/CAN/RS485/网络回路时延 | 示波器、总线分析仪、抓包工具 | 验证系统外部闭环而非仅内部线程表现 |
|
||||
| 恢复与稳态行为 | 故障恢复时间、重试成功率、24 h 退化曲线 | 守护日志、错误注入脚本、长稳记录程序 | 判断系统是否具备工程可用性 |
|
||||
|
||||
### 8.2 理论与仿真工具
|
||||
|
||||
| 类别 | 作用 |
|
||||
|---|---|
|
||||
| RTA / WCET 分析 | 关键保障负载响应时间边界分析 |
|
||||
| 抽象仿真框架 | 参数扫描、到达流与机制对比 |
|
||||
| 架构级仿真 | 必要时验证拓扑与内存模型假设 |
|
||||
|
||||
这里的仿真用于机制理解、参数扫描与拓扑假设验证。
|
||||
主线验证平台为 **SylixOS 与其对照系统**。
|
||||
|
||||
## 9. 实验流程
|
||||
|
||||
统一实验流程如下：
|
||||
|
||||
1. 完成 `G0~G4` 准入；
|
||||
2. 建立 `O0/O1/O2/O3` 对照组；
|
||||
3. 先测空载与仅人工智能目标负载基线；
|
||||
4. 再测人工智能目标负载与关键保障负载并存场景；
|
||||
5. 加入 CPU / 内存 / I/O / 网络等伴生竞争负载；
|
||||
6. 进行长稳、突发、恢复与消融实验；
|
||||
7. 进行跨档位和跨部署形态对比。
|
||||
|
||||
## 10. 可复现性要求
|
||||
|
||||
每次运行至少保存以下元数据：
|
||||
|
||||
- 档位、设备编号、OS/BSP/驱动版本；
|
||||
- 模型校验值、量化格式、输入模板、随机种子；
|
||||
- CPU/IRQ/频率/内存配置；
|
||||
- 环境温度、散热方式、测量仪器；
|
||||
- 原始延迟、功率、温度与错误日志。
|
||||
|
||||
只有满足这些条件，后续论文中的“优势”才具备可外部讨论的基础。
|
||||
|
||||
## 11. 本文档在整个仓库中的作用
|
||||
|
||||
本文件负责回答三个问题：
|
||||
|
||||
1. **怎么保证研究对象始终落在 RTOS 平台层；**
|
||||
2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
|
||||
3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
|
||||
4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
|
||||
|
||||
这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
|
||||
@@ -0,0 +1,60 @@
|
||||
# 研究框架索引
|
||||
|
||||
本目录放置项目的核心研究框架文档，分为两部分：
|
||||
|
||||
1. **主干机制文档**：作为公共研究材料，沉淀已经形成的主线表达、机制拆解与方法论；
|
||||
2. **候选课题框架目录**：并行维护 3 套可讨论、可修改、可优选的课题框架方案。
|
||||
|
||||
## 阅读建议
|
||||
|
||||
### 1. 主干机制文档
|
||||
|
||||
1. `00-整体研究框架.md`
|
||||
2. `01-推理图任务调度.md`
|
||||
3. `02-KV-Cache与内存管理.md`
|
||||
4. `03-加速器协同调度.md`
|
||||
5. `04-量化精度感知调度.md`
|
||||
6. `05-中断与实时性保障.md`
|
||||
7. `06-能耗与热管理.md`
|
||||
8. `07-方法论与评估工具链.md`
|
||||
9. `参考文件/README.md`
|
||||
|
||||
### 2. 候选课题框架目录
|
||||
|
||||
1. `方案A-RTOS平台主导框架/00-课题框架.md`
|
||||
2. `方案B-系统协同保障框架/00-课题框架.md`
|
||||
3. `方案C-小型化与低功耗应用框架/00-课题框架.md`
|
||||
|
||||
## 文件说明
|
||||
|
||||
- `00-整体研究框架.md`
|
||||
- 研究总框架、问题空间、技术分层、预期成果
|
||||
- `01-推理图任务调度.md`
|
||||
- LLM 推理 DAG 拆解、任务映射与调度策略
|
||||
- `02-KV-Cache与内存管理.md`
|
||||
- KV Cache 生命周期、内存池、带宽竞争与局部性
|
||||
- `03-加速器协同调度.md`
|
||||
- CPU、NPU、GPU、DMA 等异构资源协同
|
||||
- `04-量化精度感知调度.md`
|
||||
- 精度、资源占用和调度决策的联动关系
|
||||
- `05-中断与实时性保障.md`
|
||||
- IRQ 路径、线程化、中断隔离与实时任务保护
|
||||
- `06-能耗与热管理.md`
|
||||
- 能耗约束、温度耦合、频率策略与热稳定性
|
||||
- `07-方法论与评估工具链.md`
|
||||
- 建模、仿真、原型验证和评估方法学
|
||||
- `参考文件/`
|
||||
- 按研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射
|
||||
|
||||
## 候选框架说明
|
||||
|
||||
- `方案A-RTOS平台主导框架`
|
||||
- 保持“大型跨平台 RTOS”作为研究主语，适合继续沿现有主线推进
|
||||
- `方案B-系统协同保障框架`
|
||||
- 强调 RTOS、运行时、模型与加速器协同治理，适合承接系统级方法学讨论
|
||||
- `方案C-小型化与低功耗应用框架`
|
||||
- 强调 `T5/T4` 受限系统与低功耗应用场景，适合形成更聚焦的专题路线
|
||||
|
||||
## 使用方式
|
||||
|
||||
后续讨论、修改和优选时，可以优先在这 3 个候选目录中推进，不必立即改动主干机制文档。待最终课题框架确定后，再把优选结果回收进 `00-整体研究框架.md` 及相关主干文件。
|
||||
@@ -0,0 +1,43 @@
|
||||
# 推理图任务调度参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向连接两类研究：一类是固定优先级、EDF、响应时间分析等经典实时调度理论；另一类是 LLM 服务中的连续批处理、prefill/decode 分离、分块 prefill 和 SLO 感知调度。本项目的增量应落在两者交叉处：把推理图阶段映射为可度量、可准入、可隔离的 RTOS 任务，同时保障关键周期任务。
|
||||
|
||||
## 2. 核心必引资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” JACM, 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | 周期任务、固定优先级与 EDF 的理论基础 | 定义关键保障任务模型和可调度性讨论的起点 |
|
||||
| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和释放抖动的固定优先级响应时间分析 | 为推理、中断与共享资源干扰进入 RTA 提供基础 |
|
||||
| W. Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022. [USENIX](https://www.usenix.org/conference/osdi22/presentation/yu) | A | 迭代级调度和连续批处理 | 作为 LLM 服务调度基线，不作为实时保证 |
|
||||
| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 请求调度与 KV 分页耦合、吞吐提升 | 支撑调度与内存联合设计及 vLLM 对照 |
|
||||
| A. Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/agrawal) | A | 分块 prefill、decode 干扰与吞吐—时延权衡 | 支撑 prefill 可分段化和关键任务插入点设计 |
|
||||
| Y. Zhong et al., “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin) | A | TTFT/TPOT 双 SLO、prefill/decode 解耦和 goodput | 对应本项目 TTFT、TPOT 和有效吞吐联合门槛 |
|
||||
|
||||
## 3. 扩展参考
|
||||
|
||||
| 资料 | 关注点 |
|
||||
|---|---|
|
||||
| A. Gujarati et al., “Serving DNNs like Clockwork: Performance Predictability from the Bottom Up,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | DNN 推理可预测性、受控执行和 deadline-aware 调度 |
|
||||
| A. Agrawal et al., “SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills,” 2023. [arXiv](https://arxiv.org/abs/2308.16369) | prefill 分块、decode-maximal batching 与流水线气泡 |
|
||||
|
||||
## 4. 可形成的论文论点
|
||||
|
||||
1. 把 `prefill/decode/postprocess` 从服务框架内部阶段提升为可被 RTOS 观测和治理的任务图节点。
|
||||
2. 比较固定优先级、EDF、混合优先级和准入控制在双目标场景下的边界。
|
||||
3. 以满足 `TTFT + TPOT + 关键任务 deadline` 的有效吞吐，而不是总 tokens/s，作为调度目标。
|
||||
4. 分析推理阶段不可抢占区间、驱动提交和完成中断对 RTA 的附加阻塞项。
|
||||
|
||||
## 5. 对应证据与实验
|
||||
|
||||
- 指标：`TTFT`、`TPOT`、端到端时延、有效吞吐、关键任务 `P99.9/Max`、违约率。
|
||||
- 场景：L1、L2、L3、L5、L7。
|
||||
- 对照：FCFS/默认批处理、连续批处理、分块 prefill、完整 RTOS 方案及消融。
|
||||
- 关键边界：GPU/NPU 内核通常不能被 CPU 调度器直接细粒度抢占，必须实测设备与驱动行为。
|
||||
|
||||
## 6. 不应直接推出的结论
|
||||
|
||||
- 云端 LLM 系统的 SLO 达标不等于硬实时保证。
|
||||
- 平均 tokens/s 提升不能说明关键保障任务更可预测。
|
||||
- RTA 中的执行时间和阻塞项若未经目标硬件测量，不能作为安全上界。
|
||||
@@ -0,0 +1,41 @@
|
||||
# KV Cache 与内存管理参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
KV Cache 同时影响容量、内存带宽、请求并发和尾延迟。在 RTOS 场景中，研究重点不是单纯提高缓存命中率，而是控制动态分配、换入换出、DMA 和回收行为对关键任务造成的不可预测干扰。
|
||||
|
||||
## 2. 核心必引资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 块式 KV 分配、碎片控制、共享与调度耦合 | 作为分页池设计和 vLLM 基线 |
|
||||
| Y. Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/sheng23a.html) | A | GPU/CPU/存储分层放置与 I/O 调度 | 支撑分层 KV/权重放置，但需强调其吞吐导向 |
|
||||
| Z. Zhang et al., “H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html) | A | 基于重要 token 的 KV 淘汰及质量影响 | 用于“容量—质量—时延”三目标实验 |
|
||||
| W. Lee et al., “InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/lee) | A | KV 预取、CPU offload、动态池管理 | 对应 CPU—加速器带宽与预取干扰研究 |
|
||||
| P. Patel et al., “vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention,” 2024. [arXiv](https://arxiv.org/abs/2405.04437) | B | 利用虚拟内存保持逻辑连续、比较分页内核复杂度 | 作为 PagedAttention 的替代路线和消融参考 |
|
||||
|
||||
## 3. 研究问题映射
|
||||
|
||||
| 本项目问题 | 参考资料启发 | 必须补充的 RTOS 证据 |
|
||||
|---|---|---|
|
||||
| 内存池预分配是否减少尾延迟 | PagedAttention 的块式管理 | 分配路径时延、关键任务 `P99.9/Max`、碎片率 |
|
||||
| KV 换出是否可控 | FlexGen、InfiniGen | DMA/内存带宽竞争、外部接口响应和违约率 |
|
||||
| KV 淘汰如何影响可用性 | H2O | 固定题集质量、输出可用率、恢复到全量 KV 的开销 |
|
||||
| 多请求是否相互污染 | 分页与共享机制 | 每租户上限、OOM 隔离、Jain 指数和逐租户 SLO |
|
||||
| B8/B16 容量边界 | 各类压缩/分页工作 | 峰值驻留集、KV 增长曲线、首次失败点和错误类型 |
|
||||
|
||||
## 4. 建议实验变量
|
||||
|
||||
- KV 块大小、内存池大小、预分配比例和保留余量；
|
||||
- 上下文长度、并发度、输出长度和突发到达；
|
||||
- GPU/NPU 本地、主存和存储三级放置；
|
||||
- 淘汰策略：LRU、近期 token、重要 token、固定配额；
|
||||
- 是否锁页、是否异步预取、DMA 并发数和带宽限额。
|
||||
|
||||
输出至少包括峰值内存、碎片率、分配失败率、KV 迁移字节数、带宽、`TTFT/TPOT`、质量、关键任务尾延迟和 OOM 恢复行为。
|
||||
|
||||
## 5. 不应直接推出的结论
|
||||
|
||||
- 内存占用减少不必然降低端到端时延；压缩、索引和搬移可能增加尾延迟。
|
||||
- 论文中的 perplexity 或准确率保持不代表任务关键应用输出可用。
|
||||
- Linux/CUDA 的虚拟内存和 UVM 机制不能假定在 SylixOS、NPU SDK 或受限 SoC 上等价存在。
|
||||
@@ -0,0 +1,54 @@
|
||||
# 加速器协同调度参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向研究 CPU 调度、驱动提交、DMA、GPU/NPU 执行和完成中断组成的完整链路。核心是识别哪些环节受 RTOS 控制，哪些环节只受厂商运行时或固件控制，并通过端到端时间戳验证协同效果。
|
||||
|
||||
## 2. 核心资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| NVIDIA, “CUDA Programming Guide: Asynchronous Execution, Streams and Events.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html) | A | 流、事件、同步、并发和优先级语义 | 定义 CUDA 路线中的提交和同步边界 |
|
||||
| NVIDIA, “CUDA Programming Guide: Unified Memory.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/unified-memory.html) | A | CPU/GPU 统一内存、迁移及流关联 | 解释缺页/迁移引入的不确定性，不能替代实测 |
|
||||
| Z. Bai et al., “PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/bai) | A | GPU 应用切换、模型传输与执行流水化 | 支撑多模型共享和切换开销研究 |
|
||||
| A. Gujarati et al., “Serving DNNs like Clockwork,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | A | 可预测 GPU 推理、执行时间建模和准入 | 作为加速器可预测性相邻工作 |
|
||||
| Y. Choi, M. Rhu, “PREMA: A Predictive Multi-task Scheduling Algorithm for Preemptible Neural Processing Units,” HPCA 2020. [DOI](https://doi.org/10.1109/HPCA47549.2020.00030) | A | 可抢占 NPU 多任务预测调度 | 支撑 NPU 细粒度抢占的研究假设，需检查实际硬件支持 |
|
||||
| MLCommons, “MLPerf Inference.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、负载发生和准确率约束 | 用于外部性能方法对齐，不替代双目标测试 |
|
||||
|
||||
## 3. 硬件路线需单独核对的官方资料
|
||||
|
||||
- NVIDIA：CUDA Toolkit、驱动、MPS/MIG、DCGM 与 NCCL 对应版本文档；
|
||||
- Rockchip：RKNN Toolkit2、RKLLM、RKNPU2 Runtime 与对应芯片技术参考；
|
||||
- 其他 NPU/GPU：运行时队列、优先级、超时、复位、DMA 和性能计数器文档；
|
||||
- SylixOS：BSP、中断、DMA、一致性、IOMMU 和驱动接口资料。
|
||||
|
||||
闭源资料若不能公开引用，应在论文中描述可复现的外部行为，不披露受限内容。
|
||||
|
||||
## 4. 建议链路分解
|
||||
|
||||
```text
|
||||
请求到达
|
||||
→ CPU 预处理
|
||||
→ 驱动/运行时提交
|
||||
→ DMA/内存迁移
|
||||
→ 加速器排队
|
||||
→ kernel/NPU task 执行
|
||||
→ 完成中断
|
||||
→ CPU 后处理
|
||||
→ 外部输出
|
||||
```
|
||||
|
||||
每段都应有时间戳或外部观测点。设备事件只能衡量设备域执行，不能替代 CPU 到结果可用的端到端时延。
|
||||
|
||||
## 5. 可形成的论文论点
|
||||
|
||||
1. RTOS 可通过 CPU/IRQ 亲和性、队列限长、预分配和准入减少主机侧不确定性。
|
||||
2. 加速器运行时不提供硬优先级保证时，RTOS 的收益会受设备不可抢占区间限制。
|
||||
3. 异步流水可能提高吞吐，但需要同时检查关键任务尾延迟、内存带宽和中断干扰。
|
||||
4. 多加速器扩展需分开报告单请求并行、多实例吞吐与通信开销。
|
||||
|
||||
## 6. 不应直接推出的结论
|
||||
|
||||
- CUDA stream priority 是调度提示，不是硬实时保证。
|
||||
- GPU 支持并发 kernel 不代表特定工作负载必然并发执行。
|
||||
- 加速器利用率高不等于有效吞吐高，也不等于关键任务 deadline 达标。
|
||||
@@ -0,0 +1,44 @@
|
||||
# 量化与精度感知调度参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向不只比较 INT4/INT8/FP16 的速度，而是研究在不同任务紧迫度、资源预算和热状态下，能否选择满足质量门槛的最低成本精度，并保证切换过程不会破坏关键任务实时性。
|
||||
|
||||
## 2. 核心必引资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| E. Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers,” ICLR 2023. [OpenReview](https://openreview.net/forum?id=tcbBPnfwxS) | A | 基于近似二阶信息的低比特权重量化 | 作为 3/4-bit PTQ 方法基线 |
|
||||
| G. Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/xiao23c.html) | A | W8A8、激活离群值平滑、硬件效率 | 作为 INT8 权重—激活量化基线 |
|
||||
| J. Lin et al., “AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration,” MLSys 2024. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html) | A | 面向端侧的激活感知权重量化 | 对应 T5/T4/T3 设备端路线 |
|
||||
| T. Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale,” NeurIPS 2022. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html) | A | 激活离群值与混合精度分解 | 支撑异常通道和精度保持讨论 |
|
||||
| T. Dettmers et al., “QLoRA: Efficient Finetuning of Quantized LLMs,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html) | A | NF4、双重量化和分页优化器 | 主要用于背景；本项目若不训练，不作为主实验 |
|
||||
| Z. Lin et al., “QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving,” MLSys 2025. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html) | A | 权重、激活和 KV 联合低比特系统设计 | 支撑量化与内存/内核协同研究 |
|
||||
|
||||
## 3. 精度感知调度应补足的研究空白
|
||||
|
||||
现有量化论文通常回答“某种格式能否保持平均精度并加速推理”，但本项目还需要回答：
|
||||
|
||||
- 精度切换是否引起模型加载、重新编译、缓存失效或内存峰值；
|
||||
- 动态切换期间关键保障负载是否出现尾延迟峰值；
|
||||
- 低比特内核在目标 NPU/GPU 上是否真正加速，而非只有模型更小；
|
||||
- 质量门槛、实时门槛和功耗门槛能否同时满足；
|
||||
- 对不同风险等级请求，能否采用不同的可接受精度下限。
|
||||
|
||||
## 4. 建议实验矩阵
|
||||
|
||||
| 维度 | 建议取值 |
|
||||
|---|---|
|
||||
| 精度 | FP16/BF16、INT8、INT4；仅测试后端真实支持项 |
|
||||
| 模型变量 | 同一模型修订、同一 tokenizer、同一输入与解码参数 |
|
||||
| 质量 | 固定题集、perplexity/准确率/F1/任务判分、输出可用率 |
|
||||
| 性能 | TTFT、TPOT、端到端时延、有效吞吐 |
|
||||
| 系统 | 峰值内存、切换时间、能耗、温度、关键任务违约与尾延迟 |
|
||||
| 调度 | 静态精度、基于 deadline 的精度、基于热/功耗预算的精度 |
|
||||
|
||||
## 5. 不应直接推出的结论
|
||||
|
||||
- 权重压缩比不能替代整机内存、速度或能效实测。
|
||||
- perplexity 接近不等于所有任务质量和安全性等价。
|
||||
- 不同量化后端的算子、校准和数值格式不同，通常只能视为整套软件栈比较。
|
||||
- 动态精度调度若未测切换开销，不能宣称适合实时路径。
|
||||
@@ -0,0 +1,54 @@
|
||||
# 中断与实时性保障参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向为论文的“可保障性”提供理论和系统基础，覆盖固定优先级响应时间、共享资源阻塞、优先级倒置、中断线程化、CPU/IRQ 亲和性以及外部闭环测量。
|
||||
|
||||
## 2. 经典理论资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | RMS/EDF 与周期任务基础 | 建立基本任务模型 |
|
||||
| L. Sha, R. Rajkumar, J. P. Lehoczky, “Priority Inheritance Protocols: An Approach to Real-Time Synchronization,” IEEE TC, 1990. [DOI](https://doi.org/10.1109/12.57058) | A | 优先级继承、优先级上限与有界阻塞 | 支撑锁竞争和优先级倒置分析 |
|
||||
| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和抖动的精确固定优先级分析 | 构建含 IRQ/驱动阻塞的 RTA |
|
||||
| K. Tindell, A. Burns, A. Wellings, “An Extendible Approach for Analyzing Fixed Priority Hard Real-Time Tasks,” Real-Time Systems, 1994. [DOI](https://doi.org/10.1007/BF01088593) | A | 固定优先级分析扩展 | 用于更复杂任务和通信分析 |
|
||||
|
||||
## 3. 内核与测量资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 |
|
||||
|---|---|---|
|
||||
| Linux Kernel, “PREEMPT_RT Theory of Operation.” [官方文档](https://docs.kernel.org/core-api/real-time/theory.html) | A | 可抢占锁、rtmutex、优先级继承和线程化中断 |
|
||||
| Linux Kernel, “How realtime kernels differ.” [官方文档](https://docs.kernel.org/core-api/real-time/differences.html) | A | 普通 Linux 与 PREEMPT_RT 的内核语义差异 |
|
||||
| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | 唤醒延迟工具、参数、限制和最大值解释 |
|
||||
| Linux `rt-tests` 项目. [kernel.org](https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/) | B | cyclictest、hwlatdetect 等实现与版本记录 |
|
||||
|
||||
## 4. 本项目分析框架
|
||||
|
||||
关键任务响应时间可写为：
|
||||
|
||||
```text
|
||||
R_i = C_i + B_i + I_irq,i + I_sched,i
|
||||
+ sum(ceil((R_i + J_h) / T_h) * C_h)
|
||||
```
|
||||
|
||||
其中 `C_i` 是自身执行时间，`B_i` 是共享资源阻塞，`I_irq,i` 是中断与驱动干扰，`I_sched,i` 是调度器和不可抢占区间干扰，求和项是高优先级任务干扰。该式只用于组织分析；每个项的取值和适用假设必须单独验证。
|
||||
|
||||
实测至少覆盖：
|
||||
|
||||
- 计划释放、就绪、开始和完成时间；
|
||||
- 唤醒延迟、响应时间、完成抖动、违约率和观测最大值；
|
||||
- IRQ 数量、处理时间、CPU 亲和性和最长关中断区间；
|
||||
- 推理提交、DMA 和完成中断与关键任务峰值的时间关联；
|
||||
- GPIO/CAN/RS485/网络外部回路端到端时延。
|
||||
|
||||
## 5. 对照与消融
|
||||
|
||||
- O0 普通 Linux、O1 PREEMPT_RT、O2 SylixOS 默认、O3 SylixOS 优化、必要时 O4 等预算调优；
|
||||
- 逐项去除 CPU 隔离、IRQ 亲和性、优先级继承、内存预分配和推理准入；
|
||||
- 同时报人工智能有效吞吐代价，避免通过饿死推理任务获得低抖动。
|
||||
|
||||
## 6. 不应直接推出的结论
|
||||
|
||||
- cyclictest 测得的是特定路径的唤醒延迟，通常不等于业务任务完整响应时间。
|
||||
- 实测最大值不是 WCET；零违约不是硬实时证明。
|
||||
- PREEMPT_RT 和专用 RTOS 的机制差异必须通过等价任务语义比较，不能只比较工具默认输出。
|
||||
@@ -0,0 +1,51 @@
|
||||
# 能耗与热管理参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向关注满足人工智能和关键实时约束时的能效，而不是脱离任务完成质量的最低功率。功率、温度、频率、有效吞吐和违约必须使用对齐的时间窗口联合分析。
|
||||
|
||||
## 2. 核心资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| MLCommons, “MLPerf Inference Power Measurement.” [官方文档](https://docs.mlcommons.org/inference/power/) | A | 外部功率分析仪、PTDaemon、测量窗口和配置 | 设计整机功耗采集链路 |
|
||||
| MLCommons, “MLPerf Inference Benchmark Suite.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、性能与准确率约束 | 对齐负载发生和结果报告方法 |
|
||||
| SPEC, “SPECpower_ssj2008.” [官方资料](https://www.spec.org/osg/power_ssj2008/) | A | AC 输入功率—性能联合测量、负载档位 | 借鉴整机边界和多负载点报告 |
|
||||
| W. Huang et al., “HotSpot: A Compact Thermal Modeling Methodology for Early-Stage VLSI Design,” IEEE TVLSI, 2006. [DOI](https://doi.org/10.1109/TVLSI.2006.876103) | A | 热 RC 模型、瞬态与稳态温度 | 支撑热动态建模背景，不替代板级传感器实测 |
|
||||
| NVIDIA, “DCGM Field Identifiers.” [官方文档](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html) | A | GPU 功率、能量、温度、频率和降频原因 | V100/H100 路线的设备侧归因数据 |
|
||||
|
||||
## 3. 统一计算口径
|
||||
|
||||
```text
|
||||
E_total = integral(P(t), t0, t1)
|
||||
E/token = E_total / N_output
|
||||
effective_E/token = E_total / N_qualified_output
|
||||
tokens/J = N_output / E_total
|
||||
throttling_ratio = throttled_time / valid_measurement_time
|
||||
```
|
||||
|
||||
主结果使用整机输入端测量。设备遥测只作归因；TDP、标称功耗和电源额定值不能替代实测。`N_output=0` 时能效不可计算。
|
||||
|
||||
## 4. 建议实验
|
||||
|
||||
1. 空闲、prefill、decode 和混合负载分阶段功率曲线；
|
||||
2. 25/50/75/100% 负载下的温度—频率—性能耦合；
|
||||
3. 不同固定频率/DVFS/功耗上限下的 `E/token` 与 deadline miss；
|
||||
4. 冷态、热稳态和 24 h 后的 TTFT/TPOT、吞吐与关键任务尾延迟；
|
||||
5. 降频前后同一到达流的有效吞吐变化；
|
||||
6. O0～O4 在相同双目标门槛下的能效比较。
|
||||
|
||||
每次运行记录环境温度、散热方式、风扇策略、功率计型号、量程、精度和采样率。
|
||||
|
||||
## 5. 可形成的论文论点
|
||||
|
||||
- RTOS 的准入、空闲管理和频率策略可能降低无效执行和失败请求的能耗。
|
||||
- 更低精度或更高并发可能降低 `J/token`，但热饱和后可能扩大尾延迟和违约率。
|
||||
- 应寻找满足双目标约束的 Pareto 前沿，而不是独立最小化功率或最大化吞吐。
|
||||
|
||||
## 6. 不应直接推出的结论
|
||||
|
||||
- 芯片遥测功率不能代表整机功率。
|
||||
- 短时冷态跑分不能代表热稳态或 24 h 性能。
|
||||
- 更低平均功率不等于更低任务能耗；运行时间延长可能提高总能量。
|
||||
- 未取得温箱数据时不能宣称覆盖全温域。
|
||||
@@ -0,0 +1,66 @@
|
||||
# 方法论与评估工具链参考
|
||||
|
||||
## 1. 与本项目的关系
|
||||
|
||||
本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。
|
||||
|
||||
## 2. 核心资料
|
||||
|
||||
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||
|---|---|---|---|
|
||||
| J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. [Google Research](https://research.google/pubs/the-tail-at-scale/) | A | 大规模系统尾延迟的来源和重要性 | 支撑 P99/P99.9 而非均值作为核心证据 |
|
||||
| V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. [arXiv](https://arxiv.org/abs/1911.02549) | A/B | 标准负载发生、场景、准确率与性能方法 | 作为 AI 基准方法学参照 |
|
||||
| MLCommons, “MLPerf Inference Submission Guide.” [官方文档](https://docs.mlcommons.org/inference/submission/) | A | LoadGen、系统描述、Closed/Open division 和可比性 | 设计外部基准对齐和 manifest |
|
||||
| ACM, “Artifact Review and Badging.” [官方政策](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | A | 可用、可运行、可复用与结果复现 | 规划代码、数据和复现包 |
|
||||
| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | RT 延迟测试设计、参数和限制 | 作为 Linux 辅助基线及测量避坑依据 |
|
||||
| R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. [PDF](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf) | A/B | Jain 公平指数 | 多租户相对独占吞吐公平性 |
|
||||
|
||||
## 3. 本项目最低方法要求
|
||||
|
||||
### 3.1 公平对照
|
||||
|
||||
冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。
|
||||
|
||||
### 3.2 样本与重复
|
||||
|
||||
- 普通性能单元至少 5 次独立运行；
|
||||
- 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性；
|
||||
- 1 ms 周期任务记录计划释放数、缺失数和全部违约；
|
||||
- 长稳运行 24 h，保留完整时间序列；
|
||||
- 跨运行使用中位数、区间及按运行/时间块 bootstrap。
|
||||
|
||||
### 3.3 失败处理
|
||||
|
||||
拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。
|
||||
|
||||
### 3.4 三层证据
|
||||
|
||||
```text
|
||||
AI 目标负载：TTFT/TPOT/端到端/质量/可用性
|
||||
关键保障负载：违约率/P99.9/Max/外部闭环
|
||||
系统协同：有效吞吐/E-token/热/公平/恢复/24 h
|
||||
```
|
||||
|
||||
任何“更优”结论都必须说明另外两层是否仍达标。
|
||||
|
||||
## 4. 工具链建议
|
||||
|
||||
| 目的 | 工具或方式 | 注意事项 |
|
||||
|---|---|---|
|
||||
| OS 跟踪 | SylixOS trace、ftrace、perf、事件日志 | 统一事件语义，不直接比较工具自身字段 |
|
||||
| RT 辅助测试 | rt-tests/cyclictest、GPIO 打点 | cyclictest 不等于业务端到端响应 |
|
||||
| 加速器分析 | CUDA profiler/DCGM、RKNN/RKLLM 日志 | 版本固定；设备事件只作阶段分解 |
|
||||
| 外部时序 | 示波器、逻辑分析仪、CAN/RS485 分析仪 | 保存探头、触发、分辨率和空回路基线 |
|
||||
| 功率与热 | 外部功率计/PDU、板载温度与频率 | 时间窗口对齐，遥测不替代整机功率 |
|
||||
| 分析 | R/Python、bootstrap、CDF/ECDF、时间序列 | 不静默删异常，不把相关样本当独立样本 |
|
||||
|
||||
## 5. 推荐数据结构
|
||||
|
||||
每次运行保留 `manifest.json`、`requests.csv`、`rt.csv`、`power.csv`、`thermal.csv`、`events.log` 和 `summary.json`。原始数据只读保存，图表和摘要由版本化脚本生成。
|
||||
|
||||
## 6. 不应直接推出的结论
|
||||
|
||||
- 统计显著不等于工程差异重要，应同时报告效应量与阈值。
|
||||
- 单次最佳结果不能代表配置能力。
|
||||
- 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。
|
||||
- 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。
|
||||
@@ -0,0 +1,57 @@
|
||||
# 标准与工程资料参考
|
||||
|
||||
## 1. 文档定位
|
||||
|
||||
本文件列出论文方向可能涉及但不应与学术论文混为一谈的标准、官方工程文档和安全边界资料。标准是否适用取决于最终行业场景、系统边界和认证目标。
|
||||
|
||||
## 2. 功能安全与任务关键系统
|
||||
|
||||
| 标准/资料 | 适用范围 | 本项目可能的关系 |
|
||||
|---|---|---|
|
||||
| IEC 61508, *Functional safety of electrical/electronic/programmable electronic safety-related systems* | 通用功能安全 | 定义安全生命周期、SIL 和证据要求；本项目不应在未认证时宣称合规 |
|
||||
| ISO 26262, *Road vehicles — Functional safety* | 道路车辆 | 若落到车载控制与 AI 辅助功能，可用于场景和安全目标分解 |
|
||||
| ISO/PAS 8800, *Road vehicles — Safety and artificial intelligence* | 车载 AI 安全 | 用于 AI 输出不确定性、数据和安全论证背景 |
|
||||
| DO-178C | 航空机载软件 | 若研究航空部署，可参考软件保证等级和验证独立性 |
|
||||
| ARINC 653 | 航空综合模块化系统分区 | 支撑时间/空间分区的相邻工程背景 |
|
||||
| IEC 62443 系列 | 工业自动化与控制系统安全 | 涉及联网工业控制时补充网络安全边界 |
|
||||
|
||||
正式引用应从 IEC、ISO、RTCA、EUROCAE、SAE 或 ARINC 的标准目录核对版本与访问权限。标准通常受版权保护，本仓库只保存条目和适用性说明，不复制正文。
|
||||
|
||||
## 3. 实时通信与时间同步
|
||||
|
||||
| 标准/资料 | 作用 | 使用边界 |
|
||||
|---|---|---|
|
||||
| IEEE 802.1AS | 广义精确时间协议 | 跨设备单向时延需要同步精度证据 |
|
||||
| IEEE 802.1Qbv | 时间感知整形 | 可用于 TSN 周期流量窗口规划 |
|
||||
| IEEE 802.1Qbu / IEEE 802.3br | 帧抢占 | 分析关键流量受大帧阻塞的边界 |
|
||||
| IEEE 1588 | 精确时间协议 | 记录 grandmaster、硬件时间戳和误差 |
|
||||
| CAN/CAN FD、RS-485 对应规范 | 工业接口 | 固定波特率、帧长、总线负载和时间戳位置 |
|
||||
|
||||
## 4. 操作系统与处理器接口资料
|
||||
|
||||
- Linux PREEMPT_RT 官方文档：[Real-time preemption](https://docs.kernel.org/core-api/real-time/index.html)。
|
||||
- POSIX 实时扩展：线程调度、时钟、定时器、内存锁定和优先级协议；需按目标 OS 支持集核对。
|
||||
- Arm 架构、GIC、SMMU 和缓存一致性官方手册：用于解释中断路由、DMA 和共享内存边界。
|
||||
- PCIe、IOMMU、NVLink、NCCL 等规范或官方文档：用于多加速器/多节点通信路径。
|
||||
- SylixOS BSP/API/驱动资料：用于确认优先级、中断、内存、设备复位和追踪接口的实际能力。
|
||||
|
||||
## 5. 基准与测量规范
|
||||
|
||||
| 资料 | 可借鉴内容 |
|
||||
|---|---|
|
||||
| [MLPerf Inference](https://docs.mlcommons.org/inference/index_gh/) | 场景、负载发生、准确率约束、系统描述与结果合规 |
|
||||
| [MLPerf Power](https://docs.mlcommons.org/inference/power/) | 外部仪器、时间同步、测量窗口与功率记录 |
|
||||
| [SPECpower_ssj2008](https://www.spec.org/osg/power_ssj2008/) | 整机 AC 功率、多个负载档位与功效比 |
|
||||
| [ACM Artifact Review and Badging](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | 可用、可运行、可复用和结果复现证据 |
|
||||
|
||||
## 6. 论文中的合规表述
|
||||
|
||||
建议使用：
|
||||
|
||||
> 本研究借鉴相关标准中的任务关键性、时间/空间隔离和测量原则，但实验平台与研究原型未经过相应行业认证，因此结果不构成功能安全等级、适航或产品合规声明。
|
||||
|
||||
避免使用：
|
||||
|
||||
- “满足 SIL2/SIL3”——除非完成规定流程并取得正式证据；
|
||||
- “达到航空级/车规级”——除非硬件、软件、流程和环境均符合对应标准；
|
||||
- “证明硬实时安全”——除非有完整时序模型、可信 WCET、可调度性证明和覆盖充分的验证证据。
|
||||
@@ -0,0 +1,51 @@
|
||||
# 论文方向参考文件索引
|
||||
|
||||
## 1. 目录用途
|
||||
|
||||
本目录为 `10-研究框架` 七个研究方向提供可追溯的论文、标准和工程资料入口。它不是完整综述，也不代表文中列出的方案已经在 SylixOS 或本项目硬件上得到验证。
|
||||
|
||||
参考资料按以下证据等级使用：
|
||||
|
||||
| 等级 | 类型 | 建议用途 |
|
||||
|---|---|---|
|
||||
| A | 同行评审论文、正式标准、官方内核/硬件文档 | 支撑定义、方法选择和主要论证 |
|
||||
| B | arXiv 预印本、官方项目文档、开放源码实现 | 支撑前沿方案、实现路线和复现实验 |
|
||||
| C | 厂商白皮书、博客或二手综述 | 仅作背景和线索，不单独支撑核心结论 |
|
||||
|
||||
优先引用论文正式页面、DOI、标准组织或厂商官方文档。正式写作前仍需通过学校或机构数据库核对作者、卷期、页码、版本和 BibTeX。
|
||||
|
||||
## 2. 文件与研究方向映射
|
||||
|
||||
| 文件 | 对应研究文件 | 主要主题 |
|
||||
|---|---|---|
|
||||
| [01-推理图任务调度参考.md](./01-推理图任务调度参考.md) | `01-推理图任务调度.md` | 经典实时调度、LLM 连续批处理、prefill/decode 调度、SLO |
|
||||
| [02-KV-Cache与内存管理参考.md](./02-KV-Cache与内存管理参考.md) | `02-KV-Cache与内存管理.md` | 分页、换出、压缩、淘汰、容量隔离 |
|
||||
| [03-加速器协同调度参考.md](./03-加速器协同调度参考.md) | `03-加速器协同调度.md` | CPU/GPU/NPU 协同、流、事件、DMA、共享与切换 |
|
||||
| [04-量化与精度感知调度参考.md](./04-量化与精度感知调度参考.md) | `04-量化精度感知调度.md` | PTQ、权重量化、激活量化、KV 量化、精度—时延联合约束 |
|
||||
| [05-中断与实时性保障参考.md](./05-中断与实时性保障参考.md) | `05-中断与实时性保障.md` | PREEMPT_RT、优先级继承、响应时间分析、中断线程化、测试 |
|
||||
| [06-能耗与热管理参考.md](./06-能耗与热管理参考.md) | `06-能耗与热管理.md` | 整机功耗、E/token、DVFS、温度、降频与热漂移 |
|
||||
| [07-方法论与评估工具链参考.md](./07-方法论与评估工具链参考.md) | `07-方法论与评估工具链.md` | MLPerf、尾延迟、统计、可复现性、长稳与公平性 |
|
||||
| [08-标准与工程资料参考.md](./08-标准与工程资料参考.md) | 全部方向 | 功能安全、时间敏感网络、硬件接口与工程边界 |
|
||||
| [参考文献.md](./参考文献.md) | 论文十章与整个项目 | 连续编号的论文参考文献候选清单与章节映射 |
|
||||
|
||||
## 3. 建议引用策略
|
||||
|
||||
每项核心主张至少建立“理论基础 + 相邻系统工作 + 本项目实测”三段证据：
|
||||
|
||||
```text
|
||||
经典理论或标准
|
||||
→ LLM/AI 系统领域的相邻工作
|
||||
→ 本项目在 O0～O4、T5～T1 条件下的实测与边界
|
||||
```
|
||||
|
||||
例如，“RTOS 优化提高双目标可保障性”不能只引用 vLLM 或 PREEMPT_RT 文档，而应同时给出实时调度理论、LLM 服务调度工作、对照实验与消融结果。
|
||||
|
||||
## 4. 维护规则
|
||||
|
||||
- 每条新资料需记录标题、作者或组织、年份、正式入口和与本项目的关系。
|
||||
- 预印本被正式会议或期刊接收后，优先替换为正式版本。
|
||||
- 厂商文档需记录访问日期和软件/驱动版本。
|
||||
- 不将论文报告的相对提升直接移植为本项目预期值。
|
||||
- 不将“平均性能改善”表述为硬实时保证；不将“未观测到违约”表述为理论最坏界。
|
||||
|
||||
本目录最后核验日期：**2026-09-21**。
|
||||
@@ -0,0 +1,170 @@
|
||||
# 论文参考文献候选清单
|
||||
|
||||
## 1. 文档说明
|
||||
|
||||
本文依据仓库根目录的 `最终稿文章规划.md`、`00-项目总览`、`10-研究框架`、`20-实验与规划` 以及现有参考文件，整理拟投实时系统、嵌入式系统或机器学习系统会议论文时可使用的参考文献。
|
||||
|
||||
书目格式参照 `GB/T 7714—2015`，英文会议论文保留原始会议名称。在线文档统一记录访问日期 `2026-09-21`。最终投稿时应使用目标会议的 BibTeX/LaTeX 样式重新生成，并再次核对作者、页码、DOI 和版本。
|
||||
|
||||
当前项目已经从旧规划中的“四层谱系”调整为 `T5~T1` 五类部署形态与 11 个代表档位。本文献表按当前项目口径组织，但仍可支撑旧版 `最终稿文章规划.md` 的十章结构。
|
||||
|
||||
## 2. 章节—参考文献映射
|
||||
|
||||
| 论文内容 | 建议优先引用 | 支撑作用 |
|
||||
|---|---|---|
|
||||
| 第1章 引言 | `[1]~[10]`、`[42]`、`[50]~[53]` | 实时保障基础、任务关键 AI 背景和安全边界 |
|
||||
| 第2章 背景与相关工作 | `[1]~[32]` | 经典调度、PREEMPT_RT、LLM 推理服务、KV Cache、加速器和量化 |
|
||||
| 第3章 部署形态与硬件谱系 | `[34]~[39]`、`[43]~[47]` | Edge/Datacenter 方法、功率边界、模型与推理运行时 |
|
||||
| 第4章 SylixOS 调度框架 | `[1]~[9]`、`[12]~[33]`、`[43]~[47]` | 任务图、内存、异构加速、量化、中断与运行时实现 |
|
||||
| 第5章 实验方法学 | `[5]`、`[6]`、`[34]~[42]`、`[48]`、`[49]` | 延迟测试、MLPerf、功率、统计、公平性和可复现性 |
|
||||
| 第6章 模型与负载 | `[11]`、`[12]`、`[27]~[33]`、`[43]~[47]` | Transformer、低比特模型、Qwen、llama.cpp、TensorRT-LLM |
|
||||
| 第7章 实验结果 | `[34]~[41]` | 指标、功率、尾延迟、温度、公平性和统计解释 |
|
||||
| 第8章 深入分析 | `[1]~[33]`、`[37]~[41]` | 根因分析、机制对照与跨层权衡 |
|
||||
| 第9章 威胁有效性 | `[7]~[10]`、`[34]~[42]`、`[48]~[53]` | 系统边界、复现性、功能安全与跨设备测量限制 |
|
||||
| 第10章 结论与展望 | `[23]`、`[24]`、`[26]`、`[33]`、`[50]~[53]` | 动态调度、精度/资源协同、任务关键 AI 和安全论证 |
|
||||
|
||||
## 3. 实时调度、RTOS 与操作系统基础
|
||||
|
||||
[1] LIU C L, LAYLAND J W. Scheduling algorithms for multiprogramming in a hard-real-time environment[J]. Journal of the ACM, 1973, 20(1): 46-61. DOI: [10.1145/321738.321743](https://doi.org/10.1145/321738.321743).
|
||||
|
||||
[2] SHA L, RAJKUMAR R, LEHOCZKY J P. Priority inheritance protocols: An approach to real-time synchronization[J]. IEEE Transactions on Computers, 1990, 39(9): 1175-1185. DOI: [10.1109/12.57058](https://doi.org/10.1109/12.57058).
|
||||
|
||||
[3] AUDSLEY N, BURNS A, RICHARDSON M, et al. Applying new scheduling theory to static priority pre-emptive scheduling[J]. Software Engineering Journal, 1993, 8(5): 284-292. DOI: [10.1049/sej.1993.0034](https://doi.org/10.1049/sej.1993.0034).
|
||||
|
||||
[4] TINDELL K, BURNS A, WELLINGS A J. An extendible approach for analyzing fixed priority hard real-time tasks[J]. Real-Time Systems, 1994, 6(2): 133-151. DOI: [10.1007/BF01088593](https://doi.org/10.1007/BF01088593).
|
||||
|
||||
[5] LINUX KERNEL COMMUNITY. Theory of operation: Real-time preemption[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/theory.html](https://docs.kernel.org/core-api/real-time/theory.html).
|
||||
|
||||
[6] LINUX FOUNDATION REAL-TIME LINUX. Cyclictest: Test design, interpretation and limitations[EB/OL]. [2026-09-21]. [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start).
|
||||
|
||||
[7] 翼辉信息. SylixOS 概述[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html](https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html).
|
||||
|
||||
[8] 翼辉信息. SylixOS 发展历程[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html](https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html).
|
||||
|
||||
[9] QNX. Priorities and scheduling: QNX Neutrino RTOS[EB/OL]. [2026-09-21]. [https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html](https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html).
|
||||
|
||||
[10] THE OPEN GROUP. POSIX.1-2024: Realtime functions and general information[S/OL]. 2024[2026-09-21]. [https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html).
|
||||
|
||||
## 4. Transformer、LLM 推理调度与服务系统
|
||||
|
||||
[11] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]//Advances in Neural Information Processing Systems 30. 2017: 5998-6008. [https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need](https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need).
|
||||
|
||||
[12] DAO T, FU D Y, ERMON S, et al. FlashAttention: Fast and memory-efficient exact attention with IO-awareness[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html](https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html).
|
||||
|
||||
[13] DAO T. FlashAttention-2: Faster attention with better parallelism and work partitioning[C]//International Conference on Learning Representations. 2024. [https://openreview.net/forum?id=mZn2Xyh9Ec](https://openreview.net/forum?id=mZn2Xyh9Ec).
|
||||
|
||||
[14] YU G I, JEONG J S, KIM G W, et al. Orca: A distributed serving system for Transformer-based generative models[C]//16th USENIX Symposium on Operating Systems Design and Implementation. 2022. [https://www.usenix.org/conference/osdi22/presentation/yu](https://www.usenix.org/conference/osdi22/presentation/yu).
|
||||
|
||||
[15] KWON W, LI Z, ZHUANG S, et al. Efficient memory management for large language model serving with PagedAttention[C]//Proceedings of the 29th ACM Symposium on Operating Systems Principles. 2023. [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180).
|
||||
|
||||
[16] AGRAWAL A, KEDIA N, PANWAR A, et al. Taming throughput-latency tradeoff in LLM inference with Sarathi-Serve[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 117-134. [https://www.usenix.org/conference/osdi24/presentation/agrawal](https://www.usenix.org/conference/osdi24/presentation/agrawal).
|
||||
|
||||
[17] ZHONG Y, LIU S, CHEN J, et al. DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 193-210. [https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin).
|
||||
|
||||
[18] SUN B, HUANG Z, ZHAO H, et al. Llumnix: Dynamic scheduling for large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 173-191. [https://www.usenix.org/conference/osdi24/presentation/sun-biao](https://www.usenix.org/conference/osdi24/presentation/sun-biao).
|
||||
|
||||
[19] GUJARATI A, KARANASOS K, CURINO C, et al. Serving DNNs like Clockwork: Performance predictability from the bottom up[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020. [https://www.usenix.org/conference/osdi20/presentation/gujarati](https://www.usenix.org/conference/osdi20/presentation/gujarati).
|
||||
|
||||
[20] SHENG Y, ZHENG L, YUAN B, et al. FlexGen: High-throughput generative inference of large language models with a single GPU[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202. [https://proceedings.mlr.press/v202/sheng23a.html](https://proceedings.mlr.press/v202/sheng23a.html).
|
||||
|
||||
[21] ZHANG Z, SHENG Y, ZHOU T, et al. H2O: Heavy-Hitter Oracle for efficient generative inference of large language models[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html).
|
||||
|
||||
[22] LEE W, LEE J, SEO J, et al. InfiniGen: Efficient generative inference of large language models with dynamic KV cache management[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 155-172. [https://www.usenix.org/conference/osdi24/presentation/lee](https://www.usenix.org/conference/osdi24/presentation/lee).
|
||||
|
||||
[23] PRABHU R, NAYAK A, MOHAN J, et al. vAttention: Dynamic memory management for serving LLMs without PagedAttention[EB/OL]. arXiv:2405.04437, 2024[2026-09-21]. [https://arxiv.org/abs/2405.04437](https://arxiv.org/abs/2405.04437).
|
||||
|
||||
[24] BAI Z, ZHANG Z, ZHU Y, et al. PipeSwitch: Fast pipelined context switching for deep learning applications[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020: 499-514. [https://www.usenix.org/conference/osdi20/presentation/bai](https://www.usenix.org/conference/osdi20/presentation/bai).
|
||||
|
||||
[25] CHOI Y, RHU M. PREMA: A predictive multi-task scheduling algorithm for preemptible neural processing units[C]//2020 IEEE International Symposium on High Performance Computer Architecture. 2020. DOI: [10.1109/HPCA47549.2020.00030](https://doi.org/10.1109/HPCA47549.2020.00030).
|
||||
|
||||
[26] NVIDIA. CUDA Programming Guide: Asynchronous execution, streams and events[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html).
|
||||
|
||||
## 5. 量化、低比特推理与质量约束
|
||||
|
||||
[27] DETTMERS T, LEWIS M, BELKADA Y, et al. LLM.int8(): 8-bit matrix multiplication for Transformers at scale[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html).
|
||||
|
||||
[28] FRANTAR E, ASHKBOOS S, HOEFLER T, et al. GPTQ: Accurate post-training quantization for generative pre-trained Transformers[C]//International Conference on Learning Representations. 2023. [https://openreview.net/forum?id=tcbBPnfwxS](https://openreview.net/forum?id=tcbBPnfwxS).
|
||||
|
||||
[29] XIAO G, LIN J, SEZNEC M, et al. SmoothQuant: Accurate and efficient post-training quantization for large language models[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202: 38087-38099. [https://proceedings.mlr.press/v202/xiao23c.html](https://proceedings.mlr.press/v202/xiao23c.html).
|
||||
|
||||
[30] LIN J, TANG J, TANG H, et al. AWQ: Activation-aware weight quantization for on-device LLM compression and acceleration[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html).
|
||||
|
||||
[31] DETTMERS T, PAGNONI A, HOLTZMAN A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html).
|
||||
|
||||
[32] LIN Y, TANG H, YANG S, et al. QServe: W4A8KV4 quantization and system co-design for efficient LLM serving[C]//Proceedings of Machine Learning and Systems. 2025, 7. [https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html).
|
||||
|
||||
[33] ZHAO Y, LIN C Y, ZHU K, et al. Atom: Low-bit quantization for efficient and accurate LLM serving[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html).
|
||||
|
||||
## 6. 评估、功耗、热管理与可复现性
|
||||
|
||||
[34] REDDI V J, CHENG C, KANTER D, et al. MLPerf Inference Benchmark[EB/OL]. arXiv:1911.02549, 2019[2026-09-21]. [https://arxiv.org/abs/1911.02549](https://arxiv.org/abs/1911.02549).
|
||||
|
||||
[35] MLCOMMONS. MLPerf Inference Benchmark Suite[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/index_gh/](https://docs.mlcommons.org/inference/index_gh/).
|
||||
|
||||
[36] MLCOMMONS. MLPerf Inference power measurement[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/power/](https://docs.mlcommons.org/inference/power/).
|
||||
|
||||
[37] DEAN J, BARROSO L A. The tail at scale[J]. Communications of the ACM, 2013, 56(2): 74-80. [https://research.google/pubs/the-tail-at-scale/](https://research.google/pubs/the-tail-at-scale/).
|
||||
|
||||
[38] HUANG W, GHOSH S, VELUSAMY S, et al. HotSpot: A compact thermal modeling methodology for early-stage VLSI design[J]. IEEE Transactions on Very Large Scale Integration Systems, 2006, 14(5): 501-513. DOI: [10.1109/TVLSI.2006.876103](https://doi.org/10.1109/TVLSI.2006.876103).
|
||||
|
||||
[39] STANDARD PERFORMANCE EVALUATION CORPORATION. SPECpower_ssj2008[EB/OL]. [2026-09-21]. [https://www.spec.org/osg/power_ssj2008/](https://www.spec.org/osg/power_ssj2008/).
|
||||
|
||||
[40] JAIN R, CHIU D M, HAWE W R. A quantitative measure of fairness and discrimination for resource allocation in shared computer systems[R]. DEC Research Report TR-301, 1984. [https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf).
|
||||
|
||||
[41] EFRON B, TIBSHIRANI R J. An introduction to the bootstrap[M]. New York: Chapman & Hall/CRC, 1993.
|
||||
|
||||
[42] ASSOCIATION FOR COMPUTING MACHINERY. Artifact review and badging policy[EB/OL]. [2026-09-21]. [https://www.acm.org/publications/policies/artifact-review-and-badging-current](https://www.acm.org/publications/policies/artifact-review-and-badging-current).
|
||||
|
||||
## 7. 模型、推理框架与工程实现资料
|
||||
|
||||
[43] YANG A, YANG B, ZHANG B, et al. Qwen2.5 Technical Report[EB/OL]. arXiv:2412.15115, 2024[2026-09-21]. [https://arxiv.org/abs/2412.15115](https://arxiv.org/abs/2412.15115).
|
||||
|
||||
[44] GGERGANOV, GGML-ORG. llama.cpp: LLM inference in C/C++[CP/OL]. [2026-09-21]. [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp).
|
||||
|
||||
[45] NVIDIA. TensorRT-LLM architecture overview[EB/OL]. [2026-09-21]. [https://nvidia.github.io/TensorRT-LLM/architecture/overview.html](https://nvidia.github.io/TensorRT-LLM/architecture/overview.html).
|
||||
|
||||
[46] NVIDIA. NVIDIA Data Center GPU Manager: Field identifiers[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html).
|
||||
|
||||
[47] LINUX KERNEL COMMUNITY. How realtime kernels differ[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/differences.html](https://docs.kernel.org/core-api/real-time/differences.html).
|
||||
|
||||
## 8. 任务关键 AI、功能安全与时间同步标准
|
||||
|
||||
[48] ULLRICH L, BUCHHOLZ M, DIETMAYER K, et al. AI safety assurance for automated vehicles: A survey on research, standardization, regulation[J]. IEEE Transactions on Intelligent Vehicles, 2024. DOI: [10.1109/TIV.2024.3496797](https://doi.org/10.1109/TIV.2024.3496797).
|
||||
|
||||
[49] IEC. IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems—Parts 1 to 7[S]. 2nd ed. Geneva: International Electrotechnical Commission, 2010. [https://webstore.iec.ch/en/publication/22273](https://webstore.iec.ch/en/publication/22273).
|
||||
|
||||
[50] ISO. ISO 26262:2018, Road vehicles—Functional safety[S]. 2nd ed. Geneva: International Organization for Standardization, 2018. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html).
|
||||
|
||||
[51] ISO. ISO/PAS 8800:2024, Road vehicles—Safety and artificial intelligence[S]. Geneva: International Organization for Standardization, 2024. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html).
|
||||
|
||||
[52] IEEE. IEEE Std 1588-2019, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems[S]. New York: IEEE, 2019. [https://standards.ieee.org/ieee/1588/6825/](https://standards.ieee.org/ieee/1588/6825/).
|
||||
|
||||
[53] RTCA. DO-178C: Software considerations in airborne systems and equipment certification[S]. Washington, D.C.: RTCA, 2011. [https://www.rtca.org/do-178/](https://www.rtca.org/do-178/).
|
||||
|
||||
## 9. 使用与取舍建议
|
||||
|
||||
### 9.1 核心正文优先保留
|
||||
|
||||
受篇幅限制时，建议首先保留 `[1]~[6]`、`[11]`、`[14]~[22]`、`[25]~[30]`、`[34]~[42]`、`[49]~[52]`。它们分别支撑实时理论、LLM 服务、异构调度、量化、实验方法与任务关键边界。
|
||||
|
||||
### 9.2 只作工程实现说明
|
||||
|
||||
`[7]~[10]`、`[26]`、`[35]`、`[36]`、`[39]`、`[44]~[47]` 属于官方标准、文档或开源实现，适合说明平台能力、API 语义和实验工具，不宜单独用来证明算法创新或相对性能优势。
|
||||
|
||||
### 9.3 需要谨慎使用
|
||||
|
||||
- `[23]`、`[34]`、`[43]` 为预印本或技术报告，投稿前应检查是否已有正式发表版本。
|
||||
- 功能安全标准只能支撑需求与证据框架；本项目原型未完成对应认证时，不得据此宣称满足 SIL、ASIL 或适航要求。
|
||||
- SylixOS、QNX、CUDA、TensorRT-LLM 等官方资料描述的是产品或接口能力，实际可用性仍需由本项目准入实验验证。
|
||||
- 任何外部论文报告的倍数提升都不能移植为本项目预期结果，只能用于选择对照方案和解释机制。
|
||||
|
||||
## 10. 待补充文献
|
||||
|
||||
正式投稿前还应根据实际实验结果补充：
|
||||
|
||||
1. 最终采用的 RKLLM/RKNN SDK、芯片手册和模型转换工具的固定版本文档；
|
||||
2. 实际使用的 SylixOS BSP、驱动和追踪工具文档；
|
||||
3. 若完成 T1 多节点实验，补充 NCCL、RDMA 和分布式推理的正式文献；
|
||||
4. 若完成 MoE 实验，补充专家路由、负载均衡和专家并行文献；
|
||||
5. 若论文转投 ISLPED，补充 DVFS、race-to-idle 与嵌入式热管理相关工作；
|
||||
6. 若论文面向车载或航空场景，按最终系统边界补充 ISO 26262、ISO/PAS 8800、DO-178C 及行业适用指南。
|
||||
Reference in New Issue
Block a user