docs: add metrics and research references

Merge origin/main updates using repository document structure
docs: add SylixOS experiment plan and formatted reports
2026-09-21 15:55:17 +08:00 · 2026-09-21 10:12:56 +08:00 · 2026-09-20 13:32:20 +08:00
25 changed files with 2622 additions and 23 deletions
@@ -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
@@ -12,6 +12,7 @@
 6. `05-中断与实时性保障.md`
 7. `06-能耗与热管理.md`
 8. `07-方法论与评估工具链.md`
 9. `参考文件/README.md`
 ## 文件说明
@@ -31,3 +32,5 @@
  - 能耗约束、温度耦合、频率策略与热稳定性
 - `07-方法论与评估工具链.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 及行业适用指南。
@@ -3,7 +3,6 @@
 > 版本: v2.1    起草日期: 2026-09-21
 > 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
 > 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
 > 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
 ---
@@ -38,26 +38,7 @@
 GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
-### 2.2 平台 A：现有 V100 服务器
+### 2.2 测量设备
 依设备清单配置 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 测量设备
 | 测量对象 | 工具与接线 | 要求 |
 |---|---|---|
@@ -7,8 +7,9 @@
 1. `01-研究逻辑说明.md`
 2. `02-基础设备与算力基础.md`
 3. `03-实验设计.md`
-4. `04-论文写作规划.md`
+4. `metric.md`
-5. `05-论文结构总览.png`
+5. `04-论文写作规划.md`
 6. `05-论文结构总览.png`
 ## 文件说明
@@ -18,6 +19,8 @@
  - 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,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 和功耗采集均满足对应实验条件 |
 设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
@@ -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 的实时调度和资源隔离在什么负载范围内能显著改善实时任务确定性，这种改善需要付出多少吞吐和能耗代价，其优势又会在哪个硬件档位开始减弱。
 如果数据支持该关系，就形成四层硬件谱系、混合负载实时保号和统一评测方法三项论文贡献；如果某些档位不支持，也应把适配失败、容量上限和优势消失的边界作为研究结论的一部分。
Author	SHA1	Message	Date
Mo1s	2d6e15348f	docs: add metrics and research references	2026-09-21 15:55:17 +08:00
Mo1s	15227a257d	Merge origin/main updates using repository document structure	2026-09-21 10:12:56 +08:00
Mo1s	e2fabe7be8	docs: add SylixOS experiment plan and formatted reports	2026-09-20 13:32:20 +08:00