# 面向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 路线的基础系统问题显式暴露出来。**