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

核心证据指标说明

1. 文档目的

本文依据 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 三层联合判定

正式实验单元只有同时满足下列条件，才能记为“通过”：

人工智能目标负载达标
AND 关键保障负载达标
AND 系统协同稳定

若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。

3. 人工智能目标负载层

3.1 TTFT

TTFT（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间：

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 的请求：

TPOT_i = (c_i - g_i) / (n_i - 1)

报告要求：

• 单位统一为 ms/token；
• n_i <= 1 的请求记为不可计算，不以 0 填充；
• 请求级 TPOT 与逐 token 间隔分布分开报告；
• 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善；
• 按输入长度、输出长度、并发度和到达率分组。

3.3 端到端响应时间

端到端响应时间描述从请求实际发出到完整可用结果到达的时间：

T_e2e,i = c_i - s_i

对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。

除分位数外，还需按业务完成期限 D_ai 报告按时完成率：

on_time_completion_ratio
= count(success_i AND T_e2e,i <= D_ai) / planned_requests

3.4 成功率、任务质量与输出可用性

三个概念必须分开计算：

指标	定义	典型失败
请求成功率	协议和运行时层面正常完成的请求数 / 计划请求数	超时、拒绝、崩溃、OOM、传输失败
任务质量	输出与冻结的参考答案或数据集指标之间的符合程度	精度下降、错误分类、内容偏差
输出可用率	同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数	空输出、截断、格式错误、不可解析或不满足质量门槛

计算式：

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 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率：

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，则发生截止期违约：

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

本文默认以完成间隔抖动作为关键保障负载的主抖动口径：

jitter_i = (f_i - f_(i-1)) - T

同时可报告绝对抖动 abs(jitter_i)。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。

报告要求：

• 有符号抖动报告上下尾，绝对抖动报告 P99/P99.9/Max；
• 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件；
• 给出样本量及采样周期；
• 不使用均值或标准差替代尾部分位数。

4.3 观测最大响应时间

关键任务响应时间定义为：

R_i = f_i - r_i
R_observed_max = max(R_i)

观测最大响应时间需要与截止期 D 并列展示，并给出裕量：

deadline_margin = D - R_observed_max

deadline_margin < 0 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。

4.4 外部接口响应时间

外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路：

T_external = t_external_output - t_external_input

采集要求：

• 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳；
• 固定波特率、帧长、总线负载、网络拓扑和时间戳位置；
• 报告空回路基线、测量分辨率和仪器误差；
• 报告 P50/P99/P99.9/Max、超时和丢帧；
• 内核或应用日志仅作为归因证据，不能替代外部闭环测量。

5. 系统协同层

5.1 有效吞吐

有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出：

effective_throughput
= qualified_output_units / measurement_window

对 LLM，qualified_output_units 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。

合格请求至少满足：

请求成功
AND TTFT/端到端期限达标
AND 任务质量达标
AND 输出可用
AND 同一窗口内关键保障负载达标

有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。

5.2 E/token

在与负载统计完全一致的窗口 [t0,t1] 内：

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 和内存相关实际频率；
• 降频事件及其原因；
• 功率、风扇/散热策略；
• 同时间轴上的时延、吞吐和违约。

降频时间比例定义为：

throttling_ratio = throttled_time / valid_measurement_time

热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化：

thermal_drift(metric)
= (hot_steady_metric - early_steady_metric) / early_steady_metric

时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。

5.4 多任务公平性

多租户或多模型并发场景使用各任务相对独占性能 x_i 计算 Jain 公平指数：

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