diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 46daa30..0000000 --- a/.gitignore +++ /dev/null @@ -1,10 +0,0 @@ -# Local assistant and workspace metadata -.claude/ -.workbuddy-ai/ - -# Local Git access notes may contain credentials -git_skills.md - -# Microsoft Office temporary lock files -~$*.docx -**/~$*.docx diff --git a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md index d096000..67fd1bc 100644 --- a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md +++ b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md @@ -17,7 +17,6 @@ 6. `05-中断与实时性保障.md` 7. `06-能耗与热管理.md` 8. `07-方法论与评估工具链.md` -9. `参考文件/README.md` ### 2. 候选课题框架目录 @@ -43,8 +42,6 @@ - 能耗约束、温度耦合、频率策略与热稳定性 - `07-方法论与评估工具链.md` - 建模、仿真、原型验证和评估方法学 -- `参考文件/` - - 按研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射 ## 候选框架说明 diff --git a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md index d5b844f..1f27d27 100644 --- a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md +++ b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md @@ -3,6 +3,7 @@ > 版本: v2.1 起草日期: 2026-09-21 > 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位** > 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色 +> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位 --- diff --git a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md index 965b9a2..b0b3871 100644 --- a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md +++ b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md @@ -7,9 +7,8 @@ 1. `01-研究逻辑说明.md` 2. `02-基础设备与算力基础.md` 3. `03-实验设计.md` -4. `metric.md` -5. `04-论文写作规划.md` -6. `05-论文结构总览.png` +4. `04-论文写作规划.md` +5. `05-论文结构总览.png` ## 文件说明 @@ -19,8 +18,6 @@ - T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则 - `03-实验设计.md` - 准入条件、对照原则、混合负载场景、指标与验收方法 -- `metric.md` - - 三层核心证据指标的统一定义、计算公式、采集要求与报告口径 - `04-论文写作规划.md` - 论文结构、章节分工、图表规划和证据映射 - `05-论文结构总览.png` diff --git a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md b/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md deleted file mode 100644 index 151221e..0000000 --- a/02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md +++ /dev/null @@ -1,397 +0,0 @@ -# 核心证据指标说明 - -## 1. 文档目的 - -本文依据 [01-研究逻辑说明.md](./01-研究逻辑说明.md) 第 8 节，对后续实验必须覆盖的三层核心证据指标给出统一定义、计算方法、采集要求和报告口径。 - -本指标体系用于回答一个核心问题： - -> **在人工智能目标负载与关键保障负载并存时，RTOS 能否在不牺牲任务质量和系统有效产出的前提下，提高系统的稳定性、可预测性与可保障性；这种提升在什么负载、功耗、温度和部署档位下成立。** - -指标分为三层： - -1. **人工智能目标负载层**：智能任务是否及时、正确、可用地完成； -2. **关键保障负载层**：周期控制、联锁和外部闭环是否仍满足实时约束； -3. **系统协同层**：双目标并存时，系统是否保持有效、节能、公平、稳定且可恢复。 - -任何单一指标都不能独立支撑系统优越性结论。正式结论必须同时给出三层证据，并说明平台、OS、模型、负载、功耗、温度和运行时长等适用边界。 - -## 2. 统一测量原则 - -### 2.1 时间点与时钟 - -人工智能请求至少记录以下时间点： - -| 符号 | 含义 | -|---|---| -| `a_i` | 请求计划到达时间 | -| `s_i` | 请求实际发送时间 | -| `u_i` | 服务端接收时间，可取得时记录 | -| `g_i` | 首个有效输出到达时间 | -| `c_i` | 完整输出到达或任务完成时间 | - -周期关键任务至少记录： - -| 符号 | 含义 | -|---|---| -| `r_i` | 计划释放时间 | -| `q_i` | 进入就绪态时间，可等价取得时使用 | -| `b_i` | 实际开始执行时间 | -| `f_i` | 完成时间 | -| `T` | 任务周期 | -| `D` | 相对截止期 | - -同一指标必须在同一时钟域内计算，优先使用单调时钟。跨设备测量需在 `manifest` 中记录同步方法、同步误差和时间戳位置；同步误差不足以支持单向时延时，改报往返时延，不将往返时延简单除以二作为单向结果。 - -### 2.2 统计与报告 - -- 时延和抖动至少报告样本数、`P50/P95/P99/P99.9` 和观测最大值；样本不足以稳定估计 `P99.9` 时，明确标为探索性结果并改以 `P99` 为主。 -- 每个普通性能单元至少独立运行 5 次；跨运行报告中位数、区间和置信区间，不只报告最佳一次。 -- 最大值只能表述为“指定时长和工况下的观测最大值”，不能写成理论 `WCET`。 -- 零违约只能表述为“在 `N` 次计划释放中未观测到违约”，不能据此证明绝对硬实时安全。 -- 原始超时、拒绝、OOM、丢样和失败请求必须保留，不能从分母中静默删除。 -- OS 对照需冻结硬件、模型与量化版本、输入/输出长度、到达序列、随机种子、CPU/IRQ/频率配置、内存预算、加速器数量、散热条件和测量窗口。 - -### 2.3 三层联合判定 - -正式实验单元只有同时满足下列条件，才能记为“通过”： - -```text -人工智能目标负载达标 -AND 关键保障负载达标 -AND 系统协同稳定 -``` - -若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。 - -## 3. 人工智能目标负载层 - -### 3.1 TTFT - -`TTFT`（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间： - -```text -TTFT_i = g_i - s_i -``` - -该指标包含请求传输、排队、调度和 prefill 阶段。负载发生器还应记录发送滞后 `s_i-a_i`，防止发生器本身饱和导致排队时间被遗漏。 - -报告要求： - -- 单位统一为 `ms`； -- 按模型、输入长度、并发度和到达率分别汇总； -- 至少报告 `P50/P95/P99/P99.9/Max`、样本数和超时数； -- 流式接口以客户端收到首个**有效内容 token**为终点，不把连接确认、空片段或仅含元数据的事件作为首 token； -- 非生成式人工智能任务不使用 `TTFT`，改用任务对应的首结果时间，并明确终点语义。 - -### 3.2 TPOT - -`TPOT`（Time Per Output Token）描述首 token 之后的平均生成间隔。对输出 token 数 `n_i > 1` 的请求： - -```text -TPOT_i = (c_i - g_i) / (n_i - 1) -``` - -报告要求： - -- 单位统一为 `ms/token`； -- `n_i <= 1` 的请求记为不可计算，不以 0 填充； -- 请求级 `TPOT` 与逐 token 间隔分布分开报告； -- 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善； -- 按输入长度、输出长度、并发度和到达率分组。 - -### 3.3 端到端响应时间 - -端到端响应时间描述从请求实际发出到完整可用结果到达的时间： - -```text -T_e2e,i = c_i - s_i -``` - -对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。 - -除分位数外，还需按业务完成期限 `D_ai` 报告按时完成率： - -```text -on_time_completion_ratio -= count(success_i AND T_e2e,i <= D_ai) / planned_requests -``` - -### 3.4 成功率、任务质量与输出可用性 - -三个概念必须分开计算： - -| 指标 | 定义 | 典型失败 | -|---|---|---| -| 请求成功率 | 协议和运行时层面正常完成的请求数 / 计划请求数 | 超时、拒绝、崩溃、OOM、传输失败 | -| 任务质量 | 输出与冻结的参考答案或数据集指标之间的符合程度 | 精度下降、错误分类、内容偏差 | -| 输出可用率 | 同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数 | 空输出、截断、格式错误、不可解析或不满足质量门槛 | - -计算式： - -```text -success_ratio = successful_requests / planned_requests -usable_output_ratio = usable_outputs / planned_requests -``` - -任务质量应按负载类型选择并预先冻结： - -- LLM：固定题集得分、精确匹配、规则判分或人工盲评结果； -- 视觉检测：`mAP`、召回率、误检率； -- 分类：准确率、F1 等； -- 语音识别：`WER/CER`； -- 故障诊断：检出率、漏报率、误报率。 - -量化或调度优化必须同时报告质量变化。仅提高速度但跌破质量门槛的输出不得计入有效结果。 - -### 3.5 长时间运行稳定性 - -人工智能负载稳定性用于检查持续运行时的性能和正确性是否退化。至少观测： - -- 每个时间块的 `TTFT/TPOT/T_e2e` 分位数； -- 请求成功率、输出可用率和错误类型； -- 吞吐、队列长度、内存和 KV Cache 占用； -- 温度、实际频率、进程重启和驱动异常。 - -建议将 24 h 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率： - -```text -latency_drift = (late_block_metric - early_block_metric) - / early_block_metric -``` - -报告时需给出完整时间序列，不能仅给 24 h 总平均值。持续内存增长、尾延迟恶化、成功率下降或周期性驱动错误均应作为稳定性退化证据。 - -## 4. 关键保障负载层 - -### 4.1 Deadline miss ratio - -对第 `i` 次计划释放，若 `f_i > r_i + D`，则发生截止期违约： - -```text -miss_i = 1, if f_i > r_i + D; otherwise 0 -deadline_miss_ratio = sum(miss_i) / planned_releases -``` - -要求： - -- 分母必须是计划释放次数，而不是实际完成次数； -- 未释放、跳过、丢失或未完成的实例必须单独标记，不能直接从分母删除； -- 同时报告违约数、计划释放数、连续违约长度和违约发生时间； -- 按场景、负载强度和 OS 配置分别统计。 - -### 4.2 P99/P99.9 jitter - -本文默认以完成间隔抖动作为关键保障负载的主抖动口径： - -```text -jitter_i = (f_i - f_(i-1)) - T -``` - -同时可报告绝对抖动 `abs(jitter_i)`。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。 - -报告要求： - -- 有符号抖动报告上下尾，绝对抖动报告 `P99/P99.9/Max`； -- 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件； -- 给出样本量及采样周期； -- 不使用均值或标准差替代尾部分位数。 - -### 4.3 观测最大响应时间 - -关键任务响应时间定义为： - -```text -R_i = f_i - r_i -R_observed_max = max(R_i) -``` - -观测最大响应时间需要与截止期 `D` 并列展示，并给出裕量： - -```text -deadline_margin = D - R_observed_max -``` - -`deadline_margin < 0` 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。 - -### 4.4 外部接口响应时间 - -外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路： - -```text -T_external = t_external_output - t_external_input -``` - -采集要求： - -- 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳； -- 固定波特率、帧长、总线负载、网络拓扑和时间戳位置； -- 报告空回路基线、测量分辨率和仪器误差； -- 报告 `P50/P99/P99.9/Max`、超时和丢帧； -- 内核或应用日志仅作为归因证据，不能替代外部闭环测量。 - -## 5. 系统协同层 - -### 5.1 有效吞吐 - -有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出： - -```text -effective_throughput -= qualified_output_units / measurement_window -``` - -对 LLM，`qualified_output_units` 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。 - -合格请求至少满足： - -```text -请求成功 -AND TTFT/端到端期限达标 -AND 任务质量达标 -AND 输出可用 -AND 同一窗口内关键保障负载达标 -``` - -有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。 - -### 5.2 E/token - -在与负载统计完全一致的窗口 `[t0,t1]` 内： - -```text -E_total = integral(P(t), t0, t1) -E/token = E_total / N_output -tokens/J = N_output / E_total -``` - -其中 `N_output` 为窗口内实际收到的输出 token 数。主结果使用整机输入端实测能耗，包含排队、空闲和失败请求消耗；板载或加速器遥测用于归因，不能替代整机测量。 - -要求： - -- 单位为 `J/token`，同时报告平均功率、峰值采样功率和仪器采样率； -- `N_output = 0` 时记为不可计算，不记为 0； -- 同时报有效 `E/token = E_total / N_qualified_output`，以反映失败和不合格输出的成本； -- 混合视觉与 LLM 负载时，不将全部能耗归因于 LLM，应使用独立对照或单列场景总能耗； -- 只在人工智能与关键保障约束均满足的配置之间比较能效。 - -### 5.3 温度、降频与热漂移 - -全程同步记录： - -- 环境温度、芯片/板卡温度； -- CPU、GPU、NPU 和内存相关实际频率； -- 降频事件及其原因； -- 功率、风扇/散热策略； -- 同时间轴上的时延、吞吐和违约。 - -降频时间比例定义为： - -```text -throttling_ratio = throttled_time / valid_measurement_time -``` - -热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化： - -```text -thermal_drift(metric) -= (hot_steady_metric - early_steady_metric) / early_steady_metric -``` - -时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。 - -### 5.4 多任务公平性 - -多租户或多模型并发场景使用各任务相对独占性能 `x_i` 计算 Jain 公平指数： - -```text -J = (sum(x_i))^2 / (k * sum(x_i^2)) -``` - -其中 `k` 为任务数，`x_i` 可取“共享运行时的有效吞吐 / 独占运行时的有效吞吐”。`J` 越接近 1，吞吐分配越均衡。 - -公平性不能只用一个指数概括，还应报告： - -- 每个任务或租户的有效吞吐、`TTFT`、端到端时延和成功率； -- 关键任务是否满足各自服务等级； -- 饥饿次数、最长无服务时间和优先级倒置事件； -- 高优先级保障所造成的低优先级代价。 - -对具有不同优先级和服务等级的任务，“公平”不是平均分配资源，而是在满足保障等级后不存在非预期饥饿。因此 Jain 指数只作为补充证据，不能替代逐任务 SLA 结果。 - -### 5.5 恢复能力 - -恢复测试应预先定义故障注入时刻 `t_fault` 和恢复判据。至少覆盖推理进程重启和队列过载；驱动重置、设备掉线或网络故障仅在存在安全、可恢复路径时执行。 - -建议记录： - -| 指标 | 定义 | -|---|---| -| 故障检测时间 | 检测到故障的时刻减 `t_fault` | -| 服务恢复时间 | 恢复到预定成功率和有效吞吐稳定区间的时刻减 `t_fault` | -| 数据损失 | 故障窗口内丢失、重复或无法确认的请求数 | -| 实时影响 | 故障窗口内关键任务违约数及最大响应时间 | -| 重试成功率 | 成功重试请求数 / 发起重试请求数 | -| 不可恢复故障数 | 需要人工干预、重启系统或丢失测量链路的次数 | - -恢复完成必须同时满足人工智能服务恢复和关键保障负载重新达标。仅进程重新启动但吞吐、队列或实时任务仍未恢复，不算恢复完成。 - -### 5.6 24 h 长稳表现 - -24 h 长稳采用人工智能目标负载、关键保障负载及必要伴生竞争负载的混合场景。至少连续记录： - -- 三层核心指标的固定时间块汇总； -- 温度、频率、功率和降频事件； -- 内存、KV Cache、句柄/线程和队列长度； -- OOM、驱动错误、进程重启、接口超时和日志中断； -- 注入故障前后恢复曲线。 - -长稳通过条件至少包括： - -1. 完成连续 24 h 有效测量； -2. 无不可恢复故障； -3. 测量与日志链路无中断； -4. 无持续、不可解释的内存增长； -5. 人工智能输出与关键保障负载在冻结阈值内； -6. 故障注入后在冻结时间内恢复。 - -若发生故障，必须保留原始数据并分析，不得删除故障批次后宣称长稳通过。 - -## 6. 指标—数据源—实验映射 - -| 层级 | 指标 | 主要数据源 | 主要实验/场景 | -|---|---|---|---| -| 人工智能目标负载 | `TTFT/TPOT`、端到端响应时间 | `requests.csv`、负载发生器、推理日志 | E2/E3/E8，L1～L7 | -| 人工智能目标负载 | 成功率、质量、输出可用率 | 请求日志、固定题集/数据集、判分程序 | E2/E3/E4/E8 | -| 人工智能目标负载 | 长时间稳定性 | 分块请求汇总、内存和错误日志 | E8，24 h | -| 关键保障负载 | 违约率、抖动、最大响应时间 | `rt.csv`、RTOS trace、GPIO 打点 | E1/E3/E7/E8，L0/L2～L7 | -| 关键保障负载 | 外部接口响应时间 | 示波器、逻辑/总线分析仪、抓包 | E1/E3/E8 | -| 系统协同 | 有效吞吐 | 请求、质量和 RT 数据联合计算 | E3/E5/E7/E8 | -| 系统协同 | `E/token` | 外部功率计/PDU、`requests.csv` | E2/E6/E8 | -| 系统协同 | 温度、降频、热漂移 | `thermal.csv`、频率与功率日志 | E6/E8 | -| 系统协同 | 多任务公平性 | 各租户请求日志和独占基线 | E5，L6 | -| 系统协同 | 恢复与 24 h 长稳 | `events.log`、三层时间序列 | E8，L7 | - -## 7. 最小数据产物 - -每次运行至少保存： - -| 文件 | 必需内容 | -|---|---| -| `manifest.json` | 平台/档位、OS/BSP/驱动、模型校验值、量化、输入、到达序列、CPU/IRQ/频率/内存配置、环境和仪器信息 | -| `requests.csv` | 请求 ID、计划到达、实际发送、首/末输出、输出数、成功、质量、可用性、超时/拒绝原因 | -| `rt.csv` | 计划释放、就绪、开始、完成、CPU、违约、丢失/跳过状态 | -| `power.csv` | 时间戳、功率、电压、电流、仪器来源 | -| `thermal.csv` | 时间戳、环境/芯片温度、实际频率、降频状态 | -| `events.log` | OOM、驱动错误、故障注入、重启、网络异常、测量故障 | -| `summary.json` | 三层指标、样本量、分位数、最大值、区间、阈值和判定结果 | - -所有派生指标必须能够从原始记录重新计算。汇总程序不得覆盖原始文件，不得静默剔除异常值。 - -## 8. 核心证据表述模板 - -正式报告应采用带边界的联合表述： - -> 在 `[平台/档位]`、`[模型与输入输出配置]`、`[到达率与竞争负载]`、`[功耗和温度条件]` 下，`[OS/配置]` 在人工智能目标负载达到 `[TTFT/TPOT/质量/可用率]`、关键保障负载达到 `[违约率/P99.9/观测最大响应]` 的同时，实现 `[有效吞吐和 E/token]`，并在 `[故障与 24 h 长稳结果]` 下保持稳定。相对 `[对照组]` 的改善为 `[效应量及置信区间]`。 - -不应只写“平均时延更低”“吞吐更高”或“24 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/00-子课题定义.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-子课题定义.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/00-子课题定义.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-子课题定义.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/00-子课题定义.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/00-子课题定义.md deleted file mode 100644 index d1497be..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/00-子课题定义.md +++ /dev/null @@ -1,84 +0,0 @@ -# 子课题定义 - -## 1. 建议名称 - -正式名称： - -> **面向 MCU 的静态智能控制基础系统研究** - -当前工程阶段名称： - -> **基于 SylixOS 与控制端 SoC 的静态智能任务编排、准入与闭环保障研究** - -两个名称分别解决不同问题：正式名称保持长期研究方向，工程阶段名称准确反映当前拥有 RK3588、4×V100，而尚缺真正 MCU 实验板的设备现实。 - -## 2. 核心研究问题 - -本子课题研究： - -> 在控制任务的时间、内存、功耗和安全边界必须优先满足的条件下，如何把轻量智能模型转换为具有固定资源上限、固定执行窗口、明确异常处理方式的 SylixOS 实时任务，并通过工具链在部署前完成可行性判定。 - -研究对象不是某一个模型，也不是单纯的模型压缩，而是由以下部分构成的静态智能控制基础系统： - -1. 控制任务与安全规则； -2. 小模型与有限算子集合； -3. 离线资源分析与联合编排器； -4. 静态内存、固定优先级和固定推理窗口； -5. SylixOS BSP、内核机制和 RealEvo 工程链路； -6. 超时、拒绝、降级、恢复和部署准入机制。 - -## 3. 项目现实基础 - -| 现有条件 | 在本子课题中的作用 | -|---|---| -| RK3588 16 GB 工业盒 | 首个 SylixOS/控制端 SoC 方法原型平台 | -| RK3588 8 GB 受限配置 | 验证预算收缩和部署准入，不冒充真实 MCU | -| 4×V100 服务器 | 模型训练、量化校准、转换和参考精度平台 | -| SylixOS / RealEvo | 实时任务、BSP、内存布局、编译部署与调试基础 | -| RK3568 / RK3576 候选板 | 控制端资源收缩与跨 BSP 验证 | -| 真正 MCU 平台 | 后续补充，用于形成严格 MCU 级结论 | - -## 4. 三阶段研究路线 - -### 阶段A：方法原型 - -在现有 RK3588 上打通控制任务描述、模型转换、静态 Tensor Arena、SylixOS 任务生成、固定优先级、超时与规则兜底以及部署准入报告。 - -### 阶段B：控制端收缩 - -在 RK3568、RK3576 或等价控制端平台上收紧内存、CPU时间、功耗、散热和启动预算，验证跨 BSP 可移植性。 - -### 阶段C：真正 MCU 实证 - -在确认 SylixOS lite/tiny、目标 BSP 和算子运行时可用后，验证 KB/MB 级 SRAM、片上 Flash、固定控制周期、快速启动和 `E/inference`。 - -## 5. 研究边界 - -本子课题重点覆盖： - -- 小模型、小算子与关键控制任务共存； -- 离线编排、静态内存和部署前准入； -- SylixOS上的调度、中断、内存、DMA和恢复； -- 低功耗、快速启动和规则兜底； -- 工具链、代码生成和芯片协同。 - -本子课题不把以下内容作为主线： - -- 通用大语言模型在 MCU 上运行； -- Linux 容器、复杂虚拟化和大规模服务编排； -- 只追求平均吞吐的推理优化； -- 用 RK3588 限额实验替代真正 MCU 结论； -- 在驱动或 BSP 未准入时预设 NPU 已经可用。 - -## 6. 与总课题的关系 - -本子课题对应总课题的 `T5` 控制端路线，重点研究 RTOS 直接控制域与推理运行域如何在极端约束下闭合。其任务描述、资源准入、规则兜底和数据格式也可供子课题B复用。 - -## 7. 成功判据 - -1. 部署前能够预测内存、时间和功耗预算； -2. 工具能够生成 SylixOS 工程所需代码和配置； -3. AI加入后关键控制任务仍满足截止期； -4. 超时、过载或模型异常时规则路径能够接管； -5. 预测值与实测值存在可解释误差； -6. 方法能够从 RK3588 迁移到更小控制端和真正 MCU。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/01-研究问题与适用场景.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/01-研究问题与适用场景.md deleted file mode 100644 index b09dcc5..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/01-研究问题与适用场景.md +++ /dev/null @@ -1,77 +0,0 @@ -# 研究问题与适用场景 - -## 1. 总体问题 - -本子课题不研究“MCU能运行多大的模型”，而研究： - -> 在控制任务优先、资源预算刚性和AI结果不完全可信的条件下，基础系统如何给智能任务建立可分析的资源边界、时间边界和安全边界。 - -## 2. 核心研究问题 - -| 编号 | 研究问题 | 主要证据 | -|---|---|---| -| RQ1 | 控制任务与模型如何离线联合编排 | 可调度性、控制截止期、固定推理窗口 | -| RQ2 | 静态内存规划能否降低峰值和碎片风险 | 峰值内存、长期稳定性、部署成功率 | -| RQ3 | 部署前预测能否接近目标板实测 | 时间、内存、功耗预测误差 | -| RQ4 | 规则兜底能否限制AI故障传播 | 降级时间、控制保持率、恢复时间 | -| RQ5 | 同一工具描述能否跨设备迁移 | RK3588、RK3568/3576、真正MCU之间的迁移代价 | - -## 3. 推荐主场景 - -### 3.1 电机或泵类设备状态识别 - -- 关键控制：1 ms级采样、控制计算和执行输出； -- AI功能：振动、电流或温度窗口的异常分类； -- AI周期：50～100 ms或事件触发； -- 模型：INT8 1D CNN、小型MLP或决策树； -- 兜底：AI超时或结果越界时继续规则控制并上报告警。 - -这个场景适合首个实验，因为控制链路、AI链路和故障处理边界都清晰，且不要求AI直接进入硬实时内环。 - -### 3.2 工业节点状态分类 - -持续运行传感器采集与现场总线通信，AI负责工况分类、故障预警或参数建议，规则层负责范围校验和安全动作。该场景可以验证 CAN、RS485、GPIO、DMA 与推理之间的干扰。 - -### 3.3 关键词或声学事件识别 - -模型和输入窗口固定，适合验证算子分段、静态Arena和低占空比推理，但不建议把语音输出直接接入关键执行链路。 - -### 3.4 轻量视觉检测或分类 - -适合 RK3588/RK3568 方法原型，可研究摄像头DMA、内存带宽和NPU中断对控制任务的影响，但不宜作为真正 MCU 阶段的唯一场景。 - -## 4. 不同设备上的场景分工 - -| 平台 | 优先场景 | 研究重点 | -|---|---|---| -| 4×V100 | 模型训练、量化校准、参考精度 | 不进行MCU实时性结论 | -| RK3588 16 GB | 电机状态、轻量视觉、控制与推理共存 | SylixOS集成、工具链闭环、干扰注入 | -| RK3588 8 GB限额 | 同一工作负载的预算收缩 | 准入机制能否正确降级或拒绝 | -| RK3568/RK3576 | 电机状态、关键词、工业节点 | 更小资源、低功耗、跨BSP迁移 | -| 真正MCU | 1D CNN、MLP、关键词、状态分类 | SRAM/Flash极限、快速启动、E/inference | - -## 5. 负载结构 - -所有场景统一拆成三类任务： - -1. **关键保障负载**：周期控制、采样、执行输出、联锁； -2. **人工智能目标负载**：分类、检测、异常识别或参数建议； -3. **伴生竞争负载**：日志、通信、存储、模型加载和后台诊断。 - -AI任务必须满足：不阻塞控制内环、使用有界队列、输入过期可丢弃、结果经过规则检查、超时结果不再生效、故障时控制系统能够独立运行。 - -## 6. 研究假设 - -- H1：静态联合编排比普通后台部署更能维持控制任务的尾延迟和截止期； -- H2：静态Arena与生命周期复用比动态堆具有更低、更稳定的峰值内存； -- H3：基于目标板算子数据库的预测能够给出具有工程安全系数的执行上界； -- H4：有界队列、超时和规则兜底能够把AI过载转化为可解释的拒绝或降级； -- H5：统一描述格式能够降低从RK3588迁移到更小控制端的适配成本。 - -## 7. 首期排除项 - -- AI直接闭合1 ms硬实时控制环； -- 动态Agent、多轮生成和开放式工具调用； -- 无法固定输入、模型版本或任务质量标准的应用； -- 无法获得BSP、驱动或时间戳的黑盒设备； -- 仅通过降低任务完成率来获得更好实时性或能耗结果。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/README.md deleted file mode 100644 index 05b90a1..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/README.md +++ /dev/null @@ -1,19 +0,0 @@ -# 00-总览与定位 - -本层回答“研究什么、为什么研究、用现有设备能证明什么”。 - -## 文件 - -1. [00-子课题定义.md](./00-子课题定义.md)：名称、研究对象、三阶段路线、边界和成功判据； -2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)：研究问题、假设、首个工业场景和设备分工。 - -## 阅读结果 - -读完本层应能够明确： - -- RK3588、RK3568/RK3576与真正MCU的区别； -- 4×V100在项目中的辅助角色； -- 为什么AI不直接进入1 ms硬实时内环； -- 项目最终需要证明哪些研究假设。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/01-研究问题与适用场景.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/01-研究问题与适用场景.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/01-研究问题与适用场景.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/01-研究问题与适用场景.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/02-技术路线：静态编排、工具链与芯片协同.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/02-技术路线：静态编排、工具链与芯片协同.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/03-实验设计与验证方法.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/03-实验设计与验证方法.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/04-预期成果与论文方向.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/04-预期成果与论文方向.md similarity index 92% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/04-预期成果与论文方向.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/04-预期成果与论文方向.md index e42bbbd..266464f 100644 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/04-预期成果与论文方向.md +++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/04-预期成果与论文方向.md @@ -1,4 +1,4 @@ - # 预期成果与论文方向 +# 预期成果与论文方向 ## 1. 预期成果 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/05-合作方式与产业落点.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/05-合作方式与产业落点.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/05-合作方式与产业落点.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/05-合作方式与产业落点.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/00-总体技术路线.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/00-总体技术路线.md deleted file mode 100644 index 0d8fc9a..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/00-总体技术路线.md +++ /dev/null @@ -1,171 +0,0 @@ -# 技术路线：静态编排、工具链与芯片协同 - -## 1. 总体架构 - -本子课题采用“离线联合编排 + SylixOS有界运行时 + 规则兜底”的结构。 - -```text -模型与数据集 控制任务与安全规则 - │ │ - ├──模型解析/量化 ├──周期/截止期/WCET - ├──算子图/张量生命周期 ├──中断/DMA/通信开销 - └──质量阈值 └──降级与恢复条件 - │ │ - └────┬─────┘ - ▼ - 离线联合编排器 - 内存规划/时间编排/准入判定 - │ - ┌───────────┴───────────┐ - ▼ ▼ - 拒绝或降级建议 SylixOS工程产物 - │ - ▼ - 固定任务、静态内存、有界队列 - │ - ▼ - 超时检测、规则兜底、恢复 -``` - -## 2. 四层技术结构 - -### 2.1 模型与算子层 - -- 固定模型版本、输入尺寸和任务质量标准； -- INT8等目标量化； -- 有限算子集合； -- 统计权重、Tensor Arena和工作区； -- 建立目标板算子执行时间和能耗数据库。 - -### 2.2 离线编排层 - -- 分析控制任务周期、截止期、执行时间与干扰； -- 规划静态内存和张量复用； -- 选择完整推理窗口或算子分段窗口； -- 计算响应时间和安全余量； -- 输出 `PASS / PASS WITH LIMITS / REJECT`。 - -### 2.3 SylixOS执行层 - -- 固定优先级与周期释放； -- 控制任务、AI任务和安全任务分级； -- 任务核绑定与中断治理； -- 静态区、固定Arena和DMA缓冲； -- 高精度时间戳、看门狗和异常恢复。 - -### 2.4 规则与闭环层 - -- AI输出范围、状态机和置信度检查； -- 超时或过载时丢弃过期结果； -- 默认动作或规则控制接管； -- 恢复前连续自检； -- 保证控制内环不等待AI。 - -## 3. 核心机制 - -### 3.1 静态内存 - -部署前计算： - -\[ -M_{AI}=M_{weights}+M_{arena}+M_{workspace}+M_{IO}+M_{stack} -\] - -并保证： - -\[ -M_{AI}\leq M_{total}-M_{OS}-M_{control}-M_{comm}-M_{safety} -\] - -运行阶段避免模型路径使用无界动态分配；权重、张量、DMA和控制缓冲分区管理。 - -### 3.2 静态时间 - -控制任务始终高于AI任务。AI采用以下两种方式之一： - -- 固定周期内完成一次完整推理； -- 把算子图切分成若干有界片段，分布在多个控制周期的空闲窗口执行。 - -必须分析AI不可抢占片段、中断和DMA对关键任务造成的最大阻塞。 - -### 3.3 有界通信 - -- 固定长度队列或环形缓冲； -- 最新值优先，过期输入可丢弃； -- 控制任务不得因等待AI队列而阻塞； -- 结果携带时间戳和有效期； -- 超时结果不得晚到生效。 - -### 3.4 部署准入 - -在编译和烧录前检查： - -- Flash/RAM是否超限； -- 算子是否受支持； -- 模型质量是否达标； -- 推理窗口是否满足； -- 控制任务是否仍可调度； -- 是否存在规则兜底和故障恢复路径。 - -## 4. 工具链路线 - -```text -ONNX/TFLite/其他固定模型 - → 解析与校验 - → 量化和算子合法化 - → 目标芯片算子映射 - → 张量生命周期与静态内存规划 - → 控制任务联合调度分析 - → SylixOS C/C++、链接段和任务配置生成 - → RealEvo编译、部署、调试 - → 板端数据回灌 -``` - -建议研究团队开发独立的编排器，不重复实现IDE。编排器负责模型、资源和任务分析；RealEvo继续负责BSP/App工程、交叉编译、部署和调试。 - -## 5. 结合现有设备的实现 - -### 5.1 4×V100服务器 - -负责训练、剪枝、量化校准、参考精度、模型转换和编排工具运行。服务器结果只提供模型侧基线，不作为控制端实时性证据。 - -### 5.2 RK3588工业盒 - -首期以CPU路径打通端到端流程，再把NPU作为条件扩展： - -1. SylixOS BSP和控制任务准入； -2. CPU小模型运行； -3. 静态Arena和任务生成； -4. 固定核、共享核与干扰对照； -5. 超时、过载和规则兜底； -6. NPU运行时可用后增加DMA、统一内存和中断实验。 - -### 5.3 RK3568/RK3576 - -用于验证生成代码和资源描述能否跨BSP迁移，并逐步缩小内存、算力和功耗预算。两者仍归类为控制端SoC。 - -### 5.4 真正MCU - -必须在BSP、最小系统、模型运行时和测量链路确认后选型。真正MCU阶段应把模型收敛到1D CNN、DS-CNN、MLP、决策树等有限任务，不延续大模型口径。 - -## 6. SylixOS技术映射 - -| 研究机制 | SylixOS/RealEvo落点 | 待确认项 | -|---|---|---| -| 周期任务与优先级 | 线程、定时器、RMS/固定优先级 | API和实际调度配置 | -| 核绑定 | SMP与大小核调度 | RK3588具体亲和性接口 | -| 静态内存 | BSP内存映射、链接脚本、静态区 | 内存域和限额能力 | -| DMA/Cache | BSP与驱动接口 | NPU、摄像头等设备一致性路径 | -| 异常恢复 | 看门狗、任务/进程恢复 | 推荐的局部重启方式 | -| 代码部署 | RealEvo BSP/App构建、上传和调试 | 外部生成工程接口 | -| MCU落地 | lite/tiny与目标BSP | 芯片清单和最小资源占用 | - -## 7. 技术边界 - -- 不把GPU/NPU内部执行时间直接归因于RTOS； -- 不把不同推理后端的整栈差异写成操作系统差异； -- 不用观测最大值替代理论WCET； -- 不在驱动未准入时承诺NPU路径； -- 不用SoC受限配置替代真正MCU功耗和存储结论。 - -六步编排、配置产物和准入门槛详见 [01-离线联合编排研究框架.md](./01-离线联合编排研究框架.md)。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/01-离线联合编排研究框架.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/01-离线联合编排研究框架.md deleted file mode 100644 index e9427c1..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/01-离线联合编排研究框架.md +++ /dev/null @@ -1,662 +0,0 @@ -# 面向 MCU 静态智能控制基础系统的离线联合编排研究框架 - -> 版本：v0.1 -> -> 用途：解释“模型—控制任务离线联合编排”具体研究什么、如何在现有硬件与 SylixOS 条件下实施，以及最终形成哪些可验证成果。 -> 适用范围：子课题 A“面向 MCU 的静态智能控制基础系统”。 - -## 1. 研究目的 - -本研究不是把模型训练、控制软件开发和操作系统移植分别完成后，再把三者简单放到同一设备上运行，而是在部署前联合回答以下问题： - -1. 控制任务必须保留多少 CPU 时间、内存、中断和通信资源； -2. 智能模型需要多少权重空间、运行内存、执行时间和能量； -3. 模型能否在不破坏控制截止期的条件下进入系统； -4. 模型、算子、任务和缓冲区应如何静态放置； -5. 推理超时、输入堆积、结果异常或设备故障时，系统如何降级； -6. 部署工具能否在烧录前给出“允许部署、需要降级或拒绝部署”的结论。 - -本研究的核心目标可以概括为： - -> 将轻量智能任务转换为一个具有固定资源上限、固定执行边界和明确失效处理方式的实时系统任务，使其能够被纳入 SylixOS 控制系统的可调度性与资源预算分析。 - -## 2. 先明确设备边界 - -### 2.1 MCU 与控制端 SoC 不能混为一谈 - -仓库现有设备和候选设备中，RK3568、RK3576、RK3588 都属于多核应用处理器或异构 SoC，不是真正意义上的微控制器 MCU。它们拥有 MMU、GB 级内存并可运行 Linux 或大型 RTOS，适合验证： - -- SylixOS 上的静态任务与内存编排流程； -- 大小核绑定、任务优先级、中断与 DMA 干扰； -- 模型转换、代码生成、部署和运行时保护； -- 从控制端 SoC 向真正 MCU 收缩时的方法可迁移性。 - -但如果最终论文题目明确使用“MCU”，仍需要增加一块真正的 MCU 实验平台，对 KB/MB 级 SRAM、片上 Flash、无 MMU、固定外设和极低功耗条件进行实测。 - -### 2.2 当前硬件在本研究中的分工 - -| 平台 | 当前状态 | 在本子课题中的角色 | 不能直接证明什么 | -|---|---|---|---| -| RK3588 16 GB 工业盒 | 已有 | P0 方法原型；验证 SylixOS 集成、静态编排工具、资源限额和控制/推理共存 | 不能直接代表真正 MCU 的内存与功耗边界 | -| RK3588 8 GB 受限配置 | 由现有设备限额形成 | 模拟控制端高档资源约束，验证预算收缩和部署拒绝机制 | 内存限额不等于真实小芯片的缓存、总线和功耗特征 | -| 4×V100 服务器 | 已有 | 模型训练、量化校准、转换、参考精度和离线工具运行 | 不作为 MCU 实时控制结论的证据 | -| RK3568 / RK3576 | 条件扩展 | 控制端 SoC 收缩验证；观察更小内存、低功耗和较弱算力条件 | 仍不是严格意义上的 MCU | -| 真正 MCU 开发板 | 当前需补充 | P2 核心实证；验证 KB/MB 级内存、固定窗口、快速启动和 `E/inference` | 需先确认 SylixOS BSP、工具链和模型运行时支持 | - -### 2.3 SylixOS 已确认能力与待确认能力 - -基于当前仓库材料和翼辉官方资料，可以把 SylixOS 能力分成两类。 - -已确认、可用于研究设计的能力： - -- 支持多线程、实时调度、中断、定时器、同步和内存管理； -- 支持 SMP、多种处理器架构和 BSP 开发； -- RealEvo 可创建、构建、部署和调试 BSP 与应用工程； -- BSP 工程可配置启动、内存映射、链接脚本、中断、时钟、Cache 和 DMA； -- 官方存在 RK3588 和 RK3568 的板级资料，可作为适配依据； -- 可通过链接脚本、静态区、固定任务和固定优先级实现离线资源布局。 - -必须由翼辉或具体 BSP 进一步确认的能力： - -- 现有 RK3588 工业盒是否与官方支持板完全兼容； -- RK3588 NPU、RKNN/RKLLM 或其他推理后端在 SylixOS 下的可用性； -- RK3576 的完整 BSP、驱动和性能计数支持； -- 面向真正 MCU 的 SylixOS lite/tiny 配置、最小内存占用和目标芯片 BSP； -- 模型运行时、算子库、DSP/NPU驱动和功耗测量接口； -- 核绑定、内存域、DMA缓冲、缓存维护和中断亲和性的具体 API。 - -因此，本研究不能预设“模型和NPU在SylixOS上已经可用”，而应把运行时与驱动准入作为第一道实验门槛。 - -## 3. 离线联合编排的输入与输出 - -### 3.1 输入 - -离线编排器至少接收四类描述。 - -#### 控制任务描述 - -- 周期 `T_i`； -- 相对截止期 `D_i`； -- 优先级； -- WCET、测量上界或执行时间分布； -- 栈空间； -- 中断、DMA、总线和外设依赖； -- 任务之间的先后关系； -- 故障时必须继续运行的最小任务集合。 - -#### 模型描述 - -- 模型格式与版本； -- 输入输出张量； -- 算子图； -- 量化格式； -- 权重大小； -- 中间张量生命周期； -- 算子工作区； -- 各算子在目标芯片上的执行时间与能耗估计； -- 任务质量阈值。 - -#### 平台描述 - -- CPU、DSP、NPU及其频率； -- Flash、SRAM、DDR和内存 Bank； -- Cache、DMA、总线和外设结构； -- SylixOS BSP、驱动、编译器和运行时版本； -- 可用算子库与硬件加速能力； -- 功耗模式、启动方式和测量接口。 - -#### 安全与运行策略描述 - -- AI任务周期与最大等待时间； -- 可接受的输入丢弃策略； -- 超时后的默认动作； -- 模型结果合法性检查； -- 连续异常次数阈值； -- 进入降级模式与退出降级模式的条件。 - -### 3.2 输出 - -离线编排器最终不只生成可执行程序，还应生成一组可审查产物： - -1. 静态内存布局； -2. 任务优先级与核绑定表； -3. 推理窗口与抢占关系表； -4. 模型和算子映射结果； -5. 超时、丢弃、降级和恢复策略； -6. SylixOS 应用代码与配置； -7. 部署准入报告； -8. 实测校准清单； -9. 配置清单与版本指纹。 - -## 4. 六步离线联合编排流程 - -### 4.1 步骤一：分析控制任务 - -#### 研究问题 - -第一步不是分析模型，而是先确定系统中哪些控制功能绝对不能被AI破坏。 - -对每个控制任务建立任务参数： - -\[ -\tau_i=(T_i,D_i,C_i,P_i,M_i,I_i) -\] - -其中： - -- `T_i`：周期； -- `D_i`：截止期； -- `C_i`：执行时间上界或测量上界； -- `P_i`：优先级； -- `M_i`：栈、静态数据和缓冲区； -- `I_i`：中断、DMA和外设干扰。 - -#### 具体工作 - -1. 列出周期控制、状态采集、执行输出、通信、诊断和日志任务； -2. 区分硬关键、软关键和非关键任务； -3. 测量空载和典型干扰下的执行时间； -4. 记录中断屏蔽、临界区、锁竞争和DMA影响； -5. 确定控制任务必须保留的CPU、栈、缓冲区和安全余量； -6. 建立无AI时的实时性基线。 - -#### SylixOS 落点 - -- 使用固定优先级、RMS或项目冻结的调度策略； -- 控制任务使用静态或预分配栈； -- 将关键中断与AI相关中断分层； -- 在多核 SoC 上优先为关键任务设置固定核或亲和性； -- 通过GPIO翻转、系统时间戳或外部逻辑分析仪测量端到端响应。 - -#### 输出 - -- `control_tasks.yaml`； -- 控制任务时序图； -- CPU利用率和响应时间分析表； -- 关键任务内存预留表； -- 无AI基线数据。 - -#### 准入门槛 G1 - -只有在控制任务单独运行时能够稳定满足截止期、测量链路可信且日志不会明显干扰实时任务，才进入下一步。 - -### 4.2 步骤二：分析模型与算子 - -#### 研究问题 - -模型是否适合控制端，不由参数量单独决定，而由模型图、算子支持、工作区、执行时间和任务质量共同决定。 - -#### 具体工作 - -1. 固定模型修订、输入尺寸、前处理和输出语义； -2. 将模型转换为稳定的中间表示； -3. 完成 INT8 或其他目标量化，并保存校准数据； -4. 展开算子图，统计每个算子的输入、输出和工作区； -5. 检查动态 Shape、动态控制流和不支持算子； -6. 在目标芯片或参考内核上测量算子执行时间； -7. 计算模型峰值内存，而不是只计算权重大小； -8. 比较量化前后任务质量。 - -#### 优先模型类型 - -真正 MCU 阶段优先选择： - -- 1D CNN 异常检测； -- DS-CNN 关键词识别； -- 小型 MLP 状态分类； -- 轻量视觉分类； -- 决策树或小型集成模型。 - -RK3588/RK3568 方法原型阶段可以使用更大的模型验证工具链，但不能据此替代 MCU 结论。 - -#### 输出 - -- `model_manifest.yaml`； -- 算子支持矩阵； -- 权重、Tensor Arena与工作区统计； -- 算子执行时间数据库； -- 精度与量化报告。 - -#### 准入门槛 G2 - -出现以下任一情况时拒绝进入正式编排： - -- 存在无法替换的不支持算子； -- 峰值内存已经超过AI预算； -- 任务质量低于冻结阈值； -- 单次推理时间明显超过允许窗口且无法分段； -- 推理后端或驱动在SylixOS目标板上不可用。 - -### 4.3 步骤三：制定静态内存布局 - -#### 研究问题 - -系统必须在部署前知道每一类内存由谁使用、峰值是多少、是否会与DMA或控制任务冲突。 - -AI 内存预算至少包括： - -\[ -M_{AI}=M_{weights}+M_{arena}+M_{workspace}+M_{IO}+M_{stack} -\] - -系统可给AI使用的上限为： - -\[ -M_{AI,max}=M_{total}-M_{OS}-M_{control}-M_{comm}-M_{safety} -\] - -必须满足： - -\[ -M_{AI}\leq M_{AI,max} -\] - -#### 具体工作 - -1. 冻结SylixOS内核、应用、控制任务和通信缓冲的预留； -2. 确定权重放在Flash、eMMC映射区、DDR还是SRAM； -3. 根据张量生命周期复用Tensor Arena； -4. 单独划分DMA缓冲，明确Cache一致性处理； -5. 避免控制任务与推理任务共享无界堆； -6. 在多Bank SRAM或NUMA式结构中确定放置位置； -7. 为日志、异常和升级预留安全余量； -8. 生成链接段、内存映射和静态数组。 - -#### SylixOS 落点 - -- 在BSP和链接脚本中固定关键内存段； -- 控制任务与AI任务使用独立静态区或受限内存区域； -- 正式运行窗口内禁止模型路径调用无界 `malloc/free`； -- 使用SylixOS的Cache、DMA和内存管理接口完成一致性治理； -- 在RK3588原型阶段分别测试16 GB全量和8 GB限额，但将结果标为SoC约束实验。 - -#### 输出 - -- `memory_layout.yaml`； -- SylixOS链接脚本片段； -- Tensor Arena偏移表； -- DMA与控制缓冲区映射； -- 峰值内存与安全余量报告。 - -#### 准入门槛 G3 - -若内存峰值超过预算、DMA缓冲与关键区域存在未解决冲突，或部署依赖运行时无界分配，则拒绝部署。 - -### 4.4 步骤四：制定静态时间布局 - -#### 研究问题 - -AI任务必须使用控制任务执行后明确剩余的时间，而不能依赖平均CPU占用较低。 - -#### 两类编排方式 - -##### 方式A：完整推理窗口 - -每隔固定周期释放一次AI任务，并要求其在固定窗口内完成。例如： - -- 控制任务周期：1 ms； -- AI任务周期：50 ms； -- AI最大完成时间：20 ms； -- 控制任务可随时抢占AI任务； -- AI超时则丢弃本次结果。 - -适合一次推理可在较短时间内完成的模型。 - -##### 方式B：算子级分段窗口 - -将推理图按算子或子图切分，每次只执行一个有界片段： - -```text -控制周期1：Conv1 -控制周期2：DepthwiseConv -控制周期3：Pooling -控制周期4：FC + 输出检查 -``` - -适合单次完整推理时间较长，但每个算子能够独立建立执行边界的模型。 - -#### 具体工作 - -1. 冻结AI任务的周期、相位和相对截止期； -2. 确定AI任务优先级低于关键控制任务； -3. 确定是否允许算子间抢占； -4. 建立AI任务对控制任务的阻塞时间上界； -5. 建立中断与DMA干扰项； -6. 进行响应时间分析或调度仿真； -7. 生成时间表、优先级和核绑定配置； -8. 在目标板上校准预测值。 - -#### SylixOS 落点 - -- 使用SylixOS线程优先级和定时器建立周期释放； -- 控制任务固定为高优先级，AI工作线程低于控制与安全线程； -- 在RK3588上可将关键控制线程与AI线程固定到不同核，比较固定核与共享核； -- NPU提交线程、中断回收线程和模型加载线程必须进入统一优先级分析； -- 记录调度延迟、抢占次数和每个推理片段的开始/结束时间。 - -#### 输出 - -- `schedule.yaml`； -- 任务—核心映射表； -- 推理窗口或算子分段表； -- 响应时间和可调度性分析； -- 预测与实测偏差表。 - -#### 准入门槛 G4 - -只有在加入AI任务后，关键控制任务仍满足冻结的截止期条件，并保留约定安全余量，才允许进入混合负载实验。 - -### 4.5 步骤五：加入运行时保护机制 - -#### 研究问题 - -静态编排只能说明正常条件下可运行，保护机制负责处理模型超时、输入过载、输出异常和推理域故障。 - -#### 保护机制 - -| 机制 | 目的 | 推荐策略 | -|---|---|---| -| 超时检测 | 防止推理无限占用窗口 | 到期取消结果、停止后续片段或重置任务状态 | -| 有界队列 | 防止输入无限堆积 | 固定长度1～N，禁止无界增长 | -| 输入丢弃 | 保持结果时效性 | 优先保留最新状态，丢弃过期样本 | -| 输出校验 | 阻止非法模型结果进入控制路径 | 范围检查、状态机检查、置信度与一致性检查 | -| 规则兜底 | AI不可用时维持基本控制 | 执行冻结的安全规则或默认动作 | -| 看门狗 | 处理推理任务卡死 | 局部任务重启，必要时进入系统降级 | -| 恢复门槛 | 防止故障后立即反复切换 | 连续通过若干次自检后恢复AI路径 | - -#### 运行原则 - -1. AI结果不能直接覆盖硬安全约束； -2. 控制内环不等待AI任务； -3. 超时结果不得晚到后继续生效； -4. 队列满时优先拒绝或覆盖旧输入，而不是阻塞控制任务； -5. 降级路径必须在没有AI的情况下独立运行； -6. 恢复过程不能引入新的控制抖动。 - -#### SylixOS 落点 - -- 使用高精度定时器或任务级截止期监视； -- 使用固定长度消息队列、事件或环形缓冲； -- 利用看门狗和任务重启机制处理异常； -- 将规则兜底任务设置为高于AI任务、低于最关键控制任务的明确层级； -- 使用RealEvo调试与性能工具记录异常切换过程； -- 在RK3568/RK3588上可进一步测试NPU/驱动异常是否传播到控制路径。 - -#### 输出 - -- `safety_policy.yaml`； -- 超时和丢弃状态机； -- 规则兜底代码； -- 故障注入脚本或测试程序； -- 异常切换与恢复测试报告。 - -#### 准入门槛 G5 - -模型超时、队列过载和推理任务异常时，控制任务必须继续运行；若故障能够无界传播到控制路径，则系统不得进入正式实验。 - -### 4.6 步骤六：生成部署产物与准入报告 - -#### 研究问题 - -部署报告不是普通性能总结，而是对一个“模型—硬件—SylixOS—控制任务”组合能否上线的工程判定。 - -#### 报告内容 - -##### 基本信息 - -- 板卡与硬件版本； -- SylixOS、BSP、编译器和驱动版本； -- 模型、量化文件和校验值； -- 控制应用版本； -- 工具链版本。 - -##### 资源预算 - -| 项目 | 上限 | 预测值 | 实测值 | 结论 | -|---|---:|---:|---:|---| -| Flash/eMMC占用 | 待冻结 | | | | -| 静态RAM | 待冻结 | | | | -| Tensor Arena | 待冻结 | | | | -| 任务栈 | 待冻结 | | | | -| DMA缓冲 | 待冻结 | | | | -| 单次推理时间 | 待冻结 | | | | -| 控制任务最大响应时间 | 待冻结 | | | | -| `E/inference` | 待冻结 | | | | -| 启动到安全控制 | 待冻结 | | | | -| 启动到AI就绪 | 待冻结 | | | | - -##### 准入结论 - -部署结论只允许使用以下三种状态： - -- **PASS**：资源、时间、质量和保护机制全部通过； -- **PASS WITH LIMITS**：降低AI周期、模型规模或功能范围后通过； -- **REJECT**：会破坏控制截止期、超出资源预算或缺少可验证保护机制。 - -#### 自动生成的工程产物 - -- 模型权重或模型镜像； -- 静态Tensor Arena； -- 算子调用代码； -- SylixOS任务包装代码； -- 超时与规则兜底代码； -- 链接脚本和内存布局； -- 编译配置； -- 部署清单； -- 测试用例与验收脚本。 - -## 5. 工具链总体结构 - -```text -训练模型/固定数据集 - │ - ▼ -模型解析、量化与任务质量检查 - │ - ▼ -算子合法化、融合与目标芯片映射 - │ - ├──────────────┐ - ▼ ▼ -算子时间/能耗数据库 控制任务与平台描述 - │ │ - └──────┬───────┘ - ▼ - 内存规划与时间编排 - │ - ▼ - 可调度性与准入检查 - │ - ┌────────┴────────┐ - ▼ ▼ - 拒绝/降级建议 生成SylixOS工程 - │ - ▼ - RealEvo编译、部署与调试 - │ - ▼ - 板端实测与模型校准 -``` - -### 5.1 与 RealEvo 的结合方式 - -建议不要重新实现完整IDE，而是在模型编排工具与RealEvo之间定义稳定接口： - -1. 模型侧工具生成C/C++代码、权重、静态内存描述和任务配置； -2. RealEvo负责SylixOS BSP/App工程管理、交叉编译、部署和调试； -3. 编排工具生成或修改应用层配置和链接片段； -4. 板端采样程序输出执行时间、内存、功耗和异常事件； -5. 实测数据回灌算子数据库，修正下一轮预测。 - -这样可以把研究贡献集中在“模型与控制任务的联合编排”，避免重复建设已有的操作系统IDE能力。 - -## 6. 基于现有硬件的分阶段实施路线 - -### P0：在现有 RK3588 上建立完整链路 - -目标：不等待新硬件，先打通方法和工具。 - -工作内容： - -1. 确认现有工业盒的SylixOS BSP兼容性； -2. 建立普通Linux/PREEMPT_RT与SylixOS控制任务基线； -3. 先使用CPU可执行的小模型，避免一开始被NPU驱动阻塞； -4. 完成模型解析、量化、静态Arena和代码生成； -5. 完成控制任务与AI任务的固定优先级编排； -6. 完成超时、队列限长和规则兜底； -7. 在16 GB和受限内存配置下验证部署报告是否能够正确给出结论。 - -P0的成果是“方法原型”，不是MCU最终结论。 - -### P1：向 RK3568/RK3576 控制端收缩 - -目标：验证方法在较弱CPU、更小内存和更低功耗平台上的迁移能力。 - -工作内容： - -- 减小模型和Tensor Arena； -- 收紧CPU时间和功耗预算； -- 验证启动时间和看门狗恢复； -- 验证不同BSP下代码生成的可移植性； -- 比较工具预测值与板端实测偏差。 - -P1仍属于“控制端SoC验证”，正式材料中不应写成纯MCU实证。 - -### P2：增加真正 MCU 平台 - -目标：形成严格的MCU级研究证据。 - -选板前必须确认： - -- SylixOS或其lite/tiny配置能否运行； -- BSP、编译器、调试器和功耗测量链路是否可用； -- SRAM、Flash、DSP/NPU和DMA结构是否适合研究； -- 是否可以获得芯片厂商算子库和周期数据； -- 控制外设、GPIO、CAN、ADC/PWM是否满足闭环实验。 - -如果SylixOS不适合最终选定的极小MCU，可将研究拆成两层： - -1. SylixOS控制端SoC负责系统编排与工程平台验证； -2. 真正MCU负责静态模型、控制闭环和极限资源边界验证； -3. 两层共享任务描述、模型清单、内存规划和准入报告格式。 - -这比为了维持单一操作系统叙事而选择不合适的平台更符合研究真实性。 - -## 7. 推荐的首个实验样例 - -### 7.1 场景：电机状态识别与 1 ms 控制共存 - -控制链路： - -```text -ADC/编码器采样 → 1 ms控制算法 → PWM/CAN输出 -``` - -智能链路： - -```text -振动/电流窗口 → 1D CNN → 状态分类 → 规则检查 → 参数建议或告警 -``` - -关键原则： - -- 1 ms控制内环不等待AI； -- AI每50～100 ms运行一次； -- AI只提供状态分类、参数建议或告警； -- AI超时或结果非法时，继续使用规则控制； -- AI结果只有通过范围和状态机检查后才能生效。 - -### 7.2 实验变量 - -- 无AI、AI静态编排、AI无保护三组； -- CPU共享核与固定核； -- 动态堆与静态Arena； -- 完整推理与算子分段； -- 无干扰、CPU干扰、内存/DMA干扰； -- 不同量化模型； -- 正常、超时、队列过载和任务异常。 - -### 7.3 主要指标 - -| 层次 | 指标 | -|---|---| -| 控制任务 | deadline miss ratio、P99/P99.9 jitter、最大响应时间、GPIO端到端响应 | -| AI任务 | 单次推理时延、完成率、任务质量、峰值内存 | -| 系统协同 | CPU占用、内存余量、队列状态、干扰下的可用区间 | -| 能耗与启动 | `E/inference`、平均功耗、启动到安全控制、启动到AI就绪 | -| 安全与恢复 | 超时切换时间、规则触发正确率、恢复时间、故障传播范围 | - -## 8. 研究问题与论文贡献 - -### RQ1：离线联合编排能否保护控制截止期 - -比较模型单独部署、普通后台任务部署和静态联合编排，观察关键控制任务的尾延迟与截止期违约。 - -### RQ2：静态内存规划能否降低峰值与碎片风险 - -比较动态堆、固定Arena和生命周期复用三种方案，观察峰值内存、长期稳定性和部署成功率。 - -### RQ3：部署前预测能否接近板端实测 - -比较工具预测的内存、执行时间和功耗与板端实测值，建立误差范围与安全系数。 - -### RQ4：保护机制能否限制AI故障传播 - -注入超时、错误输出、队列过载和任务崩溃，测量控制任务是否继续达标以及系统恢复时间。 - -### 预期贡献 - -1. 面向智能控制任务的统一描述方法； -2. 模型—算子—控制任务联合静态编排算法； -3. 面向SylixOS的代码生成与部署接口； -4. 部署前资源和可调度性准入方法； -5. 规则兜底与故障隔离运行时； -6. 从RK3588方法原型到真正MCU实证的分级验证体系。 - -## 9. 与翼辉联合研究需要确认的接口 - -建议将以下问题整理为与翼辉的技术确认清单： - -1. 现有RK3588工业盒可复用哪个官方BSP，板级差异有哪些； -2. RK3588/RK3568上可用的任务核绑定、中断亲和性和内存限额接口； -3. RKNN/RKLLM或其他NPU运行时能否移植到SylixOS； -4. DMA连续内存、Cache维护和设备中断的推荐实现； -5. RealEvo能否接收外部工具生成的工程、链接配置和代码； -6. 是否存在适合真正MCU的SylixOS lite/tiny产品形态和参考BSP； -7. 能否提供任务切换、中断延迟、内存和功耗相关追踪接口； -8. 看门狗、任务重启、进程隔离和异常恢复的推荐工程路径； -9. 是否可联合建设算子执行时间与资源占用数据库； -10. 是否可共同定义“模型进入任务关键控制系统”的部署准入报告。 - -## 10. 最终判断标准 - -本研究成功的标志不是模型能够在板卡上输出结果，而是同时满足： - -1. 部署前能够计算模型和控制任务的资源需求； -2. 工具能够自动生成静态内存和时间布局； -3. SylixOS上的控制任务在AI和干扰负载下仍满足截止期； -4. AI任务的资源使用不超过冻结预算； -5. 模型超时或异常时规则路径可以接管； -6. 预测值和实测值之间存在可解释误差范围； -7. 同一描述和工具链能够从RK3588原型逐步迁移到更小控制端和真正MCU。 - -最终需要形成的不是一个“能够运行的小模型演示”，而是一套： - -> **能够在部署前判断可行性、在运行时维持控制边界、在异常时完成安全降级的静态智能控制基础系统。** - -## 11. 参考资料 - -### 仓库内材料 - -- `10-共享理论与方法层/06-基础设备与算力基础.md` -- `20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md` -- `20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md` -- 项目框架1中的设备、实验设计和SylixOS联合研究方资料 - -### 翼辉官方资料 - -- SylixOS / RealEvo 开发环境： -- RealEvo BSP开发： -- SylixOS系统与驱动开发： -- RK3588官方板级资料： -- RK3568看门狗与设备资料示例： diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/README.md deleted file mode 100644 index 805eedd..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# 10-技术框架 - -本层回答“静态智能控制基础系统如何设计和生成”。 - -## 文件 - -1. [00-总体技术路线.md](./00-总体技术路线.md)：四层架构、核心机制、工具链和SylixOS映射； -2. [01-离线联合编排研究框架.md](./01-离线联合编排研究框架.md)：六步编排流程、准入门槛、配置产物和板端校准。 - -## 核心链路 - -```text -控制任务 + 模型 + 平台 - ↓ -内存规划 + 时间编排 + 准入检查 - ↓ -SylixOS工程生成 - ↓ -超时、规则兜底与恢复 -``` - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/00-实验设计与验证方法.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/00-实验设计与验证方法.md deleted file mode 100644 index d726ac7..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/00-实验设计与验证方法.md +++ /dev/null @@ -1,144 +0,0 @@ -# 实验设计与验证方法 - -## 1. 实验目标 - -验证静态联合编排是否能够在AI进入控制系统后，同时保证： - -1. 控制任务时间边界； -2. AI任务质量与时效性； -3. 内存、功耗和启动预算； -4. 超时、过载和异常时的安全降级。 - -## 2. 平台分层 - -| 层级 | 平台 | 作用 | -|---|---|---| -| H0 | 4×V100服务器 | 训练、量化、转换和参考精度 | -| H1 | RK3588 16 GB | SylixOS方法原型和完整链路 | -| H2 | RK3588 8 GB限额 | 预算收缩与准入判定验证 | -| H3 | RK3568/RK3576 | 控制端迁移、低功耗和跨BSP验证 | -| H4 | 真正MCU | SRAM/Flash、快速启动和极限资源实证 | - -## 3. 对照组 - -| 编号 | 配置 | 目的 | -|---|---|---| -| O0 | 无AI，仅控制任务 | 控制性能下界 | -| O1 | AI作为普通后台任务 | 观察未经治理的干扰 | -| O2 | 静态Arena + 固定优先级 | 验证基础静态机制 | -| O3 | O2 + 固定窗口/算子分段 | 验证时间编排 | -| O4 | O3 + 准入、超时和规则兜底 | 完整方案 | - -在同硬件、同模型、同输入和同编译选项下进行机制消融。Linux/PREEMPT_RT与SylixOS比较属于系统方案对照，若推理后端不同，必须单独解释。 - -## 4. 负载场景 - -| 编号 | 场景 | 目的 | -|---|---|---| -| L0 | 仅周期控制 | 建立基线 | -| L1 | 仅AI任务 | 建立模型时间与能耗基线 | -| L2 | 控制 + AI | 核心共存场景 | -| L3 | L2 + CPU竞争 | 验证调度和抢占 | -| L4 | L2 + 内存/DMA竞争 | 验证内存与总线干扰 | -| L5 | L2 + CAN/网络/存储 | 验证中断和I/O污染 | -| L6 | L2 + 突发输入 | 验证队列、丢弃与准入 | -| L7 | L2 + 超时/崩溃/错误输出 | 验证规则兜底和恢复 | - -## 5. 实验单元 - -### E0：设备和软件准入 - -- BSP启动、时钟、SMP、外设和看门狗； -- SylixOS/RealEvo版本冻结； -- 模型在CPU路径完成正确性验证； -- NPU路径单独设置准入门槛； -- 测量工具和时间戳校验。 - -### E1：控制任务基线 - -测量1 ms主任务及5/10 ms扩展任务的唤醒延迟、响应时间、抖动和GPIO端到端响应。 - -### E2：模型和算子基线 - -记录每个算子与完整模型的执行时间、峰值内存、工作区、任务质量和 `E/inference`。 - -### E3：内存方案对照 - -比较动态堆、固定Arena、生命周期复用和不同内存限额，观察峰值、碎片、失败点和长稳行为。 - -### E4：时间编排对照 - -比较普通后台运行、固定窗口和算子分段，观察控制任务尾延迟、AI完成率和切分开销。 - -### E5：混合干扰 - -依次增加CPU、内存、DMA、通信和存储干扰，不同时改变多个变量。 - -### E6：准入和过载 - -逐级增加AI到达率，记录队列峰值、拒绝率、过期输入、有效完成率和控制任务边界。 - -### E7：故障与规则兜底 - -注入模型超时、错误输出、任务崩溃和驱动不可用，测量切换时间、控制保持率和恢复时间。 - -### E8：启动、功耗和长稳 - -分别测量启动到安全控制、启动到AI就绪、平均功耗、单次推理能耗和24小时运行状态。 - -## 6. 指标 - -### 6.1 控制层 - -- deadline miss ratio； -- P50/P95/P99/P99.9 jitter； -- 观测最大响应时间； -- GPIO/CAN端到端响应； -- 降级期间控制任务保持率。 - -### 6.2 AI层 - -- 单次推理时延及分布； -- 完成率、拒绝率和过期率； -- 任务准确率、F1或业务指标； -- 权重、Arena、工作区和峰值内存。 - -### 6.3 系统层 - -- CPU占用和抢占次数； -- 队列长度； -- 内存安全余量； -- `E/inference`； -- 温度、频率和降频； -- 启动与恢复时间。 - -## 7. 统计与报告原则 - -1. 普通单元至少独立运行5次； -2. 控制任务报告样本数、分位数、最大值和违约分子/分母； -3. 零违约只表述为“在指定工况和样本数下未观测到违约”； -4. 不用P99.9或观测最大值冒充理论WCET； -5. 保存超时、拒绝、OOM和任务崩溃，不静默删除失败数据； -6. 预测与实测必须使用相同配置和版本； -7. 功耗报告说明测量边界、采样率和空载功率。 - -## 8. 数据产物 - -每次运行至少保存： - -- `manifest.json`：硬件、SylixOS/BSP、模型、任务和编译配置； -- `control.csv`：释放、开始、完成、CPU、截止期状态； -- `inference.csv`：输入、开始、结束、结果、超时与拒绝原因； -- `memory.csv`：静态区、Arena、栈和峰值； -- `power.csv`：功率、温度和频率； -- `events.log`：看门狗、降级、重启和恢复； -- `summary.json`：指标、样本量和准入结论。 - -## 9. 阶段完成条件 - -- P0：RK3588 CPU路径完成E0～E7； -- P1：NPU或加速路径在准入后完成E2、E5、E7； -- P2：RK3568/RK3576复现实验并量化迁移成本； -- P3：真正MCU完成E0～E8，形成严格MCU论文证据。 - -若BSP、驱动或推理运行时不可用，停止对应路径，输出适配缺口，不把计划写成实测结果。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/01-首个实验冻结说明.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/01-首个实验冻结说明.md deleted file mode 100644 index 869009e..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/01-首个实验冻结说明.md +++ /dev/null @@ -1,147 +0,0 @@ -# 首个实验冻结说明 - -> 实验名称：RK3588 + SylixOS上1 ms控制任务与INT8 1D CNN共存实验 -> -> 状态：草案，待BSP与场景数据确认后冻结 -> 原则：冻结后，正式实验期间不得静默改变模型、输入、任务、频率和测量口径。 - -## 1. 实验目标 - -回答以下问题： - -1. AI作为普通后台任务运行时，会对1 ms控制任务造成多大干扰； -2. 静态Arena、固定优先级和固定推理窗口能否降低干扰； -3. 有界队列、超时和规则兜底能否限制AI过载与故障传播； -4. 离线预测的内存和执行时间与板端实测相差多少。 - -## 2. 平台冻结 - -| 项目 | 冻结值 | 状态 | -|---|---|---| -| 设备型号/编号 | RK3588工业盒，待填写 | 待确认 | -| CPU | 4×A76 + 4×A55 | 已知 | -| 内存 | 16 GB；增加8 GB限额组 | 计划 | -| 存储 | eMMC/NVMe，待填写 | 待确认 | -| SylixOS版本 | | 待翼辉确认 | -| BSP版本 | | 待翼辉确认 | -| RealEvo版本 | | 待翼辉确认 | -| 编译器与优化级别 | | 待确认 | -| CPU频率策略 | 固定频率优先 | 待确认 | -| 散热与环境温度 | | 待填写 | - -## 3. 控制任务冻结 - -| 参数 | 初始建议 | 最终冻结值 | -|---|---:|---:| -| 周期 `T` | 1 ms | | -| 截止期 `D` | 1 ms | | -| 任务体 | 确定性计算 + GPIO/CAN回环 | | -| 参考执行时间 | 约100～200 μs | | -| 释放方式 | 绝对周期释放 | | -| 优先级 | 最高业务优先级 | | -| CPU绑定 | 独占核与共享核各一组 | | -| 日志 | 预分配内存缓冲 | | - -控制任务必须在无AI条件下先通过基线准入。 - -## 4. AI任务冻结 - -| 参数 | 初始建议 | 最终冻结值 | -|---|---|---| -| 任务 | 振动/电流窗口状态分类 | | -| 模型 | 小型INT8 1D CNN | | -| 输入长度 | 固定，待数据集确认 | | -| 输出类别 | 正常/轻微异常/严重异常 | | -| 推理周期 | 50或100 ms | | -| 推理后端 | 第一阶段CPU | | -| Tensor Arena | 静态生成 | | -| 最大允许执行时间 | 由基线试运行后冻结 | | -| 质量阈值 | Accuracy/F1，待冻结 | | -| 超时行为 | 丢弃结果并触发规则路径 | | - -## 5. 对照组 - -| 编号 | 配置 | -|---|---| -| O0 | 仅控制任务 | -| O1 | 控制 + AI普通后台任务、动态内存 | -| O2 | 控制 + AI静态Arena、固定优先级 | -| O3 | O2 + 固定推理窗口或算子分段 | -| O4 | O3 + 有界队列、超时、规则兜底和恢复 | - -## 6. 负载组 - -- L0：无干扰； -- L1：CPU竞争25/50/75%； -- L2：内存流式读写； -- L3：GPIO/CAN/网络I/O； -- L4：AI输入突发； -- L5：模型超时； -- L6：AI任务异常退出； -- L7：连续运行与热状态。 - -## 7. 规则兜底 - -AI结果仅用于状态分类、告警或参数建议，不直接覆盖硬安全约束。 - -触发兜底的条件： - -- 推理超过冻结截止期； -- 输出类别或数值越界； -- 输入时间戳过期； -- 队列溢出； -- AI任务或运行时异常； -- 连续若干次结果不可信。 - -兜底动作： - -1. 丢弃当前AI结果； -2. 保持或恢复规则控制； -3. 记录事件； -4. 必要时重启AI任务； -5. 连续自检通过后恢复AI路径。 - -## 8. 指标 - -### 控制任务 - -- deadline miss ratio； -- P50/P95/P99/P99.9响应时间与抖动； -- 观测最大值； -- GPIO/CAN端到端响应。 - -### AI任务 - -- 单次推理时延； -- 完成、拒绝、超时和过期率； -- 任务质量； -- 权重、Arena、工作区和峰值内存。 - -### 系统 - -- CPU占用、抢占和上下文切换； -- 内存余量； -- 功率、温度和频率； -- 降级切换和恢复时间。 - -## 9. 运行方法 - -1. 保存硬件和软件配置快照； -2. 重启进入指定配置； -3. 先运行O0基线； -4. 模型预热与冷启动分开测量； -5. 各组随机或平衡顺序运行； -6. 普通单元至少独立运行5次； -7. 保存所有失败、拒绝和超时； -8. 正式结果使用冻结后的新运行批次。 - -## 10. 首轮完成判据 - -- [ ] BSP、时钟和测量链路通过； -- [ ] O0控制基线无未解释异常； -- [ ] CPU模型正确运行； -- [ ] O0～O4全部有数据； -- [ ] 至少完成CPU、内存和突发干扰； -- [ ] 至少完成一次超时和任务异常注入； -- [ ] 预测内存与实测内存完成比较； -- [ ] 得出静态联合编排是否改善控制边界的结论。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/02-硬件软件版本清单模板.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/02-硬件软件版本清单模板.md deleted file mode 100644 index dcc531a..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/02-硬件软件版本清单模板.md +++ /dev/null @@ -1,109 +0,0 @@ -# 硬件与软件版本清单模板 - -> 每次正式实验必须复制一份本模板并填写完整。无法获取的字段填写 `N/A` 或 `UNKNOWN`，不得留空或按经验猜测。 - -## 1. 实验标识 - -| 字段 | 内容 | -|---|---| -| 项目 | 面向MCU的静态智能控制基础系统 | -| 实验编号 | | -| 运行编号 | | -| 日期与时区 | | -| 操作人 | | -| 数据目录 | | -| Git提交 | | - -## 2. 硬件 - -| 字段 | 内容 | -|---|---| -| 设备名称 | | -| 实物编号 | | -| 主板/核心板型号 | | -| PCB/硬件版本 | | -| SoC/MCU | | -| CPU核心与频率 | | -| DSP/NPU/GPU | | -| RAM容量与类型 | | -| Flash/eMMC/NVMe | | -| 网络接口 | | -| CAN/RS485/GPIO | | -| 电源 | | -| 散热方式 | | -| 环境温度 | | - -## 3. SylixOS与BSP - -| 字段 | 内容 | -|---|---| -| SylixOS版本 | | -| Base版本 | | -| BSP名称与版本 | | -| 设备树校验值 | | -| RealEvo版本 | | -| 编译器版本 | | -| 编译优化级别 | | -| C/C++运行库 | | -| 启动参数 | | -| CPU亲和性 | | -| 中断亲和性 | | -| 频率策略 | | -| 看门狗配置 | | - -## 4. AI模型与运行时 - -| 字段 | 内容 | -|---|---| -| 模型名称 | | -| 模型版本/校验值 | | -| 模型格式 | | -| 量化格式 | | -| 输入形状 | | -| 输出定义 | | -| 权重大小 | | -| Tensor Arena | | -| 最大工作区 | | -| 推理运行时 | | -| 算子库版本 | | -| NPU/驱动版本 | | -| 校准数据版本 | | -| 任务质量阈值 | | - -## 5. 控制任务 - -| 字段 | 内容 | -|---|---| -| 周期 | | -| 截止期 | | -| 优先级 | | -| CPU绑定 | | -| 栈大小 | | -| 任务体版本 | | -| GPIO/CAN回环 | | -| 安全规则版本 | | -| 超时动作 | | - -## 6. 测量设备 - -| 字段 | 内容 | -|---|---| -| 逻辑分析仪/示波器 | | -| 探头与采样率 | | -| 功率计 | | -| 功率采样率 | | -| CAN/RS485分析仪 | | -| 时间同步方式 | | -| 空载环回延迟 | | - -## 7. 配置校验 - -- [ ] 设备编号与实物一致； -- [ ] Git提交已记录； -- [ ] 模型校验值已记录； -- [ ] BSP、编译器和运行时版本已记录； -- [ ] CPU频率和亲和性已确认； -- [ ] 输入、随机种子和负载序列已冻结； -- [ ] 测量设备和采样率已确认； -- [ ] 数据目录空间充足； -- [ ] 故障与无效批次记录方式已确认。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/03-实验运行记录模板.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/03-实验运行记录模板.md deleted file mode 100644 index 8d1e561..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/03-实验运行记录模板.md +++ /dev/null @@ -1,107 +0,0 @@ -# 实验运行记录模板 - -## 1. 运行信息 - -| 字段 | 内容 | -|---|---| -| 实验编号 | | -| 运行编号 | | -| 日期/开始时间/结束时间 | | -| 操作人 | | -| 对照组 | O0/O1/O2/O3/O4 | -| 负载组 | L0～L7 | -| 数据目录 | | -| 配置清单 | | - -## 2. 运行前检查 - -- [ ] 硬件编号正确； -- [ ] SylixOS/BSP/应用版本正确； -- [ ] 模型校验值正确； -- [ ] CPU频率与亲和性正确； -- [ ] 中断配置正确； -- [ ] 测量设备已连接； -- [ ] 空载环回值正常； -- [ ] 时间同步正常； -- [ ] 数据目录空间充足； -- [ ] 环境温度已记录。 - -## 3. 运行参数 - -| 参数 | 值 | -|---|---| -| 控制周期/截止期 | | -| 控制任务优先级/CPU | | -| AI周期/截止期 | | -| AI任务优先级/CPU | | -| 模型/量化/输入 | | -| Arena/工作区 | | -| 队列长度 | | -| 超时策略 | | -| 干扰负载 | | -| 运行时长 | | -| 随机种子 | | - -## 4. 运行过程 - -| 时间 | 事件 | 影响 | 处理 | -|---|---|---|---| -| | 启动 | | | -| | 进入稳态 | | | -| | 干扰开始 | | | -| | 故障注入 | | | -| | 降级/恢复 | | | -| | 结束 | | | - -## 5. 结果摘要 - -### 控制任务 - -| 指标 | 结果 | -|---|---:| -| 计划释放数 | | -| 完成数 | | -| 截止期违约数/比率 | | -| P99/P99.9响应时间 | | -| 观测最大响应时间 | | -| GPIO/CAN端到端延迟 | | - -### AI任务 - -| 指标 | 结果 | -|---|---:| -| 输入数 | | -| 完成/拒绝/超时/过期 | | -| P50/P99推理时延 | | -| 任务质量 | | -| 峰值内存 | | - -### 系统 - -| 指标 | 结果 | -|---|---:| -| CPU占用 | | -| 平均/峰值功率 | | -| `E/inference` | | -| 温度/降频比例 | | -| 降级切换时间 | | -| 恢复时间 | | - -## 6. 有效性判定 - -- [ ] 配置与冻结说明一致； -- [ ] 原始数据完整； -- [ ] 无丢失且未解释的时间戳； -- [ ] 测量设备正常； -- [ ] 失败、超时和拒绝均已保存； -- [ ] 无人为中断或未记录操作。 - -运行判定：`VALID / INVALID / EXPLORATORY` - -原因： - -## 7. 异常与后续动作 - -| 异常 | 初步原因 | 是否重跑 | 后续负责人 | -|---|---|---|---| -| | | | | diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/README.md deleted file mode 100644 index 21e829b..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# 20-实验与验证 - -本层管理研究证据、冻结配置和逐次实验记录。 - -## 方法文档 - -1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：O0～O4对照、L0～L7负载、E0～E8实验和指标； -2. [01-首个实验冻结说明.md](./01-首个实验冻结说明.md)：RK3588首个正式实验的冻结模板。 - -## 实验模板 - -3. [02-硬件软件版本清单模板.md](./02-硬件软件版本清单模板.md)：每个正式配置填写一次； -4. [03-实验运行记录模板.md](./03-实验运行记录模板.md)：每次运行填写一次。 - -## 使用原则 - -- 先冻结配置，再运行正式实验； -- 保存失败、拒绝、超时和异常； -- 不用观测最大值替代理论WCET； -- 不把不同推理后端的差异直接归因于操作系统。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/00-基于现有设备的项目实施路线图.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/00-基于现有设备的项目实施路线图.md deleted file mode 100644 index 8b4139a..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/00-基于现有设备的项目实施路线图.md +++ /dev/null @@ -1,129 +0,0 @@ -# 基于现有设备的项目实施路线图 - -## 1. 当前起点 - -项目目前具备： - -- RK3588 16 GB工业盒，可作为SylixOS控制端SoC主样例； -- 4×V100服务器，可承担训练、量化、转换和离线工具； -- SylixOS/RealEvo研究基础； -- RK3568/RK3576候选扩展路线； -- 已形成六步离线联合编排与准入框架。 - -当前关键缺口： - -- 现有工业盒BSP兼容性确认； -- SylixOS下可用的小模型CPU运行时； -- RK3588 NPU运行时和驱动准入； -- 功耗与GPIO端到端测量设备； -- 真正MCU开发板及对应SylixOS形态。 - -## 2. 工作包 - -### WP0：平台与版本冻结 - -输出：硬件清单、设备编号、SylixOS/BSP/RealEvo版本、编译器、时间戳和测量链路。 - -停止条件：BSP不能稳定启动、关键外设不可用或计时误差无法接受。 - -### WP1：控制任务与基线 - -在RK3588上实现1 ms控制任务、GPIO/CAN回环、看门狗和日志缓冲，形成无AI基线。 - -输出：`control_tasks.yaml`、控制延迟数据、外部响应数据。 - -### WP2：模型与离线工具 - -在V100服务器完成模型训练/选择、INT8量化、算子图分析、Tensor Arena规划和代码生成。 - -首个模型建议：振动或电流窗口上的1D CNN。 - -输出：模型清单、算子数据库、静态内存布局和参考精度。 - -### WP3：RK3588 CPU路径闭环 - -先不依赖NPU，完成AI任务、固定优先级、静态Arena、有界队列、超时和规则兜底。 - -输出：首个完整SylixOS参考工程和O0～O4对照数据。 - -### WP4：干扰、故障与长稳 - -增加CPU、内存、DMA、通信、突发输入、模型超时和任务崩溃；执行长稳和恢复实验。 - -输出：可行负载区间、故障传播边界和恢复时间。 - -### WP5：NPU条件扩展 - -只有在RK3588 NPU驱动、运行时、模型转换和时间戳均通过准入后开展。 - -输出：CPU与NPU路径的整栈对照，并区分RTOS收益和加速器收益。 - -### WP6：控制端收缩 - -把相同描述和生成工具迁移到RK3568/RK3576，收紧内存、功耗和启动预算。 - -输出：跨BSP迁移工作量、预测误差和资源边界变化。 - -### WP7：真正MCU实证 - -完成选板、BSP、轻量运行时、功耗采样和控制外设准入，再复用任务描述和准入报告。 - -输出：严格MCU级实证、第三篇论文候选和开发套件原型。 - -## 3. 依赖关系 - -```text -WP0 → WP1 ─────────────┐ - └→ WP2 → WP3 → WP4 ─┼→ WP6 → WP7 - └─────┘ - WP5为条件扩展 -``` - -不应让NPU适配阻塞CPU路径，也不应等待真正MCU采购后才开始工具链研究。 - -## 4. 阶段验收 - -| 阶段 | 验收标志 | -|---|---| -| M0 | 备份、目录重组和技术确认清单完成 | -| M1 | RK3588 SylixOS控制任务基线可复现 | -| M2 | 服务器端模型转换和静态内存报告完成 | -| M3 | RK3588 CPU路径AI+控制闭环完成 | -| M4 | O0～O4与L0～L7核心数据完成 | -| M5 | RK3568/RK3576至少一档迁移成功 | -| M6 | 真正MCU完成核心实验并形成论文数据 | - -## 5. 首批采购与确认优先级 - -### 优先确认，不立即采购 - -- 现有RK3588工业盒BSP； -- SylixOS CPU小模型运行时； -- RealEvo自动化接口； -- 逻辑分析仪/示波器、功率计是否已有。 - -### 首批可能需要补充 - -- RK3568或RK3576官方/兼容开发板； -- GPIO、CAN或电机回环负载； -- 可同步采样的直流功率计； -- 真正MCU候选板，但须在BSP确认后采购。 - -## 6. 风险与替代路线 - -| 风险 | 替代路线 | -|---|---| -| RK3588 NPU在SylixOS不可用 | CPU路径先完成方法验证，NPU列适配缺口 | -| 现有工业盒与官方BSP不兼容 | 使用官方RK3588评估板或先在仿真/兼容板验证 | -| RK3576 BSP不可用 | 跳过中间档，优先RK3568或RK3588限额 | -| 真正MCU无法运行SylixOS | MCU使用轻量RTOS验证方法，SylixOS保留控制端SoC工程平台角色 | -| 功耗仪器不足 | 先完成时间和内存实验，能耗标为未测而非估算 | -| 模型不能满足窗口 | 缩小模型、降低周期或采用算子分段，并由准入报告记录限制 | - -## 7. 当前最小可行成果 - -无需等待所有设备，当前即可完成的最小成果是： - -> 在RK3588与SylixOS上，以1 ms控制任务和INT8 1D CNN为样例，完成静态Arena、固定优先级、有界队列、超时与规则兜底，并证明离线联合编排相比普通后台部署能够更稳定地维持控制任务边界。 - -这一成果能够同时验证问题定义、工具链、SylixOS集成和实验方法，是后续向RK3568和真正MCU扩展的共同基础。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/01-两周执行计划与验收清单.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/01-两周执行计划与验收清单.md deleted file mode 100644 index bec3b63..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/01-两周执行计划与验收清单.md +++ /dev/null @@ -1,134 +0,0 @@ -# 两周执行计划与验收清单 - -> 目标：用两周时间完成“平台能否开展实验”的判断，并形成RK3588控制基线与小模型准备结果。两周结束时不要求完成整篇论文，但必须减少关键不确定性。 - -## 第1周：平台准入与任务冻结 - -### D1：设备清点 - -- [ ] 记录RK3588工业盒型号、接口、内存和存储； -- [ ] 导出Ubuntu启动日志和设备树信息； -- [ ] 确认GPIO、CAN、RS485和网络可用性； -- [ ] 清点逻辑分析仪、示波器和功率计； -- [ ] 填写硬件软件版本清单初稿。 - -验收物：硬件清单、设备照片、接口表。 - -### D2：翼辉技术确认材料 - -- [ ] 完成会议提纲； -- [ ] 整理工业盒资料； -- [ ] 整理首个实验和模型算子清单； -- [ ] 向翼辉发送问题； -- [ ] 确定会议时间和双方接口人。 - -验收物：已发送的会议材料。 - -### D3：控制任务设计 - -- [ ] 冻结1 ms周期和1 ms截止期； -- [ ] 设计确定性任务体； -- [ ] 设计GPIO或CAN回环； -- [ ] 设计预分配日志缓冲； -- [ ] 定义释放、开始、完成时间戳。 - -验收物：控制任务说明和数据字段。 - -### D4：模型与数据选择 - -- [ ] 选择振动、电流或公开轴承数据； -- [ ] 定义输入窗口与类别； -- [ ] 建立小型1D CNN； -- [ ] 固定训练/验证划分； -- [ ] 确定Accuracy/F1阈值。 - -验收物：数据说明、模型结构和质量基线。 - -### D5：SylixOS路径结论 - -- [ ] 召开翼辉会议； -- [ ] 冻结推荐SylixOS/BSP/RealEvo版本； -- [ ] 判断现有工业盒兼容性； -- [ ] 明确CPU推理路径； -- [ ] 将NPU标记为可用、需适配或暂缓。 - -验收物：会议纪要和责任表。 - -## 第2周：基线和离线工具准备 - -### D6：开发环境 - -- [ ] 安装RealEvo与工具链； -- [ ] 获取或创建BSP/App工程； -- [ ] 完成Hello World、定时器和GPIO测试； -- [ ] 记录构建与部署步骤； -- [ ] 冻结Git提交和版本。 - -验收物：可重复构建的最小工程。 - -### D7：控制基线程序 - -- [ ] 实现周期任务； -- [ ] 实现时间戳记录； -- [ ] 实现内存缓冲日志； -- [ ] 实现截止期判定； -- [ ] 实现GPIO/CAN回环。 - -验收物：控制程序和原始数据样例。 - -### D8：模型量化与转换 - -- [ ] 训练或取得模型； -- [ ] 完成INT8量化； -- [ ] 导出固定格式； -- [ ] 统计算子、权重和中间张量； -- [ ] 比较FP32与INT8质量。 - -验收物：模型文件、校验值和量化报告。 - -### D9：静态资源报告 - -- [ ] 生成模型算子清单； -- [ ] 计算权重、Arena和工作区； -- [ ] 给出CPU推理时间初测； -- [ ] 形成首版任务与模型描述； -- [ ] 给出是否可进入板端的初步判定。 - -验收物：资源预算与准入报告v0.1。 - -### D10：复核与下一阶段冻结 - -- [ ] 控制基线至少独立运行5次； -- [ ] 保存样本数、分位数、最大值和违约数； -- [ ] 检查所有版本和配置记录； -- [ ] 更新首个实验冻结说明； -- [ ] 决定是否进入AI板端接入阶段。 - -验收物：两周总结和下一阶段Go/No-Go结论。 - -## 两周结束验收表 - -| 项目 | 必须完成 | 状态 | -|---|---|---| -| RK3588硬件与接口清单 | 是 | | -| 翼辉技术确认会议 | 是 | | -| SylixOS/BSP/RealEvo版本结论 | 是 | | -| 1 ms控制任务设计 | 是 | | -| 控制基线程序或明确阻塞项 | 是 | | -| INT8 1D CNN模型 | 是 | | -| 模型质量与资源报告 | 是 | | -| CPU推理路径结论 | 是 | | -| NPU路径结论 | 可标记暂缓 | | -| 下一阶段Go/No-Go | 是 | | - -## Go/No-Go规则 - -满足以下条件进入板端AI接入： - -- BSP稳定； -- 控制任务基线可信； -- CPU小模型可执行； -- 静态内存预算未超限； -- 计时和日志链路可用。 - -任一核心条件不满足时，输出阻塞项和责任人，不通过降低测量标准强行进入正式实验。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/README.md deleted file mode 100644 index 4b74623..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/README.md +++ /dev/null @@ -1,17 +0,0 @@ -# 30-实施管理 - -本层回答“使用现有设备如何开工、依赖是什么、什么时候Go/No-Go”。 - -## 文件 - -1. [00-基于现有设备的项目实施路线图.md](./00-基于现有设备的项目实施路线图.md)：WP0～WP7、设备依赖、里程碑和风险替代路线； -2. [01-两周执行计划与验收清单.md](./01-两周执行计划与验收清单.md)：D1～D10执行清单与阶段验收。 - -## 当前第一优先级 - -1. 确认RK3588工业盒的SylixOS BSP； -2. 跑通1 ms控制任务基线； -3. 在V100侧完成INT8 1D CNN和资源报告； -4. 不等待NPU，先完成CPU推理路径。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/00-合作方式与产业落点.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/00-合作方式与产业落点.md deleted file mode 100644 index 915830b..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/00-合作方式与产业落点.md +++ /dev/null @@ -1,96 +0,0 @@ -# 合作方式与产业落点 - -## 1. 合作结构 - -本子课题适合采用“研究团队 + 翼辉信息 + 芯片/板卡厂商 + 场景方”的四方结构。 - -| 参与方 | 主要职责 | -|---|---| -| 研究团队 | 问题定义、编排算法、实验设计、数据分析和论文 | -| 翼辉信息 | SylixOS/RealEvo、BSP、调度与内存接口、工程验证 | -| 芯片/板卡厂商 | 算子库、SDK、驱动、周期/功耗数据和硬件样机 | -| 场景方 | 控制任务、传感器数据、安全规则和验收约束 | - -## 2. 与翼辉信息的合作重点 - -### 2.1 平台准入 - -- 确认现有RK3588工业盒与官方BSP的兼容性； -- 确认RK3568、RK3576和真正MCU候选平台； -- 冻结SylixOS、BSP、编译器和RealEvo版本； -- 明确CPU、NPU、DMA、CAN、GPIO和看门狗支持边界。 - -### 2.2 实时机制 - -- 固定优先级、RMS和周期任务配置； -- 核绑定、中断亲和性和大小核调度； -- 静态内存、链接段和DMA连续内存； -- Cache一致性、任务/进程恢复和看门狗； -- 高精度时间戳与性能追踪。 - -### 2.3 工具链接口 - -- 外部编排器生成SylixOS App工程的方式； -- 链接脚本、任务配置和静态数组注入； -- RealEvo自动构建、上传、调试和数据回收； -- 生成代码与BSP版本兼容检查； -- 部署准入报告的联合格式。 - -## 3. 与芯片厂商的合作重点 - -- 算子支持矩阵和优化内核； -- 每个算子的工作区、周期和能耗数据； -- SRAM Bank、Cache、DMA和中断结构； -- 模型转换、代码生成和SDK接口； -- 低功耗状态、唤醒时间和功耗测量； -- 芯片规格与AI任务需求的反向协同。 - -## 4. 建议合作步骤 - -1. 完成现有设备、BSP和工具链盘点； -2. 选择一个电机状态识别或工业节点场景； -3. 在RK3588上完成CPU路径最小原型； -4. 接入SylixOS静态任务、超时和规则兜底； -5. 在NPU运行时准入后增加异构路径； -6. 向RK3568/RK3576收缩； -7. 共同选择真正MCU平台； -8. 形成参考工程、工具、样机和论文。 - -## 5. 产业落点 - -### 5.1 SylixOS静态智能任务开发套件 - -面向工业控制设备开发者，提供模型转换、资源预算、代码生成、部署检查和板端验证。 - -### 5.2 智能控制器升级方案 - -在不破坏原有控制和安全规则的前提下，为电机、泵、阀、PLC外围节点和设备控制盒增加异常识别与状态分类。 - -### 5.3 芯片适配与选型服务 - -用模型、控制任务和资源预算反向评估芯片、内存和加速器是否适合目标设备。 - -### 5.4 AI进入任务关键系统的准入规范 - -形成可复用的资源、时间、质量、故障和恢复检查表，而不只交付单个模型Demo。 - -## 6. 合作边界 - -- BSP或驱动未确认前，不承诺具体加速器性能； -- 不把SylixOS认证范围自动扩展到AI模型和完整应用； -- 不把模型平均速度当作实时安全证据； -- 不把场景方未确认的规则写成安全策略； -- 联合研究数据需冻结版本、设备编号和测量边界。 - -## 7. 首次技术会议建议清单 - -1. RK3588现有工业盒可复用的BSP； -2. RK3588/RK3568的核绑定和中断接口； -3. NPU运行时与驱动的可用状态； -4. 静态链接布局和内存域能力； -5. 看门狗、任务重启和局部恢复路径； -6. RealEvo外部生成工程接口； -7. lite/tiny目标和真正MCU支持清单； -8. 可开放的追踪、功耗和算子数据； -9. 联合参考板与首个工业场景； -10. 论文、白皮书、工具和知识产权分工。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/01-翼辉技术确认会议提纲.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/01-翼辉技术确认会议提纲.md deleted file mode 100644 index 5320100..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/01-翼辉技术确认会议提纲.md +++ /dev/null @@ -1,125 +0,0 @@ -# 翼辉技术确认会议提纲 - -> 会议目标：确认现有 RK3588 工业盒能否进入 SylixOS 实验，冻结首期 BSP、开发工具、运行时和测量接口，明确需要翼辉支持的工作。 - -## 1. 会前材料 - -- [ ] RK3588 工业盒型号、主板照片和硬件规格； -- [ ] CPU、内存、eMMC、网络、CAN、RS485、GPIO清单； -- [ ] 当前 Ubuntu 版本、设备树和启动日志； -- [ ] 拟运行的1 ms控制任务说明； -- [ ] INT8 1D CNN模型与算子清单； -- [ ] 预期对照实验和指标； -- [ ] 本会议问题清单提前发送给翼辉。 - -## 2. 项目说明 - -本项目拟研究： - -> 在 SylixOS 控制系统中，通过静态内存、固定优先级、固定推理窗口、部署准入和规则兜底，使轻量AI任务进入系统后不破坏关键控制任务的时间边界。 - -首期实验不依赖大模型，也不把NPU作为启动前提。计划先完成： - -- RK3588 + SylixOS； -- 1 ms周期控制任务； -- CPU执行的INT8 1D CNN； -- 控制与AI共存； -- 超时、过载、故障和规则兜底。 - -## 3. 必须确认的问题 - -### 3.1 板卡与BSP - -1. 现有工业盒是否兼容翼辉官方RK3588 BSP？ -2. 如果不完全兼容，需要提供哪些原理图、设备树和启动信息？ -3. 推荐使用哪个SylixOS版本、BSP版本和RealEvo版本？ -4. 当前BSP支持哪些CPU核、定时器、GPIO、CAN、RS485、网口、eMMC和NVMe？ -5. 是否支持SMP和大小核调度？ -6. BSP移植工作由哪一方负责，预计交付物是什么？ - -### 3.2 调度与计时 - -1. 周期任务推荐使用哪类定时器和任务接口？ -2. 是否支持固定优先级、RMS和CPU亲和性？ -3. 是否支持将控制任务固定到指定CPU核？ -4. 是否支持中断亲和性或中断线程化？ -5. 高精度单调时钟的分辨率和读取开销是多少？ -6. 推荐如何记录任务释放、开始、完成和截止期违约？ - -### 3.3 内存、Cache与DMA - -1. 如何在BSP或链接脚本中划分控制区、AI区和DMA区？ -2. 是否可为应用设置固定内存上限或独立内存区域？ -3. DMA连续内存如何申请和释放？ -4. Cache刷新、失效和一致性维护使用什么接口？ -5. 是否可以避免正式运行阶段的动态内存分配？ -6. 是否有内存峰值、碎片和泄漏监测工具？ - -### 3.4 推理运行时 - -1. SylixOS下是否已有可用的小模型CPU推理运行时？ -2. 是否支持TFLite Micro、ONNX Runtime裁剪版或翼辉自有方案？ -3. RK3588 NPU驱动是否可用？ -4. RKNN/RKLLM模型转换和运行时能否在SylixOS下工作？ -5. NPU提交、完成中断、DMA和统一内存路径是否可观测？ -6. 若NPU不可用，翼辉是否认可先完成CPU路径研究？ - -### 3.5 故障处理 - -1. RK3588看门狗在SylixOS中的推荐使用方式是什么？ -2. AI线程卡死后能否只重启线程或进程？ -3. 驱动异常是否可能影响关键控制任务？ -4. 如何记录任务异常、看门狗、重启和恢复事件？ -5. 是否有推荐的安全降级或双任务监控模式？ - -### 3.6 RealEvo与自动化 - -1. 外部工具能否生成或修改SylixOS App工程？ -2. 是否有命令行编译、部署和调试接口？ -3. 链接脚本、静态数组和任务配置如何自动注入？ -4. 是否支持批量运行测试和回收日志？ -5. 性能分析、代码覆盖率和远程调试工具如何使用？ - -### 3.7 真正MCU路线 - -1. 是否存在SylixOS lite/tiny产品形态？ -2. 支持哪些真正MCU或无MMU目标？ -3. 最小Flash、RAM和启动时间是多少？ -4. 推荐哪块参考板开展MCU实证？ -5. 是否有TinyML或轻量推理参考工程？ - -## 4. 希望翼辉提供的材料 - -- [ ] 推荐BSP与版本； -- [ ] 板卡兼容性判断； -- [ ] RealEvo安装包和开发文档； -- [ ] 周期任务、核绑定和高精度计时样例； -- [ ] DMA、Cache和静态链接布局样例； -- [ ] 看门狗和任务恢复样例； -- [ ] CPU推理运行时或移植建议； -- [ ] NPU支持状态说明； -- [ ] 真正MCU候选平台清单； -- [ ] 技术接口人与问题跟踪方式。 - -## 5. 会议输出 - -| 决策项 | 结论 | 责任方 | 完成时间 | 证据/链接 | -|---|---|---|---|---| -| RK3588 BSP | 待确认 | | | | -| SylixOS/RealEvo版本 | 待确认 | | | | -| CPU推理路径 | 待确认 | | | | -| NPU路径 | 待确认 | | | | -| 调度和计时接口 | 待确认 | | | | -| 内存和DMA接口 | 待确认 | | | | -| 故障恢复接口 | 待确认 | | | | -| 真正MCU候选 | 待确认 | | | | - -## 6. 会议结束判据 - -会议结束时至少应得到： - -1. RK3588能否进入SylixOS实验的明确结论； -2. 一个冻结的软件版本组合； -3. 一个CPU推理可行路径； -4. NPU路径是“可用、需适配或暂缓”的结论； -5. 双方责任人和下一次检查节点。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/02-预期成果与论文方向.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/02-预期成果与论文方向.md deleted file mode 100644 index f585dbc..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/02-预期成果与论文方向.md +++ /dev/null @@ -1,95 +0,0 @@ -# 预期成果与论文方向 - -## 1. 方法成果 - -1. 面向 MCU / 控制端的静态智能控制问题定义； -2. 控制任务、模型和平台的统一描述方法； -3. 小模型与控制任务离线联合编排方法； -4. 静态内存、固定推理窗口和有界通信设计； -5. 部署前资源、可调度性和安全准入方法； -6. 规则兜底、异常切换与恢复方法。 - -## 2. 工具与软件成果 - -- 模型解析、量化和算子合法化工具； -- 目标板算子执行时间与资源数据库； -- Tensor Arena与链接布局生成器； -- 控制任务与AI任务联合调度分析器； -- SylixOS C/C++任务包装与配置生成器； -- `PASS / PASS WITH LIMITS / REJECT`部署报告生成器； -- 板端采样、故障注入和数据汇总工具。 - -## 3. 原型与数据成果 - -### 原型A：RK3588 + SylixOS方法原型 - -完成控制任务、CPU小模型、静态Arena、固定窗口、超时和规则兜底的完整闭环。 - -### 原型B：控制端收缩原型 - -在RK3568/RK3576或等价平台上复现，并量化内存、功耗和BSP迁移成本。 - -### 原型C：真正MCU验证样机 - -完成KB/MB级内存、快速启动、`E/inference`和控制截止期验证。 - -### 数据集 - -- 控制任务时间序列； -- 算子和完整模型执行时间； -- 内存峰值与碎片； -- 功耗、温度和启动数据； -- 超时、过载、降级和恢复事件； -- 预测值与实测值误差。 - -## 4. 论文组织建议 - -不建议把所有设备和工具链塞入一篇论文。建议拆成三类成果。 - -### 论文1：静态联合编排方法 - -核心问题：模型和控制任务如何在部署前共同完成内存、时间和准入分析。 - -主要贡献：统一描述、静态内存规划、时间编排和预测—实测校准。 - -### 论文2：SylixOS控制端共存与故障隔离 - -核心问题：AI进入控制端后，SylixOS如何维持关键任务边界并限制故障传播。 - -主要贡献：固定优先级、核绑定、中断/DMA干扰、规则兜底和恢复实证。 - -### 论文3：真正MCU上的低功耗静态智能控制 - -核心问题：在极小SRAM、Flash和功耗预算下，静态智能任务的成立边界是什么。 - -主要贡献：内存极限、快速启动、`E/inference`和跨设备迁移。 - -## 5. 可使用的学术方向表述 - -- TinyML / Edge AI on MCU； -- 低功耗嵌入式智能系统； -- 静态部署与工具链协同； -- 实时控制中的小模型纳入； -- AI workload admission for real-time systems； -- predictable embedded inference； -- safety fallback for intelligent control。 - -## 6. 产业交付物 - -- 面向芯片与板卡的AI任务准入规范； -- SylixOS静态智能任务开发模板； -- 面向设备厂商的部署检查工具； -- 电机/泵/工业节点参考样机； -- 联合白皮书和基准测试报告； -- 芯片选型与模型适配矩阵。 - -## 7. 成果成熟度阶梯 - -| 阶段 | 可对外表述 | -|---|---| -| 仅RK3588方法原型 | 控制端SoC上的静态编排方法验证 | -| 增加RK3568/RK3576 | 跨控制端平台的迁移与收缩验证 | -| 增加真正MCU | 面向MCU的静态智能控制实证 | -| 形成工具和样机 | 可部署的开发套件与产业方案 | - -在真正MCU实验完成前，不将SoC结果表述为MCU极限结论。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/README.md deleted file mode 100644 index 62776c7..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/README.md +++ /dev/null @@ -1,17 +0,0 @@ -# 40-合作与成果 - -本层管理联合研究分工、翼辉技术确认和成果组织。 - -## 文件 - -1. [00-合作方式与产业落点.md](./00-合作方式与产业落点.md)：研究团队、翼辉、芯片厂商和场景方分工； -2. [01-翼辉技术确认会议提纲.md](./01-翼辉技术确认会议提纲.md)：第一次技术会议的问题、材料和输出模板； -3. [02-预期成果与论文方向.md](./02-预期成果与论文方向.md)：方法、工具、原型、数据、论文和产业交付物。 - -## 合作原则 - -- BSP或驱动未确认前，不承诺具体加速器性能； -- 不把SylixOS认证范围自动扩展到AI模型和完整应用； -- 联合数据必须冻结版本、设备编号和测量边界。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md index 38ef011..b7efb1d 100644 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md +++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md @@ -1,83 +1,24 @@ # 子课题A：面向MCU的静态智能控制基础系统 -本目录按“研究定义—技术框架—实验验证—实施管理—合作成果”分层管理，目标是把MCU研究方向落到现有RK3588、4×V100、SylixOS/RealEvo及后续控制端板卡上。 +本目录用于承接框架2中的第一个子课题，重点面向 `T5` 控制端与极小资源预算场景。 -## 一句话定位 +## 子课题定位 -> 把轻量智能模型转换为具有固定资源上限、固定执行窗口和明确故障处理方式的实时任务，并在部署前判断其能否安全进入SylixOS控制系统。 +本子课题重点研究： -## 目录结构 +> **在极小内存、极低功耗和强实时约束条件下，人工智能能力如何以静态、可分析、可部署的方式进入控制系统。** -```text -子课题A -├─ 00-总览与定位 研究对象、边界、问题和适用场景 -├─ 10-技术框架 总体技术路线与六步离线联合编排 -├─ 20-实验与验证 实验设计、冻结单和运行记录模板 -├─ 30-实施管理 设备路线图、工作包和两周计划 -├─ 40-合作与成果 翼辉合作、技术确认和成果组织 -└─ README.md 总导航 -``` +## 建议阅读顺序 -## 分层入口 +1. [00-子课题定义.md](./00-子课题定义.md) +2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md) +3. [02-技术路线：静态编排、工具链与芯片协同.md](./02-技术路线：静态编排、工具链与芯片协同.md) +4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md) +5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md) +6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md) -### 00-总览与定位 +## 当前特点 -- [子课题定义](./00-总览与定位/00-子课题定义.md) -- [研究问题与适用场景](./00-总览与定位/01-研究问题与适用场景.md) +本子课题的关键词是： -### 10-技术框架 - -- [总体技术路线](./10-技术框架/00-总体技术路线.md) -- [离线联合编排研究框架](./10-技术框架/01-离线联合编排研究框架.md) - -### 20-实验与验证 - -- [实验设计与验证方法](./20-实验与验证/00-实验设计与验证方法.md) -- [首个实验冻结说明](./20-实验与验证/01-首个实验冻结说明.md) -- [硬件软件版本清单模板](./20-实验与验证/02-硬件软件版本清单模板.md) -- [实验运行记录模板](./20-实验与验证/03-实验运行记录模板.md) - -### 30-实施管理 - -- [基于现有设备的项目实施路线图](./30-实施管理/00-基于现有设备的项目实施路线图.md) -- [两周执行计划与验收清单](./30-实施管理/01-两周执行计划与验收清单.md) - -### 40-合作与成果 - -- [合作方式与产业落点](./40-合作与成果/00-合作方式与产业落点.md) -- [翼辉技术确认会议提纲](./40-合作与成果/01-翼辉技术确认会议提纲.md) -- [预期成果与论文方向](./40-合作与成果/02-预期成果与论文方向.md) - -## 推荐阅读路线 - -### 理解研究框架 - -`00-总览与定位` → `10-技术框架` → `20-实验与验证/00-实验设计与验证方法.md` - -### 立即启动项目 - -`30-实施管理/01-两周执行计划与验收清单.md` → `40-合作与成果/01-翼辉技术确认会议提纲.md` → `20-实验与验证/01-首个实验冻结说明.md` - -### 执行正式实验 - -`20-实验与验证/02-硬件软件版本清单模板.md` → `20-实验与验证/03-实验运行记录模板.md` - -## 当前设备边界 - -- RK3588是控制端SoC方法原型，不是真正MCU； -- 4×V100用于模型训练、量化和离线工具； -- RK3568/RK3576用于控制端收缩和跨BSP验证； -- 严格MCU结论需要真正MCU实验板及对应BSP/运行时。 - -## 当前最小可行实验 - -- 平台：RK3588工业盒； -- 系统：SylixOS； -- 控制任务：1 ms周期任务与GPIO/CAN回环； -- AI任务：INT8 1D CNN状态识别； -- 机制：静态Arena、固定优先级、有界队列、超时和规则兜底； -- 目标：验证静态联合编排能否在AI负载下维持控制边界。 - -## 备份说明 - -本目录重组前的快照位于同级目录：`90-备份-子课题A-重组前-20260924`。备份仅用于回溯，不参与当前阅读和实验流程。 +`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算` diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/00-子课题定义.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-子课题定义.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/00-子课题定义.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-子课题定义.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md deleted file mode 100644 index 0ff33ce..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md +++ /dev/null @@ -1,444 +0,0 @@ -# 面向边侧异构SoC的混合实时控制基础系统研究综述 - -## 摘要 - -随着边缘人工智能从“离线感知”走向“在线决策”，边侧系统需要在同一异构SoC上同时承载硬实时控制、深度学习推理、设备管理、网络通信和人机交互等差异显著的工作负载。传统单一操作系统难以同时满足确定性、算力利用率、软件生态和故障隔离要求，Linux、实时操作系统（RTOS）、静态分区Hypervisor以及非对称多处理（AMP）相结合的混合系统因而成为重要技术路线。本文围绕边侧异构SoC上的混合实时控制基础系统，对实时Linux、双内核、AMP、静态分区虚拟化、共享资源干扰治理、GPU/NPU可预测执行、跨域通信以及安全降级等研究进行结构化综述。已有研究表明，处理器核、内存和设备的静态划分能够降低软件域之间的直接干扰，但共享末级缓存、内存控制器、DMA、片上互连、加速器驱动以及功耗热约束仍会形成难以忽略的跨域耦合；同时，平均推理速度、虚拟机切换开销和通信吞吐量均不能单独证明端到端实时性。本文据此提出“控制响应时间—AI结果新鲜度—资源干扰预算—故障恢复语义”四维分析框架，并给出适用于本课题的系统分工、评价指标和实验路线。综述认为，下一阶段的关键不在于简单选择Linux、RTOS或某一种Hypervisor，而在于形成可测量、可配置、可复现且可审查的系统级实时边界，使AI域失效、过载或超时时，控制域仍能维持安全状态。 - -**关键词：** 边缘人工智能；异构SoC；混合关键系统；实时操作系统；静态分区Hypervisor；共享资源干扰；NPU；安全降级 - ---- - -## 1 引言 - -边侧智能控制系统正从“传感器采集—云端分析”转向“本地感知—本地推理—本地闭环”。典型平台往往在单芯片中集成多核CPU、GPU、NPU、DSP、共享内存控制器、DMA和高速外设。一方面，Linux能够提供完整的AI运行时、设备驱动、网络协议栈和应用生态；另一方面，电机控制、运动控制、制动、保护和看门狗等任务要求低抖动、可分析的最坏响应时间及明确的故障处置责任。两类需求叠加后，系统设计问题从“模型是否足够快”扩展为“整个控制链在竞争、过载和故障条件下是否仍满足边界”。 - -Vestal提出的混合关键度任务模型揭示了同一计算平台上不同保证等级工作负载共存的基本矛盾[1]；后续综述表明，混合关键系统研究已经从处理器调度扩展到内存、I/O、通信、虚拟化和认证证据[2]。在边侧AI场景中，这一矛盾进一步表现为：AI任务通常具有高吞吐、突发性和运行时不透明等特征，而控制任务强调周期性、优先级、截止期和故障可控。因此，本文不把“Linux+RTOS”视为天然实时的答案，而是考察操作系统分工、虚拟化隔离、共享资源治理、跨域数据语义和安全降级如何共同构成实时保证。 - -本文的主要目的有三点： - -1. 梳理边侧异构SoC混合实时系统的主要技术形态及其适用边界； -2. 总结影响端到端确定性的关键干扰源、测量方法和治理机制； -3. 将已有研究转化为子课题B可执行的体系结构、实验问题和评价指标。 - -## 2 综述范围与方法 - -### 2.1 研究范围 - -本文关注部署在边侧异构SoC上的本地闭环系统，主要覆盖以下对象： - -- 实时Linux、双内核和协内核机制； -- Linux与RTOS并行运行的AMP系统； -- 静态分区Hypervisor、分离内核和微内核虚拟化； -- 多核共享缓存、DRAM、DMA、片上互连和加速器竞争； -- GPU/NPU推理的调度、抢占、可观测性和时延分析； -- 跨域共享内存、消息通道、时钟与状态同步； -- AI失效、超时和异常条件下的监测、隔离、降级与恢复。 - -本文不重点讨论云端训练、纯服务器推理、仅含单片机且没有多操作系统共存的系统，也不把平均帧率提升作为实时性研究的充分证据。 - -### 2.2 文献选择与证据使用 - -本文采用结构化叙述综述方法，检索和分析截至**2026年9月**公开的代表性研究论文、国际标准和项目官方资料。材料选择遵循以下原则： - -1. 优先采用原始论文、标准正文入口和项目官方文档； -2. 同时覆盖体系结构、调度与资源干扰、跨域通信、安全与评价方法； -3. 对尚缺乏开放实现或可复现实验的数据，仅作为研究趋势，不作为确定结论； -4. 对厂商或项目自述的能力，明确视为工程资料，而不等同于独立实验验证。 - -本文属于面向课题设计的结构化综述，不宣称穷尽全部文献，也不进行统计意义上的Meta分析。 - -## 3 核心概念与分析框架 - -### 3.1 混合实时控制系统的基本对象 - -本文所称“混合实时控制基础系统”，是指在同一边侧SoC上，以两个或多个执行域共同承载控制与智能任务的系统。典型职责划分如下： - -| 执行域 | 典型职责 | 主要保证目标 | -|---|---|---| -| RTOS/安全域 | 传感采集、控制律、执行器输出、联锁、看门狗、降级控制 | 截止期、低抖动、故障可控 | -| Linux/智能域 | AI推理、模型管理、复杂协议、日志、可视化、OTA | 算力与生态、功能完整性 | -| Hypervisor/分离层 | 核、内存、设备、中断与通信通道划分 | 空间隔离、故障约束、启动与生命周期管理 | -| GPU/NPU/DSP域 | 神经网络或信号处理加速 | 有界排队、可观测执行、资源预算 | - -这里的“混合”不是简单并存，而是要求各执行域之间存在明确的资源所有权、数据契约、时间边界和故障处置规则。 - -### 3.2 端到端实时边界 - -单独测量控制线程周期或模型推理时间会遗漏大量系统开销。对一次“采集—推理—决策—执行”链路，可采用下式描述端到端时延： - -\[ -L_{e2e}=L_{sense}+L_{input}+L_{queue}+L_{infer}+L_{ipc}+L_{validate}+L_{actuate} -\] - -其中，输入搬运、队列等待、跨域通信和结果校验都可能形成长尾。对高关键控制任务，其响应时间可进一步分解为： - -\[ -R_c=C_c+B_{os}+B_{hv}+I_{cpu}+I_{cache}+I_{dram}+I_{dma}+I_{irq}+I_{thermal} -\] - -式中，\(C_c\)为任务自身执行时间，\(B_{os}\)和\(B_{hv}\)分别为操作系统与虚拟化阻塞，\(I_*\)表示核、缓存、内存、DMA、中断和热降频等干扰。该分解并非假定各项严格独立，而是用于建立可测量的干扰清单和预算归属。 - -AI结果的有效性还应同时满足时间和内容条件： - -\[ -Valid(y)=Fresh(y)\land Integrity(y)\land Confidence(y)\land VersionMatch(y) -\] - -即结果必须未超过新鲜度窗口、数据完整、置信度满足策略且模型与协议版本匹配。由此可见，AI推理完成并不等于控制系统可以使用该结果。 - -## 4 系统形态及其适用边界 - -### 4.1 单Linux与PREEMPT_RT - -PREEMPT_RT通过可抢占内核、优先级继承锁和线程化中断等机制缩短Linux中的不可抢占区间[3]。这一方案保留了完整Linux生态，开发与部署成本较低，适合关键度中等、外设和AI软件栈复杂的系统。然而，它主要改善调度延迟，并不自动消除设备驱动长临界区、内存带宽竞争、GPU/NPU运行时阻塞、SMI等固件活动以及应用级故障。因此，“启用PREEMPT_RT并测得较低平均延迟”不能直接推出硬实时保证。 - -### 4.2 双内核或协内核 - -Xenomai Cobalt等双内核方案在Linux旁建立更高优先级的实时执行环境，使实时活动能够优先于普通Linux路径[4]。相较单Linux，该方案可以减小Linux负载对实时线程的直接影响，同时仍利用Linux驱动和应用生态。其代价是内核适配、系统调用迁移、调试链和版本维护复杂度增加；更重要的是，双内核仍共享缓存、DRAM和部分设备，不能仅依靠中断优先级解决片上共享资源干扰。 - -### 4.3 AMP：Linux与RTOS并行运行 - -AMP通常把不同CPU核交给Linux和RTOS独立管理，并通过共享内存和核间中断通信。OpenAMP及Linux remoteproc/RPMsg为远端处理器生命周期和消息通道提供了通用框架[5][6]。AMP结构适用于SoC已经包含应用核与实时核、设备所有权较易静态划分的场景。其优势是RTOS可以独立掌握控制循环和执行器；其局限在于启动顺序、共享内存一致性、地址映射、设备复位、故障传播和跨域优先级等通常依赖平台实现，系统级证据容易碎片化。 - -### 4.4 静态分区Hypervisor - -静态分区Hypervisor在启动阶段把CPU核、内存区域和设备分配给各客体，运行期尽量避免复杂的动态资源复用。Jailhouse采用Linux先启动、随后建立隔离单元的工程路径[7]；Bao强调面向嵌入式多核平台的轻量静态分区[8]；Xen Dom0-less、ACRN等也提供面向嵌入式或工业场景的不同部署模式[9][10]。静态分区减少了动态调度与频繁VM退出，便于构造较清晰的资源所有权。 - -但静态分区并非“物理隔离”的同义词。即使CPU核、内存页和设备已划分，不同分区仍可能共享末级缓存、内存控制器、片上互连、电源域和热设计功耗。Martins和Pinto对多种Arm静态分区Hypervisor的系统比较也说明，应同时评估中断延迟、通信、启动、代码规模和共享资源影响，而不能只比较虚拟化微基准开销[11]。 - -### 4.5 分离内核与高保证微内核 - -seL4等微内核通过能力机制和形式化验证强化空间隔离与内核正确性证据[12]。这类方案适合对可信计算基和认证证据要求较高的场景。不过，经过验证的内核并不意味着设备驱动、Hypervisor配置、硬件实现、AI运行时和应用任务的最坏执行时间也已经得到验证。因此，高保证内核应被视为证据链的一部分，而不是完整系统安全与实时性的替代品。 - -### 4.6 形态比较 - -| 形态 | 实时隔离潜力 | Linux生态 | 跨域协同成本 | 主要风险 | 适用场景 | -|---|---:|---:|---:|---|---| -| Linux + PREEMPT_RT | 中 | 高 | 低 | 内核、驱动与共享资源长尾 | 单域、中等关键度、快速产品化 | -| 双内核/协内核 | 中至高 | 较高 | 中 | 内核适配与共享硬件干扰 | 需要强实时线程但仍依赖Linux | -| AMP（Linux+RTOS） | 高 | 高 | 中至高 | 生命周期、共享内存与故障传播 | 应用核/实时核天然分离的SoC | -| 静态分区Hypervisor | 高 | 高 | 高 | 共享微体系结构资源与设备复位 | 多核SoC、关键域与智能域共存 | -| 分离内核/高保证微内核 | 高 | 中 | 高 | 驱动生态、系统集成与验证成本 | 高可信、高认证要求系统 | - -选择依据不应是“哪一种架构更先进”，而应是其能否满足具体设备所有权、截止期、AI软件栈、故障模型和认证目标。 - -## 5 共享资源干扰与确定性治理 - -### 5.1 干扰来源 - -边侧SoC上的干扰具有跨层特征： - -- **CPU与调度：** 核超售、优先级反转、不可抢占区、中断风暴； -- **缓存与一致性：** 末级缓存替换、缓存行争用、跨核一致性流量； -- **DRAM与互连：** 内存控制器队列、行缓冲冲突、bank冲突、总线仲裁； -- **DMA与I/O：** 摄像头、网络、存储和NPU的大块传输挤占带宽； -- **加速器：** 驱动队列、命令提交、不可抢占内核、上下文切换； -- **功耗与温度：** DVFS、热降频和共享电源预算导致执行时间漂移； -- **固件与管理域：** 安全监控、系统管理中断和不可见固件活动。 - -其中，CPU核独占只能消除部分调度竞争，无法消除共享缓存、DRAM、DMA和温度耦合。 - -### 5.2 缓存与内存治理 - -MemGuard通过按核带宽监管降低内存带宽争用，并为实时任务提供可控的内存预算[13]；PALLOC利用页着色和DRAM bank感知分配改善内存资源隔离[14]；面向多核并行任务的研究进一步表明，干扰上界需要考虑请求并行性，而不能把每次访存阻塞简单相加[15]。RT-Gang则通过限制高关键并行任务并发、控制内存带宽等方法降低与其他任务之间的不可预测干扰[16]。 - -这些工作共同说明，资源隔离需要“空间划分+时间监管+运行时监测”协同： - -1. 空间划分用于核、内存区域、缓存路和设备所有权； -2. 时间监管用于内存带宽、DMA窗口和加速器服务配额； -3. 运行时监测用于发现预算超限、热降频和异常排队； -4. 超限后的处置必须预先定义，不能只记录日志而继续无界运行。 - -### 5.3 从资源指标到控制指标 - -内存带宽、缓存未命中率和DMA吞吐是解释变量，而不是最终验收指标。研究应建立以下因果链： - -> 资源竞争强度 → 控制任务响应时间变化 → 截止期违约 → 控制品质或安全状态变化。 - -因此，资源治理机制必须同时报告其对控制抖动、最大响应时间、AI新鲜度和业务吞吐的影响，避免以牺牲AI功能到不可用为代价获得表面上的实时改善。 - -## 6 GPU/NPU推理的可预测执行 - -### 6.1 主要困难 - -GPU/NPU的峰值算力不能代表其实时能力。边侧AI加速器常见的不确定性包括： - -- 驱动和固件内部排队策略不可见； -- 多模型或多进程共享时缺少明确优先级； -- 神经网络算子或命令批次难以中途抢占； -- CPU预处理、内存复制和后处理未计入“推理时间”； -- 统一内存减少显式复制，但可能增加缓存一致性和带宽竞争； -- 温控、功耗封顶和动态频率改变长时间运行结果。 - -### 6.2 代表性调度研究 - -GPUart探索了嵌入式GPU上的受限抢占和面向应用的实时调度[17]；GPU server将GPU请求集中到服务任务中，以改善共享GPU时的优先级管理和分析性[18]；GCAPS进一步从GPU上下文与优先级角度研究多核实时任务的加速器调度[19]。RT-Gang等工作也把DNN工作负载纳入共享资源干扰实验[16]。这些成果证明，加速器实时化需要调度协议、驱动机制和可分析模型共同支持，而不是仅在应用层设置线程优先级。 - -现有GPU研究相对丰富，而NPU通常具有更封闭的编译器、运行时和固件接口。在缺乏公开抢占机制和执行模型时，本课题应采用“黑盒可测、边界可控”的工程策略：固定模型与编译产物，冻结驱动和固件版本，测量提交、排队、执行和完成通知的独立时间戳，并通过准入控制限制并发模型、输入频率和队列深度。 - -### 6.3 AI结果新鲜度优先于平均吞吐 - -控制系统对AI输出的核心约束通常不是每秒帧数，而是： - -- 最迟何时得到结果； -- 结果对应哪一帧、哪一时刻和哪一模型版本； -- 超时后旧结果是否会被误用； -- 连续多少次无有效结果后必须降级； -- 恢复后需要满足什么条件才能重新参与控制。 - -因此，建议同时记录平均值、P99/P99.9、观测最大值、截止期违约率和连续违约长度，并强调：有限测试中的“零违约”只是实验观察，不是数学意义上的最坏情况证明。 - -## 7 跨域通信与协同协议 - -### 7.1 通信机制 - -Linux与RTOS之间常采用共享内存环形队列、核间中断、RPMsg、虚拟串口或虚拟网络。共享内存可以降低复制开销，但其确定性仍取决于缓存维护、内存屏障、接收端调度和队列策略。Dong等提出的混合双操作系统实时通信机制表明，跨域RPC需要显式处理优先级和同步语义，单纯追求吞吐不足以满足实时交互[20]。 - -对于板间或设备间通信，DDS和IEEE TSN分别提供数据分发QoS及确定性以太网相关标准框架[21][22]。它们可用于外部网络的优先级、时钟和传输治理，但不能替代片上共享内存与接收端调度分析。 - -### 7.2 消息契约 - -本课题中的跨域消息至少应包含： - -| 字段 | 作用 | -|---|---| -| 序列号 | 检测重复、乱序与丢失 | -| 采集时间戳 | 计算结果年龄和端到端时延 | -| 截止时间/有效期 | 在RTOS侧拒绝过期结果 | -| 模型与协议版本 | 防止版本不一致 | -| 置信度与质量标志 | 支持结果准入与降级策略 | -| 完整性校验 | 检测传输或内存破坏 | -| 运行状态 | 表示Linux、NPU及数据源健康状态 | - -队列宜采用有界设计。对状态估计类数据，通常应优先保留最新值而不是无限堆积旧值；RTOS控制线程不应因等待Linux或NPU结果而无界阻塞。 - -### 7.3 时间同步与因果一致性 - -跨域分析必须区分采集时间、发送时间、接收时间、推理完成时间和执行器生效时间。若各域时钟来源不同，应定义同步方式和最大偏差；若共享同一硬件时钟，也应验证虚拟化层的时间暴露和暂停语义。没有统一时间基准，就无法可靠判断AI结果是否新鲜，也无法把一次截止期违约定位到采集、排队、推理还是通信阶段。 - -## 8 故障隔离、安全降级与恢复 - -### 8.1 控制权归属 - -面向安全相关控制，建议把最终执行器控制权、超时判定和降级状态机保留在RTOS/安全域。Linux/AI域提供建议值、目标值或感知结果，而不是未经校验直接驱动执行器。已有面向AI实时信息物理系统的研究在异构平台上采用Linux承载AI、FreeRTOS承载安全功能，并通过共享内存通道、健康监视和结果新鲜度校验实现故障兜底[23]，这与本课题方向高度一致。 - -### 8.2 需要覆盖的故障模型 - -至少应包含： - -- Linux用户进程崩溃、内核卡死或重启； -- NPU驱动超时、固件异常、队列停滞； -- 跨域消息丢失、乱序、重复、损坏和版本不匹配； -- AI结果低置信、越界、过期或持续不可用； -- DMA越界、设备复位影响其他域； -- 内存或互连过载导致控制任务长尾； -- 温度过高、降频和电源预算收缩； -- RTOS健康监测本身失效或误判。 - -### 8.3 标准语境 - -ISO 26262面向道路车辆功能安全[24]，ISO 21448关注预期功能安全及感知、算法能力不足等非故障风险[25]，ISO/PAS 8800进一步聚焦道路车辆AI安全[26]。三者关注点不同：软件或硬件故障、功能性能局限、AI特有不足不能混为一类。若本课题面向工业或其他领域，也应映射到相应功能安全标准，而不是直接宣称符合汽车标准。 - -AUTOSAR Adaptive Platform为高性能ECU提供了面向服务的软件架构和执行管理机制[27]。这类行业框架有助于定义进程生命周期和接口，但系统确定性仍取决于底层调度、资源隔离、设备路径和具体部署配置。 - -### 8.4 降级与恢复语义 - -完整的兜底机制应定义以下状态： - -`正常协同 → AI结果异常/超时 → 降级控制 → 故障隔离 → 服务恢复验证 → 受控重新接入` - -其中，“Linux已重启”不等于“AI可以重新参与控制”。重新接入至少需要完成模型版本校验、通道清空、连续健康样本确认、时间同步检查和状态重建。恢复期间应继续由RTOS维持安全控制策略。 - -## 9 国内外研究进展综合 - -### 9.1 国外研究脉络 - -国外研究大致形成四条相互衔接的路线： - -1. **混合关键度调度理论：** 从不同关键等级任务的执行时间假设和模式切换出发，研究可调度性与服务降级[1][2]； -2. **分区与虚拟化：** 通过Jailhouse、Bao、Xen、ACRN、seL4等降低操作系统之间的直接耦合[7]-[12]； -3. **共享资源分析：** 从内存带宽监管、DRAM bank划分、并行请求分析和gang调度等角度控制多核干扰[13]-[16]； -4. **AI与加速器实时化：** 从GPU调度逐步扩展到DNN负载、异构平台协同和AI故障兜底[17]-[19][23]。 - -总体趋势是由“降低虚拟化开销”转向“给出系统级时间与故障证据”，评价对象也从单次VM退出或IPC时延扩展到端到端控制链。 - -### 9.2 国内公开研究与工程实践 - -国内公开成果在混合双操作系统通信、嵌入式虚拟化和国产实时操作系统工程适配方面已有积累。例如，面向TrustZone的混合双操作系统实时RPC研究关注了跨域通信中的优先级与可预测性[20]；湖南大学嵌入式与网络计算实验室公开的ZVM项目面向嵌入式多核平台提供虚拟化研究与原型基础[28]。同时，国产RTOS和行业SoC生态为本土化验证提供了工程条件。 - -但从公开、可复现证据看，仍缺少把国产SoC、国产RTOS、Linux、NPU运行时和完整闭环控制统一起来的基准套件；尤其缺少共享NPU/DDR压力下的截止期数据、跨域故障注入记录和可复用安全降级协议。因此，国内工程适配不应只停留在“系统成功启动、域间能够通信”，而应转向边界测量和证据固化。 - -### 9.3 代表性研究对比 - -| 研究/项目 | 主要对象 | 核心贡献 | 对本课题的启示 | 主要局限 | -|---|---|---|---|---| -| Vestal[1] | 混合关键任务 | 建立不同保证等级执行时间模型 | 明确控制域与AI域保证等级 | 未覆盖现代异构加速器 | -| PREEMPT_RT[3] | 实时Linux | 降低Linux内核不可抢占延迟 | 可作为低成本基线 | 不提供完整空间/故障隔离 | -| Jailhouse[7] | 静态分区 | Linux辅助建立硬件分区 | 工程集成路径清晰 | 共享资源仍需单独治理 | -| Bao[8] | 轻量Hypervisor | 面向嵌入式多核的静态分区 | 适合研究小型可信基 | 设备生态和平台适配成本较高 | -| seL4[12] | 高保证微内核 | 提供形式化内核正确性证据 | 支持高可信隔离证据链 | 不覆盖整机时序与AI栈 | -| MemGuard/PALLOC[13][14] | DRAM干扰 | 带宽监管与bank感知分配 | 建立内存预算与隔离基线 | 需适配具体内存控制器 | -| RT-Gang[16] | 多核/DNN负载 | 限制关键并行任务间干扰 | 适合AI与控制共存实验 | 可能降低总体吞吐 | -| GPUart/GCAPS[17][19] | GPU实时调度 | 抢占、优先级与可分析调度 | 为NPU治理提供方法参照 | GPU机制不能直接移植到封闭NPU | -| RTRG-RPC[20] | 双OS通信 | 跨域RPC及优先级协同 | 通信协议必须携带实时语义 | 仍需结合共享资源分析 | -| Cittadini等[23] | AI+RTOS+Hypervisor | 健康监测、新鲜度验证和兜底 | 与本课题体系结构高度对应 | 平台与应用特定，需跨平台复现 | - -## 10 现有研究的主要不足 - -### 10.1 证据链条分散 - -Hypervisor论文常强调隔离和切换开销，实时调度论文关注任务响应时间，AI系统论文关注吞吐和准确率，安全研究关注风险与降级。这些证据通常来自不同平台、负载和测量口径，尚未自然组合成“传感输入到执行器输出”的完整论证。 - -### 10.2 NPU运行时缺乏可分析接口 - -相较CPU和部分GPU，边侧NPU的队列策略、固件执行、抢占粒度和内部内存流量往往不公开。这使传统WCET分析难以直接应用，也容易造成“推理平均值稳定、极端情况下却阻塞控制域”的风险。 - -### 10.3 跨域优先级与新鲜度缺乏统一语义 - -一个高优先级RTOS任务发出的请求，进入Linux驱动、NPU队列和回传通道后可能丢失原有优先级；即使及时返回，也可能对应已经过期的传感帧。现有IPC性能测试往往只测往返时间，未同时验证数据年龄、版本和接收端可用性。 - -### 10.4 动态治理与可认证性存在张力 - -动态调整核、带宽和加速器配额可以提高平均利用率，但增加了状态空间和时序分析复杂度。如何在不破坏高关键域保证的前提下，让AI域使用剩余资源，是系统设计中的关键权衡。 - -### 10.5 故障恢复研究弱于故障检测 - -许多系统能够检测Linux或AI任务异常，但对清理旧消息、重建共享状态、验证模型版本和安全重新接入缺少明确协议。若恢复路径未被测试，其风险可能高于直接维持降级模式。 - -## 11 面向子课题B的研究框架 - -### 11.1 建议体系结构 - -本课题宜采用“RTOS掌握控制权、Linux承载智能栈、Hypervisor实施静态隔离、共享内存执行有界通信”的主线： - -```text -传感器 ──> RTOS/安全域 ──> 基础控制与执行器 - │ - ├─ 有界输入通道 ─> Linux/AI域 ─> NPU/GPU - │ │ - └─ 新鲜度/完整性校验 <── 有界结果通道 - -Hypervisor：CPU核、内存、设备、中断和通信区域静态划分 -资源监测器：DDR、DMA、加速器队列、温度、截止期与故障状态 -``` - -RTOS不等待AI结果完成才推进控制周期；当AI结果有效时，可用于修正目标、估计状态或优化控制参数；当结果超时、异常或不可用时，立即保持基础控制或切换到预定义安全策略。 - -### 11.2 建议研究问题 - -| 编号 | 研究问题 | 可验证假设 | -|---|---|---| -| RQ1 | 静态分区能否显著降低Linux负载对控制任务的影响？ | 核、内存和设备划分后，控制时延长尾下降，但DDR/DMA压力下仍存在残余干扰 | -| RQ2 | 哪些共享资源是目标SoC的主要瓶颈？ | 干扰贡献与工作负载类型有关，可由硬件计数器、带宽和时延联合识别 | -| RQ3 | AI输出怎样在控制域中安全使用？ | 带时间戳、版本、置信度和有效期的有界协议可消除旧结果误用 | -| RQ4 | Linux/NPU故障是否会突破控制实时边界？ | 执行器归RTOS所有且通道非阻塞时，AI域故障可被限制在预设恢复时间内 | -| RQ5 | 资源治理的性能代价是多少？ | 合理配额可换取长尾稳定性，但存在吞吐—确定性折中曲线 | - -### 11.3 建议实验矩阵 - -实验应至少设置四类对照： - -1. 普通Linux； -2. Linux + PREEMPT_RT； -3. Linux/RTOS共存但不启用完整资源治理； -4. 静态分区Hypervisor + RTOS控制域 + Linux智能域 + 资源治理与兜底机制。 - -每类系统分别施加以下压力： - -- CPU计算压力； -- LLC/DRAM带宽压力； -- 摄像头、网络、存储和DMA并发； -- 多模型或多流NPU/GPU推理； -- 高温、降频和长时运行； -- Linux崩溃、AI进程退出、NPU超时、消息损坏与通信中断。 - -### 11.4 建议评价指标 - -| 维度 | 核心指标 | -|---|---| -| 控制实时性 | 周期抖动、响应时间分布、观测最大值、截止期违约率、最长连续违约 | -| AI时效性 | 输入年龄、队列等待、推理时延、端到端时延、有效结果率、过期丢弃率 | -| 资源隔离 | DDR带宽、LLC未命中、DMA流量、加速器队列深度、干扰放大系数 | -| 通信 | 单向/往返时延、抖动、丢包/覆盖、队列水位、时钟偏差 | -| 故障安全 | 检测时间、隔离时间、降级切换时间、安全状态保持率、受控恢复时间 | -| 功耗热 | 功耗、温度、频率状态、热稳态前后时延变化 | -| 控制品质 | 超调量、稳态误差、整定时间、轨迹误差或任务特定安全指标 | - -实验报告必须同时记录硬件型号、内核和RTOS版本、Hypervisor提交、固件/驱动、模型哈希、编译参数、频率策略、环境温度、负载脚本和原始日志。否则，所谓“实时改善”难以复现和比较。 - -### 11.5 预期创新点 - -结合现有研究空白，子课题B可把创新集中在以下四点： - -1. **系统级实时边界模型：** 将控制响应时间与AI结果新鲜度放在同一端到端链路中分析； -2. **异构共享资源预算：** 建立CPU、DDR、DMA、NPU/GPU及温度干扰的测量与预算方法； -3. **跨域安全数据契约：** 形成包含时间戳、版本、置信度、有效期和恢复代次的有界协议； -4. **故障注入与证据闭环：** 通过Linux/NPU/通信故障注入验证降级、隔离和重新接入，而非只验证正常路径。 - -## 12 结论 - -边侧异构SoC上的混合实时控制不是单一操作系统、单一Hypervisor或单一调度算法可以独立解决的问题。PREEMPT_RT、双内核、AMP、静态分区和高保证微内核各有适用范围；核与内存静态划分能够减少直接干扰，却不能自动消除共享缓存、DRAM、DMA、加速器和热约束带来的长尾。AI任务的评价也必须从平均吞吐转向结果新鲜度、连续违约和故障条件下的可用性。 - -对本课题而言，最稳妥的研究主线是：把执行器控制权和降级状态机固定在RTOS域，把复杂AI生态放在Linux域，用Hypervisor和硬件机制建立资源边界，用有界通信协议传递可校验的AI结果，并通过混合压力与故障注入形成系统级证据。最终成果不应只是“Linux与RTOS可以同时运行”，而应回答在何种资源预算、负载和故障条件下，控制截止期仍可维持、AI结果仍可使用、系统仍可安全降级。 - -## 参考文献 - -[1] VESTAL S. Preemptive Scheduling of Multi-criticality Systems with Varying Degrees of Execution Time Assurance[C]//Proceedings of the 28th IEEE International Real-Time Systems Symposium. 2007: 239-243. DOI: [10.1109/RTSS.2007.47](https://doi.org/10.1109/RTSS.2007.47). - -[2] BURNS A, DAVIS R I. A Survey of Research into Mixed Criticality Systems[J]. ACM Computing Surveys, 2018, 50(6). DOI: [10.1145/3131347](https://doi.org/10.1145/3131347). - -[3] THE LINUX KERNEL DOCUMENTATION. Real-time preemption[EB/OL]. [2026-09-28]. [https://www.kernel.org/doc/html/latest/core-api/real-time/index.html](https://www.kernel.org/doc/html/latest/core-api/real-time/index.html). - -[4] XENOMAI PROJECT. Xenomai 3 Overview[EB/OL]. [2026-09-28]. [https://v3.xenomai.org/overview/](https://v3.xenomai.org/overview/). - -[5] OPENAMP PROJECT. OpenAMP Overview[EB/OL]. [2026-09-28]. [https://openamp.readthedocs.io/en/latest/openamp/overview.html](https://openamp.readthedocs.io/en/latest/openamp/overview.html). - -[6] THE LINUX KERNEL DOCUMENTATION. Remote Processor Messaging (rpmsg) Framework[EB/OL]. [2026-09-28]. [https://www.kernel.org/doc/html/latest/staging/rpmsg.html](https://www.kernel.org/doc/html/latest/staging/rpmsg.html). - -[7] RAMSAUER R, KISZKA J, LOHMANN W, et al. Look Mum, no VM Exits! (Almost)[EB/OL]. 2017. [https://arxiv.org/abs/1705.06932](https://arxiv.org/abs/1705.06932). - -[8] MARTINS J, TAVARES A, SOLIERI M, BERTOGNA M, PINTO S. Bao: A Lightweight Static Partitioning Hypervisor for Modern Multi-Core Embedded Systems[C]//Next Generation Real-Time Embedded Systems. 2020. DOI: [10.4230/OASIcs.NG-RES.2020.3](https://doi.org/10.4230/OASIcs.NG-RES.2020.3). - -[9] XEN PROJECT. True Static Partitioning with Xen Dom0-less[EB/OL]. [2026-09-28]. [https://xenproject.org/blog/true-static-partitioning-with-xen-dom0-less/](https://xenproject.org/blog/true-static-partitioning-with-xen-dom0-less/). - -[10] LI S, KWEON S, YANG X, et al. ACRN: A Big Little Hypervisor for IoT Development[C]//Proceedings of the 15th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. 2019. DOI: [10.1145/3313808.3313816](https://doi.org/10.1145/3313808.3313816). - -[11] MARTINS J, PINTO S. Shedding Light on Static Partitioning Hypervisors for Arm-based Mixed-Criticality Systems[C]//2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium. 2023. DOI: [10.1109/RTAS58335.2023.00011](https://doi.org/10.1109/RTAS58335.2023.00011). - -[12] KLEIN G, ELPHINSTONE K, HEISER G, et al. seL4: Formal Verification of an OS Kernel[C]//Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles. 2009. DOI: [10.1145/1629575.1629596](https://doi.org/10.1145/1629575.1629596). - -[13] YUN H, YAO G, PELLIZZONI R, et al. MemGuard: Memory Bandwidth Reservation System for Efficient Performance Isolation in Multi-core Platforms[C]//2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium. 2013. DOI: [10.1109/RTAS.2013.6531079](https://doi.org/10.1109/RTAS.2013.6531079). - -[14] YUN H, MANCUSO R, WU Z P, PELLIZZONI R. PALLOC: DRAM Bank-Aware Memory Allocator for Performance Isolation on Multicore Platforms[C]//2014 IEEE 20th Real-Time and Embedded Technology and Applications Symposium. 2014. DOI: [10.1109/RTAS.2014.6925999](https://doi.org/10.1109/RTAS.2014.6925999). - -[15] YUN H, PELLIZZONI R, VALSAN P K. Parallelism-Aware Memory Interference Delay Analysis for COTS Multicore Systems[C]//27th Euromicro Conference on Real-Time Systems. 2015: 184-195. DOI: [10.1109/ECRTS.2015.24](https://doi.org/10.1109/ECRTS.2015.24). - -[16] ALI W, YUN H. RT-Gang: Real-Time Gang Scheduling Framework for Safety-Critical Systems[C]//2019 IEEE Real-Time and Embedded Technology and Applications Symposium. 2019. DOI: [10.1109/RTAS.2019.00020](https://doi.org/10.1109/RTAS.2019.00020). - -[17] HARTMANN C, MARGULL U. GPUart: An Application-Based Limited Preemptive GPU Real-Time Scheduler for Embedded Systems[J]. Journal of Systems Architecture, 2019, 97: 304-319. DOI: [10.1016/j.sysarc.2018.10.005](https://doi.org/10.1016/j.sysarc.2018.10.005). - -[18] KIM H, PATEL P, WANG S, RAJKUMAR R. A Server-Based Approach for Predictable GPU Access with Improved Analysis[J]. Journal of Systems Architecture, 2018, 88: 97-109. DOI: [10.1016/j.sysarc.2018.05.003](https://doi.org/10.1016/j.sysarc.2018.05.003). - -[19] WANG Y, LIU C, WONG D, KIM H. GCAPS: GPU Context-Aware Preemptive Priority-Based Scheduling for Real-Time Tasks[C]//36th Euromicro Conference on Real-Time Systems. 2024. DOI: [10.4230/LIPIcs.ECRTS.2024.14](https://doi.org/10.4230/LIPIcs.ECRTS.2024.14). - -[20] DONG P, JIANG Z, BURNS A, DING Y, MA J. Build Real-Time Communication for Hybrid Dual-OS System[J]. Journal of Systems Architecture, 2020, 107: 101774. DOI: [10.1016/j.sysarc.2020.101774](https://doi.org/10.1016/j.sysarc.2020.101774). - -[21] OBJECT MANAGEMENT GROUP. Data Distribution Service Specification[EB/OL]. [2026-09-28]. [https://www.omg.org/spec/DDS/](https://www.omg.org/spec/DDS/). - -[22] IEEE 802.1 TIME-SENSITIVE NETWORKING TASK GROUP. Time-Sensitive Networking[EB/OL]. [2026-09-28]. [https://1.ieee802.org/tsn/](https://1.ieee802.org/tsn/). - -[23] CITTADINI E, MARINONI M, BIONDI A, CICERO G, BUTTAZZO G. Supporting AI-Powered Real-Time Cyber-Physical Systems on Heterogeneous Platforms via Hypervisor Technology[J]. Real-Time Systems, 2023, 59: 609-635. DOI: [10.1007/s11241-023-09402-4](https://doi.org/10.1007/s11241-023-09402-4). - -[24] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 26262 Road Vehicles—Functional Safety[EB/OL]. [2026-09-28]. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html). - -[25] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21448:2022 Road Vehicles—Safety of the Intended Functionality[EB/OL]. [2026-09-28]. [https://www.iso.org/standard/77490.html](https://www.iso.org/standard/77490.html). - -[26] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/PAS 8800:2024 Road Vehicles—Safety and Artificial Intelligence[EB/OL]. [2026-09-28]. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html). - -[27] AUTOSAR. Adaptive Platform[EB/OL]. [2026-09-28]. [https://www.autosar.org/standards/adaptive-platform/](https://www.autosar.org/standards/adaptive-platform/). - -[28] 湖南大学嵌入式与网络计算实验室. ZVM嵌入式虚拟化项目[EB/OL]. [2026-09-28]. [https://esnl.hnu.edu.cn/zvm/](https://esnl.hnu.edu.cn/zvm/). - ---- - -> 说明：本文中的公式、四维分析框架、建议体系结构、研究问题与实验矩阵，是在所引文献基础上针对子课题B形成的综合研究设计，不是对某一篇文献结论的直接复述。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md deleted file mode 100644 index 81648b5..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md +++ /dev/null @@ -1,278 +0,0 @@ -# 主流异构边侧设备与AI模型性能指标综述 - -## 摘要 - -边侧智能控制设备正从单一CPU或GPU计算平台，演进为同时集成应用核、实时核、GPU、NPU/DLA、DSP、ISP、FPGA可编程逻辑和多类I/O加速单元的异构系统。对这类平台进行选型时，仅比较TOPS会遮蔽模型精度、权重体积、算子落点、内存带宽、运行时回退、队列等待、功耗模式和尾时延等关键差异。本文结合前期《面向边侧异构SoC的混合实时控制基础系统研究综述》和《工程应用场景与性能指标对标》，对NVIDIA Jetson Orin、Rockchip RK3588、TI TDA4VM、NXP i.MX 8M Plus、Qualcomm QRB5165/RB5、Hailo-8和AMD Kria K26等代表性设备的计算组成、标称算力、存储资源、功耗与推理软件栈进行对比；同时以MobileNetV3、YOLOv8、Octo、OpenVLA及边缘VLA工作负载为例，分析参数量、权重精度、训练/任务精度、量化损失、推理时间和端到端控制频率之间的关系。本文进一步给出面向子课题B的统一报告模板和分层实验矩阵，使“峰值算力—模型质量—平均性能—尾时延—控制安全”能在同一证据链中进行审查。 - -**关键词：** 异构SoC；边缘AI；模型权重；混合精度；量化；推理时延；尾延迟；具身智能；混合实时系统 - ---- - -## 1 研究对象及与前两篇综述的关系 - -前期国内外研究综述主要回答“Linux、RTOS、Hypervisor和AI加速器如何共存”，并将研究重点放在资源隔离、共享资源干扰、跨域通信和安全降级上。工程应用场景文档主要回答“这些问题在人形/四足机器人、移动操作、巡检和EtherCAT控制中如何落地”。 - -本文作为第三篇独立综述，聚焦于二者之间尚缺的“设备—模型—运行时—实时指标”对应关系： - -1. 设备端具有哪些异构计算单元，其标称算力和存储资源是多少； -2. 模型的参数量、权重位宽、活化值和中间缓冲如何占用内存； -3. “训练精度”、“数值精度”和“任务准确率”应如何区分； -4. 推理时间究竟是纯硬件执行、运行时API返回，还是传感器到执行器的端到端时间； -5. 平均FPS很高的平台，在AI、DMA、网络和存储并发时是否仍能维持控制周期的P99.9和观测最大值。 - -因此，本文中的数据不用于简单给出设备排名，而用于建立实验选型和结果解释的基准。 - -## 2 性能指标的统一语义 - -### 2.1 峰值算力不等于模型性能 - -TOPS通常表示每秒可执行的万亿次基本操作，但其数值受计数方式、数据精度和稀疏性假设影响。例如Jetson Orin官方表格中的整体AI性能明确标为稀疏INT8 TOPS，而同页又另列GPU Tensor Core的稠密INT8性能[1]。因此，不能直接把某厂商的稀疏INT8 TOPS与另一厂商的稠密INT8、FP16 TFLOPS或可配置DPU单元数进行比例换算。 - -对任一实际模型，性能还取决于： - -- 算子是否全部被加速器支持，是否回退到CPU/GPU； -- 张量排布转换、量化/反量化和外部算子的开销； -- 权重、活化值和特征图是否受内存带宽限制； -- 动态形状、batch大小、多流和多模型并发方式； -- 功耗档位、频率锁定、温度以及热降频状态； -- 运行时、编译器、驱动、固件和模型编译产物版本。 - -### 2.2 模型权重与内存占用 - -若模型参数量为\(N_p\)，每个权重位宽为\(b\)，则仅权重的理论容量为： - -\[ -S_{weight}=N_p\times b/8 -\] - -例如7B参数模型的理论权重容量约为：FP32 28 GB、FP16/BF16 14 GB、INT8 7 GB、INT4 3.5 GB。这些数字不包括视觉编码临时张量、KV cache、活化值、量化尺度/零点、运行时工作区、图优化副本及I/O缓冲。因此，“权重能放入内存”不等于“模型能稳定运行”。 - -本课题建议分开报告五个内存量：原始模型文件、编译后引擎/私有格式、常驻权重、峰值活化与工作区、进程峰值常驻内存（RSS）或设备内存峰值。 - -### 2.3 “精度”需要区分三种含义 - -| 精度类型 | 常见取值 | 它回答的问题 | 必须同时记录的信息 | -|---|---|---|---| -| 训练数值精度 | FP32、FP16、BF16、混合精度 | 梯度、权重更新和前/反向计算用什么数值格式 | 优化器、loss scaling、训练硬件、时长、数据集版本 | -| 部署/推理精度 | FP32、FP16/BF16、INT8、INT4、W4A16等 | 权重和活化值如何存储与计算 | PTQ或QAT、校准集、逐张量/逐通道、对称/非对称 | -| 任务质量 | Top-1/Top-5、mAP、mIoU、WER、任务成功率 | 模型完成实际任务的质量 | 数据集、划分、输入尺寸、评估脚本、随机种子、置信区间 | - -用户所说的“训练精度”在工程文档中经常同时指数值精度和准确率。本文统一将二者分写为“训练/部署位宽”和“任务质量”，避免把“INT8”误读为“80%准确率”。 - -### 2.4 推理时间的五层口径 - -| 层级 | 延迟定义 | 包含内容 | 主要用途 | -|---|---|---|---| -| L0 | 算子/核函数时间 | 单个算子或融合核执行 | 算子库与瓶颈分析 | -| L1 | 设备执行时间 | 加速器从接受到完成图执行 | 比较编译产物和计算核 | -| L2 | 运行时推理时间 | API调用、提交、排队、同步和图执行 | 单模型部署基准 | -| L3 | 应用流水线时间 | 预处理+推理+后处理+主机/设备搬运 | 视觉或多模态应用评价 | -| L4 | 端到端控制时间 | 采集、队列、预处理、推理、IPC、校验、控制与执行提交 | 本课题的最终验收口径 | - -FPS或samples/s表示吞吐率，\(1/FPS\)只能在batch=1、没有流水重叠且测量口径一致时近似单请求时间。对实时控制，应同时报告P50、P95、P99、P99.9、观测最大值、截止期违约率和连续违约长度，不应只报平均值。 - -## 3 代表性异构边侧设备指标 - -### 3.1 设备横向对比 - -表1使用2026年9月前公开的厂商一手资料。“未给出”表示引用的官方页面没有给出可直接比较的数值，而不表示设备没有功耗或存储限制。 - -| 平台/芯片 | 异构计算组成 | 官方标称AI性能 | 内存/带宽 | 官方功耗口径 | 典型软件路径 | 对本课题的主要价值 | -|---|---|---:|---|---|---|---| -| Jetson Orin Nano 8GB | 6核Cortex-A78AE + 512核Ampere GPU/16 Tensor Cores | 最高67稀疏INT8 TOPS | 8 GB LPDDR5，约102 GB/s | 7–25 W | Linux/JetPack + CUDA/TensorRT/ONNX Runtime/Isaac ROS | 低成本具身智能与视觉基线；没有独立DLA[1] | -| Jetson Orin NX 16GB | 8核Cortex-A78AE + 1024核Ampere GPU/32 Tensor Cores + 2个NVDLA | 最高157稀疏INT8 TOPS | 16 GB LPDDR5，102.4 GB/s | 10–40 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 适合VLA、多视觉流和异构调度；也是当前机器人开发中常见的档位[1] | -| Jetson AGX Orin 64GB | 12核Cortex-A78AE + 2048核Ampere GPU/64 Tensor Cores + 2个NVDLA + PVA | 最高275稀疏INT8 TOPS | 64 GB LPDDR5，204.8 GB/s | 15–60 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 多模型、多传感器和大模型本地推理基线[1][2] | -| Rockchip RK3588 | 4×Cortex-A76 + 4×Cortex-A55 + Mali-G610 MP4 + 三核NPU + 低功耗MCU | 6 INT8 TOPS；数据手册还列出INT4/INT16/FP16/BF16/TF32支持 | 64-bit LPDDR4/4X/5；额定容量与带宽取决于板级实现 | 未给出统一模块档位 | Linux/Android + RKNN Toolkit2/RKNN Runtime | 低成本NPU和多核CPU/GPU/NPU共存对照；官方模型库提供多模型FPS[3][4] | -| TI TDA4VM | 2×Cortex-A72 + 6×Cortex-R5F + C7x DSP/MMA + 2×C66x DSP + GPU + ISP/VPAC/DMPAC | MMA最高8 INT8 TOPS | 随具体型号和板级设计确定 | 官方产品页未给出统一整机值 | Linux/QNX/FreeRTOS等 + TIDL | 应用核、多实时核、DSP与AI加速器高度集成，非常适合研究“Linux+RTOS+硬件隔离”[5] | -| NXP i.MX 8M Plus | 2/4×Cortex-A53 + Cortex-M7 + NPU + HiFi 4 DSP + GPU + 双ISP | 最高2.3 TOPS | LPDDR4/DDR4，支持内联ECC；容量取决于型号和板级实现 | 未给出统一整机值 | Linux + FreeRTOS + eIQ/TFLite/ONNX生态 | 算力不高但实时核、TSN/CAN FD和工业接口完整，适合中小模型+实时控制[6][7] | -| Qualcomm QRB5165/RB5 | 4高性能+4低功耗Kryo 585 + Adreno 650 + Hexagon 698/HTA/HVX + EVA/ISP | AI Engine最高15 TOPS | 开发套件配置与商用SoM不同，需按BOM冻结 | 官方页未给出统一整机值 | Linux/Ubuntu/ROS 2 + QAIRT/QNN/HTP | 强ISP、DSP、NPU和连接性，适合机器人、无人机和多相机异构流水线[8] | -| Hailo-8（加速器） | 数据流AI处理器，需外部主机 | 26 TOPS | 芯片设计不需外部存储器；系统总内存仍由主机和流水线决定 | 官方典型值2.5 W | Host Linux + Hailo Dataflow Compiler + HailoRT/HEF | 适合研究外挂NPU、PCIe搬运、设备队列与主机控制任务之间的干扰[9] | -| AMD Kria K26 | 4×Cortex-A53 + 2×Cortex-R5F + Mali-400 + 25.6万逻辑单元/1248 DSP的可编程逻辑 | 取决于DPU或自定义数据通路配置，不宜以固定TOPS与NPU比较 | 4 GB 64-bit DDR4，2400 Mb/s；26.6 Mb片上存储 | 取决于PL设计与载板 | Linux/FreeRTOS + Vitis AI/自定义PL加速 | 可把关键预处理、时间触发或自定义推理流水线硬件化，适合确定性对照[10][11] | - -上表表明，主流设备并不是同一类产品。Jetson强调GPU生态、统一内存与大模型兼容性；RK3588强调成本与多媒体NPU；TDA4VM、i.MX 8M Plus和Kria更容易形成应用域与实时域的硬件分工；QRB5165具有移动SoC的能效、感知和连接优势；Hailo-8则是主机外挂专用加速器。子课题B的“混合实时”研究应关注这些架构差异如何影响隔离和尾时延，而不是只寻找TOPS最大的设备。 - -### 3.2 主要推理架构和编译链 - -| 类型 | 典型数据路径 | 优势 | 与实时性相关的风险 | -|---|---|---|---| -| GPU/Tensor Core | PyTorch/ONNX → TensorRT engine → CUDA stream → GPU | 算子覆盖广，支持FP32/FP16/BF16/FP8/INT8/INT4/FP4等混合精度，易部署Transformer[12] | 核函数不可抢占区间、多流排队、显存/统一内存竞争和热降频 | -| 固定功能NPU/DLA | ONNX/TFLite → 厂商编译器 → 私有图/二进制 → NPU Runtime | INT8能效高，适合固定视觉网络 | 算子不支持时可切图或回退CPU；固件队列和抢占能力不透明 | -| DSP/HTP/MMA | 模型编译 → DSP/向量核+矩阵加速器 | 视觉、信号处理和AI可在相同子系统内融合 | 多核共享内存、任务图与数据搬运配置复杂 | -| 数据流NPU | 模型 → 结构映射/编译 → HEF等产物 → 流式执行 | 视觉模型吞吐和能效高 | 主机预/后处理、PCIe或M.2传输和多流调度仍会影响端到端时间 | -| FPGA/可编程逻辑 | 模型或自定义算子 → HLS/RTL/DPU → PL流水线 | 可定制I/O、并行度和固定数据路径，便于硬件时间触发 | 编译时间长，可用算子和量化方案受配置限制，更改模型需重新生成硬件产物 | - -这些运行时并不直接对应操作系统的实时优先级。即使提交线程在Linux中设置了高优先级，设备内部已排队任务、固件命令批次和内存控制器仍可能不可抢占。因此需要以时间戳区分“主机提交—设备开始—设备完成—结果可用”四个时刻。 - -## 4 代表性模型的权重、质量与计算规模 - -### 4.1 从轻量视觉到具身大模型 - -表2中的权重容量按参数量与位宽计算，是方便选型的理论值，不代表文件大小或运行时峰值内存。 - -| 模型 | 任务/架构 | 参数与计算 | 理论权重容量 | 公开任务质量/训练信息 | 对边侧部署的含义 | -|---|---|---|---|---|---| -| MobileNetV3-Large 1.0 | ImageNet分类，移动CNN | 5.4M参数，219M MAdds | FP32 21.6 MB；FP16 10.8 MB；INT8 5.4 MB | ImageNet Top-1 75.2%[13] | 适合作为算子覆盖和量化基线，但不能代表检测、分割或VLA | -| YOLOv8n | COCO目标检测，单阶段CNN | 3.2M参数，约8.74 GOP（Hailo口径） | FP32 12.8 MB；FP16 6.4 MB；INT8 3.2 MB | Hailo模型库报告float mAP 37.0、设备mAP 36.4[14] | 适合低延迟感知和量化损失对照 | -| YOLOv8s | COCO目标检测 | 11.2M参数，约28.6 GOP | FP32 44.8 MB；FP16 22.4 MB；INT8 11.2 MB | float mAP 44.6、Hailo设备mAP 43.9[14] | 与YOLOv8n组成同系列精度—延迟折中实验 | -| Octo-Small/Base | 通用机器人策略，Transformer+动作头 | 27M/93M参数 | FP16约54/186 MB；INT8约27/93 MB | 使用约80万条机器人轨迹；官方仓库报告RTX 4090上约17/13 it/s[15] | 模型可放入边侧内存，但4090结果不能代替边侧实测；任务质量应以机器人成功率报告 | -| OpenVLA-7B | 视觉—语言—动作，双视觉编码器+投影层+Llama 2 7B | 约7B参数 | FP16约14 GB；INT8约7 GB；INT4约3.5 GB | 97万条真实机器人演示；64块A100训练15天；论文报告其在29项任务上较RT-2-X绝对成功率高16.5个百分点[16][17] | 量化后权重可能放入8–16 GB设备，但活化值、视觉编码和上下文仍可造成显著内存及延迟压力 | -| LiteVLA-Edge实验管线 | 边缘多模态控制，ROS 2 + llama.cpp | 论文采用FP32监督微调后4-bit GGUF量化 | 依具体基座模型而定 | Jetson Orin类平台上报告平均端到端时延150.5 ms，约6.6 Hz[18] | 说明“可运行”与“可高频闭环”差距巨大；需用异步动作块、过期拒绝和RTOS底层控制弥补 | - -上述数据还显示，“准确率”不能在不同任务之间直接比较。75.2% ImageNet Top-1、44.6 COCO mAP和机器人任务成功率属于不同评价对象。对具身智能，最终应报告分任务成功率、碰撞/越界次数、完成时间和对延迟扰动的敏感性，不能只使用离线感知指标。 - -### 4.2 公开设备推理数据示例 - -下表故意保留了各官方模型库的测试口径，不将它们包装成严格跨平台排名。倒数时间仅为\(1000/FPS\)的理想化换算，不是P99或端到端延迟。 - -| 设备/来源 | 模型与输入 | 精度 | 公开吞吐 | 理想化倒数时间 | 测试条件与解读 | -|---|---|---|---:|---:|---| -| RK3588官方RKNN Model Zoo | MobileNetV2，1×3×224×224 | INT8 | 450.7 FPS | 2.22 ms | 官方表格标注RK3588 NPU单核，适合作图执行吞吐基线[4] | -| RK3588官方RKNN Model Zoo | ResNet50-v2，1×3×224×224 | INT8 | 110.1 FPS | 9.08 ms | 同上[4] | -| RK3588官方RKNN Model Zoo | YOLOv8n/s/m，1×3×640×640 | INT8 | 73.5/38.0/16.2 FPS | 13.61/26.32/61.73 ms | 同系列随模型规模增大出现清晰延迟梯度[4] | -| Hailo-8官方Model Zoo | YOLOv8n/s/m/l，640×640 | 编译后硬件部署 | 1036/491/66.9/36.2 FPS | 0.97/2.04/14.95/27.62 ms | 官方表格的主机为i5-9400、PCIe Gen3×4、室温、batch=1；表内还分别报告float和硬件mAP[14] | -| Hailo-8官方CLI示例 | ResNet-50 | 编译后HEF | 1328.83 FPS | 不按倒数解读 | 同一输出报告硬件延迟2.936 ms和流式平均功耗3.194 W，说明流水吞吐与单请求延迟并非简单互为倒数[19] | -| Jetson Orin类设备/LiteVLA-Edge | 量化多模态控制管线 | 4-bit GGUF | 约6.6 Hz | 平均端到端150.5 ms | 包含ROS 2感知—推理—动作管线，与纯NPU图执行不是同一口径[18] | - -对真正的跨设备比较，应优先使用MLPerf Inference Edge这类固定模型、数据集、质量门槛、负载生成器和场景规则的基准。MLCommons将Closed组用于尽可能同模型横向比较，Open组则允许更换模型或重训练[20]。即使如此，MLPerf的Offline/Server/SingleStream等场景仍不能替代本课题的RTOS控制并发和故障注入实验。 - -## 5 面向混合实时控制的指标体系 - -### 5.1 不应缺失的设备信息 - -每一组实验至少冻结： - -- SoC/模组/开发板型号、内存容量和载板版本； -- OS、内核、RTOS、Hypervisor、BSP和固件版本； -- AI编译器、运行时、驱动和模型编译产物的哈希； -- 功耗模式、CPU/GPU/NPU/内存频率、锁频方式和散热条件； -- CPU亲和性、中断亲和性、内存区域、IOMMU、设备所有权和加速器并发度； -- 采集时长、样本数、预热时间、环境温度与稳态温度。 - -### 5.2 不应缺失的模型信息 - -- 模型名称、代码/权重提交号、输入尺寸、batch、序列长度和动态形状范围； -- 参数量、MACs/FLOPs/OPS口径和支持算子比例； -- 原始权重位宽、部署权重/活化位宽和混合精度列表； -- PTQ/QAT方式、校准数据集与样本数，是否采用稀疏性或剪枝； -- FP32/原始模型质量、编译后仿真质量和目标板实测质量； -- 编译失败、CPU回退、子图切分、张量转换和外部算子情况。 - -### 5.3 四类性能结果 - -| 类别 | 核心指标 | 解释要点 | -|---|---|---| -| 模型质量 | 原始质量、量化后质量、绝对/相对下降、分类别/分场景成功率 | 达不到冻结质量门槛时，性能再高也不进入实时比较 | -| 推理时序 | 冷启动、预热后P50/P95/P99/P99.9/最大值，吞吐、队列深度和超时率 | 分别记录L1–L4口径，避免用纯硬件FPS代替端到端时间 | -| 资源与能效 | CPU/GPU/NPU利用率、DDR带宽、LLC未命中、DMA、峰值内存、平均/峰值功耗、J/inference | 功耗必须注明是芯片、模组、加速卡还是整机口径 | -| 控制影响 | 控制周期偏差、截止期违约、AI结果年龄、过期丢弃率、降级与恢复时间 | 这是子课题B区别于通用AI硬件评测的最终指标 | - -## 6 对子课题B的设备和模型选型建议 - -### 6.1 建议形成四类对照平台 - -1. **高AI生态主平台：Jetson Orin NX 16GB或AGX Orin。** 用于具身视觉、VLA、多模型并发和GPU/DLA异构分配，也便于与已有机器人应用资料衔接。 -2. **集成实时域平台：TDA4VM或i.MX 8M Plus。** 用于对比应用核与R5F/M7实时核的硬件分工、共享内存通信和故障隔离。 -3. **低成本NPU平台：RK3588。** 用于评价私有NPU编译、算子回退、单/多NPU核调度与Linux实时化的性价比。 -4. **外挂或可编程加速平台：Hailo-8或Kria K26。** 用于研究PCIe/DMA搬运、主机队列、自定义数据通路和固定流水线的确定性。 - -若当前资源只允许购置一套平台，建议优先Orin NX 16GB，并外接一块运行RTOS的MCU或实时控制器建立可测的Linux AI域—RTOS控制域链路。若研究重心更偏向单芯片内的真正AMP和安全隔离，TDA4VM的A72+R5F+C7x/MMA结构更具代表性。 - -### 6.2 建议的模型负载梯度 - -| 梯度 | 建议模型 | 目的 | -|---|---|---| -| M0 算子微基准 | Conv2D、Depthwise Conv、GEMM、Attention、Resize、NMS | 建立算子时间、能耗和CPU回退数据库 | -| M1 轻量分类 | MobileNetV3-Large或MobileNetV2 | 验证编译链、INT8量化和最小延迟 | -| M2 实时检测 | YOLOv8n/s/m | 建立模型规模—质量—延迟—能耗曲线 | -| M3 语义/姿态任务 | DeepLabV3+、YOLOv8-Pose或项目自有模型 | 接近机器人对环境和人的感知负载 | -| M4 紧凑机器人策略 | Octo-Small/Base或等规模动作模型 | 评估视觉、语言/状态和动作生成管线 | -| M5 量化VLA | OpenVLA类7B或更小VLA的INT4版本 | 验证大权重、长时延、异步动作块和结果新鲜度策略 | - -## 7 建议直接纳入课题的实验设计 - -### 7.1 E0：版本与配置冻结 - -生成设备BOM、软件版本、功耗/频率、核与中断分配、模型哈希、校准集哈希和编译参数清单。未完成E0的数据不进入横向对比。 - -### 7.2 E1：模型质量与内存账本 - -对每个模型依次测量FP32/FP16原始质量、PTQ INT8/INT4质量、必要时的QAT质量；统计模型文件、设备编译产物、常驻权重、峰值工作区和稳态/峰值RSS。质量下降超过任务门槛的精度方案不参加性能验收。 - -### 7.3 E2：单模型隔离推理 - -固定batch=1和输入，分别测试冷启动、预热后和热稳态。对L1、L2、L3时间分段打点，报告分位数、吞吐、功耗和能耗。对具有多NPU核、GPU+DLA或CPU+DSP+NPU的设备，对比单加速器、多加速器和多模型并发。 - -### 7.4 E3：控制域与AI域并发 - -设置0.5/1/2/10 ms等不同控制周期的仿真或实机任务，对比： - -1. 仅控制任务； -2. 控制+单模型推理； -3. 控制+多视频流/多模型； -4. 控制+大模型/VLA长时推理； -5. 同负载下的普通Linux、PREEMPT_RT、AMP或静态分区方案。 - -主指标为控制周期P99.9/最大偏差、截止期违约、AI结果年龄和过期拒绝率。 - -### 7.5 E4：共享资源压力 - -逐项和联合注入CPU、LLC、DDR、DMA、摄像头/ISP、网络、NVMe、GPU/NPU和热负载，建立： - -\[ -资源干扰强度\rightarrow推理队列和尾时延\rightarrow控制周期偏差\rightarrow截止期/任务质量 -\] - -的因果记录。此实验应长时运行到热稳态，否则无法观测DVFS和热降频对长尾的影响。 - -### 7.6 E5：超时、故障和恢复 - -注入AI进程崩溃、设备超时、驱动队列停滞、消息丢失/乱序/重复、过期结果、Linux重启和温度降频。测量故障检测时间、RTOS降级切换时间、安全状态保持率、通道清理和受控重新接入时间。 - -## 8 综合讨论 - -### 8.1 关于“边端训练” - -大多数异构边侧设备的主要任务是推理，并非从零训练大模型。OpenVLA的公开信息显示其预训练使用了64块A100、15天[17]，这与边侧SoC的功耗、内存和散热边界不在同一级别。边端更可行的路径是离线集中训练，边端进行小样本校准、LoRA/适配层微调、增量学习或模型选择。这些在线学习活动不应与高关键控制无界共享资源。 - -### 8.2 关于具身智能的多频率系统 - -具身智能中的VLA可能只能以6–20 Hz生成动作或动作块，而关节、平衡、力控和安全监测可能需要500 Hz–2 kHz甚至更高的周期。这不意味着VLA必须和伺服环同频，而意味着系统必须有明确的多频率协议：VLA只发布带时间戳、有效期、版本和置信度的有界目标/动作块；RTOS以高频率完成插值、限幅、状态估计、执行器控制和故障降级。 - -### 8.3 最有价值的研究指标 - -对本课题而言，最有价值的不是“将YOLO加速到多少FPS”，而是以下三类关系： - -1. 在相同模型质量门槛下，不同设备/精度/运行时的L3和L4尾时延如何； -2. 在相同AI负载下，普通Linux、PREEMPT_RT、AMP和静态分区对控制周期P99.9和最大值的改善程度； -3. 当AI超时、过载或崩溃时，RTOS能否在已知时间内拒绝旧结果、进入降级并维持安全状态。 - -## 9 结论 - -当前主流异构边侧设备已形成GPU主导、集成NPU/DSP、应用核+实时核、外挂数据流加速器和FPGA可编程逻辑等多条技术路线。其公开算力横跨约2.3 TOPS到275稀疏INT8 TOPS，但TOPS口径、数值精度、稀疏性、算子覆盖、内存系统和运行时都不同，因而不能根据峰值数字直接预测模型FPS或端到端控制时闶。 - -在模型层面，MobileNet/YOLO类模型的权重仅为数MB至数十MB，而7B VLA即使INT4权重也约3.5 GB，其中间状态和端到端流水线还会显著增加内存与时间成本。量化的意义不只是减小文件，还要同时验证任务质量、算子映射、实际内存峰值和长尾时延。 - -因此，子课题B应将设备峰值参数作为入口，将模型质量作为准入门槛，将L1–L4时间分解和资源计量作为过程证据，最终以控制周期、AI结果新鲜度、过期拒绝、故障降级和恢复时间作为系统级结论。这样才能把“模型跑得动”提升为“智能与实时控制可在已知边界内共存”。 - -## 参考资料 - -1. NVIDIA. *Jetson AGX Orin for Next-Gen Robotics: Technical Specifications*. [官方产品与规格页](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/)，访问日期：2026-09-29。 -2. NVIDIA. *Jetson AGX Orin Series Hardware Architecture*. [官方技术简报](https://www.nvidia.com/content/dam/en-zz/Solutions/gtcf21/jetson-orin/nvidia-jetson-agx-orin-technical-brief.pdf)。 -3. Rockchip. *RK3588 Brief Datasheet*. [官方数据手册](https://www.rock-chips.com/uploads/pdf/2022.8.26/191/RK3588%20Brief%20Datasheet.pdf)。 -4. Rockchip AI Team. *RKNN Model Zoo*. [官方代码仓库及性能表](https://github.com/airockchip/rknn_model_zoo/blob/main/README_CN.md)，访问日期：2026-09-29。 -5. Texas Instruments. *TDA4VM SoC with Dual Arm Cortex-A72, 8 TOPS of AI, C7x DSP, and GPU*. [官方产品页](https://www.ti.com/product/TDA4VM)。 -6. NXP. *i.MX 8M Plus: Cortex-A53/M7, Machine Learning, Vision, Multimedia and Industrial IoT*. [官方产品页](https://www.nxp.com/products/i.MX8MPLUS)。 -7. NXP. *i.MX 8M Plus Applications Processor Family*. [官方产品手册](https://www.nxp.com/docs/en/brochure/IMX8SERAPPBR.pdf)。 -8. Qualcomm. *Dragonwing QRB5165*. [官方产品页](https://www.qualcomm.com/internet-of-things/products/q5-series/qrb5165)。 -9. Hailo. *Hailo-8 AI Processor Product Brief*. [官方产品简报](https://hailo.ai/wp-content/uploads/2023/10/hailo-8-product-brief-rev3.26.pdf)。 -10. AMD. *Kria K26 SOM Data Sheet (DS987)*. [官方数据手册](https://docs.amd.com/r/en-US/ds987-k26-som)。 -11. AMD. *Kria K26 SOM: The Ideal Platform for Vision AI at the Edge*. [官方白皮书](https://docs.amd.com/v/u/en-US/wp529-som-benchmarks)。 -12. NVIDIA. *TensorRT Documentation*. [官方文档](https://docs.nvidia.com/deeplearning/tensorrt/latest/)。 -13. HOWARD A, SANDLER M, CHU G, et al. Searching for MobileNetV3[EB/OL]. arXiv:1905.02244, 2019. [论文](https://arxiv.org/abs/1905.02244)。 -14. Hailo AI. *Hailo Model Zoo: Hailo-8 Object Detection Models*. [官方模型指标与基准表](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/public_models/HAILO8/HAILO8_object_detection.rst)。 -15. OCTO MODEL TEAM, GHOSH D, WALKE H, et al. Octo: An Open-Source Generalist Robot Policy[C]//Robotics: Science and Systems. 2024. [官方仓库与模型数据](https://github.com/octo-models/octo)。 -16. KIM M J, PERTSCH K, KARAMCHETI S, et al. OpenVLA: An Open-Source Vision-Language-Action Model[EB/OL]. arXiv:2406.09246, 2024. [论文](https://arxiv.org/abs/2406.09246)。 -17. OpenVLA Team. *OpenVLA Project Page*. [官方项目页](https://openvla.github.io/)。 -18. WILLIAMS J, GUPTA K D, GEORGE R, et al. LiteVLA-Edge: Quantized On-Device Multimodal Control for Embedded Robotics[EB/OL]. arXiv:2603.03380, 2026. [论文](https://arxiv.org/abs/2603.03380)。 -19. Hailo AI. *Hailo Model Zoo Benchmarks*. [官方基准复现说明](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/BENCHMARKS.rst)。 -20. MLCommons. *MLPerf Inference: Edge*. [官方基准、场景与结果](https://mlcommons.org/benchmarks/inference-edge/)，访问日期：2026-09-29。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md deleted file mode 100644 index 3c1eb42..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# 00-总览与定位 - -本层回答“子课题B研究什么、为什么研究、适用于哪些边侧SoC场景”。 - -## 文件 - -1. [00-子课题定义.md](./00-子课题定义.md)：研究对象、核心目标和方向边界； -2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)：关键问题、应用场景和系统约束； -3. [02-面向边侧异构SoC的混合实时控制基础系统研究综述.md](./02-面向边侧异构SoC的混合实时控制基础系统研究综述.md)：系统形态、共享资源干扰、跨域通信、安全降级、研究空白与本课题研究框架； -4. [03-主流异构边侧设备与AI模型性能指标综述.md](./03-主流异构边侧设备与AI模型性能指标综述.md)：主流异构设备、模型权重与精度、公开推理数据、运行时架构和统一实验指标。 - -## 阅读结果 - -读完本层应能够明确： - -- 子课题B与子课题A在资源规模和部署形态上的区别； -- Linux、RTOS、Hypervisor和Hybrid结构分别解决什么问题； -- 哪些实时控制职责必须留在确定性执行域中； -- 国内外相关研究已经解决了什么、尚缺少什么，以及本课题的可验证创新点； -- 不同设备的TOPS、模型权重、精度、FPS和端到端延迟应如何正确比较。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/01-研究问题与适用场景.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/01-研究问题与适用场景.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/01-研究问题与适用场景.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/01-研究问题与适用场景.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/03-实验设计与验证方法.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/03-实验设计与验证方法.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/03-实验设计与验证方法.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/03-实验设计与验证方法.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/04-预期成果与论文方向.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/04-预期成果与论文方向.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/04-预期成果与论文方向.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/04-预期成果与论文方向.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/05-合作方式与产业落点.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/05-合作方式与产业落点.md similarity index 100% rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/05-合作方式与产业落点.md rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/05-合作方式与产业落点.md diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md deleted file mode 100644 index bde1eab..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md +++ /dev/null @@ -1,77 +0,0 @@ -# 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 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。** diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/README.md deleted file mode 100644 index 1dfef64..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/README.md +++ /dev/null @@ -1,16 +0,0 @@ -# 10-技术框架 - -本层回答“边侧SoC上的混合实时控制基础系统如何划分运行域、隔离资源并完成跨域协同”。 - -## 文件 - -1. [00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md](./00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md)：四类系统形态、异构资源治理和技术路线。 - -## 后续重点 - -- 控制域与推理域的CPU核、内存和中断隔离； -- 跨域通信的时延上界和故障传播边界； -- NPU/GPU/DMA共享资源对控制任务尾时延的影响； -- 推理超时、服务失效和系统异常时的规则接管。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/00-实验设计与验证方法.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/00-实验设计与验证方法.md deleted file mode 100644 index 4986583..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/00-实验设计与验证方法.md +++ /dev/null @@ -1,29 +0,0 @@ -# 实验设计与验证方法 - -## 1. 验证重点 - -本子课题的验证重点包括： - -- Linux / RTOS 分工是否稳定； -- Hypervisor 隔离是否有效； -- 统一内存、总线与 DMA 竞争是否可观测、可治理； -- 规则兜底与异常切换是否能保护关键保障负载边界。 - -## 2. 典型实验单元 - -适合优先组织： - -1. Linux 与 RTOS 双域并存实验； -2. Hypervisor 隔离与无隔离结构对比； -3. 统一内存、DMA 与总线竞争实验； -4. 模型输出、规则兜底与异常切换实验； -5. 长稳、热状态与恢复实验。 - -## 3. 指标重点 - -- `TTFT` -- `TPOT` -- `deadline miss ratio` -- `P99/P99.9 jitter` -- 资源隔离效果 -- 温度、热漂移与恢复时间 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md deleted file mode 100644 index 6b49736..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md +++ /dev/null @@ -1,135 +0,0 @@ -# 工程应用场景与异构系统性能指标对标 - -## 1 调研目的与结论 - -本文件把子课题B“Linux、RTOS、Hypervisor与异构加速器协同”的研究主线映射到可验证的工程场景，并整理截至2026年9月公开可查的延迟、抖动和控制周期数据。 - -先说明数据边界：目前项目材料尚未冻结目标SoC、载板、Linux/RTOS版本、Hypervisor、AI加速器运行时和具体机器人型号。因此，下文数据是公开论文、厂商工程测试和产品资料中的**对标值**，不是本课题目标板的实测值，也不能直接互相比较。尤其宇树官网公开了部分算力、传感器和开发接口信息，但未公开其机器人内部控制链的端到端延迟分布、P99/P99.9抖动或截止期违约率。 - -本次调研的工程判断是： - -1. 具身机器人适合作为课题牵引场景，宇树G1-D/G1-Comp、H1/H1-2以及四足巡检机器人具备“实时运动控制+视觉/语言模型+边侧算力”的真实需求； -2. 公开VLA数据能说明高级策略推理可能需要百毫秒至秒级，不能把它放入毫秒级伺服闭环； -3. 控制域的目标应单独定义周期、抖动和违约率，并由RTOS或专用控制器维持安全闭环；Linux/AI域通过有界通道提供更新较慢的感知和动作建议； -4. 对课题最有价值的实验不是只报AI FPS，而是在CPU、DDR、DMA、NPU/GPU和温度压力下测量“传感输入至控制输出”的长尾时延、抖动和故障切换时间。 - -## 2 已公开的量化性能参照 - -### 2.1 边侧SoC实时内核与现场总线 - -Seeed公布了在Orin Nano Super上对标准Linux和PREEMPT_RT进行的同机对照测试。设备运行JetPack 7.2，六核CPU；测试同时包含满CPU负载、内核临界区干扰、GPIO周期输出和1 kHz EtherCAT主站。该资料由硬件厂商发布，实验步骤和部分代码公开，属于可复核的工程数据，但不是独立同行评审论文。 - -| 测量对象与条件 | 标准内核 | PREEMPT_RT | 解释 | -|---|---:|---:|---| -| 用户态满CPU负载下，周期线程唤醒延迟 P99 / 最大值 | 1,879 / 8,200 μs | 11 / 32 μs | 说明高优先级线程虽能压过普通用户任务，内核调度仍会产生毫秒级长尾 | -| EtherCAT主站，1 kHz，内核自旋锁每3秒持有1秒，5,000周期中超1 ms周期数 | 约2,000 | 0 | 这是有意构造的严重内核临界区干扰，展示了非抢占内核区可能造成总线失联 | -| 同一EtherCAT测试，主站唤醒延迟 P50 / P99 / 最大值 | 7 / 约994,000 / 约1,018,000 μs | 2 / 3 / 12 μs | PREEMPT_RT数据来自相同测试条件；不可视为所有Orin设备的通用保证 | -| 2 kHz GPIO输出，300 μs锁竞争下 P99 / 最大值 | 306 / 325–547 μs | 251 / 257 μs，标准差0.56 μs | 周期输出比单纯cyclictest更接近电气边沿抖动测量 | - -同一资料还显示，标准内核与PREEMPT_RT在纯用户态负载下都能维持电机运行，但延迟分布差别仍明显；当内核不可抢占临界区加入后，标准内核会触发安全停机，PREEMPT_RT在该测试中没有丢周期。[Seeed Orin Nano Super PREEMPT_RT与EtherCAT对照测试](https://wiki.seeedstudio.com/deploy_preempt_rt_kernel_with_prebuilt_deb_package_on_recomputer_jetson/) - -NVIDIA的Jetson Thor实时内核测试也给出一个资源隔离参照：在性能模式、DDR/GPU高频、显示/USB/网络和编译负载并行的配置下，隔离核上的`rtla timerlat`线程最大延迟为26 μs；承担系统负载的核最大值最高96 μs。该测试针对Thor，不应外推为Orin或宇树开发计算单元的性能保证。[NVIDIA Jetson实时内核测量说明](https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/Kernel/RealTimeKernel.html) - -### 2.2 ROS 2与机器人控制周期 - -清华大学双臂机器人相关研究在PC控制平台上测试ROS 2、PREEMPT_RT和EtherCAT。其结果可用来设计指标口径，但硬件不是Jetson异构SoC： - -- 满CPU压力下，PREEMPT_RT周期线程测试持续25.7小时，最大唤醒延迟82 μs、平均2 μs；周期抖动在25–5,000 Hz测试范围内小于60 μs； -- 1 kHz EtherCAT主站、16个从站的周期实测最小982.5 μs、平均999.8 μs、最大1,022.4 μs； -- 1 KB ROS 2消息在不同发布频率下测得的最大传输延迟低于150 μs；消息大小、DDS/QoS和节点数变化会影响结果。 - -该研究明确指出其测试优化的是系统实时性能，并未证明机器人运动控制品质；因此上述值适合作为“如何报告周期与延迟”的参照，不宜直接作为课题目标板的验收结论。[Ye等，ROS2 Real-time Performance Optimization and Evaluation](https://doi.org/10.1186/s10033-023-00976-5) - -### 2.3 Jetson上具身VLA推理与反应时间 - -2026年的Jetson-PI研究在Jetson Orin上测试π0.5视觉语言动作模型。其表格给出以下分阶段优化结果： - -| Orin推理流程 | 端到端模型推理时间 | 动作反应时间 | 报告的控制频率 | -|---|---:|---:|---:| -| 朴素同步推理 | 1,420.8 ms | 1,420.8 ms | 0.70 Hz | -| 加入VLM调用调度 | 1,420.8 ms | 674.9 ms | 1.48 Hz | -| 加入CUDA Graph复用 | 476.1 ms | 227.0 ms | 4.41 Hz | -| 加入中间缓冲与迭代展开 | 412.9 ms | 165.1 ms | 6.06 Hz | - -这里的“控制频率”是VLA高级策略生成/反应能力，不是关节伺服频率，也没有报告目标SoC混合负载下的P99抖动。研究另在PrimeBot X2-W平台上用三路224×224相机执行叠衣任务，报告机器人动作频率15 Hz；该实机结果使用XR-1模型，不应与上表π0.5的6.06 Hz混为一谈。该结果适合支持“VLA异步运行、低层控制独立闭环”的设计，而非证明VLA可以直接承担实时伺服。[Jetson-PI论文，arXiv版本于2026-09-05更新](https://arxiv.org/abs/2607.12659) - -### 2.4 Orin Nano移动机器人感知—规划链路 - -2026年发表的一项ROS 2小型自动驾驶/移动机器人研究采用NVIDIA Jetson Orin Nano 8 GB作为高层计算单元、STM32 Nucleo-F401RE作为低层控制器，两者通过UART交换命令和反馈。其定位与感知规划链具有可对照的端到端时间分布： - -| 感知—规划任务 | 均值 | P95 | 实测最大值 | -|---|---:|---:|---:| -| 车道检测链 | 43.221 ms | 49.538 ms | 62.061 ms | -| 目标检测链 | 49.998 ms | 61.986 ms | 72.616 ms | -| 障碍检测链 | 11.554 ms | 19.524 ms | 25.909 ms | - -论文报告车道参考更新平均频率22.4 Hz。采集时计算、内存和I/O资源专门分配给该架构，没有叠加无关AI/DMA压力；论文将从测量数据汇总的最大值称为WCET，但从严格时序分析角度看，有限运行中的最大实测值不等同于已证明的理论WCET。[Bonci等，ROS 2-Based Architecture for Autonomous Driving Systems](https://doi.org/10.3390/s26020463) - -### 2.5 宇树平台的公开参数与指标缺口 - -宇树官网资料显示，H1/H1-2标配计算单元包含平台功能计算机和用户开发计算机，选配可使用Intel Core i7或Orin NX；H1-2页面列出最多三块Orin NX。G1-D公开了8核高性能CPU、头部双目相机和腕部相机，并可选Orin NX 16 GB（100 TOPS）；G1-Comp页面列出Orin NX、ROS生态兼容、仿真和运动控制API。官方SDK2的G1低层控制示例把`control_dt`设为2 ms，即示例任务按500 Hz生成命令。 - -这些信息证明具身机器人产品具有异构计算、感知和实时运动控制接口，但500 Hz只是SDK示例中的用户命令周期，不代表机器人内部伺服周期、实际网络收发周期或抖动上限。公开产品页和示例没有给出完整的传感器到执行器路径P99/P99.9、并发推理下的控制超期率或Hypervisor隔离数据。因此，宇树可作为应用平台和工作负载来源，具体性能必须在锁定机型、开发计算单元、SDK/固件和通信拓扑后实测。[宇树H1/H1-2规格](https://www.unitree.com/cn/h1/)；[宇树G1-D平台](https://www.unitree.com/G1-D/)；[宇树G1-Comp](https://www.unitree.com/cn/robocup/)；[Unitree SDK2 G1低层控制示例](https://github.com/unitreerobotics/unitree_sdk2_python/blob/master/example/g1/low_level/g1_low_level_example.py) - -## 3 适合子课题B的应用场景 - -| 场景 | 可选平台与任务 | 异构计算分工 | 需要回答的实时问题 | 适合作为课题的原因 | -|---|---|---|---|---| -| 人形机器人移动操作 | 宇树G1-D/G1-Comp或H1-2；视觉找物、自然语言任务、抓取、递送、整理 | Linux/Orin运行视觉、VLA、任务规划；RTOS/安全控制域维护高频状态采集、关节/底盘控制接口、限位与看门狗；Hypervisor划分核、内存、设备和通信区 | 模型推理过慢或NPU排队时，控制域能否保持步态/姿态稳定；过期动作块是否被丢弃；抓取碰撞事件能否抢占慢速任务规划 | 直接体现“慢速智能决策+快速安全闭环”，与具身智能、异构SoC和AI故障兜底高度吻合；官方有Orin NX选配和多相机/开发接口 | -| 四足机器人巡检与应急 | 宇树As2/Go2/B2等；电力巡检、园区巡逻、消防侦察、越障与回传 | Linux/SoC运行视觉、点云、SLAM、异常识别和任务规划；RTOS/运动控制域负责步态、IMU、关节状态和急停；网络/云端只传非安全关键任务 | 摄像头、雷达和NPU同时工作时，DDR/DMA竞争是否拉长姿态估计；无线链路断开、定位失效、AI异常时多快进入安全策略；热稳态后时延如何变化 | 宇树公开了[四足行业巡检方案及As2高算力扩展](https://www.unitree.com/As2/)；跌倒、振动、户外温度和断网可构造真实压力及故障注入 | -| 视觉引导移动操作/仓储机器人 | Jetson Orin NX/Nano + ROS 2 + STM32/RTOS底盘或机械臂；目标搬运、避障、二维码/货架识别 | RTOS控制电机、编码器、安全输入和制动；Linux运行相机/激光雷达驱动、检测、定位和规划；IPC传递带时间戳的速度/轨迹目标 | 从相机曝光到电机命令的端到端P95/P99；队列积压和旧帧处理；Linux重启时RTOS能否维持受控停车 | 有Jetson Orin Nano + STM32的公开实机架构和端到端基线，原型成本较低，适合先打通测试工具链 | -| EtherCAT协作臂/高精度运动控制 | Orin Nano/NX或其他边侧SoC + EtherCAT伺服；视觉定位、抓取、插装、轨迹跟踪 | RTOS或PREEMPT_RT域运行1 kHz现场总线周期任务；Linux/NPU做视觉和轨迹更新；低层以有界周期缓冲接收新目标 | CPU、DMA、相机和模型并发时1 ms周期最大偏差；主站唤醒延迟；超期和总线失联次数；故障恢复到安全位置的时间 | 有Orin Nano Super + 1 kHz EtherCAT公开对照测试，能直接形成标准内核、PREEMPT_RT和隔离方案基线 | - -## 4 推荐的课题验证路线 - -### 4.1 先做可复现的实时底座 - -建议先在一块可获得的Orin NX/Nano级开发板上固定操作系统、内核、频率和驱动版本，建立Linux基线、PREEMPT_RT基线和Linux+RTOS/Hypervisor共存方案。第一轮不急着跑完整VLA，可用固定模型推理或视频/DDR/DMA合成负载复现“AI负载压迫控制域”的时序问题。 - -### 4.2 再挂接真实机器人工作负载 - -低成本路径是Orin + RTOS微控制器的移动底盘/小型机械臂；展示路径可选宇树G1-D/G1-Comp或四足开发型号。接入前应确认指定版本是否开放所需SDK、低层命令、传感器时间戳、急停和控制权切换能力。机器人平台上是否能够部署本课题的Hypervisor/RTOS，需要根据厂商授权的开发单元和实际软件接口核实，不能从“支持Orin NX”推断内部控制器可被替换。 - -### 4.3 建议统一报告的指标 - -| 层次 | 指标 | 建议记录方法 | -|---|---|---| -| RTOS控制域 | 目标周期、唤醒延迟、执行时间、周期抖动P50/P95/P99/P99.9/最大值、截止期违约次数和连续违约长度 | 使用单调时钟或硬件时间戳；报告运行时间、样本数和负载条件 | -| AI/加速器域 | 输入等待、预处理、NPU/GPU排队、推理、后处理各段时延；推理吞吐与有效结果率 | 分离排队时间与设备执行时间；同时报告冷启动和热稳态 | -| 端到端链 | 传感器采集时间到RTOS接收结果、再到执行器命令提交的时延；AI结果年龄和过期率 | 以消息序列号和时间戳贯穿各域；不只测ROS topic往返 | -| 资源争用 | CPU占用、DDR带宽、LLC未命中、DMA吞吐、加速器队列深度、核心迁移/中断分布 | 逐项压力与联合压力对照，报告控制时延增量及隔离效果 | -| 故障与恢复 | 检测时间、降级切换时间、安全状态保持率、通道清理时间、重新接入时间 | 注入进程退出、NPU超时、旧/乱序数据、通信中断、热降频和Linux重启 | -| 热与能耗 | SoC/加速器温度、频率、板级功耗、热稳态前后尾时延差 | 长时运行后再测P99.9和最大值，避免只报启动后短测数据 | - -### 4.4 初始验收值的设定原则 - -在目标控制器和机械对象尚未冻结前，不宜把单篇论文的数字写成最终验收指标。可先把下列值作为第一轮工程门槛，再由控制周期、执行器接口和安全分析修订： - -- 若控制接口周期为2 ms，可将P99.9周期抖动≤50 μs、观测最大绝对偏差≤100 μs、规定负载下截止期违约为0作为试运行目标； -- 若EtherCAT周期为1 ms，应单独记录周期误差和主站唤醒延迟，并按驱动器/机构允许的周期偏差给出通过线； -- 感知或VLA消息需按任务设置有效期。超过有效期即丢弃，RTOS不得等待其完成； -- 任何实测“最大值”必须附带测试时长、样本数、温度、频率、负载和版本信息。有限时间内零违约是实验结果，不是已证明的硬实时上界。 - -## 5 与综述的衔接和课题落点 - -综述中的静态分区、共享资源干扰、跨域消息契约和安全降级，在上述应用中分别落到可操作的研究问题： - -1. **体系结构贡献：** 明确AI域、控制域和Hypervisor的职责与设备所有权； -2. **实时性贡献：** 在相同传感与控制链下比较普通Linux、PREEMPT_RT、AMP和静态分区方案； -3. **资源治理贡献：** 使用真实NPU/GPU推理、图像流、DMA和存储负载测量控制尾时延； -4. **协同机制贡献：** 将序列号、采集时间、模型版本、置信度和有效期纳入IPC协议； -5. **安全证据贡献：** 通过过期结果拒绝、AI超时降级、Linux重启恢复和设备故障注入验证安全边界。 - -因此，推荐把“**具身机器人上的视觉/语言任务与实时运动控制共存**”作为总体应用牵引，把“**Orin类SoC + RTOS安全控制域 + Linux AI域 + 有界IPC + 多资源压力**”作为系统研究对象；先以移动底盘或EtherCAT小型执行器快速建立可复现实验，再在宇树人形或四足平台上验证场景价值和系统适用范围。 - -## 参考资料 - -1. Seeed Studio. *Deploy a PREEMPT_RT Real-Time Kernel with a Prebuilt DEB Package on Seeed reComputer Jetson Devices*. [官方工程测试与复现实验](https://wiki.seeedstudio.com/deploy_preempt_rt_kernel_with_prebuilt_deb_package_on_recomputer_jetson/)，访问日期：2026-09-28。 -2. NVIDIA. *Installing Real-Time Kernel — Jetson Linux Developer Guide, R39.2*. [官方文档](https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/Kernel/RealTimeKernel.html)，访问日期：2026-09-28。 -3. YE Y, NIE Z, LIU X, et al. ROS2 Real-time Performance Optimization and Evaluation[J]. Chinese Journal of Mechanical Engineering, 2023, 36:144. [DOI: 10.1186/s10033-023-00976-5](https://doi.org/10.1186/s10033-023-00976-5)。 -4. BONCI A, BRUNELLA F, COLLETTA M, et al. ROS 2-Based Architecture for Autonomous Driving Systems: Design and Implementation[J]. Sensors, 2026, 26(2):463. [DOI: 10.3390/s26020463](https://doi.org/10.3390/s26020463)。 -5. YANG Z, WANG Q, WANG Y, et al. Jetson-PI: Towards Onboard Real-Time Robot Control via Foresight-Aligned Asynchronous Inference[EB/OL]. arXiv:2607.12659, 2026. [https://arxiv.org/abs/2607.12659](https://arxiv.org/abs/2607.12659)。 -6. Unitree Robotics. H1/H1-2产品规格. [宇树官方页面](https://www.unitree.com/cn/h1/)，访问日期：2026-09-28。 -7. Unitree Robotics. G1-D End-to-End Platform for Humanoid Robot. [宇树官方页面](https://www.unitree.com/G1-D/)，访问日期：2026-09-28。 -8. Unitree Robotics. G1-Comp产品及RoboCup SDK. [宇树官方页面](https://www.unitree.com/cn/robocup/)，访问日期：2026-09-28。 -9. Unitree Robotics. Unitree SDK2 Python，G1低层控制示例. [官方代码仓库](https://github.com/unitreerobotics/unitree_sdk2_python/blob/master/example/g1/low_level/g1_low_level_example.py)，访问日期：2026-09-28。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md deleted file mode 100644 index 8a1e5ba..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md +++ /dev/null @@ -1,19 +0,0 @@ -# 20-实验与验证 - -本层管理子课题B的实验设计、对照系统、混合负载和验证证据。 - -## 文件 - -1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：当前实验设计与指标骨架； -2. [01-工程应用场景与性能指标对标.md](./01-工程应用场景与性能指标对标.md)：宇树具身机器人、Orin移动机器人和EtherCAT场景，以及公开时延、抖动和实验指标参照。 - -## 后续需要补充 - -- 设备与软件版本清单； -- 首个共存实验冻结说明； -- 每次实验运行记录； -- 资源争用和故障注入记录； -- Linux、RTOS、Hypervisor及Hybrid方案的统一对照表。 -- 根据最终选定的SoC、机器人型号和控制接口，把本文件中的公开对标值替换为目标板实测值。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/30-实施管理/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/30-实施管理/README.md deleted file mode 100644 index 6cb4a5a..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/30-实施管理/README.md +++ /dev/null @@ -1,13 +0,0 @@ -# 30-实施管理 - -本层用于管理设备路线、工作包、依赖条件、阶段计划和Go/No-Go判据。 - -当前尚未形成独立实施文档。正式开工前应补齐： - -1. T4/T3具体设备、芯片和外设清单； -2. Linux、RTOS、Hypervisor及驱动可用能力； -3. 推理后端与异构加速器支持情况； -4. 首个共存实验的固定硬件与软件组合； -5. 两周或月度执行计划与验收清单。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/00-合作方式与产业落点.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/00-合作方式与产业落点.md deleted file mode 100644 index f79d09e..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/00-合作方式与产业落点.md +++ /dev/null @@ -1,29 +0,0 @@ -# 合作方式与产业落点 - -## 1. 合作重点 - -本子课题更适合围绕以下合作对象展开： - -- SoC / 板级平台厂商； -- Hypervisor / mixed-criticality 基础软件团队； -- 工业边缘和机器人设备团队； -- 同时承载 AI 与控制任务的行业客户。 - -## 2. 合作方式 - -建议采用： - -1. 平台条件与资源结构梳理； -2. Linux / RTOS / Hypervisor 分工设计； -3. 板级实验与隔离验证； -4. 规则兜底和闭环安全验证； -5. 系统协同证据沉淀。 - -## 3. 产业落点 - -这一子课题更容易落到： - -- 边侧 SoC 参考架构； -- 混合基础系统方案； -- Hypervisor 协同部署方法； -- 设备端 AI + 控制一体化平台路线。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/01-预期成果与论文方向.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/01-预期成果与论文方向.md deleted file mode 100644 index b408e51..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/01-预期成果与论文方向.md +++ /dev/null @@ -1,19 +0,0 @@ -# 预期成果与论文方向 - -## 1. 预期成果 - -本子课题预期形成： - -1. 面向边侧 SoC 的混合基础系统问题定义； -2. Linux / RTOS / Hypervisor / Hybrid 协同结构说明； -3. 统一内存与资源竞争治理证据； -4. 规则兜底、异常切换与控制闭环验证材料。 - -## 2. 论文方向 - -可对应的论文方向包括： - -- Mixed-criticality embedded systems -- Hypervisor / partitioned real-time systems -- Edge AI system co-design -- Linux + RTOS 协同结构与实时边界 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/README.md deleted file mode 100644 index b000199..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/README.md +++ /dev/null @@ -1,16 +0,0 @@ -# 40-合作与成果 - -本层管理联合研究分工、产业落点、工程交付物和论文成果。 - -## 文件 - -1. [00-合作方式与产业落点.md](./00-合作方式与产业落点.md)：合作对象、分工方式和产业结合点； -2. [01-预期成果与论文方向.md](./01-预期成果与论文方向.md)：方法、系统、实验和论文成果。 - -## 使用原则 - -- 合作承诺以具体BSP、虚拟化能力和加速器支持情况为依据； -- 论文结论必须对应冻结的平台、负载和系统形态； -- 工程成果与学术贡献分别描述，但共享同一套实验数据和版本记录。 - -[返回总目录](../README.md) diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md index 9841975..94c79fc 100644 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md +++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md @@ -1,68 +1,24 @@ # 子课题B：面向边侧SoC的混合实时控制基础系统 -本目录按“研究定义—技术框架—实验验证—实施管理—合作成果”分层管理，与子课题A保持一致的文档骨架。 +本目录用于承接框架2中的第二个子课题，重点面向 `T4/T3` 设备端 SoC 与边侧混合系统场景。 -## 一句话定位 +## 子课题定位 -> 在边侧异构SoC上，研究Linux、RTOS、Hypervisor和Hybrid系统如何通过资源隔离、跨域协同及故障兜底维持实时控制边界。 +本子课题重点研究： -## 目录结构 +> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构与异构资源治理如何共同维持系统的实时边界。** -```text -子课题B -├─ 00-总览与定位 研究对象、边界、问题和适用场景 -├─ 10-技术框架 系统形态、资源治理和协同机制 -├─ 20-实验与验证 对照系统、混合负载和评价指标 -├─ 30-实施管理 设备路线、工作计划和验收材料 -├─ 40-合作与成果 联合研究、产业落点和论文成果 -└─ README.md 总导航 -``` +## 建议阅读顺序 -## 分层入口 +1. [00-子课题定义.md](./00-子课题定义.md) +2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md) +3. [02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md](./02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md) +4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md) +5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md) +6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md) -### 00-总览与定位 +## 当前特点 -- [子课题定义](./00-总览与定位/00-子课题定义.md) -- [研究问题与适用场景](./00-总览与定位/01-研究问题与适用场景.md) -- [面向边侧异构SoC的混合实时控制基础系统研究综述](./00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md) -- [主流异构边侧设备与AI模型性能指标综述](./00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md) +本子课题的关键词是： -### 10-技术框架 - -- [Linux-RTOS-Hypervisor-Hybrid技术路线](./10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md) - -### 20-实验与验证 - -- [实验设计与验证方法](./20-实验与验证/00-实验设计与验证方法.md) -- [工程应用场景与性能指标对标](./20-实验与验证/01-工程应用场景与性能指标对标.md) - -### 30-实施管理 - -- [实施管理说明](./30-实施管理/README.md) - -### 40-合作与成果 - -- [合作方式与产业落点](./40-合作与成果/00-合作方式与产业落点.md) -- [预期成果与论文方向](./40-合作与成果/01-预期成果与论文方向.md) - -## 推荐阅读路线 - -### 理解研究框架 - -`00-总览与定位` → `10-技术框架` → `20-实验与验证` - -### 准备实施 - -`30-实施管理` → 确认T4/T3设备与系统组合 → 冻结首个共存实验 - -### 组织合作与成果 - -`40-合作与成果/00-合作方式与产业落点.md` → `40-合作与成果/01-预期成果与论文方向.md` - -## 当前成熟度 - -研究定义、技术路线、实验方法和成果骨架已经形成。设备实施路线、版本清单、实验冻结单及运行记录模板，需要在具体SoC、RTOS、Linux和Hypervisor组合确认后继续补充。 - -## 备份说明 - -本目录重组前的快照位于同级目录：`90-备份-子课题B-重组前-20260924`。备份仅用于回溯，不参与当前阅读和实验流程。 +`Hybrid`、`Hypervisor`、`Linux+RTOS`、`统一内存`、`资源隔离`、`系统协同` diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/06-离线联合编排研究框架.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/06-离线联合编排研究框架.md deleted file mode 100644 index 2e739ff..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/06-离线联合编排研究框架.md +++ /dev/null @@ -1,661 +0,0 @@ -# 面向 MCU 静态智能控制基础系统的离线联合编排研究框架 - -> 版本：v0.1 -> 用途：解释“模型—控制任务离线联合编排”具体研究什么、如何在现有硬件与 SylixOS 条件下实施，以及最终形成哪些可验证成果。 -> 适用范围：子课题 A“面向 MCU 的静态智能控制基础系统”。 - -## 1. 研究目的 - -本研究不是把模型训练、控制软件开发和操作系统移植分别完成后，再把三者简单放到同一设备上运行，而是在部署前联合回答以下问题： - -1. 控制任务必须保留多少 CPU 时间、内存、中断和通信资源； -2. 智能模型需要多少权重空间、运行内存、执行时间和能量； -3. 模型能否在不破坏控制截止期的条件下进入系统； -4. 模型、算子、任务和缓冲区应如何静态放置； -5. 推理超时、输入堆积、结果异常或设备故障时，系统如何降级； -6. 部署工具能否在烧录前给出“允许部署、需要降级或拒绝部署”的结论。 - -本研究的核心目标可以概括为： - -> 将轻量智能任务转换为一个具有固定资源上限、固定执行边界和明确失效处理方式的实时系统任务，使其能够被纳入 SylixOS 控制系统的可调度性与资源预算分析。 - -## 2. 先明确设备边界 - -### 2.1 MCU 与控制端 SoC 不能混为一谈 - -仓库现有设备和候选设备中，RK3568、RK3576、RK3588 都属于多核应用处理器或异构 SoC，不是真正意义上的微控制器 MCU。它们拥有 MMU、GB 级内存并可运行 Linux 或大型 RTOS，适合验证： - -- SylixOS 上的静态任务与内存编排流程； -- 大小核绑定、任务优先级、中断与 DMA 干扰； -- 模型转换、代码生成、部署和运行时保护； -- 从控制端 SoC 向真正 MCU 收缩时的方法可迁移性。 - -但如果最终论文题目明确使用“MCU”，仍需要增加一块真正的 MCU 实验平台，对 KB/MB 级 SRAM、片上 Flash、无 MMU、固定外设和极低功耗条件进行实测。 - -### 2.2 当前硬件在本研究中的分工 - -| 平台 | 当前状态 | 在本子课题中的角色 | 不能直接证明什么 | -|---|---|---|---| -| RK3588 16 GB 工业盒 | 已有 | P0 方法原型；验证 SylixOS 集成、静态编排工具、资源限额和控制/推理共存 | 不能直接代表真正 MCU 的内存与功耗边界 | -| RK3588 8 GB 受限配置 | 由现有设备限额形成 | 模拟控制端高档资源约束，验证预算收缩和部署拒绝机制 | 内存限额不等于真实小芯片的缓存、总线和功耗特征 | -| 4×V100 服务器 | 已有 | 模型训练、量化校准、转换、参考精度和离线工具运行 | 不作为 MCU 实时控制结论的证据 | -| RK3568 / RK3576 | 条件扩展 | 控制端 SoC 收缩验证；观察更小内存、低功耗和较弱算力条件 | 仍不是严格意义上的 MCU | -| 真正 MCU 开发板 | 当前需补充 | P2 核心实证；验证 KB/MB 级内存、固定窗口、快速启动和 `E/inference` | 需先确认 SylixOS BSP、工具链和模型运行时支持 | - -### 2.3 SylixOS 已确认能力与待确认能力 - -基于当前仓库材料和翼辉官方资料，可以把 SylixOS 能力分成两类。 - -已确认、可用于研究设计的能力： - -- 支持多线程、实时调度、中断、定时器、同步和内存管理； -- 支持 SMP、多种处理器架构和 BSP 开发； -- RealEvo 可创建、构建、部署和调试 BSP 与应用工程； -- BSP 工程可配置启动、内存映射、链接脚本、中断、时钟、Cache 和 DMA； -- 官方存在 RK3588 和 RK3568 的板级资料，可作为适配依据； -- 可通过链接脚本、静态区、固定任务和固定优先级实现离线资源布局。 - -必须由翼辉或具体 BSP 进一步确认的能力： - -- 现有 RK3588 工业盒是否与官方支持板完全兼容； -- RK3588 NPU、RKNN/RKLLM 或其他推理后端在 SylixOS 下的可用性； -- RK3576 的完整 BSP、驱动和性能计数支持； -- 面向真正 MCU 的 SylixOS lite/tiny 配置、最小内存占用和目标芯片 BSP； -- 模型运行时、算子库、DSP/NPU驱动和功耗测量接口； -- 核绑定、内存域、DMA缓冲、缓存维护和中断亲和性的具体 API。 - -因此，本研究不能预设“模型和NPU在SylixOS上已经可用”，而应把运行时与驱动准入作为第一道实验门槛。 - -## 3. 离线联合编排的输入与输出 - -### 3.1 输入 - -离线编排器至少接收四类描述。 - -#### 控制任务描述 - -- 周期 `T_i`； -- 相对截止期 `D_i`； -- 优先级； -- WCET、测量上界或执行时间分布； -- 栈空间； -- 中断、DMA、总线和外设依赖； -- 任务之间的先后关系； -- 故障时必须继续运行的最小任务集合。 - -#### 模型描述 - -- 模型格式与版本； -- 输入输出张量； -- 算子图； -- 量化格式； -- 权重大小； -- 中间张量生命周期； -- 算子工作区； -- 各算子在目标芯片上的执行时间与能耗估计； -- 任务质量阈值。 - -#### 平台描述 - -- CPU、DSP、NPU及其频率； -- Flash、SRAM、DDR和内存 Bank； -- Cache、DMA、总线和外设结构； -- SylixOS BSP、驱动、编译器和运行时版本； -- 可用算子库与硬件加速能力； -- 功耗模式、启动方式和测量接口。 - -#### 安全与运行策略描述 - -- AI任务周期与最大等待时间； -- 可接受的输入丢弃策略； -- 超时后的默认动作； -- 模型结果合法性检查； -- 连续异常次数阈值； -- 进入降级模式与退出降级模式的条件。 - -### 3.2 输出 - -离线编排器最终不只生成可执行程序，还应生成一组可审查产物： - -1. 静态内存布局； -2. 任务优先级与核绑定表； -3. 推理窗口与抢占关系表； -4. 模型和算子映射结果； -5. 超时、丢弃、降级和恢复策略； -6. SylixOS 应用代码与配置； -7. 部署准入报告； -8. 实测校准清单； -9. 配置清单与版本指纹。 - -## 4. 六步离线联合编排流程 - -### 4.1 步骤一：分析控制任务 - -#### 研究问题 - -第一步不是分析模型，而是先确定系统中哪些控制功能绝对不能被AI破坏。 - -对每个控制任务建立任务参数： - -\[ -\tau_i=(T_i,D_i,C_i,P_i,M_i,I_i) -\] - -其中： - -- `T_i`：周期； -- `D_i`：截止期； -- `C_i`：执行时间上界或测量上界； -- `P_i`：优先级； -- `M_i`：栈、静态数据和缓冲区； -- `I_i`：中断、DMA和外设干扰。 - -#### 具体工作 - -1. 列出周期控制、状态采集、执行输出、通信、诊断和日志任务； -2. 区分硬关键、软关键和非关键任务； -3. 测量空载和典型干扰下的执行时间； -4. 记录中断屏蔽、临界区、锁竞争和DMA影响； -5. 确定控制任务必须保留的CPU、栈、缓冲区和安全余量； -6. 建立无AI时的实时性基线。 - -#### SylixOS 落点 - -- 使用固定优先级、RMS或项目冻结的调度策略； -- 控制任务使用静态或预分配栈； -- 将关键中断与AI相关中断分层； -- 在多核 SoC 上优先为关键任务设置固定核或亲和性； -- 通过GPIO翻转、系统时间戳或外部逻辑分析仪测量端到端响应。 - -#### 输出 - -- `control_tasks.yaml`； -- 控制任务时序图； -- CPU利用率和响应时间分析表； -- 关键任务内存预留表； -- 无AI基线数据。 - -#### 准入门槛 G1 - -只有在控制任务单独运行时能够稳定满足截止期、测量链路可信且日志不会明显干扰实时任务，才进入下一步。 - -### 4.2 步骤二：分析模型与算子 - -#### 研究问题 - -模型是否适合控制端，不由参数量单独决定，而由模型图、算子支持、工作区、执行时间和任务质量共同决定。 - -#### 具体工作 - -1. 固定模型修订、输入尺寸、前处理和输出语义； -2. 将模型转换为稳定的中间表示； -3. 完成 INT8 或其他目标量化，并保存校准数据； -4. 展开算子图，统计每个算子的输入、输出和工作区； -5. 检查动态 Shape、动态控制流和不支持算子； -6. 在目标芯片或参考内核上测量算子执行时间； -7. 计算模型峰值内存，而不是只计算权重大小； -8. 比较量化前后任务质量。 - -#### 优先模型类型 - -真正 MCU 阶段优先选择： - -- 1D CNN 异常检测； -- DS-CNN 关键词识别； -- 小型 MLP 状态分类； -- 轻量视觉分类； -- 决策树或小型集成模型。 - -RK3588/RK3568 方法原型阶段可以使用更大的模型验证工具链，但不能据此替代 MCU 结论。 - -#### 输出 - -- `model_manifest.yaml`； -- 算子支持矩阵； -- 权重、Tensor Arena与工作区统计； -- 算子执行时间数据库； -- 精度与量化报告。 - -#### 准入门槛 G2 - -出现以下任一情况时拒绝进入正式编排： - -- 存在无法替换的不支持算子； -- 峰值内存已经超过AI预算； -- 任务质量低于冻结阈值； -- 单次推理时间明显超过允许窗口且无法分段； -- 推理后端或驱动在SylixOS目标板上不可用。 - -### 4.3 步骤三：制定静态内存布局 - -#### 研究问题 - -系统必须在部署前知道每一类内存由谁使用、峰值是多少、是否会与DMA或控制任务冲突。 - -AI 内存预算至少包括： - -\[ -M_{AI}=M_{weights}+M_{arena}+M_{workspace}+M_{IO}+M_{stack} -\] - -系统可给AI使用的上限为： - -\[ -M_{AI,max}=M_{total}-M_{OS}-M_{control}-M_{comm}-M_{safety} -\] - -必须满足： - -\[ -M_{AI}\leq M_{AI,max} -\] - -#### 具体工作 - -1. 冻结SylixOS内核、应用、控制任务和通信缓冲的预留； -2. 确定权重放在Flash、eMMC映射区、DDR还是SRAM； -3. 根据张量生命周期复用Tensor Arena； -4. 单独划分DMA缓冲，明确Cache一致性处理； -5. 避免控制任务与推理任务共享无界堆； -6. 在多Bank SRAM或NUMA式结构中确定放置位置； -7. 为日志、异常和升级预留安全余量； -8. 生成链接段、内存映射和静态数组。 - -#### SylixOS 落点 - -- 在BSP和链接脚本中固定关键内存段； -- 控制任务与AI任务使用独立静态区或受限内存区域； -- 正式运行窗口内禁止模型路径调用无界 `malloc/free`； -- 使用SylixOS的Cache、DMA和内存管理接口完成一致性治理； -- 在RK3588原型阶段分别测试16 GB全量和8 GB限额，但将结果标为SoC约束实验。 - -#### 输出 - -- `memory_layout.yaml`； -- SylixOS链接脚本片段； -- Tensor Arena偏移表； -- DMA与控制缓冲区映射； -- 峰值内存与安全余量报告。 - -#### 准入门槛 G3 - -若内存峰值超过预算、DMA缓冲与关键区域存在未解决冲突，或部署依赖运行时无界分配，则拒绝部署。 - -### 4.4 步骤四：制定静态时间布局 - -#### 研究问题 - -AI任务必须使用控制任务执行后明确剩余的时间，而不能依赖平均CPU占用较低。 - -#### 两类编排方式 - -##### 方式A：完整推理窗口 - -每隔固定周期释放一次AI任务，并要求其在固定窗口内完成。例如： - -- 控制任务周期：1 ms； -- AI任务周期：50 ms； -- AI最大完成时间：20 ms； -- 控制任务可随时抢占AI任务； -- AI超时则丢弃本次结果。 - -适合一次推理可在较短时间内完成的模型。 - -##### 方式B：算子级分段窗口 - -将推理图按算子或子图切分，每次只执行一个有界片段： - -```text -控制周期1：Conv1 -控制周期2：DepthwiseConv -控制周期3：Pooling -控制周期4：FC + 输出检查 -``` - -适合单次完整推理时间较长，但每个算子能够独立建立执行边界的模型。 - -#### 具体工作 - -1. 冻结AI任务的周期、相位和相对截止期； -2. 确定AI任务优先级低于关键控制任务； -3. 确定是否允许算子间抢占； -4. 建立AI任务对控制任务的阻塞时间上界； -5. 建立中断与DMA干扰项； -6. 进行响应时间分析或调度仿真； -7. 生成时间表、优先级和核绑定配置； -8. 在目标板上校准预测值。 - -#### SylixOS 落点 - -- 使用SylixOS线程优先级和定时器建立周期释放； -- 控制任务固定为高优先级，AI工作线程低于控制与安全线程； -- 在RK3588上可将关键控制线程与AI线程固定到不同核，比较固定核与共享核； -- NPU提交线程、中断回收线程和模型加载线程必须进入统一优先级分析； -- 记录调度延迟、抢占次数和每个推理片段的开始/结束时间。 - -#### 输出 - -- `schedule.yaml`； -- 任务—核心映射表； -- 推理窗口或算子分段表； -- 响应时间和可调度性分析； -- 预测与实测偏差表。 - -#### 准入门槛 G4 - -只有在加入AI任务后，关键控制任务仍满足冻结的截止期条件，并保留约定安全余量，才允许进入混合负载实验。 - -### 4.5 步骤五：加入运行时保护机制 - -#### 研究问题 - -静态编排只能说明正常条件下可运行，保护机制负责处理模型超时、输入过载、输出异常和推理域故障。 - -#### 保护机制 - -| 机制 | 目的 | 推荐策略 | -|---|---|---| -| 超时检测 | 防止推理无限占用窗口 | 到期取消结果、停止后续片段或重置任务状态 | -| 有界队列 | 防止输入无限堆积 | 固定长度1～N，禁止无界增长 | -| 输入丢弃 | 保持结果时效性 | 优先保留最新状态，丢弃过期样本 | -| 输出校验 | 阻止非法模型结果进入控制路径 | 范围检查、状态机检查、置信度与一致性检查 | -| 规则兜底 | AI不可用时维持基本控制 | 执行冻结的安全规则或默认动作 | -| 看门狗 | 处理推理任务卡死 | 局部任务重启，必要时进入系统降级 | -| 恢复门槛 | 防止故障后立即反复切换 | 连续通过若干次自检后恢复AI路径 | - -#### 运行原则 - -1. AI结果不能直接覆盖硬安全约束； -2. 控制内环不等待AI任务； -3. 超时结果不得晚到后继续生效； -4. 队列满时优先拒绝或覆盖旧输入，而不是阻塞控制任务； -5. 降级路径必须在没有AI的情况下独立运行； -6. 恢复过程不能引入新的控制抖动。 - -#### SylixOS 落点 - -- 使用高精度定时器或任务级截止期监视； -- 使用固定长度消息队列、事件或环形缓冲； -- 利用看门狗和任务重启机制处理异常； -- 将规则兜底任务设置为高于AI任务、低于最关键控制任务的明确层级； -- 使用RealEvo调试与性能工具记录异常切换过程； -- 在RK3568/RK3588上可进一步测试NPU/驱动异常是否传播到控制路径。 - -#### 输出 - -- `safety_policy.yaml`； -- 超时和丢弃状态机； -- 规则兜底代码； -- 故障注入脚本或测试程序； -- 异常切换与恢复测试报告。 - -#### 准入门槛 G5 - -模型超时、队列过载和推理任务异常时，控制任务必须继续运行；若故障能够无界传播到控制路径，则系统不得进入正式实验。 - -### 4.6 步骤六：生成部署产物与准入报告 - -#### 研究问题 - -部署报告不是普通性能总结，而是对一个“模型—硬件—SylixOS—控制任务”组合能否上线的工程判定。 - -#### 报告内容 - -##### 基本信息 - -- 板卡与硬件版本； -- SylixOS、BSP、编译器和驱动版本； -- 模型、量化文件和校验值； -- 控制应用版本； -- 工具链版本。 - -##### 资源预算 - -| 项目 | 上限 | 预测值 | 实测值 | 结论 | -|---|---:|---:|---:|---| -| Flash/eMMC占用 | 待冻结 | | | | -| 静态RAM | 待冻结 | | | | -| Tensor Arena | 待冻结 | | | | -| 任务栈 | 待冻结 | | | | -| DMA缓冲 | 待冻结 | | | | -| 单次推理时间 | 待冻结 | | | | -| 控制任务最大响应时间 | 待冻结 | | | | -| `E/inference` | 待冻结 | | | | -| 启动到安全控制 | 待冻结 | | | | -| 启动到AI就绪 | 待冻结 | | | | - -##### 准入结论 - -部署结论只允许使用以下三种状态： - -- **PASS**：资源、时间、质量和保护机制全部通过； -- **PASS WITH LIMITS**：降低AI周期、模型规模或功能范围后通过； -- **REJECT**：会破坏控制截止期、超出资源预算或缺少可验证保护机制。 - -#### 自动生成的工程产物 - -- 模型权重或模型镜像； -- 静态Tensor Arena； -- 算子调用代码； -- SylixOS任务包装代码； -- 超时与规则兜底代码； -- 链接脚本和内存布局； -- 编译配置； -- 部署清单； -- 测试用例与验收脚本。 - -## 5. 工具链总体结构 - -```text -训练模型/固定数据集 - │ - ▼ -模型解析、量化与任务质量检查 - │ - ▼ -算子合法化、融合与目标芯片映射 - │ - ├──────────────┐ - ▼ ▼ -算子时间/能耗数据库 控制任务与平台描述 - │ │ - └──────┬───────┘ - ▼ - 内存规划与时间编排 - │ - ▼ - 可调度性与准入检查 - │ - ┌────────┴────────┐ - ▼ ▼ - 拒绝/降级建议 生成SylixOS工程 - │ - ▼ - RealEvo编译、部署与调试 - │ - ▼ - 板端实测与模型校准 -``` - -### 5.1 与 RealEvo 的结合方式 - -建议不要重新实现完整IDE，而是在模型编排工具与RealEvo之间定义稳定接口： - -1. 模型侧工具生成C/C++代码、权重、静态内存描述和任务配置； -2. RealEvo负责SylixOS BSP/App工程管理、交叉编译、部署和调试； -3. 编排工具生成或修改应用层配置和链接片段； -4. 板端采样程序输出执行时间、内存、功耗和异常事件； -5. 实测数据回灌算子数据库，修正下一轮预测。 - -这样可以把研究贡献集中在“模型与控制任务的联合编排”，避免重复建设已有的操作系统IDE能力。 - -## 6. 基于现有硬件的分阶段实施路线 - -### P0：在现有 RK3588 上建立完整链路 - -目标：不等待新硬件，先打通方法和工具。 - -工作内容： - -1. 确认现有工业盒的SylixOS BSP兼容性； -2. 建立普通Linux/PREEMPT_RT与SylixOS控制任务基线； -3. 先使用CPU可执行的小模型，避免一开始被NPU驱动阻塞； -4. 完成模型解析、量化、静态Arena和代码生成； -5. 完成控制任务与AI任务的固定优先级编排； -6. 完成超时、队列限长和规则兜底； -7. 在16 GB和受限内存配置下验证部署报告是否能够正确给出结论。 - -P0的成果是“方法原型”，不是MCU最终结论。 - -### P1：向 RK3568/RK3576 控制端收缩 - -目标：验证方法在较弱CPU、更小内存和更低功耗平台上的迁移能力。 - -工作内容： - -- 减小模型和Tensor Arena； -- 收紧CPU时间和功耗预算； -- 验证启动时间和看门狗恢复； -- 验证不同BSP下代码生成的可移植性； -- 比较工具预测值与板端实测偏差。 - -P1仍属于“控制端SoC验证”，正式材料中不应写成纯MCU实证。 - -### P2：增加真正 MCU 平台 - -目标：形成严格的MCU级研究证据。 - -选板前必须确认： - -- SylixOS或其lite/tiny配置能否运行； -- BSP、编译器、调试器和功耗测量链路是否可用； -- SRAM、Flash、DSP/NPU和DMA结构是否适合研究； -- 是否可以获得芯片厂商算子库和周期数据； -- 控制外设、GPIO、CAN、ADC/PWM是否满足闭环实验。 - -如果SylixOS不适合最终选定的极小MCU，可将研究拆成两层： - -1. SylixOS控制端SoC负责系统编排与工程平台验证； -2. 真正MCU负责静态模型、控制闭环和极限资源边界验证； -3. 两层共享任务描述、模型清单、内存规划和准入报告格式。 - -这比为了维持单一操作系统叙事而选择不合适的平台更符合研究真实性。 - -## 7. 推荐的首个实验样例 - -### 7.1 场景：电机状态识别与 1 ms 控制共存 - -控制链路： - -```text -ADC/编码器采样 → 1 ms控制算法 → PWM/CAN输出 -``` - -智能链路： - -```text -振动/电流窗口 → 1D CNN → 状态分类 → 规则检查 → 参数建议或告警 -``` - -关键原则： - -- 1 ms控制内环不等待AI； -- AI每50～100 ms运行一次； -- AI只提供状态分类、参数建议或告警； -- AI超时或结果非法时，继续使用规则控制； -- AI结果只有通过范围和状态机检查后才能生效。 - -### 7.2 实验变量 - -- 无AI、AI静态编排、AI无保护三组； -- CPU共享核与固定核； -- 动态堆与静态Arena； -- 完整推理与算子分段； -- 无干扰、CPU干扰、内存/DMA干扰； -- 不同量化模型； -- 正常、超时、队列过载和任务异常。 - -### 7.3 主要指标 - -| 层次 | 指标 | -|---|---| -| 控制任务 | deadline miss ratio、P99/P99.9 jitter、最大响应时间、GPIO端到端响应 | -| AI任务 | 单次推理时延、完成率、任务质量、峰值内存 | -| 系统协同 | CPU占用、内存余量、队列状态、干扰下的可用区间 | -| 能耗与启动 | `E/inference`、平均功耗、启动到安全控制、启动到AI就绪 | -| 安全与恢复 | 超时切换时间、规则触发正确率、恢复时间、故障传播范围 | - -## 8. 研究问题与论文贡献 - -### RQ1：离线联合编排能否保护控制截止期 - -比较模型单独部署、普通后台任务部署和静态联合编排，观察关键控制任务的尾延迟与截止期违约。 - -### RQ2：静态内存规划能否降低峰值与碎片风险 - -比较动态堆、固定Arena和生命周期复用三种方案，观察峰值内存、长期稳定性和部署成功率。 - -### RQ3：部署前预测能否接近板端实测 - -比较工具预测的内存、执行时间和功耗与板端实测值，建立误差范围与安全系数。 - -### RQ4：保护机制能否限制AI故障传播 - -注入超时、错误输出、队列过载和任务崩溃，测量控制任务是否继续达标以及系统恢复时间。 - -### 预期贡献 - -1. 面向智能控制任务的统一描述方法； -2. 模型—算子—控制任务联合静态编排算法； -3. 面向SylixOS的代码生成与部署接口； -4. 部署前资源和可调度性准入方法； -5. 规则兜底与故障隔离运行时； -6. 从RK3588方法原型到真正MCU实证的分级验证体系。 - -## 9. 与翼辉联合研究需要确认的接口 - -建议将以下问题整理为与翼辉的技术确认清单： - -1. 现有RK3588工业盒可复用哪个官方BSP，板级差异有哪些； -2. RK3588/RK3568上可用的任务核绑定、中断亲和性和内存限额接口； -3. RKNN/RKLLM或其他NPU运行时能否移植到SylixOS； -4. DMA连续内存、Cache维护和设备中断的推荐实现； -5. RealEvo能否接收外部工具生成的工程、链接配置和代码； -6. 是否存在适合真正MCU的SylixOS lite/tiny产品形态和参考BSP； -7. 能否提供任务切换、中断延迟、内存和功耗相关追踪接口； -8. 看门狗、任务重启、进程隔离和异常恢复的推荐工程路径； -9. 是否可联合建设算子执行时间与资源占用数据库； -10. 是否可共同定义“模型进入任务关键控制系统”的部署准入报告。 - -## 10. 最终判断标准 - -本研究成功的标志不是模型能够在板卡上输出结果，而是同时满足： - -1. 部署前能够计算模型和控制任务的资源需求； -2. 工具能够自动生成静态内存和时间布局； -3. SylixOS上的控制任务在AI和干扰负载下仍满足截止期； -4. AI任务的资源使用不超过冻结预算； -5. 模型超时或异常时规则路径可以接管； -6. 预测值和实测值之间存在可解释误差范围； -7. 同一描述和工具链能够从RK3588原型逐步迁移到更小控制端和真正MCU。 - -最终需要形成的不是一个“能够运行的小模型演示”，而是一套： - -> **能够在部署前判断可行性、在运行时维持控制边界、在异常时完成安全降级的静态智能控制基础系统。** - -## 11. 参考资料 - -### 仓库内材料 - -- `10-共享理论与方法层/06-基础设备与算力基础.md` -- `20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md` -- `20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md` -- 项目框架1中的设备、实验设计和SylixOS联合研究方资料 - -### 翼辉官方资料 - -- SylixOS / RealEvo 开发环境： -- RealEvo BSP开发： -- SylixOS系统与驱动开发： -- RK3588官方板级资料： -- RK3568看门狗与设备资料示例： diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/README.md deleted file mode 100644 index a3de76a..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# 子课题A：面向MCU的静态智能控制基础系统 - -本目录用于承接框架2中的第一个子课题，重点面向 `T5` 控制端与极小资源预算场景。 - -## 子课题定位 - -本子课题重点研究： - -> **在极小内存、极低功耗和强实时约束条件下，人工智能能力如何以静态、可分析、可部署的方式进入控制系统。** - -## 建议阅读顺序 - -1. [00-子课题定义.md](./00-子课题定义.md) -2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md) -3. [02-技术路线：静态编排、工具链与芯片协同.md](./02-技术路线：静态编排、工具链与芯片协同.md) -4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md) -5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md) -6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md) -7. [06-离线联合编排研究框架.md](./06-离线联合编排研究框架.md) - -## 当前特点 - -本子课题的关键词是： - -`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算` diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/00-子课题定义.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/00-子课题定义.md deleted file mode 100644 index 68679a9..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/00-子课题定义.md +++ /dev/null @@ -1,27 +0,0 @@ -# 子课题定义 - -## 1. 子课题名称 - -面向边侧 SoC 的混合实时控制基础系统 - -## 2. 子课题主问题 - -本子课题围绕以下问题展开： - -> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构、统一内存和异构协处理器如何共同维持控制路径与推理路径的整体实时边界。** - -## 3. 子课题边界 - -本子课题重点聚焦： - -- Linux 与 RTOS 的分工； -- Hypervisor 与隔离机制； -- Hybrid 升级为协同治理结构； -- 统一内存、总线、DMA、NPU/GPU 竞争； -- 规则兜底与闭环安全边界。 - -本子课题不以极小资源 MCU 的静态部署问题为主战场。 - -## 4. 在总课题中的位置 - -这是框架2中的第二个子课题，重点对应 `T4/T3`，也是总课题中最能体现混合结构、系统协同和边侧 SoC 真实工程复杂度的方向。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/01-研究问题与适用场景.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/01-研究问题与适用场景.md deleted file mode 100644 index d69cd9e..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/01-研究问题与适用场景.md +++ /dev/null @@ -1,29 +0,0 @@ -# 研究问题与适用场景 - -## 1. 研究问题 - -本子课题重点回答四个问题： - -1. Linux 与 RTOS 如何在同一 SoC 上分工； -2. Hypervisor 与 Hybrid 结构如何提升整体可治理性； -3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析； -4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。 - -## 2. 适用场景 - -典型场景包括： - -- 设备端 SoC； -- 工业边缘节点； -- 车载或机器人边侧平台； -- 同时承载控制与 AI 推理的异构系统。 - -## 3. 与总课题共享层的衔接 - -本子课题主要继承共享层中的： - -- `系统协同域` -- `规则兜底与控制闭环` -- `基础设备与算力基础` 中的 `T4/T3` 部分 - -同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。 diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/README.md deleted file mode 100644 index 94c79fc..0000000 --- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题B-重组前-20260924/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# 子课题B：面向边侧SoC的混合实时控制基础系统 - -本目录用于承接框架2中的第二个子课题，重点面向 `T4/T3` 设备端 SoC 与边侧混合系统场景。 - -## 子课题定位 - -本子课题重点研究： - -> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构与异构资源治理如何共同维持系统的实时边界。** - -## 建议阅读顺序 - -1. [00-子课题定义.md](./00-子课题定义.md) -2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md) -3. [02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md](./02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md) -4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md) -5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md) -6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md) - -## 当前特点 - -本子课题的关键词是： - -`Hybrid`、`Hypervisor`、`Linux+RTOS`、`统一内存`、`资源隔离`、`系统协同` diff --git a/10-研究框架/08-RTOS-Linux-Hypervisor边缘并行架构说明.md b/10-研究框架/08-RTOS-Linux-Hypervisor边缘并行架构说明.md deleted file mode 100644 index 0356054..0000000 --- a/10-研究框架/08-RTOS-Linux-Hypervisor边缘并行架构说明.md +++ /dev/null @@ -1,241 +0,0 @@ -# RTOS + Linux + Hypervisor 边缘并行架构说明 - -## 1. 架构目标 - -边缘侧采用并行分域思路：RTOS 负责控制和安全关键路径，Linux 负责 AI 推理与复杂软件生态，Hypervisor 或等价静态分区层负责空间隔离、时间干扰控制和设备分配。 - -该架构不把“让 RTOS 原生运行全部大模型软件栈”作为前提。优化目标按优先级排序为： - -1. 控制闭环截止期不被推理负载破坏； -2. AI 结果在规定的新鲜度窗口内可用； -3. 推理域故障不扩散到控制域； -4. 在前三项满足后提高推理吞吐、能效和资源利用率。 - -## 2. 逻辑架构 - -```text -┌─────────────────────────────────────────────────────────────┐ -│ 边缘计算硬件 │ -│ CPU 核 / LLC / DRAM / 内存带宽 / NPU或GPU / I/O / 时钟 │ -├─────────────────────────────────────────────────────────────┤ -│ Hypervisor、静态分区器或具备等价能力的隔离层 │ -│ vCPU/物理核分配、内存区间、IOMMU、设备直通、中断路由、监控 │ -├───────────────────────────┬─────────────────────────────────┤ -│ RTOS 控制域 │ Linux 推理域 │ -│ - 周期控制与联锁 │ - 模型加载与推理运行时 │ -│ - 现场总线与关键传感器 │ - GPU/NPU 驱动与厂商 SDK │ -│ - 时间戳、结果校验 │ - 数据预处理与后处理 │ -│ - 超时、降级与安全状态 │ - 模型更新、日志与网络服务 │ -├───────────────────────────┴─────────────────────────────────┤ -│ 有界跨域通道：共享内存环形队列 + 通知 / RPMsg / 虚拟设备等 │ -└─────────────────────────────────────────────────────────────┘ -``` - -这里的“Hypervisor”表示架构角色，不预设具体产品。若 SoC 已具备安全岛、独立 MCU、AMP 或硬件静态分区能力，只要能够提供可验证的资源和故障隔离，也可以作为实现路径。 - -## 3. 两个域的职责边界 - -### 3.1 RTOS 控制域 - -RTOS 域应拥有： - -- 周期控制、联锁、执行器输出和关键状态采集； -- 控制任务使用的定时器、关键中断和关键 I/O； -- AI 请求的采样时刻、任务编号、期望完成期限和优先级； -- AI 结果的完整性、新鲜度、置信度和序列一致性检查； -- 超时、失联、异常结果和推理域重启时的回退控制； -- 必要的看门狗与推理域生命周期控制接口。 - -RTOS 域不应依赖 Linux 域才能维持基本安全状态。AI 可增强系统能力，但关键控制闭环应明确 AI 缺席时的可接受行为。 - -### 3.2 Linux 推理域 - -Linux 域应拥有： - -- 模型文件、模型运行时和推理服务； -- GPU/NPU/DLA 等加速器驱动及厂商 SDK； -- 复杂预处理、后处理、模型编排和批处理； -- 网络、存储、模型更新以及非关键日志服务； -- 推理资源的吞吐优化和域内调度。 - -Linux 域可以对 AI 服务做软实时优化，但不得把域内平均时延等同于控制系统的实时保证。 - -### 3.3 Hypervisor/分区层 - -隔离层需要明确而不是笼统声称以下能力： - -- CPU 核是静态独占、时间分片还是混合分配； -- 内存区域是否静态划分，是否存在共享页和动态气球机制； -- LLC、内存带宽和互联是否可分配、限额或仅可观测； -- 加速器采用直通、复用还是由单一域独占； -- 设备 DMA 是否受 IOMMU 限制； -- 物理中断如何路由，是否会在控制核上产生额外虚拟化出口； -- 一个域崩溃、重启或过载时，另一域是否持续运行。 - -Hypervisor 本身也会引入 VM exit、虚拟中断和跨域通信开销，必须纳入实测，不能只把它视为零成本隔离层。 - -## 4. 跨域通信契约 - -推荐使用异步、有界、可丢弃的通信语义，避免 RTOS 控制任务同步等待 Linux 推理。 - -### 4.1 请求消息最小字段 - -| 字段 | 作用 | -|---|---| -| `request_id` | 区分请求和乱序结果 | -| `sample_time` | 标识传感数据的采样时刻 | -| `deadline` | AI 结果最晚可用时刻 | -| `priority/class` | 区分任务重要性和推理策略 | -| `payload_ref` | 指向受控共享缓冲区或内联小数据 | -| `schema/version` | 防止两域版本不一致 | - -### 4.2 结果消息最小字段 - -| 字段 | 作用 | -|---|---| -| `request_id` | 与请求配对 | -| `model_version` | 支撑审计和回滚 | -| `finish_time` | 计算跨域端到端时延 | -| `confidence/status` | 判断结果是否可用 | -| `valid_until` | 规定结果新鲜度边界 | -| `payload/checksum` | 结果与完整性校验 | - -### 4.3 控制域消费规则 - -RTOS 只在以下条件同时满足时采用 AI 结果： - -```text -ID 匹配 -AND 数据完整 -AND finish_time <= deadline -AND now <= valid_until -AND confidence/status 满足策略 -``` - -任一条件不满足时执行预定义回退，例如沿用上次可信结果、使用传统控制器、降低运行等级或进入安全状态。回退动作和完成时间本身也属于实时需求。 - -## 5. 系统级时间模型 - -AI 辅助决策链可表示为： - -```text -R_ai = C_sample + C_tx_req + Q_linux + C_pre - + C_infer + C_post + C_tx_rsp + C_validate -``` - -系统约束不是简单要求 `C_infer` 最小，而是： - -```text -R_control <= D_control - -AI 结果被采用时：R_ai <= D_ai 且 age(result) <= A_max - -AI 结果未按时到达时：R_fallback <= D_fallback -``` - -其中，控制闭环约束为硬优先级；AI 时效约束通常为任务相关的软实时或固实时约束；回退路径必须有独立期限。 - -## 6. 资源并行与隔离策略 - -### 6.1 CPU 和中断 - -- 为 RTOS 域保留独立物理核，避免与 Linux vCPU 时间复用； -- 将关键定时器和现场总线中断直达 RTOS 域； -- 将网卡、存储和加速器完成中断尽量路由到 Linux 域； -- 若共享 LLC，测量 Linux 推理对控制任务缓存行为的干扰； -- 记录 SMT、动态迁核和电源管理对分区确定性的影响。 - -### 6.2 内存、带宽和 DMA - -- 两域使用静态内存区间，共享区保持最小化； -- 共享缓冲区预分配，禁止关键路径动态扩容； -- 使用 IOMMU 或硬件访问控制限制 DMA 范围； -- 对 DRAM 带宽、内存控制器和互联竞争进行压力实验； -- 若硬件不支持带宽限额，必须把“核隔离”和“内存隔离”分开表述。 - -### 6.3 加速器 - -推荐由 Linux 推理域独占 GPU/NPU，以保留成熟驱动和运行时生态。RTOS 通过请求契约使用推理服务，而不是直接进入厂商运行时。 - -若控制域也需访问同一加速器，则必须额外解决队列仲裁、DMA 隔离、不可抢占执行段和故障复位归属。这种共享模式风险更高，应作为扩展方案而非默认主线。 - -### 6.4 功耗和热 - -分域不自动消除芯片级功耗和温度耦合。Linux 域的持续推理可能触发全芯片功耗限制或降频，进而改变 RTOS 域执行时间。因此需要： - -- 固定或记录各域频率和功率模式； -- 同步采集控制延迟、推理负载、温度和实际频率； -- 对推理域设置负载准入或功耗上限； -- 验证热稳态而非只测短时冷机性能。 - -## 7. 故障与降级状态机 - -```text -正常增强控制 - │ AI 超时/低置信度 - ▼ -传统控制或保持模式 - │ 连续超时/通信故障 - ▼ -推理域隔离与重启 - │ 控制风险上升 - ▼ -受限运行或安全状态 -``` - -需要验证的故障至少包括： - -- Linux 推理进程崩溃； -- Linux 域卡死或重启； -- 加速器驱动错误或设备复位； -- 跨域队列堆满、消息乱序或数据损坏； -- 推理持续超时； -- Linux 域 CPU、内存、网络或存储过载。 - -每种故障都要记录检测时间、隔离时间、回退完成时间、控制任务违约数和恢复后首个有效 AI 结果时间。 - -## 8. 可比较的架构组 - -| 组别 | 架构 | 用途 | -|---|---|---| -| A0 | 单 Linux，控制与推理同域 | 通用部署基线 | -| A1 | PREEMPT_RT Linux，控制与推理同域 | 实时增强 Linux 基线 | -| A2 | RTOS 同域承载控制与可运行的 AI | 适用于 MCU/小模型，不强求大模型生态 | -| A3 | RTOS 控制域 + Linux 推理域 + 分区层 | 边缘并行主方案 | -| A4 | A3 加入通信、带宽、故障和热治理机制 | 完整优化方案 | - -比较时必须固定硬件、控制任务语义、AI 模型、输入到达序列和功率策略。A2 与 A3 若使用不同推理后端，应明确这是“系统方案比较”，不能仅归因为内核差异。 - -## 9. 核心评价指标 - -### 控制域 - -- 周期任务响应时间、抖动和 deadline miss ratio； -- 外部输入到执行器输出的物理链路延迟； -- AI 过载与故障期间的观测最大响应时间； -- 回退路径完成时间。 - -### AI 链路 - -- 从 RTOS 发起请求到结果验证完成的端到端延迟； -- 结果按期率、新鲜度合格率、超时率和丢弃率； -- 吞吐、TTFT/TPOT 或任务特定推理时延； -- 推理域重启后的恢复时间。 - -### 隔离与代价 - -- 空载和推理满载时控制延迟之差； -- CPU、内存带宽、I/O、DMA 和热干扰敏感度； -- 跨域 IPC 延迟、抖动、拷贝次数和 CPU 开销； -- 静态资源预留造成的推理吞吐及能效损失。 - -## 10. 架构结论边界 - -本架构旨在证明“系统可以在 AI 负载不确定的情况下保护关键控制路径，并对 AI 结果实施有期限的安全消费”。它不自动证明： - -- Linux 域中的大模型具备硬实时性； -- Hypervisor 消除了所有共享硬件干扰； -- 一个硬件平台的分区结果可直接迁移到另一 SoC； -- 只要控制域未违约，AI 功能就一定满足任务需求。 - -最终结论必须同时报告控制保障效果、AI 结果可用性以及隔离带来的资源代价。 diff --git a/20-实验与规划/05-调整后研究问题与验证建议.md b/20-实验与规划/05-调整后研究问题与验证建议.md deleted file mode 100644 index dd9889f..0000000 --- a/20-实验与规划/05-调整后研究问题与验证建议.md +++ /dev/null @@ -1,207 +0,0 @@ -# 调整后研究问题与验证建议 - -## 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 引入后，任务关键系统如何保持实时”的核心问题。 diff --git a/word格式规范版/基础设备.docx b/word格式规范版/基础设备.docx deleted file mode 100644 index c0c3554..0000000 Binary files a/word格式规范版/基础设备.docx and /dev/null differ diff --git a/word格式规范版/基础说明.docx b/word格式规范版/基础说明.docx deleted file mode 100644 index 481c04a..0000000 Binary files a/word格式规范版/基础说明.docx and /dev/null differ diff --git a/word格式规范版/实验设计.docx b/word格式规范版/实验设计.docx deleted file mode 100644 index d407760..0000000 Binary files a/word格式规范版/实验设计.docx and /dev/null differ diff --git a/word格式规范版/最终文章规划.docx b/word格式规范版/最终文章规划.docx deleted file mode 100644 index 9ab4f76..0000000 Binary files a/word格式规范版/最终文章规划.docx and /dev/null differ diff --git a/基础设备.md b/基础设备.md deleted file mode 100644 index fb26be1..0000000 --- a/基础设备.md +++ /dev/null @@ -1,740 +0,0 @@ -# 基础设备配置（四层级 × 三档算力分级） - -> 版本: v2.0 起草日期: 2026-09-18 -> 设计目标: 为翼辉 SylixOS 调度框架研究建立 **集群→桌面→边→端** 四级硬件体系，每级内再按 **低/中/高** 三档细分 -> 现有硬件全覆盖: T2-L（4×V100 SXM）+ T3-L / T4-H（RK3588 工业盒）| 需新增: T1 集群扩展 + 其余档位 - ---- - -## 0. 分级体系总览 - -### 0.1 分级维度与分档规则 - -**分级维度**: 以「统一内存 / 显存容量」为第一分类维度——容量直接决定可承载的模型规模，且与功耗、散热、互联架构强相关，四个层级可连续衔接、无断层。 - -**分档规则**: 相邻两档的边界值归入**上界一侧** - -| 层级 | 代码 | 低级 | 中级 | 高级 | -| -------- | --- | --------------- | ---------------- | ---------------- | -| **端级** | T4 | **1~2 G** | **2~4 G** | **4~8 G** | -| **边级** | T3 | **8~16 G** | **16~32 G** | **32~64 G** | -| **桌面级** | T2 | **64~128 G** | **128~256 G** | **256~512 G** | -| **集群级** | T1 | **512 G~1 T** | —（不设中档） | **1 T~2 T** | - -> 边界值归属示例: 8 GB → 端-高；16 GB → 边-低；64 GB → 边-高；128 GB → 桌-低；512 GB → 桌-高；1 TB → 集-低。 - -### 0.2 全谱系总表（11 个档位） - -> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。 - -| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 | -| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- | -| **T4-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | | -| **T4-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | | -| **T4-H** | 4~8 G | 6~32 TOPS (INT8) | 7~21 W | ARM A76+A55 + M0 + NPU；DC 12V 被动 | **RK3588 8GB** / Jetson Orin Nano 8GB | 现有（16G 板降配） | -| **T3-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 | -| **T3-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | | -| **T3-H** | 32~64 G | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | | -| **T2-L** | 64~128 G | 500 TFLOPS (FP16) | 600~1.65 kW | x86 + 4×V100 SXM NVLink；双电源 + 360 液冷 | **4×V100 32GB SXM 塔式** | 现有 | -| **T2-M** | 128~256 G | 1000 TFLOPS (FP16) | 3.0~3.3 kW | x86 + 8×V100 SXM NVLink；双电源 + 液冷 | 8×V100 32GB SXM 整机 | 需扩展 | -| **T2-H** | 256~512 G | ~4000 TFLOPS (FP16) | 4.5~6.5 kW | x86 + 4×H100 SXM5 NVLink；高压供电 + 强制液冷 | 4×H100 80GB SXM5 工作站 | | -| **T1-L** | 512 G~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × x86+4×V100，100GbE RoCE/IB；机房风冷/液冷 | 4×（T2-L 节点）+ IB 交换机 | 需扩展 | -| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | 20~25 kW | 4 节点 × x86+4×H100，NDR 400G IB；机房级液冷 | 4×（T2-H 节点）+ NDR 交换机 | | - -### 0.3 设计原则 - -1. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。 -2. **CUDA 栈贯通 T1/T2/T3**: 集群/桌面/边级全部或大部分走 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位无缝迁移，变量只有规模。 -3. **非 CUDA 端路线**: T4 全档位与 T3-L 走 RKNN/RKLLM NPU 栈，代表极致资源约束端点，是 RTOS 调度隔离价值最大化的场景。 -4. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T3-L 16GB / T4-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。 -5. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2）与 ARM64（T3/T4），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。 - ---- - -## T1. 集群级 — 512 G ~ 2 T - -### T1.1 定位 - -大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。 - -### T1.2 档位对比 - -| 维度 | T1-L 集群-低 | T1-H 集群-高 | -| ----------- | --------------------- | --------------------------- | -| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） | -| **节点数** | 4 节点 | 4 节点 | -| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 | -| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) | -| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s | -| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB | -| **整机功耗** | ~6.6 kW | 20~25 kW | -| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） | -| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 | - -#### T1.2.1 T1-L 集群-低 — 4 节点 × 4×V100 = 512 GB（本方案主线） - -| 项目 | 规格 | 数量 | 备注 | -| --------- | ------------------------------------------------ | ------------- | --------------------------- | -| **计算节点** | 同 T2-L 桌面级配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB | -| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 | -| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 | -| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB | -| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB | -| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 | -| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 | -| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L | -| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW | -| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 | - -**显存与算力** - -| 指标 | 值 | -| --------------- | ---------------------------------- | -| **总显存** | **512 GB** (4 × 128GB) | -| 单卡 FP16 算力 | 125 TFLOPS | -| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) | -| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) | - -**可运行模型** - -| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 | -| ------------------------ | ---------- | ------- | ----- | ------------------ | -| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 | -| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray | -| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI | -| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) | -| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray | - -> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。 - -#### T1.2.2 T1-H 集群-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档） - -| 项目 | 规格 | 数量 | 备注 | -| ------- | ----------------------------------------- | --------- | --------------------- | -| 计算节点 | 同 T2-H 桌面级配置 | 4 台 | 每节点 4×H100 80GB SXM5 | -| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s | -| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 | -| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB | -| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 | -| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 | -| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 | -| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 | -| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW | - -**可运行模型** - -| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 | -| ------------------------ | ---------- | -------- | ----- | -------------------- | -| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang | -| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM | -| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI | -| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM | - -### T1.3 SylixOS 要求（T1 通用） - -| 要求项 | 描述 | 风险 | -| ------------------ | ------------------------------- | ------------------------------ | -| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） | -| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） | -| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） | -| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） | -| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** | - -### T1.4 研究角度 - -- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟 -- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟 -- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性 -- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益） -- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限） - ---- - -## T2. 桌面级 — 64 G ~ 512 G - -### T2.1 定位 - -单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。 - -### T2.2 档位对比 - -| 维度 | T2-L 桌面-低 | T2-M 桌面-中 | T2-H 桌面-高 | -| ----------- | ---------------------- | --------------------------- | --------------------------- | -| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） | -| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 | -| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) | -| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 | -| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW | -| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 | -| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 | -| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 | -| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 | -| **状态** | 现有 | 需扩展（现有平台加卡） | 需 | - -#### T2.2.1 T2-L 桌面-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点） - -| # | 部件 | 型号 / 规格 | 数量 | 备注 | -| -- | ------- | ---------------------------------------------- | ----- | --------------------------- | -| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | | -| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | | -| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 | -| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 | -| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU | -| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | | -| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 | -| 8 | 机箱 | 塔式一体定制机箱 | 1 | | -| 9 | 主电源 | 长城全模组 1650W | 1 | | -| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 | -| 11 | 散热器 | SP3 高性能散热器 | 1 | | -| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | | -| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** | - -**显存与算力** - -| 指标 | 值 | -| ---------- | --------------------------- | -| **总显存** | **128 GB** (4 × 32GB HBM2) | -| 单卡显存 | 32 GB HBM2 | -| 单卡 FP16 算力 | 125 TFLOPS | -| 总算力 (FP16) | ~500 TFLOPS | -| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) | -| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) | -| **整机功耗** | **~1650 W** (满载) | - -**可运行模型** - -| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 | -| ------------------------ | ---------- | ------ | ----- | ------------------- | -| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM | -| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM | -| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM | -| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) | -| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM | -| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp | -| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper | - -#### T2.2.2 T2-M 桌面-中 — 8×V100 SXM = 256 GB - -在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。 - -| 项目 | 规格 | 变更点 | -| --------- | ----------------------------------------------- | ------------------ | -| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 | -| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 | -| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 | -| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 | -| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 | -| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory | -| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 | -| 散热 | 360 液冷 ×2 + 机箱风道强化 | — | -| **整机功耗** | **~3.0~3.3 kW** | +100% | -| **总算力** | **~1000 TFLOPS (FP16)** | +100% | - -**可运行模型（新增/提升）** - -| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 | -| ------------------------ | ---------- | ------ | ----- | ------------------ | -| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 | -| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 | -| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — | -| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 | - -> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。 - -#### T2.2.3 T2-H 桌面-高 — 4×H100 SXM5 = 320 GB - -| 项目 | 规格 | -| ------- | ---------------------------------------- | -| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） | -| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) | -| 单卡显存 | 80 GB HBM3 | -| NVLink | 900 GB/s (GPU↔GPU) | -| CPU | AMD EPYC 9654 (96C/192T) ×1~2 | -| 内存 | 512 GB DDR5-4800 ECC | -| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） | -| 存储 | 4 TB NVMe RAID0（模型权重加载） | -| 散热 | **强制液冷（冷板式）**，风冷不可行 | -| 电源 | 2 × 3000W 冗余 / 220V | -| **整机功耗** | **~4.5~6.5 kW** | -| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS | - -**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。 - -**可运行模型（新增/提升）** - -| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 | -| ------------------------ | ---------- | ------- | ----- | ----------------- | -| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 | -| LLaMA-3-70B | FP16 | ~140 GB | 2 | — | -| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 | -| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 | - -### T2.3 SylixOS 要求（T2 三档通用） - -| 要求项 | 描述 | 风险 | -| ----------------- | ----------------------------- | ------------------- | -| x86 BSP | SylixOS 2.x LTS x86 | 低 | -| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） | -| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 | -| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） | -| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 | -| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） | - -### T2.4 对照组 OS - -- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM -- **辅助对照**: CentOS Stream 9 + RT 内核（可选） - ---- - -## T3. 边级 — 8 G ~ 64 G - -### T3.1 定位 - -边缘 AI 推理与工业控制并发。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性——推理任务与实时控制任务共享内存带宽时的隔离能力。 - -### T3.2 档位对比 - -| 维度 | T3-L 边-低 | T3-M 边-中 | T3-H 边-高 | -| --------- | ---------------------------- | -------------------------- | ----------------------------- | -| **容量** | 16 GB 统一内存 | 32 GB 统一内存 | 64 GB 统一内存 / 48 GB 独立显存 | -| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA | AGX Orin 64GB / RTX 6000 Ada | -| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) | 275 TOPS / 91 TFLOPS (FP16) | -| **功耗** | 10~30 W | 15~60 W | 60~600 W | -| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 | DC 19 V 或 ATX，风冷/液冷 | -| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ | -25~80 ℃ / 0~50 ℃ | -| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T4） | **高**（T234 BSP 需验证） | 高 / 中 | -| **状态** | （RK3588 16GB 工业盒） | | | - -#### T3.2.1 T3-L 边-低 — RK3588 16GB 工业盒（现有设备） - -**这是现有 RK3588 设备的标准归属档位**（16 GB 统一内存落在边级区间内），也是唯一可零成本立即开展研究的边级档位。 - -| 项目 | 规格 | 备注 | -| --------- | --------------------------------------- | --------------------- | -| SoC | Rockchip RK3588（同 T4-H） | SylixOS BSP 与 T4 共用 | -| 内存 | **16 GB LPDDR4X**（统一内存） | -40~60 ℃ 工业宽温 | -| NPU | 6 TOPS 原生 + **26 TOPS 算力棒扩展 = 32 TOPS** | 算力棒走 M.2 2280 | -| 功耗 | ~21~30 W（含算力棒） | 被动散热，可选小风扇 | -| 内存带宽 | ~51.2 GB/s (128-bit LPDDR4X) | 与 T4 相同，是带宽瓶颈点 | -| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T4-H 内存翻倍，可跑更大模型 | - -**备选方案（同档位、CUDA 路线）**: NVIDIA Jetson Orin NX 16GB — 100 TOPS (INT8, sparse)，1024 CUDA + 32 Tensor Core，16 GB LPDDR5 / 102.4 GB/s，10~25 W，**CUDA 生态与 T1/T2 打通**。代价是 SylixOS T234 BSP 风险高。 - -#### T3.2.2 T3-M 边-中 — NVIDIA Jetson AGX Orin 32GB - -| 项目 | 规格 | -| --------- | -------------------------------------------------- | -| **SoC** | NVIDIA T234（Grace 系列衍生） | -| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） | -| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores | -| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） | -| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) | -| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） | -| 内存带宽 | 204.8 GB/s | -| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） | -| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） | -| 存储 | 64GB eMMC + M.2 NVMe（可扩展） | -| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 | -| 视频接口 | HDMI 2.1 + DP 1.4a | -| USB | 4× USB 3.2 + 2× USB 2.0 | -| PCIe | PCIe Gen4 ×4（可扩展外设） | -| MIPI CSI | 4 通道（可接工业相机） | -| 尺寸 | 100mm × 87mm（核心模块） | -| **出厂 OS** | Ubuntu 20.04 LTS (L4T) | -| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） | - -**选择 Jetson AGX Orin 的理由** - -1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈 -2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台 -3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证 -4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试 -5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡 - -#### T3.2.3 T3-H 边-高 — 64 GB 档（两条路线） - -| 路线 | 主推 A: Jetson AGX Orin 64GB | 主推 B: 边缘工控机 + RTX 6000 Ada 48GB | -| ---------- | -------------------------------- | -------------------------------- | -| **架构** | ARM A78AE + Ampere GPU（统一内存） | x86 (Xeon/Core) + 独立 CUDA 显卡 | -| **容量** | 64 GB LPDDR5（统一内存） | 48 GB GDDR6 ECC（独立显存） | -| **算力** | 275 TOPS (INT8) | 91 TFLOPS (FP16) / 182 TFLOPS 稀疏 | -| **功耗** | 15~60 W | 整机 ~600 W | -| **散热** | 被动/主动风冷 | 主动风冷或液冷 | -| **生态** | CUDA + DLA，与 T3-M 同 BSP | 完整 CUDA + NVLink 可选 | -| **优势** | 能效极高、宽温、无风扇可行 | 算力密度高、显存带宽大、生态完整 | -| **劣势** | 统一内存带宽仅 204.8 GB/s，带宽受限 | 功耗/体积/散热不适合现场部署 | -| **适用场景** | 边缘现场、宽温环境、低功耗 | 边缘机柜、算力下沉、多模型并发 | - -**可运行模型（T3 三档合并）** - -| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 | -| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ | -| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T3-L | RKLLM | -| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T3-L / T3-M | TensorRT-LLM / RKLLM | -| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T3-L / T3-M | TensorRT-LLM / llama.cpp | -| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T3-M | TensorRT-LLM | -| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T3-M / T3-H | TensorRT-LLM | -| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | ~5-8 | T3-H | TensorRT-LLM / vLLM | -| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T3-L 以上 | llama.cpp | -| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T3-L 以上 | faster-whisper | -| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T3 全档 | TensorRT / RKNN | - -### T3.3 SylixOS 要求（T3） - -| 要求项 | 描述 | 风险 | -| -------------------- | --------------------------------------- | ---------------------------- | -| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） | -| **RK3588 BSP（T3-L）** | 与 T4-H 共用同一 BSP，零额外风险 | **极低** | -| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 | -| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 | -| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 | -| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 | -| 独立显存管理（T3-H B 路线） | x86 + 独显的显存分配与实时性 | 中 | - -> **取舍**: Jetson 路线优势在 CUDA 生态统一 + 275 TOPS + DLA；RK3588-16GB（T3-L）优势在 SylixOS BSP 风险极低 + -40~60℃ 工业级宽温。**建议 T3-L 直接用现有 RK3588 起步，T3-M/H 待 Jetson BSP 确认后再采购。** - -### T3.4 对照组 OS - -| 档位 | 主对照 | 辅助对照 | -| ---- | -------------------------------- | ----------------------------- | -| T3-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） | -| T3-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） | -| T3-H | Ubuntu 22.04 + PREEMPT_RT（x86/ARM） | Docker + KVM | - -### T3.5 功率采集 - -| 设备 | 用途 | 适用档位 | -| ----------------------------- | --------------------- | ----------- | -| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T3-L / T3-M | -| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 | -| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T3-M / T3-H | -| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-H B 路线 | - ---- - -## T4. 端级 — 1 G ~ 8 G - -### T4.1 定位 - -工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这是 RTOS 杀手锏场景——资源越紧张，RTOS 调度隔离的价值越大。 - -### T4.2 档位对比 - -| 维度 | T4-L 端-低 | T4-M 端-中 | T4-H 端-高 | -| ----------- | ---------------------- | -------------------- | ------------------------------ | -| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 | -| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano | -| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) | -| **功耗** | 3~5 W | 5~10 W | 7~21 W | -| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） | -| **供电** | DC 5V / 12V | DC 12V | DC 12V | -| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ | -| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V | -| **状态** | | | ✅ 现有（RK3588 16GB 降配） | - -#### T4.2.1 T4-L 端-低 — RK3568 核心板（1~2 GB） - -| 项目 | 规格 | -| --------- | -------------------------------------- | -| SoC | Rockchip RK3568 (22nm) | -| CPU | 4× Cortex-A55 @ 2.0 GHz | -| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） | -| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） | -| 内存带宽 | ~25.6 GB/s | -| GPU | Mali-G52（仅辅助显示） | -| 存储 | 8~16 GB eMMC | -| 网络 | 1× 千兆 + 可选 WiFi | -| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） | -| **功耗** | **3~5 W**（无风扇被动散热） | -| 工作温度 | -40 ~ 85 ℃ 工业级 | -| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） | -| 参考价格 | ~300~800 RMB（核心板/开发板） | - -**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。 -**定位价值**: 谱系最低档，用于测出「LLM 推理到底能把实时性压到多差」的**下界**，以及 RTOS 在极小内存下能否守住 1ms。 - -#### T4.2.2 T4-M 端-中 — RK3576 核心板（2~4 GB） - -| 项目 | 规格 | -| --------- | ---------------------------------------- | -| SoC | Rockchip RK3576 (8nm) | -| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） | -| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 | -| **内存** | **2~4 GB LPDDR5**（统一内存） | -| 内存带宽 | ~40 GB/s | -| **功耗** | **5~10 W**（无风扇被动） | -| 工作温度 | -40 ~ 85 ℃ 工业级 | -| 参考价格 | ~600~1,500 RMB | - -**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。 -**定位价值**: 端级主力档，算力是 T4-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。 - -#### T4.2.3 T4-H 端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB - -**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置** - -| 项目 | 规格 | 说明 | -| --------- | --------------------------------------------------- | ------------------------ | -| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** | -| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 | -| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 | -| GPU | Mali-G610 MC4 | 仅辅助显示 | -| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 | -| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 | -| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T3-L 同 | -| **功耗** | **7~21 W**（无风扇被动散热） | 6 TOPS 档 ~12W / 32 TOPS 档 ~21W | -| 工作温度 | -40 ~ 60 ℃ 工业级 | 宽温优势 | -| 出厂 OS | Ubuntu 22.04 | 换 SylixOS BSP | - -> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T3-L（16 GB 全量）** 也可作为 **T4-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。 - -**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB** - -| 项目 | 规格 | -| --------- | --------------------------------------------------- | -| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） | -| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） | -| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） | -| **功耗** | **7~25 W**（可配置 7W/15W/25W） | -| 优势 | **T4 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3-M 同栈 | -| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 | -| 参考价格 | ~$249（开发套件） | - -**可运行模型（T4-H）** - -| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 | -| ------------------------- | ---- | ------- | ----------- | ----- | -| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM | -| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM | -| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM | -| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM | - -#### T4.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备） - -**系统 (System)** - -| 项目 | 规格 | -| ------- | ---------------------------------------------------- | -| SoC | Rockchip RK3588 (8nm) | -| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） | -| MCU | Cortex-M0 @200 MHz（协处理，可选） | -| GPU | Mali-G610 MC4 | -| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | -| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T4-H | -| **显存** | 统一内存（NPU 与 CPU 共享） | - -**存储 / 扩展** - -- EMMC 64 GB（系统盘） -- 1× TF 卡槽（存储扩展） -- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒） - -**出厂软件** - -- 操作系统: **Ubuntu 22.04**（出厂预装） -- 验证方案: 替换为 SylixOS BSP for RK3588，保留 Ubuntu 22.04 作为对照组 - -**算力与功耗（T4-H 档）** - -| 指标 | 值 | -| ------------------ | ------------------------------- | -| **可用显存** | **8 GB**（16 GB 板分区限额） | -| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) | -| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) | -| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） | -| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) | -| **TDP** | **7~21 W**（无风扇被动散热） | - -### T4.3 SylixOS 要求（T4） - -| 要求项 | 描述 | 风险 | 适用档位 | -| ---------------------- | --------------------------------------- | -------------------- | --------- | -| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T4-H | -| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T4-M | -| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T4-L | -| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T4 全档 | -| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T4-H | -| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T4-H | -| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T3-L/T4-H 切换） | 中（需 SylixOS 内存域支持） | T4-H | -| CAN ×2 驱动 | 工业现场总线 | 中 | T4 全档 | -| RS485 ×2 + RS232 ×1 | 串口 | 低 | T4 全档 | -| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T4-H | -| 看门狗 / RTC | 工业可靠性 | 低 | T4 全档 | -| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T4-H 路线B | - -### T4.4 对照组 OS - -- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照） -- **辅助对照**: OpenHarmony 4.x + RT patch（可选） -- T4-L / T4-M: Buildroot + PREEMPT_RT - ---- - -## 5. 跨档位对比总表 - -### 5.1 全档位硬件规格对比 - -| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 | -| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- | -| **T4-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 | -| **T4-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 | -| **T4-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） | -| **T3-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） | -| **T3-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** | -| **T3-H** | 32~64 GB | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 | -| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） | -| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 | -| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 | -| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 | -| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 | - -### 5.2 模型规模梯度 - -| 档位 | 代表模型 | 量化 | 显存占用 | 角色 | -| -------- | --------------------------- | ---------- | ------- | -------------- | -| T4-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 谱系下界，实时性基准 | -| T4-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 端级能效拐点 | -| T4-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B | -| T3-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 边缘推理 + 工业控制 | -| T3-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 边缘多模型并发 | -| T3-H | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘可跑 72B | -| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 | -| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B | -| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 | -| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 | -| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 | - -### 5.3 SylixOS 调度框架验证重点 - -| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 | -| ----- | ----------- | ---------------------------------- | -------------------------- | -| T4-L | 极小内存下保号 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 | -| T4-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token | -| T4-H | 极致资源约束下保号 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token | -| T3-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s | -| T3-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 | -| T3-H | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS | -| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 | -| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s | -| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 | -| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS | -| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 | - -### 5.4 基线 OS 对照 - -| 档位 | SylixOS 实验组 | 主对照 (Linux RT) | 虚拟化对照 | 容器对照 | -| ------- | ---------------------- | --------------------- | -------------- | --------- | -| T4-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker | -| T4-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker | -| T4-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker | -| T3-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker | -| T3-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker | -| T3-H | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker | -| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker | -| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker | -| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 | -| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 | - ---- - -## 6. 采购与获取计划 - -| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 | -| ------ | ------- | ----------------------------- | -------------------- | ---------------------- | -| **P0** | T3-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 | -| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 | -| **P0** | T4-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T3-L 同机双档位 | -| **P1** | T4-L | RK3568 1~2GB 核心板 | ~300-800 | 谱系下界，必做 | -| **P1** | T4-M | RK3576 4GB 核心板 | ~600-1,500 | 端级能效拐点 | -| **P1** | T3-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP | -| **P2** | T3-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 | -| **P2** | T3-H | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘可跑 72B | -| **P2** | T4-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 | -| **P3** | T2-M | 4× V100 32GB SXM + 8 卡底板 + 电源 | ~70,000-100,000 | 现有平台加卡扩容 | -| **P3** | T2-H | 4× H100 80GB SXM5 工作站 | ~800,000-1,200,000 | 可租云实例替代 | -| **P3** | T1-L | 3× 计算节点 + 12× V100 + IB | ~270,000 | 可用云实例替代 | -| **P4** | T1-H | 4 节点 × 4×H100 + NDR IB | ~3,000,000+ | 强烈建议云租替代 | -| — | 仪器 | DC 功率计 ×2 (T3+T4) | ~6,000 | T4 强制 | -| — | 仪器 | INA226 采集板 ×2 | ~500 | T3+T4 | -| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3-H / T2 档 | -| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） | -| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 | -| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） | -| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 | - -### 降本策略 - -1. **P0 零成本起步**: T2-L + T3-L + T4-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。 -2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T3-L（16 GB）与 T4-H（8 GB），省去一台设备与一套 BSP 验证成本。 -3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T4-M 若 RK3576 BSP 不可用，用 T4-H 降配替代），谱系不断。 -4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。 -5. **T3-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。 -6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。 - ---- - -## 7. SylixOS BSP 适配 Checklist（跨档位汇总） - -### 7.1 x86 BSP（T2 全档 + T1 全档） - -- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动 -- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度 -- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心） -- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M） -- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H） -- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举 -- [ ] nvidia-smi / DCGM 监控 -- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行 -- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属） -- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属） -- [ ] NCCL / MPI 分布式通信库（T1 专属） -- [ ] IPMI / BMC 功耗采集 -- [ ] tickless + CPU 隔离 + 中断亲和性 -- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频） - -### 7.2 ARM64 BSP — T234 / Ampere（T3-M / T3-H-A / T4-H 路线B） - -- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认） -- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano） -- [ ] Jetson Ampere GPU CUDA 驱动 -- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属） -- [ ] 16/32/64 GB LPDDR5 统一内存管理 -- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W) -- [ ] 10GbE 网络驱动 -- [ ] MIPI CSI 工业相机接口 -- [ ] PCIe Gen4 扩展 -- [ ] 温度传感器 + 降频阈值 - -### 7.3 ARM64 BSP — RK3588（T4-H / T3-L） - -- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP） -- [ ] CPU 频率独立调节 (governor) -- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T3-L ↔ T4-H 切换） -- [ ] tickless / idle hook -- [ ] 看门狗驱动 -- [ ] **rknn / RKLLM NPU 驱动**（核心） -- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位） -- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0） -- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动 -- [ ] CAN ×2 驱动 -- [ ] RS485 ×2 + RS232 ×1 驱动 -- [ ] GPIO 子系统 -- [ ] HDMI 输出（调试） -- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导** - -### 7.4 ARM64 BSP — RK3576（T4-M） - -- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP） -- [ ] 6 TOPS NPU 驱动（RKNN 栈） -- [ ] 2~4 GB LPDDR5 内存管理 -- [ ] CAN / RS485 / 千兆网络驱动 -- [ ] 低功耗被动散热下的频率/温度联动 - -### 7.5 ARM64 BSP — RK3568（T4-L） - -- [ ] SylixOS BSP for RK3568（4×A55 SMP） -- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈） -- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点） -- [ ] CAN / RS485 / 千兆网络驱动 -- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证 diff --git a/实验设计.md b/实验设计.md deleted file mode 100644 index 022ce42..0000000 --- a/实验设计.md +++ /dev/null @@ -1,282 +0,0 @@ -# SylixOS 混合实时任务与 AI 推理实验设计 - -> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](../基础设备.md)，扩展自[原实验设计](../实验设计.md)。 -> 本文给出待执行方案，不代表已有测试结果。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。 - -## 1. 研究目标与实验范围 - -研究问题是：在端、边、桌面、集群不同资源条件下，SylixOS 的调度与资源隔离能否在保持实时任务截止期的同时，提高 AI 推理服务的有效吞吐和能效？ - -| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 | -|---|---|---|---| -| RQ1：混合负载下的实时性 | OS、调度策略、干扰强度 | 唤醒延迟、响应时间、截止期违约率 | 同硬件同负载的配对对照 | -| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | P99.9 延迟、有效吞吐、拒绝率 | 默认、完整方案与逐项消融 | -| RQ3：功耗预算下的运行能力 | 频率、空闲策略、推理并发 | J/token、温度、违约率 | 满足同一服务质量约束的配置比较 | -| RQ4：规模扩展后的瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 | - -执行分为两层：**核心实验使用现有 T2-L、T3-L 和 T4-H 内存受限配置；其他八档属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM 是主负载，YOLO 检测和语音识别是可选混合负载；训练不纳入主实验。 - -## 2. 设备分层与实验平台 - -### 2.1 四层级、十一档实验映射 - -沿用设备文档的档位标签，实际容量单列。设备文档中“512 GB 边界归桌面高档”与“512 GB 集群标为 T1-L”存在口径差异；本文按多节点架构将该集群记为 T1-L，不据容量边界推导性能。 - -| 层级与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 | -|---|---|---|---| -| T4-L 端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 | -| T4-M 端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 | -| T4-H 端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 | -| T3-L 边低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 | -| T3-M 边中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA | -| T3-H 边高 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 | -| T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 | -| T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 | -| T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 | -| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信与分布式推理 | -| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式服务与能效 | - -GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。 - -### 2.2 平台 A：现有 V100 服务器 - -依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。 - -实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。 - -分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。 - -### 2.3 平台 B：现有 RK3588 工业盒 - -依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。 - -- B16：全量 16 GB，记为 T3-L。 -- B8：同板施加 8 GB 限额，记为 T4-H 受限配置；两种配置顺序运行。 -- 原生 NPU 是首轮路径；所谓“6+26 TOPS”仅为设备文档中的组合标称。扩展芯片型号、连接方式、模型格式和任务拆分能力通过后，才增加独立对照，不假定两者能共同加速同一 LLM。 -- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。 - -**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。 - -### 2.4 测量设备 - -| 测量对象 | 工具与接线 | 要求 | -|---|---|---| -| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 | -| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 | -| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 | -| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 | -| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 | - -传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。 - -## 3. 软件与模型准入 - -### 3.1 分阶段准入门槛 - -| 门槛 | 验证内容 | 通过证据 | 失败后的处理 | -|---|---|---|---| -| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 | -| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 | -| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 | -| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 | -| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 | - -SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用。设备文档列出的软件栈均按候选路线处理，冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后再比较。 - -若仅能采用“SylixOS 实时域 + Linux 推理域”，应作为单独的异构系统架构组，注明核分配、通信和内存共享方式。该结果不能写成 SylixOS 原生 GPU/NPU 推理结论。 - -### 3.2 模型梯度与用途 - -| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 | -|---|---|---|---| -| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 | -| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 | -| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 | -| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 | -| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 | -| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 | - -模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。原稿中的 tokens/s、FPS、内存估计作为待验证参考，不作为已知性能。 - -### 3.3 输入与正确性控制 - -LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。 - -YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。 - -## 4. 指标定义与采集口径 - -### 4.1 实时性与系统开销 - -对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。 - -| 指标 | 定义 | 汇总 | -|---|---|---| -| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 | -| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 | -| 响应时间 | f_i − r_i | 分位数、观测最大值 | -| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 | -| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 | -| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 | -| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 | - -缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。 - -### 4.2 推理服务 - -在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。 - -- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。 -- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。 -- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。 -- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。 -- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。 - -### 4.3 能耗与热状态 - -在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。 - -同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。 - -报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。 - -## 5. 对照组与变量控制 - -### 5.1 OS 与部署组 - -| 编号 | 配置 | 作用 | -|---|---|---| -| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 | -| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 | -| O2 | SylixOS 默认配置 | 原生系统基线 | -| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 | -| O4 | Linux RT 等预算调优 | 避免仅一侧调优造成偏差 | -| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 | - -平台 B 原稿列出的出厂 Ubuntu 22.04 先核对镜像；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，明确区分“OS 调度效应”与“系统方案效应”。 - -### 5.2 配置控制与消融 - -所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。 - -完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。 - -## 6. 负载设计 - -### 6.1 实时任务 - -主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。 - -任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。 - -### 6.2 背景干扰与推理到达 - -| 场景 | 内容 | 目的 | -|---|---|---| -| L0 | 仅 RT | 实时性下界与测量开销 | -| L1 | 仅推理 | 最大可持续服务能力与独立能耗 | -| L2 | RT + LLM | 核心混合场景 | -| L3 | L2 + CPU 干扰 | 参考占用 25/50/75/100%，注明施加核心 | -| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 | -| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务干扰 | -| L6 | RT + LLM + YOLO（可选） | 多模型竞争与优先级影响 | -| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 | - -推理先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 λ_ref，所有 OS 使用同一绝对到达序列，测试 0.25/0.5/0.75/1.0/1.25×λ_ref。不得各组按自身吞吐重新归一化后声称承受相同负载。 - -突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。 - -## 7. 实验矩阵与具体步骤 - -### 7.1 核心实验 - -| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 | -|---|---|---|---| -| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 | -| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 | -| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 | -| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 | -| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 | -| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 | -| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 | -| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 | -| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 | - -E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。 - -E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。 - -### 7.2 条件扩展 - -| 扩展 | 前提 | 实验内容 | 结论边界 | -|---|---|---|---| -| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 | -| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 | -| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 | -| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 | -| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 | - -T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。 - -跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。 - -### 7.3 控制实验数量 - -不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。 - -## 8. 运行流程与统计方法 - -1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。 -2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。 -3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。 -4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。 -5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。 -6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。 -7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。 - -观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。 - -## 9. 验收与结果判断 - -验收分为“数据可用”“系统约束满足”和“研究假设得到支持”，避免将目标写成已取得结果。 - -| 类型 | 判据 | 说明 | -|---|---|---| -| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 | -| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 | -| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 | -| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 | -| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 | -| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 | - -原稿的“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”仅保留为历史候选目标。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，正式实验前冻结，不能看完正式结果再下调阈值。原有 8/15/21 W 数值同样不直接作为跨配置统一验收值。 - -## 10. 数据产物与论文图表 - -建议按 `results//////` 保存数据，每次运行至少包含： - -| 文件 | 内容 | -|---|---| -| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 | -| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 | -| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 | -| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 | -| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 | -| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 | - -不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。 - -最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。 - -## 11. 实施顺序与停止条件 - -| 阶段 | 工作 | 完成标志 | -|---|---|---| -| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 | -| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 | -| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 | -| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 | -| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 | -| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 | - -设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。 diff --git a/最终稿文章结构总览.png b/最终稿文章结构总览.png deleted file mode 100644 index a667c99..0000000 Binary files a/最终稿文章结构总览.png and /dev/null differ diff --git a/最终稿文章规划.md b/最终稿文章规划.md deleted file mode 100644 index 16f0a51..0000000 --- a/最终稿文章规划.md +++ /dev/null @@ -1,421 +0,0 @@ -# 最终稿文章规划 — SylixOS 大模型推理调度框架研究 - -> **版本**: v1.0 (最终稿规划) -> **日期**: 2026-09-20 -> **整合来源**: 基础设备.md + 方案1.md v1.0 (大模型负载实验设计) + 方案2.md v2.0 (第三方基准复现方法学) + -> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章 (含完整实验数据与基准对比) - ---- - -## 0. 文章定位与核心贡献 - -### 0.1 一句话定位 - -> **用业界公认方法学，在四层连续算力硬件谱系 (1 GB → 2 TB / 3 W → 25 kW) 上，首次系统化评测国产 RTOS (SylixOS) 在大模型推理负载下的低延迟、低功耗与实时保号能力，填补 RTOS 在边缘~集群算力评测领域的数据空白。** - -### 0.2 三大核心贡献 - -| 编号 | 贡献 | 来源整合 | 对标空白 | -|------|------|----------|----------| -| C1 | **四层连续算力谱系上的 RTOS 调度评测** — 从端级 RK3568 (1 GB/3 W) 到集群级 4×H100 (1.28 TB/25 kW)，11 个档位覆盖被动散热→机房液冷全散热形态，首次在连续硬件梯度上刻画 RTOS 调度性能曲线 | 基础设备.md §0~§5 | 公开研究仅覆盖单一平台或两档对比，无连续谱系 | -| C2 | **大模型混合负载下 RTOS 实时保号量化** — LLM 推理 + 1 ms 周期控制并发场景下，SylixOS 的 T_rt_max_under_llm 与 J_rt_under_llm 相对 Linux RT 的尾延迟优势量化 (≤30% = 显著优势) | 方案1.md §3, §6, §9 | 公开基准仅测吞吐 FPS，未测混合负载下的实时任务保号 | -| C3 | **RTOS 数据与业界公开基准首次横向对齐** — 引入第三方文章 (萤火虫数智笔记) 的 CPU/内存/NPU/功耗实测方法学与数据，在 SylixOS 上复现并对比，使 RTOS 数据首次可对外校验 | 方案2.md §2, §5, §7 | 国产 RTOS 在边缘算力 SoC 上的实测数据严重缺失 | - -### 0.3 目标读者与发表场景 - -| 维度 | 选择 | -|------|------| -| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) | -| 备选 | EMSOFT / DAC / MLSys (系统方向) | -| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) | -| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 | - ---- - -## 1. 文章整体结构 (十章) - -``` -第1章 引言 — 问题、动机、贡献概述 -第2章 背景与相关工作 — LLM 推理特征 + RTOS 基础 + 差距分析 -第3章 四层连续算力硬件谱系 — 11 档位体系设计与现有设备锚点 -第4章 SylixOS 调度框架技术架构 — 五层技术栈与六大优化方向 -第5章 实验方法学 — 第三方基准复现 + 混合负载场景 + 避坑约束 -第6章 大模型负载选型与配置 — 跨档位模型矩阵 -第7章 实验结果 — 基准对齐 + 实时性 + 能效 + 温度耦合 -第8章 深入分析 — 档位间性能曲线 + RTOS vs Linux RT 差异化 -第9章 讨论与威胁有效性 — 适用场景边界 + 局限性 -第10章 结论与展望 -``` - ---- - -## 2. 逐章详细规划 - -### 第1章 引言 - -**目标**: 300~500 词，点明矛盾、贡献、文章路线图。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 1.1 问题矛盾 | RTOS 追求 µs~ms 级确定性 vs LLM 推理是 GB 级内存、s 级耗时的软实时负载；边缘~集群场景中二者必须共存 | | -| 1.2 研究空白 | 公开基准 (如萤火虫文章) 全部基于 Linux/Ubuntu，国产 RTOS 在边缘算力 SoC 上的实测数据严重缺失；现有研究无连续硬件谱系 | 方案2.md §1.1 | -| 1.3 本文贡献 | C1 (四层谱系评测)、C2 (混合负载保号量化)、C3 (业界基准对齐)，一句话概述每个贡献 | | -| 1.4 文章组织 | 十章路线图 | 本规划 §1 | - -**关键图表**: 无 (引言章通常无图表或仅一张概念图)。 - ---- - -### 第2章 背景与相关工作 - -**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 2.1 LLM 推理特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 IO 抖动 | 方案1.md §1.1 | -| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 方案1.md §1.1 表 | -| 2.3 Linux RT 相对短板 | cgroup/kswapd 大模型加载停顿；PREEMPT_RT P99.9 仍受内核态长路径限制；tickless 仅 idle 启用 | 方案1.md §1.1 | -| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | FRAMEWORK.md §6, 方案2.md §2.4 | -| 2.5 第三方基准方法学 | 萤火虫文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 5 条避坑清单 | 方案2.md §2 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 | -| Tab.1 | SylixOS vs Linux RT 特性对比 | 6 项 RTOS 特性对应的大模型负载优势 + Linux RT 短板 | - ---- - -### 第3章 四层连续算力硬件谱系 - -**目标**: 800~1000 词，这是 C1 的核心展示章，也是本文区别于其他单平台研究的最大差异化。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 3.1 分级维度与分档规则 | 以「统一内存/显存容量」为第一分类维度；边界值归上界；四层连续无断层 | 基础设备.md §0.1 | -| 3.2 全谱系总表 (11 档位) | T4-L→T4-M→T4-H→T3-L→T3-M→T3-H→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 基础设备.md §0.2 | -| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 端路线 (T4 全档 + T3-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 基础设备.md §0.3 | -| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T3-L+T4-H)；一机两档 (RK3588 16 GB 同时充当 T3-L 与 T4-H)；T1/T2-H 云替代 | 基础设备.md §6 | -| 3.5 各层级定位与验证重点 | T1 跨节点分布式调度；T2 单机多卡 NVLink；T3 统一内存带宽隔离；T4 极致资源约束保号 | 基础设备.md T1~T4 各 §.1 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Fig.2 | 四层硬件谱系全景图 | 横轴=容量 (1 GB→2 TB, log 刻度), 纵轴=功耗 (3 W→25 kW, log 刻度), 11 个档位点标注, 散热形态用颜色分区 (被动/风冷/液冷/机房液冷) | -| Tab.2 | 11 档位全规格对比表 | 容量、算力、功耗、加速器架构、散热、互联、SylixOS BSP 风险、状态 (现有/需扩展) | -| Tab.3 | 模型规模梯度表 | 11 档位 × 代表模型 × 量化 × 显存占用 × 角色 (谱系下界→超大模型分布式) | -| Tab.4 | 采购计划表 | P0~P4 优先级 + 估算费用 + 降本策略 | - ---- - -### 第4章 SylixOS 调度框架技术架构 - -**目标**: 600~800 词，将 FRAMEWORK.md 的五层技术栈和六大优化方向浓缩为文章的技术背景章。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 4.1 核心问题定义 | 不是让 RTOS "跑大模型"，而是用 RTOS 做 "LLM 推理资源的调度与协调" | FRAMEWORK.md §0 | -| 4.2 五层技术栈 | L1 硬件层 → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | FRAMEWORK.md §2 | -| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-inference-scheduling.md §2 | -| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | FRAMEWORK.md §3, 01~06 子文档 | -| 4.5 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 基础设备.md §7 (BSP Checklist) | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 | -| Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 | -| Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) | -| Tab.6 | 六大优化方向概览 | 方向 × (核心问题/关键手段/目标指标/对应章节) | - ---- - -### 第5章 实验方法学 - -**目标**: 800~1000 词，这是 C2 和 C3 的方法论基础，也是本文"可复现"承诺的核心。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 5.1 方法论框架 | "基准测量 → 建模 → 算法设计 → 仿真验证 → 原型实现 → 实测对比" 六步循环 | 07-analysis-methods.md §1 | -| 5.2 第三方基准复现方法学 | 引入萤火虫文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑 sysbench/stress-ng/RKNN，与文章数据对比 | 方案2.md §5.1~§5.3 | -| 5.3 混合负载实验设计四原则 | 原则1: 混合负载而非孤立；原则2: 看尾延迟不看均值；原则3: 突发场景而非稳态；原则4: 调度精细度而非裸吞吐 | 方案1.md §3 | -| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 (Yokogawa WT310) + INA226 采集板强制；采样 ≥1 Hz | 方案2.md §5.4 | -| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 方案2.md §5.5 | -| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳 10 项强制 | 方案2.md §5.6 | -| 5.7 对照组设计 | OS 层: SylixOS vs Ubuntu+PREEMPT_RT vs (KVM/Docker)；配置层: C0 默认 → C1 tuned → C2 extreme | 方案1.md §7, 方案2.md §7.1 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Fig.5 | 实验方法论流程图 | 六步循环 + 第三方基准对齐校验门 (±15% 才准入主场景) | -| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s | -| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) | -| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 | - ---- - -### 第6章 大模型负载选型与配置 - -**目标**: 500~700 词，定义跨 11 档位的模型矩阵。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 方案1.md §2.1 | -| 6.2 跨档位模型矩阵 | T4-L: Qwen2.5-0.5B INT4；T4-M: 1.5B INT4；T4-H: 3B/7B INT4；T3-L: 3B/7B INT4 (RKLLM)；T3-M: 14B/32B INT4 (TensorRT-LLM)；T3-H: 72B INT4；T2-L: 72B INT4/14B FP16；T2-M: 72B FP16；T2-H: DeepSeek-V2 FP16；T1-L: 72B FP16 分布式；T1-H: 671B INT4 | 基础设备.md §5.2 + 方案1.md §2.2~§2.3 | -| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T3-M/H)、llama.cpp (T2-L/T3-L 退路)、RKLLM (T4/T3-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 方案1.md §2.2~§2.4 | -| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 方案1.md §2.4 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) | -| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 | - ---- - -### 第7章 实验结果 - -**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核 (sysbench)、内存带宽、NPU FPS (YOLOv5s/ResNet18/MobileNetV2)、3B LLM tok/s 与文章基线的偏差 (目标 ±10%~±20%) | 方案2.md §7.2, §9.3 第一层 | -| 7.2 低功耗结果 | P_idle / P_prefill / P_decode / E_per_token 分阶段功耗曲线；T2-L (V100) 与 T3-L/T4-H (RK3588) 两平台对照；SylixOS vs Linux RT 能效比 | 方案1.md §5.1, §6.7, 方案2.md §4.1 | -| 7.3 低延迟结果 | T_irq / T_sched / T_ctx P50~Max；T_ttft / T_tok 尾延迟分布直方图；SylixOS vs Linux RT P99.9/Max/σ 对比 | 方案1.md §5.2, §6.5 | -| 7.4 混合负载保号结果 (★ 核心) | 场景1: LLM 推理 + 1 ms 周期控制并发；T_rt_max_under_llm / J_rt_under_llm；4 变体 (A1 Linux RT 默认 / A2 Linux RT tuned / A3 SylixOS 默认 / A4 SylixOS 极限)；30 min 全周期延迟时间序列图 | 方案1.md §6.1, §5.3, §9.3 | -| 7.5 多模型并发与突发场景 | 场景2: 多模型流水线 P0/P1/P2 优先级公平性；场景3: 突发加载/切换瞬间实时性保持；场景4: GPU/NPU 多请求调度公平性 | 方案1.md §6.2~§6.4 | -| 7.6 温度-功耗-性能耦合 | 场景8: 25%→100% CPU 逐步加压的三维耦合曲线；SylixOS vs Linux RT 降频触发温度与性能下降斜率 | 方案2.md §4.4, §6.8 | -| 7.7 异构核分配 | 场景6: RK3588 大核 A76 (LLM) + 小核 A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 方案1.md §6.6 | -| 7.8 跨档位性能曲线 | 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线 (现有 P0 档位实测 + 扩展档位预估) | 基础设备.md §5.3, 基础设备.md §5.1~§5.2 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 | -| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 W(t) 曲线, SylixOS vs Linux RT 叠加 | -| Fig.7 | 混合负载实时任务延迟分布 (★ 核心证据) | P50~Max 直方图 + 时间序列, 4 变体叠加, 突出 A4 的"细长尾部"优势 | -| Fig.8 | LLM token 延迟直方图 | Qwen2.5-7B 1 流 1 h 采集, SylixOS vs Linux RT | -| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间实时任务延迟 spike, SylixOS ≤50 µs vs Linux RT 100 µs~1 ms | -| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 | -| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T4-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 | -| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 | - ---- - -### 第8章 深入分析 - -**目标**: 800~1000 词，从数据中提炼规律性结论。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 8.1 档位间性能曲线规律 | 容量每 ×2 时 RTOS 优势的变化趋势；端级 (资源越紧→RTOS 价值越大) vs 集群级 (资源充裕→RTOS 优势收窄) 的拐点分析 | 基础设备.md §5.3 | -| 8.2 SylixOS vs Linux RT 差异化量化 | 按 §9.4 优越性判据：T_rt_max_under_llm ≤30% = 显著优势 / ≤60% = 可比偏优 / >60% = 未体现；按档位和场景分别判定 | 方案1.md §9.4 | -| 8.3 混合负载下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 不被 decode 抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 加载大模型不引入额外抖动；中断线程化 + 亲和性 → NPU 中断不污染实时核 | 方案1.md §1.1 表, 05-irq-realtime.md | -| 8.4 能效分析 | 每 token 能耗 vs 档位 (V100 集群能效基线 vs H100 能效上限)；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 J/token 对比 | 基础设备.md §0.3, 06-power-thermal.md | -| 8.5 BSP 风险与可行性 | x86 BSP (低风险, V100 已验证) vs ARM64 RK3588 BSP (极低, 现有) vs T234 Jetson BSP (高, 需翼辉确认) vs RKLLM 移植 (高, 核心风险)；档位跳跃验证降本策略 | 基础设备.md §7, 方案1.md §10 | - -**关键图表**: - -| 编号 | 图表 | 描述 | -|------|------|------| -| Fig.12 | RTOS 优势 vs 硬件档位趋势图 | 横轴=11 档位, 纵轴=SylixOS 相对 Linux RT 的 P99.9 改善百分比, 标注"显著优势/可比偏优/未体现"区间 | -| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) | -| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) | - ---- - -### 第9章 讨论与威胁有效性 - -**目标**: 400~600 词，诚实地界定适用边界和局限性。 - -| 小节 | 内容要点 | 来源映射 | -|------|----------|----------| -| 9.1 适用场景边界 | 资源越紧张 (T4) → RTOS 价值越大；资源充裕 (T1-H) → RTOS 优势收窄, 可能"可比偏优"；混合负载 (LLM+RT 并发) → RTOS 杀手锏；纯吞吐场景 → 通用 OS 可能更高 | 方案1.md §3, §9.4 | -| 9.2 威胁有效性 | (1) RKLLM 移植风险: 若未完成, 退路 llama.cpp CPU 推理但失去 NPU 优势, 需标注; (2) V100 驱动成熟度: 4 卡 NVLink 联用可能受限, 单卡先行; (3) sysbench/stress-ng 移植: POSIX 兼容可行性高但需验证; (4) 量化精度差异: 同模型同量化跨 OS 不变, 已控制; (5) 室温/散热波动: 25±2 ℃ + 液冷恒定 | 方案1.md §10, 方案2.md §11 | -| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | FRAMEWORK.md §6, 方案2.md §2.4 | -| 9.4 方法论局限 | 文章仅引用单一第三方来源 (萤火虫文章), 跨平台参照 (昇腾 Qwen-7B) 为非本方案硬件; 消融实验仅在现有 P0 档位可完整执行; 扩展档位 (T1-H/T2-H) 依赖云租替代, 数据可比性需说明 | 方案2.md §13 后续建议 | - ---- - -### 第10章 结论与展望 - -**目标**: 300~400 词，总结贡献并指出未来方向。 - -| 小节 | 内容要点 | -|------|----------| -| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果 (基准对齐 ±X%、混合负载 ≤Linux RT X%、能效 ≤Linux RT X%) | -| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 | -| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-inference-scheduling.md §8 | - ---- - -## 3. 来源文档到章节的映射矩阵 - -| 来源文档 | 主要贡献章节 | 次要贡献章节 | -|----------|------------|------------| -| **基础设备.md** | §3 (硬件谱系) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) | -| **方案1.md v1.0** | §5.3 (四原则), §7.4 (混合负载) | §2.1~§2.3 (LLM 推理特征/RTOS 优势/Linux 短板), §5.7 (对照组), §6 (模型选型), §7.2~§7.5 (功耗/延迟/并发/突发), §7.7 (异构), §8.2 (优越性量化), §9.2 (威胁有效性) | -| **方案2.md v2.0** | §5.2 (基准复现), §5.4~§5.6 (强制约束) | §2.5 (第三方方法学), §7.1 (基准对齐结果), §7.6 (温度耦合), §9.3 (与已有工作关系), §9.4 (方法论局限) | -| **FRAMEWORK.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §8.3 (根因分析), §10.3 (开放问题) | -| **01-inference-scheduling.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) | -| **02-kv-cache-memory.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) | -| **03-accelerator-collab.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) | -| **04-quantization-scheduling.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) | -| **05-irq-realtime.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) | -| **06-power-thermal.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) | -| **07-analysis-methods.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) | - ---- - -## 4. 关键数据产物清单 - -| 编号 | 产物 | 类型 | 优先级 | 依赖 | -|------|------|------|--------|------| -| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 基础设备.md 已就绪 | -| D2 | 跨档位模型矩阵 | 数据表 | P0 | 基础设备.md + 方案1.md 已就绪 | -| D3 | RK3588 上 sysbench/stress-ng 基准复现数据 | 实测数据 | P0 | 需 SylixOS BSP + sysbench 移植 | -| D4 | 业界基准对比表 (SylixOS vs 文章基线) | 对比表 | P0 | D3 | -| D5 | 混合负载 30 min 全周期延迟时间序列 | 实测数据 | P0 | 需混合负载驱动脚本 + 4 变体 | -| D6 | 混合负载延迟分布直方图 (4 变体叠加) | 图表 | P0 | D5 | -| D7 | 功耗分阶段曲线 (prefill/decode/idle) | 图表 | P0 | 功率计采集 + LLM 推理 | -| D8 | LLM token 延迟直方图 (1 h 采集) | 图表 | P1 | vLLM/RKLLM benchmark | -| D9 | 突发加载瞬间实时任务时间序列 | 图表 | P1 | 混合负载脚本 + 模型切换 | -| D10 | 温度-功耗-性能三维耦合曲线 | 图表 | P1 | stress-ng 逐步加压 + 温度日志 | -| D11 | 跨档位性能连续曲线 | 图表 | P1 | P0 档位实测 + P1~P4 档位预估 | -| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 | -| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 方案2.md §5.6 模板 | - ---- - -## 5. 写作优先级与依赖关系 - -``` -Phase 0: BSP 适配 + 工具移植 (3 周) - ├─ SylixOS RK3588 BSP 部署 - ├─ sysbench / stress-ng / RKLLM 移植验证 - └─ vLLM / llama.cpp 在 SylixOS 编译运行 - -Phase 1: 基准复现 + 文章骨架 (1.5 周) - ├─ D3: RK3588 基准复现 → D4: 业界对比表 - ├─ 撰写: §1 引言 + §2 背景 + §3 硬件谱系 + §4 技术架构 + §5 方法学 + §6 模型选型 - └─ 依赖: D3 通过 ±15% 对齐门 → 准入 Phase 2 - -Phase 2: 低功耗测试 + 温度耦合 (2 周) - ├─ D7: 功耗曲线 + D10: 温度耦合曲线 - └─ 撰写: §7.2 + §7.6 - -Phase 3: 低延迟 + 混合负载测试 (3 周) - ├─ D5+D6: 混合负载核心证据 + D8: token 延迟直方图 + D9: 突发场景 - └─ 撰写: §7.3 + §7.4 + §7.5 - -Phase 4: 异构调度测试 (1 周) - ├─ 场景6: A76+A55+M0 异构分配 - └─ 撰写: §7.7 - -Phase 5: 数据汇总 + 深入分析 + 全文定稿 (2.5 周) - ├─ D11: 跨档位曲线 + D12: 优越性矩阵 - ├─ 撰写: §7.8 + §8 深入分析 + §9 讨论 + §10 结论 - └─ 全文校对 + 图表终版 -``` - -**总周期: ~13 周** (Phase 0~5 累计) - ---- - -## 6. 章节字数预算 - -| 章节 | 预算字数 | 占比 | -|------|---------|------| -| §1 引言 | 400 | 4% | -| §2 背景与相关工作 | 700 | 7% | -| §3 四层硬件谱系 | 900 | 9% | -| §4 技术架构 | 700 | 7% | -| §5 实验方法学 | 900 | 9% | -| §6 模型选型 | 600 | 6% | -| §7 实验结果 | 1800 | 18% | -| §8 深入分析 | 900 | 9% | -| §9 讨论 | 500 | 5% | -| §10 结论 | 350 | 3% | -| 参考文献 + 附录 | ~2000 | 23% | -| **总计** | **~9750** | 100% | - -> 注: 按 RTSS/RTAS 会议论文 10~12 页双栏计算, 正文约 8000~10000 词, 参考文献+附录另计。 - ---- - -## 7. 核心叙事线 (Storyline) - -``` -问题矛盾 (§1) - → RTOS 确定性 vs LLM 计算密集, 边缘~集群必须共存 - → 空白: 国产 RTOS 在边缘算力上零实测数据 - -背景铺垫 (§2) - → LLM 推理的 CPU/内存/长尾特征 - → RTOS 的 6 项调度优势 + Linux RT 的 3 项短板 - → 第三方方法学引入 (5 维度 + 5 避坑) - -硬件谱系 (§3) ← C1 差异化 - → 11 档位连续梯度: 1 GB/3 W → 2 TB/25 kW - → 现有 P0 零成本起步 (V100 + RK3588) - → 一机两档降本 - -技术架构 (§4) - → 五层技术栈 + 六大优化方向 - → LLM 推理 DAG → RTOS 任务映射 - → BSP 适配要点与风险 - -方法学 (§5) ← C2/C3 基础 - → 第三方基准复现 (先对齐 ±15% 才准入) - → 混合负载四原则 (杀手锏设计) - → 功耗真测 + 温度监控 + 元数据强制 - -模型选型 (§6) - → 跨 11 档位的 Qwen/LLaMA/MiniCPM/Whisper 矩阵 - → INT4/INT8/FP16 量化梯度 - -实验结果 (§7) ← 本文核心 - → 7.1 基准对齐 (第一层门) - → 7.2~7.3 功耗/延迟 (基础指标) - → 7.4 混合负载保号 (★ 杀手锏证据) - → 7.5~7.7 并发/突发/异构 - → 7.8 跨档位连续曲线 - -深入分析 (§8) - → 档位间趋势: 资源越紧 → RTOS 价值越大 - → 优越性量化: ≤30% 显著优势 / ≤60% 可比偏优 - → 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和 - → 能效: V100 基线 vs H100 上限, INT4 拐点 - -讨论 (§9) - → 适用边界: T4 杀手锏, T1-H 可能收窄 - → 威胁有效性: RKLLM 移植/V100 驱动/sysbench 移植 - → 与已有工作: vs vLLM/NPU SDK/CUDA Stream/第三方文章 - -结论 (§10) - → 三大贡献量化回顾 - → 跨平台/功能安全/分布式/自适应展望 -``` - ---- - -## 8. 待确认事项 - -| 编号 | 待确认项 | 影响章节 | 当前假设 | -|------|---------|---------|---------| -| Q1 | SylixOS 在 x86+4×V100 NVLink 的 CUDA 驱动支持度 | §4.5, §7.3, §8.5 | 需翼辉确认; 单卡先行, 4 卡作 stretch | -| Q2 | RK3588 BSP 是否集成 rknn/RKLLM | §5.2, §7.1, §9.2 | 需翼辉确认; 退路 llama.cpp CPU | -| Q3 | sysbench/stress-ng 在 SylixOS 可移植性 | §5.2, §7.1 | POSIX 兼容, 假设可行 | -| Q4 | T234 (Jetson Orin) BSP 是否支持 | §3.2 (T3-M/H) | 风险高; T3-L 用 RK3588 起步 | -| Q5 | RK3588 板卡是否引出 M0 调试接口 | §7.7 (场景6) | 若未引出, 场景6 需调整 | -| Q6 | 是否纳入功能安全 SIL2/IEC 61508 章节 | §10.2 展望 | 暂列为展望, 不入正文 | -| Q7 | 是否纳入昇腾 Qwen-7B 作为第二业界参照 | §7.1, §9.4 | 暂列为后续, 非本方案硬件 | -| Q8 | 主对照组确认: Ubuntu 22.04+PREEMPT_RT | §5.7 | 与第三方文章配置一致, 可比性最高 | - ---- diff --git a/说明文档.md b/说明文档.md deleted file mode 100644 index 25e424b..0000000 --- a/说明文档.md +++ /dev/null @@ -1,132 +0,0 @@ -# SylixOS 大模型推理调度研究逻辑说明 - -## 1. 文档目的 - -本文用于解释[整体逻辑流程图](./整体逻辑流程图.md)，说明《基础设备.md》《实验设计.md》和《最终稿文章规划.md》如何共同组成一套完整的研究方案。 - -三份文档承担不同职责： - -| 文档 | 回答的问题 | 在研究中的作用 | -|---|---|---| -| [基础设备.md](./基础设备.md) | 在哪些硬件条件下研究？ | 定义四层、十一档硬件谱系及现有设备锚点 | -| [实验设计.md](./实验设计.md) | 如何产生可信且可复现的证据？ | 定义准入、对照、负载、指标、统计与验收方法 | -| [最终稿文章规划.md](./最终稿文章规划.md) | 如何把证据组织成论文贡献？ | 把硬件、方法、结果和分析映射到论文十章结构 | - -整个研究的主线是： - -> 硬件谱系 → 软件与模型准入 → 公平对照 → 混合负载实验 → 可复现数据 → 跨档位规律 → 论文贡献。 - -## 2. 核心研究矛盾 - -实时控制任务通常要求微秒到毫秒级的确定性，大模型推理却会长时间占用 CPU、内存、总线、GPU 或 NPU，并产生排队、模型加载、KV Cache 和中断干扰。两类任务共存时，单纯提高模型吞吐不能说明系统适合实时场景。 - -因此，本研究不只考察“模型能跑多快”，而是同时回答三个问题： - -1. 在 LLM 推理干扰下，1 ms 周期任务是否仍能满足截止期？ -2. SylixOS 的资源隔离和调度机制能否改善尾延迟，同时避免过大的推理吞吐损失？ -3. 在满足相同实时性和推理服务约束时，系统能否降低每 token 能耗？ - -## 3. 为什么建立四层硬件谱系 - -《基础设备.md》以可用内存或显存为主要分级维度，构建端、边、桌面和集群四个层级。这样可以观察系统瓶颈随硬件规模变化的过程： - -| 层级 | 主要资源矛盾 | 研究重点 | -|---|---|---| -| T4 端级 | 内存和功耗预算非常紧张 | 极小资源下的实时任务保留能力 | -| T3 边级 | CPU、NPU/GPU 共享统一内存 | 带宽隔离、多模型竞争和功率模式 | -| T2 桌面级 | 多 GPU 共享 CPU、内存与互联 | NVLink 通信、多卡调度和并发公平性 | -| T1 集群级 | 节点内计算与节点间通信耦合 | RDMA/NCCL 抖动及跨节点调度 | - -当前最重要的实测锚点是： - -- RK3588 16 GB 作为 T3-L 边级平台； -- 同一 RK3588 施加 8 GB 内存预算，作为 T4-H 受限配置； -- 4×V100、128 GB 总显存服务器作为 T2-L 桌面级平台。 - -其余档位用于后续采购、扩容或云租后的条件扩展。现有设备负责产生核心证据，扩展设备用于验证规律能否跨硬件规模成立。 - -需要注意，RK3588 的 8 GB 限额配置只能用于研究内存预算变化，不能等同于真实 8 GB 板卡的功耗、物理带宽或热特性。 - -## 4. 为什么必须先做准入 - -设备可以启动，不代表加速器、模型和混合负载已经具备可比较条件。因此实验被划分为五个连续门槛： - -| 门槛 | 核心检查内容 | -|---|---| -| G0 设备准入 | 启动、SMP、容量、接口和硬件拓扑 | -| G1 测量准入 | 单调时钟、周期任务、日志和功耗仪器 | -| G2 加速器准入 | CUDA、RKLLM、RKNN、驱动和基本算子 | -| G3 模型准入 | 模型转换、加载、正确推理和峰值内存 | -| G4 混合负载准入 | RT 与 LLM 同时稳定运行至少 30 分钟 | - -只有通过 G4 的配置才能进入正式对照实验。准入失败本身也是研究结果，应记录为 BSP、驱动、模型格式或容量限制，不能用估计值补齐。 - -## 5. 如何保证对照公平 - -主对照包括普通 Linux、Linux PREEMPT_RT、SylixOS 默认配置和 SylixOS 优化配置。比较时需要固定： - -- 模型版本、量化格式、tokenizer、输入长度、输出长度和随机种子； -- CPU 核数量、实时优先级、内存预算、加速器数量和频率策略； -- 推理请求到达序列、背景干扰强度、预热时间和测量窗口； -- 环境温度、散热条件、驱动与框架版本。 - -如果两个系统无法使用等价推理后端，结果应表述为“完整系统方案比较”，不能只归因于操作系统调度器。 - -## 6. 实验如何逐步展开 - -实验采用从简单到复杂的顺序： - -1. E0 确认设备、测量和空载基线。 -2. E1 测量实时任务唤醒、响应、IPC 和物理接口延迟。 -3. E2 单独测量模型容量、TTFT、TPOT、吞吐和能耗。 -4. E3 运行核心场景，即 1 ms 实时任务与 LLM 推理并发。 -5. E4 比较 RK3588 的 16 GB 与 8 GB 预算配置。 -6. E5 比较 V100 的 1、2、4 卡运行状态及公平性。 -7. E6 分析温度、频率、功耗与性能耦合。 -8. E7 逐项移除核隔离、IRQ 亲和、内存预分配、准入控制等机制，确认收益来源。 -9. E8 对最终候选配置进行 24 小时长稳与恢复测试。 - -背景负载从仅实时任务、仅推理逐步增加到 RT+LLM、CPU/内存/I/O 干扰以及突发过载。这样可以确定系统在哪一个压力区间开始出现排队、降频或截止期违约。 - -## 7. 哪些指标构成核心证据 - -实时性证据包括 P50、P95、P99、P99.9、观测最大响应时间和截止期违约率。论文中的“实时保号”必须建立在截止期违约统计和完整样本量上，不能只比较平均延迟。 - -推理服务证据包括 TTFT、TPOT、成功请求吞吐、有效吞吐、成功率、超时率和拒绝率。有效吞吐只统计满足预先冻结服务约束的请求，防止通过拒绝请求或牺牲实时任务获得虚假吞吐优势。 - -功耗证据使用整机输入端功率测量，计算 J/token 和 tokens/J，并同时记录温度、实际频率和降频时间。GPU/NPU 软件遥测可以用于解释能耗来源，但不能代替整机功率计。 - -多卡和多节点实验还需要报告强扩展效率、弱扩展吞吐、通信尾延迟和多租户公平性。 - -## 8. 数据如何转化为论文贡献 - -实验数据最终对应三项贡献： - -| 贡献 | 所需证据 | 对应论文内容 | -|---|---|---| -| C1 四层连续算力谱系评测 | 各档位的容量、功耗、瓶颈与扩展趋势 | 第3章硬件谱系、第7章结果、第8章跨档位分析 | -| C2 混合负载实时保号量化 | RT+LLM 下的尾延迟、违约率、有效吞吐和消融结果 | 第4章调度机制、第5章方法、第7章核心结果 | -| C3 可复现方法与基准对齐 | 统一输入、环境元数据、完整原始数据和外部基准复现 | 第5章方法学、第7章基准结果、第9章有效性威胁 | - -文章的论证顺序应保持为：先说明为什么需要四层谱系，再说明 SylixOS 的调度机制和实验方法，然后给出结果，最后讨论优势产生的原因、适用范围和局限性。 - -## 9. 实测、计划与结论边界 - -论文中应严格区分以下三类内容： - -- **实测结果**：已通过准入并完成实验的数据； -- **候选目标**：正式实验前冻结的服务或性能阈值； -- **扩展计划**：尚未获得设备、驱动或测量条件的实验。 - -设备标称 TOPS、TFLOPS、TDP 和模型预估 tokens/s 不能写成实验结果。FP16 TFLOPS 与 INT8 TOPS不能直接比较，多卡总显存也不能直接推导模型一定可运行。 - -24 小时无违约只能表述为“在指定工况和样本量下未观测到违约”，不能证明理论最坏情况。没有温箱数据时，也不能宣称已经验证 RK3588 的完整工业温区。 - -## 10. 最终闭环 - -这套研究的最终闭环不是追求某一平台的最高 tokens/s，而是寻找一条可重复验证的关系： - -> 随着资源从端级扩展到集群级，SylixOS 的实时调度和资源隔离在什么负载范围内能显著改善实时任务确定性，这种改善需要付出多少吞吐和能耗代价，其优势又会在哪个硬件档位开始减弱。 - -如果数据支持该关系，就形成四层硬件谱系、混合负载实时保号和统一评测方法三项论文贡献；如果某些档位不支持，也应把适配失败、容量上限和优势消失的边界作为研究结论的一部分。 - diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/01-推理图任务调度参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/01-推理图任务调度参考.md deleted file mode 100644 index 77a9a67..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/01-推理图任务调度参考.md +++ /dev/null @@ -1,43 +0,0 @@ -# 推理图任务调度参考 - -## 1. 与本项目的关系 - -本方向连接两类研究：一类是固定优先级、EDF、响应时间分析等经典实时调度理论；另一类是 LLM 服务中的连续批处理、prefill/decode 分离、分块 prefill 和 SLO 感知调度。本项目的增量应落在两者交叉处：把推理图阶段映射为可度量、可准入、可隔离的 RTOS 任务，同时保障关键周期任务。 - -## 2. 核心必引资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” JACM, 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | 周期任务、固定优先级与 EDF 的理论基础 | 定义关键保障任务模型和可调度性讨论的起点 | -| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和释放抖动的固定优先级响应时间分析 | 为推理、中断与共享资源干扰进入 RTA 提供基础 | -| W. Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022. [USENIX](https://www.usenix.org/conference/osdi22/presentation/yu) | A | 迭代级调度和连续批处理 | 作为 LLM 服务调度基线，不作为实时保证 | -| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 请求调度与 KV 分页耦合、吞吐提升 | 支撑调度与内存联合设计及 vLLM 对照 | -| A. Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/agrawal) | A | 分块 prefill、decode 干扰与吞吐—时延权衡 | 支撑 prefill 可分段化和关键任务插入点设计 | -| Y. Zhong et al., “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin) | A | TTFT/TPOT 双 SLO、prefill/decode 解耦和 goodput | 对应本项目 TTFT、TPOT 和有效吞吐联合门槛 | - -## 3. 扩展参考 - -| 资料 | 关注点 | -|---|---| -| A. Gujarati et al., “Serving DNNs like Clockwork: Performance Predictability from the Bottom Up,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | DNN 推理可预测性、受控执行和 deadline-aware 调度 | -| A. Agrawal et al., “SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills,” 2023. [arXiv](https://arxiv.org/abs/2308.16369) | prefill 分块、decode-maximal batching 与流水线气泡 | - -## 4. 可形成的论文论点 - -1. 把 `prefill/decode/postprocess` 从服务框架内部阶段提升为可被 RTOS 观测和治理的任务图节点。 -2. 比较固定优先级、EDF、混合优先级和准入控制在双目标场景下的边界。 -3. 以满足 `TTFT + TPOT + 关键任务 deadline` 的有效吞吐，而不是总 tokens/s，作为调度目标。 -4. 分析推理阶段不可抢占区间、驱动提交和完成中断对 RTA 的附加阻塞项。 - -## 5. 对应证据与实验 - -- 指标：`TTFT`、`TPOT`、端到端时延、有效吞吐、关键任务 `P99.9/Max`、违约率。 -- 场景：L1、L2、L3、L5、L7。 -- 对照：FCFS/默认批处理、连续批处理、分块 prefill、完整 RTOS 方案及消融。 -- 关键边界：GPU/NPU 内核通常不能被 CPU 调度器直接细粒度抢占，必须实测设备与驱动行为。 - -## 6. 不应直接推出的结论 - -- 云端 LLM 系统的 SLO 达标不等于硬实时保证。 -- 平均 tokens/s 提升不能说明关键保障任务更可预测。 -- RTA 中的执行时间和阻塞项若未经目标硬件测量，不能作为安全上界。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/02-KV-Cache与内存管理参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/02-KV-Cache与内存管理参考.md deleted file mode 100644 index ee55dec..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/02-KV-Cache与内存管理参考.md +++ /dev/null @@ -1,41 +0,0 @@ -# KV Cache 与内存管理参考 - -## 1. 与本项目的关系 - -KV Cache 同时影响容量、内存带宽、请求并发和尾延迟。在 RTOS 场景中，研究重点不是单纯提高缓存命中率，而是控制动态分配、换入换出、DMA 和回收行为对关键任务造成的不可预测干扰。 - -## 2. 核心必引资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 块式 KV 分配、碎片控制、共享与调度耦合 | 作为分页池设计和 vLLM 基线 | -| Y. Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/sheng23a.html) | A | GPU/CPU/存储分层放置与 I/O 调度 | 支撑分层 KV/权重放置，但需强调其吞吐导向 | -| Z. Zhang et al., “H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html) | A | 基于重要 token 的 KV 淘汰及质量影响 | 用于“容量—质量—时延”三目标实验 | -| W. Lee et al., “InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/lee) | A | KV 预取、CPU offload、动态池管理 | 对应 CPU—加速器带宽与预取干扰研究 | -| P. Patel et al., “vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention,” 2024. [arXiv](https://arxiv.org/abs/2405.04437) | B | 利用虚拟内存保持逻辑连续、比较分页内核复杂度 | 作为 PagedAttention 的替代路线和消融参考 | - -## 3. 研究问题映射 - -| 本项目问题 | 参考资料启发 | 必须补充的 RTOS 证据 | -|---|---|---| -| 内存池预分配是否减少尾延迟 | PagedAttention 的块式管理 | 分配路径时延、关键任务 `P99.9/Max`、碎片率 | -| KV 换出是否可控 | FlexGen、InfiniGen | DMA/内存带宽竞争、外部接口响应和违约率 | -| KV 淘汰如何影响可用性 | H2O | 固定题集质量、输出可用率、恢复到全量 KV 的开销 | -| 多请求是否相互污染 | 分页与共享机制 | 每租户上限、OOM 隔离、Jain 指数和逐租户 SLO | -| B8/B16 容量边界 | 各类压缩/分页工作 | 峰值驻留集、KV 增长曲线、首次失败点和错误类型 | - -## 4. 建议实验变量 - -- KV 块大小、内存池大小、预分配比例和保留余量； -- 上下文长度、并发度、输出长度和突发到达； -- GPU/NPU 本地、主存和存储三级放置； -- 淘汰策略：LRU、近期 token、重要 token、固定配额； -- 是否锁页、是否异步预取、DMA 并发数和带宽限额。 - -输出至少包括峰值内存、碎片率、分配失败率、KV 迁移字节数、带宽、`TTFT/TPOT`、质量、关键任务尾延迟和 OOM 恢复行为。 - -## 5. 不应直接推出的结论 - -- 内存占用减少不必然降低端到端时延；压缩、索引和搬移可能增加尾延迟。 -- 论文中的 perplexity 或准确率保持不代表任务关键应用输出可用。 -- Linux/CUDA 的虚拟内存和 UVM 机制不能假定在 SylixOS、NPU SDK 或受限 SoC 上等价存在。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/03-加速器协同调度参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/03-加速器协同调度参考.md deleted file mode 100644 index 16c4773..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/03-加速器协同调度参考.md +++ /dev/null @@ -1,54 +0,0 @@ -# 加速器协同调度参考 - -## 1. 与本项目的关系 - -本方向研究 CPU 调度、驱动提交、DMA、GPU/NPU 执行和完成中断组成的完整链路。核心是识别哪些环节受 RTOS 控制，哪些环节只受厂商运行时或固件控制，并通过端到端时间戳验证协同效果。 - -## 2. 核心资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| NVIDIA, “CUDA Programming Guide: Asynchronous Execution, Streams and Events.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html) | A | 流、事件、同步、并发和优先级语义 | 定义 CUDA 路线中的提交和同步边界 | -| NVIDIA, “CUDA Programming Guide: Unified Memory.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/unified-memory.html) | A | CPU/GPU 统一内存、迁移及流关联 | 解释缺页/迁移引入的不确定性，不能替代实测 | -| Z. Bai et al., “PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/bai) | A | GPU 应用切换、模型传输与执行流水化 | 支撑多模型共享和切换开销研究 | -| A. Gujarati et al., “Serving DNNs like Clockwork,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | A | 可预测 GPU 推理、执行时间建模和准入 | 作为加速器可预测性相邻工作 | -| Y. Choi, M. Rhu, “PREMA: A Predictive Multi-task Scheduling Algorithm for Preemptible Neural Processing Units,” HPCA 2020. [DOI](https://doi.org/10.1109/HPCA47549.2020.00030) | A | 可抢占 NPU 多任务预测调度 | 支撑 NPU 细粒度抢占的研究假设，需检查实际硬件支持 | -| MLCommons, “MLPerf Inference.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、负载发生和准确率约束 | 用于外部性能方法对齐，不替代双目标测试 | - -## 3. 硬件路线需单独核对的官方资料 - -- NVIDIA：CUDA Toolkit、驱动、MPS/MIG、DCGM 与 NCCL 对应版本文档； -- Rockchip：RKNN Toolkit2、RKLLM、RKNPU2 Runtime 与对应芯片技术参考； -- 其他 NPU/GPU：运行时队列、优先级、超时、复位、DMA 和性能计数器文档； -- SylixOS：BSP、中断、DMA、一致性、IOMMU 和驱动接口资料。 - -闭源资料若不能公开引用，应在论文中描述可复现的外部行为，不披露受限内容。 - -## 4. 建议链路分解 - -```text -请求到达 -→ CPU 预处理 -→ 驱动/运行时提交 -→ DMA/内存迁移 -→ 加速器排队 -→ kernel/NPU task 执行 -→ 完成中断 -→ CPU 后处理 -→ 外部输出 -``` - -每段都应有时间戳或外部观测点。设备事件只能衡量设备域执行，不能替代 CPU 到结果可用的端到端时延。 - -## 5. 可形成的论文论点 - -1. RTOS 可通过 CPU/IRQ 亲和性、队列限长、预分配和准入减少主机侧不确定性。 -2. 加速器运行时不提供硬优先级保证时，RTOS 的收益会受设备不可抢占区间限制。 -3. 异步流水可能提高吞吐，但需要同时检查关键任务尾延迟、内存带宽和中断干扰。 -4. 多加速器扩展需分开报告单请求并行、多实例吞吐与通信开销。 - -## 6. 不应直接推出的结论 - -- CUDA stream priority 是调度提示，不是硬实时保证。 -- GPU 支持并发 kernel 不代表特定工作负载必然并发执行。 -- 加速器利用率高不等于有效吞吐高，也不等于关键任务 deadline 达标。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/04-量化与精度感知调度参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/04-量化与精度感知调度参考.md deleted file mode 100644 index fc90462..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/04-量化与精度感知调度参考.md +++ /dev/null @@ -1,44 +0,0 @@ -# 量化与精度感知调度参考 - -## 1. 与本项目的关系 - -本方向不只比较 INT4/INT8/FP16 的速度，而是研究在不同任务紧迫度、资源预算和热状态下，能否选择满足质量门槛的最低成本精度，并保证切换过程不会破坏关键任务实时性。 - -## 2. 核心必引资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| E. Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers,” ICLR 2023. [OpenReview](https://openreview.net/forum?id=tcbBPnfwxS) | A | 基于近似二阶信息的低比特权重量化 | 作为 3/4-bit PTQ 方法基线 | -| G. Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/xiao23c.html) | A | W8A8、激活离群值平滑、硬件效率 | 作为 INT8 权重—激活量化基线 | -| J. Lin et al., “AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration,” MLSys 2024. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html) | A | 面向端侧的激活感知权重量化 | 对应 T5/T4/T3 设备端路线 | -| T. Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale,” NeurIPS 2022. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html) | A | 激活离群值与混合精度分解 | 支撑异常通道和精度保持讨论 | -| T. Dettmers et al., “QLoRA: Efficient Finetuning of Quantized LLMs,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html) | A | NF4、双重量化和分页优化器 | 主要用于背景；本项目若不训练，不作为主实验 | -| Z. Lin et al., “QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving,” MLSys 2025. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html) | A | 权重、激活和 KV 联合低比特系统设计 | 支撑量化与内存/内核协同研究 | - -## 3. 精度感知调度应补足的研究空白 - -现有量化论文通常回答“某种格式能否保持平均精度并加速推理”，但本项目还需要回答： - -- 精度切换是否引起模型加载、重新编译、缓存失效或内存峰值； -- 动态切换期间关键保障负载是否出现尾延迟峰值； -- 低比特内核在目标 NPU/GPU 上是否真正加速，而非只有模型更小； -- 质量门槛、实时门槛和功耗门槛能否同时满足； -- 对不同风险等级请求，能否采用不同的可接受精度下限。 - -## 4. 建议实验矩阵 - -| 维度 | 建议取值 | -|---|---| -| 精度 | FP16/BF16、INT8、INT4；仅测试后端真实支持项 | -| 模型变量 | 同一模型修订、同一 tokenizer、同一输入与解码参数 | -| 质量 | 固定题集、perplexity/准确率/F1/任务判分、输出可用率 | -| 性能 | TTFT、TPOT、端到端时延、有效吞吐 | -| 系统 | 峰值内存、切换时间、能耗、温度、关键任务违约与尾延迟 | -| 调度 | 静态精度、基于 deadline 的精度、基于热/功耗预算的精度 | - -## 5. 不应直接推出的结论 - -- 权重压缩比不能替代整机内存、速度或能效实测。 -- perplexity 接近不等于所有任务质量和安全性等价。 -- 不同量化后端的算子、校准和数值格式不同，通常只能视为整套软件栈比较。 -- 动态精度调度若未测切换开销，不能宣称适合实时路径。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/05-中断与实时性保障参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/05-中断与实时性保障参考.md deleted file mode 100644 index 536175c..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/05-中断与实时性保障参考.md +++ /dev/null @@ -1,54 +0,0 @@ -# 中断与实时性保障参考 - -## 1. 与本项目的关系 - -本方向为论文的“可保障性”提供理论和系统基础，覆盖固定优先级响应时间、共享资源阻塞、优先级倒置、中断线程化、CPU/IRQ 亲和性以及外部闭环测量。 - -## 2. 经典理论资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | RMS/EDF 与周期任务基础 | 建立基本任务模型 | -| L. Sha, R. Rajkumar, J. P. Lehoczky, “Priority Inheritance Protocols: An Approach to Real-Time Synchronization,” IEEE TC, 1990. [DOI](https://doi.org/10.1109/12.57058) | A | 优先级继承、优先级上限与有界阻塞 | 支撑锁竞争和优先级倒置分析 | -| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和抖动的精确固定优先级分析 | 构建含 IRQ/驱动阻塞的 RTA | -| K. Tindell, A. Burns, A. Wellings, “An Extendible Approach for Analyzing Fixed Priority Hard Real-Time Tasks,” Real-Time Systems, 1994. [DOI](https://doi.org/10.1007/BF01088593) | A | 固定优先级分析扩展 | 用于更复杂任务和通信分析 | - -## 3. 内核与测量资料 - -| 资料 | 等级 | 可支撑内容 | -|---|---|---| -| Linux Kernel, “PREEMPT_RT Theory of Operation.” [官方文档](https://docs.kernel.org/core-api/real-time/theory.html) | A | 可抢占锁、rtmutex、优先级继承和线程化中断 | -| Linux Kernel, “How realtime kernels differ.” [官方文档](https://docs.kernel.org/core-api/real-time/differences.html) | A | 普通 Linux 与 PREEMPT_RT 的内核语义差异 | -| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | 唤醒延迟工具、参数、限制和最大值解释 | -| Linux `rt-tests` 项目. [kernel.org](https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/) | B | cyclictest、hwlatdetect 等实现与版本记录 | - -## 4. 本项目分析框架 - -关键任务响应时间可写为： - -```text -R_i = C_i + B_i + I_irq,i + I_sched,i - + sum(ceil((R_i + J_h) / T_h) * C_h) -``` - -其中 `C_i` 是自身执行时间，`B_i` 是共享资源阻塞，`I_irq,i` 是中断与驱动干扰，`I_sched,i` 是调度器和不可抢占区间干扰，求和项是高优先级任务干扰。该式只用于组织分析；每个项的取值和适用假设必须单独验证。 - -实测至少覆盖： - -- 计划释放、就绪、开始和完成时间； -- 唤醒延迟、响应时间、完成抖动、违约率和观测最大值； -- IRQ 数量、处理时间、CPU 亲和性和最长关中断区间； -- 推理提交、DMA 和完成中断与关键任务峰值的时间关联； -- GPIO/CAN/RS485/网络外部回路端到端时延。 - -## 5. 对照与消融 - -- O0 普通 Linux、O1 PREEMPT_RT、O2 SylixOS 默认、O3 SylixOS 优化、必要时 O4 等预算调优； -- 逐项去除 CPU 隔离、IRQ 亲和性、优先级继承、内存预分配和推理准入； -- 同时报人工智能有效吞吐代价，避免通过饿死推理任务获得低抖动。 - -## 6. 不应直接推出的结论 - -- cyclictest 测得的是特定路径的唤醒延迟，通常不等于业务任务完整响应时间。 -- 实测最大值不是 WCET；零违约不是硬实时证明。 -- PREEMPT_RT 和专用 RTOS 的机制差异必须通过等价任务语义比较，不能只比较工具默认输出。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/06-能耗与热管理参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/06-能耗与热管理参考.md deleted file mode 100644 index bdfce2d..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/06-能耗与热管理参考.md +++ /dev/null @@ -1,51 +0,0 @@ -# 能耗与热管理参考 - -## 1. 与本项目的关系 - -本方向关注满足人工智能和关键实时约束时的能效，而不是脱离任务完成质量的最低功率。功率、温度、频率、有效吞吐和违约必须使用对齐的时间窗口联合分析。 - -## 2. 核心资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| MLCommons, “MLPerf Inference Power Measurement.” [官方文档](https://docs.mlcommons.org/inference/power/) | A | 外部功率分析仪、PTDaemon、测量窗口和配置 | 设计整机功耗采集链路 | -| MLCommons, “MLPerf Inference Benchmark Suite.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、性能与准确率约束 | 对齐负载发生和结果报告方法 | -| SPEC, “SPECpower_ssj2008.” [官方资料](https://www.spec.org/osg/power_ssj2008/) | A | AC 输入功率—性能联合测量、负载档位 | 借鉴整机边界和多负载点报告 | -| W. Huang et al., “HotSpot: A Compact Thermal Modeling Methodology for Early-Stage VLSI Design,” IEEE TVLSI, 2006. [DOI](https://doi.org/10.1109/TVLSI.2006.876103) | A | 热 RC 模型、瞬态与稳态温度 | 支撑热动态建模背景，不替代板级传感器实测 | -| NVIDIA, “DCGM Field Identifiers.” [官方文档](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html) | A | GPU 功率、能量、温度、频率和降频原因 | V100/H100 路线的设备侧归因数据 | - -## 3. 统一计算口径 - -```text -E_total = integral(P(t), t0, t1) -E/token = E_total / N_output -effective_E/token = E_total / N_qualified_output -tokens/J = N_output / E_total -throttling_ratio = throttled_time / valid_measurement_time -``` - -主结果使用整机输入端测量。设备遥测只作归因；TDP、标称功耗和电源额定值不能替代实测。`N_output=0` 时能效不可计算。 - -## 4. 建议实验 - -1. 空闲、prefill、decode 和混合负载分阶段功率曲线； -2. 25/50/75/100% 负载下的温度—频率—性能耦合； -3. 不同固定频率/DVFS/功耗上限下的 `E/token` 与 deadline miss； -4. 冷态、热稳态和 24 h 后的 TTFT/TPOT、吞吐与关键任务尾延迟； -5. 降频前后同一到达流的有效吞吐变化； -6. O0～O4 在相同双目标门槛下的能效比较。 - -每次运行记录环境温度、散热方式、风扇策略、功率计型号、量程、精度和采样率。 - -## 5. 可形成的论文论点 - -- RTOS 的准入、空闲管理和频率策略可能降低无效执行和失败请求的能耗。 -- 更低精度或更高并发可能降低 `J/token`，但热饱和后可能扩大尾延迟和违约率。 -- 应寻找满足双目标约束的 Pareto 前沿，而不是独立最小化功率或最大化吞吐。 - -## 6. 不应直接推出的结论 - -- 芯片遥测功率不能代表整机功率。 -- 短时冷态跑分不能代表热稳态或 24 h 性能。 -- 更低平均功率不等于更低任务能耗；运行时间延长可能提高总能量。 -- 未取得温箱数据时不能宣称覆盖全温域。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/07-方法论与评估工具链参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/07-方法论与评估工具链参考.md deleted file mode 100644 index e66c2aa..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/07-方法论与评估工具链参考.md +++ /dev/null @@ -1,66 +0,0 @@ -# 方法论与评估工具链参考 - -## 1. 与本项目的关系 - -本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。 - -## 2. 核心资料 - -| 资料 | 等级 | 可支撑内容 | 本项目使用方式 | -|---|---|---|---| -| J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. [Google Research](https://research.google/pubs/the-tail-at-scale/) | A | 大规模系统尾延迟的来源和重要性 | 支撑 P99/P99.9 而非均值作为核心证据 | -| V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. [arXiv](https://arxiv.org/abs/1911.02549) | A/B | 标准负载发生、场景、准确率与性能方法 | 作为 AI 基准方法学参照 | -| MLCommons, “MLPerf Inference Submission Guide.” [官方文档](https://docs.mlcommons.org/inference/submission/) | A | LoadGen、系统描述、Closed/Open division 和可比性 | 设计外部基准对齐和 manifest | -| ACM, “Artifact Review and Badging.” [官方政策](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | A | 可用、可运行、可复用与结果复现 | 规划代码、数据和复现包 | -| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | RT 延迟测试设计、参数和限制 | 作为 Linux 辅助基线及测量避坑依据 | -| R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. [PDF](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf) | A/B | Jain 公平指数 | 多租户相对独占吞吐公平性 | - -## 3. 本项目最低方法要求 - -### 3.1 公平对照 - -冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。 - -### 3.2 样本与重复 - -- 普通性能单元至少 5 次独立运行； -- 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性； -- 1 ms 周期任务记录计划释放数、缺失数和全部违约； -- 长稳运行 24 h，保留完整时间序列； -- 跨运行使用中位数、区间及按运行/时间块 bootstrap。 - -### 3.3 失败处理 - -拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。 - -### 3.4 三层证据 - -```text -AI 目标负载：TTFT/TPOT/端到端/质量/可用性 -关键保障负载：违约率/P99.9/Max/外部闭环 -系统协同：有效吞吐/E-token/热/公平/恢复/24 h -``` - -任何“更优”结论都必须说明另外两层是否仍达标。 - -## 4. 工具链建议 - -| 目的 | 工具或方式 | 注意事项 | -|---|---|---| -| OS 跟踪 | SylixOS trace、ftrace、perf、事件日志 | 统一事件语义，不直接比较工具自身字段 | -| RT 辅助测试 | rt-tests/cyclictest、GPIO 打点 | cyclictest 不等于业务端到端响应 | -| 加速器分析 | CUDA profiler/DCGM、RKNN/RKLLM 日志 | 版本固定；设备事件只作阶段分解 | -| 外部时序 | 示波器、逻辑分析仪、CAN/RS485 分析仪 | 保存探头、触发、分辨率和空回路基线 | -| 功率与热 | 外部功率计/PDU、板载温度与频率 | 时间窗口对齐，遥测不替代整机功率 | -| 分析 | R/Python、bootstrap、CDF/ECDF、时间序列 | 不静默删异常，不把相关样本当独立样本 | - -## 5. 推荐数据结构 - -每次运行保留 `manifest.json`、`requests.csv`、`rt.csv`、`power.csv`、`thermal.csv`、`events.log` 和 `summary.json`。原始数据只读保存，图表和摘要由版本化脚本生成。 - -## 6. 不应直接推出的结论 - -- 统计显著不等于工程差异重要，应同时报告效应量与阈值。 -- 单次最佳结果不能代表配置能力。 -- 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。 -- 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/08-标准与工程资料参考.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/08-标准与工程资料参考.md deleted file mode 100644 index 475ecbc..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/08-标准与工程资料参考.md +++ /dev/null @@ -1,57 +0,0 @@ -# 标准与工程资料参考 - -## 1. 文档定位 - -本文件列出论文方向可能涉及但不应与学术论文混为一谈的标准、官方工程文档和安全边界资料。标准是否适用取决于最终行业场景、系统边界和认证目标。 - -## 2. 功能安全与任务关键系统 - -| 标准/资料 | 适用范围 | 本项目可能的关系 | -|---|---|---| -| IEC 61508, *Functional safety of electrical/electronic/programmable electronic safety-related systems* | 通用功能安全 | 定义安全生命周期、SIL 和证据要求；本项目不应在未认证时宣称合规 | -| ISO 26262, *Road vehicles — Functional safety* | 道路车辆 | 若落到车载控制与 AI 辅助功能，可用于场景和安全目标分解 | -| ISO/PAS 8800, *Road vehicles — Safety and artificial intelligence* | 车载 AI 安全 | 用于 AI 输出不确定性、数据和安全论证背景 | -| DO-178C | 航空机载软件 | 若研究航空部署，可参考软件保证等级和验证独立性 | -| ARINC 653 | 航空综合模块化系统分区 | 支撑时间/空间分区的相邻工程背景 | -| IEC 62443 系列 | 工业自动化与控制系统安全 | 涉及联网工业控制时补充网络安全边界 | - -正式引用应从 IEC、ISO、RTCA、EUROCAE、SAE 或 ARINC 的标准目录核对版本与访问权限。标准通常受版权保护，本仓库只保存条目和适用性说明，不复制正文。 - -## 3. 实时通信与时间同步 - -| 标准/资料 | 作用 | 使用边界 | -|---|---|---| -| IEEE 802.1AS | 广义精确时间协议 | 跨设备单向时延需要同步精度证据 | -| IEEE 802.1Qbv | 时间感知整形 | 可用于 TSN 周期流量窗口规划 | -| IEEE 802.1Qbu / IEEE 802.3br | 帧抢占 | 分析关键流量受大帧阻塞的边界 | -| IEEE 1588 | 精确时间协议 | 记录 grandmaster、硬件时间戳和误差 | -| CAN/CAN FD、RS-485 对应规范 | 工业接口 | 固定波特率、帧长、总线负载和时间戳位置 | - -## 4. 操作系统与处理器接口资料 - -- Linux PREEMPT_RT 官方文档：[Real-time preemption](https://docs.kernel.org/core-api/real-time/index.html)。 -- POSIX 实时扩展：线程调度、时钟、定时器、内存锁定和优先级协议；需按目标 OS 支持集核对。 -- Arm 架构、GIC、SMMU 和缓存一致性官方手册：用于解释中断路由、DMA 和共享内存边界。 -- PCIe、IOMMU、NVLink、NCCL 等规范或官方文档：用于多加速器/多节点通信路径。 -- SylixOS BSP/API/驱动资料：用于确认优先级、中断、内存、设备复位和追踪接口的实际能力。 - -## 5. 基准与测量规范 - -| 资料 | 可借鉴内容 | -|---|---| -| [MLPerf Inference](https://docs.mlcommons.org/inference/index_gh/) | 场景、负载发生、准确率约束、系统描述与结果合规 | -| [MLPerf Power](https://docs.mlcommons.org/inference/power/) | 外部仪器、时间同步、测量窗口与功率记录 | -| [SPECpower_ssj2008](https://www.spec.org/osg/power_ssj2008/) | 整机 AC 功率、多个负载档位与功效比 | -| [ACM Artifact Review and Badging](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | 可用、可运行、可复用和结果复现证据 | - -## 6. 论文中的合规表述 - -建议使用： - -> 本研究借鉴相关标准中的任务关键性、时间/空间隔离和测量原则，但实验平台与研究原型未经过相应行业认证，因此结果不构成功能安全等级、适航或产品合规声明。 - -避免使用： - -- “满足 SIL2/SIL3”——除非完成规定流程并取得正式证据； -- “达到航空级/车规级”——除非硬件、软件、流程和环境均符合对应标准； -- “证明硬实时安全”——除非有完整时序模型、可信 WCET、可调度性证明和覆盖充分的验证证据。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/README.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/README.md deleted file mode 100644 index 50d7e97..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/README.md +++ /dev/null @@ -1,51 +0,0 @@ -# 论文方向参考文件索引 - -## 1. 目录用途 - -本目录为 `10-研究框架` 七个研究方向提供可追溯的论文、标准和工程资料入口。它不是完整综述，也不代表文中列出的方案已经在 SylixOS 或本项目硬件上得到验证。 - -参考资料按以下证据等级使用： - -| 等级 | 类型 | 建议用途 | -|---|---|---| -| A | 同行评审论文、正式标准、官方内核/硬件文档 | 支撑定义、方法选择和主要论证 | -| B | arXiv 预印本、官方项目文档、开放源码实现 | 支撑前沿方案、实现路线和复现实验 | -| C | 厂商白皮书、博客或二手综述 | 仅作背景和线索，不单独支撑核心结论 | - -优先引用论文正式页面、DOI、标准组织或厂商官方文档。正式写作前仍需通过学校或机构数据库核对作者、卷期、页码、版本和 BibTeX。 - -## 2. 文件与研究方向映射 - -| 文件 | 对应研究文件 | 主要主题 | -|---|---|---| -| [01-推理图任务调度参考.md](./01-推理图任务调度参考.md) | `01-推理图任务调度.md` | 经典实时调度、LLM 连续批处理、prefill/decode 调度、SLO | -| [02-KV-Cache与内存管理参考.md](./02-KV-Cache与内存管理参考.md) | `02-KV-Cache与内存管理.md` | 分页、换出、压缩、淘汰、容量隔离 | -| [03-加速器协同调度参考.md](./03-加速器协同调度参考.md) | `03-加速器协同调度.md` | CPU/GPU/NPU 协同、流、事件、DMA、共享与切换 | -| [04-量化与精度感知调度参考.md](./04-量化与精度感知调度参考.md) | `04-量化精度感知调度.md` | PTQ、权重量化、激活量化、KV 量化、精度—时延联合约束 | -| [05-中断与实时性保障参考.md](./05-中断与实时性保障参考.md) | `05-中断与实时性保障.md` | PREEMPT_RT、优先级继承、响应时间分析、中断线程化、测试 | -| [06-能耗与热管理参考.md](./06-能耗与热管理参考.md) | `06-能耗与热管理.md` | 整机功耗、E/token、DVFS、温度、降频与热漂移 | -| [07-方法论与评估工具链参考.md](./07-方法论与评估工具链参考.md) | `07-方法论与评估工具链.md` | MLPerf、尾延迟、统计、可复现性、长稳与公平性 | -| [08-标准与工程资料参考.md](./08-标准与工程资料参考.md) | 全部方向 | 功能安全、时间敏感网络、硬件接口与工程边界 | -| [参考文献.md](./参考文献.md) | 论文十章与整个项目 | 连续编号的论文参考文献候选清单与章节映射 | - -## 3. 建议引用策略 - -每项核心主张至少建立“理论基础 + 相邻系统工作 + 本项目实测”三段证据： - -```text -经典理论或标准 - → LLM/AI 系统领域的相邻工作 - → 本项目在 O0～O4、T5～T1 条件下的实测与边界 -``` - -例如，“RTOS 优化提高双目标可保障性”不能只引用 vLLM 或 PREEMPT_RT 文档，而应同时给出实时调度理论、LLM 服务调度工作、对照实验与消融结果。 - -## 4. 维护规则 - -- 每条新资料需记录标题、作者或组织、年份、正式入口和与本项目的关系。 -- 预印本被正式会议或期刊接收后，优先替换为正式版本。 -- 厂商文档需记录访问日期和软件/驱动版本。 -- 不将论文报告的相对提升直接移植为本项目预期值。 -- 不将“平均性能改善”表述为硬实时保证；不将“未观测到违约”表述为理论最坏界。 - -本目录最后核验日期：**2026-09-21**。 diff --git a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/参考文献.md b/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/参考文献.md deleted file mode 100644 index d65a145..0000000 --- a/项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/参考文件/参考文献.md +++ /dev/null @@ -1,170 +0,0 @@ -# 论文参考文献候选清单 - -## 1. 文档说明 - -本文依据仓库根目录的 `最终稿文章规划.md`、`00-项目总览`、`10-研究框架`、`20-实验与规划` 以及现有参考文件，整理拟投实时系统、嵌入式系统或机器学习系统会议论文时可使用的参考文献。 - -书目格式参照 `GB/T 7714—2015`，英文会议论文保留原始会议名称。在线文档统一记录访问日期 `2026-09-21`。最终投稿时应使用目标会议的 BibTeX/LaTeX 样式重新生成，并再次核对作者、页码、DOI 和版本。 - -当前项目已经从旧规划中的“四层谱系”调整为 `T5~T1` 五类部署形态与 11 个代表档位。本文献表按当前项目口径组织，但仍可支撑旧版 `最终稿文章规划.md` 的十章结构。 - -## 2. 章节—参考文献映射 - -| 论文内容 | 建议优先引用 | 支撑作用 | -|---|---|---| -| 第1章 引言 | `[1]~[10]`、`[42]`、`[50]~[53]` | 实时保障基础、任务关键 AI 背景和安全边界 | -| 第2章 背景与相关工作 | `[1]~[32]` | 经典调度、PREEMPT_RT、LLM 推理服务、KV Cache、加速器和量化 | -| 第3章 部署形态与硬件谱系 | `[34]~[39]`、`[43]~[47]` | Edge/Datacenter 方法、功率边界、模型与推理运行时 | -| 第4章 SylixOS 调度框架 | `[1]~[9]`、`[12]~[33]`、`[43]~[47]` | 任务图、内存、异构加速、量化、中断与运行时实现 | -| 第5章 实验方法学 | `[5]`、`[6]`、`[34]~[42]`、`[48]`、`[49]` | 延迟测试、MLPerf、功率、统计、公平性和可复现性 | -| 第6章 模型与负载 | `[11]`、`[12]`、`[27]~[33]`、`[43]~[47]` | Transformer、低比特模型、Qwen、llama.cpp、TensorRT-LLM | -| 第7章 实验结果 | `[34]~[41]` | 指标、功率、尾延迟、温度、公平性和统计解释 | -| 第8章 深入分析 | `[1]~[33]`、`[37]~[41]` | 根因分析、机制对照与跨层权衡 | -| 第9章 威胁有效性 | `[7]~[10]`、`[34]~[42]`、`[48]~[53]` | 系统边界、复现性、功能安全与跨设备测量限制 | -| 第10章 结论与展望 | `[23]`、`[24]`、`[26]`、`[33]`、`[50]~[53]` | 动态调度、精度/资源协同、任务关键 AI 和安全论证 | - -## 3. 实时调度、RTOS 与操作系统基础 - -[1] LIU C L, LAYLAND J W. Scheduling algorithms for multiprogramming in a hard-real-time environment[J]. Journal of the ACM, 1973, 20(1): 46-61. DOI: [10.1145/321738.321743](https://doi.org/10.1145/321738.321743). - -[2] SHA L, RAJKUMAR R, LEHOCZKY J P. Priority inheritance protocols: An approach to real-time synchronization[J]. IEEE Transactions on Computers, 1990, 39(9): 1175-1185. DOI: [10.1109/12.57058](https://doi.org/10.1109/12.57058). - -[3] AUDSLEY N, BURNS A, RICHARDSON M, et al. Applying new scheduling theory to static priority pre-emptive scheduling[J]. Software Engineering Journal, 1993, 8(5): 284-292. DOI: [10.1049/sej.1993.0034](https://doi.org/10.1049/sej.1993.0034). - -[4] TINDELL K, BURNS A, WELLINGS A J. An extendible approach for analyzing fixed priority hard real-time tasks[J]. Real-Time Systems, 1994, 6(2): 133-151. DOI: [10.1007/BF01088593](https://doi.org/10.1007/BF01088593). - -[5] LINUX KERNEL COMMUNITY. Theory of operation: Real-time preemption[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/theory.html](https://docs.kernel.org/core-api/real-time/theory.html). - -[6] LINUX FOUNDATION REAL-TIME LINUX. Cyclictest: Test design, interpretation and limitations[EB/OL]. [2026-09-21]. [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start). - -[7] 翼辉信息. SylixOS 概述[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html](https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html). - -[8] 翼辉信息. SylixOS 发展历程[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html](https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html). - -[9] QNX. Priorities and scheduling: QNX Neutrino RTOS[EB/OL]. [2026-09-21]. [https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html](https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html). - -[10] THE OPEN GROUP. POSIX.1-2024: Realtime functions and general information[S/OL]. 2024[2026-09-21]. [https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html). - -## 4. Transformer、LLM 推理调度与服务系统 - -[11] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]//Advances in Neural Information Processing Systems 30. 2017: 5998-6008. [https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need](https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need). - -[12] DAO T, FU D Y, ERMON S, et al. FlashAttention: Fast and memory-efficient exact attention with IO-awareness[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html](https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html). - -[13] DAO T. FlashAttention-2: Faster attention with better parallelism and work partitioning[C]//International Conference on Learning Representations. 2024. [https://openreview.net/forum?id=mZn2Xyh9Ec](https://openreview.net/forum?id=mZn2Xyh9Ec). - -[14] YU G I, JEONG J S, KIM G W, et al. Orca: A distributed serving system for Transformer-based generative models[C]//16th USENIX Symposium on Operating Systems Design and Implementation. 2022. [https://www.usenix.org/conference/osdi22/presentation/yu](https://www.usenix.org/conference/osdi22/presentation/yu). - -[15] KWON W, LI Z, ZHUANG S, et al. Efficient memory management for large language model serving with PagedAttention[C]//Proceedings of the 29th ACM Symposium on Operating Systems Principles. 2023. [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180). - -[16] AGRAWAL A, KEDIA N, PANWAR A, et al. Taming throughput-latency tradeoff in LLM inference with Sarathi-Serve[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 117-134. [https://www.usenix.org/conference/osdi24/presentation/agrawal](https://www.usenix.org/conference/osdi24/presentation/agrawal). - -[17] ZHONG Y, LIU S, CHEN J, et al. DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 193-210. [https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin). - -[18] SUN B, HUANG Z, ZHAO H, et al. Llumnix: Dynamic scheduling for large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 173-191. [https://www.usenix.org/conference/osdi24/presentation/sun-biao](https://www.usenix.org/conference/osdi24/presentation/sun-biao). - -[19] GUJARATI A, KARANASOS K, CURINO C, et al. Serving DNNs like Clockwork: Performance predictability from the bottom up[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020. [https://www.usenix.org/conference/osdi20/presentation/gujarati](https://www.usenix.org/conference/osdi20/presentation/gujarati). - -[20] SHENG Y, ZHENG L, YUAN B, et al. FlexGen: High-throughput generative inference of large language models with a single GPU[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202. [https://proceedings.mlr.press/v202/sheng23a.html](https://proceedings.mlr.press/v202/sheng23a.html). - -[21] ZHANG Z, SHENG Y, ZHOU T, et al. H2O: Heavy-Hitter Oracle for efficient generative inference of large language models[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html). - -[22] LEE W, LEE J, SEO J, et al. InfiniGen: Efficient generative inference of large language models with dynamic KV cache management[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 155-172. [https://www.usenix.org/conference/osdi24/presentation/lee](https://www.usenix.org/conference/osdi24/presentation/lee). - -[23] PRABHU R, NAYAK A, MOHAN J, et al. vAttention: Dynamic memory management for serving LLMs without PagedAttention[EB/OL]. arXiv:2405.04437, 2024[2026-09-21]. [https://arxiv.org/abs/2405.04437](https://arxiv.org/abs/2405.04437). - -[24] BAI Z, ZHANG Z, ZHU Y, et al. PipeSwitch: Fast pipelined context switching for deep learning applications[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020: 499-514. [https://www.usenix.org/conference/osdi20/presentation/bai](https://www.usenix.org/conference/osdi20/presentation/bai). - -[25] CHOI Y, RHU M. PREMA: A predictive multi-task scheduling algorithm for preemptible neural processing units[C]//2020 IEEE International Symposium on High Performance Computer Architecture. 2020. DOI: [10.1109/HPCA47549.2020.00030](https://doi.org/10.1109/HPCA47549.2020.00030). - -[26] NVIDIA. CUDA Programming Guide: Asynchronous execution, streams and events[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html). - -## 5. 量化、低比特推理与质量约束 - -[27] DETTMERS T, LEWIS M, BELKADA Y, et al. LLM.int8(): 8-bit matrix multiplication for Transformers at scale[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html). - -[28] FRANTAR E, ASHKBOOS S, HOEFLER T, et al. GPTQ: Accurate post-training quantization for generative pre-trained Transformers[C]//International Conference on Learning Representations. 2023. [https://openreview.net/forum?id=tcbBPnfwxS](https://openreview.net/forum?id=tcbBPnfwxS). - -[29] XIAO G, LIN J, SEZNEC M, et al. SmoothQuant: Accurate and efficient post-training quantization for large language models[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202: 38087-38099. [https://proceedings.mlr.press/v202/xiao23c.html](https://proceedings.mlr.press/v202/xiao23c.html). - -[30] LIN J, TANG J, TANG H, et al. AWQ: Activation-aware weight quantization for on-device LLM compression and acceleration[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html). - -[31] DETTMERS T, PAGNONI A, HOLTZMAN A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html). - -[32] LIN Y, TANG H, YANG S, et al. QServe: W4A8KV4 quantization and system co-design for efficient LLM serving[C]//Proceedings of Machine Learning and Systems. 2025, 7. [https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html). - -[33] ZHAO Y, LIN C Y, ZHU K, et al. Atom: Low-bit quantization for efficient and accurate LLM serving[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html). - -## 6. 评估、功耗、热管理与可复现性 - -[34] REDDI V J, CHENG C, KANTER D, et al. MLPerf Inference Benchmark[EB/OL]. arXiv:1911.02549, 2019[2026-09-21]. [https://arxiv.org/abs/1911.02549](https://arxiv.org/abs/1911.02549). - -[35] MLCOMMONS. MLPerf Inference Benchmark Suite[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/index_gh/](https://docs.mlcommons.org/inference/index_gh/). - -[36] MLCOMMONS. MLPerf Inference power measurement[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/power/](https://docs.mlcommons.org/inference/power/). - -[37] DEAN J, BARROSO L A. The tail at scale[J]. Communications of the ACM, 2013, 56(2): 74-80. [https://research.google/pubs/the-tail-at-scale/](https://research.google/pubs/the-tail-at-scale/). - -[38] HUANG W, GHOSH S, VELUSAMY S, et al. HotSpot: A compact thermal modeling methodology for early-stage VLSI design[J]. IEEE Transactions on Very Large Scale Integration Systems, 2006, 14(5): 501-513. DOI: [10.1109/TVLSI.2006.876103](https://doi.org/10.1109/TVLSI.2006.876103). - -[39] STANDARD PERFORMANCE EVALUATION CORPORATION. SPECpower_ssj2008[EB/OL]. [2026-09-21]. [https://www.spec.org/osg/power_ssj2008/](https://www.spec.org/osg/power_ssj2008/). - -[40] JAIN R, CHIU D M, HAWE W R. A quantitative measure of fairness and discrimination for resource allocation in shared computer systems[R]. DEC Research Report TR-301, 1984. [https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf). - -[41] EFRON B, TIBSHIRANI R J. An introduction to the bootstrap[M]. New York: Chapman & Hall/CRC, 1993. - -[42] ASSOCIATION FOR COMPUTING MACHINERY. Artifact review and badging policy[EB/OL]. [2026-09-21]. [https://www.acm.org/publications/policies/artifact-review-and-badging-current](https://www.acm.org/publications/policies/artifact-review-and-badging-current). - -## 7. 模型、推理框架与工程实现资料 - -[43] YANG A, YANG B, ZHANG B, et al. Qwen2.5 Technical Report[EB/OL]. arXiv:2412.15115, 2024[2026-09-21]. [https://arxiv.org/abs/2412.15115](https://arxiv.org/abs/2412.15115). - -[44] GGERGANOV, GGML-ORG. llama.cpp: LLM inference in C/C++[CP/OL]. [2026-09-21]. [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp). - -[45] NVIDIA. TensorRT-LLM architecture overview[EB/OL]. [2026-09-21]. [https://nvidia.github.io/TensorRT-LLM/architecture/overview.html](https://nvidia.github.io/TensorRT-LLM/architecture/overview.html). - -[46] NVIDIA. NVIDIA Data Center GPU Manager: Field identifiers[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html). - -[47] LINUX KERNEL COMMUNITY. How realtime kernels differ[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/differences.html](https://docs.kernel.org/core-api/real-time/differences.html). - -## 8. 任务关键 AI、功能安全与时间同步标准 - -[48] ULLRICH L, BUCHHOLZ M, DIETMAYER K, et al. AI safety assurance for automated vehicles: A survey on research, standardization, regulation[J]. IEEE Transactions on Intelligent Vehicles, 2024. DOI: [10.1109/TIV.2024.3496797](https://doi.org/10.1109/TIV.2024.3496797). - -[49] IEC. IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems—Parts 1 to 7[S]. 2nd ed. Geneva: International Electrotechnical Commission, 2010. [https://webstore.iec.ch/en/publication/22273](https://webstore.iec.ch/en/publication/22273). - -[50] ISO. ISO 26262:2018, Road vehicles—Functional safety[S]. 2nd ed. Geneva: International Organization for Standardization, 2018. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html). - -[51] ISO. ISO/PAS 8800:2024, Road vehicles—Safety and artificial intelligence[S]. Geneva: International Organization for Standardization, 2024. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html). - -[52] IEEE. IEEE Std 1588-2019, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems[S]. New York: IEEE, 2019. [https://standards.ieee.org/ieee/1588/6825/](https://standards.ieee.org/ieee/1588/6825/). - -[53] RTCA. DO-178C: Software considerations in airborne systems and equipment certification[S]. Washington, D.C.: RTCA, 2011. [https://www.rtca.org/do-178/](https://www.rtca.org/do-178/). - -## 9. 使用与取舍建议 - -### 9.1 核心正文优先保留 - -受篇幅限制时，建议首先保留 `[1]~[6]`、`[11]`、`[14]~[22]`、`[25]~[30]`、`[34]~[42]`、`[49]~[52]`。它们分别支撑实时理论、LLM 服务、异构调度、量化、实验方法与任务关键边界。 - -### 9.2 只作工程实现说明 - -`[7]~[10]`、`[26]`、`[35]`、`[36]`、`[39]`、`[44]~[47]` 属于官方标准、文档或开源实现，适合说明平台能力、API 语义和实验工具，不宜单独用来证明算法创新或相对性能优势。 - -### 9.3 需要谨慎使用 - -- `[23]`、`[34]`、`[43]` 为预印本或技术报告，投稿前应检查是否已有正式发表版本。 -- 功能安全标准只能支撑需求与证据框架；本项目原型未完成对应认证时，不得据此宣称满足 SIL、ASIL 或适航要求。 -- SylixOS、QNX、CUDA、TensorRT-LLM 等官方资料描述的是产品或接口能力，实际可用性仍需由本项目准入实验验证。 -- 任何外部论文报告的倍数提升都不能移植为本项目预期结果，只能用于选择对照方案和解释机制。 - -## 10. 待补充文献 - -正式投稿前还应根据实际实验结果补充： - -1. 最终采用的 RKLLM/RKNN SDK、芯片手册和模型转换工具的固定版本文档； -2. 实际使用的 SylixOS BSP、驱动和追踪工具文档； -3. 若完成 T1 多节点实验，补充 NCCL、RDMA 和分布式推理的正式文献； -4. 若完成 MoE 实验，补充专家路由、负载均衡和专家并行文献； -5. 若论文转投 ISLPED，补充 DVFS、race-to-idle 与嵌入式热管理相关工作； -6. 若论文面向车载或航空场景，按最终系统边界补充 ISO 26262、ISO/PAS 8800、DO-178C 及行业适用指南。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/00-项目总览/01-研究问题、定位与边界.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/00-项目总览/01-研究问题、定位与边界.md deleted file mode 100644 index 5ed8911..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/00-项目总览/01-研究问题、定位与边界.md +++ /dev/null @@ -1,67 +0,0 @@ -# 研究问题、定位与边界 - -## 1. 工业背景 - -机器人同时包含两类时间尺度显著不同的任务： - -- 感知、语言理解、任务规划和大模型推理计算量大、运行时间动态，通常属于软实时或固实时； -- 姿态稳定、关节控制、力控、现场总线和安全联锁按固定周期运行，通常属于硬实时或严格固实时。 - -把两类任务简单部署在同一 Linux 系统中，会产生调度、中断、内存带宽、DMA、功耗和故障传播问题；把完整 AI 软件栈迁入 RTOS，又会面临驱动、运行时、模型生态和不可控加速器执行路径问题。 - -## 2. 研究对象 - -本项目研究的是机器人大小脑异构系统，而不是单独研究 RTOS 或大模型： - -| 子系统 | 工程角色 | 主要软件 | -|---|---|---| -| 大脑域 | 环境理解、模型推理、任务规划、技能选择 | Linux、ROS 2、LLM/VLM/VLA、GPU/NPU 运行时 | -| 技能与安全接口 | 命令结构化、白名单技能、期限和约束检查 | 跨域协议、安全监控器、行为管理器 | -| 小脑域 | 状态估计、轨迹跟踪、关节控制、联锁和降级 | RTOS、控制算法、关键设备驱动 | -| 隔离层 | CPU、内存、设备、中断和故障域分区 | Hypervisor、AMP、IOMMU 或静态硬件分区 | - -## 3. 核心研究问题 - -> 在机器人大小脑异构平台中，如何建立跨域时间契约和资源隔离机制，使动态、不可完全预测的大脑负载不会破坏小脑控制的实时边界，并使大脑输出能够被安全、按期地使用？ - -分解为五个问题： - -1. 大脑负载通过哪些 CPU、缓存、内存、I/O、中断、DMA 和热路径干扰小脑控制？ -2. 静态分核与 Hypervisor 分域能够隔离哪些干扰，仍有哪些共享硬件干扰无法消除？ -3. 大小脑之间应采用什么时间契约、消息语义和队列策略？ -4. 大脑输出迟到、过期、错误或低置信度时，小脑如何在规定时间内回退？ -5. 大脑域、加速器或通信通道故障时，机器人能否持续受控并完成隔离和恢复？ - -## 4. 研究边界 - -### 纳入范围 - -- 机器人本体或近端边缘计算平台； -- RTOS 小脑与 Linux 大脑并行运行； -- 控制任务 deadline、AI 结果期限和新鲜度； -- 跨域通信、共享资源干扰、故障隔离和安全降级； -- 大模型、视觉或规划作为大脑压力负载。 - -### 不作为主线 - -- 大模型训练； -- T1 多节点集群吞吐优化； -- 证明大模型本身具备硬实时性； -- 用平均推理时延替代机器人控制实时性； -- 让自然语言输出直接控制电机力矩。 - -## 5. 基本原则 - -1. 小脑不依赖大脑即可维持基本稳定和安全状态。 -2. 大脑输出的是目标、技能或受约束轨迹，不直接绕过控制器驱动执行器。 -3. 小脑不得同步阻塞等待大脑推理完成。 -4. 所有大脑输出必须携带时间戳、序号、有效期、状态和必要的安全约束。 -5. Hypervisor 只是一种隔离手段，隔离效果必须通过压力和故障实验验证。 - -## 6. 预期贡献 - -- 一套面向大小脑系统的多时间尺度任务模型； -- 一套有期限、有新鲜度、有回退语义的跨域通信契约； -- 一套 RTOS/Linux/Hypervisor 资源和故障隔离机制； -- 一套覆盖正常、过载、热稳态和故障状态的实验方法； -- 大脑智能能力、控制实时性和资源代价之间的适用边界。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/00-整体研究框架.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/00-整体研究框架.md deleted file mode 100644 index 2761f2d..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/00-整体研究框架.md +++ /dev/null @@ -1,90 +0,0 @@ -# 整体研究框架 - -## 1. 系统架构 - -```text -操作员/任务系统 - │ - ▼ -┌────────────────────────────────────────────┐ -│ Linux 大脑域 │ -│ 感知、LLM/VLM/VLA、任务规划、技能选择 │ -│ GPU/NPU、ROS 2、模型运行时 │ -└──────────────────┬─────────────────────────┘ - │ 有界异步命令 - │ 序号/时间戳/期限/有效期 -┌──────────────────▼─────────────────────────┐ -│ RTOS 小脑域 │ -│ 安全校验、状态估计、轨迹跟踪、关节控制 │ -│ 现场总线、联锁、超时回退、安全状态 │ -└──────────────────┬─────────────────────────┘ - │ 周期控制量 - ▼ - 执行器与机器人本体 - - Hypervisor / AMP / IOMMU / 静态资源分区 -``` - -传感数据按需求分别进入大小脑：高频本体反馈优先直达小脑，图像、语音和复杂环境信息主要进入大脑。关键安全传感器不得仅通过 Linux 域转发。 - -## 2. 三层时间模型 - -| 层次 | 典型任务 | 时间属性 | 主要指标 | -|---|---|---|---| -| L1 控制闭环 | 关节控制、姿态稳定、联锁 | 硬实时/严格固实时 | deadline、jitter、最大响应时间 | -| L2 技能与决策窗口 | 轨迹片段、目标位姿、避障决策 | 固实时 | 按期率、新鲜度、回退率 | -| L3 认知与交互 | 语言理解、长任务规划、解释 | 软实时 | TTFT、端到端延迟、任务成功率 | - -基本约束为： - -```text -R_control <= D_control - -采用大脑结果时： -R_brain <= D_brain AND age(result) <= A_max - -大脑不可用时： -R_fallback <= D_fallback -``` - -## 3. 三条研究主线 - -### 主线一：时间契约 - -- 规定大脑输出的期限、有效期和更新频率； -- 把大脑输出转换为结构化技能或轨迹约束； -- 对迟到、乱序、重复和低置信度结果定义统一处理； -- 保证小脑在没有新命令时仍能连续控制。 - -### 主线二：资源与故障隔离 - -- 为小脑保留 CPU 核、内存、定时器和关键 I/O； -- 路由关键中断到 RTOS 域； -- 限制 Linux 和加速器 DMA 范围； -- 测量 LLC、DRAM、互联、功耗和热等残余共享干扰； -- 验证一个域崩溃或重启时另一域的持续运行能力。 - -### 主线三：联合评价 - -不能只报告控制延迟，也不能只报告大模型速度。结论必须联合回答： - -- 小脑控制是否按时； -- 大脑结果是否按期且有效； -- 分域使用了多少静态资源； -- 推理吞吐和能效付出了多少代价； -- 故障与恢复期间机器人是否保持受控。 - -## 4. 研究假设 - -- H1：大脑负载会通过共享资源显著扩大控制尾延迟。 -- H2：RTOS/Linux 分域能够降低调度、中断和故障传播影响，但不能自动消除内存带宽与热耦合。 -- H3：有界异步时间契约能够避免小脑等待大脑，并降低过期决策进入执行路径的风险。 -- H4：准入、限流和故障降级可扩大“控制无违约且 AI 结果仍有用”的运行区域。 - -## 5. 研究成果形态 - -- 原型系统：RTOS 小脑域、Linux 大脑域与隔离层； -- 跨域协议：请求、响应、心跳、超时和版本管理； -- 实验工具：时间戳、压力发生、故障注入和物理链路测量； -- 数据集：控制周期、大脑请求、功耗热状态和故障事件的对齐时间序列； -- 论文结论：适用边界、收益来源和残余风险。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/01-大小脑时间契约与跨域通信.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/01-大小脑时间契约与跨域通信.md deleted file mode 100644 index 71d2f0f..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/01-大小脑时间契约与跨域通信.md +++ /dev/null @@ -1,80 +0,0 @@ -# 大小脑时间契约与跨域通信 - -## 1. 接口原则 - -大小脑之间采用异步、有界、可超时和可丢弃的消息通道。小脑控制线程不得执行无限等待、动态扩容或不可控的大块数据复制。 - -大脑输出应从开放文本收敛为受约束结构： - -```text -任务目标 → 白名单技能 → 参数与约束 → 小脑验证 → 执行 -``` - -## 2. 消息模型 - -### 请求 - -| 字段 | 含义 | -|---|---| -| `request_id` | 唯一序号 | -| `sample_time` | 输入数据采样时刻 | -| `deadline` | 最晚可用时刻 | -| `task_class` | 感知、规划、诊断或交互类别 | -| `priority` | 域内服务优先级提示 | -| `payload_ref` | 受控共享缓冲区引用 | -| `schema_version` | 接口版本 | - -### 响应 - -| 字段 | 含义 | -|---|---| -| `request_id` | 请求匹配 | -| `finish_time` | 推理完成时刻 | -| `valid_until` | 结果失效时刻 | -| `model_version` | 模型版本和审计信息 | -| `confidence/status` | 结果质量与错误状态 | -| `skill_id` | 白名单技能编号 | -| `constraints` | 速度、力、空间和持续时间约束 | -| `checksum` | 完整性校验 | - -## 3. 小脑消费条件 - -```text -accept(result) = - id_match - AND schema_valid - AND checksum_valid - AND finish_time <= deadline - AND now <= valid_until - AND confidence >= threshold - AND skill_is_whitelisted - AND constraints_passed -``` - -拒绝结果后，小脑执行保持、传统控制、减速、停车或其他预定义回退，不等待大脑重新计算。 - -## 4. 通信实现候选 - -| 方式 | 优点 | 风险 | 适用场景 | -|---|---|---|---| -| 共享内存环形队列 + 通知 | 低复制、可控队列 | 缓存一致性和内存访问权限 | 同 SoC 分域主方案 | -| RPMsg/邮箱 | SoC 生态常见、域间明确 | 消息大小和驱动能力受限 | MCU + 应用核 | -| 虚拟设备 | 与 Hypervisor 集成 | VM exit 和虚拟中断开销 | 虚拟机分区 | -| 以太网/TSN | 物理隔离、易扩展 | 网络栈与同步误差 | 双机大小脑 | - -## 5. 队列策略 - -- 队列必须有固定容量； -- 状态类消息可采用“只保留最新值”； -- 事务类技能命令不得静默覆盖； -- 大脑过载时优先拒绝低价值请求； -- 小脑记录丢弃、超时、覆盖和回退原因； -- 域重启后通过 epoch 或会话号拒绝旧消息。 - -## 6. 验证重点 - -- IPC 单向、往返、P99.9 和观测最大时延； -- 消息大小、频率和队列深度的影响； -- 队列满、乱序、重复、损坏和版本不一致； -- 大脑域重启后的旧消息隔离； -- 通信线程是否影响控制核和关键中断。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/02-Hypervisor隔离、故障与降级.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/02-Hypervisor隔离、故障与降级.md deleted file mode 100644 index f1acb2e..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/02-Hypervisor隔离、故障与降级.md +++ /dev/null @@ -1,67 +0,0 @@ -# Hypervisor 隔离、故障与降级 - -## 1. 隔离对象 - -| 资源 | 推荐归属 | 验证问题 | -|---|---|---| -| 控制 CPU 核 | RTOS 独占 | Linux 满载时是否发生调度干扰 | -| 关键内存 | RTOS 静态分区 | Linux OOM、换页或内存压力是否影响控制 | -| 电机/编码器/现场总线 | RTOS 直通 | 中断和 DMA 是否经过 Linux | -| GPU/NPU/摄像头 | Linux 独占 | 设备复位是否影响 RTOS | -| 共享内存 | 最小固定区域 | 越界、缓存一致性和拥塞 | -| 网络/存储 | Linux 为主 | 高频 IRQ 是否污染控制核 | - -## 2. 残余共享干扰 - -分核和虚拟化不能自动消除： - -- LLC 和缓存互联竞争； -- DRAM 带宽及内存控制器竞争； -- SoC 总线与 DMA 拥塞； -- 芯片级功耗限制； -- 温度升高与全局降频； -- 固件、系统管理中断和共享时钟源影响。 - -因此需要分别实施 CPU、缓存、内存、I/O 和热压力实验，不能用“已使用 Hypervisor”代替隔离证据。 - -## 3. 故障模型 - -- 大脑推理进程崩溃或永久阻塞； -- Linux 域卡死、内核错误或重启； -- GPU/NPU 驱动错误和设备复位； -- 共享队列溢出、损坏或失联； -- 大脑持续产生过期或不安全命令； -- Linux 域 CPU、内存、网络和存储过载； -- 热降频导致推理与控制执行时间漂移。 - -## 4. 降级状态机 - -```text -智能增强运行 - │ 单次超时/低置信度 - ▼ -保持当前安全技能或传统控制 - │ 连续超时/通信故障 - ▼ -隔离并重启大脑域 - │ 本体风险上升 - ▼ -减速、停车或安全状态 -``` - -每个状态必须规定进入条件、最大驻留时间、控制策略、可用传感器、允许执行器动作和恢复条件。 - -## 5. 安全监控职责 - -安全监控器位于 RTOS 小脑域或独立安全核，至少负责： - -- 大脑心跳与期限监控； -- 命令白名单和参数范围检查； -- 速度、力矩、工作空间和碰撞约束； -- 过期结果拒绝； -- 大脑域隔离与重启请求； -- 本地停车和安全状态执行。 - -## 6. 核心结论边界 - -实验可以证明指定平台和压力范围内的隔离效果，但不能自动证明形式化的最坏情况边界。若要宣称硬实时或功能安全，还需要可信 WCET、可调度性分析、硬件干扰上界和相应安全生命周期证据。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/01-实验设计.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/01-实验设计.md deleted file mode 100644 index d3b92ec..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/01-实验设计.md +++ /dev/null @@ -1,67 +0,0 @@ -# 实验设计 - -## 1. 对照组 - -| 编号 | 系统配置 | 作用 | -|---|---|---| -| A0 | 普通 Linux：控制与大脑负载同域 | 通用基线 | -| A1 | PREEMPT_RT Linux：控制与大脑负载同域 | 实时 Linux 基线 | -| A2 | RTOS 小脑 + Linux 大脑，基础分区 | 分域基线 | -| A3 | A2 + CPU/IRQ/内存/IPC 治理 | 完整方案 | -| A4 | A3 + 超时、降级和故障恢复 | 安全协同方案 | - -对照固定机器人控制任务、AI 模型、输入到达序列、硬件频率和功率策略。若推理后端不同，结果表述为系统方案比较，不单独归因于内核。 - -## 2. 负载场景 - -| 场景 | 内容 | 目的 | -|---|---|---| -| L0 | 仅小脑控制 | 实时性下界 | -| L1 | 仅大脑推理 | 推理容量与功耗基线 | -| L2 | 控制 + 感知/大模型 | 核心共存场景 | -| L3 | L2 + CPU/内存压力 | 共享资源干扰 | -| L4 | L2 + 摄像头/网络/存储 I/O | IRQ 与 DMA 干扰 | -| L5 | L2 + 突发请求和过载 | 队列与准入边界 | -| L6 | L2 长时间运行至热稳态 | 功耗和降频耦合 | -| L7 | 进程、域、加速器和通信故障 | 隔离、降级与恢复 | - -## 3. 控制任务 - -至少包含： - -- 高频周期控制任务； -- 状态估计或轨迹跟踪任务； -- 关键 I/O 或 GPIO 回环； -- 安全监控与回退任务。 - -无真实机器人时，先使用硬件在环、倒立摆、电机台架或确定性控制负载；不得仅用空循环替代全部控制语义。 - -## 4. 大脑任务 - -按平台能力选择视觉、VLM、VLA 或 LLM。大脑输出必须转换为结构化技能命令。分别扫描： - -- 请求率和突发强度； -- 模型规模、输入长度和输出长度； -- batch、队列长度与并发； -- GPU/NPU 利用率； -- 感知数据大小和通信频率。 - -## 5. 故障注入 - -依次实施：推理进程退出、请求永久阻塞、消息乱序或损坏、队列溢出、Linux 域重启、加速器错误。设备级故障只在具备可恢复路径时开展。 - -记录故障发生、检测、回退、隔离、重启和首个恢复结果的完整时间线。 - -## 6. 实施顺序 - -1. 冻结控制 deadline、大脑结果期限和回退期限。 -2. 完成 A0/A1 的同域基线。 -3. 建立 A2 基础分域和最小 IPC。 -4. 扫描 CPU、内存、I/O 和热干扰。 -5. 加入 A3 治理机制并逐项消融。 -6. 加入 A4 故障状态机并开展故障注入。 -7. 进行长稳实验和独立确认批次。 - -## 7. 最小闭环 - -一台具备 RTOS/Linux 分域条件的边缘平台、一个可测量的控制任务和一个真实 AI 大脑负载，即可形成最小验证闭环，不要求扩展到工作站或集群。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/02-指标与证据.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/02-指标与证据.md deleted file mode 100644 index e289a3b..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/02-指标与证据.md +++ /dev/null @@ -1,60 +0,0 @@ -# 指标与证据 - -## 1. 小脑控制实时性 - -- 周期任务释放、开始和完成时间； -- 响应时间与完成抖动； -- P50/P95/P99/P99.9 和观测最大值； -- deadline miss ratio，报告分子与分母； -- 外部输入到执行器输出的物理链路时延； -- 过载、热稳态和故障期间的控制表现。 - -## 2. 大脑结果可用性 - -- 大小脑端到端决策时延； -- deadline-hit ratio； -- 结果新鲜度合格率； -- 超时、过期、乱序、损坏和拒绝率； -- 模型任务质量与置信度； -- 大脑不可用时的回退发生率。 - -## 3. 跨域与隔离代价 - -- IPC 单向/往返延迟及尾部； -- 拷贝次数、CPU 开销和队列占用； -- 静态保留的 CPU、内存和设备资源； -- 分域前后的推理有效吞吐和能效； -- Linux 满载相对小脑空载的控制延迟增量； -- LLC、DRAM、I/O 和热压力的敏感度。 - -## 4. 故障与恢复 - -- 故障检测时间； -- 回退完成时间； -- 域隔离和重启时间； -- 故障窗口内控制违约数； -- 恢复后首个有效大脑结果时间； -- 是否出现不可恢复故障或错误动作。 - -## 5. 联合判定 - -系统配置只有同时满足下列条件才算有效： - -```text -控制任务满足期限 -AND 大脑结果达到规定的按期率与质量 -AND 超时结果不会进入执行路径 -AND 故障时在期限内完成回退 -AND 资源和能耗代价可接受 -``` - -平均推理时延降低但控制违约增加，不构成系统实时性改善；控制零违约但所有 AI 请求都被拒绝，也不构成有效协同。 - -## 6. 推荐核心图表 - -1. 大脑负载强度—控制违约率—结果按期率可行域； -2. 单域与分域方案的控制尾延迟对比； -3. CPU、内存、I/O 和热干扰消融图； -4. 跨域时序分解图； -5. 大脑故障期间控制时间序列； -6. 静态资源预留与推理有效吞吐 Pareto 曲线。 diff --git a/项目框架2-面向机器人大小脑异构系统的实时保障研究/README.md b/项目框架2-面向机器人大小脑异构系统的实时保障研究/README.md deleted file mode 100644 index 5f106e3..0000000 --- a/项目框架2-面向机器人大小脑异构系统的实时保障研究/README.md +++ /dev/null @@ -1,45 +0,0 @@ -# 项目框架2：面向机器人大小脑异构系统的实时保障研究 - -## 一句话定位 - -本项目研究机器人“大脑—小脑”异构系统的系统级实时保障：Linux 大脑域承担感知、推理与规划，RTOS 小脑域承担运动控制和安全保护，Hypervisor 或等价分区机制负责资源与故障隔离。 - -## 核心问题 - -> 当大模型、视觉和规划负载具有动态执行时间且可能过载或故障时，如何保证机器人控制闭环持续满足截止期，并使大脑输出只在满足时限、新鲜度和安全约束时进入执行路径？ - -## 与另外两套框架的区别 - -| 框架 | 研究主语 | 核心场景 | 本框架中的地位 | -|---|---|---|---| -| 框架1 | 大型跨平台 RTOS | T5～T1 五类部署形态 | 机制与设备资料来源，不作为本框架的统一谱系 | -| 框架2 | 机器人大小脑异构系统 | RTOS 控制域 + Linux 推理域 | 当前目录的主线 | -| 框架3 | MCU/资源受限 SoC | 轻量 AI 与实时控制同节点共存 | 小脑侧 AI 的专题补充 | - -## 目录结构 - -- `00-项目总览/01-研究问题、定位与边界.md` - - 研究对象、工业场景、核心假设和结论边界 -- `10-研究框架/00-整体研究框架.md` - - 大小脑架构、三层时间模型与研究主线 -- `10-研究框架/01-大小脑时间契约与跨域通信.md` - - 命令语义、结果新鲜度、有界 IPC 和时序约束 -- `10-研究框架/02-Hypervisor隔离、故障与降级.md` - - CPU、内存、中断、DMA、热干扰和故障恢复 -- `20-实验与规划/01-实验设计.md` - - 对照组、压力场景、故障注入和实施顺序 -- `20-实验与规划/02-指标与证据.md` - - 控制实时性、大脑结果可用性和系统代价指标 - -## 推荐阅读顺序 - -1. `00-项目总览/01-研究问题、定位与边界.md` -2. `10-研究框架/00-整体研究框架.md` -3. `10-研究框架/01-大小脑时间契约与跨域通信.md` -4. `10-研究框架/02-Hypervisor隔离、故障与降级.md` -5. `20-实验与规划/01-实验设计.md` -6. `20-实验与规划/02-指标与证据.md` - -## 推荐课题名称 - -> **面向机器人大小脑异构系统的分域实时保障与安全协同机制研究** diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/00-项目总览/01-研究问题、定位与边界.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/00-项目总览/01-研究问题、定位与边界.md deleted file mode 100644 index 500ecc0..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/00-项目总览/01-研究问题、定位与边界.md +++ /dev/null @@ -1,44 +0,0 @@ -# 研究问题、定位与边界 - -## 1. 问题背景 - -MCU 和资源受限 SoC 原本承担周期控制、采集、通信和保护任务。引入 AI 后，模型执行会持续占用 CPU/NPU、内存、缓存、总线、DMA 和功耗预算，导致控制抖动、关键中断延迟、内存不足或热降频。 - -该问题具有明确的工业实时属性：AI 可以降质、跳帧或暂停，但关键控制任务和安全保护不能因为 AI 负载而失去截止期。 - -## 2. 核心研究问题 - -1. 轻量 AI 通过哪些资源路径影响控制任务？ -2. 如何为 AI 分配可执行时间、内存、带宽和功耗预算？ -3. AI 负载超过容量时，如何限流、跳帧、切换模型或暂停执行？ -4. 模型精度、结果期限、控制实时性和能耗之间如何联合优化？ -5. 不同 MCU/SoC 上哪些机制可迁移，哪些依赖具体硬件？ - -## 3. 研究范围 - -### 纳入范围 - -- MCU、带 NPU 的工业 SoC 和控制器； -- AI 与控制任务同 OS 或同芯片共存； -- 固定优先级、预算服务器、准入和过载降级； -- 静态内存、DMA、缓存、总线、功耗和热管理； -- GPIO、CAN、RS485、工业以太网等物理响应。 - -### 不纳入主线 - -- 大模型训练和多节点集群； -- 为补齐 T1～T5 而采购全谱系设备； -- 只测 tokens/s 或平均推理速度； -- 在设备无法真实运行时估算模型性能； -- 把零违约实测表述为理论硬实时证明。 - -## 4. 基本假设 - -- H1：AI 对控制的主要影响不仅来自 CPU，还来自内存、DMA、中断和热耦合。 -- H2：预算、预分配和准入可以扩大控制无违约的 AI 运行范围。 -- H3：过载时主动降低 AI 服务质量，比继续排队更有利于维持系统可预测性。 -- H4：满足相同控制和 AI 约束时，可以找到能耗更低的模型、频率与执行策略。 - -## 5. 成果边界 - -本研究证明的是指定设备、任务和环境下的容量边界与机制收益。不同芯片的 NPU 固件、内存控制器和功耗策略不同，不能仅按内存容量把结果直接外推。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/00-整体研究框架.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/00-整体研究框架.md deleted file mode 100644 index c40e108..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/00-整体研究框架.md +++ /dev/null @@ -1,59 +0,0 @@ -# 整体研究框架 - -## 1. 系统模型 - -```text -┌─────────────────────────────────────────────┐ -│ 安全与关键控制任务 │ -│ 周期控制、联锁、关键采集、现场总线 │ -├─────────────────────────────────────────────┤ -│ AI 目标任务 │ -│ 检测、估计、识别、诊断、轻量智能决策 │ -├─────────────────────────────────────────────┤ -│ 伴生任务 │ -│ 日志、通信、更新、存储和非关键后台服务 │ -├─────────────────────────────────────────────┤ -│ RTOS/嵌入式系统治理 │ -│ 优先级、预算、准入、预分配、中断与降级 │ -├─────────────────────────────────────────────┤ -│ MCU/SoC：CPU、NPU、RAM、缓存、总线、DMA、热 │ -└─────────────────────────────────────────────┘ -``` - -## 2. 优先级原则 - -1. 安全与关键控制任务优先满足 deadline； -2. AI 任务在剩余时间和资源预算内执行； -3. AI 结果超过有效期后不再进入控制路径； -4. 伴生任务不得挤占控制和已准入 AI 的预算； -5. 过载时优先降低 AI 频率、模型复杂度或输入质量。 - -## 3. 四维预算 - -| 预算 | 控制手段 | 典型风险 | -|---|---|---| -| 时间预算 | 固定优先级、时间服务器、分块执行 | 长算子和不可抢占段 | -| 内存预算 | 静态分配、内存池、峰值准入 | OOM、碎片、共享缓冲区 | -| 带宽预算 | DMA 编排、访问节流、采样降频 | 控制数据被 AI 挤占 | -| 功耗预算 | DVFS、模型切换、占空比控制 | 热降频反向破坏实时性 | - -## 4. 运行状态 - -```text -S0 控制优先、AI 正常运行 -S1 AI 降频或跳帧 -S2 切换轻量模型或低精度模式 -S3 暂停 AI，保留传统控制 -S4 故障安全状态 -``` - -状态切换依据控制裕量、队列长度、内存水位、温度、功耗和 AI 结果质量。切换过程本身必须有界，并避免关键路径动态加载大型模型。 - -## 5. 研究主线 - -- AI WCET/执行时间分布与可抢占结构分析； -- 控制任务响应时间和共享资源干扰分析； -- AI 多维预算与准入控制； -- 精度、执行频率和功耗联合降级； -- 长时间热稳态和异常恢复； -- 跨设备可迁移机制与芯片特定机制区分。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/01-AI预算调度与控制保护.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/01-AI预算调度与控制保护.md deleted file mode 100644 index 90518e8..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/01-AI预算调度与控制保护.md +++ /dev/null @@ -1,54 +0,0 @@ -# AI 预算调度与控制保护 - -## 1. 任务模型 - -控制任务表示为： - -```text -τc = (Tc, Dc, Cc, Pc) -``` - -其中 `T` 为周期、`D` 为截止期、`C` 为执行需求、`P` 为优先级。 - -AI 任务表示为： - -```text -τai = (arrival, deadline, budget_cpu, budget_mem, - budget_power, quality_level, droppable) -``` - -AI 任务必须声明是否可丢弃、是否允许跳帧以及可接受的最低质量等级。 - -## 2. 调度原则 - -- 控制任务使用固定优先级或已验证的实时调度策略； -- AI 使用低优先级后台、预算服务器或可中止任务； -- 将长推理拆分为可抢占或可中断阶段； -- 不可抢占 NPU/GPU 执行段必须测量并纳入控制响应时间； -- AI 请求只有在时间、内存和功耗预算同时满足时才准入。 - -## 3. 准入条件 - -```text -schedulable(control | ai_load) -AND peak_memory <= M_budget -AND predicted_power <= P_budget -AND result_deadline_feasible -AND quality >= Q_min -``` - -准入失败时，系统可以拒绝请求、推迟非关键输入、跳帧或选择更小模型，不能无限排队。 - -## 4. 控制保护机制 - -- 控制代码、数据和栈静态分配； -- AI 与控制使用独立内存池； -- 关键中断优先于 NPU、摄像头和通信完成中断； -- 日志采用预分配缓冲并异步输出； -- AI 执行前检查控制裕量； -- AI 超时后结果直接失效； -- 看门狗覆盖 AI 运行时和设备驱动卡死。 - -## 5. 消融验证 - -逐项移除预算服务器、内存池、中断隔离、准入和降级机制，比较控制尾延迟、AI 按期率和能耗，识别收益来源。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/02-内存、功耗、热与降级.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/02-内存、功耗、热与降级.md deleted file mode 100644 index be21ec0..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/02-内存、功耗、热与降级.md +++ /dev/null @@ -1,55 +0,0 @@ -# 内存、功耗、热与降级 - -## 1. 内存治理 - -模型准入按完整峰值计算： - -```text -M_total = M_weight + M_activation + M_workspace - + M_io + M_runtime + M_control_reserved -``` - -必须为控制任务、关键通信和故障日志保留不可侵占空间。权重大小不能代替峰值内存测量。 - -推荐机制： - -- 模型和工作区静态加载； -- 固定大小内存池； -- 禁止关键窗口模型切换； -- DMA 缓冲区白名单和容量上限； -- OOM 前主动降低 AI 并发或切换模型。 - -## 2. 功耗与热耦合 - -AI 满载可能触发整芯片功耗限制或热降频，进而增加控制任务执行时间。实验必须同步记录： - -- 整机功率； -- 芯片温度； -- CPU/NPU 实际频率； -- AI 执行阶段； -- 控制响应时间和违约； -- 降频事件。 - -## 3. 降级策略 - -| 触发条件 | 优先动作 | -|---|---| -| 控制裕量下降 | 降低 AI 请求率或跳帧 | -| AI 队列增长 | 拒绝低优先级请求 | -| 内存水位过高 | 减少并发或切换小模型 | -| 温度接近阈值 | 降低 AI 占空比或精度 | -| 连续 AI 超时 | 暂停 AI，保留传统控制 | -| 驱动或设备故障 | 复位 AI 子系统并进入安全模式 | - -## 4. 能效口径 - -不能仅比较最低功率，应在相同控制实时约束和 AI 质量约束下比较： - -- 单次有效推理能耗； -- 有效结果/焦耳； -- 控制无违约条件下的持续 AI 吞吐； -- 热稳态而非冷机短时能效。 - -## 5. 结论边界 - -动态量化、模型切换和 DVFS 只有在切换开销已测量且不破坏控制 deadline 时，才能称为实时感知的低功耗策略。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/01-实验设计.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/01-实验设计.md deleted file mode 100644 index 87b95e3..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/01-实验设计.md +++ /dev/null @@ -1,64 +0,0 @@ -# 实验设计 - -## 1. 平台选择 - -建议最少包含： - -- 一个 MCU 或低资源控制器，用于 TinyML/轻量 AI 与周期控制共存； -- 一个带 NPU 的资源受限 SoC，用于统一内存、DMA 和热干扰； -- 必要的功率计、逻辑分析仪或示波器以及 CAN/RS485 对端。 - -设备按真实 AI 运行能力选择，不以补齐 T1～T5 为目标。 - -## 2. 对照组 - -| 编号 | 配置 | -|---|---| -| C0 | 仅控制任务 | -| C1 | 控制 + AI 默认配置 | -| C2 | C1 + 优先级和中断隔离 | -| C3 | C2 + 时间/内存/功耗预算与准入 | -| C4 | C3 + 模型降级和故障恢复 | - -## 3. 压力场景 - -| 场景 | 内容 | -|---|---| -| M0 | 控制空载基线 | -| M1 | AI 独立运行 | -| M2 | 控制 + AI | -| M3 | M2 + CPU/缓存压力 | -| M4 | M2 + 内存/DMA 压力 | -| M5 | M2 + I/O/中断压力 | -| M6 | AI 突发和过载 | -| M7 | 热稳态和降频 | -| M8 | OOM、超时、运行时或设备故障 | - -## 4. 变量扫描 - -- 控制周期、执行预算和关键 I/O 频率； -- AI 模型、精度、输入尺寸和执行频率； -- CPU/NPU 频率与功率模式； -- 内存预算和 DMA 缓冲区大小； -- AI 队列深度、跳帧率和超时期限； -- 环境温度和持续运行时间。 - -## 5. 实施顺序 - -1. 验证控制任务和物理计时链路。 -2. 完成模型正确性、峰值内存和独立能耗准入。 -3. 运行 C0/C1，确认 AI 实际产生的干扰。 -4. 依次加入 C2～C4 并做逐项消融。 -5. 扫描负载直到出现控制违约或 AI 服务失效。 -6. 在选定边界附近进行热稳态与长时间实验。 -7. 使用冻结配置进行独立确认批次。 - -## 6. 停止条件 - -- 控制任务出现不可接受违约； -- 温度、电压或电流超过设备安全范围； -- 测量链路丢样或时钟失效； -- 内存不足导致无法保持关键任务； -- AI 后端不支持目标模型或精度。 - -停止不代表实验失败，应记录为容量或适配边界。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/02-指标与证据.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/02-指标与证据.md deleted file mode 100644 index f82d3c6..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/02-指标与证据.md +++ /dev/null @@ -1,58 +0,0 @@ -# 指标与证据 - -## 1. 控制实时性 - -- 任务响应时间、完成抖动和观测最大值； -- deadline miss ratio； -- 中断响应和关键 I/O 端到端时延； -- AI 启停、模型切换和降频瞬间的时间序列； -- 故障与恢复窗口内的控制表现。 - -## 2. AI 服务有效性 - -- 推理端到端时延和按期率； -- 有效结果率、任务质量和超时率； -- 跳帧、拒绝和降级比例； -- 模型切换时间； -- 控制无违约条件下的最大持续 AI 负载。 - -## 3. 资源与能耗 - -- 峰值和稳态内存； -- CPU/NPU 利用率与执行占空比； -- 内存带宽或可取得的代理指标； -- 整机平均功率、峰值功率和能量； -- 温度、实际频率和降频时间比例； -- 单次有效结果能耗和有效结果/焦耳。 - -## 4. 核心结果表达 - -推荐把结果组织为“安全运行区”： - -```text -控制 deadline 满足 -AND AI 质量 >= Q_min -AND AI 按期率 >= H_min -AND 功耗 <= P_max -AND 温度 <= Temp_max -``` - -扫描 AI 频率、模型复杂度和功耗模式，绘制满足全部条件的可行区域及其边界。 - -## 5. 不应使用的证据替代 - -- 平均延迟不能替代 deadline miss ratio； -- 短时冷机性能不能替代热稳态； -- 模型权重大小不能替代峰值内存； -- 芯片标称 TOPS 不能替代实测完成时间； -- 零违约不能直接表述为理论硬实时保证； -- 降低 AI 完成率获得的低功耗不能单独称为能效提升。 - -## 6. 推荐图表 - -1. AI 负载—控制尾延迟与违约率曲线； -2. 时间、内存、功耗预算消融图； -3. 模型质量—按期率—能耗 Pareto 图； -4. 热稳态下温度、频率、控制延迟时间序列； -5. 过载状态下跳帧、降级和恢复过程； -6. 不同 MCU/SoC 的机制可迁移性对比表。 diff --git a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/README.md b/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/README.md deleted file mode 100644 index 7f4801a..0000000 --- a/项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/README.md +++ /dev/null @@ -1,32 +0,0 @@ -# 项目框架3：MCU 与资源受限 SoC 的 AI 实时性与低功耗研究 - -## 一句话定位 - -本项目研究 MCU 和资源受限 SoC 引入轻量 AI 后的实时干扰、资源预算、低功耗运行与安全降级问题，形成“控制期限优先、AI 预算执行、过载主动降级”的端侧智能方法。 - -## 核心问题 - -> 在 CPU、内存、带宽、功耗和散热均受限的控制节点中，允许多大的 AI 负载，才能在不破坏周期控制和关键 I/O 截止期的前提下获得有效智能功能？ - -## 研究对象说明 - -这里的 AI 不默认等于大语言模型。根据硬件能力，可以是： - -- TinyML 和小型神经网络； -- 异常检测与预测维护模型； -- 轻量视觉、语音和状态识别； -- 学习型状态估计或控制补偿； -- 能在目标设备真实运行的小型语言模型。 - -## 目录结构 - -- `00-项目总览/01-研究问题、定位与边界.md` -- `10-研究框架/00-整体研究框架.md` -- `10-研究框架/01-AI预算调度与控制保护.md` -- `10-研究框架/02-内存、功耗、热与降级.md` -- `20-实验与规划/01-实验设计.md` -- `20-实验与规划/02-指标与证据.md` - -## 推荐课题名称 - -> **资源受限嵌入式控制系统中 AI 负载的实时预算与低功耗协同机制研究**