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

做工业 AI 视觉这几年，我们踩过很多坑。最深刻的一个教训是：别把所有东西都塞在一个进程里。本文分享我们从单进程 demo 到三进程生产级系统的演进过程，以及为什么 RK3588 这块芯片上，三进程架构是更优解。

---

一、背景：边缘 AI 视觉为什么火了？

这两年工业 AI 视觉的需求爆发式增长。原因很现实：

• 人力成本越来越高——一个车间配几个巡检工人，一年的工资成本可能比一套 AI 系统还贵
• 7×24 小时不间断——人会疲劳、会走神、会请假，AI 系统可以不知疲倦地一直跑
• 准确率稳定可追溯——人的判断受情绪、经验、状态影响，AI 的判断是可复现的，每次检测都有证据图留存

但这里有个关键问题：AI 视觉分析跑在哪里？

早期的方案是「摄像头 + 云端服务器」——摄像头把视频流传到云端，云端做 AI 推理，再把结果推回来。但这个方案在工业场景里问题很多：

• 带宽不够——一路 1080P 视频流就要 4Mbps，一个车间几十路摄像头，普通企业带宽根本扛不住
• 延迟太高——视频传到云端再推理再返回，端到端延迟可能几百毫秒甚至几秒，实时告警场景根本没法用
• 数据安全——生产现场的视频流传到第三方云端，很多企业客户不接受
• 网络不稳定——工厂车间的 WiFi/有线网络偶尔断网，断网期间 AI 系统就瞎了

所以边缘计算成了工业 AI 视觉的主流方案——在摄像头旁边放一台边缘计算设备，视频流不用上传，直接在本地解码、推理、告警，只把检测结果和证据图传到云端或客户端。

而在边缘计算设备的选型上，RK3588 成了这两年的一匹黑马。

---

二、为什么选 RK3588？

RK3588 是瑞芯微的一款旗舰级 SoC，参数很能打：

简单说，RK3588 把 AI 推理（NPU）、视频处理（MPP+RGA+VPU）、通用计算（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 硬解码接口。

但软解码的性能问题在多路场景下暴露无遗：

4 路 1080P 软解码就能把 RK3588 的 CPU 占满，留给 AI 推理和业务逻辑的 CPU 资源所剩无几。推理延迟从几十毫秒涨到几百毫秒，实时告警变成了「事后诸葛亮」。

而且软解码和推理在同一个进程里抢 CPU，解码占多了推理就慢，推理占多了解码就丢帧，互相打架。

我们当时的感觉是：RK3588 这块芯片明明有硬解码能力，但我们放着不用，用 CPU 软解码把算力浪费掉了，这不是暴殄天物吗？

罪三：算法模型升级，整个系统都要重新部署

单进程架构下，算法模型和业务逻辑编译在同一个二进制文件里。每次算法团队更新模型（比如优化了 YOLO 的后处理、换了一个新模型、调整了 NMS 参数），都要重新编译整个进程，然后重新部署到设备上。

这带来几个问题：

• 部署风险大——重新部署整个系统，可能引入新的 bug，影响已经稳定运行的业务逻辑
• 升级窗口受限——客户现场的系统不能随便停，升级要等半夜或周末，算法迭代速度被拖慢
• 回滚困难——如果新模型有问题，要回滚到旧版本，就得重新部署旧版本的整个二进制文件
• 算法和业务耦合——算法团队改模型，要动业务代码的编译流程；业务团队改逻辑，也要重新编译算法部分。两队互相干扰

我们算法团队的抱怨是：「我就改了个模型文件，为什么要重新编译整个系统、还要等半夜才能升级？」

---

四、我们的方案：三进程架构 [Yuewell Inside]

踩了这些坑之后，我们决定重构系统架构。核心思路是：按职责拆分进程，让稳定的和不稳定的分开，让算力密集的和业务逻辑分开，让需要频繁升级的和需要稳定运行的分开。

最终我们定了三进程架构，三个进程分别承担不同职责，各自独立部署、独立升级、独立崩溃恢复：

