某工厂产线振动传感器已经部署了3年，数据一直在采集，但从未被实时分析。工人靠经验判断异常，一次轴承故障导致停机8小时，损失超过50万。为什么不加AI？因为老板说“换硬件太贵，上云不安全”。

这是工业现场的真实困境。传统云端AI方案面临四大痛点：网络延迟高、断网即瘫痪、数据隐私合规、推理成本贵。而EdgeAgent Hub将AI推理能力下沉到边缘侧，让每一台工业网关都拥有自主决策的“大脑”。我们在一台RK3588（8GB内存）的边缘盒子上，用不到512MB的常驻内存跑通了完整的边缘AI推理链路：从传感器数据接入、ONNX模型推理、到LLM生成告警并推送到钉钉。整个过程延迟低于3秒，断网也能自治。本文将完整复现这套方案，所有代码和配置都可以在仓库中找到。

为什么选ONNX Runtime + llama.cpp？ 端侧推理的本质优势在于：云端API是“租车出行”——方便但每公里付费、路径透明；端侧推理是“自己开车”——前期投入但之后零油费、路径私密。

方案 硬件要求 断网可用 数据隐私 部署成本 云端推理API 无 ❌ 数据上云 按次付费 TensorRT NVIDIA GPU ✅ ✅ 需Jetson ONNX Runtime 任意CPU ✅ ✅ 零额外硬件 llama.cpp 任意CPU ✅ ✅ 零额外硬件 EdgeAgent Hub默认使用ONNX Runtime作为基础推理引擎，LLM后端使用llama.cpp。启动时自动检测硬件能力，选择最优Execution Provider。在RK3588上，NPU通过RKNN Toolkit加速；在树莓派5上，则使用ONNX Runtime CPU EP + ARM NEON优化。

从零搭建推理链路 完整的Docker Compose配置如下，可直接复制运行：

version: "3.8"

services: nats: image: nats:2.10-alpine command: ["-js", "-sd", "/data", "-m", "8222"] volumes:

• nats-data:/data

ports:

• "4222:4222"
• "8222:8222"

mqtt-bridge: image: edgelite/mqtt-nats-bridge:latest environment:

• MQTT_BROKER=tcp://192.168.1.100:1883
• NATS_URL=nats://nats:4222

depends_on:

• nats

inference-onnx: image: edgelite/hub-onnx:latest volumes:

• ./models:/models
• ./data/onnx:/data

devices:

• /dev/dri:/dev/dri

depends_on:

• nats

inference-llm: image: edgelite/hub-llm:latest volumes:

• ./models/llm:/models

environment:

• LLM MODEL=qwen3-0.6b-q4k_m.gguf
• LLM_PORT=50054

depends_on:

• nats

orchestrator: image: edgelite/hub-orchestrator:latest volumes:

• ./configs/workflows:/workflows
• ./data/orchestrator:/data

depends_on:

• nats

volumes: nats-data: 配套的YAML工作流定义，实现振动异常检测和RAG告警：

name: vibration anomalyalert trigger: source: mqtt topic: sensors/vibration/+/+ condition: "value > 4.5 AND confidence > 0.85"

steps:

• id: anomaly_detect

agent: onnx.vibration anomaly   input: "{{ trigger.payload }}"   output: anomalyresult   timeout: 100ms   on_timeout: skip

• id: rag_alert

agent: llm.rag anchored   input:   sensordata: "{{ trigger.payload }}"   anomaly result: "{{ anomalyresult }}"   output: alert message   timeout: 5000ms   onfailure:   agent: template.fallback_alert

• id: notify

agent: notify.multi channel   input:   message: "{{ alertmessage }}"   channels: [dingtalk, sms, webhook]   condition: "alert_message.urgency >= HIGH"   将上述文件保存后，执行 docker compose up -d，整个边缘AI推理链路就启动了。传感器数据通过MQTT上报，自动桥接到NATS，触发工作流，ONNX模型推理，LLM生成告警，最后通过钉钉或短信通知运维人员。

实测数据 在RK3588（8GB）上实测：

场景 延迟目标 实测结果 振动异常检测 (ONNX) < 50ms 42ms LLM 告警生成 (Qwen3-0.6B Q4) < 3s 2.8s 端到端（振动→视觉→告警） < 3s 2.6s RAG 锚定通过率 > 90% 92% 常驻内存占用 < 512MB 480MB 对比云端方案端到端延迟200-2000ms，边缘推理延迟降低10-40倍，且断网时完全不受影响。

踩坑记录 ONNX模型在ARM CPU上的EP选择：需要显式指定CPU Execution Provider，否则可能报错。在代码中通过 ort.SessionOptions() 设置 intra opnum_threads 为物理核心数，性能提升约30%。

JetStream持久化路径权限问题：Docker容器内需挂载宿主机目录并设置正确权限。建议在宿主机上创建 /data/nats 并赋予 UID 1000 读写权限。

NATS-MQTT bridge的topic映射规则：MQTT的 / 层级需转换为NATS的 . 分隔。例如 sensors/vibration/line1 映射为 edgelite.sensors.vibration.line1，映射规则在bridge的配置文件中可自定义。

LLM模型量化选择：Qwen3-0.6B使用Q4 KM量化后约400MB，在8GB内存设备上运行流畅。如果内存只有4GB，建议使用Q4 0或Q3K_S量化，但会牺牲少量精度。

小结 EdgeAgent Hub让存量工业网关在不更换硬件的前提下获得AI推理能力。512MB内存即可运行基础推理，4GB内存可运行小LLM和RAG锚定。所有代码开源，欢迎访问仓库获取完整示例和文档。

仓库地址： Gitee: suoten/edgeagent-hub GitHub: suoten/EdgeAgent-Hub