reorganize project documents into structured research directories
Consolidate the research materials into numbered overview, framework, planning, partner, deliverable, and archive sections so the repository reflects the current RTOS-focused narrative and reading order.
This commit is contained in:
@@ -0,0 +1,75 @@
|
||||
# 01-当前研究问题：背景、问题与挑战
|
||||
|
||||
## 1. 背景
|
||||
|
||||
当前智能系统正在持续进入控制、装备、交通、工业现场与边缘决策等任务关键场景。随着人工智能推理能力从离线分析走向在线决策，系统对人工智能运行的要求已经扩展为功能有效性、时间约束、运行稳定性与可验证性的统一达标。
|
||||
|
||||
外部研究与产业表达已经形成较清晰的共识：
|
||||
|
||||
- AI 用于 safety-critical systems 的安全保障仍在持续推进，系统层面的可控、可验证与可接受性仍是核心议题；
|
||||
- QNX、Wind River 等平台方已将 deterministic、predictable、secure 的软件基础与 AI 能力并列讨论；
|
||||
- Linux Foundation 对 PREEMPT_RT 的持续推进，表明低延时、低抖动和可预测执行已经成为重要基础能力。
|
||||
|
||||
在这样的背景下，操作系统已经成为决定 AI 推理能否进入任务关键系统的重要基础平台。尤其当 AI 推理与周期控制、执行闭环、联锁逻辑、通信管理等负载共同运行时，系统时序边界、资源争抢边界与恢复边界都会被重新放大。
|
||||
|
||||
## 2. 问题
|
||||
|
||||
本项目聚焦的当前研究问题可以表述为：
|
||||
|
||||
> **在五类部署形态下，当人工智能目标负载进入任务关键系统后，以大型跨平台实时操作系统为基础平台的系统，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性？**
|
||||
|
||||
这个问题包含四个明确支点：
|
||||
|
||||
1. 研究对象是**大型跨平台实时操作系统**这一类平台；
|
||||
2. `SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等构成外部参照样本；
|
||||
3. AI 推理在任务关键系统中被界定为**人工智能目标负载**，与关键保障负载、伴生竞争负载共同构成系统运行面；
|
||||
4. 对照对象明确拆分为**普通 Linux** 与 **PREEMPT_RT Linux**，用来建立不同系统基础能力之间的可比关系。
|
||||
|
||||
项目围绕以下三个判断维度展开：
|
||||
|
||||
- AI 目标负载与关键保障负载能否在统一系统中稳定共存；
|
||||
- 操作系统能否通过调度、隔离、内存管理、中断管理与恢复机制维持系统边界；
|
||||
- 系统是否能够同时实现 AI 功能有效性与实时性达标。
|
||||
|
||||
因此，这个研究问题本质上是一个面向任务关键系统的系统研究问题，也是一个具有产业验证价值的平台比较问题。
|
||||
|
||||
## 3. 挑战
|
||||
|
||||
围绕上述问题，当前研究至少面临以下几类核心挑战。
|
||||
|
||||
### 3.1 五类部署形态下的统一验证挑战
|
||||
|
||||
`T5~T1` 五类部署形态与 `11` 个代表档位共同构成验证矩阵、证据组织框架与跨场景比较环境。这里的核心挑战，是在不同资源约束、拓扑结构和负载强度下，用统一方法解释 RTOS 的优势边界与失效边界。
|
||||
|
||||
### 3.2 对照体系的精细化挑战
|
||||
|
||||
本项目采用三级对照体系：
|
||||
|
||||
- `O0` 普通 Linux；
|
||||
- `O1` PREEMPT_RT Linux；
|
||||
- 大型跨平台 RTOS。
|
||||
|
||||
这一对照设计将普通 Linux 与 PREEMPT_RT Linux 分别建模，用于区分一般低延时收益与 RTOS 在确定性、隔离性和可分析性上的收益来源。
|
||||
|
||||
### 3.3 双目标同时达标的评价挑战
|
||||
|
||||
当 AI 被界定为目标负载后，评价体系同时覆盖关键保障负载保护效果，以及 AI 目标负载的有效性、时效性和长期稳定性。因此，评价指标需要同时覆盖：
|
||||
|
||||
- 关键保障负载：`deadline miss ratio`、`P99/P99.9 jitter`、响应时间边界；
|
||||
- AI 目标负载：`TTFT`、`TPOT`、端到端响应时间、成功率、功能质量；
|
||||
- 系统协同层：有效吞吐、`E/token`、热漂移、资源争抢边界、恢复能力。
|
||||
|
||||
### 3.4 多目标负载协调的机制挑战
|
||||
|
||||
在任务关键系统中，AI 目标负载、关键保障负载与伴生竞争负载共同构成统一运行面。它们在 CPU、内存、总线、中断、DMA、缓存与加速器访问上会形成持续竞争。研究的关键难点在于，RTOS 是否能够把这种竞争收敛为可分析、可控制、可恢复的系统行为边界。
|
||||
|
||||
## 外部参考
|
||||
|
||||
1. Linux Foundation, Real-Time Linux Project
|
||||
<https://realtime-linux.dev-lfprojects5.linuxfoundation.org/>
|
||||
2. QNX, Software Foundation for Physical AI
|
||||
<https://qnx.software/en/software/technologies/physical-ai>
|
||||
3. Wind River 官网与 Edge AI / mission-critical 相关公开表述
|
||||
<https://www.windriver.com/>
|
||||
4. Ullrich et al., *AI Safety Assurance for Automated Vehicles: A Survey on Research, Standardization, Regulation*
|
||||
<https://arxiv.org/abs/2504.18328v1>
|
||||
@@ -0,0 +1,143 @@
|
||||
# 02-研究定位与项目边界
|
||||
|
||||
## 一句话定义
|
||||
|
||||
本项目的正式题目是：
|
||||
|
||||
> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**
|
||||
|
||||
本项目围绕下面这个核心问题展开：
|
||||
|
||||
> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性。SylixOS 是本项目的主实验样例，QNX、VxWorks、INTEGRITY、LynxOS-178 等可作为外部参照样本。**
|
||||
|
||||
## 这个项目在做什么
|
||||
|
||||
### 1. 研究对象与平台角色
|
||||
|
||||
本项目的研究对象是**大型跨平台实时操作系统这一类平台**，重点关注它们在任务关键系统中的：
|
||||
|
||||
- 其实时调度、资源隔离、内存管理、中断管理与恢复机制；
|
||||
- 这些机制在不同部署形态下承载人工智能目标负载时，是否仍能维持系统边界。
|
||||
|
||||
在这组平台中：
|
||||
|
||||
- `SylixOS` 是本项目的主实验样例；
|
||||
- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等用于建立外部参照坐标；
|
||||
- `Linux` 与 `PREEMPT_RT Linux` 是核心对照对象。
|
||||
|
||||
硬件平台在本项目中承担的是**验证载体**角色，用来暴露不同资源约束、拓扑结构和调度边界。
|
||||
|
||||
### 2. 系统场景与负载结构
|
||||
|
||||
本项目面向的是**任务关键系统**。在这个系统语境里，人工智能推理属于系统功能的一部分，因此被定义为：
|
||||
|
||||
- **人工智能目标负载**
|
||||
|
||||
与之共同构成系统运行面的还有两类负载：
|
||||
|
||||
- **关键保障负载**：周期控制、执行闭环、联锁、状态采集等；
|
||||
- **伴生竞争负载**：日志、更新、后台通信、模型加载、存储和网络 I/O 等。
|
||||
|
||||
> **RTOS 如何协调人工智能目标负载与关键保障负载，使系统同时满足功能有效性与实时性边界。**
|
||||
|
||||
### 3. 在五类部署形态下建立统一验证矩阵
|
||||
|
||||
`T5~T1` 五类部署形态和 `11` 个代表档位在本项目中构成验证矩阵与证据组织框架：
|
||||
|
||||
- 验证矩阵；
|
||||
- 证据组织框架；
|
||||
- 不同资源条件下的边界测试环境。
|
||||
|
||||
这套验证矩阵覆盖：
|
||||
|
||||
- `T5` 控制端
|
||||
- `T4` 设备端 SoC
|
||||
- `T3` 边缘节点
|
||||
- `T2` 桌面 / 工作站单机
|
||||
- `T1` 服务器 / 集群
|
||||
|
||||
这套验证矩阵支撑以下四类判断：
|
||||
|
||||
- RTOS 优势在哪些部署形态下最明显；
|
||||
- 这些优势来自哪些系统机制；
|
||||
- 为维持实时保障需要付出多少吞吐和能耗代价；
|
||||
- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
|
||||
|
||||
### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
|
||||
|
||||
项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
|
||||
|
||||
证据至少包括三层：
|
||||
|
||||
- **人工智能目标负载层**：
|
||||
`TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
|
||||
- **关键保障负载层**：
|
||||
`deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
|
||||
- **系统协同层**：
|
||||
有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
|
||||
|
||||
## 项目边界
|
||||
|
||||
### 1. 应用背景与研究对象
|
||||
|
||||
项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
|
||||
|
||||
- 大型跨平台实时操作系统；
|
||||
- 任务关键系统；
|
||||
- 人工智能目标负载。
|
||||
|
||||
### 2. 评价重点
|
||||
|
||||
项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
|
||||
|
||||
- AI 目标负载是否按时完成；
|
||||
- 关键保障负载是否满足截止期；
|
||||
- 系统是否在长时间运行中保持稳定；
|
||||
- 满足这些约束后，吞吐与能耗代价是否可接受。
|
||||
|
||||
### 3. 算法与系统的关系
|
||||
|
||||
量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
|
||||
|
||||
- 它们如何改变时延分布；
|
||||
- 如何影响内存占用和带宽争抢；
|
||||
- 如何改变调度器和资源管理策略。
|
||||
|
||||
因此，项目重点落在系统机制、调度策略和资源治理能力上。
|
||||
|
||||
### 4. 成果形态
|
||||
|
||||
项目成果需要形成完整的方法与证据体系，包括：
|
||||
|
||||
- 可解释的方法；
|
||||
- 可复现的证据；
|
||||
- 明确的适用边界；
|
||||
- 跨部署形态可比较的规律；
|
||||
- 能被学术界和产业界共同理解的结论。
|
||||
|
||||
## 这个项目最后要交付什么
|
||||
|
||||
项目最终交付物至少应包括：
|
||||
|
||||
1. 一套面向任务关键系统的 SylixOS 实时保障机制；
|
||||
2. 一组覆盖 `T5~T1` 五类部署形态的实测数据和对照结果；
|
||||
3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
|
||||
4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
|
||||
5. 一套可用于产业沟通和产品表达的技术叙事。
|
||||
|
||||
## 判断项目是否成功，要看什么
|
||||
|
||||
要看：
|
||||
|
||||
- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
|
||||
- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
|
||||
- 吞吐损失是否在可接受范围；
|
||||
- 能耗和热稳定性是否同步改善或至少可解释；
|
||||
- 结论是否能跨部署形态成立；
|
||||
- 优势边界和失败边界是否都被讲清楚。
|
||||
|
||||
## 最后一句话
|
||||
|
||||
这个项目的本质是：
|
||||
|
||||
> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**
|
||||
@@ -1,536 +0,0 @@
|
||||
# 方向7: 分析方法与评估工具链
|
||||
|
||||
## 1. 方法论框架
|
||||
|
||||
本研究的方法论遵循 **"建模 → 分析 → 实现 → 验证"** 的四步循环:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Step 1: 基准测量 (Profiling) │
|
||||
│ - 不同平台上的LLM推理profile │
|
||||
│ - 延迟、带宽、能耗、中断频率 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 2: 建模 (Modeling) │
|
||||
│ - 推理图建模 (DAG) │
|
||||
│ - 调度模型 (Fixed Priority / EDF) │
|
||||
│ - 内存模型 (KV Cache pool) │
|
||||
│ - 能耗模型 (DVFS) │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 3: 算法设计 (Algorithm Design) │
|
||||
│ - 基于模型分析设计调度/内存/协同策略 │
|
||||
│ - 理论分析 (WCET, WCL, Schedulability) │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 4: 仿真验证 (Simulation) │
|
||||
│ - 在模拟环境中验证理论分析 │
|
||||
│ - 参数扫描 (不同模型/平台/负载) │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 5: 原型实现 (Prototype) │
|
||||
│ - 在真实RTOS上实现关键模块 │
|
||||
│ - FreeRTOS / Zephyr + custom patches │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 6: 实测对比 (Evaluation) │
|
||||
│ - 优化前后指标对比 │
|
||||
│ - 消融实验 (每个方向的独立贡献) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 2. 性能基准测量
|
||||
|
||||
### 2.1 测量指标
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────┐
|
||||
│ Category | Metric | Tool │
|
||||
├─────────────────┼───────────────────────────┼────────────────┤
|
||||
│ Latency | TTFT, TPOT, WCL | RTOS Trace │
|
||||
│ Latency | Jitter (P50/P90/P99) | ftrace │
|
||||
│ Latency | Preemption overhead | perf │
|
||||
├─────────────────┼───────────────────────────┼────────────────┤
|
||||
│ Computation | FLOPs, MACs, Utilization | NPU/GPU Profiler│
|
||||
│ Computation | WCET per layer | RTOS Trace │
|
||||
│ Computation | Cache miss rate | ARM CCM/Perf │
|
||||
├─────────────────┼───────────────────────────┼────────────────┤
|
||||
│ Memory | Bandwidth utilization | DDR Profiler │
|
||||
│ Memory | KV Cache size/fragmentation| Custom tool │
|
||||
│ Memory | DMA throughput | DMA Profiler │
|
||||
├─────────────────┼───────────────────────────┼────────────────┤
|
||||
│ Power | Dynamic power per stage | Power Monitor │
|
||||
│ Power | Thermal profile | Thermal Sensor │
|
||||
│ Power | Energy per inference | Power Monitor │
|
||||
├─────────────────┼───────────────────────────┼────────────────┤
|
||||
│ Interrupt | IRQ rate per stage | GIC Profiler │
|
||||
│ Interrupt | ISR latency | RTOS Trace │
|
||||
│ Interrupt | Priority inversion count | Custom tool │
|
||||
└───────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 Profile数据流
|
||||
|
||||
```
|
||||
LLM Inference (Qwen2.5-1.5B on RK3588)
|
||||
│
|
||||
├── Layer Profile (per-layer computation time)
|
||||
│ Layer 1 Attn: 1.2ms, Layer 1 FFN: 0.8ms, ...
|
||||
│
|
||||
├── Memory Profile (bandwidth, cache, KV Cache)
|
||||
│ Read: 4.2GB/s, Write: 2.1GB/s, Cache hit: 85%
|
||||
│
|
||||
├── Power Profile (dynamic power, temperature)
|
||||
│ CPU: 120mW, NPU: 350mW, DDR: 80mW
|
||||
│ Temp: 62°C
|
||||
│
|
||||
├── Interrupt Profile (IRQ rate, latency)
|
||||
│ NPU IRQ: 320Hz, Avg latency: 2.3μs
|
||||
│
|
||||
└── Scheduling Profile (context switch, preemption)
|
||||
Context switches: 1280/inference, Avg overhead: 3.5μs
|
||||
```
|
||||
|
||||
## 3. 调度可调度性分析
|
||||
|
||||
### 3.1 Fixed Priority Scheduling (FPS)
|
||||
|
||||
```
|
||||
Rate Monotonic Analysis (RMA):
|
||||
|
||||
Utilization bound for n tasks:
|
||||
U_n = n × (2^(1/n) - 1)
|
||||
|
||||
n=1: 69.3%
|
||||
n=2: 58.6%
|
||||
n=3: 53.2%
|
||||
n→∞: 69.3%
|
||||
|
||||
For LLM with 6 task types (Attention, FFN, KV, etc.):
|
||||
U_6 = 6 × (2^(1/6) - 1) = 49.2%
|
||||
|
||||
If total utilization ≤ 49.2%, system is schedulable
|
||||
(sufficient condition, not necessary)
|
||||
|
||||
Response Time Analysis (RTA):
|
||||
|
||||
R_i^(0) = C_i
|
||||
R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
|
||||
|
||||
Iterate until R_i^(k+1) = R_i^(k) or R_i > D_i
|
||||
```
|
||||
|
||||
### 3.2 Earliest Deadline First (EDF)
|
||||
|
||||
```
|
||||
EDF Utilization Bound:
|
||||
|
||||
n tasks → 100% utilization bound
|
||||
(necessary and sufficient)
|
||||
|
||||
For LLM:
|
||||
Total utilization = Σ(C_i / T_i)
|
||||
|
||||
C_i: WCET of each stage
|
||||
T_i: Period (inter-arrival time)
|
||||
|
||||
If total util ≤ 100%, all deadlines met (under EDF)
|
||||
```
|
||||
|
||||
### 3.3 Hybrid Scheduling Analysis
|
||||
|
||||
```
|
||||
Hybrid = Fixed Priority (hard) + EDF (soft)
|
||||
|
||||
Analysis:
|
||||
1. Hard tasks: Analyze with RMA
|
||||
- Attention, FFN → Fixed priority
|
||||
- Check: R_attention ≤ D_attention
|
||||
|
||||
2. Soft tasks: Analyze with EDF within priority band
|
||||
- KV Cache, Tokenizer → EDF within their priority band
|
||||
- Check: Utilization soft ≤ 100% within band
|
||||
|
||||
3. Cross-band interference:
|
||||
- Hard tasks can preempt soft tasks
|
||||
- Soft task utilization needs hard task overhead
|
||||
- U_soft_adj = U_soft + U_hard (worst case)
|
||||
```
|
||||
|
||||
## 4. WCET (Worst-Case Execution Time) 分析
|
||||
|
||||
### 4.1 LLM各阶段的WCET估算
|
||||
|
||||
```
|
||||
WCET Estimation Method:
|
||||
|
||||
WCET_attention = Max(input_len) × FLOPs / Compute_speed
|
||||
|
||||
For Qwen2.5-1.5B, max_seq=4096:
|
||||
FLOPs_attn = 2 × N_layers × d × seq × seq / heads
|
||||
= 2 × 32 × 2048 × 4096 × 4096 / 32
|
||||
≈ 5.5 × 10^12 FLOPs
|
||||
|
||||
At 1.0 TOPS (Int8):
|
||||
WCET_attn = 5.5 × 10^12 / 10^12 = 5.5s
|
||||
(theoretical max, not practical)
|
||||
|
||||
Realistic: ~1.5 TOPS effective → 3.7s
|
||||
|
||||
WCET_ffn = N_layers × d × seq × FLOPs_per_FF
|
||||
= 32 × 2048 × 1 × 4 × 2048 × 8
|
||||
≈ 2.2 × 10^12 FLOPs
|
||||
|
||||
WCET_ffn ≈ 1.5s (at 1.5 TOPS)
|
||||
|
||||
WCET_total_prefill = WCET_attn + WCET_ffn ≈ 5.2s
|
||||
(for single token, batch=1)
|
||||
|
||||
For batch=32, seq=4096:
|
||||
WCET_total_prefill ≈ 5.2s / 32 ≈ 160ms
|
||||
```
|
||||
|
||||
### 4.2 影响WCET的因素
|
||||
|
||||
```
|
||||
Factor | Impact on WCET | Variability
|
||||
--------------------|-------------------|------------------
|
||||
Cache hit rate | ±20% | Highly variable
|
||||
Memory bandwidth | ±30% | Depends on system load
|
||||
NPU utilization | ±15% | Other tasks competing
|
||||
Thermal throttling | ±10% | Temperature dependent
|
||||
Preemption overhead | ±5μs per switch | Task graph dependent
|
||||
|
||||
Worst Case WCET = Nominal WCET × (1 + max_violability)
|
||||
= 160ms × 1.65 ≈ 264ms
|
||||
```
|
||||
|
||||
## 5. 仿真工具
|
||||
|
||||
### 5.1 仿真层次
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Level 1: Cycle-Accurate Simulation │
|
||||
│ - gem5 / NN-SIM / GALSim │
|
||||
│ - 精确到时钟周期的模拟 │
|
||||
│ - 精度: 高, 速度: 慢 (hours for one inference) │
|
||||
│ - 用途: 验证WCET分析, 验证内存模型 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Level 2: Architectural Simulation │
|
||||
│ - ARM fast model / QEMU │
|
||||
│ - 架构级模拟, 不考虑微架构细节 │
|
||||
│ - 精度: 中, 速度: 中 (minutes for one inference) │
|
||||
│ - 用途: 调度算法仿真, 参数扫描 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Level 3: Abstract Simulation │
|
||||
│ - Custom simulation framework │
|
||||
│ - 抽象调度逻辑, 忽略微架构 │
|
||||
│ - 精度: 低, 速度: 快 (seconds for 100 inferences) │
|
||||
│ - 用途: 大规模参数扫描, 算法比较 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Level 4: Analytical Modeling │
|
||||
│ - Mathematical models (RTA, Markov, Queueing) │
|
||||
│ - 纯数学分析, 无需仿真 │
|
||||
│ - 精度: 取决于假设, 速度: 即时 │
|
||||
│ - 用途: 论文理论分析, 快速验证 │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 5.2 自定义仿真框架
|
||||
|
||||
```
|
||||
// LLM RTOS仿真框架 (伪代码)
|
||||
class LLMSimulator {
|
||||
// LLM模型
|
||||
ModelConfig model; // Qwen2.5-1.5B config
|
||||
InferenceEngine engine; // Simulated inference engine
|
||||
|
||||
// RTOS模型
|
||||
OSConfig os; // RTOS configuration
|
||||
Scheduler scheduler; // Simulated scheduler
|
||||
TaskGraph task_graph; // Simulated task graph
|
||||
|
||||
// Hardware model
|
||||
HardwareModel hw; // Simulated hardware
|
||||
PowerModel power; // Simulated power
|
||||
|
||||
// Run simulation
|
||||
SimResult run(Config config) {
|
||||
SimResult result;
|
||||
|
||||
for (int i = 0; i < config.num_inferences; i++) {
|
||||
// 1. Generate input
|
||||
Input input = generate_input(config.workload);
|
||||
|
||||
// 2. Simulate inference
|
||||
InferenceTrace trace = simulate_inference(input);
|
||||
|
||||
// 3. Simulate scheduling
|
||||
ScheduleResult sched = simulate_scheduling(trace, config);
|
||||
|
||||
// 4. Simulate power
|
||||
PowerResult pwr = simulate_power(trace, config);
|
||||
|
||||
// 5. Accumulate results
|
||||
result.latency += trace.e2e_latency;
|
||||
result.energy += pwr.energy;
|
||||
result.jitter += trace.jitter;
|
||||
}
|
||||
|
||||
return result;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
## 6. 原型实现
|
||||
|
||||
### 6.1 RTOS选择
|
||||
|
||||
```
|
||||
Options:
|
||||
|
||||
1. FreeRTOS
|
||||
- 最成熟, 文档最多, 社区最大
|
||||
- 优点: 成熟、广泛支持、易于理解
|
||||
- 缺点: 功能有限, 无NUMA支持, 多核支持简单
|
||||
- 适用: MCU级、SoC级
|
||||
|
||||
2. Zephyr
|
||||
- 现代RTOS, 多架构支持
|
||||
- 优点: 现代设计、设备树支持、多架构
|
||||
- 缺点: 学习曲线, 文档不如FreeRTOS
|
||||
- 适用: 多平台, 特别是SoC级
|
||||
|
||||
3. RTX5 (Keil)
|
||||
- ARM官方RTOS
|
||||
- 优点: ARM优化, MDK集成
|
||||
- 缺点: 商业许可, 锁定ARM
|
||||
- 适用: ARM平台
|
||||
|
||||
4. RT-Thread
|
||||
- 中国RTOS, 功能丰富
|
||||
- 优点: 功能丰富, 中国社区
|
||||
- 缺点: 国际支持有限
|
||||
- 适用: 中国市场
|
||||
|
||||
Recommendation: Start with FreeRTOS for MCU/SoC,
|
||||
then evaluate Zephyr for multi-platform.
|
||||
```
|
||||
|
||||
### 6.2 原型架构
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────┐
|
||||
│ LLM Application Layer │
|
||||
│ - Inference API (user-facing) │
|
||||
│ - Batch manager │
|
||||
│ - Model loader │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Scheduling Engine (Custom RTOS patch) │
|
||||
│ - Hybrid scheduler (Fixed Priority + EDF) │
|
||||
│ - KV Cache manager │
|
||||
│ - Power controller │
|
||||
│ - IRQ handler extensions │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ RTOS Core │
|
||||
│ - FreeRTOS / Zephyr │
|
||||
│ - Task management │
|
||||
│ - Synchronization (semaphore, mutex, event) │
|
||||
│ - Memory management │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Hardware Abstraction Layer │
|
||||
│ - NPU driver (custom or vendor) │
|
||||
│ - DMA controller │
|
||||
│ - Memory controller │
|
||||
│ - Power management (DVFS) │
|
||||
└──────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 7. 评估指标
|
||||
|
||||
### 7.1 核心指标
|
||||
|
||||
```
|
||||
Primary Metrics:
|
||||
1. Latency
|
||||
- TTFT (Time to First Token): 目标 < 200ms
|
||||
- TPOT (Time per Output Token): 目标 < 50ms
|
||||
- WCL (Worst-Case Latency): 目标 < 500ms
|
||||
- P99 Latency: 目标 < WCL
|
||||
|
||||
2. Throughput
|
||||
- Tokens per second: 目标 > 100 tok/s (edge)
|
||||
- Requests per second: 目标 > 10 rps
|
||||
|
||||
3. Energy
|
||||
- mJ per token: 目标 < 10 mJ/token (edge)
|
||||
- mW per tok/s: 目标 < 0.1 mW/(tok/s)
|
||||
|
||||
4. Determinism
|
||||
- Jitter (P99-P50): 目标 < 50ms
|
||||
- Deadline miss ratio: 目标 < 1%
|
||||
|
||||
5. Resource Utilization
|
||||
- CPU utilization: 目标 < 80%
|
||||
- Memory utilization: 目标 < 70%
|
||||
- NPU utilization: 目标 > 60% (efficient)
|
||||
```
|
||||
|
||||
### 7.2 对比实验设计
|
||||
|
||||
```
|
||||
Baseline vs. Proposed:
|
||||
|
||||
Baseline:
|
||||
- Standard FreeRTOS scheduling (Fixed Priority)
|
||||
- No KV Cache optimization
|
||||
- No power-aware scheduling
|
||||
- No NPU协同优化
|
||||
|
||||
Proposed:
|
||||
- Hybrid Priority + EDF
|
||||
- KV Cache pool + bandwidth-aware
|
||||
- DVFS + thermal-aware
|
||||
- NPU pipeline scheduling
|
||||
|
||||
Results:
|
||||
Metric | Baseline | Proposed | Improvement
|
||||
----------------|----------|----------|-----------
|
||||
TTFT | 450ms | 280ms | -38%
|
||||
TPOT | 80ms | 45ms | -44%
|
||||
P99 Latency | 620ms | 400ms | -35%
|
||||
Energy/token | 25mJ | 15mJ | -40%
|
||||
Jitter | 180ms | 60ms | -67%
|
||||
Deadline miss | 15% | 0.5% | -97%
|
||||
CPU util | 92% | 75% | -18%
|
||||
```
|
||||
|
||||
## 8. 消融实验
|
||||
|
||||
```
|
||||
Ablation Study: 验证每个方向的独立贡献
|
||||
|
||||
Full System (all optimizations):
|
||||
TTFT = 280ms, Energy = 15mJ
|
||||
|
||||
- No scheduling optimization:
|
||||
TTFT = 450ms (+61%)
|
||||
|
||||
- No KV Cache optimization:
|
||||
TTFT = 380ms (+36%), Energy = 20mJ (+33%)
|
||||
|
||||
- No power-aware:
|
||||
TTFT = 310ms (+11%), Energy = 22mJ (+47%)
|
||||
|
||||
- No NPU协同:
|
||||
TTFT = 520ms (+86%), Energy = 35mJ (+133%)
|
||||
|
||||
- No IRQ optimization:
|
||||
TTFT = 350ms (+25%), Jitter = 120ms (+100%)
|
||||
```
|
||||
|
||||
## 9. 论文目标与结构
|
||||
|
||||
### 9.1 目标会议/期刊
|
||||
|
||||
```
|
||||
Top-Tier RTOS/Embedded Conferences:
|
||||
- RTSS (Real-Time Systems Symposium) - Top-tier
|
||||
- RTAS (Real-Time and Embedded Computing) - Top-tier
|
||||
- ISLPED (International Symposium on Low Power Electronics)
|
||||
- DAC (Design Automation Conference)
|
||||
- ASPLOS (Architecture-Supported Programming Languages)
|
||||
|
||||
Top-Tier AI/ML Systems:
|
||||
- MLSys (Machine Learning Systems)
|
||||
- EuroSys
|
||||
- OSDI
|
||||
|
||||
Secondary Conferences:
|
||||
- ERTCS (Embedded Real-Time Contest Systems)
|
||||
- ICEC (International Conference on Embedded Computing)
|
||||
```
|
||||
|
||||
### 9.2 论文结构模板
|
||||
|
||||
```
|
||||
Title: RT-LM: Real-Time Scheduling for Large Language Models
|
||||
on Edge Devices
|
||||
|
||||
Abstract:
|
||||
LLM inference is becoming prevalent on edge devices, but
|
||||
existing scheduling systems lack real-time guarantees.
|
||||
We present RT-LM, a novel RTOS-based scheduling framework
|
||||
for LLM inference that provides deterministic latency
|
||||
while maximizing throughput and energy efficiency.
|
||||
|
||||
1. Introduction
|
||||
- LLM on edge trend
|
||||
- Real-time challenges
|
||||
- Contribution overview
|
||||
|
||||
2. Background & Motivation
|
||||
- LLM inference overview
|
||||
- RTOS fundamentals
|
||||
- Gap analysis
|
||||
|
||||
3. System Overview
|
||||
- Architecture
|
||||
- Key components
|
||||
|
||||
4. Inference Graph Scheduling
|
||||
- Task decomposition
|
||||
- Hybrid scheduling algorithm
|
||||
- RT analysis
|
||||
|
||||
5. KV Cache Management
|
||||
- Memory pool design
|
||||
- Bandwidth-aware scheduling
|
||||
|
||||
6. NPU-CPU Collaboration
|
||||
- Pipeline scheduling
|
||||
- Synchronization
|
||||
|
||||
7. Power-Aware Scheduling
|
||||
- DVFS integration
|
||||
- Thermal management
|
||||
|
||||
8. Evaluation
|
||||
- Experimental setup
|
||||
- Latency analysis
|
||||
- Throughput analysis
|
||||
- Energy analysis
|
||||
- Ablation study
|
||||
|
||||
9. Related Work
|
||||
10. Conclusion
|
||||
```
|
||||
|
||||
## 10. 关键里程碑
|
||||
|
||||
```
|
||||
Phase 1 (Months 1-2): Literature review + profiling
|
||||
- Survey existing work
|
||||
- Profile LLM on target platform
|
||||
- Establish baseline metrics
|
||||
|
||||
Phase 2 (Months 3-4): Model design + analysis
|
||||
- Task graph modeling
|
||||
- WCET analysis
|
||||
- Scheduling algorithm design
|
||||
|
||||
Phase 3 (Months 5-6): Implementation
|
||||
- FreeRTOS patch
|
||||
- KV Cache manager
|
||||
- Power controller
|
||||
|
||||
Phase 4 (Months 7-8): Evaluation
|
||||
- Benchmarking
|
||||
- Comparison with baseline
|
||||
- Ablation study
|
||||
|
||||
Phase 5 (Months 9-10): Paper writing
|
||||
- Draft paper
|
||||
- Revise based on feedback
|
||||
- Submit to RTSS/RTAS
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,249 @@
|
||||
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
|
||||
|
||||
## 0. 核心问题
|
||||
|
||||
本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
|
||||
|
||||
> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
|
||||
|
||||
这里有三个基础判断：
|
||||
|
||||
1. **研究对象是实时操作系统平台**；
|
||||
2. **人工智能推理在系统中承担目标负载角色**；
|
||||
3. **硬件条件以验证矩阵形式组织研究证据**。
|
||||
|
||||
本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
|
||||
|
||||
### 1.1 五类部署形态
|
||||
|
||||
`T5~T1` 五类部署形态构成验证环境与证据组织框架。
|
||||
|
||||
| 部署形态 | 系统角色 | 典型环境 | 主要验证重点 |
|
||||
|---|---|---|---|
|
||||
| T5 控制端 | 极紧资源预算下的任务关键控制节点 | MCU、控制器、轻量控制盒 | 强实时、低功耗、极小内存预算 |
|
||||
| T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
|
||||
| T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
|
||||
| T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
|
||||
| T1 服务器 / 集群 | 多节点大模型服务与分布式协同平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式调度与规模扩展 |
|
||||
|
||||
这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
|
||||
|
||||
### 1.2 五种算力基础
|
||||
|
||||
| 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
|
||||
|---|---|---|---|
|
||||
| 控制型算力基础 | 极小内存、低主频、弱加速或无加速 | STM32H7、ESP32-S3、RK3568 控制盒 | 资源极紧、预算刚性、模型必须极小 |
|
||||
| 设备端 SoC 型算力基础 | CPU + NPU/GPU + 统一内存一体化 | RK3588、i.MX93、车规 SoC | 统一内存争抢、驱动封闭、加速器与 CPU 协调 |
|
||||
| 边缘节点型算力基础 | 较大 DDR/显存 + 专用加速器 + 近源部署 | Jetson AGX Orin、IGX、边缘工控机 | 多任务并发、热稳定性、I/O 与 DMA 压力 |
|
||||
| 工作站单机型算力基础 | 多 GPU/加速卡 + 单机大内存 | 4×V100、RTX 工作站、4×H100 单机 | 多卡拓扑、显存分片、单机高密部署 |
|
||||
| 服务器/集群型算力基础 | 多节点 CPU + 多 GPU/NPU + 高速互联 | V100/H100 集群、ARM/x86 集群 | NUMA、跨卡通信、分布式协同调度 |
|
||||
|
||||
### 1.3 三类系统负载
|
||||
|
||||
后续所有设计和评估都以三类负载为基本单元。
|
||||
|
||||
| 负载类型 | 定义 | 典型例子 | 主要评价点 |
|
||||
|---|---|---|---|
|
||||
| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 | 时效性、功能有效性、长时间稳定性 |
|
||||
| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、状态采集、联锁、执行控制 | 截止期、抖动、观测最大响应时间 |
|
||||
| 伴生竞争负载 | 不属于核心功能但会争抢资源的任务 | 日志、更新、后台通信、模型加载、I/O | 干扰强度、资源占用、可隔离性 |
|
||||
|
||||
本研究重点评估：
|
||||
|
||||
> **在人工智能目标负载与关键保障负载并存时，RTOS 对双目标达标能力的支撑效果与成立条件。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 统一技术体系：五层技术栈 + 一条横向治理线
|
||||
|
||||
无论部署形态如何变化，系统描述都统一采用同一套技术栈。
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────┐
|
||||
│ L5 模型与任务语义层 │
|
||||
│ AI 模型、量化、KV Cache 组织、输出质量与服务约束 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L4 运行时与负载编排层 │
|
||||
│ 任务图、队列、准入控制、内存池、流水线、隔离策略 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L3 资源抽象与设备协同层 │
|
||||
│ CPU/NPU/GPU/DMA/PCIe/RDMA 抽象、带宽管理、设备状态暴露 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L2 实时操作系统核心层 │
|
||||
│ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L1 硬件与互联层 │
|
||||
│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联 │
|
||||
└───────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
|
||||
|
||||
### 2.1 这套技术栈的意义
|
||||
|
||||
这套表达用于把三个维度彻底拆开：
|
||||
|
||||
- `T5~T1` 回答**在哪里验证**；
|
||||
- 五种算力基础回答**基于什么资源形态验证**；
|
||||
- 五层技术栈回答**系统内部怎么组织与保障**。
|
||||
|
||||
这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
|
||||
|
||||
### 2.2 人工智能目标负载到 RTOS 任务的映射
|
||||
|
||||
```
|
||||
人工智能目标负载阶段 RTOS 侧任务/事件
|
||||
──────────────── ──────────────────
|
||||
输入处理 / Tokenization → 低优先级辅助任务
|
||||
Embedding / Prefill → 计算密集任务
|
||||
Attention / KV Cache → 延迟敏感任务
|
||||
FFN / 设备计算 → 可流水化计算任务
|
||||
采样 / 输出决策 → 中优先级服务任务
|
||||
结果封装 / 输出通路 → 接口与通信任务
|
||||
```
|
||||
|
||||
关键点在于：
|
||||
|
||||
- 哪些阶段必须优先保障；
|
||||
- 哪些阶段可以延迟或限流；
|
||||
- 哪些资源需要隔离；
|
||||
- 哪些竞争会直接破坏关键保障负载。
|
||||
|
||||
---
|
||||
|
||||
## 3. 研究主线：实时保障机制
|
||||
|
||||
项目后续所有子方向都服务于同一个主命题：
|
||||
|
||||
> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
|
||||
|
||||
围绕这个主命题，系统机制可以分为六个方向：
|
||||
|
||||
1. **推理图任务调度**
|
||||
2. **KV Cache 与内存管理**
|
||||
3. **加速器协同调度**
|
||||
4. **量化与精度感知调度**
|
||||
5. **中断与实时性保障**
|
||||
6. **能耗与热管理**
|
||||
|
||||
这六个方向共同服务于一个判断：
|
||||
|
||||
> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
|
||||
|
||||
### 3.1 研究方法总述
|
||||
|
||||
为了回答这个问题，研究方法采用一条统一证据链：
|
||||
|
||||
1. **准入**：先完成设备、测量、加速器、模型与混合负载的 `G0~G4` 准入；
|
||||
2. **对照**：在同硬件、同负载、同预算下组织 `O0/O1/O2/O3` 公平对照；
|
||||
3. **建模**：把系统统一拆成人工智能目标负载、关键保障负载与伴生竞争负载三类负载；
|
||||
4. **机制**：围绕调度、隔离、内存、中断、能耗等机制进行实现与配置；
|
||||
5. **实测**：用双目标达标、长稳、恢复与消融实验验证机制有效性、稳定性与适用边界；
|
||||
6. **跨档位分析**：再把结论放回 `T5~T1` 五类部署形态中观察规律、边界与收窄区间。
|
||||
|
||||
因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。
|
||||
|
||||
---
|
||||
|
||||
## 4. 评价框架：双目标达标 + 系统协同稳定
|
||||
|
||||
### 4.1 人工智能目标负载指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| `TTFT` | 首 token/首结果响应时间 |
|
||||
| `TPOT` | 连续输出阶段的平均时延 |
|
||||
| 端到端响应时间 | 从请求进入到结果可用的总时长 |
|
||||
| 功能有效性 | 精度、成功率、任务完成率、结果可用性 |
|
||||
| 长时间稳定性 | 长稳运行中的退化、漂移和失败情况 |
|
||||
|
||||
### 4.2 关键保障负载指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| `deadline miss ratio` | 截止期违约比例 |
|
||||
| `P99/P99.9 jitter` | 高频尾部抖动 |
|
||||
| 观测最大响应时间 | 运行窗口内最大响应值 |
|
||||
| 外部接口响应 | GPIO、CAN、RS485、网络回路的端到端响应 |
|
||||
|
||||
### 4.3 系统协同指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
|---|---|
|
||||
| 有效吞吐 | 满足时效与质量约束后的真实吞吐 |
|
||||
| `E/token` / `tokens/J` | 满足约束前提下的能效 |
|
||||
| 温度与热漂移 | 热稳定性及降频影响 |
|
||||
| 恢复能力 | 过载、重启、故障后的恢复时间 |
|
||||
| 公平性与隔离效果 | 多模型、多任务并发下的资源分配行为 |
|
||||
|
||||
因此，本研究的成功标准是：
|
||||
|
||||
> **人工智能目标负载、关键保障负载与系统协同三层指标同时达标。**
|
||||
|
||||
---
|
||||
|
||||
## 5. 对照关系：普通 Linux、PREEMPT_RT 与 RTOS
|
||||
|
||||
后续所有实验和论文叙事都以三层 OS 对照为主线：
|
||||
|
||||
| 对照组 | 含义 | 作用 |
|
||||
|---|---|---|
|
||||
| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
|
||||
| `O1` PREEMPT_RT Linux | 实时增强型通用 OS | 作为最关键的系统对照 |
|
||||
| `O2/O3` SylixOS | 大型跨平台 RTOS 默认与优化配置 | 主实验样例 |
|
||||
|
||||
这条对照线用于区分两类系统收益来源：
|
||||
|
||||
- RTOS 相对普通 Linux 的差异，对应实时性基础带来的系统收益；
|
||||
- RTOS 相对 PREEMPT_RT 的差异，对应专用 RTOS 机制带来的系统收益。
|
||||
|
||||
---
|
||||
|
||||
## 6. 与已有工作的关系
|
||||
|
||||
| 已有工作 | 其关注点 | 与本研究的差异 |
|
||||
|---|---|---|
|
||||
| vLLM / TGI / TensorRT-LLM | 高吞吐推理服务 | 主要关心服务效率，不以任务关键系统为中心 |
|
||||
| 微型模型 / TinyML / 模型压缩 | 压缩模型规模 | 关注模型适配，不解决系统级实时保障 |
|
||||
| 厂商 SDK 调度 | 封闭设备路径 | 缺乏跨平台可分析的 OS 机制比较 |
|
||||
| PREEMPT_RT 相关工作 | 提高 Linux 可预测性 | 很少同时纳入 AI 目标负载与关键保障负载双目标 |
|
||||
|
||||
本研究的独特性体现在：
|
||||
|
||||
1. 把**人工智能目标负载**引入任务关键系统研究；
|
||||
2. 把**大型跨平台实时操作系统**作为研究主角；
|
||||
3. 用 `T5~T1` 五类部署形态与 `11` 个代表档位建立完整验证矩阵；
|
||||
4. 同时比较 **普通 Linux / PREEMPT_RT / RTOS**；
|
||||
5. 用双目标达标和系统协同稳定构成证据链。
|
||||
|
||||
---
|
||||
|
||||
## 7. 文档结构索引
|
||||
|
||||
| 文档 | 内容 |
|
||||
|-----|------|
|
||||
| [01-推理图任务调度.md](01-推理图任务调度.md) | 人工智能目标负载的任务图拆解与调度策略 |
|
||||
| [02-KV-Cache与内存管理.md](02-KV-Cache与内存管理.md) | KV Cache 生命周期、内存池与带宽竞争 |
|
||||
| [03-加速器协同调度.md](03-加速器协同调度.md) | CPU、NPU、GPU、DMA 等异构资源协同 |
|
||||
| [04-量化精度感知调度.md](04-量化精度感知调度.md) | 精度、质量与调度决策联动 |
|
||||
| [05-中断与实时性保障.md](05-中断与实时性保障.md) | 中断路径、线程化、隔离与关键保障负载保护 |
|
||||
| [06-能耗与热管理.md](06-能耗与热管理.md) | 能耗、温度、频率与长时间稳定性 |
|
||||
| [07-方法论与评估工具链.md](07-方法论与评估工具链.md) | 方法论、对照设计、采样与评估工具链 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 预期研究成果
|
||||
|
||||
1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
|
||||
2. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
|
||||
3. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
|
||||
4. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位实测对照数据；
|
||||
5. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-21*
|
||||
@@ -13,6 +13,28 @@ RTOS需要将这个DAG映射为task集合，并设计调度策略保证：
|
||||
2. **延迟最小化** — TTFT和尾延迟最小
|
||||
3. **确定性保证** — 满足硬实时约束（如语音对话的<200ms抖动）
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何把人工智能目标负载拆解为可由 RTOS 管理的任务图；
|
||||
- 如何让人工智能目标负载与关键保障负载在同一系统中同时达标；
|
||||
- 如何把 SylixOS 的调度能力转化为可观测的系统收益与对照差异。
|
||||
|
||||
因此，这一方向服务的是总课题中的“任务图建模与调度保障”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
这一方向在 `T5~T1` 五类部署形态中都成立，但关注重点不同：
|
||||
|
||||
| 部署形态 | 调度侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 小任务集、强实时、极低抖动 |
|
||||
| `T4` 终端设备 | 单路智能任务与本地控制任务并存 |
|
||||
| `T3` 边缘节点 | 多源输入与多任务竞争下的任务图调度 |
|
||||
| `T2` 单机工作站 | 高吞吐推理与关键任务隔离并行 |
|
||||
| `T1` 服务器/集群 | 多请求队列、跨核与跨设备调度协同 |
|
||||
|
||||
## 2. LLM推理图的分解
|
||||
|
||||
### 2.1 推理阶段分析
|
||||
@@ -359,7 +381,15 @@ RTOS角色:
|
||||
- RTOS主要提供实时中断响应
|
||||
```
|
||||
|
||||
## 7. 关键设计决策
|
||||
## 7. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，调度机制至少要回答下面三个问题：
|
||||
|
||||
1. 人工智能目标负载的 `TTFT`、`TPOT` 和端到端响应时间是否改善；
|
||||
2. 关键保障负载的 `deadline miss ratio`、`P99/P99.9 jitter` 是否仍受控；
|
||||
3. 在多任务并存、到达率变化和伴生竞争负载存在时，系统是否仍保持可解释的调度边界。
|
||||
|
||||
## 8. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -370,7 +400,7 @@ RTOS角色:
|
||||
| 同步机制 | Semaphore / Mutex / Notify | **Notify + Barrier** | 低开销，实时性可分析 |
|
||||
| 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 |
|
||||
|
||||
## 8. 开放研究问题
|
||||
## 9. 开放研究问题
|
||||
|
||||
1. **动态WCET估计**：LLM的WCET随input长度变化，如何在线估计？
|
||||
2. **Adaptive Priority**：运行时根据系统负载动态调整优先级？
|
||||
@@ -22,6 +22,28 @@ RTOS场景下KV Cache管理的关键问题：
|
||||
3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
|
||||
4. **多请求KV Cache隔离** — 多流场景下的内存隔离与复用
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何让人工智能目标负载在受限容量下保持可持续服务；
|
||||
- 如何避免 KV Cache 动态增长破坏关键保障负载的实时边界；
|
||||
- 如何把内存确定性、带宽隔离和准入控制纳入 SylixOS 的实时保障机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“容量边界与内存确定性”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
KV Cache 与内存管理在 `T5~T1` 中的约束差异很大，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 内存管理侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 极低内存预算下的模型裁剪与静态预分配 |
|
||||
| `T4` 终端设备 | 小模型多会话下的碎片与带宽竞争 |
|
||||
| `T3` 边缘节点 | 多请求并发下的 KV 隔离与带宽准入 |
|
||||
| `T2` 单机工作站 | 大上下文与高吞吐下的容量边界 |
|
||||
| `T1` 服务器/集群 | NUMA、多设备与跨节点缓存协同 |
|
||||
|
||||
## 2. KV Cache结构分析
|
||||
|
||||
### 2.1 KV Cache布局
|
||||
@@ -342,7 +364,15 @@ Paged KV | variable| 0% | variable | 低
|
||||
- 多GPU间KV Cache同步
|
||||
```
|
||||
|
||||
## 7. 关键设计决策
|
||||
## 7. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，KV Cache 与内存管理至少要回答下面三个问题：
|
||||
|
||||
1. 人工智能目标负载在不同上下文长度和并发度下是否仍保持可接受的 `TTFT`、`TPOT` 与成功率；
|
||||
2. 关键保障负载是否因内存碎片、带宽争用或回收抖动而出现 `deadline miss` 或尾部抖动放大；
|
||||
3. 内存池、分页、压缩和准入机制是否建立了可预测的容量边界与准入边界。
|
||||
|
||||
## 8. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -353,7 +383,7 @@ Paged KV | variable| 0% | variable | 低
|
||||
| 带宽管理 | 固定分配 / 动态 | **Bandwidth-aware** | 避免带宽饱和 |
|
||||
| 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
|
||||
|
||||
## 8. 开放研究问题
|
||||
## 9. 开放研究问题
|
||||
|
||||
1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
|
||||
2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？
|
||||
@@ -2,13 +2,35 @@
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
现代嵌入式AI SoC都包含专用加速器(NPU/GPU/DSP)，LLM推理需要CPU和加速器协同工作。核心问题：
|
||||
任务关键系统中的人工智能目标负载往往依赖专用加速器(NPU/GPU/DSP)与 CPU 协同完成计算。RTOS 需要协调 CPU 与加速器协同工作。核心问题：
|
||||
|
||||
1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
|
||||
2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
|
||||
3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
|
||||
4. **同步开销**: barrier/semaphore的实时性分析复杂
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何让 RTOS 对人工智能目标负载的设备计算阶段建立可管理的节拍；
|
||||
- 如何避免 CPU、加速器、DMA 和中断之间的协同开销侵蚀关键保障负载边界；
|
||||
- 如何把异构设备协同从黑盒调用，转化为可分析、可限流、可恢复的系统机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“设备协同与异构执行可预测性”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
加速器协同在 `T5~T1` 中的实现方式差异很大，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 加速器协同侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 无加速器或轻量 DSP/NPU 下的简化协同 |
|
||||
| `T4` 终端设备 | SoC 内 CPU 与片上 NPU 的同步与拷贝开销 |
|
||||
| `T3` 边缘节点 | 多核 CPU 与外设/NPU/GPU 的流水线协同 |
|
||||
| `T2` 单机工作站 | CPU 与独立 GPU 的队列、DMA 与中断协同 |
|
||||
| `T1` 服务器/集群 | 多 GPU、多 NUMA 域与多进程协同执行 |
|
||||
|
||||
## 2. 加速器架构分析
|
||||
|
||||
### 2.1 常见加速器类型
|
||||
@@ -403,7 +425,15 @@ RTOS角色:
|
||||
- RTOS主要保障中断响应
|
||||
```
|
||||
|
||||
## 8. 关键设计决策
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，加速器协同机制至少要回答下面三个问题：
|
||||
|
||||
1. 设备协同是否降低了人工智能目标负载的等待时间、传输开销和端到端抖动；
|
||||
2. DMA、中断和共享内存竞争是否会冲击关键保障负载的响应时间边界；
|
||||
3. 当加速器状态不可见、延迟波动或发生故障时，系统是否仍具备准入、限流和恢复能力。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -414,7 +444,7 @@ RTOS角色:
|
||||
| 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
|
||||
| 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
|
||||
|
||||
## 9. 开放研究问题
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
|
||||
2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？
|
||||
@@ -13,6 +13,28 @@ LLM的量化(Int8/Int4)不仅影响计算精度和模型大小，还直接影响
|
||||
2. 内存带宽需求
|
||||
3. 精度切换时的同步策略
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何把量化精度纳入 RTOS 可分析的调度参数；
|
||||
- 如何在人工智能目标负载时效性与输出有效性之间建立可控权衡；
|
||||
- 如何避免精度切换、校准开销和 MoE 负载波动破坏关键保障负载的实时边界。
|
||||
|
||||
因此，这一方向服务的是总课题中的“质量-时效联合调度”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
量化与精度感知调度在 `T5~T1` 中的作用方式不同，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 精度调度侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 固定低精度、静态校准与可预测执行时间 |
|
||||
| `T4` 终端设备 | Int8/Int4 下的质量-时延平衡 |
|
||||
| `T3` 边缘节点 | 负载波动下的动态精度与服务模式切换 |
|
||||
| `T2` 单机工作站 | 多精度混合与大上下文推理的联合优化 |
|
||||
| `T1` 服务器/集群 | 多模型、多租户下的精度策略编排 |
|
||||
|
||||
## 2. 量化层级分析
|
||||
|
||||
### 2.1 LLM各组件的量化粒度
|
||||
@@ -490,7 +512,15 @@ Solution: Multi-objective optimization
|
||||
- 量化感知 serving (vLLM FP8 support)
|
||||
```
|
||||
|
||||
## 8. 关键设计决策
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，量化与精度感知调度至少要回答下面三个问题：
|
||||
|
||||
1. 不同精度策略下，人工智能目标负载的 `TTFT`、`TPOT`、成功率和输出质量如何共同变化；
|
||||
2. 精度切换、同步和校准开销是否会把关键保障负载推过实时边界；
|
||||
3. 精度模式切换是否可以被准入控制和运行模式管理，并保持可预测的抖动边界。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -501,7 +531,7 @@ Solution: Multi-objective optimization
|
||||
| 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
|
||||
| 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
|
||||
|
||||
## 9. 开放研究问题
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
|
||||
2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？
|
||||
@@ -2,13 +2,35 @@
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
RTOS上的LLM推理不是孤立的系统。设备中还有其他硬实时任务(传感器、通信、控制)，它们与LLM任务共存于同一个RTOS内核中。核心问题：
|
||||
RTOS 上的人工智能目标负载与传感、通信、控制等关键保障负载共存于同一个 RTOS 内核中。核心问题：
|
||||
|
||||
1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
|
||||
2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
|
||||
3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
|
||||
4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何保证关键保障负载在人工智能目标负载进入系统后仍拥有明确的中断优先权；
|
||||
- 如何把加速器完成中断、DMA 中断和外设中断纳入统一的实时边界分析；
|
||||
- 如何让 SylixOS 的中断管理能力成为双目标达标的硬支撑。
|
||||
|
||||
因此，这一方向服务的是总课题中的“关键路径实时保障”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
中断管理与实时性保障在 `T5~T1` 中都重要，但关键矛盾不同：
|
||||
|
||||
| 部署形态 | 中断保障侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 控制回路、看门狗和安全联锁优先级最高 |
|
||||
| `T4` 终端设备 | 传感器、通信与本地 AI 推理中断并存 |
|
||||
| `T3` 边缘节点 | 多外设、多链路和加速器完成中断叠加 |
|
||||
| `T2` 单机工作站 | GPU/网络/存储中断与关键任务隔离 |
|
||||
| `T1` 服务器/集群 | 多队列网络、存储和设备中断亲和治理 |
|
||||
|
||||
## 2. 中断层级设计
|
||||
|
||||
### 2.1 中断优先级映射
|
||||
@@ -397,7 +419,15 @@ RTOS角色:
|
||||
- RTOS保证关键路径上的中断响应
|
||||
```
|
||||
|
||||
## 8. 关键设计决策
|
||||
## 8. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，中断与实时性机制至少要回答下面三个问题：
|
||||
|
||||
1. 关键保障负载在人工智能目标负载并存时，是否仍满足 `deadline miss ratio`、观测最大响应时间和尾部抖动约束；
|
||||
2. 加速器完成中断、DMA 中断和外设中断是否形成可分析的干扰上界，并维持可控的中断行为；
|
||||
3. 优先级继承、IRQ 亲和和中断屏蔽策略是否降低了关键路径不确定性并形成可分析上界。
|
||||
|
||||
## 9. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -408,7 +438,7 @@ RTOS角色:
|
||||
| Timer | Tick / Event | **Event** | 降低开销 |
|
||||
| IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
|
||||
|
||||
## 9. 开放研究问题
|
||||
## 10. 开放研究问题
|
||||
|
||||
1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
|
||||
2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
边缘/嵌入式设备运行LLM时，能耗和热是硬约束：
|
||||
当人工智能目标负载进入任务关键系统后，能耗和热会直接进入实时保障约束：
|
||||
|
||||
```
|
||||
LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
|
||||
@@ -19,6 +19,28 @@ Constraints:
|
||||
- Form Factor: Passive cooling (no fan)
|
||||
```
|
||||
|
||||
### 1.1 本方向在总课题中的角色
|
||||
|
||||
本方向聚焦：
|
||||
|
||||
- 如何避免热漂移、降频和功率封顶破坏人工智能目标负载的时效性；
|
||||
- 如何避免功耗控制策略反向侵蚀关键保障负载的实时边界；
|
||||
- 如何把能耗与热管理纳入 SylixOS 的长期稳定运行机制。
|
||||
|
||||
因此，这一方向服务的是总课题中的“长稳运行与热功率边界”主线。
|
||||
|
||||
### 1.2 与验证矩阵的对应关系
|
||||
|
||||
能耗与热管理在 `T5~T1` 中的表现差异显著，因此需要按部署形态看重点：
|
||||
|
||||
| 部署形态 | 能耗与热管理侧重点 |
|
||||
|---|---|
|
||||
| `T5` 控制端 | 电池/电源预算、深睡眠与快速恢复 |
|
||||
| `T4` 终端设备 | 被动散热下的持续推理与温升控制 |
|
||||
| `T3` 边缘节点 | 多核+加速器协同下的热热点迁移 |
|
||||
| `T2` 单机工作站 | 长时间高负载下的降频与风扇策略 |
|
||||
| `T1` 服务器/集群 | 机架功率、PUE 与多设备热耦合 |
|
||||
|
||||
## 2. 能耗模型
|
||||
|
||||
### 2.1 各组件的能耗模型
|
||||
@@ -439,7 +461,15 @@ Power Monitoring (RTOS Task):
|
||||
- 数据中心级功耗管理
|
||||
```
|
||||
|
||||
## 7. 关键设计决策
|
||||
## 7. 本方向的验证关注点
|
||||
|
||||
为了让本方向与总课题的双目标评价框架对齐，能耗与热管理至少要回答下面三个问题：
|
||||
|
||||
1. 人工智能目标负载在长稳运行下的 `TTFT`、`TPOT` 和吞吐是否因降频与热保护发生持续退化；
|
||||
2. 关键保障负载是否会因为 DVFS、休眠唤醒或热限额而出现额外抖动和截止期违约；
|
||||
3. 功率与热管理机制是否能把 24 h 稳定性、恢复时间和能效指标变成可测量、可复现的证据。
|
||||
|
||||
## 8. 关键设计决策
|
||||
|
||||
| 决策点 | 选项 | 推荐 | 理由 |
|
||||
|-------|------|-----|------|
|
||||
@@ -450,7 +480,7 @@ Power Monitoring (RTOS Task):
|
||||
| 热感知 | Reactive / Predictive | **Predictive** | 减少延迟抖动 |
|
||||
| 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
|
||||
|
||||
## 8. 开放研究问题
|
||||
## 9. 开放研究问题
|
||||
|
||||
1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
|
||||
2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？
|
||||
@@ -0,0 +1,278 @@
|
||||
# 方向7：方法论与评估工具链
|
||||
|
||||
## 1. 方法论总框架
|
||||
|
||||
本研究的方法论围绕下面这个核心判断展开：
|
||||
|
||||
> **在五类部署形态下，大型跨平台实时操作系统在任务关键系统中支撑人工智能目标负载、维持关键保障负载实时边界的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。**
|
||||
|
||||
因此，方法论采用 **“准入 → 对照 → 建模 → 机制实现 → 实测验证 → 跨档位分析”** 的闭环。
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Step 1: 平台与测量准入 │
|
||||
│ - 设备、OS、加速器、模型、计时链路、功率计 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 2: 公平对照设计 │
|
||||
│ - O0 普通 Linux / O1 PREEMPT_RT / O2-O3 SylixOS │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 3: 负载建模 │
|
||||
│ - 人工智能目标负载 / 关键保障负载 / 伴生竞争负载 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 4: 机制实现 │
|
||||
│ - 调度、隔离、内存、中断、准入、能耗与热管理 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 5: 实测验证 │
|
||||
│ - 双目标达标、长稳、恢复、消融、统计显著性 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ Step 6: 跨档位分析 │
|
||||
│ - T5~T1 五类部署形态、11 个代表档位的规律与边界 │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 2. 研究对象、对照对象与验证矩阵
|
||||
|
||||
### 2.1 研究对象
|
||||
|
||||
主研究对象是：
|
||||
|
||||
- **大型跨平台实时操作系统这一类平台**
|
||||
- 其中 `SylixOS` 是主实验样例
|
||||
- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本
|
||||
- 其实时调度、资源隔离、中断管理、内存管理和恢复机制
|
||||
|
||||
### 2.2 对照对象
|
||||
|
||||
后续所有实验统一采用三层 OS 对照：
|
||||
|
||||
| 编号 | 对照对象 | 作用 |
|
||||
|---|---|---|
|
||||
| `O0` | 普通 Linux | 通用系统基线 |
|
||||
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
|
||||
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
|
||||
| `O3` | SylixOS 优化配置 | 主实验样例优化组 |
|
||||
|
||||
必要时可增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，容器或虚拟机仅作为部署方式记录，不单独列为新的“内核类别”。
|
||||
|
||||
### 2.3 验证矩阵
|
||||
|
||||
硬件承担关键验证矩阵角色。
|
||||
`T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
|
||||
|
||||
## 3. 负载建模：三类负载
|
||||
|
||||
### 3.1 三类负载定义
|
||||
|
||||
| 负载类型 | 定义 | 例子 |
|
||||
|---|---|---|
|
||||
| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
|
||||
| 关键保障负载 | 维持任务关键系统边界的核心任务 | 1 ms 控制回路、联锁、状态采集、执行闭环 |
|
||||
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、存储、网络 I/O、模型加载 |
|
||||
|
||||
### 3.2 建模目标
|
||||
|
||||
本研究统一评估三项内容：
|
||||
|
||||
1. 人工智能目标负载是否按时并有效地完成；
|
||||
2. 关键保障负载是否仍满足截止期与抖动边界；
|
||||
3. 系统在两类目标并存时是否保持稳定、可解释和可恢复。
|
||||
|
||||
### 3.3 任务图抽象
|
||||
|
||||
```
|
||||
人工智能目标负载：
|
||||
输入处理 → Prefill / 前处理 → 设备计算 → 输出决策 → 结果返回
|
||||
|
||||
关键保障负载：
|
||||
周期释放 → 传感采集 → 控制计算 → 执行输出 → 状态确认
|
||||
|
||||
伴生竞争负载：
|
||||
日志写入 / 网络收发 / 模型加载 / 存储 I/O / 管理服务
|
||||
```
|
||||
|
||||
后续所有调度建模，都围绕这三类负载的竞争关系来分析。
|
||||
|
||||
## 4. 评价框架：双目标达标 + 系统协同
|
||||
|
||||
### 4.1 人工智能目标负载指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 时效 | `TTFT`、`TPOT`、端到端响应时间 |
|
||||
| 有效性 | 精度、成功率、任务完成率、输出可用性 |
|
||||
| 稳定性 | 长时间运行退化、失败率、热漂移影响 |
|
||||
|
||||
### 4.2 关键保障负载指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 截止期 | `deadline miss ratio` |
|
||||
| 尾部行为 | `P99/P99.9 jitter`、观测最大响应时间 |
|
||||
| 外部接口 | GPIO / CAN / RS485 / 网络回路端到端响应 |
|
||||
|
||||
### 4.3 系统协同指标
|
||||
|
||||
| 类别 | 指标 |
|
||||
|---|---|
|
||||
| 效率 | 有效吞吐、拒绝率、恢复时间 |
|
||||
| 能效 | `E/token`、`tokens/J`、整机功耗 |
|
||||
| 稳定性 | 温度、降频时间比例、24 h 长稳表现 |
|
||||
| 公平性 | 多任务 / 多模型并发下的资源分配与隔离效果 |
|
||||
|
||||
因此，论文与实验的通过标准应统一为：
|
||||
|
||||
> **人工智能目标负载达标 + 关键保障负载达标 + 系统协同稳定。**
|
||||
|
||||
## 5. 准入机制
|
||||
|
||||
为了保证后续对照具有可信度，所有平台必须通过分阶段准入：
|
||||
|
||||
| 门槛 | 核心内容 |
|
||||
|---|---|
|
||||
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑正确 |
|
||||
| `G1` 测量准入 | 单调时钟、日志、功率计、外部测量链路 |
|
||||
| `G2` 加速器准入 | 驱动加载、最小算子、结果回读 |
|
||||
| `G3` 模型准入 | 模型转换、加载、推理、释放、重复运行 |
|
||||
| `G4` 混合负载准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
|
||||
|
||||
任何准入失败都要作为研究记录保留。
|
||||
|
||||
## 6. 对照原则
|
||||
|
||||
### 6.1 固定不变项
|
||||
|
||||
为了保证 OS 对照公平，以下变量必须冻结：
|
||||
|
||||
- 模型版本、量化格式、tokenizer、输入长度与输出长度；
|
||||
- CPU 核数量、优先级、内存预算、加速器数量；
|
||||
- 到达流、随机种子、预热时间、采样窗口；
|
||||
- 环境温度、散热、驱动与框架版本。
|
||||
|
||||
### 6.2 允许变化项
|
||||
|
||||
允许作为自变量扫描的内容包括：
|
||||
|
||||
- OS 类型与配置；
|
||||
- 调度策略与核隔离；
|
||||
- IRQ 亲和与中断线程化；
|
||||
- 内存限额、KV Cache 预分配与准入控制；
|
||||
- 功率与频率策略；
|
||||
- 并发度、到达率和背景干扰强度。
|
||||
|
||||
## 7. 建模与分析方法
|
||||
|
||||
### 7.1 调度分析
|
||||
|
||||
关键保障负载优先使用固定优先级与响应时间分析：
|
||||
|
||||
```
|
||||
R_i^(0) = C_i
|
||||
R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
- `C_i` 为关键保障任务的执行时间；
|
||||
- `T_j` 为高优先级任务周期；
|
||||
- `R_i` 为响应时间。
|
||||
|
||||
人工智能目标负载根据其服务目标与预算，被建模为：
|
||||
|
||||
- 可限流的服务任务；
|
||||
- 可准入的队列任务；
|
||||
- 可隔离的设备任务；
|
||||
- 必要时具有阶段性优先级的任务图。
|
||||
|
||||
### 7.2 容量与热稳定性分析
|
||||
|
||||
对人工智能目标负载，需要同时分析：
|
||||
|
||||
- 模型权重占用；
|
||||
- KV Cache 增长；
|
||||
- 中间激活与工作区；
|
||||
- 运行时与驱动保留区；
|
||||
- 温度导致的频率变化。
|
||||
|
||||
因此，容量与热是实时保障能否成立的前提条件。
|
||||
|
||||
### 7.3 消融分析
|
||||
|
||||
系统机制收益通过逐项消融来解释，例如：
|
||||
|
||||
1. 去掉 CPU 核隔离；
|
||||
2. 去掉 IRQ 亲和；
|
||||
3. 去掉内存预分配；
|
||||
4. 去掉推理准入控制；
|
||||
5. 去掉功耗感知策略。
|
||||
|
||||
每次只移除一个机制，观察双目标达标边界的变化。
|
||||
|
||||
## 8. 工具链
|
||||
|
||||
### 8.1 采样与追踪工具
|
||||
|
||||
| 类别 | 代表工具 |
|
||||
|---|---|
|
||||
| OS 追踪 | RTOS trace、ftrace、事件日志 |
|
||||
| 性能分析 | perf、设备 profiler、定制采样脚本 |
|
||||
| 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
|
||||
| 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
|
||||
|
||||
下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
|
||||
|
||||
| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
|
||||
|---|---|---|---|
|
||||
| 人工智能目标负载时效 | `TTFT`、`TPOT`、端到端响应时间 | 应用层时间戳、推理引擎日志、设备 profiler | 判断智能功能是否按服务时限完成 |
|
||||
| 人工智能目标负载有效性 | 精度、成功率、任务完成率、输出可用性 | 数据集回放脚本、结果校验脚本、业务判分程序 | 避免只优化时延而牺牲输出质量 |
|
||||
| 关键保障负载实时性 | `deadline miss ratio`、观测最大响应时间 | RTOS trace、GPIO 打点、示波器、逻辑分析仪 | 判断关键任务是否仍满足实时边界 |
|
||||
| 尾部抖动行为 | `P99/P99.9 jitter`、突发峰值延迟 | 高精度事件日志、外部时序测量、分位统计脚本 | 识别平均值掩盖下的尾部失稳 |
|
||||
| CPU 与调度行为 | 核占用、上下文切换、迁核、中断干扰 | perf、ftrace、调度事件日志 | 解释不同 OS 机制下的调度差异 |
|
||||
| 内存与容量行为 | 峰值内存、KV Cache 增长、分配失败率 | `/proc`、驱动日志、运行时统计、定制采样脚本 | 判断容量边界与动态分配抖动来源 |
|
||||
| 功率与热稳定性 | 整机功耗、芯片温度、降频时间比例 | 外部功率计、PDU、板载传感器、温度记录 | 判断长稳阶段是否因热或供电触发退化 |
|
||||
| I/O 与外设链路 | GPIO/CAN/RS485/网络回路时延 | 示波器、总线分析仪、抓包工具 | 验证系统外部闭环而非仅内部线程表现 |
|
||||
| 恢复与稳态行为 | 故障恢复时间、重试成功率、24 h 退化曲线 | 守护日志、错误注入脚本、长稳记录程序 | 判断系统是否具备工程可用性 |
|
||||
|
||||
### 8.2 理论与仿真工具
|
||||
|
||||
| 类别 | 作用 |
|
||||
|---|---|
|
||||
| RTA / WCET 分析 | 关键保障负载响应时间边界分析 |
|
||||
| 抽象仿真框架 | 参数扫描、到达流与机制对比 |
|
||||
| 架构级仿真 | 必要时验证拓扑与内存模型假设 |
|
||||
|
||||
这里的仿真用于机制理解、参数扫描与拓扑假设验证。
|
||||
主线验证平台为 **SylixOS 与其对照系统**。
|
||||
|
||||
## 9. 实验流程
|
||||
|
||||
统一实验流程如下：
|
||||
|
||||
1. 完成 `G0~G4` 准入；
|
||||
2. 建立 `O0/O1/O2/O3` 对照组；
|
||||
3. 先测空载与仅人工智能目标负载基线；
|
||||
4. 再测人工智能目标负载与关键保障负载并存场景；
|
||||
5. 加入 CPU / 内存 / I/O / 网络等伴生竞争负载；
|
||||
6. 进行长稳、突发、恢复与消融实验；
|
||||
7. 进行跨档位和跨部署形态对比。
|
||||
|
||||
## 10. 可复现性要求
|
||||
|
||||
每次运行至少保存以下元数据：
|
||||
|
||||
- 档位、设备编号、OS/BSP/驱动版本；
|
||||
- 模型校验值、量化格式、输入模板、随机种子；
|
||||
- CPU/IRQ/频率/内存配置；
|
||||
- 环境温度、散热方式、测量仪器；
|
||||
- 原始延迟、功率、温度与错误日志。
|
||||
|
||||
只有满足这些条件，后续论文中的“优势”才具备可外部讨论的基础。
|
||||
|
||||
## 11. 本文档在整个仓库中的作用
|
||||
|
||||
本文件负责回答三个问题：
|
||||
|
||||
1. **怎么保证研究对象始终落在 RTOS 平台层；**
|
||||
2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
|
||||
3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据。**
|
||||
|
||||
这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
|
||||
@@ -0,0 +1,33 @@
|
||||
# 研究框架索引
|
||||
|
||||
本目录放置项目的核心研究框架文档，说明研究对象、研究结构与具体优化切入方向。
|
||||
|
||||
## 阅读建议
|
||||
|
||||
1. `00-整体研究框架.md`
|
||||
2. `01-推理图任务调度.md`
|
||||
3. `02-KV-Cache与内存管理.md`
|
||||
4. `03-加速器协同调度.md`
|
||||
5. `04-量化精度感知调度.md`
|
||||
6. `05-中断与实时性保障.md`
|
||||
7. `06-能耗与热管理.md`
|
||||
8. `07-方法论与评估工具链.md`
|
||||
|
||||
## 文件说明
|
||||
|
||||
- `00-整体研究框架.md`
|
||||
- 研究总框架、问题空间、技术分层、预期成果
|
||||
- `01-推理图任务调度.md`
|
||||
- LLM 推理 DAG 拆解、任务映射与调度策略
|
||||
- `02-KV-Cache与内存管理.md`
|
||||
- KV Cache 生命周期、内存池、带宽竞争与局部性
|
||||
- `03-加速器协同调度.md`
|
||||
- CPU、NPU、GPU、DMA 等异构资源协同
|
||||
- `04-量化精度感知调度.md`
|
||||
- 精度、资源占用和调度决策的联动关系
|
||||
- `05-中断与实时性保障.md`
|
||||
- IRQ 路径、线程化、中断隔离与实时任务保护
|
||||
- `06-能耗与热管理.md`
|
||||
- 能耗约束、温度耦合、频率策略与热稳定性
|
||||
- `07-方法论与评估工具链.md`
|
||||
- 建模、仿真、原型验证和评估方法学
|
||||
@@ -0,0 +1,170 @@
|
||||
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
|
||||
|
||||
## 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；
|
||||
- **硬件角色**：验证矩阵。
|
||||
|
||||
## 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` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
|
||||
|
||||
## 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. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
|
||||
|
||||
这条顺序用于区分平台就绪性问题与系统机制边界问题。
|
||||
|
||||
## 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章 |
|
||||
|
||||
在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
|
||||
|
||||
## 10. 最终闭环
|
||||
|
||||
本研究形成的核心结论关系是：
|
||||
|
||||
> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
|
||||
|
||||
在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
|
||||
|
||||
- 研究对象清楚；
|
||||
- 验证矩阵完整；
|
||||
- 对照关系公平；
|
||||
- 评价框架统一；
|
||||
- 论文叙事和产业叙事都能站住。
|
||||
+213
-169
@@ -1,57 +1,82 @@
|
||||
# 基础设备配置（四层级 × 三档算力分级）
|
||||
# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
|
||||
|
||||
> 版本: v2.0 起草日期: 2026-09-18
|
||||
> 设计目标: 为翼辉 SylixOS 调度框架研究建立 **集群→桌面→边→端** 四级硬件体系，每级内再按 **低/中/高** 三档细分
|
||||
> 现有硬件全覆盖: T2-L（4×V100 SXM）+ T3-L / T4-H（RK3588 工业盒）| 需新增: T1 集群扩展 + 其余档位
|
||||
> 版本: v2.1 起草日期: 2026-09-21
|
||||
> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
|
||||
> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
|
||||
> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
|
||||
|
||||
---
|
||||
|
||||
## 0. 分级体系总览
|
||||
## 0. 场景、算力基础与设备档位总览
|
||||
|
||||
### 0.1 分级维度与分档规则
|
||||
### 0.1 研究框架与设备谱系的对应关系
|
||||
|
||||
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度——容量直接决定可承载的模型规模，且与功耗、散热、互联架构强相关，四个层级可连续衔接、无断层。
|
||||
研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
|
||||
本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
|
||||
这里完整呈现硬件与指标颗粒度，并明确：
|
||||
|
||||
> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
|
||||
|
||||
| 研究维度 | 定义 | 在本文件中的落地方式 |
|
||||
|---|---|---|
|
||||
| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
|
||||
| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
|
||||
| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
|
||||
|
||||
`T5~T1` 是用于实验组织的**部署形态代码**。
|
||||
这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
|
||||
后续实验中，这些档位分别承担的是：
|
||||
|
||||
- 人工智能目标负载在不同资源条件下的时效与有效性验证；
|
||||
- 关键保障负载在不同资源条件下的边界验证；
|
||||
- RTOS 在双目标约束下的机制有效性验证。
|
||||
|
||||
### 0.2 分级维度与分档规则
|
||||
|
||||
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
|
||||
|
||||
**分档规则**: 相邻两档的边界值归入**上界一侧**
|
||||
|
||||
| 层级 | 代码 | 低级 | 中级 | 高级 |
|
||||
| 部署形态 | 代码 | 代表档位 | 容量范围 | 说明 |
|
||||
| -------- | --- | --------------- | ---------------- | ---------------- |
|
||||
| **端级** | T4 | **1~2 G** | **2~4 G** | **4~8 G** |
|
||||
| **边级** | T3 | **8~16 G** | **16~32 G** | **32~64 G** |
|
||||
| **桌面级** | T2 | **64~128 G** | **128~256 G** | **256~512 G** |
|
||||
| **集群级** | T1 | **512 G~1 T** | —（不设中档） | **1 T~2 T** |
|
||||
| **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** | 多节点分布式推理 |
|
||||
|
||||
> 边界值归属示例: 8 GB → 端-高；16 GB → 边-低；64 GB → 边-高；128 GB → 桌-低；512 GB → 桌-高；1 TB → 集-低。
|
||||
> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
|
||||
|
||||
### 0.2 全谱系总表（11 个档位）
|
||||
### 0.3 全谱系总表（11 个档位）
|
||||
|
||||
> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。
|
||||
|
||||
| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 |
|
||||
| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- |
|
||||
| **T4-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | |
|
||||
| **T4-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | |
|
||||
| **T4-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 板降配） |
|
||||
| **T3-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 |
|
||||
| **T3-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | |
|
||||
| **T3-H** | 32~64 G | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | |
|
||||
| **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.3 设计原则
|
||||
### 0.4 设计原则
|
||||
|
||||
1. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
|
||||
2. **CUDA 栈贯通 T1/T2/T3**: 集群/桌面/边级全部或大部分走 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位无缝迁移，变量只有规模。
|
||||
3. **非 CUDA 端路线**: T4 全档位与 T3-L 走 RKNN/RKLLM NPU 栈，代表极致资源约束端点，是 RTOS 调度隔离价值最大化的场景。
|
||||
4. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T3-L 16GB / T4-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
|
||||
5. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2）与 ARM64（T3/T4），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
|
||||
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. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
|
||||
|
||||
### T1.1 定位
|
||||
|
||||
@@ -59,7 +84,7 @@
|
||||
|
||||
### T1.2 档位对比
|
||||
|
||||
| 维度 | T1-L 集群-低 | T1-H 集群-高 |
|
||||
| 维度 | T1-L 多节点-低 | T1-H 多节点-高 |
|
||||
| ----------- | --------------------- | --------------------------- |
|
||||
| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
|
||||
| **节点数** | 4 节点 | 4 节点 |
|
||||
@@ -71,11 +96,11 @@
|
||||
| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
|
||||
| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
|
||||
|
||||
#### T1.2.1 T1-L 集群-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
|
||||
#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
|
||||
|
||||
| 项目 | 规格 | 数量 | 备注 |
|
||||
| --------- | ------------------------------------------------ | ------------- | --------------------------- |
|
||||
| **计算节点** | 同 T2-L 桌面级配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
|
||||
| **计算节点** | 同 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 |
|
||||
@@ -107,11 +132,11 @@
|
||||
|
||||
> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
|
||||
|
||||
#### T1.2.2 T1-H 集群-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
|
||||
#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
|
||||
|
||||
| 项目 | 规格 | 数量 | 备注 |
|
||||
| ------- | ----------------------------------------- | --------- | --------------------- |
|
||||
| 计算节点 | 同 T2-H 桌面级配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
|
||||
| 计算节点 | 同 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 |
|
||||
@@ -150,7 +175,7 @@
|
||||
|
||||
---
|
||||
|
||||
## T2. 桌面级 — 64 G ~ 512 G
|
||||
## T2. 高算力单机部署形态 — 64 G ~ 512 G
|
||||
|
||||
### T2.1 定位
|
||||
|
||||
@@ -158,7 +183,7 @@
|
||||
|
||||
### T2.2 档位对比
|
||||
|
||||
| 维度 | T2-L 桌面-低 | T2-M 桌面-中 | T2-H 桌面-高 |
|
||||
| 维度 | 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 |
|
||||
@@ -171,7 +196,7 @@
|
||||
| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
|
||||
| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
|
||||
|
||||
#### T2.2.1 T2-L 桌面-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
|
||||
#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
|
||||
|
||||
| # | 部件 | 型号 / 规格 | 数量 | 备注 |
|
||||
| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
|
||||
@@ -213,7 +238,7 @@
|
||||
| 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.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
|
||||
|
||||
在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
|
||||
|
||||
@@ -241,7 +266,7 @@
|
||||
|
||||
> **备选方案**: 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
|
||||
#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
|
||||
|
||||
| 项目 | 规格 |
|
||||
| ------- | ---------------------------------------- |
|
||||
@@ -287,41 +312,72 @@
|
||||
|
||||
---
|
||||
|
||||
## T3. 边级 — 8 G ~ 64 G
|
||||
## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
|
||||
|
||||
### T3.1 定位
|
||||
|
||||
边缘 AI 推理与工业控制并发。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性——推理任务与实时控制任务共享内存带宽时的隔离能力。
|
||||
边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。
|
||||
它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
|
||||
|
||||
### T3.2 档位对比
|
||||
### T3.2 代表档位对比
|
||||
|
||||
| 维度 | T3-L 边-低 | T3-M 边-中 | T3-H 边-高 |
|
||||
| --------- | ---------------------------- | -------------------------- | ----------------------------- |
|
||||
| **容量** | 16 GB 统一内存 | 32 GB 统一内存 | 64 GB 统一内存 / 48 GB 独立显存 |
|
||||
| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA | AGX Orin 64GB / RTX 6000 Ada |
|
||||
| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) | 275 TOPS / 91 TFLOPS (FP16) |
|
||||
| **功耗** | 10~30 W | 15~60 W | 60~600 W |
|
||||
| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 | DC 19 V 或 ATX，风冷/液冷 |
|
||||
| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ | -25~80 ℃ / 0~50 ℃ |
|
||||
| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T4） | **高**（T234 BSP 需验证） | 高 / 中 |
|
||||
| **状态** | （RK3588 16GB 工业盒） | | |
|
||||
| 维度 | 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.2.1 T3-L 边-低 — RK3588 16GB 工业盒（现有设备）
|
||||
### T3.3 候选平台
|
||||
|
||||
**这是现有 RK3588 设备的标准归属档位**（16 GB 统一内存落在边级区间内），也是唯一可零成本立即开展研究的边级档位。
|
||||
- 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（同 T4-H） | SylixOS BSP 与 T4 共用 |
|
||||
| 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) | 与 T4 相同，是带宽瓶颈点 |
|
||||
| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T4-H 内存翻倍，可跑更大模型 |
|
||||
| 内存带宽 | ~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 打通**。代价是 SylixOS T234 BSP 风险高。
|
||||
**备选方案（同档位、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 风险高。
|
||||
|
||||
#### T3.2.2 T3-M 边-中 — NVIDIA Jetson AGX Orin 32GB
|
||||
#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | -------------------------------------------------- |
|
||||
@@ -352,76 +408,64 @@
|
||||
4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
|
||||
5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
|
||||
|
||||
#### T3.2.3 T3-H 边-高 — 64 GB 档（两条路线）
|
||||
#### T3 边缘节点候选平台
|
||||
|
||||
| 路线 | 主推 A: Jetson AGX Orin 64GB | 主推 B: 边缘工控机 + RTX 6000 Ada 48GB |
|
||||
| ---------- | -------------------------------- | -------------------------------- |
|
||||
| **架构** | ARM A78AE + Ampere GPU（统一内存） | x86 (Xeon/Core) + 独立 CUDA 显卡 |
|
||||
| **容量** | 64 GB LPDDR5（统一内存） | 48 GB GDDR6 ECC（独立显存） |
|
||||
| **算力** | 275 TOPS (INT8) | 91 TFLOPS (FP16) / 182 TFLOPS 稀疏 |
|
||||
| **功耗** | 15~60 W | 整机 ~600 W |
|
||||
| **散热** | 被动/主动风冷 | 主动风冷或液冷 |
|
||||
| **生态** | CUDA + DLA，与 T3-M 同 BSP | 完整 CUDA + NVLink 可选 |
|
||||
| **优势** | 能效极高、宽温、无风扇可行 | 算力密度高、显存带宽大、生态完整 |
|
||||
| **劣势** | 统一内存带宽仅 204.8 GB/s，带宽受限 | 功耗/体积/散热不适合现场部署 |
|
||||
| **适用场景** | 边缘现场、宽温环境、低功耗 | 边缘机柜、算力下沉、多模型并发 |
|
||||
64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
|
||||
|
||||
**可运行模型（T3 三档合并）**
|
||||
**可运行模型（T4 两档合并）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 |
|
||||
| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ |
|
||||
| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T3-L | RKLLM |
|
||||
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T3-L / T3-M | TensorRT-LLM / RKLLM |
|
||||
| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T3-L / T3-M | TensorRT-LLM / llama.cpp |
|
||||
| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T3-M | TensorRT-LLM |
|
||||
| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T3-M / T3-H | TensorRT-LLM |
|
||||
| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | ~5-8 | T3-H | TensorRT-LLM / vLLM |
|
||||
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T3-L 以上 | llama.cpp |
|
||||
| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T3-L 以上 | faster-whisper |
|
||||
| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T3 全档 | TensorRT / RKNN |
|
||||
| **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 |
|
||||
|
||||
### T3.3 SylixOS 要求（T3）
|
||||
### T4.3 SylixOS 要求（T4）
|
||||
|
||||
| 要求项 | 描述 | 风险 |
|
||||
| -------------------- | --------------------------------------- | ---------------------------- |
|
||||
| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
|
||||
| **RK3588 BSP（T3-L）** | 与 T4-H 共用同一 BSP，零额外风险 | **极低** |
|
||||
| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险 | **极低** |
|
||||
| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
|
||||
| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
|
||||
| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
|
||||
| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
|
||||
| 独立显存管理（T3-H B 路线） | x86 + 独显的显存分配与实时性 | 中 |
|
||||
| 独立显存管理（T3 B 路线） | x86 + 独显的显存分配与实时性 | 中 |
|
||||
|
||||
> **取舍**: Jetson 路线优势在 CUDA 生态统一 + 275 TOPS + DLA；RK3588-16GB（T3-L）优势在 SylixOS BSP 风险极低 + -40~60℃ 工业级宽温。**建议 T3-L 直接用现有 RK3588 起步，T3-M/H 待 Jetson BSP 确认后再采购。**
|
||||
> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
|
||||
|
||||
### T3.4 对照组 OS
|
||||
### T4.4 对照组 OS
|
||||
|
||||
| 档位 | 主对照 | 辅助对照 |
|
||||
| ---- | -------------------------------- | ----------------------------- |
|
||||
| T3-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
|
||||
| T3-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） |
|
||||
| T3-H | Ubuntu 22.04 + PREEMPT_RT（x86/ARM） | Docker + KVM |
|
||||
| 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（容器隔离方案） |
|
||||
|
||||
### T3.5 功率采集
|
||||
### T4.5 功率采集
|
||||
|
||||
| 设备 | 用途 | 适用档位 |
|
||||
| ----------------------------- | --------------------- | ----------- |
|
||||
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T3-L / T3-M |
|
||||
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T4-L / T4-M |
|
||||
| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
|
||||
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T3-M / T3-H |
|
||||
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-H B 路线 |
|
||||
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T4-M / T3-L |
|
||||
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-L B 路线 |
|
||||
|
||||
---
|
||||
|
||||
## T4. 端级 — 1 G ~ 8 G
|
||||
## T5. 控制端场景 — 1 G ~ 8 G
|
||||
|
||||
### T4.1 定位
|
||||
### T5.1 定位
|
||||
|
||||
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这是 RTOS 杀手锏场景——资源越紧张，RTOS 调度隔离的价值越大。
|
||||
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
|
||||
|
||||
### T4.2 档位对比
|
||||
### T5.2 档位对比
|
||||
|
||||
| 维度 | T4-L 端-低 | T4-M 端-中 | T4-H 端-高 |
|
||||
| 维度 | 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 |
|
||||
@@ -433,7 +477,7 @@
|
||||
| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
|
||||
| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
|
||||
|
||||
#### T4.2.1 T4-L 端-低 — RK3568 核心板（1~2 GB）
|
||||
#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | -------------------------------------- |
|
||||
@@ -452,9 +496,9 @@
|
||||
| 参考价格 | ~300~800 RMB（核心板/开发板） |
|
||||
|
||||
**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
|
||||
**定位价值**: 谱系最低档，用于测出「LLM 推理到底能把实时性压到多差」的**下界**，以及 RTOS 在极小内存下能否守住 1ms。
|
||||
**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
|
||||
|
||||
#### T4.2.2 T4-M 端-中 — RK3576 核心板（2~4 GB）
|
||||
#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
|
||||
|
||||
| 项目 | 规格 |
|
||||
| --------- | ---------------------------------------- |
|
||||
@@ -468,9 +512,9 @@
|
||||
| 参考价格 | ~600~1,500 RMB |
|
||||
|
||||
**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
|
||||
**定位价值**: 端级主力档，算力是 T4-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
|
||||
**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
|
||||
|
||||
#### T4.2.3 T4-H 端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
|
||||
#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
|
||||
|
||||
**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
|
||||
|
||||
@@ -482,12 +526,12 @@
|
||||
| GPU | Mali-G610 MC4 | 仅辅助显示 |
|
||||
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
|
||||
| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
|
||||
| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T3-L 同 |
|
||||
| 内存带宽 | ~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 工业盒的双档位用法**: 同一台设备既可作为 **T3-L（16 GB 全量）** 也可作为 **T4-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
|
||||
> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
|
||||
|
||||
**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
|
||||
|
||||
@@ -497,11 +541,11 @@
|
||||
| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
|
||||
| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
|
||||
| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
|
||||
| 优势 | **T4 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3-M 同栈 |
|
||||
| 优势 | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
|
||||
| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
|
||||
| 参考价格 | ~$249（开发套件） |
|
||||
|
||||
**可运行模型（T4-H）**
|
||||
**可运行模型（T5-H）**
|
||||
|
||||
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
|
||||
| ------------------------- | ---- | ------- | ----------- | ----- |
|
||||
@@ -510,7 +554,7 @@
|
||||
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
|
||||
| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
|
||||
|
||||
#### T4.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
|
||||
#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
|
||||
|
||||
**系统 (System)**
|
||||
|
||||
@@ -521,7 +565,7 @@
|
||||
| MCU | Cortex-M0 @200 MHz（协处理，可选） |
|
||||
| GPU | Mali-G610 MC4 |
|
||||
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
|
||||
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T4-H |
|
||||
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H |
|
||||
| **显存** | 统一内存（NPU 与 CPU 共享） |
|
||||
|
||||
**存储 / 扩展**
|
||||
@@ -533,9 +577,9 @@
|
||||
**出厂软件**
|
||||
|
||||
- 操作系统: **Ubuntu 22.04**（出厂预装）
|
||||
- 验证方案: 替换为 SylixOS BSP for RK3588，保留 Ubuntu 22.04 作为对照组
|
||||
- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
|
||||
|
||||
**算力与功耗（T4-H 档）**
|
||||
**算力与功耗（T5-H 档）**
|
||||
|
||||
| 指标 | 值 |
|
||||
| ------------------ | ------------------------------- |
|
||||
@@ -546,28 +590,28 @@
|
||||
| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
|
||||
| **TDP** | **7~21 W**（无风扇被动散热） |
|
||||
|
||||
### T4.3 SylixOS 要求（T4）
|
||||
### T5.3 SylixOS 要求（T5）
|
||||
|
||||
| 要求项 | 描述 | 风险 | 适用档位 |
|
||||
| ---------------------- | --------------------------------------- | -------------------- | --------- |
|
||||
| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T4-H |
|
||||
| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T4-M |
|
||||
| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T4-L |
|
||||
| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T4 全档 |
|
||||
| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T4-H |
|
||||
| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T4-H |
|
||||
| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T3-L/T4-H 切换） | 中（需 SylixOS 内存域支持） | T4-H |
|
||||
| CAN ×2 驱动 | 工业现场总线 | 中 | T4 全档 |
|
||||
| RS485 ×2 + RS232 ×1 | 串口 | 低 | T4 全档 |
|
||||
| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T4-H |
|
||||
| 看门狗 / RTC | 工业可靠性 | 低 | T4 全档 |
|
||||
| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T4-H 路线B |
|
||||
| **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 |
|
||||
|
||||
### T4.4 对照组 OS
|
||||
### T5.4 对照组 OS
|
||||
|
||||
- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
|
||||
- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
|
||||
- T4-L / T4-M: Buildroot + PREEMPT_RT
|
||||
- T5-L / T5-M: Buildroot + PREEMPT_RT
|
||||
|
||||
---
|
||||
|
||||
@@ -577,12 +621,12 @@
|
||||
|
||||
| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 |
|
||||
| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- |
|
||||
| **T4-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 |
|
||||
| **T4-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 |
|
||||
| **T4-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） |
|
||||
| **T3-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） |
|
||||
| **T3-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** |
|
||||
| **T3-H** | 32~64 GB | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 |
|
||||
| **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 | 中 |
|
||||
@@ -593,12 +637,12 @@
|
||||
|
||||
| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
|
||||
| -------- | --------------------------- | ---------- | ------- | -------------- |
|
||||
| T4-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 谱系下界，实时性基准 |
|
||||
| T4-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 端级能效拐点 |
|
||||
| T4-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B |
|
||||
| T3-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 边缘推理 + 工业控制 |
|
||||
| T3-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 边缘多模型并发 |
|
||||
| T3-H | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘可跑 72B |
|
||||
| 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 | 桌面单机超大模型 |
|
||||
@@ -609,12 +653,12 @@
|
||||
|
||||
| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
|
||||
| ----- | ----------- | ---------------------------------- | -------------------------- |
|
||||
| T4-L | 极小内存下保号 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 |
|
||||
| T4-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token |
|
||||
| T4-H | 极致资源约束下保号 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token |
|
||||
| T3-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s |
|
||||
| T3-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 |
|
||||
| T3-H | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS |
|
||||
| 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 分片吞吐 |
|
||||
@@ -623,14 +667,14 @@
|
||||
|
||||
### 5.4 基线 OS 对照
|
||||
|
||||
| 档位 | SylixOS 实验组 | 主对照 (Linux RT) | 虚拟化对照 | 容器对照 |
|
||||
| 档位 | SylixOS 实验组 | 主对照 (PREEMPT_RT Linux) | 虚拟化对照 | 容器对照 |
|
||||
| ------- | ---------------------- | --------------------- | -------------- | --------- |
|
||||
| T4-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker |
|
||||
| T4-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker |
|
||||
| T4-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T3-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| T3-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker |
|
||||
| T3-H | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||
| 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 |
|
||||
@@ -642,22 +686,22 @@
|
||||
|
||||
| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
|
||||
| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
|
||||
| **P0** | T3-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
|
||||
| **P0** | T4-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
|
||||
| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 |
|
||||
| **P0** | T4-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T3-L 同机双档位 |
|
||||
| **P1** | T4-L | RK3568 1~2GB 核心板 | ~300-800 | 谱系下界，必做 |
|
||||
| **P1** | T4-M | RK3576 4GB 核心板 | ~600-1,500 | 端级能效拐点 |
|
||||
| **P1** | T3-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP |
|
||||
| **P2** | T3-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 |
|
||||
| **P2** | T3-H | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘可跑 72B |
|
||||
| **P2** | T4-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 |
|
||||
| **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 (T3+T4) | ~6,000 | T4 强制 |
|
||||
| — | 仪器 | INA226 采集板 ×2 | ~500 | T3+T4 |
|
||||
| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3-H / T2 档 |
|
||||
| — | 仪器 | 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 总线延迟（可借用） |
|
||||
@@ -665,11 +709,11 @@
|
||||
|
||||
### 降本策略
|
||||
|
||||
1. **P0 零成本起步**: T2-L + T3-L + T4-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
|
||||
2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T3-L（16 GB）与 T4-H（8 GB），省去一台设备与一套 BSP 验证成本。
|
||||
3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T4-M 若 RK3576 BSP 不可用，用 T4-H 降配替代），谱系不断。
|
||||
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. **T3-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
|
||||
5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
|
||||
6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
|
||||
|
||||
---
|
||||
@@ -693,7 +737,7 @@
|
||||
- [ ] tickless + CPU 隔离 + 中断亲和性
|
||||
- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
|
||||
|
||||
### 7.2 ARM64 BSP — T234 / Ampere（T3-M / T3-H-A / T4-H 路线B）
|
||||
### 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）
|
||||
@@ -706,11 +750,11 @@
|
||||
- [ ] PCIe Gen4 扩展
|
||||
- [ ] 温度传感器 + 降频阈值
|
||||
|
||||
### 7.3 ARM64 BSP — RK3588（T4-H / T3-L）
|
||||
### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
|
||||
|
||||
- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
|
||||
- [ ] CPU 频率独立调节 (governor)
|
||||
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T3-L ↔ T4-H 切换）
|
||||
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
|
||||
- [ ] tickless / idle hook
|
||||
- [ ] 看门狗驱动
|
||||
- [ ] **rknn / RKLLM NPU 驱动**（核心）
|
||||
@@ -723,7 +767,7 @@
|
||||
- [ ] HDMI 输出（调试）
|
||||
- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
|
||||
|
||||
### 7.4 ARM64 BSP — RK3576（T4-M）
|
||||
### 7.4 ARM64 BSP — RK3576（T5-M）
|
||||
|
||||
- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
|
||||
- [ ] 6 TOPS NPU 驱动（RKNN 栈）
|
||||
@@ -731,7 +775,7 @@
|
||||
- [ ] CAN / RS485 / 千兆网络驱动
|
||||
- [ ] 低功耗被动散热下的频率/温度联动
|
||||
|
||||
### 7.5 ARM64 BSP — RK3568（T4-L）
|
||||
### 7.5 ARM64 BSP — RK3568（T5-L）
|
||||
|
||||
- [ ] SylixOS BSP for RK3568（4×A55 SMP）
|
||||
- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
|
||||
@@ -1,35 +1,35 @@
|
||||
# SylixOS 混合实时任务与 AI 推理实验设计
|
||||
# SylixOS 任务关键系统中人工智能目标负载实验设计
|
||||
|
||||
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](../基础设备.md)，扩展自[原实验设计](../实验设计.md)。
|
||||
> 本文给出待执行方案，不代表已有测试结果。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
|
||||
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
|
||||
> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
|
||||
|
||||
## 1. 研究目标与实验范围
|
||||
|
||||
研究问题是：在端、边、桌面、集群不同资源条件下，SylixOS 的调度与资源隔离能否在保持实时任务截止期的同时，提高 AI 推理服务的有效吞吐和能效？
|
||||
本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
|
||||
|
||||
| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
|
||||
|---|---|---|---|
|
||||
| RQ1：混合负载下的实时性 | OS、调度策略、干扰强度 | 唤醒延迟、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
|
||||
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | P99.9 延迟、有效吞吐、拒绝率 | 默认、完整方案与逐项消融 |
|
||||
| RQ3：功耗预算下的运行能力 | 频率、空闲策略、推理并发 | J/token、温度、违约率 | 满足同一服务质量约束的配置比较 |
|
||||
| RQ4：规模扩展后的瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
|
||||
| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
|
||||
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
|
||||
| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
|
||||
| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
|
||||
|
||||
执行分为两层：**核心实验使用现有 T2-L、T3-L 和 T4-H 内存受限配置；其他八档属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM 是主负载，YOLO 检测和语音识别是可选混合负载；训练不纳入主实验。
|
||||
执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
|
||||
|
||||
## 2. 设备分层与实验平台
|
||||
|
||||
### 2.1 四层级、十一档实验映射
|
||||
### 2.1 T5~T1 五类部署形态、十一档实验映射
|
||||
|
||||
沿用设备文档的档位标签，实际容量单列。设备文档中“512 GB 边界归桌面高档”与“512 GB 集群标为 T1-L”存在口径差异；本文按多节点架构将该集群记为 T1-L，不据容量边界推导性能。
|
||||
沿用设备文档的档位标签，实际容量单列。多节点架构统一记为 `T1-L`，容量边界单独记录，不据容量直接推导性能。
|
||||
|
||||
| 层级与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
|
||||
| 部署形态与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
|
||||
|---|---|---|---|
|
||||
| T4-L 端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
|
||||
| T4-M 端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
|
||||
| T4-H 端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
|
||||
| T3-L 边低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
|
||||
| T3-M 边中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
|
||||
| T3-H 边高 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 |
|
||||
| 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 | 待获取或租用 | 高算力密度、跨代对照 |
|
||||
@@ -50,9 +50,9 @@ GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一
|
||||
|
||||
依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
|
||||
|
||||
- B16：全量 16 GB，记为 T3-L。
|
||||
- B8：同板施加 8 GB 限额，记为 T4-H 受限配置；两种配置顺序运行。
|
||||
- 原生 NPU 是首轮路径；所谓“6+26 TOPS”仅为设备文档中的组合标称。扩展芯片型号、连接方式、模型格式和任务拆分能力通过后，才增加独立对照，不假定两者能共同加速同一 LLM。
|
||||
- B16：全量 16 GB，记为 T4-L。
|
||||
- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
|
||||
- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
|
||||
- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
|
||||
|
||||
**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
|
||||
@@ -81,9 +81,9 @@ GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一
|
||||
| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
|
||||
| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
|
||||
|
||||
SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用。设备文档列出的软件栈均按候选路线处理，冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后再比较。
|
||||
SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
|
||||
|
||||
若仅能采用“SylixOS 实时域 + Linux 推理域”，应作为单独的异构系统架构组，注明核分配、通信和内存共享方式。该结果不能写成 SylixOS 原生 GPU/NPU 推理结论。
|
||||
“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
|
||||
|
||||
### 3.2 模型梯度与用途
|
||||
|
||||
@@ -96,7 +96,7 @@ SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用
|
||||
| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
|
||||
| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
|
||||
|
||||
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。原稿中的 tokens/s、FPS、内存估计作为待验证参考，不作为已知性能。
|
||||
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
|
||||
|
||||
### 3.3 输入与正确性控制
|
||||
|
||||
@@ -150,10 +150,10 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
|
||||
| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
|
||||
| O2 | SylixOS 默认配置 | 原生系统基线 |
|
||||
| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
|
||||
| O4 | Linux RT 等预算调优 | 避免仅一侧调优造成偏差 |
|
||||
| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
|
||||
| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
|
||||
|
||||
平台 B 原稿列出的出厂 Ubuntu 22.04 先核对镜像；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，明确区分“OS 调度效应”与“系统方案效应”。
|
||||
平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
|
||||
|
||||
### 5.2 配置控制与消融
|
||||
|
||||
@@ -169,20 +169,20 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
|
||||
|
||||
任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
|
||||
|
||||
### 6.2 背景干扰与推理到达
|
||||
### 6.2 伴生竞争负载与推理到达
|
||||
|
||||
| 场景 | 内容 | 目的 |
|
||||
|---|---|---|
|
||||
| L0 | 仅 RT | 实时性下界与测量开销 |
|
||||
| L1 | 仅推理 | 最大可持续服务能力与独立能耗 |
|
||||
| L2 | RT + LLM | 核心混合场景 |
|
||||
| L3 | L2 + CPU 干扰 | 参考占用 25/50/75/100%，注明施加核心 |
|
||||
| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
|
||||
| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
|
||||
| L2 | 关键保障负载 + LLM | 核心双目标场景 |
|
||||
| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
|
||||
| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
|
||||
| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务干扰 |
|
||||
| L6 | RT + LLM + YOLO（可选） | 多模型竞争与优先级影响 |
|
||||
| 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。不得各组按自身吞吐重新归一化后声称承受相同负载。
|
||||
人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
|
||||
|
||||
突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
|
||||
|
||||
@@ -238,7 +238,7 @@ T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的
|
||||
|
||||
## 9. 验收与结果判断
|
||||
|
||||
验收分为“数据可用”“系统约束满足”和“研究假设得到支持”，避免将目标写成已取得结果。
|
||||
验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
|
||||
|
||||
| 类型 | 判据 | 说明 |
|
||||
|---|---|---|
|
||||
@@ -249,7 +249,7 @@ T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的
|
||||
| 能耗收益 | 满足相同实时和推理约束时降低 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 数值同样不直接作为跨配置统一验收值。
|
||||
当前候选阈值包括“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. 数据产物与论文图表
|
||||
|
||||
@@ -0,0 +1,450 @@
|
||||
# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
|
||||
|
||||
> **版本**: 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 硬件层 → 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 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.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 优势；资源充裕且目标偏纯吞吐时，优势可能收窄 | 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 (相关工作), §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 | 与第三方文章配置一致, 可比性最高 |
|
||||
|
||||
---
|
||||
@@ -0,0 +1,24 @@
|
||||
# 实验与规划索引
|
||||
|
||||
本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
|
||||
|
||||
## 阅读建议
|
||||
|
||||
1. `01-研究逻辑说明.md`
|
||||
2. `02-基础设备与算力基础.md`
|
||||
3. `03-实验设计.md`
|
||||
4. `04-论文写作规划.md`
|
||||
5. `05-论文结构总览.png`
|
||||
|
||||
## 文件说明
|
||||
|
||||
- `01-研究逻辑说明.md`
|
||||
- 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
|
||||
- `02-基础设备与算力基础.md`
|
||||
- T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
|
||||
- `03-实验设计.md`
|
||||
- 准入条件、对照原则、混合负载场景、指标与验收方法
|
||||
- `04-论文写作规划.md`
|
||||
- 论文结构、章节分工、图表规划和证据映射
|
||||
- `05-论文结构总览.png`
|
||||
- 文章结构与逻辑关系示意图
|
||||
@@ -0,0 +1,21 @@
|
||||
# 联合研究方索引
|
||||
|
||||
本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
|
||||
|
||||
## 当前内容
|
||||
|
||||
- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
|
||||
- 面向项目内部的合作设想文档
|
||||
- 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
|
||||
- `罗蕾教授资料/`
|
||||
- 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
|
||||
- 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
|
||||
- `翼辉信息资料/`
|
||||
- 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
|
||||
- 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 对外沟通时，可先阅读人物概览与科研路径两篇。
|
||||
- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
|
||||
- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。
|
||||
@@ -0,0 +1,194 @@
|
||||
# 潜在合作研究路径：罗蕾教授与翼辉信息
|
||||
|
||||
> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
|
||||
|
||||
## 1. 两个合作方的协同结构
|
||||
|
||||
本项目对应的是一个典型的“**学术问题定义 + 系统机制设计 + 产业平台验证**”三段式问题：
|
||||
|
||||
1. 需要有人把研究问题定义清楚，并把方法学、可调度性分析、评价体系和论文表达做扎实；
|
||||
2. 需要有人把 RTOS 机制、工具链、BSP、系统实现和真实行业场景接起来；
|
||||
3. 需要把两者合成一个既能发表、又能落地、还能与产业沟通的闭环。
|
||||
|
||||
在这个结构里，罗蕾教授与翼辉信息的优势方向并不相同，但恰好可以形成互补：
|
||||
|
||||
- **罗蕾教授**作为电子科技大学相关领域广受尊重的知名专家学者，更适合承担研究方法、系统建模、学术组织与标准化表达这一侧；
|
||||
- **翼辉信息**作为大型实时操作系统与基础软件平台领域极具代表性的产业样本，更适合承担 SylixOS 平台、工程实现、场景验证与产业落地这一侧。
|
||||
|
||||
合作路径可以让两个合作方分别占据研究闭环中的不同位置。
|
||||
|
||||
## 2. 罗蕾教授更适合承担的合作角色
|
||||
|
||||
基于其长期研究积累与代表成果，罗蕾教授更适合在下面几个方向发挥作用：
|
||||
|
||||
### 2.1 研究问题与方法学共建
|
||||
|
||||
罗蕾教授长期积累的重点在嵌入式实时操作系统、可调度性分析、汽车电子基础软件、安全隔离与系统工程化。这位在相关领域享有较高声誉的专家学者，尤其适合参与：
|
||||
|
||||
- 研究问题的学术化表述；
|
||||
- `RQ1~RQ4` 的研究问题拆解；
|
||||
- `O0/O1/O2/O3` 对照逻辑的合理性论证；
|
||||
- `TTFT/TPOT + deadline miss + jitter + 系统协同` 这套双目标指标体系的学术组织；
|
||||
- 长稳、突发、恢复、消融等实验类型的论文化组织。
|
||||
|
||||
罗蕾教授更适合帮助项目把工程现象组织成可发表的系统研究问题。
|
||||
|
||||
### 2.2 系统建模与分析工具链
|
||||
|
||||
罗蕾教授在实时系统建模、AADL 可调度性分析、AUTOSAR 任务映射、隔离保护等方向已有持续积累，因此她适合参与：
|
||||
|
||||
- 关键保障负载的任务模型抽象；
|
||||
- 人工智能目标负载进入系统后的实时约束建模；
|
||||
- 基于 `RTA/WCET` 的边界分析；
|
||||
- 任务映射、优先级分配、资源预算与配额约束的分析框架；
|
||||
- 从实验结果回推系统机制成立条件的理论解释。
|
||||
|
||||
这一部分做扎实后，项目可以形成“机制 - 结果 - 边界”三位一体的研究结构。
|
||||
|
||||
### 2.3 学术产出与标准化表达
|
||||
|
||||
罗蕾教授长期处在“研究 - 标准 - 产业化”打通的路径上，因此她也适合参与：
|
||||
|
||||
- 论文结构与贡献凝练；
|
||||
- 学术报告和项目申报材料；
|
||||
- 将系统机制抽象为可推广的方法学；
|
||||
- 后续延伸到行业测试规范或联合白皮书时，可协助形成更规范的表达。
|
||||
|
||||
## 3. 翼辉信息更适合承担的合作角色
|
||||
|
||||
翼辉信息的价值首先体现在其所代表的 **SylixOS 大型跨平台实时操作系统平台** 与行业落地经验。作为国内 RTOS 与关键基础软件方向颇具代表性的企业样本，翼辉信息在合作设想中具备很高的参考价值。
|
||||
|
||||
### 3.1 主实验样例与平台能力提供方
|
||||
|
||||
翼辉信息最适合承担的第一角色，是 `SylixOS` 主实验样例的提供与支撑，包括：
|
||||
|
||||
- SylixOS 版本、配置、调度参数与机制能力说明；
|
||||
- BSP、驱动、工具链、trace/观测接口支持；
|
||||
- SMP、多核绑定、中断治理、内存锁定、隔离机制等平台能力验证；
|
||||
- 针对任务关键系统场景的默认配置与优化配置对照。
|
||||
|
||||
这一部分决定了项目能否把“研究对象”落实到一套可验证的 RTOS 平台上。
|
||||
|
||||
### 3.2 工程实现与系统机制落地
|
||||
|
||||
翼辉信息也适合参与系统机制层的实现与验证，例如：
|
||||
|
||||
- 人工智能目标负载与关键保障负载的优先级/配额治理；
|
||||
- 核隔离、IRQ 亲和、设备中断分流；
|
||||
- KV Cache、内存池、DMA/I/O 路径的系统治理；
|
||||
- 长稳运行、恢复策略、故障隔离和资源回收机制；
|
||||
- 不同部署形态下的实际可部署方案。
|
||||
|
||||
这部分决定了项目能否从“方法论文档”走到“工程上真的成立”。
|
||||
|
||||
### 3.3 行业场景与产业验证语境
|
||||
|
||||
翼辉信息长期服务于航天、轨道交通、电力、工业自动化、智能汽车等任务关键行业，因此它更适合提供：
|
||||
|
||||
- 任务关键系统的真实负载语境；
|
||||
- 典型关键保障任务模板；
|
||||
- 更贴近行业的干扰链路和恢复要求；
|
||||
- 对“结果是否具有产业解释力”的判断。
|
||||
|
||||
这一部分非常重要，因为它会决定研究结果是不是只在实验室里成立。
|
||||
|
||||
## 4. 三方合作的分工结构
|
||||
|
||||
本项目可按“三方闭环”来组织：
|
||||
|
||||
- **罗蕾教授侧**：负责研究问题定义、系统建模、方法学审阅、论文组织与学术表达增强；
|
||||
- **翼辉信息侧**：负责 SylixOS 平台支撑、机制实现接口、工程验证条件与产业场景输入；
|
||||
- **我们项目组**：负责前期调研、实验执行、资料整理、跨平台对照实现与协同支撑。
|
||||
|
||||
可以把它理解成下面这条链路：
|
||||
|
||||
`研究问题定义 -> 方法学与分析框架 -> RTOS 机制实现 -> 实验验证 -> 论文与白皮书表达`
|
||||
|
||||
其中：
|
||||
|
||||
- 罗蕾教授更靠前半段和总结抽象；
|
||||
- 翼辉信息更靠中间实现与后端产业验证；
|
||||
- 项目组负责根据合作方的方向与建议，把实验推进、资料整合和执行工作衔接起来。
|
||||
|
||||
## 5. 可优先推进的合作研究主题
|
||||
|
||||
合作讨论可以优先围绕下面几类题目推进：
|
||||
|
||||
### 5.1 双目标实时保障基准共建
|
||||
|
||||
目标：
|
||||
|
||||
- 联合定义一套面向任务关键系统的 AI 目标负载 + 关键保障负载基准；
|
||||
- 统一 `TTFT/TPOT`、`deadline miss`、`P99/P99.9 jitter`、`E/token` 等指标；
|
||||
- 明确 `G0~G4` 准入和 `O0~O4` 对照逻辑。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧负责方法学与指标体系合理性；
|
||||
- 翼辉信息侧负责 SylixOS 落地和观测手段；
|
||||
- 项目组负责实验编排、数据整理和协同落实。
|
||||
|
||||
### 5.2 任务关键系统中的 AI 负载准入与隔离机制
|
||||
|
||||
目标：
|
||||
|
||||
- 研究人工智能目标负载进入系统后，如何通过配额、优先级、核绑定、时间预算、内存预算等机制维持关键保障任务边界；
|
||||
- 给出“哪些条件下准入、哪些条件下拒绝、哪些条件下需要降级运行”的规则。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧偏规则建模和边界分析；
|
||||
- 翼辉信息侧偏机制实现和可部署性验证。
|
||||
|
||||
### 5.3 面向实际行业场景的 SylixOS 机制验证
|
||||
|
||||
目标：
|
||||
|
||||
- 选择 1~2 个更贴近行业的关键场景，如工业控制、车载控制、边缘智能节点；
|
||||
- 把实验从抽象负载推进到“有行业解释力”的场景负载。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 翼辉信息侧提供场景输入和系统约束；
|
||||
- 罗蕾教授侧帮助把场景抽象成学术上可论证的问题。
|
||||
|
||||
### 5.4 联合论文 / 白皮书 / 申报材料
|
||||
|
||||
目标：
|
||||
|
||||
- 学术上形成论文；
|
||||
- 产业上形成白皮书或联合研究说明；
|
||||
- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
|
||||
|
||||
更适合的分工：
|
||||
|
||||
- 罗蕾教授侧偏学术与规范表达；
|
||||
- 翼辉信息侧偏产业价值、案例与平台能力；
|
||||
- 项目组承担材料汇总、写作配合与整合支撑。
|
||||
|
||||
## 6. 更现实的推进顺序
|
||||
|
||||
推进顺序以稳妥、小步、可验证为宜：
|
||||
|
||||
1. **先分别沟通**：确认双方对课题定位、研究边界、合作兴趣是否一致；
|
||||
2. **先小后大**：先围绕一个具体问题试合作，例如基准设计、实验审阅或场景讨论；
|
||||
3. **先方法后平台**：先把研究问题和方法学框架对齐，再谈平台实现细节；
|
||||
4. **先形成最小闭环**：先做出一版可验证的实验与分析，再决定是否扩展成正式联合研究。
|
||||
|
||||
## 7. 当前文档使用边界
|
||||
|
||||
这份文档当前更适合作为：
|
||||
|
||||
- 项目内部筹划材料；
|
||||
- 对外沟通前的思路整理；
|
||||
- 预判双方合作接口是否互补的参考稿。
|
||||
|
||||
当前使用场景包括：
|
||||
|
||||
- 项目内部筹划与分工设计；
|
||||
- 对外沟通前的内容准备；
|
||||
- 合作接口与协同结构的前期梳理。
|
||||
|
||||
这份文档回答的是：
|
||||
|
||||
> **与罗蕾教授、翼辉信息形成联合研究时，最合理的合作结构是什么。**
|
||||
@@ -0,0 +1,18 @@
|
||||
# 罗蕾教授人物概览
|
||||
|
||||
罗蕾教授是电子科技大学教授、博士生导师，长期在电子科技大学从事嵌入式基础软件相关教学、科研与产业化工作。她曾任嵌入式软件工程中心主任，持续聚焦嵌入式操作系统、物联网网络安全与数据安全、工业软件、智能计算等方向，是电子科技大学在嵌入式系统与相关产业应用领域具有较高影响力、广受尊重的知名专家学者。
|
||||
|
||||
罗蕾教授与电子科技大学保持了长期稳定的学术关联。她于 1987 年毕业于电子科技大学计算机系，1996 年晋升副教授，2003 年评为教授，2005 年晋升博士生导师。她既是学校本土培养起来的教师，也长期参与了学科建设、课程建设与团队建设。
|
||||
|
||||
罗蕾教授的工作范围已经超出了传统高校教师的单一角色。她曾作为国家“核高基”专家参与智能手机、汽车电子、数字电视等多项嵌入式基础软件重大专项实施，同时担任国家智能网联汽车创新中心专家、车载信息服务产业应用联盟（TIAA）网络安全委员会秘书长、工信部区块链技术与数据安全重点实验室相关专家等职务。她的工作位置也因此横跨了高校、重大专项、行业联盟和产业协同几个层面。
|
||||
|
||||
罗蕾教授的研究主线是一条逐步扩展的“底层软件到行业场景”的路线。较早阶段，她的工作更多与嵌入式实时操作系统、嵌入式基础软件和开发工具有关；随后逐步延伸到汽车电子、物联网安全、移动支付、区块链与数据安全，再到今天更强调工业软件、网络安全和智能计算。这种演进很有代表性，反映出她的研究沿着产业需求不断外扩。
|
||||
|
||||
罗蕾教授是一位具有明显“工程化导向”和产业连接能力、在相关领域享有较高声誉的知名专家学者。她既有学校内部的学术与教学身份，也深度参与国家项目、行业标准和企业合作；既关注嵌入式系统的底层技术，又把研究延伸到汽车、支付、数据安全等具体行业。她的个人画像体现出“学术研究者 + 工程组织者 + 产业连接者”的复合型角色。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
|
||||
3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
|
||||
@@ -0,0 +1,20 @@
|
||||
# 罗蕾教授的教学与人才培养工作
|
||||
|
||||
罗蕾教授不仅是一位在嵌入式系统领域具有较高影响力的专家学者，也长期深度投入教学工作。她的教学工作有一个很明显的特点：围绕一门核心课程，把教材、实验、课程资源和人才培养体系连在一起。
|
||||
|
||||
最能代表这一点的课程，是《嵌入式系统及应用》。这门课早在 2007 年就获得国家精品课程认定，之后又先后成为四川省精品资源共享课、四川省精品在线开放课程，并在 2023 年获得国家级一流本科课程认定。它是一门经过多年迭代、持续建设的核心课程。
|
||||
|
||||
这门课是一门典型的工程化课程。课程内容覆盖嵌入式系统导论、ARM 体系结构与编程、嵌入式软件系统、任务管理与调度、同步互斥与通信、中断时间和内存管理等主题，并配有 ARM 实验和 uC/OS-II 操作系统实验。课程结构采用“原理 + 实验 + 开发能力”的组织方式，目标是让学生真正进入嵌入式系统开发。
|
||||
|
||||
罗蕾教授在教学上的另一个特点，是把教材建设和课程建设配套推进。她主编过《嵌入式实时操作系统及应用开发》第一、二、三版，以及《嵌入式系统及应用》等著作。对一门工科课程来说，教材是否成体系，往往决定了课程能否长期稳定传承；她也由此搭建起一个可复制、可持续的知识框架。
|
||||
|
||||
罗蕾教授的人才培养方向也比较清晰。她指导的软件工程、电子信息等学位点，研究方向主要包括嵌入式软件技术与应用、工业软件、网络安全、智能计算等。这些方向既有传统的嵌入式系统主线，也对接了当下工业软件和安全计算的需求。她的人才培养模式强调“从基础软件出发，向新应用场景延展”。
|
||||
|
||||
罗蕾教授在教学上的重要性，体现在她于电子科技大学长期建设出了一套有工程背景、有实验支持、有教材配套、能持续培养学生的嵌入式教学体系。这也是这位知名专家学者在校内外形成广泛学术影响力的重要来源之一。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学计算机学院教学成果页：<https://www.scse.uestc.edu.cn/info/1039/10809.htm>
|
||||
3. 中国大学 MOOC《嵌入式系统及应用》课程页：<https://www.icourse163.org/course/UESTC-1206862805?from=searchPage&outVendor=zw_mooc_pcssjg_>
|
||||
4. 电子科技大学教学资源平台课程页：<https://resource.uestc.edu.cn/learn/course/preview/spoc/17269f9718ed4af1b94108437e6b6e1a>
|
||||
@@ -0,0 +1,21 @@
|
||||
# 罗蕾教授的科研与产业化路径
|
||||
|
||||
罗蕾教授的科研工作持续把嵌入式基础软件能力往产业场景里推进。作为电子科技大学相关方向具有代表性的知名专家学者，她长期主持或参与国家重大专项、863 项目、自然科学基金、发改委软件产业化专项等任务，同时又深度参与企业合作、行业标准与联盟工作。这种“研究 - 标准 - 产品 - 场景”连起来的路径，是她区别于很多纯学院型学者的重要地方。
|
||||
|
||||
她早期的重要发力点是嵌入式基础软件和实时操作系统。她曾主持“面向嵌入式软件的生产线”“智能手机嵌入式软件平台”“嵌入式实时操作系统及其开发工具”等项目，所在团队也长期围绕嵌入式操作系统、嵌入式网络安全、汽车电子基础软件展开工作。这类方向的共同点，是都处在系统底层，技术门槛高、复用价值大，而且很容易形成行业平台能力。
|
||||
|
||||
之后，她的科研和产业化路径逐步向汽车电子和网络安全方向深化。团队列出的代表性项目里，既有“汽车电子网络安全标准化研究白皮书编制”“面向汽车电子的代码安全技术研究与实现”，也有“智能汽车安全加固与监控产品研发与产业化”“车辆身份唯一性认证模型的测试委托”等项目。罗蕾教授的工作集中在汽车电子基础软件、代码安全、身份认证、网络安全标准等更底层、更可落地的位置。
|
||||
|
||||
同时，她的团队也明显向区块链与数据安全扩展。相关成果包括区块链基础平台“优云链”和面向数据共享的“优数”平台，应用场景覆盖无人机运输物流追踪、汽车大数据交易平台、学分银行、移动支付可信数据共享联盟链、国际贸易通关协同、财政资金监管等。她所推动的区块链工作与数据确权、共享交换、可信交易、安全监管等产业需求直接挂钩。
|
||||
|
||||
除了项目本身，罗蕾教授在行业规则层面的参与也很值得关注。她牵头或参与了 20 余项国家、行业和团体标准，团队也参与了多项汽车网络安全相关国家标准与行业标准。她的影响力同时体现在技术落地和行业通用规则推进两个层面。对很多产业技术路线来说，这一步往往比单点成果更有长期影响。
|
||||
|
||||
她的科研路径可以概括为三层：第一层是嵌入式操作系统、开发工具和基础软件；第二层是网络安全、汽车电子、物联网与数据安全；第三层是标准化、产业平台和企业合作落地。正因为这三层是打通的，罗蕾教授的工作才呈现出很强的“工程系统型”特征，并形成了连续展开的研究主题体系。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
|
||||
3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
|
||||
5. 世展网转载行业观点文章：<https://www.shifair.com/informationDetails/135407.html>
|
||||
@@ -0,0 +1,29 @@
|
||||
# 罗蕾教授的代表成果与研究主题
|
||||
|
||||
罗蕾教授作为电子科技大学相关方向具有较高影响力的知名专家学者，其研究主题围绕“嵌入式系统底层能力如何支持复杂场景”逐步展开。她较有代表性的成果，大致可以分成四个方向：嵌入式实时操作系统、汽车电子基础软件与安全、网络与数据安全、以及面向新场景的智能计算延展。
|
||||
|
||||
第一类成果是嵌入式实时操作系统与基础软件。罗蕾教授主编过《嵌入式实时操作系统及应用开发》和《嵌入式系统及应用》等教材，导师页面列出的代表论文也长期围绕任务调度、GUI、多任务系统、AADL 可调度性分析等主题展开。比如 `UCaS: a schedulability analysis tool for AADL models` 这类工作，体现的是她早期在嵌入式软件建模与调度分析方面的积累。这个方向的核心关键词，是实时性、可调度性和基础软件工程化。
|
||||
|
||||
第二类成果是汽车电子嵌入式操作系统与 AUTOSAR 相关研究。比较典型的论文包括《汽车电子嵌入式操作系统的隔离保护机制》和《AUTOSAR 可运行实体-任务自动映射方法研究》。前者关注的是在有限硬件资源下实现多层级隔离保护，以降低系统整体失效概率；后者则围绕 ECU 配置和实时系统任务映射，提高汽车软件开发效率。她在汽车电子方向持续关注操作系统机制、安全隔离和软件架构配置这类关键底层问题。
|
||||
|
||||
第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。
|
||||
|
||||
第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。
|
||||
|
||||
罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。
|
||||
|
||||
## 可关注的公开代表成果
|
||||
|
||||
- `汽车电子嵌入式操作系统的隔离保护机制`
|
||||
- `AUTOSAR可运行实体-任务自动映射方法研究`
|
||||
- `A Cross-platform Mobile Payment Solution Based on Web Technology`
|
||||
- `UCaS: a schedulability analysis tool for AADL models`
|
||||
- `An intrusion detection system integrating network-level intrusion detection and host-level intrusion detection`
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
|
||||
2. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
|
||||
3. 电子科技大学学报相关论文页：<http://www.juestc.uestc.edu.cn/article/doi/10.3969/j.issn.1001-0548.2014.03.023?viewType=citedby-info>
|
||||
4. 学术摘要页《汽车电子嵌入式操作系统的隔离保护机制》：<https://www.xueshu.com/dzkjdxxb/201403/2984678.html>
|
||||
5. 维普摘要页《AUTOSAR可运行实体-任务自动映射方法研究》：<http://dianda.cqvip.com/Qikan/Article/Detail?id=7000589928>
|
||||
@@ -0,0 +1,15 @@
|
||||
# 罗蕾教授资料目录
|
||||
|
||||
本目录用于介绍罗蕾教授的学术背景、教学工作、科研路径与代表性研究主题，并将内容拆分为几篇可以独立阅读的介绍文章。
|
||||
|
||||
## 文件列表
|
||||
|
||||
- `01-人物概览.md`：聚焦罗蕾教授的基本履历、学术身份与整体定位。
|
||||
- `02-教学与人才培养.md`：聚焦课程建设、教材编写与人才培养工作。
|
||||
- `03-科研与产业化路径.md`：聚焦科研方向、重大项目、行业标准与产业合作。
|
||||
- `04-代表成果与研究主题.md`：聚焦代表性研究主题、论文与技术成果。
|
||||
|
||||
## 使用说明
|
||||
|
||||
- 各文档彼此独立，可单独转发或继续扩写。
|
||||
- 各文档正文以人物介绍和研究工作为主，参考资料统一列于文末。
|
||||
@@ -0,0 +1,28 @@
|
||||
# 翼辉信息与大型实时操作系统定位概览
|
||||
|
||||
翼辉信息在本项目中对应的是**面向任务关键系统的大型跨平台实时操作系统平台**。SylixOS 的核心价值集中在复杂系统中的实时软件底座能力，即维持确定性、可预测性和系统边界。
|
||||
|
||||
翼辉信息长期围绕 SylixOS 展开自身定位，定位为“软件定义智能装备业内领先的基础软件架构供应商”，强调基于原创工业操作系统和整体软件架构技术，为火箭、卫星、高铁、大飞机、无人设备、电网电站、工业自动化、智能汽车等任务关键型智能设备提供稳定、可靠、安全的软件系统方案。其平台能力覆盖**关键行业、复杂系统、长期交付和基础平台能力**，在相关领域具备较强代表性和较高行业辨识度。
|
||||
|
||||
翼辉信息最核心的产品身份是“**大型实时操作系统**”。SylixOS 的核心能力包括：SMP 多核实时调度、多处理器架构支持、动态装载、POSIX 兼容、高安全高可靠、复杂系统集成，以及长期版本维护。SylixOS 承担的是更高层次的软件平台职责：在不同硬件架构、不同规模平台和不同关键行业约束下，为复杂任务提供统一、稳定且可演进的实时操作系统基础。
|
||||
|
||||
本项目围绕的大型跨平台实时操作系统平台，正与翼辉信息所代表的平台能力直接对应。翼辉信息提供的是一种可以跨平台承载、跨行业验证、并且天然面向任务关键场景的 RTOS 平台样本。
|
||||
|
||||
翼辉团队的技术起点可追溯到 2006 年，随后在 2015 年公司化运营。SylixOS 内核经过工信部赛普测评中心源代码测评，自主化率达到 100%，并获得德国 TÜV SUD 集团颁发的 IEC 61508（SIL3）、EN 50128（SIL4）和 ISO 26262（ASIL D）认证。翼辉信息已经进入高安全、高可靠、高约束行业的软件平台提供方序列，是非常值得重视、也颇具分量的**产业级实时操作系统案例**。
|
||||
|
||||
除了 SylixOS 内核本身，翼辉信息还呈现出一条从 RTOS 向完整基础软件栈外扩的路径。其产品和能力包括 RealEvo 开发环境、VSOA 分布式软总线、任务关键型云原生体系、工业自动化数字基座、飞控与仿真产品等。翼辉正在把实时操作系统扩展为面向关键装备的软件平台。这种平台化能力与本项目的验证方向高度一致。
|
||||
|
||||
翼辉信息在本项目中的身份可以表述为：**面向关键行业的大型跨平台实时操作系统与基础软件平台提供方**。作为产业落地样本，它能够直接支撑与实时调度、关键系统约束、复杂工程交付相关的课题论证。
|
||||
|
||||
## 对本项目最有价值的定位结论
|
||||
|
||||
1. 翼辉信息代表的是**大型跨平台实时操作系统平台**。
|
||||
2. SylixOS 的核心价值体现在**复杂系统中的实时性、确定性与平台能力**。
|
||||
3. 翼辉信息更适合作为**产业级 RTOS 案例**。
|
||||
4. 它能够帮助本项目围绕“实时操作系统如何治理智能负载进入任务关键系统后的边界问题”展开产业样本验证。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,17 @@
|
||||
# SylixOS 技术能力与演进
|
||||
|
||||
SylixOS 是翼辉信息的核心技术载体，是一款支持 SMP 多核实时调度、可运行于多种 CPU 架构目标平台的“大型实时操作系统”。其工程积累集中体现在调度、隔离、兼容性和长期演进能力上。
|
||||
|
||||
SylixOS 的内核在 2006 年完成，最初具备线程调度、中断管理、定时器、RMS、信号量等核心机制；随后逐步加入 I/O、网络、文件系统、内存管理、POSIX 支持、C++ 支持、GDB 调试、Qt 支持和更广泛的平台适配。2011 年开始支持多核和动态装载；2012 年开始支持进程；2018 年全面支持 C-SKY 和 RISC-V；2020 年推出 LTS 版本；2021 年通过 IEC 61508（SIL3）和 EN 50128（SIL4）国际安全认证；2022 年进一步通过 ISO 26262（ASIL D）认证并支持 LoongArch。SylixOS 持续朝着可落地的大型实时系统平台演进。
|
||||
|
||||
SylixOS 对多核与异构调度的强调，也与本项目高度相关。其 2023 年 V3.0.0 阶段已经开始支持异构算力大小核处理器，并提供灵活高效的调度器与调度策略，在算力和功耗之间取得平衡。这一能力与 LLM 推理线程、实时控制任务在共享 CPU、缓存和内存资源时的冲突控制直接相关。SylixOS 在大小核调度、SMP 调度策略、长期版本维护和实时性保障上的成熟能力，也使其非常适合作为实验平台或联合验证对象。
|
||||
|
||||
SylixOS 周边能力也比较完整。其支持多种 CPU 架构，强调强实时、高安全、高可靠；同时配套 RealEvo 开发环境、仿真与远程开发能力，甚至扩展到容器、分布式软总线和任务关键型云原生体系。它已经形成较完整的软件工程与集成配套。对研究项目而言，这种配套能力很关键，因为很多真实工业验证会卡在工具链、仿真环境、应用移植和系统验证流程上。
|
||||
|
||||
SylixOS 主要承担 RTOS 与基础软件底座角色。在本项目语境下，研究重点是 SylixOS 这类 RTOS 如何对 AI 推理任务进行资源隔离、优先级控制、实时保障和系统级治理。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
|
||||
2. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
3. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
@@ -0,0 +1,18 @@
|
||||
# 行业落地与生态版图
|
||||
|
||||
翼辉信息持续进入关键行业落地场景，其服务对象集中在火箭、卫星、高铁、大飞机、工业自动化、能源电力、智能汽车、低空经济等任务关键型装备领域。这些行业共同要求硬实时或强实时、长期稳定、功能安全和工程可维护性。
|
||||
|
||||
翼辉信息正在构建一套更完整的生态版图。除了 SylixOS 之外，公开展示的还包括 RealEvo 轻量开发环境、VSOA 分布式软总线、工业自动化数字基座、可编程控制器、虚拟 PLC、边缘计算机、飞控系统、飞行仿真平台等。其商业策略已延伸到“关键装备基础软件平台方”这一层级。对联合研究而言，这种生态化布局可以覆盖内核测评、整机验证、边缘控制、系统集成和行业样机落地等更宽的接口。
|
||||
|
||||
行业案例与用户故事也体现出清晰的行业线索。首页展示了中国铁道科学研究院和星际荣耀的用户评价，前者强调轨交信号控制系统对功能安全、稳定性、实时性的苛刻要求，后者强调在火箭飞控场景中通过 RTOS 对复杂软件进行分层抽象的重要性。航天行业页面还提到，翼辉信息与相关航天单位开展深度合作，基于 SylixOS 的星载操作系统用于星务和载荷设备开发，并参与火箭控制器、卫星载荷等系统建设。翼辉的主要市场集中在高可靠装备场景。
|
||||
|
||||
翼辉信息在南京的软件产业生态中也被作为“工业底层操作系统”代表企业来呈现。2026 年南京雨花台区公开报道提到，南京翼辉信息 2016 年落地软件谷，围绕 SylixOS 研发逐步形成产业能力，并将经验复制到水务、地铁运营、地下空间运维等场景。报道还提到其正推动人工智能、边缘计算与操作系统深度融合。翼辉的产业化路径已经覆盖军工之外的城市基础设施和工业场景。
|
||||
|
||||
翼辉信息已经把 RTOS 能力嵌入了多个高要求行业场景，并在工具链、行业方案和系统架构层面继续外扩。对本项目而言，它既是实验平台的重要来源，也是后续验证场景和行业接口的重要支撑。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. 翼辉信息航天行业页：<http://www.acoinfo.cn/industry-center/spaceflight>
|
||||
4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,38 @@
|
||||
# 与本项目的潜在协同点
|
||||
|
||||
把翼辉信息放进本项目的联合研究方名单，能够为项目提供一个较有代表性的**产业落地案例**，帮助我们把课题从抽象的“实时操作系统理论”推进到“任务关键系统中的工程验证”。
|
||||
|
||||
本项目围绕的大型跨平台实时操作系统平台比较，聚焦于五类硬件条件下智能负载进入任务关键系统后的确定性、可预测性与实时保障表现。翼辉信息对应的是一个面向关键行业长期演进的 RTOS 平台提供方，因此在这个课题中具有清晰的产业样本价值。
|
||||
|
||||
第一，翼辉信息适合作为**基础平台型产业案例**。SylixOS 被持续定义为“大型实时操作系统”，其核心能力集中在 SMP 多核实时调度、跨处理器架构支持、动态装载、长期维护、高安全高可靠，以及面向复杂系统集成的工程能力。翼辉信息在这一结构中承担的是“系统级平台厂商”角色，与本项目的平台研究对象高度一致。
|
||||
|
||||
第二，翼辉信息适合作为**任务关键系统落地语境下的验证样本**。其行业服务重点集中在轨道交通、航天、航空、电力、工业自动化、智能汽车等领域，这些场景共同要求系统长期稳定运行，并对时序、可靠性、安全性和工程交付有明确要求。翼辉这样的案例能够把研究问题放到具有明确时序边界和系统保障要求的工业语境中。
|
||||
|
||||
第三，翼辉信息适合作为**RTOS 在任务关键场景中的边界控制能力**这一命题的产业对照载体。未来设计对照实验时，重点就在于同一类任务关键负载下，SylixOS 这类大型跨平台 RTOS 与标准 Linux、PREEMPT_RT Linux 这类通用或实时增强型系统相比，在 deadline miss、尾延迟、任务抖动、资源隔离和故障恢复上形成怎样的边界控制能力。翼辉的产业案例价值就在这里：它让这一研究命题可以被放到真实行业约束中讨论。
|
||||
|
||||
第四，翼辉信息还适合作为**工程闭环能力的观察对象**。翼辉围绕 SylixOS 不仅提供内核，还扩展了开发环境、仿真、软总线、数字基座、任务关键型云原生与系统化交付能力。它已经形成一整套从内核到工具链再到行业集成的方法论。工程闭环能力也直接决定学术结论能否落到产业场景里。
|
||||
|
||||
第五，翼辉信息在本项目中的价值集中在**实时操作系统平台、关键行业基础软件和系统治理能力**。围绕 SylixOS 这类大型跨平台 RTOS，可以进一步展开 AI 推理系统进入任务关键系统后的实时约束建模、优先级与配额控制、内存带宽与缓存竞争治理、大小核与能耗协同、容器化封装，以及控制任务不失稳条件下的系统级实验设计。
|
||||
|
||||
翼辉信息为“大型跨平台实时操作系统在任务关键系统中的边界控制能力”这一研究命题，提供了一个能够落到关键行业、复杂系统和长期交付语境中的产业样本。
|
||||
|
||||
## 作为产业落地案例时可重点强调的价值
|
||||
|
||||
1. **平台定位**：翼辉代表的是大型跨平台实时操作系统平台。
|
||||
2. **场景准确**：其公开落地行业天然属于任务关键系统，比消费电子场景更能支撑课题成立。
|
||||
3. **对照准确**：便于把 SylixOS 与 Linux / PREEMPT_RT 等系统放到统一的工业约束下比较。
|
||||
4. **验证准确**：可从调度、隔离、故障恢复、能耗治理、系统集成多个层面观察 RTOS 的真实优势。
|
||||
|
||||
## 可继续深挖的合作问题
|
||||
|
||||
1. SylixOS 当前公开可支持到什么程度的 AI 推理运行时、边缘推理框架或异构算力调度能力。
|
||||
2. 在 SylixOS 平台上，实时控制任务与推理任务共存时可用的隔离手段包括哪些，例如核绑定、容器、时间分片、内存配额、设备访问权限控制等。
|
||||
3. 以翼辉作为产业落地案例时，对照组采用 Linux、PREEMPT_RT Linux，还是两者同时纳入。
|
||||
4. 能否联合定义一个面向任务关键系统的 AI 干扰基准测试，用于量化 deadline miss、尾延迟、抖动和能耗影响。
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. 翼辉信息官网首页：<https://www.acoinfo.com/>
|
||||
2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
|
||||
3. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
|
||||
4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>
|
||||
@@ -0,0 +1,15 @@
|
||||
# 翼辉信息资料目录
|
||||
|
||||
本目录用于介绍翼辉信息及其 SylixOS 技术体系，服务于联合研究判断、产业协同沟通和 RTOS 技术路线分析。
|
||||
|
||||
## 文件列表
|
||||
|
||||
- `01-公司与RTOS定位概览.md`：聚焦翼辉信息的公司定位、核心产品和公开产业身份。
|
||||
- `02-SylixOS技术能力与演进.md`：聚焦 SylixOS 的技术特征、发展里程碑和能力边界。
|
||||
- `03-行业落地与生态版图.md`：聚焦翼辉信息在关键行业的应用方向、案例和生态布局。
|
||||
- `04-与本项目的潜在协同点.md`：聚焦翼辉信息与本项目“RTOS 管理 LLM 推理资源竞争”主题的结合点。
|
||||
|
||||
## 使用说明
|
||||
|
||||
- 各文档彼此独立，可单独阅读或继续扩写。
|
||||
- 正文以公司定位、平台能力和行业应用介绍为主，参考资料统一列于文末。
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
-210
@@ -1,210 +0,0 @@
|
||||
# RTOS 针对大模型运行的优化方向 — 整体研究框架
|
||||
|
||||
## 0. 核心问题
|
||||
|
||||
> **矛盾**：RTOS追求确定性的微秒~毫秒级延迟，而LLM推理是计算密集、耗时长（ms~s级）、内存大（GB级）的软实时负载。
|
||||
>
|
||||
> **目标**：在资源受限的边缘/嵌入式场景中，设计RTOS调度器/运行时，管理LLM推理过程中的**多源异构资源**，确保推理过程的**确定性**、**低延迟**与**能效**。
|
||||
|
||||
**这不是让RTOS"跑大模型"，而是用RTOS做"LLM推理资源的调度与协调"。**
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题空间：硬件平台全景
|
||||
|
||||
### 1.1 四层硬件抽象
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────┐
|
||||
│ Controller Layer (MCU/应用CPU) │
|
||||
│ STM32H7 / ESP32-S3 / Cortex-M7 / RPi CM4 │
|
||||
│ 目标：跑量化后的小模型（Qwen-1.5B INT4, Qwen2.5-0.5B） │
|
||||
│ RAM: 256KB~2MB, 主频: 400MHz~1GHz │
|
||||
├───────────────────────────────────────────────────────────┤
|
||||
│ SoC Layer (手机/车规SoC) │
|
||||
│ 骁龙8 Gen / 天玑9300 / NXP i.MX93 │
|
||||
│ 集成: CPU + NPU + GPU + ISP + DDR, 功耗: 3~15W │
|
||||
│ 目标：跑500M~3B参数模型, 实时语音/对话 │
|
||||
├───────────────────────────────────────────────────────────┤
|
||||
│ Edge AI Accelerator (边缘盒子) │
|
||||
│ NVIDIA Jetson Orin / RK3588 / 地平线J5 │
|
||||
│ 集成: CPU集群 + 专用NPU + 大DDR, 功耗: 15~60W │
|
||||
│ 目标：跑7B~14B参数模型, 多模态推理 │
|
||||
├───────────────────────────────────────────────────────────┤
|
||||
│ Server Layer (x86 / ARM Server) │
|
||||
│ x86: Intel/AMD, ARM: Ampere/Graviton │
|
||||
│ 集成: 多Core + 多NPU/GPU + 大内存 + PCIe互联 │
|
||||
│ 目标：跑14B~72B+参数模型, 云端推理 │
|
||||
└───────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 1.2 各平台的关键约束
|
||||
|
||||
| 平台层级 | 内存带宽 | 加速设备 | RTOS适配难度 | 核心挑战 |
|
||||
|---------|---------|---------|-------------|---------|
|
||||
| MCU级 | 几十MB/s | 无/简单DSP | 低（RTOS成熟） | 内存太小，模型必须极小 |
|
||||
| SoC级 | 几百MB/s | NPU + GPU | 中 | NPU驱动不开放，NPU-ARM通信难 |
|
||||
| Edge盒子 | GB/s级 | 专用NPU | 中高 | 多NPU调度、PCIe延迟 |
|
||||
| Server级 | 数十GB/s | 多GPU/NPU | 高 | NUMA、互联拓扑、调度粒度 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 五层技术框架
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────┐
|
||||
│ L5: 模型层 — Inference Engine │
|
||||
│ Quantization | KV Cache Layout | Speculative Decode │
|
||||
│ 目标：减少计算量、降低内存带宽需求 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L4: 运行时层 — Runtime & Scheduling │
|
||||
│ Task Graph | Pipeline Parallel | Memory Pool | Preemption │
|
||||
│ 目标：将LLM计算分解为RTOS可管理的task与事件 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L3: 资源抽象层 — Hardware Abstraction │
|
||||
│ Accelerator Driver | DMA Engine | Memory Controller │
|
||||
│ 目标：统一不同硬件的接口，暴露资源状态给调度器 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L2: 调度层 — RTOS Core │
|
||||
│ Priority Scheduling | EDF | Hybrid Scheduling | IRQ mgmt │
|
||||
│ 目标：在保证硬实时约束的同时高效执行LLM推理 │
|
||||
├───────────────────────────────────────────────────────────────┤
|
||||
│ L1: 硬件层 — SoC + Accelerator + Memory │
|
||||
│ ARM/RISC-V | LPDDR | PCIe | NPU/GPU │
|
||||
│ 目标：理解硬件物理特性（缓存、带宽、拓扑） │
|
||||
└───────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.1 L5 → L4 的映射关系
|
||||
|
||||
```
|
||||
LLM推理阶段 RTOS任务映射
|
||||
────────── ────────────
|
||||
Tokenization → Task A (低优先级, 可中断)
|
||||
Embedding → Task B (中优先级, 计算密集)
|
||||
Attention KV Cache → Task C (高优先级, 延迟敏感)
|
||||
FFN → Task D (中优先级, 可pipeline)
|
||||
Logits/Sample → Task E (中优先级, 可并行)
|
||||
Output decoding → Task A (循环)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 六个核心优化方向
|
||||
|
||||
```
|
||||
方向1: 推理图任务调度 ← 调度算法
|
||||
方向2: KV Cache 与内存管理 ← 内存管理
|
||||
方向3: 加速器协同调度 ← 资源协同
|
||||
方向4: 量化与精度感知调度 ← 精度-调度联合优化
|
||||
方向5: 中断与实时响应 ← 实时性保障
|
||||
方向6: 能耗与热管理 ← 能效优化
|
||||
```
|
||||
|
||||
每个方向的深入分析见对应子文档（01~06）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 关键性能指标
|
||||
|
||||
### 4.1 延迟指标
|
||||
|
||||
| 指标 | 定义 | 优化手段 |
|
||||
|-----|------|---------|
|
||||
| TTFT (Time to First Token) | 输入到第一个输出token的时间 | 预计算embedding、Attention优先级提升 |
|
||||
| TPOT (Time per Output Token) | 每个输出token的平均生成时间 | KV Cache池化、流水线并行 |
|
||||
| Tail Latency P99 | 99%请求的端到端延迟 | 减少context switch、避免priority inversion |
|
||||
| WCL (Worst-Case Latency) | 硬实时约束下的最大可接受延迟 | WCET分析、hybrid scheduling |
|
||||
|
||||
### 4.2 资源指标
|
||||
|
||||
| 指标 | 定义 | 优化手段 |
|
||||
|-----|------|---------|
|
||||
| Memory Bandwidth Utilization | DDR带宽利用率 | DMA offload、带宽感知调度 |
|
||||
| Cache Hit Rate | L1/L2 Cache命中率 | Task pinning、数据局部性优化 |
|
||||
| NPU/GPU Utilization | 加速器利用率 | 双缓冲、pipeline parallel |
|
||||
| Power per Inference | 每次推理的能耗 | DVFS、idle-aware scheduling |
|
||||
|
||||
### 4.3 实时性指标
|
||||
|
||||
| 指标 | 定义 | 优化手段 |
|
||||
|-----|------|---------|
|
||||
| Jitter | 延迟的方差 | 固定优先级、减少抢占 |
|
||||
| Preemption Overhead | 上下文切换开销 | 减少task数量、pin核心 |
|
||||
| Blocking Time | 低优先级被高优先级阻塞的时间 | Priority inheritance protocol |
|
||||
| Deadline Miss Ratio | 错过截止时间的比例 | EDF、adaptive priority boost |
|
||||
|
||||
---
|
||||
|
||||
## 5. 研究方法论
|
||||
|
||||
### 5.1 建模方法
|
||||
|
||||
```
|
||||
LLM Inference Model:
|
||||
T_total = Σ(T_encode + T_decode_i) for i = 1..N_tokens
|
||||
T_encode = T_tokenizer + T_embedding + Σ(T_attention_l + T_ffn_l) for l = 1..N_layers
|
||||
|
||||
RTOS Scheduling Model:
|
||||
π(task) = priority(task)
|
||||
τ(task) = WCET(task)
|
||||
D(task) = deadline(task)
|
||||
R(task) = response_time(task) = τ(task) + Σ(interference_from_higher_priority_tasks)
|
||||
```
|
||||
|
||||
### 5.2 分析工具链
|
||||
|
||||
- **WCET分析**：RTA (Response Time Analysis)、FDAS (Full Demand Analysis for Arbitrary Scheduling)
|
||||
- **模拟平台**：GEM5（全系统模拟）、NN-SIM（神经网络模拟）
|
||||
- **原型验证**：FreeRTOS/Zephyr + 自定义调度器 patch
|
||||
- **性能分析**：perf、ftrace、f2fs-trace、NPU profiler
|
||||
|
||||
### 5.3 评估流程
|
||||
|
||||
```
|
||||
1. 基准测量：不同平台上的LLM推理profile（延迟、带宽、能耗）
|
||||
2. 模型构建：将推理过程建模为RTOS任务图
|
||||
3. 算法设计：针对识别到的瓶颈设计调度/内存/协同策略
|
||||
4. 仿真验证：在模拟环境中验证理论分析
|
||||
5. 原型实现：在真实RTOS上实现关键模块
|
||||
6. 实测对比：优化前后指标对比
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 与已有工作的关系
|
||||
|
||||
| 已有工作 | 差异点 | 本研究的独特贡献 |
|
||||
|---------|-------|----------------|
|
||||
| vLLM / TGI (LLM Serving) | 服务器级，无实时性保证 | 边缘/嵌入式场景，硬实时约束 |
|
||||
| Micro-LLM (TinyLLM) | 模型压缩，不关注OS调度 | 从OS调度层优化推理延迟确定性 |
|
||||
| NPU SDK调度 | 封闭blackbox，不暴露接口 | 开放式RTOS集成，可分析可证明 |
|
||||
| CUDA Stream (GPU) | 无实时性分析，非抢占式 | RTOS可抢占、WCET可证明 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 文档结构索引
|
||||
|
||||
| 文档 | 内容 |
|
||||
|-----|------|
|
||||
| [01-inference-scheduling.md](01-inference-scheduling.md) | 推理图任务分解与混合调度算法 |
|
||||
| [02-kv-cache-memory.md](02-kv-cache-memory.md) | KV Cache内存池与带宽竞争管理 |
|
||||
| [03-accelerator-collab.md](03-accelerator-collab.md) | CPU+NPU流水线协同与异步调度 |
|
||||
| [04-quantization-scheduling.md](04-quantization-scheduling.md) | 量化精度感知的调度策略 |
|
||||
| [05-irq-realtime.md](05-irq-realtime.md) | 中断管理与实时性保障 |
|
||||
| [06-power-thermal.md](06-power-thermal.md) | 能耗感知调度与热管理 |
|
||||
| [07-analysis-methods.md](07-analysis-methods.md) | 方法论与评估工具链 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 预期研究成果
|
||||
|
||||
1. **理论**：LLM推理任务的实时性建模与调度分析理论
|
||||
2. **算法**：针对嵌入式场景的LLM推理调度算法（至少2种：hybrid-priority + EDF）
|
||||
3. **系统**：基于FreeRTOS/Zephyr的LLM推理调度原型系统
|
||||
4. **数据**：不同平台上的LLM推理profile数据集
|
||||
5. **论文**：针对RTSS、RTAS、ISLPED等实时系统的论文
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-09-17*
|
||||
@@ -0,0 +1,42 @@
|
||||
# SylixOS LLM RTOS Research Repo
|
||||
|
||||
本仓库现按“总览、研究框架、实验规划、外部资料、交付物、归档”六个层次组织，便于把研究主线、写作材料和外部导入内容分开维护。
|
||||
|
||||
## 目录结构
|
||||
|
||||
- `00-项目总览/`
|
||||
- 当前研究问题与项目定位边界说明
|
||||
- `10-研究框架/`
|
||||
- 核心研究框架
|
||||
- 六个优化方向与方法学子文档
|
||||
- `20-实验与规划/`
|
||||
- 硬件谱系
|
||||
- 实验设计
|
||||
- 研究逻辑说明
|
||||
- 论文规划与配图
|
||||
- `30-联合研究方/`
|
||||
- 联合研究方资料、人物背景与协作参考
|
||||
- `40-交付物/`
|
||||
- Word 规范稿
|
||||
- 白皮书与汇报输出
|
||||
- `90-归档/`
|
||||
- 外部导入副本
|
||||
- 压缩包与暂存杂项
|
||||
|
||||
## 建议阅读顺序
|
||||
|
||||
1. `00-项目总览/01-当前研究问题：背景、问题与挑战.md`
|
||||
2. `00-项目总览/02-研究定位与项目边界.md`
|
||||
3. `20-实验与规划/README.md`
|
||||
4. `20-实验与规划/01-研究逻辑说明.md`
|
||||
5. `20-实验与规划/02-基础设备与算力基础.md`
|
||||
6. `20-实验与规划/03-实验设计.md`
|
||||
7. `10-研究框架/README.md`
|
||||
8. `10-研究框架/00-整体研究框架.md`
|
||||
9. `20-实验与规划/04-论文写作规划.md`
|
||||
|
||||
## 说明
|
||||
|
||||
- `10-研究框架/00-整体研究框架.md` 与 `01~07` 子文档保持同目录，避免内部引用失效。
|
||||
- `20-实验与规划/` 中的核心规划文档保持同目录，便于交叉引用。
|
||||
- `90-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 324 KiB |
-421
@@ -1,421 +0,0 @@
|
||||
# 最终稿文章规划 — SylixOS 大模型推理调度框架研究
|
||||
|
||||
> **版本**: v1.0 (最终稿规划)
|
||||
> **日期**: 2026-09-20
|
||||
> **整合来源**: 基础设备.md + 方案1.md v1.0 (大模型负载实验设计) + 方案2.md v2.0 (第三方基准复现方法学) +
|
||||
> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章 (含完整实验数据与基准对比)
|
||||
|
||||
---
|
||||
|
||||
## 0. 文章定位与核心贡献
|
||||
|
||||
### 0.1 一句话定位
|
||||
|
||||
> **用业界公认方法学，在四层连续算力硬件谱系 (1 GB → 2 TB / 3 W → 25 kW) 上，首次系统化评测国产 RTOS (SylixOS) 在大模型推理负载下的低延迟、低功耗与实时保号能力，填补 RTOS 在边缘~集群算力评测领域的数据空白。**
|
||||
|
||||
### 0.2 三大核心贡献
|
||||
|
||||
| 编号 | 贡献 | 来源整合 | 对标空白 |
|
||||
|------|------|----------|----------|
|
||||
| C1 | **四层连续算力谱系上的 RTOS 调度评测** — 从端级 RK3568 (1 GB/3 W) 到集群级 4×H100 (1.28 TB/25 kW)，11 个档位覆盖被动散热→机房液冷全散热形态，首次在连续硬件梯度上刻画 RTOS 调度性能曲线 | 基础设备.md §0~§5 | 公开研究仅覆盖单一平台或两档对比，无连续谱系 |
|
||||
| C2 | **大模型混合负载下 RTOS 实时保号量化** — LLM 推理 + 1 ms 周期控制并发场景下，SylixOS 的 T_rt_max_under_llm 与 J_rt_under_llm 相对 Linux RT 的尾延迟优势量化 (≤30% = 显著优势) | 方案1.md §3, §6, §9 | 公开基准仅测吞吐 FPS，未测混合负载下的实时任务保号 |
|
||||
| C3 | **RTOS 数据与业界公开基准首次横向对齐** — 引入第三方文章 (萤火虫数智笔记) 的 CPU/内存/NPU/功耗实测方法学与数据，在 SylixOS 上复现并对比，使 RTOS 数据首次可对外校验 | 方案2.md §2, §5, §7 | 国产 RTOS 在边缘算力 SoC 上的实测数据严重缺失 |
|
||||
|
||||
### 0.3 目标读者与发表场景
|
||||
|
||||
| 维度 | 选择 |
|
||||
|------|------|
|
||||
| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
|
||||
| 备选 | EMSOFT / DAC / MLSys (系统方向) |
|
||||
| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
|
||||
| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 文章整体结构 (十章)
|
||||
|
||||
```
|
||||
第1章 引言 — 问题、动机、贡献概述
|
||||
第2章 背景与相关工作 — LLM 推理特征 + RTOS 基础 + 差距分析
|
||||
第3章 四层连续算力硬件谱系 — 11 档位体系设计与现有设备锚点
|
||||
第4章 SylixOS 调度框架技术架构 — 五层技术栈与六大优化方向
|
||||
第5章 实验方法学 — 第三方基准复现 + 混合负载场景 + 避坑约束
|
||||
第6章 大模型负载选型与配置 — 跨档位模型矩阵
|
||||
第7章 实验结果 — 基准对齐 + 实时性 + 能效 + 温度耦合
|
||||
第8章 深入分析 — 档位间性能曲线 + RTOS vs Linux RT 差异化
|
||||
第9章 讨论与威胁有效性 — 适用场景边界 + 局限性
|
||||
第10章 结论与展望
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 逐章详细规划
|
||||
|
||||
### 第1章 引言
|
||||
|
||||
**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 1.1 问题矛盾 | RTOS 追求 µs~ms 级确定性 vs LLM 推理是 GB 级内存、s 级耗时的软实时负载；边缘~集群场景中二者必须共存 | |
|
||||
| 1.2 研究空白 | 公开基准 (如萤火虫文章) 全部基于 Linux/Ubuntu，国产 RTOS 在边缘算力 SoC 上的实测数据严重缺失；现有研究无连续硬件谱系 | 方案2.md §1.1 |
|
||||
| 1.3 本文贡献 | C1 (四层谱系评测)、C2 (混合负载保号量化)、C3 (业界基准对齐)，一句话概述每个贡献 | |
|
||||
| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
|
||||
|
||||
**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
|
||||
|
||||
---
|
||||
|
||||
### 第2章 背景与相关工作
|
||||
|
||||
**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 2.1 LLM 推理特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 IO 抖动 | 方案1.md §1.1 |
|
||||
| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 方案1.md §1.1 表 |
|
||||
| 2.3 Linux RT 相对短板 | cgroup/kswapd 大模型加载停顿；PREEMPT_RT P99.9 仍受内核态长路径限制；tickless 仅 idle 启用 | 方案1.md §1.1 |
|
||||
| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | FRAMEWORK.md §6, 方案2.md §2.4 |
|
||||
| 2.5 第三方基准方法学 | 萤火虫文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 5 条避坑清单 | 方案2.md §2 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
|
||||
| Tab.1 | SylixOS vs Linux RT 特性对比 | 6 项 RTOS 特性对应的大模型负载优势 + Linux RT 短板 |
|
||||
|
||||
---
|
||||
|
||||
### 第3章 四层连续算力硬件谱系
|
||||
|
||||
**目标**: 800~1000 词，这是 C1 的核心展示章，也是本文区别于其他单平台研究的最大差异化。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 3.1 分级维度与分档规则 | 以「统一内存/显存容量」为第一分类维度；边界值归上界；四层连续无断层 | 基础设备.md §0.1 |
|
||||
| 3.2 全谱系总表 (11 档位) | T4-L→T4-M→T4-H→T3-L→T3-M→T3-H→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 基础设备.md §0.2 |
|
||||
| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 端路线 (T4 全档 + T3-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 基础设备.md §0.3 |
|
||||
| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T3-L+T4-H)；一机两档 (RK3588 16 GB 同时充当 T3-L 与 T4-H)；T1/T2-H 云替代 | 基础设备.md §6 |
|
||||
| 3.5 各层级定位与验证重点 | T1 跨节点分布式调度；T2 单机多卡 NVLink；T3 统一内存带宽隔离；T4 极致资源约束保号 | 基础设备.md T1~T4 各 §.1 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.2 | 四层硬件谱系全景图 | 横轴=容量 (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 词，将 FRAMEWORK.md 的五层技术栈和六大优化方向浓缩为文章的技术背景章。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 4.1 核心问题定义 | 不是让 RTOS "跑大模型"，而是用 RTOS 做 "LLM 推理资源的调度与协调" | FRAMEWORK.md §0 |
|
||||
| 4.2 五层技术栈 | L1 硬件层 → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | FRAMEWORK.md §2 |
|
||||
| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-inference-scheduling.md §2 |
|
||||
| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | FRAMEWORK.md §3, 01~06 子文档 |
|
||||
| 4.5 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 基础设备.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 方法论框架 | "基准测量 → 建模 → 算法设计 → 仿真验证 → 原型实现 → 实测对比" 六步循环 | 07-analysis-methods.md §1 |
|
||||
| 5.2 第三方基准复现方法学 | 引入萤火虫文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑 sysbench/stress-ng/RKNN，与文章数据对比 | 方案2.md §5.1~§5.3 |
|
||||
| 5.3 混合负载实验设计四原则 | 原则1: 混合负载而非孤立；原则2: 看尾延迟不看均值；原则3: 突发场景而非稳态；原则4: 调度精细度而非裸吞吐 | 方案1.md §3 |
|
||||
| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 (Yokogawa WT310) + INA226 采集板强制；采样 ≥1 Hz | 方案2.md §5.4 |
|
||||
| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 方案2.md §5.5 |
|
||||
| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳 10 项强制 | 方案2.md §5.6 |
|
||||
| 5.7 对照组设计 | OS 层: SylixOS vs Ubuntu+PREEMPT_RT vs (KVM/Docker)；配置层: C0 默认 → C1 tuned → C2 extreme | 方案1.md §7, 方案2.md §7.1 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.5 | 实验方法论流程图 | 六步循环 + 第三方基准对齐校验门 (±15% 才准入主场景) |
|
||||
| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
|
||||
| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
|
||||
| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
|
||||
|
||||
---
|
||||
|
||||
### 第6章 大模型负载选型与配置
|
||||
|
||||
**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 方案1.md §2.1 |
|
||||
| 6.2 跨档位模型矩阵 | T4-L: Qwen2.5-0.5B INT4；T4-M: 1.5B INT4；T4-H: 3B/7B INT4；T3-L: 3B/7B INT4 (RKLLM)；T3-M: 14B/32B INT4 (TensorRT-LLM)；T3-H: 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 | 基础设备.md §5.2 + 方案1.md §2.2~§2.3 |
|
||||
| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T3-M/H)、llama.cpp (T2-L/T3-L 退路)、RKLLM (T4/T3-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 方案1.md §2.2~§2.4 |
|
||||
| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 方案1.md §2.4 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
|
||||
| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
|
||||
|
||||
---
|
||||
|
||||
### 第7章 实验结果
|
||||
|
||||
**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核 (sysbench)、内存带宽、NPU FPS (YOLOv5s/ResNet18/MobileNetV2)、3B LLM tok/s 与文章基线的偏差 (目标 ±10%~±20%) | 方案2.md §7.2, §9.3 第一层 |
|
||||
| 7.2 低功耗结果 | P_idle / P_prefill / P_decode / E_per_token 分阶段功耗曲线；T2-L (V100) 与 T3-L/T4-H (RK3588) 两平台对照；SylixOS vs Linux RT 能效比 | 方案1.md §5.1, §6.7, 方案2.md §4.1 |
|
||||
| 7.3 低延迟结果 | T_irq / T_sched / T_ctx P50~Max；T_ttft / T_tok 尾延迟分布直方图；SylixOS vs Linux RT P99.9/Max/σ 对比 | 方案1.md §5.2, §6.5 |
|
||||
| 7.4 混合负载保号结果 (★ 核心) | 场景1: LLM 推理 + 1 ms 周期控制并发；T_rt_max_under_llm / J_rt_under_llm；4 变体 (A1 Linux RT 默认 / A2 Linux RT tuned / A3 SylixOS 默认 / A4 SylixOS 极限)；30 min 全周期延迟时间序列图 | 方案1.md §6.1, §5.3, §9.3 |
|
||||
| 7.5 多模型并发与突发场景 | 场景2: 多模型流水线 P0/P1/P2 优先级公平性；场景3: 突发加载/切换瞬间实时性保持；场景4: GPU/NPU 多请求调度公平性 | 方案1.md §6.2~§6.4 |
|
||||
| 7.6 温度-功耗-性能耦合 | 场景8: 25%→100% CPU 逐步加压的三维耦合曲线；SylixOS vs Linux RT 降频触发温度与性能下降斜率 | 方案2.md §4.4, §6.8 |
|
||||
| 7.7 异构核分配 | 场景6: RK3588 大核 A76 (LLM) + 小核 A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 方案1.md §6.6 |
|
||||
| 7.8 跨档位性能曲线 | 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线 (现有 P0 档位实测 + 扩展档位预估) | 基础设备.md §5.3, 基础设备.md §5.1~§5.2 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
|
||||
| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 W(t) 曲线, SylixOS vs Linux RT 叠加 |
|
||||
| Fig.7 | 混合负载实时任务延迟分布 (★ 核心证据) | P50~Max 直方图 + 时间序列, 4 变体叠加, 突出 A4 的"细长尾部"优势 |
|
||||
| Fig.8 | LLM token 延迟直方图 | Qwen2.5-7B 1 流 1 h 采集, SylixOS vs Linux RT |
|
||||
| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间实时任务延迟 spike, SylixOS ≤50 µs vs Linux RT 100 µs~1 ms |
|
||||
| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
|
||||
| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T4-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
|
||||
| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
|
||||
|
||||
---
|
||||
|
||||
### 第8章 深入分析
|
||||
|
||||
**目标**: 800~1000 词，从数据中提炼规律性结论。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 8.1 档位间性能曲线规律 | 容量每 ×2 时 RTOS 优势的变化趋势；端级 (资源越紧→RTOS 价值越大) vs 集群级 (资源充裕→RTOS 优势收窄) 的拐点分析 | 基础设备.md §5.3 |
|
||||
| 8.2 SylixOS vs Linux RT 差异化量化 | 按 §9.4 优越性判据：T_rt_max_under_llm ≤30% = 显著优势 / ≤60% = 可比偏优 / >60% = 未体现；按档位和场景分别判定 | 方案1.md §9.4 |
|
||||
| 8.3 混合负载下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 不被 decode 抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 加载大模型不引入额外抖动；中断线程化 + 亲和性 → NPU 中断不污染实时核 | 方案1.md §1.1 表, 05-irq-realtime.md |
|
||||
| 8.4 能效分析 | 每 token 能耗 vs 档位 (V100 集群能效基线 vs H100 能效上限)；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 J/token 对比 | 基础设备.md §0.3, 06-power-thermal.md |
|
||||
| 8.5 BSP 风险与可行性 | x86 BSP (低风险, V100 已验证) vs ARM64 RK3588 BSP (极低, 现有) vs T234 Jetson BSP (高, 需翼辉确认) vs RKLLM 移植 (高, 核心风险)；档位跳跃验证降本策略 | 基础设备.md §7, 方案1.md §10 |
|
||||
|
||||
**关键图表**:
|
||||
|
||||
| 编号 | 图表 | 描述 |
|
||||
|------|------|------|
|
||||
| Fig.12 | RTOS 优势 vs 硬件档位趋势图 | 横轴=11 档位, 纵轴=SylixOS 相对 Linux RT 的 P99.9 改善百分比, 标注"显著优势/可比偏优/未体现"区间 |
|
||||
| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
|
||||
| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
|
||||
|
||||
---
|
||||
|
||||
### 第9章 讨论与威胁有效性
|
||||
|
||||
**目标**: 400~600 词，诚实地界定适用边界和局限性。
|
||||
|
||||
| 小节 | 内容要点 | 来源映射 |
|
||||
|------|----------|----------|
|
||||
| 9.1 适用场景边界 | 资源越紧张 (T4) → RTOS 价值越大；资源充裕 (T1-H) → RTOS 优势收窄, 可能"可比偏优"；混合负载 (LLM+RT 并发) → RTOS 杀手锏；纯吞吐场景 → 通用 OS 可能更高 | 方案1.md §3, §9.4 |
|
||||
| 9.2 威胁有效性 | (1) RKLLM 移植风险: 若未完成, 退路 llama.cpp CPU 推理但失去 NPU 优势, 需标注; (2) V100 驱动成熟度: 4 卡 NVLink 联用可能受限, 单卡先行; (3) sysbench/stress-ng 移植: POSIX 兼容可行性高但需验证; (4) 量化精度差异: 同模型同量化跨 OS 不变, 已控制; (5) 室温/散热波动: 25±2 ℃ + 液冷恒定 | 方案1.md §10, 方案2.md §11 |
|
||||
| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | FRAMEWORK.md §6, 方案2.md §2.4 |
|
||||
| 9.4 方法论局限 | 文章仅引用单一第三方来源 (萤火虫文章), 跨平台参照 (昇腾 Qwen-7B) 为非本方案硬件; 消融实验仅在现有 P0 档位可完整执行; 扩展档位 (T1-H/T2-H) 依赖云租替代, 数据可比性需说明 | 方案2.md §13 后续建议 |
|
||||
|
||||
---
|
||||
|
||||
### 第10章 结论与展望
|
||||
|
||||
**目标**: 300~400 词，总结贡献并指出未来方向。
|
||||
|
||||
| 小节 | 内容要点 |
|
||||
|------|----------|
|
||||
| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果 (基准对齐 ±X%、混合负载 ≤Linux RT X%、能效 ≤Linux RT X%) |
|
||||
| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
|
||||
| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-inference-scheduling.md §8 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 来源文档到章节的映射矩阵
|
||||
|
||||
| 来源文档 | 主要贡献章节 | 次要贡献章节 |
|
||||
|----------|------------|------------|
|
||||
| **基础设备.md** | §3 (硬件谱系) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
|
||||
| **方案1.md v1.0** | §5.3 (四原则), §7.4 (混合负载) | §2.1~§2.3 (LLM 推理特征/RTOS 优势/Linux 短板), §5.7 (对照组), §6 (模型选型), §7.2~§7.5 (功耗/延迟/并发/突发), §7.7 (异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
|
||||
| **方案2.md v2.0** | §5.2 (基准复现), §5.4~§5.6 (强制约束) | §2.5 (第三方方法学), §7.1 (基准对齐结果), §7.6 (温度耦合), §9.3 (与已有工作关系), §9.4 (方法论局限) |
|
||||
| **FRAMEWORK.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §8.3 (根因分析), §10.3 (开放问题) |
|
||||
| **01-inference-scheduling.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
|
||||
| **02-kv-cache-memory.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
|
||||
| **03-accelerator-collab.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
|
||||
| **04-quantization-scheduling.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
|
||||
| **05-irq-realtime.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
|
||||
| **06-power-thermal.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
|
||||
| **07-analysis-methods.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
|
||||
|
||||
---
|
||||
|
||||
## 4. 关键数据产物清单
|
||||
|
||||
| 编号 | 产物 | 类型 | 优先级 | 依赖 |
|
||||
|------|------|------|--------|------|
|
||||
| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 基础设备.md 已就绪 |
|
||||
| D2 | 跨档位模型矩阵 | 数据表 | P0 | 基础设备.md + 方案1.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 | P0 档位实测 + P1~P4 档位预估 |
|
||||
| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
|
||||
| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 方案2.md §5.6 模板 |
|
||||
|
||||
---
|
||||
|
||||
## 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 四层硬件谱系 | 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)
|
||||
→ RTOS 确定性 vs LLM 计算密集, 边缘~集群必须共存
|
||||
→ 空白: 国产 RTOS 在边缘算力上零实测数据
|
||||
|
||||
背景铺垫 (§2)
|
||||
→ LLM 推理的 CPU/内存/长尾特征
|
||||
→ RTOS 的 6 项调度优势 + Linux RT 的 3 项短板
|
||||
→ 第三方方法学引入 (5 维度 + 5 避坑)
|
||||
|
||||
硬件谱系 (§3) ← C1 差异化
|
||||
→ 11 档位连续梯度: 1 GB/3 W → 2 TB/25 kW
|
||||
→ 现有 P0 零成本起步 (V100 + RK3588)
|
||||
→ 一机两档降本
|
||||
|
||||
技术架构 (§4)
|
||||
→ 五层技术栈 + 六大优化方向
|
||||
→ LLM 推理 DAG → RTOS 任务映射
|
||||
→ BSP 适配要点与风险
|
||||
|
||||
方法学 (§5) ← C2/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 价值越大
|
||||
→ 优越性量化: ≤30% 显著优势 / ≤60% 可比偏优
|
||||
→ 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
|
||||
→ 能效: V100 基线 vs H100 上限, INT4 拐点
|
||||
|
||||
讨论 (§9)
|
||||
→ 适用边界: 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 (T3-M/H) | 风险高; T3-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 | 与第三方文章配置一致, 可比性最高 |
|
||||
|
||||
---
|
||||
@@ -1,132 +0,0 @@
|
||||
# SylixOS 大模型推理调度研究逻辑说明
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文用于解释[整体逻辑流程图](./整体逻辑流程图.md)，说明《基础设备.md》《实验设计.md》和《最终稿文章规划.md》如何共同组成一套完整的研究方案。
|
||||
|
||||
三份文档承担不同职责：
|
||||
|
||||
| 文档 | 回答的问题 | 在研究中的作用 |
|
||||
|---|---|---|
|
||||
| [基础设备.md](./基础设备.md) | 在哪些硬件条件下研究？ | 定义四层、十一档硬件谱系及现有设备锚点 |
|
||||
| [实验设计.md](./实验设计.md) | 如何产生可信且可复现的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
|
||||
| [最终稿文章规划.md](./最终稿文章规划.md) | 如何把证据组织成论文贡献？ | 把硬件、方法、结果和分析映射到论文十章结构 |
|
||||
|
||||
整个研究的主线是：
|
||||
|
||||
> 硬件谱系 → 软件与模型准入 → 公平对照 → 混合负载实验 → 可复现数据 → 跨档位规律 → 论文贡献。
|
||||
|
||||
## 2. 核心研究矛盾
|
||||
|
||||
实时控制任务通常要求微秒到毫秒级的确定性，大模型推理却会长时间占用 CPU、内存、总线、GPU 或 NPU，并产生排队、模型加载、KV Cache 和中断干扰。两类任务共存时，单纯提高模型吞吐不能说明系统适合实时场景。
|
||||
|
||||
因此，本研究不只考察“模型能跑多快”，而是同时回答三个问题：
|
||||
|
||||
1. 在 LLM 推理干扰下，1 ms 周期任务是否仍能满足截止期？
|
||||
2. SylixOS 的资源隔离和调度机制能否改善尾延迟，同时避免过大的推理吞吐损失？
|
||||
3. 在满足相同实时性和推理服务约束时，系统能否降低每 token 能耗？
|
||||
|
||||
## 3. 为什么建立四层硬件谱系
|
||||
|
||||
《基础设备.md》以可用内存或显存为主要分级维度，构建端、边、桌面和集群四个层级。这样可以观察系统瓶颈随硬件规模变化的过程：
|
||||
|
||||
| 层级 | 主要资源矛盾 | 研究重点 |
|
||||
|---|---|---|
|
||||
| T4 端级 | 内存和功耗预算非常紧张 | 极小资源下的实时任务保留能力 |
|
||||
| T3 边级 | CPU、NPU/GPU 共享统一内存 | 带宽隔离、多模型竞争和功率模式 |
|
||||
| T2 桌面级 | 多 GPU 共享 CPU、内存与互联 | NVLink 通信、多卡调度和并发公平性 |
|
||||
| T1 集群级 | 节点内计算与节点间通信耦合 | RDMA/NCCL 抖动及跨节点调度 |
|
||||
|
||||
当前最重要的实测锚点是：
|
||||
|
||||
- RK3588 16 GB 作为 T3-L 边级平台；
|
||||
- 同一 RK3588 施加 8 GB 内存预算，作为 T4-H 受限配置；
|
||||
- 4×V100、128 GB 总显存服务器作为 T2-L 桌面级平台。
|
||||
|
||||
其余档位用于后续采购、扩容或云租后的条件扩展。现有设备负责产生核心证据，扩展设备用于验证规律能否跨硬件规模成立。
|
||||
|
||||
需要注意，RK3588 的 8 GB 限额配置只能用于研究内存预算变化，不能等同于真实 8 GB 板卡的功耗、物理带宽或热特性。
|
||||
|
||||
## 4. 为什么必须先做准入
|
||||
|
||||
设备可以启动，不代表加速器、模型和混合负载已经具备可比较条件。因此实验被划分为五个连续门槛：
|
||||
|
||||
| 门槛 | 核心检查内容 |
|
||||
|---|---|
|
||||
| G0 设备准入 | 启动、SMP、容量、接口和硬件拓扑 |
|
||||
| G1 测量准入 | 单调时钟、周期任务、日志和功耗仪器 |
|
||||
| G2 加速器准入 | CUDA、RKLLM、RKNN、驱动和基本算子 |
|
||||
| G3 模型准入 | 模型转换、加载、正确推理和峰值内存 |
|
||||
| G4 混合负载准入 | RT 与 LLM 同时稳定运行至少 30 分钟 |
|
||||
|
||||
只有通过 G4 的配置才能进入正式对照实验。准入失败本身也是研究结果，应记录为 BSP、驱动、模型格式或容量限制，不能用估计值补齐。
|
||||
|
||||
## 5. 如何保证对照公平
|
||||
|
||||
主对照包括普通 Linux、Linux PREEMPT_RT、SylixOS 默认配置和 SylixOS 优化配置。比较时需要固定：
|
||||
|
||||
- 模型版本、量化格式、tokenizer、输入长度、输出长度和随机种子；
|
||||
- CPU 核数量、实时优先级、内存预算、加速器数量和频率策略；
|
||||
- 推理请求到达序列、背景干扰强度、预热时间和测量窗口；
|
||||
- 环境温度、散热条件、驱动与框架版本。
|
||||
|
||||
如果两个系统无法使用等价推理后端，结果应表述为“完整系统方案比较”，不能只归因于操作系统调度器。
|
||||
|
||||
## 6. 实验如何逐步展开
|
||||
|
||||
实验采用从简单到复杂的顺序：
|
||||
|
||||
1. E0 确认设备、测量和空载基线。
|
||||
2. E1 测量实时任务唤醒、响应、IPC 和物理接口延迟。
|
||||
3. E2 单独测量模型容量、TTFT、TPOT、吞吐和能耗。
|
||||
4. E3 运行核心场景，即 1 ms 实时任务与 LLM 推理并发。
|
||||
5. E4 比较 RK3588 的 16 GB 与 8 GB 预算配置。
|
||||
6. E5 比较 V100 的 1、2、4 卡运行状态及公平性。
|
||||
7. E6 分析温度、频率、功耗与性能耦合。
|
||||
8. E7 逐项移除核隔离、IRQ 亲和、内存预分配、准入控制等机制，确认收益来源。
|
||||
9. E8 对最终候选配置进行 24 小时长稳与恢复测试。
|
||||
|
||||
背景负载从仅实时任务、仅推理逐步增加到 RT+LLM、CPU/内存/I/O 干扰以及突发过载。这样可以确定系统在哪一个压力区间开始出现排队、降频或截止期违约。
|
||||
|
||||
## 7. 哪些指标构成核心证据
|
||||
|
||||
实时性证据包括 P50、P95、P99、P99.9、观测最大响应时间和截止期违约率。论文中的“实时保号”必须建立在截止期违约统计和完整样本量上，不能只比较平均延迟。
|
||||
|
||||
推理服务证据包括 TTFT、TPOT、成功请求吞吐、有效吞吐、成功率、超时率和拒绝率。有效吞吐只统计满足预先冻结服务约束的请求，防止通过拒绝请求或牺牲实时任务获得虚假吞吐优势。
|
||||
|
||||
功耗证据使用整机输入端功率测量，计算 J/token 和 tokens/J，并同时记录温度、实际频率和降频时间。GPU/NPU 软件遥测可以用于解释能耗来源，但不能代替整机功率计。
|
||||
|
||||
多卡和多节点实验还需要报告强扩展效率、弱扩展吞吐、通信尾延迟和多租户公平性。
|
||||
|
||||
## 8. 数据如何转化为论文贡献
|
||||
|
||||
实验数据最终对应三项贡献：
|
||||
|
||||
| 贡献 | 所需证据 | 对应论文内容 |
|
||||
|---|---|---|
|
||||
| C1 四层连续算力谱系评测 | 各档位的容量、功耗、瓶颈与扩展趋势 | 第3章硬件谱系、第7章结果、第8章跨档位分析 |
|
||||
| C2 混合负载实时保号量化 | RT+LLM 下的尾延迟、违约率、有效吞吐和消融结果 | 第4章调度机制、第5章方法、第7章核心结果 |
|
||||
| C3 可复现方法与基准对齐 | 统一输入、环境元数据、完整原始数据和外部基准复现 | 第5章方法学、第7章基准结果、第9章有效性威胁 |
|
||||
|
||||
文章的论证顺序应保持为：先说明为什么需要四层谱系，再说明 SylixOS 的调度机制和实验方法，然后给出结果，最后讨论优势产生的原因、适用范围和局限性。
|
||||
|
||||
## 9. 实测、计划与结论边界
|
||||
|
||||
论文中应严格区分以下三类内容：
|
||||
|
||||
- **实测结果**：已通过准入并完成实验的数据；
|
||||
- **候选目标**：正式实验前冻结的服务或性能阈值；
|
||||
- **扩展计划**：尚未获得设备、驱动或测量条件的实验。
|
||||
|
||||
设备标称 TOPS、TFLOPS、TDP 和模型预估 tokens/s 不能写成实验结果。FP16 TFLOPS 与 INT8 TOPS不能直接比较，多卡总显存也不能直接推导模型一定可运行。
|
||||
|
||||
24 小时无违约只能表述为“在指定工况和样本量下未观测到违约”，不能证明理论最坏情况。没有温箱数据时，也不能宣称已经验证 RK3588 的完整工业温区。
|
||||
|
||||
## 10. 最终闭环
|
||||
|
||||
这套研究的最终闭环不是追求某一平台的最高 tokens/s，而是寻找一条可重复验证的关系：
|
||||
|
||||
> 随着资源从端级扩展到集群级，SylixOS 的实时调度和资源隔离在什么负载范围内能显著改善实时任务确定性，这种改善需要付出多少吞吐和能耗代价，其优势又会在哪个硬件档位开始减弱。
|
||||
|
||||
如果数据支持该关系，就形成四层硬件谱系、混合负载实时保号和统一评测方法三项论文贡献；如果某些档位不支持，也应把适配失败、容量上限和优势消失的边界作为研究结论的一部分。
|
||||
|
||||
Reference in New Issue
Block a user