156 lines
7.2 KiB
Markdown
156 lines
7.2 KiB
Markdown
# 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 是否同时保持了人工智能目标负载的时效性和功能有效性；
|
||
- 吞吐损失是否在可接受范围；
|
||
- 能耗和热稳定性是否同步改善或至少可解释；
|
||
- 结论是否能跨部署形态成立；
|
||
- 优势边界和失败边界是否都被讲清楚。
|
||
|
||
## 最后一句话
|
||
|
||
这个项目的本质是：
|
||
|
||
> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**
|