forked from eaiadmin/rtos_llm_opt
Compare commits
12
Commits
main
...
b7863721fe
| Author | SHA1 | Date | |
|---|---|---|---|
 Mo1s
|
b7863721fe | ||
|
Mo1s
|
60e0d2e46b | ||
 eaiadmin
|
f28cf2314e | ||
|
eaiadmin
|
7bcd140cdb | ||
|
Mo1s
|
2d6e15348f | ||
|
Mo1s
|
15227a257d | ||
|
eaiadmin
|
67297c66bf | ||
|
eaiadmin
|
3fb61b2d85 | ||
|
eaiadmin
|
d64542f870 | ||
 moyixin
|
cc2ef8f108 | ||
|
moyixin
|
827f0f9e8b | ||
|
Mo1s
|
e2fabe7be8 |
+10
@@ -0,0 +1,10 @@
|
|||||||
|
# Local assistant and workspace metadata
|
||||||
|
.claude/
|
||||||
|
.workbuddy-ai/
|
||||||
|
|
||||||
|
# Local Git access notes may contain credentials
|
||||||
|
git_skills.md
|
||||||
|
|
||||||
|
# Microsoft Office temporary lock files
|
||||||
|
~$*.docx
|
||||||
|
**/~$*.docx
|
||||||
@@ -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,241 @@
|
|||||||
|
# RTOS + Linux + Hypervisor 边缘并行架构说明
|
||||||
|
|
||||||
|
## 1. 架构目标
|
||||||
|
|
||||||
|
边缘侧采用并行分域思路：RTOS 负责控制和安全关键路径，Linux 负责 AI 推理与复杂软件生态，Hypervisor 或等价静态分区层负责空间隔离、时间干扰控制和设备分配。
|
||||||
|
|
||||||
|
该架构不把“让 RTOS 原生运行全部大模型软件栈”作为前提。优化目标按优先级排序为：
|
||||||
|
|
||||||
|
1. 控制闭环截止期不被推理负载破坏；
|
||||||
|
2. AI 结果在规定的新鲜度窗口内可用；
|
||||||
|
3. 推理域故障不扩散到控制域；
|
||||||
|
4. 在前三项满足后提高推理吞吐、能效和资源利用率。
|
||||||
|
|
||||||
|
## 2. 逻辑架构
|
||||||
|
|
||||||
|
```text
|
||||||
|
┌─────────────────────────────────────────────────────────────┐
|
||||||
|
│ 边缘计算硬件 │
|
||||||
|
│ CPU 核 / LLC / DRAM / 内存带宽 / NPU或GPU / I/O / 时钟 │
|
||||||
|
├─────────────────────────────────────────────────────────────┤
|
||||||
|
│ Hypervisor、静态分区器或具备等价能力的隔离层 │
|
||||||
|
│ vCPU/物理核分配、内存区间、IOMMU、设备直通、中断路由、监控 │
|
||||||
|
├───────────────────────────┬─────────────────────────────────┤
|
||||||
|
│ RTOS 控制域 │ Linux 推理域 │
|
||||||
|
│ - 周期控制与联锁 │ - 模型加载与推理运行时 │
|
||||||
|
│ - 现场总线与关键传感器 │ - GPU/NPU 驱动与厂商 SDK │
|
||||||
|
│ - 时间戳、结果校验 │ - 数据预处理与后处理 │
|
||||||
|
│ - 超时、降级与安全状态 │ - 模型更新、日志与网络服务 │
|
||||||
|
├───────────────────────────┴─────────────────────────────────┤
|
||||||
|
│ 有界跨域通道：共享内存环形队列 + 通知 / RPMsg / 虚拟设备等 │
|
||||||
|
└─────────────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
这里的“Hypervisor”表示架构角色，不预设具体产品。若 SoC 已具备安全岛、独立 MCU、AMP 或硬件静态分区能力，只要能够提供可验证的资源和故障隔离，也可以作为实现路径。
|
||||||
|
|
||||||
|
## 3. 两个域的职责边界
|
||||||
|
|
||||||
|
### 3.1 RTOS 控制域
|
||||||
|
|
||||||
|
RTOS 域应拥有：
|
||||||
|
|
||||||
|
- 周期控制、联锁、执行器输出和关键状态采集；
|
||||||
|
- 控制任务使用的定时器、关键中断和关键 I/O；
|
||||||
|
- AI 请求的采样时刻、任务编号、期望完成期限和优先级；
|
||||||
|
- AI 结果的完整性、新鲜度、置信度和序列一致性检查；
|
||||||
|
- 超时、失联、异常结果和推理域重启时的回退控制；
|
||||||
|
- 必要的看门狗与推理域生命周期控制接口。
|
||||||
|
|
||||||
|
RTOS 域不应依赖 Linux 域才能维持基本安全状态。AI 可增强系统能力，但关键控制闭环应明确 AI 缺席时的可接受行为。
|
||||||
|
|
||||||
|
### 3.2 Linux 推理域
|
||||||
|
|
||||||
|
Linux 域应拥有：
|
||||||
|
|
||||||
|
- 模型文件、模型运行时和推理服务；
|
||||||
|
- GPU/NPU/DLA 等加速器驱动及厂商 SDK；
|
||||||
|
- 复杂预处理、后处理、模型编排和批处理；
|
||||||
|
- 网络、存储、模型更新以及非关键日志服务；
|
||||||
|
- 推理资源的吞吐优化和域内调度。
|
||||||
|
|
||||||
|
Linux 域可以对 AI 服务做软实时优化，但不得把域内平均时延等同于控制系统的实时保证。
|
||||||
|
|
||||||
|
### 3.3 Hypervisor/分区层
|
||||||
|
|
||||||
|
隔离层需要明确而不是笼统声称以下能力：
|
||||||
|
|
||||||
|
- CPU 核是静态独占、时间分片还是混合分配；
|
||||||
|
- 内存区域是否静态划分，是否存在共享页和动态气球机制；
|
||||||
|
- LLC、内存带宽和互联是否可分配、限额或仅可观测；
|
||||||
|
- 加速器采用直通、复用还是由单一域独占；
|
||||||
|
- 设备 DMA 是否受 IOMMU 限制；
|
||||||
|
- 物理中断如何路由，是否会在控制核上产生额外虚拟化出口；
|
||||||
|
- 一个域崩溃、重启或过载时，另一域是否持续运行。
|
||||||
|
|
||||||
|
Hypervisor 本身也会引入 VM exit、虚拟中断和跨域通信开销，必须纳入实测，不能只把它视为零成本隔离层。
|
||||||
|
|
||||||
|
## 4. 跨域通信契约
|
||||||
|
|
||||||
|
推荐使用异步、有界、可丢弃的通信语义，避免 RTOS 控制任务同步等待 Linux 推理。
|
||||||
|
|
||||||
|
### 4.1 请求消息最小字段
|
||||||
|
|
||||||
|
| 字段 | 作用 |
|
||||||
|
|---|---|
|
||||||
|
| `request_id` | 区分请求和乱序结果 |
|
||||||
|
| `sample_time` | 标识传感数据的采样时刻 |
|
||||||
|
| `deadline` | AI 结果最晚可用时刻 |
|
||||||
|
| `priority/class` | 区分任务重要性和推理策略 |
|
||||||
|
| `payload_ref` | 指向受控共享缓冲区或内联小数据 |
|
||||||
|
| `schema/version` | 防止两域版本不一致 |
|
||||||
|
|
||||||
|
### 4.2 结果消息最小字段
|
||||||
|
|
||||||
|
| 字段 | 作用 |
|
||||||
|
|---|---|
|
||||||
|
| `request_id` | 与请求配对 |
|
||||||
|
| `model_version` | 支撑审计和回滚 |
|
||||||
|
| `finish_time` | 计算跨域端到端时延 |
|
||||||
|
| `confidence/status` | 判断结果是否可用 |
|
||||||
|
| `valid_until` | 规定结果新鲜度边界 |
|
||||||
|
| `payload/checksum` | 结果与完整性校验 |
|
||||||
|
|
||||||
|
### 4.3 控制域消费规则
|
||||||
|
|
||||||
|
RTOS 只在以下条件同时满足时采用 AI 结果：
|
||||||
|
|
||||||
|
```text
|
||||||
|
ID 匹配
|
||||||
|
AND 数据完整
|
||||||
|
AND finish_time <= deadline
|
||||||
|
AND now <= valid_until
|
||||||
|
AND confidence/status 满足策略
|
||||||
|
```
|
||||||
|
|
||||||
|
任一条件不满足时执行预定义回退，例如沿用上次可信结果、使用传统控制器、降低运行等级或进入安全状态。回退动作和完成时间本身也属于实时需求。
|
||||||
|
|
||||||
|
## 5. 系统级时间模型
|
||||||
|
|
||||||
|
AI 辅助决策链可表示为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
R_ai = C_sample + C_tx_req + Q_linux + C_pre
|
||||||
|
+ C_infer + C_post + C_tx_rsp + C_validate
|
||||||
|
```
|
||||||
|
|
||||||
|
系统约束不是简单要求 `C_infer` 最小，而是：
|
||||||
|
|
||||||
|
```text
|
||||||
|
R_control <= D_control
|
||||||
|
|
||||||
|
AI 结果被采用时：R_ai <= D_ai 且 age(result) <= A_max
|
||||||
|
|
||||||
|
AI 结果未按时到达时：R_fallback <= D_fallback
|
||||||
|
```
|
||||||
|
|
||||||
|
其中，控制闭环约束为硬优先级；AI 时效约束通常为任务相关的软实时或固实时约束；回退路径必须有独立期限。
|
||||||
|
|
||||||
|
## 6. 资源并行与隔离策略
|
||||||
|
|
||||||
|
### 6.1 CPU 和中断
|
||||||
|
|
||||||
|
- 为 RTOS 域保留独立物理核，避免与 Linux vCPU 时间复用；
|
||||||
|
- 将关键定时器和现场总线中断直达 RTOS 域；
|
||||||
|
- 将网卡、存储和加速器完成中断尽量路由到 Linux 域；
|
||||||
|
- 若共享 LLC，测量 Linux 推理对控制任务缓存行为的干扰；
|
||||||
|
- 记录 SMT、动态迁核和电源管理对分区确定性的影响。
|
||||||
|
|
||||||
|
### 6.2 内存、带宽和 DMA
|
||||||
|
|
||||||
|
- 两域使用静态内存区间，共享区保持最小化；
|
||||||
|
- 共享缓冲区预分配，禁止关键路径动态扩容；
|
||||||
|
- 使用 IOMMU 或硬件访问控制限制 DMA 范围；
|
||||||
|
- 对 DRAM 带宽、内存控制器和互联竞争进行压力实验；
|
||||||
|
- 若硬件不支持带宽限额，必须把“核隔离”和“内存隔离”分开表述。
|
||||||
|
|
||||||
|
### 6.3 加速器
|
||||||
|
|
||||||
|
推荐由 Linux 推理域独占 GPU/NPU，以保留成熟驱动和运行时生态。RTOS 通过请求契约使用推理服务，而不是直接进入厂商运行时。
|
||||||
|
|
||||||
|
若控制域也需访问同一加速器，则必须额外解决队列仲裁、DMA 隔离、不可抢占执行段和故障复位归属。这种共享模式风险更高，应作为扩展方案而非默认主线。
|
||||||
|
|
||||||
|
### 6.4 功耗和热
|
||||||
|
|
||||||
|
分域不自动消除芯片级功耗和温度耦合。Linux 域的持续推理可能触发全芯片功耗限制或降频，进而改变 RTOS 域执行时间。因此需要：
|
||||||
|
|
||||||
|
- 固定或记录各域频率和功率模式；
|
||||||
|
- 同步采集控制延迟、推理负载、温度和实际频率；
|
||||||
|
- 对推理域设置负载准入或功耗上限；
|
||||||
|
- 验证热稳态而非只测短时冷机性能。
|
||||||
|
|
||||||
|
## 7. 故障与降级状态机
|
||||||
|
|
||||||
|
```text
|
||||||
|
正常增强控制
|
||||||
|
│ AI 超时/低置信度
|
||||||
|
▼
|
||||||
|
传统控制或保持模式
|
||||||
|
│ 连续超时/通信故障
|
||||||
|
▼
|
||||||
|
推理域隔离与重启
|
||||||
|
│ 控制风险上升
|
||||||
|
▼
|
||||||
|
受限运行或安全状态
|
||||||
|
```
|
||||||
|
|
||||||
|
需要验证的故障至少包括：
|
||||||
|
|
||||||
|
- Linux 推理进程崩溃；
|
||||||
|
- Linux 域卡死或重启；
|
||||||
|
- 加速器驱动错误或设备复位；
|
||||||
|
- 跨域队列堆满、消息乱序或数据损坏；
|
||||||
|
- 推理持续超时；
|
||||||
|
- Linux 域 CPU、内存、网络或存储过载。
|
||||||
|
|
||||||
|
每种故障都要记录检测时间、隔离时间、回退完成时间、控制任务违约数和恢复后首个有效 AI 结果时间。
|
||||||
|
|
||||||
|
## 8. 可比较的架构组
|
||||||
|
|
||||||
|
| 组别 | 架构 | 用途 |
|
||||||
|
|---|---|---|
|
||||||
|
| A0 | 单 Linux，控制与推理同域 | 通用部署基线 |
|
||||||
|
| A1 | PREEMPT_RT Linux，控制与推理同域 | 实时增强 Linux 基线 |
|
||||||
|
| A2 | RTOS 同域承载控制与可运行的 AI | 适用于 MCU/小模型，不强求大模型生态 |
|
||||||
|
| A3 | RTOS 控制域 + Linux 推理域 + 分区层 | 边缘并行主方案 |
|
||||||
|
| A4 | A3 加入通信、带宽、故障和热治理机制 | 完整优化方案 |
|
||||||
|
|
||||||
|
比较时必须固定硬件、控制任务语义、AI 模型、输入到达序列和功率策略。A2 与 A3 若使用不同推理后端，应明确这是“系统方案比较”，不能仅归因为内核差异。
|
||||||
|
|
||||||
|
## 9. 核心评价指标
|
||||||
|
|
||||||
|
### 控制域
|
||||||
|
|
||||||
|
- 周期任务响应时间、抖动和 deadline miss ratio；
|
||||||
|
- 外部输入到执行器输出的物理链路延迟；
|
||||||
|
- AI 过载与故障期间的观测最大响应时间；
|
||||||
|
- 回退路径完成时间。
|
||||||
|
|
||||||
|
### AI 链路
|
||||||
|
|
||||||
|
- 从 RTOS 发起请求到结果验证完成的端到端延迟；
|
||||||
|
- 结果按期率、新鲜度合格率、超时率和丢弃率；
|
||||||
|
- 吞吐、TTFT/TPOT 或任务特定推理时延；
|
||||||
|
- 推理域重启后的恢复时间。
|
||||||
|
|
||||||
|
### 隔离与代价
|
||||||
|
|
||||||
|
- 空载和推理满载时控制延迟之差；
|
||||||
|
- CPU、内存带宽、I/O、DMA 和热干扰敏感度；
|
||||||
|
- 跨域 IPC 延迟、抖动、拷贝次数和 CPU 开销；
|
||||||
|
- 静态资源预留造成的推理吞吐及能效损失。
|
||||||
|
|
||||||
|
## 10. 架构结论边界
|
||||||
|
|
||||||
|
本架构旨在证明“系统可以在 AI 负载不确定的情况下保护关键控制路径，并对 AI 结果实施有期限的安全消费”。它不自动证明：
|
||||||
|
|
||||||
|
- Linux 域中的大模型具备硬实时性；
|
||||||
|
- Hypervisor 消除了所有共享硬件干扰；
|
||||||
|
- 一个硬件平台的分区结果可直接迁移到另一 SoC；
|
||||||
|
- 只要控制域未违约，AI 功能就一定满足任务需求。
|
||||||
|
|
||||||
|
最终结论必须同时报告控制保障效果、AI 结果可用性以及隔离带来的资源代价。
|
||||||
@@ -0,0 +1,207 @@
|
|||||||
|
# 调整后研究问题与验证建议
|
||||||
|
|
||||||
|
## 1. 调整目的
|
||||||
|
|
||||||
|
本文将最新方向意见转化为可执行的研究问题和验证建议。它不替换现有实验设计，而用于指导下一轮方案收敛：主线从覆盖 `T1~T5` 的 RTOS 大模型统一评测，转向 MCU/资源受限 SoC 的 AI 实时干扰，以及边缘侧 RTOS/Linux 分域系统的整体实时保障。
|
||||||
|
|
||||||
|
## 2. 建议的研究范围
|
||||||
|
|
||||||
|
### 2.1 核心范围
|
||||||
|
|
||||||
|
- MCU 或资源受限 SoC 上，AI 与周期控制、采集和通信共存；
|
||||||
|
- 边缘平台上，RTOS 控制域与 Linux 推理域并行运行；
|
||||||
|
- CPU、内存、缓存、总线、中断、DMA、加速器、功耗和热形成的系统级干扰；
|
||||||
|
- AI 结果的期限、新鲜度、超时、降级与故障恢复。
|
||||||
|
|
||||||
|
### 2.2 条件扩展
|
||||||
|
|
||||||
|
- 更大模型、更高并发和多加速器用于增加 Linux 推理域压力；
|
||||||
|
- 不同 Hypervisor、静态分区或 AMP 实现之间的隔离开销比较；
|
||||||
|
- 多边缘节点之间的协同推理。
|
||||||
|
|
||||||
|
### 2.3 暂不作为主线
|
||||||
|
|
||||||
|
- `T1` 多节点大模型集群的 RTOS 部署；
|
||||||
|
- `T2` 多 GPU 工作站上的统一 RTOS 推理栈；
|
||||||
|
- 以“容量从 MCU 连续扩展到集群”为核心贡献；
|
||||||
|
- 将模型量化、KV Cache 或分布式推理优化直接归为 RTOS 成果。
|
||||||
|
|
||||||
|
## 3. 研究问题
|
||||||
|
|
||||||
|
| 编号 | 研究问题 | 核心输出 |
|
||||||
|
|---|---|---|
|
||||||
|
| RQ1 | AI 进入 MCU/SoC 后，通过哪些资源路径破坏控制实时性？ | 干扰来源排序、响应时间与违约边界 |
|
||||||
|
| RQ2 | RTOS 的优先级、预算、隔离、预分配和准入机制能扩大多少安全运行区间？ | 无违约容量曲线与机制消融 |
|
||||||
|
| RQ3 | RTOS 控制域 + Linux 推理域 + Hypervisor 是否优于单域共存？ | 控制保护、AI 结果按期率与资源代价 |
|
||||||
|
| RQ4 | 跨域通信与静态资源预留带来多大开销？ | IPC 延迟/抖动、吞吐和能效损失 |
|
||||||
|
| RQ5 | 推理超时、Linux 域崩溃或加速器故障时能否按时降级？ | 故障检测、隔离、回退和恢复时间 |
|
||||||
|
|
||||||
|
## 4. 分阶段实验路线
|
||||||
|
|
||||||
|
### 阶段 P0：需求与时间契约冻结
|
||||||
|
|
||||||
|
先定义而不是从设备档位反推：
|
||||||
|
|
||||||
|
- 控制任务周期 `T_control` 和截止期 `D_control`；
|
||||||
|
- AI 结果期限 `D_ai` 和最大新鲜度 `A_max`；
|
||||||
|
- AI 缺席时的回退动作和期限 `D_fallback`；
|
||||||
|
- 可接受的 AI 完成率、结果质量和能耗预算；
|
||||||
|
- 需要保护的关键 I/O、中断、内存和设备。
|
||||||
|
|
||||||
|
完成标志是形成一张“任务—资源—期限—失败处理”表。
|
||||||
|
|
||||||
|
### 阶段 P1：MCU/SoC 干扰确认
|
||||||
|
|
||||||
|
在真实可运行 AI 的最小平台上建立下列负载：
|
||||||
|
|
||||||
|
| 负载 | 内容 | 目的 |
|
||||||
|
|---|---|---|
|
||||||
|
| M0 | 仅控制任务 | 控制实时性下界 |
|
||||||
|
| M1 | 仅 AI | AI 执行、内存、功耗基线 |
|
||||||
|
| M2 | 控制 + AI | 确认同域干扰 |
|
||||||
|
| M3 | M2 + 内存/总线压力 | 定位共享资源瓶颈 |
|
||||||
|
| M4 | M2 + I/O/中断压力 | 定位中断与 DMA 干扰 |
|
||||||
|
| M5 | M2 + 热稳态运行 | 识别降频导致的时间漂移 |
|
||||||
|
| M6 | AI 过载与突发 | 找到准入和降级阈值 |
|
||||||
|
|
||||||
|
AI 模型按硬件实际能力选择，不要求 MCU 运行大语言模型。小模型同样可以有效暴露系统级资源竞争。
|
||||||
|
|
||||||
|
### 阶段 P2：RTOS 机制验证
|
||||||
|
|
||||||
|
逐项加入并消融以下机制：
|
||||||
|
|
||||||
|
1. 控制任务固定优先级与核/执行上下文隔离；
|
||||||
|
2. AI 任务预算或服务器机制；
|
||||||
|
3. 内存预分配、缓冲区限额和禁止关键路径动态分配；
|
||||||
|
4. 中断亲和性和关键设备优先级；
|
||||||
|
5. AI 请求队列上限、限流和拒绝策略；
|
||||||
|
6. 模型降级、跳帧或降低推理频率；
|
||||||
|
7. 超时后回退到非 AI 控制路径。
|
||||||
|
|
||||||
|
每次只改变一个机制，输出控制任务违约率、AI 完成率和吞吐代价，避免只给出“优化前后”黑盒比较。
|
||||||
|
|
||||||
|
### 阶段 P3：边缘分域基线
|
||||||
|
|
||||||
|
至少比较：
|
||||||
|
|
||||||
|
| 组别 | 配置 |
|
||||||
|
|---|---|
|
||||||
|
| E0 | 普通 Linux：控制与推理同域 |
|
||||||
|
| E1 | PREEMPT_RT Linux：控制与推理同域 |
|
||||||
|
| E2 | RTOS 控制域 + Linux 推理域，最小静态分区 |
|
||||||
|
| E3 | E2 + 中断、内存、通信和准入优化 |
|
||||||
|
|
||||||
|
如硬件不支持其中某组，应明确记录缺失原因，不用不同硬件数据替代同平台对照。
|
||||||
|
|
||||||
|
### 阶段 P4：共享资源压力扫描
|
||||||
|
|
||||||
|
在 Linux 推理域逐步增加：
|
||||||
|
|
||||||
|
- CPU 利用率和线程数量；
|
||||||
|
- 模型请求到达率、batch 和上下文长度；
|
||||||
|
- DRAM 带宽与 LLC 压力；
|
||||||
|
- 网络、存储和摄像头 I/O；
|
||||||
|
- GPU/NPU 占用和完成中断频率；
|
||||||
|
- 持续功耗与温度。
|
||||||
|
|
||||||
|
横轴使用相同绝对负载或相同到达序列，纵轴联合展示控制 deadline miss ratio、AI 结果按期率和有效吞吐。目标是找到“控制仍安全、AI 仍有用”的二维可行区，而不是只比较单个平均值。
|
||||||
|
|
||||||
|
### 阶段 P5：跨域通信实验
|
||||||
|
|
||||||
|
比较可实现的通信方式，例如共享内存环形队列、通知机制、RPMsg 或虚拟设备。统一消息大小和到达序列，测量：
|
||||||
|
|
||||||
|
- 单向和往返时延；
|
||||||
|
- P99/P99.9 与观测最大抖动；
|
||||||
|
- 拷贝次数和 CPU 占用；
|
||||||
|
- 队列满时的丢弃、覆盖或背压行为；
|
||||||
|
- 域重启后的通道恢复时间；
|
||||||
|
- 旧结果、乱序结果和损坏结果是否被 RTOS 拒绝。
|
||||||
|
|
||||||
|
### 阶段 P6：故障注入与恢复
|
||||||
|
|
||||||
|
建议故障集：
|
||||||
|
|
||||||
|
| 故障 | 必测结果 |
|
||||||
|
|---|---|
|
||||||
|
| 推理进程退出 | 检测时间、控制违约、服务恢复时间 |
|
||||||
|
| Linux 域重启 | RTOS 是否持续运行、回退完成时间 |
|
||||||
|
| 推理请求永久阻塞 | 超时是否生效、队列是否泄漏 |
|
||||||
|
| 加速器错误/复位 | 故障是否跨域传播、恢复路径 |
|
||||||
|
| 共享队列溢出 | 丢弃策略、内存安全、控制影响 |
|
||||||
|
| 消息乱序/校验失败 | 错误结果是否被消费 |
|
||||||
|
| Linux 域 CPU/内存/I/O 过载 | 控制尾延迟和隔离上限 |
|
||||||
|
|
||||||
|
仅在具备安全恢复路径时执行设备级故障注入；否则先用软件故障和仿真通道验证状态机。
|
||||||
|
|
||||||
|
## 5. 指标体系调整
|
||||||
|
|
||||||
|
### 5.1 第一优先级：控制实时性
|
||||||
|
|
||||||
|
- 释放到完成的响应时间；
|
||||||
|
- deadline miss ratio；
|
||||||
|
- P99/P99.9 和观测最大抖动；
|
||||||
|
- GPIO、CAN、RS485 或工业以太网的端到端物理响应；
|
||||||
|
- AI 满载、热稳态和故障期间的控制表现。
|
||||||
|
|
||||||
|
### 5.2 第二优先级：AI 结果可用性
|
||||||
|
|
||||||
|
- 请求发出到 RTOS 验证结果完成的端到端时延；
|
||||||
|
- 结果按期率和新鲜度合格率；
|
||||||
|
- 超时、拒绝、丢弃、乱序和错误率；
|
||||||
|
- 任务质量或置信度；
|
||||||
|
- 回退发生比例。
|
||||||
|
|
||||||
|
### 5.3 第三优先级：系统代价
|
||||||
|
|
||||||
|
- 分给 RTOS 的 CPU、内存和设备资源；
|
||||||
|
- Hypervisor 与 IPC 开销；
|
||||||
|
- 推理吞吐损失、能耗和热影响；
|
||||||
|
- 静态预留导致的资源利用率变化；
|
||||||
|
- 故障恢复和长稳运行开销。
|
||||||
|
|
||||||
|
TTFT、TPOT、tokens/s 和 `E/token` 可以继续使用，但它们属于 Linux 推理域或系统服务指标，不能替代控制实时性与结果新鲜度指标。
|
||||||
|
|
||||||
|
## 6. 推荐图表
|
||||||
|
|
||||||
|
1. 单域与分域架构职责图；
|
||||||
|
2. AI 负载强度—控制违约率—AI 按期率三维或等高线图；
|
||||||
|
3. CPU、内存、I/O、热干扰的控制尾延迟对比；
|
||||||
|
4. 跨域请求—推理—返回—验证的时序分解图；
|
||||||
|
5. RTOS 机制逐项消融图；
|
||||||
|
6. 推理域故障期间控制响应时间序列；
|
||||||
|
7. 静态资源预留与推理有效吞吐的 Pareto 曲线；
|
||||||
|
8. AI 结果超时、回退、恢复状态机图。
|
||||||
|
|
||||||
|
## 7. 阶段验收标准
|
||||||
|
|
||||||
|
| 层次 | 验收条件 |
|
||||||
|
|---|---|
|
||||||
|
| 数据有效 | 时钟、负载、版本、拓扑和原始事件可追踪；失败样本未被静默删除 |
|
||||||
|
| 控制保障 | 在冻结的运行区间内满足控制期限，并报告样本数和观测最大值 |
|
||||||
|
| AI 可用 | 在冻结质量门槛下达到规定的按期率和新鲜度合格率 |
|
||||||
|
| 隔离有效 | 推理负载或故障对控制域的影响显著小于单域基线 |
|
||||||
|
| 代价可接受 | 同时报告资源预留、IPC、吞吐、能耗和热代价 |
|
||||||
|
| 降级有效 | AI 不可用时在 `D_fallback` 内进入预定义状态，且不依赖推理域恢复 |
|
||||||
|
|
||||||
|
“未观测到违约”仍不能代替理论最坏界；Hypervisor 分域结果也只能在已验证的硬件、配置和压力范围内成立。
|
||||||
|
|
||||||
|
## 8. 对现有设备的使用建议
|
||||||
|
|
||||||
|
- 现有 RK3588 更适合作为边缘分域或资源受限 SoC 的核心验证平台，而不是同时承担多个容量档位以构造连续谱系；
|
||||||
|
- 现有 V100 平台可作为 Linux 推理域的高压力源、吞吐参照或跨域服务端，但不需要证明其属于 RTOS 主线；
|
||||||
|
- MCU 平台应根据真实 AI 运行能力和工业 I/O 条件选取，优先验证控制期限和资源干扰，而非模型参数规模；
|
||||||
|
- 新增设备采购应由研究问题和分域实现需求驱动，不再为了补齐 `T1~T5` 档位而采购。
|
||||||
|
|
||||||
|
## 9. 建议的最小可发表闭环
|
||||||
|
|
||||||
|
在一个 MCU/SoC 同域平台和一个边缘分域平台上完成以下闭环即可形成聚焦的系统研究：
|
||||||
|
|
||||||
|
1. 证明 AI 负载会通过可识别的资源路径干扰控制实时性；
|
||||||
|
2. 给出 RTOS 预算、隔离、准入和降级机制；
|
||||||
|
3. 实现 RTOS 控制域与 Linux 推理域的有界异步通信；
|
||||||
|
4. 与普通 Linux、PREEMPT_RT 或单域方案进行同平台比较；
|
||||||
|
5. 在过载、热稳态和故障注入下验证控制保护；
|
||||||
|
6. 同时报告 AI 结果按期率和资源代价；
|
||||||
|
7. 明确结论只覆盖 MCU/SoC 与边缘任务关键系统，不外推到 T1/T2 集群。
|
||||||
|
|
||||||
|
这一闭环比覆盖全部硬件档位更容易建立清晰的因果关系，也更直接回应“AI 引入后，任务关键系统如何保持实时”的核心问题。
|
||||||
-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,740 @@
|
|||||||
|
# 基础设备配置（四层级 × 三档算力分级）
|
||||||
|
|
||||||
|
> 版本: v2.0 起草日期: 2026-09-18
|
||||||
|
> 设计目标: 为翼辉 SylixOS 调度框架研究建立 **集群→桌面→边→端** 四级硬件体系，每级内再按 **低/中/高** 三档细分
|
||||||
|
> 现有硬件全覆盖: T2-L（4×V100 SXM）+ T3-L / T4-H（RK3588 工业盒）| 需新增: T1 集群扩展 + 其余档位
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. 分级体系总览
|
||||||
|
|
||||||
|
### 0.1 分级维度与分档规则
|
||||||
|
|
||||||
|
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度——容量直接决定可承载的模型规模，且与功耗、散热、互联架构强相关，四个层级可连续衔接、无断层。
|
||||||
|
|
||||||
|
**分档规则**: 相邻两档的边界值归入**上界一侧**
|
||||||
|
|
||||||
|
| 层级 | 代码 | 低级 | 中级 | 高级 |
|
||||||
|
| -------- | --- | --------------- | ---------------- | ---------------- |
|
||||||
|
| **端级** | 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** |
|
||||||
|
|
||||||
|
> 边界值归属示例: 8 GB → 端-高；16 GB → 边-低；64 GB → 边-高；128 GB → 桌-低；512 GB → 桌-高；1 TB → 集-低。
|
||||||
|
|
||||||
|
### 0.2 全谱系总表（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 | |
|
||||||
|
| **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 设计原则
|
||||||
|
|
||||||
|
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），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T1. 集群级 — 512 G ~ 2 T
|
||||||
|
|
||||||
|
### T1.1 定位
|
||||||
|
|
||||||
|
大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。
|
||||||
|
|
||||||
|
### T1.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T1-L 集群-低 | T1-H 集群-高 |
|
||||||
|
| ----------- | --------------------- | --------------------------- |
|
||||||
|
| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
|
||||||
|
| **节点数** | 4 节点 | 4 节点 |
|
||||||
|
| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||||
|
| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) |
|
||||||
|
| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s |
|
||||||
|
| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB |
|
||||||
|
| **整机功耗** | ~6.6 kW | 20~25 kW |
|
||||||
|
| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
|
||||||
|
| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
|
||||||
|
|
||||||
|
#### T1.2.1 T1-L 集群-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
|
||||||
|
|
||||||
|
| 项目 | 规格 | 数量 | 备注 |
|
||||||
|
| --------- | ------------------------------------------------ | ------------- | --------------------------- |
|
||||||
|
| **计算节点** | 同 T2-L 桌面级配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
|
||||||
|
| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 |
|
||||||
|
| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 |
|
||||||
|
| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB |
|
||||||
|
| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB |
|
||||||
|
| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 |
|
||||||
|
| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 |
|
||||||
|
| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L |
|
||||||
|
| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW |
|
||||||
|
| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 |
|
||||||
|
|
||||||
|
**显存与算力**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| --------------- | ---------------------------------- |
|
||||||
|
| **总显存** | **512 GB** (4 × 128GB) |
|
||||||
|
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||||
|
| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) |
|
||||||
|
| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | ------- | ----- | ------------------ |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 |
|
||||||
|
| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray |
|
||||||
|
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) |
|
||||||
|
| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray |
|
||||||
|
|
||||||
|
> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
|
||||||
|
|
||||||
|
#### T1.2.2 T1-H 集群-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
|
||||||
|
|
||||||
|
| 项目 | 规格 | 数量 | 备注 |
|
||||||
|
| ------- | ----------------------------------------- | --------- | --------------------- |
|
||||||
|
| 计算节点 | 同 T2-H 桌面级配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
|
||||||
|
| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s |
|
||||||
|
| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 |
|
||||||
|
| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB |
|
||||||
|
| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 |
|
||||||
|
| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 |
|
||||||
|
| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 |
|
||||||
|
| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 |
|
||||||
|
| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | -------- | ----- | -------------------- |
|
||||||
|
| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang |
|
||||||
|
| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM |
|
||||||
|
| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI |
|
||||||
|
| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM |
|
||||||
|
|
||||||
|
### T1.3 SylixOS 要求（T1 通用）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| ------------------ | ------------------------------- | ------------------------------ |
|
||||||
|
| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） |
|
||||||
|
| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） |
|
||||||
|
| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） |
|
||||||
|
| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） |
|
||||||
|
| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** |
|
||||||
|
|
||||||
|
### T1.4 研究角度
|
||||||
|
|
||||||
|
- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟
|
||||||
|
- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟
|
||||||
|
- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性
|
||||||
|
- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益）
|
||||||
|
- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T2. 桌面级 — 64 G ~ 512 G
|
||||||
|
|
||||||
|
### T2.1 定位
|
||||||
|
|
||||||
|
单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。
|
||||||
|
|
||||||
|
### T2.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T2-L 桌面-低 | T2-M 桌面-中 | T2-H 桌面-高 |
|
||||||
|
| ----------- | ---------------------- | --------------------------- | --------------------------- |
|
||||||
|
| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） |
|
||||||
|
| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||||
|
| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) |
|
||||||
|
| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 |
|
||||||
|
| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW |
|
||||||
|
| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 |
|
||||||
|
| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 |
|
||||||
|
| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 |
|
||||||
|
| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
|
||||||
|
| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
|
||||||
|
|
||||||
|
#### T2.2.1 T2-L 桌面-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
|
||||||
|
|
||||||
|
| # | 部件 | 型号 / 规格 | 数量 | 备注 |
|
||||||
|
| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
|
||||||
|
| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | |
|
||||||
|
| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | |
|
||||||
|
| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 |
|
||||||
|
| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 |
|
||||||
|
| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU |
|
||||||
|
| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | |
|
||||||
|
| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 |
|
||||||
|
| 8 | 机箱 | 塔式一体定制机箱 | 1 | |
|
||||||
|
| 9 | 主电源 | 长城全模组 1650W | 1 | |
|
||||||
|
| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 |
|
||||||
|
| 11 | 散热器 | SP3 高性能散热器 | 1 | |
|
||||||
|
| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | |
|
||||||
|
| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** |
|
||||||
|
|
||||||
|
**显存与算力**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| ---------- | --------------------------- |
|
||||||
|
| **总显存** | **128 GB** (4 × 32GB HBM2) |
|
||||||
|
| 单卡显存 | 32 GB HBM2 |
|
||||||
|
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||||
|
| 总算力 (FP16) | ~500 TFLOPS |
|
||||||
|
| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) |
|
||||||
|
| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) |
|
||||||
|
| **整机功耗** | **~1650 W** (满载) |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | ------ | ----- | ------------------- |
|
||||||
|
| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM |
|
||||||
|
| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM |
|
||||||
|
| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) |
|
||||||
|
| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM |
|
||||||
|
| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp |
|
||||||
|
| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper |
|
||||||
|
|
||||||
|
#### T2.2.2 T2-M 桌面-中 — 8×V100 SXM = 256 GB
|
||||||
|
|
||||||
|
在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
|
||||||
|
|
||||||
|
| 项目 | 规格 | 变更点 |
|
||||||
|
| --------- | ----------------------------------------------- | ------------------ |
|
||||||
|
| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 |
|
||||||
|
| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 |
|
||||||
|
| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 |
|
||||||
|
| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 |
|
||||||
|
| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 |
|
||||||
|
| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory |
|
||||||
|
| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 |
|
||||||
|
| 散热 | 360 液冷 ×2 + 机箱风道强化 | — |
|
||||||
|
| **整机功耗** | **~3.0~3.3 kW** | +100% |
|
||||||
|
| **总算力** | **~1000 TFLOPS (FP16)** | +100% |
|
||||||
|
|
||||||
|
**可运行模型（新增/提升）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||||
|
| ------------------------ | ---------- | ------ | ----- | ------------------ |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 |
|
||||||
|
| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 |
|
||||||
|
| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 |
|
||||||
|
|
||||||
|
> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。
|
||||||
|
|
||||||
|
#### T2.2.3 T2-H 桌面-高 — 4×H100 SXM5 = 320 GB
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| ------- | ---------------------------------------- |
|
||||||
|
| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） |
|
||||||
|
| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) |
|
||||||
|
| 单卡显存 | 80 GB HBM3 |
|
||||||
|
| NVLink | 900 GB/s (GPU↔GPU) |
|
||||||
|
| CPU | AMD EPYC 9654 (96C/192T) ×1~2 |
|
||||||
|
| 内存 | 512 GB DDR5-4800 ECC |
|
||||||
|
| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） |
|
||||||
|
| 存储 | 4 TB NVMe RAID0（模型权重加载） |
|
||||||
|
| 散热 | **强制液冷（冷板式）**，风冷不可行 |
|
||||||
|
| 电源 | 2 × 3000W 冗余 / 220V |
|
||||||
|
| **整机功耗** | **~4.5~6.5 kW** |
|
||||||
|
| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS |
|
||||||
|
|
||||||
|
**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。
|
||||||
|
|
||||||
|
**可运行模型（新增/提升）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||||
|
| ------------------------ | ---------- | ------- | ----- | ----------------- |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 |
|
||||||
|
| LLaMA-3-70B | FP16 | ~140 GB | 2 | — |
|
||||||
|
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 |
|
||||||
|
| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 |
|
||||||
|
|
||||||
|
### T2.3 SylixOS 要求（T2 三档通用）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| ----------------- | ----------------------------- | ------------------- |
|
||||||
|
| x86 BSP | SylixOS 2.x LTS x86 | 低 |
|
||||||
|
| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） |
|
||||||
|
| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 |
|
||||||
|
| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） |
|
||||||
|
| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 |
|
||||||
|
| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） |
|
||||||
|
|
||||||
|
### T2.4 对照组 OS
|
||||||
|
|
||||||
|
- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM
|
||||||
|
- **辅助对照**: CentOS Stream 9 + RT 内核（可选）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T3. 边级 — 8 G ~ 64 G
|
||||||
|
|
||||||
|
### T3.1 定位
|
||||||
|
|
||||||
|
边缘 AI 推理与工业控制并发。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性——推理任务与实时控制任务共享内存带宽时的隔离能力。
|
||||||
|
|
||||||
|
### 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.2.1 T3-L 边-低 — RK3588 16GB 工业盒（现有设备）
|
||||||
|
|
||||||
|
**这是现有 RK3588 设备的标准归属档位**（16 GB 统一内存落在边级区间内），也是唯一可零成本立即开展研究的边级档位。
|
||||||
|
|
||||||
|
| 项目 | 规格 | 备注 |
|
||||||
|
| --------- | --------------------------------------- | --------------------- |
|
||||||
|
| SoC | Rockchip RK3588（同 T4-H） | SylixOS BSP 与 T4 共用 |
|
||||||
|
| 内存 | **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 内存翻倍，可跑更大模型 |
|
||||||
|
|
||||||
|
**备选方案（同档位、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 风险高。
|
||||||
|
|
||||||
|
#### T3.2.2 T3-M 边-中 — NVIDIA Jetson AGX Orin 32GB
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | -------------------------------------------------- |
|
||||||
|
| **SoC** | NVIDIA T234（Grace 系列衍生） |
|
||||||
|
| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） |
|
||||||
|
| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores |
|
||||||
|
| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） |
|
||||||
|
| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) |
|
||||||
|
| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） |
|
||||||
|
| 内存带宽 | 204.8 GB/s |
|
||||||
|
| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） |
|
||||||
|
| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） |
|
||||||
|
| 存储 | 64GB eMMC + M.2 NVMe（可扩展） |
|
||||||
|
| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 |
|
||||||
|
| 视频接口 | HDMI 2.1 + DP 1.4a |
|
||||||
|
| USB | 4× USB 3.2 + 2× USB 2.0 |
|
||||||
|
| PCIe | PCIe Gen4 ×4（可扩展外设） |
|
||||||
|
| MIPI CSI | 4 通道（可接工业相机） |
|
||||||
|
| 尺寸 | 100mm × 87mm（核心模块） |
|
||||||
|
| **出厂 OS** | Ubuntu 20.04 LTS (L4T) |
|
||||||
|
| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） |
|
||||||
|
|
||||||
|
**选择 Jetson AGX Orin 的理由**
|
||||||
|
|
||||||
|
1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈
|
||||||
|
2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台
|
||||||
|
3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证
|
||||||
|
4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
|
||||||
|
5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
|
||||||
|
|
||||||
|
#### T3.2.3 T3-H 边-高 — 64 GB 档（两条路线）
|
||||||
|
|
||||||
|
| 路线 | 主推 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，带宽受限 | 功耗/体积/散热不适合现场部署 |
|
||||||
|
| **适用场景** | 边缘现场、宽温环境、低功耗 | 边缘机柜、算力下沉、多模型并发 |
|
||||||
|
|
||||||
|
**可运行模型（T3 三档合并）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 预期 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 |
|
||||||
|
|
||||||
|
### T3.3 SylixOS 要求（T3）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| -------------------- | --------------------------------------- | ---------------------------- |
|
||||||
|
| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
|
||||||
|
| **RK3588 BSP（T3-L）** | 与 T4-H 共用同一 BSP，零额外风险 | **极低** |
|
||||||
|
| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
|
||||||
|
| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
|
||||||
|
| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
|
||||||
|
| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
|
||||||
|
| 独立显存管理（T3-H B 路线） | x86 + 独显的显存分配与实时性 | 中 |
|
||||||
|
|
||||||
|
> **取舍**: Jetson 路线优势在 CUDA 生态统一 + 275 TOPS + DLA；RK3588-16GB（T3-L）优势在 SylixOS BSP 风险极低 + -40~60℃ 工业级宽温。**建议 T3-L 直接用现有 RK3588 起步，T3-M/H 待 Jetson BSP 确认后再采购。**
|
||||||
|
|
||||||
|
### T3.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 |
|
||||||
|
|
||||||
|
### T3.5 功率采集
|
||||||
|
|
||||||
|
| 设备 | 用途 | 适用档位 |
|
||||||
|
| ----------------------------- | --------------------- | ----------- |
|
||||||
|
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T3-L / T3-M |
|
||||||
|
| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
|
||||||
|
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T3-M / T3-H |
|
||||||
|
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-H B 路线 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T4. 端级 — 1 G ~ 8 G
|
||||||
|
|
||||||
|
### T4.1 定位
|
||||||
|
|
||||||
|
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这是 RTOS 杀手锏场景——资源越紧张，RTOS 调度隔离的价值越大。
|
||||||
|
|
||||||
|
### T4.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T4-L 端-低 | T4-M 端-中 | T4-H 端-高 |
|
||||||
|
| ----------- | ---------------------- | -------------------- | ------------------------------ |
|
||||||
|
| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 |
|
||||||
|
| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano |
|
||||||
|
| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) |
|
||||||
|
| **功耗** | 3~5 W | 5~10 W | 7~21 W |
|
||||||
|
| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） |
|
||||||
|
| **供电** | DC 5V / 12V | DC 12V | DC 12V |
|
||||||
|
| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ |
|
||||||
|
| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
|
||||||
|
| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
|
||||||
|
|
||||||
|
#### T4.2.1 T4-L 端-低 — RK3568 核心板（1~2 GB）
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | -------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3568 (22nm) |
|
||||||
|
| CPU | 4× Cortex-A55 @ 2.0 GHz |
|
||||||
|
| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） |
|
||||||
|
| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） |
|
||||||
|
| 内存带宽 | ~25.6 GB/s |
|
||||||
|
| GPU | Mali-G52（仅辅助显示） |
|
||||||
|
| 存储 | 8~16 GB eMMC |
|
||||||
|
| 网络 | 1× 千兆 + 可选 WiFi |
|
||||||
|
| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） |
|
||||||
|
| **功耗** | **3~5 W**（无风扇被动散热） |
|
||||||
|
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||||
|
| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） |
|
||||||
|
| 参考价格 | ~300~800 RMB（核心板/开发板） |
|
||||||
|
|
||||||
|
**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
|
||||||
|
**定位价值**: 谱系最低档，用于测出「LLM 推理到底能把实时性压到多差」的**下界**，以及 RTOS 在极小内存下能否守住 1ms。
|
||||||
|
|
||||||
|
#### T4.2.2 T4-M 端-中 — RK3576 核心板（2~4 GB）
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | ---------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3576 (8nm) |
|
||||||
|
| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） |
|
||||||
|
| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 |
|
||||||
|
| **内存** | **2~4 GB LPDDR5**（统一内存） |
|
||||||
|
| 内存带宽 | ~40 GB/s |
|
||||||
|
| **功耗** | **5~10 W**（无风扇被动） |
|
||||||
|
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||||
|
| 参考价格 | ~600~1,500 RMB |
|
||||||
|
|
||||||
|
**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
|
||||||
|
**定位价值**: 端级主力档，算力是 T4-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
|
||||||
|
|
||||||
|
#### T4.2.3 T4-H 端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
|
||||||
|
|
||||||
|
**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
|
||||||
|
|
||||||
|
| 项目 | 规格 | 说明 |
|
||||||
|
| --------- | --------------------------------------------------- | ------------------------ |
|
||||||
|
| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** |
|
||||||
|
| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 |
|
||||||
|
| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 |
|
||||||
|
| GPU | Mali-G610 MC4 | 仅辅助显示 |
|
||||||
|
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
|
||||||
|
| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
|
||||||
|
| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T3-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 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
|
||||||
|
|
||||||
|
**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | --------------------------------------------------- |
|
||||||
|
| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） |
|
||||||
|
| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
|
||||||
|
| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
|
||||||
|
| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
|
||||||
|
| 优势 | **T4 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3-M 同栈 |
|
||||||
|
| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
|
||||||
|
| 参考价格 | ~$249（开发套件） |
|
||||||
|
|
||||||
|
**可运行模型（T4-H）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
|
||||||
|
| ------------------------- | ---- | ------- | ----------- | ----- |
|
||||||
|
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM |
|
||||||
|
| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM |
|
||||||
|
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
|
||||||
|
| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
|
||||||
|
|
||||||
|
#### T4.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
|
||||||
|
|
||||||
|
**系统 (System)**
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| ------- | ---------------------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3588 (8nm) |
|
||||||
|
| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） |
|
||||||
|
| MCU | Cortex-M0 @200 MHz（协处理，可选） |
|
||||||
|
| GPU | Mali-G610 MC4 |
|
||||||
|
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
|
||||||
|
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T4-H |
|
||||||
|
| **显存** | 统一内存（NPU 与 CPU 共享） |
|
||||||
|
|
||||||
|
**存储 / 扩展**
|
||||||
|
|
||||||
|
- EMMC 64 GB（系统盘）
|
||||||
|
- 1× TF 卡槽（存储扩展）
|
||||||
|
- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒）
|
||||||
|
|
||||||
|
**出厂软件**
|
||||||
|
|
||||||
|
- 操作系统: **Ubuntu 22.04**（出厂预装）
|
||||||
|
- 验证方案: 替换为 SylixOS BSP for RK3588，保留 Ubuntu 22.04 作为对照组
|
||||||
|
|
||||||
|
**算力与功耗（T4-H 档）**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| ------------------ | ------------------------------- |
|
||||||
|
| **可用显存** | **8 GB**（16 GB 板分区限额） |
|
||||||
|
| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) |
|
||||||
|
| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) |
|
||||||
|
| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） |
|
||||||
|
| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
|
||||||
|
| **TDP** | **7~21 W**（无风扇被动散热） |
|
||||||
|
|
||||||
|
### T4.3 SylixOS 要求（T4）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 | 适用档位 |
|
||||||
|
| ---------------------- | --------------------------------------- | -------------------- | --------- |
|
||||||
|
| **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 |
|
||||||
|
|
||||||
|
### T4.4 对照组 OS
|
||||||
|
|
||||||
|
- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
|
||||||
|
- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
|
||||||
|
- T4-L / T4-M: Buildroot + PREEMPT_RT
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. 跨档位对比总表
|
||||||
|
|
||||||
|
### 5.1 全档位硬件规格对比
|
||||||
|
|
||||||
|
| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | 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 | 高 / 中 |
|
||||||
|
| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） |
|
||||||
|
| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 |
|
||||||
|
| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 |
|
||||||
|
| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 |
|
||||||
|
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 |
|
||||||
|
|
||||||
|
### 5.2 模型规模梯度
|
||||||
|
|
||||||
|
| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
|
||||||
|
| -------- | --------------------------- | ---------- | ------- | -------------- |
|
||||||
|
| 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 |
|
||||||
|
| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 |
|
||||||
|
| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B |
|
||||||
|
| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 |
|
||||||
|
| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 |
|
||||||
|
| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 |
|
||||||
|
|
||||||
|
### 5.3 SylixOS 调度框架验证重点
|
||||||
|
|
||||||
|
| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
|
||||||
|
| ----- | ----------- | ---------------------------------- | -------------------------- |
|
||||||
|
| 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 |
|
||||||
|
| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 |
|
||||||
|
| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s |
|
||||||
|
| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 |
|
||||||
|
| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS |
|
||||||
|
| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 |
|
||||||
|
|
||||||
|
### 5.4 基线 OS 对照
|
||||||
|
|
||||||
|
| 档位 | SylixOS 实验组 | 主对照 (Linux RT) | 虚拟化对照 | 容器对照 |
|
||||||
|
| ------- | ---------------------- | --------------------- | -------------- | --------- |
|
||||||
|
| 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 |
|
||||||
|
| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||||
|
| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. 采购与获取计划
|
||||||
|
|
||||||
|
| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
|
||||||
|
| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
|
||||||
|
| **P0** | T3-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 路线对照 |
|
||||||
|
| **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 档 |
|
||||||
|
| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） |
|
||||||
|
| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 |
|
||||||
|
| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） |
|
||||||
|
| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 |
|
||||||
|
|
||||||
|
### 降本策略
|
||||||
|
|
||||||
|
1. **P0 零成本起步**: T2-L + 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 降配替代），谱系不断。
|
||||||
|
4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
|
||||||
|
5. **T3-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
|
||||||
|
6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. SylixOS BSP 适配 Checklist（跨档位汇总）
|
||||||
|
|
||||||
|
### 7.1 x86 BSP（T2 全档 + T1 全档）
|
||||||
|
|
||||||
|
- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动
|
||||||
|
- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度
|
||||||
|
- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心）
|
||||||
|
- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M）
|
||||||
|
- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H）
|
||||||
|
- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举
|
||||||
|
- [ ] nvidia-smi / DCGM 监控
|
||||||
|
- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行
|
||||||
|
- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属）
|
||||||
|
- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属）
|
||||||
|
- [ ] NCCL / MPI 分布式通信库（T1 专属）
|
||||||
|
- [ ] IPMI / BMC 功耗采集
|
||||||
|
- [ ] tickless + CPU 隔离 + 中断亲和性
|
||||||
|
- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
|
||||||
|
|
||||||
|
### 7.2 ARM64 BSP — T234 / Ampere（T3-M / T3-H-A / T4-H 路线B）
|
||||||
|
|
||||||
|
- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
|
||||||
|
- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
|
||||||
|
- [ ] Jetson Ampere GPU CUDA 驱动
|
||||||
|
- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属）
|
||||||
|
- [ ] 16/32/64 GB LPDDR5 统一内存管理
|
||||||
|
- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W)
|
||||||
|
- [ ] 10GbE 网络驱动
|
||||||
|
- [ ] MIPI CSI 工业相机接口
|
||||||
|
- [ ] PCIe Gen4 扩展
|
||||||
|
- [ ] 温度传感器 + 降频阈值
|
||||||
|
|
||||||
|
### 7.3 ARM64 BSP — RK3588（T4-H / T3-L）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
|
||||||
|
- [ ] CPU 频率独立调节 (governor)
|
||||||
|
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T3-L ↔ T4-H 切换）
|
||||||
|
- [ ] tickless / idle hook
|
||||||
|
- [ ] 看门狗驱动
|
||||||
|
- [ ] **rknn / RKLLM NPU 驱动**（核心）
|
||||||
|
- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位）
|
||||||
|
- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0）
|
||||||
|
- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动
|
||||||
|
- [ ] CAN ×2 驱动
|
||||||
|
- [ ] RS485 ×2 + RS232 ×1 驱动
|
||||||
|
- [ ] GPIO 子系统
|
||||||
|
- [ ] HDMI 输出（调试）
|
||||||
|
- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
|
||||||
|
|
||||||
|
### 7.4 ARM64 BSP — RK3576（T4-M）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
|
||||||
|
- [ ] 6 TOPS NPU 驱动（RKNN 栈）
|
||||||
|
- [ ] 2~4 GB LPDDR5 内存管理
|
||||||
|
- [ ] CAN / RS485 / 千兆网络驱动
|
||||||
|
- [ ] 低功耗被动散热下的频率/温度联动
|
||||||
|
|
||||||
|
### 7.5 ARM64 BSP — RK3568（T4-L）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3568（4×A55 SMP）
|
||||||
|
- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
|
||||||
|
- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点）
|
||||||
|
- [ ] CAN / RS485 / 千兆网络驱动
|
||||||
|
- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证
|
||||||
@@ -0,0 +1,282 @@
|
|||||||
|
# SylixOS 混合实时任务与 AI 推理实验设计
|
||||||
|
|
||||||
|
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](../基础设备.md)，扩展自[原实验设计](../实验设计.md)。
|
||||||
|
> 本文给出待执行方案，不代表已有测试结果。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
|
||||||
|
|
||||||
|
## 1. 研究目标与实验范围
|
||||||
|
|
||||||
|
研究问题是：在端、边、桌面、集群不同资源条件下，SylixOS 的调度与资源隔离能否在保持实时任务截止期的同时，提高 AI 推理服务的有效吞吐和能效？
|
||||||
|
|
||||||
|
| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| RQ1：混合负载下的实时性 | OS、调度策略、干扰强度 | 唤醒延迟、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
|
||||||
|
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | P99.9 延迟、有效吞吐、拒绝率 | 默认、完整方案与逐项消融 |
|
||||||
|
| RQ3：功耗预算下的运行能力 | 频率、空闲策略、推理并发 | J/token、温度、违约率 | 满足同一服务质量约束的配置比较 |
|
||||||
|
| RQ4：规模扩展后的瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
|
||||||
|
|
||||||
|
执行分为两层：**核心实验使用现有 T2-L、T3-L 和 T4-H 内存受限配置；其他八档属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM 是主负载，YOLO 检测和语音识别是可选混合负载；训练不纳入主实验。
|
||||||
|
|
||||||
|
## 2. 设备分层与实验平台
|
||||||
|
|
||||||
|
### 2.1 四层级、十一档实验映射
|
||||||
|
|
||||||
|
沿用设备文档的档位标签，实际容量单列。设备文档中“512 GB 边界归桌面高档”与“512 GB 集群标为 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 | 二选一，分别标识架构 | 大模型并发与容量上限 |
|
||||||
|
| T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
|
||||||
|
| T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
|
||||||
|
| T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
|
||||||
|
| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信与分布式推理 |
|
||||||
|
| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式服务与能效 |
|
||||||
|
|
||||||
|
GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
|
||||||
|
|
||||||
|
### 2.2 平台 A：现有 V100 服务器
|
||||||
|
|
||||||
|
依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
|
||||||
|
|
||||||
|
实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
|
||||||
|
|
||||||
|
分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
|
||||||
|
|
||||||
|
### 2.3 平台 B：现有 RK3588 工业盒
|
||||||
|
|
||||||
|
依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
|
||||||
|
|
||||||
|
- B16：全量 16 GB，记为 T3-L。
|
||||||
|
- B8：同板施加 8 GB 限额，记为 T4-H 受限配置；两种配置顺序运行。
|
||||||
|
- 原生 NPU 是首轮路径；所谓“6+26 TOPS”仅为设备文档中的组合标称。扩展芯片型号、连接方式、模型格式和任务拆分能力通过后，才增加独立对照，不假定两者能共同加速同一 LLM。
|
||||||
|
- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
|
||||||
|
|
||||||
|
**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
|
||||||
|
|
||||||
|
### 2.4 测量设备
|
||||||
|
|
||||||
|
| 测量对象 | 工具与接线 | 要求 |
|
||||||
|
|---|---|---|
|
||||||
|
| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 |
|
||||||
|
| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 |
|
||||||
|
| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 |
|
||||||
|
| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 |
|
||||||
|
| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 |
|
||||||
|
|
||||||
|
传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。
|
||||||
|
|
||||||
|
## 3. 软件与模型准入
|
||||||
|
|
||||||
|
### 3.1 分阶段准入门槛
|
||||||
|
|
||||||
|
| 门槛 | 验证内容 | 通过证据 | 失败后的处理 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 |
|
||||||
|
| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 |
|
||||||
|
| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 |
|
||||||
|
| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
|
||||||
|
| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
|
||||||
|
|
||||||
|
SylixOS 能启动不等于 CUDA、RKLLM、RKNN、NCCL、Ray 或 RDMA 已可用。设备文档列出的软件栈均按候选路线处理，冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后再比较。
|
||||||
|
|
||||||
|
若仅能采用“SylixOS 实时域 + Linux 推理域”，应作为单独的异构系统架构组，注明核分配、通信和内存共享方式。该结果不能写成 SylixOS 原生 GPU/NPU 推理结论。
|
||||||
|
|
||||||
|
### 3.2 模型梯度与用途
|
||||||
|
|
||||||
|
| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 |
|
||||||
|
| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 |
|
||||||
|
| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 |
|
||||||
|
| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 |
|
||||||
|
| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
|
||||||
|
| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
|
||||||
|
|
||||||
|
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。原稿中的 tokens/s、FPS、内存估计作为待验证参考，不作为已知性能。
|
||||||
|
|
||||||
|
### 3.3 输入与正确性控制
|
||||||
|
|
||||||
|
LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。
|
||||||
|
|
||||||
|
YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。
|
||||||
|
|
||||||
|
## 4. 指标定义与采集口径
|
||||||
|
|
||||||
|
### 4.1 实时性与系统开销
|
||||||
|
|
||||||
|
对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。
|
||||||
|
|
||||||
|
| 指标 | 定义 | 汇总 |
|
||||||
|
|---|---|---|
|
||||||
|
| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 |
|
||||||
|
| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 |
|
||||||
|
| 响应时间 | f_i − r_i | 分位数、观测最大值 |
|
||||||
|
| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 |
|
||||||
|
| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 |
|
||||||
|
| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 |
|
||||||
|
| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 |
|
||||||
|
|
||||||
|
缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。
|
||||||
|
|
||||||
|
### 4.2 推理服务
|
||||||
|
|
||||||
|
在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。
|
||||||
|
|
||||||
|
- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。
|
||||||
|
- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。
|
||||||
|
- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。
|
||||||
|
- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。
|
||||||
|
- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。
|
||||||
|
|
||||||
|
### 4.3 能耗与热状态
|
||||||
|
|
||||||
|
在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。
|
||||||
|
|
||||||
|
同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。
|
||||||
|
|
||||||
|
报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。
|
||||||
|
|
||||||
|
## 5. 对照组与变量控制
|
||||||
|
|
||||||
|
### 5.1 OS 与部署组
|
||||||
|
|
||||||
|
| 编号 | 配置 | 作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 |
|
||||||
|
| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
|
||||||
|
| O2 | SylixOS 默认配置 | 原生系统基线 |
|
||||||
|
| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
|
||||||
|
| O4 | Linux RT 等预算调优 | 避免仅一侧调优造成偏差 |
|
||||||
|
| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
|
||||||
|
|
||||||
|
平台 B 原稿列出的出厂 Ubuntu 22.04 先核对镜像；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，明确区分“OS 调度效应”与“系统方案效应”。
|
||||||
|
|
||||||
|
### 5.2 配置控制与消融
|
||||||
|
|
||||||
|
所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。
|
||||||
|
|
||||||
|
完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。
|
||||||
|
|
||||||
|
## 6. 负载设计
|
||||||
|
|
||||||
|
### 6.1 实时任务
|
||||||
|
|
||||||
|
主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。
|
||||||
|
|
||||||
|
任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
|
||||||
|
|
||||||
|
### 6.2 背景干扰与推理到达
|
||||||
|
|
||||||
|
| 场景 | 内容 | 目的 |
|
||||||
|
|---|---|---|
|
||||||
|
| L0 | 仅 RT | 实时性下界与测量开销 |
|
||||||
|
| L1 | 仅推理 | 最大可持续服务能力与独立能耗 |
|
||||||
|
| L2 | RT + LLM | 核心混合场景 |
|
||||||
|
| L3 | L2 + CPU 干扰 | 参考占用 25/50/75/100%，注明施加核心 |
|
||||||
|
| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
|
||||||
|
| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务干扰 |
|
||||||
|
| L6 | RT + LLM + YOLO（可选） | 多模型竞争与优先级影响 |
|
||||||
|
| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
|
||||||
|
|
||||||
|
推理先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 λ_ref，所有 OS 使用同一绝对到达序列，测试 0.25/0.5/0.75/1.0/1.25×λ_ref。不得各组按自身吞吐重新归一化后声称承受相同负载。
|
||||||
|
|
||||||
|
突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
|
||||||
|
|
||||||
|
## 7. 实验矩阵与具体步骤
|
||||||
|
|
||||||
|
### 7.1 核心实验
|
||||||
|
|
||||||
|
| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 |
|
||||||
|
| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 |
|
||||||
|
| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 |
|
||||||
|
| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 |
|
||||||
|
| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 |
|
||||||
|
| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 |
|
||||||
|
| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 |
|
||||||
|
| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
|
||||||
|
| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
|
||||||
|
|
||||||
|
E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
|
||||||
|
|
||||||
|
E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
|
||||||
|
|
||||||
|
### 7.2 条件扩展
|
||||||
|
|
||||||
|
| 扩展 | 前提 | 实验内容 | 结论边界 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 |
|
||||||
|
| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 |
|
||||||
|
| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 |
|
||||||
|
| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 |
|
||||||
|
| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 |
|
||||||
|
|
||||||
|
T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
|
||||||
|
|
||||||
|
跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
|
||||||
|
|
||||||
|
### 7.3 控制实验数量
|
||||||
|
|
||||||
|
不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。
|
||||||
|
|
||||||
|
## 8. 运行流程与统计方法
|
||||||
|
|
||||||
|
1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。
|
||||||
|
2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。
|
||||||
|
3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。
|
||||||
|
4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。
|
||||||
|
5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。
|
||||||
|
6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。
|
||||||
|
7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。
|
||||||
|
|
||||||
|
观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。
|
||||||
|
|
||||||
|
## 9. 验收与结果判断
|
||||||
|
|
||||||
|
验收分为“数据可用”“系统约束满足”和“研究假设得到支持”，避免将目标写成已取得结果。
|
||||||
|
|
||||||
|
| 类型 | 判据 | 说明 |
|
||||||
|
|---|---|---|
|
||||||
|
| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 |
|
||||||
|
| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 |
|
||||||
|
| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 |
|
||||||
|
| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 |
|
||||||
|
| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 |
|
||||||
|
| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 |
|
||||||
|
|
||||||
|
原稿的“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”仅保留为历史候选目标。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，正式实验前冻结，不能看完正式结果再下调阈值。原有 8/15/21 W 数值同样不直接作为跨配置统一验收值。
|
||||||
|
|
||||||
|
## 10. 数据产物与论文图表
|
||||||
|
|
||||||
|
建议按 `results/<experiment>/<platform>/<os>/<config>/<run_id>/` 保存数据，每次运行至少包含：
|
||||||
|
|
||||||
|
| 文件 | 内容 |
|
||||||
|
|---|---|
|
||||||
|
| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 |
|
||||||
|
| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 |
|
||||||
|
| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 |
|
||||||
|
| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 |
|
||||||
|
| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 |
|
||||||
|
| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 |
|
||||||
|
|
||||||
|
不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。
|
||||||
|
|
||||||
|
最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。
|
||||||
|
|
||||||
|
## 11. 实施顺序与停止条件
|
||||||
|
|
||||||
|
| 阶段 | 工作 | 完成标志 |
|
||||||
|
|---|---|---|
|
||||||
|
| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 |
|
||||||
|
| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 |
|
||||||
|
| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 |
|
||||||
|
| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 |
|
||||||
|
| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 |
|
||||||
|
| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 |
|
||||||
|
|
||||||
|
设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 324 KiB |
+421
@@ -0,0 +1,421 @@
|
|||||||
|
# 最终稿文章规划 — 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 | 与第三方文章配置一致, 可比性最高 |
|
||||||
|
|
||||||
|
---
|
||||||
@@ -0,0 +1,132 @@
|
|||||||
|
# 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 的实时调度和资源隔离在什么负载范围内能显著改善实时任务确定性，这种改善需要付出多少吞吐和能耗代价，其优势又会在哪个硬件档位开始减弱。
|
||||||
|
|
||||||
|
如果数据支持该关系，就形成四层硬件谱系、混合负载实时保号和统一评测方法三项论文贡献；如果某些档位不支持，也应把适配失败、容量上限和优势消失的边界作为研究结论的一部分。
|
||||||
|
|
||||||
@@ -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,155 @@
|
|||||||
|
# 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` 服务器 / 集群
|
||||||
|
|
||||||
|
其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
|
||||||
|
|
||||||
|
这套验证矩阵支撑以下四类判断：
|
||||||
|
|
||||||
|
- RTOS 优势在哪些部署形态下最明显；
|
||||||
|
- 这些优势来自哪些系统机制；
|
||||||
|
- 为维持实时保障需要付出多少吞吐和能耗代价；
|
||||||
|
- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
|
||||||
|
|
||||||
|
这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
|
||||||
|
|
||||||
|
### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
|
||||||
|
|
||||||
|
项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
|
||||||
|
|
||||||
|
证据至少包括三层：
|
||||||
|
|
||||||
|
- **人工智能目标负载层**：
|
||||||
|
`TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
|
||||||
|
- **关键保障负载层**：
|
||||||
|
`deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
|
||||||
|
- **系统协同层**：
|
||||||
|
有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
|
||||||
|
|
||||||
|
## 项目边界
|
||||||
|
|
||||||
|
### 1. 应用背景与研究对象
|
||||||
|
|
||||||
|
项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
|
||||||
|
|
||||||
|
- 大型跨平台实时操作系统；
|
||||||
|
- 任务关键系统；
|
||||||
|
- 人工智能目标负载。
|
||||||
|
|
||||||
|
其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
|
||||||
|
|
||||||
|
### 2. 评价重点
|
||||||
|
|
||||||
|
项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
|
||||||
|
|
||||||
|
- AI 目标负载是否按时完成；
|
||||||
|
- 关键保障负载是否满足截止期；
|
||||||
|
- 系统是否在长时间运行中保持稳定；
|
||||||
|
- 满足这些约束后，吞吐与能耗代价是否可接受。
|
||||||
|
|
||||||
|
### 3. 算法与系统的关系
|
||||||
|
|
||||||
|
量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
|
||||||
|
|
||||||
|
- 它们如何改变时延分布；
|
||||||
|
- 如何影响内存占用和带宽争抢；
|
||||||
|
- 如何改变调度器和资源管理策略。
|
||||||
|
|
||||||
|
因此，项目重点落在系统机制、调度策略和资源治理能力上。
|
||||||
|
|
||||||
|
对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
|
||||||
|
|
||||||
|
因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
|
||||||
|
|
||||||
|
### 4. 成果形态
|
||||||
|
|
||||||
|
项目成果需要形成完整的方法与证据体系，包括：
|
||||||
|
|
||||||
|
- 可解释的方法；
|
||||||
|
- 可复现的证据；
|
||||||
|
- 明确的适用边界；
|
||||||
|
- 跨部署形态可比较的规律；
|
||||||
|
- 能被学术界和产业界共同理解的结论。
|
||||||
|
|
||||||
|
在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
|
||||||
|
|
||||||
|
## 这个项目最后要交付什么
|
||||||
|
|
||||||
|
项目最终交付物至少应包括：
|
||||||
|
|
||||||
|
1. 一套面向任务关键系统的 SylixOS 实时保障机制；
|
||||||
|
2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
|
||||||
|
3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
|
||||||
|
4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
|
||||||
|
5. 一套可用于产业沟通和产品表达的技术叙事。
|
||||||
|
|
||||||
|
## 判断项目是否成功，要看什么
|
||||||
|
|
||||||
|
要看：
|
||||||
|
|
||||||
|
- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
|
||||||
|
- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
|
||||||
|
- 吞吐损失是否在可接受范围；
|
||||||
|
- 能耗和热稳定性是否同步改善或至少可解释；
|
||||||
|
- 结论是否能跨部署形态成立；
|
||||||
|
- 优势边界和失败边界是否都被讲清楚。
|
||||||
|
|
||||||
|
## 最后一句话
|
||||||
|
|
||||||
|
这个项目的本质是：
|
||||||
|
|
||||||
|
> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**
|
||||||
@@ -0,0 +1,283 @@
|
|||||||
|
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
|
||||||
|
|
||||||
|
## 0. 核心问题
|
||||||
|
|
||||||
|
本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
|
||||||
|
|
||||||
|
> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
|
||||||
|
|
||||||
|
这里有三个基础判断：
|
||||||
|
|
||||||
|
1. **研究对象是实时操作系统平台**；
|
||||||
|
2. **人工智能推理在系统中承担目标负载角色**；
|
||||||
|
3. **硬件条件以验证矩阵形式组织研究证据**。
|
||||||
|
|
||||||
|
本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
|
||||||
|
|
||||||
|
在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，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、多节点集群 | 跨节点通信、分布式协同与规模扩展 |
|
||||||
|
|
||||||
|
这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
|
||||||
|
|
||||||
|
其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
|
||||||
|
|
||||||
|
### 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、网络互联、PTP │
|
||||||
|
└───────────────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
|
||||||
|
|
||||||
|
### 2.1 这套技术栈的意义
|
||||||
|
|
||||||
|
这套表达用于把三个维度彻底拆开：
|
||||||
|
|
||||||
|
- `T5~T1` 回答**在哪里验证**；
|
||||||
|
- 五种算力基础回答**基于什么资源形态验证**；
|
||||||
|
- 五层技术栈回答**系统内部怎么组织与保障**。
|
||||||
|
|
||||||
|
这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
|
||||||
|
|
||||||
|
### 2.2 人工智能目标负载到 RTOS 任务的映射
|
||||||
|
|
||||||
|
```
|
||||||
|
人工智能目标负载阶段 RTOS 侧任务/事件
|
||||||
|
──────────────── ──────────────────
|
||||||
|
输入处理 / Tokenization → 低优先级辅助任务
|
||||||
|
Embedding / Prefill → 计算密集任务
|
||||||
|
Attention / KV Cache → 延迟敏感任务
|
||||||
|
FFN / 设备计算 → 可流水化计算任务
|
||||||
|
采样 / 输出决策 → 中优先级服务任务
|
||||||
|
结果封装 / 输出通路 → 接口与通信任务
|
||||||
|
```
|
||||||
|
|
||||||
|
关键点在于：
|
||||||
|
|
||||||
|
- 哪些阶段必须优先保障；
|
||||||
|
- 哪些阶段可以延迟或限流；
|
||||||
|
- 哪些资源需要隔离；
|
||||||
|
- 哪些竞争会直接破坏关键保障负载。
|
||||||
|
|
||||||
|
这里还要明确区分两类执行单元：
|
||||||
|
|
||||||
|
- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
|
||||||
|
- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. 研究主线：实时保障机制
|
||||||
|
|
||||||
|
项目后续所有子方向都服务于同一个主命题：
|
||||||
|
|
||||||
|
> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
|
||||||
|
|
||||||
|
围绕这个主命题，系统机制可以分为六个方向：
|
||||||
|
|
||||||
|
1. **推理图任务调度**
|
||||||
|
2. **KV Cache 与内存管理**
|
||||||
|
3. **加速器协同调度**
|
||||||
|
4. **量化与精度感知调度**
|
||||||
|
5. **中断与实时性保障**
|
||||||
|
6. **能耗与热管理**
|
||||||
|
|
||||||
|
这六个方向共同服务于一个判断：
|
||||||
|
|
||||||
|
> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
|
||||||
|
|
||||||
|
### 3.1 面向小型化与低功耗方向的应用副课题
|
||||||
|
|
||||||
|
在六个机制方向之外，项目设置一条面向应用落点的专题线：
|
||||||
|
|
||||||
|
> **面向小型化与低功耗方向的应用副课题。**
|
||||||
|
|
||||||
|
这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
|
||||||
|
|
||||||
|
1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
|
||||||
|
2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
|
||||||
|
3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
|
||||||
|
4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
|
||||||
|
|
||||||
|
这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
|
||||||
|
|
||||||
|
- 小型化与低功耗系统是否仍能承载人工智能目标负载；
|
||||||
|
- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
|
||||||
|
- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
|
||||||
|
|
||||||
|
因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
|
||||||
|
|
||||||
|
### 3.2 研究方法总述
|
||||||
|
|
||||||
|
为了回答这个问题，研究方法采用一条统一证据链：
|
||||||
|
|
||||||
|
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. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
|
||||||
|
3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
|
||||||
|
4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
|
||||||
|
5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
|
||||||
|
6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
|
||||||
|
7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*最后更新: 2026-09-21*
|
||||||
@@ -13,6 +13,28 @@ RTOS需要将这个DAG映射为task集合，并设计调度策略保证：
|
|||||||
2. **延迟最小化** — TTFT和尾延迟最小
|
2. **延迟最小化** — TTFT和尾延迟最小
|
||||||
3. **确定性保证** — 满足硬实时约束（如语音对话的<200ms抖动）
|
3. **确定性保证** — 满足硬实时约束（如语音对话的<200ms抖动）
|
||||||
|
|
||||||
|
### 1.1 本方向在总课题中的角色
|
||||||
|
|
||||||
|
本方向聚焦：
|
||||||
|
|
||||||
|
- 如何把人工智能目标负载拆解为可由 RTOS 管理的任务图；
|
||||||
|
- 如何让人工智能目标负载与关键保障负载在同一系统中同时达标；
|
||||||
|
- 如何把 SylixOS 的调度能力转化为可观测的系统收益与对照差异。
|
||||||
|
|
||||||
|
因此，这一方向服务的是总课题中的“任务图建模与调度保障”主线。
|
||||||
|
|
||||||
|
### 1.2 与验证矩阵的对应关系
|
||||||
|
|
||||||
|
这一方向在 `T5~T1` 五类部署形态中都成立，但关注重点不同：
|
||||||
|
|
||||||
|
| 部署形态 | 调度侧重点 |
|
||||||
|
|---|---|
|
||||||
|
| `T5` 控制端 | 小任务集、强实时、极低抖动 |
|
||||||
|
| `T4` 终端设备 | 单路智能任务与本地控制任务并存 |
|
||||||
|
| `T3` 边缘节点 | 多源输入与多任务竞争下的任务图调度 |
|
||||||
|
| `T2` 单机工作站 | 高吞吐推理与关键任务隔离并行 |
|
||||||
|
| `T1` 服务器/集群 | 多请求队列、跨核与跨设备调度协同 |
|
||||||
|
|
||||||
## 2. LLM推理图的分解
|
## 2. LLM推理图的分解
|
||||||
|
|
||||||
### 2.1 推理阶段分析
|
### 2.1 推理阶段分析
|
||||||
@@ -359,7 +381,15 @@ RTOS角色:
|
|||||||
- 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** | 低开销，实时性可分析 |
|
| 同步机制 | Semaphore / Mutex / Notify | **Notify + Barrier** | 低开销，实时性可分析 |
|
||||||
| 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 |
|
| 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 |
|
||||||
|
|
||||||
## 8. 开放研究问题
|
## 9. 开放研究问题
|
||||||
|
|
||||||
1. **动态WCET估计**：LLM的WCET随input长度变化，如何在线估计？
|
1. **动态WCET估计**：LLM的WCET随input长度变化，如何在线估计？
|
||||||
2. **Adaptive Priority**：运行时根据系统负载动态调整优先级？
|
2. **Adaptive Priority**：运行时根据系统负载动态调整优先级？
|
||||||
@@ -22,6 +22,28 @@ RTOS场景下KV Cache管理的关键问题：
|
|||||||
3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
|
3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
|
||||||
4. **多请求KV Cache隔离** — 多流场景下的内存隔离与复用
|
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. KV Cache结构分析
|
||||||
|
|
||||||
### 2.1 KV Cache布局
|
### 2.1 KV Cache布局
|
||||||
@@ -342,7 +364,15 @@ Paged KV | variable| 0% | variable | 低
|
|||||||
- 多GPU间KV Cache同步
|
- 多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** | 避免带宽饱和 |
|
| 带宽管理 | 固定分配 / 动态 | **Bandwidth-aware** | 避免带宽饱和 |
|
||||||
| 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
|
| 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
|
||||||
|
|
||||||
## 8. 开放研究问题
|
## 9. 开放研究问题
|
||||||
|
|
||||||
1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
|
1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
|
||||||
2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？
|
2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？
|
||||||
@@ -2,13 +2,35 @@
|
|||||||
|
|
||||||
## 1. 问题陈述
|
## 1. 问题陈述
|
||||||
|
|
||||||
现代嵌入式AI SoC都包含专用加速器(NPU/GPU/DSP)，LLM推理需要CPU和加速器协同工作。核心问题：
|
任务关键系统中的人工智能目标负载往往依赖专用加速器(NPU/GPU/DSP)与 CPU 协同完成计算。RTOS 需要协调 CPU 与加速器协同工作。核心问题：
|
||||||
|
|
||||||
1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
|
1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
|
||||||
2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
|
2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
|
||||||
3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
|
3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
|
||||||
4. **同步开销**: barrier/semaphore的实时性分析复杂
|
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. 加速器架构分析
|
||||||
|
|
||||||
### 2.1 常见加速器类型
|
### 2.1 常见加速器类型
|
||||||
@@ -403,7 +425,15 @@ RTOS角色:
|
|||||||
- RTOS主要保障中断响应
|
- RTOS主要保障中断响应
|
||||||
```
|
```
|
||||||
|
|
||||||
## 8. 关键设计决策
|
## 8. 本方向的验证关注点
|
||||||
|
|
||||||
|
为了让本方向与总课题的双目标评价框架对齐，加速器协同机制至少要回答下面三个问题：
|
||||||
|
|
||||||
|
1. 设备协同是否降低了人工智能目标负载的等待时间、传输开销和端到端抖动；
|
||||||
|
2. DMA、中断和共享内存竞争是否会冲击关键保障负载的响应时间边界；
|
||||||
|
3. 当加速器状态不可见、延迟波动或发生故障时，系统是否仍具备准入、限流和恢复能力。
|
||||||
|
|
||||||
|
## 9. 关键设计决策
|
||||||
|
|
||||||
| 决策点 | 选项 | 推荐 | 理由 |
|
| 决策点 | 选项 | 推荐 | 理由 |
|
||||||
|-------|------|-----|------|
|
|-------|------|-----|------|
|
||||||
@@ -414,7 +444,7 @@ RTOS角色:
|
|||||||
| 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
|
| 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
|
||||||
| 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
|
| 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
|
||||||
|
|
||||||
## 9. 开放研究问题
|
## 10. 开放研究问题
|
||||||
|
|
||||||
1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
|
1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
|
||||||
2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？
|
2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？
|
||||||
@@ -13,6 +13,28 @@ LLM的量化(Int8/Int4)不仅影响计算精度和模型大小，还直接影响
|
|||||||
2. 内存带宽需求
|
2. 内存带宽需求
|
||||||
3. 精度切换时的同步策略
|
3. 精度切换时的同步策略
|
||||||
|
|
||||||
|
### 1.1 本方向在总课题中的角色
|
||||||
|
|
||||||
|
本方向聚焦：
|
||||||
|
|
||||||
|
- 如何把量化精度纳入 RTOS 可分析的调度参数；
|
||||||
|
- 如何在人工智能目标负载时效性与输出有效性之间建立可控权衡；
|
||||||
|
- 如何避免精度切换、校准开销和 MoE 负载波动破坏关键保障负载的实时边界。
|
||||||
|
|
||||||
|
因此，这一方向服务的是总课题中的“质量-时效联合调度”主线。
|
||||||
|
|
||||||
|
### 1.2 与验证矩阵的对应关系
|
||||||
|
|
||||||
|
量化与精度感知调度在 `T5~T1` 中的作用方式不同，因此需要按部署形态看重点：
|
||||||
|
|
||||||
|
| 部署形态 | 精度调度侧重点 |
|
||||||
|
|---|---|
|
||||||
|
| `T5` 控制端 | 固定低精度、静态校准与可预测执行时间 |
|
||||||
|
| `T4` 终端设备 | Int8/Int4 下的质量-时延平衡 |
|
||||||
|
| `T3` 边缘节点 | 负载波动下的动态精度与服务模式切换 |
|
||||||
|
| `T2` 单机工作站 | 多精度混合与大上下文推理的联合优化 |
|
||||||
|
| `T1` 服务器/集群 | 多模型、多租户下的精度策略编排 |
|
||||||
|
|
||||||
## 2. 量化层级分析
|
## 2. 量化层级分析
|
||||||
|
|
||||||
### 2.1 LLM各组件的量化粒度
|
### 2.1 LLM各组件的量化粒度
|
||||||
@@ -490,7 +512,15 @@ Solution: Multi-objective optimization
|
|||||||
- 量化感知 serving (vLLM FP8 support)
|
- 量化感知 serving (vLLM FP8 support)
|
||||||
```
|
```
|
||||||
|
|
||||||
## 8. 关键设计决策
|
## 8. 本方向的验证关注点
|
||||||
|
|
||||||
|
为了让本方向与总课题的双目标评价框架对齐，量化与精度感知调度至少要回答下面三个问题：
|
||||||
|
|
||||||
|
1. 不同精度策略下，人工智能目标负载的 `TTFT`、`TPOT`、成功率和输出质量如何共同变化；
|
||||||
|
2. 精度切换、同步和校准开销是否会把关键保障负载推过实时边界；
|
||||||
|
3. 精度模式切换是否可以被准入控制和运行模式管理，并保持可预测的抖动边界。
|
||||||
|
|
||||||
|
## 9. 关键设计决策
|
||||||
|
|
||||||
| 决策点 | 选项 | 推荐 | 理由 |
|
| 决策点 | 选项 | 推荐 | 理由 |
|
||||||
|-------|------|-----|------|
|
|-------|------|-----|------|
|
||||||
@@ -501,7 +531,7 @@ Solution: Multi-objective optimization
|
|||||||
| 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
|
| 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
|
||||||
| 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
|
| 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
|
||||||
|
|
||||||
## 9. 开放研究问题
|
## 10. 开放研究问题
|
||||||
|
|
||||||
1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
|
1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
|
||||||
2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？
|
2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？
|
||||||
@@ -2,13 +2,35 @@
|
|||||||
|
|
||||||
## 1. 问题陈述
|
## 1. 问题陈述
|
||||||
|
|
||||||
RTOS上的LLM推理不是孤立的系统。设备中还有其他硬实时任务(传感器、通信、控制)，它们与LLM任务共存于同一个RTOS内核中。核心问题：
|
RTOS 上的人工智能目标负载与传感、通信、控制等关键保障负载共存于同一个 RTOS 内核中。核心问题：
|
||||||
|
|
||||||
1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
|
1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
|
||||||
2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
|
2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
|
||||||
3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
|
3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
|
||||||
4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
|
4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
|
||||||
|
|
||||||
|
### 1.1 本方向在总课题中的角色
|
||||||
|
|
||||||
|
本方向聚焦：
|
||||||
|
|
||||||
|
- 如何保证关键保障负载在人工智能目标负载进入系统后仍拥有明确的中断优先权；
|
||||||
|
- 如何把加速器完成中断、DMA 中断和外设中断纳入统一的实时边界分析；
|
||||||
|
- 如何让 SylixOS 的中断管理能力成为双目标达标的硬支撑。
|
||||||
|
|
||||||
|
因此，这一方向服务的是总课题中的“关键路径实时保障”主线。
|
||||||
|
|
||||||
|
### 1.2 与验证矩阵的对应关系
|
||||||
|
|
||||||
|
中断管理与实时性保障在 `T5~T1` 中都重要，但关键矛盾不同：
|
||||||
|
|
||||||
|
| 部署形态 | 中断保障侧重点 |
|
||||||
|
|---|---|
|
||||||
|
| `T5` 控制端 | 控制回路、看门狗和安全联锁优先级最高 |
|
||||||
|
| `T4` 终端设备 | 传感器、通信与本地 AI 推理中断并存 |
|
||||||
|
| `T3` 边缘节点 | 多外设、多链路和加速器完成中断叠加 |
|
||||||
|
| `T2` 单机工作站 | GPU/网络/存储中断与关键任务隔离 |
|
||||||
|
| `T1` 服务器/集群 | 多队列网络、存储和设备中断亲和治理 |
|
||||||
|
|
||||||
## 2. 中断层级设计
|
## 2. 中断层级设计
|
||||||
|
|
||||||
### 2.1 中断优先级映射
|
### 2.1 中断优先级映射
|
||||||
@@ -397,7 +419,15 @@ RTOS角色:
|
|||||||
- RTOS保证关键路径上的中断响应
|
- RTOS保证关键路径上的中断响应
|
||||||
```
|
```
|
||||||
|
|
||||||
## 8. 关键设计决策
|
## 8. 本方向的验证关注点
|
||||||
|
|
||||||
|
为了让本方向与总课题的双目标评价框架对齐，中断与实时性机制至少要回答下面三个问题：
|
||||||
|
|
||||||
|
1. 关键保障负载在人工智能目标负载并存时，是否仍满足 `deadline miss ratio`、观测最大响应时间和尾部抖动约束；
|
||||||
|
2. 加速器完成中断、DMA 中断和外设中断是否形成可分析的干扰上界，并维持可控的中断行为；
|
||||||
|
3. 优先级继承、IRQ 亲和和中断屏蔽策略是否降低了关键路径不确定性并形成可分析上界。
|
||||||
|
|
||||||
|
## 9. 关键设计决策
|
||||||
|
|
||||||
| 决策点 | 选项 | 推荐 | 理由 |
|
| 决策点 | 选项 | 推荐 | 理由 |
|
||||||
|-------|------|-----|------|
|
|-------|------|-----|------|
|
||||||
@@ -408,7 +438,7 @@ RTOS角色:
|
|||||||
| Timer | Tick / Event | **Event** | 降低开销 |
|
| Timer | Tick / Event | **Event** | 降低开销 |
|
||||||
| IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
|
| IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
|
||||||
|
|
||||||
## 9. 开放研究问题
|
## 10. 开放研究问题
|
||||||
|
|
||||||
1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
|
1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
|
||||||
2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？
|
2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？
|
||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
## 1. 问题陈述
|
## 1. 问题陈述
|
||||||
|
|
||||||
边缘/嵌入式设备运行LLM时，能耗和热是硬约束：
|
当人工智能目标负载进入任务关键系统后，能耗和热会直接进入实时保障约束：
|
||||||
|
|
||||||
```
|
```
|
||||||
LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
|
LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
|
||||||
@@ -19,6 +19,28 @@ Constraints:
|
|||||||
- Form Factor: Passive cooling (no fan)
|
- Form Factor: Passive cooling (no fan)
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### 1.1 本方向在总课题中的角色
|
||||||
|
|
||||||
|
本方向聚焦：
|
||||||
|
|
||||||
|
- 如何避免热漂移、降频和功率封顶破坏人工智能目标负载的时效性；
|
||||||
|
- 如何避免功耗控制策略反向侵蚀关键保障负载的实时边界；
|
||||||
|
- 如何把能耗与热管理纳入 SylixOS 的长期稳定运行机制。
|
||||||
|
|
||||||
|
因此，这一方向服务的是总课题中的“长稳运行与热功率边界”主线。
|
||||||
|
|
||||||
|
### 1.2 与验证矩阵的对应关系
|
||||||
|
|
||||||
|
能耗与热管理在 `T5~T1` 中的表现差异显著，因此需要按部署形态看重点：
|
||||||
|
|
||||||
|
| 部署形态 | 能耗与热管理侧重点 |
|
||||||
|
|---|---|
|
||||||
|
| `T5` 控制端 | 电池/电源预算、深睡眠与快速恢复 |
|
||||||
|
| `T4` 终端设备 | 被动散热下的持续推理与温升控制 |
|
||||||
|
| `T3` 边缘节点 | 多核+加速器协同下的热热点迁移 |
|
||||||
|
| `T2` 单机工作站 | 长时间高负载下的降频与风扇策略 |
|
||||||
|
| `T1` 服务器/集群 | 机架功率、PUE 与多设备热耦合 |
|
||||||
|
|
||||||
## 2. 能耗模型
|
## 2. 能耗模型
|
||||||
|
|
||||||
### 2.1 各组件的能耗模型
|
### 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** | 减少延迟抖动 |
|
| 热感知 | Reactive / Predictive | **Predictive** | 减少延迟抖动 |
|
||||||
| 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
|
| 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
|
||||||
|
|
||||||
## 8. 开放研究问题
|
## 9. 开放研究问题
|
||||||
|
|
||||||
1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
|
1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
|
||||||
2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？
|
2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？
|
||||||
@@ -0,0 +1,294 @@
|
|||||||
|
# 方向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` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
|
||||||
|
|
||||||
|
这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
|
||||||
|
|
||||||
|
对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
|
||||||
|
|
||||||
|
- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
|
||||||
|
- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
|
||||||
|
|
||||||
|
前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
|
||||||
|
|
||||||
|
## 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 分钟 |
|
||||||
|
|
||||||
|
任何准入失败都要作为研究记录保留。
|
||||||
|
|
||||||
|
对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
|
||||||
|
|
||||||
|
## 6. 对照原则
|
||||||
|
|
||||||
|
### 6.1 固定不变项
|
||||||
|
|
||||||
|
为了保证 OS 对照公平，以下变量必须冻结：
|
||||||
|
|
||||||
|
- 模型版本、量化格式、tokenizer、输入长度与输出长度；
|
||||||
|
- CPU 核数量、优先级、内存预算、加速器数量；
|
||||||
|
- 到达流、随机种子、预热时间、采样窗口；
|
||||||
|
- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
|
||||||
|
- 环境温度、散热、驱动与框架版本。
|
||||||
|
|
||||||
|
### 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` 为响应时间。
|
||||||
|
|
||||||
|
人工智能目标负载根据其服务目标与预算，被建模为：
|
||||||
|
|
||||||
|
- 可限流的服务任务；
|
||||||
|
- 可准入的队列任务；
|
||||||
|
- 可隔离的设备任务；
|
||||||
|
- 必要时具有阶段性优先级的任务图。
|
||||||
|
|
||||||
|
当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
|
||||||
|
|
||||||
|
### 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 分析仪 |
|
||||||
|
| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
|
||||||
|
|
||||||
|
下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
|
||||||
|
|
||||||
|
| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 人工智能目标负载时效 | `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. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
|
||||||
|
4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
|
||||||
|
|
||||||
|
这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
|
||||||
@@ -0,0 +1,60 @@
|
|||||||
|
# 研究框架索引
|
||||||
|
|
||||||
|
本目录放置项目的核心研究框架文档，分为两部分：
|
||||||
|
|
||||||
|
1. **主干机制文档**：作为公共研究材料，沉淀已经形成的主线表达、机制拆解与方法论；
|
||||||
|
2. **候选课题框架目录**：并行维护 3 套可讨论、可修改、可优选的课题框架方案。
|
||||||
|
|
||||||
|
## 阅读建议
|
||||||
|
|
||||||
|
### 1. 主干机制文档
|
||||||
|
|
||||||
|
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`
|
||||||
|
9. `参考文件/README.md`
|
||||||
|
|
||||||
|
### 2. 候选课题框架目录
|
||||||
|
|
||||||
|
1. `方案A-RTOS平台主导框架/00-课题框架.md`
|
||||||
|
2. `方案B-系统协同保障框架/00-课题框架.md`
|
||||||
|
3. `方案C-小型化与低功耗应用框架/00-课题框架.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`
|
||||||
|
- 建模、仿真、原型验证和评估方法学
|
||||||
|
- `参考文件/`
|
||||||
|
- 按研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射
|
||||||
|
|
||||||
|
## 候选框架说明
|
||||||
|
|
||||||
|
- `方案A-RTOS平台主导框架`
|
||||||
|
- 保持“大型跨平台 RTOS”作为研究主语，适合继续沿现有主线推进
|
||||||
|
- `方案B-系统协同保障框架`
|
||||||
|
- 强调 RTOS、运行时、模型与加速器协同治理，适合承接系统级方法学讨论
|
||||||
|
- `方案C-小型化与低功耗应用框架`
|
||||||
|
- 强调 `T5/T4` 受限系统与低功耗应用场景，适合形成更聚焦的专题路线
|
||||||
|
|
||||||
|
## 使用方式
|
||||||
|
|
||||||
|
后续讨论、修改和优选时，可以优先在这 3 个候选目录中推进，不必立即改动主干机制文档。待最终课题框架确定后，再把优选结果回收进 `00-整体研究框架.md` 及相关主干文件。
|
||||||
@@ -0,0 +1,43 @@
|
|||||||
|
# 推理图任务调度参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向连接两类研究：一类是固定优先级、EDF、响应时间分析等经典实时调度理论；另一类是 LLM 服务中的连续批处理、prefill/decode 分离、分块 prefill 和 SLO 感知调度。本项目的增量应落在两者交叉处：把推理图阶段映射为可度量、可准入、可隔离的 RTOS 任务，同时保障关键周期任务。
|
||||||
|
|
||||||
|
## 2. 核心必引资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” JACM, 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | 周期任务、固定优先级与 EDF 的理论基础 | 定义关键保障任务模型和可调度性讨论的起点 |
|
||||||
|
| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和释放抖动的固定优先级响应时间分析 | 为推理、中断与共享资源干扰进入 RTA 提供基础 |
|
||||||
|
| W. Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022. [USENIX](https://www.usenix.org/conference/osdi22/presentation/yu) | A | 迭代级调度和连续批处理 | 作为 LLM 服务调度基线，不作为实时保证 |
|
||||||
|
| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 请求调度与 KV 分页耦合、吞吐提升 | 支撑调度与内存联合设计及 vLLM 对照 |
|
||||||
|
| A. Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/agrawal) | A | 分块 prefill、decode 干扰与吞吐—时延权衡 | 支撑 prefill 可分段化和关键任务插入点设计 |
|
||||||
|
| Y. Zhong et al., “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin) | A | TTFT/TPOT 双 SLO、prefill/decode 解耦和 goodput | 对应本项目 TTFT、TPOT 和有效吞吐联合门槛 |
|
||||||
|
|
||||||
|
## 3. 扩展参考
|
||||||
|
|
||||||
|
| 资料 | 关注点 |
|
||||||
|
|---|---|
|
||||||
|
| A. Gujarati et al., “Serving DNNs like Clockwork: Performance Predictability from the Bottom Up,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | DNN 推理可预测性、受控执行和 deadline-aware 调度 |
|
||||||
|
| A. Agrawal et al., “SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills,” 2023. [arXiv](https://arxiv.org/abs/2308.16369) | prefill 分块、decode-maximal batching 与流水线气泡 |
|
||||||
|
|
||||||
|
## 4. 可形成的论文论点
|
||||||
|
|
||||||
|
1. 把 `prefill/decode/postprocess` 从服务框架内部阶段提升为可被 RTOS 观测和治理的任务图节点。
|
||||||
|
2. 比较固定优先级、EDF、混合优先级和准入控制在双目标场景下的边界。
|
||||||
|
3. 以满足 `TTFT + TPOT + 关键任务 deadline` 的有效吞吐，而不是总 tokens/s，作为调度目标。
|
||||||
|
4. 分析推理阶段不可抢占区间、驱动提交和完成中断对 RTA 的附加阻塞项。
|
||||||
|
|
||||||
|
## 5. 对应证据与实验
|
||||||
|
|
||||||
|
- 指标：`TTFT`、`TPOT`、端到端时延、有效吞吐、关键任务 `P99.9/Max`、违约率。
|
||||||
|
- 场景：L1、L2、L3、L5、L7。
|
||||||
|
- 对照：FCFS/默认批处理、连续批处理、分块 prefill、完整 RTOS 方案及消融。
|
||||||
|
- 关键边界：GPU/NPU 内核通常不能被 CPU 调度器直接细粒度抢占，必须实测设备与驱动行为。
|
||||||
|
|
||||||
|
## 6. 不应直接推出的结论
|
||||||
|
|
||||||
|
- 云端 LLM 系统的 SLO 达标不等于硬实时保证。
|
||||||
|
- 平均 tokens/s 提升不能说明关键保障任务更可预测。
|
||||||
|
- RTA 中的执行时间和阻塞项若未经目标硬件测量，不能作为安全上界。
|
||||||
@@ -0,0 +1,41 @@
|
|||||||
|
# KV Cache 与内存管理参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
KV Cache 同时影响容量、内存带宽、请求并发和尾延迟。在 RTOS 场景中，研究重点不是单纯提高缓存命中率，而是控制动态分配、换入换出、DMA 和回收行为对关键任务造成的不可预测干扰。
|
||||||
|
|
||||||
|
## 2. 核心必引资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 块式 KV 分配、碎片控制、共享与调度耦合 | 作为分页池设计和 vLLM 基线 |
|
||||||
|
| Y. Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/sheng23a.html) | A | GPU/CPU/存储分层放置与 I/O 调度 | 支撑分层 KV/权重放置，但需强调其吞吐导向 |
|
||||||
|
| Z. Zhang et al., “H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html) | A | 基于重要 token 的 KV 淘汰及质量影响 | 用于“容量—质量—时延”三目标实验 |
|
||||||
|
| W. Lee et al., “InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/lee) | A | KV 预取、CPU offload、动态池管理 | 对应 CPU—加速器带宽与预取干扰研究 |
|
||||||
|
| P. Patel et al., “vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention,” 2024. [arXiv](https://arxiv.org/abs/2405.04437) | B | 利用虚拟内存保持逻辑连续、比较分页内核复杂度 | 作为 PagedAttention 的替代路线和消融参考 |
|
||||||
|
|
||||||
|
## 3. 研究问题映射
|
||||||
|
|
||||||
|
| 本项目问题 | 参考资料启发 | 必须补充的 RTOS 证据 |
|
||||||
|
|---|---|---|
|
||||||
|
| 内存池预分配是否减少尾延迟 | PagedAttention 的块式管理 | 分配路径时延、关键任务 `P99.9/Max`、碎片率 |
|
||||||
|
| KV 换出是否可控 | FlexGen、InfiniGen | DMA/内存带宽竞争、外部接口响应和违约率 |
|
||||||
|
| KV 淘汰如何影响可用性 | H2O | 固定题集质量、输出可用率、恢复到全量 KV 的开销 |
|
||||||
|
| 多请求是否相互污染 | 分页与共享机制 | 每租户上限、OOM 隔离、Jain 指数和逐租户 SLO |
|
||||||
|
| B8/B16 容量边界 | 各类压缩/分页工作 | 峰值驻留集、KV 增长曲线、首次失败点和错误类型 |
|
||||||
|
|
||||||
|
## 4. 建议实验变量
|
||||||
|
|
||||||
|
- KV 块大小、内存池大小、预分配比例和保留余量；
|
||||||
|
- 上下文长度、并发度、输出长度和突发到达；
|
||||||
|
- GPU/NPU 本地、主存和存储三级放置；
|
||||||
|
- 淘汰策略：LRU、近期 token、重要 token、固定配额；
|
||||||
|
- 是否锁页、是否异步预取、DMA 并发数和带宽限额。
|
||||||
|
|
||||||
|
输出至少包括峰值内存、碎片率、分配失败率、KV 迁移字节数、带宽、`TTFT/TPOT`、质量、关键任务尾延迟和 OOM 恢复行为。
|
||||||
|
|
||||||
|
## 5. 不应直接推出的结论
|
||||||
|
|
||||||
|
- 内存占用减少不必然降低端到端时延；压缩、索引和搬移可能增加尾延迟。
|
||||||
|
- 论文中的 perplexity 或准确率保持不代表任务关键应用输出可用。
|
||||||
|
- Linux/CUDA 的虚拟内存和 UVM 机制不能假定在 SylixOS、NPU SDK 或受限 SoC 上等价存在。
|
||||||
@@ -0,0 +1,54 @@
|
|||||||
|
# 加速器协同调度参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向研究 CPU 调度、驱动提交、DMA、GPU/NPU 执行和完成中断组成的完整链路。核心是识别哪些环节受 RTOS 控制，哪些环节只受厂商运行时或固件控制，并通过端到端时间戳验证协同效果。
|
||||||
|
|
||||||
|
## 2. 核心资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| NVIDIA, “CUDA Programming Guide: Asynchronous Execution, Streams and Events.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html) | A | 流、事件、同步、并发和优先级语义 | 定义 CUDA 路线中的提交和同步边界 |
|
||||||
|
| NVIDIA, “CUDA Programming Guide: Unified Memory.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/unified-memory.html) | A | CPU/GPU 统一内存、迁移及流关联 | 解释缺页/迁移引入的不确定性，不能替代实测 |
|
||||||
|
| Z. Bai et al., “PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/bai) | A | GPU 应用切换、模型传输与执行流水化 | 支撑多模型共享和切换开销研究 |
|
||||||
|
| A. Gujarati et al., “Serving DNNs like Clockwork,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | A | 可预测 GPU 推理、执行时间建模和准入 | 作为加速器可预测性相邻工作 |
|
||||||
|
| Y. Choi, M. Rhu, “PREMA: A Predictive Multi-task Scheduling Algorithm for Preemptible Neural Processing Units,” HPCA 2020. [DOI](https://doi.org/10.1109/HPCA47549.2020.00030) | A | 可抢占 NPU 多任务预测调度 | 支撑 NPU 细粒度抢占的研究假设，需检查实际硬件支持 |
|
||||||
|
| MLCommons, “MLPerf Inference.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、负载发生和准确率约束 | 用于外部性能方法对齐，不替代双目标测试 |
|
||||||
|
|
||||||
|
## 3. 硬件路线需单独核对的官方资料
|
||||||
|
|
||||||
|
- NVIDIA：CUDA Toolkit、驱动、MPS/MIG、DCGM 与 NCCL 对应版本文档；
|
||||||
|
- Rockchip：RKNN Toolkit2、RKLLM、RKNPU2 Runtime 与对应芯片技术参考；
|
||||||
|
- 其他 NPU/GPU：运行时队列、优先级、超时、复位、DMA 和性能计数器文档；
|
||||||
|
- SylixOS：BSP、中断、DMA、一致性、IOMMU 和驱动接口资料。
|
||||||
|
|
||||||
|
闭源资料若不能公开引用，应在论文中描述可复现的外部行为，不披露受限内容。
|
||||||
|
|
||||||
|
## 4. 建议链路分解
|
||||||
|
|
||||||
|
```text
|
||||||
|
请求到达
|
||||||
|
→ CPU 预处理
|
||||||
|
→ 驱动/运行时提交
|
||||||
|
→ DMA/内存迁移
|
||||||
|
→ 加速器排队
|
||||||
|
→ kernel/NPU task 执行
|
||||||
|
→ 完成中断
|
||||||
|
→ CPU 后处理
|
||||||
|
→ 外部输出
|
||||||
|
```
|
||||||
|
|
||||||
|
每段都应有时间戳或外部观测点。设备事件只能衡量设备域执行，不能替代 CPU 到结果可用的端到端时延。
|
||||||
|
|
||||||
|
## 5. 可形成的论文论点
|
||||||
|
|
||||||
|
1. RTOS 可通过 CPU/IRQ 亲和性、队列限长、预分配和准入减少主机侧不确定性。
|
||||||
|
2. 加速器运行时不提供硬优先级保证时，RTOS 的收益会受设备不可抢占区间限制。
|
||||||
|
3. 异步流水可能提高吞吐，但需要同时检查关键任务尾延迟、内存带宽和中断干扰。
|
||||||
|
4. 多加速器扩展需分开报告单请求并行、多实例吞吐与通信开销。
|
||||||
|
|
||||||
|
## 6. 不应直接推出的结论
|
||||||
|
|
||||||
|
- CUDA stream priority 是调度提示，不是硬实时保证。
|
||||||
|
- GPU 支持并发 kernel 不代表特定工作负载必然并发执行。
|
||||||
|
- 加速器利用率高不等于有效吞吐高，也不等于关键任务 deadline 达标。
|
||||||
@@ -0,0 +1,44 @@
|
|||||||
|
# 量化与精度感知调度参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向不只比较 INT4/INT8/FP16 的速度，而是研究在不同任务紧迫度、资源预算和热状态下，能否选择满足质量门槛的最低成本精度，并保证切换过程不会破坏关键任务实时性。
|
||||||
|
|
||||||
|
## 2. 核心必引资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| E. Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers,” ICLR 2023. [OpenReview](https://openreview.net/forum?id=tcbBPnfwxS) | A | 基于近似二阶信息的低比特权重量化 | 作为 3/4-bit PTQ 方法基线 |
|
||||||
|
| G. Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/xiao23c.html) | A | W8A8、激活离群值平滑、硬件效率 | 作为 INT8 权重—激活量化基线 |
|
||||||
|
| J. Lin et al., “AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration,” MLSys 2024. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html) | A | 面向端侧的激活感知权重量化 | 对应 T5/T4/T3 设备端路线 |
|
||||||
|
| T. Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale,” NeurIPS 2022. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html) | A | 激活离群值与混合精度分解 | 支撑异常通道和精度保持讨论 |
|
||||||
|
| T. Dettmers et al., “QLoRA: Efficient Finetuning of Quantized LLMs,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html) | A | NF4、双重量化和分页优化器 | 主要用于背景；本项目若不训练，不作为主实验 |
|
||||||
|
| Z. Lin et al., “QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving,” MLSys 2025. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html) | A | 权重、激活和 KV 联合低比特系统设计 | 支撑量化与内存/内核协同研究 |
|
||||||
|
|
||||||
|
## 3. 精度感知调度应补足的研究空白
|
||||||
|
|
||||||
|
现有量化论文通常回答“某种格式能否保持平均精度并加速推理”，但本项目还需要回答：
|
||||||
|
|
||||||
|
- 精度切换是否引起模型加载、重新编译、缓存失效或内存峰值；
|
||||||
|
- 动态切换期间关键保障负载是否出现尾延迟峰值；
|
||||||
|
- 低比特内核在目标 NPU/GPU 上是否真正加速，而非只有模型更小；
|
||||||
|
- 质量门槛、实时门槛和功耗门槛能否同时满足；
|
||||||
|
- 对不同风险等级请求，能否采用不同的可接受精度下限。
|
||||||
|
|
||||||
|
## 4. 建议实验矩阵
|
||||||
|
|
||||||
|
| 维度 | 建议取值 |
|
||||||
|
|---|---|
|
||||||
|
| 精度 | FP16/BF16、INT8、INT4；仅测试后端真实支持项 |
|
||||||
|
| 模型变量 | 同一模型修订、同一 tokenizer、同一输入与解码参数 |
|
||||||
|
| 质量 | 固定题集、perplexity/准确率/F1/任务判分、输出可用率 |
|
||||||
|
| 性能 | TTFT、TPOT、端到端时延、有效吞吐 |
|
||||||
|
| 系统 | 峰值内存、切换时间、能耗、温度、关键任务违约与尾延迟 |
|
||||||
|
| 调度 | 静态精度、基于 deadline 的精度、基于热/功耗预算的精度 |
|
||||||
|
|
||||||
|
## 5. 不应直接推出的结论
|
||||||
|
|
||||||
|
- 权重压缩比不能替代整机内存、速度或能效实测。
|
||||||
|
- perplexity 接近不等于所有任务质量和安全性等价。
|
||||||
|
- 不同量化后端的算子、校准和数值格式不同，通常只能视为整套软件栈比较。
|
||||||
|
- 动态精度调度若未测切换开销，不能宣称适合实时路径。
|
||||||
@@ -0,0 +1,54 @@
|
|||||||
|
# 中断与实时性保障参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向为论文的“可保障性”提供理论和系统基础，覆盖固定优先级响应时间、共享资源阻塞、优先级倒置、中断线程化、CPU/IRQ 亲和性以及外部闭环测量。
|
||||||
|
|
||||||
|
## 2. 经典理论资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | RMS/EDF 与周期任务基础 | 建立基本任务模型 |
|
||||||
|
| L. Sha, R. Rajkumar, J. P. Lehoczky, “Priority Inheritance Protocols: An Approach to Real-Time Synchronization,” IEEE TC, 1990. [DOI](https://doi.org/10.1109/12.57058) | A | 优先级继承、优先级上限与有界阻塞 | 支撑锁竞争和优先级倒置分析 |
|
||||||
|
| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和抖动的精确固定优先级分析 | 构建含 IRQ/驱动阻塞的 RTA |
|
||||||
|
| K. Tindell, A. Burns, A. Wellings, “An Extendible Approach for Analyzing Fixed Priority Hard Real-Time Tasks,” Real-Time Systems, 1994. [DOI](https://doi.org/10.1007/BF01088593) | A | 固定优先级分析扩展 | 用于更复杂任务和通信分析 |
|
||||||
|
|
||||||
|
## 3. 内核与测量资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 |
|
||||||
|
|---|---|---|
|
||||||
|
| Linux Kernel, “PREEMPT_RT Theory of Operation.” [官方文档](https://docs.kernel.org/core-api/real-time/theory.html) | A | 可抢占锁、rtmutex、优先级继承和线程化中断 |
|
||||||
|
| Linux Kernel, “How realtime kernels differ.” [官方文档](https://docs.kernel.org/core-api/real-time/differences.html) | A | 普通 Linux 与 PREEMPT_RT 的内核语义差异 |
|
||||||
|
| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | 唤醒延迟工具、参数、限制和最大值解释 |
|
||||||
|
| Linux `rt-tests` 项目. [kernel.org](https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/) | B | cyclictest、hwlatdetect 等实现与版本记录 |
|
||||||
|
|
||||||
|
## 4. 本项目分析框架
|
||||||
|
|
||||||
|
关键任务响应时间可写为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
R_i = C_i + B_i + I_irq,i + I_sched,i
|
||||||
|
+ sum(ceil((R_i + J_h) / T_h) * C_h)
|
||||||
|
```
|
||||||
|
|
||||||
|
其中 `C_i` 是自身执行时间，`B_i` 是共享资源阻塞，`I_irq,i` 是中断与驱动干扰，`I_sched,i` 是调度器和不可抢占区间干扰，求和项是高优先级任务干扰。该式只用于组织分析；每个项的取值和适用假设必须单独验证。
|
||||||
|
|
||||||
|
实测至少覆盖：
|
||||||
|
|
||||||
|
- 计划释放、就绪、开始和完成时间；
|
||||||
|
- 唤醒延迟、响应时间、完成抖动、违约率和观测最大值；
|
||||||
|
- IRQ 数量、处理时间、CPU 亲和性和最长关中断区间；
|
||||||
|
- 推理提交、DMA 和完成中断与关键任务峰值的时间关联；
|
||||||
|
- GPIO/CAN/RS485/网络外部回路端到端时延。
|
||||||
|
|
||||||
|
## 5. 对照与消融
|
||||||
|
|
||||||
|
- O0 普通 Linux、O1 PREEMPT_RT、O2 SylixOS 默认、O3 SylixOS 优化、必要时 O4 等预算调优；
|
||||||
|
- 逐项去除 CPU 隔离、IRQ 亲和性、优先级继承、内存预分配和推理准入；
|
||||||
|
- 同时报人工智能有效吞吐代价，避免通过饿死推理任务获得低抖动。
|
||||||
|
|
||||||
|
## 6. 不应直接推出的结论
|
||||||
|
|
||||||
|
- cyclictest 测得的是特定路径的唤醒延迟，通常不等于业务任务完整响应时间。
|
||||||
|
- 实测最大值不是 WCET；零违约不是硬实时证明。
|
||||||
|
- PREEMPT_RT 和专用 RTOS 的机制差异必须通过等价任务语义比较，不能只比较工具默认输出。
|
||||||
@@ -0,0 +1,51 @@
|
|||||||
|
# 能耗与热管理参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向关注满足人工智能和关键实时约束时的能效，而不是脱离任务完成质量的最低功率。功率、温度、频率、有效吞吐和违约必须使用对齐的时间窗口联合分析。
|
||||||
|
|
||||||
|
## 2. 核心资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| MLCommons, “MLPerf Inference Power Measurement.” [官方文档](https://docs.mlcommons.org/inference/power/) | A | 外部功率分析仪、PTDaemon、测量窗口和配置 | 设计整机功耗采集链路 |
|
||||||
|
| MLCommons, “MLPerf Inference Benchmark Suite.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、性能与准确率约束 | 对齐负载发生和结果报告方法 |
|
||||||
|
| SPEC, “SPECpower_ssj2008.” [官方资料](https://www.spec.org/osg/power_ssj2008/) | A | AC 输入功率—性能联合测量、负载档位 | 借鉴整机边界和多负载点报告 |
|
||||||
|
| W. Huang et al., “HotSpot: A Compact Thermal Modeling Methodology for Early-Stage VLSI Design,” IEEE TVLSI, 2006. [DOI](https://doi.org/10.1109/TVLSI.2006.876103) | A | 热 RC 模型、瞬态与稳态温度 | 支撑热动态建模背景，不替代板级传感器实测 |
|
||||||
|
| NVIDIA, “DCGM Field Identifiers.” [官方文档](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html) | A | GPU 功率、能量、温度、频率和降频原因 | V100/H100 路线的设备侧归因数据 |
|
||||||
|
|
||||||
|
## 3. 统一计算口径
|
||||||
|
|
||||||
|
```text
|
||||||
|
E_total = integral(P(t), t0, t1)
|
||||||
|
E/token = E_total / N_output
|
||||||
|
effective_E/token = E_total / N_qualified_output
|
||||||
|
tokens/J = N_output / E_total
|
||||||
|
throttling_ratio = throttled_time / valid_measurement_time
|
||||||
|
```
|
||||||
|
|
||||||
|
主结果使用整机输入端测量。设备遥测只作归因；TDP、标称功耗和电源额定值不能替代实测。`N_output=0` 时能效不可计算。
|
||||||
|
|
||||||
|
## 4. 建议实验
|
||||||
|
|
||||||
|
1. 空闲、prefill、decode 和混合负载分阶段功率曲线；
|
||||||
|
2. 25/50/75/100% 负载下的温度—频率—性能耦合；
|
||||||
|
3. 不同固定频率/DVFS/功耗上限下的 `E/token` 与 deadline miss；
|
||||||
|
4. 冷态、热稳态和 24 h 后的 TTFT/TPOT、吞吐与关键任务尾延迟；
|
||||||
|
5. 降频前后同一到达流的有效吞吐变化；
|
||||||
|
6. O0～O4 在相同双目标门槛下的能效比较。
|
||||||
|
|
||||||
|
每次运行记录环境温度、散热方式、风扇策略、功率计型号、量程、精度和采样率。
|
||||||
|
|
||||||
|
## 5. 可形成的论文论点
|
||||||
|
|
||||||
|
- RTOS 的准入、空闲管理和频率策略可能降低无效执行和失败请求的能耗。
|
||||||
|
- 更低精度或更高并发可能降低 `J/token`，但热饱和后可能扩大尾延迟和违约率。
|
||||||
|
- 应寻找满足双目标约束的 Pareto 前沿，而不是独立最小化功率或最大化吞吐。
|
||||||
|
|
||||||
|
## 6. 不应直接推出的结论
|
||||||
|
|
||||||
|
- 芯片遥测功率不能代表整机功率。
|
||||||
|
- 短时冷态跑分不能代表热稳态或 24 h 性能。
|
||||||
|
- 更低平均功率不等于更低任务能耗；运行时间延长可能提高总能量。
|
||||||
|
- 未取得温箱数据时不能宣称覆盖全温域。
|
||||||
@@ -0,0 +1,66 @@
|
|||||||
|
# 方法论与评估工具链参考
|
||||||
|
|
||||||
|
## 1. 与本项目的关系
|
||||||
|
|
||||||
|
本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。
|
||||||
|
|
||||||
|
## 2. 核心资料
|
||||||
|
|
||||||
|
| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. [Google Research](https://research.google/pubs/the-tail-at-scale/) | A | 大规模系统尾延迟的来源和重要性 | 支撑 P99/P99.9 而非均值作为核心证据 |
|
||||||
|
| V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. [arXiv](https://arxiv.org/abs/1911.02549) | A/B | 标准负载发生、场景、准确率与性能方法 | 作为 AI 基准方法学参照 |
|
||||||
|
| MLCommons, “MLPerf Inference Submission Guide.” [官方文档](https://docs.mlcommons.org/inference/submission/) | A | LoadGen、系统描述、Closed/Open division 和可比性 | 设计外部基准对齐和 manifest |
|
||||||
|
| ACM, “Artifact Review and Badging.” [官方政策](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | A | 可用、可运行、可复用与结果复现 | 规划代码、数据和复现包 |
|
||||||
|
| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | RT 延迟测试设计、参数和限制 | 作为 Linux 辅助基线及测量避坑依据 |
|
||||||
|
| R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. [PDF](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf) | A/B | Jain 公平指数 | 多租户相对独占吞吐公平性 |
|
||||||
|
|
||||||
|
## 3. 本项目最低方法要求
|
||||||
|
|
||||||
|
### 3.1 公平对照
|
||||||
|
|
||||||
|
冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。
|
||||||
|
|
||||||
|
### 3.2 样本与重复
|
||||||
|
|
||||||
|
- 普通性能单元至少 5 次独立运行；
|
||||||
|
- 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性；
|
||||||
|
- 1 ms 周期任务记录计划释放数、缺失数和全部违约；
|
||||||
|
- 长稳运行 24 h，保留完整时间序列；
|
||||||
|
- 跨运行使用中位数、区间及按运行/时间块 bootstrap。
|
||||||
|
|
||||||
|
### 3.3 失败处理
|
||||||
|
|
||||||
|
拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。
|
||||||
|
|
||||||
|
### 3.4 三层证据
|
||||||
|
|
||||||
|
```text
|
||||||
|
AI 目标负载：TTFT/TPOT/端到端/质量/可用性
|
||||||
|
关键保障负载：违约率/P99.9/Max/外部闭环
|
||||||
|
系统协同：有效吞吐/E-token/热/公平/恢复/24 h
|
||||||
|
```
|
||||||
|
|
||||||
|
任何“更优”结论都必须说明另外两层是否仍达标。
|
||||||
|
|
||||||
|
## 4. 工具链建议
|
||||||
|
|
||||||
|
| 目的 | 工具或方式 | 注意事项 |
|
||||||
|
|---|---|---|
|
||||||
|
| OS 跟踪 | SylixOS trace、ftrace、perf、事件日志 | 统一事件语义，不直接比较工具自身字段 |
|
||||||
|
| RT 辅助测试 | rt-tests/cyclictest、GPIO 打点 | cyclictest 不等于业务端到端响应 |
|
||||||
|
| 加速器分析 | CUDA profiler/DCGM、RKNN/RKLLM 日志 | 版本固定；设备事件只作阶段分解 |
|
||||||
|
| 外部时序 | 示波器、逻辑分析仪、CAN/RS485 分析仪 | 保存探头、触发、分辨率和空回路基线 |
|
||||||
|
| 功率与热 | 外部功率计/PDU、板载温度与频率 | 时间窗口对齐，遥测不替代整机功率 |
|
||||||
|
| 分析 | R/Python、bootstrap、CDF/ECDF、时间序列 | 不静默删异常，不把相关样本当独立样本 |
|
||||||
|
|
||||||
|
## 5. 推荐数据结构
|
||||||
|
|
||||||
|
每次运行保留 `manifest.json`、`requests.csv`、`rt.csv`、`power.csv`、`thermal.csv`、`events.log` 和 `summary.json`。原始数据只读保存，图表和摘要由版本化脚本生成。
|
||||||
|
|
||||||
|
## 6. 不应直接推出的结论
|
||||||
|
|
||||||
|
- 统计显著不等于工程差异重要，应同时报告效应量与阈值。
|
||||||
|
- 单次最佳结果不能代表配置能力。
|
||||||
|
- 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。
|
||||||
|
- 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
# 标准与工程资料参考
|
||||||
|
|
||||||
|
## 1. 文档定位
|
||||||
|
|
||||||
|
本文件列出论文方向可能涉及但不应与学术论文混为一谈的标准、官方工程文档和安全边界资料。标准是否适用取决于最终行业场景、系统边界和认证目标。
|
||||||
|
|
||||||
|
## 2. 功能安全与任务关键系统
|
||||||
|
|
||||||
|
| 标准/资料 | 适用范围 | 本项目可能的关系 |
|
||||||
|
|---|---|---|
|
||||||
|
| IEC 61508, *Functional safety of electrical/electronic/programmable electronic safety-related systems* | 通用功能安全 | 定义安全生命周期、SIL 和证据要求；本项目不应在未认证时宣称合规 |
|
||||||
|
| ISO 26262, *Road vehicles — Functional safety* | 道路车辆 | 若落到车载控制与 AI 辅助功能，可用于场景和安全目标分解 |
|
||||||
|
| ISO/PAS 8800, *Road vehicles — Safety and artificial intelligence* | 车载 AI 安全 | 用于 AI 输出不确定性、数据和安全论证背景 |
|
||||||
|
| DO-178C | 航空机载软件 | 若研究航空部署，可参考软件保证等级和验证独立性 |
|
||||||
|
| ARINC 653 | 航空综合模块化系统分区 | 支撑时间/空间分区的相邻工程背景 |
|
||||||
|
| IEC 62443 系列 | 工业自动化与控制系统安全 | 涉及联网工业控制时补充网络安全边界 |
|
||||||
|
|
||||||
|
正式引用应从 IEC、ISO、RTCA、EUROCAE、SAE 或 ARINC 的标准目录核对版本与访问权限。标准通常受版权保护，本仓库只保存条目和适用性说明，不复制正文。
|
||||||
|
|
||||||
|
## 3. 实时通信与时间同步
|
||||||
|
|
||||||
|
| 标准/资料 | 作用 | 使用边界 |
|
||||||
|
|---|---|---|
|
||||||
|
| IEEE 802.1AS | 广义精确时间协议 | 跨设备单向时延需要同步精度证据 |
|
||||||
|
| IEEE 802.1Qbv | 时间感知整形 | 可用于 TSN 周期流量窗口规划 |
|
||||||
|
| IEEE 802.1Qbu / IEEE 802.3br | 帧抢占 | 分析关键流量受大帧阻塞的边界 |
|
||||||
|
| IEEE 1588 | 精确时间协议 | 记录 grandmaster、硬件时间戳和误差 |
|
||||||
|
| CAN/CAN FD、RS-485 对应规范 | 工业接口 | 固定波特率、帧长、总线负载和时间戳位置 |
|
||||||
|
|
||||||
|
## 4. 操作系统与处理器接口资料
|
||||||
|
|
||||||
|
- Linux PREEMPT_RT 官方文档：[Real-time preemption](https://docs.kernel.org/core-api/real-time/index.html)。
|
||||||
|
- POSIX 实时扩展：线程调度、时钟、定时器、内存锁定和优先级协议；需按目标 OS 支持集核对。
|
||||||
|
- Arm 架构、GIC、SMMU 和缓存一致性官方手册：用于解释中断路由、DMA 和共享内存边界。
|
||||||
|
- PCIe、IOMMU、NVLink、NCCL 等规范或官方文档：用于多加速器/多节点通信路径。
|
||||||
|
- SylixOS BSP/API/驱动资料：用于确认优先级、中断、内存、设备复位和追踪接口的实际能力。
|
||||||
|
|
||||||
|
## 5. 基准与测量规范
|
||||||
|
|
||||||
|
| 资料 | 可借鉴内容 |
|
||||||
|
|---|---|
|
||||||
|
| [MLPerf Inference](https://docs.mlcommons.org/inference/index_gh/) | 场景、负载发生、准确率约束、系统描述与结果合规 |
|
||||||
|
| [MLPerf Power](https://docs.mlcommons.org/inference/power/) | 外部仪器、时间同步、测量窗口与功率记录 |
|
||||||
|
| [SPECpower_ssj2008](https://www.spec.org/osg/power_ssj2008/) | 整机 AC 功率、多个负载档位与功效比 |
|
||||||
|
| [ACM Artifact Review and Badging](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | 可用、可运行、可复用和结果复现证据 |
|
||||||
|
|
||||||
|
## 6. 论文中的合规表述
|
||||||
|
|
||||||
|
建议使用：
|
||||||
|
|
||||||
|
> 本研究借鉴相关标准中的任务关键性、时间/空间隔离和测量原则，但实验平台与研究原型未经过相应行业认证，因此结果不构成功能安全等级、适航或产品合规声明。
|
||||||
|
|
||||||
|
避免使用：
|
||||||
|
|
||||||
|
- “满足 SIL2/SIL3”——除非完成规定流程并取得正式证据；
|
||||||
|
- “达到航空级/车规级”——除非硬件、软件、流程和环境均符合对应标准；
|
||||||
|
- “证明硬实时安全”——除非有完整时序模型、可信 WCET、可调度性证明和覆盖充分的验证证据。
|
||||||
@@ -0,0 +1,51 @@
|
|||||||
|
# 论文方向参考文件索引
|
||||||
|
|
||||||
|
## 1. 目录用途
|
||||||
|
|
||||||
|
本目录为 `10-研究框架` 七个研究方向提供可追溯的论文、标准和工程资料入口。它不是完整综述，也不代表文中列出的方案已经在 SylixOS 或本项目硬件上得到验证。
|
||||||
|
|
||||||
|
参考资料按以下证据等级使用：
|
||||||
|
|
||||||
|
| 等级 | 类型 | 建议用途 |
|
||||||
|
|---|---|---|
|
||||||
|
| A | 同行评审论文、正式标准、官方内核/硬件文档 | 支撑定义、方法选择和主要论证 |
|
||||||
|
| B | arXiv 预印本、官方项目文档、开放源码实现 | 支撑前沿方案、实现路线和复现实验 |
|
||||||
|
| C | 厂商白皮书、博客或二手综述 | 仅作背景和线索，不单独支撑核心结论 |
|
||||||
|
|
||||||
|
优先引用论文正式页面、DOI、标准组织或厂商官方文档。正式写作前仍需通过学校或机构数据库核对作者、卷期、页码、版本和 BibTeX。
|
||||||
|
|
||||||
|
## 2. 文件与研究方向映射
|
||||||
|
|
||||||
|
| 文件 | 对应研究文件 | 主要主题 |
|
||||||
|
|---|---|---|
|
||||||
|
| [01-推理图任务调度参考.md](./01-推理图任务调度参考.md) | `01-推理图任务调度.md` | 经典实时调度、LLM 连续批处理、prefill/decode 调度、SLO |
|
||||||
|
| [02-KV-Cache与内存管理参考.md](./02-KV-Cache与内存管理参考.md) | `02-KV-Cache与内存管理.md` | 分页、换出、压缩、淘汰、容量隔离 |
|
||||||
|
| [03-加速器协同调度参考.md](./03-加速器协同调度参考.md) | `03-加速器协同调度.md` | CPU/GPU/NPU 协同、流、事件、DMA、共享与切换 |
|
||||||
|
| [04-量化与精度感知调度参考.md](./04-量化与精度感知调度参考.md) | `04-量化精度感知调度.md` | PTQ、权重量化、激活量化、KV 量化、精度—时延联合约束 |
|
||||||
|
| [05-中断与实时性保障参考.md](./05-中断与实时性保障参考.md) | `05-中断与实时性保障.md` | PREEMPT_RT、优先级继承、响应时间分析、中断线程化、测试 |
|
||||||
|
| [06-能耗与热管理参考.md](./06-能耗与热管理参考.md) | `06-能耗与热管理.md` | 整机功耗、E/token、DVFS、温度、降频与热漂移 |
|
||||||
|
| [07-方法论与评估工具链参考.md](./07-方法论与评估工具链参考.md) | `07-方法论与评估工具链.md` | MLPerf、尾延迟、统计、可复现性、长稳与公平性 |
|
||||||
|
| [08-标准与工程资料参考.md](./08-标准与工程资料参考.md) | 全部方向 | 功能安全、时间敏感网络、硬件接口与工程边界 |
|
||||||
|
| [参考文献.md](./参考文献.md) | 论文十章与整个项目 | 连续编号的论文参考文献候选清单与章节映射 |
|
||||||
|
|
||||||
|
## 3. 建议引用策略
|
||||||
|
|
||||||
|
每项核心主张至少建立“理论基础 + 相邻系统工作 + 本项目实测”三段证据：
|
||||||
|
|
||||||
|
```text
|
||||||
|
经典理论或标准
|
||||||
|
→ LLM/AI 系统领域的相邻工作
|
||||||
|
→ 本项目在 O0～O4、T5～T1 条件下的实测与边界
|
||||||
|
```
|
||||||
|
|
||||||
|
例如，“RTOS 优化提高双目标可保障性”不能只引用 vLLM 或 PREEMPT_RT 文档，而应同时给出实时调度理论、LLM 服务调度工作、对照实验与消融结果。
|
||||||
|
|
||||||
|
## 4. 维护规则
|
||||||
|
|
||||||
|
- 每条新资料需记录标题、作者或组织、年份、正式入口和与本项目的关系。
|
||||||
|
- 预印本被正式会议或期刊接收后，优先替换为正式版本。
|
||||||
|
- 厂商文档需记录访问日期和软件/驱动版本。
|
||||||
|
- 不将论文报告的相对提升直接移植为本项目预期值。
|
||||||
|
- 不将“平均性能改善”表述为硬实时保证；不将“未观测到违约”表述为理论最坏界。
|
||||||
|
|
||||||
|
本目录最后核验日期：**2026-09-21**。
|
||||||
@@ -0,0 +1,170 @@
|
|||||||
|
# 论文参考文献候选清单
|
||||||
|
|
||||||
|
## 1. 文档说明
|
||||||
|
|
||||||
|
本文依据仓库根目录的 `最终稿文章规划.md`、`00-项目总览`、`10-研究框架`、`20-实验与规划` 以及现有参考文件，整理拟投实时系统、嵌入式系统或机器学习系统会议论文时可使用的参考文献。
|
||||||
|
|
||||||
|
书目格式参照 `GB/T 7714—2015`，英文会议论文保留原始会议名称。在线文档统一记录访问日期 `2026-09-21`。最终投稿时应使用目标会议的 BibTeX/LaTeX 样式重新生成，并再次核对作者、页码、DOI 和版本。
|
||||||
|
|
||||||
|
当前项目已经从旧规划中的“四层谱系”调整为 `T5~T1` 五类部署形态与 11 个代表档位。本文献表按当前项目口径组织，但仍可支撑旧版 `最终稿文章规划.md` 的十章结构。
|
||||||
|
|
||||||
|
## 2. 章节—参考文献映射
|
||||||
|
|
||||||
|
| 论文内容 | 建议优先引用 | 支撑作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| 第1章 引言 | `[1]~[10]`、`[42]`、`[50]~[53]` | 实时保障基础、任务关键 AI 背景和安全边界 |
|
||||||
|
| 第2章 背景与相关工作 | `[1]~[32]` | 经典调度、PREEMPT_RT、LLM 推理服务、KV Cache、加速器和量化 |
|
||||||
|
| 第3章 部署形态与硬件谱系 | `[34]~[39]`、`[43]~[47]` | Edge/Datacenter 方法、功率边界、模型与推理运行时 |
|
||||||
|
| 第4章 SylixOS 调度框架 | `[1]~[9]`、`[12]~[33]`、`[43]~[47]` | 任务图、内存、异构加速、量化、中断与运行时实现 |
|
||||||
|
| 第5章 实验方法学 | `[5]`、`[6]`、`[34]~[42]`、`[48]`、`[49]` | 延迟测试、MLPerf、功率、统计、公平性和可复现性 |
|
||||||
|
| 第6章 模型与负载 | `[11]`、`[12]`、`[27]~[33]`、`[43]~[47]` | Transformer、低比特模型、Qwen、llama.cpp、TensorRT-LLM |
|
||||||
|
| 第7章 实验结果 | `[34]~[41]` | 指标、功率、尾延迟、温度、公平性和统计解释 |
|
||||||
|
| 第8章 深入分析 | `[1]~[33]`、`[37]~[41]` | 根因分析、机制对照与跨层权衡 |
|
||||||
|
| 第9章 威胁有效性 | `[7]~[10]`、`[34]~[42]`、`[48]~[53]` | 系统边界、复现性、功能安全与跨设备测量限制 |
|
||||||
|
| 第10章 结论与展望 | `[23]`、`[24]`、`[26]`、`[33]`、`[50]~[53]` | 动态调度、精度/资源协同、任务关键 AI 和安全论证 |
|
||||||
|
|
||||||
|
## 3. 实时调度、RTOS 与操作系统基础
|
||||||
|
|
||||||
|
[1] LIU C L, LAYLAND J W. Scheduling algorithms for multiprogramming in a hard-real-time environment[J]. Journal of the ACM, 1973, 20(1): 46-61. DOI: [10.1145/321738.321743](https://doi.org/10.1145/321738.321743).
|
||||||
|
|
||||||
|
[2] SHA L, RAJKUMAR R, LEHOCZKY J P. Priority inheritance protocols: An approach to real-time synchronization[J]. IEEE Transactions on Computers, 1990, 39(9): 1175-1185. DOI: [10.1109/12.57058](https://doi.org/10.1109/12.57058).
|
||||||
|
|
||||||
|
[3] AUDSLEY N, BURNS A, RICHARDSON M, et al. Applying new scheduling theory to static priority pre-emptive scheduling[J]. Software Engineering Journal, 1993, 8(5): 284-292. DOI: [10.1049/sej.1993.0034](https://doi.org/10.1049/sej.1993.0034).
|
||||||
|
|
||||||
|
[4] TINDELL K, BURNS A, WELLINGS A J. An extendible approach for analyzing fixed priority hard real-time tasks[J]. Real-Time Systems, 1994, 6(2): 133-151. DOI: [10.1007/BF01088593](https://doi.org/10.1007/BF01088593).
|
||||||
|
|
||||||
|
[5] LINUX KERNEL COMMUNITY. Theory of operation: Real-time preemption[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/theory.html](https://docs.kernel.org/core-api/real-time/theory.html).
|
||||||
|
|
||||||
|
[6] LINUX FOUNDATION REAL-TIME LINUX. Cyclictest: Test design, interpretation and limitations[EB/OL]. [2026-09-21]. [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start).
|
||||||
|
|
||||||
|
[7] 翼辉信息. SylixOS 概述[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html](https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html).
|
||||||
|
|
||||||
|
[8] 翼辉信息. SylixOS 发展历程[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html](https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html).
|
||||||
|
|
||||||
|
[9] QNX. Priorities and scheduling: QNX Neutrino RTOS[EB/OL]. [2026-09-21]. [https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html](https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html).
|
||||||
|
|
||||||
|
[10] THE OPEN GROUP. POSIX.1-2024: Realtime functions and general information[S/OL]. 2024[2026-09-21]. [https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html).
|
||||||
|
|
||||||
|
## 4. Transformer、LLM 推理调度与服务系统
|
||||||
|
|
||||||
|
[11] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]//Advances in Neural Information Processing Systems 30. 2017: 5998-6008. [https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need](https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need).
|
||||||
|
|
||||||
|
[12] DAO T, FU D Y, ERMON S, et al. FlashAttention: Fast and memory-efficient exact attention with IO-awareness[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html](https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html).
|
||||||
|
|
||||||
|
[13] DAO T. FlashAttention-2: Faster attention with better parallelism and work partitioning[C]//International Conference on Learning Representations. 2024. [https://openreview.net/forum?id=mZn2Xyh9Ec](https://openreview.net/forum?id=mZn2Xyh9Ec).
|
||||||
|
|
||||||
|
[14] YU G I, JEONG J S, KIM G W, et al. Orca: A distributed serving system for Transformer-based generative models[C]//16th USENIX Symposium on Operating Systems Design and Implementation. 2022. [https://www.usenix.org/conference/osdi22/presentation/yu](https://www.usenix.org/conference/osdi22/presentation/yu).
|
||||||
|
|
||||||
|
[15] KWON W, LI Z, ZHUANG S, et al. Efficient memory management for large language model serving with PagedAttention[C]//Proceedings of the 29th ACM Symposium on Operating Systems Principles. 2023. [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180).
|
||||||
|
|
||||||
|
[16] AGRAWAL A, KEDIA N, PANWAR A, et al. Taming throughput-latency tradeoff in LLM inference with Sarathi-Serve[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 117-134. [https://www.usenix.org/conference/osdi24/presentation/agrawal](https://www.usenix.org/conference/osdi24/presentation/agrawal).
|
||||||
|
|
||||||
|
[17] ZHONG Y, LIU S, CHEN J, et al. DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 193-210. [https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin).
|
||||||
|
|
||||||
|
[18] SUN B, HUANG Z, ZHAO H, et al. Llumnix: Dynamic scheduling for large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 173-191. [https://www.usenix.org/conference/osdi24/presentation/sun-biao](https://www.usenix.org/conference/osdi24/presentation/sun-biao).
|
||||||
|
|
||||||
|
[19] GUJARATI A, KARANASOS K, CURINO C, et al. Serving DNNs like Clockwork: Performance predictability from the bottom up[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020. [https://www.usenix.org/conference/osdi20/presentation/gujarati](https://www.usenix.org/conference/osdi20/presentation/gujarati).
|
||||||
|
|
||||||
|
[20] SHENG Y, ZHENG L, YUAN B, et al. FlexGen: High-throughput generative inference of large language models with a single GPU[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202. [https://proceedings.mlr.press/v202/sheng23a.html](https://proceedings.mlr.press/v202/sheng23a.html).
|
||||||
|
|
||||||
|
[21] ZHANG Z, SHENG Y, ZHOU T, et al. H2O: Heavy-Hitter Oracle for efficient generative inference of large language models[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html).
|
||||||
|
|
||||||
|
[22] LEE W, LEE J, SEO J, et al. InfiniGen: Efficient generative inference of large language models with dynamic KV cache management[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 155-172. [https://www.usenix.org/conference/osdi24/presentation/lee](https://www.usenix.org/conference/osdi24/presentation/lee).
|
||||||
|
|
||||||
|
[23] PRABHU R, NAYAK A, MOHAN J, et al. vAttention: Dynamic memory management for serving LLMs without PagedAttention[EB/OL]. arXiv:2405.04437, 2024[2026-09-21]. [https://arxiv.org/abs/2405.04437](https://arxiv.org/abs/2405.04437).
|
||||||
|
|
||||||
|
[24] BAI Z, ZHANG Z, ZHU Y, et al. PipeSwitch: Fast pipelined context switching for deep learning applications[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020: 499-514. [https://www.usenix.org/conference/osdi20/presentation/bai](https://www.usenix.org/conference/osdi20/presentation/bai).
|
||||||
|
|
||||||
|
[25] CHOI Y, RHU M. PREMA: A predictive multi-task scheduling algorithm for preemptible neural processing units[C]//2020 IEEE International Symposium on High Performance Computer Architecture. 2020. DOI: [10.1109/HPCA47549.2020.00030](https://doi.org/10.1109/HPCA47549.2020.00030).
|
||||||
|
|
||||||
|
[26] NVIDIA. CUDA Programming Guide: Asynchronous execution, streams and events[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html).
|
||||||
|
|
||||||
|
## 5. 量化、低比特推理与质量约束
|
||||||
|
|
||||||
|
[27] DETTMERS T, LEWIS M, BELKADA Y, et al. LLM.int8(): 8-bit matrix multiplication for Transformers at scale[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html).
|
||||||
|
|
||||||
|
[28] FRANTAR E, ASHKBOOS S, HOEFLER T, et al. GPTQ: Accurate post-training quantization for generative pre-trained Transformers[C]//International Conference on Learning Representations. 2023. [https://openreview.net/forum?id=tcbBPnfwxS](https://openreview.net/forum?id=tcbBPnfwxS).
|
||||||
|
|
||||||
|
[29] XIAO G, LIN J, SEZNEC M, et al. SmoothQuant: Accurate and efficient post-training quantization for large language models[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202: 38087-38099. [https://proceedings.mlr.press/v202/xiao23c.html](https://proceedings.mlr.press/v202/xiao23c.html).
|
||||||
|
|
||||||
|
[30] LIN J, TANG J, TANG H, et al. AWQ: Activation-aware weight quantization for on-device LLM compression and acceleration[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html).
|
||||||
|
|
||||||
|
[31] DETTMERS T, PAGNONI A, HOLTZMAN A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html).
|
||||||
|
|
||||||
|
[32] LIN Y, TANG H, YANG S, et al. QServe: W4A8KV4 quantization and system co-design for efficient LLM serving[C]//Proceedings of Machine Learning and Systems. 2025, 7. [https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html).
|
||||||
|
|
||||||
|
[33] ZHAO Y, LIN C Y, ZHU K, et al. Atom: Low-bit quantization for efficient and accurate LLM serving[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html).
|
||||||
|
|
||||||
|
## 6. 评估、功耗、热管理与可复现性
|
||||||
|
|
||||||
|
[34] REDDI V J, CHENG C, KANTER D, et al. MLPerf Inference Benchmark[EB/OL]. arXiv:1911.02549, 2019[2026-09-21]. [https://arxiv.org/abs/1911.02549](https://arxiv.org/abs/1911.02549).
|
||||||
|
|
||||||
|
[35] MLCOMMONS. MLPerf Inference Benchmark Suite[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/index_gh/](https://docs.mlcommons.org/inference/index_gh/).
|
||||||
|
|
||||||
|
[36] MLCOMMONS. MLPerf Inference power measurement[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/power/](https://docs.mlcommons.org/inference/power/).
|
||||||
|
|
||||||
|
[37] DEAN J, BARROSO L A. The tail at scale[J]. Communications of the ACM, 2013, 56(2): 74-80. [https://research.google/pubs/the-tail-at-scale/](https://research.google/pubs/the-tail-at-scale/).
|
||||||
|
|
||||||
|
[38] HUANG W, GHOSH S, VELUSAMY S, et al. HotSpot: A compact thermal modeling methodology for early-stage VLSI design[J]. IEEE Transactions on Very Large Scale Integration Systems, 2006, 14(5): 501-513. DOI: [10.1109/TVLSI.2006.876103](https://doi.org/10.1109/TVLSI.2006.876103).
|
||||||
|
|
||||||
|
[39] STANDARD PERFORMANCE EVALUATION CORPORATION. SPECpower_ssj2008[EB/OL]. [2026-09-21]. [https://www.spec.org/osg/power_ssj2008/](https://www.spec.org/osg/power_ssj2008/).
|
||||||
|
|
||||||
|
[40] JAIN R, CHIU D M, HAWE W R. A quantitative measure of fairness and discrimination for resource allocation in shared computer systems[R]. DEC Research Report TR-301, 1984. [https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf).
|
||||||
|
|
||||||
|
[41] EFRON B, TIBSHIRANI R J. An introduction to the bootstrap[M]. New York: Chapman & Hall/CRC, 1993.
|
||||||
|
|
||||||
|
[42] ASSOCIATION FOR COMPUTING MACHINERY. Artifact review and badging policy[EB/OL]. [2026-09-21]. [https://www.acm.org/publications/policies/artifact-review-and-badging-current](https://www.acm.org/publications/policies/artifact-review-and-badging-current).
|
||||||
|
|
||||||
|
## 7. 模型、推理框架与工程实现资料
|
||||||
|
|
||||||
|
[43] YANG A, YANG B, ZHANG B, et al. Qwen2.5 Technical Report[EB/OL]. arXiv:2412.15115, 2024[2026-09-21]. [https://arxiv.org/abs/2412.15115](https://arxiv.org/abs/2412.15115).
|
||||||
|
|
||||||
|
[44] GGERGANOV, GGML-ORG. llama.cpp: LLM inference in C/C++[CP/OL]. [2026-09-21]. [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp).
|
||||||
|
|
||||||
|
[45] NVIDIA. TensorRT-LLM architecture overview[EB/OL]. [2026-09-21]. [https://nvidia.github.io/TensorRT-LLM/architecture/overview.html](https://nvidia.github.io/TensorRT-LLM/architecture/overview.html).
|
||||||
|
|
||||||
|
[46] NVIDIA. NVIDIA Data Center GPU Manager: Field identifiers[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html).
|
||||||
|
|
||||||
|
[47] LINUX KERNEL COMMUNITY. How realtime kernels differ[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/differences.html](https://docs.kernel.org/core-api/real-time/differences.html).
|
||||||
|
|
||||||
|
## 8. 任务关键 AI、功能安全与时间同步标准
|
||||||
|
|
||||||
|
[48] ULLRICH L, BUCHHOLZ M, DIETMAYER K, et al. AI safety assurance for automated vehicles: A survey on research, standardization, regulation[J]. IEEE Transactions on Intelligent Vehicles, 2024. DOI: [10.1109/TIV.2024.3496797](https://doi.org/10.1109/TIV.2024.3496797).
|
||||||
|
|
||||||
|
[49] IEC. IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems—Parts 1 to 7[S]. 2nd ed. Geneva: International Electrotechnical Commission, 2010. [https://webstore.iec.ch/en/publication/22273](https://webstore.iec.ch/en/publication/22273).
|
||||||
|
|
||||||
|
[50] ISO. ISO 26262:2018, Road vehicles—Functional safety[S]. 2nd ed. Geneva: International Organization for Standardization, 2018. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html).
|
||||||
|
|
||||||
|
[51] ISO. ISO/PAS 8800:2024, Road vehicles—Safety and artificial intelligence[S]. Geneva: International Organization for Standardization, 2024. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html).
|
||||||
|
|
||||||
|
[52] IEEE. IEEE Std 1588-2019, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems[S]. New York: IEEE, 2019. [https://standards.ieee.org/ieee/1588/6825/](https://standards.ieee.org/ieee/1588/6825/).
|
||||||
|
|
||||||
|
[53] RTCA. DO-178C: Software considerations in airborne systems and equipment certification[S]. Washington, D.C.: RTCA, 2011. [https://www.rtca.org/do-178/](https://www.rtca.org/do-178/).
|
||||||
|
|
||||||
|
## 9. 使用与取舍建议
|
||||||
|
|
||||||
|
### 9.1 核心正文优先保留
|
||||||
|
|
||||||
|
受篇幅限制时，建议首先保留 `[1]~[6]`、`[11]`、`[14]~[22]`、`[25]~[30]`、`[34]~[42]`、`[49]~[52]`。它们分别支撑实时理论、LLM 服务、异构调度、量化、实验方法与任务关键边界。
|
||||||
|
|
||||||
|
### 9.2 只作工程实现说明
|
||||||
|
|
||||||
|
`[7]~[10]`、`[26]`、`[35]`、`[36]`、`[39]`、`[44]~[47]` 属于官方标准、文档或开源实现，适合说明平台能力、API 语义和实验工具，不宜单独用来证明算法创新或相对性能优势。
|
||||||
|
|
||||||
|
### 9.3 需要谨慎使用
|
||||||
|
|
||||||
|
- `[23]`、`[34]`、`[43]` 为预印本或技术报告，投稿前应检查是否已有正式发表版本。
|
||||||
|
- 功能安全标准只能支撑需求与证据框架；本项目原型未完成对应认证时，不得据此宣称满足 SIL、ASIL 或适航要求。
|
||||||
|
- SylixOS、QNX、CUDA、TensorRT-LLM 等官方资料描述的是产品或接口能力，实际可用性仍需由本项目准入实验验证。
|
||||||
|
- 任何外部论文报告的倍数提升都不能移植为本项目预期结果，只能用于选择对照方案和解释机制。
|
||||||
|
|
||||||
|
## 10. 待补充文献
|
||||||
|
|
||||||
|
正式投稿前还应根据实际实验结果补充：
|
||||||
|
|
||||||
|
1. 最终采用的 RKLLM/RKNN SDK、芯片手册和模型转换工具的固定版本文档；
|
||||||
|
2. 实际使用的 SylixOS BSP、驱动和追踪工具文档；
|
||||||
|
3. 若完成 T1 多节点实验，补充 NCCL、RDMA 和分布式推理的正式文献；
|
||||||
|
4. 若完成 MoE 实验，补充专家路由、负载均衡和专家并行文献；
|
||||||
|
5. 若论文转投 ISLPED，补充 DVFS、race-to-idle 与嵌入式热管理相关工作；
|
||||||
|
6. 若论文面向车载或航空场景，按最终系统边界补充 ISO 26262、ISO/PAS 8800、DO-178C 及行业适用指南。
|
||||||
@@ -0,0 +1,178 @@
|
|||||||
|
# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
|
||||||
|
|
||||||
|
## 1. 文档目的
|
||||||
|
|
||||||
|
本文用于解释本目录中的研究逻辑结构，并说明：
|
||||||
|
|
||||||
|
- [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) 如何承载完整的 `T5~T1` 五类部署形态与 `11` 个代表档位；
|
||||||
|
- [03-实验设计.md](./03-实验设计.md) 如何把这些硬件条件组织成可复现的对照实验；
|
||||||
|
- [04-论文写作规划.md](./04-论文写作规划.md) 如何把证据组织成一篇系统化论文。
|
||||||
|
|
||||||
|
三份文档承担的职责如下：
|
||||||
|
|
||||||
|
| 文档 | 回答的问题 | 在研究中的作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) | 在哪些部署形态与硬件条件下验证？ | 定义 `T5~T1` 五类部署形态、五种算力基础与十一档实验矩阵 |
|
||||||
|
| [03-实验设计.md](./03-实验设计.md) | 如何产生可信、可复现、可比较的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
|
||||||
|
| [04-论文写作规划.md](./04-论文写作规划.md) | 如何把这些证据组织成论文贡献？ | 把研究问题、方法、结果和边界映射成论文结构 |
|
||||||
|
|
||||||
|
整个研究的主线是：
|
||||||
|
|
||||||
|
> **研究对象定义清楚 → 验证矩阵完整展开 → 公平对照与双目标实验 → 数据可复现 → 跨档位规律与边界 → 论文贡献。**
|
||||||
|
|
||||||
|
## 2. 研究对象
|
||||||
|
|
||||||
|
这个项目的研究对象是：
|
||||||
|
|
||||||
|
> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制。**
|
||||||
|
|
||||||
|
本目录后续所有实验和文档都围绕下面这条主线展开：
|
||||||
|
|
||||||
|
- **研究对象**：大型跨平台实时操作系统这一类平台；
|
||||||
|
- **主实验样例**：SylixOS；
|
||||||
|
- **外部参照样本**：QNX、VxWorks、INTEGRITY、LynxOS-178；
|
||||||
|
- **系统场景**：任务关键系统；
|
||||||
|
- **目标负载**：人工智能目标负载；
|
||||||
|
- **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
|
||||||
|
- **硬件角色**：验证矩阵。
|
||||||
|
|
||||||
|
在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
|
||||||
|
|
||||||
|
## 3. T5~T1 五类部署形态与 11 个代表档位
|
||||||
|
|
||||||
|
硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
|
||||||
|
|
||||||
|
1. **验证矩阵**：在不同资源条件下检验同一系统问题是否成立；
|
||||||
|
2. **证据组织框架**：把结果放到统一谱系中观察规律与边界；
|
||||||
|
3. **产业可解释性**：让不同部署形态都能找到对应的现实位置。
|
||||||
|
|
||||||
|
对应关系如下：
|
||||||
|
|
||||||
|
| 部署形态 | 主要系统角色 | 主要验证重点 |
|
||||||
|
|---|---|---|
|
||||||
|
| `T5` 控制端 | 极紧资源预算下的任务关键控制节点 | 强实时、极小内存、低功耗边界 |
|
||||||
|
| `T4` 设备端 SoC | 设备本体内的统一内存异构平台 | CPU/NPU/GPU 共享资源与带宽隔离 |
|
||||||
|
| `T3` 边缘节点 | 设备附近的近源推理节点 | 多任务并发、热稳定性、边缘协同 |
|
||||||
|
| `T2` 桌面 / 工作站单机 | 单机高密本地推理平台 | 单机多卡调度、NVLink/PCIe 拓扑、公平性 |
|
||||||
|
| `T1` 服务器 / 集群 | 多节点大模型服务平台 | 跨节点通信、分布式调度、规模扩展 |
|
||||||
|
|
||||||
|
`T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
|
||||||
|
`T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
|
||||||
|
|
||||||
|
其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
|
||||||
|
|
||||||
|
## 4. 人工智能目标负载与系统负载结构
|
||||||
|
|
||||||
|
在任务关键系统里，负载应至少分成三类：
|
||||||
|
|
||||||
|
| 负载类型 | 定义 | 例子 |
|
||||||
|
|---|---|---|
|
||||||
|
| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
|
||||||
|
| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、联锁、状态采集、执行输出 |
|
||||||
|
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、后台通信、模型加载、I/O |
|
||||||
|
|
||||||
|
本项目重点评估的是：
|
||||||
|
|
||||||
|
> **RTOS 协调人工智能目标负载与关键保障负载时，对系统边界的维持能力与成立条件。**
|
||||||
|
|
||||||
|
这一步会直接影响实验设计、论文结构和评价指标。
|
||||||
|
|
||||||
|
## 5. 准入与对照的实验顺序
|
||||||
|
|
||||||
|
本项目采用分阶段准入机制：
|
||||||
|
|
||||||
|
| 门槛 | 核心检查内容 |
|
||||||
|
|---|---|
|
||||||
|
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑 |
|
||||||
|
| `G1` 测量准入 | 单调时钟、日志、外部测量链路、功率计 |
|
||||||
|
| `G2` 加速器准入 | CUDA / RKLLM / RKNN / 驱动 / 最小算子 |
|
||||||
|
| `G3` 模型准入 | 模型转换、加载、正确推理与峰值内存 |
|
||||||
|
| `G4` 混合场景准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
|
||||||
|
|
||||||
|
只有通过 `G4` 的平台与配置，才能进入正式对照。
|
||||||
|
|
||||||
|
## 6. O0~O4 对照组结构
|
||||||
|
|
||||||
|
主对照统一采用：
|
||||||
|
|
||||||
|
| 编号 | 配置 | 作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| `O0` | 普通 Linux | 通用系统基线 |
|
||||||
|
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
|
||||||
|
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
|
||||||
|
| `O3` | SylixOS 优化配置 | 主实验组 |
|
||||||
|
|
||||||
|
必要时增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，并继续保持“普通 Linux”和“实时增强 Linux”的对照边界。
|
||||||
|
|
||||||
|
## 7. 实验逻辑如何展开
|
||||||
|
|
||||||
|
实验逻辑遵循从简单到复杂、从单目标到双目标的顺序：
|
||||||
|
|
||||||
|
1. 先确认平台、模型与测量链路可用；
|
||||||
|
2. 再测仅人工智能目标负载的基线表现；
|
||||||
|
3. 再测仅关键保障负载的下界行为；
|
||||||
|
4. 再测两者并存的核心场景；
|
||||||
|
5. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
|
||||||
|
|
||||||
|
这条顺序用于区分平台就绪性问题与系统机制边界问题。
|
||||||
|
|
||||||
|
对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
|
||||||
|
|
||||||
|
## 8. 哪些指标构成核心证据
|
||||||
|
|
||||||
|
后续证据链必须覆盖三层：
|
||||||
|
|
||||||
|
### 8.1 人工智能目标负载层
|
||||||
|
|
||||||
|
- `TTFT`
|
||||||
|
- `TPOT`
|
||||||
|
- 端到端响应时间
|
||||||
|
- 成功率、任务质量、输出可用性
|
||||||
|
- 长时间运行稳定性
|
||||||
|
|
||||||
|
### 8.2 关键保障负载层
|
||||||
|
|
||||||
|
- `deadline miss ratio`
|
||||||
|
- `P99/P99.9 jitter`
|
||||||
|
- 观测最大响应时间
|
||||||
|
- 外部接口响应时间
|
||||||
|
|
||||||
|
### 8.3 系统协同层
|
||||||
|
|
||||||
|
- 有效吞吐
|
||||||
|
- `E/token`
|
||||||
|
- 温度、降频和热漂移
|
||||||
|
- 多任务公平性
|
||||||
|
- 恢复能力与 24 h 长稳表现
|
||||||
|
|
||||||
|
项目最终形成的核心判断是：
|
||||||
|
|
||||||
|
> **在双目标约束下，RTOS 对系统稳定性、可预测性与可保障性的提升边界。**
|
||||||
|
|
||||||
|
## 9. 数据如何转化为论文贡献
|
||||||
|
|
||||||
|
论文贡献排序如下：
|
||||||
|
|
||||||
|
| 贡献 | 所需证据 | 对应论文位置 |
|
||||||
|
|---|---|---|
|
||||||
|
| `C1` RTOS 对人工智能目标负载与关键保障负载的实时保障优势 | 双目标达标、尾部行为、有效吞吐与恢复结果 | 第1、4、5、7、8章 |
|
||||||
|
| `C2` T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵 | 跨档位容量、功耗、拓扑与边界分析 | 第3、7、8章 |
|
||||||
|
| `C3` 可复现的方法论与基准对齐 | 准入、元数据、第三方基准复现、消融与统计口径 | 第5、7、9章 |
|
||||||
|
|
||||||
|
在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
|
||||||
|
|
||||||
|
面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
|
||||||
|
|
||||||
|
## 10. 最终闭环
|
||||||
|
|
||||||
|
本研究形成的核心结论关系是：
|
||||||
|
|
||||||
|
> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
|
||||||
|
|
||||||
|
在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
|
||||||
|
|
||||||
|
- 研究对象清楚；
|
||||||
|
- 验证矩阵完整；
|
||||||
|
- 对照关系公平；
|
||||||
|
- 评价框架统一；
|
||||||
|
- 论文叙事和产业叙事都能站住。
|
||||||
@@ -0,0 +1,783 @@
|
|||||||
|
# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
|
||||||
|
|
||||||
|
> 版本: v2.1 起草日期: 2026-09-21
|
||||||
|
> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
|
||||||
|
> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. 场景、算力基础与设备档位总览
|
||||||
|
|
||||||
|
### 0.1 研究框架与设备谱系的对应关系
|
||||||
|
|
||||||
|
研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
|
||||||
|
本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
|
||||||
|
这里完整呈现硬件与指标颗粒度，并明确：
|
||||||
|
|
||||||
|
> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
|
||||||
|
|
||||||
|
| 研究维度 | 定义 | 在本文件中的落地方式 |
|
||||||
|
|---|---|---|
|
||||||
|
| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
|
||||||
|
| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
|
||||||
|
| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
|
||||||
|
|
||||||
|
`T5~T1` 是用于实验组织的**部署形态代码**。
|
||||||
|
这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
|
||||||
|
后续实验中，这些档位分别承担的是：
|
||||||
|
|
||||||
|
- 人工智能目标负载在不同资源条件下的时效与有效性验证；
|
||||||
|
- 关键保障负载在不同资源条件下的边界验证；
|
||||||
|
- RTOS 在双目标约束下的机制有效性验证。
|
||||||
|
|
||||||
|
### 0.2 分级维度与分档规则
|
||||||
|
|
||||||
|
**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
|
||||||
|
|
||||||
|
**分档规则**: 相邻两档的边界值归入**上界一侧**
|
||||||
|
|
||||||
|
| 部署形态 | 代码 | 代表档位 | 容量范围 | 说明 |
|
||||||
|
| -------- | --- | --------------- | ---------------- | ---------------- |
|
||||||
|
| **T5 控制端场景** | T5 | **T5-L / T5-M / T5-H** | **1~8 G** | 运行在控制器或轻量控制盒本体 |
|
||||||
|
| **T4 设备端 SoC 场景** | T4 | **T4-L / T4-M** | **8~32 G** | 运行在设备本体 SoC 上 |
|
||||||
|
| **T3 边缘节点场景** | T3 | **T3-L** | **32~64 G / 48 G 独显** | 运行在设备附近的边缘节点 |
|
||||||
|
| **T2 桌面/工作站单机场景** | T2 | **T2-L / T2-M / T2-H** | **64~512 G** | 研发或本地服务用单机多卡 |
|
||||||
|
| **T1 服务器/集群场景** | T1 | **T1-L / T1-H** | **512 G~2 T** | 多节点分布式推理 |
|
||||||
|
|
||||||
|
> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
|
||||||
|
|
||||||
|
### 0.3 全谱系总表（11 个档位）
|
||||||
|
|
||||||
|
> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。
|
||||||
|
|
||||||
|
| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 |
|
||||||
|
| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- |
|
||||||
|
| **T5-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | |
|
||||||
|
| **T5-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | |
|
||||||
|
| **T5-H** | 4~8 G | 6~32 TOPS (INT8) | 7~21 W | ARM A76+A55 + M0 + NPU；DC 12V 被动 | **RK3588 8GB** / Jetson Orin Nano 8GB | 现有（16G 板降配） |
|
||||||
|
| **T4-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 |
|
||||||
|
| **T4-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | |
|
||||||
|
| **T3-L** | 32~64 G / 48 G 独显 | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | |
|
||||||
|
| **T2-L** | 64~128 G | 500 TFLOPS (FP16) | 600~1.65 kW | x86 + 4×V100 SXM NVLink；双电源 + 360 液冷 | **4×V100 32GB SXM 塔式** | 现有 |
|
||||||
|
| **T2-M** | 128~256 G | 1000 TFLOPS (FP16) | 3.0~3.3 kW | x86 + 8×V100 SXM NVLink；双电源 + 液冷 | 8×V100 32GB SXM 整机 | 需扩展 |
|
||||||
|
| **T2-H** | 256~512 G | ~4000 TFLOPS (FP16) | 4.5~6.5 kW | x86 + 4×H100 SXM5 NVLink；高压供电 + 强制液冷 | 4×H100 80GB SXM5 工作站 | |
|
||||||
|
| **T1-L** | 512 G~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × x86+4×V100，100GbE RoCE/IB；机房风冷/液冷 | 4×（T2-L 节点）+ IB 交换机 | 需扩展 |
|
||||||
|
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | 20~25 kW | 4 节点 × x86+4×H100，NDR 400G IB；机房级液冷 | 4×（T2-H 节点）+ NDR 交换机 | |
|
||||||
|
|
||||||
|
### 0.4 设计原则
|
||||||
|
|
||||||
|
1. **部署形态先行、设备落地**: 先用“控制端 / 设备端 SoC / 边缘节点 / 桌面工作站 / 服务器集群”定义研究问题，再用 `T5~T1` 设备档位组织具体实验。
|
||||||
|
2. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
|
||||||
|
3. **CUDA 栈贯通高算力侧**: T1/T2/T3 的候选平台可共享 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位迁移，主要变化是规模与拓扑。
|
||||||
|
4. **非 CUDA 控制端与设备端路线**: T5 全档位与 T4-L 走 RKNN/RKLLM NPU 栈，代表最强资源约束与最接近设备本体的运行位置。
|
||||||
|
5. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T4-L 16GB / T5-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
|
||||||
|
6. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2/T3-B 路线）与 ARM64（T5/T4/T3-A 路线），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T1. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
|
||||||
|
|
||||||
|
### T1.1 定位
|
||||||
|
|
||||||
|
大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。
|
||||||
|
|
||||||
|
### T1.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T1-L 多节点-低 | T1-H 多节点-高 |
|
||||||
|
| ----------- | --------------------- | --------------------------- |
|
||||||
|
| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
|
||||||
|
| **节点数** | 4 节点 | 4 节点 |
|
||||||
|
| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||||
|
| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) |
|
||||||
|
| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s |
|
||||||
|
| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB |
|
||||||
|
| **整机功耗** | ~6.6 kW | 20~25 kW |
|
||||||
|
| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
|
||||||
|
| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
|
||||||
|
|
||||||
|
#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
|
||||||
|
|
||||||
|
| 项目 | 规格 | 数量 | 备注 |
|
||||||
|
| --------- | ------------------------------------------------ | ------------- | --------------------------- |
|
||||||
|
| **计算节点** | 同 T2-L 单机配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
|
||||||
|
| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 |
|
||||||
|
| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 |
|
||||||
|
| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB |
|
||||||
|
| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB |
|
||||||
|
| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 |
|
||||||
|
| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 |
|
||||||
|
| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L |
|
||||||
|
| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW |
|
||||||
|
| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 |
|
||||||
|
|
||||||
|
**显存与算力**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| --------------- | ---------------------------------- |
|
||||||
|
| **总显存** | **512 GB** (4 × 128GB) |
|
||||||
|
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||||
|
| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) |
|
||||||
|
| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | ------- | ----- | ------------------ |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 |
|
||||||
|
| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray |
|
||||||
|
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) |
|
||||||
|
| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray |
|
||||||
|
|
||||||
|
> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
|
||||||
|
|
||||||
|
#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
|
||||||
|
|
||||||
|
| 项目 | 规格 | 数量 | 备注 |
|
||||||
|
| ------- | ----------------------------------------- | --------- | --------------------- |
|
||||||
|
| 计算节点 | 同 T2-H 单机配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
|
||||||
|
| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s |
|
||||||
|
| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 |
|
||||||
|
| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB |
|
||||||
|
| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 |
|
||||||
|
| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 |
|
||||||
|
| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 |
|
||||||
|
| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 |
|
||||||
|
| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | -------- | ----- | -------------------- |
|
||||||
|
| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang |
|
||||||
|
| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM |
|
||||||
|
| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI |
|
||||||
|
| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM |
|
||||||
|
|
||||||
|
### T1.3 SylixOS 要求（T1 通用）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| ------------------ | ------------------------------- | ------------------------------ |
|
||||||
|
| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） |
|
||||||
|
| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） |
|
||||||
|
| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） |
|
||||||
|
| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） |
|
||||||
|
| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** |
|
||||||
|
|
||||||
|
### T1.4 研究角度
|
||||||
|
|
||||||
|
- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟
|
||||||
|
- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟
|
||||||
|
- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性
|
||||||
|
- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益）
|
||||||
|
- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T2. 高算力单机部署形态 — 64 G ~ 512 G
|
||||||
|
|
||||||
|
### T2.1 定位
|
||||||
|
|
||||||
|
单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。
|
||||||
|
|
||||||
|
### T2.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T2-L 单机-低 | T2-M 单机-中 | T2-H 单机-高 |
|
||||||
|
| ----------- | ---------------------- | --------------------------- | --------------------------- |
|
||||||
|
| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） |
|
||||||
|
| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 |
|
||||||
|
| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) |
|
||||||
|
| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 |
|
||||||
|
| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW |
|
||||||
|
| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 |
|
||||||
|
| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 |
|
||||||
|
| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 |
|
||||||
|
| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
|
||||||
|
| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
|
||||||
|
|
||||||
|
#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
|
||||||
|
|
||||||
|
| # | 部件 | 型号 / 规格 | 数量 | 备注 |
|
||||||
|
| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
|
||||||
|
| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | |
|
||||||
|
| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | |
|
||||||
|
| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 |
|
||||||
|
| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 |
|
||||||
|
| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU |
|
||||||
|
| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | |
|
||||||
|
| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 |
|
||||||
|
| 8 | 机箱 | 塔式一体定制机箱 | 1 | |
|
||||||
|
| 9 | 主电源 | 长城全模组 1650W | 1 | |
|
||||||
|
| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 |
|
||||||
|
| 11 | 散热器 | SP3 高性能散热器 | 1 | |
|
||||||
|
| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | |
|
||||||
|
| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** |
|
||||||
|
|
||||||
|
**显存与算力**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| ---------- | --------------------------- |
|
||||||
|
| **总显存** | **128 GB** (4 × 32GB HBM2) |
|
||||||
|
| 单卡显存 | 32 GB HBM2 |
|
||||||
|
| 单卡 FP16 算力 | 125 TFLOPS |
|
||||||
|
| 总算力 (FP16) | ~500 TFLOPS |
|
||||||
|
| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) |
|
||||||
|
| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) |
|
||||||
|
| **整机功耗** | **~1650 W** (满载) |
|
||||||
|
|
||||||
|
**可运行模型**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
|
||||||
|
| ------------------------ | ---------- | ------ | ----- | ------------------- |
|
||||||
|
| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM |
|
||||||
|
| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM |
|
||||||
|
| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) |
|
||||||
|
| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM |
|
||||||
|
| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp |
|
||||||
|
| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper |
|
||||||
|
|
||||||
|
#### T2.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
|
||||||
|
|
||||||
|
在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
|
||||||
|
|
||||||
|
| 项目 | 规格 | 变更点 |
|
||||||
|
| --------- | ----------------------------------------------- | ------------------ |
|
||||||
|
| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 |
|
||||||
|
| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 |
|
||||||
|
| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 |
|
||||||
|
| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 |
|
||||||
|
| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 |
|
||||||
|
| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory |
|
||||||
|
| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 |
|
||||||
|
| 散热 | 360 液冷 ×2 + 机箱风道强化 | — |
|
||||||
|
| **整机功耗** | **~3.0~3.3 kW** | +100% |
|
||||||
|
| **总算力** | **~1000 TFLOPS (FP16)** | +100% |
|
||||||
|
|
||||||
|
**可运行模型（新增/提升）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||||
|
| ------------------------ | ---------- | ------ | ----- | ------------------ |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 |
|
||||||
|
| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 |
|
||||||
|
| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — |
|
||||||
|
| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 |
|
||||||
|
|
||||||
|
> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。
|
||||||
|
|
||||||
|
#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| ------- | ---------------------------------------- |
|
||||||
|
| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） |
|
||||||
|
| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) |
|
||||||
|
| 单卡显存 | 80 GB HBM3 |
|
||||||
|
| NVLink | 900 GB/s (GPU↔GPU) |
|
||||||
|
| CPU | AMD EPYC 9654 (96C/192T) ×1~2 |
|
||||||
|
| 内存 | 512 GB DDR5-4800 ECC |
|
||||||
|
| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） |
|
||||||
|
| 存储 | 4 TB NVMe RAID0（模型权重加载） |
|
||||||
|
| 散热 | **强制液冷（冷板式）**，风冷不可行 |
|
||||||
|
| 电源 | 2 × 3000W 冗余 / 220V |
|
||||||
|
| **整机功耗** | **~4.5~6.5 kW** |
|
||||||
|
| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS |
|
||||||
|
|
||||||
|
**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。
|
||||||
|
|
||||||
|
**可运行模型（新增/提升）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
|
||||||
|
| ------------------------ | ---------- | ------- | ----- | ----------------- |
|
||||||
|
| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 |
|
||||||
|
| LLaMA-3-70B | FP16 | ~140 GB | 2 | — |
|
||||||
|
| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 |
|
||||||
|
| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 |
|
||||||
|
|
||||||
|
### T2.3 SylixOS 要求（T2 三档通用）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| ----------------- | ----------------------------- | ------------------- |
|
||||||
|
| x86 BSP | SylixOS 2.x LTS x86 | 低 |
|
||||||
|
| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） |
|
||||||
|
| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 |
|
||||||
|
| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） |
|
||||||
|
| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 |
|
||||||
|
| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） |
|
||||||
|
|
||||||
|
### T2.4 对照组 OS
|
||||||
|
|
||||||
|
- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM
|
||||||
|
- **辅助对照**: CentOS Stream 9 + RT 内核（可选）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
|
||||||
|
|
||||||
|
### T3.1 定位
|
||||||
|
|
||||||
|
边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。
|
||||||
|
它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
|
||||||
|
|
||||||
|
### T3.2 代表档位对比
|
||||||
|
|
||||||
|
| 维度 | T3-L 边缘节点代表档 |
|
||||||
|
| --------- | ---------------- |
|
||||||
|
| **容量** | 64 GB 统一内存 / 48 GB 独立显存 |
|
||||||
|
| **加速器** | Jetson AGX Orin 64GB / RTX 6000 Ada 48GB |
|
||||||
|
| **算力** | 275 TOPS (INT8) / 91 TFLOPS (FP16) |
|
||||||
|
| **功耗** | 15~60 W / ~600 W |
|
||||||
|
| **部署位置** | 设备附近机柜、边缘控制室、产线边缘节点 |
|
||||||
|
| **主要任务** | 多模态推理、近源协同、边缘缓存与调度 |
|
||||||
|
|
||||||
|
### T3.3 候选平台
|
||||||
|
|
||||||
|
- Jetson AGX Orin 64GB：统一内存、能效高，适合近设备部署；
|
||||||
|
- 边缘工控机 + RTX 6000 Ada 48GB：生态完整，适合边缘机柜和算力下沉场景。
|
||||||
|
|
||||||
|
### T3.4 研究重点
|
||||||
|
|
||||||
|
- 设备端到边缘节点的协同调度；
|
||||||
|
- 近源多任务并发下的实时隔离；
|
||||||
|
- 边缘节点与桌面/工作站单机在功耗、散热和部署约束上的边界。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T4. 设备端 SoC 场景 — 8 G ~ 32 G
|
||||||
|
|
||||||
|
### T4.1 定位
|
||||||
|
|
||||||
|
设备端 SoC 直接运行在终端设备本体上。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性，即推理任务与实时控制任务共享本机资源时的隔离能力。
|
||||||
|
|
||||||
|
### T4.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T4-L SoC-低 | T4-M SoC-中 |
|
||||||
|
| --------- | ---------------------------- | -------------------------- |
|
||||||
|
| **容量** | 16 GB 统一内存 | 32 GB 统一内存 |
|
||||||
|
| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA |
|
||||||
|
| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) |
|
||||||
|
| **功耗** | 10~30 W | 15~60 W |
|
||||||
|
| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 |
|
||||||
|
| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ |
|
||||||
|
| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T5） | **高**（T234 BSP 需验证） |
|
||||||
|
| **状态** | （RK3588 16GB 工业盒） | 待验证 |
|
||||||
|
|
||||||
|
#### T4.2.1 T4-L SoC-低 — RK3588 16GB 工业盒（现有设备）
|
||||||
|
|
||||||
|
**这是现有 RK3588 设备的标准归属档位**，也是唯一可零成本立即开展研究的设备端 SoC 档位。
|
||||||
|
|
||||||
|
| 项目 | 规格 | 备注 |
|
||||||
|
| --------- | --------------------------------------- | --------------------- |
|
||||||
|
| SoC | Rockchip RK3588（同 T5-H） | SylixOS BSP 与 T5 共用 |
|
||||||
|
| 内存 | **16 GB LPDDR4X**（统一内存） | -40~60 ℃ 工业宽温 |
|
||||||
|
| NPU | 6 TOPS 原生 + **26 TOPS 算力棒扩展 = 32 TOPS** | 算力棒走 M.2 2280 |
|
||||||
|
| 功耗 | ~21~30 W（含算力棒） | 被动散热，可选小风扇 |
|
||||||
|
| 内存带宽 | ~51.2 GB/s (128-bit LPDDR4X) | 与 T5-H 同源，是带宽瓶颈点 |
|
||||||
|
| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T5-H 内存翻倍，可跑更大模型 |
|
||||||
|
|
||||||
|
**备选方案（同档位、CUDA 路线）**: NVIDIA Jetson Orin NX 16GB — 100 TOPS (INT8, sparse)，1024 CUDA + 32 Tensor Core，16 GB LPDDR5 / 102.4 GB/s，10~25 W，**CUDA 生态与 T1/T2/T3 打通**。代价是 SylixOS T234 BSP 风险高。
|
||||||
|
|
||||||
|
#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | -------------------------------------------------- |
|
||||||
|
| **SoC** | NVIDIA T234（Grace 系列衍生） |
|
||||||
|
| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） |
|
||||||
|
| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores |
|
||||||
|
| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） |
|
||||||
|
| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) |
|
||||||
|
| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） |
|
||||||
|
| 内存带宽 | 204.8 GB/s |
|
||||||
|
| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） |
|
||||||
|
| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） |
|
||||||
|
| 存储 | 64GB eMMC + M.2 NVMe（可扩展） |
|
||||||
|
| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 |
|
||||||
|
| 视频接口 | HDMI 2.1 + DP 1.4a |
|
||||||
|
| USB | 4× USB 3.2 + 2× USB 2.0 |
|
||||||
|
| PCIe | PCIe Gen4 ×4（可扩展外设） |
|
||||||
|
| MIPI CSI | 4 通道（可接工业相机） |
|
||||||
|
| 尺寸 | 100mm × 87mm（核心模块） |
|
||||||
|
| **出厂 OS** | Ubuntu 20.04 LTS (L4T) |
|
||||||
|
| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） |
|
||||||
|
|
||||||
|
**选择 Jetson AGX Orin 的理由**
|
||||||
|
|
||||||
|
1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈
|
||||||
|
2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台
|
||||||
|
3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证
|
||||||
|
4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
|
||||||
|
5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
|
||||||
|
|
||||||
|
#### T3 边缘节点候选平台
|
||||||
|
|
||||||
|
64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
|
||||||
|
|
||||||
|
**可运行模型（T4 两档合并）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 |
|
||||||
|
| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ |
|
||||||
|
| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T4-L | RKLLM |
|
||||||
|
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T4-L / T4-M | TensorRT-LLM / RKLLM |
|
||||||
|
| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T4-L / T4-M | TensorRT-LLM / llama.cpp |
|
||||||
|
| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T4-M | TensorRT-LLM |
|
||||||
|
| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T4-M | TensorRT-LLM |
|
||||||
|
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T4-L 以上 | llama.cpp |
|
||||||
|
| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T4-L 以上 | faster-whisper |
|
||||||
|
| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T4 全档 | TensorRT / RKNN |
|
||||||
|
|
||||||
|
### T4.3 SylixOS 要求（T4）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 |
|
||||||
|
| -------------------- | --------------------------------------- | ---------------------------- |
|
||||||
|
| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
|
||||||
|
| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险 | **极低** |
|
||||||
|
| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
|
||||||
|
| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
|
||||||
|
| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
|
||||||
|
| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
|
||||||
|
| 独立显存管理（T3 B 路线） | x86 + 独显的显存分配与实时性 | 中 |
|
||||||
|
|
||||||
|
> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
|
||||||
|
|
||||||
|
### T4.4 对照组 OS
|
||||||
|
|
||||||
|
| 档位 | 主对照 | 辅助对照 |
|
||||||
|
| ---- | -------------------------------- | ----------------------------- |
|
||||||
|
| T4-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
|
||||||
|
| T4-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） |
|
||||||
|
|
||||||
|
### T4.5 功率采集
|
||||||
|
|
||||||
|
| 设备 | 用途 | 适用档位 |
|
||||||
|
| ----------------------------- | --------------------- | ----------- |
|
||||||
|
| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T4-L / T4-M |
|
||||||
|
| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
|
||||||
|
| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T4-M / T3-L |
|
||||||
|
| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-L B 路线 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## T5. 控制端场景 — 1 G ~ 8 G
|
||||||
|
|
||||||
|
### T5.1 定位
|
||||||
|
|
||||||
|
工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
|
||||||
|
|
||||||
|
### T5.2 档位对比
|
||||||
|
|
||||||
|
| 维度 | T5-L 控制端-低 | T5-M 控制端-中 | T5-H 控制端-高 |
|
||||||
|
| ----------- | ---------------------- | -------------------- | ------------------------------ |
|
||||||
|
| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 |
|
||||||
|
| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano |
|
||||||
|
| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) |
|
||||||
|
| **功耗** | 3~5 W | 5~10 W | 7~21 W |
|
||||||
|
| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） |
|
||||||
|
| **供电** | DC 5V / 12V | DC 12V | DC 12V |
|
||||||
|
| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ |
|
||||||
|
| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
|
||||||
|
| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
|
||||||
|
|
||||||
|
#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | -------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3568 (22nm) |
|
||||||
|
| CPU | 4× Cortex-A55 @ 2.0 GHz |
|
||||||
|
| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） |
|
||||||
|
| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） |
|
||||||
|
| 内存带宽 | ~25.6 GB/s |
|
||||||
|
| GPU | Mali-G52（仅辅助显示） |
|
||||||
|
| 存储 | 8~16 GB eMMC |
|
||||||
|
| 网络 | 1× 千兆 + 可选 WiFi |
|
||||||
|
| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） |
|
||||||
|
| **功耗** | **3~5 W**（无风扇被动散热） |
|
||||||
|
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||||
|
| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） |
|
||||||
|
| 参考价格 | ~300~800 RMB（核心板/开发板） |
|
||||||
|
|
||||||
|
**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
|
||||||
|
**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
|
||||||
|
|
||||||
|
#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | ---------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3576 (8nm) |
|
||||||
|
| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） |
|
||||||
|
| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 |
|
||||||
|
| **内存** | **2~4 GB LPDDR5**（统一内存） |
|
||||||
|
| 内存带宽 | ~40 GB/s |
|
||||||
|
| **功耗** | **5~10 W**（无风扇被动） |
|
||||||
|
| 工作温度 | -40 ~ 85 ℃ 工业级 |
|
||||||
|
| 参考价格 | ~600~1,500 RMB |
|
||||||
|
|
||||||
|
**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
|
||||||
|
**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
|
||||||
|
|
||||||
|
#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
|
||||||
|
|
||||||
|
**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
|
||||||
|
|
||||||
|
| 项目 | 规格 | 说明 |
|
||||||
|
| --------- | --------------------------------------------------- | ------------------------ |
|
||||||
|
| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** |
|
||||||
|
| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 |
|
||||||
|
| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 |
|
||||||
|
| GPU | Mali-G610 MC4 | 仅辅助显示 |
|
||||||
|
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
|
||||||
|
| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
|
||||||
|
| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T4-L 同 |
|
||||||
|
| **功耗** | **7~21 W**（无风扇被动散热） | 6 TOPS 档 ~12W / 32 TOPS 档 ~21W |
|
||||||
|
| 工作温度 | -40 ~ 60 ℃ 工业级 | 宽温优势 |
|
||||||
|
| 出厂 OS | Ubuntu 22.04 | 换 SylixOS BSP |
|
||||||
|
|
||||||
|
> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
|
||||||
|
|
||||||
|
**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| --------- | --------------------------------------------------- |
|
||||||
|
| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） |
|
||||||
|
| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
|
||||||
|
| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
|
||||||
|
| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
|
||||||
|
| 优势 | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
|
||||||
|
| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
|
||||||
|
| 参考价格 | ~$249（开发套件） |
|
||||||
|
|
||||||
|
**可运行模型（T5-H）**
|
||||||
|
|
||||||
|
| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
|
||||||
|
| ------------------------- | ---- | ------- | ----------- | ----- |
|
||||||
|
| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM |
|
||||||
|
| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM |
|
||||||
|
| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
|
||||||
|
| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
|
||||||
|
|
||||||
|
#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
|
||||||
|
|
||||||
|
**系统 (System)**
|
||||||
|
|
||||||
|
| 项目 | 规格 |
|
||||||
|
| ------- | ---------------------------------------------------- |
|
||||||
|
| SoC | Rockchip RK3588 (8nm) |
|
||||||
|
| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） |
|
||||||
|
| MCU | Cortex-M0 @200 MHz（协处理，可选） |
|
||||||
|
| GPU | Mali-G610 MC4 |
|
||||||
|
| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
|
||||||
|
| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H |
|
||||||
|
| **显存** | 统一内存（NPU 与 CPU 共享） |
|
||||||
|
|
||||||
|
**存储 / 扩展**
|
||||||
|
|
||||||
|
- EMMC 64 GB（系统盘）
|
||||||
|
- 1× TF 卡槽（存储扩展）
|
||||||
|
- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒）
|
||||||
|
|
||||||
|
**出厂软件**
|
||||||
|
|
||||||
|
- 操作系统: **Ubuntu 22.04**（出厂预装）
|
||||||
|
- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
|
||||||
|
|
||||||
|
**算力与功耗（T5-H 档）**
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
| ------------------ | ------------------------------- |
|
||||||
|
| **可用显存** | **8 GB**（16 GB 板分区限额） |
|
||||||
|
| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) |
|
||||||
|
| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) |
|
||||||
|
| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） |
|
||||||
|
| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
|
||||||
|
| **TDP** | **7~21 W**（无风扇被动散热） |
|
||||||
|
|
||||||
|
### T5.3 SylixOS 要求（T5）
|
||||||
|
|
||||||
|
| 要求项 | 描述 | 风险 | 适用档位 |
|
||||||
|
| ---------------------- | --------------------------------------- | -------------------- | --------- |
|
||||||
|
| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T5-H |
|
||||||
|
| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T5-M |
|
||||||
|
| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T5-L |
|
||||||
|
| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T5 全档 |
|
||||||
|
| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T5-H |
|
||||||
|
| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T5-H |
|
||||||
|
| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T4-L/T5-H 切换） | 中（需 SylixOS 内存域支持） | T5-H |
|
||||||
|
| CAN ×2 驱动 | 工业现场总线 | 中 | T5 全档 |
|
||||||
|
| RS485 ×2 + RS232 ×1 | 串口 | 低 | T5 全档 |
|
||||||
|
| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T5-H |
|
||||||
|
| 看门狗 / RTC | 工业可靠性 | 低 | T5 全档 |
|
||||||
|
| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T5-H 路线B |
|
||||||
|
|
||||||
|
### T5.4 对照组 OS
|
||||||
|
|
||||||
|
- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
|
||||||
|
- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
|
||||||
|
- T5-L / T5-M: Buildroot + PREEMPT_RT
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. 跨档位对比总表
|
||||||
|
|
||||||
|
### 5.1 全档位硬件规格对比
|
||||||
|
|
||||||
|
| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 |
|
||||||
|
| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- |
|
||||||
|
| **T5-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 |
|
||||||
|
| **T5-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 |
|
||||||
|
| **T5-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） |
|
||||||
|
| **T4-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） |
|
||||||
|
| **T4-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** |
|
||||||
|
| **T3-L** | 32~64 GB / 48 GB 独显 | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 |
|
||||||
|
| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） |
|
||||||
|
| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 |
|
||||||
|
| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 |
|
||||||
|
| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 |
|
||||||
|
| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 |
|
||||||
|
|
||||||
|
### 5.2 模型规模梯度
|
||||||
|
|
||||||
|
| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
|
||||||
|
| -------- | --------------------------- | ---------- | ------- | -------------- |
|
||||||
|
| T5-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 控制端最低资源参考档，实时性基准 |
|
||||||
|
| T5-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 控制端能效拐点 |
|
||||||
|
| T5-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B |
|
||||||
|
| T4-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 设备端推理 + 工业控制 |
|
||||||
|
| T4-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 设备端多模型并发 |
|
||||||
|
| T3-L | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘节点可跑 72B |
|
||||||
|
| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 |
|
||||||
|
| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B |
|
||||||
|
| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 |
|
||||||
|
| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 |
|
||||||
|
| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 |
|
||||||
|
|
||||||
|
### 5.3 SylixOS 调度框架验证重点
|
||||||
|
|
||||||
|
| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
|
||||||
|
| ----- | ----------- | ---------------------------------- | -------------------------- |
|
||||||
|
| T5-L | 极小内存下保持关键保障负载边界 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 |
|
||||||
|
| T5-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token |
|
||||||
|
| T5-H | 极致资源约束下保持关键保障负载边界 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token |
|
||||||
|
| T4-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s |
|
||||||
|
| T4-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 |
|
||||||
|
| T3-L | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS |
|
||||||
|
| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 |
|
||||||
|
| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s |
|
||||||
|
| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 |
|
||||||
|
| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS |
|
||||||
|
| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 |
|
||||||
|
|
||||||
|
### 5.4 基线 OS 对照
|
||||||
|
|
||||||
|
| 档位 | SylixOS 实验组 | 主对照 (PREEMPT_RT Linux) | 虚拟化对照 | 容器对照 |
|
||||||
|
| ------- | ---------------------- | --------------------- | -------------- | --------- |
|
||||||
|
| T5-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker |
|
||||||
|
| T5-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker |
|
||||||
|
| T5-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T4-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T4-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T3-L | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
|
||||||
|
| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||||
|
| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. 采购与获取计划
|
||||||
|
|
||||||
|
| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
|
||||||
|
| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
|
||||||
|
| **P0** | T4-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
|
||||||
|
| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 |
|
||||||
|
| **P0** | T5-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T4-L 同机双档位 |
|
||||||
|
| **P1** | T5-L | RK3568 1~2GB 核心板 | ~300-800 | 控制端最低资源参考档，必做 |
|
||||||
|
| **P1** | T5-M | RK3576 4GB 核心板 | ~600-1,500 | 控制端能效拐点 |
|
||||||
|
| **P1** | T4-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP |
|
||||||
|
| **P2** | T4-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 |
|
||||||
|
| **P2** | T3-L | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘节点可跑 72B |
|
||||||
|
| **P2** | T5-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 |
|
||||||
|
| **P3** | T2-M | 4× V100 32GB SXM + 8 卡底板 + 电源 | ~70,000-100,000 | 现有平台加卡扩容 |
|
||||||
|
| **P3** | T2-H | 4× H100 80GB SXM5 工作站 | ~800,000-1,200,000 | 可租云实例替代 |
|
||||||
|
| **P3** | T1-L | 3× 计算节点 + 12× V100 + IB | ~270,000 | 可用云实例替代 |
|
||||||
|
| **P4** | T1-H | 4 节点 × 4×H100 + NDR IB | ~3,000,000+ | 强烈建议云租替代 |
|
||||||
|
| — | 仪器 | DC 功率计 ×2 (T4+T5) | ~6,000 | T5 强制 |
|
||||||
|
| — | 仪器 | INA226 采集板 ×2 | ~500 | T4+T5 |
|
||||||
|
| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3 / T2 档 |
|
||||||
|
| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） |
|
||||||
|
| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 |
|
||||||
|
| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） |
|
||||||
|
| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 |
|
||||||
|
|
||||||
|
### 降本策略
|
||||||
|
|
||||||
|
1. **P0 零成本起步**: T2-L + T4-L + T5-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
|
||||||
|
2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T4-L（16 GB）与 T5-H（8 GB），省去一台设备与一套 BSP 验证成本。
|
||||||
|
3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T5-M 若 RK3576 BSP 不可用，用 T5-H 降配替代），谱系不断。
|
||||||
|
4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
|
||||||
|
5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
|
||||||
|
6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. SylixOS BSP 适配 Checklist（跨档位汇总）
|
||||||
|
|
||||||
|
### 7.1 x86 BSP（T2 全档 + T1 全档）
|
||||||
|
|
||||||
|
- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动
|
||||||
|
- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度
|
||||||
|
- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心）
|
||||||
|
- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M）
|
||||||
|
- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H）
|
||||||
|
- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举
|
||||||
|
- [ ] nvidia-smi / DCGM 监控
|
||||||
|
- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行
|
||||||
|
- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属）
|
||||||
|
- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属）
|
||||||
|
- [ ] NCCL / MPI 分布式通信库（T1 专属）
|
||||||
|
- [ ] IPMI / BMC 功耗采集
|
||||||
|
- [ ] tickless + CPU 隔离 + 中断亲和性
|
||||||
|
- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
|
||||||
|
|
||||||
|
### 7.2 ARM64 BSP — T234 / Ampere（T4-M / T3-L-A / T5-H 路线B）
|
||||||
|
|
||||||
|
- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
|
||||||
|
- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
|
||||||
|
- [ ] Jetson Ampere GPU CUDA 驱动
|
||||||
|
- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属）
|
||||||
|
- [ ] 16/32/64 GB LPDDR5 统一内存管理
|
||||||
|
- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W)
|
||||||
|
- [ ] 10GbE 网络驱动
|
||||||
|
- [ ] MIPI CSI 工业相机接口
|
||||||
|
- [ ] PCIe Gen4 扩展
|
||||||
|
- [ ] 温度传感器 + 降频阈值
|
||||||
|
|
||||||
|
### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
|
||||||
|
- [ ] CPU 频率独立调节 (governor)
|
||||||
|
- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
|
||||||
|
- [ ] tickless / idle hook
|
||||||
|
- [ ] 看门狗驱动
|
||||||
|
- [ ] **rknn / RKLLM NPU 驱动**（核心）
|
||||||
|
- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位）
|
||||||
|
- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0）
|
||||||
|
- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动
|
||||||
|
- [ ] CAN ×2 驱动
|
||||||
|
- [ ] RS485 ×2 + RS232 ×1 驱动
|
||||||
|
- [ ] GPIO 子系统
|
||||||
|
- [ ] HDMI 输出（调试）
|
||||||
|
- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
|
||||||
|
|
||||||
|
### 7.4 ARM64 BSP — RK3576（T5-M）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
|
||||||
|
- [ ] 6 TOPS NPU 驱动（RKNN 栈）
|
||||||
|
- [ ] 2~4 GB LPDDR5 内存管理
|
||||||
|
- [ ] CAN / RS485 / 千兆网络驱动
|
||||||
|
- [ ] 低功耗被动散热下的频率/温度联动
|
||||||
|
|
||||||
|
### 7.5 ARM64 BSP — RK3568（T5-L）
|
||||||
|
|
||||||
|
- [ ] SylixOS BSP for RK3568（4×A55 SMP）
|
||||||
|
- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
|
||||||
|
- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点）
|
||||||
|
- [ ] CAN / RS485 / 千兆网络驱动
|
||||||
|
- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证
|
||||||
@@ -0,0 +1,302 @@
|
|||||||
|
# SylixOS 任务关键系统中人工智能目标负载实验设计
|
||||||
|
|
||||||
|
> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
|
||||||
|
> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
|
||||||
|
|
||||||
|
## 1. 研究目标与实验范围
|
||||||
|
|
||||||
|
本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
|
||||||
|
|
||||||
|
| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
|
||||||
|
| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
|
||||||
|
| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
|
||||||
|
| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
|
||||||
|
|
||||||
|
执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
|
||||||
|
|
||||||
|
这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
|
||||||
|
|
||||||
|
在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
|
||||||
|
|
||||||
|
## 2. 设备分层与实验平台
|
||||||
|
|
||||||
|
### 2.1 T5~T1 五类部署形态、十一档实验映射
|
||||||
|
|
||||||
|
沿用设备文档的档位标签，实际容量单列。多节点架构统一记为 `T1-L`，容量边界单独记录，不据容量直接推导性能。
|
||||||
|
|
||||||
|
| 部署形态与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| T5-L 控制端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
|
||||||
|
| T5-M 控制端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
|
||||||
|
| T5-H 控制端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
|
||||||
|
| T4-L 设备端 SoC 低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
|
||||||
|
| T4-M 设备端 SoC 中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
|
||||||
|
| T3-L 边缘节点代表档 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 |
|
||||||
|
| T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
|
||||||
|
| T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
|
||||||
|
| T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
|
||||||
|
| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
|
||||||
|
| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |
|
||||||
|
|
||||||
|
GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
|
||||||
|
|
||||||
|
`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
|
||||||
|
|
||||||
|
其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
|
||||||
|
|
||||||
|
### 2.2 平台 A：现有 V100 服务器
|
||||||
|
|
||||||
|
依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
|
||||||
|
|
||||||
|
实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
|
||||||
|
|
||||||
|
分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
|
||||||
|
|
||||||
|
### 2.3 平台 B：现有 RK3588 工业盒
|
||||||
|
|
||||||
|
依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
|
||||||
|
|
||||||
|
- B16：全量 16 GB，记为 T4-L。
|
||||||
|
- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
|
||||||
|
- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
|
||||||
|
- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
|
||||||
|
|
||||||
|
**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
|
||||||
|
|
||||||
|
### 2.4 测量设备
|
||||||
|
|
||||||
|
| 测量对象 | 工具与接线 | 要求 |
|
||||||
|
|---|---|---|
|
||||||
|
| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 |
|
||||||
|
| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 |
|
||||||
|
| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 |
|
||||||
|
| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 |
|
||||||
|
| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 |
|
||||||
|
|
||||||
|
传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。
|
||||||
|
|
||||||
|
## 3. 软件与模型准入
|
||||||
|
|
||||||
|
### 3.1 分阶段准入门槛
|
||||||
|
|
||||||
|
| 门槛 | 验证内容 | 通过证据 | 失败后的处理 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 |
|
||||||
|
| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 |
|
||||||
|
| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 |
|
||||||
|
| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
|
||||||
|
| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
|
||||||
|
|
||||||
|
SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
|
||||||
|
|
||||||
|
“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
|
||||||
|
|
||||||
|
对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
|
||||||
|
|
||||||
|
### 3.2 模型梯度与用途
|
||||||
|
|
||||||
|
| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 |
|
||||||
|
| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 |
|
||||||
|
| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 |
|
||||||
|
| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 |
|
||||||
|
| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
|
||||||
|
| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
|
||||||
|
|
||||||
|
模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
|
||||||
|
|
||||||
|
### 3.3 输入与正确性控制
|
||||||
|
|
||||||
|
LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。
|
||||||
|
|
||||||
|
YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。
|
||||||
|
|
||||||
|
## 4. 指标定义与采集口径
|
||||||
|
|
||||||
|
### 4.1 实时性与系统开销
|
||||||
|
|
||||||
|
对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。
|
||||||
|
|
||||||
|
| 指标 | 定义 | 汇总 |
|
||||||
|
|---|---|---|
|
||||||
|
| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 |
|
||||||
|
| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 |
|
||||||
|
| 响应时间 | f_i − r_i | 分位数、观测最大值 |
|
||||||
|
| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 |
|
||||||
|
| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 |
|
||||||
|
| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 |
|
||||||
|
| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 |
|
||||||
|
|
||||||
|
缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。
|
||||||
|
|
||||||
|
### 4.2 推理服务
|
||||||
|
|
||||||
|
在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。
|
||||||
|
|
||||||
|
- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。
|
||||||
|
- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。
|
||||||
|
- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。
|
||||||
|
- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。
|
||||||
|
- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。
|
||||||
|
|
||||||
|
### 4.3 能耗与热状态
|
||||||
|
|
||||||
|
在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。
|
||||||
|
|
||||||
|
同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。
|
||||||
|
|
||||||
|
报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。
|
||||||
|
|
||||||
|
## 5. 对照组与变量控制
|
||||||
|
|
||||||
|
### 5.1 OS 与部署组
|
||||||
|
|
||||||
|
| 编号 | 配置 | 作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 |
|
||||||
|
| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
|
||||||
|
| O2 | SylixOS 默认配置 | 原生系统基线 |
|
||||||
|
| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
|
||||||
|
| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
|
||||||
|
| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
|
||||||
|
|
||||||
|
平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
|
||||||
|
|
||||||
|
### 5.2 配置控制与消融
|
||||||
|
|
||||||
|
所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。
|
||||||
|
|
||||||
|
完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。
|
||||||
|
|
||||||
|
## 6. 负载设计
|
||||||
|
|
||||||
|
### 6.1 实时任务
|
||||||
|
|
||||||
|
主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。
|
||||||
|
|
||||||
|
任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
|
||||||
|
|
||||||
|
### 6.2 伴生竞争负载与推理到达
|
||||||
|
|
||||||
|
| 场景 | 内容 | 目的 |
|
||||||
|
|---|---|---|
|
||||||
|
| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
|
||||||
|
| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
|
||||||
|
| L2 | 关键保障负载 + LLM | 核心双目标场景 |
|
||||||
|
| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
|
||||||
|
| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
|
||||||
|
| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务竞争 |
|
||||||
|
| L6 | 关键保障负载 + LLM + YOLO（可选） | 多人工智能目标负载竞争与优先级影响 |
|
||||||
|
| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
|
||||||
|
|
||||||
|
人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
|
||||||
|
|
||||||
|
突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
|
||||||
|
|
||||||
|
## 7. 实验矩阵与具体步骤
|
||||||
|
|
||||||
|
### 7.1 核心实验
|
||||||
|
|
||||||
|
| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 |
|
||||||
|
| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 |
|
||||||
|
| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 |
|
||||||
|
| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 |
|
||||||
|
| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 |
|
||||||
|
| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 |
|
||||||
|
| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 |
|
||||||
|
| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
|
||||||
|
| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
|
||||||
|
|
||||||
|
面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
|
||||||
|
|
||||||
|
- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
|
||||||
|
- `E3` 负责比较双目标并存时的达标边界；
|
||||||
|
- `E4` 负责观察内存限额与容量失败边界；
|
||||||
|
- `E6` 负责组织功耗、温度与降频证据；
|
||||||
|
- `E8` 负责验证长时间运行、恢复与热稳定性。
|
||||||
|
|
||||||
|
E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
|
||||||
|
|
||||||
|
E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
|
||||||
|
|
||||||
|
### 7.2 条件扩展
|
||||||
|
|
||||||
|
| 扩展 | 前提 | 实验内容 | 结论边界 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 |
|
||||||
|
| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 |
|
||||||
|
| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 |
|
||||||
|
| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 |
|
||||||
|
| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 |
|
||||||
|
|
||||||
|
T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
|
||||||
|
|
||||||
|
若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
|
||||||
|
|
||||||
|
跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
|
||||||
|
|
||||||
|
### 7.3 控制实验数量
|
||||||
|
|
||||||
|
不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。
|
||||||
|
|
||||||
|
## 8. 运行流程与统计方法
|
||||||
|
|
||||||
|
1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。
|
||||||
|
2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。
|
||||||
|
3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。
|
||||||
|
4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。
|
||||||
|
5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。
|
||||||
|
6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。
|
||||||
|
7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。
|
||||||
|
|
||||||
|
观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。
|
||||||
|
|
||||||
|
## 9. 验收与结果判断
|
||||||
|
|
||||||
|
验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
|
||||||
|
|
||||||
|
| 类型 | 判据 | 说明 |
|
||||||
|
|---|---|---|
|
||||||
|
| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 |
|
||||||
|
| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 |
|
||||||
|
| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 |
|
||||||
|
| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 |
|
||||||
|
| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 |
|
||||||
|
| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 |
|
||||||
|
|
||||||
|
当前候选阈值包括“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，并在正式实验前冻结；8/15/21 W 数值同样单独按配置记录，不作为跨配置统一验收值。
|
||||||
|
|
||||||
|
## 10. 数据产物与论文图表
|
||||||
|
|
||||||
|
建议按 `results/<experiment>/<platform>/<os>/<config>/<run_id>/` 保存数据，每次运行至少包含：
|
||||||
|
|
||||||
|
| 文件 | 内容 |
|
||||||
|
|---|---|
|
||||||
|
| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 |
|
||||||
|
| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 |
|
||||||
|
| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 |
|
||||||
|
| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 |
|
||||||
|
| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 |
|
||||||
|
| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 |
|
||||||
|
|
||||||
|
不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。
|
||||||
|
|
||||||
|
最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。
|
||||||
|
|
||||||
|
## 11. 实施顺序与停止条件
|
||||||
|
|
||||||
|
| 阶段 | 工作 | 完成标志 |
|
||||||
|
|---|---|---|
|
||||||
|
| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 |
|
||||||
|
| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 |
|
||||||
|
| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 |
|
||||||
|
| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 |
|
||||||
|
| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 |
|
||||||
|
| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 |
|
||||||
|
|
||||||
|
设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
|
||||||
@@ -0,0 +1,453 @@
|
|||||||
|
# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
|
||||||
|
|
||||||
|
> **版本**: v0.1 (研究启动版)
|
||||||
|
> **日期**: 2026-09-20
|
||||||
|
> **整合来源**: 01-研究逻辑说明.md + 02-基础设备与算力基础.md + 03-实验设计.md + 10-研究框架/00~07 系列文档 + 第三方基准复现思路
|
||||||
|
> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章规划稿 (后续随实验推进持续迭代)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. 文章定位与核心贡献
|
||||||
|
|
||||||
|
### 0.1 一句话定位
|
||||||
|
|
||||||
|
> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**
|
||||||
|
|
||||||
|
### 0.2 三大核心贡献
|
||||||
|
|
||||||
|
| 编号 | 贡献 | 来源整合 | 对标空白 |
|
||||||
|
|------|------|----------|----------|
|
||||||
|
| C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
|
||||||
|
| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
|
||||||
|
| C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
|
||||||
|
|
||||||
|
### 0.3 目标读者与发表场景
|
||||||
|
|
||||||
|
| 维度 | 选择 |
|
||||||
|
|------|------|
|
||||||
|
| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
|
||||||
|
| 备选 | EMSOFT / DAC / MLSys (系统方向) |
|
||||||
|
| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
|
||||||
|
| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. 文章整体结构 (十章)
|
||||||
|
|
||||||
|
```
|
||||||
|
第1章 引言 — 问题、动机、贡献概述
|
||||||
|
第2章 背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
|
||||||
|
第3章 T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
|
||||||
|
第4章 SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
|
||||||
|
第5章 实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
|
||||||
|
第6章 大模型负载选型与配置 — 跨档位模型矩阵
|
||||||
|
第7章 实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
|
||||||
|
第8章 深入分析 — 档位间性能曲线 + RTOS vs 普通 Linux / PREEMPT_RT 差异化
|
||||||
|
第9章 讨论与威胁有效性 — 适用场景边界 + 局限性
|
||||||
|
第10章 结论与展望
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. 逐章详细规划
|
||||||
|
|
||||||
|
### 第1章 引言
|
||||||
|
|
||||||
|
**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 1.1 问题矛盾 | 人工智能目标负载要求结果及时且有效，关键保障负载要求严格截止期；两者进入同一任务关键系统后，会在 CPU、内存、总线、加速器和中断路径上发生竞争 | |
|
||||||
|
| 1.2 研究空白 | 公开基准大多基于 Linux/Ubuntu，重点放在吞吐或单任务性能，缺少 RTOS 对人工智能目标负载与关键保障负载双目标实时保障的系统评测 | 01-研究逻辑说明.md §2、§8 |
|
||||||
|
| 1.3 本文贡献 | C1 (双目标实时保障优势)、C2 (五类部署形态统一验证矩阵)、C3 (业界基准对齐)，一句话概述每个贡献 | |
|
||||||
|
| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
|
||||||
|
|
||||||
|
**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第2章 背景与相关工作
|
||||||
|
|
||||||
|
**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 2.1 人工智能目标负载特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 I/O 抖动；输出质量与时效双重约束 | 03-实验设计.md §3、10-研究框架/01~04 |
|
||||||
|
| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 10-研究框架/00.md §3、05-中断与实时性保障.md |
|
||||||
|
| 2.3 PREEMPT_RT 相对短板 | 内核态长路径、系统后台线程、内存回收与共享资源竞争仍可能拉长 `P99.9`；其可预测性增强但不等同于专用 RTOS | 00-整体研究框架.md §5、07-方法论与评估工具链.md §2、§4 |
|
||||||
|
| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | 00-整体研究框架.md §6 |
|
||||||
|
| 2.5 第三方基准方法学 | 第三方文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 避坑清单 | 03-实验设计.md §4、07-方法论与评估工具链.md §8~§10 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
|
||||||
|
| Tab.1 | SylixOS vs 普通 Linux / PREEMPT_RT 对比 | 关键 RTOS 特性对应的双目标实时保障优势与对照平台短板 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第3章 T5~T1 五类部署形态验证矩阵
|
||||||
|
|
||||||
|
**目标**: 800~1000 词，用连续验证矩阵承载主问题，保持硬件作为验证矩阵的角色。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 3.1 分级维度与分档规则 | 以「部署形态」为第一分类维度，以「统一内存/显存容量」为分档参考；T5~T1 五类部署形态下连续展开 | 02-基础设备与算力基础.md §0.1 |
|
||||||
|
| 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
|
||||||
|
| 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
|
||||||
|
| 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
|
||||||
|
| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Fig.2 | T5~T1 五类部署形态验证矩阵全景图 | 横轴=容量 (1 GB→2 TB, log 刻度), 纵轴=功耗 (3 W→25 kW, log 刻度), 11 个档位点标注, 散热形态用颜色分区 (被动/风冷/液冷/机房液冷) |
|
||||||
|
| Tab.2 | 11 档位全规格对比表 | 容量、算力、功耗、加速器架构、散热、互联、SylixOS BSP 风险、状态 (现有/需扩展) |
|
||||||
|
| Tab.3 | 模型规模梯度表 | 11 档位 × 代表模型 × 量化 × 显存占用 × 角色 (控制端最低资源参考档→超大模型分布式) |
|
||||||
|
| Tab.4 | 采购计划表 | P0~P4 优先级 + 估算费用 + 降本策略 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第4章 SylixOS 调度框架技术架构
|
||||||
|
|
||||||
|
**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
|
||||||
|
| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
|
||||||
|
| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
|
||||||
|
| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
|
||||||
|
| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
|
||||||
|
| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
|
||||||
|
| Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
|
||||||
|
| Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
|
||||||
|
| Tab.6 | 六大优化方向与低功耗专题线概览 | 方向/专题 × (核心问题/关键手段/目标指标/对应章节) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第5章 实验方法学
|
||||||
|
|
||||||
|
**目标**: 800~1000 词，这是 C2 和 C3 的方法论基础，也是本文"可复现"承诺的核心。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
|
||||||
|
| 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
|
||||||
|
| 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
|
||||||
|
| 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
|
||||||
|
| 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
|
||||||
|
| 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
|
||||||
|
| 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
|
||||||
|
| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
|
||||||
|
| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
|
||||||
|
| 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
|
||||||
|
| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Fig.5 | 实验方法论流程图 | `G0~G4` 准入 + `O0~O4` 对照 + 第三方基准对齐校验门 |
|
||||||
|
| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
|
||||||
|
| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
|
||||||
|
| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
|
||||||
|
|
||||||
|
本章设置下面两张“索引表”：
|
||||||
|
|
||||||
|
| 索引表 | 作用 |
|
||||||
|
|------|------|
|
||||||
|
| RQ → 实验 → 章节映射表 | 把 `RQ1~RQ4` 对应到 `E0~E8`、`L0~L7` 与第7/8章，保证每个研究问题都有直接证据链 |
|
||||||
|
| 场景编号 → 结果章节映射表 | 把 `L0~L7` 对应到第7章的小节与图表，保持实验编号与结果章节的直接锚点 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第6章 大模型负载选型与配置
|
||||||
|
|
||||||
|
**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 03-实验设计.md §3.2 |
|
||||||
|
| 6.2 跨档位模型矩阵 | T5-L: Qwen2.5-0.5B INT4；T5-M: 1.5B INT4；T5-H: 3B/7B INT4；T4-L: 3B/7B INT4 (RKLLM)；T4-M: 14B/32B INT4 (TensorRT-LLM)；T3-L: 72B INT4；T2-L: 72B INT4/14B FP16；T2-M: 72B FP16；T2-H: DeepSeek-V2 FP16；T1-L: 72B FP16 分布式；T1-H: 671B INT4 | 02-基础设备与算力基础.md §5.2、03-实验设计.md §3.2 |
|
||||||
|
| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T4-M/T3-L)、llama.cpp (T2-L/T4-L 退路)、RKLLM (T5/T4-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 03-实验设计.md §3.1~§3.3 |
|
||||||
|
| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 03-实验设计.md §3、§6 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
|
||||||
|
| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第7章 实验结果
|
||||||
|
|
||||||
|
**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
|
||||||
|
| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
|
||||||
|
| 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
|
||||||
|
| 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
|
||||||
|
| 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
|
||||||
|
| 7.6 温度-功耗-性能耦合 | 对应 `RQ3`；可与 `L1/L2/L7` 组合，报告 25%→100% CPU 逐步加压的三维耦合曲线，以及 SylixOS vs 普通 Linux / PREEMPT_RT Linux 的降频触发温度与性能下降斜率 | 03-实验设计.md §4、06-能耗与热管理.md |
|
||||||
|
| 7.7 异构核分配 | 对应 `RQ2/RQ3`；主要落在 RK3588 路线与 `L2/L3`，体现 A76 (LLM) + A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 03-实验设计.md §6、03-加速器协同调度.md |
|
||||||
|
| 7.8 跨档位性能曲线 | 对应 `RQ4`；汇总 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线；第7.8节按“已实测结果”与“后续扩展计划”两类展示 | 02-基础设备与算力基础.md §5.3、03-实验设计.md §2 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
|
||||||
|
| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 `W(t)` 曲线，SylixOS vs 普通 Linux / PREEMPT_RT Linux 叠加 |
|
||||||
|
| Fig.7 | 双目标实时保障延迟分布 (★ 核心证据) | 人工智能目标负载与关键保障负载的 P50~Max 直方图 + 时间序列，4 变体叠加 |
|
||||||
|
| Fig.8 | 人工智能目标负载输出时延直方图 | Qwen2.5-7B 单流 1 h 采集，SylixOS vs 普通 Linux / PREEMPT_RT Linux |
|
||||||
|
| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间关键保障负载延迟 spike 与人工智能目标负载队列变化的联合时间序列 |
|
||||||
|
| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
|
||||||
|
| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T5-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
|
||||||
|
| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
|
||||||
|
|
||||||
|
建议在第7章开头直接放入下面两张索引表：
|
||||||
|
|
||||||
|
| 研究问题 | 主要实验单元 | 主要场景编号 | 主要结果章节 | 核心图表 |
|
||||||
|
|------|------|------|------|------|
|
||||||
|
| `RQ1` 双目标约束下的实时保障 | `E1` 微基准、`E3` 混合负载、`E8` 长稳与恢复 | `L0`、`L2`、`L3`、`L4`、`L5`、`L7` | `7.3`、`7.4` | `Fig.7`、`Tab.13` |
|
||||||
|
| `RQ2` 隔离机制的代价与收益 | `E3` 混合负载、`E4` 内存限额、`E7` 消融、`E8` 长稳与恢复 | `L2`、`L3`、`L4`、`L5`、`L6`、`L7` | `7.3`、`7.5`、`7.7` | `Fig.7`、`Fig.9`、`Tab.13` |
|
||||||
|
| `RQ3` 功耗预算下的系统协同能力 | `E2` 推理基线、`E3` 混合负载、`E6` 能耗与热、`E8` 长稳与恢复 | `L1`、`L2`、`L7` | `7.2`、`7.6` | `Fig.6`、`Fig.10`、`Tab.13` |
|
||||||
|
| `RQ4` 规模扩展后的边界与瓶颈 | `E5` 多卡竞争、`X3`/`X4`/`X5` 条件扩展 | `L3`、`L5`、`L6`、`L7` | `7.5`、`7.8` | `Fig.11`、`Tab.14` |
|
||||||
|
|
||||||
|
| 场景编号 | 场景定义 | 论文归属章节 | 主要回答的问题 | 核心图表 |
|
||||||
|
|------|------|------|------|------|
|
||||||
|
| `L0` | 仅关键保障负载 | `7.3` 低延迟结果 | 关键保障负载下界、测量链路开销 | 延迟 CDF、基线表 |
|
||||||
|
| `L1` | 仅人工智能目标负载 | `7.2` 低功耗结果、`7.3` 低延迟结果 | 人工智能目标负载基线时效、能耗与服务能力 | `Fig.6`、`Fig.8` |
|
||||||
|
| `L2` | 关键保障负载 + LLM | `7.4` 双目标实时保障结果 | 双目标是否同时达标，是全文核心主场景 | `Fig.7`、`Tab.13` |
|
||||||
|
| `L3` | `L2` + CPU 竞争负载 | `7.4`、`7.5` | CPU 竞争下的隔离能力与调度边界 | `Fig.7`、竞争负载对照表 |
|
||||||
|
| `L4` | `L2` + 内存流式读写 | `7.4` | 内存带宽与容量压力下的边界变化 | 内存压力时间序列、违约率表 |
|
||||||
|
| `L5` | `L2` + 网络/存储 I/O | `7.4`、`7.5` | IRQ、DMA 与系统服务竞争影响 | `Fig.9`、I/O 干扰对照表 |
|
||||||
|
| `L6` | 关键保障负载 + LLM + YOLO（可选） | `7.5` | 多人工智能目标负载共存时的优先级与公平性 | 多模型公平性图、Jain 指数表 |
|
||||||
|
| `L7` | `L2` + 突发/过载 | `7.4`、`7.5`、`7.6` | 过载、拒绝、恢复与热耦合下的系统稳定性 | `Fig.9`、`Fig.10`、恢复时间表 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第8章 深入分析
|
||||||
|
|
||||||
|
**目标**: 800~1000 词，从数据中提炼规律性结论。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 8.1 档位间性能曲线规律 | 容量、功耗和拓扑变化下 RTOS 优势的变化趋势；分析哪些档位更容易体现差异、哪些档位优势可能收窄 | 02-基础设备与算力基础.md §5.3 |
|
||||||
|
| 8.2 SylixOS vs 普通 Linux / PREEMPT_RT 差异化量化 | 分别评价关键保障负载边界、人工智能目标负载时效和系统协同收益；按档位和场景分别判定 | 03-实验设计.md §9、§10 |
|
||||||
|
| 8.3 双目标场景下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 关键保障负载不被长路径抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 模型加载不引入额外抖动；中断线程化 + 亲和性 → NPU/GPU 中断不污染实时核 | 05-中断与实时性保障.md、02-KV-Cache与内存管理.md |
|
||||||
|
| 8.4 能效分析 | 每 token 能耗 vs 档位；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 `J/token` 对比 | 02-基础设备与算力基础.md §0.3、06-能耗与热管理.md |
|
||||||
|
| 8.5 BSP 风险与可行性 | x86 BSP、ARM64 RK3588 BSP、T234 Jetson BSP、RKLLM 移植等路径的风险等级与降本策略 | 02-基础设备与算力基础.md §7、03-实验设计.md §3 |
|
||||||
|
|
||||||
|
**关键图表**:
|
||||||
|
|
||||||
|
| 编号 | 图表 | 描述 |
|
||||||
|
|------|------|------|
|
||||||
|
| Fig.12 | RTOS 优势 vs 部署档位趋势图 | 横轴=11 档位，纵轴=SylixOS 相对普通 Linux / PREEMPT_RT Linux 的 `P99.9` 与有效吞吐改善百分比，标注"显著优势/可比偏优/未体现"区间 |
|
||||||
|
| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
|
||||||
|
| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第9章 讨论与威胁有效性
|
||||||
|
|
||||||
|
**目标**: 400~600 词，诚实地界定适用边界和局限性。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 | 来源映射 |
|
||||||
|
|------|----------|----------|
|
||||||
|
| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
|
||||||
|
| 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
|
||||||
|
| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
|
||||||
|
| 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 第10章 结论与展望
|
||||||
|
|
||||||
|
**目标**: 300~400 词，总结贡献并指出未来方向。
|
||||||
|
|
||||||
|
| 小节 | 内容要点 |
|
||||||
|
|------|----------|
|
||||||
|
| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果（基准对齐 ±X%、双目标场景下相对 PREEMPT_RT Linux 的边界改善 X%、能效改善 X%） |
|
||||||
|
| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
|
||||||
|
| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-推理图任务调度.md §8 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. 来源文档到章节的映射矩阵
|
||||||
|
|
||||||
|
| 来源文档 | 主要贡献章节 | 次要贡献章节 |
|
||||||
|
|----------|------------|------------|
|
||||||
|
| **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
|
||||||
|
| **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
|
||||||
|
| **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
|
||||||
|
| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
|
||||||
|
| **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
|
||||||
|
| **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
|
||||||
|
| **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
|
||||||
|
| **04-量化精度感知调度.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
|
||||||
|
| **05-中断与实时性保障.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
|
||||||
|
| **06-能耗与热管理.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
|
||||||
|
| **07-方法论与评估工具链.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. 关键数据产物清单
|
||||||
|
|
||||||
|
| 编号 | 产物 | 类型 | 优先级 | 依赖 |
|
||||||
|
|------|------|------|--------|------|
|
||||||
|
| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 02-基础设备与算力基础.md 已就绪 |
|
||||||
|
| D2 | 跨档位模型矩阵 | 数据表 | P0 | 02-基础设备与算力基础.md + 03-实验设计.md 已就绪 |
|
||||||
|
| D3 | RK3588 上 sysbench/stress-ng 基准复现数据 | 实测数据 | P0 | 需 SylixOS BSP + sysbench 移植 |
|
||||||
|
| D4 | 业界基准对比表 (SylixOS vs 文章基线) | 对比表 | P0 | D3 |
|
||||||
|
| D5 | 混合负载 30 min 全周期延迟时间序列 | 实测数据 | P0 | 需混合负载驱动脚本 + 4 变体 |
|
||||||
|
| D6 | 混合负载延迟分布直方图 (4 变体叠加) | 图表 | P0 | D5 |
|
||||||
|
| D7 | 功耗分阶段曲线 (prefill/decode/idle) | 图表 | P0 | 功率计采集 + LLM 推理 |
|
||||||
|
| D8 | LLM token 延迟直方图 (1 h 采集) | 图表 | P1 | vLLM/RKLLM benchmark |
|
||||||
|
| D9 | 突发加载瞬间实时任务时间序列 | 图表 | P1 | 混合负载脚本 + 模型切换 |
|
||||||
|
| D10 | 温度-功耗-性能三维耦合曲线 | 图表 | P1 | stress-ng 逐步加压 + 温度日志 |
|
||||||
|
| D11 | 跨档位性能连续曲线 | 图表 | P1 | 已完成档位实测 + 后续档位条件补充；未完成档位不写成正式结果 |
|
||||||
|
| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
|
||||||
|
| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 03-实验设计.md §11 模板 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. 写作优先级与依赖关系
|
||||||
|
|
||||||
|
```
|
||||||
|
Phase 0: BSP 适配 + 工具移植 (3 周)
|
||||||
|
├─ SylixOS RK3588 BSP 部署
|
||||||
|
├─ sysbench / stress-ng / RKLLM 移植验证
|
||||||
|
└─ vLLM / llama.cpp 在 SylixOS 编译运行
|
||||||
|
|
||||||
|
Phase 1: 基准复现 + 文章骨架 (1.5 周)
|
||||||
|
├─ D3: RK3588 基准复现 → D4: 业界对比表
|
||||||
|
├─ 撰写: §1 引言 + §2 背景 + §3 验证矩阵 + §4 技术架构 + §5 方法学 + §6 模型选型
|
||||||
|
└─ 依赖: D3 通过 ±15% 对齐门 → 准入 Phase 2
|
||||||
|
|
||||||
|
Phase 2: 低功耗测试 + 温度耦合 (2 周)
|
||||||
|
├─ D7: 功耗曲线 + D10: 温度耦合曲线
|
||||||
|
└─ 撰写: §7.2 + §7.6
|
||||||
|
|
||||||
|
Phase 3: 低延迟 + 混合负载测试 (3 周)
|
||||||
|
├─ D5+D6: 混合负载核心证据 + D8: token 延迟直方图 + D9: 突发场景
|
||||||
|
└─ 撰写: §7.3 + §7.4 + §7.5
|
||||||
|
|
||||||
|
Phase 4: 异构调度测试 (1 周)
|
||||||
|
├─ 场景6: A76+A55+M0 异构分配
|
||||||
|
└─ 撰写: §7.7
|
||||||
|
|
||||||
|
Phase 5: 数据汇总 + 深入分析 + 全文定稿 (2.5 周)
|
||||||
|
├─ D11: 跨档位曲线 + D12: 优越性矩阵
|
||||||
|
├─ 撰写: §7.8 + §8 深入分析 + §9 讨论 + §10 结论
|
||||||
|
└─ 全文校对 + 图表终版
|
||||||
|
```
|
||||||
|
|
||||||
|
**总周期: ~13 周** (Phase 0~5 累计)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. 章节字数预算
|
||||||
|
|
||||||
|
| 章节 | 预算字数 | 占比 |
|
||||||
|
|------|---------|------|
|
||||||
|
| §1 引言 | 400 | 4% |
|
||||||
|
| §2 背景与相关工作 | 700 | 7% |
|
||||||
|
| §3 T5~T1 五类部署形态验证矩阵 | 900 | 9% |
|
||||||
|
| §4 技术架构 | 700 | 7% |
|
||||||
|
| §5 实验方法学 | 900 | 9% |
|
||||||
|
| §6 模型选型 | 600 | 6% |
|
||||||
|
| §7 实验结果 | 1800 | 18% |
|
||||||
|
| §8 深入分析 | 900 | 9% |
|
||||||
|
| §9 讨论 | 500 | 5% |
|
||||||
|
| §10 结论 | 350 | 3% |
|
||||||
|
| 参考文献 + 附录 | ~2000 | 23% |
|
||||||
|
| **总计** | **~9750** | 100% |
|
||||||
|
|
||||||
|
> 注: 按 RTSS/RTAS 会议论文 10~12 页双栏计算, 正文约 8000~10000 词, 参考文献+附录另计。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. 核心叙事线 (Storyline)
|
||||||
|
|
||||||
|
```
|
||||||
|
问题矛盾 (§1)
|
||||||
|
→ 人工智能目标负载时效/有效性 vs 关键保障负载严格截止期, 在任务关键系统中必须共存
|
||||||
|
→ 空白: 国产 RTOS 在任务关键系统中承载人工智能目标负载的系统化数据仍然稀缺
|
||||||
|
|
||||||
|
背景铺垫 (§2)
|
||||||
|
→ 人工智能目标负载的 CPU/内存/长尾特征
|
||||||
|
→ RTOS 的 6 项调度优势 + 普通 Linux / PREEMPT_RT 的边界
|
||||||
|
→ 第三方方法学引入 (5 维度 + 5 避坑)
|
||||||
|
|
||||||
|
验证矩阵 (§3) ← C2 验证框架
|
||||||
|
→ 11 档位连续展开: 1 GB/3 W → 2 TB/25 kW
|
||||||
|
→ 现有 P0 零成本起步 (V100 + RK3588)
|
||||||
|
→ 一机两档降本
|
||||||
|
|
||||||
|
技术架构 (§4)
|
||||||
|
→ 五层技术栈 + 六大优化方向
|
||||||
|
→ LLM 推理 DAG → RTOS 任务映射
|
||||||
|
→ BSP 适配要点与风险
|
||||||
|
|
||||||
|
方法学 (§5) ← C1/C3 基础
|
||||||
|
→ 第三方基准复现 (先对齐 ±15% 才准入)
|
||||||
|
→ 双目标负载四原则 (核心设计)
|
||||||
|
→ 功耗真测 + 温度监控 + 元数据强制
|
||||||
|
|
||||||
|
模型选型 (§6)
|
||||||
|
→ 跨 11 档位的 Qwen/LLaMA/MiniCPM/Whisper 矩阵
|
||||||
|
→ INT4/INT8/FP16 量化梯度
|
||||||
|
|
||||||
|
实验结果 (§7) ← 本文核心
|
||||||
|
→ 7.1 基准对齐 (第一层门)
|
||||||
|
→ 7.2~7.3 功耗/延迟 (基础指标)
|
||||||
|
→ 7.4 双目标实时保障 (★ 核心证据)
|
||||||
|
→ 7.5~7.7 并发/突发/异构
|
||||||
|
→ 7.8 跨档位连续曲线
|
||||||
|
|
||||||
|
深入分析 (§8)
|
||||||
|
→ 档位间趋势: 哪些资源条件与拓扑更容易体现 RTOS 优势
|
||||||
|
→ 优越性量化: 关键保障负载边界、人工智能目标负载时效与有效吞吐的联合改进
|
||||||
|
→ 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
|
||||||
|
→ 能效: V100 基线 vs H100 上限, INT4 拐点
|
||||||
|
|
||||||
|
讨论 (§9)
|
||||||
|
→ 适用边界: T5/T4 更容易体现优势, T1-H 可能收窄
|
||||||
|
→ 威胁有效性: RKLLM 移植/V100 驱动/sysbench 移植
|
||||||
|
→ 与已有工作: vs vLLM/NPU SDK/CUDA Stream/第三方文章
|
||||||
|
|
||||||
|
结论 (§10)
|
||||||
|
→ 三大贡献量化回顾
|
||||||
|
→ 跨平台/功能安全/分布式/自适应展望
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. 待确认事项
|
||||||
|
|
||||||
|
| 编号 | 待确认项 | 影响章节 | 当前假设 |
|
||||||
|
|------|---------|---------|---------|
|
||||||
|
| Q1 | SylixOS 在 x86+4×V100 NVLink 的 CUDA 驱动支持度 | §4.5, §7.3, §8.5 | 需翼辉确认; 单卡先行, 4 卡作 stretch |
|
||||||
|
| Q2 | RK3588 BSP 是否集成 rknn/RKLLM | §5.2, §7.1, §9.2 | 需翼辉确认; 退路 llama.cpp CPU |
|
||||||
|
| Q3 | sysbench/stress-ng 在 SylixOS 可移植性 | §5.2, §7.1 | POSIX 兼容, 假设可行 |
|
||||||
|
| Q4 | T234 (Jetson Orin) BSP 是否支持 | §3.2 (T4-M / T3-L) | 风险高; T4-L 用 RK3588 起步 |
|
||||||
|
| Q5 | RK3588 板卡是否引出 M0 调试接口 | §7.7 (场景6) | 若未引出, 场景6 需调整 |
|
||||||
|
| Q6 | 是否纳入功能安全 SIL2/IEC 61508 章节 | §10.2 展望 | 暂列为展望, 不入正文 |
|
||||||
|
| Q7 | 是否纳入昇腾 Qwen-7B 作为第二业界参照 | §7.1, §9.4 | 暂列为后续, 非本方案硬件 |
|
||||||
|
| Q8 | 主对照组确认: Ubuntu 22.04+PREEMPT_RT | §5.7 | 与第三方文章配置一致, 可比性最高 |
|
||||||
|
|
||||||
|
---
|
||||||
@@ -0,0 +1,27 @@
|
|||||||
|
# 实验与规划索引
|
||||||
|
|
||||||
|
本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
|
||||||
|
|
||||||
|
## 阅读建议
|
||||||
|
|
||||||
|
1. `01-研究逻辑说明.md`
|
||||||
|
2. `02-基础设备与算力基础.md`
|
||||||
|
3. `03-实验设计.md`
|
||||||
|
4. `metric.md`
|
||||||
|
5. `04-论文写作规划.md`
|
||||||
|
6. `05-论文结构总览.png`
|
||||||
|
|
||||||
|
## 文件说明
|
||||||
|
|
||||||
|
- `01-研究逻辑说明.md`
|
||||||
|
- 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
|
||||||
|
- `02-基础设备与算力基础.md`
|
||||||
|
- T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
|
||||||
|
- `03-实验设计.md`
|
||||||
|
- 准入条件、对照原则、混合负载场景、指标与验收方法
|
||||||
|
- `metric.md`
|
||||||
|
- 三层核心证据指标的统一定义、计算公式、采集要求与报告口径
|
||||||
|
- `04-论文写作规划.md`
|
||||||
|
- 论文结构、章节分工、图表规划和证据映射
|
||||||
|
- `05-论文结构总览.png`
|
||||||
|
- 文章结构与逻辑关系示意图
|
||||||
@@ -0,0 +1,397 @@
|
|||||||
|
# 核心证据指标说明
|
||||||
|
|
||||||
|
## 1. 文档目的
|
||||||
|
|
||||||
|
本文依据 [01-研究逻辑说明.md](./01-研究逻辑说明.md) 第 8 节，对后续实验必须覆盖的三层核心证据指标给出统一定义、计算方法、采集要求和报告口径。
|
||||||
|
|
||||||
|
本指标体系用于回答一个核心问题：
|
||||||
|
|
||||||
|
> **在人工智能目标负载与关键保障负载并存时，RTOS 能否在不牺牲任务质量和系统有效产出的前提下，提高系统的稳定性、可预测性与可保障性；这种提升在什么负载、功耗、温度和部署档位下成立。**
|
||||||
|
|
||||||
|
指标分为三层：
|
||||||
|
|
||||||
|
1. **人工智能目标负载层**：智能任务是否及时、正确、可用地完成；
|
||||||
|
2. **关键保障负载层**：周期控制、联锁和外部闭环是否仍满足实时约束；
|
||||||
|
3. **系统协同层**：双目标并存时，系统是否保持有效、节能、公平、稳定且可恢复。
|
||||||
|
|
||||||
|
任何单一指标都不能独立支撑系统优越性结论。正式结论必须同时给出三层证据，并说明平台、OS、模型、负载、功耗、温度和运行时长等适用边界。
|
||||||
|
|
||||||
|
## 2. 统一测量原则
|
||||||
|
|
||||||
|
### 2.1 时间点与时钟
|
||||||
|
|
||||||
|
人工智能请求至少记录以下时间点：
|
||||||
|
|
||||||
|
| 符号 | 含义 |
|
||||||
|
|---|---|
|
||||||
|
| `a_i` | 请求计划到达时间 |
|
||||||
|
| `s_i` | 请求实际发送时间 |
|
||||||
|
| `u_i` | 服务端接收时间，可取得时记录 |
|
||||||
|
| `g_i` | 首个有效输出到达时间 |
|
||||||
|
| `c_i` | 完整输出到达或任务完成时间 |
|
||||||
|
|
||||||
|
周期关键任务至少记录：
|
||||||
|
|
||||||
|
| 符号 | 含义 |
|
||||||
|
|---|---|
|
||||||
|
| `r_i` | 计划释放时间 |
|
||||||
|
| `q_i` | 进入就绪态时间，可等价取得时使用 |
|
||||||
|
| `b_i` | 实际开始执行时间 |
|
||||||
|
| `f_i` | 完成时间 |
|
||||||
|
| `T` | 任务周期 |
|
||||||
|
| `D` | 相对截止期 |
|
||||||
|
|
||||||
|
同一指标必须在同一时钟域内计算，优先使用单调时钟。跨设备测量需在 `manifest` 中记录同步方法、同步误差和时间戳位置；同步误差不足以支持单向时延时，改报往返时延，不将往返时延简单除以二作为单向结果。
|
||||||
|
|
||||||
|
### 2.2 统计与报告
|
||||||
|
|
||||||
|
- 时延和抖动至少报告样本数、`P50/P95/P99/P99.9` 和观测最大值；样本不足以稳定估计 `P99.9` 时，明确标为探索性结果并改以 `P99` 为主。
|
||||||
|
- 每个普通性能单元至少独立运行 5 次；跨运行报告中位数、区间和置信区间，不只报告最佳一次。
|
||||||
|
- 最大值只能表述为“指定时长和工况下的观测最大值”，不能写成理论 `WCET`。
|
||||||
|
- 零违约只能表述为“在 `N` 次计划释放中未观测到违约”，不能据此证明绝对硬实时安全。
|
||||||
|
- 原始超时、拒绝、OOM、丢样和失败请求必须保留，不能从分母中静默删除。
|
||||||
|
- OS 对照需冻结硬件、模型与量化版本、输入/输出长度、到达序列、随机种子、CPU/IRQ/频率配置、内存预算、加速器数量、散热条件和测量窗口。
|
||||||
|
|
||||||
|
### 2.3 三层联合判定
|
||||||
|
|
||||||
|
正式实验单元只有同时满足下列条件，才能记为“通过”：
|
||||||
|
|
||||||
|
```text
|
||||||
|
人工智能目标负载达标
|
||||||
|
AND 关键保障负载达标
|
||||||
|
AND 系统协同稳定
|
||||||
|
```
|
||||||
|
|
||||||
|
若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。
|
||||||
|
|
||||||
|
## 3. 人工智能目标负载层
|
||||||
|
|
||||||
|
### 3.1 TTFT
|
||||||
|
|
||||||
|
`TTFT`（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间：
|
||||||
|
|
||||||
|
```text
|
||||||
|
TTFT_i = g_i - s_i
|
||||||
|
```
|
||||||
|
|
||||||
|
该指标包含请求传输、排队、调度和 prefill 阶段。负载发生器还应记录发送滞后 `s_i-a_i`，防止发生器本身饱和导致排队时间被遗漏。
|
||||||
|
|
||||||
|
报告要求：
|
||||||
|
|
||||||
|
- 单位统一为 `ms`；
|
||||||
|
- 按模型、输入长度、并发度和到达率分别汇总；
|
||||||
|
- 至少报告 `P50/P95/P99/P99.9/Max`、样本数和超时数；
|
||||||
|
- 流式接口以客户端收到首个**有效内容 token**为终点，不把连接确认、空片段或仅含元数据的事件作为首 token；
|
||||||
|
- 非生成式人工智能任务不使用 `TTFT`，改用任务对应的首结果时间，并明确终点语义。
|
||||||
|
|
||||||
|
### 3.2 TPOT
|
||||||
|
|
||||||
|
`TPOT`（Time Per Output Token）描述首 token 之后的平均生成间隔。对输出 token 数 `n_i > 1` 的请求：
|
||||||
|
|
||||||
|
```text
|
||||||
|
TPOT_i = (c_i - g_i) / (n_i - 1)
|
||||||
|
```
|
||||||
|
|
||||||
|
报告要求：
|
||||||
|
|
||||||
|
- 单位统一为 `ms/token`；
|
||||||
|
- `n_i <= 1` 的请求记为不可计算，不以 0 填充；
|
||||||
|
- 请求级 `TPOT` 与逐 token 间隔分布分开报告；
|
||||||
|
- 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善；
|
||||||
|
- 按输入长度、输出长度、并发度和到达率分组。
|
||||||
|
|
||||||
|
### 3.3 端到端响应时间
|
||||||
|
|
||||||
|
端到端响应时间描述从请求实际发出到完整可用结果到达的时间：
|
||||||
|
|
||||||
|
```text
|
||||||
|
T_e2e,i = c_i - s_i
|
||||||
|
```
|
||||||
|
|
||||||
|
对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。
|
||||||
|
|
||||||
|
除分位数外，还需按业务完成期限 `D_ai` 报告按时完成率：
|
||||||
|
|
||||||
|
```text
|
||||||
|
on_time_completion_ratio
|
||||||
|
= count(success_i AND T_e2e,i <= D_ai) / planned_requests
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.4 成功率、任务质量与输出可用性
|
||||||
|
|
||||||
|
三个概念必须分开计算：
|
||||||
|
|
||||||
|
| 指标 | 定义 | 典型失败 |
|
||||||
|
|---|---|---|
|
||||||
|
| 请求成功率 | 协议和运行时层面正常完成的请求数 / 计划请求数 | 超时、拒绝、崩溃、OOM、传输失败 |
|
||||||
|
| 任务质量 | 输出与冻结的参考答案或数据集指标之间的符合程度 | 精度下降、错误分类、内容偏差 |
|
||||||
|
| 输出可用率 | 同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数 | 空输出、截断、格式错误、不可解析或不满足质量门槛 |
|
||||||
|
|
||||||
|
计算式：
|
||||||
|
|
||||||
|
```text
|
||||||
|
success_ratio = successful_requests / planned_requests
|
||||||
|
usable_output_ratio = usable_outputs / planned_requests
|
||||||
|
```
|
||||||
|
|
||||||
|
任务质量应按负载类型选择并预先冻结：
|
||||||
|
|
||||||
|
- LLM：固定题集得分、精确匹配、规则判分或人工盲评结果；
|
||||||
|
- 视觉检测：`mAP`、召回率、误检率；
|
||||||
|
- 分类：准确率、F1 等；
|
||||||
|
- 语音识别：`WER/CER`；
|
||||||
|
- 故障诊断：检出率、漏报率、误报率。
|
||||||
|
|
||||||
|
量化或调度优化必须同时报告质量变化。仅提高速度但跌破质量门槛的输出不得计入有效结果。
|
||||||
|
|
||||||
|
### 3.5 长时间运行稳定性
|
||||||
|
|
||||||
|
人工智能负载稳定性用于检查持续运行时的性能和正确性是否退化。至少观测：
|
||||||
|
|
||||||
|
- 每个时间块的 `TTFT/TPOT/T_e2e` 分位数；
|
||||||
|
- 请求成功率、输出可用率和错误类型；
|
||||||
|
- 吞吐、队列长度、内存和 KV Cache 占用；
|
||||||
|
- 温度、实际频率、进程重启和驱动异常。
|
||||||
|
|
||||||
|
建议将 24 h 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率：
|
||||||
|
|
||||||
|
```text
|
||||||
|
latency_drift = (late_block_metric - early_block_metric)
|
||||||
|
/ early_block_metric
|
||||||
|
```
|
||||||
|
|
||||||
|
报告时需给出完整时间序列，不能仅给 24 h 总平均值。持续内存增长、尾延迟恶化、成功率下降或周期性驱动错误均应作为稳定性退化证据。
|
||||||
|
|
||||||
|
## 4. 关键保障负载层
|
||||||
|
|
||||||
|
### 4.1 Deadline miss ratio
|
||||||
|
|
||||||
|
对第 `i` 次计划释放，若 `f_i > r_i + D`，则发生截止期违约：
|
||||||
|
|
||||||
|
```text
|
||||||
|
miss_i = 1, if f_i > r_i + D; otherwise 0
|
||||||
|
deadline_miss_ratio = sum(miss_i) / planned_releases
|
||||||
|
```
|
||||||
|
|
||||||
|
要求：
|
||||||
|
|
||||||
|
- 分母必须是计划释放次数，而不是实际完成次数；
|
||||||
|
- 未释放、跳过、丢失或未完成的实例必须单独标记，不能直接从分母删除；
|
||||||
|
- 同时报告违约数、计划释放数、连续违约长度和违约发生时间；
|
||||||
|
- 按场景、负载强度和 OS 配置分别统计。
|
||||||
|
|
||||||
|
### 4.2 P99/P99.9 jitter
|
||||||
|
|
||||||
|
本文默认以完成间隔抖动作为关键保障负载的主抖动口径：
|
||||||
|
|
||||||
|
```text
|
||||||
|
jitter_i = (f_i - f_(i-1)) - T
|
||||||
|
```
|
||||||
|
|
||||||
|
同时可报告绝对抖动 `abs(jitter_i)`。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。
|
||||||
|
|
||||||
|
报告要求：
|
||||||
|
|
||||||
|
- 有符号抖动报告上下尾，绝对抖动报告 `P99/P99.9/Max`；
|
||||||
|
- 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件；
|
||||||
|
- 给出样本量及采样周期；
|
||||||
|
- 不使用均值或标准差替代尾部分位数。
|
||||||
|
|
||||||
|
### 4.3 观测最大响应时间
|
||||||
|
|
||||||
|
关键任务响应时间定义为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
R_i = f_i - r_i
|
||||||
|
R_observed_max = max(R_i)
|
||||||
|
```
|
||||||
|
|
||||||
|
观测最大响应时间需要与截止期 `D` 并列展示，并给出裕量：
|
||||||
|
|
||||||
|
```text
|
||||||
|
deadline_margin = D - R_observed_max
|
||||||
|
```
|
||||||
|
|
||||||
|
`deadline_margin < 0` 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。
|
||||||
|
|
||||||
|
### 4.4 外部接口响应时间
|
||||||
|
|
||||||
|
外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路：
|
||||||
|
|
||||||
|
```text
|
||||||
|
T_external = t_external_output - t_external_input
|
||||||
|
```
|
||||||
|
|
||||||
|
采集要求：
|
||||||
|
|
||||||
|
- 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳；
|
||||||
|
- 固定波特率、帧长、总线负载、网络拓扑和时间戳位置；
|
||||||
|
- 报告空回路基线、测量分辨率和仪器误差；
|
||||||
|
- 报告 `P50/P99/P99.9/Max`、超时和丢帧；
|
||||||
|
- 内核或应用日志仅作为归因证据，不能替代外部闭环测量。
|
||||||
|
|
||||||
|
## 5. 系统协同层
|
||||||
|
|
||||||
|
### 5.1 有效吞吐
|
||||||
|
|
||||||
|
有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出：
|
||||||
|
|
||||||
|
```text
|
||||||
|
effective_throughput
|
||||||
|
= qualified_output_units / measurement_window
|
||||||
|
```
|
||||||
|
|
||||||
|
对 LLM，`qualified_output_units` 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。
|
||||||
|
|
||||||
|
合格请求至少满足：
|
||||||
|
|
||||||
|
```text
|
||||||
|
请求成功
|
||||||
|
AND TTFT/端到端期限达标
|
||||||
|
AND 任务质量达标
|
||||||
|
AND 输出可用
|
||||||
|
AND 同一窗口内关键保障负载达标
|
||||||
|
```
|
||||||
|
|
||||||
|
有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。
|
||||||
|
|
||||||
|
### 5.2 E/token
|
||||||
|
|
||||||
|
在与负载统计完全一致的窗口 `[t0,t1]` 内：
|
||||||
|
|
||||||
|
```text
|
||||||
|
E_total = integral(P(t), t0, t1)
|
||||||
|
E/token = E_total / N_output
|
||||||
|
tokens/J = N_output / E_total
|
||||||
|
```
|
||||||
|
|
||||||
|
其中 `N_output` 为窗口内实际收到的输出 token 数。主结果使用整机输入端实测能耗，包含排队、空闲和失败请求消耗；板载或加速器遥测用于归因，不能替代整机测量。
|
||||||
|
|
||||||
|
要求：
|
||||||
|
|
||||||
|
- 单位为 `J/token`，同时报告平均功率、峰值采样功率和仪器采样率；
|
||||||
|
- `N_output = 0` 时记为不可计算，不记为 0；
|
||||||
|
- 同时报有效 `E/token = E_total / N_qualified_output`，以反映失败和不合格输出的成本；
|
||||||
|
- 混合视觉与 LLM 负载时，不将全部能耗归因于 LLM，应使用独立对照或单列场景总能耗；
|
||||||
|
- 只在人工智能与关键保障约束均满足的配置之间比较能效。
|
||||||
|
|
||||||
|
### 5.3 温度、降频与热漂移
|
||||||
|
|
||||||
|
全程同步记录：
|
||||||
|
|
||||||
|
- 环境温度、芯片/板卡温度；
|
||||||
|
- CPU、GPU、NPU 和内存相关实际频率；
|
||||||
|
- 降频事件及其原因；
|
||||||
|
- 功率、风扇/散热策略；
|
||||||
|
- 同时间轴上的时延、吞吐和违约。
|
||||||
|
|
||||||
|
降频时间比例定义为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
throttling_ratio = throttled_time / valid_measurement_time
|
||||||
|
```
|
||||||
|
|
||||||
|
热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化：
|
||||||
|
|
||||||
|
```text
|
||||||
|
thermal_drift(metric)
|
||||||
|
= (hot_steady_metric - early_steady_metric) / early_steady_metric
|
||||||
|
```
|
||||||
|
|
||||||
|
时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。
|
||||||
|
|
||||||
|
### 5.4 多任务公平性
|
||||||
|
|
||||||
|
多租户或多模型并发场景使用各任务相对独占性能 `x_i` 计算 Jain 公平指数：
|
||||||
|
|
||||||
|
```text
|
||||||
|
J = (sum(x_i))^2 / (k * sum(x_i^2))
|
||||||
|
```
|
||||||
|
|
||||||
|
其中 `k` 为任务数，`x_i` 可取“共享运行时的有效吞吐 / 独占运行时的有效吞吐”。`J` 越接近 1，吞吐分配越均衡。
|
||||||
|
|
||||||
|
公平性不能只用一个指数概括，还应报告：
|
||||||
|
|
||||||
|
- 每个任务或租户的有效吞吐、`TTFT`、端到端时延和成功率；
|
||||||
|
- 关键任务是否满足各自服务等级；
|
||||||
|
- 饥饿次数、最长无服务时间和优先级倒置事件；
|
||||||
|
- 高优先级保障所造成的低优先级代价。
|
||||||
|
|
||||||
|
对具有不同优先级和服务等级的任务，“公平”不是平均分配资源，而是在满足保障等级后不存在非预期饥饿。因此 Jain 指数只作为补充证据，不能替代逐任务 SLA 结果。
|
||||||
|
|
||||||
|
### 5.5 恢复能力
|
||||||
|
|
||||||
|
恢复测试应预先定义故障注入时刻 `t_fault` 和恢复判据。至少覆盖推理进程重启和队列过载；驱动重置、设备掉线或网络故障仅在存在安全、可恢复路径时执行。
|
||||||
|
|
||||||
|
建议记录：
|
||||||
|
|
||||||
|
| 指标 | 定义 |
|
||||||
|
|---|---|
|
||||||
|
| 故障检测时间 | 检测到故障的时刻减 `t_fault` |
|
||||||
|
| 服务恢复时间 | 恢复到预定成功率和有效吞吐稳定区间的时刻减 `t_fault` |
|
||||||
|
| 数据损失 | 故障窗口内丢失、重复或无法确认的请求数 |
|
||||||
|
| 实时影响 | 故障窗口内关键任务违约数及最大响应时间 |
|
||||||
|
| 重试成功率 | 成功重试请求数 / 发起重试请求数 |
|
||||||
|
| 不可恢复故障数 | 需要人工干预、重启系统或丢失测量链路的次数 |
|
||||||
|
|
||||||
|
恢复完成必须同时满足人工智能服务恢复和关键保障负载重新达标。仅进程重新启动但吞吐、队列或实时任务仍未恢复，不算恢复完成。
|
||||||
|
|
||||||
|
### 5.6 24 h 长稳表现
|
||||||
|
|
||||||
|
24 h 长稳采用人工智能目标负载、关键保障负载及必要伴生竞争负载的混合场景。至少连续记录：
|
||||||
|
|
||||||
|
- 三层核心指标的固定时间块汇总；
|
||||||
|
- 温度、频率、功率和降频事件；
|
||||||
|
- 内存、KV Cache、句柄/线程和队列长度；
|
||||||
|
- OOM、驱动错误、进程重启、接口超时和日志中断；
|
||||||
|
- 注入故障前后恢复曲线。
|
||||||
|
|
||||||
|
长稳通过条件至少包括：
|
||||||
|
|
||||||
|
1. 完成连续 24 h 有效测量；
|
||||||
|
2. 无不可恢复故障；
|
||||||
|
3. 测量与日志链路无中断；
|
||||||
|
4. 无持续、不可解释的内存增长；
|
||||||
|
5. 人工智能输出与关键保障负载在冻结阈值内；
|
||||||
|
6. 故障注入后在冻结时间内恢复。
|
||||||
|
|
||||||
|
若发生故障，必须保留原始数据并分析，不得删除故障批次后宣称长稳通过。
|
||||||
|
|
||||||
|
## 6. 指标—数据源—实验映射
|
||||||
|
|
||||||
|
| 层级 | 指标 | 主要数据源 | 主要实验/场景 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 人工智能目标负载 | `TTFT/TPOT`、端到端响应时间 | `requests.csv`、负载发生器、推理日志 | E2/E3/E8，L1～L7 |
|
||||||
|
| 人工智能目标负载 | 成功率、质量、输出可用率 | 请求日志、固定题集/数据集、判分程序 | E2/E3/E4/E8 |
|
||||||
|
| 人工智能目标负载 | 长时间稳定性 | 分块请求汇总、内存和错误日志 | E8，24 h |
|
||||||
|
| 关键保障负载 | 违约率、抖动、最大响应时间 | `rt.csv`、RTOS trace、GPIO 打点 | E1/E3/E7/E8，L0/L2～L7 |
|
||||||
|
| 关键保障负载 | 外部接口响应时间 | 示波器、逻辑/总线分析仪、抓包 | E1/E3/E8 |
|
||||||
|
| 系统协同 | 有效吞吐 | 请求、质量和 RT 数据联合计算 | E3/E5/E7/E8 |
|
||||||
|
| 系统协同 | `E/token` | 外部功率计/PDU、`requests.csv` | E2/E6/E8 |
|
||||||
|
| 系统协同 | 温度、降频、热漂移 | `thermal.csv`、频率与功率日志 | E6/E8 |
|
||||||
|
| 系统协同 | 多任务公平性 | 各租户请求日志和独占基线 | E5，L6 |
|
||||||
|
| 系统协同 | 恢复与 24 h 长稳 | `events.log`、三层时间序列 | E8，L7 |
|
||||||
|
|
||||||
|
## 7. 最小数据产物
|
||||||
|
|
||||||
|
每次运行至少保存：
|
||||||
|
|
||||||
|
| 文件 | 必需内容 |
|
||||||
|
|---|---|
|
||||||
|
| `manifest.json` | 平台/档位、OS/BSP/驱动、模型校验值、量化、输入、到达序列、CPU/IRQ/频率/内存配置、环境和仪器信息 |
|
||||||
|
| `requests.csv` | 请求 ID、计划到达、实际发送、首/末输出、输出数、成功、质量、可用性、超时/拒绝原因 |
|
||||||
|
| `rt.csv` | 计划释放、就绪、开始、完成、CPU、违约、丢失/跳过状态 |
|
||||||
|
| `power.csv` | 时间戳、功率、电压、电流、仪器来源 |
|
||||||
|
| `thermal.csv` | 时间戳、环境/芯片温度、实际频率、降频状态 |
|
||||||
|
| `events.log` | OOM、驱动错误、故障注入、重启、网络异常、测量故障 |
|
||||||
|
| `summary.json` | 三层指标、样本量、分位数、最大值、区间、阈值和判定结果 |
|
||||||
|
|
||||||
|
所有派生指标必须能够从原始记录重新计算。汇总程序不得覆盖原始文件，不得静默剔除异常值。
|
||||||
|
|
||||||
|
## 8. 核心证据表述模板
|
||||||
|
|
||||||
|
正式报告应采用带边界的联合表述：
|
||||||
|
|
||||||
|
> 在 `[平台/档位]`、`[模型与输入输出配置]`、`[到达率与竞争负载]`、`[功耗和温度条件]` 下，`[OS/配置]` 在人工智能目标负载达到 `[TTFT/TPOT/质量/可用率]`、关键保障负载达到 `[违约率/P99.9/观测最大响应]` 的同时，实现 `[有效吞吐和 E/token]`，并在 `[故障与 24 h 长稳结果]` 下保持稳定。相对 `[对照组]` 的改善为 `[效应量及置信区间]`。
|
||||||
|
|
||||||
|
不应只写“平均时延更低”“吞吐更高”或“24 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
# 联合研究方索引
|
||||||
|
|
||||||
|
本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
|
||||||
|
|
||||||
|
## 当前内容
|
||||||
|
|
||||||
|
- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
|
||||||
|
- 面向项目内部的合作设想文档
|
||||||
|
- 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
|
||||||
|
- `罗蕾教授资料/`
|
||||||
|
- 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
|
||||||
|
- 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
|
||||||
|
- `翼辉信息资料/`
|
||||||
|
- 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
|
||||||
|
- 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
|
||||||
|
|
||||||
|
## 使用建议
|
||||||
|
|
||||||
|
- 对外沟通时，可先阅读人物概览与科研路径两篇。
|
||||||
|
- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
|
||||||
|
- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。
|
||||||
@@ -0,0 +1,210 @@
|
|||||||
|
# 潜在合作研究路径：罗蕾教授与翼辉信息
|
||||||
|
|
||||||
|
> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
|
||||||
|
|
||||||
|
## 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 联合论文 / 白皮书 / 申报材料
|
||||||
|
|
||||||
|
目标：
|
||||||
|
|
||||||
|
- 学术上形成论文；
|
||||||
|
- 产业上形成白皮书或联合研究说明；
|
||||||
|
- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
|
||||||
|
|
||||||
|
更适合的分工：
|
||||||
|
|
||||||
|
- 罗蕾教授侧偏学术与规范表达；
|
||||||
|
- 翼辉信息侧偏产业价值、案例与平台能力；
|
||||||
|
- 项目组承担材料汇总、写作配合与整合支撑。
|
||||||
|
|
||||||
|
### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
|
||||||
|
|
||||||
|
目标：
|
||||||
|
|
||||||
|
- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
|
||||||
|
- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
|
||||||
|
- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
|
||||||
|
|
||||||
|
更适合的分工：
|
||||||
|
|
||||||
|
- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
|
||||||
|
- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
|
||||||
|
- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
|
||||||
|
|
||||||
|
这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
|
||||||
|
|
||||||
|
## 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.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -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-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。
|
||||||
@@ -0,0 +1,67 @@
|
|||||||
|
# 研究问题、定位与边界
|
||||||
|
|
||||||
|
## 1. 工业背景
|
||||||
|
|
||||||
|
机器人同时包含两类时间尺度显著不同的任务：
|
||||||
|
|
||||||
|
- 感知、语言理解、任务规划和大模型推理计算量大、运行时间动态，通常属于软实时或固实时；
|
||||||
|
- 姿态稳定、关节控制、力控、现场总线和安全联锁按固定周期运行，通常属于硬实时或严格固实时。
|
||||||
|
|
||||||
|
把两类任务简单部署在同一 Linux 系统中，会产生调度、中断、内存带宽、DMA、功耗和故障传播问题；把完整 AI 软件栈迁入 RTOS，又会面临驱动、运行时、模型生态和不可控加速器执行路径问题。
|
||||||
|
|
||||||
|
## 2. 研究对象
|
||||||
|
|
||||||
|
本项目研究的是机器人大小脑异构系统，而不是单独研究 RTOS 或大模型：
|
||||||
|
|
||||||
|
| 子系统 | 工程角色 | 主要软件 |
|
||||||
|
|---|---|---|
|
||||||
|
| 大脑域 | 环境理解、模型推理、任务规划、技能选择 | Linux、ROS 2、LLM/VLM/VLA、GPU/NPU 运行时 |
|
||||||
|
| 技能与安全接口 | 命令结构化、白名单技能、期限和约束检查 | 跨域协议、安全监控器、行为管理器 |
|
||||||
|
| 小脑域 | 状态估计、轨迹跟踪、关节控制、联锁和降级 | RTOS、控制算法、关键设备驱动 |
|
||||||
|
| 隔离层 | CPU、内存、设备、中断和故障域分区 | Hypervisor、AMP、IOMMU 或静态硬件分区 |
|
||||||
|
|
||||||
|
## 3. 核心研究问题
|
||||||
|
|
||||||
|
> 在机器人大小脑异构平台中，如何建立跨域时间契约和资源隔离机制，使动态、不可完全预测的大脑负载不会破坏小脑控制的实时边界，并使大脑输出能够被安全、按期地使用？
|
||||||
|
|
||||||
|
分解为五个问题：
|
||||||
|
|
||||||
|
1. 大脑负载通过哪些 CPU、缓存、内存、I/O、中断、DMA 和热路径干扰小脑控制？
|
||||||
|
2. 静态分核与 Hypervisor 分域能够隔离哪些干扰，仍有哪些共享硬件干扰无法消除？
|
||||||
|
3. 大小脑之间应采用什么时间契约、消息语义和队列策略？
|
||||||
|
4. 大脑输出迟到、过期、错误或低置信度时，小脑如何在规定时间内回退？
|
||||||
|
5. 大脑域、加速器或通信通道故障时，机器人能否持续受控并完成隔离和恢复？
|
||||||
|
|
||||||
|
## 4. 研究边界
|
||||||
|
|
||||||
|
### 纳入范围
|
||||||
|
|
||||||
|
- 机器人本体或近端边缘计算平台；
|
||||||
|
- RTOS 小脑与 Linux 大脑并行运行；
|
||||||
|
- 控制任务 deadline、AI 结果期限和新鲜度；
|
||||||
|
- 跨域通信、共享资源干扰、故障隔离和安全降级；
|
||||||
|
- 大模型、视觉或规划作为大脑压力负载。
|
||||||
|
|
||||||
|
### 不作为主线
|
||||||
|
|
||||||
|
- 大模型训练；
|
||||||
|
- T1 多节点集群吞吐优化；
|
||||||
|
- 证明大模型本身具备硬实时性；
|
||||||
|
- 用平均推理时延替代机器人控制实时性；
|
||||||
|
- 让自然语言输出直接控制电机力矩。
|
||||||
|
|
||||||
|
## 5. 基本原则
|
||||||
|
|
||||||
|
1. 小脑不依赖大脑即可维持基本稳定和安全状态。
|
||||||
|
2. 大脑输出的是目标、技能或受约束轨迹，不直接绕过控制器驱动执行器。
|
||||||
|
3. 小脑不得同步阻塞等待大脑推理完成。
|
||||||
|
4. 所有大脑输出必须携带时间戳、序号、有效期、状态和必要的安全约束。
|
||||||
|
5. Hypervisor 只是一种隔离手段，隔离效果必须通过压力和故障实验验证。
|
||||||
|
|
||||||
|
## 6. 预期贡献
|
||||||
|
|
||||||
|
- 一套面向大小脑系统的多时间尺度任务模型；
|
||||||
|
- 一套有期限、有新鲜度、有回退语义的跨域通信契约；
|
||||||
|
- 一套 RTOS/Linux/Hypervisor 资源和故障隔离机制；
|
||||||
|
- 一套覆盖正常、过载、热稳态和故障状态的实验方法；
|
||||||
|
- 大脑智能能力、控制实时性和资源代价之间的适用边界。
|
||||||
@@ -0,0 +1,90 @@
|
|||||||
|
# 整体研究框架
|
||||||
|
|
||||||
|
## 1. 系统架构
|
||||||
|
|
||||||
|
```text
|
||||||
|
操作员/任务系统
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌────────────────────────────────────────────┐
|
||||||
|
│ Linux 大脑域 │
|
||||||
|
│ 感知、LLM/VLM/VLA、任务规划、技能选择 │
|
||||||
|
│ GPU/NPU、ROS 2、模型运行时 │
|
||||||
|
└──────────────────┬─────────────────────────┘
|
||||||
|
│ 有界异步命令
|
||||||
|
│ 序号/时间戳/期限/有效期
|
||||||
|
┌──────────────────▼─────────────────────────┐
|
||||||
|
│ RTOS 小脑域 │
|
||||||
|
│ 安全校验、状态估计、轨迹跟踪、关节控制 │
|
||||||
|
│ 现场总线、联锁、超时回退、安全状态 │
|
||||||
|
└──────────────────┬─────────────────────────┘
|
||||||
|
│ 周期控制量
|
||||||
|
▼
|
||||||
|
执行器与机器人本体
|
||||||
|
|
||||||
|
Hypervisor / AMP / IOMMU / 静态资源分区
|
||||||
|
```
|
||||||
|
|
||||||
|
传感数据按需求分别进入大小脑：高频本体反馈优先直达小脑，图像、语音和复杂环境信息主要进入大脑。关键安全传感器不得仅通过 Linux 域转发。
|
||||||
|
|
||||||
|
## 2. 三层时间模型
|
||||||
|
|
||||||
|
| 层次 | 典型任务 | 时间属性 | 主要指标 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| L1 控制闭环 | 关节控制、姿态稳定、联锁 | 硬实时/严格固实时 | deadline、jitter、最大响应时间 |
|
||||||
|
| L2 技能与决策窗口 | 轨迹片段、目标位姿、避障决策 | 固实时 | 按期率、新鲜度、回退率 |
|
||||||
|
| L3 认知与交互 | 语言理解、长任务规划、解释 | 软实时 | TTFT、端到端延迟、任务成功率 |
|
||||||
|
|
||||||
|
基本约束为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
R_control <= D_control
|
||||||
|
|
||||||
|
采用大脑结果时：
|
||||||
|
R_brain <= D_brain AND age(result) <= A_max
|
||||||
|
|
||||||
|
大脑不可用时：
|
||||||
|
R_fallback <= D_fallback
|
||||||
|
```
|
||||||
|
|
||||||
|
## 3. 三条研究主线
|
||||||
|
|
||||||
|
### 主线一：时间契约
|
||||||
|
|
||||||
|
- 规定大脑输出的期限、有效期和更新频率；
|
||||||
|
- 把大脑输出转换为结构化技能或轨迹约束；
|
||||||
|
- 对迟到、乱序、重复和低置信度结果定义统一处理；
|
||||||
|
- 保证小脑在没有新命令时仍能连续控制。
|
||||||
|
|
||||||
|
### 主线二：资源与故障隔离
|
||||||
|
|
||||||
|
- 为小脑保留 CPU 核、内存、定时器和关键 I/O；
|
||||||
|
- 路由关键中断到 RTOS 域；
|
||||||
|
- 限制 Linux 和加速器 DMA 范围；
|
||||||
|
- 测量 LLC、DRAM、互联、功耗和热等残余共享干扰；
|
||||||
|
- 验证一个域崩溃或重启时另一域的持续运行能力。
|
||||||
|
|
||||||
|
### 主线三：联合评价
|
||||||
|
|
||||||
|
不能只报告控制延迟，也不能只报告大模型速度。结论必须联合回答：
|
||||||
|
|
||||||
|
- 小脑控制是否按时；
|
||||||
|
- 大脑结果是否按期且有效；
|
||||||
|
- 分域使用了多少静态资源；
|
||||||
|
- 推理吞吐和能效付出了多少代价；
|
||||||
|
- 故障与恢复期间机器人是否保持受控。
|
||||||
|
|
||||||
|
## 4. 研究假设
|
||||||
|
|
||||||
|
- H1：大脑负载会通过共享资源显著扩大控制尾延迟。
|
||||||
|
- H2：RTOS/Linux 分域能够降低调度、中断和故障传播影响，但不能自动消除内存带宽与热耦合。
|
||||||
|
- H3：有界异步时间契约能够避免小脑等待大脑，并降低过期决策进入执行路径的风险。
|
||||||
|
- H4：准入、限流和故障降级可扩大“控制无违约且 AI 结果仍有用”的运行区域。
|
||||||
|
|
||||||
|
## 5. 研究成果形态
|
||||||
|
|
||||||
|
- 原型系统：RTOS 小脑域、Linux 大脑域与隔离层；
|
||||||
|
- 跨域协议：请求、响应、心跳、超时和版本管理；
|
||||||
|
- 实验工具：时间戳、压力发生、故障注入和物理链路测量；
|
||||||
|
- 数据集：控制周期、大脑请求、功耗热状态和故障事件的对齐时间序列；
|
||||||
|
- 论文结论：适用边界、收益来源和残余风险。
|
||||||
@@ -0,0 +1,80 @@
|
|||||||
|
# 大小脑时间契约与跨域通信
|
||||||
|
|
||||||
|
## 1. 接口原则
|
||||||
|
|
||||||
|
大小脑之间采用异步、有界、可超时和可丢弃的消息通道。小脑控制线程不得执行无限等待、动态扩容或不可控的大块数据复制。
|
||||||
|
|
||||||
|
大脑输出应从开放文本收敛为受约束结构：
|
||||||
|
|
||||||
|
```text
|
||||||
|
任务目标 → 白名单技能 → 参数与约束 → 小脑验证 → 执行
|
||||||
|
```
|
||||||
|
|
||||||
|
## 2. 消息模型
|
||||||
|
|
||||||
|
### 请求
|
||||||
|
|
||||||
|
| 字段 | 含义 |
|
||||||
|
|---|---|
|
||||||
|
| `request_id` | 唯一序号 |
|
||||||
|
| `sample_time` | 输入数据采样时刻 |
|
||||||
|
| `deadline` | 最晚可用时刻 |
|
||||||
|
| `task_class` | 感知、规划、诊断或交互类别 |
|
||||||
|
| `priority` | 域内服务优先级提示 |
|
||||||
|
| `payload_ref` | 受控共享缓冲区引用 |
|
||||||
|
| `schema_version` | 接口版本 |
|
||||||
|
|
||||||
|
### 响应
|
||||||
|
|
||||||
|
| 字段 | 含义 |
|
||||||
|
|---|---|
|
||||||
|
| `request_id` | 请求匹配 |
|
||||||
|
| `finish_time` | 推理完成时刻 |
|
||||||
|
| `valid_until` | 结果失效时刻 |
|
||||||
|
| `model_version` | 模型版本和审计信息 |
|
||||||
|
| `confidence/status` | 结果质量与错误状态 |
|
||||||
|
| `skill_id` | 白名单技能编号 |
|
||||||
|
| `constraints` | 速度、力、空间和持续时间约束 |
|
||||||
|
| `checksum` | 完整性校验 |
|
||||||
|
|
||||||
|
## 3. 小脑消费条件
|
||||||
|
|
||||||
|
```text
|
||||||
|
accept(result) =
|
||||||
|
id_match
|
||||||
|
AND schema_valid
|
||||||
|
AND checksum_valid
|
||||||
|
AND finish_time <= deadline
|
||||||
|
AND now <= valid_until
|
||||||
|
AND confidence >= threshold
|
||||||
|
AND skill_is_whitelisted
|
||||||
|
AND constraints_passed
|
||||||
|
```
|
||||||
|
|
||||||
|
拒绝结果后，小脑执行保持、传统控制、减速、停车或其他预定义回退，不等待大脑重新计算。
|
||||||
|
|
||||||
|
## 4. 通信实现候选
|
||||||
|
|
||||||
|
| 方式 | 优点 | 风险 | 适用场景 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 共享内存环形队列 + 通知 | 低复制、可控队列 | 缓存一致性和内存访问权限 | 同 SoC 分域主方案 |
|
||||||
|
| RPMsg/邮箱 | SoC 生态常见、域间明确 | 消息大小和驱动能力受限 | MCU + 应用核 |
|
||||||
|
| 虚拟设备 | 与 Hypervisor 集成 | VM exit 和虚拟中断开销 | 虚拟机分区 |
|
||||||
|
| 以太网/TSN | 物理隔离、易扩展 | 网络栈与同步误差 | 双机大小脑 |
|
||||||
|
|
||||||
|
## 5. 队列策略
|
||||||
|
|
||||||
|
- 队列必须有固定容量；
|
||||||
|
- 状态类消息可采用“只保留最新值”；
|
||||||
|
- 事务类技能命令不得静默覆盖；
|
||||||
|
- 大脑过载时优先拒绝低价值请求；
|
||||||
|
- 小脑记录丢弃、超时、覆盖和回退原因；
|
||||||
|
- 域重启后通过 epoch 或会话号拒绝旧消息。
|
||||||
|
|
||||||
|
## 6. 验证重点
|
||||||
|
|
||||||
|
- IPC 单向、往返、P99.9 和观测最大时延；
|
||||||
|
- 消息大小、频率和队列深度的影响；
|
||||||
|
- 队列满、乱序、重复、损坏和版本不一致；
|
||||||
|
- 大脑域重启后的旧消息隔离；
|
||||||
|
- 通信线程是否影响控制核和关键中断。
|
||||||
@@ -0,0 +1,67 @@
|
|||||||
|
# Hypervisor 隔离、故障与降级
|
||||||
|
|
||||||
|
## 1. 隔离对象
|
||||||
|
|
||||||
|
| 资源 | 推荐归属 | 验证问题 |
|
||||||
|
|---|---|---|
|
||||||
|
| 控制 CPU 核 | RTOS 独占 | Linux 满载时是否发生调度干扰 |
|
||||||
|
| 关键内存 | RTOS 静态分区 | Linux OOM、换页或内存压力是否影响控制 |
|
||||||
|
| 电机/编码器/现场总线 | RTOS 直通 | 中断和 DMA 是否经过 Linux |
|
||||||
|
| GPU/NPU/摄像头 | Linux 独占 | 设备复位是否影响 RTOS |
|
||||||
|
| 共享内存 | 最小固定区域 | 越界、缓存一致性和拥塞 |
|
||||||
|
| 网络/存储 | Linux 为主 | 高频 IRQ 是否污染控制核 |
|
||||||
|
|
||||||
|
## 2. 残余共享干扰
|
||||||
|
|
||||||
|
分核和虚拟化不能自动消除：
|
||||||
|
|
||||||
|
- LLC 和缓存互联竞争；
|
||||||
|
- DRAM 带宽及内存控制器竞争；
|
||||||
|
- SoC 总线与 DMA 拥塞；
|
||||||
|
- 芯片级功耗限制；
|
||||||
|
- 温度升高与全局降频；
|
||||||
|
- 固件、系统管理中断和共享时钟源影响。
|
||||||
|
|
||||||
|
因此需要分别实施 CPU、缓存、内存、I/O 和热压力实验，不能用“已使用 Hypervisor”代替隔离证据。
|
||||||
|
|
||||||
|
## 3. 故障模型
|
||||||
|
|
||||||
|
- 大脑推理进程崩溃或永久阻塞；
|
||||||
|
- Linux 域卡死、内核错误或重启；
|
||||||
|
- GPU/NPU 驱动错误和设备复位；
|
||||||
|
- 共享队列溢出、损坏或失联；
|
||||||
|
- 大脑持续产生过期或不安全命令；
|
||||||
|
- Linux 域 CPU、内存、网络和存储过载；
|
||||||
|
- 热降频导致推理与控制执行时间漂移。
|
||||||
|
|
||||||
|
## 4. 降级状态机
|
||||||
|
|
||||||
|
```text
|
||||||
|
智能增强运行
|
||||||
|
│ 单次超时/低置信度
|
||||||
|
▼
|
||||||
|
保持当前安全技能或传统控制
|
||||||
|
│ 连续超时/通信故障
|
||||||
|
▼
|
||||||
|
隔离并重启大脑域
|
||||||
|
│ 本体风险上升
|
||||||
|
▼
|
||||||
|
减速、停车或安全状态
|
||||||
|
```
|
||||||
|
|
||||||
|
每个状态必须规定进入条件、最大驻留时间、控制策略、可用传感器、允许执行器动作和恢复条件。
|
||||||
|
|
||||||
|
## 5. 安全监控职责
|
||||||
|
|
||||||
|
安全监控器位于 RTOS 小脑域或独立安全核，至少负责：
|
||||||
|
|
||||||
|
- 大脑心跳与期限监控；
|
||||||
|
- 命令白名单和参数范围检查；
|
||||||
|
- 速度、力矩、工作空间和碰撞约束；
|
||||||
|
- 过期结果拒绝；
|
||||||
|
- 大脑域隔离与重启请求；
|
||||||
|
- 本地停车和安全状态执行。
|
||||||
|
|
||||||
|
## 6. 核心结论边界
|
||||||
|
|
||||||
|
实验可以证明指定平台和压力范围内的隔离效果，但不能自动证明形式化的最坏情况边界。若要宣称硬实时或功能安全，还需要可信 WCET、可调度性分析、硬件干扰上界和相应安全生命周期证据。
|
||||||
@@ -0,0 +1,67 @@
|
|||||||
|
# 实验设计
|
||||||
|
|
||||||
|
## 1. 对照组
|
||||||
|
|
||||||
|
| 编号 | 系统配置 | 作用 |
|
||||||
|
|---|---|---|
|
||||||
|
| A0 | 普通 Linux：控制与大脑负载同域 | 通用基线 |
|
||||||
|
| A1 | PREEMPT_RT Linux：控制与大脑负载同域 | 实时 Linux 基线 |
|
||||||
|
| A2 | RTOS 小脑 + Linux 大脑，基础分区 | 分域基线 |
|
||||||
|
| A3 | A2 + CPU/IRQ/内存/IPC 治理 | 完整方案 |
|
||||||
|
| A4 | A3 + 超时、降级和故障恢复 | 安全协同方案 |
|
||||||
|
|
||||||
|
对照固定机器人控制任务、AI 模型、输入到达序列、硬件频率和功率策略。若推理后端不同，结果表述为系统方案比较，不单独归因于内核。
|
||||||
|
|
||||||
|
## 2. 负载场景
|
||||||
|
|
||||||
|
| 场景 | 内容 | 目的 |
|
||||||
|
|---|---|---|
|
||||||
|
| L0 | 仅小脑控制 | 实时性下界 |
|
||||||
|
| L1 | 仅大脑推理 | 推理容量与功耗基线 |
|
||||||
|
| L2 | 控制 + 感知/大模型 | 核心共存场景 |
|
||||||
|
| L3 | L2 + CPU/内存压力 | 共享资源干扰 |
|
||||||
|
| L4 | L2 + 摄像头/网络/存储 I/O | IRQ 与 DMA 干扰 |
|
||||||
|
| L5 | L2 + 突发请求和过载 | 队列与准入边界 |
|
||||||
|
| L6 | L2 长时间运行至热稳态 | 功耗和降频耦合 |
|
||||||
|
| L7 | 进程、域、加速器和通信故障 | 隔离、降级与恢复 |
|
||||||
|
|
||||||
|
## 3. 控制任务
|
||||||
|
|
||||||
|
至少包含：
|
||||||
|
|
||||||
|
- 高频周期控制任务；
|
||||||
|
- 状态估计或轨迹跟踪任务；
|
||||||
|
- 关键 I/O 或 GPIO 回环；
|
||||||
|
- 安全监控与回退任务。
|
||||||
|
|
||||||
|
无真实机器人时，先使用硬件在环、倒立摆、电机台架或确定性控制负载；不得仅用空循环替代全部控制语义。
|
||||||
|
|
||||||
|
## 4. 大脑任务
|
||||||
|
|
||||||
|
按平台能力选择视觉、VLM、VLA 或 LLM。大脑输出必须转换为结构化技能命令。分别扫描：
|
||||||
|
|
||||||
|
- 请求率和突发强度；
|
||||||
|
- 模型规模、输入长度和输出长度；
|
||||||
|
- batch、队列长度与并发；
|
||||||
|
- GPU/NPU 利用率；
|
||||||
|
- 感知数据大小和通信频率。
|
||||||
|
|
||||||
|
## 5. 故障注入
|
||||||
|
|
||||||
|
依次实施：推理进程退出、请求永久阻塞、消息乱序或损坏、队列溢出、Linux 域重启、加速器错误。设备级故障只在具备可恢复路径时开展。
|
||||||
|
|
||||||
|
记录故障发生、检测、回退、隔离、重启和首个恢复结果的完整时间线。
|
||||||
|
|
||||||
|
## 6. 实施顺序
|
||||||
|
|
||||||
|
1. 冻结控制 deadline、大脑结果期限和回退期限。
|
||||||
|
2. 完成 A0/A1 的同域基线。
|
||||||
|
3. 建立 A2 基础分域和最小 IPC。
|
||||||
|
4. 扫描 CPU、内存、I/O 和热干扰。
|
||||||
|
5. 加入 A3 治理机制并逐项消融。
|
||||||
|
6. 加入 A4 故障状态机并开展故障注入。
|
||||||
|
7. 进行长稳实验和独立确认批次。
|
||||||
|
|
||||||
|
## 7. 最小闭环
|
||||||
|
|
||||||
|
一台具备 RTOS/Linux 分域条件的边缘平台、一个可测量的控制任务和一个真实 AI 大脑负载，即可形成最小验证闭环，不要求扩展到工作站或集群。
|
||||||
@@ -0,0 +1,60 @@
|
|||||||
|
# 指标与证据
|
||||||
|
|
||||||
|
## 1. 小脑控制实时性
|
||||||
|
|
||||||
|
- 周期任务释放、开始和完成时间；
|
||||||
|
- 响应时间与完成抖动；
|
||||||
|
- P50/P95/P99/P99.9 和观测最大值；
|
||||||
|
- deadline miss ratio，报告分子与分母；
|
||||||
|
- 外部输入到执行器输出的物理链路时延；
|
||||||
|
- 过载、热稳态和故障期间的控制表现。
|
||||||
|
|
||||||
|
## 2. 大脑结果可用性
|
||||||
|
|
||||||
|
- 大小脑端到端决策时延；
|
||||||
|
- deadline-hit ratio；
|
||||||
|
- 结果新鲜度合格率；
|
||||||
|
- 超时、过期、乱序、损坏和拒绝率；
|
||||||
|
- 模型任务质量与置信度；
|
||||||
|
- 大脑不可用时的回退发生率。
|
||||||
|
|
||||||
|
## 3. 跨域与隔离代价
|
||||||
|
|
||||||
|
- IPC 单向/往返延迟及尾部；
|
||||||
|
- 拷贝次数、CPU 开销和队列占用；
|
||||||
|
- 静态保留的 CPU、内存和设备资源；
|
||||||
|
- 分域前后的推理有效吞吐和能效；
|
||||||
|
- Linux 满载相对小脑空载的控制延迟增量；
|
||||||
|
- LLC、DRAM、I/O 和热压力的敏感度。
|
||||||
|
|
||||||
|
## 4. 故障与恢复
|
||||||
|
|
||||||
|
- 故障检测时间；
|
||||||
|
- 回退完成时间；
|
||||||
|
- 域隔离和重启时间；
|
||||||
|
- 故障窗口内控制违约数；
|
||||||
|
- 恢复后首个有效大脑结果时间；
|
||||||
|
- 是否出现不可恢复故障或错误动作。
|
||||||
|
|
||||||
|
## 5. 联合判定
|
||||||
|
|
||||||
|
系统配置只有同时满足下列条件才算有效：
|
||||||
|
|
||||||
|
```text
|
||||||
|
控制任务满足期限
|
||||||
|
AND 大脑结果达到规定的按期率与质量
|
||||||
|
AND 超时结果不会进入执行路径
|
||||||
|
AND 故障时在期限内完成回退
|
||||||
|
AND 资源和能耗代价可接受
|
||||||
|
```
|
||||||
|
|
||||||
|
平均推理时延降低但控制违约增加，不构成系统实时性改善；控制零违约但所有 AI 请求都被拒绝，也不构成有效协同。
|
||||||
|
|
||||||
|
## 6. 推荐核心图表
|
||||||
|
|
||||||
|
1. 大脑负载强度—控制违约率—结果按期率可行域；
|
||||||
|
2. 单域与分域方案的控制尾延迟对比；
|
||||||
|
3. CPU、内存、I/O 和热干扰消融图；
|
||||||
|
4. 跨域时序分解图；
|
||||||
|
5. 大脑故障期间控制时间序列；
|
||||||
|
6. 静态资源预留与推理有效吞吐 Pareto 曲线。
|
||||||
@@ -0,0 +1,45 @@
|
|||||||
|
# 项目框架2：面向机器人大小脑异构系统的实时保障研究
|
||||||
|
|
||||||
|
## 一句话定位
|
||||||
|
|
||||||
|
本项目研究机器人“大脑—小脑”异构系统的系统级实时保障：Linux 大脑域承担感知、推理与规划，RTOS 小脑域承担运动控制和安全保护，Hypervisor 或等价分区机制负责资源与故障隔离。
|
||||||
|
|
||||||
|
## 核心问题
|
||||||
|
|
||||||
|
> 当大模型、视觉和规划负载具有动态执行时间且可能过载或故障时，如何保证机器人控制闭环持续满足截止期，并使大脑输出只在满足时限、新鲜度和安全约束时进入执行路径？
|
||||||
|
|
||||||
|
## 与另外两套框架的区别
|
||||||
|
|
||||||
|
| 框架 | 研究主语 | 核心场景 | 本框架中的地位 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 框架1 | 大型跨平台 RTOS | T5～T1 五类部署形态 | 机制与设备资料来源，不作为本框架的统一谱系 |
|
||||||
|
| 框架2 | 机器人大小脑异构系统 | RTOS 控制域 + Linux 推理域 | 当前目录的主线 |
|
||||||
|
| 框架3 | MCU/资源受限 SoC | 轻量 AI 与实时控制同节点共存 | 小脑侧 AI 的专题补充 |
|
||||||
|
|
||||||
|
## 目录结构
|
||||||
|
|
||||||
|
- `00-项目总览/01-研究问题、定位与边界.md`
|
||||||
|
- 研究对象、工业场景、核心假设和结论边界
|
||||||
|
- `10-研究框架/00-整体研究框架.md`
|
||||||
|
- 大小脑架构、三层时间模型与研究主线
|
||||||
|
- `10-研究框架/01-大小脑时间契约与跨域通信.md`
|
||||||
|
- 命令语义、结果新鲜度、有界 IPC 和时序约束
|
||||||
|
- `10-研究框架/02-Hypervisor隔离、故障与降级.md`
|
||||||
|
- CPU、内存、中断、DMA、热干扰和故障恢复
|
||||||
|
- `20-实验与规划/01-实验设计.md`
|
||||||
|
- 对照组、压力场景、故障注入和实施顺序
|
||||||
|
- `20-实验与规划/02-指标与证据.md`
|
||||||
|
- 控制实时性、大脑结果可用性和系统代价指标
|
||||||
|
|
||||||
|
## 推荐阅读顺序
|
||||||
|
|
||||||
|
1. `00-项目总览/01-研究问题、定位与边界.md`
|
||||||
|
2. `10-研究框架/00-整体研究框架.md`
|
||||||
|
3. `10-研究框架/01-大小脑时间契约与跨域通信.md`
|
||||||
|
4. `10-研究框架/02-Hypervisor隔离、故障与降级.md`
|
||||||
|
5. `20-实验与规划/01-实验设计.md`
|
||||||
|
6. `20-实验与规划/02-指标与证据.md`
|
||||||
|
|
||||||
|
## 推荐课题名称
|
||||||
|
|
||||||
|
> **面向机器人大小脑异构系统的分域实时保障与安全协同机制研究**
|
||||||
@@ -0,0 +1,44 @@
|
|||||||
|
# 研究问题、定位与边界
|
||||||
|
|
||||||
|
## 1. 问题背景
|
||||||
|
|
||||||
|
MCU 和资源受限 SoC 原本承担周期控制、采集、通信和保护任务。引入 AI 后，模型执行会持续占用 CPU/NPU、内存、缓存、总线、DMA 和功耗预算，导致控制抖动、关键中断延迟、内存不足或热降频。
|
||||||
|
|
||||||
|
该问题具有明确的工业实时属性：AI 可以降质、跳帧或暂停，但关键控制任务和安全保护不能因为 AI 负载而失去截止期。
|
||||||
|
|
||||||
|
## 2. 核心研究问题
|
||||||
|
|
||||||
|
1. 轻量 AI 通过哪些资源路径影响控制任务？
|
||||||
|
2. 如何为 AI 分配可执行时间、内存、带宽和功耗预算？
|
||||||
|
3. AI 负载超过容量时，如何限流、跳帧、切换模型或暂停执行？
|
||||||
|
4. 模型精度、结果期限、控制实时性和能耗之间如何联合优化？
|
||||||
|
5. 不同 MCU/SoC 上哪些机制可迁移，哪些依赖具体硬件？
|
||||||
|
|
||||||
|
## 3. 研究范围
|
||||||
|
|
||||||
|
### 纳入范围
|
||||||
|
|
||||||
|
- MCU、带 NPU 的工业 SoC 和控制器；
|
||||||
|
- AI 与控制任务同 OS 或同芯片共存；
|
||||||
|
- 固定优先级、预算服务器、准入和过载降级；
|
||||||
|
- 静态内存、DMA、缓存、总线、功耗和热管理；
|
||||||
|
- GPIO、CAN、RS485、工业以太网等物理响应。
|
||||||
|
|
||||||
|
### 不纳入主线
|
||||||
|
|
||||||
|
- 大模型训练和多节点集群；
|
||||||
|
- 为补齐 T1～T5 而采购全谱系设备；
|
||||||
|
- 只测 tokens/s 或平均推理速度；
|
||||||
|
- 在设备无法真实运行时估算模型性能；
|
||||||
|
- 把零违约实测表述为理论硬实时证明。
|
||||||
|
|
||||||
|
## 4. 基本假设
|
||||||
|
|
||||||
|
- H1：AI 对控制的主要影响不仅来自 CPU，还来自内存、DMA、中断和热耦合。
|
||||||
|
- H2：预算、预分配和准入可以扩大控制无违约的 AI 运行范围。
|
||||||
|
- H3：过载时主动降低 AI 服务质量，比继续排队更有利于维持系统可预测性。
|
||||||
|
- H4：满足相同控制和 AI 约束时，可以找到能耗更低的模型、频率与执行策略。
|
||||||
|
|
||||||
|
## 5. 成果边界
|
||||||
|
|
||||||
|
本研究证明的是指定设备、任务和环境下的容量边界与机制收益。不同芯片的 NPU 固件、内存控制器和功耗策略不同，不能仅按内存容量把结果直接外推。
|
||||||
@@ -0,0 +1,59 @@
|
|||||||
|
# 整体研究框架
|
||||||
|
|
||||||
|
## 1. 系统模型
|
||||||
|
|
||||||
|
```text
|
||||||
|
┌─────────────────────────────────────────────┐
|
||||||
|
│ 安全与关键控制任务 │
|
||||||
|
│ 周期控制、联锁、关键采集、现场总线 │
|
||||||
|
├─────────────────────────────────────────────┤
|
||||||
|
│ AI 目标任务 │
|
||||||
|
│ 检测、估计、识别、诊断、轻量智能决策 │
|
||||||
|
├─────────────────────────────────────────────┤
|
||||||
|
│ 伴生任务 │
|
||||||
|
│ 日志、通信、更新、存储和非关键后台服务 │
|
||||||
|
├─────────────────────────────────────────────┤
|
||||||
|
│ RTOS/嵌入式系统治理 │
|
||||||
|
│ 优先级、预算、准入、预分配、中断与降级 │
|
||||||
|
├─────────────────────────────────────────────┤
|
||||||
|
│ MCU/SoC：CPU、NPU、RAM、缓存、总线、DMA、热 │
|
||||||
|
└─────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
## 2. 优先级原则
|
||||||
|
|
||||||
|
1. 安全与关键控制任务优先满足 deadline；
|
||||||
|
2. AI 任务在剩余时间和资源预算内执行；
|
||||||
|
3. AI 结果超过有效期后不再进入控制路径；
|
||||||
|
4. 伴生任务不得挤占控制和已准入 AI 的预算；
|
||||||
|
5. 过载时优先降低 AI 频率、模型复杂度或输入质量。
|
||||||
|
|
||||||
|
## 3. 四维预算
|
||||||
|
|
||||||
|
| 预算 | 控制手段 | 典型风险 |
|
||||||
|
|---|---|---|
|
||||||
|
| 时间预算 | 固定优先级、时间服务器、分块执行 | 长算子和不可抢占段 |
|
||||||
|
| 内存预算 | 静态分配、内存池、峰值准入 | OOM、碎片、共享缓冲区 |
|
||||||
|
| 带宽预算 | DMA 编排、访问节流、采样降频 | 控制数据被 AI 挤占 |
|
||||||
|
| 功耗预算 | DVFS、模型切换、占空比控制 | 热降频反向破坏实时性 |
|
||||||
|
|
||||||
|
## 4. 运行状态
|
||||||
|
|
||||||
|
```text
|
||||||
|
S0 控制优先、AI 正常运行
|
||||||
|
S1 AI 降频或跳帧
|
||||||
|
S2 切换轻量模型或低精度模式
|
||||||
|
S3 暂停 AI，保留传统控制
|
||||||
|
S4 故障安全状态
|
||||||
|
```
|
||||||
|
|
||||||
|
状态切换依据控制裕量、队列长度、内存水位、温度、功耗和 AI 结果质量。切换过程本身必须有界，并避免关键路径动态加载大型模型。
|
||||||
|
|
||||||
|
## 5. 研究主线
|
||||||
|
|
||||||
|
- AI WCET/执行时间分布与可抢占结构分析；
|
||||||
|
- 控制任务响应时间和共享资源干扰分析；
|
||||||
|
- AI 多维预算与准入控制；
|
||||||
|
- 精度、执行频率和功耗联合降级；
|
||||||
|
- 长时间热稳态和异常恢复；
|
||||||
|
- 跨设备可迁移机制与芯片特定机制区分。
|
||||||
@@ -0,0 +1,54 @@
|
|||||||
|
# AI 预算调度与控制保护
|
||||||
|
|
||||||
|
## 1. 任务模型
|
||||||
|
|
||||||
|
控制任务表示为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
τc = (Tc, Dc, Cc, Pc)
|
||||||
|
```
|
||||||
|
|
||||||
|
其中 `T` 为周期、`D` 为截止期、`C` 为执行需求、`P` 为优先级。
|
||||||
|
|
||||||
|
AI 任务表示为：
|
||||||
|
|
||||||
|
```text
|
||||||
|
τai = (arrival, deadline, budget_cpu, budget_mem,
|
||||||
|
budget_power, quality_level, droppable)
|
||||||
|
```
|
||||||
|
|
||||||
|
AI 任务必须声明是否可丢弃、是否允许跳帧以及可接受的最低质量等级。
|
||||||
|
|
||||||
|
## 2. 调度原则
|
||||||
|
|
||||||
|
- 控制任务使用固定优先级或已验证的实时调度策略；
|
||||||
|
- AI 使用低优先级后台、预算服务器或可中止任务；
|
||||||
|
- 将长推理拆分为可抢占或可中断阶段；
|
||||||
|
- 不可抢占 NPU/GPU 执行段必须测量并纳入控制响应时间；
|
||||||
|
- AI 请求只有在时间、内存和功耗预算同时满足时才准入。
|
||||||
|
|
||||||
|
## 3. 准入条件
|
||||||
|
|
||||||
|
```text
|
||||||
|
schedulable(control | ai_load)
|
||||||
|
AND peak_memory <= M_budget
|
||||||
|
AND predicted_power <= P_budget
|
||||||
|
AND result_deadline_feasible
|
||||||
|
AND quality >= Q_min
|
||||||
|
```
|
||||||
|
|
||||||
|
准入失败时，系统可以拒绝请求、推迟非关键输入、跳帧或选择更小模型，不能无限排队。
|
||||||
|
|
||||||
|
## 4. 控制保护机制
|
||||||
|
|
||||||
|
- 控制代码、数据和栈静态分配；
|
||||||
|
- AI 与控制使用独立内存池；
|
||||||
|
- 关键中断优先于 NPU、摄像头和通信完成中断；
|
||||||
|
- 日志采用预分配缓冲并异步输出；
|
||||||
|
- AI 执行前检查控制裕量；
|
||||||
|
- AI 超时后结果直接失效；
|
||||||
|
- 看门狗覆盖 AI 运行时和设备驱动卡死。
|
||||||
|
|
||||||
|
## 5. 消融验证
|
||||||
|
|
||||||
|
逐项移除预算服务器、内存池、中断隔离、准入和降级机制，比较控制尾延迟、AI 按期率和能耗，识别收益来源。
|
||||||
@@ -0,0 +1,55 @@
|
|||||||
|
# 内存、功耗、热与降级
|
||||||
|
|
||||||
|
## 1. 内存治理
|
||||||
|
|
||||||
|
模型准入按完整峰值计算：
|
||||||
|
|
||||||
|
```text
|
||||||
|
M_total = M_weight + M_activation + M_workspace
|
||||||
|
+ M_io + M_runtime + M_control_reserved
|
||||||
|
```
|
||||||
|
|
||||||
|
必须为控制任务、关键通信和故障日志保留不可侵占空间。权重大小不能代替峰值内存测量。
|
||||||
|
|
||||||
|
推荐机制：
|
||||||
|
|
||||||
|
- 模型和工作区静态加载；
|
||||||
|
- 固定大小内存池；
|
||||||
|
- 禁止关键窗口模型切换；
|
||||||
|
- DMA 缓冲区白名单和容量上限；
|
||||||
|
- OOM 前主动降低 AI 并发或切换模型。
|
||||||
|
|
||||||
|
## 2. 功耗与热耦合
|
||||||
|
|
||||||
|
AI 满载可能触发整芯片功耗限制或热降频，进而增加控制任务执行时间。实验必须同步记录：
|
||||||
|
|
||||||
|
- 整机功率；
|
||||||
|
- 芯片温度；
|
||||||
|
- CPU/NPU 实际频率；
|
||||||
|
- AI 执行阶段；
|
||||||
|
- 控制响应时间和违约；
|
||||||
|
- 降频事件。
|
||||||
|
|
||||||
|
## 3. 降级策略
|
||||||
|
|
||||||
|
| 触发条件 | 优先动作 |
|
||||||
|
|---|---|
|
||||||
|
| 控制裕量下降 | 降低 AI 请求率或跳帧 |
|
||||||
|
| AI 队列增长 | 拒绝低优先级请求 |
|
||||||
|
| 内存水位过高 | 减少并发或切换小模型 |
|
||||||
|
| 温度接近阈值 | 降低 AI 占空比或精度 |
|
||||||
|
| 连续 AI 超时 | 暂停 AI，保留传统控制 |
|
||||||
|
| 驱动或设备故障 | 复位 AI 子系统并进入安全模式 |
|
||||||
|
|
||||||
|
## 4. 能效口径
|
||||||
|
|
||||||
|
不能仅比较最低功率，应在相同控制实时约束和 AI 质量约束下比较：
|
||||||
|
|
||||||
|
- 单次有效推理能耗；
|
||||||
|
- 有效结果/焦耳；
|
||||||
|
- 控制无违约条件下的持续 AI 吞吐；
|
||||||
|
- 热稳态而非冷机短时能效。
|
||||||
|
|
||||||
|
## 5. 结论边界
|
||||||
|
|
||||||
|
动态量化、模型切换和 DVFS 只有在切换开销已测量且不破坏控制 deadline 时，才能称为实时感知的低功耗策略。
|
||||||
@@ -0,0 +1,64 @@
|
|||||||
|
# 实验设计
|
||||||
|
|
||||||
|
## 1. 平台选择
|
||||||
|
|
||||||
|
建议最少包含：
|
||||||
|
|
||||||
|
- 一个 MCU 或低资源控制器，用于 TinyML/轻量 AI 与周期控制共存；
|
||||||
|
- 一个带 NPU 的资源受限 SoC，用于统一内存、DMA 和热干扰；
|
||||||
|
- 必要的功率计、逻辑分析仪或示波器以及 CAN/RS485 对端。
|
||||||
|
|
||||||
|
设备按真实 AI 运行能力选择，不以补齐 T1～T5 为目标。
|
||||||
|
|
||||||
|
## 2. 对照组
|
||||||
|
|
||||||
|
| 编号 | 配置 |
|
||||||
|
|---|---|
|
||||||
|
| C0 | 仅控制任务 |
|
||||||
|
| C1 | 控制 + AI 默认配置 |
|
||||||
|
| C2 | C1 + 优先级和中断隔离 |
|
||||||
|
| C3 | C2 + 时间/内存/功耗预算与准入 |
|
||||||
|
| C4 | C3 + 模型降级和故障恢复 |
|
||||||
|
|
||||||
|
## 3. 压力场景
|
||||||
|
|
||||||
|
| 场景 | 内容 |
|
||||||
|
|---|---|
|
||||||
|
| M0 | 控制空载基线 |
|
||||||
|
| M1 | AI 独立运行 |
|
||||||
|
| M2 | 控制 + AI |
|
||||||
|
| M3 | M2 + CPU/缓存压力 |
|
||||||
|
| M4 | M2 + 内存/DMA 压力 |
|
||||||
|
| M5 | M2 + I/O/中断压力 |
|
||||||
|
| M6 | AI 突发和过载 |
|
||||||
|
| M7 | 热稳态和降频 |
|
||||||
|
| M8 | OOM、超时、运行时或设备故障 |
|
||||||
|
|
||||||
|
## 4. 变量扫描
|
||||||
|
|
||||||
|
- 控制周期、执行预算和关键 I/O 频率；
|
||||||
|
- AI 模型、精度、输入尺寸和执行频率；
|
||||||
|
- CPU/NPU 频率与功率模式；
|
||||||
|
- 内存预算和 DMA 缓冲区大小；
|
||||||
|
- AI 队列深度、跳帧率和超时期限；
|
||||||
|
- 环境温度和持续运行时间。
|
||||||
|
|
||||||
|
## 5. 实施顺序
|
||||||
|
|
||||||
|
1. 验证控制任务和物理计时链路。
|
||||||
|
2. 完成模型正确性、峰值内存和独立能耗准入。
|
||||||
|
3. 运行 C0/C1，确认 AI 实际产生的干扰。
|
||||||
|
4. 依次加入 C2～C4 并做逐项消融。
|
||||||
|
5. 扫描负载直到出现控制违约或 AI 服务失效。
|
||||||
|
6. 在选定边界附近进行热稳态与长时间实验。
|
||||||
|
7. 使用冻结配置进行独立确认批次。
|
||||||
|
|
||||||
|
## 6. 停止条件
|
||||||
|
|
||||||
|
- 控制任务出现不可接受违约；
|
||||||
|
- 温度、电压或电流超过设备安全范围；
|
||||||
|
- 测量链路丢样或时钟失效；
|
||||||
|
- 内存不足导致无法保持关键任务；
|
||||||
|
- AI 后端不支持目标模型或精度。
|
||||||
|
|
||||||
|
停止不代表实验失败，应记录为容量或适配边界。
|
||||||
@@ -0,0 +1,58 @@
|
|||||||
|
# 指标与证据
|
||||||
|
|
||||||
|
## 1. 控制实时性
|
||||||
|
|
||||||
|
- 任务响应时间、完成抖动和观测最大值；
|
||||||
|
- deadline miss ratio；
|
||||||
|
- 中断响应和关键 I/O 端到端时延；
|
||||||
|
- AI 启停、模型切换和降频瞬间的时间序列；
|
||||||
|
- 故障与恢复窗口内的控制表现。
|
||||||
|
|
||||||
|
## 2. AI 服务有效性
|
||||||
|
|
||||||
|
- 推理端到端时延和按期率；
|
||||||
|
- 有效结果率、任务质量和超时率；
|
||||||
|
- 跳帧、拒绝和降级比例；
|
||||||
|
- 模型切换时间；
|
||||||
|
- 控制无违约条件下的最大持续 AI 负载。
|
||||||
|
|
||||||
|
## 3. 资源与能耗
|
||||||
|
|
||||||
|
- 峰值和稳态内存；
|
||||||
|
- CPU/NPU 利用率与执行占空比；
|
||||||
|
- 内存带宽或可取得的代理指标；
|
||||||
|
- 整机平均功率、峰值功率和能量；
|
||||||
|
- 温度、实际频率和降频时间比例；
|
||||||
|
- 单次有效结果能耗和有效结果/焦耳。
|
||||||
|
|
||||||
|
## 4. 核心结果表达
|
||||||
|
|
||||||
|
推荐把结果组织为“安全运行区”：
|
||||||
|
|
||||||
|
```text
|
||||||
|
控制 deadline 满足
|
||||||
|
AND AI 质量 >= Q_min
|
||||||
|
AND AI 按期率 >= H_min
|
||||||
|
AND 功耗 <= P_max
|
||||||
|
AND 温度 <= Temp_max
|
||||||
|
```
|
||||||
|
|
||||||
|
扫描 AI 频率、模型复杂度和功耗模式，绘制满足全部条件的可行区域及其边界。
|
||||||
|
|
||||||
|
## 5. 不应使用的证据替代
|
||||||
|
|
||||||
|
- 平均延迟不能替代 deadline miss ratio；
|
||||||
|
- 短时冷机性能不能替代热稳态；
|
||||||
|
- 模型权重大小不能替代峰值内存；
|
||||||
|
- 芯片标称 TOPS 不能替代实测完成时间；
|
||||||
|
- 零违约不能直接表述为理论硬实时保证；
|
||||||
|
- 降低 AI 完成率获得的低功耗不能单独称为能效提升。
|
||||||
|
|
||||||
|
## 6. 推荐图表
|
||||||
|
|
||||||
|
1. AI 负载—控制尾延迟与违约率曲线；
|
||||||
|
2. 时间、内存、功耗预算消融图；
|
||||||
|
3. 模型质量—按期率—能耗 Pareto 图；
|
||||||
|
4. 热稳态下温度、频率、控制延迟时间序列；
|
||||||
|
5. 过载状态下跳帧、降级和恢复过程；
|
||||||
|
6. 不同 MCU/SoC 的机制可迁移性对比表。
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
# 项目框架3：MCU 与资源受限 SoC 的 AI 实时性与低功耗研究
|
||||||
|
|
||||||
|
## 一句话定位
|
||||||
|
|
||||||
|
本项目研究 MCU 和资源受限 SoC 引入轻量 AI 后的实时干扰、资源预算、低功耗运行与安全降级问题，形成“控制期限优先、AI 预算执行、过载主动降级”的端侧智能方法。
|
||||||
|
|
||||||
|
## 核心问题
|
||||||
|
|
||||||
|
> 在 CPU、内存、带宽、功耗和散热均受限的控制节点中，允许多大的 AI 负载，才能在不破坏周期控制和关键 I/O 截止期的前提下获得有效智能功能？
|
||||||
|
|
||||||
|
## 研究对象说明
|
||||||
|
|
||||||
|
这里的 AI 不默认等于大语言模型。根据硬件能力，可以是：
|
||||||
|
|
||||||
|
- TinyML 和小型神经网络；
|
||||||
|
- 异常检测与预测维护模型；
|
||||||
|
- 轻量视觉、语音和状态识别；
|
||||||
|
- 学习型状态估计或控制补偿；
|
||||||
|
- 能在目标设备真实运行的小型语言模型。
|
||||||
|
|
||||||
|
## 目录结构
|
||||||
|
|
||||||
|
- `00-项目总览/01-研究问题、定位与边界.md`
|
||||||
|
- `10-研究框架/00-整体研究框架.md`
|
||||||
|
- `10-研究框架/01-AI预算调度与控制保护.md`
|
||||||
|
- `10-研究框架/02-内存、功耗、热与降级.md`
|
||||||
|
- `20-实验与规划/01-实验设计.md`
|
||||||
|
- `20-实验与规划/02-指标与证据.md`
|
||||||
|
|
||||||
|
## 推荐课题名称
|
||||||
|
|
||||||
|
> **资源受限嵌入式控制系统中 AI 负载的实时预算与低功耗协同机制研究**
|
||||||
Reference in New Issue
Block a user