284 lines
16 KiB
Markdown
284 lines
16 KiB
Markdown
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
|
||
|
||
## 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*
|