边缘AI视觉01-为什么我们在 RK3588 上做了一套三进程边缘 AI 视频分析系统

为什么我们在 RK3588 上做了一套三进程边缘 AI 视频分析系统做工业 AI 视觉这几年我们踩过很多坑。最深刻的一个教训是别把所有东西都塞在一个进程里。本文分享我们从单进程 demo 到三进程生产级系统的演进过程以及为什么 RK3588 这块芯片上三进程架构是更优解。一、背景边缘 AI 视觉为什么火了这两年工业 AI 视觉的需求爆发式增长。原因很现实人力成本越来越高——一个车间配几个巡检工人一年的工资成本可能比一套 AI 系统还贵7×24 小时不间断——人会疲劳、会走神、会请假AI 系统可以不知疲倦地一直跑准确率稳定可追溯——人的判断受情绪、经验、状态影响AI 的判断是可复现的每次检测都有证据图留存但这里有个关键问题AI 视觉分析跑在哪里早期的方案是「摄像头 云端服务器」——摄像头把视频流传到云端云端做 AI 推理再把结果推回来。但这个方案在工业场景里问题很多带宽不够——一路 1080P 视频流就要 4Mbps一个车间几十路摄像头普通企业带宽根本扛不住延迟太高——视频传到云端再推理再返回端到端延迟可能几百毫秒甚至几秒实时告警场景根本没法用数据安全——生产现场的视频流传到第三方云端很多企业客户不接受网络不稳定——工厂车间的 WiFi/有线网络偶尔断网断网期间 AI 系统就瞎了所以边缘计算成了工业 AI 视觉的主流方案——在摄像头旁边放一台边缘计算设备视频流不用上传直接在本地解码、推理、告警只把检测结果和证据图传到云端或客户端。而在边缘计算设备的选型上RK3588成了这两年的一匹黑马。二、为什么选 RK3588RK3588 是瑞芯微的一款旗舰级 SoC参数很能打模块规格对 AI 视觉的意义CPU8 核4×A76 4×A55最高 2.4GHz跑业务逻辑、网络通信、数据库性能足够NPU6 TOPSINT8三核独立 NPU Core跑 YOLO 等检测模型多路并发推理视频解码MPP 硬解码支持 H.264/H.265 等 16 种格式8 路以上 1080P 硬解码CPU 几乎不占用图像加速RGA 2D 硬件加速器裁剪、缩放、色彩空间转换零 CPU 负载视频编码硬编码 H.264/H.265证据图 JPEG 编码、结果流推流内存最高 32GB LPDDR4/5多路视频缓冲 多模型加载内存够用功耗典型 5-10W被动散热即可适合工业现场长时间运行价格千元级板卡比 NVIDIA Jetson 系列便宜一半以上简单说RK3588 把 AI 推理NPU、视频处理MPPRGAVPU、通用计算CPU三大能力集成在一块芯片上而且价格只有同级别 NVIDIA 方案的一半。对于 8-16 路 1080P 视频分析的工业场景RK3588 是性价比极高的选择。我们越微智能在多个工业视觉项目中都选用了 RK3588 作为边缘计算平台从早期的单路 demo 到现在的 16 路生产级系统踩了不少坑也积累了一些经验。三、踩坑实录单进程架构的「三宗罪」刚开始做的时候我们和大多数团队一样写了一个单进程的 demo——拉流、解码、预处理、推理、后处理、告警推送全在一个进程里搞定。demo 跑起来的时候觉得挺爽——代码简单、调试方便、一个二进制文件扔到设备上就能跑。但等我们把它放到客户现场跑了几周之后问题全来了。罪一一个模块崩溃整个系统全挂单进程架构下所有模块共享同一个进程空间。任何一个模块出问题段错误、内存泄漏、死循环都会把整个进程拖垮。我们遇到过的真实案例算法模块内存泄漏——某个模型的后处理代码有内存泄漏跑了 3 天之后进程 OOM内存溢出被系统杀掉整个系统包括拉流、解码、告警推送全部停摆网络模块死循环——RTSP 拉流库在某个异常码流下进入死循环CPU 占满 100%整个进程卡死其他模块包括已经在运行的推理任务全部停摆解码模块段错误——某路摄像头的码流有异常帧MPP 解码库触发段错误整个进程崩溃其他正常的摄像头也跟着停了单进程架构下系统的可靠性取决于最不稳定的那个模块。而 AI 视觉系统里拉流库、解码库、推理 SDK任何一个都可能有 bug。一个崩全崩。客户现场的反馈很直接「你们这个系统怎么动不动就重启我其他路摄像头还在跑着呢。」罪二CPU 软解码占满算力推理没资源了单进程 demo 阶段我们用的是 FFmpeg 软解码——因为简单跨平台不用折腾 RK3588 的 MPP 硬解码接口。但软解码的性能问题在多路场景下暴露无遗路数软解码 CPU 占用系统状态1 路 1080P15-20%流畅2 路 1080P35-40%还行4 路 1080P80-100%开始丢帧推理延迟增大8 路 1080P200%多核占满严重丢帧系统卡死4 路 1080P 软解码就能把 RK3588 的 CPU 占满留给 AI 推理和业务逻辑的 CPU 资源所剩无几。推理延迟从几十毫秒涨到几百毫秒实时告警变成了「事后诸葛亮」。而且软解码和推理在同一个进程里抢 CPU解码占多了推理就慢推理占多了解码就丢帧互相打架。我们当时的感觉是RK3588 这块芯片明明有硬解码能力但我们放着不用用 CPU 软解码把算力浪费掉了这不是暴殄天物吗罪三算法模型升级整个系统都要重新部署单进程架构下算法模型和业务逻辑编译在同一个二进制文件里。每次算法团队更新模型比如优化了 YOLO 的后处理、换了一个新模型、调整了 NMS 参数都要重新编译整个进程然后重新部署到设备上。这带来几个问题部署风险大——重新部署整个系统可能引入新的 bug影响已经稳定运行的业务逻辑升级窗口受限——客户现场的系统不能随便停升级要等半夜或周末算法迭代速度被拖慢回滚困难——如果新模型有问题要回滚到旧版本就得重新部署旧版本的整个二进制文件算法和业务耦合——算法团队改模型要动业务代码的编译流程业务团队改逻辑也要重新编译算法部分。两队互相干扰我们算法团队的抱怨是「我就改了个模型文件为什么要重新编译整个系统、还要等半夜才能升级」四、我们的方案三进程架构 [Yuewell Inside]踩了这些坑之后我们决定重构系统架构。核心思路是按职责拆分进程让稳定的和不稳定的分开让算力密集的和业务逻辑分开让需要频繁升级的和需要稳定运行的分开。最终我们定了三进程架构三个进程分别承担不同职责各自独立部署、独立升级、独立崩溃恢复┌─────────────────────────────────────────────────────┐ │ UI/交互层进程 (Client App) │ │ .NET 8 Avalonia UI跨平台 │ │ 设备管理、任务配置、实时预览、报警查看、历史回溯 │ └──────────────────────┬──────────────────────────────┘ │ gRPC管理 预览 报警流 ┌──────────────────────▼──────────────────────────────┐ │ 边缘核心服务与流媒体引擎 (Core Service) │ │ C20 gRPC SQLite 3 │ │ 拉流解封装、MPP硬解码、RGA预处理、任务调度、 │ │ 越微自研事件融合引擎、证据链编码、第三方推送、配置持久化 │ └──────────────────────┬──────────────────────────────┘ │ 越微自研零拷贝通信组件 ┌──────────────────────▼──────────────────────────────┐ │ NPU 推理与算法调度引擎 (Algo Runner) │ │ C RKNN SDK │ │ 模型加载/切换、前处理、NPU推理、后处理(NMS) │ │ 多模型多实例、健康检查、负载指标 │ └─────────────────────────────────────────────────────┘进程一UI/交互层进程 (Client App)——人机交互面技术栈.NET 8 Avalonia UI跨平台Windows/Linux 都能跑职责设备与相机管理、算法任务配置含 ROI 绘制、实时点播预览、报警与证据链查看、历史轨迹回溯特点只和边缘核心服务通信不直连推理引擎不持久化全网配置以核心服务的 SQLite 为准为什么客户端要独立成进程因为客户端是给人用的可能运行在运维人员的 Windows 电脑上也可能运行在 RK3588 设备上接显示器。独立成进程后客户端崩溃不影响后端服务后端服务升级不影响客户端界面。进程二边缘核心服务与流媒体引擎 (Core Service)——业务编排核心技术栈C20 gRPC SQLite 3职责相机与会话调度、RTSP/ONVIF 接入、RK3588 MPP 视频硬解码、RGA 图像硬件加速、同源多任务会话复用调度、编排并调用推理引擎完成推理、越微自研的工业多模态事件去重与时空融合引擎、确认时刻实帧 JPEG 编码、第三方 HTTP 推送、对客户端的 gRPC 服务特点持有配置与运行态权威数据SQLite承担 I/O 与业务编排不做模型训练纯推理内核集中在推理引擎这是整个系统的「大脑」和「调度中心」也是最稳定的进程——因为它不做算力密集的推理只做调度和业务逻辑代码相对稳定不需要频繁升级。进程三NPU 推理与算法调度引擎 (Algo Runner)——推理执行器技术栈CLinux 上用 RKNN SDKWindows 上可用 ONNX Runtime 联调职责按请求加载/切换模型、执行前处理与推理、后处理如 NMS、输出检测结果列表提供健康检查与负载指标特点不直接访问相机、不解析 RTSP、不持久化业务配置、不做第三方推送尽量不感知业务规则保持可替换与可单测这是整个系统的「算力引擎」也是最需要频繁升级的进程——算法团队迭代模型、优化后处理、新增算法类型都只需要升级这个进程不影响核心服务的业务逻辑和客户端界面。部署模型1 1 N1 个边缘核心服务集中管理本平台的解码、RGA 搬运与业务编排1 个推理引擎独立进程承载多模型、多实例推理N 个算法任务逻辑上同一相机可同时挂载多个任务比如实时人员入侵 离散定时视频诊断或烟火 垃圾检测未来如果算力不够可以扩展为多推理引擎实例在核心服务里做路由与负载均衡客户端完全不感知分片细节。五、三进程架构解决了什么问题问题一模块隔离一个崩不影响其他三进程架构下每个进程有独立的地址空间。推理引擎进程崩溃比如模型加载失败、推理 SDK 段错误核心服务可以通过健康检查快速发现然后重启推理引擎、降级处理停止无效重试、跳帧在客户端呈现可诊断状态。拉流、解码、业务逻辑完全不受影响。反过来核心服务如果出问题虽然概率很低推理引擎还在运行重启核心服务后可以重新连接推理引擎不需要重新加载模型。我们在客户现场做过故障注入测试故意杀掉推理引擎进程核心服务在 2 秒内检测到并重启期间拉流和解码正常运行只是推理暂停了几秒重启后自动恢复。整个过程其他模块零感知。问题二硬解码释放 CPU推理有资源了核心服务进程专门负责 MPP 硬解码和 RGA 预处理用的是 RK3588 的硬件加速能力CPU 占用极低。推理引擎进程专门负责 NPU 推理CPU 只做轻量的前处理和后处理。两个进程分工明确不再抢 CPU模块运行位置CPU 占用8 路 1080P拉流 MPP 硬解码 RGA核心服务硬件加速15-20%NPU 推理 轻量前后处理推理引擎NPU 加速10-15%业务逻辑 网络 数据库核心服务5-10%总计30-45%8 路 1080P 视频分析总 CPU 占用只有 30-45%剩下的 CPU 资源还能跑更多任务或做更复杂的业务逻辑。对比单进程软解码的 200%多核占满这是质的飞跃。问题三算法独立升级不影响业务稳定性算法模型迭代只需要升级推理引擎进程核心服务和客户端完全不动。升级过程准备新的推理引擎二进制文件和模型文件通过 OTA 升级包只替换推理引擎部分停止旧推理引擎 → 启动新推理引擎 → 核心服务自动重连整个过程核心服务的拉流、解码、业务逻辑持续运行只是推理暂停几秒算法团队的反馈是「现在改模型只需要升级推理引擎半夜升级也不怕影响业务了迭代速度快了很多。」六、三进程架构的代价与工程壁垒警告当然三进程架构不是银弹它也带来了一些新的挑战。6.1 进程间通信的复杂性单进程里函数调用就行三进程之间要通信。我们用了两种通信方式客户端 ↔ 核心服务gRPC管理操作 双向流承载预览和报警核心服务 ↔ 推理引擎越微自研零拷贝通信组件图像数据 gRPC控制信令和检测结果通信机制的引入增加了开发复杂度但这是值得的——换来的是模块隔离和独立升级。6.2 共享内存的生命周期管理零拷贝共享内存需要管理缓冲区的生命周期、双端同步序列号/事件 fd、约定布局NV12 格式、stride 对齐。这些细节处理不好会导致内存泄漏、数据错乱、进程死锁。我们在这上面踩了不少坑后面会专门写一篇讲零拷贝通信的实战经验。6.3 调试难度增加单进程下用一个调试器就能跟完整条链路三进程下要同时挂三个调试器还要看进程间的消息时序。不过我们通过完善的日志统一 trace_id 贯穿三个进程和结构化日志输出基本解决了调试问题。6.4 部署包变大三个进程的二进制文件 各自的依赖库部署包比单进程大一些。但对于 RK3588 动辄几十 GB 的存储来说这点增量可以忽略不计。⚠️ 工程坑点与技术壁垒警告提示三进程架构虽好但在工程落地中极易踩坑以下是我们用大量崩溃换来的经验内存泄漏与句柄残余若推理引擎进程异常崩溃DMA 句柄若未在内核层做严格的泄漏回收与生命周期托管设备连续运行数天后物理内存会被残余句柄逐步耗尽最终触发 OOM 且难以定位根因。这不是「加个 free 就能解决」的问题需要在内核态与用户态构建完整的句柄追踪与自动回收机制。跨进程时钟同步与丢帧错位多进程架构下各进程的时间戳若不做硬件级 RTC/NTP 补偿与全局时钟对齐在做事件融合证据链时会发生「帧画错位」——告警记录的时间戳和证据图对不上事后追溯时客户会质疑数据真实性。我们的做法是在硬件层做全局时钟锚定所有进程共享同一个时间基准。越微团队历时大半年、经历了上百次崩溃压测与故障注入才打磨出这套零崩溃的生产级通讯框架。三进程架构的思想不难理解但要做到 7×24 小时零崩溃运行中间的工程细节和异常处理才是真正的技术壁垒。七、什么场景适合三进程架构不是所有项目都需要三进程架构。我们的经验是场景推荐架构原因1-2 路视频demo/验证阶段单进程简单快速不需要复杂架构4 路以上视频生产环境双进程业务推理至少把推理拆出来避免崩溃互相影响8 路以上视频多算法任务需要长期运维三进程客户端核心服务推理引擎完整的模块隔离、硬件加速、独立升级16 路以上或多模态大模型多推理引擎实例 负载均衡算力不够横向扩展推理引擎简单说如果你的系统要在客户现场 7×24 小时跑、要支持多路视频、要持续迭代算法模型三进程架构是更稳妥的选择。如果只是 demo 或小规模验证单进程更快。写在最后从单进程 demo 到三进程生产级系统我们花了大半年时间踩了很多坑也走了一些弯路。但最终的结果是值得的——系统在客户现场稳定运行了几个月算法团队可以独立迭代模型运维人员可以方便地管理设备和任务。三进程架构不是什么高深的新技术它就是「关注点分离」这个古老原则在边缘 AI 视觉系统中的具体应用。但真正把它落地处理好进程间通信、共享内存、故障恢复、独立升级这些细节需要大量的工程实践。我们越微智能团队一直在做工业 AI 视觉、机器人二次开发、边缘计算部署这些落地工作三进程边缘 AI 视频分析系统是我们的核心产品之一。后面的文章我们会逐一拆解这个系统的各个模块——MPP 硬解码与 RGA 加速、同源多任务调度、零拷贝通信、多模型推理、事件融合与证据链、部署与 OTA 升级把我们踩过的坑和积累的经验分享出来。如果你也在做边缘 AI 视觉、工业视频分析、RK3588 开发相关的工作欢迎交流我们一起踩坑、一起进步。关于作者与团队越微智能Yuewell是一支专注具身智能与工业 AI 视觉落地的技术团队提供工业级视觉算法定制30 算法、RK3588 边缘一体机、具身机器人调度管理平台、全品牌机器人二次开发适配宇树/优必选/智元/傅利叶等、ROS2 系统开发等产品和服务支持从算法、硬件到产线实机部署的全栈交付。我们将这套经过上百次故障注入与压测验证的稳定架构封装为了工业级边缘 AI 视觉基座Yuewell Edge Framework支持硬件/算法快速二次开发帮助客户跳过最痛苦的工程踩坑阶段直接聚焦业务价值。下一篇预告《MPP 硬解码 RGA 加速我们如何把 8 路 1080P 视频处理的 CPU 占用降到 20% 以下》我们将分享从 FFmpeg 软解码到 RK3588 MPP 硬解码的迁移过程、RGA 硬件加速做裁剪/缩放/色彩空间转换的实战、越微自研零拷贝链路的搭建以及软解码 vs 硬解码的性能对比数据敬请关注。