rtos_llm_opt/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/03-系统协同域.md

系统协同域

1. 主题定位

系统协同域是框架2相对框架1最大的变化之一。它不再把问题停留在“RTOS 是否更强”，而是直接讨论：当 Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU、GPU 和规则兜底机制共同存在时，整体实时性如何被建立、维持和验证。

2. 为什么系统协同域是主问题

会议中最关键的判断之一是：人工智能进入实时控制系统后的真实问题，已经超出了单一操作系统边界。原因在于：

• 推理生态通常离不开 Linux；
• 关键保障负载需要 RTOS 或等价实时控制底座；
• 设备端 SoC 常常采用统一内存和异构协处理器；
• Hypervisor 与隔离机制直接影响资源边界；
• 规则兜底与安全约束必须与模型输出共同工作。

因此，系统协同域回答的是：

在混合结构中，整体秩序如何形成。

3. 核心问题

3.1 Linux 与 RTOS 如何分工

Linux 更适合承担：

• 推理框架与模型生态；
• 容器、服务和工具链支持；
• 非关键路径的 AI 相关运行任务。

RTOS 更适合承担：

• 关键保障负载；
• 控制闭环中的刚性时间边界；
• 关键路径上的确定性治理。

系统协同域的核心，不是让两者彼此替代，而是让两者分工清楚、边界稳定。

3.2 Hypervisor 在这里起什么作用

Hypervisor 不是附属选项，而是重要研究对象之一。它至少影响：

• 核心隔离和资源切分；
• 中断路由和设备访问边界；
• 共享内存与通信路径；
• 异常传播与恢复策略。

在设备端 SoC 和边缘节点上，Hypervisor 往往是把“共存”升级为“可治理共存”的关键层。

3.3 异构资源竞争如何进入系统分析

在 SoC 和边缘节点上，整体边界往往由以下竞争共同决定：

• CPU 与 NPU/GPU 的统一内存争用；
• DMA 与 CPU 访存冲突；
• 总线与缓存竞争；
• 模型加载与控制 I/O 共享带宽；
• 后台服务与关键任务共享中断和核资源。

这些问题不能只在驱动层或 RTOS 层单独解释，必须进入系统协同域。

4. 关键机制

4.1 资源隔离

后续研究应重点观察：

• CPU 核和关键任务核是否可隔离；
• 设备中断是否可隔离；
• 共享内存和 DMA 缓冲是否可限定边界；
• 模型提交路径是否会挤占控制路径资源。

4.2 协同治理

协同治理关注的是：

• 推理与控制如何分层；
• 哪些事件由 Linux 负责，哪些由 RTOS 负责；
• 资源冲突发生时谁拥有优先权；
• 发生过载和异常时系统如何降级与恢复。

4.3 证据组织

系统协同域的证据不能只看某一个线程或某一个服务，而需要同时观察：

• 人工智能目标负载层；
• 关键保障负载层；
• 系统协同层。

只有三层指标同时成立，才能说明协同结构是有效的。

5. 对照方式

框架2的主对照建议采用：

• O0 普通 Linux
• O1 PREEMPT_RT Linux
• O2 RTOS 原生配置
• O3 混合基础系统配置

其中 O3 不再只是附属架构，而是系统协同域的主实验路径之一。

6. 当前结论

框架2真正抬升的，不只是标题口径，而是研究主线本身：

系统协同域使项目从“RTOS 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。