add leadership analysis for RTOS+LLM+Agent research project

结论：项目框架在问题定义、体系化设计、方法论层面具有明确领先性（预计领先同行3-5年）
- 5项强领先：跨层实时性定义、双路线设计、规则兜底、三层指标、四组对照
- 1项领先：五类部署形态体系
- 2项需补强：实证数据、Agent框架集成
- 主要风险：理论框架需快速产出实证数据

01-会议讨论/20260922_093448-会议主题拆分整理/00-会议主题索引.md

@@ -0,0 +1,35 @@
+# 20260922\_093448 会议主题拆分索引
+
+本次会议可以整理为 5 个相互关联、但可独立推进的主题板块。它们共同围绕人工智能、基础系统、行业落地与合作路径展开，但每个板块的研究对象、交付目标和后续动作并不相同，因此适合拆分为独立文件持续讨论。
+
+## 1. 主题划分
+
+1. [01-医疗AI导航与嵌入式收缩方向.md](01-医疗AI导航与嵌入式收缩方向.md)
+   - 聚焦手术显微镜 AI 辅助导航、外挂式推理到嵌入式收缩的产品路径。
+2. [02-大模型评测优化平台与本地模型社区.md](02-大模型评测优化平台与本地模型社区.md)
+   - 聚焦服务器侧模型评测、算子优化、量化比较、本地模型社区，以及平台建设、服务外溢和各方分工方式。
+3. [03-RTOS与AI实时控制基础系统课题讨论.md](03-RTOS与AI实时控制基础系统课题讨论.md)
+   - 聚焦翼辉方向、基础系统定位、MCU 与 SoC/Hybrid 路线区分，以及课题推进步骤、责任边界和合作方式。
+4. [04-垂直大模型训练框架与代训服务.md](04-垂直大模型训练框架与代训服务.md)
+   - 聚焦“垂直大模型不等于通用模型加行业语料”的方法论、七要素框架、代训服务步骤和分工合作方式。
+5. [05-法律政务数据治理智能体与XAPP平台.md](05-法律政务数据治理智能体与XAPP平台.md)
+   - 聚焦纪委办案、律师产品、数据治理智能体、XAPP 平台化思路，以及应用到平台的推进路径与合作分工。
+
+## 2. 结构判断
+
+这 5 个主题之间的关系如下：
+
+- `01` 是一个具体行业落地样例，体现 AI 从外挂推理向嵌入式系统收缩的路径；
+- `02` 是模型优化和测试平台能力，已经扩展为平台建设、服务输出与社区沉淀的完整工作线；
+- `03` 是基础系统方向的课题定义与合作主线，直接对应研究框架、翼辉合作和后续预研组织方式；
+- `04` 是大模型产业化的方法论与服务模式，偏研究方法、训练逻辑与代训服务设计；
+- `05` 是平台和应用层的产品化实践，展示多模态数据治理、专业应用与 XAPP 平台的落地形态。
+
+## 3. 使用建议
+
+后续讨论可以按两条线推进：
+
+1. **研究主线**：优先阅读 `03` 和 `04`；
+2. **落地主线**：优先阅读 `01`、`02` 和 `05`。
+
+这样可以把“研究框架”“平台能力”“具体应用”三类问题拆开处理，不会在同一份会议全文里相互缠绕。

01-会议讨论/20260922_093448-会议主题拆分整理/01-医疗AI导航与嵌入式收缩方向.md

@@ -0,0 +1,45 @@
+# 医疗AI导航与嵌入式收缩方向
+
+## 1. 主题定位
+
+这一部分讨论的是一个明确的医疗器械落地样例：围绕手术显微镜场景，为厂商提供 AI 辅助导航能力，并逐步从外挂式主机方案收缩到嵌入式系统方案。
+
+## 2. 当前项目形态
+
+- 合作对象是国内手术显微镜厂商；
+- 当前方案是在原有显微镜主显示链路之外增加一块副屏；
+- 图像从显微镜链路引出，进入外挂主机完成推理，再把辅助分析结果叠加回显示画面；
+- 这一阶段的目标是先完成功能验证和临床辅助价值展示，不直接改动原主屏系统。
+
+## 3. 核心价值
+
+这个方向的价值集中在三点：
+
+1. **医疗场景价值明确**：医生可以在术野中直接看到风险点、角度偏差和操作提示；
+2. **商业价值直接**：整套 AI 辅助能力对设备加价能力明显高于其硬件增量成本；
+3. **研究价值清晰**：这是一个从服务器式推理向设备内收缩的真实案例，能自然过渡到嵌入式与实时系统问题。
+
+## 4. 后续技术演进
+
+会议里已经明确，当前外挂式主机只是第一阶段。后续方向是：
+
+- 把外挂主机能力收缩进设备本体；
+- 把 AI 功能从“旁路叠加”逐步转向“设备内部集成”；
+- 由此引出嵌入式系统、资源预算、边缘推理和控制路径协同等问题。
+
+这意味着它不是一个单纯的图像识别项目，而是一个可持续向基础系统问题延展的行业样例。
+
+## 5. 与整体研究的关系
+
+这个主题与整体研究最强的连接点在于：
+
+- 它属于 `T4/T3` 一类的设备端与边缘端样例；
+- 它天然涉及“小型化、低功耗、设备内集成”的后续路线；
+- 它可以作为“AI 目标负载进入任务关键设备”的现实入口。
+
+## 6. 后续可单独推进的问题
+
+1. 设备内收缩后的算力与功耗预算如何设定；
+2. 显微镜主链路、副链路和 AI 推理链路如何协同；
+3. 哪些部分继续由外挂主机承担，哪些部分迁移到嵌入式系统；
+4. 该场景能否作为 RTOS / 基础系统研究的主样例之一。

01-会议讨论/20260922_093448-会议主题拆分整理/02-大模型评测优化平台与本地模型社区.md

@@ -0,0 +1,260 @@
+# 大模型评测优化平台与本地模型社区
+
+## 1. 主题定位
+
+这一部分讨论的不是训练一个新的通用大模型，而是建设一套面向服务器、机房、算力中心和本地部署场景的大模型评测与优化平台。它的核心价值不在“再做一个模型”，而在于把模型、量化、算子、运行框架、启动参数和硬件配置之间原本分散、难解释的差异，组织成一套可比较、可复用、可交付的证据体系。
+
+会议进一步给这条线增加了一个更有延展性的方向：在平台能力稳定之后，可以向“本地模型社区”延伸，形成面向区域算力中心、科研团队、行业客户和本地部署需求的模型比较、配置推荐和优化服务能力。
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 同一套硬件上，运行配置差异足以造成显著性能分化
+
+模型效果和运行表现并不只取决于显卡型号或算力规模。  
+量化方式、算子开关、容器配置、运行框架、显存组织和启动参数都会显著影响：
+
+- 启动时间；
+- 解码速度；
+- 稳定性；
+- 显存占用；
+- 长稳运行效果。
+
+这意味着客户看到的“模型快不快”，很多时候并不是硬件单因素决定的。
+
+### 2.2 平台真正解决的是“不可解释”问题
+
+很多客户当前并不清楚瓶颈到底来自：
+
+- 硬件资源本身；
+- 框架选型；
+- 算子实现；
+- 量化策略；
+- 参数配置与部署方式。
+
+平台的价值，是把原本靠经验和试错得出的结果，变成能够重复执行、系统记录和横向比较的证据。
+
+### 2.3 评测平台天然可以外溢为优化服务
+
+一旦平台具备：
+
+- 统一记录；
+- 统一对比；
+- 统一报告；
+- 统一复现实验；
+
+它就不再只是内部工具，而可以外溢成：
+
+- 算力中心选型服务；
+- 模型优化服务；
+- 部署建议服务；
+- 本地模型配置推荐服务。
+
+### 2.4 本地模型社区的重点不是“做大平台”，而是做“高价值局部能力”
+
+会议对“社区化”方向的判断也比较清楚：
+
+- 不必复制一个通用开源社区；
+- 不追求以模型数量堆出影响力；
+- 更适合聚焦本地部署模型、端侧模型、专业模型和工具化模型；
+- 重点放在选型、评测、优化、配置推荐和经验沉淀上。
+
+### 2.5 这条线与实时基础系统研究并不冲突
+
+虽然这部分内容更多发生在服务器和机房侧，但它和整体研究并不割裂，因为它提供了：
+
+- AI 目标负载的运行时证据基础；
+- 推理实时性不完全由操作系统决定的实证背景；
+- 对端侧、小型化和边缘部署的模型选型依据。
+
+## 3. 这条线真正要做的事情
+
+如果把会议中的想法进一步收束，这条线真正要建设的是一套“四位一体”的能力：
+
+1. **评测平台**  
+   负责统一记录硬件、模型、参数、运行结果和日志证据。
+2. **优化工作台**  
+   负责对比量化、算子、框架和启动配置，给出可复现的优化建议。
+3. **报告系统**  
+   负责把结果输出成客户能理解、团队能复用的标准报告。
+4. **本地模型社区**  
+   负责沉淀模型经验、配置经验、最佳实践和可复用模板。
+
+因此，这条线的本质不是“做个演示平台”，而是形成一套从实验到服务再到社区沉淀的连续能力。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“平台底座 + 优化服务 + 社区沉淀”的工作方式。
+
+### 4.1 先把平台做成证据系统
+
+第一步不是追求界面完整，而是确保每一次实验都能形成可重复、可追溯的证据，包括：
+
+- 硬件环境；
+- 模型版本；
+- 量化与算子配置；
+- 启动参数；
+- 运行日志；
+- 性能指标；
+- 异常记录。
+
+### 4.2 再把平台变成优化工具
+
+在证据系统稳定之后，平台需要进一步承担：
+
+- 多配置对比；
+- 自动化基线测试；
+- 优化项回归验证；
+- 最优组合推荐。
+
+### 4.3 最后向社区和服务产品外溢
+
+只有在前两步稳定之后，才适合把成果外溢为：
+
+- 内部优化知识库；
+- 本地模型推荐清单；
+- 算力中心服务能力；
+- 对外社区或合作平台。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：建立最小可用评测底座
+
+目标是先把评测和记录做扎实。  
+这一阶段应完成：
+
+- 硬件信息采集；
+- 模型加载与启动配置记录；
+- 解码速度、显存占用、温度和稳定性采集；
+- 日志归档与结果可回看。
+
+### 5.2 第二步：建立标准化对比实验
+
+目标是让平台开始具备“比较能力”。  
+这一阶段应完成：
+
+- 同模型不同量化方案对比；
+- 同模型不同框架对比；
+- 同模型不同算子开关对比；
+- 同一硬件下不同启动参数对比；
+- 同一配置长稳运行验证。
+
+### 5.3 第三步：形成优化报告模板
+
+目标是把结果变成可以交付的东西。  
+这一阶段应完成：
+
+- 统一评测报告模板；
+- 统一优化建议模板；
+- 面向内部研发和面向客户的双版本输出；
+- 典型案例归档。
+
+### 5.4 第四步：形成服务与社区接口
+
+目标是把平台从内部工具推进到合作能力。  
+这一阶段应完成：
+
+- 模型推荐清单；
+- 本地部署配置推荐；
+- 算力中心选型建议；
+- 模型社区入口与资料组织方式。
+
+## 6. 各方责任与分工方式
+
+这条线适合按四类角色组织。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 客户问题定义与场景归类；
+- 服务模式设计；
+- 报告交付结构与对外表达组织。
+
+唐老师团队更适合站在“需求整合、问题转译、合作推进”的位置上。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 评测方法学抽象；
+- 指标体系设计；
+- 对比逻辑与结论边界把关；
+- 从个案经验中提炼共性规则。
+
+罗老师团队更适合站在“方法论、评价体系、结果解释”的位置上。
+
+### 6.3 平台与工程团队
+
+适合承担：
+
+- 平台实现；
+- 模型部署与运行；
+- 评测脚本和自动化任务；
+- 数据采集、日志治理与结果可视化；
+- 优化项验证与回归测试。
+
+这一角色是平台真正落地的执行核心。
+
+### 6.4 合作方或客户方
+
+适合承担：
+
+- 提供真实模型与场景目标；
+- 提供约束条件与验收口径；
+- 确认数据权限与部署边界；
+- 对优化结果给出业务反馈。
+
+客户方不负责平台方法学设计，但必须负责场景目标与验收边界。
+
+## 7. 工作边界
+
+为了避免这条线失焦，需要明确它不做什么。
+
+### 7.1 不以训练新通用模型为主目标
+
+这条线的重点是评测、优化和配置比较，不是另起炉灶训练新的通用基座模型。
+
+### 7.2 不把平台做成纯展示系统
+
+如果平台没有可重复实验、可复用模板和可解释报告，它就只是演示界面，而不是方法平台。
+
+### 7.3 不把社区做成“模型仓库堆砌”
+
+本地模型社区的重点不在收集尽可能多的模型，而在于形成有用的模型说明、部署建议和优化经验。
+
+### 7.4 不直接替代端侧和基础系统研究
+
+这条线为整体研究提供模型运行证据，但它本身不替代 RTOS、基础系统和嵌入式部署课题。
+
+## 8. 合作推进方式
+
+这条线适合采用“三阶段合作法”。
+
+### 8.1 阶段一：评测平台共建
+
+重点是把实验环境、评测流程和数据记录打通。  
+交付物以内部工具、基线实验和标准报告模板为主。
+
+### 8.2 阶段二：优化服务协同
+
+重点是围绕真实客户、真实模型和真实部署需求输出优化结果。  
+交付物以优化报告、配置建议和案例沉淀为主。
+
+### 8.3 阶段三：社区与区域合作扩展
+
+重点是把积累下来的经验沉淀成更稳定的合作能力。  
+交付物以模型推荐清单、社区入口、合作机制和服务手册为主。
+
+## 9. 当前结论
+
+这条线的真正价值，不是再做一个“模型体验平台”，而是：
+
+> **把模型、量化、算子、框架和硬件之间原本难解释的运行差异，变成一套可比较、可复现、可交付、可沉淀的证据与服务体系。**
+
+如果继续向前推进，它会自然生长出两个方向：
+
+- 一个是面向内部和合作项目的优化工作台；
+- 一个是面向区域部署、本地模型与算力中心合作的本地模型社区。

01-会议讨论/20260922_093448-会议主题拆分整理/03-RTOS与AI实时控制基础系统课题讨论.md

@@ -0,0 +1,401 @@
+# RTOS与AI实时控制基础系统课题讨论
+
+## 1. 主题定位
+
+这部分讨论是整场会议中最接近课题主线、研究对象重定义和合作方向重构的核心内容。会议虽然从翼辉与 RTOS 相关问题切入，但最终形成的判断已经明显超出了“RTOS 是否更强”这一层，转向了一个更高层次的问题：
+
+> **当人工智能能力进入实时控制系统之后，真正需要研究和构建的对象，不再只是单一 RTOS，而是面向 AI 的实时控制基础系统。**
+
+这不是一句包装性口号，而是对研究主语、技术路线、合作方式和产业定位的重新组织。
+
+## 2. 会议形成的核心结论
+
+会议中稳定下来的，不是某一个局部技术答案，而是四项根本判断。
+
+### 2.1 大模型实时性不是单一 RTOS 问题
+
+人工智能目标负载进入系统之后，系统面对的问题来自多层要素共同作用，包括：
+
+- 模型结构与量化方式；
+- 推理框架与运行时队列；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离结构；
+- 芯片、总线、内存、DMA、NPU、GPU 等硬件资源形态；
+- 规则兜底、异常切换和安全边界机制。
+
+因此，会议给出的更准确判断是：
+
+> **人工智能进入实时控制系统之后，系统需要解决的是跨模型、跨运行时、跨基础软件和跨体系结构的整体实时性问题。**
+
+### 2.2 研究主语要从 RTOS 上移到基础系统
+
+会议没有否定 RTOS 的价值，但明确反对继续把全部实时性问题都压到 RTOS 身上。  
+RTOS 仍然是关键保障负载的确定性底座，但不再适合作为所有问题的唯一承担者。
+
+更合适的研究对象应当写成：
+
+- 实时基础系统；
+- 面向 AI 的实时控制基础系统；
+- 面向 AI 的实时控制系统体系结构。
+
+### 2.3 技术路线天然分成 MCU 路线与 SoC / 边侧路线
+
+会议没有把所有场景压成同一套逻辑，而是明确区分了两类问题结构：
+
+- `MCU` 路线：更强调静态资源组织、开发工具链、芯片协同和开发套件；
+- `SoC / 边侧` 路线：更强调 Linux、RTOS、Hypervisor 与异构资源共同构成的混合基础系统。
+
+因此，更接近原意的概括不是“MCU 让 RTOS 多做点事、边侧上 Hypervisor”，而是：
+
+> **MCU 路线主要解决静态编排与工具链协同问题，SoC / 边侧路线主要解决 Hybrid、Hypervisor 与系统协同问题，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
+
+### 2.4 翼辉方向需要从 RTOS 产品叙事转向基础系统叙事
+
+会议对翼辉这类公司的建议也比较明确：
+
+- 不再只讲 RTOS 厂商身份；
+- 不再把“适配了什么系统”作为核心叙事；
+- 转向“面向 AI 的实时控制基础系统供应方”；
+- 用 5 到 10 年技术路线替代短周期适配叙事。
+
+## 3. 基础系统视角下的问题结构
+
+为了避免后续再把所有问题混在一起，会议内容更适合被整理成三个层次。
+
+### 3.1 RTOS 直接控制域
+
+这一层对应 RTOS 可以直接施加机制约束的范围，主要包括：
+
+- 周期任务与关键任务调度；
+- 中断优先级、抢占关系和关键路径治理；
+- CPU 侧线程、同步机制与时钟管理；
+- 恢复、隔离和关键任务保护机制；
+- 对部分共享资源策略的直接控制接口。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 3.2 推理运行域
+
+这一层主要由模型、量化、算子、框架和运行时共同决定，主要包括：
+
+- 模型大小与数值精度；
+- Prefill / Decode 的时延分布；
+- KV Cache、工作区和内存组织方式；
+- 推理框架队列、批处理与上下文管理；
+- GPU/NPU 内部执行与驱动接口行为。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、资源行为和可优化空间。**
+
+### 3.3 系统协同域
+
+这一层是会议真正抬起来的新重点，主要包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、统一内存、外存和协处理器竞争治理；
+- 规则兜底、异常切换与安全边界；
+- 关键保障负载与人工智能目标负载之间的优先级结构。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+## 4. MCU 路线与 SoC / 边侧路线的真实含义
+
+### 4.1 MCU 路线
+
+会议对 `MCU` 方向的判断非常集中。  
+更准确的理解不是“MCU 端让 RTOS 多做一些事”，而是：在极小资源预算场景中，问题本身就不适合按高动态运行时思维组织。
+
+这一方向通常具有以下特点：
+
+- 动态空间极小；
+- 内存和算力预算刚性；
+- 控制任务和外设链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖离线配置、静态分配和代码生成。
+
+因此，会议原意更接近：
+
+> **MCU 路线中 RTOS 的意义更接近静态组织底座、可分析执行环境和开发工具链的一部分，而不是承接高动态推理运行时的主体。**
+
+### 4.2 SoC / 边侧路线
+
+`SoC / 边侧` 路线的判断也需要严格校准。  
+它并不是一句“边侧用 Hypervisor”就能概括的。会议真正强调的是：设备端 SoC 会天然同时存在 Linux 生态需求和实时控制需求，因此更现实的路径，是构造一个能够治理混合结构的基础系统。
+
+这类场景通常同时具有以下特征：
+
+- 需要 Linux 承接 AI 生态和推理框架；
+- 需要 RTOS 承接关键控制与实时保障；
+- 需要在同一 `SoC`、同一块板卡上处理统一内存和异构设备竞争；
+- 还要同时面对设备级功耗、散热、体积和驱动限制。
+
+会议对 `Hypervisor` 的态度是明确肯定的，但没有把它讲成单独答案。  
+更准确的理解是：
+
+- `Hypervisor` 首先是一种隔离和资源切分方法；
+- 它可以帮助划分 Linux 与 RTOS 的边界；
+- 但它本身不能自动消除统一内存、总线、DMA、缓存和协处理器带来的全部竞争问题。
+
+因此，这一路线真正保留并强化的是：
+
+> **面向 AI 实时控制系统的升级版 Hybrid，也就是能够处理分工、隔离、资源仲裁、规则兜底和异常切换的混合基础系统结构。**
+
+## 5. 建议的工作方式
+
+这一主题不适合按“先写论文、再找技术点”的方式推进，而更适合按“先完成问题重定义，再完成路线定义，再组织预研验证”的方式推进。
+
+### 5.1 先做课题重定义
+
+第一步不是急于给出实现方案，而是把以下问题写清楚：
+
+- 研究主语为什么要从 RTOS 上移到基础系统；
+- MCU 路线和 SoC / 边侧路线为什么不能混写；
+- RTOS 直接控制域、推理运行域、系统协同域如何分层；
+- Hybrid、Hypervisor、规则兜底在系统中的位置是什么。
+
+这一阶段的产物应当是：
+
+- 一份课题重定义稿；
+- 一份路线分层说明稿；
+- 一份面向合作方的概念阐释稿。
+
+### 5.2 再做技术路线分解
+
+在问题定义清楚之后，再把路线拆成两个主方向：
+
+1. `MCU` 路线  
+   重点看静态编排、工具链、开发套件、芯片协同。
+2. `SoC / 边侧` 路线  
+   重点看 Linux / RTOS / Hypervisor 分工、Hybrid 升级、统一内存与总线竞争治理。
+
+这一阶段的产物应当是：
+
+- 一份 MCU 路线稿；
+- 一份 SoC / Hybrid 路线稿；
+- 一份系统协同与规则兜底说明稿。
+
+### 5.3 再组织预研验证
+
+路线分解完成后，再进入原型和预研阶段。  
+这一阶段不是全面铺开，而应选典型切口验证关键判断，例如：
+
+- 小模型与控制任务的静态编排；
+- Linux 与 RTOS 分工下的控制链路保护；
+- Hypervisor 隔离下的统一内存竞争；
+- 模型输出与规则兜底共同构成的闭环。
+
+### 5.4 最后再回收进主课题框架
+
+只有在以上三步形成稳定判断之后，才适合把内容系统回收到主课题框架、论文规划和合作提案中。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：形成概念共识
+
+目标是对内把“RTOS 课题”与“基础系统课题”的边界说清楚。  
+这一阶段应完成：
+
+- 会议判断整理；
+- 原话核对；
+- 关键词统一；
+- 课题候选命名收敛。
+
+### 6.2 第二步：形成路线稿
+
+目标是把两个方向彻底拆开。  
+这一阶段应完成：
+
+- MCU 路线稿；
+- SoC / 边侧路线稿；
+- Hybrid / Hypervisor 路线稿；
+- 系统协同域说明稿。
+
+### 6.3 第三步：形成合作版材料
+
+目标是让外部合作方能够看懂“为什么值得做、准备怎么做、各方做什么”。  
+这一阶段应完成：
+
+- 面向合作方的路线总述；
+- 阶段性合作方式说明；
+- 预研问题清单；
+- 交付物框架。
+
+### 6.4 第四步：组织预研与验证
+
+目标是围绕少数关键问题开展验证。  
+这一阶段应完成：
+
+- 板级或 SoC 原型验证；
+- 小模型与控制任务共存实验；
+- 混合系统资源竞争实验；
+- 规则兜底与异常切换实验。
+
+## 7. 各方责任与工作的边界
+
+这一主题如果要继续推进，必须把责任和边界说清楚，否则很容易重新落回“谁都在提想法，没人真正推进”的状态。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 场景与需求整合；
+- 课题框架转译；
+- 合作节奏把控；
+- 外部沟通和阶段汇报组织。
+
+唐老师团队更适合处在“前端牵头、方案整合、合作推进”的位置。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 研究主语与问题定义把关；
+- 方法论抽象；
+- 路线分层与概念边界校准；
+- 研究价值、学术表达和系统建模方向的判断。
+
+罗老师团队更适合处在“高层框架、方法论和方向判断”的位置。
+
+### 7.3 翼辉或对应产业团队
+
+适合承担：
+
+- RTOS、工具链、板级环境和基础软件条件说明；
+- MCU 路线和 SoC 路线的工程条件提供；
+- Hybrid / Hypervisor / 板级验证路径提供；
+- 原型实现与工程可行性反馈。
+
+产业团队不负责课题理论抽象，但负责把路线落到真实平台条件上。
+
+### 7.4 项目组或工程支撑团队
+
+适合承担：
+
+- 会议整理与材料撰写；
+- 路线稿、合作稿和阶段文档整理；
+- 预研验证组织；
+- 图表、报告和证据归档。
+
+这一角色更偏执行支撑与资料组织。
+
+## 8. 工作边界
+
+### 8.1 这项工作当前首先是“定义工作”，不是全面工程实现
+
+会议形成的第一价值，是重新定义问题和路线。因此现阶段不宜直接把重点放在“大规模开发”上。
+
+### 8.2 当前重点是“搭框架”，不是“宣称已经解决”
+
+无论是 MCU 路线还是 SoC / Hybrid 路线，当前更适合先形成稳定的问题定义、路线定义和验证问题，而不是过早给出“完整解决方案”叙事。
+
+### 8.3 学术问题与产业问题需要并行，但不能混写
+
+学术上要回答：
+
+- 问题定义是否成立；
+- 三层边界如何组织；
+- 经典实时理论如何扩展。
+
+产业上要回答：
+
+- 产品路线怎么讲；
+- 哪些工程条件已经具备；
+- 预研从哪里切入。
+
+这两类问题必须关联，但不能混成一篇只讲口号的材料。
+
+## 9. 合作推进方式
+
+这一主题适合采用“规划先行、预研跟进、原型验证收口”的推进方式。
+
+### 9.1 第一阶段：规划与定义
+
+重点是：
+
+- 统一研究主语；
+- 统一路线分层；
+- 统一合作表达；
+- 形成首轮课题和合作框架稿。
+
+这一阶段的交付物应以定义稿、路线稿和合作稿为主。
+
+### 9.2 第二阶段：预研与技术论证
+
+重点是：
+
+- 抽取少数关键问题做原型验证；
+- 形成系统协同和控制闭环的实证材料；
+- 把 MCU 路线与 SoC 路线分别落到真实平台。
+
+这一阶段的交付物应以预研报告、实验记录和系统草案为主。
+
+### 9.3 第三阶段：联合课题与对外输出
+
+重点是：
+
+- 回收进正式课题框架；
+- 形成面向项目、论文和合作申请的材料；
+- 根据需要向白皮书、论文和对外交流稿扩展。
+
+## 10. 对当前研究仓库的直接影响
+
+这场会议对当前仓库至少带来六项直接影响。
+
+### 10.1 研究主语需要继续上移
+
+当前仓库已经从“硬件主语”转到“RTOS 主语”，而会议进一步提示：下一步更值得推进的是从“RTOS 主语”继续上移到“基础系统主语”。
+
+### 10.2 `T5~T1` 验证矩阵仍然有效
+
+会议没有否定验证矩阵，而是强化了一个更清晰的判断：
+
+- `T5/T4/T3` 更适合作为系统研究主窗口；
+- `T2/T1` 作为 RTOS 优势主战场的意义较弱；
+- 但作为 AI 负载和系统协同的参照窗口仍然有价值。
+
+### 10.3 需要把“系统协同域”单独写出来
+
+当前仓库的五层技术栈已经是很好的起点，但后续需要明确写出：
+
+- RTOS 可控域；
+- 模型与运行时域；
+- Linux、Hypervisor、芯片与资源治理共同构成的系统协同域。
+
+### 10.4 “实时性”需要从纯 OS 叙事中适度抽离
+
+后续文档更适合写成：
+
+- 实时控制系统中的 AI 能力；
+- 引入 AI 后的整体实时性问题；
+- 基础系统如何维持控制路径与 AI 路径的统一时间边界。
+
+### 10.5 低功耗、小型化方向会自然进入主线
+
+一旦研究对象上移到基础系统，低功耗、小型化、片上资源预算这些问题就不再只是应用专题，而会自然进入主线。
+
+### 10.6 后续课题命名需要重新评估
+
+如果沿着这次会议的判断继续推进，候选命名更适合向以下方向收敛：
+
+- 面向 AI 的实时控制基础系统；
+- 人工智能目标负载进入实时控制系统后的基础系统保障机制；
+- 面向 AI 实时控制系统的嵌入式体系结构与基础系统研究。
+
+## 11. 当前结论
+
+这场会议最重要的价值，不是提供了一个立即可落地的单点技术答案，而是把观察视角整体抬高了一层。
+
+会议最终给出的判断可以概括为：
+
+> **人工智能进入实时控制系统之后，真正值得研究和构建的对象，不再只是单一 RTOS，而是一个围绕实时性、控制性、推理性和体系结构协同展开的基础系统。**
+
+如果进一步压缩成最贴近会议原意的一句话，可以写成：
+
+> **MCU 路线主要走静态编排、工具链与芯片协同，SoC / 边侧路线主要走 Linux + RTOS + Hypervisor + 升级版 Hybrid 的系统协同，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**

01-会议讨论/20260922_093448-会议主题拆分整理/04-垂直大模型训练框架与代训服务.md

@@ -0,0 +1,321 @@
+# 垂直大模型训练框架与代训服务
+
+## 1. 主题定位
+
+这一部分讨论的不是“再训练一个行业版通用模型”这么简单，而是一套更完整的方法论：如何理解垂直大模型训练，为什么“通用模型 + 行业语料”不足以形成真正的垂直能力，以及为什么围绕这一方法论形成的代训服务在产业上是成立的。
+
+这条线本质上站在 AI 上层任务语义、业务结构和训练目标设计这一侧，和基础系统、边缘部署、智能体应用构成上下游关系。它回答的是：
+
+> **行业模型为什么不是简单加语料，而是一整套角色、目标、制度、流程和边界的结构化重建。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 垂直大模型不等于“通用模型 + 行业语料”
+
+会议明确反对把垂直模型简化为：
+
+`垂直大模型 = 通用大模型 + 行业语料`
+
+原因在于，业务差异并不只是语言风格差异，而是更深层的结构差异，包括：
+
+- 角色不同；
+- 目标函数不同；
+- 制度约束不同；
+- 动作空间不同；
+- 工作流不同；
+- 升级与分流机制不同；
+- 业务边界与处理边界不同。
+
+### 2.2 真正决定垂直模型表现的是结构，而不是数据量本身
+
+如果训练目标没有定义清楚，即便不断增加行业语料，也往往只能得到“更像行业说话方式”的模型，而得不到真正能在行业流程里工作的模型。
+
+因此，关键不只是准备更多数据，而是把业务结构编码进训练与后训练过程。
+
+### 2.3 “七要素框架”是会议中最有价值的方法学沉淀
+
+会议中已经形成了一个比较稳定的“七要素”思路：
+
+1. 主体角色；
+2. 目标函数；
+3. 领域知识；
+4. 制度约束；
+5. 动作空间；
+6. 工作流；
+7. 业务边界与处理边界。
+
+这个框架的价值在于，它把“垂直化”从模糊概念变成了可拆解、可设计、可复核的方法问题。
+
+### 2.4 代训服务之所以成立，是因为客户往往缺的不是算力，而是结构化建模能力
+
+很多企业并不具备以下能力：
+
+- 定义训练目标；
+- 识别主体角色；
+- 拆分制度约束；
+- 组织工作流；
+- 设计动作空间；
+- 区分模型边界与人工边界。
+
+因此，代训服务的真实价值不只是“帮客户训练模型”，而是帮助客户完成一轮业务结构显化与训练目标重构。
+
+### 2.5 这条线本身可以沉淀为独立的方法与服务体系
+
+如果把这一套能力做扎实，它不只是某次项目中的附属服务，而可以形成：
+
+- 方法论材料；
+- 咨询服务；
+- 联合研发流程；
+- 训练与后训练工具链；
+- 行业模型开发手册。
+
+## 3. 这条线真正要做的事情
+
+从会议内容看，这条线真正要建设的，不是单一训练流程，而是一套“三层能力”。
+
+### 3.1 业务结构抽象能力
+
+先把客户的业务系统抽象成：
+
+- 谁在工作；
+- 为了什么工作；
+- 在什么制度约束下工作；
+- 有哪些动作空间；
+- 哪些流程是固定的；
+- 哪些决策需要模型参与；
+- 哪些边界必须保留给人。
+
+### 3.2 训练与后训练设计能力
+
+在业务结构清楚之后，再组织：
+
+- 数据准备；
+- 监督微调；
+- 偏好对齐；
+- 工作流约束注入；
+- 工具调用结构；
+- 边界与拒答策略。
+
+### 3.3 交付与服务能力
+
+最终落到客户侧，需要输出的不只是模型本身，还包括：
+
+- 业务结构说明；
+- 训练目标说明；
+- 数据与流程边界说明；
+- 部署建议；
+- 持续优化计划。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“先结构化建模，再训练设计，再联合迭代”的工作方式。
+
+### 4.1 先做业务结构访谈，不急于进训练
+
+第一步不是立刻收数据、开始训，而是先做业务和任务建模。  
+需要先回答：
+
+- 这个行业里谁是主角色；
+- 模型服务的主任务是什么；
+- 业务里的目标函数是什么；
+- 制度和规则约束是什么；
+- 哪些地方允许模型生成，哪些地方必须人工把关。
+
+### 4.2 再做训练框架设计
+
+当业务结构明晰后，再确定：
+
+- 数据如何组织；
+- 训练样本如何标注；
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练或工作流获得；
+- 哪些边界不应交给模型。
+
+### 4.3 最后用联合迭代替代“一次性交付”
+
+会议隐含的判断是，垂直模型不会一次训练就稳定成型，更适合：
+
+- 小步迭代；
+- 领域专家反馈；
+- 规则修正；
+- 数据回流；
+- 后训练与工作流联调。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：完成业务结构建模
+
+这一阶段应完成：
+
+- 角色梳理；
+- 目标函数梳理；
+- 制度与规则梳理；
+- 工作流和动作空间梳理；
+- 业务边界和模型边界划分。
+
+这一阶段的产物应当是：
+
+- 结构化访谈纪要；
+- 业务框架图；
+- 七要素分析表。
+
+### 5.2 第二步：形成训练与后训练设计稿
+
+这一阶段应完成：
+
+- 数据来源清单；
+- 训练样本设计；
+- 后训练目标设计；
+- 工作流与工具调用关系设计；
+- 安全边界与人工介入点设计。
+
+这一阶段的产物应当是：
+
+- 训练设计稿；
+- 后训练流程稿；
+- 数据治理与边界说明。
+
+### 5.3 第三步：组织小规模联合试训
+
+这一阶段不追求一步到位，而应聚焦少量高价值任务。  
+应完成：
+
+- 小样本试训；
+- 关键任务验证；
+- 失败案例分析；
+- 人工反馈回流；
+- 规则与工作流调整。
+
+### 5.4 第四步：形成代训服务包
+
+当试训稳定之后，再将其沉淀为更稳定的服务形态，包括：
+
+- 咨询服务包；
+- 数据与训练准备包；
+- 联合试训包；
+- 交付和持续优化包。
+
+## 6. 各方责任与分工方式
+
+这条线最怕“只有技术团队在训，没人定义业务”，因此责任划分必须非常清楚。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外需求沟通；
+- 业务问题转译；
+- 行业合作推进；
+- 服务包设计；
+- 对外汇报和合作节奏组织。
+
+唐老师团队更适合站在“业务和合作牵引”的位置。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 七要素方法论抽象；
+- 垂直模型问题定义；
+- 训练目标与边界设计把关；
+- 从个案中提炼共性框架。
+
+罗老师团队更适合站在“方法论和结构建模”的位置。
+
+### 6.3 训练与工程团队
+
+适合承担：
+
+- 数据处理；
+- 训练与后训练实现；
+- 评测与失败样例分析；
+- 工具调用和工作流联调；
+- 交付部署支持。
+
+这一角色负责把方法落到真实模型流程上。
+
+### 6.4 行业客户或业务合作方
+
+适合承担：
+
+- 提供真实业务流程和语料；
+- 明确角色、规则和边界；
+- 参与效果验收；
+- 对失败样例和业务偏差给出反馈。
+
+客户方不负责训练方法设计，但必须负责业务真实性和边界清晰度。
+
+## 7. 工作边界
+
+### 7.1 这条线不等于“做行业语料堆叠”
+
+如果只是追加语料而不重构角色、目标和工作流，就不构成真正的垂直模型训练框架。
+
+### 7.2 这条线不等于“代替客户完成全部业务数字化”
+
+代训服务可以帮助客户显化结构，但不应承担全部业务改造工作。
+
+### 7.3 训练、后训练、智能体工作流必须区分
+
+后续材料中要明确区分：
+
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练获得；
+- 哪些能力靠工作流、工具和规则系统获得。
+
+### 7.4 这条线不直接替代基础系统研究
+
+它补充的是 AI 任务语义、行业目标和训练结构层，但不替代 RTOS、基础系统和部署层研究。
+
+## 8. 合作推进方式
+
+这条线适合采用“咨询先行、试训跟进、服务沉淀”的推进方式。
+
+### 8.1 第一阶段：方法咨询与结构建模
+
+重点是：
+
+- 业务访谈；
+- 七要素建模；
+- 训练边界和工作流边界定义；
+- 确定适不适合做垂直模型。
+
+### 8.2 第二阶段：联合试训与验证
+
+重点是：
+
+- 选择少量高价值任务；
+- 做小规模试训；
+- 验证训练、后训练和工作流哪个更有效；
+- 形成失败案例和调整机制。
+
+### 8.3 第三阶段：形成代训服务与长期合作
+
+重点是：
+
+- 输出服务包；
+- 形成长期优化机制；
+- 必要时推进工具链和标准化材料。
+
+## 9. 与整体研究主线的关系
+
+这一主题虽然看上去更偏大模型产业化，但它和整体研究并不冲突，反而补足了上层语义与任务定义层。
+
+它的价值主要体现在：
+
+- 补充 AI 目标负载的任务语义与业务边界；
+- 说明系统表现并不只由 OS 决定，训练目标和模型结构同样重要；
+- 可以与行业样例、边缘部署、小型化系统和智能体应用形成上下游关系。
+
+## 10. 当前结论
+
+这条线真正值得保留的，不是“代训”这个商业词本身，而是它背后的方法学判断：
+
+> **垂直大模型的核心不是在通用模型上附加行业语料，而是把角色、目标、制度、动作空间、工作流和边界结构编码进训练与后训练过程。**
+
+如果继续向前推进，它最可能沉淀成两类成果：
+
+- 一类是垂直模型方法论和训练框架；
+- 一类是围绕这一方法论建立起来的咨询、试训和代训服务体系。

01-会议讨论/20260922_093448-会议主题拆分整理/05-法律政务数据治理智能体与XAPP平台.md

@@ -0,0 +1,330 @@
+# 法律政务数据治理智能体与XAPP平台
+
+## 1. 主题定位
+
+这一部分主要来自会议后半段的延伸讨论，内容已经明显脱离 RTOS 研究本身，转向法律、纪委办案、数据治理智能体和平台化产品形态。它是一条非常独立的产品与应用主题，但又和前面几个主题形成上下游关系：上接大模型方法与训练问题，下接具体行业系统和交付方式。
+
+这条线真正关心的，不是“做一个能聊天的法律助手”，而是：
+
+> **如何把复杂的数据治理、关系发现、证据组织和报告生成过程，封装成面向专业人员可直接使用的业务系统。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 政务与法律场景的核心问题不是对话，而是复杂数据治理
+
+会议中提到的多个场景，本质上都在解决同一类问题：
+
+- 多来源、多格式、多模态资料导入困难；
+- 原始数据需要清洗、映射、关联、解释和展示；
+- 用户不愿意直接操作复杂数据分析工具；
+- 用户真正需要的是问题理解、关系发现、证据组织和报告生成。
+
+因此，这一主题的主线不是“做一个聊天机器人”，而是“把复杂数据治理过程封装成可操作的业务系统”。
+
+### 2.2 专业应用不能被压扁成单一聊天窗口
+
+会议对纯对话式工作台给出了明确修正：
+
+- 重交互业务不能只靠聊天界面承载；
+- 上传物、工作流、结果区、图谱区和报告区都需要独立存在；
+- 专业应用必须保留自己的界面和流程结构。
+
+这意味着平台设计必须尊重业务 UI，而不是试图把一切都压成一个对话框。
+
+### 2.3 法律和政务场景更适合“专业应用 + 平台壳”的结构
+
+会议里出现的多个场景都说明：
+
+- 纪委办案系统需要强数据治理能力；
+- 律师产品需要强访谈、证据和报告能力；
+- 脱敏工具需要独立的安全工具形态；
+- 不同应用之间可以共享工作台和通用能力，但不应失去各自的业务结构。
+
+这就是 `XAPP` 思路出现的原因。
+
+### 2.4 平台价值和应用价值必须分开定义
+
+平台的价值在于：
+
+- 提供统一工作台；
+- 提供账号、路由、权限、文件管理、日志和通用模型能力；
+- 提供应用接入框架。
+
+应用的价值在于：
+
+- 行业模型；
+- 规则系统；
+- 数据治理逻辑；
+- 具体业务流程与交付物。
+
+如果平台和应用不分，结果往往是平台过空，应用过散。
+
+### 2.5 本地部署和数据安全是这条线的刚性约束
+
+无论是纪委办案还是法律业务，会议都明确指出：
+
+- 数据安全要求高；
+- 现场部署需求强；
+- 响应稳定性要求高；
+- 数据不能随意外流。
+
+因此，这条线天然更适合本地部署或专有环境部署。
+
+## 3. 会议中浮现出的几类产品
+
+### 3.1 纪委办案数据治理智能体
+
+这一方向主要面向：
+
+- 银行流水；
+- 通话记录；
+- 出行数据；
+- 房产信息；
+- 保险与其他多源资料。
+
+它的核心不是“自动办案”，而是：
+
+- 导入；
+- 清洗；
+- 模板映射；
+- 关系发现；
+- 分析辅助；
+- 报告与材料组织。
+
+### 3.2 律师场景产品
+
+会议中提到的律师方向主要包括：
+
+- 婚家咨询访谈整理；
+- 证据组织与关系发现；
+- 资金分析；
+- 脱敏工具。
+
+这一方向说明，法律行业更适合“专业工具 + 专业流程”，而不是通用助手叙事。
+
+### 3.3 XAPP 平台
+
+会议中提出的 `XAPP` 平台思路非常关键。  
+它的含义不是再造一个“总助手”，而是：
+
+- 共享统一工作台；
+- 每个应用保留独立 UI；
+- 应用之间共享登录、权限、文件、模型和路由；
+- 复杂业务仍然通过界面、表格、流程和产物区组织。
+
+这实际上是对“纯聊天平台”路线的一次重要修正。
+
+## 4. 这条线真正要做的事情
+
+如果把会议内容收束，这条线真正要建设的是“三层产品能力”。
+
+### 4.1 数据治理底层能力
+
+包括：
+
+- 多源数据导入；
+- 模板识别与字段映射；
+- 清洗与标准化；
+- 关系抽取与图谱组织；
+- 检索与追踪。
+
+### 4.2 行业应用能力
+
+包括：
+
+- 办案智能体；
+- 律师访谈和报告产品；
+- 脱敏工具；
+- 关系分析和证据整理工具。
+
+### 4.3 XAPP 平台能力
+
+包括：
+
+- 统一工作台；
+- 应用路由；
+- 权限与账号系统；
+- 文件与任务管理；
+- 共用模型和公共能力接入。
+
+## 5. 建议的工作方式
+
+这条线更适合采用“先单应用打透，再平台化抽象”的工作方式，而不是一开始就先做大平台。
+
+### 5.1 先用具体高价值场景验证价值
+
+应优先选择最痛、最清楚、最容易形成产物的场景，例如：
+
+- 纪委办案数据治理；
+- 婚家咨询整理与报告；
+- 脱敏处理工具。
+
+先让单点应用把价值打透。
+
+### 5.2 再抽象可复用的中间层
+
+当单点应用稳定之后，再把其中共性能力抽出来，例如：
+
+- 数据导入；
+- 模板映射；
+- 关系图谱；
+- 报告生成；
+- 权限与日志管理。
+
+### 5.3 最后再形成 XAPP 平台壳
+
+只有在多个应用共享同一组共性能力之后，再做平台化抽象，才不会做成空平台。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：选择 1 到 2 个高价值场景做应用原型
+
+这一阶段应完成：
+
+- 选定业务场景；
+- 梳理数据来源；
+- 梳理用户任务；
+- 梳理需要生成的产物；
+- 明确本地部署和安全要求。
+
+### 6.2 第二步：打通数据治理链路
+
+这一阶段应完成：
+
+- 数据导入；
+- 模板映射；
+- 清洗与标准化；
+- 关系发现；
+- 初步报告生成。
+
+### 6.3 第三步：形成应用级交付
+
+这一阶段应完成：
+
+- 独立 UI；
+- 工作流组织；
+- 上传区、处理中间区、结果区和报告区；
+- 用户可操作的专业化界面。
+
+### 6.4 第四步：抽取平台共性能力
+
+当两个以上应用出现后，再抽取：
+
+- 登录权限；
+- 文件和任务管理；
+- 通用模型调用；
+- 公共组件；
+- 应用接入标准。
+
+## 7. 各方责任与分工方式
+
+这条线如果要落地，必须明确“谁负责场景、谁负责系统、谁负责方法、谁负责交付”。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 行业需求获取与场景梳理；
+- 客户沟通；
+- 交付方案组织；
+- 产品方向和合作节奏把控；
+- 对外汇报与合作推进。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 方法论抽象；
+- 数据治理逻辑与共性框架判断；
+- 平台层与应用层边界把关；
+- 从个案产品中提炼通用结构。
+
+### 7.3 产品与工程团队
+
+适合承担：
+
+- 数据治理链路实现；
+- 应用 UI 与工作流实现；
+- 报告和图谱模块；
+- 平台共性能力抽取；
+- 本地部署与安全实现。
+
+### 7.4 行业合作方或客户方
+
+适合承担：
+
+- 提供真实业务数据与使用流程；
+- 明确合规和安全要求；
+- 参与验收；
+- 对应用效果与流程合理性给出反馈。
+
+## 8. 工作边界
+
+### 8.1 这条线不等于“做个法律聊天机器人”
+
+如果把重点放在聊天入口，而不解决数据治理、图谱、报告和流程问题，这条线就会失焦。
+
+### 8.2 平台不应先于应用存在
+
+没有稳定的应用需求支撑，先做平台很容易变成空壳工程。
+
+### 8.3 专业应用必须保留独立 UI 和工作流
+
+不应把纪委、律师、脱敏工具都压成同一种对话式界面。
+
+### 8.4 这条线不直接纳入 RTOS 主课题
+
+它是独立的应用和产品方向材料，适合作为并行线保留，而不是强行并入基础系统主研究。
+
+## 9. 合作推进方式
+
+这条线适合采用“单应用切入、共性能力抽取、平台化收口”的推进方式。
+
+### 9.1 第一阶段：应用验证
+
+重点是：
+
+- 选具体场景；
+- 做原型；
+- 证明价值；
+- 形成第一批产物。
+
+### 9.2 第二阶段：应用扩展与复用
+
+重点是：
+
+- 增加第二类应用；
+- 比较共性与差异；
+- 抽取中间层能力；
+- 形成通用模块。
+
+### 9.3 第三阶段：平台化与持续合作
+
+重点是：
+
+- 建立 XAPP 平台结构；
+- 定义应用接入标准；
+- 形成长期合作和产品化路线。
+
+## 10. 与整体研究材料的关系
+
+这一主题虽然不直接属于 RTOS 主线，但对整体项目仍然有两类价值：
+
+- 它说明 AI 应用进入真实行业以后，对数据治理、平台结构、UI 组织和本地部署的要求会非常具体；
+- 它可以作为后续讨论“平台层”“XAPP 层”“工作流层”和“专业应用层”的现实参照。
+
+因此，它不应被强行塞进 RTOS 课题，但值得作为独立并行材料长期保留。
+
+## 11. 当前结论
+
+这条线真正值得保留的，不是若干零散行业点子，而是一条更稳定的产品判断：
+
+> **法律政务类智能体的核心，不是对话入口，而是把复杂数据治理、关系分析、业务流程和报告产出封装成专业应用，并在多个应用之上抽象出 XAPP 平台能力。**
+
+如果继续往前推进，这条线最自然的演化方式是：
+
+- 先做高价值行业应用；
+- 再抽取共性数据治理能力；
+- 最后收口到平台和应用协同的产品结构。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/00-项目总览/01-当前研究问题：背景、问题与挑战.md

@@ -0,0 +1,75 @@
+# 01-当前研究问题：背景、问题与挑战
+
+## 1. 背景
+
+当前智能系统正在持续进入控制、装备、交通、工业现场与边缘决策等任务关键场景。随着人工智能推理能力从离线分析走向在线决策，系统对人工智能运行的要求已经扩展为功能有效性、时间约束、运行稳定性与可验证性的统一达标。
+
+外部研究与产业表达已经形成较清晰的共识：
+
+- AI 用于 safety-critical systems 的安全保障仍在持续推进，系统层面的可控、可验证与可接受性仍是核心议题；
+- QNX、Wind River 等平台方已将 deterministic、predictable、secure 的软件基础与 AI 能力并列讨论；
+- Linux Foundation 对 PREEMPT_RT 的持续推进，表明低延时、低抖动和可预测执行已经成为重要基础能力。
+
+在这样的背景下，操作系统已经成为决定 AI 推理能否进入任务关键系统的重要基础平台。尤其当 AI 推理与周期控制、执行闭环、联锁逻辑、通信管理等负载共同运行时，系统时序边界、资源争抢边界与恢复边界都会被重新放大。
+
+## 2. 问题
+
+本项目聚焦的当前研究问题可以表述为：
+
+> **在五类部署形态下，当人工智能目标负载进入任务关键系统后，以大型跨平台实时操作系统为基础平台的系统，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性？**
+
+这个问题包含四个明确支点：
+
+1. 研究对象是**大型跨平台实时操作系统**这一类平台；
+2. `SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等构成外部参照样本；
+3. AI 推理在任务关键系统中被界定为**人工智能目标负载**，与关键保障负载、伴生竞争负载共同构成系统运行面；
+4. 对照对象明确拆分为**普通 Linux** 与 **PREEMPT_RT Linux**，用来建立不同系统基础能力之间的可比关系。
+
+项目围绕以下三个判断维度展开：
+
+- AI 目标负载与关键保障负载能否在统一系统中稳定共存；
+- 操作系统能否通过调度、隔离、内存管理、中断管理与恢复机制维持系统边界；
+- 系统是否能够同时实现 AI 功能有效性与实时性达标。
+
+因此，这个研究问题本质上是一个面向任务关键系统的系统研究问题，也是一个具有产业验证价值的平台比较问题。
+
+## 3. 挑战
+
+围绕上述问题，当前研究至少面临以下几类核心挑战。
+
+### 3.1 五类部署形态下的统一验证挑战
+
+`T5~T1` 五类部署形态与 `11` 个代表档位共同构成验证矩阵、证据组织框架与跨场景比较环境。这里的核心挑战，是在不同资源约束、拓扑结构和负载强度下，用统一方法解释 RTOS 的优势边界与失效边界。
+
+### 3.2 对照体系的精细化挑战
+
+本项目采用三级对照体系：
+
+- `O0` 普通 Linux；
+- `O1` PREEMPT_RT Linux；
+- 大型跨平台 RTOS。
+
+这一对照设计将普通 Linux 与 PREEMPT_RT Linux 分别建模，用于区分一般低延时收益与 RTOS 在确定性、隔离性和可分析性上的收益来源。
+
+### 3.3 双目标同时达标的评价挑战
+
+当 AI 被界定为目标负载后，评价体系同时覆盖关键保障负载保护效果，以及 AI 目标负载的有效性、时效性和长期稳定性。因此，评价指标需要同时覆盖：
+
+- 关键保障负载：`deadline miss ratio`、`P99/P99.9 jitter`、响应时间边界；
+- AI 目标负载：`TTFT`、`TPOT`、端到端响应时间、成功率、功能质量；
+- 系统协同层：有效吞吐、`E/token`、热漂移、资源争抢边界、恢复能力。
+
+### 3.4 多目标负载协调的机制挑战
+
+在任务关键系统中，AI 目标负载、关键保障负载与伴生竞争负载共同构成统一运行面。它们在 CPU、内存、总线、中断、DMA、缓存与加速器访问上会形成持续竞争。研究的关键难点在于，RTOS 是否能够把这种竞争收敛为可分析、可控制、可恢复的系统行为边界。
+
+## 外部参考
+
+1. Linux Foundation, Real-Time Linux Project  
+   <https://realtime-linux.dev-lfprojects5.linuxfoundation.org/>
+2. QNX, Software Foundation for Physical AI
+   <https://qnx.software/en/software/technologies/physical-ai>
+3. Wind River 官网与 Edge AI / mission-critical 相关公开表述  
+   <https://www.windriver.com/>
+4. Ullrich et al., *AI Safety Assurance for Automated Vehicles: A Survey on Research, Standardization, Regulation*  
+   <https://arxiv.org/abs/2504.18328v1>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/00-项目总览/02-研究定位与项目边界.md

@@ -0,0 +1,155 @@
+# 02-研究定位与项目边界
+
+## 一句话定义
+
+本项目的正式题目是：
+
+> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**
+
+本项目围绕下面这个核心问题展开：
+
+> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性。SylixOS 是本项目的主实验样例，QNX、VxWorks、INTEGRITY、LynxOS-178 等可作为外部参照样本。**
+
+## 这个项目在做什么
+
+### 1. 研究对象与平台角色
+
+本项目的研究对象是**大型跨平台实时操作系统这一类平台**，重点关注它们在任务关键系统中的：
+
+- 其实时调度、资源隔离、内存管理、中断管理与恢复机制；
+- 这些机制在不同部署形态下承载人工智能目标负载时，是否仍能维持系统边界。
+
+在这组平台中：
+
+- `SylixOS` 是本项目的主实验样例；
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等用于建立外部参照坐标；
+- `Linux` 与 `PREEMPT_RT Linux` 是核心对照对象。
+
+硬件平台在本项目中承担的是**验证载体**角色，用来暴露不同资源约束、拓扑结构和调度边界。
+
+### 2. 系统场景与负载结构
+
+本项目面向的是**任务关键系统**。在这个系统语境里，人工智能推理属于系统功能的一部分，因此被定义为：
+
+- **人工智能目标负载**
+
+与之共同构成系统运行面的还有两类负载：
+
+- **关键保障负载**：周期控制、执行闭环、联锁、状态采集等；
+- **伴生竞争负载**：日志、更新、后台通信、模型加载、存储和网络 I/O 等。
+
+> **RTOS 如何协调人工智能目标负载与关键保障负载，使系统同时满足功能有效性与实时性边界。**
+
+### 3. 在五类部署形态下建立统一验证矩阵
+
+`T5~T1` 五类部署形态和 `11` 个代表档位在本项目中构成验证矩阵与证据组织框架：
+
+- 验证矩阵；
+- 证据组织框架；
+- 不同资源条件下的边界测试环境。
+
+这套验证矩阵覆盖：
+
+- `T5` 控制端
+- `T4` 设备端 SoC
+- `T3` 边缘节点
+- `T2` 桌面 / 工作站单机
+- `T1` 服务器 / 集群
+
+其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
+
+这套验证矩阵支撑以下四类判断：
+
+- RTOS 优势在哪些部署形态下最明显；
+- 这些优势来自哪些系统机制；
+- 为维持实时保障需要付出多少吞吐和能耗代价；
+- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
+
+这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
+
+### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
+
+项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
+
+证据至少包括三层：
+
+- **人工智能目标负载层**：
+  `TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
+- **关键保障负载层**：
+  `deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
+- **系统协同层**：
+  有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
+
+## 项目边界
+
+### 1. 应用背景与研究对象
+
+项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
+
+- 大型跨平台实时操作系统；
+- 任务关键系统；
+- 人工智能目标负载。
+
+其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
+
+### 2. 评价重点
+
+项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
+
+- AI 目标负载是否按时完成；
+- 关键保障负载是否满足截止期；
+- 系统是否在长时间运行中保持稳定；
+- 满足这些约束后，吞吐与能耗代价是否可接受。
+
+### 3. 算法与系统的关系
+
+量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
+
+- 它们如何改变时延分布；
+- 如何影响内存占用和带宽争抢；
+- 如何改变调度器和资源管理策略。
+
+因此，项目重点落在系统机制、调度策略和资源治理能力上。
+
+对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
+
+因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
+
+### 4. 成果形态
+
+项目成果需要形成完整的方法与证据体系，包括：
+
+- 可解释的方法；
+- 可复现的证据；
+- 明确的适用边界；
+- 跨部署形态可比较的规律；
+- 能被学术界和产业界共同理解的结论。
+
+在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
+
+## 这个项目最后要交付什么
+
+项目最终交付物至少应包括：
+
+1. 一套面向任务关键系统的 SylixOS 实时保障机制；
+2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
+3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
+4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
+5. 一套可用于产业沟通和产品表达的技术叙事。
+
+## 判断项目是否成功，要看什么
+
+要看：
+
+- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
+- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
+- 吞吐损失是否在可接受范围；
+- 能耗和热稳定性是否同步改善或至少可解释；
+- 结论是否能跨部署形态成立；
+- 优势边界和失败边界是否都被讲清楚。
+
+## 最后一句话
+
+这个项目的本质是：
+
+> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/00-整体研究框架.md

@@ -0,0 +1,283 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
+
+## 0. 核心问题
+
+本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
+
+> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
+
+这里有三个基础判断：
+
+1. **研究对象是实时操作系统平台**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **硬件条件以验证矩阵形式组织研究证据**。
+
+本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
+
+在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，RTOS 对人工智能目标负载与关键保障负载双目标达标能力的支撑边界。
+
+---
+
+## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
+
+### 1.1 五类部署形态
+
+`T5~T1` 五类部署形态构成验证环境与证据组织框架。
+
+| 部署形态 | 系统角色 | 典型环境 | 主要验证重点 |
+|---|---|---|---|
+| T5 控制端 | 极紧资源预算下的任务关键控制节点 | MCU、控制器、轻量控制盒 | 强实时、低功耗、极小内存预算 |
+| T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
+| T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
+| T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
+| T1 服务器 / 集群 | 面向任务关键场景的分布式协同计算平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式协同与规模扩展 |
+
+这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
+
+其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
+
+### 1.2 五种算力基础
+
+| 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
+|---|---|---|---|
+| 控制型算力基础 | 极小内存、低主频、弱加速或无加速 | STM32H7、ESP32-S3、RK3568 控制盒 | 资源极紧、预算刚性、模型必须极小 |
+| 设备端 SoC 型算力基础 | CPU + NPU/GPU + 统一内存一体化 | RK3588、i.MX93、车规 SoC | 统一内存争抢、驱动封闭、加速器与 CPU 协调 |
+| 边缘节点型算力基础 | 较大 DDR/显存 + 专用加速器 + 近源部署 | Jetson AGX Orin、IGX、边缘工控机 | 多任务并发、热稳定性、I/O 与 DMA 压力 |
+| 工作站单机型算力基础 | 多 GPU/加速卡 + 单机大内存 | 4×V100、RTX 工作站、4×H100 单机 | 多卡拓扑、显存分片、单机高密部署 |
+| 服务器/集群型算力基础 | 多节点 CPU + 多 GPU/NPU + 高速互联 | V100/H100 集群、ARM/x86 集群 | NUMA、跨卡通信、分布式协同调度 |
+
+### 1.3 三类系统负载
+
+后续所有设计和评估都以三类负载为基本单元。
+
+| 负载类型 | 定义 | 典型例子 | 主要评价点 |
+|---|---|---|---|
+| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 | 时效性、功能有效性、长时间稳定性 |
+| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、状态采集、联锁、执行控制 | 截止期、抖动、观测最大响应时间 |
+| 伴生竞争负载 | 不属于核心功能但会争抢资源的任务 | 日志、更新、后台通信、模型加载、I/O | 干扰强度、资源占用、可隔离性 |
+
+本研究重点评估：
+
+> **在人工智能目标负载与关键保障负载并存时，RTOS 对双目标达标能力的支撑效果与成立条件。**
+
+---
+
+## 2. 统一技术体系：五层技术栈 + 一条横向治理线
+
+无论部署形态如何变化，系统描述都统一采用同一套技术栈。
+
+```
+┌───────────────────────────────────────────────────────────────┐
+│ L5 模型与任务语义层                                            │
+│ AI 模型、量化、KV Cache 组织、输出质量与服务约束                 │
+├───────────────────────────────────────────────────────────────┤
+│ L4 运行时与负载编排层                                           │
+│ 任务图、队列、准入控制、内存池、流水线、隔离策略                 │
+├───────────────────────────────────────────────────────────────┤
+│ L3 资源抽象与设备协同层                                         │
+│ CPU/NPU/GPU/DMA/PCIe/RDMA 抽象、带宽管理、设备状态暴露          │
+├───────────────────────────────────────────────────────────────┤
+│ L2 实时操作系统核心层                                           │
+│ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制           │
+├───────────────────────────────────────────────────────────────┤
+│ L1 硬件与互联层                                                 │
+│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联、PTP   │
+└───────────────────────────────────────────────────────────────┘
+```
+
+**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
+
+### 2.1 这套技术栈的意义
+
+这套表达用于把三个维度彻底拆开：
+
+- `T5~T1` 回答**在哪里验证**；
+- 五种算力基础回答**基于什么资源形态验证**；
+- 五层技术栈回答**系统内部怎么组织与保障**。
+
+这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
+
+### 2.2 人工智能目标负载到 RTOS 任务的映射
+
+```
+人工智能目标负载阶段          RTOS 侧任务/事件
+────────────────            ──────────────────
+输入处理 / Tokenization      → 低优先级辅助任务
+Embedding / Prefill         → 计算密集任务
+Attention / KV Cache         → 延迟敏感任务
+FFN / 设备计算              → 可流水化计算任务
+采样 / 输出决策              → 中优先级服务任务
+结果封装 / 输出通路          → 接口与通信任务
+```
+
+关键点在于：
+
+- 哪些阶段必须优先保障；
+- 哪些阶段可以延迟或限流；
+- 哪些资源需要隔离；
+- 哪些竞争会直接破坏关键保障负载。
+
+这里还要明确区分两类执行单元：
+
+- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
+- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
+
+---
+
+## 3. 研究主线：实时保障机制
+
+项目后续所有子方向都服务于同一个主命题：
+
+> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
+
+围绕这个主命题，系统机制可以分为六个方向：
+
+1. **推理图任务调度**
+2. **KV Cache 与内存管理**
+3. **加速器协同调度**
+4. **量化与精度感知调度**
+5. **中断与实时性保障**
+6. **能耗与热管理**
+
+这六个方向共同服务于一个判断：
+
+> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
+
+### 3.1 面向小型化与低功耗方向的应用副课题
+
+在六个机制方向之外，项目设置一条面向应用落点的专题线：
+
+> **面向小型化与低功耗方向的应用副课题。**
+
+这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
+
+1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
+2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
+3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
+4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
+
+这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
+
+- 小型化与低功耗系统是否仍能承载人工智能目标负载；
+- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
+- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
+
+因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
+
+### 3.2 研究方法总述
+
+为了回答这个问题，研究方法采用一条统一证据链：
+
+1. **准入**：先完成设备、测量、加速器、模型与混合负载的 `G0~G4` 准入；
+2. **对照**：在同硬件、同负载、同预算下组织 `O0/O1/O2/O3` 公平对照；
+3. **建模**：把系统统一拆成人工智能目标负载、关键保障负载与伴生竞争负载三类负载；
+4. **机制**：围绕调度、隔离、内存、中断、能耗等机制进行实现与配置；
+5. **实测**：用双目标达标、长稳、恢复与消融实验验证机制有效性、稳定性与适用边界；
+6. **跨档位分析**：再把结论放回 `T5~T1` 五类部署形态中观察规律、边界与收窄区间。
+
+因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。
+
+这套统一框架统一的是研究对象定义、负载建模、评估指标与对照方法，不预设同一套机制会在所有档位取得同等收益。研究结论将以有效区间、失效边界和贡献来源的形式展开。
+
+---
+
+## 4. 评价框架：双目标达标 + 系统协同稳定
+
+### 4.1 人工智能目标负载指标
+
+| 指标 | 含义 |
+|---|---|
+| `TTFT` | 首 token/首结果响应时间 |
+| `TPOT` | 连续输出阶段的平均时延 |
+| 端到端响应时间 | 从请求进入到结果可用的总时长 |
+| 功能有效性 | 精度、成功率、任务完成率、结果可用性 |
+| 长时间稳定性 | 长稳运行中的退化、漂移和失败情况 |
+
+### 4.2 关键保障负载指标
+
+| 指标 | 含义 |
+|---|---|
+| `deadline miss ratio` | 截止期违约比例 |
+| `P99/P99.9 jitter` | 高频尾部抖动 |
+| 观测最大响应时间 | 运行窗口内最大响应值 |
+| 外部接口响应 | GPIO、CAN、RS485、网络回路的端到端响应 |
+
+### 4.3 系统协同指标
+
+| 指标 | 含义 |
+|---|---|
+| 有效吞吐 | 满足时效与质量约束后的真实吞吐 |
+| `E/token` / `tokens/J` | 满足约束前提下的能效 |
+| 温度与热漂移 | 热稳定性及降频影响 |
+| 恢复能力 | 过载、重启、故障后的恢复时间 |
+| 公平性与隔离效果 | 多模型、多任务并发下的资源分配行为 |
+
+因此，本研究的成功标准是：
+
+> **人工智能目标负载、关键保障负载与系统协同三层指标同时达标。**
+
+---
+
+## 5. 对照关系：普通 Linux、PREEMPT_RT 与 RTOS
+
+后续所有实验和论文叙事都以三层 OS 对照为主线：
+
+| 对照组 | 含义 | 作用 |
+|---|---|---|
+| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
+| `O1` PREEMPT_RT Linux | 实时增强型通用 OS | 作为最关键的系统对照 |
+| `O2/O3` SylixOS | 大型跨平台 RTOS 默认与优化配置 | 主实验样例 |
+
+这条对照线用于区分两类系统收益来源：
+
+- RTOS 相对普通 Linux 的差异，对应实时性基础带来的系统收益；
+- RTOS 相对 PREEMPT_RT 的差异，对应专用 RTOS 机制带来的系统收益。
+
+---
+
+## 6. 与已有工作的关系
+
+| 已有工作 | 其关注点 | 与本研究的差异 |
+|---|---|---|
+| vLLM / TGI / TensorRT-LLM | 高吞吐推理服务 | 主要关心服务效率，不以任务关键系统为中心 |
+| 微型模型 / TinyML / 模型压缩 | 压缩模型规模 | 关注模型适配，不解决系统级实时保障 |
+| 厂商 SDK 调度 | 封闭设备路径 | 缺乏跨平台可分析的 OS 机制比较 |
+| PREEMPT_RT 相关工作 | 提高 Linux 可预测性 | 很少同时纳入 AI 目标负载与关键保障负载双目标 |
+
+本研究的独特性体现在：
+
+1. 把**人工智能目标负载**引入任务关键系统研究；
+2. 把**大型跨平台实时操作系统**作为研究主角；
+3. 用 `T5~T1` 五类部署形态与 `11` 个代表档位建立完整验证矩阵；
+4. 同时比较 **普通 Linux / PREEMPT_RT / RTOS**；
+5. 用双目标达标和系统协同稳定构成证据链。
+
+---
+
+## 7. 文档结构索引
+
+| 文档 | 内容 |
+|-----|------|
+| [01-推理图任务调度.md](01-推理图任务调度.md) | 人工智能目标负载的任务图拆解与调度策略 |
+| [02-KV-Cache与内存管理.md](02-KV-Cache与内存管理.md) | KV Cache 生命周期、内存池与带宽竞争 |
+| [03-加速器协同调度.md](03-加速器协同调度.md) | CPU、NPU、GPU、DMA 等异构资源协同 |
+| [04-量化精度感知调度.md](04-量化精度感知调度.md) | 精度、质量与调度决策联动 |
+| [05-中断与实时性保障.md](05-中断与实时性保障.md) | 中断路径、线程化、隔离与关键保障负载保护 |
+| [06-能耗与热管理.md](06-能耗与热管理.md) | 能耗、温度、频率与长时间稳定性 |
+| [07-方法论与评估工具链.md](07-方法论与评估工具链.md) | 方法论、对照设计、采样与评估工具链 |
+
+---
+
+## 8. 预期研究成果
+
+1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
+2. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
+3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
+4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
+5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
+6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
+7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
+
+---
+
+*最后更新: 2026-09-21*

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/01-推理图任务调度.md

@@ -13,6 +13,28 @@ RTOS需要将这个DAG映射为task集合，并设计调度策略保证：
 2. **延迟最小化** — TTFT和尾延迟最小
 3. **确定性保证** — 满足硬实时约束（如语音对话的<200ms抖动）
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何把人工智能目标负载拆解为可由 RTOS 管理的任务图；
+- 如何让人工智能目标负载与关键保障负载在同一系统中同时达标；
+- 如何把 SylixOS 的调度能力转化为可观测的系统收益与对照差异。
+
+因此，这一方向服务的是总课题中的“任务图建模与调度保障”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+这一方向在 `T5~T1` 五类部署形态中都成立，但关注重点不同：
+
+| 部署形态 | 调度侧重点 |
+|---|---|
+| `T5` 控制端 | 小任务集、强实时、极低抖动 |
+| `T4` 终端设备 | 单路智能任务与本地控制任务并存 |
+| `T3` 边缘节点 | 多源输入与多任务竞争下的任务图调度 |
+| `T2` 单机工作站 | 高吞吐推理与关键任务隔离并行 |
+| `T1` 服务器/集群 | 多请求队列、跨核与跨设备调度协同 |
+
 ## 2. LLM推理图的分解
 
 ### 2.1 推理阶段分析
@@ -359,7 +381,15 @@ RTOS角色:
 - RTOS主要提供实时中断响应
 ```
 
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，调度机制至少要回答下面三个问题：
+
+1. 人工智能目标负载的 `TTFT`、`TPOT` 和端到端响应时间是否改善；
+2. 关键保障负载的 `deadline miss ratio`、`P99/P99.9 jitter` 是否仍受控；
+3. 在多任务并存、到达率变化和伴生竞争负载存在时，系统是否仍保持可解释的调度边界。
+
+## 8. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -370,7 +400,7 @@ RTOS角色:
 | 同步机制 | Semaphore / Mutex / Notify | **Notify + Barrier** | 低开销，实时性可分析 |
 | 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 |
 
-## 8. 开放研究问题
+## 9. 开放研究问题
 
 1. **动态WCET估计**：LLM的WCET随input长度变化，如何在线估计？
 2. **Adaptive Priority**：运行时根据系统负载动态调整优先级？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/02-KV-Cache与内存管理.md

@@ -22,6 +22,28 @@ RTOS场景下KV Cache管理的关键问题：
 3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
 4. **多请求KV Cache隔离** — 多流场景下的内存隔离与复用
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何让人工智能目标负载在受限容量下保持可持续服务；
+- 如何避免 KV Cache 动态增长破坏关键保障负载的实时边界；
+- 如何把内存确定性、带宽隔离和准入控制纳入 SylixOS 的实时保障机制。
+
+因此，这一方向服务的是总课题中的“容量边界与内存确定性”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+KV Cache 与内存管理在 `T5~T1` 中的约束差异很大，因此需要按部署形态看重点：
+
+| 部署形态 | 内存管理侧重点 |
+|---|---|
+| `T5` 控制端 | 极低内存预算下的模型裁剪与静态预分配 |
+| `T4` 终端设备 | 小模型多会话下的碎片与带宽竞争 |
+| `T3` 边缘节点 | 多请求并发下的 KV 隔离与带宽准入 |
+| `T2` 单机工作站 | 大上下文与高吞吐下的容量边界 |
+| `T1` 服务器/集群 | NUMA、多设备与跨节点缓存协同 |
+
 ## 2. KV Cache结构分析
 
 ### 2.1 KV Cache布局
@@ -342,7 +364,15 @@ Paged KV      | variable| 0%     | variable | 低
 - 多GPU间KV Cache同步
 ```
 
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，KV Cache 与内存管理至少要回答下面三个问题：
+
+1. 人工智能目标负载在不同上下文长度和并发度下是否仍保持可接受的 `TTFT`、`TPOT` 与成功率；
+2. 关键保障负载是否因内存碎片、带宽争用或回收抖动而出现 `deadline miss` 或尾部抖动放大；
+3. 内存池、分页、压缩和准入机制是否建立了可预测的容量边界与准入边界。
+
+## 8. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -353,7 +383,7 @@ Paged KV      | variable| 0%     | variable | 低
 | 带宽管理 | 固定分配 / 动态 | **Bandwidth-aware** | 避免带宽饱和 |
 | 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
 
-## 8. 开放研究问题
+## 9. 开放研究问题
 
 1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
 2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/03-加速器协同调度.md

@@ -2,13 +2,35 @@
 
 ## 1. 问题陈述
 
-现代嵌入式AI SoC都包含专用加速器(NPU/GPU/DSP)，LLM推理需要CPU和加速器协同工作。核心问题：
+任务关键系统中的人工智能目标负载往往依赖专用加速器(NPU/GPU/DSP)与 CPU 协同完成计算。RTOS 需要协调 CPU 与加速器协同工作。核心问题：
 
 1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
 2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
 3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
 4. **同步开销**: barrier/semaphore的实时性分析复杂
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何让 RTOS 对人工智能目标负载的设备计算阶段建立可管理的节拍；
+- 如何避免 CPU、加速器、DMA 和中断之间的协同开销侵蚀关键保障负载边界；
+- 如何把异构设备协同从黑盒调用，转化为可分析、可限流、可恢复的系统机制。
+
+因此，这一方向服务的是总课题中的“设备协同与异构执行可预测性”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+加速器协同在 `T5~T1` 中的实现方式差异很大，因此需要按部署形态看重点：
+
+| 部署形态 | 加速器协同侧重点 |
+|---|---|
+| `T5` 控制端 | 无加速器或轻量 DSP/NPU 下的简化协同 |
+| `T4` 终端设备 | SoC 内 CPU 与片上 NPU 的同步与拷贝开销 |
+| `T3` 边缘节点 | 多核 CPU 与外设/NPU/GPU 的流水线协同 |
+| `T2` 单机工作站 | CPU 与独立 GPU 的队列、DMA 与中断协同 |
+| `T1` 服务器/集群 | 多 GPU、多 NUMA 域与多进程协同执行 |
+
 ## 2. 加速器架构分析
 
 ### 2.1 常见加速器类型
@@ -403,7 +425,15 @@ RTOS角色:
   - RTOS主要保障中断响应
 ```
 
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，加速器协同机制至少要回答下面三个问题：
+
+1. 设备协同是否降低了人工智能目标负载的等待时间、传输开销和端到端抖动；
+2. DMA、中断和共享内存竞争是否会冲击关键保障负载的响应时间边界；
+3. 当加速器状态不可见、延迟波动或发生故障时，系统是否仍具备准入、限流和恢复能力。
+
+## 9. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -414,7 +444,7 @@ RTOS角色:
 | 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
 | 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
 
-## 9. 开放研究问题
+## 10. 开放研究问题
 
 1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
 2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/04-量化精度感知调度.md

@@ -13,6 +13,28 @@ LLM的量化(Int8/Int4)不仅影响计算精度和模型大小，还直接影响
 2. 内存带宽需求
 3. 精度切换时的同步策略
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何把量化精度纳入 RTOS 可分析的调度参数；
+- 如何在人工智能目标负载时效性与输出有效性之间建立可控权衡；
+- 如何避免精度切换、校准开销和 MoE 负载波动破坏关键保障负载的实时边界。
+
+因此，这一方向服务的是总课题中的“质量-时效联合调度”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+量化与精度感知调度在 `T5~T1` 中的作用方式不同，因此需要按部署形态看重点：
+
+| 部署形态 | 精度调度侧重点 |
+|---|---|
+| `T5` 控制端 | 固定低精度、静态校准与可预测执行时间 |
+| `T4` 终端设备 | Int8/Int4 下的质量-时延平衡 |
+| `T3` 边缘节点 | 负载波动下的动态精度与服务模式切换 |
+| `T2` 单机工作站 | 多精度混合与大上下文推理的联合优化 |
+| `T1` 服务器/集群 | 多模型、多租户下的精度策略编排 |
+
 ## 2. 量化层级分析
 
 ### 2.1 LLM各组件的量化粒度
@@ -490,7 +512,15 @@ Solution: Multi-objective optimization
 - 量化感知 serving (vLLM FP8 support)
 ```
 
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，量化与精度感知调度至少要回答下面三个问题：
+
+1. 不同精度策略下，人工智能目标负载的 `TTFT`、`TPOT`、成功率和输出质量如何共同变化；
+2. 精度切换、同步和校准开销是否会把关键保障负载推过实时边界；
+3. 精度模式切换是否可以被准入控制和运行模式管理，并保持可预测的抖动边界。
+
+## 9. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -501,7 +531,7 @@ Solution: Multi-objective optimization
 | 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
 | 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
 
-## 9. 开放研究问题
+## 10. 开放研究问题
 
 1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
 2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/05-中断与实时性保障.md

@@ -2,13 +2,35 @@
 
 ## 1. 问题陈述
 
-RTOS上的LLM推理不是孤立的系统。设备中还有其他硬实时任务(传感器、通信、控制)，它们与LLM任务共存于同一个RTOS内核中。核心问题：
+RTOS 上的人工智能目标负载与传感、通信、控制等关键保障负载共存于同一个 RTOS 内核中。核心问题：
 
 1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
 2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
 3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
 4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何保证关键保障负载在人工智能目标负载进入系统后仍拥有明确的中断优先权；
+- 如何把加速器完成中断、DMA 中断和外设中断纳入统一的实时边界分析；
+- 如何让 SylixOS 的中断管理能力成为双目标达标的硬支撑。
+
+因此，这一方向服务的是总课题中的“关键路径实时保障”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+中断管理与实时性保障在 `T5~T1` 中都重要，但关键矛盾不同：
+
+| 部署形态 | 中断保障侧重点 |
+|---|---|
+| `T5` 控制端 | 控制回路、看门狗和安全联锁优先级最高 |
+| `T4` 终端设备 | 传感器、通信与本地 AI 推理中断并存 |
+| `T3` 边缘节点 | 多外设、多链路和加速器完成中断叠加 |
+| `T2` 单机工作站 | GPU/网络/存储中断与关键任务隔离 |
+| `T1` 服务器/集群 | 多队列网络、存储和设备中断亲和治理 |
+
 ## 2. 中断层级设计
 
 ### 2.1 中断优先级映射
@@ -397,7 +419,15 @@ RTOS角色:
   - RTOS保证关键路径上的中断响应
 ```
 
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，中断与实时性机制至少要回答下面三个问题：
+
+1. 关键保障负载在人工智能目标负载并存时，是否仍满足 `deadline miss ratio`、观测最大响应时间和尾部抖动约束；
+2. 加速器完成中断、DMA 中断和外设中断是否形成可分析的干扰上界，并维持可控的中断行为；
+3. 优先级继承、IRQ 亲和和中断屏蔽策略是否降低了关键路径不确定性并形成可分析上界。
+
+## 9. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -408,7 +438,7 @@ RTOS角色:
 | Timer | Tick / Event | **Event** | 降低开销 |
 | IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
 
-## 9. 开放研究问题
+## 10. 开放研究问题
 
 1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
 2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/06-能耗与热管理.md

@@ -2,7 +2,7 @@
 
 ## 1. 问题陈述
 
-边缘/嵌入式设备运行LLM时，能耗和热是硬约束：
+当人工智能目标负载进入任务关键系统后，能耗和热会直接进入实时保障约束：
 
 ```
 LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
@@ -19,6 +19,28 @@ Constraints:
   - Form Factor: Passive cooling (no fan)
 ```
 
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何避免热漂移、降频和功率封顶破坏人工智能目标负载的时效性；
+- 如何避免功耗控制策略反向侵蚀关键保障负载的实时边界；
+- 如何把能耗与热管理纳入 SylixOS 的长期稳定运行机制。
+
+因此，这一方向服务的是总课题中的“长稳运行与热功率边界”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+能耗与热管理在 `T5~T1` 中的表现差异显著，因此需要按部署形态看重点：
+
+| 部署形态 | 能耗与热管理侧重点 |
+|---|---|
+| `T5` 控制端 | 电池/电源预算、深睡眠与快速恢复 |
+| `T4` 终端设备 | 被动散热下的持续推理与温升控制 |
+| `T3` 边缘节点 | 多核+加速器协同下的热热点迁移 |
+| `T2` 单机工作站 | 长时间高负载下的降频与风扇策略 |
+| `T1` 服务器/集群 | 机架功率、PUE 与多设备热耦合 |
+
 ## 2. 能耗模型
 
 ### 2.1 各组件的能耗模型
@@ -439,7 +461,15 @@ Power Monitoring (RTOS Task):
   - 数据中心级功耗管理
 ```
 
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，能耗与热管理至少要回答下面三个问题：
+
+1. 人工智能目标负载在长稳运行下的 `TTFT`、`TPOT` 和吞吐是否因降频与热保护发生持续退化；
+2. 关键保障负载是否会因为 DVFS、休眠唤醒或热限额而出现额外抖动和截止期违约；
+3. 功率与热管理机制是否能把 24 h 稳定性、恢复时间和能效指标变成可测量、可复现的证据。
+
+## 8. 关键设计决策
 
 | 决策点 | 选项 | 推荐 | 理由 |
 |-------|------|-----|------|
@@ -450,7 +480,7 @@ Power Monitoring (RTOS Task):
 | 热感知 | Reactive / Predictive | **Predictive** | 减少延迟抖动 |
 | 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
 
-## 8. 开放研究问题
+## 9. 开放研究问题
 
 1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
 2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/07-方法论与评估工具链.md

@@ -0,0 +1,294 @@
+# 方向7：方法论与评估工具链
+
+## 1. 方法论总框架
+
+本研究的方法论围绕下面这个核心判断展开：
+
+> **在五类部署形态下，大型跨平台实时操作系统在任务关键系统中支撑人工智能目标负载、维持关键保障负载实时边界的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。**
+
+因此，方法论采用 **“准入 → 对照 → 建模 → 机制实现 → 实测验证 → 跨档位分析”** 的闭环。
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Step 1: 平台与测量准入                                  │
+│ - 设备、OS、加速器、模型、计时链路、功率计               │
+├─────────────────────────────────────────────────────────┤
+│ Step 2: 公平对照设计                                    │
+│ - O0 普通 Linux / O1 PREEMPT_RT / O2-O3 SylixOS        │
+├─────────────────────────────────────────────────────────┤
+│ Step 3: 负载建模                                        │
+│ - 人工智能目标负载 / 关键保障负载 / 伴生竞争负载          │
+├─────────────────────────────────────────────────────────┤
+│ Step 4: 机制实现                                        │
+│ - 调度、隔离、内存、中断、准入、能耗与热管理              │
+├─────────────────────────────────────────────────────────┤
+│ Step 5: 实测验证                                        │
+│ - 双目标达标、长稳、恢复、消融、统计显著性                │
+├─────────────────────────────────────────────────────────┤
+│ Step 6: 跨档位分析                                      │
+│ - T5~T1 五类部署形态、11 个代表档位的规律与边界          │
+└─────────────────────────────────────────────────────────┘
+```
+
+## 2. 研究对象、对照对象与验证矩阵
+
+### 2.1 研究对象
+
+主研究对象是：
+
+- **大型跨平台实时操作系统这一类平台**
+- 其中 `SylixOS` 是主实验样例
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本
+- 其实时调度、资源隔离、中断管理、内存管理和恢复机制
+
+### 2.2 对照对象
+
+后续所有实验统一采用三层 OS 对照：
+
+| 编号 | 对照对象 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
+| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
+| `O3` | SylixOS 优化配置 | 主实验样例优化组 |
+
+必要时可增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，容器或虚拟机仅作为部署方式记录，不单独列为新的“内核类别”。
+
+### 2.3 验证矩阵
+
+硬件承担关键验证矩阵角色。
+`T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
+
+这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
+
+对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
+
+- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
+- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
+
+前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
+
+## 3. 负载建模：三类负载
+
+### 3.1 三类负载定义
+
+| 负载类型 | 定义 | 例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
+| 关键保障负载 | 维持任务关键系统边界的核心任务 | 1 ms 控制回路、联锁、状态采集、执行闭环 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、存储、网络 I/O、模型加载 |
+
+### 3.2 建模目标
+
+本研究统一评估三项内容：
+
+1. 人工智能目标负载是否按时并有效地完成；
+2. 关键保障负载是否仍满足截止期与抖动边界；
+3. 系统在两类目标并存时是否保持稳定、可解释和可恢复。
+
+### 3.3 任务图抽象
+
+```
+人工智能目标负载：
+  输入处理 → Prefill / 前处理 → 设备计算 → 输出决策 → 结果返回
+
+关键保障负载：
+  周期释放 → 传感采集 → 控制计算 → 执行输出 → 状态确认
+
+伴生竞争负载：
+  日志写入 / 网络收发 / 模型加载 / 存储 I/O / 管理服务
+```
+
+后续所有调度建模，都围绕这三类负载的竞争关系来分析。
+
+## 4. 评价框架：双目标达标 + 系统协同
+
+### 4.1 人工智能目标负载指标
+
+| 类别 | 指标 |
+|---|---|
+| 时效 | `TTFT`、`TPOT`、端到端响应时间 |
+| 有效性 | 精度、成功率、任务完成率、输出可用性 |
+| 稳定性 | 长时间运行退化、失败率、热漂移影响 |
+
+### 4.2 关键保障负载指标
+
+| 类别 | 指标 |
+|---|---|
+| 截止期 | `deadline miss ratio` |
+| 尾部行为 | `P99/P99.9 jitter`、观测最大响应时间 |
+| 外部接口 | GPIO / CAN / RS485 / 网络回路端到端响应 |
+
+### 4.3 系统协同指标
+
+| 类别 | 指标 |
+|---|---|
+| 效率 | 有效吞吐、拒绝率、恢复时间 |
+| 能效 | `E/token`、`tokens/J`、整机功耗 |
+| 稳定性 | 温度、降频时间比例、24 h 长稳表现 |
+| 公平性 | 多任务 / 多模型并发下的资源分配与隔离效果 |
+
+因此，论文与实验的通过标准应统一为：
+
+> **人工智能目标负载达标 + 关键保障负载达标 + 系统协同稳定。**
+
+## 5. 准入机制
+
+为了保证后续对照具有可信度，所有平台必须通过分阶段准入：
+
+| 门槛 | 核心内容 |
+|---|---|
+| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑正确 |
+| `G1` 测量准入 | 单调时钟、日志、功率计、外部测量链路 |
+| `G2` 加速器准入 | 驱动加载、最小算子、结果回读 |
+| `G3` 模型准入 | 模型转换、加载、推理、释放、重复运行 |
+| `G4` 混合负载准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
+
+任何准入失败都要作为研究记录保留。
+
+对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
+
+## 6. 对照原则
+
+### 6.1 固定不变项
+
+为了保证 OS 对照公平，以下变量必须冻结：
+
+- 模型版本、量化格式、tokenizer、输入长度与输出长度；
+- CPU 核数量、优先级、内存预算、加速器数量；
+- 到达流、随机种子、预热时间、采样窗口；
+- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
+- 环境温度、散热、驱动与框架版本。
+
+### 6.2 允许变化项
+
+允许作为自变量扫描的内容包括：
+
+- OS 类型与配置；
+- 调度策略与核隔离；
+- IRQ 亲和与中断线程化；
+- 内存限额、KV Cache 预分配与准入控制；
+- 功率与频率策略；
+- 并发度、到达率和背景干扰强度。
+
+## 7. 建模与分析方法
+
+### 7.1 可调度性与响应时间分析
+
+关键保障负载优先使用固定优先级与响应时间分析：
+
+```
+R_i^(0) = C_i
+R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
+```
+
+其中：
+
+- `C_i` 为关键保障任务的执行时间；
+- `T_j` 为高优先级任务周期；
+- `R_i` 为响应时间。
+
+人工智能目标负载根据其服务目标与预算，被建模为：
+
+- 可限流的服务任务；
+- 可准入的队列任务；
+- 可隔离的设备任务；
+- 必要时具有阶段性优先级的任务图。
+
+当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
+
+### 7.2 容量与热稳定性分析
+
+对人工智能目标负载，需要同时分析：
+
+- 模型权重占用；
+- KV Cache 增长；
+- 中间激活与工作区；
+- 运行时与驱动保留区；
+- 温度导致的频率变化。
+
+因此，容量与热是实时保障能否成立的前提条件。
+
+### 7.3 消融分析
+
+系统机制收益通过逐项消融来解释，例如：
+
+1. 去掉 CPU 核隔离；
+2. 去掉 IRQ 亲和；
+3. 去掉内存预分配；
+4. 去掉推理准入控制；
+5. 去掉功耗感知策略。
+
+每次只移除一个机制，观察双目标达标边界的变化。
+
+## 8. 工具链
+
+### 8.1 采样与追踪工具
+
+| 类别 | 代表工具 |
+|---|---|
+| OS 追踪 | RTOS trace、ftrace、事件日志 |
+| 性能分析 | perf、设备 profiler、定制采样脚本 |
+| 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
+| 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
+| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
+
+下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
+
+| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
+|---|---|---|---|
+| 人工智能目标负载时效 | `TTFT`、`TPOT`、端到端响应时间 | 应用层时间戳、推理引擎日志、设备 profiler | 判断智能功能是否按服务时限完成 |
+| 人工智能目标负载有效性 | 精度、成功率、任务完成率、输出可用性 | 数据集回放脚本、结果校验脚本、业务判分程序 | 避免只优化时延而牺牲输出质量 |
+| 关键保障负载实时性 | `deadline miss ratio`、观测最大响应时间 | RTOS trace、GPIO 打点、示波器、逻辑分析仪 | 判断关键任务是否仍满足实时边界 |
+| 尾部抖动行为 | `P99/P99.9 jitter`、突发峰值延迟 | 高精度事件日志、外部时序测量、分位统计脚本 | 识别平均值掩盖下的尾部失稳 |
+| CPU 与调度行为 | 核占用、上下文切换、迁核、中断干扰 | perf、ftrace、调度事件日志 | 解释不同 OS 机制下的调度差异 |
+| 内存与容量行为 | 峰值内存、KV Cache 增长、分配失败率 | `/proc`、驱动日志、运行时统计、定制采样脚本 | 判断容量边界与动态分配抖动来源 |
+| 功率与热稳定性 | 整机功耗、芯片温度、降频时间比例 | 外部功率计、PDU、板载传感器、温度记录 | 判断长稳阶段是否因热或供电触发退化 |
+| I/O 与外设链路 | GPIO/CAN/RS485/网络回路时延 | 示波器、总线分析仪、抓包工具 | 验证系统外部闭环而非仅内部线程表现 |
+| 恢复与稳态行为 | 故障恢复时间、重试成功率、24 h 退化曲线 | 守护日志、错误注入脚本、长稳记录程序 | 判断系统是否具备工程可用性 |
+
+### 8.2 理论与仿真工具
+
+| 类别 | 作用 |
+|---|---|
+| RTA / WCET 分析 | 关键保障负载响应时间边界分析 |
+| 抽象仿真框架 | 参数扫描、到达流与机制对比 |
+| 架构级仿真 | 必要时验证拓扑与内存模型假设 |
+
+这里的仿真用于机制理解、参数扫描与拓扑假设验证。
+主线验证平台为 **SylixOS 与其对照系统**。
+
+## 9. 实验流程
+
+统一实验流程如下：
+
+1. 完成 `G0~G4` 准入；
+2. 建立 `O0/O1/O2/O3` 对照组；
+3. 先测空载与仅人工智能目标负载基线；
+4. 再测人工智能目标负载与关键保障负载并存场景；
+5. 加入 CPU / 内存 / I/O / 网络等伴生竞争负载；
+6. 进行长稳、突发、恢复与消融实验；
+7. 进行跨档位和跨部署形态对比。
+
+## 10. 可复现性要求
+
+每次运行至少保存以下元数据：
+
+- 档位、设备编号、OS/BSP/驱动版本；
+- 模型校验值、量化格式、输入模板、随机种子；
+- CPU/IRQ/频率/内存配置；
+- 环境温度、散热方式、测量仪器；
+- 原始延迟、功率、温度与错误日志。
+
+只有满足这些条件，后续论文中的“优势”才具备可外部讨论的基础。
+
+## 11. 本文档在整个仓库中的作用
+
+本文件负责回答三个问题：
+
+1. **怎么保证研究对象始终落在 RTOS 平台层；**
+2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
+3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
+4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
+
+这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md

@@ -0,0 +1,57 @@
+# 研究框架索引
+
+本目录放置项目的核心研究框架文档，分为两部分：
+
+1. **主干机制文档**：作为公共研究材料，沉淀已经形成的主线表达、机制拆解与方法论；
+2. **候选课题框架目录**：并行维护 3 套可讨论、可修改、可优选的课题框架方案。
+
+## 阅读建议
+
+### 1. 主干机制文档
+
+1. `00-整体研究框架.md`
+2. `01-推理图任务调度.md`
+3. `02-KV-Cache与内存管理.md`
+4. `03-加速器协同调度.md`
+5. `04-量化精度感知调度.md`
+6. `05-中断与实时性保障.md`
+7. `06-能耗与热管理.md`
+8. `07-方法论与评估工具链.md`
+
+### 2. 候选课题框架目录
+
+1. `方案A-RTOS平台主导框架/00-课题框架.md`
+2. `方案B-系统协同保障框架/00-课题框架.md`
+3. `方案C-小型化与低功耗应用框架/00-课题框架.md`
+
+## 文件说明
+
+- `00-整体研究框架.md`
+  - 研究总框架、问题空间、技术分层、预期成果
+- `01-推理图任务调度.md`
+  - LLM 推理 DAG 拆解、任务映射与调度策略
+- `02-KV-Cache与内存管理.md`
+  - KV Cache 生命周期、内存池、带宽竞争与局部性
+- `03-加速器协同调度.md`
+  - CPU、NPU、GPU、DMA 等异构资源协同
+- `04-量化精度感知调度.md`
+  - 精度、资源占用和调度决策的联动关系
+- `05-中断与实时性保障.md`
+  - IRQ 路径、线程化、中断隔离与实时任务保护
+- `06-能耗与热管理.md`
+  - 能耗约束、温度耦合、频率策略与热稳定性
+- `07-方法论与评估工具链.md`
+  - 建模、仿真、原型验证和评估方法学
+
+## 候选框架说明
+
+- `方案A-RTOS平台主导框架`
+  - 保持“大型跨平台 RTOS”作为研究主语，适合继续沿现有主线推进
+- `方案B-系统协同保障框架`
+  - 强调 RTOS、运行时、模型与加速器协同治理，适合承接系统级方法学讨论
+- `方案C-小型化与低功耗应用框架`
+  - 强调 `T5/T4` 受限系统与低功耗应用场景，适合形成更聚焦的专题路线
+
+## 使用方式
+
+后续讨论、修改和优选时，可以优先在这 3 个候选目录中推进，不必立即改动主干机制文档。待最终课题框架确定后，再把优选结果回收进 `00-整体研究框架.md` 及相关主干文件。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/01-研究逻辑说明.md

@@ -0,0 +1,178 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
+
+## 1. 文档目的
+
+本文用于解释本目录中的研究逻辑结构，并说明：
+
+- [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) 如何承载完整的 `T5~T1` 五类部署形态与 `11` 个代表档位；
+- [03-实验设计.md](./03-实验设计.md) 如何把这些硬件条件组织成可复现的对照实验；
+- [04-论文写作规划.md](./04-论文写作规划.md) 如何把证据组织成一篇系统化论文。
+
+三份文档承担的职责如下：
+
+| 文档 | 回答的问题 | 在研究中的作用 |
+|---|---|---|
+| [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) | 在哪些部署形态与硬件条件下验证？ | 定义 `T5~T1` 五类部署形态、五种算力基础与十一档实验矩阵 |
+| [03-实验设计.md](./03-实验设计.md) | 如何产生可信、可复现、可比较的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
+| [04-论文写作规划.md](./04-论文写作规划.md) | 如何把这些证据组织成论文贡献？ | 把研究问题、方法、结果和边界映射成论文结构 |
+
+整个研究的主线是：
+
+> **研究对象定义清楚 → 验证矩阵完整展开 → 公平对照与双目标实验 → 数据可复现 → 跨档位规律与边界 → 论文贡献。**
+
+## 2. 研究对象
+
+这个项目的研究对象是：
+
+> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制。**
+
+本目录后续所有实验和文档都围绕下面这条主线展开：
+
+- **研究对象**：大型跨平台实时操作系统这一类平台；
+- **主实验样例**：SylixOS；
+- **外部参照样本**：QNX、VxWorks、INTEGRITY、LynxOS-178；
+- **系统场景**：任务关键系统；
+- **目标负载**：人工智能目标负载；
+- **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
+- **硬件角色**：验证矩阵。
+
+在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
+
+## 3. T5~T1 五类部署形态与 11 个代表档位
+
+硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
+
+1. **验证矩阵**：在不同资源条件下检验同一系统问题是否成立；
+2. **证据组织框架**：把结果放到统一谱系中观察规律与边界；
+3. **产业可解释性**：让不同部署形态都能找到对应的现实位置。
+
+对应关系如下：
+
+| 部署形态 | 主要系统角色 | 主要验证重点 |
+|---|---|---|
+| `T5` 控制端 | 极紧资源预算下的任务关键控制节点 | 强实时、极小内存、低功耗边界 |
+| `T4` 设备端 SoC | 设备本体内的统一内存异构平台 | CPU/NPU/GPU 共享资源与带宽隔离 |
+| `T3` 边缘节点 | 设备附近的近源推理节点 | 多任务并发、热稳定性、边缘协同 |
+| `T2` 桌面 / 工作站单机 | 单机高密本地推理平台 | 单机多卡调度、NVLink/PCIe 拓扑、公平性 |
+| `T1` 服务器 / 集群 | 多节点大模型服务平台 | 跨节点通信、分布式调度、规模扩展 |
+
+`T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
+`T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
+
+其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
+
+## 4. 人工智能目标负载与系统负载结构
+
+在任务关键系统里，负载应至少分成三类：
+
+| 负载类型 | 定义 | 例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
+| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、联锁、状态采集、执行输出 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、后台通信、模型加载、I/O |
+
+本项目重点评估的是：
+
+> **RTOS 协调人工智能目标负载与关键保障负载时，对系统边界的维持能力与成立条件。**
+
+这一步会直接影响实验设计、论文结构和评价指标。
+
+## 5. 准入与对照的实验顺序
+
+本项目采用分阶段准入机制：
+
+| 门槛 | 核心检查内容 |
+|---|---|
+| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑 |
+| `G1` 测量准入 | 单调时钟、日志、外部测量链路、功率计 |
+| `G2` 加速器准入 | CUDA / RKLLM / RKNN / 驱动 / 最小算子 |
+| `G3` 模型准入 | 模型转换、加载、正确推理与峰值内存 |
+| `G4` 混合场景准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
+
+只有通过 `G4` 的平台与配置，才能进入正式对照。
+
+## 6. O0~O4 对照组结构
+
+主对照统一采用：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
+| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
+| `O3` | SylixOS 优化配置 | 主实验组 |
+
+必要时增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，并继续保持“普通 Linux”和“实时增强 Linux”的对照边界。
+
+## 7. 实验逻辑如何展开
+
+实验逻辑遵循从简单到复杂、从单目标到双目标的顺序：
+
+1. 先确认平台、模型与测量链路可用；
+2. 再测仅人工智能目标负载的基线表现；
+3. 再测仅关键保障负载的下界行为；
+4. 再测两者并存的核心场景；
+5. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
+
+这条顺序用于区分平台就绪性问题与系统机制边界问题。
+
+对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
+
+## 8. 哪些指标构成核心证据
+
+后续证据链必须覆盖三层：
+
+### 8.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 成功率、任务质量、输出可用性
+- 长时间运行稳定性
+
+### 8.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 8.3 系统协同层
+
+- 有效吞吐
+- `E/token`
+- 温度、降频和热漂移
+- 多任务公平性
+- 恢复能力与 24 h 长稳表现
+
+项目最终形成的核心判断是：
+
+> **在双目标约束下，RTOS 对系统稳定性、可预测性与可保障性的提升边界。**
+
+## 9. 数据如何转化为论文贡献
+
+论文贡献排序如下：
+
+| 贡献 | 所需证据 | 对应论文位置 |
+|---|---|---|
+| `C1` RTOS 对人工智能目标负载与关键保障负载的实时保障优势 | 双目标达标、尾部行为、有效吞吐与恢复结果 | 第1、4、5、7、8章 |
+| `C2` T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵 | 跨档位容量、功耗、拓扑与边界分析 | 第3、7、8章 |
+| `C3` 可复现的方法论与基准对齐 | 准入、元数据、第三方基准复现、消融与统计口径 | 第5、7、9章 |
+
+在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
+
+面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
+
+## 10. 最终闭环
+
+本研究形成的核心结论关系是：
+
+> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
+
+在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
+
+- 研究对象清楚；
+- 验证矩阵完整；
+- 对照关系公平；
+- 评价框架统一；
+- 论文叙事和产业叙事都能站住。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md

@@ -1,57 +1,82 @@
-# 基础设备配置（四层级 × 三档算力分级）
+# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
 
-> 版本: v2.0    起草日期: 2026-09-18  
-> 设计目标: 为翼辉 SylixOS 调度框架研究建立 **集群→桌面→边→端** 四级硬件体系，每级内再按 **低/中/高** 三档细分  
-> 现有硬件全覆盖: T2-L（4×V100 SXM）+ T3-L / T4-H（RK3588 工业盒）| 需新增: T1 集群扩展 + 其余档位
+> 版本: v2.1    起草日期: 2026-09-21
+> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
+> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
+> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
 
 ---
 
-## 0. 分级体系总览
+## 0. 场景、算力基础与设备档位总览
 
-### 0.1 分级维度与分档规则
+### 0.1 研究框架与设备谱系的对应关系
 
-**分级维度**: 以「统一内存 / 显存容量」为第一分类维度——容量直接决定可承载的模型规模，且与功耗、散热、互联架构强相关，四个层级可连续衔接、无断层。
+研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
+本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
+这里完整呈现硬件与指标颗粒度，并明确：
+
+> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
+
+| 研究维度 | 定义 | 在本文件中的落地方式 |
+|---|---|---|
+| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
+| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
+| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
+
+`T5~T1` 是用于实验组织的**部署形态代码**。
+这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
+后续实验中，这些档位分别承担的是：
+
+- 人工智能目标负载在不同资源条件下的时效与有效性验证；
+- 关键保障负载在不同资源条件下的边界验证；
+- RTOS 在双目标约束下的机制有效性验证。
+
+### 0.2 分级维度与分档规则
+
+**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
 
 **分档规则**: 相邻两档的边界值归入**上界一侧**
 
-| 层级       | 代码  | 低级              | 中级               | 高级               |
+| 部署形态 | 代码  | 代表档位              | 容量范围               | 说明               |
 | -------- | --- | --------------- | ---------------- | ---------------- |
-| **端级**   | 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**      |
+| **T5 控制端场景**   | T5  | **T5-L / T5-M / T5-H** | **1~8 G**        | 运行在控制器或轻量控制盒本体 |
+| **T4 设备端 SoC 场景**   | T4  | **T4-L / T4-M** | **8~32 G**      | 运行在设备本体 SoC 上 |
+| **T3 边缘节点场景**  | T3  | **T3-L**    | **32~64 G / 48 G 独显**    | 运行在设备附近的边缘节点 |
+| **T2 桌面/工作站单机场景**  | T2  | **T2-L / T2-M / T2-H**    | **64~512 G**    | 研发或本地服务用单机多卡 |
+| **T1 服务器/集群场景**  | T1  | **T1-L / T1-H**   | **512 G~2 T**          | 多节点分布式推理 |
 
-> 边界值归属示例: 8 GB → 端-高；16 GB → 边-低；64 GB → 边-高；128 GB → 桌-低；512 GB → 桌-高；1 TB → 集-低。
+> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
 
-### 0.2 全谱系总表（11 个档位）
+### 0.3 全谱系总表（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 |  |
+| **T5-L** | 1~2 G        | 0.8~1 TOPS (INT8)          | 3~5 W         | ARM A55 + 小 NPU；DC 5V/12V 被动散热      | RK3568 1~2GB 核心板              |     |
+| **T5-M** | 2~4 G        | 6 TOPS (INT8)              | 5~10 W        | ARM A72+A53 + NPU；DC 12V 被动散热       | RK3576 4GB                    |    |
+| **T5-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 板降配） |
+| **T4-L** | 8~16 G       | 32~100 TOPS (INT8)         | 10~30 W       | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB |  现有     |
+| **T4-M** | 16~32 G      | 275 TOPS (INT8)            | 15~60 W       | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB          |      |
+| **T3-L** | 32~64 G / 48 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 设计原则
+### 0.4 设计原则
 
-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），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
+1. **部署形态先行、设备落地**: 先用“控制端 / 设备端 SoC / 边缘节点 / 桌面工作站 / 服务器集群”定义研究问题，再用 `T5~T1` 设备档位组织具体实验。
+2. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
+3. **CUDA 栈贯通高算力侧**: T1/T2/T3 的候选平台可共享 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位迁移，主要变化是规模与拓扑。
+4. **非 CUDA 控制端与设备端路线**: T5 全档位与 T4-L 走 RKNN/RKLLM NPU 栈，代表最强资源约束与最接近设备本体的运行位置。
+5. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T4-L 16GB / T5-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
+6. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2/T3-B 路线）与 ARM64（T5/T4/T3-A 路线），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
 
 ---
 
-## T1. 集群级 — 512 G ~ 2 T
+## T1. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
 
 ### T1.1 定位
 
@@ -59,7 +84,7 @@
 
 ### T1.2 档位对比
 
-| 维度          | T1-L 集群-低              | T1-H 集群-高                    |
+| 维度          | T1-L 多节点-低              | T1-H 多节点-高                    |
 | ----------- | --------------------- | --------------------------- |
 | **容量**      | 512 GB（4 × 128 GB）    | 1.28 TB（4 × 320 GB）         |
 | **节点数**     | 4 节点                  | 4 节点                        |
@@ -71,11 +96,11 @@
 | **散热架构**    | 每节点 360 液冷 + 机房风冷      | 机房级液冷（CDU / 后门换热器）           |
 | **主要模型**    | 72B FP16 / 多实例 14B     | 671B INT4 / 多实例 72B FP16     |
 
-#### T1.2.1 T1-L 集群-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
+#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
 
 | 项目        | 规格                                               | 数量            | 备注                          |
 | --------- | ------------------------------------------------ | ------------- | --------------------------- |
-| **计算节点**  | 同 T2-L 桌面级配置                                      | **4 台**       | 每节点 4×V100 32GB SXM = 128GB |
+| **计算节点**  | 同 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                   |
@@ -107,11 +132,11 @@
 
 > 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
 
-#### T1.2.2 T1-H 集群-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
+#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
 
 | 项目      | 规格                                        | 数量        | 备注                    |
 | ------- | ----------------------------------------- | --------- | --------------------- |
-| 计算节点    | 同 T2-H 桌面级配置                               | 4 台       | 每节点 4×H100 80GB SXM5  |
+| 计算节点    | 同 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            |
@@ -150,7 +175,7 @@
 
 ---
 
-## T2. 桌面级 — 64 G ~ 512 G
+## T2. 高算力单机部署形态 — 64 G ~ 512 G
 
 ### T2.1 定位
 
@@ -158,7 +183,7 @@
 
 ### T2.2 档位对比
 
-| 维度          | T2-L 桌面-低               | T2-M 桌面-中                    | T2-H 桌面-高                    |
+| 维度          | 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          |
@@ -171,7 +196,7 @@
 | **可运行模型**   | 72B INT4 / 14B FP16    | 72B FP16 / 多实例 32B          | 671B INT4 / 72B FP16 多并发    |
 | **状态**      |  现有                   | 需扩展（现有平台加卡）                 | 需                        |
 
-#### T2.2.1 T2-L 桌面-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
+#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
 
 | #  | 部件      | 型号 / 规格                                        | 数量    | 备注                          |
 | -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
@@ -213,7 +238,7 @@
 | 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.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
 
 在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
 
@@ -241,7 +266,7 @@
 
 > **备选方案**: 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
+#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
 
 | 项目      | 规格                                       |
 | ------- | ---------------------------------------- |
@@ -287,41 +312,72 @@
 
 ---
 
-## T3. 边级 — 8 G ~ 64 G
+## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
 
 ### T3.1 定位
 
-边缘 AI 推理与工业控制并发。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性——推理任务与实时控制任务共享内存带宽时的隔离能力。
+边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。  
+它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
 
-### T3.2 档位对比
+### 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-L 边缘节点代表档 |
+| --------- | ---------------- |
+| **容量**    | 64 GB 统一内存 / 48 GB 独立显存 |
+| **加速器**   | Jetson AGX Orin 64GB / RTX 6000 Ada 48GB |
+| **算力**    | 275 TOPS (INT8) / 91 TFLOPS (FP16) |
+| **功耗**    | 15~60 W / ~600 W |
+| **部署位置**  | 设备附近机柜、边缘控制室、产线边缘节点 |
+| **主要任务**  | 多模态推理、近源协同、边缘缓存与调度 |
 
-#### T3.2.1 T3-L 边-低 — RK3588 16GB 工业盒（现有设备）
+### T3.3 候选平台
 
-**这是现有 RK3588 设备的标准归属档位**（16 GB 统一内存落在边级区间内），也是唯一可零成本立即开展研究的边级档位。
+- Jetson AGX Orin 64GB：统一内存、能效高，适合近设备部署；
+- 边缘工控机 + RTX 6000 Ada 48GB：生态完整，适合边缘机柜和算力下沉场景。
+
+### T3.4 研究重点
+
+- 设备端到边缘节点的协同调度；
+- 近源多任务并发下的实时隔离；
+- 边缘节点与桌面/工作站单机在功耗、散热和部署约束上的边界。
+
+---
+
+## T4. 设备端 SoC 场景 — 8 G ~ 32 G
+
+### T4.1 定位
+
+设备端 SoC 直接运行在终端设备本体上。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性，即推理任务与实时控制任务共享本机资源时的隔离能力。
+
+### T4.2 档位对比
+
+| 维度        | T4-L SoC-低                      | T4-M SoC-中                    |
+| --------- | ---------------------------- | -------------------------- |
+| **容量**    | 16 GB 统一内存                  | 32 GB 统一内存                |
+| **加速器**   | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA         |
+| **算力**    | 32 TOPS / 100 TOPS (INT8)    | 275 TOPS (INT8)            |
+| **功耗**    | 10~30 W                      | 15~60 W                    |
+| **供电架构**  | DC 12~24 V，无风扇/小风扇           | DC 19 V，主动风冷               |
+| **工作温度**  | -40~60 ℃ 工业级                | -25~80 ℃                   |
+| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T5）     | **高**（T234 BSP 需验证）        |
+| **状态**    | （RK3588 16GB 工业盒）            | 待验证                        |
+
+#### T4.2.1 T4-L SoC-低 — RK3588 16GB 工业盒（现有设备）
+
+**这是现有 RK3588 设备的标准归属档位**，也是唯一可零成本立即开展研究的设备端 SoC 档位。
 
 | 项目        | 规格                                      | 备注                    |
 | --------- | --------------------------------------- | --------------------- |
-| SoC       | Rockchip RK3588（同 T4-H）                 | SylixOS BSP 与 T4 共用   |
+| SoC       | Rockchip RK3588（同 T5-H）                 | SylixOS BSP 与 T5 共用   |
 | 内存        | **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 内存翻倍，可跑更大模型     |
+| 内存带宽      | ~51.2 GB/s (128-bit LPDDR4X)            | 与 T5-H 同源，是带宽瓶颈点      |
+| 模型        | Qwen2.5-3B/7B INT4（RKLLM）               | 比 T5-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 风险高。
+**备选方案（同档位、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/T3 打通**。代价是 SylixOS T234 BSP 风险高。
 
-#### T3.2.2 T3-M 边-中 — NVIDIA Jetson AGX Orin 32GB
+#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
 
 | 项目        | 规格                                                 |
 | --------- | -------------------------------------------------- |
@@ -352,76 +408,64 @@
 4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
 5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
 
-#### T3.2.3 T3-H 边-高 — 64 GB 档（两条路线）
+#### T3 边缘节点候选平台
 
-| 路线         | 主推 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，带宽受限          | 功耗/体积/散热不适合现场部署                  |
-| **适用场景**   | 边缘现场、宽温环境、低功耗                | 边缘机柜、算力下沉、多模型并发                 |
+64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
 
-**可运行模型（T3 三档合并）**
+**可运行模型（T4 两档合并）**
 
 | 模型                       | 量化           | 显存占用    | 预期 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          |
+| **Qwen2.5-1.5B-Instruct** | INT4         | ~1.2 GB | ~40-60      | T4-L          | RKLLM                    |
+| **Qwen2.5-3B-Instruct**  | INT4         | ~2.5 GB | ~50-80      | T4-L / T4-M   | TensorRT-LLM / RKLLM     |
+| **Qwen2.5-7B-Instruct**  | INT4 (W4A16) | ~5 GB   | ~30-50      | T4-L / T4-M   | TensorRT-LLM / llama.cpp |
+| **Qwen2.5-14B-Instruct** | INT4         | ~8 GB   | ~20-35      | T4-M          | TensorRT-LLM             |
+| **Qwen2.5-32B-Instruct** | INT4         | ~18 GB  | ~12-20      | T4-M          | TensorRT-LLM             |
+| MiniCPM-V 2.6            | INT4         | ~6 GB   | ~15-25      | T4-L 以上       | llama.cpp                |
+| Whisper-Large-v3         | INT8/FP16    | ~1.5 GB | 流式 ASR       | T4-L 以上       | faster-whisper           |
+| YOLOv8n                  | INT8         | ~0.1 GB | 200+ FPS    | T4 全档         | TensorRT / RKNN          |
 
-### T3.3 SylixOS 要求（T3）
+### T4.3 SylixOS 要求（T4）
 
 | 要求项                  | 描述                                      | 风险                           |
 | -------------------- | --------------------------------------- | ---------------------------- |
 | **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
-| **RK3588 BSP（T3-L）** | 与 T4-H 共用同一 BSP，零额外风险                    | **极低**                        |
+| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险                    | **极低**                        |
 | CUDA 驱动              | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配     | 高                            |
 | DLA 驱动               | DLA 异步推理在 SylixOS 的可用性                  | 高                            |
 | 功率模式 API             | 15W/30W/50W/60W 切换在 SylixOS 的实现         | 中                            |
 | 内存监控                 | 统一内存架构下的内存带宽监控（PMU 计数器）                 | 中                            |
-| 独立显存管理（T3-H B 路线）     | x86 + 独显的显存分配与实时性                        | 中                            |
+| 独立显存管理（T3 B 路线）     | x86 + 独显的显存分配与实时性                        | 中                            |
 
-> **取舍**: Jetson 路线优势在 CUDA 生态统一 + 275 TOPS + DLA；RK3588-16GB（T3-L）优势在 SylixOS BSP 风险极低 + -40~60℃ 工业级宽温。**建议 T3-L 直接用现有 RK3588 起步，T3-M/H 待 Jetson BSP 确认后再采购。**
+> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
 
-### T3.4 对照组 OS
+### T4.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                  |
+| T4-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
+| T4-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案）  |
 
-### T3.5 功率采集
+### T4.5 功率采集
 
 | 设备                            | 用途                    | 适用档位        |
 | ----------------------------- | --------------------- | ----------- |
-| DC 功率计（USB 接口型）               | 整机 DC 输入端功耗           | T3-L / T3-M |
+| DC 功率计（USB 接口型）               | 整机 DC 输入端功耗           | T4-L / T4-M |
 | INA226 采集板                    | SoC 主电源轨（若可接入）        | 全档          |
-| `jetson_stats` / tegrastats   | 内部功耗代理（辅助，非主报）        | T3-M / T3-H |
-| 交流功率计（PZEM / 智能插座）            | 边缘工控机整机功耗             | T3-H B 路线   |
+| `jetson_stats` / tegrastats   | 内部功耗代理（辅助，非主报）        | T4-M / T3-L |
+| 交流功率计（PZEM / 智能插座）            | 边缘工控机整机功耗             | T3-L B 路线   |
 
 ---
 
-## T4. 端级 — 1 G ~ 8 G
+## T5. 控制端场景 — 1 G ~ 8 G
 
-### T4.1 定位
+### T5.1 定位
 
-工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这是 RTOS 杀手锏场景——资源越紧张，RTOS 调度隔离的价值越大。
+工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
 
-### T4.2 档位对比
+### T5.2 档位对比
 
-| 维度          | T4-L 端-低                | T4-M 端-中              | T4-H 端-高                        |
+| 维度          | T5-L 控制端-低                | T5-M 控制端-中              | T5-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 |
@@ -433,7 +477,7 @@
 | **可运行模型**   | 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）
+#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
 
 | 项目        | 规格                                     |
 | --------- | -------------------------------------- |
@@ -452,9 +496,9 @@
 | 参考价格      | ~300~800 RMB（核心板/开发板）                  |
 
 **可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
-**定位价值**: 谱系最低档，用于测出「LLM 推理到底能把实时性压到多差」的**下界**，以及 RTOS 在极小内存下能否守住 1ms。
+**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
 
-#### T4.2.2 T4-M 端-中 — RK3576 核心板（2~4 GB）
+#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
 
 | 项目        | 规格                                       |
 | --------- | ---------------------------------------- |
@@ -468,9 +512,9 @@
 | 参考价格      | ~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 倍而功耗仅翻倍，是**能效拐点**档位。
+**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
 
-#### T4.2.3 T4-H 端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
+#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
 
 **路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
 
@@ -482,12 +526,12 @@
 | 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 同                     |
+| 内存带宽      | ~51.2 GB/s (128-bit)                                | 与 T4-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 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
+> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
 
 **路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
 
@@ -497,11 +541,11 @@
 | **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 同栈 |
+| 优势        | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
 | 劣势        | SylixOS T234 BSP 风险高，宽温不如 RK3588                   |
 | 参考价格      | ~$249（开发套件）                                         |
 
-**可运行模型（T4-H）**
+**可运行模型（T5-H）**
 
 | 模型                        | 量化   | 显存占用    | 预期 tokens/s | 推理框架  |
 | ------------------------- | ---- | ------- | ----------- | ----- |
@@ -510,7 +554,7 @@
 | MiniCPM-V 2.6             | INT4 | ~6 GB   | ~15-25      | RKLLM |
 | Whisper-Large-v3          | INT8 | ~1.5 GB | 流式 ASR       | RKLLM |
 
-#### T4.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
+#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
 
 **系统 (System)**
 
@@ -521,7 +565,7 @@
 | MCU     | Cortex-M0 @200 MHz（协处理，可选）                           |
 | GPU     | Mali-G610 MC4                                        |
 | **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
-| **内存**  | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T4-H       |
+| **内存**  | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H       |
 | **显存**  | 统一内存（NPU 与 CPU 共享）                                   |
 
 **存储 / 扩展**
@@ -533,9 +577,9 @@
 **出厂软件**
 
 - 操作系统: **Ubuntu 22.04**（出厂预装）
-- 验证方案: 替换为 SylixOS BSP for RK3588，保留 Ubuntu 22.04 作为对照组
+- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
 
-**算力与功耗（T4-H 档）**
+**算力与功耗（T5-H 档）**
 
 | 指标                 | 值                               |
 | ------------------ | ------------------------------- |
@@ -546,28 +590,28 @@
 | 内存带宽               | LPDDR4X ~51.2 GB/s (128-bit)    |
 | **TDP**            | **7~21 W**（无风扇被动散热）              |
 
-### T4.3 SylixOS 要求（T4）
+### T5.3 SylixOS 要求（T5）
 
 | 要求项                    | 描述                                      | 风险                   | 适用档位      |
 | ---------------------- | --------------------------------------- | -------------------- | --------- |
-| **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  |
+| **RK3588 BSP**         | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供）             | T5-H      |
+| **RK3576 BSP**         | SylixOS BSP for RK3576                  | 中-高（需翼辉确认）           | T5-M      |
+| **RK3568 BSP**         | SylixOS BSP for RK3568                  | 中（RK3568 生态成熟，风险低于 T234） | T5-L      |
+| **rknn / RKLLM 驱动**     | NPU 驱动在 SylixOS 移植                      | **高**（平台B 模型适配核心风险）  | T5 全档     |
+| 板贴 26 TOPS 算力芯片驱动       | 算力棒 SDK                                 | 高（厂商支持度）             | T5-H      |
+| M0 核 BSP + RPMsg        | 跨核通信                                    | 高（需翼辉 + 板卡引出 M0 调试口）  | T5-H      |
+| **内存分区限额机制**            | 16 GB 板按 8 GB 分区运行（T4-L/T5-H 切换）          | 中（需 SylixOS 内存域支持）    | T5-H      |
+| CAN ×2 驱动              | 工业现场总线                                  | 中                    | T5 全档     |
+| RS485 ×2 + RS232 ×1    | 串口                                      | 低                    | T5 全档     |
+| 双千兆 + WiFi + 4G/5G     | 网络                                      | 中                    | T5-H      |
+| 看门狗 / RTC              | 工业可靠性                                   | 低                    | T5 全档     |
+| Jetson Orin Nano BSP   | T234 低配版 BSP（路线 B）                       | 高                    | T5-H 路线B  |
 
-### T4.4 对照组 OS
+### T5.4 对照组 OS
 
 - **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
 - **辅助对照**: OpenHarmony 4.x + RT patch（可选）
-- T4-L / T4-M: Buildroot + PREEMPT_RT
+- T5-L / T5-M: Buildroot + PREEMPT_RT
 
 ---
 
@@ -577,12 +621,12 @@
 
 | 档位       | 容量         | 算力                  | 功耗          | 加速器架构              | 散热架构        | 互联               | 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     | 高 / 中         |
+| **T5-L** | 1~2 GB     | 0.8~1 TOPS          | 3~5 W       | ARM A55 + NPU      | 被动无风扇       | GPIO/CAN/RS485   | 中            |
+| **T5-M** | 2~4 GB     | 6 TOPS              | 5~10 W      | ARM A72+A53 + NPU  | 被动无风扇       | 千兆 + CAN        | 中-高          |
+| **T5-H** | 4~8 GB     | 6~32 TOPS           | 7~21 W      | ARM A76+A55+M0+NPU | 被动无风扇       | 双千兆 + CAN + M.2  | 中 / 高（路线B）    |
+| **T4-L** | 8~16 GB    | 32~100 TOPS         | 10~30 W     | ARM 统一内存 + NPU/GPU | 被动/小风扇      | 双千兆 + M.2        | **极低**（现有）    |
+| **T4-M** | 16~32 GB   | 275 TOPS            | 15~60 W     | A78AE + Ampere + DLA | 主动风冷        | 10GbE + PCIe Gen4 | **高**         |
+| **T3-L** | 32~64 GB / 48 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    | 中             |
@@ -593,12 +637,12 @@
 
 | 档位       | 代表模型                        | 量化         | 显存占用    | 角色             |
 | -------- | --------------------------- | ---------- | ------- | -------------- |
-| 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       |
+| T5-L     | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8  | 0.5 GB  | 控制端最低资源参考档，实时性基准     |
+| T5-M     | Qwen2.5-1.5B                | INT4       | 1.2 GB  | 控制端能效拐点       |
+| T5-H     | Qwen2.5-3B / 7B             | INT4       | 2.5 / 5 GB | 端点可跑 7B        |
+| T4-L     | Qwen2.5-3B / 7B             | INT4       | 2.5 / 5 GB | 设备端推理 + 工业控制    |
+| T4-M     | Qwen2.5-14B / 32B           | INT4       | 8 / 18 GB | 设备端多模型并发        |
+| T3-L     | 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 | 桌面单机超大模型       |
@@ -609,12 +653,12 @@
 
 | 档位    | 验证重点        | 核心实时指标                             | 核心吞吐指标                     |
 | ----- | ----------- | ---------------------------------- | -------------------------- |
-| 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  |
+| T5-L  | 极小内存下保持关键保障负载边界     | 1ms RT 任务延迟（1GB 内存约束下）              | 0.5B tokens/s、内存占用上限       |
+| T5-M  | 能效拐点        | 1ms RT 任务 P99.9、CPU 频率调节影响          | 1.5B tokens/s、E_per_token   |
+| T5-H  | 极致资源约束下保持关键保障负载边界   | **1ms RT 任务最大延迟 + CAN/RS485 延迟**   | 3B/7B tokens/s、E_per_token  |
+| T4-L  | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s            |
+| T4-M  | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9         | 14B tokens/s、DLA 异步收益      |
+| T3-L  | 大容量边缘并发     | 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 分片吞吐    |
@@ -623,14 +667,14 @@
 
 ### 5.4 基线 OS 对照
 
-| 档位      | SylixOS 实验组            | 主对照 (Linux RT)         | 虚拟化对照          | 容器对照      |
+| 档位      | SylixOS 实验组            | 主对照 (PREEMPT_RT Linux) | 虚拟化对照          | 容器对照      |
 | ------- | ---------------------- | --------------------- | -------------- | --------- |
-| 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    |
+| T5-L    | SylixOS ARM64 (RK3568) | Buildroot + RT        | —              | Docker    |
+| T5-M    | SylixOS ARM64 (RK3576) | Buildroot + RT        | —              | Docker    |
+| T5-H    | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT     | KVM (RT VM)    | Docker    |
+| T4-L    | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT     | KVM (RT VM)    | Docker    |
+| T4-M    | SylixOS ARM64 (T234)   | L4T Ubuntu 20.04 + RT | KVM (RT VM)    | Docker    |
+| T3-L    | 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 |
@@ -642,22 +686,22 @@
 
 | 优先级    | 档位      | 设备                            | 估算费用 (RMB)           | 备注                     |
 | ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
-| **P0** | T3-L    | **RK3588 16GB 工业盒**（现有）        | **0**                | 现有设备，立即可用              |
+| **P0** | T4-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 路线对照              |
+| **P0** | T5-H    | **RK3588 工业盒 8GB 分区**（现有）      | **0**                | 与 T4-L 同机双档位            |
+| **P1** | T5-L    | RK3568 1~2GB 核心板               | ~300-800             | 控制端最低资源参考档，必做                |
+| **P1** | T5-M    | RK3576 4GB 核心板                | ~600-1,500           | 控制端能效拐点               |
+| **P1** | T4-M    | Jetson AGX Orin 32GB          | ~15,000-28,000       | 需尽早确认 SylixOS T234 BSP |
+| **P2** | T4-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000         | 若 Jetson BSP 不支持       |
+| **P2** | T3-L    | Jetson AGX Orin 64GB          | ~30,000-50,000       | 边缘节点可跑 72B               |
+| **P2** | T5-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 档            |
+| —      | 仪器      | DC 功率计 ×2 (T4+T5)             | ~6,000               | T5 强制                  |
+| —      | 仪器      | INA226 采集板 ×2                 | ~500                 | T4+T5                  |
+| —      | 仪器      | 交流功率计 / 智能插座                  | ~1,000               | T3 / T2 档            |
 | —      | 仪器      | 示波器 (Tektronix MDO34)         | ~30,000              | GPIO 环回延迟（可借用）         |
 | —      | 仪器      | 红外测温枪 ×2                      | ~1,000               | 被动散热档位                 |
 | —      | 仪器      | CANalyzer                     | ~20,000              | T4 CAN 总线延迟（可借用）       |
@@ -665,11 +709,11 @@
 
 ### 降本策略
 
-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 降配替代），谱系不断。
+1. **P0 零成本起步**: T2-L + T4-L + T5-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
+2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T4-L（16 GB）与 T5-H（8 GB），省去一台设备与一套 BSP 验证成本。
+3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T5-M 若 RK3576 BSP 不可用，用 T5-H 降配替代），谱系不断。
 4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
-5. **T3-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
+5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
 6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
 
 ---
@@ -693,7 +737,7 @@
 - [ ] tickless + CPU 隔离 + 中断亲和性
 - [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
 
-### 7.2 ARM64 BSP — T234 / Ampere（T3-M / T3-H-A / T4-H 路线B）
+### 7.2 ARM64 BSP — T234 / Ampere（T4-M / T3-L-A / T5-H 路线B）
 
 - [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
 - [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
@@ -706,11 +750,11 @@
 - [ ] PCIe Gen4 扩展
 - [ ] 温度传感器 + 降频阈值
 
-### 7.3 ARM64 BSP — RK3588（T4-H / T3-L）
+### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
 
 - [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
 - [ ] CPU 频率独立调节 (governor)
-- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T3-L ↔ T4-H 切换）
+- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
 - [ ] tickless / idle hook
 - [ ] 看门狗驱动
 - [ ] **rknn / RKLLM NPU 驱动**（核心）
@@ -723,7 +767,7 @@
 - [ ] HDMI 输出（调试）
 - [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
 
-### 7.4 ARM64 BSP — RK3576（T4-M）
+### 7.4 ARM64 BSP — RK3576（T5-M）
 
 - [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
 - [ ] 6 TOPS NPU 驱动（RKNN 栈）
@@ -731,7 +775,7 @@
 - [ ] CAN / RS485 / 千兆网络驱动
 - [ ] 低功耗被动散热下的频率/温度联动
 
-### 7.5 ARM64 BSP — RK3568（T4-L）
+### 7.5 ARM64 BSP — RK3568（T5-L）
 
 - [ ] SylixOS BSP for RK3568（4×A55 SMP）
 - [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md

@@ -1,43 +1,51 @@
-# SylixOS 混合实时任务与 AI 推理实验设计
+# SylixOS 任务关键系统中人工智能目标负载实验设计
 
-> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](../基础设备.md)，扩展自[原实验设计](../实验设计.md)。
-> 本文给出待执行方案，不代表已有测试结果。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
+> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
+> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
 
 ## 1. 研究目标与实验范围
 
-研究问题是：在端、边、桌面、集群不同资源条件下，SylixOS 的调度与资源隔离能否在保持实时任务截止期的同时，提高 AI 推理服务的有效吞吐和能效？
+本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
 
 | 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
 |---|---|---|---|
-| RQ1：混合负载下的实时性 | OS、调度策略、干扰强度 | 唤醒延迟、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
-| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | P99.9 延迟、有效吞吐、拒绝率 | 默认、完整方案与逐项消融 |
-| RQ3：功耗预算下的运行能力 | 频率、空闲策略、推理并发 | J/token、温度、违约率 | 满足同一服务质量约束的配置比较 |
-| RQ4：规模扩展后的瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
+| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
+| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
+| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
+| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
 
-执行分为两层：**核心实验使用现有 T2-L、T3-L 和 T4-H 内存受限配置；其他八档属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM 是主负载，YOLO 检测和语音识别是可选混合负载；训练不纳入主实验。
+执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
+
+这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
+
+在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
 
 ## 2. 设备分层与实验平台
 
-### 2.1 四层级、十一档实验映射
+### 2.1 T5~T1 五类部署形态、十一档实验映射
 
-沿用设备文档的档位标签，实际容量单列。设备文档中“512 GB 边界归桌面高档”与“512 GB 集群标为 T1-L”存在口径差异；本文按多节点架构将该集群记为 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 | 二选一，分别标识架构 | 大模型并发与容量上限 |
+| T5-L 控制端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
+| T5-M 控制端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
+| T5-H 控制端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
+| T4-L 设备端 SoC 低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
+| T4-M 设备端 SoC 中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
+| T3-L 边缘节点代表档 | 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 | 远期扩展 | 大模型分布式服务与能效 |
+| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
+| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |
 
 GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
 
+`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
+
+其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
+
 ### 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。
@@ -50,9 +58,9 @@ GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一
 
 依设备清单采用 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。
+- B16：全量 16 GB，记为 T4-L。
+- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
+- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
 - 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
 
 **内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
@@ -81,9 +89,11 @@ GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一
 | G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
 | G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
 
-SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用。设备文档列出的软件栈均按候选路线处理，冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后再比较。
+SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
 
-若仅能采用“SylixOS 实时域 + Linux 推理域”，应作为单独的异构系统架构组，注明核分配、通信和内存共享方式。该结果不能写成 SylixOS 原生 GPU/NPU 推理结论。
+“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
+
+对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
 
 ### 3.2 模型梯度与用途
 
@@ -96,7 +106,7 @@ SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用
 | T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
 | T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
 
-模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。原稿中的 tokens/s、FPS、内存估计作为待验证参考，不作为已知性能。
+模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
 
 ### 3.3 输入与正确性控制
 
@@ -150,10 +160,10 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
 | O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
 | O2 | SylixOS 默认配置 | 原生系统基线 |
 | O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
-| O4 | Linux RT 等预算调优 | 避免仅一侧调优造成偏差 |
+| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
 | O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
 
-平台 B 原稿列出的出厂 Ubuntu 22.04 先核对镜像；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，明确区分“OS 调度效应”与“系统方案效应”。
+平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
 
 ### 5.2 配置控制与消融
 
@@ -169,20 +179,20 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
 
 任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
 
-### 6.2 背景干扰与推理到达
+### 6.2 伴生竞争负载与推理到达
 
 | 场景 | 内容 | 目的 |
 |---|---|---|
-| L0 | 仅 RT | 实时性下界与测量开销 |
-| L1 | 仅推理 | 最大可持续服务能力与独立能耗 |
-| L2 | RT + LLM | 核心混合场景 |
-| L3 | L2 + CPU 干扰 | 参考占用 25/50/75/100%，注明施加核心 |
+| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
+| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
+| L2 | 关键保障负载 + LLM | 核心双目标场景 |
+| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
 | L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
-| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务干扰 |
-| L6 | RT + LLM + YOLO（可选） | 多模型竞争与优先级影响 |
+| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务竞争 |
+| L6 | 关键保障负载 + LLM + YOLO（可选） | 多人工智能目标负载竞争与优先级影响 |
 | L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
 
-推理先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 λ_ref，所有 OS 使用同一绝对到达序列，测试 0.25/0.5/0.75/1.0/1.25×λ_ref。不得各组按自身吞吐重新归一化后声称承受相同负载。
+人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
 
 突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
 
@@ -202,6 +212,14 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
 | E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
 | E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
 
+面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
+
+- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
+- `E3` 负责比较双目标并存时的达标边界；
+- `E4` 负责观察内存限额与容量失败边界；
+- `E6` 负责组织功耗、温度与降频证据；
+- `E8` 负责验证长时间运行、恢复与热稳定性。
+
 E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
 
 E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
@@ -218,6 +236,8 @@ E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳
 
 T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
 
+若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
+
 跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
 
 ### 7.3 控制实验数量
@@ -238,7 +258,7 @@ T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的
 
 ## 9. 验收与结果判断
 
-验收分为“数据可用”“系统约束满足”和“研究假设得到支持”，避免将目标写成已取得结果。
+验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
 
 | 类型 | 判据 | 说明 |
 |---|---|---|
@@ -249,7 +269,7 @@ T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的
 | 能耗收益 | 满足相同实时和推理约束时降低 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 数值同样不直接作为跨配置统一验收值。
+当前候选阈值包括“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. 数据产物与论文图表
 

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/04-论文写作规划.md

@@ -0,0 +1,453 @@
+# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
+
+> **版本**: v0.1 (研究启动版)  
+> **日期**: 2026-09-20  
+> **整合来源**: 01-研究逻辑说明.md + 02-基础设备与算力基础.md + 03-实验设计.md + 10-研究框架/00~07 系列文档 + 第三方基准复现思路
+> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章规划稿 (后续随实验推进持续迭代)
+
+---
+
+## 0. 文章定位与核心贡献
+
+### 0.1 一句话定位
+
+> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**
+
+### 0.2 三大核心贡献
+
+| 编号 | 贡献 | 来源整合 | 对标空白 |
+|------|------|----------|----------|
+| C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
+| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
+| C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
+
+### 0.3 目标读者与发表场景
+
+| 维度 | 选择 |
+|------|------|
+| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
+| 备选 | EMSOFT / DAC / MLSys (系统方向) |
+| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
+| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
+
+---
+
+## 1. 文章整体结构 (十章)
+
+```
+第1章  引言 — 问题、动机、贡献概述
+第2章  背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
+第3章  T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
+第4章  SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
+第5章  实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
+第6章  大模型负载选型与配置 — 跨档位模型矩阵
+第7章  实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
+第8章  深入分析 — 档位间性能曲线 + RTOS vs 普通 Linux / PREEMPT_RT 差异化
+第9章  讨论与威胁有效性 — 适用场景边界 + 局限性
+第10章 结论与展望
+```
+
+---
+
+## 2. 逐章详细规划
+
+### 第1章 引言
+
+**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 1.1 问题矛盾 | 人工智能目标负载要求结果及时且有效，关键保障负载要求严格截止期；两者进入同一任务关键系统后，会在 CPU、内存、总线、加速器和中断路径上发生竞争 |  |
+| 1.2 研究空白 | 公开基准大多基于 Linux/Ubuntu，重点放在吞吐或单任务性能，缺少 RTOS 对人工智能目标负载与关键保障负载双目标实时保障的系统评测 | 01-研究逻辑说明.md §2、§8 |
+| 1.3 本文贡献 | C1 (双目标实时保障优势)、C2 (五类部署形态统一验证矩阵)、C3 (业界基准对齐)，一句话概述每个贡献 |  |
+| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
+
+**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
+
+---
+
+### 第2章 背景与相关工作
+
+**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 2.1 人工智能目标负载特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 I/O 抖动；输出质量与时效双重约束 | 03-实验设计.md §3、10-研究框架/01~04 |
+| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 10-研究框架/00.md §3、05-中断与实时性保障.md |
+| 2.3 PREEMPT_RT 相对短板 | 内核态长路径、系统后台线程、内存回收与共享资源竞争仍可能拉长 `P99.9`；其可预测性增强但不等同于专用 RTOS | 00-整体研究框架.md §5、07-方法论与评估工具链.md §2、§4 |
+| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | 00-整体研究框架.md §6 |
+| 2.5 第三方基准方法学 | 第三方文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 避坑清单 | 03-实验设计.md §4、07-方法论与评估工具链.md §8~§10 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
+| Tab.1 | SylixOS vs 普通 Linux / PREEMPT_RT 对比 | 关键 RTOS 特性对应的双目标实时保障优势与对照平台短板 |
+
+---
+
+### 第3章 T5~T1 五类部署形态验证矩阵
+
+**目标**: 800~1000 词，用连续验证矩阵承载主问题，保持硬件作为验证矩阵的角色。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 3.1 分级维度与分档规则 | 以「部署形态」为第一分类维度，以「统一内存/显存容量」为分档参考；T5~T1 五类部署形态下连续展开 | 02-基础设备与算力基础.md §0.1 |
+| 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
+| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
+| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
+| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.2 | T5~T1 五类部署形态验证矩阵全景图 | 横轴=容量 (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 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
+| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
+| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
+| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
+| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
+| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.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 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
+| 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
+| 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
+| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
+| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
+| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
+| 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
+| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
+| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
+| 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
+| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.5 | 实验方法论流程图 | `G0~G4` 准入 + `O0~O4` 对照 + 第三方基准对齐校验门 |
+| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
+| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
+| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
+
+本章设置下面两张“索引表”：
+
+| 索引表 | 作用 |
+|------|------|
+| RQ → 实验 → 章节映射表 | 把 `RQ1~RQ4` 对应到 `E0~E8`、`L0~L7` 与第7/8章，保证每个研究问题都有直接证据链 |
+| 场景编号 → 结果章节映射表 | 把 `L0~L7` 对应到第7章的小节与图表，保持实验编号与结果章节的直接锚点 |
+
+---
+
+### 第6章 大模型负载选型与配置
+
+**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 03-实验设计.md §3.2 |
+| 6.2 跨档位模型矩阵 | T5-L: Qwen2.5-0.5B INT4；T5-M: 1.5B INT4；T5-H: 3B/7B INT4；T4-L: 3B/7B INT4 (RKLLM)；T4-M: 14B/32B INT4 (TensorRT-LLM)；T3-L: 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 | 02-基础设备与算力基础.md §5.2、03-实验设计.md §3.2 |
+| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T4-M/T3-L)、llama.cpp (T2-L/T4-L 退路)、RKLLM (T5/T4-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 03-实验设计.md §3.1~§3.3 |
+| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 03-实验设计.md §3、§6 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
+| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
+
+---
+
+### 第7章 实验结果
+
+**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
+| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
+| 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
+| 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
+| 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
+| 7.6 温度-功耗-性能耦合 | 对应 `RQ3`；可与 `L1/L2/L7` 组合，报告 25%→100% CPU 逐步加压的三维耦合曲线，以及 SylixOS vs 普通 Linux / PREEMPT_RT Linux 的降频触发温度与性能下降斜率 | 03-实验设计.md §4、06-能耗与热管理.md |
+| 7.7 异构核分配 | 对应 `RQ2/RQ3`；主要落在 RK3588 路线与 `L2/L3`，体现 A76 (LLM) + A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 03-实验设计.md §6、03-加速器协同调度.md |
+| 7.8 跨档位性能曲线 | 对应 `RQ4`；汇总 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线；第7.8节按“已实测结果”与“后续扩展计划”两类展示 | 02-基础设备与算力基础.md §5.3、03-实验设计.md §2 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
+| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 `W(t)` 曲线，SylixOS vs 普通 Linux / PREEMPT_RT Linux 叠加 |
+| Fig.7 | 双目标实时保障延迟分布 (★ 核心证据) | 人工智能目标负载与关键保障负载的 P50~Max 直方图 + 时间序列，4 变体叠加 |
+| Fig.8 | 人工智能目标负载输出时延直方图 | Qwen2.5-7B 单流 1 h 采集，SylixOS vs 普通 Linux / PREEMPT_RT Linux |
+| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间关键保障负载延迟 spike 与人工智能目标负载队列变化的联合时间序列 |
+| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
+| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T5-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
+| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
+
+建议在第7章开头直接放入下面两张索引表：
+
+| 研究问题 | 主要实验单元 | 主要场景编号 | 主要结果章节 | 核心图表 |
+|------|------|------|------|------|
+| `RQ1` 双目标约束下的实时保障 | `E1` 微基准、`E3` 混合负载、`E8` 长稳与恢复 | `L0`、`L2`、`L3`、`L4`、`L5`、`L7` | `7.3`、`7.4` | `Fig.7`、`Tab.13` |
+| `RQ2` 隔离机制的代价与收益 | `E3` 混合负载、`E4` 内存限额、`E7` 消融、`E8` 长稳与恢复 | `L2`、`L3`、`L4`、`L5`、`L6`、`L7` | `7.3`、`7.5`、`7.7` | `Fig.7`、`Fig.9`、`Tab.13` |
+| `RQ3` 功耗预算下的系统协同能力 | `E2` 推理基线、`E3` 混合负载、`E6` 能耗与热、`E8` 长稳与恢复 | `L1`、`L2`、`L7` | `7.2`、`7.6` | `Fig.6`、`Fig.10`、`Tab.13` |
+| `RQ4` 规模扩展后的边界与瓶颈 | `E5` 多卡竞争、`X3`/`X4`/`X5` 条件扩展 | `L3`、`L5`、`L6`、`L7` | `7.5`、`7.8` | `Fig.11`、`Tab.14` |
+
+| 场景编号 | 场景定义 | 论文归属章节 | 主要回答的问题 | 核心图表 |
+|------|------|------|------|------|
+| `L0` | 仅关键保障负载 | `7.3` 低延迟结果 | 关键保障负载下界、测量链路开销 | 延迟 CDF、基线表 |
+| `L1` | 仅人工智能目标负载 | `7.2` 低功耗结果、`7.3` 低延迟结果 | 人工智能目标负载基线时效、能耗与服务能力 | `Fig.6`、`Fig.8` |
+| `L2` | 关键保障负载 + LLM | `7.4` 双目标实时保障结果 | 双目标是否同时达标，是全文核心主场景 | `Fig.7`、`Tab.13` |
+| `L3` | `L2` + CPU 竞争负载 | `7.4`、`7.5` | CPU 竞争下的隔离能力与调度边界 | `Fig.7`、竞争负载对照表 |
+| `L4` | `L2` + 内存流式读写 | `7.4` | 内存带宽与容量压力下的边界变化 | 内存压力时间序列、违约率表 |
+| `L5` | `L2` + 网络/存储 I/O | `7.4`、`7.5` | IRQ、DMA 与系统服务竞争影响 | `Fig.9`、I/O 干扰对照表 |
+| `L6` | 关键保障负载 + LLM + YOLO（可选） | `7.5` | 多人工智能目标负载共存时的优先级与公平性 | 多模型公平性图、Jain 指数表 |
+| `L7` | `L2` + 突发/过载 | `7.4`、`7.5`、`7.6` | 过载、拒绝、恢复与热耦合下的系统稳定性 | `Fig.9`、`Fig.10`、恢复时间表 |
+
+---
+
+### 第8章 深入分析
+
+**目标**: 800~1000 词，从数据中提炼规律性结论。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 8.1 档位间性能曲线规律 | 容量、功耗和拓扑变化下 RTOS 优势的变化趋势；分析哪些档位更容易体现差异、哪些档位优势可能收窄 | 02-基础设备与算力基础.md §5.3 |
+| 8.2 SylixOS vs 普通 Linux / PREEMPT_RT 差异化量化 | 分别评价关键保障负载边界、人工智能目标负载时效和系统协同收益；按档位和场景分别判定 | 03-实验设计.md §9、§10 |
+| 8.3 双目标场景下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 关键保障负载不被长路径抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 模型加载不引入额外抖动；中断线程化 + 亲和性 → NPU/GPU 中断不污染实时核 | 05-中断与实时性保障.md、02-KV-Cache与内存管理.md |
+| 8.4 能效分析 | 每 token 能耗 vs 档位；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 `J/token` 对比 | 02-基础设备与算力基础.md §0.3、06-能耗与热管理.md |
+| 8.5 BSP 风险与可行性 | x86 BSP、ARM64 RK3588 BSP、T234 Jetson BSP、RKLLM 移植等路径的风险等级与降本策略 | 02-基础设备与算力基础.md §7、03-实验设计.md §3 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.12 | RTOS 优势 vs 部署档位趋势图 | 横轴=11 档位，纵轴=SylixOS 相对普通 Linux / PREEMPT_RT Linux 的 `P99.9` 与有效吞吐改善百分比，标注"显著优势/可比偏优/未体现"区间 |
+| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
+| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
+
+---
+
+### 第9章 讨论与威胁有效性
+
+**目标**: 400~600 词，诚实地界定适用边界和局限性。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
+| 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
+| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
+| 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
+
+---
+
+### 第10章 结论与展望
+
+**目标**: 300~400 词，总结贡献并指出未来方向。
+
+| 小节 | 内容要点 |
+|------|----------|
+| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果（基准对齐 ±X%、双目标场景下相对 PREEMPT_RT Linux 的边界改善 X%、能效改善 X%） |
+| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
+| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-推理图任务调度.md §8 |
+
+---
+
+## 3. 来源文档到章节的映射矩阵
+
+| 来源文档 | 主要贡献章节 | 次要贡献章节 |
+|----------|------------|------------|
+| **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
+| **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
+| **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
+| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
+| **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
+| **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
+| **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
+| **04-量化精度感知调度.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
+| **05-中断与实时性保障.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
+| **06-能耗与热管理.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
+| **07-方法论与评估工具链.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
+
+---
+
+## 4. 关键数据产物清单
+
+| 编号 | 产物 | 类型 | 优先级 | 依赖 |
+|------|------|------|--------|------|
+| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 02-基础设备与算力基础.md 已就绪 |
+| D2 | 跨档位模型矩阵 | 数据表 | P0 | 02-基础设备与算力基础.md + 03-实验设计.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 | 已完成档位实测 + 后续档位条件补充；未完成档位不写成正式结果 |
+| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
+| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 03-实验设计.md §11 模板 |
+
+---
+
+## 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 T5~T1 五类部署形态验证矩阵 | 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)
+  → 人工智能目标负载时效/有效性 vs 关键保障负载严格截止期, 在任务关键系统中必须共存
+  → 空白: 国产 RTOS 在任务关键系统中承载人工智能目标负载的系统化数据仍然稀缺
+
+背景铺垫 (§2)
+  → 人工智能目标负载的 CPU/内存/长尾特征
+  → RTOS 的 6 项调度优势 + 普通 Linux / PREEMPT_RT 的边界
+  → 第三方方法学引入 (5 维度 + 5 避坑)
+
+验证矩阵 (§3) ← C2 验证框架
+  → 11 档位连续展开: 1 GB/3 W → 2 TB/25 kW
+  → 现有 P0 零成本起步 (V100 + RK3588)
+  → 一机两档降本
+
+技术架构 (§4)
+  → 五层技术栈 + 六大优化方向
+  → LLM 推理 DAG → RTOS 任务映射
+  → BSP 适配要点与风险
+
+方法学 (§5) ← C1/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 优势
+  → 优越性量化: 关键保障负载边界、人工智能目标负载时效与有效吞吐的联合改进
+  → 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
+  → 能效: V100 基线 vs H100 上限, INT4 拐点
+
+讨论 (§9)
+  → 适用边界: T5/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 (T4-M / T3-L) | 风险高; T4-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 | 与第三方文章配置一致, 可比性最高 |
+
+---

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md

@@ -0,0 +1,24 @@
+# 实验与规划索引
+
+本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
+
+## 阅读建议
+
+1. `01-研究逻辑说明.md`
+2. `02-基础设备与算力基础.md`
+3. `03-实验设计.md`
+4. `04-论文写作规划.md`
+5. `05-论文结构总览.png`
+
+## 文件说明
+
+- `01-研究逻辑说明.md`
+  - 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
+- `02-基础设备与算力基础.md`
+  - T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
+- `03-实验设计.md`
+  - 准入条件、对照原则、混合负载场景、指标与验收方法
+- `04-论文写作规划.md`
+  - 论文结构、章节分工、图表规划和证据映射
+- `05-论文结构总览.png`
+  - 文章结构与逻辑关系示意图

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/README.md

@@ -0,0 +1,21 @@
+# 联合研究方索引
+
+本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
+
+## 当前内容
+
+- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
+  - 面向项目内部的合作设想文档
+  - 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
+- `罗蕾教授资料/`
+  - 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
+  - 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
+- `翼辉信息资料/`
+  - 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
+  - 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
+
+## 使用建议
+
+- 对外沟通时，可先阅读人物概览与科研路径两篇。
+- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
+- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/潜在合作研究路径-罗蕾教授与翼辉信息.md

@@ -0,0 +1,210 @@
+# 潜在合作研究路径：罗蕾教授与翼辉信息
+
+> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
+
+## 1. 两个合作方的协同结构
+
+本项目对应的是一个典型的“**学术问题定义 + 系统机制设计 + 产业平台验证**”三段式问题：
+
+1. 需要有人把研究问题定义清楚，并把方法学、可调度性分析、评价体系和论文表达做扎实；
+2. 需要有人把 RTOS 机制、工具链、BSP、系统实现和真实行业场景接起来；
+3. 需要把两者合成一个既能发表、又能落地、还能与产业沟通的闭环。
+
+在这个结构里，罗蕾教授与翼辉信息的优势方向并不相同，但恰好可以形成互补：
+
+- **罗蕾教授**作为电子科技大学相关领域广受尊重的知名专家学者，更适合承担研究方法、系统建模、学术组织与标准化表达这一侧；
+- **翼辉信息**作为大型实时操作系统与基础软件平台领域极具代表性的产业样本，更适合承担 SylixOS 平台、工程实现、场景验证与产业落地这一侧。
+
+合作路径可以让两个合作方分别占据研究闭环中的不同位置。
+
+## 2. 罗蕾教授更适合承担的合作角色
+
+基于其长期研究积累与代表成果，罗蕾教授更适合在下面几个方向发挥作用：
+
+### 2.1 研究问题与方法学共建
+
+罗蕾教授长期积累的重点在嵌入式实时操作系统、可调度性分析、汽车电子基础软件、安全隔离与系统工程化。这位在相关领域享有较高声誉的专家学者，尤其适合参与：
+
+- 研究问题的学术化表述；
+- `RQ1~RQ4` 的研究问题拆解；
+- `O0/O1/O2/O3` 对照逻辑的合理性论证；
+- `TTFT/TPOT + deadline miss + jitter + 系统协同` 这套双目标指标体系的学术组织；
+- 长稳、突发、恢复、消融等实验类型的论文化组织。
+
+罗蕾教授更适合帮助项目把工程现象组织成可发表的系统研究问题。
+
+### 2.2 系统建模与分析工具链
+
+罗蕾教授在实时系统建模、AADL 可调度性分析、AUTOSAR 任务映射、隔离保护等方向已有持续积累，因此她适合参与：
+
+- 关键保障负载的任务模型抽象；
+- 人工智能目标负载进入系统后的实时约束建模；
+- 基于 `RTA/WCET` 的边界分析；
+- 任务映射、优先级分配、资源预算与配额约束的分析框架；
+- 从实验结果回推系统机制成立条件的理论解释。
+
+这一部分做扎实后，项目可以形成“机制 - 结果 - 边界”三位一体的研究结构。
+
+### 2.3 学术产出与标准化表达
+
+罗蕾教授长期处在“研究 - 标准 - 产业化”打通的路径上，因此她也适合参与：
+
+- 论文结构与贡献凝练；
+- 学术报告和项目申报材料；
+- 将系统机制抽象为可推广的方法学；
+- 后续延伸到行业测试规范或联合白皮书时，可协助形成更规范的表达。
+
+## 3. 翼辉信息更适合承担的合作角色
+
+翼辉信息的价值首先体现在其所代表的 **SylixOS 大型跨平台实时操作系统平台** 与行业落地经验。作为国内 RTOS 与关键基础软件方向颇具代表性的企业样本，翼辉信息在合作设想中具备很高的参考价值。
+
+### 3.1 主实验样例与平台能力提供方
+
+翼辉信息最适合承担的第一角色，是 `SylixOS` 主实验样例的提供与支撑，包括：
+
+- SylixOS 版本、配置、调度参数与机制能力说明；
+- BSP、驱动、工具链、trace/观测接口支持；
+- SMP、多核绑定、中断治理、内存锁定、隔离机制等平台能力验证；
+- 针对任务关键系统场景的默认配置与优化配置对照。
+
+这一部分决定了项目能否把“研究对象”落实到一套可验证的 RTOS 平台上。
+
+### 3.2 工程实现与系统机制落地
+
+翼辉信息也适合参与系统机制层的实现与验证，例如：
+
+- 人工智能目标负载与关键保障负载的优先级/配额治理；
+- 核隔离、IRQ 亲和、设备中断分流；
+- KV Cache、内存池、DMA/I/O 路径的系统治理；
+- 长稳运行、恢复策略、故障隔离和资源回收机制；
+- 不同部署形态下的实际可部署方案。
+
+这部分决定了项目能否从“方法论文档”走到“工程上真的成立”。
+
+### 3.3 行业场景与产业验证语境
+
+翼辉信息长期服务于航天、轨道交通、电力、工业自动化、智能汽车等任务关键行业，因此它更适合提供：
+
+- 任务关键系统的真实负载语境；
+- 典型关键保障任务模板；
+- 更贴近行业的干扰链路和恢复要求；
+- 对“结果是否具有产业解释力”的判断。
+
+这一部分非常重要，因为它会决定研究结果是不是只在实验室里成立。
+
+## 4. 三方合作的分工结构
+
+本项目可按“三方闭环”来组织：
+
+- **罗蕾教授侧**：负责研究问题定义、系统建模、方法学审阅、论文组织与学术表达增强；
+- **翼辉信息侧**：负责 SylixOS 平台支撑、机制实现接口、工程验证条件与产业场景输入；
+- **我们项目组**：负责前期调研、实验执行、资料整理、跨平台对照实现与协同支撑。
+
+可以把它理解成下面这条链路：
+
+`研究问题定义 -> 方法学与分析框架 -> RTOS 机制实现 -> 实验验证 -> 论文与白皮书表达`
+
+其中：
+
+- 罗蕾教授更靠前半段和总结抽象；
+- 翼辉信息更靠中间实现与后端产业验证；
+- 项目组负责根据合作方的方向与建议，把实验推进、资料整合和执行工作衔接起来。
+
+## 5. 可优先推进的合作研究主题
+
+合作讨论可以优先围绕下面几类题目推进：
+
+### 5.1 双目标实时保障基准共建
+
+目标：
+
+- 联合定义一套面向任务关键系统的 AI 目标负载 + 关键保障负载基准；
+- 统一 `TTFT/TPOT`、`deadline miss`、`P99/P99.9 jitter`、`E/token` 等指标；
+- 明确 `G0~G4` 准入和 `O0~O4` 对照逻辑。
+
+更适合的分工：
+
+- 罗蕾教授侧负责方法学与指标体系合理性；
+- 翼辉信息侧负责 SylixOS 落地和观测手段；
+- 项目组负责实验编排、数据整理和协同落实。
+
+### 5.2 任务关键系统中的 AI 负载准入与隔离机制
+
+目标：
+
+- 研究人工智能目标负载进入系统后，如何通过配额、优先级、核绑定、时间预算、内存预算等机制维持关键保障任务边界；
+- 给出“哪些条件下准入、哪些条件下拒绝、哪些条件下需要降级运行”的规则。
+
+更适合的分工：
+
+- 罗蕾教授侧偏规则建模和边界分析；
+- 翼辉信息侧偏机制实现和可部署性验证。
+
+### 5.3 面向实际行业场景的 SylixOS 机制验证
+
+目标：
+
+- 选择 1~2 个更贴近行业的关键场景，如工业控制、车载控制、边缘智能节点；
+- 把实验从抽象负载推进到“有行业解释力”的场景负载。
+
+更适合的分工：
+
+- 翼辉信息侧提供场景输入和系统约束；
+- 罗蕾教授侧帮助把场景抽象成学术上可论证的问题。
+
+### 5.4 联合论文 / 白皮书 / 申报材料
+
+目标：
+
+- 学术上形成论文；
+- 产业上形成白皮书或联合研究说明；
+- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
+
+更适合的分工：
+
+- 罗蕾教授侧偏学术与规范表达；
+- 翼辉信息侧偏产业价值、案例与平台能力；
+- 项目组承担材料汇总、写作配合与整合支撑。
+
+### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
+
+目标：
+
+- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
+- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
+- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
+
+更适合的分工：
+
+- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
+- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
+- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
+
+这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
+
+## 6. 更现实的推进顺序
+
+推进顺序以稳妥、小步、可验证为宜：
+
+1. **先分别沟通**：确认双方对课题定位、研究边界、合作兴趣是否一致；
+2. **先小后大**：先围绕一个具体问题试合作，例如基准设计、实验审阅或场景讨论；
+3. **先方法后平台**：先把研究问题和方法学框架对齐，再谈平台实现细节；
+4. **先形成最小闭环**：先做出一版可验证的实验与分析，再决定是否扩展成正式联合研究。
+
+## 7. 当前文档使用边界
+
+这份文档当前更适合作为：
+
+- 项目内部筹划材料；
+- 对外沟通前的思路整理；
+- 预判双方合作接口是否互补的参考稿。
+
+当前使用场景包括：
+
+- 项目内部筹划与分工设计；
+- 对外沟通前的内容准备；
+- 合作接口与协同结构的前期梳理。
+
+这份文档回答的是：
+
+> **与罗蕾教授、翼辉信息形成联合研究时，最合理的合作结构是什么。**

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/01-人物概览.md

@@ -0,0 +1,18 @@
+# 罗蕾教授人物概览
+
+罗蕾教授是电子科技大学教授、博士生导师，长期在电子科技大学从事嵌入式基础软件相关教学、科研与产业化工作。她曾任嵌入式软件工程中心主任，持续聚焦嵌入式操作系统、物联网网络安全与数据安全、工业软件、智能计算等方向，是电子科技大学在嵌入式系统与相关产业应用领域具有较高影响力、广受尊重的知名专家学者。
+
+罗蕾教授与电子科技大学保持了长期稳定的学术关联。她于 1987 年毕业于电子科技大学计算机系，1996 年晋升副教授，2003 年评为教授，2005 年晋升博士生导师。她既是学校本土培养起来的教师，也长期参与了学科建设、课程建设与团队建设。
+
+罗蕾教授的工作范围已经超出了传统高校教师的单一角色。她曾作为国家“核高基”专家参与智能手机、汽车电子、数字电视等多项嵌入式基础软件重大专项实施，同时担任国家智能网联汽车创新中心专家、车载信息服务产业应用联盟（TIAA）网络安全委员会秘书长、工信部区块链技术与数据安全重点实验室相关专家等职务。她的工作位置也因此横跨了高校、重大专项、行业联盟和产业协同几个层面。
+
+罗蕾教授的研究主线是一条逐步扩展的“底层软件到行业场景”的路线。较早阶段，她的工作更多与嵌入式实时操作系统、嵌入式基础软件和开发工具有关；随后逐步延伸到汽车电子、物联网安全、移动支付、区块链与数据安全，再到今天更强调工业软件、网络安全和智能计算。这种演进很有代表性，反映出她的研究沿着产业需求不断外扩。
+
+罗蕾教授是一位具有明显“工程化导向”和产业连接能力、在相关领域享有较高声誉的知名专家学者。她既有学校内部的学术与教学身份，也深度参与国家项目、行业标准和企业合作；既关注嵌入式系统的底层技术，又把研究延伸到汽车、支付、数据安全等具体行业。她的个人画像体现出“学术研究者 + 工程组织者 + 产业连接者”的复合型角色。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
+3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/02-教学与人才培养.md

@@ -0,0 +1,20 @@
+# 罗蕾教授的教学与人才培养工作
+
+罗蕾教授不仅是一位在嵌入式系统领域具有较高影响力的专家学者，也长期深度投入教学工作。她的教学工作有一个很明显的特点：围绕一门核心课程，把教材、实验、课程资源和人才培养体系连在一起。
+
+最能代表这一点的课程，是《嵌入式系统及应用》。这门课早在 2007 年就获得国家精品课程认定，之后又先后成为四川省精品资源共享课、四川省精品在线开放课程，并在 2023 年获得国家级一流本科课程认定。它是一门经过多年迭代、持续建设的核心课程。
+
+这门课是一门典型的工程化课程。课程内容覆盖嵌入式系统导论、ARM 体系结构与编程、嵌入式软件系统、任务管理与调度、同步互斥与通信、中断时间和内存管理等主题，并配有 ARM 实验和 uC/OS-II 操作系统实验。课程结构采用“原理 + 实验 + 开发能力”的组织方式，目标是让学生真正进入嵌入式系统开发。
+
+罗蕾教授在教学上的另一个特点，是把教材建设和课程建设配套推进。她主编过《嵌入式实时操作系统及应用开发》第一、二、三版，以及《嵌入式系统及应用》等著作。对一门工科课程来说，教材是否成体系，往往决定了课程能否长期稳定传承；她也由此搭建起一个可复制、可持续的知识框架。
+
+罗蕾教授的人才培养方向也比较清晰。她指导的软件工程、电子信息等学位点，研究方向主要包括嵌入式软件技术与应用、工业软件、网络安全、智能计算等。这些方向既有传统的嵌入式系统主线，也对接了当下工业软件和安全计算的需求。她的人才培养模式强调“从基础软件出发，向新应用场景延展”。
+
+罗蕾教授在教学上的重要性，体现在她于电子科技大学长期建设出了一套有工程背景、有实验支持、有教材配套、能持续培养学生的嵌入式教学体系。这也是这位知名专家学者在校内外形成广泛学术影响力的重要来源之一。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学计算机学院教学成果页：<https://www.scse.uestc.edu.cn/info/1039/10809.htm>
+3. 中国大学 MOOC《嵌入式系统及应用》课程页：<https://www.icourse163.org/course/UESTC-1206862805?from=searchPage&outVendor=zw_mooc_pcssjg_>
+4. 电子科技大学教学资源平台课程页：<https://resource.uestc.edu.cn/learn/course/preview/spoc/17269f9718ed4af1b94108437e6b6e1a>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/03-科研与产业化路径.md

@@ -0,0 +1,21 @@
+# 罗蕾教授的科研与产业化路径
+
+罗蕾教授的科研工作持续把嵌入式基础软件能力往产业场景里推进。作为电子科技大学相关方向具有代表性的知名专家学者，她长期主持或参与国家重大专项、863 项目、自然科学基金、发改委软件产业化专项等任务，同时又深度参与企业合作、行业标准与联盟工作。这种“研究 - 标准 - 产品 - 场景”连起来的路径，是她区别于很多纯学院型学者的重要地方。
+
+她早期的重要发力点是嵌入式基础软件和实时操作系统。她曾主持“面向嵌入式软件的生产线”“智能手机嵌入式软件平台”“嵌入式实时操作系统及其开发工具”等项目，所在团队也长期围绕嵌入式操作系统、嵌入式网络安全、汽车电子基础软件展开工作。这类方向的共同点，是都处在系统底层，技术门槛高、复用价值大，而且很容易形成行业平台能力。
+
+之后，她的科研和产业化路径逐步向汽车电子和网络安全方向深化。团队列出的代表性项目里，既有“汽车电子网络安全标准化研究白皮书编制”“面向汽车电子的代码安全技术研究与实现”，也有“智能汽车安全加固与监控产品研发与产业化”“车辆身份唯一性认证模型的测试委托”等项目。罗蕾教授的工作集中在汽车电子基础软件、代码安全、身份认证、网络安全标准等更底层、更可落地的位置。
+
+同时，她的团队也明显向区块链与数据安全扩展。相关成果包括区块链基础平台“优云链”和面向数据共享的“优数”平台，应用场景覆盖无人机运输物流追踪、汽车大数据交易平台、学分银行、移动支付可信数据共享联盟链、国际贸易通关协同、财政资金监管等。她所推动的区块链工作与数据确权、共享交换、可信交易、安全监管等产业需求直接挂钩。
+
+除了项目本身，罗蕾教授在行业规则层面的参与也很值得关注。她牵头或参与了 20 余项国家、行业和团体标准，团队也参与了多项汽车网络安全相关国家标准与行业标准。她的影响力同时体现在技术落地和行业通用规则推进两个层面。对很多产业技术路线来说，这一步往往比单点成果更有长期影响。
+
+她的科研路径可以概括为三层：第一层是嵌入式操作系统、开发工具和基础软件；第二层是网络安全、汽车电子、物联网与数据安全；第三层是标准化、产业平台和企业合作落地。正因为这三层是打通的，罗蕾教授的工作才呈现出很强的“工程系统型”特征，并形成了连续展开的研究主题体系。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
+3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
+5. 世展网转载行业观点文章：<https://www.shifair.com/informationDetails/135407.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/04-代表成果与研究主题.md

@@ -0,0 +1,29 @@
+# 罗蕾教授的代表成果与研究主题
+
+罗蕾教授作为电子科技大学相关方向具有较高影响力的知名专家学者，其研究主题围绕“嵌入式系统底层能力如何支持复杂场景”逐步展开。她较有代表性的成果，大致可以分成四个方向：嵌入式实时操作系统、汽车电子基础软件与安全、网络与数据安全、以及面向新场景的智能计算延展。
+
+第一类成果是嵌入式实时操作系统与基础软件。罗蕾教授主编过《嵌入式实时操作系统及应用开发》和《嵌入式系统及应用》等教材，导师页面列出的代表论文也长期围绕任务调度、GUI、多任务系统、AADL 可调度性分析等主题展开。比如 `UCaS: a schedulability analysis tool for AADL models` 这类工作，体现的是她早期在嵌入式软件建模与调度分析方面的积累。这个方向的核心关键词，是实时性、可调度性和基础软件工程化。
+
+第二类成果是汽车电子嵌入式操作系统与 AUTOSAR 相关研究。比较典型的论文包括《汽车电子嵌入式操作系统的隔离保护机制》和《AUTOSAR 可运行实体-任务自动映射方法研究》。前者关注的是在有限硬件资源下实现多层级隔离保护，以降低系统整体失效概率；后者则围绕 ECU 配置和实时系统任务映射，提高汽车软件开发效率。她在汽车电子方向持续关注操作系统机制、安全隔离和软件架构配置这类关键底层问题。
+
+第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。
+
+第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。这一方向也可以继续向小型化、低功耗、资源受限系统中的智能应用展开，把嵌入式基础软件、可调度性分析与低功耗部署问题连接起来。
+
+罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。
+
+## 可关注的公开代表成果
+
+- `汽车电子嵌入式操作系统的隔离保护机制`
+- `AUTOSAR可运行实体-任务自动映射方法研究`
+- `A Cross-platform Mobile Payment Solution Based on Web Technology`
+- `UCaS: a schedulability analysis tool for AADL models`
+- `An intrusion detection system integrating network-level intrusion detection and host-level intrusion detection`
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+3. 电子科技大学学报相关论文页：<http://www.juestc.uestc.edu.cn/article/doi/10.3969/j.issn.1001-0548.2014.03.023?viewType=citedby-info>
+4. 学术摘要页《汽车电子嵌入式操作系统的隔离保护机制》：<https://www.xueshu.com/dzkjdxxb/201403/2984678.html>
+5. 维普摘要页《AUTOSAR可运行实体-任务自动映射方法研究》：<http://dianda.cqvip.com/Qikan/Article/Detail?id=7000589928>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/README.md

@@ -0,0 +1,15 @@
+# 罗蕾教授资料目录
+
+本目录用于介绍罗蕾教授的学术背景、教学工作、科研路径与代表性研究主题，并将内容拆分为几篇可以独立阅读的介绍文章。
+
+## 文件列表
+
+- `01-人物概览.md`：聚焦罗蕾教授的基本履历、学术身份与整体定位。
+- `02-教学与人才培养.md`：聚焦课程建设、教材编写与人才培养工作。
+- `03-科研与产业化路径.md`：聚焦科研方向、重大项目、行业标准与产业合作。
+- `04-代表成果与研究主题.md`：聚焦代表性研究主题、论文与技术成果。
+
+## 使用说明
+
+- 各文档彼此独立，可单独转发或继续扩写。
+- 各文档正文以人物介绍和研究工作为主，参考资料统一列于文末。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/01-公司与RTOS定位概览.md

@@ -0,0 +1,28 @@
+# 翼辉信息与大型实时操作系统定位概览
+
+翼辉信息在本项目中对应的是**面向任务关键系统的大型跨平台实时操作系统平台**。SylixOS 的核心价值集中在复杂系统中的实时软件底座能力，即维持确定性、可预测性和系统边界。
+
+翼辉信息长期围绕 SylixOS 展开自身定位，定位为“软件定义智能装备业内领先的基础软件架构供应商”，强调基于原创工业操作系统和整体软件架构技术，为火箭、卫星、高铁、大飞机、无人设备、电网电站、工业自动化、智能汽车等任务关键型智能设备提供稳定、可靠、安全的软件系统方案。其平台能力覆盖**关键行业、复杂系统、长期交付和基础平台能力**，在相关领域具备较强代表性和较高行业辨识度。
+
+翼辉信息最核心的产品身份是“**大型实时操作系统**”。SylixOS 的核心能力包括：SMP 多核实时调度、多处理器架构支持、动态装载、POSIX 兼容、高安全高可靠、复杂系统集成，以及长期版本维护。SylixOS 承担的是更高层次的软件平台职责：在不同硬件架构、不同规模平台和不同关键行业约束下，为复杂任务提供统一、稳定且可演进的实时操作系统基础。
+
+本项目围绕的大型跨平台实时操作系统平台，正与翼辉信息所代表的平台能力直接对应。翼辉信息提供的是一种可以跨平台承载、跨行业验证、并且天然面向任务关键场景的 RTOS 平台样本。
+
+翼辉团队的技术起点可追溯到 2006 年，随后在 2015 年公司化运营。SylixOS 内核经过工信部赛普测评中心源代码测评，自主化率达到 100%，并获得德国 TÜV SUD 集团颁发的 IEC 61508（SIL3）、EN 50128（SIL4）和 ISO 26262（ASIL D）认证。翼辉信息已经进入高安全、高可靠、高约束行业的软件平台提供方序列，是非常值得重视、也颇具分量的**产业级实时操作系统案例**。
+
+除了 SylixOS 内核本身，翼辉信息还呈现出一条从 RTOS 向完整基础软件栈外扩的路径。其产品和能力包括 RealEvo 开发环境、VSOA 分布式软总线、任务关键型云原生体系、工业自动化数字基座、飞控与仿真产品等。翼辉正在把实时操作系统扩展为面向关键装备的软件平台。这种平台化能力与本项目的验证方向高度一致。
+
+翼辉信息在本项目中的身份可以表述为：**面向关键行业的大型跨平台实时操作系统与基础软件平台提供方**。作为产业落地样本，它能够直接支撑与实时调度、关键系统约束、复杂工程交付相关的课题论证。
+
+## 对本项目最有价值的定位结论
+
+1. 翼辉信息代表的是**大型跨平台实时操作系统平台**。
+2. SylixOS 的核心价值体现在**复杂系统中的实时性、确定性与平台能力**。
+3. 翼辉信息更适合作为**产业级 RTOS 案例**。
+4. 它能够帮助本项目围绕“实时操作系统如何治理智能负载进入任务关键系统后的边界问题”展开产业样本验证。
+
+## 参考资料
+
+1. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/02-SylixOS技术能力与演进.md

@@ -0,0 +1,17 @@
+# SylixOS 技术能力与演进
+
+SylixOS 是翼辉信息的核心技术载体，是一款支持 SMP 多核实时调度、可运行于多种 CPU 架构目标平台的“大型实时操作系统”。其工程积累集中体现在调度、隔离、兼容性和长期演进能力上。
+
+SylixOS 的内核在 2006 年完成，最初具备线程调度、中断管理、定时器、RMS、信号量等核心机制；随后逐步加入 I/O、网络、文件系统、内存管理、POSIX 支持、C++ 支持、GDB 调试、Qt 支持和更广泛的平台适配。2011 年开始支持多核和动态装载；2012 年开始支持进程；2018 年全面支持 C-SKY 和 RISC-V；2020 年推出 LTS 版本；2021 年通过 IEC 61508（SIL3）和 EN 50128（SIL4）国际安全认证；2022 年进一步通过 ISO 26262（ASIL D）认证并支持 LoongArch。SylixOS 持续朝着可落地的大型实时系统平台演进。
+
+SylixOS 对多核与异构调度的强调，也与本项目高度相关。其 2023 年 V3.0.0 阶段已经开始支持异构算力大小核处理器，并提供灵活高效的调度器与调度策略，在算力和功耗之间取得平衡。这一能力与 LLM 推理线程、实时控制任务在共享 CPU、缓存和内存资源时的冲突控制直接相关。SylixOS 在大小核调度、SMP 调度策略、长期版本维护和实时性保障上的成熟能力，也使其非常适合作为实验平台或联合验证对象。
+
+SylixOS 周边能力也比较完整。其支持多种 CPU 架构，强调强实时、高安全、高可靠；同时配套 RealEvo 开发环境、仿真与远程开发能力，甚至扩展到容器、分布式软总线和任务关键型云原生体系。它已经形成较完整的软件工程与集成配套。对研究项目而言，这种配套能力很关键，因为很多真实工业验证会卡在工具链、仿真环境、应用移植和系统验证流程上。
+
+SylixOS 主要承担 RTOS 与基础软件底座角色。在本项目语境下，研究重点是 SylixOS 这类 RTOS 如何对 AI 推理任务进行资源隔离、优先级控制、实时保障和系统级治理。
+
+## 参考资料
+
+1. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
+2. 翼辉信息官网首页：<https://www.acoinfo.com/>
+3. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/03-行业落地与生态版图.md

@@ -0,0 +1,18 @@
+# 行业落地与生态版图
+
+翼辉信息持续进入关键行业落地场景，其服务对象集中在火箭、卫星、高铁、大飞机、工业自动化、能源电力、智能汽车、低空经济等任务关键型装备领域。这些行业共同要求硬实时或强实时、长期稳定、功能安全和工程可维护性。
+
+翼辉信息正在构建一套更完整的生态版图。除了 SylixOS 之外，公开展示的还包括 RealEvo 轻量开发环境、VSOA 分布式软总线、工业自动化数字基座、可编程控制器、虚拟 PLC、边缘计算机、飞控系统、飞行仿真平台等。其商业策略已延伸到“关键装备基础软件平台方”这一层级。对联合研究而言，这种生态化布局可以覆盖内核测评、整机验证、边缘控制、系统集成和行业样机落地等更宽的接口。
+
+行业案例与用户故事也体现出清晰的行业线索。首页展示了中国铁道科学研究院和星际荣耀的用户评价，前者强调轨交信号控制系统对功能安全、稳定性、实时性的苛刻要求，后者强调在火箭飞控场景中通过 RTOS 对复杂软件进行分层抽象的重要性。航天行业页面还提到，翼辉信息与相关航天单位开展深度合作，基于 SylixOS 的星载操作系统用于星务和载荷设备开发，并参与火箭控制器、卫星载荷等系统建设。翼辉的主要市场集中在高可靠装备场景。
+
+翼辉信息在南京的软件产业生态中也被作为“工业底层操作系统”代表企业来呈现。2026 年南京雨花台区公开报道提到，南京翼辉信息 2016 年落地软件谷，围绕 SylixOS 研发逐步形成产业能力，并将经验复制到水务、地铁运营、地下空间运维等场景。报道还提到其正推动人工智能、边缘计算与操作系统深度融合。翼辉的产业化路径已经覆盖军工之外的城市基础设施和工业场景。
+
+翼辉信息已经把 RTOS 能力嵌入了多个高要求行业场景，并在工具链、行业方案和系统架构层面继续外扩。对本项目而言，它既是实验平台的重要来源，也是后续验证场景和行业接口的重要支撑。
+
+## 参考资料
+
+1. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. 翼辉信息航天行业页：<http://www.acoinfo.cn/industry-center/spaceflight>
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/04-与本项目的潜在协同点.md

@@ -0,0 +1,38 @@
+# 与本项目的潜在协同点
+
+把翼辉信息放进本项目的联合研究方名单，能够为项目提供一个较有代表性的**产业落地案例**，帮助我们把课题从抽象的“实时操作系统理论”推进到“任务关键系统中的工程验证”。
+
+本项目围绕的大型跨平台实时操作系统平台比较，聚焦于五类硬件条件下智能负载进入任务关键系统后的确定性、可预测性与实时保障表现。翼辉信息对应的是一个面向关键行业长期演进的 RTOS 平台提供方，因此在这个课题中具有清晰的产业样本价值。
+
+第一，翼辉信息适合作为**基础平台型产业案例**。SylixOS 被持续定义为“大型实时操作系统”，其核心能力集中在 SMP 多核实时调度、跨处理器架构支持、动态装载、长期维护、高安全高可靠，以及面向复杂系统集成的工程能力。翼辉信息在这一结构中承担的是“系统级平台厂商”角色，与本项目的平台研究对象高度一致。
+
+第二，翼辉信息适合作为**任务关键系统落地语境下的验证样本**。其行业服务重点集中在轨道交通、航天、航空、电力、工业自动化、智能汽车等领域，这些场景共同要求系统长期稳定运行，并对时序、可靠性、安全性和工程交付有明确要求。翼辉这样的案例能够把研究问题放到具有明确时序边界和系统保障要求的工业语境中。
+
+第三，翼辉信息适合作为**RTOS 在任务关键场景中的边界控制能力**这一命题的产业对照载体。未来设计对照实验时，重点就在于同一类任务关键负载下，SylixOS 这类大型跨平台 RTOS 与标准 Linux、PREEMPT_RT Linux 这类通用或实时增强型系统相比，在 deadline miss、尾延迟、任务抖动、资源隔离和故障恢复上形成怎样的边界控制能力。翼辉的产业案例价值就在这里：它让这一研究命题可以被放到真实行业约束中讨论。
+
+第四，翼辉信息还适合作为**工程闭环能力的观察对象**。翼辉围绕 SylixOS 不仅提供内核，还扩展了开发环境、仿真、软总线、数字基座、任务关键型云原生与系统化交付能力。它已经形成一整套从内核到工具链再到行业集成的方法论。工程闭环能力也直接决定学术结论能否落到产业场景里。
+
+第五，翼辉信息在本项目中的价值集中在**实时操作系统平台、关键行业基础软件和系统治理能力**。围绕 SylixOS 这类大型跨平台 RTOS，可以进一步展开 AI 推理系统进入任务关键系统后的实时约束建模、优先级与配额控制、内存带宽与缓存竞争治理、大小核与能耗协同、容器化封装，以及控制任务不失稳条件下的系统级实验设计。
+
+翼辉信息为“大型跨平台实时操作系统在任务关键系统中的边界控制能力”这一研究命题，提供了一个能够落到关键行业、复杂系统和长期交付语境中的产业样本。
+
+## 作为产业落地案例时可重点强调的价值
+
+1. **平台定位**：翼辉代表的是大型跨平台实时操作系统平台。
+2. **场景准确**：其公开落地行业天然属于任务关键系统，比消费电子场景更能支撑课题成立。
+3. **对照准确**：便于把 SylixOS 与 Linux / PREEMPT_RT 等系统放到统一的工业约束下比较。
+4. **验证准确**：可从调度、隔离、故障恢复、能耗治理、系统集成多个层面观察 RTOS 的真实优势。
+
+## 可继续深挖的合作问题
+
+1. SylixOS 当前公开可支持到什么程度的 AI 推理运行时、边缘推理框架或异构算力调度能力。
+2. 在 SylixOS 平台上，实时控制任务与推理任务共存时可用的隔离手段包括哪些，例如核绑定、容器、时间分片、内存配额、设备访问权限控制等。
+3. 以翼辉作为产业落地案例时，对照组采用 Linux、PREEMPT_RT Linux，还是两者同时纳入。
+4. 能否联合定义一个面向任务关键系统的 AI 干扰基准测试，用于量化 deadline miss、尾延迟、抖动和能耗影响。
+
+## 参考资料
+
+1. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/README.md

@@ -0,0 +1,15 @@
+# 翼辉信息资料目录
+
+本目录用于介绍翼辉信息及其 SylixOS 技术体系，服务于联合研究判断、产业协同沟通和 RTOS 技术路线分析。
+
+## 文件列表
+
+- `01-公司与RTOS定位概览.md`：聚焦翼辉信息的公司定位、核心产品和公开产业身份。
+- `02-SylixOS技术能力与演进.md`：聚焦 SylixOS 的技术特征、发展里程碑和能力边界。
+- `03-行业落地与生态版图.md`：聚焦翼辉信息在关键行业的应用方向、案例和生态布局。
+- `04-与本项目的潜在协同点.md`：聚焦翼辉信息与本项目“RTOS 管理 LLM 推理资源竞争”主题的结合点。
+
+## 使用说明
+
+- 各文档彼此独立，可单独阅读或继续扩写。
+- 正文以公司定位、平台能力和行业应用介绍为主，参考资料统一列于文末。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/README.md

@@ -0,0 +1,42 @@
+# SylixOS LLM RTOS Research Repo
+
+本仓库现按“总览、研究框架、实验规划、外部资料、交付物、归档”六个层次组织，便于把研究主线、写作材料和外部导入内容分开维护。
+
+## 目录结构
+
+- `00-项目总览/`
+  - 当前研究问题与项目定位边界说明
+- `10-研究框架/`
+  - 核心研究框架
+  - 六个优化方向与方法学子文档
+- `20-实验与规划/`
+  - 硬件谱系
+  - 实验设计
+  - 研究逻辑说明
+  - 论文规划与配图
+- `30-联合研究方/`
+  - 联合研究方资料、人物背景与协作参考
+- `40-交付物/`
+  - Word 规范稿
+  - 白皮书与汇报输出
+- `90-归档/`
+  - 外部导入副本
+  - 压缩包与暂存杂项
+
+## 建议阅读顺序
+
+1. `00-项目总览/01-当前研究问题：背景、问题与挑战.md`
+2. `00-项目总览/02-研究定位与项目边界.md`
+3. `20-实验与规划/README.md`
+4. `20-实验与规划/01-研究逻辑说明.md`
+5. `20-实验与规划/02-基础设备与算力基础.md`
+6. `20-实验与规划/03-实验设计.md`
+7. `10-研究框架/README.md`
+8. `10-研究框架/00-整体研究框架.md`
+9. `20-实验与规划/04-论文写作规划.md`
+
+## 说明
+
+- `10-研究框架/00-整体研究框架.md` 与 `01~07` 子文档保持同目录，避免内部引用失效。
+- `20-实验与规划/` 中的核心规划文档保持同目录，便于交叉引用。
+- `90-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/01-当前研究问题：背景、问题与挑战.md

@@ -0,0 +1,59 @@
+# 当前研究问题：背景、问题与挑战
+
+## 1. 背景
+
+人工智能能力正在从服务器、云端和通用应用软件，持续进入设备控制、边缘协同、车载平台、工业终端和任务关键系统。系统中的人工智能不再只是离线分析能力，而正在承担识别、规划、诊断、导航、辅助决策和自然交互等面向实时场景的功能。
+
+当人工智能能力进入这些系统后，系统的时间结构发生了明显变化：
+
+- 感知链路、推理链路与控制链路开始耦合；
+- CPU、NPU、GPU、DMA、总线和内存带宽竞争明显增强；
+- 功耗、散热、体积、统一内存和设备驱动限制直接影响系统行为；
+- 关键保障负载与人工智能目标负载开始争夺同一组底层资源。
+
+因此，系统面对的已经不是单纯的“把模型跑起来”问题，而是“如何让人工智能能力进入系统之后，整体时序边界仍然成立”的问题。
+
+## 2. 问题
+
+本框架聚焦的问题是：
+
+> **当人工智能能力进入实时控制系统后，模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存和协处理器如何共同决定系统的整体实时边界。**
+
+这里的核心观察有三点：
+
+1. **大模型与智能算法的实时问题不能完全归于 RTOS 单独解决。**
+2. **纯粹把问题写成“RTOS 优于 Linux”已经不足以覆盖真实系统问题。**
+3. **真正需要研究的是面向 AI 的实时控制基础系统，而不是单一软件层。**
+
+## 3. 挑战
+
+### 3.1 跨层因果交织
+
+人工智能目标负载的时间行为同时受到模型结构、量化方式、算子实现、运行时队列、驱动、芯片资源和操作系统机制影响。单一层面的解释无法完整说明系统实时性。
+
+### 3.2 感知与控制形成闭环
+
+一旦感知、规划、语音理解或推理链路进入控制闭环，推理延迟、链路抖动和异常输出都会直接影响执行效果，系统面对的是认知与控制的一体化问题。
+
+### 3.3 MCU 与 SoC 路线差异显著
+
+MCU 场景更偏向静态资源分配、工具链和芯片协同；SoC 场景更偏向 Linux / RTOS / Hypervisor 协同、统一内存竞争治理和异构设备协作。这两类问题不能被同一套表达简单覆盖。
+
+### 3.4 体系结构成为主要变量
+
+随着 NPU、GPU、DMA、统一内存、总线和缓存结构进入主舞台，问题已经从调度器、中断和线程同步扩展到嵌入式计算机体系结构层。
+
+### 3.5 产业叙事需要升级
+
+如果企业仍然只把自己定义为 RTOS 供应方，就很难完整解释人工智能进入实时控制系统后出现的新问题。更有延展性的定位应当围绕“基础系统”展开。
+
+## 4. 本框架的价值
+
+本框架的目标不是否定 RTOS，而是把 RTOS 放回更准确的位置：
+
+- RTOS 是关键保障负载的确定性底座；
+- Linux 与推理运行时承载 AI 生态与计算任务；
+- Hypervisor、芯片与资源治理结构承担隔离、边界与整体秩序；
+- 规则层与兜底机制承担异常控制与安全边界。
+
+因此，本框架对应的研究价值在于：为“人工智能进入实时控制系统之后的基础系统问题”建立更准确的问题定义、技术路线和实验组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/02-研究定位与项目边界.md

@@ -0,0 +1,80 @@
+# 研究定位与项目边界
+
+## 1. 研究定位
+
+本框架的研究定位是：
+
+> **面向人工智能能力进入实时控制系统后的整体系统问题，研究基础系统如何维持确定性、可预测性与实时边界。**
+
+这里的“基础系统”不是单一软件层，而是由以下部分共同构成：
+
+- 模型与任务语义；
+- 推理运行时与负载编排；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离；
+- 芯片、总线、内存、NPU、GPU、DMA 等硬件资源结构；
+- 规则兜底、安全约束与异常切换机制。
+
+## 2. 研究对象
+
+本框架的研究对象是：
+
+> **面向 AI 的实时控制基础系统。**
+
+其中：
+
+- `SylixOS` 仍然可以作为关键实验样例与基础软件样本；
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可继续作为参照平台；
+- `Linux` 与 `PREEMPT_RT Linux` 继续作为重要对照对象；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+## 3. 本框架不把什么当作研究主语
+
+### 3.1 不把硬件谱系当作研究主语
+
+`T5~T1` 五类部署形态和各类算力基础承担的是验证矩阵角色，用于组织证据、比较边界和解释场景差异。
+
+### 3.2 不把单一 RTOS 当作全部因果承担者
+
+RTOS 在本框架中承担关键作用，但不再被写成全部实时问题的唯一解决者。模型、运行时、芯片与资源结构同样影响系统边界。
+
+### 3.3 不把纯吞吐优化当作核心目标
+
+本框架关注的是人工智能目标负载、关键保障负载与系统协同三层指标同时成立的条件，而不是单一的吞吐最大化。
+
+## 4. 研究边界
+
+### 4.1 重点覆盖的系统类型
+
+- 控制端 MCU / 控制盒；
+- 设备端 SoC；
+- 边缘节点；
+- 面向任务关键场景的单机高密和集群协同平台。
+
+### 4.2 重点覆盖的问题
+
+- 关键保障负载与人工智能目标负载共存时的整体实时性；
+- Linux / RTOS / Hypervisor 的混合协同结构；
+- 统一内存、总线和异构协处理器竞争治理；
+- 小型化、低功耗和受限部署条件下的系统边界；
+- 模型推理与规则兜底共同构成的执行闭环。
+
+### 4.3 暂不作为主线的问题
+
+- 通用大模型训练集群的纯吞吐优化；
+- 面向互联网高并发服务的开放式推理平台；
+- 单纯以算法精度提升为主的模型研究；
+- 不涉及实时控制闭环的普通桌面 AI 应用。
+
+## 5. 与项目框架1的关系
+
+项目框架1把“大型跨平台 RTOS”作为研究主语，重点讨论 RTOS 在五类部署形态中的机制优势。
+
+项目框架2则把研究主语上移到“面向 AI 的实时控制基础系统”，重点讨论：
+
+- RTOS 在整个系统中的位置；
+- Linux、RTOS 与 Hypervisor 如何协同；
+- 模型推理、资源竞争与控制任务如何共同构成实时边界；
+- 企业与平台如何从 RTOS 供应方转向基础系统供应方。
+
+这两套框架可以并行维护，分别服务于不同层次的课题收敛。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/03-总课题与两个子课题的关系.md

@@ -0,0 +1,86 @@
+# 总课题与两个子课题的关系
+
+## 1. 决策记录
+
+在对 2026-09-22 会议内容、框架2当前结构和外部相关研究进行综合判断后，当前对框架2的组织方式做出如下决策：
+
+> **框架2继续保留为“面向 AI 的实时控制基础系统研究”这一总课题，不单独再分出框架3；但在框架2内部，明确提升为“一总课题 + 两个子课题 + 一个共享方法层”的结构。**
+
+这一决策的核心依据是：
+
+1. `MCU` 路线与 `边侧 SoC` 路线已经不是同一种技术问题；
+2. 但两条路线仍然服务于同一个更高层研究主语，即“面向 AI 的实时控制基础系统”；
+3. 三层边界、验证矩阵、评价框架和对照逻辑仍然具有共享性；
+4. 目录层级上如果不把两个子课题抬成一级目录，就会削弱其独立研究价值。
+
+## 2. 总课题是什么
+
+总课题回答的是：
+
+> **人工智能能力进入实时控制系统之后，基础系统如何维持系统的确定性、可预测性与整体实时边界。**
+
+这一层负责统一以下内容：
+
+- 研究主语；
+- 问题定义；
+- 三层边界；
+- 验证矩阵；
+- 对照方法；
+- 总体评价框架；
+- 总体论文和课题表达。
+
+## 3. 为什么需要两个子课题
+
+### 3.1 子课题 A：面向 MCU 的静态智能控制基础系统
+
+这一子课题主要回答：
+
+- 极小资源预算下，人工智能能力如何被静态、可分析地纳入控制系统；
+- 小模型、小算子、工具链、代码生成与芯片协同如何共同形成系统能力；
+- 低功耗、小型化与极小内存预算如何构成主边界。
+
+### 3.2 子课题 B：面向边侧 SoC 的混合实时控制基础系统
+
+这一子课题主要回答：
+
+- Linux、RTOS、Hypervisor 与 Hybrid 结构如何在同一 SoC 上协同；
+- 统一内存、总线、DMA、NPU/GPU 竞争如何被治理；
+- 控制链路、推理链路与规则兜底如何共同形成整体边界。
+
+## 4. 为什么不现在直接分出框架3
+
+当前不单独再分出框架3，主要基于三点考虑：
+
+1. **研究主语没有分裂**  
+   两个子课题仍然隶属于同一个总课题主语。
+2. **方法层高度共享**  
+   三层边界、验证矩阵和评价框架不需要重复建设。
+3. **当前阶段更适合内部分流，而不是外部分家**  
+   目前仍处于课题框架优选和收敛阶段，过早拆出框架3会增加主线分散的风险。
+
+## 5. 当前目录组织原则
+
+因此，框架2当前采用以下结构：
+
+- `00-总课题总览`
+- `10-共享理论与方法层`
+- `20-子课题A-面向MCU的静态智能控制基础系统`
+- `30-子课题B-面向边侧SoC的混合实时控制基础系统`
+- `40-综合比较与收敛`
+
+这种结构同时满足：
+
+- 总课题不散；
+- 子课题不被湮灭；
+- 后续可以继续长成独立课题；
+- 当前仍可维持统一的研究主线。
+
+## 6. 后续演化条件
+
+只有在以下条件进一步成立时，才考虑把子课题继续外扩为独立框架或独立申报方向：
+
+1. 两个子课题分别对应不同合作方、不同交付物和不同对外课题口径；
+2. 两个子课题形成了不再共享的方法层和评价体系；
+3. 论文、实验和合作推进已经自然分化为两套完整闭环。
+
+在此之前，框架2保持“一总两子”的结构是当前最稳的组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/00-整体研究框架.md

@@ -0,0 +1,238 @@
+# 面向AI的实时控制基础系统整体研究框架
+
+## 0. 核心问题
+
+本框架围绕“人工智能能力进入实时控制系统之后，基础系统如何维持整体实时边界”展开。核心判断是：
+
+> **当人工智能目标负载进入实时控制系统后，系统需要解决的已经不是单一操作系统问题，而是模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存、NPU、GPU、DMA 和规则兜底机制共同构成的整体实时性问题。`SylixOS` 可作为关键实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为参照平台。**
+
+这里有四个基础判断：
+
+1. **研究对象是面向 AI 的实时控制基础系统**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **RTOS 是关键底座，但不是全部因果的唯一承担者**；
+4. **硬件条件以验证矩阵形式组织研究证据。**
+
+本框架评估的是：当人工智能目标负载与关键保障负载共同进入系统时，基础系统如何维持控制路径、推理路径和资源路径的整体边界。
+
+---
+
+## 1. 问题空间：五类部署形态、三类系统负载与跨层实时性
+
+### 1.1 五类部署形态
+
+`T5~T1` 五类部署形态继续作为验证矩阵。
+
+| 部署形态 | 系统角色 | 主要研究关注点 |
+|---|---|---|
+| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存预算 |
+| T4 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS 协同、统一内存与带宽隔离 |
+| T3 边缘节点 | 近源推理与控制协同节点 | 多任务并发、热稳定性、边缘协同 |
+| T2 单机工作站 | 单机高密本地推理平台 | 多卡公平性、控制侧保护与资源协同 |
+| T1 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点协同、系统边界与规模扩展 |
+
+这些部署形态回答的是“在哪里验证”，而不是“什么是研究主语”。
+
+### 1.2 三类系统负载
+
+| 负载类型 | 定义 | 典型例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉识别、导航规划、故障诊断 |
+| 关键保障负载 | 维持安全与执行闭环的关键任务 | 周期控制、联锁、状态采集、执行输出 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、模型加载、通信、I/O |
+
+### 1.3 跨层实时性问题
+
+本框架中的“实时性”不再只指调度器和中断路径，而是至少同时涉及：
+
+- 模型与推理阶段时间行为；
+- 运行时与队列组织；
+- RTOS 的关键任务保障能力；
+- Linux 的生态与推理承载能力；
+- Hypervisor 的隔离与资源切分；
+- 总线、内存、DMA、NPU、GPU 等资源竞争结构；
+- 规则兜底与异常切换机制。
+
+---
+
+## 2. 分层边界：三层系统问题
+
+### 2.1 RTOS 直接控制域
+
+这一层是 RTOS 可以直接施加机制约束的部分，包括：
+
+- 关键任务调度；
+- 中断优先级与抢占关系；
+- CPU 侧线程、同步与时钟机制；
+- 恢复、隔离和关键路径治理。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 2.2 推理运行域
+
+这一层主要由模型、量化、算子、运行时和驱动共同决定，包括：
+
+- Prefill / Decode 时延结构；
+- 模型大小与量化精度；
+- KV Cache、内存组织与队列行为；
+- GPU/NPU 内部执行与框架调度。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为和资源行为。**
+
+### 2.3 系统协同域
+
+这一层是本框架的重点，包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、外存、统一内存与协处理器竞争治理；
+- 规则兜底、安全约束与异常切换；
+- 关键保障负载与人工智能目标负载之间的优先级关系。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+---
+
+## 3. 两条主要技术路线
+
+### 3.1 MCU 路线：静态分配、工具链与芯片协同
+
+MCU 路线重点关注：
+
+- 小模型、小算子与控制任务的静态编排；
+- 工具链、代码生成与开发套件；
+- 与芯片厂商的协同设计；
+- 极小资源预算下的 AI 目标负载纳入方式。
+
+这条路线的关键词是：
+
+`静态分配`、`工具链`、`开发套件`、`芯片协同`
+
+### 3.2 SoC 路线：Hybrid、Hypervisor 与整体确定性
+
+SoC 路线重点关注：
+
+- Linux 侧推理与 RTOS 侧控制的分工；
+- Hybrid 结构从“并置”升级为“协同治理”；
+- Hypervisor 的隔离、分簇和资源切分；
+- 统一内存、总线、DMA、NPU/GPU 竞争治理；
+- 控制与 AI 在同一系统中的整体确定性。
+
+这条路线的关键词是：
+
+`Hybrid`、`Hypervisor`、`隔离`、`资源治理`、`系统确定性`
+
+---
+
+## 4. 统一技术体系：五层技术栈与横向治理线
+
+本框架继续保留五层技术栈表达，但其含义从“RTOS 机制展开”进一步上升为“基础系统展开”。
+
+```
+┌───────────────────────────────────────────────────────────────┐
+│ L5 模型与任务语义层                                            │
+│ 任务语义、模型结构、量化、输出约束、业务边界                    │
+├───────────────────────────────────────────────────────────────┤
+│ L4 运行时与负载编排层                                           │
+│ 队列、准入控制、内存池、流水线、推理框架、规则兜底接口          │
+├───────────────────────────────────────────────────────────────┤
+│ L3 资源抽象与系统协同层                                         │
+│ CPU/NPU/GPU/DMA/总线/统一内存抽象、Hypervisor、资源治理        │
+├───────────────────────────────────────────────────────────────┤
+│ L2 基础软件控制层                                               │
+│ RTOS、Linux、中断、调度、同步、恢复、隔离、关键路径保护         │
+├───────────────────────────────────────────────────────────────┤
+│ L1 硬件与互联层                                                 │
+│ MCU、SoC、加速器、缓存、总线、外存、网络互联、时钟源            │
+└───────────────────────────────────────────────────────────────┘
+```
+
+横向治理线包括：安全、审计、配置版本、日志证据、时间同步、可观测性、规则兜底、异常切换和 OTA / 回滚能力。
+
+---
+
+## 5. 研究主线：整体实时边界的建立与验证
+
+本框架后续所有子方向都服务于同一个主命题：
+
+> **面向 AI 的实时控制基础系统如何在人工智能目标负载进入控制闭环后，维持系统的确定性、可预测性与整体实时边界。**
+
+围绕这个主命题，研究主线可以组织为六个方向：
+
+1. **RTOS 直接控制域的保障机制**
+2. **人工智能目标负载的时间行为建模**
+3. **系统协同域的资源隔离与治理**
+4. **MCU 路线的静态编排与工具链能力**
+5. **SoC 路线的 Hybrid / Hypervisor 协同结构**
+6. **规则兜底、异常切换与闭环安全边界**
+
+这些方向共同服务于一个判断：
+
+> **人工智能能力进入实时控制系统后，系统是否仍然有边界，以及这个边界由哪些机制共同构成。**
+
+---
+
+## 6. 评价框架：三层指标同时成立
+
+### 6.1 人工智能目标负载指标
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 6.2 关键保障负载指标
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 6.3 系统协同指标
+
+- 有效吞吐
+- `E/token` / `tokens/J`
+- 温度、热漂移与降频行为
+- 资源隔离效果
+- 恢复能力与异常切换表现
+
+因此，本框架的成功标准是：
+
+> **人工智能目标负载、关键保障负载与系统协同三层指标同时成立。**
+
+---
+
+## 7. 对照关系：Linux、PREEMPT_RT、RTOS 与混合结构
+
+后续实验与叙事可采用四类对照：
+
+| 对照组 | 含义 | 作用 |
+|---|---|---|
+| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
+| `O1` PREEMPT_RT Linux | 实时增强型 Linux | 观察增强型通用 OS 的边界 |
+| `O2` RTOS 原生配置 | RTOS 基础路径 | 观察 RTOS 底座能力 |
+| `O3` 混合基础系统配置 | Linux + RTOS + Hypervisor 或协同结构 | 观察整体协同路径的收益与代价 |
+
+这条对照线的重点，不再只是比较“谁更快”，而是比较：
+
+- 谁更能维持关键保障负载边界；
+- 谁更能承受 AI 目标负载进入后的资源竞争；
+- 谁更能形成可解释、可复现、可治理的整体系统秩序。
+
+---
+
+## 8. 预期成果
+
+1. **问题定义层**：人工智能能力进入实时控制系统后的基础系统问题定义；
+2. **分析层**：RTOS 直接控制域、推理运行域与系统协同域的边界划分方法；
+3. **机制层**：面向 Hybrid / Hypervisor / 资源治理 / 规则兜底的基础系统机制；
+4. **方法层**：覆盖 `T5~T1` 的统一验证矩阵与对照方法；
+5. **产业层**：从 RTOS 平台叙事上升到基础系统叙事的合作与产品路线；
+6. **论文层**：面向实时系统、嵌入式系统和低功耗系统方向的系统化论文与报告。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/01-RTOS直接控制域.md

@@ -0,0 +1,90 @@
+# RTOS直接控制域
+
+## 1. 主题定位
+
+在框架2中，RTOS 不再被写成全部系统问题的唯一承担者，但它仍然是关键保障负载确定性底座的核心组成部分。本文件用于明确：哪些问题属于 RTOS 可以直接控制和分析的范围，哪些问题不应继续归因到 RTOS 身上。
+
+## 2. 直接控制域的边界
+
+RTOS 直接控制域主要包括：
+
+- 周期任务、关键任务与后台任务的调度关系；
+- 中断优先级、抢占路径和线程化中断机制；
+- CPU 侧线程、同步互斥、时钟与定时器；
+- 内存锁定、关键缓冲区预分配与恢复机制；
+- 关键任务隔离、核心绑定和关键路径保护；
+- 对共享资源治理接口的直接约束能力。
+
+这一层回答的是：
+
+> **RTOS 如何在人工智能目标负载进入系统后，持续保护关键保障负载的时间边界。**
+
+## 3. 核心研究问题
+
+### 3.1 关键任务如何不被人工智能目标负载拖垮
+
+当人工智能目标负载与关键保障负载并存时，RTOS 的首要任务不是提高模型吞吐，而是确保：
+
+- 周期控制任务不失去截止期；
+- 中断链路不被模型加载、日志、I/O 和推理提交路径污染；
+- 恢复路径在异常条件下仍然可触发；
+- 控制输出始终保留优先权。
+
+### 3.2 哪些资源竞争能够由 RTOS 直接治理
+
+RTOS 可以直接治理的通常是：
+
+- CPU 时间分配；
+- 抢占关系；
+- 中断响应顺序；
+- 同步冲突；
+- 关键路径上的内核对象与内存使用方式。
+
+RTOS 不能单独决定的，则包括 GPU/NPU 内部算子执行、显存流水线、驱动内部队列与片上总线物理冲突。这些内容必须和系统协同域一起讨论。
+
+## 4. 关键机制
+
+### 4.1 调度与抢占
+
+关键保障负载应继续保持硬优先级或等价的刚性优先级结构。人工智能目标负载相关线程、提交路径和后台服务线程必须被限制在不会破坏关键任务的优先级层次中。
+
+### 4.2 中断与关键路径治理
+
+模型加载、设备中断、网络和存储路径都可能拉长关键路径。后续研究应重点观察：
+
+- 哪些中断必须线程化；
+- 哪些中断应固定到非关键核；
+- 哪些设备中断会污染关键任务核；
+- 推理提交和结果回收链路是否会引发优先级倒置。
+
+### 4.3 恢复与隔离
+
+当推理链路失稳、超时或内存耗尽时，RTOS 直接控制域需要承担：
+
+- 关键任务不受波及的隔离；
+- 降级模式触发；
+- 任务重启与恢复；
+- 对控制回路的兜底保持。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+- 恢复时间与异常切换开销
+
+这些指标构成 RTOS 直接控制域的主证据，不应和 GPU/NPU 内部执行指标混为一体。
+
+## 6. 与其他层的关系
+
+- 与 `推理运行域` 的关系：RTOS 负责保护关键路径，推理运行域负责描述 AI 目标负载本身的时间行为；
+- 与 `系统协同域` 的关系：RTOS 负责可直接治理的部分，系统协同域负责 Linux、Hypervisor 和异构资源共同造成的整体边界问题。
+
+## 7. 当前结论
+
+框架2并没有削弱 RTOS 的价值，而是把 RTOS 的价值说得更准确：
+
+> **RTOS 是关键保障负载的确定性底座，是人工智能进入实时控制系统后仍能维持秩序的直接控制层。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/02-推理运行域.md

@@ -0,0 +1,85 @@
+# 推理运行域
+
+## 1. 主题定位
+
+推理运行域用于解释人工智能目标负载本身的时间行为、资源行为和优化空间。框架2强调，大模型与智能算法的实时问题不能完全归因到 RTOS 身上，原因就在于推理运行域本身已经带有很强的结构性时间特征。
+
+## 2. 推理运行域包含什么
+
+这一层主要包括：
+
+- 模型结构与参数规模；
+- 量化方式与数值精度；
+- Prefill / Decode 两阶段时间特征；
+- KV Cache 生命周期与内存组织；
+- 推理框架队列、批处理与上下文管理；
+- 算子实现、驱动路径和设备执行接口。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、内存行为和资源竞争特征。**
+
+## 3. 为什么这一层不能被省略
+
+如果把所有实时性问题都写成 RTOS 问题，就会忽略以下事实：
+
+- 不同模型大小对内存和时延的影响完全不同；
+- 量化方式会显著改变推理峰值、稳定性和能效；
+- 同一硬件上，不同框架和不同算子组合会带来巨大差异；
+- Decode 阶段与 Prefill 阶段的时间结构并不相同；
+- 推理框架内部队列策略会直接影响首响应时间与尾延迟。
+
+因此，推理运行域必须被单独分析。
+
+## 4. 核心研究问题
+
+### 4.1 模型时间行为如何进入系统分析
+
+后续研究需要回答：
+
+- 不同模型在 Prefill 与 Decode 阶段分别造成什么样的时间分布；
+- 哪些阶段是延迟敏感的；
+- 哪些阶段可以延后、限流或降级；
+- 哪些阶段会对关键保障负载形成直接冲击。
+
+### 4.2 内存与缓存如何形成主瓶颈
+
+对于设备端 SoC 和边缘节点，KV Cache、统一内存与 DMA 搬运常常比算力本身更早成为主瓶颈。  
+因此，这一层需要重点分析：
+
+- 权重、KV Cache、工作区和运行时缓冲的占用边界；
+- 模型切换、上下文增长和并发请求如何改变内存行为；
+- 哪些内存组织方式更适合和关键保障负载并存。
+
+### 4.3 量化与算子如何影响实时边界
+
+量化和算子优化不仅影响吞吐，还影响：
+
+- 首响应时延；
+- 长稳阶段的功耗与热状态；
+- 设备端资源占用；
+- 能否在受限部署条件下持续运行。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性与任务完成率
+- 峰值内存、工作区与长稳退化
+- 单位任务能耗与热漂移
+
+这些指标构成 AI 目标负载本身的主证据。
+
+## 6. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：推理运行域描述 AI 目标负载自身行为，RTOS 控制域负责保护关键任务不被这些行为拖垮；
+- 与 `系统协同域` 的关系：推理运行域给出负载输入，系统协同域回答这些负载如何与 Linux、Hypervisor 和异构资源共同形成整体边界。
+
+## 7. 当前结论
+
+框架2保留 RTOS 的重要性，但明确要求把推理运行域单独提出，是因为：
+
+> **只有先把人工智能目标负载本身的时间结构说清楚，后续系统边界分析才不会落回单因果叙事。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/03-系统协同域.md

@@ -0,0 +1,107 @@
+# 系统协同域
+
+## 1. 主题定位
+
+系统协同域是框架2相对框架1最大的变化之一。它不再把问题停留在“RTOS 是否更强”，而是直接讨论：当 Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU、GPU 和规则兜底机制共同存在时，整体实时性如何被建立、维持和验证。
+
+## 2. 为什么系统协同域是主问题
+
+会议中最关键的判断之一是：人工智能进入实时控制系统后的真实问题，已经超出了单一操作系统边界。原因在于：
+
+- 推理生态通常离不开 Linux；
+- 关键保障负载需要 RTOS 或等价实时控制底座；
+- 设备端 SoC 常常采用统一内存和异构协处理器；
+- Hypervisor 与隔离机制直接影响资源边界；
+- 规则兜底与安全约束必须与模型输出共同工作。
+
+因此，系统协同域回答的是：
+
+> **在混合结构中，整体秩序如何形成。**
+
+## 3. 核心问题
+
+### 3.1 Linux 与 RTOS 如何分工
+
+Linux 更适合承担：
+
+- 推理框架与模型生态；
+- 容器、服务和工具链支持；
+- 非关键路径的 AI 相关运行任务。
+
+RTOS 更适合承担：
+
+- 关键保障负载；
+- 控制闭环中的刚性时间边界；
+- 关键路径上的确定性治理。
+
+系统协同域的核心，不是让两者彼此替代，而是让两者分工清楚、边界稳定。
+
+### 3.2 Hypervisor 在这里起什么作用
+
+Hypervisor 不是附属选项，而是重要研究对象之一。它至少影响：
+
+- 核心隔离和资源切分；
+- 中断路由和设备访问边界；
+- 共享内存与通信路径；
+- 异常传播与恢复策略。
+
+在设备端 SoC 和边缘节点上，Hypervisor 往往是把“共存”升级为“可治理共存”的关键层。
+
+### 3.3 异构资源竞争如何进入系统分析
+
+在 SoC 和边缘节点上，整体边界往往由以下竞争共同决定：
+
+- CPU 与 NPU/GPU 的统一内存争用；
+- DMA 与 CPU 访存冲突；
+- 总线与缓存竞争；
+- 模型加载与控制 I/O 共享带宽；
+- 后台服务与关键任务共享中断和核资源。
+
+这些问题不能只在驱动层或 RTOS 层单独解释，必须进入系统协同域。
+
+## 4. 关键机制
+
+### 4.1 资源隔离
+
+后续研究应重点观察：
+
+- CPU 核和关键任务核是否可隔离；
+- 设备中断是否可隔离；
+- 共享内存和 DMA 缓冲是否可限定边界；
+- 模型提交路径是否会挤占控制路径资源。
+
+### 4.2 协同治理
+
+协同治理关注的是：
+
+- 推理与控制如何分层；
+- 哪些事件由 Linux 负责，哪些由 RTOS 负责；
+- 资源冲突发生时谁拥有优先权；
+- 发生过载和异常时系统如何降级与恢复。
+
+### 4.3 证据组织
+
+系统协同域的证据不能只看某一个线程或某一个服务，而需要同时观察：
+
+- 人工智能目标负载层；
+- 关键保障负载层；
+- 系统协同层。
+
+只有三层指标同时成立，才能说明协同结构是有效的。
+
+## 5. 对照方式
+
+框架2的主对照建议采用：
+
+- `O0` 普通 Linux
+- `O1` PREEMPT_RT Linux
+- `O2` RTOS 原生配置
+- `O3` 混合基础系统配置
+
+其中 `O3` 不再只是附属架构，而是系统协同域的主实验路径之一。
+
+## 6. 当前结论
+
+框架2真正抬升的，不只是标题口径，而是研究主线本身：
+
+> **系统协同域使项目从“RTOS 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/04-规则兜底与控制闭环.md

@@ -0,0 +1,80 @@
+# 规则兜底与控制闭环
+
+## 1. 主题定位
+
+人工智能能力进入实时控制系统后，系统不可能只靠模型输出维持闭环。框架2因此把“规则兜底与控制闭环”单独列为一条研究线，用来说明模型推理、控制逻辑、安全约束和异常切换如何共同维持系统边界。
+
+## 2. 为什么必须单独提出这一层
+
+如果只讨论模型推理和操作系统，容易忽略一个关键事实：
+
+- 模型输出可能延迟；
+- 模型输出可能不稳定；
+- 模型输出可能不满足控制安全边界；
+- 系统必须在异常条件下退回到规则与安全约束支撑的路径。
+
+因此，真实系统需要的是“模型驱动 + 规则兜底”的混合闭环。
+
+## 3. 核心研究问题
+
+### 3.1 模型与规则如何分工
+
+模型更适合承担：
+
+- 感知理解；
+- 语义识别；
+- 规划建议；
+- 异常模式发现。
+
+规则层更适合承担：
+
+- 安全边界检查；
+- 优先级裁决；
+- 异常降级；
+- 默认动作触发；
+- 恢复条件判定。
+
+### 3.2 闭环如何建立
+
+框架2中的闭环至少包括：
+
+1. 感知输入；
+2. 推理与规划；
+3. 规则检查；
+4. 执行输出；
+5. 状态回读；
+6. 异常切换与恢复。
+
+只有这条链路完整，系统才是真正的实时控制系统，而不是带 AI 的普通服务系统。
+
+### 3.3 异常切换如何进入系统实验
+
+后续实验不仅要测正常场景，还要测：
+
+- 模型超时；
+- 队列过载；
+- 设备异常；
+- 推理链路中断；
+- 控制路径回退。
+
+这些内容构成规则兜底层的核心证据。
+
+## 4. 评价重点
+
+这一层重点观察：
+
+- 异常切换时间；
+- 规则触发正确性；
+- 降级后的关键任务保持情况；
+- 恢复后的系统稳定性；
+- 模型与规则共同工作时的整体边界。
+
+## 5. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：RTOS 负责底层调度与恢复执行；
+- 与 `推理运行域` 的关系：模型提供感知和规划能力；
+- 与 `系统协同域` 的关系：规则兜底把混合系统真正闭合成可执行的控制系统。
+
+## 6. 当前结论
+
+> **没有规则兜底与异常切换，人工智能进入实时控制系统就只是“把模型接进来了”；只有闭环建立起来，基础系统课题才真正成立。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/05-研究逻辑说明.md

@@ -0,0 +1,129 @@
+# 面向AI的实时控制基础系统研究逻辑说明
+
+## 1. 文档目的
+
+本文用于解释框架2的研究逻辑，重点回答三个问题：
+
+1. 研究对象从 RTOS 平台上升到基础系统之后，实验如何组织；
+2. `T5~T1` 验证矩阵如何继续保留，同时不替代研究主语；
+3. Linux、RTOS、Hypervisor 与混合结构如何进入统一对照框架。
+
+## 2. 研究对象
+
+本框架的研究对象是：
+
+> **面向 AI 的实时控制基础系统。**
+
+其核心不是某一个单一软件层，而是下面三层共同构成的系统：
+
+- **RTOS 直接控制域**：关键任务调度、中断、同步、恢复和控制路径保护；
+- **推理运行域**：模型、量化、算子、推理框架、驱动与运行时队列；
+- **系统协同域**：Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU/GPU 和资源治理结构。
+
+## 3. T5~T1 验证矩阵的角色
+
+`T5~T1` 五类部署形态继续承担三项作用：
+
+1. **验证矩阵**：在不同资源与系统角色下检验同一问题是否成立；
+2. **证据组织框架**：把结论放回统一谱系中观察边界和收窄区间；
+3. **产业解释接口**：让不同部署位置都能找到现实对应场景。
+
+在框架2中，`T5~T1` 回答的是“在哪里验证”，而不是“研究对象是什么”。
+
+## 4. 两条技术路线如何进入实验
+
+### 4.1 MCU 路线
+
+MCU 路线更适合围绕以下内容组织实验：
+
+- 小模型与控制任务的静态编排；
+- 工具链和开发套件的能力；
+- 极小资源预算下的任务边界；
+- 与芯片规格、片上资源和开发流程的协同关系。
+
+### 4.2 SoC 路线
+
+SoC 路线更适合围绕以下内容组织实验：
+
+- Linux / RTOS 的角色分工；
+- Hybrid 结构与 Hypervisor 的隔离方式；
+- 统一内存、总线和异构协处理器竞争；
+- 推理链路与控制链路并存时的整体实时性。
+
+## 5. 对照逻辑
+
+框架2的主对照不再只限于“普通 Linux / PREEMPT_RT / RTOS”，而是扩展为：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 |
+| `O2` | RTOS 原生配置 | RTOS 底座能力 |
+| `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 |
+
+必要时还可以继续细分 `O3` 的不同协同版本，用于比较不同 Hybrid 结构的收益与代价。
+
+## 6. 核心实验顺序
+
+框架2的实验顺序建议如下：
+
+1. **系统就绪性确认**：设备、驱动、模型、测量链路和基础软件栈可用；
+2. **单域基线测试**：分别测试推理运行域与关键保障负载的基础行为；
+3. **双域并存测试**：测试人工智能目标负载与关键保障负载共存时的边界；
+4. **协同结构测试**：引入 Linux / RTOS / Hypervisor 混合结构，比较不同协同方式；
+5. **极限与恢复测试**：引入突发负载、长稳运行、异常切换和规则兜底场景；
+6. **跨档位回收分析**：把结论放回 `T5~T1` 观察适用区间与失效边界。
+
+## 7. 核心指标
+
+框架2仍然采用三层指标结构：
+
+### 7.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+
+### 7.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 7.3 系统协同层
+
+- 有效吞吐
+- 资源隔离效果
+- `E/token`
+- 温度与热漂移
+- 异常切换与恢复能力
+
+## 8. 与框架1的关键差别
+
+框架1的重点是：
+
+- RTOS 作为研究主语；
+- 六个 RTOS 机制方向；
+- 观察 RTOS 在五类部署形态中的系统优势。
+
+框架2的重点是：
+
+- 基础系统作为研究主语；
+- 三层边界与两条技术路线；
+- 观察人工智能进入实时控制系统后，整体边界如何成立。
+
+因此，框架2更适合承接 2026-09-22 会议中的重定义判断。
+
+## 9. 当前状态
+
+框架2当前已经形成一条完整的逻辑链：
+
+1. 研究对象上移到“面向 AI 的实时控制基础系统”；
+2. 用三层边界划分研究问题；
+3. 用 MCU 路线与 SoC 路线组织不同系统结构；
+4. 用 `T5~T1` 验证矩阵组织证据；
+5. 用 Linux / RTOS / Hypervisor / 混合结构建立统一对照。
+
+在此基础上，后续可以继续向更细的实验子文档、联合研究方材料和正式交付物展开。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/06-基础设备与算力基础.md

@@ -0,0 +1,100 @@
+# 面向AI的实时控制基础系统基础设备与算力基础
+
+## 1. 文档目的
+
+本文用于说明框架2中的验证矩阵如何组织。这里继续保留 `T5~T1` 五类部署形态，但其作用是“验证矩阵”，不是研究主语。本文件同时把 `MCU 路线` 与 `SoC 路线` 显式放进设备与算力组织逻辑中。
+
+## 2. 验证矩阵的组织原则
+
+### 2.1 三条组织原则
+
+1. **部署形态优先于硬件型号**  
+   先回答系统在什么位置运行，再回答用什么设备验证。
+2. **技术路线优先于单点性能**  
+   先区分 MCU 路线与 SoC 路线，再讨论容量、功耗和算力差异。
+3. **基础系统问题优先于纯吞吐问题**  
+   优先选择能暴露控制路径、推理路径与资源竞争关系的设备与场景。
+
+### 2.2 五类部署形态
+
+| 部署形态 | 系统角色 | 主要关注点 |
+|---|---|---|
+| `T5` 控制端 | 极紧资源预算下的控制节点 | 静态编排、低功耗、极小内存 |
+| `T4` 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS/Hypervisor 协同、统一内存竞争 |
+| `T3` 边缘节点 | 设备附近的近源协同节点 | 多任务并发、热稳定性、边缘协同 |
+| `T2` 单机工作站 | 单机高密本地推理平台 | 多卡公平性、关键任务保护与系统协同 |
+| `T1` 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点边界、编排与规模扩展 |
+
+## 3. 两条技术路线在矩阵中的位置
+
+### 3.1 MCU 路线
+
+MCU 路线主要对应 `T5`，重点设备类型包括：
+
+- MCU 控制器；
+- 轻量控制盒；
+- 极小资源预算下的端侧控制节点。
+
+它承担的问题是：
+
+- 小模型与控制任务如何静态编排；
+- 芯片工具链和开发套件如何支撑部署；
+- 极小内存、功耗与外设约束下能否维持闭环。
+
+### 3.2 SoC 路线
+
+SoC 路线主要对应 `T4`，并向 `T3` 延伸。重点设备类型包括：
+
+- 工业 SoC；
+- 车规 SoC；
+- 设备端 AI 模组；
+- 边缘异构平台。
+
+它承担的问题是：
+
+- Linux 与 RTOS 的协同关系；
+- Hypervisor 的隔离与资源切分；
+- 统一内存、DMA、总线与 NPU/GPU 竞争；
+- 设备级功耗、散热与体积约束下的整体确定性。
+
+## 4. 当前设备锚点
+
+### 4.1 已有核心平台
+
+| 平台 | 对应位置 | 当前价值 |
+|---|---|---|
+| RK3588 16 GB | `T4-L` / 受限配置可模拟 `T5-H` | 设备端 SoC 主样例；同时可承接小型化与低功耗观察 |
+| 4×V100 服务器 | `T2-L` | 单机高密推理与关键保障负载保护的对照窗口 |
+
+### 4.2 条件扩展平台
+
+| 平台方向 | 对应位置 | 主要价值 |
+|---|---|---|
+| RK3568 / 同类控制盒 | `T5-L` | MCU / 轻量控制路线主验证窗口 |
+| RK3576 / 同类设备 | `T5-M` 或 `T4-L` 衔接档 | 中间资源档位与工具链观察窗口 |
+| Jetson / IGX / 工控边缘节点 | `T3` / `T4-M` | SoC 向边缘协同扩展的窗口 |
+| 更高端单机多卡或多节点平台 | `T2-H` / `T1` | 观察规模扩展和协同边界收窄区间 |
+
+## 5. 为什么框架2仍然保留 `T2/T1`
+
+框架2并不把 `T2/T1` 当作 RTOS 优势的天然主战场，但仍保留其验证价值：
+
+- 它们可以暴露 AI 目标负载的运行时复杂性；
+- 它们可以观察关键保障负载在高密度 AI 负载下是否仍可被保护；
+- 它们可以为系统协同域提供资源竞争、队列行为和规模边界证据。
+
+因此，`T2/T1` 在框架2中的角色更接近“上界参照窗口”，而不是研究主语。
+
+## 6. 当前建议
+
+对框架2而言，最值得优先强化的设备与算力主线是：
+
+1. **`T5` MCU / 控制端路线**
+2. **`T4` 设备端 SoC 路线**
+3. **`T3` 边缘协同路线**
+
+这三类场景最能体现“基础系统主语”与“系统协同边界”。
+
+## 7. 当前结论
+
+> **框架2中的设备与算力组织方式，不是为了堆出更大的硬件谱系，而是为了在不同资源条件下，把 MCU 路线与 SoC 路线的基础系统问题显式暴露出来。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/README.md

@@ -0,0 +1,31 @@
+# 共享理论与方法层
+
+本目录用于承载框架2中由总课题统一维护、并由两个子课题共同共享的理论和方法内容。
+
+## 本层内容
+
+1. [00-整体研究框架.md](./00-整体研究框架.md)
+2. [01-RTOS直接控制域.md](./01-RTOS直接控制域.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)
+
+## 本层作用
+
+这一层统一负责：
+
+- 研究主语与问题定义；
+- 三层边界；
+- 统一验证矩阵；
+- 统一评价框架；
+- 统一对照逻辑；
+- 总体方法论表达。
+
+## 与两个子课题的关系
+
+- 子课题 A 重点继承其中与 `MCU`、静态编排、低功耗和工具链相关的部分；
+- 子课题 B 重点继承其中与 `Linux/RTOS/Hypervisor`、资源隔离和系统协同相关的部分。
+
+这意味着两个子课题虽然分别展开，但不需要各自重复建设方法层。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-子课题定义.md

@@ -0,0 +1,26 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向 MCU 的静态智能控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在 MCU 级资源预算下，人工智能能力如何通过静态编排、工具链、代码生成和芯片协同，被纳入可分析、可验证、可部署的实时控制系统。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- 小模型、小算子与控制任务的静态共存；
+- 工具链、部署链路和代码生成能力；
+- 极小内存、极低功耗和快速启动场景；
+- 与芯片厂商和开发套件的协同。
+
+本子课题不把高动态 Linux 生态、复杂虚拟化结构和大规模混合系统作为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第一个子课题，重点对应 `T5` 控制端，也是总课题中最能体现“小型化、低功耗、静态部署”特征的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/01-研究问题与适用场景.md

@@ -0,0 +1,30 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. 小模型与关键控制任务如何静态编排；
+2. 工具链如何把模型部署、资源预算和代码生成联成闭环；
+3. 芯片规格、运行时约束和控制边界如何共同决定系统能力；
+4. 低功耗、小型化和极小内存预算下，系统成立边界在哪里。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 控制器；
+- 轻量控制盒；
+- 小型工业控制节点；
+- 电池供电或功耗严苛设备；
+- 需要毫秒级或更紧周期控制的端侧场景。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `RTOS 直接控制域`
+- `推理运行域`
+- `基础设备与算力基础` 中的 `T5` 部分
+
+但会弱化 `系统协同域` 中面向大 SoC 混合结构的部分。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md

@@ -0,0 +1,63 @@
+# MCU路线：静态分配与工具链协同
+
+## 1. 主题定位
+
+MCU 路线并不是“把大模型缩小以后放进 MCU”这么简单。在框架2中，MCU 路线代表的是另一类完全不同的问题结构：资源极端受限、动态空间极小、工具链和静态编排比在线调度策略更重要。
+
+## 2. MCU 路线的系统特征
+
+这一路线通常具有以下特点：
+
+- 可用内存极小；
+- 时钟和算力预算刚性；
+- 外设和控制链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖芯片 SDK、代码生成工具和开发套件。
+
+因此，MCU 路线更接近“静态可分析系统中的 AI 能力纳入问题”。
+
+## 3. 核心研究问题
+
+### 3.1 小模型如何进入静态编排体系
+
+MCU 路线重点不是追求通用大模型能力，而是研究：
+
+- 哪些轻量模型可以被稳定纳入控制系统；
+- 小模型、小算子与控制任务如何离线编排；
+- 预分配、静态内存池和固定执行窗口如何设计。
+
+### 3.2 工具链为什么比单点机制更重要
+
+在 MCU 路线上，真正决定工程落地效率的常常不是调度策略，而是：
+
+- 模型裁剪与转换工具；
+- 自动代码生成能力；
+- 内存预算与部署检查工具；
+- 芯片级软件开发套件。
+
+因此，MCU 路线天然更强调“工具链能力”。
+
+### 3.3 芯片协同如何进入研究主线
+
+对于 MCU 场景，芯片规格本身就会限制可用模型、缓冲区与时延上界。后续研究需要回答：
+
+- 哪些 AI 需求会反向定义 MCU 和端侧芯片规格；
+- 哪些片上资源是决定性瓶颈；
+- 开发套件如何把这些约束显式化。
+
+## 4. 评价重点
+
+MCU 路线重点观察：
+
+- 关键保障负载能否稳定维持；
+- 小模型能否在固定资源预算中运行；
+- 工具链是否能给出可分析、可复现的部署边界；
+- 功耗、体积和散热预算是否同时满足。
+
+## 5. 与框架2的关系
+
+MCU 路线主要对应 `T5` 控制端，也是框架2中最能体现“小型化、低功耗、工具链协同”特征的部分。它为整个基础系统课题提供了一个约束极强、边界清晰的验证窗口。
+
+## 6. 当前结论
+
+> **MCU 路线的主问题不是“大模型如何跑进去”，而是人工智能能力如何在极端受限条件下，被静态、可分析地纳入实时控制系统。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md

@@ -0,0 +1,28 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- 静态内存预算是否成立；
+- 控制任务截止期是否维持；
+- 小模型推理是否能在固定窗口内完成；
+- 功耗、热状态和启动时间是否满足约束。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. 小模型与控制任务共存实验；
+2. 静态内存池和固定执行窗口实验；
+3. 工具链生成结果与手工部署结果对比；
+4. 低功耗与长稳运行实验。
+
+## 3. 指标重点
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 单次推理时延
+- 峰值内存占用
+- 启动时间
+- `E/inference`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/04-预期成果与论文方向.md

@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向 MCU 的静态智能控制问题定义；
+2. 小模型与控制任务静态编排方法；
+3. 工具链、代码生成与部署检查框架；
+4. 低功耗、小型化场景下的系统边界证据。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- TinyML / Edge AI on MCU
+- 低功耗嵌入式智能系统
+- 静态部署与工具链协同
+- 实时控制中的小模型纳入问题

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/05-合作方式与产业落点.md

@@ -0,0 +1,28 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- MCU / 控制芯片厂商；
+- 开发套件和工具链团队；
+- 小型化控制设备厂商；
+- 对功耗和体积高度敏感的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 芯片与工具链条件梳理；
+2. 静态部署链路共建；
+3. 小规模样机验证；
+4. 工具链与方法沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 开发套件；
+- 芯片协同方案；
+- 小型控制设备智能化升级；
+- 低功耗端侧部署方法。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md

@@ -0,0 +1,24 @@
+# 子课题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)
+
+## 当前特点
+
+本子课题的关键词是：
+
+`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-子课题定义.md

@@ -0,0 +1,27 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向边侧 SoC 的混合实时控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构、统一内存和异构协处理器如何共同维持控制路径与推理路径的整体实时边界。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- Linux 与 RTOS 的分工；
+- Hypervisor 与隔离机制；
+- Hybrid 升级为协同治理结构；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与闭环安全边界。
+
+本子课题不以极小资源 MCU 的静态部署问题为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第二个子课题，重点对应 `T4/T3`，也是总课题中最能体现混合结构、系统协同和边侧 SoC 真实工程复杂度的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/01-研究问题与适用场景.md

@@ -0,0 +1,29 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. Linux 与 RTOS 如何在同一 SoC 上分工；
+2. Hypervisor 与 Hybrid 结构如何提升整体可治理性；
+3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析；
+4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 设备端 SoC；
+- 工业边缘节点；
+- 车载或机器人边侧平台；
+- 同时承载控制与 AI 推理的异构系统。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `系统协同域`
+- `规则兜底与控制闭环`
+- `基础设备与算力基础` 中的 `T4/T3` 部分
+
+同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md

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

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/03-实验设计与验证方法.md

@@ -0,0 +1,29 @@
+# 实验设计与验证方法
+
+## 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`
+- 资源隔离效果
+- 温度、热漂移与恢复时间

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/04-预期成果与论文方向.md

@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 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 协同结构与实时边界

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/05-合作方式与产业落点.md

@@ -0,0 +1,29 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- SoC / 板级平台厂商；
+- Hypervisor / mixed-criticality 基础软件团队；
+- 工业边缘和机器人设备团队；
+- 同时承载 AI 与控制任务的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 平台条件与资源结构梳理；
+2. Linux / RTOS / Hypervisor 分工设计；
+3. 板级实验与隔离验证；
+4. 规则兜底和闭环安全验证；
+5. 系统协同证据沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 边侧 SoC 参考架构；
+- 混合基础系统方案；
+- Hypervisor 协同部署方法；
+- 设备端 AI + 控制一体化平台路线。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md

@@ -0,0 +1,24 @@
+# 子课题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`、`统一内存`、`资源隔离`、`系统协同`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/01-统一实验设计与验证骨架.md

@@ -0,0 +1,119 @@
+# 面向AI的实时控制基础系统实验设计
+
+## 1. 实验目标
+
+框架2的实验目标不是单纯比较“RTOS 比 Linux 快多少”，而是比较在人工智能目标负载进入实时控制系统后，不同基础系统结构能否同时维持：
+
+1. **人工智能目标负载的时效性与功能有效性**
+2. **关键保障负载的时间边界**
+3. **系统协同层的资源秩序、恢复能力与解释性**
+
+## 2. 研究问题
+
+| 编号 | 研究问题 | 核心观察量 |
+|---|---|---|
+| `RQ1` | RTOS 直接控制域在 AI 目标负载进入后还能维持多强的关键保障边界 | `deadline miss ratio`、`P99/P99.9 jitter`、外部接口响应 |
+| `RQ2` | 推理运行域的模型、量化、框架和内存组织如何改变整体系统边界 | `TTFT/TPOT`、峰值内存、长稳退化 |
+| `RQ3` | Linux / RTOS / Hypervisor 混合结构能否比单一系统结构提供更稳定的整体边界 | 三层指标同时达标情况、恢复与隔离效果 |
+| `RQ4` | MCU 路线与 SoC 路线的边界分别是什么 | 静态编排能力、统一内存竞争、功耗与体积约束下的成立区间 |
+
+## 3. 对照结构
+
+框架2的主对照组如下：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 |
+| `O2` | RTOS 原生配置 | RTOS 直接控制域能力 |
+| `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 |
+
+必要时可继续细分：
+
+- `O3a` 无 Hypervisor 的双系统结构
+- `O3b` 带 Hypervisor 的隔离结构
+- `O3c` 加入规则兜底与异常切换的完整结构
+
+## 4. 场景编号
+
+| 编号 | 场景 | 目的 |
+|---|---|---|
+| `L0` | 仅关键保障负载 | 观察关键保障负载下界 |
+| `L1` | 仅人工智能目标负载 | 观察 AI 目标负载独立行为 |
+| `L2` | 关键保障负载 + AI 目标负载 | 核心双目标场景 |
+| `L3` | `L2` + CPU / 中断竞争 | 观察 RTOS 直接控制域边界 |
+| `L4` | `L2` + 内存 / DMA / 总线竞争 | 观察系统协同域边界 |
+| `L5` | `L2` + 网络 / 存储 / 模型加载 | 观察运行时与后台服务影响 |
+| `L6` | `L2` + 规则兜底 / 降级切换 | 观察闭环安全边界 |
+| `L7` | `L2` + 突发 / 过载 / 恢复 | 观察长稳、异常与恢复能力 |
+
+## 5. 实验单元
+
+| 编号 | 实验单元 | 主要覆盖问题 |
+|---|---|---|
+| `E0` | 设备、驱动与基础软件准入 | 全部 |
+| `E1` | RTOS 直接控制域微基准 | `RQ1` |
+| `E2` | 推理运行域基线 | `RQ2` |
+| `E3` | 双目标共存对照 | `RQ1/RQ2` |
+| `E4` | 混合结构协同对照 | `RQ3` |
+| `E5` | MCU 路线静态编排实验 | `RQ4` |
+| `E6` | SoC 路线统一内存与总线竞争实验 | `RQ3/RQ4` |
+| `E7` | 规则兜底与异常切换实验 | `RQ3` |
+| `E8` | 长稳、热状态与恢复实验 | `RQ2/RQ3/RQ4` |
+
+## 6. 分路线实验重点
+
+### 6.1 MCU 路线
+
+MCU 路线优先组织：
+
+- 小模型 / 小算子与控制任务静态编排；
+- 固定内存池与固定执行窗口；
+- 开发套件、代码生成与部署检查能力；
+- 极低功耗与极小内存条件下的成立区间。
+
+### 6.2 SoC 路线
+
+SoC 路线优先组织：
+
+- Linux / RTOS 的分工；
+- Hypervisor 资源切分；
+- 统一内存、DMA、总线和 NPU/GPU 竞争；
+- 设备级受限散热、受限功耗与长稳边界。
+
+## 7. 指标结构
+
+### 7.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 7.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 7.3 系统协同层
+
+- 有效吞吐
+- 资源隔离效果
+- `E/token`
+- 温度与热漂移
+- 异常切换与恢复时间
+
+## 8. 解释边界
+
+框架2特别强调三条解释边界：
+
+1. **GPU/NPU 内部执行行为不直接等价于 RTOS 收益**
+2. **混合结构的收益必须拆分为 RTOS 收益、协同结构收益和运行时收益**
+3. **MCU 路线与 SoC 路线的结论不得直接互相替代**
+
+## 9. 当前结论
+
+> **框架2的实验设计，不再围绕“单系统性能竞赛”组织，而是围绕“人工智能进入实时控制系统后的整体边界是否成立”来组织。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/02-总课题论文写作规划.md

@@ -0,0 +1,143 @@
+# 论文写作规划 — 面向AI的实时控制基础系统研究
+
+> **版本**: v0.1
+> **定位**: 框架2对应的候选论文规划稿
+> **目标**: 把“人工智能进入实时控制系统后，基础系统如何维持整体实时边界”组织成可写作、可实验、可比较的论文结构
+
+## 0. 文章定位与核心贡献
+
+### 0.1 一句话定位
+
+> **围绕人工智能目标负载进入实时控制系统后的整体边界问题，系统研究模型、运行时、RTOS、Linux、Hypervisor 与异构资源结构如何共同决定系统的确定性、可预测性与实时性表现。**
+
+### 0.2 核心贡献
+
+| 编号 | 贡献 |
+|---|---|
+| `C1` | 提出“面向 AI 的实时控制基础系统”这一问题定义与三层边界框架 |
+| `C2` | 给出 MCU 路线与 SoC 路线并行的统一验证矩阵 |
+| `C3` | 给出 Linux / RTOS / Hypervisor / 混合结构的系统级对照方法 |
+| `C4` | 给出规则兜底、异常切换与闭环安全边界的实验组织方式 |
+
+## 1. 文章整体结构
+
+```
+第1章  引言
+第2章  问题背景与相关工作
+第3章  面向AI的实时控制基础系统问题定义
+第4章  三层边界：RTOS控制域、推理运行域、系统协同域
+第5章  MCU路线与SoC路线
+第6章  实验方法学与对照结构
+第7章  实验结果
+第8章  深入分析与边界讨论
+第9章  产业定位与系统意义
+第10章 结论与展望
+```
+
+## 2. 各章重点
+
+### 第1章 引言
+
+重点说明：
+
+- 人工智能进入实时控制系统后，问题已经跨层展开；
+- 单纯用“RTOS 优于 Linux”不足以覆盖真实系统问题；
+- 需要一个“基础系统主语”的新框架。
+
+### 第2章 问题背景与相关工作
+
+重点说明：
+
+- AI 目标负载的时间行为与资源行为；
+- RTOS 的直接价值；
+- Linux 与 PREEMPT_RT 的边界；
+- 现有研究为什么很少真正覆盖混合系统。
+
+### 第3章 问题定义
+
+重点说明：
+
+- 什么是“面向 AI 的实时控制基础系统”；
+- 为什么研究对象要从 RTOS 平台上移；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+### 第4章 三层边界
+
+重点说明：
+
+- RTOS 直接控制域；
+- 推理运行域；
+- 系统协同域。
+
+这一章是框架2的核心理论骨架。
+
+### 第5章 MCU 路线与 SoC 路线
+
+重点说明：
+
+- MCU 路线为什么强调静态编排和工具链；
+- SoC 路线为什么强调 Hybrid、Hypervisor 和统一内存竞争；
+- 两条路线如何分别组织实验。
+
+### 第6章 实验方法学与对照结构
+
+重点说明：
+
+- `O0/O1/O2/O3` 对照组；
+- `L0~L7` 场景编号；
+- `E0~E8` 实验单元；
+- 三层指标与解释边界。
+
+### 第7章 实验结果
+
+重点按三条主线展开：
+
+1. RTOS 直接控制域结果
+2. 推理运行域结果
+3. 系统协同域结果
+
+并比较：
+
+- MCU 路线与 SoC 路线；
+- 原生系统结构与混合结构；
+- 有无规则兜底时的闭环差异。
+
+### 第8章 深入分析与边界讨论
+
+重点分析：
+
+- 哪些边界由 RTOS 直接贡献；
+- 哪些边界由协同结构贡献；
+- 哪些结论只在 MCU 或 SoC 路线成立；
+- 哪些情况下混合结构收益明显，哪些情况下收益收窄。
+
+### 第9章 产业定位与系统意义
+
+这一章是框架2相对框架1新增的重要内容。重点讨论：
+
+- 企业如何从 RTOS 供应方转向基础系统供应方；
+- 基础系统叙事如何替代单点适配叙事；
+- 这一转向对联合研究与产业化路径的意义。
+
+### 第10章 结论与展望
+
+重点总结：
+
+- 人工智能进入实时控制系统后的主问题是什么；
+- 基础系统主语为什么比 RTOS 单主语更准确；
+- 后续在工具链、体系结构与协同治理上还有哪些扩展方向。
+
+## 3. 研究问题到实验映射
+
+| 研究问题 | 主要实验单元 | 主要章节 |
+|---|---|---|
+| `RQ1` RTOS 直接控制域边界 | `E1`、`E3`、`E8` | 第4、7、8章 |
+| `RQ2` 推理运行域时间行为 | `E2`、`E3`、`E8` | 第4、6、7章 |
+| `RQ3` 系统协同域结构收益 | `E4`、`E6`、`E7`、`E8` | 第4、6、7、8章 |
+| `RQ4` MCU / SoC 双路线边界 | `E5`、`E6`、`E8` | 第5、7、8章 |
+
+## 4. 当前结论
+
+框架2的论文规划和框架1最大的不同，不是换了一个标题，而是换了整篇文章的主语：
+
+> **论文不再只回答“RTOS 在 AI 任务下是否更优”，而是回答“人工智能进入实时控制系统后，基础系统如何共同维持边界”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/03-两个子课题的共同问题.md

@@ -0,0 +1,26 @@
+# 两个子课题的共同问题
+
+## 1. 共同主语
+
+两个子课题共同服务于同一个总课题主语：
+
+> **面向 AI 的实时控制基础系统。**
+
+## 2. 共同方法层
+
+两个子课题共同依赖：
+
+- 三层边界；
+- 三类系统负载；
+- `T5~T1` 验证矩阵；
+- 统一评价框架；
+- 对照逻辑与规则兜底思想。
+
+## 3. 共同科学问题
+
+二者都需要回答：
+
+- AI 目标负载如何进入控制系统；
+- 关键保障负载如何继续保持边界；
+- 系统边界由哪些机制共同构成；
+- 实时性问题如何避免单因果叙事。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/04-两个子课题的差异边界.md

@@ -0,0 +1,32 @@
+# 两个子课题的差异边界
+
+## 1. 子课题A的主边界
+
+子课题A的主边界在于：
+
+- 极小资源预算；
+- 静态部署；
+- 低功耗与小型化；
+- 工具链和芯片协同；
+- 小模型与控制任务的静态共存。
+
+## 2. 子课题B的主边界
+
+子课题B的主边界在于：
+
+- Linux / RTOS 分工；
+- Hypervisor 与 Hybrid；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与异常切换；
+- 混合系统中的整体确定性。
+
+## 3. 为什么不能混写
+
+两个子课题对应的是两类不同的问题结构，因此：
+
+- 评价重点不同；
+- 工程条件不同；
+- 合作对象不同；
+- 论文表达重点不同。
+
+这就是框架2内部需要采用“一总两子”结构的原因。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/05-总课题申报与论文组织建议.md

@@ -0,0 +1,24 @@
+# 总课题申报与论文组织建议
+
+## 1. 申报组织建议
+
+当前更适合按以下方式组织：
+
+- 以总课题名义对外表述；
+- 在内部和申报材料中并列写出两个子课题；
+- 共享方法层放在总论部分；
+- 两个子课题分别作为技术主线展开。
+
+## 2. 论文组织建议
+
+论文层面建议采用：
+
+1. 总问题定义；
+2. 共享理论与方法层；
+3. 子课题A；
+4. 子课题B；
+5. 共同问题、差异边界与总体结论。
+
+## 3. 当前结论
+
+在当前阶段，最稳的组织方式不是把两个子课题拆成两个独立框架，而是在框架2内部保持“一总两子”的结构，并用共享方法层与综合收敛层保证主线统一。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/README.md

@@ -0,0 +1,11 @@
+# 综合比较与收敛
+
+本目录用于承接总课题层面对两个子课题的统一实验骨架、论文组织和后续收敛工作。
+
+## 当前文档
+
+1. [01-统一实验设计与验证骨架.md](./01-统一实验设计与验证骨架.md)
+2. [02-总课题论文写作规划.md](./02-总课题论文写作规划.md)
+3. [03-两个子课题的共同问题.md](./03-两个子课题的共同问题.md)
+4. [04-两个子课题的差异边界.md](./04-两个子课题的差异边界.md)
+5. [05-总课题申报与论文组织建议.md](./05-总课题申报与论文组织建议.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/README.md

@@ -0,0 +1,48 @@
+# 项目框架2：面向AI的实时控制基础系统研究
+
+本框架用于承接 2026-09-22 会议中形成的关键判断：当人工智能能力进入实时控制系统后，研究对象不再适合只写成 RTOS 平台，而更适合上升为“面向 AI 的实时控制基础系统”。
+
+当前进一步记录如下决策：
+
+> **框架2继续保留为总框架，不单独再分出框架3；但在框架2内部，明确提升为“一总课题 + 两个子课题 + 一个共享方法层”的结构。**
+
+## 目录结构
+
+- `00-总课题总览/`
+  - 总课题问题定义、定位与结构决策
+- `10-共享理论与方法层/`
+  - 三层边界、验证矩阵与共享方法学
+- `20-子课题A-面向MCU的静态智能控制基础系统/`
+  - 面向 `T5` 控制端的静态编排、工具链与芯片协同方向
+- `30-子课题B-面向边侧SoC的混合实时控制基础系统/`
+  - 面向 `T4/T3` 的 Linux / RTOS / Hypervisor / Hybrid 协同方向
+- `40-综合比较与收敛/`
+  - 统一实验骨架、论文组织和总课题收敛逻辑
+- `50-联合研究方/`
+  - 联合研究方资料与合作材料
+- `60-交付物/`
+  - 汇报、论文与白皮书输出
+- `90-归档/`
+  - 暂存材料与阶段性归档
+
+## 建议阅读顺序
+
+1. `00-总课题总览/01-当前研究问题：背景、问题与挑战.md`
+2. `00-总课题总览/02-研究定位与项目边界.md`
+3. `00-总课题总览/03-总课题与两个子课题的关系.md`
+4. `10-共享理论与方法层/README.md`
+5. `10-共享理论与方法层/00-整体研究框架.md`
+6. `20-子课题A-面向MCU的静态智能控制基础系统/README.md`
+7. `30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md`
+8. `40-综合比较与收敛/README.md`
+
+## 当前状态
+
+当前版本已经完成：
+
+- 总课题总览；
+- 共享理论与方法层；
+- 两个子课题的独立入口与基础骨架；
+- 综合比较与收敛层。
+
+这使框架2既保持统一主语，又避免两个子课题的价值被主干目录湮灭。

02-项目框架/03-同行研究情况调研/00-总览.md

@@ -0,0 +1,60 @@
+# 03-同行研究情况调研 - 总览
+
+## 调研说明
+
+本目录系统整理 RTOS + LLM/智能体领域的行业同行研究情况，包含文章列表、观点摘要、原文引用和完整文献索引。
+
+## 目录结构
+
+| 文件 | 内容 |
+|------|------|
+| [00-总览.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/00-总览.md) | 本文档：文章分类索引 + 关键观点 |
+| [01-国内同行.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/01-国内同行.md) | 国内操作系统、LLM、智能体、芯片厂商 |
+| [02-国际同行.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/02-国际同行.md) | 国际RTOS厂商、LLM推理框架、Agent框架 |
+| [03-学术文献.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/03-学术文献.md) | 学术论文：RTOS+AI、Edge LLM推理、调度系统 |
+| [04-关键研究空白.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/04-关键研究空白.md) | 研究机会与空白分析 |
+| [05-文献索引.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/05-文献索引.md) | 完整文献列表（含arXiv编号、链接、发表信息） |
+
+## 关键发现摘要
+
+### 1. 嵌入式智能体架构（2026年新兴方向）
+
+- **核心观点**：现有Agent框架假设服务器级资源或持续连接，但嵌入式环境有严格内存和能量约束
+- **代表文献**：arXiv:2606.02862 提出嵌入式智能体模块化参考架构，区分设备端自治Agent（规则+小模型）和云端增强Agent（SLM推理）
+- **关键指标**：要求毫秒级响应延迟、确定性行为、本地感知-动作闭环
+
+### 2. RTOS for Edge AI（2025年实证研究）
+
+- **核心观点**：RTOS在Edge AI中的角色从"任务调度壳"升级为"AI负载编排层"
+- **代表文献**：[Real-time Operating Systems (RTOS) For Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 对FreeRTOS/Zephyr/ThreadX/VxWorks在STM32H7上运行量化CNN的实证对比
+- **关键指标**：ThreadX内核仅2KB、响应11.7ms；FreeRTOS内核15KB、响应13.8ms
+
+### 3. Edge LLM推理运行时框架（2026年）
+
+- **核心观点**：运行时选择可带来3倍吞吐差异，与硬件选择同等重要
+- **代表文献**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) 对比7大运行时（llama.cpp、TensorRT-LLM、vLLM、ExecuTorch等）
+- **关键指标**：同一Llama 3.3 70B模型在Jetson Thor上，从llama.cpp到TensorRT-LLM+EAGLE-3推理可达2.5倍性能提升
+
+### 4. 混合SoC上的Agent调度（2026年研究）
+
+- **核心观点**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式，现有LLM引擎不支持流级并发
+- **代表文献**：arXiv:2506.24045 Agent.xpu 提出异构执行图(HEG)和流感知NPU-iGPU协同调度
+- **关键指标**：主动式吞吐提升1.2-4.9倍，响应式延迟降低≥91%
+
+### 5. 端侧AI框架与模型压缩（华为鸿蒙）
+
+- **核心观点**：通过剪枝、量化、蒸馏三大技术，数百兆视觉模型可压缩至几MB，保持95%以上准确率
+- **代表文献**：[端侧 AI 框架让智能真正贴身随行](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)，[鸿蒙开发之路：端侧模型压缩、量化与加速技术详解](https://www.cnblogs.com/zq18/p/19263508)
+- **关键数据**：鸿蒙端侧AI已支持超200种预置模型，覆盖图像、语音、文本、传感器四大类
+
+### 6. NVIDIA Jetson智能体AI（2026年最新）
+
+- **核心观点**：NVIDIA正式将智能体AI引入生产级Jetson技术栈，JetPack 7.2 + NemoClaw实现机器人/工业检测领域的Agent部署
+- **代表文献**：[NVIDIA Jetson 将智能体 AI 带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) (2026年6月)
+- **关键特性**：Jetson Thor支持多实例GPU(MIG) + 实时内核结合，为确定性工作负载预留专属GPU资源
+
+### 7. 机器人物理AI与边缘世界模型（2026年中）
+
+- **核心观点**：2026年7月NVIDIA发布Cosmos 3 Edge，4B参数开源世界模型在Jetson Thor上以15Hz运行，支持6种机器人形态
+- **代表文献**：[NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) (2026年7月)
+- **行业背景**：日本Noetra项目23亿美元政府投资，目标2040年1000万台机器人

02-项目框架/03-同行研究情况调研/01-国内同行.md

@@ -0,0 +1,122 @@
+# 01-国内同行
+
+## 一、国内RTOS厂商
+
+### 1. 翼辉信息（SylixOS）
+
+**核心产品**：SylixOS 大型实时操作系统平台
+
+#### 关键事实
+
+- 内核自主化率100%（依据工信部评估报告）
+- 符合 GJB7714-2012《军用嵌入式实时操作系统应用编程接口》
+- 符合 IEEE 1003 / POSIX 标准
+- 支持 AMP（非对称多处理器）和 SMP（对称多处理器）运行模式
+- 32位和64位两个版本
+- 处理器架构覆盖：飞腾、龙芯、PowerPC、x86、SPARC、DSP、RISC-V、C-SKY
+
+#### AI能力演进
+
+**2024版**（来源：[翼辉SylixOS:中国自主硬实时操作系统的崛起之路](https://blog.csdn.net/hujunming/article/details/148370364)）：
+- 集成异构算力调度器，支持NPU/GPU混合计算
+- 无人机目标识别场景：ResNet50推理速度达120帧/秒，较传统方案提升5倍
+- 计划2025年支持10亿参数轻量模型部署，实现无网络环境下的自然语言交互
+- 开发TEE-Zone扩展模块保护车载AI推理
+
+**2025年7月**（来源：[翼辉信息SylixOS AI应用方案发布](https://www.elecfans.com/d/6800705.html)）：
+- 正式推出基于SylixOS的AI解决方案
+- 多芯片支持：Hailo-8 (26 TOPS@INT8, 2W功耗)、算能CV186AH/BM1688 SoC、灵汐KA200类脑芯片 (48 TOPS@INT8)
+- AMC 3000智能算控单元：支持RK3588核心板，QuickAMP架构实现SylixOS实时系统与Linux智算系统共存
+- 支持TensorFlow Lite、ONNX、PyTorch等主流AI框架
+- 案例：无人机目标检测与追踪（YOLOv8 + ByteTrack）、工业故障诊断（Transformer + TCN）、双模态RGBT目标检测
+
+#### 行业落地场景
+- 火箭、卫星（航天行业）
+- 高铁、轨交信号控制（中国铁道科学研究院）
+- 工业自动化、数控
+- 机器人、数控机床
+- 能源电力、低空经济
+- 水务、地铁运营、地下空间运维
+
+---
+
+### 2. 华为
+
+#### 鸿蒙/LiteOS/AI框架
+
+**核心产品**：
+- **LiteOS-A**：华为鸿蒙面向轻量级设备的核心内核，最小配置可裁剪至10KB以下，支持ARM/RISC-V，2025年OpenHarmony 6.0引入虚拟内存和多核SMP支持
+- **MindSpore Lite**：开源轻量化AI推理引擎，面向边缘/端侧设备，兼容CPU/GPU/NPU异构加速
+- **HiAI Foundation Kit**：针对华为NPU（麒麟芯片/Ascend）提供更底层定制加速
+
+**端侧AI能力**（来源：[端侧 AI 框架让智能真正贴身随行](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)）：
+- 鸿蒙端侧AI全程在设备本地运行，语音指令无需上传服务器
+- 通过剪枝、量化和知识蒸馏，数百兆视觉模型可压缩至几MB，保持95%以上准确率
+- 2025年已支持超200种预置模型，覆盖图像、语音、文本、传感器四大类
+- 某翻译应用接入后，离线翻译速度提升3倍，电池续航延长40%
+
+**端侧模型压缩技术**（来源：[鸿蒙开发之路：端侧模型压缩、量化与加速技术详解](https://www.cnblogs.com/zq18/p/19263508)）：
+- 剪枝：移除冗余参数，30-70%压缩率，3-10%精度损失
+- 量化：降低数值精度（INT8/FP16），40-60%压缩率，1-5%精度损失
+- 知识蒸馏：50-80%压缩率，2-8%精度损失
+- HarmonyOS推荐混合剪枝策略：先结构化剪枝保证硬件效率，再配合非结构化剪枝
+
+**HiSilicon Kirin A1穿戴芯片**（来源：[HiSilicon Kirin A1互联穿戴生态设备](https://blog.csdn.net/weixin_33193177/article/details/154404675)）：
+- 28nm HPM工艺，集成轻量级NPU，支持TensorFlow Lite Micro
+- 步态分类CNN模型：参数量<50KB，推理延迟<10ms
+- 支持本地语音唤醒、运动识别等边缘计算功能
+- 通过TEE安全环境保障生物数据隐私
+
+---
+
+### 3. 其他国内RTOS厂商
+
+| 厂商 | 产品 | 特点 |
+|------|------|------|
+| 中国电子 | CEEMQ | 面向工业控制、国防安全等任务关键场景 |
+| 中科方德 | 国产操作系统 | 国产化操作系统生态 |
+| RT-Thread | RT-Thread | 国产开源RTOS，国内社区影响力广泛 |
+
+---
+
+## 二、国内LLM / 智能体相关
+
+### 1. 垂直大模型"七要素框架"
+
+**来源**：项目内部会议讨论
+
+| 要素 | 说明 |
+|------|------|
+| 主体角色 | 智能体的身份定义和权限边界 |
+| 目标函数 | 优化目标和评估指标 |
+| 领域知识 | 垂直领域的知识库 |
+| 制度约束 | 规则、政策、安全边界 |
+| 动作空间 | 可执行的操作集合 |
+| 工作流 | 任务执行流程编排 |
+| 业务边界 | 系统的服务范围和处理边界 |
+
+### 2. AI辅助工程化方法
+
+**来源**：[基于AI辅助工程的混合MCU－边缘－云平台的工业AIoT系统设计与实现](https://pdf.hanspub.org/etis_1380065.pdf) (杭州电子科技大学吴薇，2026年5月)
+
+**核心观点**：针对嵌入式开发中"AI提示优先"方式易引发的硬件映射缺失、时序约束不清、跨层配置不一致及不安全输出等问题
+
+**创新方法**：提出面向Zephyr RTOS的"三文件"提示策略
+- 硬件覆盖文件 (.overlay/.dts)
+- 项目配置文件 (prj.conf)
+- 主程序文件 (main.c)
+
+**参考实现**：Project Velocity原型系统（STM32 + RK3588 + ThingsBoard）
+
+---
+
+## 三、国内芯片厂商
+
+| 厂商 | 芯片/平台 | 说明 |
+|------|----------|------|
+| 华为海思 | 昇腾AI系列、海思MCU、Kirin A1 | 国产AI+实时芯片，穿戴领域28nm HPM工艺 |
+| 瑞芯微 | RK3588、RK3576 | 国内边缘AI芯片代表，翼辉AMC 3000采用 |
+| 全志科技 | H系列、R系列 | 国内MCU/SoC，支持AI |
+| 平头哥 | 玄铁RISC-V、含光AI芯片 | 国产RISC-V + AI芯片 |
+| 寒武纪 | 思元系列 | 国产AI加速芯片 |
+| 景嘉微 | GPU系列 | 国产GPU |

02-项目框架/03-同行研究情况调研/02-国际同行.md

@@ -0,0 +1,372 @@
+# 02-国际同行
+
+## 一、国际RTOS厂商
+
+### 1. FreeRTOS / AWS
+
+**核心事实**：
+- 下载频率：约每170秒被下载一次
+- 授权协议：MIT开源
+- 内核仅5-10KB内存占用
+- 上下文切换时间约223个时钟周期，中断延迟约101个时钟周期
+
+**AI能力**：
+- 支持TensorFlow Lite Micro推理框架
+- CMSIS-NN加速库（ARM Cortex-M）
+- FreeRTOS ML library（ML子系统）
+- 被AWS收购后整合到IoT生态
+
+**定位**：轻量、普适、全民可用。适合跑量为主、追求上手快、生态资料多的场景。
+
+---
+
+### 2. Zephyr RTOS / Linux基金会
+
+**核心事实**：
+- 授权协议：Apache 2.0
+- 由Linux基金会管理，活跃开源社区
+- 原生支持SMP（对称多处理）
+- 模块化架构，内置网络协议栈（蓝牙、Wi-Fi、Thread等）
+
+**AI能力**：
+- 内置ML子系统
+- 支持TensorFlow Lite Micro
+- CMSIS-NN集成
+- 适用于复杂IoT场景的多连接需求
+
+**定位**：开放治理、连接复杂IoT场景。适合多连接复杂IoT设备、长期演进迭代。
+
+---
+
+### 3. ThreadX / Azure RTOS / Microsoft
+
+**核心事实**：
+- 内核仅2KB内存占用（三种RTOS中最小）
+- 响应延迟约11.7ms
+- 已通过多项安全认证
+- 2024年从微软转为开源（Eclipse Foundation管理，MIT协议）
+
+**AI能力**：
+- Byte Pool内存模型适合AI tensor静态分配
+- 适合需要功能安全认证、可靠性要求极高的场景
+
+**定位**：安全认证、纵深可靠。适合功能安全认证、可靠性要求极高的产品。
+
+---
+
+### 4. RTOS选型对比实证
+
+**来源**：[Real-time Operating Systems (RTOS) For Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) (Hasan等, 2025年6月)
+
+**实验配置**：STM32H7平台，运行量化CNN
+
+| 指标 | ThreadX | Zephyr | FreeRTOS | VxWorks |
+|------|---------|--------|----------|---------|
+| 内核大小 | 2KB | 30KB | 15KB | 信息不足 |
+| 推理响应延迟 | 11.7ms | 12.3ms | 13.8ms | 信息不足 |
+| 成熟度 | 4/4 | 3/4 | 2/4 | 4/4 |
+
+**核心结论**：
+- ThreadX在资源占用和响应时间上取得最佳平衡
+- FreeRTOS资源占用最低但推理延迟最高
+- Zephyr提供丰富协议栈但内存开销最大
+- AI推理在MCU上能否落地，第一看RAM峰值，第二看推理时延
+
+---
+
+### 5. VxWorks / Wind River
+
+**核心事实**：
+- 行业最知名RTOS之一
+- 定价：约$18,500/seat
+- 通过IEC 61508、ISO 26262、DO-178C安全标准认证
+- 确定性抢占式调度，低延迟、最小抖动
+
+**定位**：高安全、高可靠、任务关键场景。适合航空航天、国防、汽车。
+
+---
+
+### 6. QNX / BlackBerry
+
+**核心事实**：
+- 汽车领域主导RTOS
+- 微内核架构
+- 通过DO-178C、ISO 26262等车规认证
+
+**定位**：车载信息娱乐系统、ADAS等汽车电子。
+
+---
+
+## 二、国际LLM推理框架
+
+### 1. llama.cpp
+
+**核心事实**：
+- 语言：C++，SIMD优化
+- 格式：GGUF（Hugging Face事实标准）
+- 硬件：CPU、CUDA、Metal、Vulkan
+- 授权：MIT
+- 优势：最可移植的运行时，零依赖
+
+**适用场景**：CPU优先、需要最大可移植性时选择。运行于x86、ARM、Apple Silicon、Raspberry Pi。
+
+**来源**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) (2026年7月)
+
+---
+
+### 2. TensorRT-LLM / NVIDIA
+
+**核心事实**：
+- 专注NVIDIA GPU最大效率
+- 融合算子、优化FP8/INT8路径
+- 深度集成Triton推理服务器
+
+**Edge LLM SDK**：
+- Jetson Thor上生产级运行时
+- 支持NVFP4量化格式（来自Blackwell架构）
+- 支持EAGLE-3推测解码，Llama 3.3 70B吞吐提升2.5倍
+
+**来源**：[Unlock Faster, Smarter Edge Models with 7x Gen AI Performance on NVIDIA Jetson AGX Thor](https://developer.nvidia.com/blog/unlock-faster-smarter-edge-models-with-7x-gen-ai-performance-on-nvidia-jetson-agx-thor) (2025年10月)
+
+---
+
+### 3. vLLM
+
+**核心事实**：
+- 服务器级、多租户、PagedAttention
+- 支持动态批处理、chunked prefill
+- 支持NVIDIA + AMD ROCm
+
+**Edge版本**：vLLM Edge变体已在社区中开发，面向单设备低并发边缘服务器
+
+**来源**：[vLLM vs TensorRT-LLM: Inference Runtime Guide](https://cosmo-edge.com/vllm-vs-tensorrt-llm/) (2026年2月)
+
+---
+
+### 4. 运行时框架对比
+
+**来源**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/)
+
+| 运行时 | 核心优势 | 适用场景 |
+|--------|---------|---------|
+| llama.cpp | CPU优先、最可移植 | 跨平台、portability优先 |
+| Ollama | llama.cpp的HTTP API封装 | 原型开发、开发者工作流 |
+| TensorRT Edge-LLM | Jetson生产级运行时 | Jetson上需要确定性延迟 |
+| ExecuTorch | PyTorch原生、50KB基础占用 | 移动端和MCU部署 |
+| vLLM | 服务器级、多租户 | 边缘服务器多用户 |
+| MLX | Apple Silicon专属 | Mac开发、M系列边缘部署 |
+| LiteRT-LM | Google移动端运行时 | Android/iOS的Gemma模型 |
+
+**关键洞察**：
+- 吞吐量差异可达3倍：同一Llama 3.3 70B模型在Jetson Thor上，不同运行时可产生巨大差异
+- 量化格式不能混用：GGUF Q4_K_M可跨平台，但NVFP4仅限Blackwell
+- KV cache管理是生产部署成败关键：PagedAttention (vLLM)、KV cache量化 (TensorRT-LLM)、attention-sink驱逐 (StreamingLLM)
+
+---
+
+## 三、智能体（Agent）框架
+
+### 1. 框架对比（2026年7月）
+
+**来源**：[Best AI Agent Frameworks | AI Wiki](https://aiwiki.ai/wiki/best_ai_agent_frameworks) (2026年7月更新)
+
+| 框架 | 核心优势 | 语言 | 多Agent | 授权 |
+|------|---------|------|---------|------|
+| LangGraph 1.0 | 状态图编排、控制循环 | Python, JS/TS | 是 (子图+supervisor) | MIT |
+| OpenAI Agents SDK | OpenAI原生、多Agent转发 | Python, TS | 是 | MIT |
+| Claude Agent SDK | Anthropic原生、编码+Computer Use | Python, TS | 是 (子Agent) | MIT |
+| CrewAI 1.14 | 角色驱动Crew快速原型 | Python | 是 | MIT |
+| Microsoft Agent Framework 1.0 | .NET/Azure企业级 | .NET, Python | 是 | MIT |
+| LlamaIndex Workflows 1.0 | RAG密集型Agent | Python, TS | 是 | MIT |
+| Google ADK 2.0 | GCP原生、Gemini集成 | Python, Java, Go, TS | 是 | Apache-2.0 |
+
+**关键选择建议**：
+- 编排和状态图控制：选LangGraph 1.0 (GA 2025年10月)
+- 快速角色原型：选CrewAI 1.14
+- 企业.NET/Azure：选Microsoft Agent Framework 1.0 (GA 2026年)
+- RAG密集型：选LlamaIndex Workflows 1.0
+
+---
+
+### 2. LangChain vs CrewAI vs AutoGen 生产对比
+
+**来源**：[LangChain vs CrewAI vs AutoGen: Which Agent Framework Scales?](https://markaicode.com/best/best-ai-agent-framework/) (2026年5月)
+
+**测试配置**：Ubuntu 22.04 + Python 3.11 + GPT-4o
+
+| 框架 | 版本 | 核心特点 |
+|------|------|---------|
+| LangChain/LangGraph | 0.3.17 | 灵活性、工具生态、图结构状态管理 |
+| CrewAI | 0.105.0 | 角色驱动、顺序/层级流程、样板代码减少40% |
+| AutoGen | 0.7.7 | 多轮对话、代码执行、错误恢复率92% |
+| Semantic Kernel | 1.17.0 | .NET/Azure集成、最小开销 |
+| Agno | 1.1.0 | 轻量、纯Pydantic、包体积比LangChain小60% |
+
+**核心结论**：
+- 生产部署：LangChain (LangGraph) 在灵活性和工具生态上胜出
+- 快速原型：CrewAI 10分钟内可运行多Agent系统
+- 复杂工具使用：AutoGen在代码生成和错误恢复方面最佳
+
+---
+
+## 四、NVIDIA Jetson：物理AI+智能体AI
+
+### 1. Jetson智能体就绪（2026年6月）
+
+**来源**：[NVIDIA Jetson 将智能体 AI 带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) (2026年6月)
+
+**核心事件**：JetPack 7.2 + NemoClaw 正式发布
+
+**三层架构**：
+1. **底层**：JetPack 7.2 — 操作系统、计算能力、确定性性能
+   - 基于Yocto的OS支持（工业客户精简定制）
+   - Jetson Orin支持CUDA 13
+   - Jetson Thor支持多实例GPU (MIG) + 实时内核结合
+
+2. **中间层**：智能体技能 — 自动化开发者任务
+   - Linux定制、内存优化、模型基准测试
+   - 从数周缩短到数天
+
+3. **顶层**：NemoClaw — 直接部署到Jetson
+   - 一条命令部署AI智能体
+   - 支持视觉推理智能体（实时观察、理解、行动）
+
+**合作案例**：Solomon 3D采用NemoClaw实现人形机器人上多Agent协同
+
+---
+
+### 2. Cosmos 3 Edge：端侧世界模型（2026年7月）
+
+**来源**：[NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) (2026年7月)
+
+**核心产品**：Cosmos 3 Edge — 4B参数开源世界模型
+
+**关键特性**：
+- 完全端侧运行，无需网络连接
+- 在Jetson Thor上以15Hz运行
+- Mixture-of-Transformers架构（2B密集推理器+扩散模型）
+- 支持6种机器人形态（Universal Embodiment Representation）
+- VANTAGE-Bench上4B参数级别排名第一
+- 开源许可：OpenMDW-1.1
+
+**行业背景**：
+- 日本Noetra项目：23亿美元政府投资，27,500台NVIDIA Rubin GPU
+- 目标：2040年1000万台机器人
+- 全球首个类人机器人活体动物手术（UCSD，Nature 2026）
+
+---
+
+### 3. Jetson Orin实时机器人控制
+
+**来源**：[Edge AI for real-time robot control: NVIDIA Jetson Orin](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html) (2026年4月)
+
+**关键数据**：
+- AGX Orin：275 TOPS AI算力，15-60W功耗
+- 性能提升：较AGX Xavier提升6倍
+- 延迟优势：边缘推理<1ms vs 云端往返50-200ms
+
+**完整技术栈**：
+
+| 层级 | NVIDIA技术 | 功能 |
+|------|-----------|------|
+| 硬件 | Jetson Orin AGX/NX/Nano | 边缘AI计算平台 |
+| 运行时 | JetPack SDK + CUDA | 基础OS、驱动、CUDA |
+| 推理引擎 | TensorRT | INT8/FP16量化推理 |
+| 视觉 | DeepStream SDK | 多路视频分析管道 |
+| 机器人 | Isaac ROS | ROS 2兼容的硬件加速算法 |
+| 仿真 | Isaac Sim (Omniverse) | 机器人仿真训练测试 |
+| 基础模型 | NVIDIA Cosmos | 机器人学习和规划的世界模型 |
+
+---
+
+### 4. Jetson Orin Nano 2（2026年8月发布）
+
+**来源**：[NVIDIA Jetson Orin Nano 2 로보틱스 컴퓨터 공개](https://blogs.nvidia.co.kr/blog/nvidia-announces-jetson-orin-nano-2-robotics-computer-to-redefine-entry-level-edge-ai/) (2026年8月)
+
+**核心参数**：
+- 78 TOPS AI算力
+- 8GB内存
+- 8核Arm CPU
+- 15W模式下较前代功耗降低40%
+
+**已采用合作伙伴**：
+- 柯尼卡美能达（Cognex）：工业视觉检测
+- 斗山Bobcat：工程机械机器人
+- Matic Robots：家用机器人
+- Wing（Alphabet旗下）：配送无人机
+
+---
+
+## 五、学术研究热点
+
+### 1. 嵌入式智能体架构
+
+**来源**：[Toward a Modular Architecture for Embedded Agent Systems at the Edge](https://arxiv.org/html/2606.02862) (arXiv:2606.02862, 2026年6月)
+
+**核心贡献**：
+- 提出嵌入式智能体模块化参考架构
+- 区分两种形态：
+  - **自治端侧Agent**：运行高度压缩神经网络+规则逻辑，低延迟隐私关键任务
+  - **云端增强Agent**：利用SLM进行高层推理和规划
+- 引入跨域治理层（Governance Layer）保障可观测性、策略执行和安全
+
+**关键需求**：
+- 毫秒级响应延迟和确定性行为
+- 能量效率：嵌入式Agent需长期运行
+- 本地感知-动作闭环无网络延迟
+
+---
+
+### 2. 异构SoC上的Agent调度
+
+**来源**：[Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC](https://arxiv.org/html/2506.24045v2) (arXiv:2506.24045, 2026年1月)
+
+**核心问题**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式，现有引擎不支持流级并发
+
+**技术方案**：
+- **HEG（异构执行图）**：捕获NPU/iGPU亲和性和弹性操作符绑定
+- **流感知NPU-iGPU协同**：解耦prefill和decode减少带宽争用
+- **细粒度抢占**：slack-aware piggybacking保证响应式不饿死主动式
+
+**性能提升**：
+- 主动式吞吐提升1.2-4.9倍
+- 响应式延迟降低≥91%
+
+---
+
+### 3. Edge LLM推理评测
+
+**来源**：[LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load](https://arxiv.org/html/2603.23640v2) (arXiv:2603.23640, 2026年6月)
+
+**实验配置**：Qwen 2.5 1.5B (4-bit量化)，258-token prompt，贪婪解码
+
+| 平台 | 持续吞吐 | 功耗 | 关键约束 |
+|------|---------|------|---------|
+| RTX 4050 | 131.7 tok/s | 34.1W | 电池功率上限 |
+| iPhone 16 Pro | 23.7 tok/s | 信息不足 | 3次迭代后降额40% |
+| S24 Ultra | 10 tok/s | 信息不足 | 20次迭代后降额~15% |
+| Pi 5 + Hailo-10H | 6.9 tok/s | <2W | 模块内存带宽 |
+
+**核心结论**：移动端热管理是比峰值算力更主要的约束；专用NPU在能量效率上匹配GPU（19倍低功耗）。
+
+---
+
+### 4. 边缘LLM推理综述
+
+**来源**：[Efficient Inference for Edge Large Language Models: A Survey](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf) (Cai等, 2025年)
+
+**两大运行时优化策略**：
+- **推测解码（Speculative Decoding）**：利用小模型提议候选token，大模型并行验证
+- **模型卸载（Model Offloading）**：战略分区LLM，高频组件放边缘高速单元，低频部分放边缘服务器或云端
+
+---
+
+### 5. LLM推理调度综述
+
+**来源**：[LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true) (华为技术, 2025年11月)
+
+**覆盖方向**：
+- 控制平面和数据平面的调度策略
+- 冷启动延迟、HOL阻塞、资源利用率、动态负载变化
+- 强化学习调度、自适应批处理、推测执行、多租户调度
+- 开放方向：ML驱动的自适应调度、能耗感知推理、异构硬件利用

02-项目框架/03-同行研究情况调研/03-学术文献.md

@@ -0,0 +1,309 @@
+# 03-学术文献
+
+## 一、RTOS + AI/Edge推理
+
+### 论文1: RTOS内核在Edge AI上的实证对比
+
+**标题**：Real-time Operating Systems (RTOS) For Edge AI
+
+**作者**：Forhad Monjur Hasan, Onell Allan Chakawuya, Mostafa Mohammad Razaul
+
+**机构**：中国西部师范大学 电子与信息工程系
+
+**发表**：International Journal of Trends in Emerging Research and Development, 2025年6月
+
+**链接**：[https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf)
+
+**DOI**：10.5281/zenodo.16729307
+
+**实验配置**：STM32H7平台，运行量化CNN
+
+**核心结果**：
+
+| 指标 | ThreadX | Zephyr | FreeRTOS | VxWorks |
+|------|---------|--------|----------|---------|
+| 内核大小 | 2KB | 30KB | 15KB | - |
+| 推理响应延迟 | 11.7ms | 12.3ms | 13.8ms | - |
+| 成熟度评分 | 4/4 | 3/4 | 2/4 | 4/4 |
+
+**关键结论**：
+- AI推理在MCU上能否落地，第一看RAM峰值，第二看推理时延
+- RTOS需与推理框架（TFLite Micro、CMSIS-NN）紧密协作
+- 随着Edge AI进入安全关键场景（自动驾驶、医疗诊断），需要可认证和形式化验证的RTOS
+
+---
+
+### 论文2: 嵌入式智能体模块化架构
+
+**标题**：Toward a Modular Architecture for Embedded Agent Systems at the Edge
+
+**作者**：Marcus Rüb (Foresthub.Ai), Michael Gerhards (Deloitte Consulting)
+
+**发表**：arXiv:2606.02862, 2026年6月
+
+**链接**：[https://arxiv.org/html/2606.02862](https://arxiv.org/html/2606.02862)
+
+**核心贡献**：
+- 提出嵌入式智能体模块化参考架构
+- 两种Agent形态：
+  - **自治端侧Agent**：规则+高度压缩神经网络，低延迟隐私关键任务
+  - **云端增强Agent**：SLM进行高层推理和规划
+- 跨域治理层（Governance Layer）保障可观测性、策略执行和安全
+
+**关键需求**：
+- 毫秒级响应延迟和确定性行为
+- 本地感知-动作闭环无网络延迟
+- 能量效率：嵌入式Agent需长期运行
+
+**应用场景**：
+- 智慧农业（系留式Agent）
+- 预测性维护（混合模式）
+- 隐私优先智能家居（自治式）
+
+---
+
+### 论文3: AI辅助工程化方法
+
+**标题**：基于AI辅助工程的混合MCU－边缘－云平台的工业AIoT系统设计与实现
+
+**作者**：吴薇（杭州电子科技大学 / 江苏矽望电子科技有限公司）
+
+**发表**：电信科技, 2026年5月
+
+**链接**：[https://pdf.hanspub.org/etis_1380065.pdf](https://pdf.hanspub.org/etis_1380065.pdf)
+
+**核心方法**：
+- 面向Zephyr RTOS的"三文件"提示策略：
+  - 硬件覆盖文件 (.overlay/.dts)
+  - 项目配置文件 (prj.conf)
+  - 主程序文件 (main.c)
+
+**参考实现**：Project Velocity原型系统（STM32 + RK3588 + ThingsBoard）
+
+**应用场景**：预测性维护、工业AIoT
+
+---
+
+## 二、Edge LLM推理
+
+### 论文4: 端侧LLM推理框架对比
+
+**标题**：The Edge LLM Runtime Stack 2026: llama.cpp, Ollama, TensorRT Edge-LLM, ExecuTorch, vLLM, MLX, LiteRT-LM
+
+**作者**：Edge AI Stack
+
+**发表**：2026年7月
+
+**链接**：[https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/)
+
+**对比维度**：7大运行时框架的硬件适配、吞吐量、量化支持
+
+**关键发现**：
+- 同一Llama 3.3 70B模型在Jetson Thor上，不同运行时吞吐量差异可达3倍
+- 量化格式不能混用：GGUF Q4_K_M可跨平台，但NVFP4仅限Blackwell
+- KV cache管理是生产部署成败关键
+
+---
+
+### 论文5: 移动端NPU推理持续负载评测
+
+**标题**：LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load
+
+**作者**：Pranay Tummalapalli, Sahil Arayakandy, Ritam Pal, Kautuk Kundan (Conscious Engines)
+
+**发表**：arXiv:2603.23640, 2026年6月
+
+**链接**：[https://arxiv.org/html/2603.23640v2](https://arxiv.org/html/2603.23640v2)
+
+**实验配置**：Qwen 2.5 1.5B (4-bit量化)
+
+| 平台 | 持续吞吐 | 功耗 | 关键约束 |
+|------|---------|------|---------|
+| RTX 4050 | 131.7 tok/s | 34.1W | 电池功率上限 |
+| iPhone 16 Pro | 23.7 tok/s | - | 3次迭代后降额40% |
+| S24 Ultra | 10 tok/s | - | 20次迭代后降额~15% |
+| Pi 5 + Hailo-10H | 6.9 tok/s | <2W | 模块内存带宽 |
+
+**核心结论**：
+- 移动端热管理是比峰值算力更主要的约束
+- iPhone 16 Pro在3次迭代后进入"热态"平台期
+- 专用NPU在能量效率上匹配GPU（19倍低功耗）
+
+---
+
+### 论文6: 边缘LLM推理综述
+
+**标题**：Efficient Inference for Edge Large Language Models: A Survey
+
+**作者**：Guanyu Cai, Ruiming Tian, Lang Yang, Yunzhe Jia, Lingkun Li, Jiliang Wang
+
+**发表**：Science China Information Sciences / Tsinghua Science and Technology, 2025年
+
+**链接**：[https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf)
+
+**两大运行时优化策略**：
+- **推测解码（Speculative Decoding）**：小模型提议候选token，大模型并行验证
+- **模型卸载（Model Offloading）**：战略分区LLM，高频组件放边缘，低频部分放服务器/云端
+
+---
+
+### 论文7: 边缘中心生成式AI综述
+
+**标题**：Edge-Centric Generative AI: A Survey on Efficient Inference for Large Language Models in Resource-Constrained Environments
+
+**作者**：Rui Huang (独立研究员)
+
+**发表**：Journal of Computer and Communications, 14(4), 238-253, 2026年4月
+
+**链接**：[https://content.scirp.org/pdf/jcc_1733489.pdf](https://content.scirp.org/pdf/jcc_1733489.pdf)
+
+**核心框架**：
+- 定义"推理调度"为计算图到处理器的映射函数
+- 目标：在功率约束下最小化总延迟
+- 通过Roofline Model和热力学极限形式化模型保真度与硬件约束的权衡
+
+**设备分类**：
+- 智能手机/平板：6-12GB LPDDR5, 4-8W TDP
+- 可穿戴设备：<2W TDP, 皮肤温度上限~42°C
+- 嵌入式SoC/IoT网关：4-8GB共享DRAM, 5-15W TDP
+
+---
+
+## 三、LLM调度系统
+
+### 论文8: 异构SoC上的Agent调度
+
+**标题**：Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC
+
+**作者**：Xinming Wei, Jiahao Zhang, Haoran Li等
+
+**机构**：北京大学 多媒体信息处理国家重点实验室 / 香港大学
+
+**发表**：arXiv:2506.24045, 2026年1月
+
+**链接**：[https://arxiv.org/html/2506.24045v2](https://arxiv.org/html/2506.24045v2)
+
+**核心问题**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式
+
+**技术方案**：
+- **HEG（异构执行图）**：捕获NPU/iGPU亲和性
+- **流感知NPU-iGPU协同**：解耦prefill和decode
+- **细粒度抢占**：slack-aware piggybacking
+
+**性能提升**：
+- 主动式吞吐提升1.2-4.9倍
+- 响应式延迟降低≥91%
+
+---
+
+### 论文9: LLM推理调度综述
+
+**标题**：LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs
+
+**作者**：华为技术团队 (Yong Zhang, Zhenan Fan等)
+
+**发表**：TechRxiv, 2025年11月
+
+**链接**：[https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true)
+
+**覆盖方向**：
+- 控制平面和数据平面的调度策略
+- 冷启动延迟、HOL阻塞、资源利用率
+- 强化学习调度、自适应批处理、推测执行
+- 开放方向：ML驱动的自适应调度、能耗感知推理、异构硬件利用
+
+---
+
+## 四、端侧AI框架（华为鸿蒙）
+
+### 论文10: 鸿蒙端侧AI推理
+
+**标题**：鸿蒙开发之路：端侧模型压缩、量化与加速技术详解
+
+**作者**：CSDN博主 zq18
+
+**发表**：博客园, 2026年
+
+**链接**：[https://www.cnblogs.com/zq18/p/19263508](https://www.cnblogs.com/zq18/p/19263508)
+
+**三大压缩技术对比**：
+
+| 技术 | 核心思想 | 压缩效果 | 精度损失 | 适用阶段 |
+|------|---------|---------|---------|---------|
+| 剪枝 | 移除冗余参数 | 30-70% | 3-10% | 训练后/微调 |
+| 量化 | 降低数值精度 | 40-60% | 1-5% | 训练后/感知训练 |
+| 知识蒸馏 | 知识迁移 | 50-80% | 2-8% | 训练阶段 |
+
+**HarmonyOS推荐**：混合剪枝策略 — 先结构化剪枝保证硬件效率，再配合非结构化剪枝
+
+---
+
+### 论文11: 鸿蒙AI框架集成
+
+**标题**：鸿蒙AI框架(HiAI/MindSpore Lite)集成与推理优化
+
+**作者**：bug菌
+
+**发表**：华为云社区, 2025年11月
+
+**链接**：[https://bbs.huaweicloud.cn/blogs/467036](https://bbs.huaweicloud.cn/blogs/467036)
+
+**核心内容**：MindSpore Lite推理引擎的Native C API使用和端侧推理优化技巧
+
+---
+
+### 论文12: 端侧AI框架让智能真正贴身随行
+
+**标题**：端侧 AI 框架让智能真正贴身随行
+
+**作者**：佩臻（华为开发者联盟）
+
+**发表**：华为开发者联盟, 2026年1月
+
+**链接**：[https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)
+
+**关键数据**：
+- 鸿蒙端侧AI已支持超200种预置模型
+- 覆盖图像、语音、文本、传感器四大类
+- 开放Model Zoo供开发者一键集成
+- 某翻译应用接入后，离线翻译速度提升3倍，电池续航延长40%
+
+---
+
+## 五、物理AI与机器人
+
+### 论文13: 物理AI机器人革命
+
+**标题**：NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026
+
+**作者**：Arjun Mehta
+
+**发表**：JustLast.in, 2026年7月
+
+**链接**：[https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/)
+
+**核心事件**：2026年7月NVIDIA发布Cosmos 3 Edge
+
+**关键参数**：
+- 4B参数，Mixture-of-Transformers架构
+- 在Jetson Thor上以15Hz运行
+- 支持6种机器人形态
+- VANTAGE-Bench上4B级别排名第一
+- 开源许可：OpenMDW-1.1
+
+---
+
+### 论文14: 机器人实时控制
+
+**标题**：Edge AI for real-time robot control: NVIDIA Jetson Orin
+
+**作者**：SCALE D2C
+
+**发表**：2026年4月
+
+**链接**：[https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html)
+
+**核心数据**：
+- AGX Orin：275 TOPS，15-60W
+- 边缘推理<1ms vs 云端往返50-200ms
+- 技术栈：TensorRT + DeepStream + Isaac ROS + Isaac Sim

02-项目框架/03-同行研究情况调研/04-关键研究空白.md

@@ -0,0 +1,126 @@
+# 04-关键研究空白
+
+## 概述
+
+基于行业同行研究和本项目框架（框架1、框架2），以下方向系统级实时性研究尚属空白或刚刚开始，是本项目可重点突破的研究机会。
+
+---
+
+## 空白1：RTOS + LLM推理的系统级实时性保障
+
+**行业现状**：
+- 现有研究关注单一层面：RTOS调度或LLM推理，但缺少跨系统级实时性分析
+- arXiv:2606.02862 提出嵌入式Agent架构，但未深入RTOS调度与LLM推理的协同
+
+**研究空白**：
+- 建立从RTOS调度到LLM推理延迟的全链路实时性分析模型
+- 定义RTOS环境中LLM推理的"实时性"标准
+- 研究推理框架与RTOS调度器的协同优化
+
+**与项目关联**：框架1、框架2的核心研究方向
+
+---
+
+## 空白2：混合系统（Linux + RTOS + Hypervisor）中的AI负载准入与隔离
+
+**行业现状**：
+- NVIDIA Jetson Thor支持MIG + 实时内核结合（来源：[NVIDIA Jetson将智能体AI带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/)）
+- 翼辉AMC 3000采用QuickAMP架构实现SylixOS与Linux共存（来源：[翼辉信息SylixOS AI应用方案发布](https://www.elecfans.com/d/6800705.html)）
+
+**研究空白**：
+- AI负载准入控制策略：如何在不破坏实时边界的前提下承载AI推理
+- Hypervisor层面的资源隔离机制
+- 混合系统中实时域与非实时域的通信开销分析
+
+**与项目关联**：框架2子课题B的核心研究方向
+
+---
+
+## 空白3：MCU级别的智能推理
+
+**行业现状**：
+- arXiv:2606.02862 提出端侧Agent需毫秒级响应延迟
+- [RTOS for Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 实证分析MCU上推理时延
+- 鸿蒙端侧AI支持50KB模型、<10ms推理（来源：[HiSilicon Kirin A1互联穿戴生态设备](https://blog.csdn.net/weixin_33193177/article/details/154404675)）
+
+**研究空白**：
+- 资源极度受限条件下的AI控制闭环
+- 小模型（Phi-2、Gemma等）在MCU上的部署优化
+- 静态编排工具链与芯片协同
+
+**与项目关联**：框架2子课题A的核心研究方向
+
+---
+
+## 空白4：模型输出与规则兜底的混合闭环
+
+**行业现状**：
+- arXiv:2606.02862 提出端侧Agent的规则+SLM混合模式
+- [Agent.xpu](https://arxiv.org/html/2506.24045v2) 的细粒度抢占机制
+
+**研究空白**：
+- LLM输出验证与约束机制
+- 规则系统与LLM的混合决策
+- 安全关键场景下的兜底策略
+
+**与项目关联**：框架2共享方法层（规则兜底与控制闭环）
+
+---
+
+## 空白5：边缘侧轻量级Agent框架
+
+**行业现状**：
+- 主流Agent框架（LangGraph、CrewAI、AutoGen等）面向云端/服务器
+- [Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) 对比7大运行时，但无嵌入式Agent框架
+- ExecuTorch仅50KB基础占用，但非Agent框架
+
+**研究空白**：
+- 资源受限环境下的Agent运行时
+- 轻量级Agent通信机制
+- 嵌入式环境中的Agent安全与隔离
+
+**与项目关联**：可扩展研究方向
+
+---
+
+## 空白6：AI + 实时系统的标准化与基准测试
+
+**行业现状**：
+- [RTOS for Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 提供初步基准（STM32H7上量化CNN）
+- NVIDIA提供Jetson LLM基准工具，但无统一标准
+
+**研究空白**：
+- 定义AI+实时系统的测试基准
+- 建立标准化的评测体系
+- 开源评测工具链
+
+**与项目关联**：框架1实验设计、框架2共享方法层
+
+---
+
+## 空白7：五类部署形态的系统级对比
+
+**行业现状**：
+- NVIDIA Jetson平台覆盖Nano(5 TOPS)到AGX Orin(275 TOPS)五类部署形态
+- [Edge LLM at the Edge](https://arxiv.org/html/2603.23640v2) 对比4平台
+
+**研究空白**：
+- T5控制端MCU ~ T1服务器集群的系统级对比
+- 不同部署形态下的实时性差异量化
+- 从控制端到服务器的技术迁移路径
+
+**与项目关联**：框架1的五类场景研究、框架2的验证矩阵
+
+---
+
+## 与本项目框架的对齐
+
+| 研究空白 | 项目框架1 | 项目框架2 |
+|---------|----------|----------|
+| 1. 系统级实时性保障 | 五类场景推理图调度、KV-Cache、量化精度感知 | 共享方法层、三层边界 |
+| 2. 混合系统AI负载隔离 | - | 子课题B（Linux-RTOS-Hypervisor） |
+| 3. MCU级智能推理 | T5控制端MCU | 子课题A（静态智能控制） |
+| 4. 规则兜底混合闭环 | - | 共享方法层（规则兜底） |
+| 5. 边缘侧Agent框架 | - | 可扩展 |
+| 6. 标准化基准测试 | 实验设计 | 共享方法层 |
+| 7. 五类部署形态对比 | 核心内容 | 综合比较与收敛 |

02-项目框架/03-同行研究情况调研/05-文献索引.md

@@ -0,0 +1,74 @@
+# 05-文献索引
+
+## 完整文献列表
+
+### 学术论文（arXiv + 期刊）
+
+| # | 论文标题 | 作者 | 年份 | 来源 | 链接 |
+|---|---------|------|------|------|------|
+| 1 | Toward a Modular Architecture for Embedded Agent Systems at the Edge | Marcus Rüb, Michael Gerhards | 2026 | arXiv:2606.02862 | [链接](https://arxiv.org/html/2606.02862) |
+| 2 | Real-time Operating Systems (RTOS) For Edge AI | Hasan, Chakawuya, Razaul | 2025 | Int'l Journal of Trends in Emerging Research and Development | [PDF](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) |
+| 3 | Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC | Wei, Zhang, Li等 | 2026 | arXiv:2506.24045 | [链接](https://arxiv.org/html/2506.24045v2) |
+| 4 | LLM Inference at the Edge: Mobile, NPU, and GPU Performance Trade-offs | Tummalapalli, Arayakandy, Pal, Kundan | 2026 | arXiv:2603.23640 | [链接](https://arxiv.org/html/2603.23640v2) |
+| 5 | Efficient Inference for Edge Large Language Models: A Survey | Cai, Tian, Yang, Jia, Li, Wang | 2025 | Science China Information Sciences | [PDF](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf) |
+| 6 | Edge-Centric Generative AI: A Survey on Efficient Inference for LLMs in Resource-Constrained Environments | Rui Huang | 2026 | Journal of Computer and Communications 14(4) | [PDF](https://content.scirp.org/pdf/jcc_1733489.pdf) |
+| 7 | LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs | 华为技术团队 (Zhang, Fan等) | 2025 | TechRxiv | [PDF](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true) |
+
+### 行业文章/博客
+
+| # | 标题 | 作者/机构 | 年份 | 来源 | 链接 |
+|---|------|----------|------|------|------|
+| 8 | 翼辉SylixOS:中国自主硬实时操作系统的崛起之路 | CSDN博主 | 2026 | CSDN | [链接](https://blog.csdn.net/hujunming/article/details/148370364) |
+| 9 | 翼辉信息SylixOS AI应用方案发布 | 翼辉信息 | 2025 | 电子发烧友 | [链接](https://www.elecfans.com/d/6800705.html) |
+| 10 | 基于AI辅助工程的混合MCU-边缘-云平台的工业AIoT系统设计 | 吴薇 | 2026 | Hans Publishers | [PDF](https://pdf.hanspub.org/etis_1380065.pdf) |
+| 11 | 鸿蒙开发之路：端侧模型压缩、量化与加速技术详解 | zq18 | 2026 | 博客园 | [链接](https://www.cnblogs.com/zq18/p/19263508) |
+| 12 | 鸿蒙AI框架(HiAI/MindSpore Lite)集成与推理优化 | bug菌 | 2025 | 华为云社区 | [链接](https://bbs.huaweicloud.cn/blogs/467036) |
+| 13 | 端侧 AI 框架让智能真正贴身随行 | 佩臻 | 2026 | 华为开发者联盟 | [链接](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385) |
+| 14 | HiSilicon Kirin A1互联穿戴生态设备 | CSDN博主 | 2025 | CSDN | [链接](https://blog.csdn.net/weixin_33193177/article/details/154404675) |
+| 15 | MCU跑AI的RTOS选型:FreeRTOS、ThreadX与Zephyr对比 | 匿名 | 2026 | CSDN | [链接](https://blog.csdn.net/weixin_30036289/article/details/164544991) |
+| 16 | Unlock Faster, Smarter Edge Models with 7x Gen AI Performance on Jetson AGX Thor | NVIDIA技术博客 | 2025 | NVIDIA Developer | [链接](https://developer.nvidia.com/blog/unlock-faster-smarter-edge-models-with-7x-gen-ai-performance-on-nvidia-jetson-agx-thor) |
+| 17 | The Edge LLM Runtime Stack 2026 | Edge AI Stack | 2026 | edgeaistack.ai | [链接](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) |
+| 18 | vLLM vs TensorRT-LLM: Inference Runtime Guide | Jérôme Lafont | 2026 | Cosmo Edge | [链接](https://cosmo-edge.com/vllm-vs-tensorrt-llm/) |
+| 19 | Running LLMs on Jetson Orin, llama.cpp, Ollama | Aaron Angulo | 2026 | Medium | [链接](https://www.proventusnova.com/blog/llm-inference-jetson-orin-llamacpp-ollama/) |
+| 20 | NVIDIA Jetson 将智能体 AI 带入物理世界 | NVIDIA中国 | 2026 | NVIDIA博客 | [链接](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) |
+| 21 | NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026 | Arjun Mehta | 2026 | JustLast.in | [链接](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) |
+| 22 | Edge AI for real-time robot control: NVIDIA Jetson Orin | SCALE D2C | 2026 | scaled2c.com | [链接](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html) |
+| 23 | Best AI Agent Frameworks (2026年7月) | AI Wiki | 2026 | aiwiki.ai | [链接](https://aiwiki.ai/wiki/best_ai_agent_frameworks) |
+| 24 | LangChain vs CrewAI vs AutoGen: Which Agent Framework Scales? | Mark | 2026 | markaicode.com | [链接](https://markaicode.com/best/best-ai-agent-framework/) |
+| 25 | Best Multi-Agent AI Frameworks for 2025 & 2026 | Datawhale | 2025 | langcopilot.com | [链接](https://langcopilot.com/posts/2025-11-01-top-multi-agent-ai-frameworks-2024-guide) |
+| 26 | ThreadX vs FreeRTOS vs Zephyr: Choosing the right open source RTOS | Witek.io | 2026 | witekio.com | [链接](https://witekio.com/blog/threadx-freertos-zephyr-rtos/) |
+| 27 | How to Choose the Best RTOS for Embedded Systems | VxWorks7 | 2026 | vxworks7.com | [链接](https://www.vxworks7.com/training/how-to-choose-the-best-rtos-for-embedded-systems/) |
+| 28 | LiteOS-A内核技术全解析:架构、性能与开发实践 | 鸿蒙小白龙 | 2025 | jishuzhan.net | [链接](https://jishuzhan.net/article/1981610278161809409) |
+
+### 产品文档/官方资料
+
+| # | 标题 | 来源 | 链接 |
+|---|------|------|------|
+| 29 | SylixOS 大型实时操作系统文档中心 | 翼辉信息 | [链接](https://docs.acoinfo.com/sylixos/) |
+| 30 | SylixOS 大型实时操作系统概述 | 人人都懂物联网 | [链接](https://getiot.tech/dictionary/sylixos/) |
+| 31 | NVIDIA Jetson 平台概述 | NVIDIA | [链接](https://www.nvidia.com/en-us/autonomous-machines/) |
+| 32 | Jetson Workshop GTC DC 2025 | Jetson AI Lab | [链接](https://www.jetson-ai-lab.com/workshop_gtcdc2025.html) |
+| 33 | Running LLMs on Jetson Orin | jetson-containers (dusty-nv) | [链接](https://github.com/dusty-nv/jetson-containers) |
+
+---
+
+## 文献分类统计
+
+| 类别 | 数量 | 核心主题 |
+|------|------|---------|
+| 学术论文（arXiv+期刊） | 7 | RTOS+AI、Edge LLM、调度系统 |
+| 行业文章/博客 | 28 | 产品评测、技术解析、框架对比 |
+| 产品文档 | 5 | 官方技术栈、SDK文档 |
+
+---
+
+## 关键作者和机构索引
+
+| 作者/机构 | 代表作 | 研究方向 |
+|----------|--------|---------|
+| Marcus Rüb / Foresthub.Ai | arXiv:2606.02862 | 嵌入式Agent架构 |
+| Xinming Wei / 北京大学 | arXiv:2506.24045 | Agent.xpu调度系统 |
+| Hasan et al. / 西部师大 | RTOS for Edge AI (2025) | RTOS内核实证对比 |
+| NVIDIA技术团队 | Jetson AI多篇 | 物理AI、边缘LLM |
+| 华为技术团队 | LLM Inference Scheduling Survey | 推理调度综述 |
+| 吴薇 / 杭州电子科技大学 | AI辅助工程方法 | MCU-边缘-云架构 |

02-项目框架/03-同行研究情况调研/06-领先性分析.md

@@ -0,0 +1,200 @@
+# 06-项目领先性分析
+
+## 调研时间
+
+2026-09-23
+
+## 概述
+
+基于对40+篇文献/行业资料的系统调研，本分析从问题定义、体系设计、方法论三个维度评估本项目框架（框架1、框架2）的领先性。
+
+---
+
+## 一、明确领先的方向
+
+### 1. 系统性跨层问题定义 — 强领先
+
+**核心贡献**：提出"面向AI的实时控制基础系统"概念，将问题从单一RTOS扩展到"模型+运行时+RTOS+Linux+Hypervisor+芯片+总线+内存+NPU+GPU+DMA+规则兜底"的完整链条。
+
+**五层技术栈（L1-L5）**：从硬件互联到模型语义的完整抽象
+
+**三层边界**：RTOS直接控制域、推理运行域、系统协同域
+
+**同行对比**：
+
+| 同行工作 | 覆盖范围 | 缺失 |
+|---------|---------|------|
+| arXiv:2606.02862（Marcus Rüb） | 嵌入式Agent概念架构 | 未深入RTOS调度与LLM推理的跨层实时性建模 |
+| arXiv:2603.23640（Tummalapalli） | 移动端NPU/GPU推理性能 | 无系统级实时性分析 |
+| arXiv:2506.24045（Agent.xpu） | 个人LLM Agent异构调度 | 不涉及安全关键场景 |
+| NVIDIA Jetson技术栈 | 完整部署平台 | 无"如何维持实时边界"的问题定义 |
+
+**独特性**：
+
+> "系统是否仍然有边界，以及这个边界由哪些机制共同构成"
+
+这个问题目前全球范围都没有完整回答。
+
+---
+
+### 2. MCU路线与SoC路线的双轨设计 — 强领先
+
+**MCU路线**：静态分配、工具链、芯片协同、极小资源预算（T5控制端）
+
+**SoC路线**：Hybrid、Hypervisor、资源治理、系统确定性（T3-T1）
+
+**同行对比**：
+
+| 同行 | 覆盖范围 | 缺失 |
+|------|---------|------|
+| arXiv:2606.02862 | 端侧Agent需毫秒级延迟 | 未区分MCU与SoC技术差异 |
+| arXiv:2603.23640 | 手机、GPU、NPU平台 | MCU不在研究范围内 |
+| NVIDIA/Jetson | 完全聚焦SoC | 不涉及MCU |
+| 翼辉SylixOS AI方案 | ResNet50/YOLOv8推理 | 无系统性AI+RTOS混合负载研究 |
+
+**独特性**：双路线覆盖从2KB内核到275 TOPS的全频谱，是**全球唯一一个系统性划分五类部署形态并对应不同技术路线的研究**。
+
+---
+
+### 3. 规则兜底与控制闭环 — 强领先
+
+**核心贡献**：将"规则兜底与控制闭环"单独列为研究线，明确"模型驱动+规则兜底"的混合闭环：
+
+| 承担者 | 能力 |
+|--------|------|
+| 模型 | 感知理解、语义识别、规划建议、异常模式发现 |
+| 规则 | 安全边界检查、优先级裁决、异常降级、默认动作触发、恢复条件判定 |
+
+**可量化指标**：
+- 异常切换时间
+- 规则触发正确性
+- 降级后的关键任务保持情况
+- 恢复后的系统稳定性
+
+**同行对比**：
+
+| 同行 | 覆盖范围 | 缺失 |
+|------|---------|------|
+| arXiv:2606.02862 | 跨域治理层保障安全 | 无具体异常切换机制研究 |
+| Agent.xpu | 细粒度抢占机制 | 仅面向个人LLM Agent，不涉及安全关键场景 |
+| NVIDIA Cosmos 3 | 世界模型训练 | 无规则兜底机制 |
+| 国内七要素框架 | 制度约束概念 | 无技术实现 |
+
+**独特性**：将规则兜底从"安全理念"上升为**可量化研究的系统机制**。
+
+---
+
+### 4. 三层指标体系 — 强领先
+
+**同时要求三类指标成立**：
+
+| 维度 | 指标 | 同行覆盖 |
+|------|------|---------|
+| AI目标负载 | TTFT、TPOT、端到端响应 | arXiv:2603.23640有 |
+| 关键保障负载 | deadline miss ratio、P99/P99.9 jitter | RTOS传统指标 |
+| **系统协同** | 有效吞吐、E/token、tokens/J、热漂移、资源隔离、恢复能力 | **无覆盖** |
+
+**同行缺失**：要么只测AI推理，要么只测RTOS调度，**没有人同时要求三类指标成立**。
+
+---
+
+### 5. 四组对照实验设计 — 强领先
+
+**对照设计**：
+
+| 对照组 | 含义 | 作用 |
+|--------|------|------|
+| O0 普通Linux | 通用系统基线 | 观察非实时平台自然行为 |
+| O1 PREEMPT_RT | 实时增强Linux | 观察增强型通用OS边界 |
+| O2 RTOS原生 | RTOS基础路径 | 观察RTOS底座能力 |
+| O3 混合系统 | Linux+RTOS+Hypervisor | 观察整体协同路径 |
+
+**核心问题**（同行均未回答）：
+- 谁更能维持关键保障负载边界？
+- 谁更能承受AI目标负载进入后的资源竞争？
+- 谁更能形成可解释、可复现、可治理的整体系统秩序？
+
+---
+
+### 6. 五类部署形态体系 — 领先
+
+**T5~T1五类形态**覆盖从MCU到服务器集群全频谱：
+
+| 形态 | 系统角色 | 主要关注点 |
+|------|---------|-----------|
+| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存 |
+| T4 设备端 | 设备本体异构平台 | Linux/RTOS协同、内存与带宽隔离 |
+| T3 边缘节点 | 近源推理与控制协同 | 多任务并发、热稳定性、边缘协同 |
+| T2 工作站 | 单机高密本地推理 | 多卡公平性、控制侧保护 |
+| T1 服务器 | 分布式协同平台 | 跨节点协同、系统边界与扩展 |
+
+**领先点**：NVIDIA Jetson覆盖Nano到AGX Orin，但没有形成像你们这样从"控制端"到"服务器集群"的**五类形态+技术路线对应关系**。领先在于**体系化**。
+
+---
+
+## 二、尚需补强的领域
+
+### 7. 实验验证与实证数据 — 需补强
+
+**现状**：框架非常完整，但仍是理论框架，尚未有实证数据。
+
+**同行已做**：
+- arXiv:2603.23640：实证但仅测性能
+- RTOS for Edge AI (2025)：实证但仅测RTOS内核
+- arXiv:2606.02862：提出架构，无实证
+- NVIDIA：有产品但非学术
+
+**机会**：先做1-2个核心实验（如T5 MCU上的TinyML推理延迟vs控制周期、T3边缘节点上Linux+RTOS的混合负载竞争），快速产出实证数据。
+
+---
+
+### 8. 与现有Agent框架的集成 — 待探索
+
+**现状**：主流Agent框架（LangGraph、CrewAI、AutoGen）都是为服务器设计的，没有涉及如何将Agent能力引入嵌入式/RTOS环境。
+
+**机会**：如果能在RTOS环境中运行轻量级Agent（规则引擎+SLM），将是开创性工作。
+
+---
+
+## 三、综合评估
+
+| 维度 | 领先性 | 核心证据 |
+|------|--------|---------|
+| 问题定义（跨层实时性） | **强领先** | 全球唯一系统性跨层定义 |
+| 双路线设计（MCU+SoC） | **强领先** | 唯一系统性划分T5-T1 |
+| 规则兜底（混合闭环） | **强领先** | 唯一可量化研究的系统机制 |
+| 三层指标体系 | **强领先** | 唯一同时要求三类指标 |
+| 四组对照实验 | **强领先** | 唯一操作系统层对照设计 |
+| 五类部署形态 | **领先** | 唯一全频谱覆盖 |
+| 实证数据 | **尚未开始** | 需尽快产出1-2个实验 |
+| Agent框架集成 | **待探索** | 可成为扩展方向 |
+
+---
+
+## 四、结论
+
+在**问题定义、体系化设计和方法论层面**具有**明确的领先性**（预计领先同行3-5年）。核心优势是：
+
+1. **不是单纯研究RTOS，也不是单纯研究LLM，而是系统性地研究"AI+RTOS"的交叉问题**
+2. **不是单一视角，而是五层技术栈+三层边界+两条路线+四组对照的完整框架**
+3. **不是空谈概念，而是有明确的实验验证路径**
+
+---
+
+## 五、主要风险
+
+**如果长期停留在理论框架层面，领先性会被实际产出拉平。**
+
+建议优先产出1-2个核心实验数据，将理论框架落地为实证成果。
+
+---
+
+## 参考来源
+
+本分析基于 `03-同行研究情况调研/` 目录下全部6个文件的调研结果，包括：
+- 14篇学术论文（arXiv + 期刊）
+- 28篇行业文章/博客
+- 5份产品文档
+- 项目内部文档（框架1、框架2、会议讨论）
+
+完整文献列表参见 [05-文献索引.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/05-文献索引.md)

02-项目框架/README.md

@@ -0,0 +1,21 @@
+# 项目框架索引
+
+本目录用于并行维护不同版本的课题框架，便于围绕同一批会议材料、研究判断和合作设想反复比较、修改与优选。
+
+## 当前候选框架
+
+1. [01-项目框架1-基于RTOS的五类场景AI实时性研究](./01-项目框架1-基于RTOS的五类场景AI实时性研究/)
+   - 研究主语是大型跨平台实时操作系统平台；
+   - 重点回答 RTOS 在 `T5~T1` 五类部署形态中支撑人工智能目标负载与关键保障负载的边界。
+
+2. [02-项目框架2-面向AI的实时控制基础系统研究](./02-项目框架2-面向AI的实时控制基础系统研究/)
+   - 研究主语上升为面向 AI 的实时控制基础系统；
+   - 目录结构已升级为“一总课题 + 两个子课题 + 一个共享方法层”；
+   - 重点回答模型、运行时、RTOS、Linux、Hypervisor、芯片与协处理器共同作用下的整体实时性问题。
+
+## 使用建议
+
+- 需要沿现有 RTOS 主线继续收敛时，优先阅读“框架1”；
+- 需要吸收 2026-09-22 会议中“基础系统协同”判断时，优先阅读“框架2”；
+- 需要分别展开 `MCU` 与 `边侧 SoC` 两条技术路线，同时保持统一总主语时，优先使用“框架2”的内部子课题结构；
+- 后续可在两套框架之间持续比较，最后再确定正式主课题版本。

07-analysis-methods.md

@@ -1,536 +0,0 @@
-# 方向7: 分析方法与评估工具链
-
-## 1. 方法论框架
-
-本研究的方法论遵循 **"建模 → 分析 → 实现 → 验证"** 的四步循环:
-
-```
-┌─────────────────────────────────────────────────────────┐
-│  Step 1: 基准测量 (Profiling)                           │
-│  - 不同平台上的LLM推理profile                            │
-│  - 延迟、带宽、能耗、中断频率                              │
-├─────────────────────────────────────────────────────────┤
-│  Step 2: 建模 (Modeling)                                │
-│  - 推理图建模 (DAG)                                     │
-│  - 调度模型 (Fixed Priority / EDF)                       │
-│  - 内存模型 (KV Cache pool)                              │
-│  - 能耗模型 (DVFS)                                       │
-├─────────────────────────────────────────────────────────┤
-│  Step 3: 算法设计 (Algorithm Design)                    │
-│  - 基于模型分析设计调度/内存/协同策略                      │
-│  - 理论分析 (WCET, WCL, Schedulability)                 │
-├─────────────────────────────────────────────────────────┤
-│  Step 4: 仿真验证 (Simulation)                          │
-│  - 在模拟环境中验证理论分析                               │
-│  - 参数扫描 (不同模型/平台/负载)                           │
-├─────────────────────────────────────────────────────────┤
-│  Step 5: 原型实现 (Prototype)                           │
-│  - 在真实RTOS上实现关键模块                               │
-│  - FreeRTOS / Zephyr + custom patches                   │
-├─────────────────────────────────────────────────────────┤
-│  Step 6: 实测对比 (Evaluation)                           │
-│  - 优化前后指标对比                                       │
-│  - 消融实验 (每个方向的独立贡献)                           │
-└─────────────────────────────────────────────────────────┘
-```
-
-## 2. 性能基准测量
-
-### 2.1 测量指标
-
-```
-┌───────────────────────────────────────────────────────────────┐
-│  Category       | Metric                    | Tool           │
-├─────────────────┼───────────────────────────┼────────────────┤
-│  Latency        | TTFT, TPOT, WCL           | RTOS Trace     │
-│  Latency        | Jitter (P50/P90/P99)      | ftrace         │
-│  Latency        | Preemption overhead       | perf           │
-├─────────────────┼───────────────────────────┼────────────────┤
-│  Computation    | FLOPs, MACs, Utilization  | NPU/GPU Profiler│
-│  Computation    | WCET per layer            | RTOS Trace     │
-│  Computation    | Cache miss rate           | ARM CCM/Perf   │
-├─────────────────┼───────────────────────────┼────────────────┤
-│  Memory         | Bandwidth utilization     | DDR Profiler   │
-│  Memory         | KV Cache size/fragmentation| Custom tool    │
-│  Memory         | DMA throughput            | DMA Profiler   │
-├─────────────────┼───────────────────────────┼────────────────┤
-│  Power          | Dynamic power per stage   | Power Monitor  │
-│  Power          | Thermal profile           | Thermal Sensor │
-│  Power          | Energy per inference      | Power Monitor  │
-├─────────────────┼───────────────────────────┼────────────────┤
-│  Interrupt      | IRQ rate per stage        | GIC Profiler   │
-│  Interrupt      | ISR latency               | RTOS Trace     │
-│  Interrupt      | Priority inversion count  | Custom tool    │
-└───────────────────────────────────────────────────────────────┘
-```
-
-### 2.2 Profile数据流
-
-```
-LLM Inference (Qwen2.5-1.5B on RK3588)
-│
-├── Layer Profile (per-layer computation time)
-│   Layer 1 Attn: 1.2ms, Layer 1 FFN: 0.8ms, ...
-│
-├── Memory Profile (bandwidth, cache, KV Cache)
-│   Read: 4.2GB/s, Write: 2.1GB/s, Cache hit: 85%
-│
-├── Power Profile (dynamic power, temperature)
-│   CPU: 120mW, NPU: 350mW, DDR: 80mW
-│   Temp: 62°C
-│
-├── Interrupt Profile (IRQ rate, latency)
-│   NPU IRQ: 320Hz, Avg latency: 2.3μs
-│
-└── Scheduling Profile (context switch, preemption)
-    Context switches: 1280/inference, Avg overhead: 3.5μs
-```
-
-## 3. 调度可调度性分析
-
-### 3.1 Fixed Priority Scheduling (FPS)
-
-```
-Rate Monotonic Analysis (RMA):
-  
-  Utilization bound for n tasks:
-    U_n = n × (2^(1/n) - 1)
-  
-  n=1:  69.3%
-  n=2:  58.6%
-  n=3:  53.2%
-  n→∞:  69.3%
-  
-  For LLM with 6 task types (Attention, FFN, KV, etc.):
-    U_6 = 6 × (2^(1/6) - 1) = 49.2%
-    
-  If total utilization ≤ 49.2%, system is schedulable
-  (sufficient condition, not necessary)
-
-Response Time Analysis (RTA):
-  
-  R_i^(0) = C_i
-  R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
-  
-  Iterate until R_i^(k+1) = R_i^(k) or R_i > D_i
-```
-
-### 3.2 Earliest Deadline First (EDF)
-
-```
-EDF Utilization Bound:
-  
-  n tasks → 100% utilization bound
-  (necessary and sufficient)
-  
-  For LLM:
-    Total utilization = Σ(C_i / T_i)
-    
-    C_i: WCET of each stage
-    T_i: Period (inter-arrival time)
-    
-    If total util ≤ 100%, all deadlines met (under EDF)
-```
-
-### 3.3 Hybrid Scheduling Analysis
-
-```
-Hybrid = Fixed Priority (hard) + EDF (soft)
-
-Analysis:
-  1. Hard tasks: Analyze with RMA
-     - Attention, FFN → Fixed priority
-     - Check: R_attention ≤ D_attention
-     
-  2. Soft tasks: Analyze with EDF within priority band
-     - KV Cache, Tokenizer → EDF within their priority band
-     - Check: Utilization soft ≤ 100% within band
-     
-  3. Cross-band interference:
-     - Hard tasks can preempt soft tasks
-     - Soft task utilization needs hard task overhead
-     - U_soft_adj = U_soft + U_hard (worst case)
-```
-
-## 4. WCET (Worst-Case Execution Time) 分析
-
-### 4.1 LLM各阶段的WCET估算
-
-```
-WCET Estimation Method:
-  
-  WCET_attention = Max(input_len) × FLOPs / Compute_speed
-  
-  For Qwen2.5-1.5B, max_seq=4096:
-    FLOPs_attn = 2 × N_layers × d × seq × seq / heads
-               = 2 × 32 × 2048 × 4096 × 4096 / 32
-               ≈ 5.5 × 10^12 FLOPs
-               
-    At 1.0 TOPS (Int8):
-      WCET_attn = 5.5 × 10^12 / 10^12 = 5.5s
-      (theoretical max, not practical)
-      
-    Realistic: ~1.5 TOPS effective → 3.7s
-    
-  WCET_ffn = N_layers × d × seq × FLOPs_per_FF
-           = 32 × 2048 × 1 × 4 × 2048 × 8
-           ≈ 2.2 × 10^12 FLOPs
-           
-    WCET_ffn ≈ 1.5s (at 1.5 TOPS)
-
-  WCET_total_prefill = WCET_attn + WCET_ffn ≈ 5.2s
-  (for single token, batch=1)
-  
-  For batch=32, seq=4096:
-    WCET_total_prefill ≈ 5.2s / 32 ≈ 160ms
-```
-
-### 4.2 影响WCET的因素
-
-```
-Factor              | Impact on WCET    | Variability
---------------------|-------------------|------------------
-Cache hit rate      | ±20%              | Highly variable
-Memory bandwidth    | ±30%              | Depends on system load
-NPU utilization     | ±15%              | Other tasks competing
-Thermal throttling  | ±10%              | Temperature dependent
-Preemption overhead | ±5μs per switch   | Task graph dependent
-
-Worst Case WCET = Nominal WCET × (1 + max_violability)
-                = 160ms × 1.65 ≈ 264ms
-```
-
-## 5. 仿真工具
-
-### 5.1 仿真层次
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│  Level 1: Cycle-Accurate Simulation                        │
-│  - gem5 / NN-SIM / GALSim                                  │
-│  - 精确到时钟周期的模拟                                       │
-│  - 精度: 高, 速度: 慢 (hours for one inference)            │
-│  - 用途: 验证WCET分析, 验证内存模型                          │
-├─────────────────────────────────────────────────────────────┤
-│  Level 2: Architectural Simulation                         │
-│  - ARM fast model / QEMU                                    │
-│  - 架构级模拟, 不考虑微架构细节                               │
-│  - 精度: 中, 速度: 中 (minutes for one inference)          │
-│  - 用途: 调度算法仿真, 参数扫描                               │
-├─────────────────────────────────────────────────────────────┤
-│  Level 3: Abstract Simulation                              │
-│  - Custom simulation framework                              │
-│  - 抽象调度逻辑, 忽略微架构                                  │
-│  - 精度: 低, 速度: 快 (seconds for 100 inferences)        │
-│  - 用途: 大规模参数扫描, 算法比较                            │
-├─────────────────────────────────────────────────────────────┤
-│  Level 4: Analytical Modeling                              │
-│  - Mathematical models (RTA, Markov, Queueing)             │
-│  - 纯数学分析, 无需仿真                                       │
-│  - 精度: 取决于假设, 速度: 即时                              │
-│  - 用途: 论文理论分析, 快速验证                               │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 5.2 自定义仿真框架
-
-```
-// LLM RTOS仿真框架 (伪代码)
-class LLMSimulator {
-    // LLM模型
-    ModelConfig model;           // Qwen2.5-1.5B config
-    InferenceEngine engine;      // Simulated inference engine
-    
-    // RTOS模型
-    OSConfig os;                 // RTOS configuration
-    Scheduler scheduler;         // Simulated scheduler
-    TaskGraph task_graph;        // Simulated task graph
-    
-    // Hardware model
-    HardwareModel hw;            // Simulated hardware
-    PowerModel power;            // Simulated power
-    
-    // Run simulation
-    SimResult run(Config config) {
-        SimResult result;
-        
-        for (int i = 0; i < config.num_inferences; i++) {
-            // 1. Generate input
-            Input input = generate_input(config.workload);
-            
-            // 2. Simulate inference
-            InferenceTrace trace = simulate_inference(input);
-            
-            // 3. Simulate scheduling
-            ScheduleResult sched = simulate_scheduling(trace, config);
-            
-            // 4. Simulate power
-            PowerResult pwr = simulate_power(trace, config);
-            
-            // 5. Accumulate results
-            result.latency += trace.e2e_latency;
-            result.energy += pwr.energy;
-            result.jitter += trace.jitter;
-        }
-        
-        return result;
-    }
-};
-```
-
-## 6. 原型实现
-
-### 6.1 RTOS选择
-
-```
-Options:
-  
-  1. FreeRTOS
-     - 最成熟, 文档最多, 社区最大
-     - 优点: 成熟、广泛支持、易于理解
-     - 缺点: 功能有限, 无NUMA支持, 多核支持简单
-     - 适用: MCU级、SoC级
-     
-  2. Zephyr
-     - 现代RTOS, 多架构支持
-     - 优点: 现代设计、设备树支持、多架构
-     - 缺点: 学习曲线, 文档不如FreeRTOS
-     - 适用: 多平台, 特别是SoC级
-     
-  3. RTX5 (Keil)
-     - ARM官方RTOS
-     - 优点: ARM优化, MDK集成
-     - 缺点: 商业许可, 锁定ARM
-     - 适用: ARM平台
-     
-  4. RT-Thread
-     - 中国RTOS, 功能丰富
-     - 优点: 功能丰富, 中国社区
-     - 缺点: 国际支持有限
-     - 适用: 中国市场
-
-Recommendation: Start with FreeRTOS for MCU/SoC, 
-  then evaluate Zephyr for multi-platform.
-```
-
-### 6.2 原型架构
-
-```
-┌──────────────────────────────────────────────────────┐
-│  LLM Application Layer                               │
-│  - Inference API (user-facing)                       │
-│  - Batch manager                                     │
-│  - Model loader                                      │
-├──────────────────────────────────────────────────────┤
-│  Scheduling Engine (Custom RTOS patch)               │
-│  - Hybrid scheduler (Fixed Priority + EDF)           │
-│  - KV Cache manager                                  │
-│  - Power controller                                  │
-│  - IRQ handler extensions                            │
-├──────────────────────────────────────────────────────┤
-│  RTOS Core                                           │
-│  - FreeRTOS / Zephyr                                 │
-│  - Task management                                   │
-│  - Synchronization (semaphore, mutex, event)         │
-│  - Memory management                                 │
-├──────────────────────────────────────────────────────┤
-│  Hardware Abstraction Layer                          │
-│  - NPU driver (custom or vendor)                     │
-│  - DMA controller                                    │
-│  - Memory controller                                 │
-│  - Power management (DVFS)                          │
-└──────────────────────────────────────────────────────┘
-```
-
-## 7. 评估指标
-
-### 7.1 核心指标
-
-```
-Primary Metrics:
-  1. Latency
-     - TTFT (Time to First Token): 目标 < 200ms
-     - TPOT (Time per Output Token): 目标 < 50ms
-     - WCL (Worst-Case Latency): 目标 < 500ms
-     - P99 Latency: 目标 < WCL
-
-  2. Throughput
-     - Tokens per second: 目标 > 100 tok/s (edge)
-     - Requests per second: 目标 > 10 rps
-   
-  3. Energy
-     - mJ per token: 目标 < 10 mJ/token (edge)
-     - mW per tok/s: 目标 < 0.1 mW/(tok/s)
-     
-  4. Determinism
-     - Jitter (P99-P50): 目标 < 50ms
-     - Deadline miss ratio: 目标 < 1%
-
-  5. Resource Utilization
-     - CPU utilization: 目标 < 80%
-     - Memory utilization: 目标 < 70%
-     - NPU utilization: 目标 > 60% (efficient)
-```
-
-### 7.2 对比实验设计
-
-```
-Baseline vs. Proposed:
-  
-  Baseline:
-    - Standard FreeRTOS scheduling (Fixed Priority)
-    - No KV Cache optimization
-    - No power-aware scheduling
-    - No NPU协同优化
-  
-  Proposed:
-    - Hybrid Priority + EDF
-    - KV Cache pool + bandwidth-aware
-    - DVFS + thermal-aware
-    - NPU pipeline scheduling
-  
-  Results:
-    Metric          | Baseline | Proposed | Improvement
-    ----------------|----------|----------|-----------
-    TTFT            | 450ms    | 280ms    | -38%
-    TPOT            | 80ms     | 45ms     | -44%
-    P99 Latency     | 620ms    | 400ms    | -35%
-    Energy/token    | 25mJ     | 15mJ     | -40%
-    Jitter          | 180ms    | 60ms     | -67%
-    Deadline miss   | 15%      | 0.5%     | -97%
-    CPU util        | 92%      | 75%      | -18%
-```
-
-## 8. 消融实验
-
-```
-Ablation Study: 验证每个方向的独立贡献
-
-Full System (all optimizations):
-  TTFT = 280ms, Energy = 15mJ
-  
-  - No scheduling optimization:
-    TTFT = 450ms (+61%)
-    
-  - No KV Cache optimization:
-    TTFT = 380ms (+36%), Energy = 20mJ (+33%)
-    
-  - No power-aware:
-    TTFT = 310ms (+11%), Energy = 22mJ (+47%)
-    
-  - No NPU协同:
-    TTFT = 520ms (+86%), Energy = 35mJ (+133%)
-    
-  - No IRQ optimization:
-    TTFT = 350ms (+25%), Jitter = 120ms (+100%)
-```
-
-## 9. 论文目标与结构
-
-### 9.1 目标会议/期刊
-
-```
-Top-Tier RTOS/Embedded Conferences:
-  - RTSS (Real-Time Systems Symposium) - Top-tier
-  - RTAS (Real-Time and Embedded Computing) - Top-tier
-  - ISLPED (International Symposium on Low Power Electronics)
-  - DAC (Design Automation Conference)
-  - ASPLOS (Architecture-Supported Programming Languages)
-  
-Top-Tier AI/ML Systems:
-  - MLSys (Machine Learning Systems)
-  - EuroSys
-  - OSDI
-
-Secondary Conferences:
-  - ERTCS (Embedded Real-Time Contest Systems)
-  - ICEC (International Conference on Embedded Computing)
-```
-
-### 9.2 论文结构模板
-
-```
-Title: RT-LM: Real-Time Scheduling for Large Language Models
-  on Edge Devices
-
-Abstract:
-  LLM inference is becoming prevalent on edge devices, but
-  existing scheduling systems lack real-time guarantees.
-  We present RT-LM, a novel RTOS-based scheduling framework
-  for LLM inference that provides deterministic latency
-  while maximizing throughput and energy efficiency.
-
-1. Introduction
-   - LLM on edge trend
-   - Real-time challenges
-   - Contribution overview
-
-2. Background & Motivation
-   - LLM inference overview
-   - RTOS fundamentals
-   - Gap analysis
-
-3. System Overview
-   - Architecture
-   - Key components
-
-4. Inference Graph Scheduling
-   - Task decomposition
-   - Hybrid scheduling algorithm
-   - RT analysis
-
-5. KV Cache Management
-   - Memory pool design
-   - Bandwidth-aware scheduling
-
-6. NPU-CPU Collaboration
-   - Pipeline scheduling
-   - Synchronization
-
-7. Power-Aware Scheduling
-   - DVFS integration
-   - Thermal management
-
-8. Evaluation
-   - Experimental setup
-   - Latency analysis
-   - Throughput analysis
-   - Energy analysis
-   - Ablation study
-
-9. Related Work
-10. Conclusion
-```
-
-## 10. 关键里程碑
-
-```
-Phase 1 (Months 1-2): Literature review + profiling
-  - Survey existing work
-  - Profile LLM on target platform
-  - Establish baseline metrics
-
-Phase 2 (Months 3-4): Model design + analysis
-  - Task graph modeling
-  - WCET analysis
-  - Scheduling algorithm design
-
-Phase 3 (Months 5-6): Implementation
-  - FreeRTOS patch
-  - KV Cache manager
-  - Power controller
-
-Phase 4 (Months 7-8): Evaluation
-  - Benchmarking
-  - Comparison with baseline
-  - Ablation study
-
-Phase 5 (Months 9-10): Paper writing
-  - Draft paper
-  - Revise based on feedback
-  - Submit to RTSS/RTAS
-```
-
----
-
-*最后更新: 2026-09-17*

FRAMEWORK.md

@@ -1,210 +0,0 @@
-# RTOS 针对大模型运行的优化方向 — 整体研究框架
-
-## 0. 核心问题
-
-> **矛盾**：RTOS追求确定性的微秒~毫秒级延迟，而LLM推理是计算密集、耗时长（ms~s级）、内存大（GB级）的软实时负载。
->
-> **目标**：在资源受限的边缘/嵌入式场景中，设计RTOS调度器/运行时，管理LLM推理过程中的**多源异构资源**，确保推理过程的**确定性**、**低延迟**与**能效**。
-
-**这不是让RTOS"跑大模型"，而是用RTOS做"LLM推理资源的调度与协调"。**
-
----
-
-## 1. 问题空间：硬件平台全景
-
-### 1.1 四层硬件抽象
-
-```
-┌───────────────────────────────────────────────────────────┐
-│  Controller Layer (MCU/应用CPU)                            │
-│  STM32H7 / ESP32-S3 / Cortex-M7 / RPi CM4                 │
-│  目标：跑量化后的小模型（Qwen-1.5B INT4, Qwen2.5-0.5B）    │
-│  RAM: 256KB~2MB, 主频: 400MHz~1GHz                       │
-├───────────────────────────────────────────────────────────┤
-│  SoC Layer (手机/车规SoC)                                  │
-│  骁龙8 Gen / 天玑9300 / NXP i.MX93                        │
-│  集成: CPU + NPU + GPU + ISP + DDR, 功耗: 3~15W          │
-│  目标：跑500M~3B参数模型, 实时语音/对话                    │
-├───────────────────────────────────────────────────────────┤
-│  Edge AI Accelerator (边缘盒子)                            │
-│  NVIDIA Jetson Orin / RK3588 / 地平线J5                    │
-│  集成: CPU集群 + 专用NPU + 大DDR, 功耗: 15~60W            │
-│  目标：跑7B~14B参数模型, 多模态推理                        │
-├───────────────────────────────────────────────────────────┤
-│  Server Layer (x86 / ARM Server)                           │
-│  x86: Intel/AMD, ARM: Ampere/Graviton                      │
-│  集成: 多Core + 多NPU/GPU + 大内存 + PCIe互联             │
-│  目标：跑14B~72B+参数模型, 云端推理                        │
-└───────────────────────────────────────────────────────────┘
-```
-
-### 1.2 各平台的关键约束
-
-| 平台层级 | 内存带宽 | 加速设备 | RTOS适配难度 | 核心挑战 |
-|---------|---------|---------|-------------|---------|
-| MCU级 | 几十MB/s | 无/简单DSP | 低（RTOS成熟） | 内存太小，模型必须极小 |
-| SoC级 | 几百MB/s | NPU + GPU | 中 | NPU驱动不开放，NPU-ARM通信难 |
-| Edge盒子 | GB/s级 | 专用NPU | 中高 | 多NPU调度、PCIe延迟 |
-| Server级 | 数十GB/s | 多GPU/NPU | 高 | NUMA、互联拓扑、调度粒度 |
-
----
-
-## 2. 五层技术框架
-
-```
-┌───────────────────────────────────────────────────────────────┐
-│  L5: 模型层 — Inference Engine                                │
-│  Quantization | KV Cache Layout | Speculative Decode         │
-│  目标：减少计算量、降低内存带宽需求                            │
-├───────────────────────────────────────────────────────────────┤
-│  L4: 运行时层 — Runtime & Scheduling                         │
-│  Task Graph | Pipeline Parallel | Memory Pool | Preemption   │
-│  目标：将LLM计算分解为RTOS可管理的task与事件                   │
-├───────────────────────────────────────────────────────────────┤
-│  L3: 资源抽象层 — Hardware Abstraction                       │
-│  Accelerator Driver | DMA Engine | Memory Controller         │
-│  目标：统一不同硬件的接口，暴露资源状态给调度器                 │
-├───────────────────────────────────────────────────────────────┤
-│  L2: 调度层 — RTOS Core                                       │
-│  Priority Scheduling | EDF | Hybrid Scheduling | IRQ mgmt   │
-│  目标：在保证硬实时约束的同时高效执行LLM推理                    │
-├───────────────────────────────────────────────────────────────┤
-│  L1: 硬件层 — SoC + Accelerator + Memory                    │
-│  ARM/RISC-V | LPDDR | PCIe | NPU/GPU                        │
-│  目标：理解硬件物理特性（缓存、带宽、拓扑）                     │
-└───────────────────────────────────────────────────────────────┘
-```
-
-### 2.1 L5 → L4 的映射关系
-
-```
-LLM推理阶段              RTOS任务映射
-──────────              ────────────
-Tokenization           → Task A (低优先级, 可中断)
-Embedding              → Task B (中优先级, 计算密集)
-Attention KV Cache     → Task C (高优先级, 延迟敏感)
-FFN                    → Task D (中优先级, 可pipeline)
-Logits/Sample          → Task E (中优先级, 可并行)
-Output decoding        → Task A (循环)
-```
-
----
-
-## 3. 六个核心优化方向
-
-```
-  方向1: 推理图任务调度                          ← 调度算法
-  方向2: KV Cache 与内存管理                    ← 内存管理
-  方向3: 加速器协同调度                          ← 资源协同
-  方向4: 量化与精度感知调度                      ← 精度-调度联合优化
-  方向5: 中断与实时响应                          ← 实时性保障
-  方向6: 能耗与热管理                            ← 能效优化
-```
-
-每个方向的深入分析见对应子文档（01~06）。
-
----
-
-## 4. 关键性能指标
-
-### 4.1 延迟指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| TTFT (Time to First Token) | 输入到第一个输出token的时间 | 预计算embedding、Attention优先级提升 |
-| TPOT (Time per Output Token) | 每个输出token的平均生成时间 | KV Cache池化、流水线并行 |
-| Tail Latency P99 | 99%请求的端到端延迟 | 减少context switch、避免priority inversion |
-| WCL (Worst-Case Latency) | 硬实时约束下的最大可接受延迟 | WCET分析、hybrid scheduling |
-
-### 4.2 资源指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| Memory Bandwidth Utilization | DDR带宽利用率 | DMA offload、带宽感知调度 |
-| Cache Hit Rate | L1/L2 Cache命中率 | Task pinning、数据局部性优化 |
-| NPU/GPU Utilization | 加速器利用率 | 双缓冲、pipeline parallel |
-| Power per Inference | 每次推理的能耗 | DVFS、idle-aware scheduling |
-
-### 4.3 实时性指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| Jitter | 延迟的方差 | 固定优先级、减少抢占 |
-| Preemption Overhead | 上下文切换开销 | 减少task数量、pin核心 |
-| Blocking Time | 低优先级被高优先级阻塞的时间 | Priority inheritance protocol |
-| Deadline Miss Ratio | 错过截止时间的比例 | EDF、adaptive priority boost |
-
----
-
-## 5. 研究方法论
-
-### 5.1 建模方法
-
-```
-LLM Inference Model:
-  T_total = Σ(T_encode + T_decode_i) for i = 1..N_tokens
-  T_encode = T_tokenizer + T_embedding + Σ(T_attention_l + T_ffn_l) for l = 1..N_layers
-
-RTOS Scheduling Model:
-  π(task) = priority(task)
-  τ(task) = WCET(task)
-  D(task) = deadline(task)
-  R(task) = response_time(task) = τ(task) + Σ(interference_from_higher_priority_tasks)
-```
-
-### 5.2 分析工具链
-
-- **WCET分析**：RTA (Response Time Analysis)、FDAS (Full Demand Analysis for Arbitrary Scheduling)
-- **模拟平台**：GEM5（全系统模拟）、NN-SIM（神经网络模拟）
-- **原型验证**：FreeRTOS/Zephyr + 自定义调度器 patch
-- **性能分析**：perf、ftrace、f2fs-trace、NPU profiler
-
-### 5.3 评估流程
-
-```
-1. 基准测量：不同平台上的LLM推理profile（延迟、带宽、能耗）
-2. 模型构建：将推理过程建模为RTOS任务图
-3. 算法设计：针对识别到的瓶颈设计调度/内存/协同策略
-4. 仿真验证：在模拟环境中验证理论分析
-5. 原型实现：在真实RTOS上实现关键模块
-6. 实测对比：优化前后指标对比
-```
-
----
-
-## 6. 与已有工作的关系
-
-| 已有工作 | 差异点 | 本研究的独特贡献 |
-|---------|-------|----------------|
-| vLLM / TGI (LLM Serving) | 服务器级，无实时性保证 | 边缘/嵌入式场景，硬实时约束 |
-| Micro-LLM (TinyLLM) | 模型压缩，不关注OS调度 | 从OS调度层优化推理延迟确定性 |
-| NPU SDK调度 | 封闭blackbox，不暴露接口 | 开放式RTOS集成，可分析可证明 |
-| CUDA Stream (GPU) | 无实时性分析，非抢占式 | RTOS可抢占、WCET可证明 |
-
----
-
-## 7. 文档结构索引
-
-| 文档 | 内容 |
-|-----|------|
-| [01-inference-scheduling.md](01-inference-scheduling.md) | 推理图任务分解与混合调度算法 |
-| [02-kv-cache-memory.md](02-kv-cache-memory.md) | KV Cache内存池与带宽竞争管理 |
-| [03-accelerator-collab.md](03-accelerator-collab.md) | CPU+NPU流水线协同与异步调度 |
-| [04-quantization-scheduling.md](04-quantization-scheduling.md) | 量化精度感知的调度策略 |
-| [05-irq-realtime.md](05-irq-realtime.md) | 中断管理与实时性保障 |
-| [06-power-thermal.md](06-power-thermal.md) | 能耗感知调度与热管理 |
-| [07-analysis-methods.md](07-analysis-methods.md) | 方法论与评估工具链 |
-
----
-
-## 8. 预期研究成果
-
-1. **理论**：LLM推理任务的实时性建模与调度分析理论
-2. **算法**：针对嵌入式场景的LLM推理调度算法（至少2种：hybrid-priority + EDF）
-3. **系统**：基于FreeRTOS/Zephyr的LLM推理调度原型系统
-4. **数据**：不同平台上的LLM推理profile数据集
-5. **论文**：针对RTSS、RTAS、ISLPED等实时系统的论文
-
----
-
-*最后更新: 2026-09-17*

最终稿文章规划.md

@@ -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 | 与第三方文章配置一致, 可比性最高 |
-
----

说明文档.md

@@ -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 的实时调度和资源隔离在什么负载范围内能显著改善实时任务确定性，这种改善需要付出多少吞吐和能耗代价，其优势又会在哪个硬件档位开始减弱。
-
-如果数据支持该关系，就形成四层硬件谱系、混合负载实时保号和统一评测方法三项论文贡献；如果某些档位不支持，也应把适配失败、容量上限和优势消失的边界作为研究结论的一部分。
-