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

# 核心证据指标说明

## 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 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。