moyixin/rtos_llm_opt

Fork 0

forked from eaiadmin/rtos_llm_opt

Files

T

Mo1s b7863721fe docs: add alternative real-time research frameworks

2026-09-22 16:26:37 +08:00

10 KiB

Raw Permalink Blame History

RTOS + Linux + Hypervisor 边缘并行架构说明

1. 架构目标

边缘侧采用并行分域思路：RTOS 负责控制和安全关键路径，Linux 负责 AI 推理与复杂软件生态，Hypervisor 或等价静态分区层负责空间隔离、时间干扰控制和设备分配。

该架构不把“让 RTOS 原生运行全部大模型软件栈”作为前提。优化目标按优先级排序为：

控制闭环截止期不被推理负载破坏；
AI 结果在规定的新鲜度窗口内可用；
推理域故障不扩散到控制域；
在前三项满足后提高推理吞吐、能效和资源利用率。

2. 逻辑架构

┌─────────────────────────────────────────────────────────────┐
│                    边缘计算硬件                              │
│  CPU 核 / LLC / DRAM / 内存带宽 / NPU或GPU / I/O / 时钟     │
├─────────────────────────────────────────────────────────────┤
│        Hypervisor、静态分区器或具备等价能力的隔离层          │
│  vCPU/物理核分配、内存区间、IOMMU、设备直通、中断路由、监控  │
├───────────────────────────┬─────────────────────────────────┤
│ RTOS 控制域               │ Linux 推理域                    │
│ - 周期控制与联锁          │ - 模型加载与推理运行时          │
│ - 现场总线与关键传感器    │ - GPU/NPU 驱动与厂商 SDK        │
│ - 时间戳、结果校验        │ - 数据预处理与后处理            │
│ - 超时、降级与安全状态    │ - 模型更新、日志与网络服务      │
├───────────────────────────┴─────────────────────────────────┤
│ 有界跨域通道：共享内存环形队列 + 通知 / RPMsg / 虚拟设备等   │
└─────────────────────────────────────────────────────────────┘

这里的“Hypervisor”表示架构角色，不预设具体产品。若 SoC 已具备安全岛、独立 MCU、AMP 或硬件静态分区能力，只要能够提供可验证的资源和故障隔离，也可以作为实现路径。

3. 两个域的职责边界

3.1 RTOS 控制域

RTOS 域应拥有：

周期控制、联锁、执行器输出和关键状态采集；
控制任务使用的定时器、关键中断和关键 I/O；
AI 请求的采样时刻、任务编号、期望完成期限和优先级；
AI 结果的完整性、新鲜度、置信度和序列一致性检查；
超时、失联、异常结果和推理域重启时的回退控制；
必要的看门狗与推理域生命周期控制接口。

RTOS 域不应依赖 Linux 域才能维持基本安全状态。AI 可增强系统能力，但关键控制闭环应明确 AI 缺席时的可接受行为。

3.2 Linux 推理域

Linux 域应拥有：

模型文件、模型运行时和推理服务；
GPU/NPU/DLA 等加速器驱动及厂商 SDK；
复杂预处理、后处理、模型编排和批处理；
网络、存储、模型更新以及非关键日志服务；
推理资源的吞吐优化和域内调度。

Linux 域可以对 AI 服务做软实时优化，但不得把域内平均时延等同于控制系统的实时保证。

3.3 Hypervisor/分区层

隔离层需要明确而不是笼统声称以下能力：

CPU 核是静态独占、时间分片还是混合分配；
内存区域是否静态划分，是否存在共享页和动态气球机制；
LLC、内存带宽和互联是否可分配、限额或仅可观测；
加速器采用直通、复用还是由单一域独占；
设备 DMA 是否受 IOMMU 限制；
物理中断如何路由，是否会在控制核上产生额外虚拟化出口；
一个域崩溃、重启或过载时，另一域是否持续运行。

Hypervisor 本身也会引入 VM exit、虚拟中断和跨域通信开销，必须纳入实测，不能只把它视为零成本隔离层。

4. 跨域通信契约

推荐使用异步、有界、可丢弃的通信语义，避免 RTOS 控制任务同步等待 Linux 推理。

4.1 请求消息最小字段

字段	作用
`request_id`	区分请求和乱序结果
`sample_time`	标识传感数据的采样时刻
`deadline`	AI 结果最晚可用时刻
`priority/class`	区分任务重要性和推理策略
`payload_ref`	指向受控共享缓冲区或内联小数据
`schema/version`	防止两域版本不一致

4.2 结果消息最小字段

字段	作用
`request_id`	与请求配对
`model_version`	支撑审计和回滚
`finish_time`	计算跨域端到端时延
`confidence/status`	判断结果是否可用
`valid_until`	规定结果新鲜度边界
`payload/checksum`	结果与完整性校验

4.3 控制域消费规则

RTOS 只在以下条件同时满足时采用 AI 结果：

ID 匹配
AND 数据完整
AND finish_time <= deadline
AND now <= valid_until
AND confidence/status 满足策略

