rtos_llm_opt/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/06-基础设备与算力基础.md

面向AI的实时控制基础系统基础设备与算力基础

1. 文档目的

本文用于说明框架2中的验证矩阵如何组织。这里继续保留 T5~T1 五类部署形态，但其作用是“验证矩阵”，不是研究主语。本文件同时把 MCU 路线 与 SoC 路线 显式放进设备与算力组织逻辑中。

2. 验证矩阵的组织原则

2.1 三条组织原则

1. 部署形态优先于硬件型号
   先回答系统在什么位置运行，再回答用什么设备验证。
2. 技术路线优先于单点性能
   先区分 MCU 路线与 SoC 路线，再讨论容量、功耗和算力差异。
3. 基础系统问题优先于纯吞吐问题
   优先选择能暴露控制路径、推理路径与资源竞争关系的设备与场景。

2.2 五类部署形态

部署形态	系统角色	主要关注点
T5 控制端	极紧资源预算下的控制节点	静态编排、低功耗、极小内存
T4 设备端 SoC	设备本体内的异构平台	Linux/RTOS/Hypervisor 协同、统一内存竞争
T3 边缘节点	设备附近的近源协同节点	多任务并发、热稳定性、边缘协同
T2 单机工作站	单机高密本地推理平台	多卡公平性、关键任务保护与系统协同
T1 服务器 / 集群	任务关键场景中的分布式协同平台	跨节点边界、编排与规模扩展

3. 两条技术路线在矩阵中的位置

3.1 MCU 路线

MCU 路线主要对应 T5，重点设备类型包括：

• MCU 控制器；
• 轻量控制盒；
• 极小资源预算下的端侧控制节点。

它承担的问题是：

• 小模型与控制任务如何静态编排；
• 芯片工具链和开发套件如何支撑部署；
• 极小内存、功耗与外设约束下能否维持闭环。

3.2 SoC 路线

SoC 路线主要对应 T4，并向 T3 延伸。重点设备类型包括：

• 工业 SoC；
• 车规 SoC；
• 设备端 AI 模组；
• 边缘异构平台。

它承担的问题是：

• Linux 与 RTOS 的协同关系；
• Hypervisor 的隔离与资源切分；
• 统一内存、DMA、总线与 NPU/GPU 竞争；
• 设备级功耗、散热与体积约束下的整体确定性。

4. 当前设备锚点

4.1 已有核心平台

平台	对应位置	当前价值
RK3588 16 GB	T4-L / 受限配置可模拟 T5-H	设备端 SoC 主样例；同时可承接小型化与低功耗观察
4×V100 服务器	T2-L	单机高密推理与关键保障负载保护的对照窗口

4.2 条件扩展平台

平台方向	对应位置	主要价值
RK3568 / 同类控制盒	T5-L	MCU / 轻量控制路线主验证窗口
RK3576 / 同类设备	T5-M 或 T4-L 衔接档	中间资源档位与工具链观察窗口
Jetson / IGX / 工控边缘节点	T3 / T4-M	SoC 向边缘协同扩展的窗口
更高端单机多卡或多节点平台	T2-H / T1	观察规模扩展和协同边界收窄区间

5. 为什么框架2仍然保留 T2/T1

框架2并不把 T2/T1 当作 RTOS 优势的天然主战场，但仍保留其验证价值：

• 它们可以暴露 AI 目标负载的运行时复杂性；
• 它们可以观察关键保障负载在高密度 AI 负载下是否仍可被保护；
• 它们可以为系统协同域提供资源竞争、队列行为和规模边界证据。

因此，T2/T1 在框架2中的角色更接近“上界参照窗口”，而不是研究主语。

6. 当前建议

对框架2而言，最值得优先强化的设备与算力主线是：

1. T5 MCU / 控制端路线
2. T4 设备端 SoC 路线
3. T3 边缘协同路线

这三类场景最能体现“基础系统主语”与“系统协同边界”。

7. 当前结论

框架2中的设备与算力组织方式，不是为了堆出更大的硬件谱系，而是为了在不同资源条件下，把 MCU 路线与 SoC 路线的基础系统问题显式暴露出来。