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

方法论与评估工具链参考

1. 与本项目的关系

本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。

2. 核心资料

资料	等级	可支撑内容	本项目使用方式
J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. Google Research	A	大规模系统尾延迟的来源和重要性	支撑 P99/P99.9 而非均值作为核心证据
V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. arXiv	A/B	标准负载发生、场景、准确率与性能方法	作为 AI 基准方法学参照
MLCommons, “MLPerf Inference Submission Guide.” 官方文档	A	LoadGen、系统描述、Closed/Open division 和可比性	设计外部基准对齐和 manifest
ACM, “Artifact Review and Badging.” 官方政策	A	可用、可运行、可复用与结果复现	规划代码、数据和复现包
Linux Foundation Real-Time Linux, “Cyclictest.” 官方文档	A/B	RT 延迟测试设计、参数和限制	作为 Linux 辅助基线及测量避坑依据
R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. PDF	A/B	Jain 公平指数	多租户相对独占吞吐公平性

3. 本项目最低方法要求

3.1 公平对照

冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。

3.2 样本与重复

• 普通性能单元至少 5 次独立运行；
• 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性；
• 1 ms 周期任务记录计划释放数、缺失数和全部违约；
• 长稳运行 24 h，保留完整时间序列；
• 跨运行使用中位数、区间及按运行/时间块 bootstrap。

3.3 失败处理

拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。

3.4 三层证据

AI 目标负载：TTFT/TPOT/端到端/质量/可用性
关键保障负载：违约率/P99.9/Max/外部闭环
系统协同：有效吞吐/E-token/热/公平/恢复/24 h

任何“更优”结论都必须说明另外两层是否仍达标。

4. 工具链建议

目的	工具或方式	注意事项
OS 跟踪	SylixOS trace、ftrace、perf、事件日志	统一事件语义，不直接比较工具自身字段
RT 辅助测试	rt-tests/cyclictest、GPIO 打点	cyclictest 不等于业务端到端响应
加速器分析	CUDA profiler/DCGM、RKNN/RKLLM 日志	版本固定；设备事件只作阶段分解
外部时序	示波器、逻辑分析仪、CAN/RS485 分析仪	保存探头、触发、分辨率和空回路基线
功率与热	外部功率计/PDU、板载温度与频率	时间窗口对齐，遥测不替代整机功率
分析	R/Python、bootstrap、CDF/ECDF、时间序列	不静默删异常，不把相关样本当独立样本

5. 推荐数据结构

每次运行保留 manifest.json、requests.csv、rt.csv、power.csv、thermal.csv、events.log 和 summary.json。原始数据只读保存，图表和摘要由版本化脚本生成。

6. 不应直接推出的结论

• 统计显著不等于工程差异重要，应同时报告效应量与阈值。
• 单次最佳结果不能代表配置能力。
• 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。
• 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。