reorganize repository into meeting and project framework structure
Align the repository with the new collaboration workflow by separating meeting records from project framework materials, so discussion outputs and formal research assets can evolve independently.
This commit is contained in:
@@ -0,0 +1,75 @@
|
||||
# 01-当前研究问题：背景、问题与挑战
|
||||
|
||||
## 1. 背景
|
||||
|
||||
当前智能系统正在持续进入控制、装备、交通、工业现场与边缘决策等任务关键场景。随着人工智能推理能力从离线分析走向在线决策，系统对人工智能运行的要求已经扩展为功能有效性、时间约束、运行稳定性与可验证性的统一达标。
|
||||
|
||||
外部研究与产业表达已经形成较清晰的共识：
|
||||
|
||||
- AI 用于 safety-critical systems 的安全保障仍在持续推进，系统层面的可控、可验证与可接受性仍是核心议题；
|
||||
- QNX、Wind River 等平台方已将 deterministic、predictable、secure 的软件基础与 AI 能力并列讨论；
|
||||
- Linux Foundation 对 PREEMPT_RT 的持续推进，表明低延时、低抖动和可预测执行已经成为重要基础能力。
|
||||
|
||||
在这样的背景下，操作系统已经成为决定 AI 推理能否进入任务关键系统的重要基础平台。尤其当 AI 推理与周期控制、执行闭环、联锁逻辑、通信管理等负载共同运行时，系统时序边界、资源争抢边界与恢复边界都会被重新放大。
|
||||
|
||||
## 2. 问题
|
||||
|
||||
本项目聚焦的当前研究问题可以表述为：
|
||||
|
||||
> **在五类部署形态下，当人工智能目标负载进入任务关键系统后，以大型跨平台实时操作系统为基础平台的系统，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性？**
|
||||
|
||||
这个问题包含四个明确支点：
|
||||
|
||||
1. 研究对象是**大型跨平台实时操作系统**这一类平台；
|
||||
2. `SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等构成外部参照样本；
|
||||
3. AI 推理在任务关键系统中被界定为**人工智能目标负载**，与关键保障负载、伴生竞争负载共同构成系统运行面；
|
||||
4. 对照对象明确拆分为**普通 Linux** 与 **PREEMPT_RT Linux**，用来建立不同系统基础能力之间的可比关系。
|
||||
|
||||
项目围绕以下三个判断维度展开：
|
||||
|
||||
- AI 目标负载与关键保障负载能否在统一系统中稳定共存；
|
||||
- 操作系统能否通过调度、隔离、内存管理、中断管理与恢复机制维持系统边界；
|
||||
- 系统是否能够同时实现 AI 功能有效性与实时性达标。
|
||||
|
||||
因此，这个研究问题本质上是一个面向任务关键系统的系统研究问题，也是一个具有产业验证价值的平台比较问题。
|
||||
|
||||
## 3. 挑战
|
||||
|
||||
围绕上述问题，当前研究至少面临以下几类核心挑战。
|
||||
|
||||
### 3.1 五类部署形态下的统一验证挑战
|
||||
|
||||
`T5~T1` 五类部署形态与 `11` 个代表档位共同构成验证矩阵、证据组织框架与跨场景比较环境。这里的核心挑战，是在不同资源约束、拓扑结构和负载强度下，用统一方法解释 RTOS 的优势边界与失效边界。
|
||||
|
||||
### 3.2 对照体系的精细化挑战
|
||||
|
||||
本项目采用三级对照体系：
|
||||
|
||||
- `O0` 普通 Linux；
|
||||
- `O1` PREEMPT_RT Linux；
|
||||
- 大型跨平台 RTOS。
|
||||
|
||||
这一对照设计将普通 Linux 与 PREEMPT_RT Linux 分别建模，用于区分一般低延时收益与 RTOS 在确定性、隔离性和可分析性上的收益来源。
|
||||
|
||||
### 3.3 双目标同时达标的评价挑战
|
||||
|
||||
当 AI 被界定为目标负载后，评价体系同时覆盖关键保障负载保护效果，以及 AI 目标负载的有效性、时效性和长期稳定性。因此，评价指标需要同时覆盖：
|
||||
|
||||
- 关键保障负载：`deadline miss ratio`、`P99/P99.9 jitter`、响应时间边界；
|
||||
- AI 目标负载：`TTFT`、`TPOT`、端到端响应时间、成功率、功能质量；
|
||||
- 系统协同层：有效吞吐、`E/token`、热漂移、资源争抢边界、恢复能力。
|
||||
|
||||
### 3.4 多目标负载协调的机制挑战
|
||||
|
||||
在任务关键系统中，AI 目标负载、关键保障负载与伴生竞争负载共同构成统一运行面。它们在 CPU、内存、总线、中断、DMA、缓存与加速器访问上会形成持续竞争。研究的关键难点在于，RTOS 是否能够把这种竞争收敛为可分析、可控制、可恢复的系统行为边界。
|
||||
|
||||
## 外部参考
|
||||
|
||||
1. Linux Foundation, Real-Time Linux Project
|
||||
<https://realtime-linux.dev-lfprojects5.linuxfoundation.org/>
|
||||
2. QNX, Software Foundation for Physical AI
|
||||
<https://qnx.software/en/software/technologies/physical-ai>
|
||||
3. Wind River 官网与 Edge AI / mission-critical 相关公开表述
|
||||
<https://www.windriver.com/>
|
||||
4. Ullrich et al., *AI Safety Assurance for Automated Vehicles: A Survey on Research, Standardization, Regulation*
|
||||
<https://arxiv.org/abs/2504.18328v1>
|
||||
@@ -0,0 +1,155 @@
|
||||
# 02-研究定位与项目边界
|
||||
|
||||
## 一句话定义
|
||||
|
||||
本项目的正式题目是：
|
||||
|
||||
> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**
|
||||
|
||||
本项目围绕下面这个核心问题展开：
|
||||
|
||||
> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性。SylixOS 是本项目的主实验样例，QNX、VxWorks、INTEGRITY、LynxOS-178 等可作为外部参照样本。**
|
||||
|
||||
## 这个项目在做什么
|
||||
|
||||
### 1. 研究对象与平台角色
|
||||
|
||||
本项目的研究对象是**大型跨平台实时操作系统这一类平台**，重点关注它们在任务关键系统中的：
|
||||
|
||||
- 其实时调度、资源隔离、内存管理、中断管理与恢复机制；
|
||||
- 这些机制在不同部署形态下承载人工智能目标负载时，是否仍能维持系统边界。
|
||||
|
||||
在这组平台中：
|
||||
|
||||
- `SylixOS` 是本项目的主实验样例；
|
||||
- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等用于建立外部参照坐标；
|
||||
- `Linux` 与 `PREEMPT_RT Linux` 是核心对照对象。
|
||||
|
||||
硬件平台在本项目中承担的是**验证载体**角色，用来暴露不同资源约束、拓扑结构和调度边界。
|
||||
|
||||
### 2. 系统场景与负载结构
|
||||
|
||||
本项目面向的是**任务关键系统**。在这个系统语境里，人工智能推理属于系统功能的一部分，因此被定义为：
|
||||
|
||||
- **人工智能目标负载**
|
||||
|
||||
与之共同构成系统运行面的还有两类负载：
|
||||
|
||||
- **关键保障负载**：周期控制、执行闭环、联锁、状态采集等；
|
||||
- **伴生竞争负载**：日志、更新、后台通信、模型加载、存储和网络 I/O 等。
|
||||
|
||||
> **RTOS 如何协调人工智能目标负载与关键保障负载，使系统同时满足功能有效性与实时性边界。**
|
||||
|
||||
### 3. 在五类部署形态下建立统一验证矩阵
|
||||
|
||||
`T5~T1` 五类部署形态和 `11` 个代表档位在本项目中构成验证矩阵与证据组织框架：
|
||||
|
||||
- 验证矩阵；
|
||||
- 证据组织框架；
|
||||
- 不同资源条件下的边界测试环境。
|
||||
|
||||
这套验证矩阵覆盖：
|
||||
|
||||
- `T5` 控制端
|
||||
- `T4` 设备端 SoC
|
||||
- `T3` 边缘节点
|
||||
- `T2` 桌面 / 工作站单机
|
||||
- `T1` 服务器 / 集群
|
||||
|
||||
其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
|
||||
|
||||
这套验证矩阵支撑以下四类判断：
|
||||
|
||||
- RTOS 优势在哪些部署形态下最明显；
|
||||
- 这些优势来自哪些系统机制；
|
||||
- 为维持实时保障需要付出多少吞吐和能耗代价；
|
||||
- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
|
||||
|
||||
这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
|
||||
|
||||
### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
|
||||
|
||||
项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
|
||||
|
||||
证据至少包括三层：
|
||||
|
||||
- **人工智能目标负载层**：
|
||||
`TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
|
||||
- **关键保障负载层**：
|
||||
`deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
|
||||
- **系统协同层**：
|
||||
有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
|
||||
|
||||
## 项目边界
|
||||
|
||||
### 1. 应用背景与研究对象
|
||||
|
||||
项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
|
||||
|
||||
- 大型跨平台实时操作系统；
|
||||
- 任务关键系统；
|
||||
- 人工智能目标负载。
|
||||
|
||||
其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
|
||||
|
||||
### 2. 评价重点
|
||||
|
||||
项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
|
||||
|
||||
- AI 目标负载是否按时完成；
|
||||
- 关键保障负载是否满足截止期；
|
||||
- 系统是否在长时间运行中保持稳定；
|
||||
- 满足这些约束后，吞吐与能耗代价是否可接受。
|
||||
|
||||
### 3. 算法与系统的关系
|
||||
|
||||
量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
|
||||
|
||||
- 它们如何改变时延分布；
|
||||
- 如何影响内存占用和带宽争抢；
|
||||
- 如何改变调度器和资源管理策略。
|
||||
|
||||
因此，项目重点落在系统机制、调度策略和资源治理能力上。
|
||||
|
||||
对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
|
||||
|
||||
因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
|
||||
|
||||
### 4. 成果形态
|
||||
|
||||
项目成果需要形成完整的方法与证据体系，包括：
|
||||
|
||||
- 可解释的方法；
|
||||
- 可复现的证据；
|
||||
- 明确的适用边界；
|
||||
- 跨部署形态可比较的规律；
|
||||
- 能被学术界和产业界共同理解的结论。
|
||||
|
||||
在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
|
||||
|
||||
## 这个项目最后要交付什么
|
||||
|
||||
项目最终交付物至少应包括：
|
||||
|
||||
1. 一套面向任务关键系统的 SylixOS 实时保障机制；
|
||||
2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
|
||||
3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
|
||||
4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
|
||||
5. 一套可用于产业沟通和产品表达的技术叙事。
|
||||
|
||||
## 判断项目是否成功，要看什么
|
||||
|
||||
要看：
|
||||
|
||||
- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
|
||||
- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
|
||||
- 吞吐损失是否在可接受范围；
|
||||
- 能耗和热稳定性是否同步改善或至少可解释；
|
||||
- 结论是否能跨部署形态成立；
|
||||
- 优势边界和失败边界是否都被讲清楚。
|
||||
|
||||
## 最后一句话
|
||||
|
||||
这个项目的本质是：
|
||||
|
||||
> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**
|
||||
@@ -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,57 @@
|
||||
# 研究框架索引
|
||||
|
||||
本目录放置项目的核心研究框架文档，分为两部分：
|
||||
|
||||
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`
|
||||
|
||||
### 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,178 @@
|
||||
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文用于解释本目录中的研究逻辑结构，并说明：
|
||||
|
||||
- [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) 如何承载完整的 `T5~T1` 五类部署形态与 `11` 个代表档位；
|
||||
- [03-实验设计.md](./03-实验设计.md) 如何把这些硬件条件组织成可复现的对照实验；
|
||||
- [04-论文写作规划.md](./04-论文写作规划.md) 如何把证据组织成一篇系统化论文。
|
||||
|
||||
三份文档承担的职责如下：
|
||||
|
||||
| 文档 | 回答的问题 | 在研究中的作用 |
|
||||
|---|---|---|
|
||||
| [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) | 在哪些部署形态与硬件条件下验证？ | 定义 `T5~T1` 五类部署形态、五种算力基础与十一档实验矩阵 |
|
||||
| [03-实验设计.md](./03-实验设计.md) | 如何产生可信、可复现、可比较的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
|
||||
| [04-论文写作规划.md](./04-论文写作规划.md) | 如何把这些证据组织成论文贡献？ | 把研究问题、方法、结果和边界映射成论文结构 |
|
||||
|
||||
整个研究的主线是：
|
||||
|
||||
> **研究对象定义清楚 → 验证矩阵完整展开 → 公平对照与双目标实验 → 数据可复现 → 跨档位规律与边界 → 论文贡献。**
|
||||
|
||||
## 2. 研究对象
|
||||
|
||||
这个项目的研究对象是：
|
||||
|
||||
> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制。**
|
||||
|
||||
本目录后续所有实验和文档都围绕下面这条主线展开：
|
||||
|
||||
- **研究对象**：大型跨平台实时操作系统这一类平台；
|
||||
- **主实验样例**：SylixOS；
|
||||
- **外部参照样本**：QNX、VxWorks、INTEGRITY、LynxOS-178；
|
||||
- **系统场景**：任务关键系统；
|
||||
- **目标负载**：人工智能目标负载；
|
||||
- **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
|
||||
- **硬件角色**：验证矩阵。
|
||||
|
||||
在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
|
||||
|
||||
## 3. T5~T1 五类部署形态与 11 个代表档位
|
||||
|
||||
硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
|
||||
|
||||
1. **验证矩阵**：在不同资源条件下检验同一系统问题是否成立；
|
||||
2. **证据组织框架**：把结果放到统一谱系中观察规律与边界；
|
||||
3. **产业可解释性**：让不同部署形态都能找到对应的现实位置。
|
||||
|
||||
对应关系如下：
|
||||
|
||||
| 部署形态 | 主要系统角色 | 主要验证重点 |
|
||||
|---|---|---|
|
||||
| `T5` 控制端 | 极紧资源预算下的任务关键控制节点 | 强实时、极小内存、低功耗边界 |
|
||||
| `T4` 设备端 SoC | 设备本体内的统一内存异构平台 | CPU/NPU/GPU 共享资源与带宽隔离 |
|
||||
| `T3` 边缘节点 | 设备附近的近源推理节点 | 多任务并发、热稳定性、边缘协同 |
|
||||
| `T2` 桌面 / 工作站单机 | 单机高密本地推理平台 | 单机多卡调度、NVLink/PCIe 拓扑、公平性 |
|
||||
| `T1` 服务器 / 集群 | 多节点大模型服务平台 | 跨节点通信、分布式调度、规模扩展 |
|
||||
|
||||
`T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
|
||||
`T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
|
||||
|
||||
其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
|
||||
|
||||
## 4. 人工智能目标负载与系统负载结构
|
||||
|
||||
在任务关键系统里，负载应至少分成三类：
|
||||
|
||||
| 负载类型 | 定义 | 例子 |
|
||||
|---|---|---|
|
||||
| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
|
||||
| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、联锁、状态采集、执行输出 |
|
||||
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、后台通信、模型加载、I/O |
|
||||
|
||||
本项目重点评估的是：
|
||||
|
||||
> **RTOS 协调人工智能目标负载与关键保障负载时，对系统边界的维持能力与成立条件。**
|
||||
|
||||
这一步会直接影响实验设计、论文结构和评价指标。
|
||||
|
||||
## 5. 准入与对照的实验顺序
|
||||
|
||||
本项目采用分阶段准入机制：
|
||||
|
||||
| 门槛 | 核心检查内容 |
|
||||
|---|---|
|
||||
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑 |
|
||||
| `G1` 测量准入 | 单调时钟、日志、外部测量链路、功率计 |
|
||||
| `G2` 加速器准入 | CUDA / RKLLM / RKNN / 驱动 / 最小算子 |
|
||||
| `G3` 模型准入 | 模型转换、加载、正确推理与峰值内存 |
|
||||
| `G4` 混合场景准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
|
||||
|
||||
只有通过 `G4` 的平台与配置，才能进入正式对照。
|
||||
|
||||
## 6. O0~O4 对照组结构
|
||||
|
||||
主对照统一采用：
|
||||
|
||||
| 编号 | 配置 | 作用 |
|
||||
|---|---|---|
|
||||
| `O0` | 普通 Linux | 通用系统基线 |
|
||||
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
|
||||
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
|
||||
| `O3` | SylixOS 优化配置 | 主实验组 |
|
||||
|
||||
必要时增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，并继续保持“普通 Linux”和“实时增强 Linux”的对照边界。
|
||||
|
||||
## 7. 实验逻辑如何展开
|
||||
|
||||
实验逻辑遵循从简单到复杂、从单目标到双目标的顺序：
|
||||
|
||||
1. 先确认平台、模型与测量链路可用；
|
||||
2. 再测仅人工智能目标负载的基线表现；
|
||||
3. 再测仅关键保障负载的下界行为；
|
||||
4. 再测两者并存的核心场景；
|
||||
5. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
|
||||
|
||||
这条顺序用于区分平台就绪性问题与系统机制边界问题。
|
||||
|
||||
对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
|
||||
|
||||
## 8. 哪些指标构成核心证据
|
||||
|
||||
后续证据链必须覆盖三层：
|
||||
|
||||
### 8.1 人工智能目标负载层
|
||||
|
||||
- `TTFT`
|
||||
- `TPOT`
|
||||
- 端到端响应时间
|
||||
- 成功率、任务质量、输出可用性
|
||||
- 长时间运行稳定性
|
||||
|
||||
### 8.2 关键保障负载层
|
||||
|
||||
- `deadline miss ratio`
|
||||
- `P99/P99.9 jitter`
|
||||
- 观测最大响应时间
|
||||
- 外部接口响应时间
|
||||
|
||||
### 8.3 系统协同层
|
||||
|
||||
- 有效吞吐
|
||||
- `E/token`
|
||||
- 温度、降频和热漂移
|
||||
- 多任务公平性
|
||||
- 恢复能力与 24 h 长稳表现
|
||||
|
||||
项目最终形成的核心判断是：
|
||||
|
||||
> **在双目标约束下，RTOS 对系统稳定性、可预测性与可保障性的提升边界。**
|
||||
|
||||
## 9. 数据如何转化为论文贡献
|
||||
|
||||
论文贡献排序如下：
|
||||
|
||||
| 贡献 | 所需证据 | 对应论文位置 |
|
||||
|---|---|---|
|
||||
| `C1` RTOS 对人工智能目标负载与关键保障负载的实时保障优势 | 双目标达标、尾部行为、有效吞吐与恢复结果 | 第1、4、5、7、8章 |
|
||||
| `C2` T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵 | 跨档位容量、功耗、拓扑与边界分析 | 第3、7、8章 |
|
||||
| `C3` 可复现的方法论与基准对齐 | 准入、元数据、第三方基准复现、消融与统计口径 | 第5、7、9章 |
|
||||
|
||||
在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
|
||||
|
||||
面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
|
||||
|
||||
## 10. 最终闭环
|
||||
|
||||
本研究形成的核心结论关系是：
|
||||
|
||||
> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
|
||||
|
||||
在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
|
||||
|
||||
- 研究对象清楚；
|
||||
- 验证矩阵完整；
|
||||
- 对照关系公平；
|
||||
- 评价框架统一；
|
||||
- 论文叙事和产业叙事都能站住。
|
||||
@@ -0,0 +1,784 @@
|
||||
# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
|
||||
|
||||
> 版本: v2.1 起草日期: 2026-09-21
|
||||
> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
|
||||
> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
|
||||
> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
|
||||
|
||||
---
|
||||
|
||||
## 0. 场景、算力基础与设备档位总览
|
||||
|
||||
### 0.1 研究框架与设备谱系的对应关系
|
||||
|
||||
研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
|
||||
本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
|
||||
这里完整呈现硬件与指标颗粒度，并明确：
|
||||
|
||||
> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
|
||||
|
||||
| 研究维度 | 定义 | 在本文件中的落地方式 |
|
||||
|---|---|---|
|
||||
| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
|
||||
| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
|
||||
| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
|
||||
|
||||
`T5~T1` 是用于实验组织的**部署形态代码**。
|
||||
这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
|
||||
后续实验中，这些档位分别承担的是：
|
||||
|
||||
- 人工智能目标负载在不同资源条件下的时效与有效性验证；
|
||||
- 关键保障负载在不同资源条件下的边界验证；
|
||||
- RTOS 在双目标约束下的机制有效性验证。
|
||||
|
||||
### 0.2 分级维度与分档规则
|
||||
|
||||
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
|
||||
|
||||
**分档规则**: 相邻两档的边界值归入**上界一侧**
|
||||
|
||||
| 部署形态 | 代码 | 代表档位 | 容量范围 | 说明 |
|
||||
| -------- | --- | --------------- | ---------------- | ---------------- |
|
||||
| **T5 控制端场景** | T5 | **T5-L / T5-M / T5-H** | **1~8 G** | 运行在控制器或轻量控制盒本体 |
|
||||
| **T4 设备端 SoC 场景** | T4 | **T4-L / T4-M** | **8~32 G** | 运行在设备本体 SoC 上 |
|
||||
| **T3 边缘节点场景** | T3 | **T3-L** | **32~64 G / 48 G 独显** | 运行在设备附近的边缘节点 |
|
||||
| **T2 桌面/工作站单机场景** | T2 | **T2-L / T2-M / T2-H** | **64~512 G** | 研发或本地服务用单机多卡 |
|
||||
| **T1 服务器/集群场景** | T1 | **T1-L / T1-H** | **512 G~2 T** | 多节点分布式推理 |
|
||||
|
||||
> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
|
||||
|
||||
### 0.3 全谱系总表（11 个档位）
|
||||
|
||||
> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。
|
||||
|
||||
| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 |
|
||||
| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- |
|
||||
| **T5-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | |
|
||||
| **T5-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | |
|
||||
| **T5-H** | 4~8 G | 6~32 TOPS (INT8) | 7~21 W | ARM A76+A55 + M0 + NPU；DC 12V 被动 | **RK3588 8GB** / Jetson Orin Nano 8GB | 现有（16G 板降配） |
|
||||
| **T4-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 |
|
||||
| **T4-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | |
|
||||
| **T3-L** | 32~64 G / 48 G 独显 | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | |
|
||||
| **T2-L** | 64~128 G | 500 TFLOPS (FP16) | 600~1.65 kW | x86 + 4×V100 SXM NVLink；双电源 + 360 液冷 | **4×V100 32GB SXM 塔式** | 现有 |
|
||||
| **T2-M** | 128~256 G | 1000 TFLOPS (FP16) | 3.0~3.3 kW | x86 + 8×V100 SXM NVLink；双电源 + 液冷 | 8×V100 32GB SXM 整机 | 需扩展 |
|
||||
| **T2-H** | 256~512 G | ~4000 TFLOPS (FP16) | 4.5~6.5 kW | x86 + 4×H100 SXM5 NVLink；高压供电 + 强制液冷 | 4×H100 80GB SXM5 工作站 | |
|
||||
| **T1-L** | 512 G~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × x86+4×V100，100GbE RoCE/IB；机房风冷/液冷 | 4×（T2-L 节点）+ IB 交换机 | 需扩展 |
|
||||
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | 20~25 kW | 4 节点 × x86+4×H100，NDR 400G IB；机房级液冷 | 4×（T2-H 节点）+ NDR 交换机 | |
|
||||
|
||||
### 0.4 设计原则
|
||||
|
||||
1. **部署形态先行、设备落地**: 先用“控制端 / 设备端 SoC / 边缘节点 / 桌面工作站 / 服务器集群”定义研究问题，再用 `T5~T1` 设备档位组织具体实验。
|
||||
2. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
|
||||
3. **CUDA 栈贯通高算力侧**: T1/T2/T3 的候选平台可共享 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位迁移，主要变化是规模与拓扑。
|
||||
4. **非 CUDA 控制端与设备端路线**: T5 全档位与 T4-L 走 RKNN/RKLLM NPU 栈，代表最强资源约束与最接近设备本体的运行位置。
|
||||
5. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T4-L 16GB / T5-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
|
||||
6. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2/T3-B 路线）与 ARM64（T5/T4/T3-A 路线），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
|
||||
|
||||
---
|
||||
|
||||
## T1. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
|
||||
|
||||
### T1.1 定位
|
||||
|
||||
大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。
|
||||
|
||||
### T1.2 档位对比
|
||||
|
||||
| 维度 | T1-L 多节点-低 | T1-H 多节点-高 |
|
||||
| ----------- | --------------------- | --------------------------- |
|
||||
| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
|
||||
| **节点数** | 4 节点 | 4 节点 |
|
||||
| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||
| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) |
|
||||
| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s |
|
||||
| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB |
|
||||
| **整机功耗** | ~6.6 kW | 20~25 kW |
|
||||
| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
|
||||
| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
|
||||
|
||||
#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
|
||||
|
||||
| 项目 | 规格 | 数量 | 备注 |
|
||||
| --------- | ------------------------------------------------ | ------------- | --------------------------- |
|
||||
| **计算节点** | 同 T2-L 单机配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
|
||||
| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 |
|
||||
| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 |
|
||||
| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB |
|
||||
| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB |
|
||||
| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 |
|
||||
| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 |
|
||||
| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L |
|
||||
| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW |
|
||||
| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 |
|
||||
|
||||
**显存与算力**
|
||||
|
||||
| 指标 | 值 |
|
||||
| --------------- | ---------------------------------- |
|
||||
| **总显存** | **512 GB** (4 × 128GB) |
|
||||
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||
| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) |
|
||||
| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) |
|
||||
|
||||
**可运行模型**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||
| ------------------------ | ---------- | ------- | ----- | ------------------ |
|
||||
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 |
|
||||
| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray |
|
||||
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI |
|
||||
| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) |
|
||||
| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray |
|
||||
|
||||
> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
|
||||
|
||||
#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
|
||||
|
||||
| 项目 | 规格 | 数量 | 备注 |
|
||||
| ------- | ----------------------------------------- | --------- | --------------------- |
|
||||
| 计算节点 | 同 T2-H 单机配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
|
||||
| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s |
|
||||
| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 |
|
||||
| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB |
|
||||
| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 |
|
||||
| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 |
|
||||
| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 |
|
||||
| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 |
|
||||
| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW |
|
||||
|
||||
**可运行模型**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||
| ------------------------ | ---------- | -------- | ----- | -------------------- |
|
||||
| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang |
|
||||
| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM |
|
||||
| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI |
|
||||
| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM |
|
||||
|
||||
### T1.3 SylixOS 要求（T1 通用）
|
||||
|
||||
| 要求项 | 描述 | 风险 |
|
||||
| ------------------ | ------------------------------- | ------------------------------ |
|
||||
| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） |
|
||||
| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） |
|
||||
| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） |
|
||||
| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） |
|
||||
| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** |
|
||||
|
||||
### T1.4 研究角度
|
||||
|
||||
- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟
|
||||
- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟
|
||||
- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性
|
||||
- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益）
|
||||
- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限）
|
||||
|
||||
---
|
||||
|
||||
## T2. 高算力单机部署形态 — 64 G ~ 512 G
|
||||
|
||||
### T2.1 定位
|
||||
|
||||
单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。
|
||||
|
||||
### T2.2 档位对比
|
||||
|
||||
| 维度 | T2-L 单机-低 | T2-M 单机-中 | T2-H 单机-高 |
|
||||
| ----------- | ---------------------- | --------------------------- | --------------------------- |
|
||||
| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） |
|
||||
| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||
| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) |
|
||||
| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 |
|
||||
| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW |
|
||||
| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 |
|
||||
| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 |
|
||||
| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 |
|
||||
| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
|
||||
| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
|
||||
|
||||
#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
|
||||
|
||||
| # | 部件 | 型号 / 规格 | 数量 | 备注 |
|
||||
| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
|
||||
| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | |
|
||||
| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | |
|
||||
| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 |
|
||||
| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 |
|
||||
| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU |
|
||||
| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | |
|
||||
| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 |
|
||||
| 8 | 机箱 | 塔式一体定制机箱 | 1 | |
|
||||
| 9 | 主电源 | 长城全模组 1650W | 1 | |
|
||||
| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 |
|
||||
| 11 | 散热器 | SP3 高性能散热器 | 1 | |
|
||||
| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | |
|
||||
| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** |
|
||||
|
||||
**显存与算力**
|
||||
|
||||
| 指标 | 值 |
|
||||
| ---------- | --------------------------- |
|
||||
| **总显存** | **128 GB** (4 × 32GB HBM2) |
|
||||
| 单卡显存 | 32 GB HBM2 |
|
||||
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||
| 总算力 (FP16) | ~500 TFLOPS |
|
||||
| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) |
|
||||
| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) |
|
||||
| **整机功耗** | **~1650 W** (满载) |
|
||||
|
||||
**可运行模型**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||
| ------------------------ | ---------- | ------ | ----- | ------------------- |
|
||||
| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM |
|
||||
| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM |
|
||||
| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM |
|
||||
| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) |
|
||||
| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM |
|
||||
| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp |
|
||||
| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper |
|
||||
|
||||
#### T2.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
|
||||
|
||||
在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
|
||||
|
||||
| 项目 | 规格 | 变更点 |
|
||||
| --------- | ----------------------------------------------- | ------------------ |
|
||||
| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 |
|
||||
| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 |
|
||||
| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 |
|
||||
| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 |
|
||||
| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 |
|
||||
| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory |
|
||||
| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 |
|
||||
| 散热 | 360 液冷 ×2 + 机箱风道强化 | — |
|
||||
| **整机功耗** | **~3.0~3.3 kW** | +100% |
|
||||
| **总算力** | **~1000 TFLOPS (FP16)** | +100% |
|
||||
|
||||
**可运行模型（新增/提升）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||
| ------------------------ | ---------- | ------ | ----- | ------------------ |
|
||||
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 |
|
||||
| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 |
|
||||
| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — |
|
||||
| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 |
|
||||
|
||||
> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。
|
||||
|
||||
#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
|
||||
|
||||
| 项目 | 规格 |
|
||||
| ------- | ---------------------------------------- |
|
||||
| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） |
|
||||
| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) |
|
||||
| 单卡显存 | 80 GB HBM3 |
|
||||
| NVLink | 900 GB/s (GPU↔GPU) |
|
||||
| CPU | AMD EPYC 9654 (96C/192T) ×1~2 |
|
||||
| 内存 | 512 GB DDR5-4800 ECC |
|
||||
| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） |
|
||||
| 存储 | 4 TB NVMe RAID0（模型权重加载） |
|
||||
| 散热 | **强制液冷（冷板式）**，风冷不可行 |
|
||||
| 电源 | 2 × 3000W 冗余 / 220V |
|
||||
| **整机功耗** | **~4.5~6.5 kW** |
|
||||
| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS |
|
||||
|
||||
**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。
|
||||
|
||||
**可运行模型（新增/提升）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||
| ------------------------ | ---------- | ------- | ----- | ----------------- |
|
||||
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 |
|
||||
| LLaMA-3-70B | FP16 | ~140 GB | 2 | — |
|
||||
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 |
|
||||
| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 |
|
||||
|
||||
### T2.3 SylixOS 要求（T2 三档通用）
|
||||
|
||||
| 要求项 | 描述 | 风险 |
|
||||
| ----------------- | ----------------------------- | ------------------- |
|
||||
| x86 BSP | SylixOS 2.x LTS x86 | 低 |
|
||||
| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） |
|
||||
| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 |
|
||||
| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） |
|
||||
| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 |
|
||||
| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） |
|
||||
|
||||
### T2.4 对照组 OS
|
||||
|
||||
- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM
|
||||
- **辅助对照**: CentOS Stream 9 + RT 内核（可选）
|
||||
|
||||
---
|
||||
|
||||
## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
|
||||
|
||||
### T3.1 定位
|
||||
|
||||
边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。
|
||||
它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
|
||||
|
||||
### T3.2 代表档位对比
|
||||
|
||||
| 维度 | T3-L 边缘节点代表档 |
|
||||
| --------- | ---------------- |
|
||||
| **容量** | 64 GB 统一内存 / 48 GB 独立显存 |
|
||||
| **加速器** | Jetson AGX Orin 64GB / RTX 6000 Ada 48GB |
|
||||
| **算力** | 275 TOPS (INT8) / 91 TFLOPS (FP16) |
|
||||
| **功耗** | 15~60 W / ~600 W |
|
||||
| **部署位置** | 设备附近机柜、边缘控制室、产线边缘节点 |
|
||||
| **主要任务** | 多模态推理、近源协同、边缘缓存与调度 |
|
||||
|
||||
### T3.3 候选平台
|
||||
|
||||
- Jetson AGX Orin 64GB：统一内存、能效高，适合近设备部署；
|
||||
- 边缘工控机 + RTX 6000 Ada 48GB：生态完整，适合边缘机柜和算力下沉场景。
|
||||
|
||||
### T3.4 研究重点
|
||||
|
||||
- 设备端到边缘节点的协同调度；
|
||||
- 近源多任务并发下的实时隔离；
|
||||
- 边缘节点与桌面/工作站单机在功耗、散热和部署约束上的边界。
|
||||
|
||||
---
|
||||
|
||||
## T4. 设备端 SoC 场景 — 8 G ~ 32 G
|
||||
|
||||
### T4.1 定位
|
||||
|
||||
设备端 SoC 直接运行在终端设备本体上。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性，即推理任务与实时控制任务共享本机资源时的隔离能力。
|
||||
|
||||
### T4.2 档位对比
|
||||
|
||||
| 维度 | T4-L SoC-低 | T4-M SoC-中 |
|
||||
| --------- | ---------------------------- | -------------------------- |
|
||||
| **容量** | 16 GB 统一内存 | 32 GB 统一内存 |
|
||||
| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA |
|
||||
| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) |
|
||||
| **功耗** | 10~30 W | 15~60 W |
|
||||
| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 |
|
||||
| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ |
|
||||
| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T5） | **高**（T234 BSP 需验证） |
|
||||
| **状态** | （RK3588 16GB 工业盒） | 待验证 |
|
||||
|
||||
#### T4.2.1 T4-L SoC-低 — RK3588 16GB 工业盒（现有设备）
|
||||
|
||||
**这是现有 RK3588 设备的标准归属档位**，也是唯一可零成本立即开展研究的设备端 SoC 档位。
|
||||
|
||||
| 项目 | 规格 | 备注 |
|
||||
| --------- | --------------------------------------- | --------------------- |
|
||||
| SoC | Rockchip RK3588（同 T5-H） | SylixOS BSP 与 T5 共用 |
|
||||
| 内存 | **16 GB LPDDR4X**（统一内存） | -40~60 ℃ 工业宽温 |
|
||||
| NPU | 6 TOPS 原生 + **26 TOPS 算力棒扩展 = 32 TOPS** | 算力棒走 M.2 2280 |
|
||||
| 功耗 | ~21~30 W（含算力棒） | 被动散热，可选小风扇 |
|
||||
| 内存带宽 | ~51.2 GB/s (128-bit LPDDR4X) | 与 T5-H 同源，是带宽瓶颈点 |
|
||||
| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T5-H 内存翻倍，可跑更大模型 |
|
||||
|
||||
**备选方案（同档位、CUDA 路线）**: NVIDIA Jetson Orin NX 16GB — 100 TOPS (INT8, sparse)，1024 CUDA + 32 Tensor Core，16 GB LPDDR5 / 102.4 GB/s，10~25 W，**CUDA 生态与 T1/T2/T3 打通**。代价是 SylixOS T234 BSP 风险高。
|
||||
|
||||
#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | -------------------------------------------------- |
|
||||
| **SoC** | NVIDIA T234（Grace 系列衍生） |
|
||||
| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） |
|
||||
| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores |
|
||||
| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） |
|
||||
| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) |
|
||||
| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） |
|
||||
| 内存带宽 | 204.8 GB/s |
|
||||
| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） |
|
||||
| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） |
|
||||
| 存储 | 64GB eMMC + M.2 NVMe（可扩展） |
|
||||
| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 |
|
||||
| 视频接口 | HDMI 2.1 + DP 1.4a |
|
||||
| USB | 4× USB 3.2 + 2× USB 2.0 |
|
||||
| PCIe | PCIe Gen4 ×4（可扩展外设） |
|
||||
| MIPI CSI | 4 通道（可接工业相机） |
|
||||
| 尺寸 | 100mm × 87mm（核心模块） |
|
||||
| **出厂 OS** | Ubuntu 20.04 LTS (L4T) |
|
||||
| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） |
|
||||
|
||||
**选择 Jetson AGX Orin 的理由**
|
||||
|
||||
1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈
|
||||
2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台
|
||||
3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证
|
||||
4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
|
||||
5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
|
||||
|
||||
#### T3 边缘节点候选平台
|
||||
|
||||
64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
|
||||
|
||||
**可运行模型（T4 两档合并）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 |
|
||||
| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ |
|
||||
| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T4-L | RKLLM |
|
||||
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T4-L / T4-M | TensorRT-LLM / RKLLM |
|
||||
| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T4-L / T4-M | TensorRT-LLM / llama.cpp |
|
||||
| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T4-M | TensorRT-LLM |
|
||||
| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T4-M | TensorRT-LLM |
|
||||
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T4-L 以上 | llama.cpp |
|
||||
| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T4-L 以上 | faster-whisper |
|
||||
| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T4 全档 | TensorRT / RKNN |
|
||||
|
||||
### T4.3 SylixOS 要求（T4）
|
||||
|
||||
| 要求项 | 描述 | 风险 |
|
||||
| -------------------- | --------------------------------------- | ---------------------------- |
|
||||
| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
|
||||
| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险 | **极低** |
|
||||
| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
|
||||
| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
|
||||
| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
|
||||
| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
|
||||
| 独立显存管理（T3 B 路线） | x86 + 独显的显存分配与实时性 | 中 |
|
||||
|
||||
> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
|
||||
|
||||
### T4.4 对照组 OS
|
||||
|
||||
| 档位 | 主对照 | 辅助对照 |
|
||||
| ---- | -------------------------------- | ----------------------------- |
|
||||
| T4-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
|
||||
| T4-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） |
|
||||
|
||||
### T4.5 功率采集
|
||||
|
||||
| 设备 | 用途 | 适用档位 |
|
||||
| ----------------------------- | --------------------- | ----------- |
|
||||
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T4-L / T4-M |
|
||||
| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
|
||||
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T4-M / T3-L |
|
||||
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-L B 路线 |
|
||||
|
||||
---
|
||||
|
||||
## T5. 控制端场景 — 1 G ~ 8 G
|
||||
|
||||
### T5.1 定位
|
||||
|
||||
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
|
||||
|
||||
### T5.2 档位对比
|
||||
|
||||
| 维度 | T5-L 控制端-低 | T5-M 控制端-中 | T5-H 控制端-高 |
|
||||
| ----------- | ---------------------- | -------------------- | ------------------------------ |
|
||||
| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 |
|
||||
| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano |
|
||||
| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) |
|
||||
| **功耗** | 3~5 W | 5~10 W | 7~21 W |
|
||||
| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） |
|
||||
| **供电** | DC 5V / 12V | DC 12V | DC 12V |
|
||||
| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ |
|
||||
| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
|
||||
| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
|
||||
|
||||
#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | -------------------------------------- |
|
||||
| SoC | Rockchip RK3568 (22nm) |
|
||||
| CPU | 4× Cortex-A55 @ 2.0 GHz |
|
||||
| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） |
|
||||
| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） |
|
||||
| 内存带宽 | ~25.6 GB/s |
|
||||
| GPU | Mali-G52（仅辅助显示） |
|
||||
| 存储 | 8~16 GB eMMC |
|
||||
| 网络 | 1× 千兆 + 可选 WiFi |
|
||||
| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） |
|
||||
| **功耗** | **3~5 W**（无风扇被动散热） |
|
||||
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||
| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） |
|
||||
| 参考价格 | ~300~800 RMB（核心板/开发板） |
|
||||
|
||||
**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
|
||||
**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
|
||||
|
||||
#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | ---------------------------------------- |
|
||||
| SoC | Rockchip RK3576 (8nm) |
|
||||
| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） |
|
||||
| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 |
|
||||
| **内存** | **2~4 GB LPDDR5**（统一内存） |
|
||||
| 内存带宽 | ~40 GB/s |
|
||||
| **功耗** | **5~10 W**（无风扇被动） |
|
||||
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||
| 参考价格 | ~600~1,500 RMB |
|
||||
|
||||
**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
|
||||
**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
|
||||
|
||||
#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
|
||||
|
||||
**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
|
||||
|
||||
| 项目 | 规格 | 说明 |
|
||||
| --------- | --------------------------------------------------- | ------------------------ |
|
||||
| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** |
|
||||
| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 |
|
||||
| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 |
|
||||
| GPU | Mali-G610 MC4 | 仅辅助显示 |
|
||||
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
|
||||
| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
|
||||
| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T4-L 同 |
|
||||
| **功耗** | **7~21 W**（无风扇被动散热） | 6 TOPS 档 ~12W / 32 TOPS 档 ~21W |
|
||||
| 工作温度 | -40 ~ 60 ℃ 工业级 | 宽温优势 |
|
||||
| 出厂 OS | Ubuntu 22.04 | 换 SylixOS BSP |
|
||||
|
||||
> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
|
||||
|
||||
**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | --------------------------------------------------- |
|
||||
| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） |
|
||||
| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
|
||||
| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
|
||||
| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
|
||||
| 优势 | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
|
||||
| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
|
||||
| 参考价格 | ~$249（开发套件） |
|
||||
|
||||
**可运行模型（T5-H）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
|
||||
| ------------------------- | ---- | ------- | ----------- | ----- |
|
||||
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM |
|
||||
| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM |
|
||||
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
|
||||
| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
|
||||
|
||||
#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
|
||||
|
||||
**系统 (System)**
|
||||
|
||||
| 项目 | 规格 |
|
||||
| ------- | ---------------------------------------------------- |
|
||||
| SoC | Rockchip RK3588 (8nm) |
|
||||
| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） |
|
||||
| MCU | Cortex-M0 @200 MHz（协处理，可选） |
|
||||
| GPU | Mali-G610 MC4 |
|
||||
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
|
||||
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H |
|
||||
| **显存** | 统一内存（NPU 与 CPU 共享） |
|
||||
|
||||
**存储 / 扩展**
|
||||
|
||||
- EMMC 64 GB（系统盘）
|
||||
- 1× TF 卡槽（存储扩展）
|
||||
- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒）
|
||||
|
||||
**出厂软件**
|
||||
|
||||
- 操作系统: **Ubuntu 22.04**（出厂预装）
|
||||
- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
|
||||
|
||||
**算力与功耗（T5-H 档）**
|
||||
|
||||
| 指标 | 值 |
|
||||
| ------------------ | ------------------------------- |
|
||||
| **可用显存** | **8 GB**（16 GB 板分区限额） |
|
||||
| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) |
|
||||
| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) |
|
||||
| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） |
|
||||
| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
|
||||
| **TDP** | **7~21 W**（无风扇被动散热） |
|
||||
|
||||
### T5.3 SylixOS 要求（T5）
|
||||
|
||||
| 要求项 | 描述 | 风险 | 适用档位 |
|
||||
| ---------------------- | --------------------------------------- | -------------------- | --------- |
|
||||
| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T5-H |
|
||||
| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T5-M |
|
||||
| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T5-L |
|
||||
| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T5 全档 |
|
||||
| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T5-H |
|
||||
| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T5-H |
|
||||
| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T4-L/T5-H 切换） | 中（需 SylixOS 内存域支持） | T5-H |
|
||||
| CAN ×2 驱动 | 工业现场总线 | 中 | T5 全档 |
|
||||
| RS485 ×2 + RS232 ×1 | 串口 | 低 | T5 全档 |
|
||||
| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T5-H |
|
||||
| 看门狗 / RTC | 工业可靠性 | 低 | T5 全档 |
|
||||
| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T5-H 路线B |
|
||||
|
||||
### T5.4 对照组 OS
|
||||
|
||||
- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
|
||||
- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
|
||||
- T5-L / T5-M: Buildroot + PREEMPT_RT
|
||||
|
||||
---
|
||||
|
||||
## 5. 跨档位对比总表
|
||||
|
||||
### 5.1 全档位硬件规格对比
|
||||
|
||||
| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 |
|
||||
| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- |
|
||||
| **T5-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 |
|
||||
| **T5-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 |
|
||||
| **T5-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） |
|
||||
| **T4-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） |
|
||||
| **T4-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** |
|
||||
| **T3-L** | 32~64 GB / 48 GB 独显 | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 |
|
||||
| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） |
|
||||
| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 |
|
||||
| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 |
|
||||
| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 |
|
||||
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 |
|
||||
|
||||
### 5.2 模型规模梯度
|
||||
|
||||
| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
|
||||
| -------- | --------------------------- | ---------- | ------- | -------------- |
|
||||
| T5-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 控制端最低资源参考档，实时性基准 |
|
||||
| T5-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 控制端能效拐点 |
|
||||
| T5-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B |
|
||||
| T4-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 设备端推理 + 工业控制 |
|
||||
| T4-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 设备端多模型并发 |
|
||||
| T3-L | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘节点可跑 72B |
|
||||
| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 |
|
||||
| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B |
|
||||
| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 |
|
||||
| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 |
|
||||
| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 |
|
||||
|
||||
### 5.3 SylixOS 调度框架验证重点
|
||||
|
||||
| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
|
||||
| ----- | ----------- | ---------------------------------- | -------------------------- |
|
||||
| T5-L | 极小内存下保持关键保障负载边界 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 |
|
||||
| T5-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token |
|
||||
| T5-H | 极致资源约束下保持关键保障负载边界 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token |
|
||||
| T4-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s |
|
||||
| T4-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 |
|
||||
| T3-L | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS |
|
||||
| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 |
|
||||
| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s |
|
||||
| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 |
|
||||
| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS |
|
||||
| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 |
|
||||
|
||||
### 5.4 基线 OS 对照
|
||||
|
||||
| 档位 | SylixOS 实验组 | 主对照 (PREEMPT_RT Linux) | 虚拟化对照 | 容器对照 |
|
||||
| ------- | ---------------------- | --------------------- | -------------- | --------- |
|
||||
| T5-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker |
|
||||
| T5-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker |
|
||||
| T5-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T4-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T4-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker |
|
||||
| T3-L | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||
| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 采购与获取计划
|
||||
|
||||
| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
|
||||
| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
|
||||
| **P0** | T4-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
|
||||
| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 |
|
||||
| **P0** | T5-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T4-L 同机双档位 |
|
||||
| **P1** | T5-L | RK3568 1~2GB 核心板 | ~300-800 | 控制端最低资源参考档，必做 |
|
||||
| **P1** | T5-M | RK3576 4GB 核心板 | ~600-1,500 | 控制端能效拐点 |
|
||||
| **P1** | T4-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP |
|
||||
| **P2** | T4-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 |
|
||||
| **P2** | T3-L | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘节点可跑 72B |
|
||||
| **P2** | T5-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 |
|
||||
| **P3** | T2-M | 4× V100 32GB SXM + 8 卡底板 + 电源 | ~70,000-100,000 | 现有平台加卡扩容 |
|
||||
| **P3** | T2-H | 4× H100 80GB SXM5 工作站 | ~800,000-1,200,000 | 可租云实例替代 |
|
||||
| **P3** | T1-L | 3× 计算节点 + 12× V100 + IB | ~270,000 | 可用云实例替代 |
|
||||
| **P4** | T1-H | 4 节点 × 4×H100 + NDR IB | ~3,000,000+ | 强烈建议云租替代 |
|
||||
| — | 仪器 | DC 功率计 ×2 (T4+T5) | ~6,000 | T5 强制 |
|
||||
| — | 仪器 | INA226 采集板 ×2 | ~500 | T4+T5 |
|
||||
| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3 / T2 档 |
|
||||
| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） |
|
||||
| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 |
|
||||
| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） |
|
||||
| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 |
|
||||
|
||||
### 降本策略
|
||||
|
||||
1. **P0 零成本起步**: T2-L + T4-L + T5-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
|
||||
2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T4-L（16 GB）与 T5-H（8 GB），省去一台设备与一套 BSP 验证成本。
|
||||
3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T5-M 若 RK3576 BSP 不可用，用 T5-H 降配替代），谱系不断。
|
||||
4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
|
||||
5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
|
||||
6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
|
||||
|
||||
---
|
||||
|
||||
## 7. SylixOS BSP 适配 Checklist（跨档位汇总）
|
||||
|
||||
### 7.1 x86 BSP（T2 全档 + T1 全档）
|
||||
|
||||
- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动
|
||||
- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度
|
||||
- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心）
|
||||
- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M）
|
||||
- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H）
|
||||
- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举
|
||||
- [ ] nvidia-smi / DCGM 监控
|
||||
- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行
|
||||
- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属）
|
||||
- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属）
|
||||
- [ ] NCCL / MPI 分布式通信库（T1 专属）
|
||||
- [ ] IPMI / BMC 功耗采集
|
||||
- [ ] tickless + CPU 隔离 + 中断亲和性
|
||||
- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
|
||||
|
||||
### 7.2 ARM64 BSP — T234 / Ampere（T4-M / T3-L-A / T5-H 路线B）
|
||||
|
||||
- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
|
||||
- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
|
||||
- [ ] Jetson Ampere GPU CUDA 驱动
|
||||
- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属）
|
||||
- [ ] 16/32/64 GB LPDDR5 统一内存管理
|
||||
- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W)
|
||||
- [ ] 10GbE 网络驱动
|
||||
- [ ] MIPI CSI 工业相机接口
|
||||
- [ ] PCIe Gen4 扩展
|
||||
- [ ] 温度传感器 + 降频阈值
|
||||
|
||||
### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
|
||||
|
||||
- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
|
||||
- [ ] CPU 频率独立调节 (governor)
|
||||
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
|
||||
- [ ] tickless / idle hook
|
||||
- [ ] 看门狗驱动
|
||||
- [ ] **rknn / RKLLM NPU 驱动**（核心）
|
||||
- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位）
|
||||
- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0）
|
||||
- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动
|
||||
- [ ] CAN ×2 驱动
|
||||
- [ ] RS485 ×2 + RS232 ×1 驱动
|
||||
- [ ] GPIO 子系统
|
||||
- [ ] HDMI 输出（调试）
|
||||
- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
|
||||
|
||||
### 7.4 ARM64 BSP — RK3576（T5-M）
|
||||
|
||||
- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
|
||||
- [ ] 6 TOPS NPU 驱动（RKNN 栈）
|
||||
- [ ] 2~4 GB LPDDR5 内存管理
|
||||
- [ ] CAN / RS485 / 千兆网络驱动
|
||||
- [ ] 低功耗被动散热下的频率/温度联动
|
||||
|
||||
### 7.5 ARM64 BSP — RK3568（T5-L）
|
||||
|
||||
- [ ] SylixOS BSP for RK3568（4×A55 SMP）
|
||||
- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
|
||||
- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点）
|
||||
- [ ] CAN / RS485 / 千兆网络驱动
|
||||
- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证
|
||||
@@ -0,0 +1,302 @@
|
||||
# SylixOS 任务关键系统中人工智能目标负载实验设计
|
||||
|
||||
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
|
||||
> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
|
||||
|
||||
## 1. 研究目标与实验范围
|
||||
|
||||
本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
|
||||
|
||||
| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
|
||||
|---|---|---|---|
|
||||
| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
|
||||
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
|
||||
| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
|
||||
| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
|
||||
|
||||
执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
|
||||
|
||||
这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
|
||||
|
||||
在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
|
||||
|
||||
## 2. 设备分层与实验平台
|
||||
|
||||
### 2.1 T5~T1 五类部署形态、十一档实验映射
|
||||
|
||||
沿用设备文档的档位标签，实际容量单列。多节点架构统一记为 `T1-L`，容量边界单独记录，不据容量直接推导性能。
|
||||
|
||||
| 部署形态与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
|
||||
|---|---|---|---|
|
||||
| T5-L 控制端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
|
||||
| T5-M 控制端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
|
||||
| T5-H 控制端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
|
||||
| T4-L 设备端 SoC 低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
|
||||
| T4-M 设备端 SoC 中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
|
||||
| T3-L 边缘节点代表档 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 |
|
||||
| T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
|
||||
| T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
|
||||
| T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
|
||||
| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
|
||||
| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |
|
||||
|
||||
GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
|
||||
|
||||
`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
|
||||
|
||||
其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
|
||||
|
||||
### 2.2 平台 A：现有 V100 服务器
|
||||
|
||||
依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
|
||||
|
||||
实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
|
||||
|
||||
分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
|
||||
|
||||
### 2.3 平台 B：现有 RK3588 工业盒
|
||||
|
||||
依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
|
||||
|
||||
- B16：全量 16 GB，记为 T4-L。
|
||||
- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
|
||||
- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
|
||||
- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
|
||||
|
||||
**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
|
||||
|
||||
### 2.4 测量设备
|
||||
|
||||
| 测量对象 | 工具与接线 | 要求 |
|
||||
|---|---|---|
|
||||
| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 |
|
||||
| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 |
|
||||
| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 |
|
||||
| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 |
|
||||
| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 |
|
||||
|
||||
传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。
|
||||
|
||||
## 3. 软件与模型准入
|
||||
|
||||
### 3.1 分阶段准入门槛
|
||||
|
||||
| 门槛 | 验证内容 | 通过证据 | 失败后的处理 |
|
||||
|---|---|---|---|
|
||||
| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 |
|
||||
| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 |
|
||||
| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 |
|
||||
| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
|
||||
| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
|
||||
|
||||
SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
|
||||
|
||||
“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
|
||||
|
||||
对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
|
||||
|
||||
### 3.2 模型梯度与用途
|
||||
|
||||
| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
|
||||
|---|---|---|---|
|
||||
| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 |
|
||||
| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 |
|
||||
| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 |
|
||||
| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 |
|
||||
| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
|
||||
| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
|
||||
|
||||
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
|
||||
|
||||
### 3.3 输入与正确性控制
|
||||
|
||||
LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。
|
||||
|
||||
YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。
|
||||
|
||||
## 4. 指标定义与采集口径
|
||||
|
||||
### 4.1 实时性与系统开销
|
||||
|
||||
对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。
|
||||
|
||||
| 指标 | 定义 | 汇总 |
|
||||
|---|---|---|
|
||||
| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 |
|
||||
| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 |
|
||||
| 响应时间 | f_i − r_i | 分位数、观测最大值 |
|
||||
| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 |
|
||||
| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 |
|
||||
| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 |
|
||||
| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 |
|
||||
|
||||
缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。
|
||||
|
||||
### 4.2 推理服务
|
||||
|
||||
在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。
|
||||
|
||||
- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。
|
||||
- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。
|
||||
- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。
|
||||
- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。
|
||||
- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。
|
||||
|
||||
### 4.3 能耗与热状态
|
||||
|
||||
在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。
|
||||
|
||||
同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。
|
||||
|
||||
报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。
|
||||
|
||||
## 5. 对照组与变量控制
|
||||
|
||||
### 5.1 OS 与部署组
|
||||
|
||||
| 编号 | 配置 | 作用 |
|
||||
|---|---|---|
|
||||
| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 |
|
||||
| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
|
||||
| O2 | SylixOS 默认配置 | 原生系统基线 |
|
||||
| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
|
||||
| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
|
||||
| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
|
||||
|
||||
平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
|
||||
|
||||
### 5.2 配置控制与消融
|
||||
|
||||
所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。
|
||||
|
||||
完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。
|
||||
|
||||
## 6. 负载设计
|
||||
|
||||
### 6.1 实时任务
|
||||
|
||||
主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。
|
||||
|
||||
任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
|
||||
|
||||
### 6.2 伴生竞争负载与推理到达
|
||||
|
||||
| 场景 | 内容 | 目的 |
|
||||
|---|---|---|
|
||||
| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
|
||||
| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
|
||||
| L2 | 关键保障负载 + LLM | 核心双目标场景 |
|
||||
| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
|
||||
| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
|
||||
| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务竞争 |
|
||||
| L6 | 关键保障负载 + LLM + YOLO（可选） | 多人工智能目标负载竞争与优先级影响 |
|
||||
| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
|
||||
|
||||
人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
|
||||
|
||||
突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
|
||||
|
||||
## 7. 实验矩阵与具体步骤
|
||||
|
||||
### 7.1 核心实验
|
||||
|
||||
| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 |
|
||||
|---|---|---|---|
|
||||
| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 |
|
||||
| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 |
|
||||
| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 |
|
||||
| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 |
|
||||
| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 |
|
||||
| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 |
|
||||
| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 |
|
||||
| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
|
||||
| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
|
||||
|
||||
面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
|
||||
|
||||
- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
|
||||
- `E3` 负责比较双目标并存时的达标边界；
|
||||
- `E4` 负责观察内存限额与容量失败边界；
|
||||
- `E6` 负责组织功耗、温度与降频证据；
|
||||
- `E8` 负责验证长时间运行、恢复与热稳定性。
|
||||
|
||||
E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
|
||||
|
||||
E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
|
||||
|
||||
### 7.2 条件扩展
|
||||
|
||||
| 扩展 | 前提 | 实验内容 | 结论边界 |
|
||||
|---|---|---|---|
|
||||
| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 |
|
||||
| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 |
|
||||
| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 |
|
||||
| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 |
|
||||
| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 |
|
||||
|
||||
T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
|
||||
|
||||
若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
|
||||
|
||||
跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
|
||||
|
||||
### 7.3 控制实验数量
|
||||
|
||||
不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。
|
||||
|
||||
## 8. 运行流程与统计方法
|
||||
|
||||
1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。
|
||||
2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。
|
||||
3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。
|
||||
4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。
|
||||
5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。
|
||||
6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。
|
||||
7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。
|
||||
|
||||
观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。
|
||||
|
||||
## 9. 验收与结果判断
|
||||
|
||||
验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
|
||||
|
||||
| 类型 | 判据 | 说明 |
|
||||
|---|---|---|
|
||||
| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 |
|
||||
| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 |
|
||||
| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 |
|
||||
| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 |
|
||||
| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 |
|
||||
| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 |
|
||||
|
||||
当前候选阈值包括“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，并在正式实验前冻结；8/15/21 W 数值同样单独按配置记录，不作为跨配置统一验收值。
|
||||
|
||||
## 10. 数据产物与论文图表
|
||||
|
||||
建议按 `results/<experiment>/<platform>/<os>/<config>/<run_id>/` 保存数据，每次运行至少包含：
|
||||
|
||||
| 文件 | 内容 |
|
||||
|---|---|
|
||||
| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 |
|
||||
| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 |
|
||||
| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 |
|
||||
| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 |
|
||||
| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 |
|
||||
| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 |
|
||||
|
||||
不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。
|
||||
|
||||
最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。
|
||||
|
||||
## 11. 实施顺序与停止条件
|
||||
|
||||
| 阶段 | 工作 | 完成标志 |
|
||||
|---|---|---|
|
||||
| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 |
|
||||
| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 |
|
||||
| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 |
|
||||
| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 |
|
||||
| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 |
|
||||
| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 |
|
||||
|
||||
设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
|
||||
@@ -0,0 +1,453 @@
|
||||
# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
|
||||
|
||||
> **版本**: v0.1 (研究启动版)
|
||||
> **日期**: 2026-09-20
|
||||
> **整合来源**: 01-研究逻辑说明.md + 02-基础设备与算力基础.md + 03-实验设计.md + 10-研究框架/00~07 系列文档 + 第三方基准复现思路
|
||||
> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章规划稿 (后续随实验推进持续迭代)
|
||||
|
||||
---
|
||||
|
||||
## 0. 文章定位与核心贡献
|
||||
|
||||
### 0.1 一句话定位
|
||||
|
||||
> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**
|
||||
|
||||
### 0.2 三大核心贡献
|
||||
|
||||
| 编号 | 贡献 | 来源整合 | 对标空白 |
|
||||
|------|------|----------|----------|
|
||||
| C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
|
||||
| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
|
||||
| C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
|
||||
|
||||
### 0.3 目标读者与发表场景
|
||||
|
||||
| 维度 | 选择 |
|
||||
|------|------|
|
||||
| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
|
||||
| 备选 | EMSOFT / DAC / MLSys (系统方向) |
|
||||
| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
|
||||
| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 文章整体结构 (十章)
|
||||
|
||||
```
|
||||
第1章 引言 — 问题、动机、贡献概述
|
||||
第2章 背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
|
||||
第3章 T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
|
||||
第4章 SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
|
||||
第5章 实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
|
||||
第6章 大模型负载选型与配置 — 跨档位模型矩阵
|
||||
第7章 实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
|
||||
第8章 深入分析 — 档位间性能曲线 + RTOS vs 普通 Linux / PREEMPT_RT 差异化
|
||||
第9章 讨论与威胁有效性 — 适用场景边界 + 局限性
|
||||
第10章 结论与展望
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 逐章详细规划
|
||||
|
||||
### 第1章 引言
|
||||
|
||||
**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 1.1 问题矛盾 | 人工智能目标负载要求结果及时且有效，关键保障负载要求严格截止期；两者进入同一任务关键系统后，会在 CPU、内存、总线、加速器和中断路径上发生竞争 | |
|
||||
| 1.2 研究空白 | 公开基准大多基于 Linux/Ubuntu，重点放在吞吐或单任务性能，缺少 RTOS 对人工智能目标负载与关键保障负载双目标实时保障的系统评测 | 01-研究逻辑说明.md §2、§8 |
|
||||
| 1.3 本文贡献 | C1 (双目标实时保障优势)、C2 (五类部署形态统一验证矩阵)、C3 (业界基准对齐)，一句话概述每个贡献 | |
|
||||
| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
|
||||
|
||||
**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
|
||||
|
||||
---
|
||||
|
||||
### 第2章 背景与相关工作
|
||||
|
||||
**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 2.1 人工智能目标负载特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 I/O 抖动；输出质量与时效双重约束 | 03-实验设计.md §3、10-研究框架/01~04 |
|
||||
| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 10-研究框架/00.md §3、05-中断与实时性保障.md |
|
||||
| 2.3 PREEMPT_RT 相对短板 | 内核态长路径、系统后台线程、内存回收与共享资源竞争仍可能拉长 `P99.9`；其可预测性增强但不等同于专用 RTOS | 00-整体研究框架.md §5、07-方法论与评估工具链.md §2、§4 |
|
||||
| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | 00-整体研究框架.md §6 |
|
||||
| 2.5 第三方基准方法学 | 第三方文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 避坑清单 | 03-实验设计.md §4、07-方法论与评估工具链.md §8~§10 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
|
||||
| Tab.1 | SylixOS vs 普通 Linux / PREEMPT_RT 对比 | 关键 RTOS 特性对应的双目标实时保障优势与对照平台短板 |
|
||||
|
||||
---
|
||||
|
||||
### 第3章 T5~T1 五类部署形态验证矩阵
|
||||
|
||||
**目标**: 800~1000 词，用连续验证矩阵承载主问题，保持硬件作为验证矩阵的角色。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 3.1 分级维度与分档规则 | 以「部署形态」为第一分类维度，以「统一内存/显存容量」为分档参考；T5~T1 五类部署形态下连续展开 | 02-基础设备与算力基础.md §0.1 |
|
||||
| 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
|
||||
| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
|
||||
| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
|
||||
| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.2 | T5~T1 五类部署形态验证矩阵全景图 | 横轴=容量 (1 GB→2 TB, log 刻度), 纵轴=功耗 (3 W→25 kW, log 刻度), 11 个档位点标注, 散热形态用颜色分区 (被动/风冷/液冷/机房液冷) |
|
||||
| Tab.2 | 11 档位全规格对比表 | 容量、算力、功耗、加速器架构、散热、互联、SylixOS BSP 风险、状态 (现有/需扩展) |
|
||||
| Tab.3 | 模型规模梯度表 | 11 档位 × 代表模型 × 量化 × 显存占用 × 角色 (控制端最低资源参考档→超大模型分布式) |
|
||||
| Tab.4 | 采购计划表 | P0~P4 优先级 + 估算费用 + 降本策略 |
|
||||
|
||||
---
|
||||
|
||||
### 第4章 SylixOS 调度框架技术架构
|
||||
|
||||
**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
|
||||
| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
|
||||
| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
|
||||
| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
|
||||
| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
|
||||
| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
|
||||
| Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
|
||||
| Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
|
||||
| Tab.6 | 六大优化方向与低功耗专题线概览 | 方向/专题 × (核心问题/关键手段/目标指标/对应章节) |
|
||||
|
||||
---
|
||||
|
||||
### 第5章 实验方法学
|
||||
|
||||
**目标**: 800~1000 词，这是 C2 和 C3 的方法论基础，也是本文"可复现"承诺的核心。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
|
||||
| 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
|
||||
| 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
|
||||
| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
|
||||
| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
|
||||
| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
|
||||
| 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
|
||||
| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
|
||||
| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
|
||||
| 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
|
||||
| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.5 | 实验方法论流程图 | `G0~G4` 准入 + `O0~O4` 对照 + 第三方基准对齐校验门 |
|
||||
| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
|
||||
| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
|
||||
| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
|
||||
|
||||
本章设置下面两张“索引表”：
|
||||
|
||||
| 索引表 | 作用 |
|
||||
|------|------|
|
||||
| RQ → 实验 → 章节映射表 | 把 `RQ1~RQ4` 对应到 `E0~E8`、`L0~L7` 与第7/8章，保证每个研究问题都有直接证据链 |
|
||||
| 场景编号 → 结果章节映射表 | 把 `L0~L7` 对应到第7章的小节与图表，保持实验编号与结果章节的直接锚点 |
|
||||
|
||||
---
|
||||
|
||||
### 第6章 大模型负载选型与配置
|
||||
|
||||
**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 03-实验设计.md §3.2 |
|
||||
| 6.2 跨档位模型矩阵 | T5-L: Qwen2.5-0.5B INT4；T5-M: 1.5B INT4；T5-H: 3B/7B INT4；T4-L: 3B/7B INT4 (RKLLM)；T4-M: 14B/32B INT4 (TensorRT-LLM)；T3-L: 72B INT4；T2-L: 72B INT4/14B FP16；T2-M: 72B FP16；T2-H: DeepSeek-V2 FP16；T1-L: 72B FP16 分布式；T1-H: 671B INT4 | 02-基础设备与算力基础.md §5.2、03-实验设计.md §3.2 |
|
||||
| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T4-M/T3-L)、llama.cpp (T2-L/T4-L 退路)、RKLLM (T5/T4-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 03-实验设计.md §3.1~§3.3 |
|
||||
| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 03-实验设计.md §3、§6 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
|
||||
| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
|
||||
|
||||
---
|
||||
|
||||
### 第7章 实验结果
|
||||
|
||||
**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
|
||||
| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
|
||||
| 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
|
||||
| 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
|
||||
| 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
|
||||
| 7.6 温度-功耗-性能耦合 | 对应 `RQ3`；可与 `L1/L2/L7` 组合，报告 25%→100% CPU 逐步加压的三维耦合曲线，以及 SylixOS vs 普通 Linux / PREEMPT_RT Linux 的降频触发温度与性能下降斜率 | 03-实验设计.md §4、06-能耗与热管理.md |
|
||||
| 7.7 异构核分配 | 对应 `RQ2/RQ3`；主要落在 RK3588 路线与 `L2/L3`，体现 A76 (LLM) + A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 03-实验设计.md §6、03-加速器协同调度.md |
|
||||
| 7.8 跨档位性能曲线 | 对应 `RQ4`；汇总 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线；第7.8节按“已实测结果”与“后续扩展计划”两类展示 | 02-基础设备与算力基础.md §5.3、03-实验设计.md §2 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
|
||||
| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 `W(t)` 曲线，SylixOS vs 普通 Linux / PREEMPT_RT Linux 叠加 |
|
||||
| Fig.7 | 双目标实时保障延迟分布 (★ 核心证据) | 人工智能目标负载与关键保障负载的 P50~Max 直方图 + 时间序列，4 变体叠加 |
|
||||
| Fig.8 | 人工智能目标负载输出时延直方图 | Qwen2.5-7B 单流 1 h 采集，SylixOS vs 普通 Linux / PREEMPT_RT Linux |
|
||||
| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间关键保障负载延迟 spike 与人工智能目标负载队列变化的联合时间序列 |
|
||||
| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
|
||||
| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T5-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
|
||||
| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
|
||||
|
||||
建议在第7章开头直接放入下面两张索引表：
|
||||
|
||||
| 研究问题 | 主要实验单元 | 主要场景编号 | 主要结果章节 | 核心图表 |
|
||||
|------|------|------|------|------|
|
||||
| `RQ1` 双目标约束下的实时保障 | `E1` 微基准、`E3` 混合负载、`E8` 长稳与恢复 | `L0`、`L2`、`L3`、`L4`、`L5`、`L7` | `7.3`、`7.4` | `Fig.7`、`Tab.13` |
|
||||
| `RQ2` 隔离机制的代价与收益 | `E3` 混合负载、`E4` 内存限额、`E7` 消融、`E8` 长稳与恢复 | `L2`、`L3`、`L4`、`L5`、`L6`、`L7` | `7.3`、`7.5`、`7.7` | `Fig.7`、`Fig.9`、`Tab.13` |
|
||||
| `RQ3` 功耗预算下的系统协同能力 | `E2` 推理基线、`E3` 混合负载、`E6` 能耗与热、`E8` 长稳与恢复 | `L1`、`L2`、`L7` | `7.2`、`7.6` | `Fig.6`、`Fig.10`、`Tab.13` |
|
||||
| `RQ4` 规模扩展后的边界与瓶颈 | `E5` 多卡竞争、`X3`/`X4`/`X5` 条件扩展 | `L3`、`L5`、`L6`、`L7` | `7.5`、`7.8` | `Fig.11`、`Tab.14` |
|
||||
|
||||
| 场景编号 | 场景定义 | 论文归属章节 | 主要回答的问题 | 核心图表 |
|
||||
|------|------|------|------|------|
|
||||
| `L0` | 仅关键保障负载 | `7.3` 低延迟结果 | 关键保障负载下界、测量链路开销 | 延迟 CDF、基线表 |
|
||||
| `L1` | 仅人工智能目标负载 | `7.2` 低功耗结果、`7.3` 低延迟结果 | 人工智能目标负载基线时效、能耗与服务能力 | `Fig.6`、`Fig.8` |
|
||||
| `L2` | 关键保障负载 + LLM | `7.4` 双目标实时保障结果 | 双目标是否同时达标，是全文核心主场景 | `Fig.7`、`Tab.13` |
|
||||
| `L3` | `L2` + CPU 竞争负载 | `7.4`、`7.5` | CPU 竞争下的隔离能力与调度边界 | `Fig.7`、竞争负载对照表 |
|
||||
| `L4` | `L2` + 内存流式读写 | `7.4` | 内存带宽与容量压力下的边界变化 | 内存压力时间序列、违约率表 |
|
||||
| `L5` | `L2` + 网络/存储 I/O | `7.4`、`7.5` | IRQ、DMA 与系统服务竞争影响 | `Fig.9`、I/O 干扰对照表 |
|
||||
| `L6` | 关键保障负载 + LLM + YOLO（可选） | `7.5` | 多人工智能目标负载共存时的优先级与公平性 | 多模型公平性图、Jain 指数表 |
|
||||
| `L7` | `L2` + 突发/过载 | `7.4`、`7.5`、`7.6` | 过载、拒绝、恢复与热耦合下的系统稳定性 | `Fig.9`、`Fig.10`、恢复时间表 |
|
||||
|
||||
---
|
||||
|
||||
### 第8章 深入分析
|
||||
|
||||
**目标**: 800~1000 词，从数据中提炼规律性结论。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 8.1 档位间性能曲线规律 | 容量、功耗和拓扑变化下 RTOS 优势的变化趋势；分析哪些档位更容易体现差异、哪些档位优势可能收窄 | 02-基础设备与算力基础.md §5.3 |
|
||||
| 8.2 SylixOS vs 普通 Linux / PREEMPT_RT 差异化量化 | 分别评价关键保障负载边界、人工智能目标负载时效和系统协同收益；按档位和场景分别判定 | 03-实验设计.md §9、§10 |
|
||||
| 8.3 双目标场景下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 关键保障负载不被长路径抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 模型加载不引入额外抖动；中断线程化 + 亲和性 → NPU/GPU 中断不污染实时核 | 05-中断与实时性保障.md、02-KV-Cache与内存管理.md |
|
||||
| 8.4 能效分析 | 每 token 能耗 vs 档位；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 `J/token` 对比 | 02-基础设备与算力基础.md §0.3、06-能耗与热管理.md |
|
||||
| 8.5 BSP 风险与可行性 | x86 BSP、ARM64 RK3588 BSP、T234 Jetson BSP、RKLLM 移植等路径的风险等级与降本策略 | 02-基础设备与算力基础.md §7、03-实验设计.md §3 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.12 | RTOS 优势 vs 部署档位趋势图 | 横轴=11 档位，纵轴=SylixOS 相对普通 Linux / PREEMPT_RT Linux 的 `P99.9` 与有效吞吐改善百分比，标注"显著优势/可比偏优/未体现"区间 |
|
||||
| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
|
||||
| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
|
||||
|
||||
---
|
||||
|
||||
### 第9章 讨论与威胁有效性
|
||||
|
||||
**目标**: 400~600 词，诚实地界定适用边界和局限性。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
|
||||
| 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
|
||||
| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
|
||||
| 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
|
||||
|
||||
---
|
||||
|
||||
### 第10章 结论与展望
|
||||
|
||||
**目标**: 300~400 词，总结贡献并指出未来方向。
|
||||
|
||||
| 小节 | 内容要点 |
|
||||
|------|----------|
|
||||
| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果（基准对齐 ±X%、双目标场景下相对 PREEMPT_RT Linux 的边界改善 X%、能效改善 X%） |
|
||||
| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
|
||||
| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-推理图任务调度.md §8 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 来源文档到章节的映射矩阵
|
||||
|
||||
| 来源文档 | 主要贡献章节 | 次要贡献章节 |
|
||||
|----------|------------|------------|
|
||||
| **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
|
||||
| **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
|
||||
| **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
|
||||
| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
|
||||
| **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
|
||||
| **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
|
||||
| **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
|
||||
| **04-量化精度感知调度.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
|
||||
| **05-中断与实时性保障.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
|
||||
| **06-能耗与热管理.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
|
||||
| **07-方法论与评估工具链.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
|
||||
|
||||
---
|
||||
|
||||
## 4. 关键数据产物清单
|
||||
|
||||
| 编号 | 产物 | 类型 | 优先级 | 依赖 |
|
||||
|------|------|------|--------|------|
|
||||
| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 02-基础设备与算力基础.md 已就绪 |
|
||||
| D2 | 跨档位模型矩阵 | 数据表 | P0 | 02-基础设备与算力基础.md + 03-实验设计.md 已就绪 |
|
||||
| D3 | RK3588 上 sysbench/stress-ng 基准复现数据 | 实测数据 | P0 | 需 SylixOS BSP + sysbench 移植 |
|
||||
| D4 | 业界基准对比表 (SylixOS vs 文章基线) | 对比表 | P0 | D3 |
|
||||
| D5 | 混合负载 30 min 全周期延迟时间序列 | 实测数据 | P0 | 需混合负载驱动脚本 + 4 变体 |
|
||||
| D6 | 混合负载延迟分布直方图 (4 变体叠加) | 图表 | P0 | D5 |
|
||||
| D7 | 功耗分阶段曲线 (prefill/decode/idle) | 图表 | P0 | 功率计采集 + LLM 推理 |
|
||||
| D8 | LLM token 延迟直方图 (1 h 采集) | 图表 | P1 | vLLM/RKLLM benchmark |
|
||||
| D9 | 突发加载瞬间实时任务时间序列 | 图表 | P1 | 混合负载脚本 + 模型切换 |
|
||||
| D10 | 温度-功耗-性能三维耦合曲线 | 图表 | P1 | stress-ng 逐步加压 + 温度日志 |
|
||||
| D11 | 跨档位性能连续曲线 | 图表 | P1 | 已完成档位实测 + 后续档位条件补充；未完成档位不写成正式结果 |
|
||||
| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
|
||||
| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 03-实验设计.md §11 模板 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 写作优先级与依赖关系
|
||||
|
||||
```
|
||||
Phase 0: BSP 适配 + 工具移植 (3 周)
|
||||
├─ SylixOS RK3588 BSP 部署
|
||||
├─ sysbench / stress-ng / RKLLM 移植验证
|
||||
└─ vLLM / llama.cpp 在 SylixOS 编译运行
|
||||
|
||||
Phase 1: 基准复现 + 文章骨架 (1.5 周)
|
||||
├─ D3: RK3588 基准复现 → D4: 业界对比表
|
||||
├─ 撰写: §1 引言 + §2 背景 + §3 验证矩阵 + §4 技术架构 + §5 方法学 + §6 模型选型
|
||||
└─ 依赖: D3 通过 ±15% 对齐门 → 准入 Phase 2
|
||||
|
||||
Phase 2: 低功耗测试 + 温度耦合 (2 周)
|
||||
├─ D7: 功耗曲线 + D10: 温度耦合曲线
|
||||
└─ 撰写: §7.2 + §7.6
|
||||
|
||||
Phase 3: 低延迟 + 混合负载测试 (3 周)
|
||||
├─ D5+D6: 混合负载核心证据 + D8: token 延迟直方图 + D9: 突发场景
|
||||
└─ 撰写: §7.3 + §7.4 + §7.5
|
||||
|
||||
Phase 4: 异构调度测试 (1 周)
|
||||
├─ 场景6: A76+A55+M0 异构分配
|
||||
└─ 撰写: §7.7
|
||||
|
||||
Phase 5: 数据汇总 + 深入分析 + 全文定稿 (2.5 周)
|
||||
├─ D11: 跨档位曲线 + D12: 优越性矩阵
|
||||
├─ 撰写: §7.8 + §8 深入分析 + §9 讨论 + §10 结论
|
||||
└─ 全文校对 + 图表终版
|
||||
```
|
||||
|
||||
**总周期: ~13 周** (Phase 0~5 累计)
|
||||
|
||||
---
|
||||
|
||||
## 6. 章节字数预算
|
||||
|
||||
| 章节 | 预算字数 | 占比 |
|
||||
|------|---------|------|
|
||||
| §1 引言 | 400 | 4% |
|
||||
| §2 背景与相关工作 | 700 | 7% |
|
||||
| §3 T5~T1 五类部署形态验证矩阵 | 900 | 9% |
|
||||
| §4 技术架构 | 700 | 7% |
|
||||
| §5 实验方法学 | 900 | 9% |
|
||||
| §6 模型选型 | 600 | 6% |
|
||||
| §7 实验结果 | 1800 | 18% |
|
||||
| §8 深入分析 | 900 | 9% |
|
||||
| §9 讨论 | 500 | 5% |
|
||||
| §10 结论 | 350 | 3% |
|
||||
| 参考文献 + 附录 | ~2000 | 23% |
|
||||
| **总计** | **~9750** | 100% |
|
||||
|
||||
> 注: 按 RTSS/RTAS 会议论文 10~12 页双栏计算, 正文约 8000~10000 词, 参考文献+附录另计。
|
||||
|
||||
---
|
||||
|
||||
## 7. 核心叙事线 (Storyline)
|
||||
|
||||
```
|
||||
问题矛盾 (§1)
|
||||
→ 人工智能目标负载时效/有效性 vs 关键保障负载严格截止期, 在任务关键系统中必须共存
|
||||
→ 空白: 国产 RTOS 在任务关键系统中承载人工智能目标负载的系统化数据仍然稀缺
|
||||
|
||||
背景铺垫 (§2)
|
||||
→ 人工智能目标负载的 CPU/内存/长尾特征
|
||||
→ RTOS 的 6 项调度优势 + 普通 Linux / PREEMPT_RT 的边界
|
||||
→ 第三方方法学引入 (5 维度 + 5 避坑)
|
||||
|
||||
验证矩阵 (§3) ← C2 验证框架
|
||||
→ 11 档位连续展开: 1 GB/3 W → 2 TB/25 kW
|
||||
→ 现有 P0 零成本起步 (V100 + RK3588)
|
||||
→ 一机两档降本
|
||||
|
||||
技术架构 (§4)
|
||||
→ 五层技术栈 + 六大优化方向
|
||||
→ LLM 推理 DAG → RTOS 任务映射
|
||||
→ BSP 适配要点与风险
|
||||
|
||||
方法学 (§5) ← C1/C3 基础
|
||||
→ 第三方基准复现 (先对齐 ±15% 才准入)
|
||||
→ 双目标负载四原则 (核心设计)
|
||||
→ 功耗真测 + 温度监控 + 元数据强制
|
||||
|
||||
模型选型 (§6)
|
||||
→ 跨 11 档位的 Qwen/LLaMA/MiniCPM/Whisper 矩阵
|
||||
→ INT4/INT8/FP16 量化梯度
|
||||
|
||||
实验结果 (§7) ← 本文核心
|
||||
→ 7.1 基准对齐 (第一层门)
|
||||
→ 7.2~7.3 功耗/延迟 (基础指标)
|
||||
→ 7.4 双目标实时保障 (★ 核心证据)
|
||||
→ 7.5~7.7 并发/突发/异构
|
||||
→ 7.8 跨档位连续曲线
|
||||
|
||||
深入分析 (§8)
|
||||
→ 档位间趋势: 哪些资源条件与拓扑更容易体现 RTOS 优势
|
||||
→ 优越性量化: 关键保障负载边界、人工智能目标负载时效与有效吞吐的联合改进
|
||||
→ 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
|
||||
→ 能效: V100 基线 vs H100 上限, INT4 拐点
|
||||
|
||||
讨论 (§9)
|
||||
→ 适用边界: T5/T4 更容易体现优势, T1-H 可能收窄
|
||||
→ 威胁有效性: RKLLM 移植/V100 驱动/sysbench 移植
|
||||
→ 与已有工作: vs vLLM/NPU SDK/CUDA Stream/第三方文章
|
||||
|
||||
结论 (§10)
|
||||
→ 三大贡献量化回顾
|
||||
→ 跨平台/功能安全/分布式/自适应展望
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 待确认事项
|
||||
|
||||
| 编号 | 待确认项 | 影响章节 | 当前假设 |
|
||||
|------|---------|---------|---------|
|
||||
| Q1 | SylixOS 在 x86+4×V100 NVLink 的 CUDA 驱动支持度 | §4.5, §7.3, §8.5 | 需翼辉确认; 单卡先行, 4 卡作 stretch |
|
||||
| Q2 | RK3588 BSP 是否集成 rknn/RKLLM | §5.2, §7.1, §9.2 | 需翼辉确认; 退路 llama.cpp CPU |
|
||||
| Q3 | sysbench/stress-ng 在 SylixOS 可移植性 | §5.2, §7.1 | POSIX 兼容, 假设可行 |
|
||||
| Q4 | T234 (Jetson Orin) BSP 是否支持 | §3.2 (T4-M / T3-L) | 风险高; T4-L 用 RK3588 起步 |
|
||||
| Q5 | RK3588 板卡是否引出 M0 调试接口 | §7.7 (场景6) | 若未引出, 场景6 需调整 |
|
||||
| Q6 | 是否纳入功能安全 SIL2/IEC 61508 章节 | §10.2 展望 | 暂列为展望, 不入正文 |
|
||||
| Q7 | 是否纳入昇腾 Qwen-7B 作为第二业界参照 | §7.1, §9.4 | 暂列为后续, 非本方案硬件 |
|
||||
| Q8 | 主对照组确认: Ubuntu 22.04+PREEMPT_RT | §5.7 | 与第三方文章配置一致, 可比性最高 |
|
||||
|
||||
---
|
||||
@@ -0,0 +1,24 @@
|
||||
# 实验与规划索引
|
||||
|
||||
本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
|
||||
|
||||
## 阅读建议
|
||||
|
||||
1. `01-研究逻辑说明.md`
|
||||
2. `02-基础设备与算力基础.md`
|
||||
3. `03-实验设计.md`
|
||||
4. `04-论文写作规划.md`
|
||||
5. `05-论文结构总览.png`
|
||||
|
||||
## 文件说明
|
||||
|
||||
- `01-研究逻辑说明.md`
|
||||
- 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
|
||||
- `02-基础设备与算力基础.md`
|
||||
- T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
|
||||
- `03-实验设计.md`
|
||||
- 准入条件、对照原则、混合负载场景、指标与验收方法
|
||||
- `04-论文写作规划.md`
|
||||
- 论文结构、章节分工、图表规划和证据映射
|
||||
- `05-论文结构总览.png`
|
||||
- 文章结构与逻辑关系示意图
|
||||
@@ -0,0 +1,21 @@
|
||||
# 联合研究方索引
|
||||
|
||||
本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
|
||||
|
||||
## 当前内容
|
||||
|
||||
- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
|
||||
- 面向项目内部的合作设想文档
|
||||
- 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
|
||||
- `罗蕾教授资料/`
|
||||
- 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
|
||||
- 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
|
||||
- `翼辉信息资料/`
|
||||
- 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
|
||||
- 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 对外沟通时，可先阅读人物概览与科研路径两篇。
|
||||
- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
|
||||
- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。
|
||||
@@ -0,0 +1,210 @@
|
||||
# 潜在合作研究路径：罗蕾教授与翼辉信息
|
||||
|
||||
> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
|
||||
|
||||
## 1. 两个合作方的协同结构
|
||||
|
||||
本项目对应的是一个典型的“**学术问题定义 + 系统机制设计 + 产业平台验证**”三段式问题：
|
||||
|
||||
1. 需要有人把研究问题定义清楚，并把方法学、可调度性分析、评价体系和论文表达做扎实；
|
||||
2. 需要有人把 RTOS 机制、工具链、BSP、系统实现和真实行业场景接起来；
|
||||
3. 需要把两者合成一个既能发表、又能落地、还能与产业沟通的闭环。
|
||||
|
||||
在这个结构里，罗蕾教授与翼辉信息的优势方向并不相同，但恰好可以形成互补：
|
||||
|
||||
- **罗蕾教授**作为电子科技大学相关领域广受尊重的知名专家学者，更适合承担研究方法、系统建模、学术组织与标准化表达这一侧；
|
||||
- **翼辉信息**作为大型实时操作系统与基础软件平台领域极具代表性的产业样本，更适合承担 SylixOS 平台、工程实现、场景验证与产业落地这一侧。
|
||||
|
||||
合作路径可以让两个合作方分别占据研究闭环中的不同位置。
|
||||
|
||||
## 2. 罗蕾教授更适合承担的合作角色
|
||||
|
||||
基于其长期研究积累与代表成果，罗蕾教授更适合在下面几个方向发挥作用：
|
||||
|
||||
### 2.1 研究问题与方法学共建
|
||||
|
||||
罗蕾教授长期积累的重点在嵌入式实时操作系统、可调度性分析、汽车电子基础软件、安全隔离与系统工程化。这位在相关领域享有较高声誉的专家学者，尤其适合参与：
|
||||
|
||||
- 研究问题的学术化表述；
|
||||
- `RQ1~RQ4` 的研究问题拆解；
|
||||
- `O0/O1/O2/O3` 对照逻辑的合理性论证；
|
||||
- `TTFT/TPOT + deadline miss + jitter + 系统协同` 这套双目标指标体系的学术组织；
|
||||
- 长稳、突发、恢复、消融等实验类型的论文化组织。
|
||||
|
||||
罗蕾教授更适合帮助项目把工程现象组织成可发表的系统研究问题。
|
||||
|
||||
### 2.2 系统建模与分析工具链
|
||||
|
||||
罗蕾教授在实时系统建模、AADL 可调度性分析、AUTOSAR 任务映射、隔离保护等方向已有持续积累，因此她适合参与：
|
||||
|
||||
- 关键保障负载的任务模型抽象；
|
||||
- 人工智能目标负载进入系统后的实时约束建模；
|
||||
- 基于 `RTA/WCET` 的边界分析；
|
||||
- 任务映射、优先级分配、资源预算与配额约束的分析框架；
|
||||
- 从实验结果回推系统机制成立条件的理论解释。
|
||||
|
||||
这一部分做扎实后，项目可以形成“机制 - 结果 - 边界”三位一体的研究结构。
|
||||
|
||||
### 2.3 学术产出与标准化表达
|
||||
|
||||
罗蕾教授长期处在“研究 - 标准 - 产业化”打通的路径上，因此她也适合参与：
|
||||
|
||||
- 论文结构与贡献凝练；
|
||||
- 学术报告和项目申报材料；
|
||||
- 将系统机制抽象为可推广的方法学；
|
||||
- 后续延伸到行业测试规范或联合白皮书时，可协助形成更规范的表达。
|
||||
|
||||
## 3. 翼辉信息更适合承担的合作角色
|
||||
|
||||
翼辉信息的价值首先体现在其所代表的 **SylixOS 大型跨平台实时操作系统平台** 与行业落地经验。作为国内 RTOS 与关键基础软件方向颇具代表性的企业样本，翼辉信息在合作设想中具备很高的参考价值。
|
||||
|
||||
### 3.1 主实验样例与平台能力提供方
|
||||
|
||||
翼辉信息最适合承担的第一角色，是 `SylixOS` 主实验样例的提供与支撑，包括：
|
||||
|
||||
- SylixOS 版本、配置、调度参数与机制能力说明；
|
||||
- BSP、驱动、工具链、trace/观测接口支持；
|
||||
- SMP、多核绑定、中断治理、内存锁定、隔离机制等平台能力验证；
|
||||
- 针对任务关键系统场景的默认配置与优化配置对照。
|
||||
|
||||
这一部分决定了项目能否把“研究对象”落实到一套可验证的 RTOS 平台上。
|
||||
|
||||
### 3.2 工程实现与系统机制落地
|
||||
|
||||
翼辉信息也适合参与系统机制层的实现与验证，例如：
|
||||
|
||||
- 人工智能目标负载与关键保障负载的优先级/配额治理；
|
||||
- 核隔离、IRQ 亲和、设备中断分流；
|
||||
- KV Cache、内存池、DMA/I/O 路径的系统治理；
|
||||
- 长稳运行、恢复策略、故障隔离和资源回收机制；
|
||||
- 不同部署形态下的实际可部署方案。
|
||||
|
||||
这部分决定了项目能否从“方法论文档”走到“工程上真的成立”。
|
||||
|
||||
### 3.3 行业场景与产业验证语境
|
||||
|
||||
翼辉信息长期服务于航天、轨道交通、电力、工业自动化、智能汽车等任务关键行业，因此它更适合提供：
|
||||
|
||||
- 任务关键系统的真实负载语境；
|
||||
- 典型关键保障任务模板；
|
||||
- 更贴近行业的干扰链路和恢复要求；
|
||||
- 对“结果是否具有产业解释力”的判断。
|
||||
|
||||
这一部分非常重要，因为它会决定研究结果是不是只在实验室里成立。
|
||||
|
||||
## 4. 三方合作的分工结构
|
||||
|
||||
本项目可按“三方闭环”来组织：
|
||||
|
||||
- **罗蕾教授侧**：负责研究问题定义、系统建模、方法学审阅、论文组织与学术表达增强；
|
||||
- **翼辉信息侧**：负责 SylixOS 平台支撑、机制实现接口、工程验证条件与产业场景输入；
|
||||
- **我们项目组**：负责前期调研、实验执行、资料整理、跨平台对照实现与协同支撑。
|
||||
|
||||
可以把它理解成下面这条链路：
|
||||
|
||||
`研究问题定义 -> 方法学与分析框架 -> RTOS 机制实现 -> 实验验证 -> 论文与白皮书表达`
|
||||
|
||||
其中：
|
||||
|
||||
- 罗蕾教授更靠前半段和总结抽象；
|
||||
- 翼辉信息更靠中间实现与后端产业验证；
|
||||
- 项目组负责根据合作方的方向与建议，把实验推进、资料整合和执行工作衔接起来。
|
||||
|
||||
## 5. 可优先推进的合作研究主题
|
||||
|
||||
合作讨论可以优先围绕下面几类题目推进：
|
||||
|
||||
### 5.1 双目标实时保障基准共建
|
||||
|
||||
目标：
|
||||
|
||||
- 联合定义一套面向任务关键系统的 AI 目标负载 + 关键保障负载基准；
|
||||
- 统一 `TTFT/TPOT`、`deadline miss`、`P99/P99.9 jitter`、`E/token` 等指标；
|
||||
- 明确 `G0~G4` 准入和 `O0~O4` 对照逻辑。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧负责方法学与指标体系合理性；
|
||||
- 翼辉信息侧负责 SylixOS 落地和观测手段；
|
||||
- 项目组负责实验编排、数据整理和协同落实。
|
||||
|
||||
### 5.2 任务关键系统中的 AI 负载准入与隔离机制
|
||||
|
||||
目标：
|
||||
|
||||
- 研究人工智能目标负载进入系统后，如何通过配额、优先级、核绑定、时间预算、内存预算等机制维持关键保障任务边界；
|
||||
- 给出“哪些条件下准入、哪些条件下拒绝、哪些条件下需要降级运行”的规则。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧偏规则建模和边界分析；
|
||||
- 翼辉信息侧偏机制实现和可部署性验证。
|
||||
|
||||
### 5.3 面向实际行业场景的 SylixOS 机制验证
|
||||
|
||||
目标：
|
||||
|
||||
- 选择 1~2 个更贴近行业的关键场景，如工业控制、车载控制、边缘智能节点；
|
||||
- 把实验从抽象负载推进到“有行业解释力”的场景负载。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 翼辉信息侧提供场景输入和系统约束；
|
||||
- 罗蕾教授侧帮助把场景抽象成学术上可论证的问题。
|
||||
|
||||
### 5.4 联合论文 / 白皮书 / 申报材料
|
||||
|
||||
目标：
|
||||
|
||||
- 学术上形成论文；
|
||||
- 产业上形成白皮书或联合研究说明；
|
||||
- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧偏学术与规范表达；
|
||||
- 翼辉信息侧偏产业价值、案例与平台能力；
|
||||
- 项目组承担材料汇总、写作配合与整合支撑。
|
||||
|
||||
### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
|
||||
|
||||
目标：
|
||||
|
||||
- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
|
||||
- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
|
||||
- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
|
||||
- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
|
||||
- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
|
||||
|
||||
这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
|
||||
|
||||
## 6. 更现实的推进顺序
|
||||
|
||||
推进顺序以稳妥、小步、可验证为宜：
|
||||
|
||||
1. **先分别沟通**：确认双方对课题定位、研究边界、合作兴趣是否一致；
|
||||
2. **先小后大**：先围绕一个具体问题试合作，例如基准设计、实验审阅或场景讨论；
|
||||
3. **先方法后平台**：先把研究问题和方法学框架对齐，再谈平台实现细节；
|
||||
4. **先形成最小闭环**：先做出一版可验证的实验与分析，再决定是否扩展成正式联合研究。
|
||||
|
||||
## 7. 当前文档使用边界
|
||||
|
||||
这份文档当前更适合作为：
|
||||
|
||||
- 项目内部筹划材料；
|
||||
- 对外沟通前的思路整理；
|
||||
- 预判双方合作接口是否互补的参考稿。
|
||||
|
||||
当前使用场景包括：
|
||||
|
||||
- 项目内部筹划与分工设计；
|
||||
- 对外沟通前的内容准备；
|
||||
- 合作接口与协同结构的前期梳理。
|
||||
|
||||
这份文档回答的是：
|
||||
|
||||
> **与罗蕾教授、翼辉信息形成联合研究时，最合理的合作结构是什么。**
|
||||
@@ -0,0 +1,18 @@
|
||||
# 罗蕾教授人物概览
|
||||
|
||||
罗蕾教授是电子科技大学教授、博士生导师，长期在电子科技大学从事嵌入式基础软件相关教学、科研与产业化工作。她曾任嵌入式软件工程中心主任，持续聚焦嵌入式操作系统、物联网网络安全与数据安全、工业软件、智能计算等方向，是电子科技大学在嵌入式系统与相关产业应用领域具有较高影响力、广受尊重的知名专家学者。
|
||||
|
||||
罗蕾教授与电子科技大学保持了长期稳定的学术关联。她于 1987 年毕业于电子科技大学计算机系，1996 年晋升副教授，2003 年评为教授，2005 年晋升博士生导师。她既是学校本土培养起来的教师，也长期参与了学科建设、课程建设与团队建设。
|
||||
|
||||
罗蕾教授的工作范围已经超出了传统高校教师的单一角色。她曾作为国家“核高基”专家参与智能手机、汽车电子、数字电视等多项嵌入式基础软件重大专项实施，同时担任国家智能网联汽车创新中心专家、车载信息服务产业应用联盟（TIAA）网络安全委员会秘书长、工信部区块链技术与数据安全重点实验室相关专家等职务。她的工作位置也因此横跨了高校、重大专项、行业联盟和产业协同几个层面。
|
||||
|
||||
罗蕾教授的研究主线是一条逐步扩展的“底层软件到行业场景”的路线。较早阶段，她的工作更多与嵌入式实时操作系统、嵌入式基础软件和开发工具有关；随后逐步延伸到汽车电子、物联网安全、移动支付、区块链与数据安全，再到今天更强调工业软件、网络安全和智能计算。这种演进很有代表性，反映出她的研究沿着产业需求不断外扩。
|
||||
|
||||
罗蕾教授是一位具有明显“工程化导向”和产业连接能力、在相关领域享有较高声誉的知名专家学者。她既有学校内部的学术与教学身份，也深度参与国家项目、行业标准和企业合作；既关注嵌入式系统的底层技术，又把研究延伸到汽车、支付、数据安全等具体行业。她的个人画像体现出“学术研究者 + 工程组织者 + 产业连接者”的复合型角色。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
|
||||
3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
|
||||
@@ -0,0 +1,20 @@
|
||||
# 罗蕾教授的教学与人才培养工作
|
||||
|
||||
罗蕾教授不仅是一位在嵌入式系统领域具有较高影响力的专家学者，也长期深度投入教学工作。她的教学工作有一个很明显的特点：围绕一门核心课程，把教材、实验、课程资源和人才培养体系连在一起。
|
||||
|
||||
最能代表这一点的课程，是《嵌入式系统及应用》。这门课早在 2007 年就获得国家精品课程认定，之后又先后成为四川省精品资源共享课、四川省精品在线开放课程，并在 2023 年获得国家级一流本科课程认定。它是一门经过多年迭代、持续建设的核心课程。
|
||||
|
||||
这门课是一门典型的工程化课程。课程内容覆盖嵌入式系统导论、ARM 体系结构与编程、嵌入式软件系统、任务管理与调度、同步互斥与通信、中断时间和内存管理等主题，并配有 ARM 实验和 uC/OS-II 操作系统实验。课程结构采用“原理 + 实验 + 开发能力”的组织方式，目标是让学生真正进入嵌入式系统开发。
|
||||
|
||||
罗蕾教授在教学上的另一个特点，是把教材建设和课程建设配套推进。她主编过《嵌入式实时操作系统及应用开发》第一、二、三版，以及《嵌入式系统及应用》等著作。对一门工科课程来说，教材是否成体系，往往决定了课程能否长期稳定传承；她也由此搭建起一个可复制、可持续的知识框架。
|
||||
|
||||
罗蕾教授的人才培养方向也比较清晰。她指导的软件工程、电子信息等学位点，研究方向主要包括嵌入式软件技术与应用、工业软件、网络安全、智能计算等。这些方向既有传统的嵌入式系统主线，也对接了当下工业软件和安全计算的需求。她的人才培养模式强调“从基础软件出发，向新应用场景延展”。
|
||||
|
||||
罗蕾教授在教学上的重要性，体现在她于电子科技大学长期建设出了一套有工程背景、有实验支持、有教材配套、能持续培养学生的嵌入式教学体系。这也是这位知名专家学者在校内外形成广泛学术影响力的重要来源之一。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学计算机学院教学成果页：<https://www.scse.uestc.edu.cn/info/1039/10809.htm>
|
||||
3. 中国大学 MOOC《嵌入式系统及应用》课程页：<https://www.icourse163.org/course/UESTC-1206862805?from=searchPage&outVendor=zw_mooc_pcssjg_>
|
||||
4. 电子科技大学教学资源平台课程页：<https://resource.uestc.edu.cn/learn/course/preview/spoc/17269f9718ed4af1b94108437e6b6e1a>
|
||||
@@ -0,0 +1,21 @@
|
||||
# 罗蕾教授的科研与产业化路径
|
||||
|
||||
罗蕾教授的科研工作持续把嵌入式基础软件能力往产业场景里推进。作为电子科技大学相关方向具有代表性的知名专家学者，她长期主持或参与国家重大专项、863 项目、自然科学基金、发改委软件产业化专项等任务，同时又深度参与企业合作、行业标准与联盟工作。这种“研究 - 标准 - 产品 - 场景”连起来的路径，是她区别于很多纯学院型学者的重要地方。
|
||||
|
||||
她早期的重要发力点是嵌入式基础软件和实时操作系统。她曾主持“面向嵌入式软件的生产线”“智能手机嵌入式软件平台”“嵌入式实时操作系统及其开发工具”等项目，所在团队也长期围绕嵌入式操作系统、嵌入式网络安全、汽车电子基础软件展开工作。这类方向的共同点，是都处在系统底层，技术门槛高、复用价值大，而且很容易形成行业平台能力。
|
||||
|
||||
之后，她的科研和产业化路径逐步向汽车电子和网络安全方向深化。团队列出的代表性项目里，既有“汽车电子网络安全标准化研究白皮书编制”“面向汽车电子的代码安全技术研究与实现”，也有“智能汽车安全加固与监控产品研发与产业化”“车辆身份唯一性认证模型的测试委托”等项目。罗蕾教授的工作集中在汽车电子基础软件、代码安全、身份认证、网络安全标准等更底层、更可落地的位置。
|
||||
|
||||
同时，她的团队也明显向区块链与数据安全扩展。相关成果包括区块链基础平台“优云链”和面向数据共享的“优数”平台，应用场景覆盖无人机运输物流追踪、汽车大数据交易平台、学分银行、移动支付可信数据共享联盟链、国际贸易通关协同、财政资金监管等。她所推动的区块链工作与数据确权、共享交换、可信交易、安全监管等产业需求直接挂钩。
|
||||
|
||||
除了项目本身，罗蕾教授在行业规则层面的参与也很值得关注。她牵头或参与了 20 余项国家、行业和团体标准，团队也参与了多项汽车网络安全相关国家标准与行业标准。她的影响力同时体现在技术落地和行业通用规则推进两个层面。对很多产业技术路线来说，这一步往往比单点成果更有长期影响。
|
||||
|
||||
她的科研路径可以概括为三层：第一层是嵌入式操作系统、开发工具和基础软件；第二层是网络安全、汽车电子、物联网与数据安全；第三层是标准化、产业平台和企业合作落地。正因为这三层是打通的，罗蕾教授的工作才呈现出很强的“工程系统型”特征，并形成了连续展开的研究主题体系。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
|
||||
3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
|
||||
5. 世展网转载行业观点文章：<https://www.shifair.com/informationDetails/135407.html>
|
||||
@@ -0,0 +1,29 @@
|
||||
# 罗蕾教授的代表成果与研究主题
|
||||
|
||||
罗蕾教授作为电子科技大学相关方向具有较高影响力的知名专家学者，其研究主题围绕“嵌入式系统底层能力如何支持复杂场景”逐步展开。她较有代表性的成果，大致可以分成四个方向：嵌入式实时操作系统、汽车电子基础软件与安全、网络与数据安全、以及面向新场景的智能计算延展。
|
||||
|
||||
第一类成果是嵌入式实时操作系统与基础软件。罗蕾教授主编过《嵌入式实时操作系统及应用开发》和《嵌入式系统及应用》等教材，导师页面列出的代表论文也长期围绕任务调度、GUI、多任务系统、AADL 可调度性分析等主题展开。比如 `UCaS: a schedulability analysis tool for AADL models` 这类工作，体现的是她早期在嵌入式软件建模与调度分析方面的积累。这个方向的核心关键词，是实时性、可调度性和基础软件工程化。
|
||||
|
||||
第二类成果是汽车电子嵌入式操作系统与 AUTOSAR 相关研究。比较典型的论文包括《汽车电子嵌入式操作系统的隔离保护机制》和《AUTOSAR 可运行实体-任务自动映射方法研究》。前者关注的是在有限硬件资源下实现多层级隔离保护，以降低系统整体失效概率；后者则围绕 ECU 配置和实时系统任务映射，提高汽车软件开发效率。她在汽车电子方向持续关注操作系统机制、安全隔离和软件架构配置这类关键底层问题。
|
||||
|
||||
第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。
|
||||
|
||||
第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。这一方向也可以继续向小型化、低功耗、资源受限系统中的智能应用展开，把嵌入式基础软件、可调度性分析与低功耗部署问题连接起来。
|
||||
|
||||
罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。
|
||||
|
||||
## 可关注的公开代表成果
|
||||
|
||||
- `汽车电子嵌入式操作系统的隔离保护机制`
|
||||
- `AUTOSAR可运行实体-任务自动映射方法研究`
|
||||
- `A Cross-platform Mobile Payment Solution Based on Web Technology`
|
||||
- `UCaS: a schedulability analysis tool for AADL models`
|
||||
- `An intrusion detection system integrating network-level intrusion detection and host-level intrusion detection`
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
3. 电子科技大学学报相关论文页：<http://www.juestc.uestc.edu.cn/article/doi/10.3969/j.issn.1001-0548.2014.03.023?viewType=citedby-info>
|
||||
4. 学术摘要页《汽车电子嵌入式操作系统的隔离保护机制》：<https://www.xueshu.com/dzkjdxxb/201403/2984678.html>
|
||||
5. 维普摘要页《AUTOSAR可运行实体-任务自动映射方法研究》：<http://dianda.cqvip.com/Qikan/Article/Detail?id=7000589928>
|
||||
@@ -0,0 +1,15 @@
|
||||
# 罗蕾教授资料目录
|
||||
|
||||
本目录用于介绍罗蕾教授的学术背景、教学工作、科研路径与代表性研究主题，并将内容拆分为几篇可以独立阅读的介绍文章。
|
||||
|
||||
## 文件列表
|
||||
|
||||
- `01-人物概览.md`：聚焦罗蕾教授的基本履历、学术身份与整体定位。
|
||||
- `02-教学与人才培养.md`：聚焦课程建设、教材编写与人才培养工作。
|
||||
- `03-科研与产业化路径.md`：聚焦科研方向、重大项目、行业标准与产业合作。
|
||||
- `04-代表成果与研究主题.md`：聚焦代表性研究主题、论文与技术成果。
|
||||
|
||||
## 使用说明
|
||||
|
||||
- 各文档彼此独立，可单独转发或继续扩写。
|
||||
- 各文档正文以人物介绍和研究工作为主，参考资料统一列于文末。
|
||||
@@ -0,0 +1,28 @@
|
||||
# 翼辉信息与大型实时操作系统定位概览
|
||||
|
||||
翼辉信息在本项目中对应的是**面向任务关键系统的大型跨平台实时操作系统平台**。SylixOS 的核心价值集中在复杂系统中的实时软件底座能力，即维持确定性、可预测性和系统边界。
|
||||
|
||||
翼辉信息长期围绕 SylixOS 展开自身定位，定位为“软件定义智能装备业内领先的基础软件架构供应商”，强调基于原创工业操作系统和整体软件架构技术，为火箭、卫星、高铁、大飞机、无人设备、电网电站、工业自动化、智能汽车等任务关键型智能设备提供稳定、可靠、安全的软件系统方案。其平台能力覆盖**关键行业、复杂系统、长期交付和基础平台能力**，在相关领域具备较强代表性和较高行业辨识度。
|
||||
|
||||
翼辉信息最核心的产品身份是“**大型实时操作系统**”。SylixOS 的核心能力包括：SMP 多核实时调度、多处理器架构支持、动态装载、POSIX 兼容、高安全高可靠、复杂系统集成，以及长期版本维护。SylixOS 承担的是更高层次的软件平台职责：在不同硬件架构、不同规模平台和不同关键行业约束下，为复杂任务提供统一、稳定且可演进的实时操作系统基础。
|
||||
|
||||
本项目围绕的大型跨平台实时操作系统平台，正与翼辉信息所代表的平台能力直接对应。翼辉信息提供的是一种可以跨平台承载、跨行业验证、并且天然面向任务关键场景的 RTOS 平台样本。
|
||||
|
||||
翼辉团队的技术起点可追溯到 2006 年，随后在 2015 年公司化运营。SylixOS 内核经过工信部赛普测评中心源代码测评，自主化率达到 100%，并获得德国 TÜV SUD 集团颁发的 IEC 61508（SIL3）、EN 50128（SIL4）和 ISO 26262（ASIL D）认证。翼辉信息已经进入高安全、高可靠、高约束行业的软件平台提供方序列，是非常值得重视、也颇具分量的**产业级实时操作系统案例**。
|
||||
|
||||
除了 SylixOS 内核本身，翼辉信息还呈现出一条从 RTOS 向完整基础软件栈外扩的路径。其产品和能力包括 RealEvo 开发环境、VSOA 分布式软总线、任务关键型云原生体系、工业自动化数字基座、飞控与仿真产品等。翼辉正在把实时操作系统扩展为面向关键装备的软件平台。这种平台化能力与本项目的验证方向高度一致。
|
||||
|
||||
翼辉信息在本项目中的身份可以表述为：**面向关键行业的大型跨平台实时操作系统与基础软件平台提供方**。作为产业落地样本，它能够直接支撑与实时调度、关键系统约束、复杂工程交付相关的课题论证。
|
||||
|
||||
## 对本项目最有价值的定位结论
|
||||
|
||||
1. 翼辉信息代表的是**大型跨平台实时操作系统平台**。
|
||||
2. SylixOS 的核心价值体现在**复杂系统中的实时性、确定性与平台能力**。
|
||||
3. 翼辉信息更适合作为**产业级 RTOS 案例**。
|
||||
4. 它能够帮助本项目围绕“实时操作系统如何治理智能负载进入任务关键系统后的边界问题”展开产业样本验证。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,17 @@
|
||||
# SylixOS 技术能力与演进
|
||||
|
||||
SylixOS 是翼辉信息的核心技术载体，是一款支持 SMP 多核实时调度、可运行于多种 CPU 架构目标平台的“大型实时操作系统”。其工程积累集中体现在调度、隔离、兼容性和长期演进能力上。
|
||||
|
||||
SylixOS 的内核在 2006 年完成，最初具备线程调度、中断管理、定时器、RMS、信号量等核心机制；随后逐步加入 I/O、网络、文件系统、内存管理、POSIX 支持、C++ 支持、GDB 调试、Qt 支持和更广泛的平台适配。2011 年开始支持多核和动态装载；2012 年开始支持进程；2018 年全面支持 C-SKY 和 RISC-V；2020 年推出 LTS 版本；2021 年通过 IEC 61508（SIL3）和 EN 50128（SIL4）国际安全认证；2022 年进一步通过 ISO 26262（ASIL D）认证并支持 LoongArch。SylixOS 持续朝着可落地的大型实时系统平台演进。
|
||||
|
||||
SylixOS 对多核与异构调度的强调，也与本项目高度相关。其 2023 年 V3.0.0 阶段已经开始支持异构算力大小核处理器，并提供灵活高效的调度器与调度策略，在算力和功耗之间取得平衡。这一能力与 LLM 推理线程、实时控制任务在共享 CPU、缓存和内存资源时的冲突控制直接相关。SylixOS 在大小核调度、SMP 调度策略、长期版本维护和实时性保障上的成熟能力，也使其非常适合作为实验平台或联合验证对象。
|
||||
|
||||
SylixOS 周边能力也比较完整。其支持多种 CPU 架构，强调强实时、高安全、高可靠；同时配套 RealEvo 开发环境、仿真与远程开发能力，甚至扩展到容器、分布式软总线和任务关键型云原生体系。它已经形成较完整的软件工程与集成配套。对研究项目而言，这种配套能力很关键，因为很多真实工业验证会卡在工具链、仿真环境、应用移植和系统验证流程上。
|
||||
|
||||
SylixOS 主要承担 RTOS 与基础软件底座角色。在本项目语境下，研究重点是 SylixOS 这类 RTOS 如何对 AI 推理任务进行资源隔离、优先级控制、实时保障和系统级治理。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
|
||||
2. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
3. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
@@ -0,0 +1,18 @@
|
||||
# 行业落地与生态版图
|
||||
|
||||
翼辉信息持续进入关键行业落地场景，其服务对象集中在火箭、卫星、高铁、大飞机、工业自动化、能源电力、智能汽车、低空经济等任务关键型装备领域。这些行业共同要求硬实时或强实时、长期稳定、功能安全和工程可维护性。
|
||||
|
||||
翼辉信息正在构建一套更完整的生态版图。除了 SylixOS 之外，公开展示的还包括 RealEvo 轻量开发环境、VSOA 分布式软总线、工业自动化数字基座、可编程控制器、虚拟 PLC、边缘计算机、飞控系统、飞行仿真平台等。其商业策略已延伸到“关键装备基础软件平台方”这一层级。对联合研究而言，这种生态化布局可以覆盖内核测评、整机验证、边缘控制、系统集成和行业样机落地等更宽的接口。
|
||||
|
||||
行业案例与用户故事也体现出清晰的行业线索。首页展示了中国铁道科学研究院和星际荣耀的用户评价，前者强调轨交信号控制系统对功能安全、稳定性、实时性的苛刻要求，后者强调在火箭飞控场景中通过 RTOS 对复杂软件进行分层抽象的重要性。航天行业页面还提到，翼辉信息与相关航天单位开展深度合作，基于 SylixOS 的星载操作系统用于星务和载荷设备开发，并参与火箭控制器、卫星载荷等系统建设。翼辉的主要市场集中在高可靠装备场景。
|
||||
|
||||
翼辉信息在南京的软件产业生态中也被作为“工业底层操作系统”代表企业来呈现。2026 年南京雨花台区公开报道提到，南京翼辉信息 2016 年落地软件谷，围绕 SylixOS 研发逐步形成产业能力，并将经验复制到水务、地铁运营、地下空间运维等场景。报道还提到其正推动人工智能、边缘计算与操作系统深度融合。翼辉的产业化路径已经覆盖军工之外的城市基础设施和工业场景。
|
||||
|
||||
翼辉信息已经把 RTOS 能力嵌入了多个高要求行业场景，并在工具链、行业方案和系统架构层面继续外扩。对本项目而言，它既是实验平台的重要来源，也是后续验证场景和行业接口的重要支撑。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. 翼辉信息航天行业页：<http://www.acoinfo.cn/industry-center/spaceflight>
|
||||
4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,38 @@
|
||||
# 与本项目的潜在协同点
|
||||
|
||||
把翼辉信息放进本项目的联合研究方名单，能够为项目提供一个较有代表性的**产业落地案例**，帮助我们把课题从抽象的“实时操作系统理论”推进到“任务关键系统中的工程验证”。
|
||||
|
||||
本项目围绕的大型跨平台实时操作系统平台比较，聚焦于五类硬件条件下智能负载进入任务关键系统后的确定性、可预测性与实时保障表现。翼辉信息对应的是一个面向关键行业长期演进的 RTOS 平台提供方，因此在这个课题中具有清晰的产业样本价值。
|
||||
|
||||
第一，翼辉信息适合作为**基础平台型产业案例**。SylixOS 被持续定义为“大型实时操作系统”，其核心能力集中在 SMP 多核实时调度、跨处理器架构支持、动态装载、长期维护、高安全高可靠，以及面向复杂系统集成的工程能力。翼辉信息在这一结构中承担的是“系统级平台厂商”角色，与本项目的平台研究对象高度一致。
|
||||
|
||||
第二，翼辉信息适合作为**任务关键系统落地语境下的验证样本**。其行业服务重点集中在轨道交通、航天、航空、电力、工业自动化、智能汽车等领域，这些场景共同要求系统长期稳定运行，并对时序、可靠性、安全性和工程交付有明确要求。翼辉这样的案例能够把研究问题放到具有明确时序边界和系统保障要求的工业语境中。
|
||||
|
||||
第三，翼辉信息适合作为**RTOS 在任务关键场景中的边界控制能力**这一命题的产业对照载体。未来设计对照实验时，重点就在于同一类任务关键负载下，SylixOS 这类大型跨平台 RTOS 与标准 Linux、PREEMPT_RT Linux 这类通用或实时增强型系统相比，在 deadline miss、尾延迟、任务抖动、资源隔离和故障恢复上形成怎样的边界控制能力。翼辉的产业案例价值就在这里：它让这一研究命题可以被放到真实行业约束中讨论。
|
||||
|
||||
第四，翼辉信息还适合作为**工程闭环能力的观察对象**。翼辉围绕 SylixOS 不仅提供内核，还扩展了开发环境、仿真、软总线、数字基座、任务关键型云原生与系统化交付能力。它已经形成一整套从内核到工具链再到行业集成的方法论。工程闭环能力也直接决定学术结论能否落到产业场景里。
|
||||
|
||||
第五，翼辉信息在本项目中的价值集中在**实时操作系统平台、关键行业基础软件和系统治理能力**。围绕 SylixOS 这类大型跨平台 RTOS，可以进一步展开 AI 推理系统进入任务关键系统后的实时约束建模、优先级与配额控制、内存带宽与缓存竞争治理、大小核与能耗协同、容器化封装，以及控制任务不失稳条件下的系统级实验设计。
|
||||
|
||||
翼辉信息为“大型跨平台实时操作系统在任务关键系统中的边界控制能力”这一研究命题，提供了一个能够落到关键行业、复杂系统和长期交付语境中的产业样本。
|
||||
|
||||
## 作为产业落地案例时可重点强调的价值
|
||||
|
||||
1. **平台定位**：翼辉代表的是大型跨平台实时操作系统平台。
|
||||
2. **场景准确**：其公开落地行业天然属于任务关键系统，比消费电子场景更能支撑课题成立。
|
||||
3. **对照准确**：便于把 SylixOS 与 Linux / PREEMPT_RT 等系统放到统一的工业约束下比较。
|
||||
4. **验证准确**：可从调度、隔离、故障恢复、能耗治理、系统集成多个层面观察 RTOS 的真实优势。
|
||||
|
||||
## 可继续深挖的合作问题
|
||||
|
||||
1. SylixOS 当前公开可支持到什么程度的 AI 推理运行时、边缘推理框架或异构算力调度能力。
|
||||
2. 在 SylixOS 平台上，实时控制任务与推理任务共存时可用的隔离手段包括哪些，例如核绑定、容器、时间分片、内存配额、设备访问权限控制等。
|
||||
3. 以翼辉作为产业落地案例时，对照组采用 Linux、PREEMPT_RT Linux，还是两者同时纳入。
|
||||
4. 能否联合定义一个面向任务关键系统的 AI 干扰基准测试，用于量化 deadline miss、尾延迟、抖动和能耗影响。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
|
||||
4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,15 @@
|
||||
# 翼辉信息资料目录
|
||||
|
||||
本目录用于介绍翼辉信息及其 SylixOS 技术体系，服务于联合研究判断、产业协同沟通和 RTOS 技术路线分析。
|
||||
|
||||
## 文件列表
|
||||
|
||||
- `01-公司与RTOS定位概览.md`：聚焦翼辉信息的公司定位、核心产品和公开产业身份。
|
||||
- `02-SylixOS技术能力与演进.md`：聚焦 SylixOS 的技术特征、发展里程碑和能力边界。
|
||||
- `03-行业落地与生态版图.md`：聚焦翼辉信息在关键行业的应用方向、案例和生态布局。
|
||||
- `04-与本项目的潜在协同点.md`：聚焦翼辉信息与本项目“RTOS 管理 LLM 推理资源竞争”主题的结合点。
|
||||
|
||||
## 使用说明
|
||||
|
||||
- 各文档彼此独立，可单独阅读或继续扩写。
|
||||
- 正文以公司定位、平台能力和行业应用介绍为主，参考资料统一列于文末。
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,42 @@
|
||||
# SylixOS LLM RTOS Research Repo
|
||||
|
||||
本仓库现按“总览、研究框架、实验规划、外部资料、交付物、归档”六个层次组织，便于把研究主线、写作材料和外部导入内容分开维护。
|
||||
|
||||
## 目录结构
|
||||
|
||||
- `00-项目总览/`
|
||||
- 当前研究问题与项目定位边界说明
|
||||
- `10-研究框架/`
|
||||
- 核心研究框架
|
||||
- 六个优化方向与方法学子文档
|
||||
- `20-实验与规划/`
|
||||
- 硬件谱系
|
||||
- 实验设计
|
||||
- 研究逻辑说明
|
||||
- 论文规划与配图
|
||||
- `30-联合研究方/`
|
||||
- 联合研究方资料、人物背景与协作参考
|
||||
- `40-交付物/`
|
||||
- Word 规范稿
|
||||
- 白皮书与汇报输出
|
||||
- `90-归档/`
|
||||
- 外部导入副本
|
||||
- 压缩包与暂存杂项
|
||||
|
||||
## 建议阅读顺序
|
||||
|
||||
1. `00-项目总览/01-当前研究问题：背景、问题与挑战.md`
|
||||
2. `00-项目总览/02-研究定位与项目边界.md`
|
||||
3. `20-实验与规划/README.md`
|
||||
4. `20-实验与规划/01-研究逻辑说明.md`
|
||||
5. `20-实验与规划/02-基础设备与算力基础.md`
|
||||
6. `20-实验与规划/03-实验设计.md`
|
||||
7. `10-研究框架/README.md`
|
||||
8. `10-研究框架/00-整体研究框架.md`
|
||||
9. `20-实验与规划/04-论文写作规划.md`
|
||||
|
||||
## 说明
|
||||
|
||||
- `10-研究框架/00-整体研究框架.md` 与 `01~07` 子文档保持同目录，避免内部引用失效。
|
||||
- `20-实验与规划/` 中的核心规划文档保持同目录，便于交叉引用。
|
||||
- `90-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。
|
||||
Reference in New Issue
Block a user