9680329b3b
revert docs: 完善三套实时性研究框架与验证方案 (#3) ## 改动内容 - 完善并提交“项目框架1：基于 RTOS 的五类场景 AI 实时性研究”。 - 新增“项目框架2：面向机器人大小脑异构系统的实时保障研究”。 - 新增“项目框架3：MCU 与资源受限 SoC 的 AI 实时性与低功耗研究”。 - 新增 RTOS–Linux–Hypervisor 边缘并行架构说明。 - 新增调整后的研究问题与验证建议，明确 RTOS、系统实时性与大模型低时延的边界。 ## 验证 - 已同步上游 `main`，源分支基于最新上游历史继续提交。 - `git diff --cached --check` 通过。 - 已检查提交范围，未加入凭据、令牌或临时文件。 - 远端分支提交已核对为 `b7863721fe906c0fa6a5e841599dd276a579d679`。 ## 建议重点审查 - 三套框架是否应作为相互独立、可并列选择的研究路线。 - 是否充分区分工业实时性、AI 推理低时延与端到端系统实时性。 - 机器人大小脑分域、Hypervisor 隔离及 MCU 资源预算的实验指标是否可落地。 --------- Co-authored-by: Mo1s <1194302708@qq.com> Reviewed-on: #3 Co-authored-by: moyixin <15971501952@163.com>
2.3 KiB
2.3 KiB
MCU路线：静态分配与工具链协同
1. 主题定位
MCU 路线并不是“把大模型缩小以后放进 MCU”这么简单。在框架2中，MCU 路线代表的是另一类完全不同的问题结构：资源极端受限、动态空间极小、工具链和静态编排比在线调度策略更重要。
2. MCU 路线的系统特征
这一路线通常具有以下特点：
- 可用内存极小；
- 时钟和算力预算刚性；
- 外设和控制链路优先级极高；
- 更适合小模型、小算子和静态工作流；
- 更依赖芯片 SDK、代码生成工具和开发套件。
因此，MCU 路线更接近“静态可分析系统中的 AI 能力纳入问题”。
3. 核心研究问题
3.1 小模型如何进入静态编排体系
MCU 路线重点不是追求通用大模型能力，而是研究：
- 哪些轻量模型可以被稳定纳入控制系统；
- 小模型、小算子与控制任务如何离线编排；
- 预分配、静态内存池和固定执行窗口如何设计。
3.2 工具链为什么比单点机制更重要
在 MCU 路线上，真正决定工程落地效率的常常不是调度策略，而是：
- 模型裁剪与转换工具；
- 自动代码生成能力；
- 内存预算与部署检查工具；
- 芯片级软件开发套件。
因此，MCU 路线天然更强调“工具链能力”。
3.3 芯片协同如何进入研究主线
对于 MCU 场景，芯片规格本身就会限制可用模型、缓冲区与时延上界。后续研究需要回答：
- 哪些 AI 需求会反向定义 MCU 和端侧芯片规格；
- 哪些片上资源是决定性瓶颈；
- 开发套件如何把这些约束显式化。
4. 评价重点
MCU 路线重点观察：
- 关键保障负载能否稳定维持；
- 小模型能否在固定资源预算中运行；
- 工具链是否能给出可分析、可复现的部署边界；
- 功耗、体积和散热预算是否同时满足。
5. 与框架2的关系
MCU 路线主要对应 T5 控制端，也是框架2中最能体现“小型化、低功耗、工具链协同”特征的部分。它为整个基础系统课题提供了一个约束极强、边界清晰的验证窗口。
6. 当前结论
MCU 路线的主问题不是“大模型如何跑进去”，而是人工智能能力如何在极端受限条件下，被静态、可分析地纳入实时控制系统。