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

方向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 必须共同服从的方法论中轴。