eaiadmin/rtos_llm_opt
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add edge SoC performance review

Browse Source
This commit is contained in:
eaiadmin
2026-09-29 04:17:22 +00:00
parent 9680329b3b
commit 4107244007
2 changed files with 722 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02-面向边侧异构SoC的混合实时控制基础系统研究综述.md
+444
View File
@@ -0,0 +1,444 @@
# 面向边侧异构SoC的混合实时控制基础系统研究综述
## 摘要
随着边缘人工智能从“离线感知”走向“在线决策”，边侧系统需要在同一异构SoC上同时承载硬实时控制、深度学习推理、设备管理、网络通信和人机交互等差异显著的工作负载。传统单一操作系统难以同时满足确定性、算力利用率、软件生态和故障隔离要求，Linux、实时操作系统（RTOS）、静态分区Hypervisor以及非对称多处理（AMP）相结合的混合系统因而成为重要技术路线。本文围绕边侧异构SoC上的混合实时控制基础系统，对实时Linux、双内核、AMP、静态分区虚拟化、共享资源干扰治理、GPU/NPU可预测执行、跨域通信以及安全降级等研究进行结构化综述。已有研究表明，处理器核、内存和设备的静态划分能够降低软件域之间的直接干扰，但共享末级缓存、内存控制器、DMA、片上互连、加速器驱动以及功耗热约束仍会形成难以忽略的跨域耦合；同时，平均推理速度、虚拟机切换开销和通信吞吐量均不能单独证明端到端实时性。本文据此提出“控制响应时间—AI结果新鲜度—资源干扰预算—故障恢复语义”四维分析框架，并给出适用于本课题的系统分工、评价指标和实验路线。综述认为，下一阶段的关键不在于简单选择Linux、RTOS或某一种Hypervisor，而在于形成可测量、可配置、可复现且可审查的系统级实时边界，使AI域失效、过载或超时时，控制域仍能维持安全状态。
**关键词：** 边缘人工智能；异构SoC；混合关键系统；实时操作系统；静态分区Hypervisor；共享资源干扰；NPU；安全降级
---
## 1 引言
边侧智能控制系统正从“传感器采集—云端分析”转向“本地感知—本地推理—本地闭环”。典型平台往往在单芯片中集成多核CPU、GPU、NPU、DSP、共享内存控制器、DMA和高速外设。一方面，Linux能够提供完整的AI运行时、设备驱动、网络协议栈和应用生态；另一方面，电机控制、运动控制、制动、保护和看门狗等任务要求低抖动、可分析的最坏响应时间及明确的故障处置责任。两类需求叠加后，系统设计问题从“模型是否足够快”扩展为“整个控制链在竞争、过载和故障条件下是否仍满足边界”。
Vestal提出的混合关键度任务模型揭示了同一计算平台上不同保证等级工作负载共存的基本矛盾[1]；后续综述表明，混合关键系统研究已经从处理器调度扩展到内存、I/O、通信、虚拟化和认证证据[2]。在边侧AI场景中，这一矛盾进一步表现为：AI任务通常具有高吞吐、突发性和运行时不透明等特征，而控制任务强调周期性、优先级、截止期和故障可控。因此，本文不把“Linux+RTOS”视为天然实时的答案，而是考察操作系统分工、虚拟化隔离、共享资源治理、跨域数据语义和安全降级如何共同构成实时保证。
本文的主要目的有三点：
1. 梳理边侧异构SoC混合实时系统的主要技术形态及其适用边界；
2. 总结影响端到端确定性的关键干扰源、测量方法和治理机制；
3. 将已有研究转化为子课题B可执行的体系结构、实验问题和评价指标。
## 2 综述范围与方法
### 2.1 研究范围
本文关注部署在边侧异构SoC上的本地闭环系统，主要覆盖以下对象：
- 实时Linux、双内核和协内核机制；
- Linux与RTOS并行运行的AMP系统；
- 静态分区Hypervisor、分离内核和微内核虚拟化；
- 多核共享缓存、DRAM、DMA、片上互连和加速器竞争；
- GPU/NPU推理的调度、抢占、可观测性和时延分析；
- 跨域共享内存、消息通道、时钟与状态同步；
- AI失效、超时和异常条件下的监测、隔离、降级与恢复。
本文不重点讨论云端训练、纯服务器推理、仅含单片机且没有多操作系统共存的系统，也不把平均帧率提升作为实时性研究的充分证据。
### 2.2 文献选择与证据使用
本文采用结构化叙述综述方法，检索和分析截至**2026年9月**公开的代表性研究论文、国际标准和项目官方资料。材料选择遵循以下原则：
1. 优先采用原始论文、标准正文入口和项目官方文档；
2. 同时覆盖体系结构、调度与资源干扰、跨域通信、安全与评价方法；
3. 对尚缺乏开放实现或可复现实验的数据，仅作为研究趋势，不作为确定结论；
4. 对厂商或项目自述的能力，明确视为工程资料，而不等同于独立实验验证。
本文属于面向课题设计的结构化综述，不宣称穷尽全部文献，也不进行统计意义上的Meta分析。
## 3 核心概念与分析框架
### 3.1 混合实时控制系统的基本对象
本文所称“混合实时控制基础系统”，是指在同一边侧SoC上，以两个或多个执行域共同承载控制与智能任务的系统。典型职责划分如下：
| 执行域 | 典型职责 | 主要保证目标 |
|---|---|---|
| RTOS/安全域 | 传感采集、控制律、执行器输出、联锁、看门狗、降级控制 | 截止期、低抖动、故障可控 |
| Linux/智能域 | AI推理、模型管理、复杂协议、日志、可视化、OTA | 算力与生态、功能完整性 |
| Hypervisor/分离层 | 核、内存、设备、中断与通信通道划分 | 空间隔离、故障约束、启动与生命周期管理 |
| GPU/NPU/DSP域 | 神经网络或信号处理加速 | 有界排队、可观测执行、资源预算 |
这里的“混合”不是简单并存，而是要求各执行域之间存在明确的资源所有权、数据契约、时间边界和故障处置规则。
### 3.2 端到端实时边界
单独测量控制线程周期或模型推理时间会遗漏大量系统开销。对一次“采集—推理—决策—执行”链路，可采用下式描述端到端时延：
\[
L_{e2e}=L_{sense}+L_{input}+L_{queue}+L_{infer}+L_{ipc}+L_{validate}+L_{actuate}
\]
其中，输入搬运、队列等待、跨域通信和结果校验都可能形成长尾。对高关键控制任务，其响应时间可进一步分解为：
\[
R_c=C_c+B_{os}+B_{hv}+I_{cpu}+I_{cache}+I_{dram}+I_{dma}+I_{irq}+I_{thermal}
\]
式中，\(C_c\)为任务自身执行时间，\(B_{os}\)和\(B_{hv}\)分别为操作系统与虚拟化阻塞，\(I_*\)表示核、缓存、内存、DMA、中断和热降频等干扰。该分解并非假定各项严格独立，而是用于建立可测量的干扰清单和预算归属。
AI结果的有效性还应同时满足时间和内容条件：
\[
Valid(y)=Fresh(y)\land Integrity(y)\land Confidence(y)\land VersionMatch(y)
\]
即结果必须未超过新鲜度窗口、数据完整、置信度满足策略且模型与协议版本匹配。由此可见，AI推理完成并不等于控制系统可以使用该结果。
## 4 系统形态及其适用边界
### 4.1 单Linux与PREEMPT_RT
PREEMPT_RT通过可抢占内核、优先级继承锁和线程化中断等机制缩短Linux中的不可抢占区间[3]。这一方案保留了完整Linux生态，开发与部署成本较低，适合关键度中等、外设和AI软件栈复杂的系统。然而，它主要改善调度延迟，并不自动消除设备驱动长临界区、内存带宽竞争、GPU/NPU运行时阻塞、SMI等固件活动以及应用级故障。因此，“启用PREEMPT_RT并测得较低平均延迟”不能直接推出硬实时保证。
### 4.2 双内核或协内核
Xenomai Cobalt等双内核方案在Linux旁建立更高优先级的实时执行环境，使实时活动能够优先于普通Linux路径[4]。相较单Linux，该方案可以减小Linux负载对实时线程的直接影响，同时仍利用Linux驱动和应用生态。其代价是内核适配、系统调用迁移、调试链和版本维护复杂度增加；更重要的是，双内核仍共享缓存、DRAM和部分设备，不能仅依靠中断优先级解决片上共享资源干扰。
### 4.3 AMP：Linux与RTOS并行运行
AMP通常把不同CPU核交给Linux和RTOS独立管理，并通过共享内存和核间中断通信。OpenAMP及Linux remoteproc/RPMsg为远端处理器生命周期和消息通道提供了通用框架[5][6]。AMP结构适用于SoC已经包含应用核与实时核、设备所有权较易静态划分的场景。其优势是RTOS可以独立掌握控制循环和执行器；其局限在于启动顺序、共享内存一致性、地址映射、设备复位、故障传播和跨域优先级等通常依赖平台实现，系统级证据容易碎片化。
### 4.4 静态分区Hypervisor
静态分区Hypervisor在启动阶段把CPU核、内存区域和设备分配给各客体，运行期尽量避免复杂的动态资源复用。Jailhouse采用Linux先启动、随后建立隔离单元的工程路径[7]；Bao强调面向嵌入式多核平台的轻量静态分区[8]；Xen Dom0-less、ACRN等也提供面向嵌入式或工业场景的不同部署模式[9][10]。静态分区减少了动态调度与频繁VM退出，便于构造较清晰的资源所有权。
但静态分区并非“物理隔离”的同义词。即使CPU核、内存页和设备已划分，不同分区仍可能共享末级缓存、内存控制器、片上互连、电源域和热设计功耗。Martins和Pinto对多种Arm静态分区Hypervisor的系统比较也说明，应同时评估中断延迟、通信、启动、代码规模和共享资源影响，而不能只比较虚拟化微基准开销[11]。
### 4.5 分离内核与高保证微内核
seL4等微内核通过能力机制和形式化验证强化空间隔离与内核正确性证据[12]。这类方案适合对可信计算基和认证证据要求较高的场景。不过，经过验证的内核并不意味着设备驱动、Hypervisor配置、硬件实现、AI运行时和应用任务的最坏执行时间也已经得到验证。因此，高保证内核应被视为证据链的一部分，而不是完整系统安全与实时性的替代品。
### 4.6 形态比较
| 形态 | 实时隔离潜力 | Linux生态 | 跨域协同成本 | 主要风险 | 适用场景 |
|---|---:|---:|---:|---|---|
| Linux + PREEMPT_RT | 中 | 高 | 低 | 内核、驱动与共享资源长尾 | 单域、中等关键度、快速产品化 |
| 双内核/协内核 | 中至高 | 较高 | 中 | 内核适配与共享硬件干扰 | 需要强实时线程但仍依赖Linux |
| AMP（Linux+RTOS） | 高 | 高 | 中至高 | 生命周期、共享内存与故障传播 | 应用核/实时核天然分离的SoC |
| 静态分区Hypervisor | 高 | 高 | 高 | 共享微体系结构资源与设备复位 | 多核SoC、关键域与智能域共存 |
| 分离内核/高保证微内核 | 高 | 中 | 高 | 驱动生态、系统集成与验证成本 | 高可信、高认证要求系统 |
选择依据不应是“哪一种架构更先进”，而应是其能否满足具体设备所有权、截止期、AI软件栈、故障模型和认证目标。
## 5 共享资源干扰与确定性治理
### 5.1 干扰来源
边侧SoC上的干扰具有跨层特征：
- **CPU与调度：** 核超售、优先级反转、不可抢占区、中断风暴；
- **缓存与一致性：** 末级缓存替换、缓存行争用、跨核一致性流量；
- **DRAM与互连：** 内存控制器队列、行缓冲冲突、bank冲突、总线仲裁；
- **DMA与I/O：** 摄像头、网络、存储和NPU的大块传输挤占带宽；
- **加速器：** 驱动队列、命令提交、不可抢占内核、上下文切换；
- **功耗与温度：** DVFS、热降频和共享电源预算导致执行时间漂移；
- **固件与管理域：** 安全监控、系统管理中断和不可见固件活动。
其中，CPU核独占只能消除部分调度竞争，无法消除共享缓存、DRAM、DMA和温度耦合。
### 5.2 缓存与内存治理
MemGuard通过按核带宽监管降低内存带宽争用，并为实时任务提供可控的内存预算[13]；PALLOC利用页着色和DRAM bank感知分配改善内存资源隔离[14]；面向多核并行任务的研究进一步表明，干扰上界需要考虑请求并行性，而不能把每次访存阻塞简单相加[15]。RT-Gang则通过限制高关键并行任务并发、控制内存带宽等方法降低与其他任务之间的不可预测干扰[16]。
这些工作共同说明，资源隔离需要“空间划分+时间监管+运行时监测”协同：
1. 空间划分用于核、内存区域、缓存路和设备所有权；
2. 时间监管用于内存带宽、DMA窗口和加速器服务配额；
3. 运行时监测用于发现预算超限、热降频和异常排队；
4. 超限后的处置必须预先定义，不能只记录日志而继续无界运行。
### 5.3 从资源指标到控制指标
内存带宽、缓存未命中率和DMA吞吐是解释变量，而不是最终验收指标。研究应建立以下因果链：
> 资源竞争强度 → 控制任务响应时间变化 → 截止期违约 → 控制品质或安全状态变化。
因此，资源治理机制必须同时报告其对控制抖动、最大响应时间、AI新鲜度和业务吞吐的影响，避免以牺牲AI功能到不可用为代价获得表面上的实时改善。
## 6 GPU/NPU推理的可预测执行
### 6.1 主要困难
GPU/NPU的峰值算力不能代表其实时能力。边侧AI加速器常见的不确定性包括：
- 驱动和固件内部排队策略不可见；
- 多模型或多进程共享时缺少明确优先级；
- 神经网络算子或命令批次难以中途抢占；
- CPU预处理、内存复制和后处理未计入“推理时间”；
- 统一内存减少显式复制，但可能增加缓存一致性和带宽竞争；
- 温控、功耗封顶和动态频率改变长时间运行结果。
### 6.2 代表性调度研究
GPUart探索了嵌入式GPU上的受限抢占和面向应用的实时调度[17]；GPU server将GPU请求集中到服务任务中，以改善共享GPU时的优先级管理和分析性[18]；GCAPS进一步从GPU上下文与优先级角度研究多核实时任务的加速器调度[19]。RT-Gang等工作也把DNN工作负载纳入共享资源干扰实验[16]。这些成果证明，加速器实时化需要调度协议、驱动机制和可分析模型共同支持，而不是仅在应用层设置线程优先级。
现有GPU研究相对丰富，而NPU通常具有更封闭的编译器、运行时和固件接口。在缺乏公开抢占机制和执行模型时，本课题应采用“黑盒可测、边界可控”的工程策略：固定模型与编译产物，冻结驱动和固件版本，测量提交、排队、执行和完成通知的独立时间戳，并通过准入控制限制并发模型、输入频率和队列深度。
### 6.3 AI结果新鲜度优先于平均吞吐
控制系统对AI输出的核心约束通常不是每秒帧数，而是：
- 最迟何时得到结果；
- 结果对应哪一帧、哪一时刻和哪一模型版本；
- 超时后旧结果是否会被误用；
- 连续多少次无有效结果后必须降级；
- 恢复后需要满足什么条件才能重新参与控制。
因此，建议同时记录平均值、P99/P99.9、观测最大值、截止期违约率和连续违约长度，并强调：有限测试中的“零违约”只是实验观察，不是数学意义上的最坏情况证明。
## 7 跨域通信与协同协议
### 7.1 通信机制
Linux与RTOS之间常采用共享内存环形队列、核间中断、RPMsg、虚拟串口或虚拟网络。共享内存可以降低复制开销，但其确定性仍取决于缓存维护、内存屏障、接收端调度和队列策略。Dong等提出的混合双操作系统实时通信机制表明，跨域RPC需要显式处理优先级和同步语义，单纯追求吞吐不足以满足实时交互[20]。
对于板间或设备间通信，DDS和IEEE TSN分别提供数据分发QoS及确定性以太网相关标准框架[21][22]。它们可用于外部网络的优先级、时钟和传输治理，但不能替代片上共享内存与接收端调度分析。
### 7.2 消息契约
本课题中的跨域消息至少应包含：
| 字段 | 作用 |
|---|---|
| 序列号 | 检测重复、乱序与丢失 |
| 采集时间戳 | 计算结果年龄和端到端时延 |
| 截止时间/有效期 | 在RTOS侧拒绝过期结果 |
| 模型与协议版本 | 防止版本不一致 |
| 置信度与质量标志 | 支持结果准入与降级策略 |
| 完整性校验 | 检测传输或内存破坏 |
| 运行状态 | 表示Linux、NPU及数据源健康状态 |
队列宜采用有界设计。对状态估计类数据，通常应优先保留最新值而不是无限堆积旧值；RTOS控制线程不应因等待Linux或NPU结果而无界阻塞。
### 7.3 时间同步与因果一致性
跨域分析必须区分采集时间、发送时间、接收时间、推理完成时间和执行器生效时间。若各域时钟来源不同，应定义同步方式和最大偏差；若共享同一硬件时钟，也应验证虚拟化层的时间暴露和暂停语义。没有统一时间基准，就无法可靠判断AI结果是否新鲜，也无法把一次截止期违约定位到采集、排队、推理还是通信阶段。
## 8 故障隔离、安全降级与恢复
### 8.1 控制权归属
面向安全相关控制，建议把最终执行器控制权、超时判定和降级状态机保留在RTOS/安全域。Linux/AI域提供建议值、目标值或感知结果，而不是未经校验直接驱动执行器。已有面向AI实时信息物理系统的研究在异构平台上采用Linux承载AI、FreeRTOS承载安全功能，并通过共享内存通道、健康监视和结果新鲜度校验实现故障兜底[23]，这与本课题方向高度一致。
### 8.2 需要覆盖的故障模型
至少应包含：
- Linux用户进程崩溃、内核卡死或重启；
- NPU驱动超时、固件异常、队列停滞；
- 跨域消息丢失、乱序、重复、损坏和版本不匹配；
- AI结果低置信、越界、过期或持续不可用；
- DMA越界、设备复位影响其他域；
- 内存或互连过载导致控制任务长尾；
- 温度过高、降频和电源预算收缩；
- RTOS健康监测本身失效或误判。
### 8.3 标准语境
ISO 26262面向道路车辆功能安全[24]，ISO 21448关注预期功能安全及感知、算法能力不足等非故障风险[25]，ISO/PAS 8800进一步聚焦道路车辆AI安全[26]。三者关注点不同：软件或硬件故障、功能性能局限、AI特有不足不能混为一类。若本课题面向工业或其他领域，也应映射到相应功能安全标准，而不是直接宣称符合汽车标准。
AUTOSAR Adaptive Platform为高性能ECU提供了面向服务的软件架构和执行管理机制[27]。这类行业框架有助于定义进程生命周期和接口，但系统确定性仍取决于底层调度、资源隔离、设备路径和具体部署配置。
### 8.4 降级与恢复语义
完整的兜底机制应定义以下状态：
`正常协同 → AI结果异常/超时 → 降级控制 → 故障隔离 → 服务恢复验证 → 受控重新接入`
其中，“Linux已重启”不等于“AI可以重新参与控制”。重新接入至少需要完成模型版本校验、通道清空、连续健康样本确认、时间同步检查和状态重建。恢复期间应继续由RTOS维持安全控制策略。
## 9 国内外研究进展综合
### 9.1 国外研究脉络
国外研究大致形成四条相互衔接的路线：
1. **混合关键度调度理论：** 从不同关键等级任务的执行时间假设和模式切换出发，研究可调度性与服务降级[1][2]；
2. **分区与虚拟化：** 通过Jailhouse、Bao、Xen、ACRN、seL4等降低操作系统之间的直接耦合[7]-[12]；
3. **共享资源分析：** 从内存带宽监管、DRAM bank划分、并行请求分析和gang调度等角度控制多核干扰[13]-[16]；
4. **AI与加速器实时化：** 从GPU调度逐步扩展到DNN负载、异构平台协同和AI故障兜底[17]-[19][23]。
总体趋势是由“降低虚拟化开销”转向“给出系统级时间与故障证据”，评价对象也从单次VM退出或IPC时延扩展到端到端控制链。
### 9.2 国内公开研究与工程实践
国内公开成果在混合双操作系统通信、嵌入式虚拟化和国产实时操作系统工程适配方面已有积累。例如，面向TrustZone的混合双操作系统实时RPC研究关注了跨域通信中的优先级与可预测性[20]；湖南大学嵌入式与网络计算实验室公开的ZVM项目面向嵌入式多核平台提供虚拟化研究与原型基础[28]。同时，国产RTOS和行业SoC生态为本土化验证提供了工程条件。
但从公开、可复现证据看，仍缺少把国产SoC、国产RTOS、Linux、NPU运行时和完整闭环控制统一起来的基准套件；尤其缺少共享NPU/DDR压力下的截止期数据、跨域故障注入记录和可复用安全降级协议。因此，国内工程适配不应只停留在“系统成功启动、域间能够通信”，而应转向边界测量和证据固化。
### 9.3 代表性研究对比
| 研究/项目 | 主要对象 | 核心贡献 | 对本课题的启示 | 主要局限 |
|---|---|---|---|---|
| Vestal[1] | 混合关键任务 | 建立不同保证等级执行时间模型 | 明确控制域与AI域保证等级 | 未覆盖现代异构加速器 |
| PREEMPT_RT[3] | 实时Linux | 降低Linux内核不可抢占延迟 | 可作为低成本基线 | 不提供完整空间/故障隔离 |
| Jailhouse[7] | 静态分区 | Linux辅助建立硬件分区 | 工程集成路径清晰 | 共享资源仍需单独治理 |
| Bao[8] | 轻量Hypervisor | 面向嵌入式多核的静态分区 | 适合研究小型可信基 | 设备生态和平台适配成本较高 |
| seL4[12] | 高保证微内核 | 提供形式化内核正确性证据 | 支持高可信隔离证据链 | 不覆盖整机时序与AI栈 |
| MemGuard/PALLOC[13][14] | DRAM干扰 | 带宽监管与bank感知分配 | 建立内存预算与隔离基线 | 需适配具体内存控制器 |
| RT-Gang[16] | 多核/DNN负载 | 限制关键并行任务间干扰 | 适合AI与控制共存实验 | 可能降低总体吞吐 |
| GPUart/GCAPS[17][19] | GPU实时调度 | 抢占、优先级与可分析调度 | 为NPU治理提供方法参照 | GPU机制不能直接移植到封闭NPU |
| RTRG-RPC[20] | 双OS通信 | 跨域RPC及优先级协同 | 通信协议必须携带实时语义 | 仍需结合共享资源分析 |
| Cittadini等[23] | AI+RTOS+Hypervisor | 健康监测、新鲜度验证和兜底 | 与本课题体系结构高度对应 | 平台与应用特定，需跨平台复现 |
## 10 现有研究的主要不足
### 10.1 证据链条分散
Hypervisor论文常强调隔离和切换开销，实时调度论文关注任务响应时间，AI系统论文关注吞吐和准确率，安全研究关注风险与降级。这些证据通常来自不同平台、负载和测量口径，尚未自然组合成“传感输入到执行器输出”的完整论证。
### 10.2 NPU运行时缺乏可分析接口
相较CPU和部分GPU，边侧NPU的队列策略、固件执行、抢占粒度和内部内存流量往往不公开。这使传统WCET分析难以直接应用，也容易造成“推理平均值稳定、极端情况下却阻塞控制域”的风险。
### 10.3 跨域优先级与新鲜度缺乏统一语义
一个高优先级RTOS任务发出的请求，进入Linux驱动、NPU队列和回传通道后可能丢失原有优先级；即使及时返回，也可能对应已经过期的传感帧。现有IPC性能测试往往只测往返时间，未同时验证数据年龄、版本和接收端可用性。
### 10.4 动态治理与可认证性存在张力
动态调整核、带宽和加速器配额可以提高平均利用率，但增加了状态空间和时序分析复杂度。如何在不破坏高关键域保证的前提下，让AI域使用剩余资源，是系统设计中的关键权衡。
### 10.5 故障恢复研究弱于故障检测
许多系统能够检测Linux或AI任务异常，但对清理旧消息、重建共享状态、验证模型版本和安全重新接入缺少明确协议。若恢复路径未被测试，其风险可能高于直接维持降级模式。
## 11 面向子课题B的研究框架
### 11.1 建议体系结构
本课题宜采用“RTOS掌握控制权、Linux承载智能栈、Hypervisor实施静态隔离、共享内存执行有界通信”的主线：
```text
传感器 ──> RTOS/安全域 ──> 基础控制与执行器
│
├─ 有界输入通道 ─> Linux/AI域 ─> NPU/GPU
│ │
└─ 新鲜度/完整性校验 <── 有界结果通道
Hypervisor：CPU核、内存、设备、中断和通信区域静态划分
资源监测器：DDR、DMA、加速器队列、温度、截止期与故障状态
```
RTOS不等待AI结果完成才推进控制周期；当AI结果有效时，可用于修正目标、估计状态或优化控制参数；当结果超时、异常或不可用时，立即保持基础控制或切换到预定义安全策略。
### 11.2 建议研究问题
| 编号 | 研究问题 | 可验证假设 |
|---|---|---|
| RQ1 | 静态分区能否显著降低Linux负载对控制任务的影响？ | 核、内存和设备划分后，控制时延长尾下降，但DDR/DMA压力下仍存在残余干扰 |
| RQ2 | 哪些共享资源是目标SoC的主要瓶颈？ | 干扰贡献与工作负载类型有关，可由硬件计数器、带宽和时延联合识别 |
| RQ3 | AI输出怎样在控制域中安全使用？ | 带时间戳、版本、置信度和有效期的有界协议可消除旧结果误用 |
| RQ4 | Linux/NPU故障是否会突破控制实时边界？ | 执行器归RTOS所有且通道非阻塞时，AI域故障可被限制在预设恢复时间内 |
| RQ5 | 资源治理的性能代价是多少？ | 合理配额可换取长尾稳定性，但存在吞吐—确定性折中曲线 |
### 11.3 建议实验矩阵
实验应至少设置四类对照：
1. 普通Linux；
2. Linux + PREEMPT_RT；
3. Linux/RTOS共存但不启用完整资源治理；
4. 静态分区Hypervisor + RTOS控制域 + Linux智能域 + 资源治理与兜底机制。
每类系统分别施加以下压力：
- CPU计算压力；
- LLC/DRAM带宽压力；
- 摄像头、网络、存储和DMA并发；
- 多模型或多流NPU/GPU推理；
- 高温、降频和长时运行；
- Linux崩溃、AI进程退出、NPU超时、消息损坏与通信中断。
### 11.4 建议评价指标
| 维度 | 核心指标 |
|---|---|
| 控制实时性 | 周期抖动、响应时间分布、观测最大值、截止期违约率、最长连续违约 |
| AI时效性 | 输入年龄、队列等待、推理时延、端到端时延、有效结果率、过期丢弃率 |
| 资源隔离 | DDR带宽、LLC未命中、DMA流量、加速器队列深度、干扰放大系数 |
| 通信 | 单向/往返时延、抖动、丢包/覆盖、队列水位、时钟偏差 |
| 故障安全 | 检测时间、隔离时间、降级切换时间、安全状态保持率、受控恢复时间 |
| 功耗热 | 功耗、温度、频率状态、热稳态前后时延变化 |
| 控制品质 | 超调量、稳态误差、整定时间、轨迹误差或任务特定安全指标 |
实验报告必须同时记录硬件型号、内核和RTOS版本、Hypervisor提交、固件/驱动、模型哈希、编译参数、频率策略、环境温度、负载脚本和原始日志。否则，所谓“实时改善”难以复现和比较。
### 11.5 预期创新点
结合现有研究空白，子课题B可把创新集中在以下四点：
1. **系统级实时边界模型：** 将控制响应时间与AI结果新鲜度放在同一端到端链路中分析；
2. **异构共享资源预算：** 建立CPU、DDR、DMA、NPU/GPU及温度干扰的测量与预算方法；
3. **跨域安全数据契约：** 形成包含时间戳、版本、置信度、有效期和恢复代次的有界协议；
4. **故障注入与证据闭环：** 通过Linux/NPU/通信故障注入验证降级、隔离和重新接入，而非只验证正常路径。
## 12 结论
边侧异构SoC上的混合实时控制不是单一操作系统、单一Hypervisor或单一调度算法可以独立解决的问题。PREEMPT_RT、双内核、AMP、静态分区和高保证微内核各有适用范围；核与内存静态划分能够减少直接干扰，却不能自动消除共享缓存、DRAM、DMA、加速器和热约束带来的长尾。AI任务的评价也必须从平均吞吐转向结果新鲜度、连续违约和故障条件下的可用性。
对本课题而言，最稳妥的研究主线是：把执行器控制权和降级状态机固定在RTOS域，把复杂AI生态放在Linux域，用Hypervisor和硬件机制建立资源边界，用有界通信协议传递可校验的AI结果，并通过混合压力与故障注入形成系统级证据。最终成果不应只是“Linux与RTOS可以同时运行”，而应回答在何种资源预算、负载和故障条件下，控制截止期仍可维持、AI结果仍可使用、系统仍可安全降级。
## 参考文献
[1] VESTAL S. Preemptive Scheduling of Multi-criticality Systems with Varying Degrees of Execution Time Assurance[C]//Proceedings of the 28th IEEE International Real-Time Systems Symposium. 2007: 239-243. DOI: [10.1109/RTSS.2007.47](https://doi.org/10.1109/RTSS.2007.47).
[2] BURNS A, DAVIS R I. A Survey of Research into Mixed Criticality Systems[J]. ACM Computing Surveys, 2018, 50(6). DOI: [10.1145/3131347](https://doi.org/10.1145/3131347).
[3] THE LINUX KERNEL DOCUMENTATION. Real-time preemption[EB/OL]. [2026-09-28]. [https://www.kernel.org/doc/html/latest/core-api/real-time/index.html](https://www.kernel.org/doc/html/latest/core-api/real-time/index.html).
[4] XENOMAI PROJECT. Xenomai 3 Overview[EB/OL]. [2026-09-28]. [https://v3.xenomai.org/overview/](https://v3.xenomai.org/overview/).
[5] OPENAMP PROJECT. OpenAMP Overview[EB/OL]. [2026-09-28]. [https://openamp.readthedocs.io/en/latest/openamp/overview.html](https://openamp.readthedocs.io/en/latest/openamp/overview.html).
[6] THE LINUX KERNEL DOCUMENTATION. Remote Processor Messaging (rpmsg) Framework[EB/OL]. [2026-09-28]. [https://www.kernel.org/doc/html/latest/staging/rpmsg.html](https://www.kernel.org/doc/html/latest/staging/rpmsg.html).
[7] RAMSAUER R, KISZKA J, LOHMANN W, et al. Look Mum, no VM Exits! (Almost)[EB/OL]. 2017. [https://arxiv.org/abs/1705.06932](https://arxiv.org/abs/1705.06932).
[8] MARTINS J, TAVARES A, SOLIERI M, BERTOGNA M, PINTO S. Bao: A Lightweight Static Partitioning Hypervisor for Modern Multi-Core Embedded Systems[C]//Next Generation Real-Time Embedded Systems. 2020. DOI: [10.4230/OASIcs.NG-RES.2020.3](https://doi.org/10.4230/OASIcs.NG-RES.2020.3).
[9] XEN PROJECT. True Static Partitioning with Xen Dom0-less[EB/OL]. [2026-09-28]. [https://xenproject.org/blog/true-static-partitioning-with-xen-dom0-less/](https://xenproject.org/blog/true-static-partitioning-with-xen-dom0-less/).
[10] LI S, KWEON S, YANG X, et al. ACRN: A Big Little Hypervisor for IoT Development[C]//Proceedings of the 15th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. 2019. DOI: [10.1145/3313808.3313816](https://doi.org/10.1145/3313808.3313816).
[11] MARTINS J, PINTO S. Shedding Light on Static Partitioning Hypervisors for Arm-based Mixed-Criticality Systems[C]//2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium. 2023. DOI: [10.1109/RTAS58335.2023.00011](https://doi.org/10.1109/RTAS58335.2023.00011).
[12] KLEIN G, ELPHINSTONE K, HEISER G, et al. seL4: Formal Verification of an OS Kernel[C]//Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles. 2009. DOI: [10.1145/1629575.1629596](https://doi.org/10.1145/1629575.1629596).
[13] YUN H, YAO G, PELLIZZONI R, et al. MemGuard: Memory Bandwidth Reservation System for Efficient Performance Isolation in Multi-core Platforms[C]//2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium. 2013. DOI: [10.1109/RTAS.2013.6531079](https://doi.org/10.1109/RTAS.2013.6531079).
[14] YUN H, MANCUSO R, WU Z P, PELLIZZONI R. PALLOC: DRAM Bank-Aware Memory Allocator for Performance Isolation on Multicore Platforms[C]//2014 IEEE 20th Real-Time and Embedded Technology and Applications Symposium. 2014. DOI: [10.1109/RTAS.2014.6925999](https://doi.org/10.1109/RTAS.2014.6925999).
[15] YUN H, PELLIZZONI R, VALSAN P K. Parallelism-Aware Memory Interference Delay Analysis for COTS Multicore Systems[C]//27th Euromicro Conference on Real-Time Systems. 2015: 184-195. DOI: [10.1109/ECRTS.2015.24](https://doi.org/10.1109/ECRTS.2015.24).
[16] ALI W, YUN H. RT-Gang: Real-Time Gang Scheduling Framework for Safety-Critical Systems[C]//2019 IEEE Real-Time and Embedded Technology and Applications Symposium. 2019. DOI: [10.1109/RTAS.2019.00020](https://doi.org/10.1109/RTAS.2019.00020).
[17] HARTMANN C, MARGULL U. GPUart: An Application-Based Limited Preemptive GPU Real-Time Scheduler for Embedded Systems[J]. Journal of Systems Architecture, 2019, 97: 304-319. DOI: [10.1016/j.sysarc.2018.10.005](https://doi.org/10.1016/j.sysarc.2018.10.005).
[18] KIM H, PATEL P, WANG S, RAJKUMAR R. A Server-Based Approach for Predictable GPU Access with Improved Analysis[J]. Journal of Systems Architecture, 2018, 88: 97-109. DOI: [10.1016/j.sysarc.2018.05.003](https://doi.org/10.1016/j.sysarc.2018.05.003).
[19] WANG Y, LIU C, WONG D, KIM H. GCAPS: GPU Context-Aware Preemptive Priority-Based Scheduling for Real-Time Tasks[C]//36th Euromicro Conference on Real-Time Systems. 2024. DOI: [10.4230/LIPIcs.ECRTS.2024.14](https://doi.org/10.4230/LIPIcs.ECRTS.2024.14).
[20] DONG P, JIANG Z, BURNS A, DING Y, MA J. Build Real-Time Communication for Hybrid Dual-OS System[J]. Journal of Systems Architecture, 2020, 107: 101774. DOI: [10.1016/j.sysarc.2020.101774](https://doi.org/10.1016/j.sysarc.2020.101774).
[21] OBJECT MANAGEMENT GROUP. Data Distribution Service Specification[EB/OL]. [2026-09-28]. [https://www.omg.org/spec/DDS/](https://www.omg.org/spec/DDS/).
[22] IEEE 802.1 TIME-SENSITIVE NETWORKING TASK GROUP. Time-Sensitive Networking[EB/OL]. [2026-09-28]. [https://1.ieee802.org/tsn/](https://1.ieee802.org/tsn/).
[23] CITTADINI E, MARINONI M, BIONDI A, CICERO G, BUTTAZZO G. Supporting AI-Powered Real-Time Cyber-Physical Systems on Heterogeneous Platforms via Hypervisor Technology[J]. Real-Time Systems, 2023, 59: 609-635. DOI: [10.1007/s11241-023-09402-4](https://doi.org/10.1007/s11241-023-09402-4).
[24] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 26262 Road Vehicles—Functional Safety[EB/OL]. [2026-09-28]. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html).
[25] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21448:2022 Road Vehicles—Safety of the Intended Functionality[EB/OL]. [2026-09-28]. [https://www.iso.org/standard/77490.html](https://www.iso.org/standard/77490.html).
[26] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/PAS 8800:2024 Road Vehicles—Safety and Artificial Intelligence[EB/OL]. [2026-09-28]. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html).
[27] AUTOSAR. Adaptive Platform[EB/OL]. [2026-09-28]. [https://www.autosar.org/standards/adaptive-platform/](https://www.autosar.org/standards/adaptive-platform/).
[28] 湖南大学嵌入式与网络计算实验室. ZVM嵌入式虚拟化项目[EB/OL]. [2026-09-28]. [https://esnl.hnu.edu.cn/zvm/](https://esnl.hnu.edu.cn/zvm/).
---
> 说明：本文中的公式、四维分析框架、建议体系结构、研究问题与实验矩阵，是在所引文献基础上针对子课题B形成的综合研究设计，不是对某一篇文献结论的直接复述。
03-主流异构边侧设备与AI模型性能指标综述.md
+278
View File
@@ -0,0 +1,278 @@
# 主流异构边侧设备与AI模型性能指标综述
## 摘要
边侧智能控制设备正从单一CPU或GPU计算平台，演进为同时集成应用核、实时核、GPU、NPU/DLA、DSP、ISP、FPGA可编程逻辑和多类I/O加速单元的异构系统。对这类平台进行选型时，仅比较TOPS会遮蔽模型精度、权重体积、算子落点、内存带宽、运行时回退、队列等待、功耗模式和尾时延等关键差异。本文结合前期《面向边侧异构SoC的混合实时控制基础系统研究综述》和《工程应用场景与性能指标对标》，对NVIDIA Jetson Orin、Rockchip RK3588、TI TDA4VM、NXP i.MX 8M Plus、Qualcomm QRB5165/RB5、Hailo-8和AMD Kria K26等代表性设备的计算组成、标称算力、存储资源、功耗与推理软件栈进行对比；同时以MobileNetV3、YOLOv8、Octo、OpenVLA及边缘VLA工作负载为例，分析参数量、权重精度、训练/任务精度、量化损失、推理时间和端到端控制频率之间的关系。本文进一步给出面向子课题B的统一报告模板和分层实验矩阵，使“峰值算力—模型质量—平均性能—尾时延—控制安全”能在同一证据链中进行审查。
**关键词：** 异构SoC；边缘AI；模型权重；混合精度；量化；推理时延；尾延迟；具身智能；混合实时系统
---
## 1 研究对象及与前两篇综述的关系
前期国内外研究综述主要回答“Linux、RTOS、Hypervisor和AI加速器如何共存”，并将研究重点放在资源隔离、共享资源干扰、跨域通信和安全降级上。工程应用场景文档主要回答“这些问题在人形/四足机器人、移动操作、巡检和EtherCAT控制中如何落地”。
本文作为第三篇独立综述，聚焦于二者之间尚缺的“设备—模型—运行时—实时指标”对应关系：
1. 设备端具有哪些异构计算单元，其标称算力和存储资源是多少；
2. 模型的参数量、权重位宽、活化值和中间缓冲如何占用内存；
3. “训练精度”、“数值精度”和“任务准确率”应如何区分；
4. 推理时间究竟是纯硬件执行、运行时API返回，还是传感器到执行器的端到端时间；
5. 平均FPS很高的平台，在AI、DMA、网络和存储并发时是否仍能维持控制周期的P99.9和观测最大值。
因此，本文中的数据不用于简单给出设备排名，而用于建立实验选型和结果解释的基准。
## 2 性能指标的统一语义
### 2.1 峰值算力不等于模型性能
TOPS通常表示每秒可执行的万亿次基本操作，但其数值受计数方式、数据精度和稀疏性假设影响。例如Jetson Orin官方表格中的整体AI性能明确标为稀疏INT8 TOPS，而同页又另列GPU Tensor Core的稠密INT8性能[1]。因此，不能直接把某厂商的稀疏INT8 TOPS与另一厂商的稠密INT8、FP16 TFLOPS或可配置DPU单元数进行比例换算。
对任一实际模型，性能还取决于：
- 算子是否全部被加速器支持，是否回退到CPU/GPU；
- 张量排布转换、量化/反量化和外部算子的开销；
- 权重、活化值和特征图是否受内存带宽限制；
- 动态形状、batch大小、多流和多模型并发方式；
- 功耗档位、频率锁定、温度以及热降频状态；
- 运行时、编译器、驱动、固件和模型编译产物版本。
### 2.2 模型权重与内存占用
若模型参数量为\(N_p\)，每个权重位宽为\(b\)，则仅权重的理论容量为：
\[
S_{weight}=N_p\times b/8
\]
例如7B参数模型的理论权重容量约为：FP32 28 GB、FP16/BF16 14 GB、INT8 7 GB、INT4 3.5 GB。这些数字不包括视觉编码临时张量、KV cache、活化值、量化尺度/零点、运行时工作区、图优化副本及I/O缓冲。因此，“权重能放入内存”不等于“模型能稳定运行”。
本课题建议分开报告五个内存量：原始模型文件、编译后引擎/私有格式、常驻权重、峰值活化与工作区、进程峰值常驻内存（RSS）或设备内存峰值。
### 2.3 “精度”需要区分三种含义
| 精度类型 | 常见取值 | 它回答的问题 | 必须同时记录的信息 |
|---|---|---|---|
| 训练数值精度 | FP32、FP16、BF16、混合精度 | 梯度、权重更新和前/反向计算用什么数值格式 | 优化器、loss scaling、训练硬件、时长、数据集版本 |
| 部署/推理精度 | FP32、FP16/BF16、INT8、INT4、W4A16等 | 权重和活化值如何存储与计算 | PTQ或QAT、校准集、逐张量/逐通道、对称/非对称 |
| 任务质量 | Top-1/Top-5、mAP、mIoU、WER、任务成功率 | 模型完成实际任务的质量 | 数据集、划分、输入尺寸、评估脚本、随机种子、置信区间 |
用户所说的“训练精度”在工程文档中经常同时指数值精度和准确率。本文统一将二者分写为“训练/部署位宽”和“任务质量”，避免把“INT8”误读为“80%准确率”。
### 2.4 推理时间的五层口径
| 层级 | 延迟定义 | 包含内容 | 主要用途 |
|---|---|---|---|
| L0 | 算子/核函数时间 | 单个算子或融合核执行 | 算子库与瓶颈分析 |
| L1 | 设备执行时间 | 加速器从接受到完成图执行 | 比较编译产物和计算核 |
| L2 | 运行时推理时间 | API调用、提交、排队、同步和图执行 | 单模型部署基准 |
| L3 | 应用流水线时间 | 预处理+推理+后处理+主机/设备搬运 | 视觉或多模态应用评价 |
| L4 | 端到端控制时间 | 采集、队列、预处理、推理、IPC、校验、控制与执行提交 | 本课题的最终验收口径 |
FPS或samples/s表示吞吐率，\(1/FPS\)只能在batch=1、没有流水重叠且测量口径一致时近似单请求时间。对实时控制，应同时报告P50、P95、P99、P99.9、观测最大值、截止期违约率和连续违约长度，不应只报平均值。
## 3 代表性异构边侧设备指标
### 3.1 设备横向对比
表1使用2026年9月前公开的厂商一手资料。“未给出”表示引用的官方页面没有给出可直接比较的数值，而不表示设备没有功耗或存储限制。
| 平台/芯片 | 异构计算组成 | 官方标称AI性能 | 内存/带宽 | 官方功耗口径 | 典型软件路径 | 对本课题的主要价值 |
|---|---|---:|---|---|---|---|
| Jetson Orin Nano 8GB | 6核Cortex-A78AE + 512核Ampere GPU/16 Tensor Cores | 最高67稀疏INT8 TOPS | 8 GB LPDDR5，约102 GB/s | 7–25 W | Linux/JetPack + CUDA/TensorRT/ONNX Runtime/Isaac ROS | 低成本具身智能与视觉基线；没有独立DLA[1] |
| Jetson Orin NX 16GB | 8核Cortex-A78AE + 1024核Ampere GPU/32 Tensor Cores + 2个NVDLA | 最高157稀疏INT8 TOPS | 16 GB LPDDR5，102.4 GB/s | 10–40 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 适合VLA、多视觉流和异构调度；也是当前机器人开发中常见的档位[1] |
| Jetson AGX Orin 64GB | 12核Cortex-A78AE + 2048核Ampere GPU/64 Tensor Cores + 2个NVDLA + PVA | 最高275稀疏INT8 TOPS | 64 GB LPDDR5，204.8 GB/s | 15–60 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 多模型、多传感器和大模型本地推理基线[1][2] |
| Rockchip RK3588 | 4×Cortex-A76 + 4×Cortex-A55 + Mali-G610 MP4 + 三核NPU + 低功耗MCU | 6 INT8 TOPS；数据手册还列出INT4/INT16/FP16/BF16/TF32支持 | 64-bit LPDDR4/4X/5；额定容量与带宽取决于板级实现 | 未给出统一模块档位 | Linux/Android + RKNN Toolkit2/RKNN Runtime | 低成本NPU和多核CPU/GPU/NPU共存对照；官方模型库提供多模型FPS[3][4] |
| TI TDA4VM | 2×Cortex-A72 + 6×Cortex-R5F + C7x DSP/MMA + 2×C66x DSP + GPU + ISP/VPAC/DMPAC | MMA最高8 INT8 TOPS | 随具体型号和板级设计确定 | 官方产品页未给出统一整机值 | Linux/QNX/FreeRTOS等 + TIDL | 应用核、多实时核、DSP与AI加速器高度集成，非常适合研究“Linux+RTOS+硬件隔离”[5] |
| NXP i.MX 8M Plus | 2/4×Cortex-A53 + Cortex-M7 + NPU + HiFi 4 DSP + GPU + 双ISP | 最高2.3 TOPS | LPDDR4/DDR4，支持内联ECC；容量取决于型号和板级实现 | 未给出统一整机值 | Linux + FreeRTOS + eIQ/TFLite/ONNX生态 | 算力不高但实时核、TSN/CAN FD和工业接口完整，适合中小模型+实时控制[6][7] |
| Qualcomm QRB5165/RB5 | 4高性能+4低功耗Kryo 585 + Adreno 650 + Hexagon 698/HTA/HVX + EVA/ISP | AI Engine最高15 TOPS | 开发套件配置与商用SoM不同，需按BOM冻结 | 官方页未给出统一整机值 | Linux/Ubuntu/ROS 2 + QAIRT/QNN/HTP | 强ISP、DSP、NPU和连接性，适合机器人、无人机和多相机异构流水线[8] |
| Hailo-8（加速器） | 数据流AI处理器，需外部主机 | 26 TOPS | 芯片设计不需外部存储器；系统总内存仍由主机和流水线决定 | 官方典型值2.5 W | Host Linux + Hailo Dataflow Compiler + HailoRT/HEF | 适合研究外挂NPU、PCIe搬运、设备队列与主机控制任务之间的干扰[9] |
| AMD Kria K26 | 4×Cortex-A53 + 2×Cortex-R5F + Mali-400 + 25.6万逻辑单元/1248 DSP的可编程逻辑 | 取决于DPU或自定义数据通路配置，不宜以固定TOPS与NPU比较 | 4 GB 64-bit DDR4，2400 Mb/s；26.6 Mb片上存储 | 取决于PL设计与载板 | Linux/FreeRTOS + Vitis AI/自定义PL加速 | 可把关键预处理、时间触发或自定义推理流水线硬件化，适合确定性对照[10][11] |
上表表明，主流设备并不是同一类产品。Jetson强调GPU生态、统一内存与大模型兼容性；RK3588强调成本与多媒体NPU；TDA4VM、i.MX 8M Plus和Kria更容易形成应用域与实时域的硬件分工；QRB5165具有移动SoC的能效、感知和连接优势；Hailo-8则是主机外挂专用加速器。子课题B的“混合实时”研究应关注这些架构差异如何影响隔离和尾时延，而不是只寻找TOPS最大的设备。
### 3.2 主要推理架构和编译链
| 类型 | 典型数据路径 | 优势 | 与实时性相关的风险 |
|---|---|---|---|
| GPU/Tensor Core | PyTorch/ONNX → TensorRT engine → CUDA stream → GPU | 算子覆盖广，支持FP32/FP16/BF16/FP8/INT8/INT4/FP4等混合精度，易部署Transformer[12] | 核函数不可抢占区间、多流排队、显存/统一内存竞争和热降频 |
| 固定功能NPU/DLA | ONNX/TFLite → 厂商编译器 → 私有图/二进制 → NPU Runtime | INT8能效高，适合固定视觉网络 | 算子不支持时可切图或回退CPU；固件队列和抢占能力不透明 |
| DSP/HTP/MMA | 模型编译 → DSP/向量核+矩阵加速器 | 视觉、信号处理和AI可在相同子系统内融合 | 多核共享内存、任务图与数据搬运配置复杂 |
| 数据流NPU | 模型 → 结构映射/编译 → HEF等产物 → 流式执行 | 视觉模型吞吐和能效高 | 主机预/后处理、PCIe或M.2传输和多流调度仍会影响端到端时间 |
| FPGA/可编程逻辑 | 模型或自定义算子 → HLS/RTL/DPU → PL流水线 | 可定制I/O、并行度和固定数据路径，便于硬件时间触发 | 编译时间长，可用算子和量化方案受配置限制，更改模型需重新生成硬件产物 |
这些运行时并不直接对应操作系统的实时优先级。即使提交线程在Linux中设置了高优先级，设备内部已排队任务、固件命令批次和内存控制器仍可能不可抢占。因此需要以时间戳区分“主机提交—设备开始—设备完成—结果可用”四个时刻。
## 4 代表性模型的权重、质量与计算规模
### 4.1 从轻量视觉到具身大模型
表2中的权重容量按参数量与位宽计算，是方便选型的理论值，不代表文件大小或运行时峰值内存。
| 模型 | 任务/架构 | 参数与计算 | 理论权重容量 | 公开任务质量/训练信息 | 对边侧部署的含义 |
|---|---|---|---|---|---|
| MobileNetV3-Large 1.0 | ImageNet分类，移动CNN | 5.4M参数，219M MAdds | FP32 21.6 MB；FP16 10.8 MB；INT8 5.4 MB | ImageNet Top-1 75.2%[13] | 适合作为算子覆盖和量化基线，但不能代表检测、分割或VLA |
| YOLOv8n | COCO目标检测，单阶段CNN | 3.2M参数，约8.74 GOP（Hailo口径） | FP32 12.8 MB；FP16 6.4 MB；INT8 3.2 MB | Hailo模型库报告float mAP 37.0、设备mAP 36.4[14] | 适合低延迟感知和量化损失对照 |
| YOLOv8s | COCO目标检测 | 11.2M参数，约28.6 GOP | FP32 44.8 MB；FP16 22.4 MB；INT8 11.2 MB | float mAP 44.6、Hailo设备mAP 43.9[14] | 与YOLOv8n组成同系列精度—延迟折中实验 |
| Octo-Small/Base | 通用机器人策略，Transformer+动作头 | 27M/93M参数 | FP16约54/186 MB；INT8约27/93 MB | 使用约80万条机器人轨迹；官方仓库报告RTX 4090上约17/13 it/s[15] | 模型可放入边侧内存，但4090结果不能代替边侧实测；任务质量应以机器人成功率报告 |
| OpenVLA-7B | 视觉—语言—动作，双视觉编码器+投影层+Llama 2 7B | 约7B参数 | FP16约14 GB；INT8约7 GB；INT4约3.5 GB | 97万条真实机器人演示；64块A100训练15天；论文报告其在29项任务上较RT-2-X绝对成功率高16.5个百分点[16][17] | 量化后权重可能放入8–16 GB设备，但活化值、视觉编码和上下文仍可造成显著内存及延迟压力 |
| LiteVLA-Edge实验管线 | 边缘多模态控制，ROS 2 + llama.cpp | 论文采用FP32监督微调后4-bit GGUF量化 | 依具体基座模型而定 | Jetson Orin类平台上报告平均端到端时延150.5 ms，约6.6 Hz[18] | 说明“可运行”与“可高频闭环”差距巨大；需用异步动作块、过期拒绝和RTOS底层控制弥补 |
上述数据还显示，“准确率”不能在不同任务之间直接比较。75.2% ImageNet Top-1、44.6 COCO mAP和机器人任务成功率属于不同评价对象。对具身智能，最终应报告分任务成功率、碰撞/越界次数、完成时间和对延迟扰动的敏感性，不能只使用离线感知指标。
### 4.2 公开设备推理数据示例
下表故意保留了各官方模型库的测试口径，不将它们包装成严格跨平台排名。倒数时间仅为\(1000/FPS\)的理想化换算，不是P99或端到端延迟。
| 设备/来源 | 模型与输入 | 精度 | 公开吞吐 | 理想化倒数时间 | 测试条件与解读 |
|---|---|---|---:|---:|---|
| RK3588官方RKNN Model Zoo | MobileNetV2，1×3×224×224 | INT8 | 450.7 FPS | 2.22 ms | 官方表格标注RK3588 NPU单核，适合作图执行吞吐基线[4] |
| RK3588官方RKNN Model Zoo | ResNet50-v2，1×3×224×224 | INT8 | 110.1 FPS | 9.08 ms | 同上[4] |
| RK3588官方RKNN Model Zoo | YOLOv8n/s/m，1×3×640×640 | INT8 | 73.5/38.0/16.2 FPS | 13.61/26.32/61.73 ms | 同系列随模型规模增大出现清晰延迟梯度[4] |
| Hailo-8官方Model Zoo | YOLOv8n/s/m/l，640×640 | 编译后硬件部署 | 1036/491/66.9/36.2 FPS | 0.97/2.04/14.95/27.62 ms | 官方表格的主机为i5-9400、PCIe Gen3×4、室温、batch=1；表内还分别报告float和硬件mAP[14] |
| Hailo-8官方CLI示例 | ResNet-50 | 编译后HEF | 1328.83 FPS | 不按倒数解读 | 同一输出报告硬件延迟2.936 ms和流式平均功耗3.194 W，说明流水吞吐与单请求延迟并非简单互为倒数[19] |
| Jetson Orin类设备/LiteVLA-Edge | 量化多模态控制管线 | 4-bit GGUF | 约6.6 Hz | 平均端到端150.5 ms | 包含ROS 2感知—推理—动作管线，与纯NPU图执行不是同一口径[18] |
对真正的跨设备比较，应优先使用MLPerf Inference Edge这类固定模型、数据集、质量门槛、负载生成器和场景规则的基准。MLCommons将Closed组用于尽可能同模型横向比较，Open组则允许更换模型或重训练[20]。即使如此，MLPerf的Offline/Server/SingleStream等场景仍不能替代本课题的RTOS控制并发和故障注入实验。
## 5 面向混合实时控制的指标体系
### 5.1 不应缺失的设备信息
每一组实验至少冻结：
- SoC/模组/开发板型号、内存容量和载板版本；
- OS、内核、RTOS、Hypervisor、BSP和固件版本；
- AI编译器、运行时、驱动和模型编译产物的哈希；
- 功耗模式、CPU/GPU/NPU/内存频率、锁频方式和散热条件；
- CPU亲和性、中断亲和性、内存区域、IOMMU、设备所有权和加速器并发度；
- 采集时长、样本数、预热时间、环境温度与稳态温度。
### 5.2 不应缺失的模型信息
- 模型名称、代码/权重提交号、输入尺寸、batch、序列长度和动态形状范围；
- 参数量、MACs/FLOPs/OPS口径和支持算子比例；
- 原始权重位宽、部署权重/活化位宽和混合精度列表；
- PTQ/QAT方式、校准数据集与样本数，是否采用稀疏性或剪枝；
- FP32/原始模型质量、编译后仿真质量和目标板实测质量；
- 编译失败、CPU回退、子图切分、张量转换和外部算子情况。
### 5.3 四类性能结果
| 类别 | 核心指标 | 解释要点 |
|---|---|---|
| 模型质量 | 原始质量、量化后质量、绝对/相对下降、分类别/分场景成功率 | 达不到冻结质量门槛时，性能再高也不进入实时比较 |
| 推理时序 | 冷启动、预热后P50/P95/P99/P99.9/最大值，吞吐、队列深度和超时率 | 分别记录L1–L4口径，避免用纯硬件FPS代替端到端时间 |
| 资源与能效 | CPU/GPU/NPU利用率、DDR带宽、LLC未命中、DMA、峰值内存、平均/峰值功耗、J/inference | 功耗必须注明是芯片、模组、加速卡还是整机口径 |
| 控制影响 | 控制周期偏差、截止期违约、AI结果年龄、过期丢弃率、降级与恢复时间 | 这是子课题B区别于通用AI硬件评测的最终指标 |
## 6 对子课题B的设备和模型选型建议
### 6.1 建议形成四类对照平台
1. **高AI生态主平台：Jetson Orin NX 16GB或AGX Orin。** 用于具身视觉、VLA、多模型并发和GPU/DLA异构分配，也便于与已有机器人应用资料衔接。
2. **集成实时域平台：TDA4VM或i.MX 8M Plus。** 用于对比应用核与R5F/M7实时核的硬件分工、共享内存通信和故障隔离。
3. **低成本NPU平台：RK3588。** 用于评价私有NPU编译、算子回退、单/多NPU核调度与Linux实时化的性价比。
4. **外挂或可编程加速平台：Hailo-8或Kria K26。** 用于研究PCIe/DMA搬运、主机队列、自定义数据通路和固定流水线的确定性。
若当前资源只允许购置一套平台，建议优先Orin NX 16GB，并外接一块运行RTOS的MCU或实时控制器建立可测的Linux AI域—RTOS控制域链路。若研究重心更偏向单芯片内的真正AMP和安全隔离，TDA4VM的A72+R5F+C7x/MMA结构更具代表性。
### 6.2 建议的模型负载梯度
| 梯度 | 建议模型 | 目的 |
|---|---|---|
| M0 算子微基准 | Conv2D、Depthwise Conv、GEMM、Attention、Resize、NMS | 建立算子时间、能耗和CPU回退数据库 |
| M1 轻量分类 | MobileNetV3-Large或MobileNetV2 | 验证编译链、INT8量化和最小延迟 |
| M2 实时检测 | YOLOv8n/s/m | 建立模型规模—质量—延迟—能耗曲线 |
| M3 语义/姿态任务 | DeepLabV3+、YOLOv8-Pose或项目自有模型 | 接近机器人对环境和人的感知负载 |
| M4 紧凑机器人策略 | Octo-Small/Base或等规模动作模型 | 评估视觉、语言/状态和动作生成管线 |
| M5 量化VLA | OpenVLA类7B或更小VLA的INT4版本 | 验证大权重、长时延、异步动作块和结果新鲜度策略 |
## 7 建议直接纳入课题的实验设计
### 7.1 E0：版本与配置冻结
生成设备BOM、软件版本、功耗/频率、核与中断分配、模型哈希、校准集哈希和编译参数清单。未完成E0的数据不进入横向对比。
### 7.2 E1：模型质量与内存账本
对每个模型依次测量FP32/FP16原始质量、PTQ INT8/INT4质量、必要时的QAT质量；统计模型文件、设备编译产物、常驻权重、峰值工作区和稳态/峰值RSS。质量下降超过任务门槛的精度方案不参加性能验收。
### 7.3 E2：单模型隔离推理
固定batch=1和输入，分别测试冷启动、预热后和热稳态。对L1、L2、L3时间分段打点，报告分位数、吞吐、功耗和能耗。对具有多NPU核、GPU+DLA或CPU+DSP+NPU的设备，对比单加速器、多加速器和多模型并发。
### 7.4 E3：控制域与AI域并发
设置0.5/1/2/10 ms等不同控制周期的仿真或实机任务，对比：
1. 仅控制任务；
2. 控制+单模型推理；
3. 控制+多视频流/多模型；
4. 控制+大模型/VLA长时推理；
5. 同负载下的普通Linux、PREEMPT_RT、AMP或静态分区方案。
主指标为控制周期P99.9/最大偏差、截止期违约、AI结果年龄和过期拒绝率。
### 7.5 E4：共享资源压力
逐项和联合注入CPU、LLC、DDR、DMA、摄像头/ISP、网络、NVMe、GPU/NPU和热负载，建立：
\[
资源干扰强度\rightarrow推理队列和尾时延\rightarrow控制周期偏差\rightarrow截止期/任务质量
\]
的因果记录。此实验应长时运行到热稳态，否则无法观测DVFS和热降频对长尾的影响。
### 7.6 E5：超时、故障和恢复
注入AI进程崩溃、设备超时、驱动队列停滞、消息丢失/乱序/重复、过期结果、Linux重启和温度降频。测量故障检测时间、RTOS降级切换时间、安全状态保持率、通道清理和受控重新接入时间。
## 8 综合讨论
### 8.1 关于“边端训练”
大多数异构边侧设备的主要任务是推理，并非从零训练大模型。OpenVLA的公开信息显示其预训练使用了64块A100、15天[17]，这与边侧SoC的功耗、内存和散热边界不在同一级别。边端更可行的路径是离线集中训练，边端进行小样本校准、LoRA/适配层微调、增量学习或模型选择。这些在线学习活动不应与高关键控制无界共享资源。
### 8.2 关于具身智能的多频率系统
具身智能中的VLA可能只能以6–20 Hz生成动作或动作块，而关节、平衡、力控和安全监测可能需要500 Hz–2 kHz甚至更高的周期。这不意味着VLA必须和伺服环同频，而意味着系统必须有明确的多频率协议：VLA只发布带时间戳、有效期、版本和置信度的有界目标/动作块；RTOS以高频率完成插值、限幅、状态估计、执行器控制和故障降级。
### 8.3 最有价值的研究指标
对本课题而言，最有价值的不是“将YOLO加速到多少FPS”，而是以下三类关系：
1. 在相同模型质量门槛下，不同设备/精度/运行时的L3和L4尾时延如何；
2. 在相同AI负载下，普通Linux、PREEMPT_RT、AMP和静态分区对控制周期P99.9和最大值的改善程度；
3. 当AI超时、过载或崩溃时，RTOS能否在已知时间内拒绝旧结果、进入降级并维持安全状态。
## 9 结论
当前主流异构边侧设备已形成GPU主导、集成NPU/DSP、应用核+实时核、外挂数据流加速器和FPGA可编程逻辑等多条技术路线。其公开算力横跨约2.3 TOPS到275稀疏INT8 TOPS，但TOPS口径、数值精度、稀疏性、算子覆盖、内存系统和运行时都不同，因而不能根据峰值数字直接预测模型FPS或端到端控制时闶。
在模型层面，MobileNet/YOLO类模型的权重仅为数MB至数十MB，而7B VLA即使INT4权重也约3.5 GB，其中间状态和端到端流水线还会显著增加内存与时间成本。量化的意义不只是减小文件，还要同时验证任务质量、算子映射、实际内存峰值和长尾时延。
因此，子课题B应将设备峰值参数作为入口，将模型质量作为准入门槛，将L1–L4时间分解和资源计量作为过程证据，最终以控制周期、AI结果新鲜度、过期拒绝、故障降级和恢复时间作为系统级结论。这样才能把“模型跑得动”提升为“智能与实时控制可在已知边界内共存”。
## 参考资料
1. NVIDIA. *Jetson AGX Orin for Next-Gen Robotics: Technical Specifications*. [官方产品与规格页](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/)，访问日期：2026-09-29。
2. NVIDIA. *Jetson AGX Orin Series Hardware Architecture*. [官方技术简报](https://www.nvidia.com/content/dam/en-zz/Solutions/gtcf21/jetson-orin/nvidia-jetson-agx-orin-technical-brief.pdf)。
3. Rockchip. *RK3588 Brief Datasheet*. [官方数据手册](https://www.rock-chips.com/uploads/pdf/2022.8.26/191/RK3588%20Brief%20Datasheet.pdf)。
4. Rockchip AI Team. *RKNN Model Zoo*. [官方代码仓库及性能表](https://github.com/airockchip/rknn_model_zoo/blob/main/README_CN.md)，访问日期：2026-09-29。
5. Texas Instruments. *TDA4VM SoC with Dual Arm Cortex-A72, 8 TOPS of AI, C7x DSP, and GPU*. [官方产品页](https://www.ti.com/product/TDA4VM)。
6. NXP. *i.MX 8M Plus: Cortex-A53/M7, Machine Learning, Vision, Multimedia and Industrial IoT*. [官方产品页](https://www.nxp.com/products/i.MX8MPLUS)。
7. NXP. *i.MX 8M Plus Applications Processor Family*. [官方产品手册](https://www.nxp.com/docs/en/brochure/IMX8SERAPPBR.pdf)。
8. Qualcomm. *Dragonwing QRB5165*. [官方产品页](https://www.qualcomm.com/internet-of-things/products/q5-series/qrb5165)。
9. Hailo. *Hailo-8 AI Processor Product Brief*. [官方产品简报](https://hailo.ai/wp-content/uploads/2023/10/hailo-8-product-brief-rev3.26.pdf)。
10. AMD. *Kria K26 SOM Data Sheet (DS987)*. [官方数据手册](https://docs.amd.com/r/en-US/ds987-k26-som)。
11. AMD. *Kria K26 SOM: The Ideal Platform for Vision AI at the Edge*. [官方白皮书](https://docs.amd.com/v/u/en-US/wp529-som-benchmarks)。
12. NVIDIA. *TensorRT Documentation*. [官方文档](https://docs.nvidia.com/deeplearning/tensorrt/latest/)。
13. HOWARD A, SANDLER M, CHU G, et al. Searching for MobileNetV3[EB/OL]. arXiv:1905.02244, 2019. [论文](https://arxiv.org/abs/1905.02244)。
14. Hailo AI. *Hailo Model Zoo: Hailo-8 Object Detection Models*. [官方模型指标与基准表](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/public_models/HAILO8/HAILO8_object_detection.rst)。
15. OCTO MODEL TEAM, GHOSH D, WALKE H, et al. Octo: An Open-Source Generalist Robot Policy[C]//Robotics: Science and Systems. 2024. [官方仓库与模型数据](https://github.com/octo-models/octo)。
16. KIM M J, PERTSCH K, KARAMCHETI S, et al. OpenVLA: An Open-Source Vision-Language-Action Model[EB/OL]. arXiv:2406.09246, 2024. [论文](https://arxiv.org/abs/2406.09246)。
17. OpenVLA Team. *OpenVLA Project Page*. [官方项目页](https://openvla.github.io/)。
18. WILLIAMS J, GUPTA K D, GEORGE R, et al. LiteVLA-Edge: Quantized On-Device Multimodal Control for Embedded Robotics[EB/OL]. arXiv:2603.03380, 2026. [论文](https://arxiv.org/abs/2603.03380)。
19. Hailo AI. *Hailo Model Zoo Benchmarks*. [官方基准复现说明](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/BENCHMARKS.rst)。
20. MLCommons. *MLPerf Inference: Edge*. [官方基准、场景与结果](https://mlcommons.org/benchmarks/inference-edge/)，访问日期：2026-09-29。