forked from eaiadmin/rtos_llm_opt
208 lines
9.2 KiB
Markdown
208 lines
9.2 KiB
Markdown
# 调整后研究问题与验证建议
|
||
|
||
## 1. 调整目的
|
||
|
||
本文将最新方向意见转化为可执行的研究问题和验证建议。它不替换现有实验设计，而用于指导下一轮方案收敛：主线从覆盖 `T1~T5` 的 RTOS 大模型统一评测，转向 MCU/资源受限 SoC 的 AI 实时干扰，以及边缘侧 RTOS/Linux 分域系统的整体实时保障。
|
||
|
||
## 2. 建议的研究范围
|
||
|
||
### 2.1 核心范围
|
||
|
||
- MCU 或资源受限 SoC 上，AI 与周期控制、采集和通信共存；
|
||
- 边缘平台上，RTOS 控制域与 Linux 推理域并行运行；
|
||
- CPU、内存、缓存、总线、中断、DMA、加速器、功耗和热形成的系统级干扰；
|
||
- AI 结果的期限、新鲜度、超时、降级与故障恢复。
|
||
|
||
### 2.2 条件扩展
|
||
|
||
- 更大模型、更高并发和多加速器用于增加 Linux 推理域压力；
|
||
- 不同 Hypervisor、静态分区或 AMP 实现之间的隔离开销比较；
|
||
- 多边缘节点之间的协同推理。
|
||
|
||
### 2.3 暂不作为主线
|
||
|
||
- `T1` 多节点大模型集群的 RTOS 部署；
|
||
- `T2` 多 GPU 工作站上的统一 RTOS 推理栈；
|
||
- 以“容量从 MCU 连续扩展到集群”为核心贡献；
|
||
- 将模型量化、KV Cache 或分布式推理优化直接归为 RTOS 成果。
|
||
|
||
## 3. 研究问题
|
||
|
||
| 编号 | 研究问题 | 核心输出 |
|
||
|---|---|---|
|
||
| RQ1 | AI 进入 MCU/SoC 后，通过哪些资源路径破坏控制实时性？ | 干扰来源排序、响应时间与违约边界 |
|
||
| RQ2 | RTOS 的优先级、预算、隔离、预分配和准入机制能扩大多少安全运行区间？ | 无违约容量曲线与机制消融 |
|
||
| RQ3 | RTOS 控制域 + Linux 推理域 + Hypervisor 是否优于单域共存？ | 控制保护、AI 结果按期率与资源代价 |
|
||
| RQ4 | 跨域通信与静态资源预留带来多大开销？ | IPC 延迟/抖动、吞吐和能效损失 |
|
||
| RQ5 | 推理超时、Linux 域崩溃或加速器故障时能否按时降级？ | 故障检测、隔离、回退和恢复时间 |
|
||
|
||
## 4. 分阶段实验路线
|
||
|
||
### 阶段 P0：需求与时间契约冻结
|
||
|
||
先定义而不是从设备档位反推：
|
||
|
||
- 控制任务周期 `T_control` 和截止期 `D_control`；
|
||
- AI 结果期限 `D_ai` 和最大新鲜度 `A_max`；
|
||
- AI 缺席时的回退动作和期限 `D_fallback`；
|
||
- 可接受的 AI 完成率、结果质量和能耗预算；
|
||
- 需要保护的关键 I/O、中断、内存和设备。
|
||
|
||
完成标志是形成一张“任务—资源—期限—失败处理”表。
|
||
|
||
### 阶段 P1：MCU/SoC 干扰确认
|
||
|
||
在真实可运行 AI 的最小平台上建立下列负载：
|
||
|
||
| 负载 | 内容 | 目的 |
|
||
|---|---|---|
|
||
| M0 | 仅控制任务 | 控制实时性下界 |
|
||
| M1 | 仅 AI | AI 执行、内存、功耗基线 |
|
||
| M2 | 控制 + AI | 确认同域干扰 |
|
||
| M3 | M2 + 内存/总线压力 | 定位共享资源瓶颈 |
|
||
| M4 | M2 + I/O/中断压力 | 定位中断与 DMA 干扰 |
|
||
| M5 | M2 + 热稳态运行 | 识别降频导致的时间漂移 |
|
||
| M6 | AI 过载与突发 | 找到准入和降级阈值 |
|
||
|
||
AI 模型按硬件实际能力选择，不要求 MCU 运行大语言模型。小模型同样可以有效暴露系统级资源竞争。
|
||
|
||
### 阶段 P2：RTOS 机制验证
|
||
|
||
逐项加入并消融以下机制：
|
||
|
||
1. 控制任务固定优先级与核/执行上下文隔离；
|
||
2. AI 任务预算或服务器机制；
|
||
3. 内存预分配、缓冲区限额和禁止关键路径动态分配；
|
||
4. 中断亲和性和关键设备优先级；
|
||
5. AI 请求队列上限、限流和拒绝策略；
|
||
6. 模型降级、跳帧或降低推理频率；
|
||
7. 超时后回退到非 AI 控制路径。
|
||
|
||
每次只改变一个机制，输出控制任务违约率、AI 完成率和吞吐代价，避免只给出“优化前后”黑盒比较。
|
||
|
||
### 阶段 P3：边缘分域基线
|
||
|
||
至少比较：
|
||
|
||
| 组别 | 配置 |
|
||
|---|---|
|
||
| E0 | 普通 Linux：控制与推理同域 |
|
||
| E1 | PREEMPT_RT Linux：控制与推理同域 |
|
||
| E2 | RTOS 控制域 + Linux 推理域，最小静态分区 |
|
||
| E3 | E2 + 中断、内存、通信和准入优化 |
|
||
|
||
如硬件不支持其中某组，应明确记录缺失原因，不用不同硬件数据替代同平台对照。
|
||
|
||
### 阶段 P4：共享资源压力扫描
|
||
|
||
在 Linux 推理域逐步增加：
|
||
|
||
- CPU 利用率和线程数量；
|
||
- 模型请求到达率、batch 和上下文长度；
|
||
- DRAM 带宽与 LLC 压力；
|
||
- 网络、存储和摄像头 I/O；
|
||
- GPU/NPU 占用和完成中断频率；
|
||
- 持续功耗与温度。
|
||
|
||
横轴使用相同绝对负载或相同到达序列，纵轴联合展示控制 deadline miss ratio、AI 结果按期率和有效吞吐。目标是找到“控制仍安全、AI 仍有用”的二维可行区，而不是只比较单个平均值。
|
||
|
||
### 阶段 P5：跨域通信实验
|
||
|
||
比较可实现的通信方式，例如共享内存环形队列、通知机制、RPMsg 或虚拟设备。统一消息大小和到达序列，测量：
|
||
|
||
- 单向和往返时延；
|
||
- P99/P99.9 与观测最大抖动；
|
||
- 拷贝次数和 CPU 占用；
|
||
- 队列满时的丢弃、覆盖或背压行为；
|
||
- 域重启后的通道恢复时间；
|
||
- 旧结果、乱序结果和损坏结果是否被 RTOS 拒绝。
|
||
|
||
### 阶段 P6：故障注入与恢复
|
||
|
||
建议故障集：
|
||
|
||
| 故障 | 必测结果 |
|
||
|---|---|
|
||
| 推理进程退出 | 检测时间、控制违约、服务恢复时间 |
|
||
| Linux 域重启 | RTOS 是否持续运行、回退完成时间 |
|
||
| 推理请求永久阻塞 | 超时是否生效、队列是否泄漏 |
|
||
| 加速器错误/复位 | 故障是否跨域传播、恢复路径 |
|
||
| 共享队列溢出 | 丢弃策略、内存安全、控制影响 |
|
||
| 消息乱序/校验失败 | 错误结果是否被消费 |
|
||
| Linux 域 CPU/内存/I/O 过载 | 控制尾延迟和隔离上限 |
|
||
|
||
仅在具备安全恢复路径时执行设备级故障注入；否则先用软件故障和仿真通道验证状态机。
|
||
|
||
## 5. 指标体系调整
|
||
|
||
### 5.1 第一优先级：控制实时性
|
||
|
||
- 释放到完成的响应时间；
|
||
- deadline miss ratio；
|
||
- P99/P99.9 和观测最大抖动；
|
||
- GPIO、CAN、RS485 或工业以太网的端到端物理响应；
|
||
- AI 满载、热稳态和故障期间的控制表现。
|
||
|
||
### 5.2 第二优先级：AI 结果可用性
|
||
|
||
- 请求发出到 RTOS 验证结果完成的端到端时延；
|
||
- 结果按期率和新鲜度合格率；
|
||
- 超时、拒绝、丢弃、乱序和错误率；
|
||
- 任务质量或置信度；
|
||
- 回退发生比例。
|
||
|
||
### 5.3 第三优先级：系统代价
|
||
|
||
- 分给 RTOS 的 CPU、内存和设备资源；
|
||
- Hypervisor 与 IPC 开销；
|
||
- 推理吞吐损失、能耗和热影响；
|
||
- 静态预留导致的资源利用率变化；
|
||
- 故障恢复和长稳运行开销。
|
||
|
||
TTFT、TPOT、tokens/s 和 `E/token` 可以继续使用，但它们属于 Linux 推理域或系统服务指标，不能替代控制实时性与结果新鲜度指标。
|
||
|
||
## 6. 推荐图表
|
||
|
||
1. 单域与分域架构职责图；
|
||
2. AI 负载强度—控制违约率—AI 按期率三维或等高线图；
|
||
3. CPU、内存、I/O、热干扰的控制尾延迟对比；
|
||
4. 跨域请求—推理—返回—验证的时序分解图；
|
||
5. RTOS 机制逐项消融图；
|
||
6. 推理域故障期间控制响应时间序列；
|
||
7. 静态资源预留与推理有效吞吐的 Pareto 曲线；
|
||
8. AI 结果超时、回退、恢复状态机图。
|
||
|
||
## 7. 阶段验收标准
|
||
|
||
| 层次 | 验收条件 |
|
||
|---|---|
|
||
| 数据有效 | 时钟、负载、版本、拓扑和原始事件可追踪；失败样本未被静默删除 |
|
||
| 控制保障 | 在冻结的运行区间内满足控制期限，并报告样本数和观测最大值 |
|
||
| AI 可用 | 在冻结质量门槛下达到规定的按期率和新鲜度合格率 |
|
||
| 隔离有效 | 推理负载或故障对控制域的影响显著小于单域基线 |
|
||
| 代价可接受 | 同时报告资源预留、IPC、吞吐、能耗和热代价 |
|
||
| 降级有效 | AI 不可用时在 `D_fallback` 内进入预定义状态，且不依赖推理域恢复 |
|
||
|
||
“未观测到违约”仍不能代替理论最坏界；Hypervisor 分域结果也只能在已验证的硬件、配置和压力范围内成立。
|
||
|
||
## 8. 对现有设备的使用建议
|
||
|
||
- 现有 RK3588 更适合作为边缘分域或资源受限 SoC 的核心验证平台，而不是同时承担多个容量档位以构造连续谱系；
|
||
- 现有 V100 平台可作为 Linux 推理域的高压力源、吞吐参照或跨域服务端，但不需要证明其属于 RTOS 主线；
|
||
- MCU 平台应根据真实 AI 运行能力和工业 I/O 条件选取，优先验证控制期限和资源干扰，而非模型参数规模；
|
||
- 新增设备采购应由研究问题和分域实现需求驱动，不再为了补齐 `T1~T5` 档位而采购。
|
||
|
||
## 9. 建议的最小可发表闭环
|
||
|
||
在一个 MCU/SoC 同域平台和一个边缘分域平台上完成以下闭环即可形成聚焦的系统研究：
|
||
|
||
1. 证明 AI 负载会通过可识别的资源路径干扰控制实时性；
|
||
2. 给出 RTOS 预算、隔离、准入和降级机制；
|
||
3. 实现 RTOS 控制域与 Linux 推理域的有界异步通信；
|
||
4. 与普通 Linux、PREEMPT_RT 或单域方案进行同平台比较；
|
||
5. 在过载、热稳态和故障注入下验证控制保护；
|
||
6. 同时报告 AI 结果按期率和资源代价；
|
||
7. 明确结论只覆盖 MCU/SoC 与边缘任务关键系统，不外推到 T1/T2 集群。
|
||
|
||
这一闭环比覆盖全部硬件档位更容易建立清晰的因果关系，也更直接回应“AI 引入后，任务关键系统如何保持实时”的核心问题。
|