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.
402 lines
14 KiB
Markdown
402 lines
14 KiB
Markdown
# RTOS与AI实时控制基础系统课题讨论
|
|
|
|
## 1. 主题定位
|
|
|
|
这部分讨论是整场会议中最接近课题主线、研究对象重定义和合作方向重构的核心内容。会议虽然从翼辉与 RTOS 相关问题切入，但最终形成的判断已经明显超出了“RTOS 是否更强”这一层，转向了一个更高层次的问题：
|
|
|
|
> **当人工智能能力进入实时控制系统之后，真正需要研究和构建的对象，不再只是单一 RTOS，而是面向 AI 的实时控制基础系统。**
|
|
|
|
这不是一句包装性口号，而是对研究主语、技术路线、合作方式和产业定位的重新组织。
|
|
|
|
## 2. 会议形成的核心结论
|
|
|
|
会议中稳定下来的，不是某一个局部技术答案，而是四项根本判断。
|
|
|
|
### 2.1 大模型实时性不是单一 RTOS 问题
|
|
|
|
人工智能目标负载进入系统之后，系统面对的问题来自多层要素共同作用，包括：
|
|
|
|
- 模型结构与量化方式；
|
|
- 推理框架与运行时队列；
|
|
- RTOS 与 Linux 的角色分工；
|
|
- Hypervisor 与资源隔离结构；
|
|
- 芯片、总线、内存、DMA、NPU、GPU 等硬件资源形态；
|
|
- 规则兜底、异常切换和安全边界机制。
|
|
|
|
因此，会议给出的更准确判断是：
|
|
|
|
> **人工智能进入实时控制系统之后，系统需要解决的是跨模型、跨运行时、跨基础软件和跨体系结构的整体实时性问题。**
|
|
|
|
### 2.2 研究主语要从 RTOS 上移到基础系统
|
|
|
|
会议没有否定 RTOS 的价值，但明确反对继续把全部实时性问题都压到 RTOS 身上。
|
|
RTOS 仍然是关键保障负载的确定性底座，但不再适合作为所有问题的唯一承担者。
|
|
|
|
更合适的研究对象应当写成：
|
|
|
|
- 实时基础系统；
|
|
- 面向 AI 的实时控制基础系统；
|
|
- 面向 AI 的实时控制系统体系结构。
|
|
|
|
### 2.3 技术路线天然分成 MCU 路线与 SoC / 边侧路线
|
|
|
|
会议没有把所有场景压成同一套逻辑，而是明确区分了两类问题结构：
|
|
|
|
- `MCU` 路线：更强调静态资源组织、开发工具链、芯片协同和开发套件；
|
|
- `SoC / 边侧` 路线：更强调 Linux、RTOS、Hypervisor 与异构资源共同构成的混合基础系统。
|
|
|
|
因此，更接近原意的概括不是“MCU 让 RTOS 多做点事、边侧上 Hypervisor”，而是：
|
|
|
|
> **MCU 路线主要解决静态编排与工具链协同问题，SoC / 边侧路线主要解决 Hybrid、Hypervisor 与系统协同问题，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
|
|
|
|
### 2.4 翼辉方向需要从 RTOS 产品叙事转向基础系统叙事
|
|
|
|
会议对翼辉这类公司的建议也比较明确：
|
|
|
|
- 不再只讲 RTOS 厂商身份；
|
|
- 不再把“适配了什么系统”作为核心叙事；
|
|
- 转向“面向 AI 的实时控制基础系统供应方”；
|
|
- 用 5 到 10 年技术路线替代短周期适配叙事。
|
|
|
|
## 3. 基础系统视角下的问题结构
|
|
|
|
为了避免后续再把所有问题混在一起，会议内容更适合被整理成三个层次。
|
|
|
|
### 3.1 RTOS 直接控制域
|
|
|
|
这一层对应 RTOS 可以直接施加机制约束的范围，主要包括：
|
|
|
|
- 周期任务与关键任务调度；
|
|
- 中断优先级、抢占关系和关键路径治理；
|
|
- CPU 侧线程、同步机制与时钟管理；
|
|
- 恢复、隔离和关键任务保护机制；
|
|
- 对部分共享资源策略的直接控制接口。
|
|
|
|
这一层回答的是：
|
|
|
|
> **RTOS 如何为关键保障负载建立确定性底座。**
|
|
|
|
### 3.2 推理运行域
|
|
|
|
这一层主要由模型、量化、算子、框架和运行时共同决定，主要包括：
|
|
|
|
- 模型大小与数值精度；
|
|
- Prefill / Decode 的时延分布；
|
|
- KV Cache、工作区和内存组织方式；
|
|
- 推理框架队列、批处理与上下文管理；
|
|
- GPU/NPU 内部执行与驱动接口行为。
|
|
|
|
这一层回答的是：
|
|
|
|
> **人工智能目标负载本身具有什么样的时间行为、资源行为和可优化空间。**
|
|
|
|
### 3.3 系统协同域
|
|
|
|
这一层是会议真正抬起来的新重点，主要包括：
|
|
|
|
- Linux 与 RTOS 的角色分工；
|
|
- Hypervisor 的隔离与资源划分；
|
|
- 总线、DMA、统一内存、外存和协处理器竞争治理；
|
|
- 规则兜底、异常切换与安全边界；
|
|
- 关键保障负载与人工智能目标负载之间的优先级结构。
|
|
|
|
这一层回答的是：
|
|
|
|
> **在混合系统中，整体实时性如何被建立、维持和验证。**
|
|
|
|
## 4. MCU 路线与 SoC / 边侧路线的真实含义
|
|
|
|
### 4.1 MCU 路线
|
|
|
|
会议对 `MCU` 方向的判断非常集中。
|
|
更准确的理解不是“MCU 端让 RTOS 多做一些事”，而是：在极小资源预算场景中，问题本身就不适合按高动态运行时思维组织。
|
|
|
|
这一方向通常具有以下特点：
|
|
|
|
- 动态空间极小；
|
|
- 内存和算力预算刚性；
|
|
- 控制任务和外设链路优先级极高；
|
|
- 更适合小模型、小算子和静态工作流；
|
|
- 更依赖离线配置、静态分配和代码生成。
|
|
|
|
因此，会议原意更接近：
|
|
|
|
> **MCU 路线中 RTOS 的意义更接近静态组织底座、可分析执行环境和开发工具链的一部分，而不是承接高动态推理运行时的主体。**
|
|
|
|
### 4.2 SoC / 边侧路线
|
|
|
|
`SoC / 边侧` 路线的判断也需要严格校准。
|
|
它并不是一句“边侧用 Hypervisor”就能概括的。会议真正强调的是：设备端 SoC 会天然同时存在 Linux 生态需求和实时控制需求，因此更现实的路径，是构造一个能够治理混合结构的基础系统。
|
|
|
|
这类场景通常同时具有以下特征：
|
|
|
|
- 需要 Linux 承接 AI 生态和推理框架；
|
|
- 需要 RTOS 承接关键控制与实时保障；
|
|
- 需要在同一 `SoC`、同一块板卡上处理统一内存和异构设备竞争；
|
|
- 还要同时面对设备级功耗、散热、体积和驱动限制。
|
|
|
|
会议对 `Hypervisor` 的态度是明确肯定的，但没有把它讲成单独答案。
|
|
更准确的理解是：
|
|
|
|
- `Hypervisor` 首先是一种隔离和资源切分方法；
|
|
- 它可以帮助划分 Linux 与 RTOS 的边界；
|
|
- 但它本身不能自动消除统一内存、总线、DMA、缓存和协处理器带来的全部竞争问题。
|
|
|
|
因此，这一路线真正保留并强化的是：
|
|
|
|
> **面向 AI 实时控制系统的升级版 Hybrid，也就是能够处理分工、隔离、资源仲裁、规则兜底和异常切换的混合基础系统结构。**
|
|
|
|
## 5. 建议的工作方式
|
|
|
|
这一主题不适合按“先写论文、再找技术点”的方式推进，而更适合按“先完成问题重定义，再完成路线定义，再组织预研验证”的方式推进。
|
|
|
|
### 5.1 先做课题重定义
|
|
|
|
第一步不是急于给出实现方案，而是把以下问题写清楚：
|
|
|
|
- 研究主语为什么要从 RTOS 上移到基础系统；
|
|
- MCU 路线和 SoC / 边侧路线为什么不能混写；
|
|
- RTOS 直接控制域、推理运行域、系统协同域如何分层；
|
|
- Hybrid、Hypervisor、规则兜底在系统中的位置是什么。
|
|
|
|
这一阶段的产物应当是：
|
|
|
|
- 一份课题重定义稿；
|
|
- 一份路线分层说明稿；
|
|
- 一份面向合作方的概念阐释稿。
|
|
|
|
### 5.2 再做技术路线分解
|
|
|
|
在问题定义清楚之后，再把路线拆成两个主方向：
|
|
|
|
1. `MCU` 路线
|
|
重点看静态编排、工具链、开发套件、芯片协同。
|
|
2. `SoC / 边侧` 路线
|
|
重点看 Linux / RTOS / Hypervisor 分工、Hybrid 升级、统一内存与总线竞争治理。
|
|
|
|
这一阶段的产物应当是：
|
|
|
|
- 一份 MCU 路线稿；
|
|
- 一份 SoC / Hybrid 路线稿；
|
|
- 一份系统协同与规则兜底说明稿。
|
|
|
|
### 5.3 再组织预研验证
|
|
|
|
路线分解完成后，再进入原型和预研阶段。
|
|
这一阶段不是全面铺开，而应选典型切口验证关键判断，例如：
|
|
|
|
- 小模型与控制任务的静态编排；
|
|
- Linux 与 RTOS 分工下的控制链路保护；
|
|
- Hypervisor 隔离下的统一内存竞争；
|
|
- 模型输出与规则兜底共同构成的闭环。
|
|
|
|
### 5.4 最后再回收进主课题框架
|
|
|
|
只有在以上三步形成稳定判断之后，才适合把内容系统回收到主课题框架、论文规划和合作提案中。
|
|
|
|
## 6. 建议的推进步骤
|
|
|
|
### 6.1 第一步：形成概念共识
|
|
|
|
目标是对内把“RTOS 课题”与“基础系统课题”的边界说清楚。
|
|
这一阶段应完成：
|
|
|
|
- 会议判断整理；
|
|
- 原话核对；
|
|
- 关键词统一；
|
|
- 课题候选命名收敛。
|
|
|
|
### 6.2 第二步：形成路线稿
|
|
|
|
目标是把两个方向彻底拆开。
|
|
这一阶段应完成：
|
|
|
|
- MCU 路线稿；
|
|
- SoC / 边侧路线稿；
|
|
- Hybrid / Hypervisor 路线稿；
|
|
- 系统协同域说明稿。
|
|
|
|
### 6.3 第三步：形成合作版材料
|
|
|
|
目标是让外部合作方能够看懂“为什么值得做、准备怎么做、各方做什么”。
|
|
这一阶段应完成：
|
|
|
|
- 面向合作方的路线总述；
|
|
- 阶段性合作方式说明；
|
|
- 预研问题清单；
|
|
- 交付物框架。
|
|
|
|
### 6.4 第四步：组织预研与验证
|
|
|
|
目标是围绕少数关键问题开展验证。
|
|
这一阶段应完成：
|
|
|
|
- 板级或 SoC 原型验证；
|
|
- 小模型与控制任务共存实验；
|
|
- 混合系统资源竞争实验；
|
|
- 规则兜底与异常切换实验。
|
|
|
|
## 7. 各方责任与工作的边界
|
|
|
|
这一主题如果要继续推进，必须把责任和边界说清楚，否则很容易重新落回“谁都在提想法，没人真正推进”的状态。
|
|
|
|
### 7.1 唐老师团队
|
|
|
|
适合承担：
|
|
|
|
- 对外合作牵头；
|
|
- 场景与需求整合；
|
|
- 课题框架转译；
|
|
- 合作节奏把控；
|
|
- 外部沟通和阶段汇报组织。
|
|
|
|
唐老师团队更适合处在“前端牵头、方案整合、合作推进”的位置。
|
|
|
|
### 7.2 罗老师团队
|
|
|
|
适合承担：
|
|
|
|
- 研究主语与问题定义把关；
|
|
- 方法论抽象；
|
|
- 路线分层与概念边界校准；
|
|
- 研究价值、学术表达和系统建模方向的判断。
|
|
|
|
罗老师团队更适合处在“高层框架、方法论和方向判断”的位置。
|
|
|
|
### 7.3 翼辉或对应产业团队
|
|
|
|
适合承担：
|
|
|
|
- RTOS、工具链、板级环境和基础软件条件说明；
|
|
- MCU 路线和 SoC 路线的工程条件提供；
|
|
- Hybrid / Hypervisor / 板级验证路径提供；
|
|
- 原型实现与工程可行性反馈。
|
|
|
|
产业团队不负责课题理论抽象，但负责把路线落到真实平台条件上。
|
|
|
|
### 7.4 项目组或工程支撑团队
|
|
|
|
适合承担：
|
|
|
|
- 会议整理与材料撰写；
|
|
- 路线稿、合作稿和阶段文档整理；
|
|
- 预研验证组织；
|
|
- 图表、报告和证据归档。
|
|
|
|
这一角色更偏执行支撑与资料组织。
|
|
|
|
## 8. 工作边界
|
|
|
|
### 8.1 这项工作当前首先是“定义工作”，不是全面工程实现
|
|
|
|
会议形成的第一价值，是重新定义问题和路线。因此现阶段不宜直接把重点放在“大规模开发”上。
|
|
|
|
### 8.2 当前重点是“搭框架”，不是“宣称已经解决”
|
|
|
|
无论是 MCU 路线还是 SoC / Hybrid 路线，当前更适合先形成稳定的问题定义、路线定义和验证问题，而不是过早给出“完整解决方案”叙事。
|
|
|
|
### 8.3 学术问题与产业问题需要并行，但不能混写
|
|
|
|
学术上要回答：
|
|
|
|
- 问题定义是否成立；
|
|
- 三层边界如何组织；
|
|
- 经典实时理论如何扩展。
|
|
|
|
产业上要回答：
|
|
|
|
- 产品路线怎么讲；
|
|
- 哪些工程条件已经具备；
|
|
- 预研从哪里切入。
|
|
|
|
这两类问题必须关联，但不能混成一篇只讲口号的材料。
|
|
|
|
## 9. 合作推进方式
|
|
|
|
这一主题适合采用“规划先行、预研跟进、原型验证收口”的推进方式。
|
|
|
|
### 9.1 第一阶段：规划与定义
|
|
|
|
重点是：
|
|
|
|
- 统一研究主语；
|
|
- 统一路线分层；
|
|
- 统一合作表达；
|
|
- 形成首轮课题和合作框架稿。
|
|
|
|
这一阶段的交付物应以定义稿、路线稿和合作稿为主。
|
|
|
|
### 9.2 第二阶段：预研与技术论证
|
|
|
|
重点是：
|
|
|
|
- 抽取少数关键问题做原型验证；
|
|
- 形成系统协同和控制闭环的实证材料；
|
|
- 把 MCU 路线与 SoC 路线分别落到真实平台。
|
|
|
|
这一阶段的交付物应以预研报告、实验记录和系统草案为主。
|
|
|
|
### 9.3 第三阶段：联合课题与对外输出
|
|
|
|
重点是：
|
|
|
|
- 回收进正式课题框架；
|
|
- 形成面向项目、论文和合作申请的材料；
|
|
- 根据需要向白皮书、论文和对外交流稿扩展。
|
|
|
|
## 10. 对当前研究仓库的直接影响
|
|
|
|
这场会议对当前仓库至少带来六项直接影响。
|
|
|
|
### 10.1 研究主语需要继续上移
|
|
|
|
当前仓库已经从“硬件主语”转到“RTOS 主语”，而会议进一步提示：下一步更值得推进的是从“RTOS 主语”继续上移到“基础系统主语”。
|
|
|
|
### 10.2 `T5~T1` 验证矩阵仍然有效
|
|
|
|
会议没有否定验证矩阵，而是强化了一个更清晰的判断：
|
|
|
|
- `T5/T4/T3` 更适合作为系统研究主窗口；
|
|
- `T2/T1` 作为 RTOS 优势主战场的意义较弱；
|
|
- 但作为 AI 负载和系统协同的参照窗口仍然有价值。
|
|
|
|
### 10.3 需要把“系统协同域”单独写出来
|
|
|
|
当前仓库的五层技术栈已经是很好的起点，但后续需要明确写出：
|
|
|
|
- RTOS 可控域；
|
|
- 模型与运行时域；
|
|
- Linux、Hypervisor、芯片与资源治理共同构成的系统协同域。
|
|
|
|
### 10.4 “实时性”需要从纯 OS 叙事中适度抽离
|
|
|
|
后续文档更适合写成：
|
|
|
|
- 实时控制系统中的 AI 能力；
|
|
- 引入 AI 后的整体实时性问题；
|
|
- 基础系统如何维持控制路径与 AI 路径的统一时间边界。
|
|
|
|
### 10.5 低功耗、小型化方向会自然进入主线
|
|
|
|
一旦研究对象上移到基础系统，低功耗、小型化、片上资源预算这些问题就不再只是应用专题，而会自然进入主线。
|
|
|
|
### 10.6 后续课题命名需要重新评估
|
|
|
|
如果沿着这次会议的判断继续推进，候选命名更适合向以下方向收敛：
|
|
|
|
- 面向 AI 的实时控制基础系统；
|
|
- 人工智能目标负载进入实时控制系统后的基础系统保障机制；
|
|
- 面向 AI 实时控制系统的嵌入式体系结构与基础系统研究。
|
|
|
|
## 11. 当前结论
|
|
|
|
这场会议最重要的价值，不是提供了一个立即可落地的单点技术答案，而是把观察视角整体抬高了一层。
|
|
|
|
会议最终给出的判断可以概括为：
|
|
|
|
> **人工智能进入实时控制系统之后，真正值得研究和构建的对象，不再只是单一 RTOS，而是一个围绕实时性、控制性、推理性和体系结构协同展开的基础系统。**
|
|
|
|
如果进一步压缩成最贴近会议原意的一句话，可以写成：
|
|
|
|
> **MCU 路线主要走静态编排、工具链与芯片协同，SoC / 边侧路线主要走 Linux + RTOS + Hypervisor + 升级版 Hybrid 的系统协同，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
|