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

RTOS直接控制域

1. 主题定位

在框架2中，RTOS 不再被写成全部系统问题的唯一承担者，但它仍然是关键保障负载确定性底座的核心组成部分。本文件用于明确：哪些问题属于 RTOS 可以直接控制和分析的范围，哪些问题不应继续归因到 RTOS 身上。

2. 直接控制域的边界

RTOS 直接控制域主要包括：

• 周期任务、关键任务与后台任务的调度关系；
• 中断优先级、抢占路径和线程化中断机制；
• CPU 侧线程、同步互斥、时钟与定时器；
• 内存锁定、关键缓冲区预分配与恢复机制；
• 关键任务隔离、核心绑定和关键路径保护；
• 对共享资源治理接口的直接约束能力。

这一层回答的是：

RTOS 如何在人工智能目标负载进入系统后，持续保护关键保障负载的时间边界。

3. 核心研究问题

3.1 关键任务如何不被人工智能目标负载拖垮

当人工智能目标负载与关键保障负载并存时，RTOS 的首要任务不是提高模型吞吐，而是确保：

• 周期控制任务不失去截止期；
• 中断链路不被模型加载、日志、I/O 和推理提交路径污染；
• 恢复路径在异常条件下仍然可触发；
• 控制输出始终保留优先权。

3.2 哪些资源竞争能够由 RTOS 直接治理

RTOS 可以直接治理的通常是：

• CPU 时间分配；
• 抢占关系；
• 中断响应顺序；
• 同步冲突；
• 关键路径上的内核对象与内存使用方式。

RTOS 不能单独决定的，则包括 GPU/NPU 内部算子执行、显存流水线、驱动内部队列与片上总线物理冲突。这些内容必须和系统协同域一起讨论。

4. 关键机制

4.1 调度与抢占

关键保障负载应继续保持硬优先级或等价的刚性优先级结构。人工智能目标负载相关线程、提交路径和后台服务线程必须被限制在不会破坏关键任务的优先级层次中。

4.2 中断与关键路径治理

模型加载、设备中断、网络和存储路径都可能拉长关键路径。后续研究应重点观察：

• 哪些中断必须线程化；
• 哪些中断应固定到非关键核；
• 哪些设备中断会污染关键任务核；
• 推理提交和结果回收链路是否会引发优先级倒置。

4.3 恢复与隔离

当推理链路失稳、超时或内存耗尽时，RTOS 直接控制域需要承担：

• 关键任务不受波及的隔离；
• 降级模式触发；
• 任务重启与恢复；
• 对控制回路的兜底保持。

5. 评价重点

这一层的核心指标包括：

• deadline miss ratio
• P99/P99.9 jitter
• 观测最大响应时间
• 外部接口响应时间
• 恢复时间与异常切换开销

这些指标构成 RTOS 直接控制域的主证据，不应和 GPU/NPU 内部执行指标混为一体。

6. 与其他层的关系

• 与 推理运行域 的关系：RTOS 负责保护关键路径，推理运行域负责描述 AI 目标负载本身的时间行为；
• 与 系统协同域 的关系：RTOS 负责可直接治理的部分，系统协同域负责 Linux、Hypervisor 和异构资源共同造成的整体边界问题。

7. 当前结论

框架2并没有削弱 RTOS 的价值，而是把 RTOS 的价值说得更准确：

RTOS 是关键保障负载的确定性底座，是人工智能进入实时控制系统后仍能维持秩序的直接控制层。