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.
78 lines
2.7 KiB
Markdown
78 lines
2.7 KiB
Markdown
# SoC路线：Hybrid与Hypervisor协同
|
|
|
|
## 1. 主题定位
|
|
|
|
SoC 路线是框架2的核心主战场。这里最直接体现会议中的判断：人工智能进入实时控制系统后，最现实的结构不是让 RTOS 独自承接一切，而是让 Linux、RTOS、Hypervisor 与异构协处理器形成可治理的混合基础系统。
|
|
|
|
## 2. 为什么 SoC 路线最关键
|
|
|
|
设备端 SoC 同时具有以下特征：
|
|
|
|
- 需要 Linux 承接 AI 生态和推理框架；
|
|
- 需要 RTOS 承接关键控制与执行闭环；
|
|
- 统一内存和异构协处理器使资源竞争非常明显；
|
|
- 设备级散热、功耗和体积限制比服务器更刚性；
|
|
- 更接近真实产业落地场景。
|
|
|
|
因此，SoC 路线最能体现“基础系统主语”。
|
|
|
|
## 3. Hybrid 结构为什么仍然重要
|
|
|
|
会议并没有否定 Hybrid，反而强调它是当前最现实的路径之一。
|
|
Hybrid 的现实价值在于：
|
|
|
|
- 保留 Linux 的推理生态；
|
|
- 保留 RTOS 的控制与保障能力；
|
|
- 让 AI 目标负载与关键保障负载可以在不同控制层上运行；
|
|
- 为后续 Hypervisor 和资源治理留出结构空间。
|
|
|
|
但框架2不再接受“传统 Hybrid 只求共存”的写法，而要求把它升级为协同治理结构。
|
|
|
|
## 4. Hypervisor 在 SoC 路线中的角色
|
|
|
|
Hypervisor 使 SoC 路线从“双系统并置”走向“可治理混合系统”。它重点承担：
|
|
|
|
- 核心与资源切分；
|
|
- 中断与设备访问边界控制；
|
|
- 共享内存与通信路径组织；
|
|
- 异常隔离与恢复。
|
|
|
|
如果没有 Hypervisor 或等价机制，很多 SoC 路线的协同边界很难稳定复现。
|
|
|
|
## 5. 核心研究问题
|
|
|
|
### 5.1 推理与控制如何分层
|
|
|
|
后续研究需要回答：
|
|
|
|
- 哪些 AI 任务保留在 Linux 侧；
|
|
- 哪些控制任务保留在 RTOS 侧；
|
|
- 控制与推理之间通过什么接口通信；
|
|
- 在延迟、异常和过载条件下如何切换策略。
|
|
|
|
### 5.2 统一内存与总线竞争如何治理
|
|
|
|
SoC 路线中最容易被低估的问题包括：
|
|
|
|
- CPU 与 NPU/GPU 的统一内存争抢；
|
|
- DMA 传输对控制路径的污染；
|
|
- 模型加载与设备 I/O 共享带宽；
|
|
- 缓存与总线冲突对尾延迟的影响。
|
|
|
|
这部分是 SoC 路线区别于纯 RTOS 叙事的关键证据。
|
|
|
|
### 5.3 设备级受限条件如何影响系统边界
|
|
|
|
SoC 路线必须同时面对：
|
|
|
|
- 功耗预算；
|
|
- 散热与封装条件；
|
|
- 设备体积与部署空间；
|
|
- 软件栈和驱动闭源限制。
|
|
|
|
因此，它天然也是框架2中“小型化与低功耗”方向最强的承载层。
|
|
|
|
## 6. 当前结论
|
|
|
|
> **SoC 路线不是 RTOS 课题的附属场景，而是“面向 AI 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**
|