moyixin/rtos_llm_opt
1
0
Fork 0
forked from eaiadmin/rtos_llm_opt
Code Pull Requests Activity

Merge remote-tracking branch 'origin/main' into moyixin-patch-1

Browse Source 
# Conflicts:
#	02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md
This commit is contained in:
Mo1s
2026-09-24 10:30:34 +08:00
parent b7863721fe feddff6fe4
commit e25991c97a
85 changed files with 8457 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/01-研究逻辑说明.md
+178
View File
@@ -0,0 +1,178 @@
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
## 1. 文档目的
本文用于解释本目录中的研究逻辑结构，并说明：
- [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) 如何承载完整的 `T5~T1` 五类部署形态与 `11` 个代表档位；
- [03-实验设计.md](./03-实验设计.md) 如何把这些硬件条件组织成可复现的对照实验；
- [04-论文写作规划.md](./04-论文写作规划.md) 如何把证据组织成一篇系统化论文。
三份文档承担的职责如下：
| 文档 | 回答的问题 | 在研究中的作用 |
|---|---|---|
| [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) | 在哪些部署形态与硬件条件下验证？ | 定义 `T5~T1` 五类部署形态、五种算力基础与十一档实验矩阵 |
| [03-实验设计.md](./03-实验设计.md) | 如何产生可信、可复现、可比较的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
| [04-论文写作规划.md](./04-论文写作规划.md) | 如何把这些证据组织成论文贡献？ | 把研究问题、方法、结果和边界映射成论文结构 |
整个研究的主线是：
> **研究对象定义清楚 → 验证矩阵完整展开 → 公平对照与双目标实验 → 数据可复现 → 跨档位规律与边界 → 论文贡献。**
## 2. 研究对象
这个项目的研究对象是：
> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制。**
本目录后续所有实验和文档都围绕下面这条主线展开：
- **研究对象**：大型跨平台实时操作系统这一类平台；
- **主实验样例**：SylixOS；
- **外部参照样本**：QNX、VxWorks、INTEGRITY、LynxOS-178；
- **系统场景**：任务关键系统；
- **目标负载**：人工智能目标负载；
- **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
- **硬件角色**：验证矩阵。
在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
## 3. T5~T1 五类部署形态与 11 个代表档位
硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
1. **验证矩阵**：在不同资源条件下检验同一系统问题是否成立；
2. **证据组织框架**：把结果放到统一谱系中观察规律与边界；
3. **产业可解释性**：让不同部署形态都能找到对应的现实位置。
对应关系如下：
| 部署形态 | 主要系统角色 | 主要验证重点 |
|---|---|---|
| `T5` 控制端 | 极紧资源预算下的任务关键控制节点 | 强实时、极小内存、低功耗边界 |
| `T4` 设备端 SoC | 设备本体内的统一内存异构平台 | CPU/NPU/GPU 共享资源与带宽隔离 |
| `T3` 边缘节点 | 设备附近的近源推理节点 | 多任务并发、热稳定性、边缘协同 |
| `T2` 桌面 / 工作站单机 | 单机高密本地推理平台 | 单机多卡调度、NVLink/PCIe 拓扑、公平性 |
| `T1` 服务器 / 集群 | 多节点大模型服务平台 | 跨节点通信、分布式调度、规模扩展 |
`T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
`T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
## 4. 人工智能目标负载与系统负载结构
在任务关键系统里，负载应至少分成三类：
| 负载类型 | 定义 | 例子 |
|---|---|---|
| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、联锁、状态采集、执行输出 |
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、后台通信、模型加载、I/O |
本项目重点评估的是：
> **RTOS 协调人工智能目标负载与关键保障负载时，对系统边界的维持能力与成立条件。**
这一步会直接影响实验设计、论文结构和评价指标。
## 5. 准入与对照的实验顺序
本项目采用分阶段准入机制：
| 门槛 | 核心检查内容 |
|---|---|
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑 |
| `G1` 测量准入 | 单调时钟、日志、外部测量链路、功率计 |
| `G2` 加速器准入 | CUDA / RKLLM / RKNN / 驱动 / 最小算子 |
| `G3` 模型准入 | 模型转换、加载、正确推理与峰值内存 |
| `G4` 混合场景准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
只有通过 `G4` 的平台与配置，才能进入正式对照。
## 6. O0~O4 对照组结构
主对照统一采用：
| 编号 | 配置 | 作用 |
|---|---|---|
| `O0` | 普通 Linux | 通用系统基线 |
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
| `O3` | SylixOS 优化配置 | 主实验组 |
必要时增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，并继续保持“普通 Linux”和“实时增强 Linux”的对照边界。
## 7. 实验逻辑如何展开
实验逻辑遵循从简单到复杂、从单目标到双目标的顺序：
1. 先确认平台、模型与测量链路可用；
2. 再测仅人工智能目标负载的基线表现；
3. 再测仅关键保障负载的下界行为；
4. 再测两者并存的核心场景；
5. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
这条顺序用于区分平台就绪性问题与系统机制边界问题。
对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
## 8. 哪些指标构成核心证据
后续证据链必须覆盖三层：
### 8.1 人工智能目标负载层
- `TTFT`
- `TPOT`
- 端到端响应时间
- 成功率、任务质量、输出可用性
- 长时间运行稳定性
### 8.2 关键保障负载层
- `deadline miss ratio`
- `P99/P99.9 jitter`
- 观测最大响应时间
- 外部接口响应时间
### 8.3 系统协同层
- 有效吞吐
- `E/token`
- 温度、降频和热漂移
- 多任务公平性
- 恢复能力与 24 h 长稳表现
项目最终形成的核心判断是：
> **在双目标约束下，RTOS 对系统稳定性、可预测性与可保障性的提升边界。**
## 9. 数据如何转化为论文贡献
论文贡献排序如下：
| 贡献 | 所需证据 | 对应论文位置 |
|---|---|---|
| `C1` RTOS 对人工智能目标负载与关键保障负载的实时保障优势 | 双目标达标、尾部行为、有效吞吐与恢复结果 | 第1、4、5、7、8章 |
| `C2` T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵 | 跨档位容量、功耗、拓扑与边界分析 | 第3、7、8章 |
| `C3` 可复现的方法论与基准对齐 | 准入、元数据、第三方基准复现、消融与统计口径 | 第5、7、9章 |
在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
## 10. 最终闭环
本研究形成的核心结论关系是：
> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
- 研究对象清楚；
- 验证矩阵完整；
- 对照关系公平；
- 评价框架统一；
- 论文叙事和产业叙事都能站住。
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md
+783
View File
@@ -0,0 +1,783 @@
# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
> 版本: v2.1 起草日期: 2026-09-21
> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
---
## 0. 场景、算力基础与设备档位总览
### 0.1 研究框架与设备谱系的对应关系
研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
这里完整呈现硬件与指标颗粒度，并明确：
> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
| 研究维度 | 定义 | 在本文件中的落地方式 |
|---|---|---|
| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
`T5~T1` 是用于实验组织的**部署形态代码**。
这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
后续实验中，这些档位分别承担的是：
- 人工智能目标负载在不同资源条件下的时效与有效性验证；
- 关键保障负载在不同资源条件下的边界验证；
- RTOS 在双目标约束下的机制有效性验证。
### 0.2 分级维度与分档规则
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
**分档规则**: 相邻两档的边界值归入**上界一侧**
| 部署形态 | 代码 | 代表档位 | 容量范围 | 说明 |
| -------- | --- | --------------- | ---------------- | ---------------- |
| **T5 控制端场景** | T5 | **T5-L / T5-M / T5-H** | **1~8 G** | 运行在控制器或轻量控制盒本体 |
| **T4 设备端 SoC 场景** | T4 | **T4-L / T4-M** | **8~32 G** | 运行在设备本体 SoC 上 |
| **T3 边缘节点场景** | T3 | **T3-L** | **32~64 G / 48 G 独显** | 运行在设备附近的边缘节点 |
| **T2 桌面/工作站单机场景** | T2 | **T2-L / T2-M / T2-H** | **64~512 G** | 研发或本地服务用单机多卡 |
| **T1 服务器/集群场景** | T1 | **T1-L / T1-H** | **512 G~2 T** | 多节点分布式推理 |
> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
### 0.3 全谱系总表（11 个档位）
> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。
| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 |
| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- |
| **T5-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | |
| **T5-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | |
| **T5-H** | 4~8 G | 6~32 TOPS (INT8) | 7~21 W | ARM A76+A55 + M0 + NPU；DC 12V 被动 | **RK3588 8GB** / Jetson Orin Nano 8GB | 现有（16G 板降配） |
| **T4-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 |
| **T4-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | |
| **T3-L** | 32~64 G / 48 G 独显 | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | |
| **T2-L** | 64~128 G | 500 TFLOPS (FP16) | 600~1.65 kW | x86 + 4×V100 SXM NVLink；双电源 + 360 液冷 | **4×V100 32GB SXM 塔式** | 现有 |
| **T2-M** | 128~256 G | 1000 TFLOPS (FP16) | 3.0~3.3 kW | x86 + 8×V100 SXM NVLink；双电源 + 液冷 | 8×V100 32GB SXM 整机 | 需扩展 |
| **T2-H** | 256~512 G | ~4000 TFLOPS (FP16) | 4.5~6.5 kW | x86 + 4×H100 SXM5 NVLink；高压供电 + 强制液冷 | 4×H100 80GB SXM5 工作站 | |
| **T1-L** | 512 G~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × x86+4×V100，100GbE RoCE/IB；机房风冷/液冷 | 4×（T2-L 节点）+ IB 交换机 | 需扩展 |
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | 20~25 kW | 4 节点 × x86+4×H100，NDR 400G IB；机房级液冷 | 4×（T2-H 节点）+ NDR 交换机 | |
### 0.4 设计原则
1. **部署形态先行、设备落地**: 先用“控制端 / 设备端 SoC / 边缘节点 / 桌面工作站 / 服务器集群”定义研究问题，再用 `T5~T1` 设备档位组织具体实验。
2. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
3. **CUDA 栈贯通高算力侧**: T1/T2/T3 的候选平台可共享 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位迁移，主要变化是规模与拓扑。
4. **非 CUDA 控制端与设备端路线**: T5 全档位与 T4-L 走 RKNN/RKLLM NPU 栈，代表最强资源约束与最接近设备本体的运行位置。
5. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T4-L 16GB / T5-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
6. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2/T3-B 路线）与 ARM64（T5/T4/T3-A 路线），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
---
## T1. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
### T1.1 定位
大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。
### T1.2 档位对比
| 维度 | T1-L 多节点-低 | T1-H 多节点-高 |
| ----------- | --------------------- | --------------------------- |
| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
| **节点数** | 4 节点 | 4 节点 |
| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 |
| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) |
| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s |
| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB |
| **整机功耗** | ~6.6 kW | 20~25 kW |
| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
| 项目 | 规格 | 数量 | 备注 |
| --------- | ------------------------------------------------ | ------------- | --------------------------- |
| **计算节点** | 同 T2-L 单机配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 |
| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 |
| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB |
| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB |
| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 |
| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 |
| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L |
| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW |
| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 |
**显存与算力**
| 指标 | 值 |
| --------------- | ---------------------------------- |
| **总显存** | **512 GB** (4 × 128GB) |
| 单卡 FP16 算力 | 125 TFLOPS |
| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) |
| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) |
**可运行模型**
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
| ------------------------ | ---------- | ------- | ----- | ------------------ |
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 |
| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray |
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI |
| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) |
| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray |
> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
| 项目 | 规格 | 数量 | 备注 |
| ------- | ----------------------------------------- | --------- | --------------------- |
| 计算节点 | 同 T2-H 单机配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s |
| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 |
| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB |
| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 |
| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 |
| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 |
| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 |
| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW |
**可运行模型**
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
| ------------------------ | ---------- | -------- | ----- | -------------------- |
| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang |
| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM |
| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI |
| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM |
### T1.3 SylixOS 要求（T1 通用）
| 要求项 | 描述 | 风险 |
| ------------------ | ------------------------------- | ------------------------------ |
| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） |
| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） |
| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） |
| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） |
| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** |
### T1.4 研究角度
- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟
- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟
- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性
- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益）
- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限）
---
## T2. 高算力单机部署形态 — 64 G ~ 512 G
### T2.1 定位
单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。
### T2.2 档位对比
| 维度 | T2-L 单机-低 | T2-M 单机-中 | T2-H 单机-高 |
| ----------- | ---------------------- | --------------------------- | --------------------------- |
| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） |
| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 |
| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) |
| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 |
| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW |
| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 |
| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 |
| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 |
| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
| # | 部件 | 型号 / 规格 | 数量 | 备注 |
| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | |
| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | |
| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 |
| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 |
| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU |
| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | |
| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 |
| 8 | 机箱 | 塔式一体定制机箱 | 1 | |
| 9 | 主电源 | 长城全模组 1650W | 1 | |
| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 |
| 11 | 散热器 | SP3 高性能散热器 | 1 | |
| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | |
| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** |
**显存与算力**
| 指标 | 值 |
| ---------- | --------------------------- |
| **总显存** | **128 GB** (4 × 32GB HBM2) |
| 单卡显存 | 32 GB HBM2 |
| 单卡 FP16 算力 | 125 TFLOPS |
| 总算力 (FP16) | ~500 TFLOPS |
| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) |
| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) |
| **整机功耗** | **~1650 W** (满载) |
**可运行模型**
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
| ------------------------ | ---------- | ------ | ----- | ------------------- |
| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM |
| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM |
| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM |
| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) |
| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM |
| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp |
| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper |
#### T2.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
| 项目 | 规格 | 变更点 |
| --------- | ----------------------------------------------- | ------------------ |
| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 |
| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 |
| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 |
| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 |
| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 |
| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory |
| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 |
| 散热 | 360 液冷 ×2 + 机箱风道强化 | — |
| **整机功耗** | **~3.0~3.3 kW** | +100% |
| **总算力** | **~1000 TFLOPS (FP16)** | +100% |
**可运行模型（新增/提升）**
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
| ------------------------ | ---------- | ------ | ----- | ------------------ |
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 |
| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 |
| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — |
| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 |
> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。
#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
| 项目 | 规格 |
| ------- | ---------------------------------------- |
| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） |
| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) |
| 单卡显存 | 80 GB HBM3 |
| NVLink | 900 GB/s (GPU↔GPU) |
| CPU | AMD EPYC 9654 (96C/192T) ×1~2 |
| 内存 | 512 GB DDR5-4800 ECC |
| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） |
| 存储 | 4 TB NVMe RAID0（模型权重加载） |
| 散热 | **强制液冷（冷板式）**，风冷不可行 |
| 电源 | 2 × 3000W 冗余 / 220V |
| **整机功耗** | **~4.5~6.5 kW** |
| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS |
**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。
**可运行模型（新增/提升）**
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
| ------------------------ | ---------- | ------- | ----- | ----------------- |
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 |
| LLaMA-3-70B | FP16 | ~140 GB | 2 | — |
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 |
| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 |
### T2.3 SylixOS 要求（T2 三档通用）
| 要求项 | 描述 | 风险 |
| ----------------- | ----------------------------- | ------------------- |
| x86 BSP | SylixOS 2.x LTS x86 | 低 |
| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） |
| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 |
| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） |
| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 |
| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） |
### T2.4 对照组 OS
- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM
- **辅助对照**: CentOS Stream 9 + RT 内核（可选）
---
## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
### T3.1 定位
边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。
它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
### T3.2 代表档位对比
| 维度 | T3-L 边缘节点代表档 |
| --------- | ---------------- |
| **容量** | 64 GB 统一内存 / 48 GB 独立显存 |
| **加速器** | Jetson AGX Orin 64GB / RTX 6000 Ada 48GB |
| **算力** | 275 TOPS (INT8) / 91 TFLOPS (FP16) |
| **功耗** | 15~60 W / ~600 W |
| **部署位置** | 设备附近机柜、边缘控制室、产线边缘节点 |
| **主要任务** | 多模态推理、近源协同、边缘缓存与调度 |
### T3.3 候选平台
- Jetson AGX Orin 64GB：统一内存、能效高，适合近设备部署；
- 边缘工控机 + RTX 6000 Ada 48GB：生态完整，适合边缘机柜和算力下沉场景。
### T3.4 研究重点
- 设备端到边缘节点的协同调度；
- 近源多任务并发下的实时隔离；
- 边缘节点与桌面/工作站单机在功耗、散热和部署约束上的边界。
---
## T4. 设备端 SoC 场景 — 8 G ~ 32 G
### T4.1 定位
设备端 SoC 直接运行在终端设备本体上。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性，即推理任务与实时控制任务共享本机资源时的隔离能力。
### T4.2 档位对比
| 维度 | T4-L SoC-低 | T4-M SoC-中 |
| --------- | ---------------------------- | -------------------------- |
| **容量** | 16 GB 统一内存 | 32 GB 统一内存 |
| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA |
| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) |
| **功耗** | 10~30 W | 15~60 W |
| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 |
| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ |
| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T5） | **高**（T234 BSP 需验证） |
| **状态** | （RK3588 16GB 工业盒） | 待验证 |
#### T4.2.1 T4-L SoC-低 — RK3588 16GB 工业盒（现有设备）
**这是现有 RK3588 设备的标准归属档位**，也是唯一可零成本立即开展研究的设备端 SoC 档位。
| 项目 | 规格 | 备注 |
| --------- | --------------------------------------- | --------------------- |
| SoC | Rockchip RK3588（同 T5-H） | SylixOS BSP 与 T5 共用 |
| 内存 | **16 GB LPDDR4X**（统一内存） | -40~60 ℃ 工业宽温 |
| NPU | 6 TOPS 原生 + **26 TOPS 算力棒扩展 = 32 TOPS** | 算力棒走 M.2 2280 |
| 功耗 | ~21~30 W（含算力棒） | 被动散热，可选小风扇 |
| 内存带宽 | ~51.2 GB/s (128-bit LPDDR4X) | 与 T5-H 同源，是带宽瓶颈点 |
| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T5-H 内存翻倍，可跑更大模型 |
**备选方案（同档位、CUDA 路线）**: NVIDIA Jetson Orin NX 16GB — 100 TOPS (INT8, sparse)，1024 CUDA + 32 Tensor Core，16 GB LPDDR5 / 102.4 GB/s，10~25 W，**CUDA 生态与 T1/T2/T3 打通**。代价是 SylixOS T234 BSP 风险高。
#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
| 项目 | 规格 |
| --------- | -------------------------------------------------- |
| **SoC** | NVIDIA T234（Grace 系列衍生） |
| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） |
| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores |
| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） |
| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) |
| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） |
| 内存带宽 | 204.8 GB/s |
| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） |
| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） |
| 存储 | 64GB eMMC + M.2 NVMe（可扩展） |
| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 |
| 视频接口 | HDMI 2.1 + DP 1.4a |
| USB | 4× USB 3.2 + 2× USB 2.0 |
| PCIe | PCIe Gen4 ×4（可扩展外设） |
| MIPI CSI | 4 通道（可接工业相机） |
| 尺寸 | 100mm × 87mm（核心模块） |
| **出厂 OS** | Ubuntu 20.04 LTS (L4T) |
| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） |
**选择 Jetson AGX Orin 的理由**
1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈
2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台
3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证
4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
#### T3 边缘节点候选平台
64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
**可运行模型（T4 两档合并）**
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 |
| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ |
| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T4-L | RKLLM |
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T4-L / T4-M | TensorRT-LLM / RKLLM |
| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T4-L / T4-M | TensorRT-LLM / llama.cpp |
| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T4-M | TensorRT-LLM |
| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T4-M | TensorRT-LLM |
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T4-L 以上 | llama.cpp |
| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T4-L 以上 | faster-whisper |
| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T4 全档 | TensorRT / RKNN |
### T4.3 SylixOS 要求（T4）
| 要求项 | 描述 | 风险 |
| -------------------- | --------------------------------------- | ---------------------------- |
| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险 | **极低** |
| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
| 独立显存管理（T3 B 路线） | x86 + 独显的显存分配与实时性 | 中 |
> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
### T4.4 对照组 OS
| 档位 | 主对照 | 辅助对照 |
| ---- | -------------------------------- | ----------------------------- |
| T4-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
| T4-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） |
### T4.5 功率采集
| 设备 | 用途 | 适用档位 |
| ----------------------------- | --------------------- | ----------- |
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T4-L / T4-M |
| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T4-M / T3-L |
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-L B 路线 |
---
## T5. 控制端场景 — 1 G ~ 8 G
### T5.1 定位
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
### T5.2 档位对比
| 维度 | T5-L 控制端-低 | T5-M 控制端-中 | T5-H 控制端-高 |
| ----------- | ---------------------- | -------------------- | ------------------------------ |
| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 |
| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano |
| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) |
| **功耗** | 3~5 W | 5~10 W | 7~21 W |
| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） |
| **供电** | DC 5V / 12V | DC 12V | DC 12V |
| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ |
| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
| 项目 | 规格 |
| --------- | -------------------------------------- |
| SoC | Rockchip RK3568 (22nm) |
| CPU | 4× Cortex-A55 @ 2.0 GHz |
| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） |
| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） |
| 内存带宽 | ~25.6 GB/s |
| GPU | Mali-G52（仅辅助显示） |
| 存储 | 8~16 GB eMMC |
| 网络 | 1× 千兆 + 可选 WiFi |
| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） |
| **功耗** | **3~5 W**（无风扇被动散热） |
| 工作温度 | -40 ~ 85 ℃ 工业级 |
| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） |
| 参考价格 | ~300~800 RMB（核心板/开发板） |
**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
| 项目 | 规格 |
| --------- | ---------------------------------------- |
| SoC | Rockchip RK3576 (8nm) |
| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） |
| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 |
| **内存** | **2~4 GB LPDDR5**（统一内存） |
| 内存带宽 | ~40 GB/s |
| **功耗** | **5~10 W**（无风扇被动） |
| 工作温度 | -40 ~ 85 ℃ 工业级 |
| 参考价格 | ~600~1,500 RMB |
**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
| 项目 | 规格 | 说明 |
| --------- | --------------------------------------------------- | ------------------------ |
| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** |
| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 |
| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 |
| GPU | Mali-G610 MC4 | 仅辅助显示 |
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T4-L 同 |
| **功耗** | **7~21 W**（无风扇被动散热） | 6 TOPS 档 ~12W / 32 TOPS 档 ~21W |
| 工作温度 | -40 ~ 60 ℃ 工业级 | 宽温优势 |
| 出厂 OS | Ubuntu 22.04 | 换 SylixOS BSP |
> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
| 项目 | 规格 |
| --------- | --------------------------------------------------- |
| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） |
| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
| 优势 | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
| 参考价格 | ~$249（开发套件） |
**可运行模型（T5-H）**
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
| ------------------------- | ---- | ------- | ----------- | ----- |
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM |
| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM |
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
**系统 (System)**
| 项目 | 规格 |
| ------- | ---------------------------------------------------- |
| SoC | Rockchip RK3588 (8nm) |
| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） |
| MCU | Cortex-M0 @200 MHz（协处理，可选） |
| GPU | Mali-G610 MC4 |
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H |
| **显存** | 统一内存（NPU 与 CPU 共享） |
**存储 / 扩展**
- EMMC 64 GB（系统盘）
- 1× TF 卡槽（存储扩展）
- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒）
**出厂软件**
- 操作系统: **Ubuntu 22.04**（出厂预装）
- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
**算力与功耗（T5-H 档）**
| 指标 | 值 |
| ------------------ | ------------------------------- |
| **可用显存** | **8 GB**（16 GB 板分区限额） |
| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) |
| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) |
| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） |
| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
| **TDP** | **7~21 W**（无风扇被动散热） |
### T5.3 SylixOS 要求（T5）
| 要求项 | 描述 | 风险 | 适用档位 |
| ---------------------- | --------------------------------------- | -------------------- | --------- |
| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T5-H |
| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T5-M |
| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T5-L |
| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T5 全档 |
| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T5-H |
| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T5-H |
| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T4-L/T5-H 切换） | 中（需 SylixOS 内存域支持） | T5-H |
| CAN ×2 驱动 | 工业现场总线 | 中 | T5 全档 |
| RS485 ×2 + RS232 ×1 | 串口 | 低 | T5 全档 |
| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T5-H |
| 看门狗 / RTC | 工业可靠性 | 低 | T5 全档 |
| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T5-H 路线B |
### T5.4 对照组 OS
- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
- T5-L / T5-M: Buildroot + PREEMPT_RT
---
## 5. 跨档位对比总表
### 5.1 全档位硬件规格对比
| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 |
| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- |
| **T5-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 |
| **T5-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 |
| **T5-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） |
| **T4-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） |
| **T4-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** |
| **T3-L** | 32~64 GB / 48 GB 独显 | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 |
| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） |
| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 |
| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 |
| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 |
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 |
### 5.2 模型规模梯度
| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
| -------- | --------------------------- | ---------- | ------- | -------------- |
| T5-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 控制端最低资源参考档，实时性基准 |
| T5-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 控制端能效拐点 |
| T5-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B |
| T4-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 设备端推理 + 工业控制 |
| T4-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 设备端多模型并发 |
| T3-L | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘节点可跑 72B |
| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 |
| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B |
| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 |
| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 |
| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 |
### 5.3 SylixOS 调度框架验证重点
| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
| ----- | ----------- | ---------------------------------- | -------------------------- |
| T5-L | 极小内存下保持关键保障负载边界 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 |
| T5-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token |
| T5-H | 极致资源约束下保持关键保障负载边界 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token |
| T4-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s |
| T4-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 |
| T3-L | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS |
| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 |
| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s |
| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 |
| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS |
| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 |
### 5.4 基线 OS 对照
| 档位 | SylixOS 实验组 | 主对照 (PREEMPT_RT Linux) | 虚拟化对照 | 容器对照 |
| ------- | ---------------------- | --------------------- | -------------- | --------- |
| T5-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker |
| T5-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker |
| T5-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
| T4-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
| T4-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker |
| T3-L | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
---
## 6. 采购与获取计划
| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
| **P0** | T4-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 |
| **P0** | T5-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T4-L 同机双档位 |
| **P1** | T5-L | RK3568 1~2GB 核心板 | ~300-800 | 控制端最低资源参考档，必做 |
| **P1** | T5-M | RK3576 4GB 核心板 | ~600-1,500 | 控制端能效拐点 |
| **P1** | T4-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP |
| **P2** | T4-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 |
| **P2** | T3-L | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘节点可跑 72B |
| **P2** | T5-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 |
| **P3** | T2-M | 4× V100 32GB SXM + 8 卡底板 + 电源 | ~70,000-100,000 | 现有平台加卡扩容 |
| **P3** | T2-H | 4× H100 80GB SXM5 工作站 | ~800,000-1,200,000 | 可租云实例替代 |
| **P3** | T1-L | 3× 计算节点 + 12× V100 + IB | ~270,000 | 可用云实例替代 |
| **P4** | T1-H | 4 节点 × 4×H100 + NDR IB | ~3,000,000+ | 强烈建议云租替代 |
| — | 仪器 | DC 功率计 ×2 (T4+T5) | ~6,000 | T5 强制 |
| — | 仪器 | INA226 采集板 ×2 | ~500 | T4+T5 |
| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3 / T2 档 |
| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） |
| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 |
| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） |
| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 |
### 降本策略
1. **P0 零成本起步**: T2-L + T4-L + T5-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T4-L（16 GB）与 T5-H（8 GB），省去一台设备与一套 BSP 验证成本。
3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T5-M 若 RK3576 BSP 不可用，用 T5-H 降配替代），谱系不断。
4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
---
## 7. SylixOS BSP 适配 Checklist（跨档位汇总）
### 7.1 x86 BSP（T2 全档 + T1 全档）
- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动
- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度
- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心）
- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M）
- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H）
- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举
- [ ] nvidia-smi / DCGM 监控
- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行
- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属）
- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属）
- [ ] NCCL / MPI 分布式通信库（T1 专属）
- [ ] IPMI / BMC 功耗采集
- [ ] tickless + CPU 隔离 + 中断亲和性
- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
### 7.2 ARM64 BSP — T234 / Ampere（T4-M / T3-L-A / T5-H 路线B）
- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
- [ ] Jetson Ampere GPU CUDA 驱动
- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属）
- [ ] 16/32/64 GB LPDDR5 统一内存管理
- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W)
- [ ] 10GbE 网络驱动
- [ ] MIPI CSI 工业相机接口
- [ ] PCIe Gen4 扩展
- [ ] 温度传感器 + 降频阈值
### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
- [ ] CPU 频率独立调节 (governor)
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
- [ ] tickless / idle hook
- [ ] 看门狗驱动
- [ ] **rknn / RKLLM NPU 驱动**（核心）
- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位）
- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0）
- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动
- [ ] CAN ×2 驱动
- [ ] RS485 ×2 + RS232 ×1 驱动
- [ ] GPIO 子系统
- [ ] HDMI 输出（调试）
- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
### 7.4 ARM64 BSP — RK3576（T5-M）
- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
- [ ] 6 TOPS NPU 驱动（RKNN 栈）
- [ ] 2~4 GB LPDDR5 内存管理
- [ ] CAN / RS485 / 千兆网络驱动
- [ ] 低功耗被动散热下的频率/温度联动
### 7.5 ARM64 BSP — RK3568（T5-L）
- [ ] SylixOS BSP for RK3568（4×A55 SMP）
- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点）
- [ ] CAN / RS485 / 千兆网络驱动
- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md
+302
View File
@@ -0,0 +1,302 @@
# SylixOS 任务关键系统中人工智能目标负载实验设计
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
## 1. 研究目标与实验范围
本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
|---|---|---|---|
| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
## 2. 设备分层与实验平台
### 2.1 T5~T1 五类部署形态、十一档实验映射
沿用设备文档的档位标签，实际容量单列。多节点架构统一记为 `T1-L`，容量边界单独记录，不据容量直接推导性能。
| 部署形态与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
|---|---|---|---|
| T5-L 控制端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
| T5-M 控制端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
| T5-H 控制端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
| T4-L 设备端 SoC 低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
| T4-M 设备端 SoC 中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
| T3-L 边缘节点代表档 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 |
| T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
| T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
| T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |
GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
### 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 测量设备
| 测量对象 | 工具与接线 | 要求 |
|---|---|---|
| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 |
| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 |
| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 |
| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 |
| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 |
传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。
## 3. 软件与模型准入
### 3.1 分阶段准入门槛
| 门槛 | 验证内容 | 通过证据 | 失败后的处理 |
|---|---|---|---|
| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 |
| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 |
| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 |
| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
### 3.2 模型梯度与用途
| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
|---|---|---|---|
| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 |
| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 |
| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 |
| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 |
| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
### 3.3 输入与正确性控制
LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。
YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。
## 4. 指标定义与采集口径
### 4.1 实时性与系统开销
对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。
| 指标 | 定义 | 汇总 |
|---|---|---|
| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 |
| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 |
| 响应时间 | f_i − r_i | 分位数、观测最大值 |
| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 |
| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 |
| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 |
| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 |
缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。
### 4.2 推理服务
在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。
- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。
- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。
- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。
- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。
- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。
### 4.3 能耗与热状态
在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。
同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。
报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。
## 5. 对照组与变量控制
### 5.1 OS 与部署组
| 编号 | 配置 | 作用 |
|---|---|---|
| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 |
| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
| O2 | SylixOS 默认配置 | 原生系统基线 |
| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
### 5.2 配置控制与消融
所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。
完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。
## 6. 负载设计
### 6.1 实时任务
主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。
任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
### 6.2 伴生竞争负载与推理到达
| 场景 | 内容 | 目的 |
|---|---|---|
| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
| L2 | 关键保障负载 + LLM | 核心双目标场景 |
| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务竞争 |
| L6 | 关键保障负载 + LLM + YOLO（可选） | 多人工智能目标负载竞争与优先级影响 |
| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
## 7. 实验矩阵与具体步骤
### 7.1 核心实验
| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 |
|---|---|---|---|
| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 |
| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 |
| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 |
| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 |
| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 |
| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 |
| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 |
| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
- `E3` 负责比较双目标并存时的达标边界；
- `E4` 负责观察内存限额与容量失败边界；
- `E6` 负责组织功耗、温度与降频证据；
- `E8` 负责验证长时间运行、恢复与热稳定性。
E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
### 7.2 条件扩展
| 扩展 | 前提 | 实验内容 | 结论边界 |
|---|---|---|---|
| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 |
| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 |
| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 |
| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 |
| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 |
T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
### 7.3 控制实验数量
不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。
## 8. 运行流程与统计方法
1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。
2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。
3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。
4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。
5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。
6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。
7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。
观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。
## 9. 验收与结果判断
验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
| 类型 | 判据 | 说明 |
|---|---|---|
| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 |
| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 |
| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 |
| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 |
| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 |
| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 |
当前候选阈值包括“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，并在正式实验前冻结；8/15/21 W 数值同样单独按配置记录，不作为跨配置统一验收值。
## 10. 数据产物与论文图表
建议按 `results/<experiment>/<platform>/<os>/<config>/<run_id>/` 保存数据，每次运行至少包含：
| 文件 | 内容 |
|---|---|
| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 |
| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 |
| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 |
| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 |
| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 |
| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 |
不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。
最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。
## 11. 实施顺序与停止条件
| 阶段 | 工作 | 完成标志 |
|---|---|---|
| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 |
| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 |
| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 |
| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 |
| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 |
| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 |
设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/04-论文写作规划.md
+453
View File
@@ -0,0 +1,453 @@
# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
> **版本**: v0.1 (研究启动版)
> **日期**: 2026-09-20
> **整合来源**: 01-研究逻辑说明.md + 02-基础设备与算力基础.md + 03-实验设计.md + 10-研究框架/00~07 系列文档 + 第三方基准复现思路
> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章规划稿 (后续随实验推进持续迭代)
---
## 0. 文章定位与核心贡献
### 0.1 一句话定位
> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**
### 0.2 三大核心贡献
| 编号 | 贡献 | 来源整合 | 对标空白 |
|------|------|----------|----------|
| C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
| C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
### 0.3 目标读者与发表场景
| 维度 | 选择 |
|------|------|
| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
| 备选 | EMSOFT / DAC / MLSys (系统方向) |
| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
---
## 1. 文章整体结构 (十章)
```
第1章 引言 — 问题、动机、贡献概述
第2章 背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
第3章 T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
第4章 SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
第5章 实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
第6章 大模型负载选型与配置 — 跨档位模型矩阵
第7章 实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
第8章 深入分析 — 档位间性能曲线 + RTOS vs 普通 Linux / PREEMPT_RT 差异化
第9章 讨论与威胁有效性 — 适用场景边界 + 局限性
第10章 结论与展望
```
---
## 2. 逐章详细规划
### 第1章 引言
**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 1.1 问题矛盾 | 人工智能目标负载要求结果及时且有效，关键保障负载要求严格截止期；两者进入同一任务关键系统后，会在 CPU、内存、总线、加速器和中断路径上发生竞争 | |
| 1.2 研究空白 | 公开基准大多基于 Linux/Ubuntu，重点放在吞吐或单任务性能，缺少 RTOS 对人工智能目标负载与关键保障负载双目标实时保障的系统评测 | 01-研究逻辑说明.md §2、§8 |
| 1.3 本文贡献 | C1 (双目标实时保障优势)、C2 (五类部署形态统一验证矩阵)、C3 (业界基准对齐)，一句话概述每个贡献 | |
| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
---
### 第2章 背景与相关工作
**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 2.1 人工智能目标负载特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 I/O 抖动；输出质量与时效双重约束 | 03-实验设计.md §3、10-研究框架/01~04 |
| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 10-研究框架/00.md §3、05-中断与实时性保障.md |
| 2.3 PREEMPT_RT 相对短板 | 内核态长路径、系统后台线程、内存回收与共享资源竞争仍可能拉长 `P99.9`；其可预测性增强但不等同于专用 RTOS | 00-整体研究框架.md §5、07-方法论与评估工具链.md §2、§4 |
| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | 00-整体研究框架.md §6 |
| 2.5 第三方基准方法学 | 第三方文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 避坑清单 | 03-实验设计.md §4、07-方法论与评估工具链.md §8~§10 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
| Tab.1 | SylixOS vs 普通 Linux / PREEMPT_RT 对比 | 关键 RTOS 特性对应的双目标实时保障优势与对照平台短板 |
---
### 第3章 T5~T1 五类部署形态验证矩阵
**目标**: 800~1000 词，用连续验证矩阵承载主问题，保持硬件作为验证矩阵的角色。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 3.1 分级维度与分档规则 | 以「部署形态」为第一分类维度，以「统一内存/显存容量」为分档参考；T5~T1 五类部署形态下连续展开 | 02-基础设备与算力基础.md §0.1 |
| 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Fig.2 | T5~T1 五类部署形态验证矩阵全景图 | 横轴=容量 (1 GB→2 TB, log 刻度), 纵轴=功耗 (3 W→25 kW, log 刻度), 11 个档位点标注, 散热形态用颜色分区 (被动/风冷/液冷/机房液冷) |
| Tab.2 | 11 档位全规格对比表 | 容量、算力、功耗、加速器架构、散热、互联、SylixOS BSP 风险、状态 (现有/需扩展) |
| Tab.3 | 模型规模梯度表 | 11 档位 × 代表模型 × 量化 × 显存占用 × 角色 (控制端最低资源参考档→超大模型分布式) |
| Tab.4 | 采购计划表 | P0~P4 优先级 + 估算费用 + 降本策略 |
---
### 第4章 SylixOS 调度框架技术架构
**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
| Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
| Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
| Tab.6 | 六大优化方向与低功耗专题线概览 | 方向/专题 × (核心问题/关键手段/目标指标/对应章节) |
---
### 第5章 实验方法学
**目标**: 800~1000 词，这是 C2 和 C3 的方法论基础，也是本文"可复现"承诺的核心。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
| 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
| 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
| 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
| 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Fig.5 | 实验方法论流程图 | `G0~G4` 准入 + `O0~O4` 对照 + 第三方基准对齐校验门 |
| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
本章设置下面两张“索引表”：
| 索引表 | 作用 |
|------|------|
| RQ → 实验 → 章节映射表 | 把 `RQ1~RQ4` 对应到 `E0~E8`、`L0~L7` 与第7/8章，保证每个研究问题都有直接证据链 |
| 场景编号 → 结果章节映射表 | 把 `L0~L7` 对应到第7章的小节与图表，保持实验编号与结果章节的直接锚点 |
---
### 第6章 大模型负载选型与配置
**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 03-实验设计.md §3.2 |
| 6.2 跨档位模型矩阵 | T5-L: Qwen2.5-0.5B INT4；T5-M: 1.5B INT4；T5-H: 3B/7B INT4；T4-L: 3B/7B INT4 (RKLLM)；T4-M: 14B/32B INT4 (TensorRT-LLM)；T3-L: 72B INT4；T2-L: 72B INT4/14B FP16；T2-M: 72B FP16；T2-H: DeepSeek-V2 FP16；T1-L: 72B FP16 分布式；T1-H: 671B INT4 | 02-基础设备与算力基础.md §5.2、03-实验设计.md §3.2 |
| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T4-M/T3-L)、llama.cpp (T2-L/T4-L 退路)、RKLLM (T5/T4-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 03-实验设计.md §3.1~§3.3 |
| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 03-实验设计.md §3、§6 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
---
### 第7章 实验结果
**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
| 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
| 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
| 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
| 7.6 温度-功耗-性能耦合 | 对应 `RQ3`；可与 `L1/L2/L7` 组合，报告 25%→100% CPU 逐步加压的三维耦合曲线，以及 SylixOS vs 普通 Linux / PREEMPT_RT Linux 的降频触发温度与性能下降斜率 | 03-实验设计.md §4、06-能耗与热管理.md |
| 7.7 异构核分配 | 对应 `RQ2/RQ3`；主要落在 RK3588 路线与 `L2/L3`，体现 A76 (LLM) + A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 03-实验设计.md §6、03-加速器协同调度.md |
| 7.8 跨档位性能曲线 | 对应 `RQ4`；汇总 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线；第7.8节按“已实测结果”与“后续扩展计划”两类展示 | 02-基础设备与算力基础.md §5.3、03-实验设计.md §2 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 `W(t)` 曲线，SylixOS vs 普通 Linux / PREEMPT_RT Linux 叠加 |
| Fig.7 | 双目标实时保障延迟分布 (★ 核心证据) | 人工智能目标负载与关键保障负载的 P50~Max 直方图 + 时间序列，4 变体叠加 |
| Fig.8 | 人工智能目标负载输出时延直方图 | Qwen2.5-7B 单流 1 h 采集，SylixOS vs 普通 Linux / PREEMPT_RT Linux |
| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间关键保障负载延迟 spike 与人工智能目标负载队列变化的联合时间序列 |
| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T5-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
建议在第7章开头直接放入下面两张索引表：
| 研究问题 | 主要实验单元 | 主要场景编号 | 主要结果章节 | 核心图表 |
|------|------|------|------|------|
| `RQ1` 双目标约束下的实时保障 | `E1` 微基准、`E3` 混合负载、`E8` 长稳与恢复 | `L0`、`L2`、`L3`、`L4`、`L5`、`L7` | `7.3`、`7.4` | `Fig.7`、`Tab.13` |
| `RQ2` 隔离机制的代价与收益 | `E3` 混合负载、`E4` 内存限额、`E7` 消融、`E8` 长稳与恢复 | `L2`、`L3`、`L4`、`L5`、`L6`、`L7` | `7.3`、`7.5`、`7.7` | `Fig.7`、`Fig.9`、`Tab.13` |
| `RQ3` 功耗预算下的系统协同能力 | `E2` 推理基线、`E3` 混合负载、`E6` 能耗与热、`E8` 长稳与恢复 | `L1`、`L2`、`L7` | `7.2`、`7.6` | `Fig.6`、`Fig.10`、`Tab.13` |
| `RQ4` 规模扩展后的边界与瓶颈 | `E5` 多卡竞争、`X3`/`X4`/`X5` 条件扩展 | `L3`、`L5`、`L6`、`L7` | `7.5`、`7.8` | `Fig.11`、`Tab.14` |
| 场景编号 | 场景定义 | 论文归属章节 | 主要回答的问题 | 核心图表 |
|------|------|------|------|------|
| `L0` | 仅关键保障负载 | `7.3` 低延迟结果 | 关键保障负载下界、测量链路开销 | 延迟 CDF、基线表 |
| `L1` | 仅人工智能目标负载 | `7.2` 低功耗结果、`7.3` 低延迟结果 | 人工智能目标负载基线时效、能耗与服务能力 | `Fig.6`、`Fig.8` |
| `L2` | 关键保障负载 + LLM | `7.4` 双目标实时保障结果 | 双目标是否同时达标，是全文核心主场景 | `Fig.7`、`Tab.13` |
| `L3` | `L2` + CPU 竞争负载 | `7.4`、`7.5` | CPU 竞争下的隔离能力与调度边界 | `Fig.7`、竞争负载对照表 |
| `L4` | `L2` + 内存流式读写 | `7.4` | 内存带宽与容量压力下的边界变化 | 内存压力时间序列、违约率表 |
| `L5` | `L2` + 网络/存储 I/O | `7.4`、`7.5` | IRQ、DMA 与系统服务竞争影响 | `Fig.9`、I/O 干扰对照表 |
| `L6` | 关键保障负载 + LLM + YOLO（可选） | `7.5` | 多人工智能目标负载共存时的优先级与公平性 | 多模型公平性图、Jain 指数表 |
| `L7` | `L2` + 突发/过载 | `7.4`、`7.5`、`7.6` | 过载、拒绝、恢复与热耦合下的系统稳定性 | `Fig.9`、`Fig.10`、恢复时间表 |
---
### 第8章 深入分析
**目标**: 800~1000 词，从数据中提炼规律性结论。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 8.1 档位间性能曲线规律 | 容量、功耗和拓扑变化下 RTOS 优势的变化趋势；分析哪些档位更容易体现差异、哪些档位优势可能收窄 | 02-基础设备与算力基础.md §5.3 |
| 8.2 SylixOS vs 普通 Linux / PREEMPT_RT 差异化量化 | 分别评价关键保障负载边界、人工智能目标负载时效和系统协同收益；按档位和场景分别判定 | 03-实验设计.md §9、§10 |
| 8.3 双目标场景下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 关键保障负载不被长路径抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 模型加载不引入额外抖动；中断线程化 + 亲和性 → NPU/GPU 中断不污染实时核 | 05-中断与实时性保障.md、02-KV-Cache与内存管理.md |
| 8.4 能效分析 | 每 token 能耗 vs 档位；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 `J/token` 对比 | 02-基础设备与算力基础.md §0.3、06-能耗与热管理.md |
| 8.5 BSP 风险与可行性 | x86 BSP、ARM64 RK3588 BSP、T234 Jetson BSP、RKLLM 移植等路径的风险等级与降本策略 | 02-基础设备与算力基础.md §7、03-实验设计.md §3 |
**关键图表**:
| 编号 | 图表 | 描述 |
|------|------|------|
| Fig.12 | RTOS 优势 vs 部署档位趋势图 | 横轴=11 档位，纵轴=SylixOS 相对普通 Linux / PREEMPT_RT Linux 的 `P99.9` 与有效吞吐改善百分比，标注"显著优势/可比偏优/未体现"区间 |
| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
---
### 第9章 讨论与威胁有效性
**目标**: 400~600 词，诚实地界定适用边界和局限性。
| 小节 | 内容要点 | 来源映射 |
|------|----------|----------|
| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
| 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
| 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
---
### 第10章 结论与展望
**目标**: 300~400 词，总结贡献并指出未来方向。
| 小节 | 内容要点 |
|------|----------|
| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果（基准对齐 ±X%、双目标场景下相对 PREEMPT_RT Linux 的边界改善 X%、能效改善 X%） |
| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-推理图任务调度.md §8 |
---
## 3. 来源文档到章节的映射矩阵
| 来源文档 | 主要贡献章节 | 次要贡献章节 |
|----------|------------|------------|
| **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
| **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
| **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
| **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
| **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
| **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
| **04-量化精度感知调度.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
| **05-中断与实时性保障.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
| **06-能耗与热管理.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
| **07-方法论与评估工具链.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
---
## 4. 关键数据产物清单
| 编号 | 产物 | 类型 | 优先级 | 依赖 |
|------|------|------|--------|------|
| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 02-基础设备与算力基础.md 已就绪 |
| D2 | 跨档位模型矩阵 | 数据表 | P0 | 02-基础设备与算力基础.md + 03-实验设计.md 已就绪 |
| D3 | RK3588 上 sysbench/stress-ng 基准复现数据 | 实测数据 | P0 | 需 SylixOS BSP + sysbench 移植 |
| D4 | 业界基准对比表 (SylixOS vs 文章基线) | 对比表 | P0 | D3 |
| D5 | 混合负载 30 min 全周期延迟时间序列 | 实测数据 | P0 | 需混合负载驱动脚本 + 4 变体 |
| D6 | 混合负载延迟分布直方图 (4 变体叠加) | 图表 | P0 | D5 |
| D7 | 功耗分阶段曲线 (prefill/decode/idle) | 图表 | P0 | 功率计采集 + LLM 推理 |
| D8 | LLM token 延迟直方图 (1 h 采集) | 图表 | P1 | vLLM/RKLLM benchmark |
| D9 | 突发加载瞬间实时任务时间序列 | 图表 | P1 | 混合负载脚本 + 模型切换 |
| D10 | 温度-功耗-性能三维耦合曲线 | 图表 | P1 | stress-ng 逐步加压 + 温度日志 |
| D11 | 跨档位性能连续曲线 | 图表 | P1 | 已完成档位实测 + 后续档位条件补充；未完成档位不写成正式结果 |
| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 03-实验设计.md §11 模板 |
---
## 5. 写作优先级与依赖关系
```
Phase 0: BSP 适配 + 工具移植 (3 周)
├─ SylixOS RK3588 BSP 部署
├─ sysbench / stress-ng / RKLLM 移植验证
└─ vLLM / llama.cpp 在 SylixOS 编译运行
Phase 1: 基准复现 + 文章骨架 (1.5 周)
├─ D3: RK3588 基准复现 → D4: 业界对比表
├─ 撰写: §1 引言 + §2 背景 + §3 验证矩阵 + §4 技术架构 + §5 方法学 + §6 模型选型
└─ 依赖: D3 通过 ±15% 对齐门 → 准入 Phase 2
Phase 2: 低功耗测试 + 温度耦合 (2 周)
├─ D7: 功耗曲线 + D10: 温度耦合曲线
└─ 撰写: §7.2 + §7.6
Phase 3: 低延迟 + 混合负载测试 (3 周)
├─ D5+D6: 混合负载核心证据 + D8: token 延迟直方图 + D9: 突发场景
└─ 撰写: §7.3 + §7.4 + §7.5
Phase 4: 异构调度测试 (1 周)
├─ 场景6: A76+A55+M0 异构分配
└─ 撰写: §7.7
Phase 5: 数据汇总 + 深入分析 + 全文定稿 (2.5 周)
├─ D11: 跨档位曲线 + D12: 优越性矩阵
├─ 撰写: §7.8 + §8 深入分析 + §9 讨论 + §10 结论
└─ 全文校对 + 图表终版
```
**总周期: ~13 周** (Phase 0~5 累计)
---
## 6. 章节字数预算
| 章节 | 预算字数 | 占比 |
|------|---------|------|
| §1 引言 | 400 | 4% |
| §2 背景与相关工作 | 700 | 7% |
| §3 T5~T1 五类部署形态验证矩阵 | 900 | 9% |
| §4 技术架构 | 700 | 7% |
| §5 实验方法学 | 900 | 9% |
| §6 模型选型 | 600 | 6% |
| §7 实验结果 | 1800 | 18% |
| §8 深入分析 | 900 | 9% |
| §9 讨论 | 500 | 5% |
| §10 结论 | 350 | 3% |
| 参考文献 + 附录 | ~2000 | 23% |
| **总计** | **~9750** | 100% |
> 注: 按 RTSS/RTAS 会议论文 10~12 页双栏计算, 正文约 8000~10000 词, 参考文献+附录另计。
---
## 7. 核心叙事线 (Storyline)
```
问题矛盾 (§1)
→ 人工智能目标负载时效/有效性 vs 关键保障负载严格截止期, 在任务关键系统中必须共存
→ 空白: 国产 RTOS 在任务关键系统中承载人工智能目标负载的系统化数据仍然稀缺
背景铺垫 (§2)
→ 人工智能目标负载的 CPU/内存/长尾特征
→ RTOS 的 6 项调度优势 + 普通 Linux / PREEMPT_RT 的边界
→ 第三方方法学引入 (5 维度 + 5 避坑)
验证矩阵 (§3) ← C2 验证框架
→ 11 档位连续展开: 1 GB/3 W → 2 TB/25 kW
→ 现有 P0 零成本起步 (V100 + RK3588)
→ 一机两档降本
技术架构 (§4)
→ 五层技术栈 + 六大优化方向
→ LLM 推理 DAG → RTOS 任务映射
→ BSP 适配要点与风险
方法学 (§5) ← C1/C3 基础
→ 第三方基准复现 (先对齐 ±15% 才准入)
→ 双目标负载四原则 (核心设计)
→ 功耗真测 + 温度监控 + 元数据强制
模型选型 (§6)
→ 跨 11 档位的 Qwen/LLaMA/MiniCPM/Whisper 矩阵
→ INT4/INT8/FP16 量化梯度
实验结果 (§7) ← 本文核心
→ 7.1 基准对齐 (第一层门)
→ 7.2~7.3 功耗/延迟 (基础指标)
→ 7.4 双目标实时保障 (★ 核心证据)
→ 7.5~7.7 并发/突发/异构
→ 7.8 跨档位连续曲线
深入分析 (§8)
→ 档位间趋势: 哪些资源条件与拓扑更容易体现 RTOS 优势
→ 优越性量化: 关键保障负载边界、人工智能目标负载时效与有效吞吐的联合改进
→ 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
→ 能效: V100 基线 vs H100 上限, INT4 拐点
讨论 (§9)
→ 适用边界: T5/T4 更容易体现优势, T1-H 可能收窄
→ 威胁有效性: RKLLM 移植/V100 驱动/sysbench 移植
→ 与已有工作: vs vLLM/NPU SDK/CUDA Stream/第三方文章
结论 (§10)
→ 三大贡献量化回顾
→ 跨平台/功能安全/分布式/自适应展望
```
---
## 8. 待确认事项
| 编号 | 待确认项 | 影响章节 | 当前假设 |
|------|---------|---------|---------|
| Q1 | SylixOS 在 x86+4×V100 NVLink 的 CUDA 驱动支持度 | §4.5, §7.3, §8.5 | 需翼辉确认; 单卡先行, 4 卡作 stretch |
| Q2 | RK3588 BSP 是否集成 rknn/RKLLM | §5.2, §7.1, §9.2 | 需翼辉确认; 退路 llama.cpp CPU |
| Q3 | sysbench/stress-ng 在 SylixOS 可移植性 | §5.2, §7.1 | POSIX 兼容, 假设可行 |
| Q4 | T234 (Jetson Orin) BSP 是否支持 | §3.2 (T4-M / T3-L) | 风险高; T4-L 用 RK3588 起步 |
| Q5 | RK3588 板卡是否引出 M0 调试接口 | §7.7 (场景6) | 若未引出, 场景6 需调整 |
| Q6 | 是否纳入功能安全 SIL2/IEC 61508 章节 | §10.2 展望 | 暂列为展望, 不入正文 |
| Q7 | 是否纳入昇腾 Qwen-7B 作为第二业界参照 | §7.1, §9.4 | 暂列为后续, 非本方案硬件 |
| Q8 | 主对照组确认: Ubuntu 22.04+PREEMPT_RT | §5.7 | 与第三方文章配置一致, 可比性最高 |
---
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/README.md
+27
View File
@@ -0,0 +1,27 @@
# 实验与规划索引
本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
## 阅读建议
1. `01-研究逻辑说明.md`
2. `02-基础设备与算力基础.md`
3. `03-实验设计.md`
4. `metric.md`
5. `04-论文写作规划.md`
6. `05-论文结构总览.png`
## 文件说明
- `01-研究逻辑说明.md`
- 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
- `02-基础设备与算力基础.md`
- T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
- `03-实验设计.md`
- 准入条件、对照原则、混合负载场景、指标与验收方法
- `metric.md`
- 三层核心证据指标的统一定义、计算公式、采集要求与报告口径
- `04-论文写作规划.md`
- 论文结构、章节分工、图表规划和证据映射
- `05-论文结构总览.png`
- 文章结构与逻辑关系示意图
02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md
+397
View File
@@ -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 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。