forked from eaiadmin/rtos_llm_opt
docs: add metrics and research references
This commit is contained in:
Mo1s
@@ -3,7 +3,6 @@
|
||||
> 版本: v2.1 起草日期: 2026-09-21
|
||||
> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
|
||||
> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
|
||||
> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
|
||||
|
||||
---
|
||||
|
||||
|
||||
+1
-20
@@ -38,26 +38,7 @@
|
||||
|
||||
GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
|
||||
|
||||
### 2.2 平台 A：现有 V100 服务器
|
||||
|
||||
依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
|
||||
|
||||
实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
|
||||
|
||||
分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
|
||||
|
||||
### 2.3 平台 B：现有 RK3588 工业盒
|
||||
|
||||
依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
|
||||
|
||||
- B16：全量 16 GB，记为 T4-L。
|
||||
- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
|
||||
- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
|
||||
- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
|
||||
|
||||
**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
|
||||
|
||||
### 2.4 测量设备
|
||||
### 2.2 测量设备
|
||||
|
||||
| 测量对象 | 工具与接线 | 要求 |
|
||||
|---|---|---|
|
||||
|
||||
+5
-2
@@ -7,8 +7,9 @@
|
||||
1. `01-研究逻辑说明.md`
|
||||
2. `02-基础设备与算力基础.md`
|
||||
3. `03-实验设计.md`
|
||||
4. `04-论文写作规划.md`
|
||||
5. `05-论文结构总览.png`
|
||||
4. `metric.md`
|
||||
5. `04-论文写作规划.md`
|
||||
6. `05-论文结构总览.png`
|
||||
|
||||
## 文件说明
|
||||
|
||||
@@ -18,6 +19,8 @@
|
||||
- T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
|
||||
- `03-实验设计.md`
|
||||
- 准入条件、对照原则、混合负载场景、指标与验收方法
|
||||
- `metric.md`
|
||||
- 三层核心证据指标的统一定义、计算公式、采集要求与报告口径
|
||||
- `04-论文写作规划.md`
|
||||
- 论文结构、章节分工、图表规划和证据映射
|
||||
- `05-论文结构总览.png`
|
||||
|
||||
@@ -0,0 +1,397 @@
|
||||
# 核心证据指标说明
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文依据 [01-研究逻辑说明.md](./01-研究逻辑说明.md) 第 8 节，对后续实验必须覆盖的三层核心证据指标给出统一定义、计算方法、采集要求和报告口径。
|
||||
|
||||
本指标体系用于回答一个核心问题：
|
||||
|
||||
> **在人工智能目标负载与关键保障负载并存时，RTOS 能否在不牺牲任务质量和系统有效产出的前提下，提高系统的稳定性、可预测性与可保障性；这种提升在什么负载、功耗、温度和部署档位下成立。**
|
||||
|
||||
指标分为三层：
|
||||
|
||||
1. **人工智能目标负载层**：智能任务是否及时、正确、可用地完成；
|
||||
2. **关键保障负载层**：周期控制、联锁和外部闭环是否仍满足实时约束；
|
||||
3. **系统协同层**：双目标并存时，系统是否保持有效、节能、公平、稳定且可恢复。
|
||||
|
||||
任何单一指标都不能独立支撑系统优越性结论。正式结论必须同时给出三层证据，并说明平台、OS、模型、负载、功耗、温度和运行时长等适用边界。
|
||||
|
||||
## 2. 统一测量原则
|
||||
|
||||
### 2.1 时间点与时钟
|
||||
|
||||
人工智能请求至少记录以下时间点：
|
||||
|
||||
| 符号 | 含义 |
|
||||
|---|---|
|
||||
| `a_i` | 请求计划到达时间 |
|
||||
| `s_i` | 请求实际发送时间 |
|
||||
| `u_i` | 服务端接收时间，可取得时记录 |
|
||||
| `g_i` | 首个有效输出到达时间 |
|
||||
| `c_i` | 完整输出到达或任务完成时间 |
|
||||
|
||||
周期关键任务至少记录：
|
||||
|
||||
| 符号 | 含义 |
|
||||
|---|---|
|
||||
| `r_i` | 计划释放时间 |
|
||||
| `q_i` | 进入就绪态时间，可等价取得时使用 |
|
||||
| `b_i` | 实际开始执行时间 |
|
||||
| `f_i` | 完成时间 |
|
||||
| `T` | 任务周期 |
|
||||
| `D` | 相对截止期 |
|
||||
|
||||
同一指标必须在同一时钟域内计算，优先使用单调时钟。跨设备测量需在 `manifest` 中记录同步方法、同步误差和时间戳位置；同步误差不足以支持单向时延时，改报往返时延，不将往返时延简单除以二作为单向结果。
|
||||
|
||||
### 2.2 统计与报告
|
||||
|
||||
- 时延和抖动至少报告样本数、`P50/P95/P99/P99.9` 和观测最大值；样本不足以稳定估计 `P99.9` 时，明确标为探索性结果并改以 `P99` 为主。
|
||||
- 每个普通性能单元至少独立运行 5 次；跨运行报告中位数、区间和置信区间，不只报告最佳一次。
|
||||
- 最大值只能表述为“指定时长和工况下的观测最大值”，不能写成理论 `WCET`。
|
||||
- 零违约只能表述为“在 `N` 次计划释放中未观测到违约”，不能据此证明绝对硬实时安全。
|
||||
- 原始超时、拒绝、OOM、丢样和失败请求必须保留，不能从分母中静默删除。
|
||||
- OS 对照需冻结硬件、模型与量化版本、输入/输出长度、到达序列、随机种子、CPU/IRQ/频率配置、内存预算、加速器数量、散热条件和测量窗口。
|
||||
|
||||
### 2.3 三层联合判定
|
||||
|
||||
正式实验单元只有同时满足下列条件，才能记为“通过”：
|
||||
|
||||
```text
|
||||
人工智能目标负载达标
|
||||
AND 关键保障负载达标
|
||||
AND 系统协同稳定
|
||||
```
|
||||
|
||||
若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。
|
||||
|
||||
## 3. 人工智能目标负载层
|
||||
|
||||
### 3.1 TTFT
|
||||
|
||||
`TTFT`（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间：
|
||||
|
||||
```text
|
||||
TTFT_i = g_i - s_i
|
||||
```
|
||||
|
||||
该指标包含请求传输、排队、调度和 prefill 阶段。负载发生器还应记录发送滞后 `s_i-a_i`，防止发生器本身饱和导致排队时间被遗漏。
|
||||
|
||||
报告要求：
|
||||
|
||||
- 单位统一为 `ms`；
|
||||
- 按模型、输入长度、并发度和到达率分别汇总；
|
||||
- 至少报告 `P50/P95/P99/P99.9/Max`、样本数和超时数；
|
||||
- 流式接口以客户端收到首个**有效内容 token**为终点，不把连接确认、空片段或仅含元数据的事件作为首 token；
|
||||
- 非生成式人工智能任务不使用 `TTFT`，改用任务对应的首结果时间，并明确终点语义。
|
||||
|
||||
### 3.2 TPOT
|
||||
|
||||
`TPOT`（Time Per Output Token）描述首 token 之后的平均生成间隔。对输出 token 数 `n_i > 1` 的请求：
|
||||
|
||||
```text
|
||||
TPOT_i = (c_i - g_i) / (n_i - 1)
|
||||
```
|
||||
|
||||
报告要求：
|
||||
|
||||
- 单位统一为 `ms/token`；
|
||||
- `n_i <= 1` 的请求记为不可计算，不以 0 填充；
|
||||
- 请求级 `TPOT` 与逐 token 间隔分布分开报告；
|
||||
- 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善；
|
||||
- 按输入长度、输出长度、并发度和到达率分组。
|
||||
|
||||
### 3.3 端到端响应时间
|
||||
|
||||
端到端响应时间描述从请求实际发出到完整可用结果到达的时间：
|
||||
|
||||
```text
|
||||
T_e2e,i = c_i - s_i
|
||||
```
|
||||
|
||||
对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。
|
||||
|
||||
除分位数外，还需按业务完成期限 `D_ai` 报告按时完成率：
|
||||
|
||||
```text
|
||||
on_time_completion_ratio
|
||||
= count(success_i AND T_e2e,i <= D_ai) / planned_requests
|
||||
```
|
||||
|
||||
### 3.4 成功率、任务质量与输出可用性
|
||||
|
||||
三个概念必须分开计算：
|
||||
|
||||
| 指标 | 定义 | 典型失败 |
|
||||
|---|---|---|
|
||||
| 请求成功率 | 协议和运行时层面正常完成的请求数 / 计划请求数 | 超时、拒绝、崩溃、OOM、传输失败 |
|
||||
| 任务质量 | 输出与冻结的参考答案或数据集指标之间的符合程度 | 精度下降、错误分类、内容偏差 |
|
||||
| 输出可用率 | 同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数 | 空输出、截断、格式错误、不可解析或不满足质量门槛 |
|
||||
|
||||
计算式：
|
||||
|
||||
```text
|
||||
success_ratio = successful_requests / planned_requests
|
||||
usable_output_ratio = usable_outputs / planned_requests
|
||||
```
|
||||
|
||||
任务质量应按负载类型选择并预先冻结：
|
||||
|
||||
- LLM：固定题集得分、精确匹配、规则判分或人工盲评结果；
|
||||
- 视觉检测：`mAP`、召回率、误检率；
|
||||
- 分类：准确率、F1 等；
|
||||
- 语音识别：`WER/CER`；
|
||||
- 故障诊断：检出率、漏报率、误报率。
|
||||
|
||||
量化或调度优化必须同时报告质量变化。仅提高速度但跌破质量门槛的输出不得计入有效结果。
|
||||
|
||||
### 3.5 长时间运行稳定性
|
||||
|
||||
人工智能负载稳定性用于检查持续运行时的性能和正确性是否退化。至少观测：
|
||||
|
||||
- 每个时间块的 `TTFT/TPOT/T_e2e` 分位数；
|
||||
- 请求成功率、输出可用率和错误类型；
|
||||
- 吞吐、队列长度、内存和 KV Cache 占用；
|
||||
- 温度、实际频率、进程重启和驱动异常。
|
||||
|
||||
建议将 24 h 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率：
|
||||
|
||||
```text
|
||||
latency_drift = (late_block_metric - early_block_metric)
|
||||
/ early_block_metric
|
||||
```
|
||||
|
||||
报告时需给出完整时间序列，不能仅给 24 h 总平均值。持续内存增长、尾延迟恶化、成功率下降或周期性驱动错误均应作为稳定性退化证据。
|
||||
|
||||
## 4. 关键保障负载层
|
||||
|
||||
### 4.1 Deadline miss ratio
|
||||
|
||||
对第 `i` 次计划释放，若 `f_i > r_i + D`，则发生截止期违约：
|
||||
|
||||
```text
|
||||
miss_i = 1, if f_i > r_i + D; otherwise 0
|
||||
deadline_miss_ratio = sum(miss_i) / planned_releases
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
- 分母必须是计划释放次数，而不是实际完成次数；
|
||||
- 未释放、跳过、丢失或未完成的实例必须单独标记，不能直接从分母删除；
|
||||
- 同时报告违约数、计划释放数、连续违约长度和违约发生时间；
|
||||
- 按场景、负载强度和 OS 配置分别统计。
|
||||
|
||||
### 4.2 P99/P99.9 jitter
|
||||
|
||||
本文默认以完成间隔抖动作为关键保障负载的主抖动口径：
|
||||
|
||||
```text
|
||||
jitter_i = (f_i - f_(i-1)) - T
|
||||
```
|
||||
|
||||
同时可报告绝对抖动 `abs(jitter_i)`。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。
|
||||
|
||||
报告要求：
|
||||
|
||||
- 有符号抖动报告上下尾，绝对抖动报告 `P99/P99.9/Max`；
|
||||
- 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件；
|
||||
- 给出样本量及采样周期；
|
||||
- 不使用均值或标准差替代尾部分位数。
|
||||
|
||||
### 4.3 观测最大响应时间
|
||||
|
||||
关键任务响应时间定义为：
|
||||
|
||||
```text
|
||||
R_i = f_i - r_i
|
||||
R_observed_max = max(R_i)
|
||||
```
|
||||
|
||||
观测最大响应时间需要与截止期 `D` 并列展示，并给出裕量：
|
||||
|
||||
```text
|
||||
deadline_margin = D - R_observed_max
|
||||
```
|
||||
|
||||
`deadline_margin < 0` 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。
|
||||
|
||||
### 4.4 外部接口响应时间
|
||||
|
||||
外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路：
|
||||
|
||||
```text
|
||||
T_external = t_external_output - t_external_input
|
||||
```
|
||||
|
||||
采集要求：
|
||||
|
||||
- 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳；
|
||||
- 固定波特率、帧长、总线负载、网络拓扑和时间戳位置；
|
||||
- 报告空回路基线、测量分辨率和仪器误差；
|
||||
- 报告 `P50/P99/P99.9/Max`、超时和丢帧；
|
||||
- 内核或应用日志仅作为归因证据，不能替代外部闭环测量。
|
||||
|
||||
## 5. 系统协同层
|
||||
|
||||
### 5.1 有效吞吐
|
||||
|
||||
有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出：
|
||||
|
||||
```text
|
||||
effective_throughput
|
||||
= qualified_output_units / measurement_window
|
||||
```
|
||||
|
||||
对 LLM，`qualified_output_units` 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。
|
||||
|
||||
合格请求至少满足：
|
||||
|
||||
```text
|
||||
请求成功
|
||||
AND TTFT/端到端期限达标
|
||||
AND 任务质量达标
|
||||
AND 输出可用
|
||||
AND 同一窗口内关键保障负载达标
|
||||
```
|
||||
|
||||
有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。
|
||||
|
||||
### 5.2 E/token
|
||||
|
||||
在与负载统计完全一致的窗口 `[t0,t1]` 内：
|
||||
|
||||
```text
|
||||
E_total = integral(P(t), t0, t1)
|
||||
E/token = E_total / N_output
|
||||
tokens/J = N_output / E_total
|
||||
```
|
||||
|
||||
其中 `N_output` 为窗口内实际收到的输出 token 数。主结果使用整机输入端实测能耗，包含排队、空闲和失败请求消耗；板载或加速器遥测用于归因，不能替代整机测量。
|
||||
|
||||
要求：
|
||||
|
||||
- 单位为 `J/token`，同时报告平均功率、峰值采样功率和仪器采样率；
|
||||
- `N_output = 0` 时记为不可计算，不记为 0；
|
||||
- 同时报有效 `E/token = E_total / N_qualified_output`，以反映失败和不合格输出的成本；
|
||||
- 混合视觉与 LLM 负载时，不将全部能耗归因于 LLM，应使用独立对照或单列场景总能耗；
|
||||
- 只在人工智能与关键保障约束均满足的配置之间比较能效。
|
||||
|
||||
### 5.3 温度、降频与热漂移
|
||||
|
||||
全程同步记录：
|
||||
|
||||
- 环境温度、芯片/板卡温度；
|
||||
- CPU、GPU、NPU 和内存相关实际频率；
|
||||
- 降频事件及其原因；
|
||||
- 功率、风扇/散热策略；
|
||||
- 同时间轴上的时延、吞吐和违约。
|
||||
|
||||
降频时间比例定义为：
|
||||
|
||||
```text
|
||||
throttling_ratio = throttled_time / valid_measurement_time
|
||||
```
|
||||
|
||||
热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化：
|
||||
|
||||
```text
|
||||
thermal_drift(metric)
|
||||
= (hot_steady_metric - early_steady_metric) / early_steady_metric
|
||||
```
|
||||
|
||||
时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。
|
||||
|
||||
### 5.4 多任务公平性
|
||||
|
||||
多租户或多模型并发场景使用各任务相对独占性能 `x_i` 计算 Jain 公平指数：
|
||||
|
||||
```text
|
||||
J = (sum(x_i))^2 / (k * sum(x_i^2))
|
||||
```
|
||||
|
||||
其中 `k` 为任务数，`x_i` 可取“共享运行时的有效吞吐 / 独占运行时的有效吞吐”。`J` 越接近 1，吞吐分配越均衡。
|
||||
|
||||
公平性不能只用一个指数概括，还应报告：
|
||||
|
||||
- 每个任务或租户的有效吞吐、`TTFT`、端到端时延和成功率；
|
||||
- 关键任务是否满足各自服务等级；
|
||||
- 饥饿次数、最长无服务时间和优先级倒置事件；
|
||||
- 高优先级保障所造成的低优先级代价。
|
||||
|
||||
对具有不同优先级和服务等级的任务，“公平”不是平均分配资源，而是在满足保障等级后不存在非预期饥饿。因此 Jain 指数只作为补充证据，不能替代逐任务 SLA 结果。
|
||||
|
||||
### 5.5 恢复能力
|
||||
|
||||
恢复测试应预先定义故障注入时刻 `t_fault` 和恢复判据。至少覆盖推理进程重启和队列过载；驱动重置、设备掉线或网络故障仅在存在安全、可恢复路径时执行。
|
||||
|
||||
建议记录：
|
||||
|
||||
| 指标 | 定义 |
|
||||
|---|---|
|
||||
| 故障检测时间 | 检测到故障的时刻减 `t_fault` |
|
||||
| 服务恢复时间 | 恢复到预定成功率和有效吞吐稳定区间的时刻减 `t_fault` |
|
||||
| 数据损失 | 故障窗口内丢失、重复或无法确认的请求数 |
|
||||
| 实时影响 | 故障窗口内关键任务违约数及最大响应时间 |
|
||||
| 重试成功率 | 成功重试请求数 / 发起重试请求数 |
|
||||
| 不可恢复故障数 | 需要人工干预、重启系统或丢失测量链路的次数 |
|
||||
|
||||
恢复完成必须同时满足人工智能服务恢复和关键保障负载重新达标。仅进程重新启动但吞吐、队列或实时任务仍未恢复，不算恢复完成。
|
||||
|
||||
### 5.6 24 h 长稳表现
|
||||
|
||||
24 h 长稳采用人工智能目标负载、关键保障负载及必要伴生竞争负载的混合场景。至少连续记录：
|
||||
|
||||
- 三层核心指标的固定时间块汇总；
|
||||
- 温度、频率、功率和降频事件；
|
||||
- 内存、KV Cache、句柄/线程和队列长度；
|
||||
- OOM、驱动错误、进程重启、接口超时和日志中断；
|
||||
- 注入故障前后恢复曲线。
|
||||
|
||||
长稳通过条件至少包括：
|
||||
|
||||
1. 完成连续 24 h 有效测量；
|
||||
2. 无不可恢复故障；
|
||||
3. 测量与日志链路无中断；
|
||||
4. 无持续、不可解释的内存增长；
|
||||
5. 人工智能输出与关键保障负载在冻结阈值内；
|
||||
6. 故障注入后在冻结时间内恢复。
|
||||
|
||||
若发生故障，必须保留原始数据并分析，不得删除故障批次后宣称长稳通过。
|
||||
|
||||
## 6. 指标—数据源—实验映射
|
||||
|
||||
| 层级 | 指标 | 主要数据源 | 主要实验/场景 |
|
||||
|---|---|---|---|
|
||||
| 人工智能目标负载 | `TTFT/TPOT`、端到端响应时间 | `requests.csv`、负载发生器、推理日志 | E2/E3/E8，L1～L7 |
|
||||
| 人工智能目标负载 | 成功率、质量、输出可用率 | 请求日志、固定题集/数据集、判分程序 | E2/E3/E4/E8 |
|
||||
| 人工智能目标负载 | 长时间稳定性 | 分块请求汇总、内存和错误日志 | E8，24 h |
|
||||
| 关键保障负载 | 违约率、抖动、最大响应时间 | `rt.csv`、RTOS trace、GPIO 打点 | E1/E3/E7/E8，L0/L2～L7 |
|
||||
| 关键保障负载 | 外部接口响应时间 | 示波器、逻辑/总线分析仪、抓包 | E1/E3/E8 |
|
||||
| 系统协同 | 有效吞吐 | 请求、质量和 RT 数据联合计算 | E3/E5/E7/E8 |
|
||||
| 系统协同 | `E/token` | 外部功率计/PDU、`requests.csv` | E2/E6/E8 |
|
||||
| 系统协同 | 温度、降频、热漂移 | `thermal.csv`、频率与功率日志 | E6/E8 |
|
||||
| 系统协同 | 多任务公平性 | 各租户请求日志和独占基线 | E5，L6 |
|
||||
| 系统协同 | 恢复与 24 h 长稳 | `events.log`、三层时间序列 | E8，L7 |
|
||||
|
||||
## 7. 最小数据产物
|
||||
|
||||
每次运行至少保存：
|
||||
|
||||
| 文件 | 必需内容 |
|
||||
|---|---|
|
||||
| `manifest.json` | 平台/档位、OS/BSP/驱动、模型校验值、量化、输入、到达序列、CPU/IRQ/频率/内存配置、环境和仪器信息 |
|
||||
| `requests.csv` | 请求 ID、计划到达、实际发送、首/末输出、输出数、成功、质量、可用性、超时/拒绝原因 |
|
||||
| `rt.csv` | 计划释放、就绪、开始、完成、CPU、违约、丢失/跳过状态 |
|
||||
| `power.csv` | 时间戳、功率、电压、电流、仪器来源 |
|
||||
| `thermal.csv` | 时间戳、环境/芯片温度、实际频率、降频状态 |
|
||||
| `events.log` | OOM、驱动错误、故障注入、重启、网络异常、测量故障 |
|
||||
| `summary.json` | 三层指标、样本量、分位数、最大值、区间、阈值和判定结果 |
|
||||
|
||||
所有派生指标必须能够从原始记录重新计算。汇总程序不得覆盖原始文件，不得静默剔除异常值。
|
||||
|
||||
## 8. 核心证据表述模板
|
||||
|
||||
正式报告应采用带边界的联合表述：
|
||||
|
||||
> 在 `[平台/档位]`、`[模型与输入输出配置]`、`[到达率与竞争负载]`、`[功耗和温度条件]` 下，`[OS/配置]` 在人工智能目标负载达到 `[TTFT/TPOT/质量/可用率]`、关键保障负载达到 `[违约率/P99.9/观测最大响应]` 的同时，实现 `[有效吞吐和 E/token]`，并在 `[故障与 24 h 长稳结果]` 下保持稳定。相对 `[对照组]` 的改善为 `[效应量及置信区间]`。
|
||||
|
||||
不应只写“平均时延更低”“吞吐更高”或“24 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。
|
||||
Reference in New Issue
Block a user