任一条件不满足时执行预定义回退，例如沿用上次可信结果、使用传统控制器、降低运行等级或进入安全状态。回退动作和完成时间本身也属于实时需求。

5. 系统级时间模型

AI 辅助决策链可表示为：

R_ai = C_sample + C_tx_req + Q_linux + C_pre
     + C_infer + C_post + C_tx_rsp + C_validate

系统约束不是简单要求 C_infer 最小，而是：

R_control <= D_control

AI 结果被采用时：R_ai <= D_ai 且 age(result) <= A_max

AI 结果未按时到达时：R_fallback <= D_fallback

其中，控制闭环约束为硬优先级；AI 时效约束通常为任务相关的软实时或固实时约束；回退路径必须有独立期限。

6. 资源并行与隔离策略

6.1 CPU 和中断

为 RTOS 域保留独立物理核，避免与 Linux vCPU 时间复用；
将关键定时器和现场总线中断直达 RTOS 域；
将网卡、存储和加速器完成中断尽量路由到 Linux 域；
若共享 LLC，测量 Linux 推理对控制任务缓存行为的干扰；
记录 SMT、动态迁核和电源管理对分区确定性的影响。

6.2 内存、带宽和 DMA

两域使用静态内存区间，共享区保持最小化；
共享缓冲区预分配，禁止关键路径动态扩容；
使用 IOMMU 或硬件访问控制限制 DMA 范围；
对 DRAM 带宽、内存控制器和互联竞争进行压力实验；
若硬件不支持带宽限额，必须把“核隔离”和“内存隔离”分开表述。

6.3 加速器

推荐由 Linux 推理域独占 GPU/NPU，以保留成熟驱动和运行时生态。RTOS 通过请求契约使用推理服务，而不是直接进入厂商运行时。

若控制域也需访问同一加速器，则必须额外解决队列仲裁、DMA 隔离、不可抢占执行段和故障复位归属。这种共享模式风险更高，应作为扩展方案而非默认主线。

6.4 功耗和热

分域不自动消除芯片级功耗和温度耦合。Linux 域的持续推理可能触发全芯片功耗限制或降频，进而改变 RTOS 域执行时间。因此需要：

固定或记录各域频率和功率模式；
同步采集控制延迟、推理负载、温度和实际频率；
对推理域设置负载准入或功耗上限；
验证热稳态而非只测短时冷机性能。

7. 故障与降级状态机

正常增强控制
    │ AI 超时/低置信度
    ▼
传统控制或保持模式
    │ 连续超时/通信故障
    ▼
推理域隔离与重启
    │ 控制风险上升
    ▼
受限运行或安全状态

需要验证的故障至少包括：

Linux 推理进程崩溃；
Linux 域卡死或重启；
加速器驱动错误或设备复位；
跨域队列堆满、消息乱序或数据损坏；
推理持续超时；
Linux 域 CPU、内存、网络或存储过载。

每种故障都要记录检测时间、隔离时间、回退完成时间、控制任务违约数和恢复后首个有效 AI 结果时间。

8. 可比较的架构组

组别	架构	用途
A0	单 Linux，控制与推理同域	通用部署基线
A1	PREEMPT_RT Linux，控制与推理同域	实时增强 Linux 基线
A2	RTOS 同域承载控制与可运行的 AI	适用于 MCU/小模型，不强求大模型生态
A3	RTOS 控制域 + Linux 推理域 + 分区层	边缘并行主方案
A4	A3 加入通信、带宽、故障和热治理机制	完整优化方案

比较时必须固定硬件、控制任务语义、AI 模型、输入到达序列和功率策略。A2 与 A3 若使用不同推理后端，应明确这是“系统方案比较”，不能仅归因为内核差异。

9. 核心评价指标

控制域

周期任务响应时间、抖动和 deadline miss ratio；
外部输入到执行器输出的物理链路延迟；
AI 过载与故障期间的观测最大响应时间；
回退路径完成时间。

AI 链路

从 RTOS 发起请求到结果验证完成的端到端延迟；
结果按期率、新鲜度合格率、超时率和丢弃率；
吞吐、TTFT/TPOT 或任务特定推理时延；
推理域重启后的恢复时间。

隔离与代价

空载和推理满载时控制延迟之差；
CPU、内存带宽、I/O、DMA 和热干扰敏感度；
跨域 IPC 延迟、抖动、拷贝次数和 CPU 开销；
静态资源预留造成的推理吞吐及能效损失。

10. 架构结论边界

本架构旨在证明“系统可以在 AI 负载不确定的情况下保护关键控制路径，并对 AI 结果实施有期限的安全消费”。它不自动证明：

Linux 域中的大模型具备硬实时性；
Hypervisor 消除了所有共享硬件干扰；
一个硬件平台的分区结果可直接迁移到另一 SoC；
只要控制域未违约，AI 功能就一定满足任务需求。

最终结论必须同时报告控制保障效果、AI 结果可用性以及隔离带来的资源代价。

10 KiB Raw Permalink Blame History Unescape Escape