eaiadmin
f18f9f2fd3
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.
239 lines
9.9 KiB
Markdown
239 lines
9.9 KiB
Markdown
# 面向AI的实时控制基础系统整体研究框架
|
||
|
||
## 0. 核心问题
|
||
|
||
本框架围绕“人工智能能力进入实时控制系统之后，基础系统如何维持整体实时边界”展开。核心判断是：
|
||
|
||
> **当人工智能目标负载进入实时控制系统后，系统需要解决的已经不是单一操作系统问题，而是模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存、NPU、GPU、DMA 和规则兜底机制共同构成的整体实时性问题。`SylixOS` 可作为关键实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为参照平台。**
|
||
|
||
这里有四个基础判断：
|
||
|
||
1. **研究对象是面向 AI 的实时控制基础系统**；
|
||
2. **人工智能推理在系统中承担目标负载角色**；
|
||
3. **RTOS 是关键底座，但不是全部因果的唯一承担者**；
|
||
4. **硬件条件以验证矩阵形式组织研究证据。**
|
||
|
||
本框架评估的是：当人工智能目标负载与关键保障负载共同进入系统时，基础系统如何维持控制路径、推理路径和资源路径的整体边界。
|
||
|
||
---
|
||
|
||
## 1. 问题空间：五类部署形态、三类系统负载与跨层实时性
|
||
|
||
### 1.1 五类部署形态
|
||
|
||
`T5~T1` 五类部署形态继续作为验证矩阵。
|
||
|
||
| 部署形态 | 系统角色 | 主要研究关注点 |
|
||
|---|---|---|
|
||
| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存预算 |
|
||
| T4 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS 协同、统一内存与带宽隔离 |
|
||
| T3 边缘节点 | 近源推理与控制协同节点 | 多任务并发、热稳定性、边缘协同 |
|
||
| T2 单机工作站 | 单机高密本地推理平台 | 多卡公平性、控制侧保护与资源协同 |
|
||
| T1 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点协同、系统边界与规模扩展 |
|
||
|
||
这些部署形态回答的是“在哪里验证”，而不是“什么是研究主语”。
|
||
|
||
### 1.2 三类系统负载
|
||
|
||
| 负载类型 | 定义 | 典型例子 |
|
||
|---|---|---|
|
||
| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉识别、导航规划、故障诊断 |
|
||
| 关键保障负载 | 维持安全与执行闭环的关键任务 | 周期控制、联锁、状态采集、执行输出 |
|
||
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、模型加载、通信、I/O |
|
||
|
||
### 1.3 跨层实时性问题
|
||
|
||
本框架中的“实时性”不再只指调度器和中断路径，而是至少同时涉及：
|
||
|
||
- 模型与推理阶段时间行为；
|
||
- 运行时与队列组织；
|
||
- RTOS 的关键任务保障能力；
|
||
- Linux 的生态与推理承载能力；
|
||
- Hypervisor 的隔离与资源切分；
|
||
- 总线、内存、DMA、NPU、GPU 等资源竞争结构；
|
||
- 规则兜底与异常切换机制。
|
||
|
||
---
|
||
|
||
## 2. 分层边界：三层系统问题
|
||
|
||
### 2.1 RTOS 直接控制域
|
||
|
||
这一层是 RTOS 可以直接施加机制约束的部分，包括：
|
||
|
||
- 关键任务调度；
|
||
- 中断优先级与抢占关系；
|
||
- CPU 侧线程、同步与时钟机制；
|
||
- 恢复、隔离和关键路径治理。
|
||
|
||
这一层回答的是：
|
||
|
||
> **RTOS 如何为关键保障负载建立确定性底座。**
|
||
|
||
### 2.2 推理运行域
|
||
|
||
这一层主要由模型、量化、算子、运行时和驱动共同决定，包括：
|
||
|
||
- Prefill / Decode 时延结构；
|
||
- 模型大小与量化精度；
|
||
- KV Cache、内存组织与队列行为；
|
||
- GPU/NPU 内部执行与框架调度。
|
||
|
||
这一层回答的是：
|
||
|
||
> **人工智能目标负载本身具有什么样的时间行为和资源行为。**
|
||
|
||
### 2.3 系统协同域
|
||
|
||
这一层是本框架的重点，包括：
|
||
|
||
- Linux 与 RTOS 的角色分工；
|
||
- Hypervisor 的隔离与资源划分；
|
||
- 总线、DMA、外存、统一内存与协处理器竞争治理；
|
||
- 规则兜底、安全约束与异常切换；
|
||
- 关键保障负载与人工智能目标负载之间的优先级关系。
|
||
|
||
这一层回答的是：
|
||
|
||
> **在混合系统中，整体实时性如何被建立、维持和验证。**
|
||
|
||
---
|
||
|
||
## 3. 两条主要技术路线
|
||
|
||
### 3.1 MCU 路线：静态分配、工具链与芯片协同
|
||
|
||
MCU 路线重点关注：
|
||
|
||
- 小模型、小算子与控制任务的静态编排；
|
||
- 工具链、代码生成与开发套件；
|
||
- 与芯片厂商的协同设计；
|
||
- 极小资源预算下的 AI 目标负载纳入方式。
|
||
|
||
这条路线的关键词是：
|
||
|
||
`静态分配`、`工具链`、`开发套件`、`芯片协同`
|
||
|
||
### 3.2 SoC 路线：Hybrid、Hypervisor 与整体确定性
|
||
|
||
SoC 路线重点关注：
|
||
|
||
- Linux 侧推理与 RTOS 侧控制的分工；
|
||
- Hybrid 结构从“并置”升级为“协同治理”；
|
||
- Hypervisor 的隔离、分簇和资源切分；
|
||
- 统一内存、总线、DMA、NPU/GPU 竞争治理；
|
||
- 控制与 AI 在同一系统中的整体确定性。
|
||
|
||
这条路线的关键词是：
|
||
|
||
`Hybrid`、`Hypervisor`、`隔离`、`资源治理`、`系统确定性`
|
||
|
||
---
|
||
|
||
## 4. 统一技术体系：五层技术栈与横向治理线
|
||
|
||
本框架继续保留五层技术栈表达，但其含义从“RTOS 机制展开”进一步上升为“基础系统展开”。
|
||
|
||
```
|
||
┌───────────────────────────────────────────────────────────────┐
|
||
│ L5 模型与任务语义层 │
|
||
│ 任务语义、模型结构、量化、输出约束、业务边界 │
|
||
├───────────────────────────────────────────────────────────────┤
|
||
│ L4 运行时与负载编排层 │
|
||
│ 队列、准入控制、内存池、流水线、推理框架、规则兜底接口 │
|
||
├───────────────────────────────────────────────────────────────┤
|
||
│ L3 资源抽象与系统协同层 │
|
||
│ CPU/NPU/GPU/DMA/总线/统一内存抽象、Hypervisor、资源治理 │
|
||
├───────────────────────────────────────────────────────────────┤
|
||
│ L2 基础软件控制层 │
|
||
│ RTOS、Linux、中断、调度、同步、恢复、隔离、关键路径保护 │
|
||
├───────────────────────────────────────────────────────────────┤
|
||
│ L1 硬件与互联层 │
|
||
│ MCU、SoC、加速器、缓存、总线、外存、网络互联、时钟源 │
|
||
└───────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
横向治理线包括：安全、审计、配置版本、日志证据、时间同步、可观测性、规则兜底、异常切换和 OTA / 回滚能力。
|
||
|
||
---
|
||
|
||
## 5. 研究主线：整体实时边界的建立与验证
|
||
|
||
本框架后续所有子方向都服务于同一个主命题：
|
||
|
||
> **面向 AI 的实时控制基础系统如何在人工智能目标负载进入控制闭环后，维持系统的确定性、可预测性与整体实时边界。**
|
||
|
||
围绕这个主命题，研究主线可以组织为六个方向：
|
||
|
||
1. **RTOS 直接控制域的保障机制**
|
||
2. **人工智能目标负载的时间行为建模**
|
||
3. **系统协同域的资源隔离与治理**
|
||
4. **MCU 路线的静态编排与工具链能力**
|
||
5. **SoC 路线的 Hybrid / Hypervisor 协同结构**
|
||
6. **规则兜底、异常切换与闭环安全边界**
|
||
|
||
这些方向共同服务于一个判断：
|
||
|
||
> **人工智能能力进入实时控制系统后，系统是否仍然有边界，以及这个边界由哪些机制共同构成。**
|
||
|
||
---
|
||
|
||
## 6. 评价框架：三层指标同时成立
|
||
|
||
### 6.1 人工智能目标负载指标
|
||
|
||
- `TTFT`
|
||
- `TPOT`
|
||
- 端到端响应时间
|
||
- 功能有效性
|
||
- 长时间稳定性
|
||
|
||
### 6.2 关键保障负载指标
|
||
|
||
- `deadline miss ratio`
|
||
- `P99/P99.9 jitter`
|
||
- 观测最大响应时间
|
||
- 外部接口响应时间
|
||
|
||
### 6.3 系统协同指标
|
||
|
||
- 有效吞吐
|
||
- `E/token` / `tokens/J`
|
||
- 温度、热漂移与降频行为
|
||
- 资源隔离效果
|
||
- 恢复能力与异常切换表现
|
||
|
||
因此，本框架的成功标准是：
|
||
|
||
> **人工智能目标负载、关键保障负载与系统协同三层指标同时成立。**
|
||
|
||
---
|
||
|
||
## 7. 对照关系：Linux、PREEMPT_RT、RTOS 与混合结构
|
||
|
||
后续实验与叙事可采用四类对照：
|
||
|
||
| 对照组 | 含义 | 作用 |
|
||
|---|---|---|
|
||
| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
|
||
| `O1` PREEMPT_RT Linux | 实时增强型 Linux | 观察增强型通用 OS 的边界 |
|
||
| `O2` RTOS 原生配置 | RTOS 基础路径 | 观察 RTOS 底座能力 |
|
||
| `O3` 混合基础系统配置 | Linux + RTOS + Hypervisor 或协同结构 | 观察整体协同路径的收益与代价 |
|
||
|
||
这条对照线的重点，不再只是比较“谁更快”，而是比较：
|
||
|
||
- 谁更能维持关键保障负载边界；
|
||
- 谁更能承受 AI 目标负载进入后的资源竞争；
|
||
- 谁更能形成可解释、可复现、可治理的整体系统秩序。
|
||
|
||
---
|
||
|
||
## 8. 预期成果
|
||
|
||
1. **问题定义层**：人工智能能力进入实时控制系统后的基础系统问题定义；
|
||
2. **分析层**：RTOS 直接控制域、推理运行域与系统协同域的边界划分方法；
|
||
3. **机制层**：面向 Hybrid / Hypervisor / 资源治理 / 规则兜底的基础系统机制；
|
||
4. **方法层**：覆盖 `T5~T1` 的统一验证矩阵与对照方法；
|
||
5. **产业层**：从 RTOS 平台叙事上升到基础系统叙事的合作与产品路线；
|
||
6. **论文层**：面向实时系统、嵌入式系统和低功耗系统方向的系统化论文与报告。
|