```

┌─────────────────────────────────────────────────────┐

│ UI/交互层进程 (Client App) │

│ .NET 8 + Avalonia UI，跨平台 │

│ 设备管理、任务配置、实时预览、报警查看、历史回溯 │

└──────────────────────┬──────────────────────────────┘

│ gRPC（管理 + 预览 + 报警流）

┌──────────────────────▼──────────────────────────────┐

│ 边缘核心服务与流媒体引擎 (Core Service) │

│ C++20 + 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)——业务编排核心

• 技术栈：C++20 + gRPC + SQLite 3
• 职责：相机与会话调度、RTSP/ONVIF 接入、RK3588 MPP 视频硬解码、RGA 图像硬件加速、同源多任务会话复用调度、编排并调用推理引擎完成推理、越微自研的工业多模态事件去重与时空融合引擎、确认时刻实帧 JPEG 编码、第三方 HTTP 推送、对客户端的 gRPC 服务
• 特点：持有配置与运行态权威数据（SQLite）；承担 I/O 与业务编排；不做模型训练；纯推理内核集中在推理引擎

这是整个系统的「大脑」和「调度中心」，也是最稳定的进程——因为它不做算力密集的推理，只做调度和业务逻辑，代码相对稳定，不需要频繁升级。

进程三：NPU 推理与算法调度引擎 (Algo Runner)——推理执行器

• 技术栈：C++；Linux 上用 RKNN SDK，Windows 上可用 ONNX Runtime 联调
• 职责：按请求加载/切换模型、执行前处理与推理、后处理（如 NMS）、输出检测结果列表；提供健康检查与负载指标
• 特点：不直接访问相机、不解析 RTSP、不持久化业务配置、不做第三方推送；尽量不感知业务规则（保持可替换与可单测）

这是整个系统的「算力引擎」，也是最需要频繁升级的进程——算法团队迭代模型、优化后处理、新增算法类型，都只需要升级这个进程，不影响核心服务的业务逻辑和客户端界面。

部署模型：1 + 1 + N

• 1 个边缘核心服务：集中管理本平台的解码、RGA 搬运与业务编排
• 1 个推理引擎：独立进程，承载多模型、多实例推理
• N 个算法任务：逻辑上同一相机可同时挂载多个任务（比如实时人员入侵 + 离散定时视频诊断，或烟火 + 垃圾检测）

未来如果算力不够，可以扩展为多推理引擎实例，在核心服务里做路由与负载均衡，客户端完全不感知分片细节。

---

五、三进程架构解决了什么问题？

问题一：模块隔离，一个崩不影响其他

三进程架构下，每个进程有独立的地址空间。推理引擎进程崩溃（比如模型加载失败、推理 SDK 段错误），核心服务可以通过健康检查快速发现，然后重启推理引擎、降级处理（停止无效重试、跳帧），在客户端呈现可诊断状态。拉流、解码、业务逻辑完全不受影响。

反过来，核心服务如果出问题（虽然概率很低），推理引擎还在运行，重启核心服务后可以重新连接推理引擎，不需要重新加载模型。

我们在客户现场做过故障注入测试：故意杀掉推理引擎进程，核心服务在 2 秒内检测到并重启，期间拉流和解码正常运行，只是推理暂停了几秒，重启后自动恢复。整个过程其他模块零感知。

问题二：硬解码释放 CPU，推理有资源了

核心服务进程专门负责 MPP 硬解码和 RGA 预处理，用的是 RK3588 的硬件加速能力，CPU 占用极低。推理引擎进程专门负责 NPU 推理，CPU 只做轻量的前处理和后处理。

两个进程分工明确，不再抢 CPU：

8 路 1080P 视频分析，总 CPU 占用只有 30-45%，剩下的 CPU 资源还能跑更多任务或做更复杂的业务逻辑。对比单进程软解码的 200%+（多核占满），这是质的飞跃。

问题三：算法独立升级，不影响业务稳定性

算法模型迭代只需要升级推理引擎进程，核心服务和客户端完全不动。升级过程：

1. 准备新的推理引擎二进制文件和模型文件
2. 通过 OTA 升级包只替换推理引擎部分
3. 停止旧推理引擎 → 启动新推理引擎 → 核心服务自动重连
4. 整个过程核心服务的拉流、解码、业务逻辑持续运行，只是推理暂停几秒

算法团队的反馈是：「现在改模型只需要升级推理引擎，半夜升级也不怕影响业务了，迭代速度快了很多。」

---

六、三进程架构的代价与工程壁垒警告

当然，三进程架构不是银弹，它也带来了一些新的挑战。

6.1 进程间通信的复杂性

单进程里函数调用就行，三进程之间要通信。我们用了两种通信方式：

• 客户端 ↔ 核心服务：gRPC（管理操作 + 双向流承载预览和报警）
• 核心服务 ↔ 推理引擎：越微自研零拷贝通信组件（图像数据）+ gRPC（控制信令和检测结果）

通信机制的引入增加了开发复杂度，但这是值得的——换来的是模块隔离和独立升级。

6.2 共享内存的生命周期管理

零拷贝共享内存需要管理缓冲区的生命周期、双端同步（序列号/事件 fd）、约定布局（NV12 格式、stride 对齐）。这些细节处理不好会导致内存泄漏、数据错乱、进程死锁。我们在这上面踩了不少坑，后面会专门写一篇讲零拷贝通信的实战经验。

6.3 调试难度增加

单进程下用一个调试器就能跟完整条链路，三进程下要同时挂三个调试器，还要看进程间的消息时序。不过我们通过完善的日志（统一 trace_id 贯穿三个进程）和结构化日志输出，基本解决了调试问题。

6.4 部署包变大

三个进程的二进制文件 + 各自的依赖库，部署包比单进程大一些。但对于 RK3588 动辄几十 GB 的存储来说，这点增量可以忽略不计。

⚠️ 工程坑点与技术壁垒警告

提示：三进程架构虽好，但在工程落地中极易踩坑，以下是我们用大量崩溃换来的经验：
内存泄漏与句柄残余：若推理引擎进程异常崩溃，DMA 句柄若未在内核层做严格的泄漏回收与生命周期托管，设备连续运行数天后物理内存会被残余句柄逐步耗尽，最终触发 OOM 且难以定位根因。这不是「加个 free 就能解决」的问题，需要在内核态与用户态构建完整的句柄追踪与自动回收机制。
跨进程时钟同步与丢帧错位：多进程架构下，各进程的时间戳若不做硬件级 RTC/NTP 补偿与全局时钟对齐，在做事件融合证据链时会发生「帧画错位」——告警记录的时间戳和证据图对不上，事后追溯时客户会质疑数据真实性。我们的做法是在硬件层做全局时钟锚定，所有进程共享同一个时间基准。
越微团队历时大半年、经历了上百次崩溃压测与故障注入，才打磨出这套零崩溃的生产级通讯框架。 三进程架构的思想不难理解，但要做到 7×24 小时零崩溃运行，中间的工程细节和异常处理才是真正的技术壁垒。

---

七、什么场景适合三进程架构？

不是所有项目都需要三进程架构。我们的经验是：

简单说：如果你的系统要在客户现场 7×24 小时跑、要支持多路视频、要持续迭代算法模型，三进程架构是更稳妥的选择。 如果只是 demo 或小规模验证，单进程更快。

---

写在最后

从单进程 demo 到三进程生产级系统，我们花了大半年时间，踩了很多坑，也走了一些弯路。但最终的结果是值得的——系统在客户现场稳定运行了几个月，算法团队可以独立迭代模型，运维人员可以方便地管理设备和任务。

三进程架构不是什么高深的新技术，它就是「关注点分离」这个古老原则在边缘 AI 视觉系统中的具体应用。但真正把它落地，处理好进程间通信、共享内存、故障恢复、独立升级这些细节，需要大量的工程实践。

我们（越微智能）团队一直在做工业 AI 视觉、机器人二次开发、边缘计算部署这些落地工作，三进程边缘 AI 视频分析系统是我们的核心产品之一。后面的文章我们会逐一拆解这个系统的各个模块——MPP 硬解码与 RGA 加速、同源多任务调度、零拷贝通信、多模型推理、事件融合与证据链、部署与 OTA 升级，把我们踩过的坑和积累的经验分享出来。

如果你也在做边缘 AI 视觉、工业视频分析、RK3588 开发相关的工作，欢迎交流，我们一起踩坑、一起进步。

---

关于作者与团队：
越微智能（Yuewell）是一支专注具身智能与工业 AI 视觉落地的技术团队，提供工业级视觉算法定制（30+ 算法）、RK3588 边缘一体机、具身机器人调度管理平台、全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶等）、ROS2 系统开发等产品和服务，支持从算法、硬件到产线实机部署的全栈交付。
我们将这套经过上百次故障注入与压测验证的稳定架构，封装为了工业级边缘 AI 视觉基座（Yuewell Edge Framework），支持硬件/算法快速二次开发，帮助客户跳过最痛苦的工程踩坑阶段，直接聚焦业务价值。
📌 获取更多技术白皮书、工业 AI 视觉方案与产品交流，欢迎访问越微智能官网：https://yuewell.com/
下一篇预告： 《MPP 硬解码 + RGA 加速：我们如何把 8 路 1080P 视频处理的 CPU 占用降到 20% 以下》，我们将分享从 FFmpeg 软解码到 RK3588 MPP 硬解码的迁移过程、RGA 硬件加速做裁剪/缩放/色彩空间转换的实战、越微自研零拷贝链路的搭建，以及软解码 vs 硬解码的性能对比数据，敬请关注。