3D视觉+AI+数据分析：智能客流系统的云边协同架构

原创

FOORIR

发布于 2026-09-04 16:55:03

1360

智能客流系统正在从单机计数设备向分布式感知节点演进。

在传统架构中，设备负责采集图像，服务器负责处理视频，再生成进出人数。

新的技术路线则将计算拆分为两个层级：

感知侧：Sensor + Edge AI
平台侧：Cloud + Data Analytics

这种变化的核心不是简单地把AI放到设备里面，而是重新定义数据流。

1. 数据链路从“视频流”变成“事件流”

传统系统：

Camera
   ↓
Video Stream
   ↓
Server
   ↓
AI
   ↓
Counting

云边协同架构：

3D Sensor
   ↓
Edge AI
   ↓
Detection
   ↓
Tracking
   ↓
Event
   ↓
MQTT / HTTP / API
   ↓
Cloud
   ↓
Data Storage
   ↓
Analytics

边缘设备处理实时任务，云端处理历史数据。

例如一个入口设备不需要持续向云端上传完整视频，而可以生成：

10:31:01 IN 1
10:31:04 IN 1
10:31:09 OUT 1
10:31:13 IN 2

平台收到的已经是结构化事件。

这类架构可以明显减少视频回传带宽，并降低云端推理压力。现有边缘客流系统也已经采用本地AI推理、云端分析的方式。

2. Edge节点应该完成哪些任务？

一个完整的边缘节点可以划分为五层。

┌────────────────────────────┐
│       Application Layer    │
│  Counting / Zone / Alert   │
├────────────────────────────┤
│       AI Processing        │
│ Detection / Tracking / ID  │
├────────────────────────────┤
│       3D Processing        │
│ Depth / Calibration        │
├────────────────────────────┤
│       Sensor Layer         │
│ Stereo / ToF / RGB         │
├────────────────────────────┤
│       Hardware Layer       │
│ CPU / GPU / NPU / RAM      │
└────────────────────────────┘

设备启动后首先完成传感器初始化和标定参数加载。

随后进行：

Frame Capture
→ Preprocess
→ AI Inference
→ Tracking
→ Event Detection
→ Local Storage

只有最终事件进入网络层。

3. AI推理应该进行流水线设计

边缘设备算力有限，因此不能简单地把所有模型同时运行。

更合理的方式是Pipeline：

Capture
  ↓
Preprocess
  ↓
Inference
  ↓
Postprocess
  ↓
Tracker
  ↓
Event

例如：

Camera FPS = 25
AI inference = 10~15 FPS
Tracking = 25 FPS

并不意味着整个系统必须每秒运行25次完整AI模型。

可以采用：

AI Detection：低频
Tracking：高频
Counting：事件触发

这样可以减少NPU/GPU负载。

最终需要关注的指标包括：

指标	关注点
FPS	每秒处理帧数
Latency	单帧推理延迟
CPU Load	CPU占用
NPU/GPU Load	AI计算负载
RAM	内存占用
Temperature	长时间运行稳定性
Packet Loss	网络丢包
Offline Buffer	离线缓存能力

4. 云端数据模型不能只存一个count字段

如果数据库设计为：

traffic_count INT

后续很难支持复杂分析。

建议采用事件模型：

device_id
timestamp
event_type
direction
zone_id
track_id
confidence
duration
metadata

例如：

{
  "device_id": "store_001_gate_02",
  "event_type": "person_cross",
  "direction": "IN",
  "zone_id": "entrance",
  "timestamp": 1788508200,
  "confidence": 0.97
}

然后通过ETL任务生成：

1分钟统计表
小时统计表
日统计表
设备状态表
区域统计表

这样原始事件与统计结果相互独立。

如果算法升级，只需要重新计算统计逻辑，不必重新采集现场数据。

5. MQTT适合设备事件上报

客流设备属于典型IoT节点。

设备可以使用：

MQTT Topic

foorir/store/001/device/002/event

Payload：

{
  "timestamp": 1788508200,
  "in": 1,
  "out": 0,
  "device_status": "online"
}

平台收到消息后进入：

MQTT Broker
      ↓
Message Queue
      ↓
Stream Processing
      ↓
Data Warehouse
      ↓
Dashboard

如果设备数量从10台增加到10000台，系统依然可以通过消息队列进行水平扩展。

6. 时间同步是多设备系统容易忽略的问题

当一个门店只有一个设备时，时间问题不明显。

当一个区域部署多个3D传感器：

Sensor A
Sensor B
Sensor C

如果设备时间分别偏移：

A = 10:00:01
B = 10:00:03
C = 09:59:58

跨设备Tracking就会出现问题。

因此需要：

NTP
↓
统一时间源
↓
Device Timestamp
↓
Server Timestamp

对于需要跨设备轨迹分析的场景，还需要进一步考虑时钟漂移。

7. 离线运行能力是边缘系统的基础能力

门店网络并不一定稳定。

因此设备应该具备：

Online
  ↓
Normal Upload

Offline
  ↓
Local Buffer
  ↓
Network Recovery
  ↓
Batch Upload

例如本地缓存最近24小时事件。

网络恢复后按照：

timestamp ASC

顺序补传。

否则设备网络中断期间，客流数据会形成时间断层。

8. 云端只负责它擅长的任务

边缘端适合：

实时检测
Tracking
Counting
本地告警
本地缓存

云端适合：

多设备管理
历史查询
数据聚合
趋势分析
API
模型版本管理
设备OTA

这就是云边协同的基本分工。

9. 3D+AI系统的最终架构

完整系统可以抽象成：

                 Cloud
┌─────────────────────────────────┐
│ Device Management               │
│ Data Platform                   │
│ Analytics                       │
│ API                             │
│ Model Management                │
└────────────────┬────────────────┘
                 │
              MQTT/API
                 │
┌────────────────▼────────────────┐
│             Edge                │
│ Sensor → 3D → AI → Tracking    │
│              ↓                  │
│          Event Engine           │
│              ↓                  │
│        Local Storage            │
└────────────────┬────────────────┘
                 │
                 ↓
             Physical Space

这种结构下，智能客流系统已经不再是一台“统计人数的设备”，而是一个完整的边缘感知节点。

未来技术演进的重点会集中在更低延迟的边缘推理、更高效的3D感知、更稳定的多目标跟踪，以及统一的数据事件模型。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

物联网

#客流系统