Mo1s
60e0d2e46b
# Conflicts: # 10-研究框架/README.md # 项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md # 项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md
67 lines
4.1 KiB
Markdown
67 lines
4.1 KiB
Markdown
# 方法论与评估工具链参考
|
|
|
|
## 1. 与本项目的关系
|
|
|
|
本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。
|
|
|
|
## 2. 核心资料
|
|
|
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
|
|---|---|---|---|
|
|
| J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. [Google Research](https://research.google/pubs/the-tail-at-scale/) | A | 大规模系统尾延迟的来源和重要性 | 支撑 P99/P99.9 而非均值作为核心证据 |
|
|
| V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. [arXiv](https://arxiv.org/abs/1911.02549) | A/B | 标准负载发生、场景、准确率与性能方法 | 作为 AI 基准方法学参照 |
|
|
| MLCommons, “MLPerf Inference Submission Guide.” [官方文档](https://docs.mlcommons.org/inference/submission/) | A | LoadGen、系统描述、Closed/Open division 和可比性 | 设计外部基准对齐和 manifest |
|
|
| ACM, “Artifact Review and Badging.” [官方政策](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | A | 可用、可运行、可复用与结果复现 | 规划代码、数据和复现包 |
|
|
| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | RT 延迟测试设计、参数和限制 | 作为 Linux 辅助基线及测量避坑依据 |
|
|
| R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. [PDF](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf) | A/B | Jain 公平指数 | 多租户相对独占吞吐公平性 |
|
|
|
|
## 3. 本项目最低方法要求
|
|
|
|
### 3.1 公平对照
|
|
|
|
冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。
|
|
|
|
### 3.2 样本与重复
|
|
|
|
- 普通性能单元至少 5 次独立运行；
|
|
- 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性；
|
|
- 1 ms 周期任务记录计划释放数、缺失数和全部违约；
|
|
- 长稳运行 24 h，保留完整时间序列；
|
|
- 跨运行使用中位数、区间及按运行/时间块 bootstrap。
|
|
|
|
### 3.3 失败处理
|
|
|
|
拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。
|
|
|
|
### 3.4 三层证据
|
|
|
|
```text
|
|
AI 目标负载：TTFT/TPOT/端到端/质量/可用性
|
|
关键保障负载：违约率/P99.9/Max/外部闭环
|
|
系统协同：有效吞吐/E-token/热/公平/恢复/24 h
|
|
```
|
|
|
|
任何“更优”结论都必须说明另外两层是否仍达标。
|
|
|
|
## 4. 工具链建议
|
|
|
|
| 目的 | 工具或方式 | 注意事项 |
|
|
|---|---|---|
|
|
| OS 跟踪 | SylixOS trace、ftrace、perf、事件日志 | 统一事件语义，不直接比较工具自身字段 |
|
|
| RT 辅助测试 | rt-tests/cyclictest、GPIO 打点 | cyclictest 不等于业务端到端响应 |
|
|
| 加速器分析 | CUDA profiler/DCGM、RKNN/RKLLM 日志 | 版本固定；设备事件只作阶段分解 |
|
|
| 外部时序 | 示波器、逻辑分析仪、CAN/RS485 分析仪 | 保存探头、触发、分辨率和空回路基线 |
|
|
| 功率与热 | 外部功率计/PDU、板载温度与频率 | 时间窗口对齐，遥测不替代整机功率 |
|
|
| 分析 | R/Python、bootstrap、CDF/ECDF、时间序列 | 不静默删异常，不把相关样本当独立样本 |
|
|
|
|
## 5. 推荐数据结构
|
|
|
|
每次运行保留 `manifest.json`、`requests.csv`、`rt.csv`、`power.csv`、`thermal.csv`、`events.log` 和 `summary.json`。原始数据只读保存，图表和摘要由版本化脚本生成。
|
|
|
|
## 6. 不应直接推出的结论
|
|
|
|
- 统计显著不等于工程差异重要，应同时报告效应量与阈值。
|
|
- 单次最佳结果不能代表配置能力。
|
|
- 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。
|
|
- 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。
|