边缘计算
在数据产生的源头（设备端）直接进行计算和决策，而非将所有数据上传到云端处理的分布式计算范式。
关键信息
| 属性 | 值 |
|---|---|
| 领域 | 分布式计算 / IoT |
| 核心价值 | 低延迟、离线可用、隐私保护、带宽节省 |
| 典型硬件 | ESP32、树莓派、NVIDIA Jetson、MCU |
| 与云端的关系 | 不是替代而是分工——边缘做实时决策，云端做训练和管理 |
核心特性
低延迟是核心驱动力
边缘计算最根本的价值在于把计算放在离数据源最近的地方。在消防预警场景中，地下车库 4G 信号差，从传感器节点到云端再返回的 RTT（Round Trip Time）至少 200-500ms，而火灾已经在烧了。改为边缘推理后，单帧推理延迟 < 50ms，网络只用于”事后回传数据”和”远程运维”。
离线可用是产品定义而非技术妥协
在很多关键场景（地下车库、矿井、地铁、船舶、隧道），网络连接不可靠甚至完全不可用。边缘计算的离线工作能力不是”降级体验”，而是产品定义里写死的硬性要求。断网也得工作——这是产品定位决定的，不是后来加上去的。
边缘与云端的分工模式
| 维度 | 边缘 | 云端 |
|---|---|---|
| 任务 | 实时推理、本地决策 | 模型训练、数据分析、远程管理 |
| 延迟 | < 50ms | 200-500ms+ |
| 网络依赖 | 无 | 必须 |
| 模型大小 | 受限（KB 级） | 不受限（GB 级） |
| 更新频率 | 低频 OTA | 持续迭代 |
模型压缩是边缘部署的关键挑战
将云端训练的大模型部署到边缘设备，需要经过 INT8 量化、模型剪枝、知识蒸馏等压缩技术。例如火眼哨兵的 1D-CNN 时序模型从训练版本压缩到 226K 参数、INT8 量化后仅 268KB，才能在 45 元的 ESP32-S3 MCU 上实时运行。
不同素材中的观点
来自 2026-06-18-woshipm-fireguard-edge-ai-fire-warning：
- 火眼哨兵团队选择边缘推理而非云端推理，核心理由是”断网也得工作”——这是消防场景的产品定义而非技术偏好。单帧推理延迟 < 50ms，代价是算法重写和模型压缩到 268KB。
- “能跑通”和”能交付”是两个产品：Mamba-YOLOv8 推理一帧 180ms（CPU），完全不能上嵌入式，最终用 ONNX Runtime + 静态 INT8 量化才压到 50ms 以内，中间 5 个月是两者之间的距离。
实用信息
适用场景
- 地下车库、矿井、地铁、船舶等网络不可靠环境
- 需要毫秒级响应的实时控制场景
- 隐私敏感的数据处理（数据不出设备）
- 大规模部署时的带宽成本控制
典型技术栈
- MCU 级：ESP32-S3、STM32 + TFLite Micro / ONNX Runtime
- 边缘 GPU：NVIDIA Jetson Nano/Orin + TensorRT
- 边缘 AI 框架：TensorFlow Lite、ONNX Runtime、Apache TVM
注意事项
- 边缘设备算力有限，模型必须经过压缩（量化/剪枝/蒸馏）
- 固件 OTA 更新机制必须可靠，否则模型迭代无法触达设备
- 边缘与云端的数据同步策略需要精心设计，避免数据丢失或重复