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 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**
|