最近这半年“边缘AI”这个概念在我的圈子里又炸了一波。前两年大家聊边缘AI更多是拿开发板跑个分类模型图一乐或者做做技术预研但这一轮明显不一样了朋友圈里刷屏的不再是单芯片的算力跑分而是“边缘视频AI引擎 轻量化异构算力平台”这种成对出现的完整方案。我做边缘视觉落地也有几年了看到这个组合的第一反应是这东西早该火了。为什么这么说因为视频类AI项目到了边缘端真正的难点从来不是“把模型跑起来”而是从摄像头取流、硬件解码、图像预处理、模型推理、目标跟踪到结构化数据上报这一整条链路能不能在一个受限的硬件环境里稳定跑起来。模型推理只占整个工程量的三成不到剩下七成都耗在流的处理、资源的调度和硬件的适配上了。这个标题之所以能戳中很多人是因为它终于把大家踩过的坑说清楚了光有算法不行光有硬件也不行必须把“引擎”和“平台”当成一套系统来设计才能把边缘视频AI真正落到生产环境里。今天我就围绕“边缘视频AI引擎 轻量化异构算力平台”这对组合把我在实际项目中积累的拆解思路、选型方法、部署流程和避坑经验完整梳理一遍。不管你是正打算做边缘AI方案选型的技术负责人还是准备在嵌入式设备上跑视频分析的开发者这篇内容应该都能帮你少走不少弯路。1. 为什么“引擎平台”一起火边缘视频AI的落地逻辑1.1 从“云端必算”到“边缘可算”算力下沉的必然性早些年做视频AI主流方案几乎都是“摄像头采集 网络回传 云端推理”。摄像头把视频流推到机房GPU服务器做分析再把结果写回业务系统。这个模式在带宽充足、摄像头数量可控、对实时性要求不高的场景下确实成立。但真到了工厂园区、连锁门店、高速公路、港口码头这类生产环境问题立刻暴露出来。首先是带宽成本。一路1080p的摄像头如果用H.264编码码率按4Mbps算100路就是400Mbps一个千兆上行专线的上限已经被吃掉近一半而且这是24小时不间断的流量。其次还有延迟问题视频从端侧传到云端机房就算延迟控制在100ms以内加上排队、解码、推理的时间告警响应往往已经慢了好几拍。最关键的是隐私和数据合规压力很多园区和厂区不允许视频画面出园区这是硬约束。我这两年看到的趋势是算力正在从中心机房向靠近摄像头的边缘侧下沉而且下沉得非常坚决。边缘侧直接完成视频解码、推理和结构化信息提取只把“人员闯入”“车辆违停”“安全帽未佩戴”这类结论和关键截图上传到业务平台。这样做带宽占用可能不到原来的千分之一告警延迟降到秒级以内视频数据也始终留在本地网络里。这套逻辑就是边缘AI的核心价值也是“边缘可算”对“云端必算”的一次彻底重构。1.2 引擎与平台的分工软件栈和底层算力必须绑在一起很多人对“边缘视频AI引擎”和“轻量化异构算力平台”这两个词有误解以为一个是纯软件一个是纯硬件能分开选型、分开采购、分开部署。我在实际项目里验证下来的结论是这两者必须绑定在一起看因为它们之间的耦合深度远超一般应用软件和服务器之间的关系。边缘视频AI引擎本质上是一套针对视频流做端到端智能分析的软件栈它要处理的不只是模型推理这一件事。一路视频流从摄像头进来先要完成RTSP或GB28181协议解析然后硬件解码再经过缩放、裁剪、颜色空间转换排版成模型需要的输入张量推理完之后还有框坐标解码、非极大值抑制、目标跟踪、跨帧去重最后才能生成一条干净的告警结构化数据。这一整套流水线的工程质量直接决定系统能不能扛住多路并发。轻量化异构算力平台则是承载这套引擎的物理底座。它为什么叫“异构”因为视频AI任务里混合了多种不同类型的计算协议解析和业务逻辑依赖CPU、视频编解码需要专门的硬件编解码单元、模型推理则适合用GPU或NPU来加速。单一类型的处理器很难同时把这三类任务都干得漂亮所以需要CPU、NPU/GPU、编解码单元协同工作。而“轻量化”三个字强调的是功耗、体积和部署成本的约束几十瓦的整机功耗、一个交换机大小的体积、能塞进户外机箱或弱电间的形态才是这类平台能落地的关键。把这两者放在一起理解你会发现它们其实是一个整体引擎是平台上的灵魂平台是引擎的躯体。选型时必须先想清楚你要跑什么样的视频分析业务再决定用什么引擎、配什么硬件。反过来拿到一款轻量化算力平台之后也要清楚它的硬件特性解码路数上限、NPU算力、内存带宽能被什么样的引擎发挥到极致。这套“软硬一体”的思维才是这轮边缘AI浪潮里最核心的方法论。2. 边缘视频AI引擎拆解完整链路与技术决策2.1 拉流解码到结构化输出引擎的九段式流水线我给很多团队培训的时候习惯把边缘视频AI引擎拆成一条九段式流水线来讲。理解这条流水线你才能真正明白一个边缘视频AI项目的时间都花在了哪里。第一段是流接入。摄像头常用的协议有RTSP、GB28181、ONVIF。RTSP最常用但不同厂家的摄像头对RTSP实现细节各有不同有的需要携带鉴权参数有的对TCP/UDP传输的兼容性不一样这导致流接入阶段就得做不少适配工作。第二段是解码。H.264和H.265是目前绝对主流边缘设备必须支持硬件解码否则纯CPU软解一路1080p就能吃掉一个核的资源。第三段是图像预处理包括缩放、裁剪、颜色空间转换和归一化。第四段是模型推理这是整个引擎的核心但并不是计算量最大的瓶颈。第五段是后处理典型任务包括框坐标解码、NMS非极大值抑制过滤重复框、阈值过滤。第六段是目标跟踪对检测结果做时序关联给每个目标分配稳定ID这是实现“计数、徘徊、逆行”等行为分析的基础。第七段是业务规则引擎把跟踪结果映射成具体事件比如“某区域出现人员停留超过30秒”判定为徘徊告警。第八段是结构化输出把告警事件序列化成JSON或者Protobuf。第九段是消息分发通过MQTT、HTTP回调或Kafka把数据推给上层的业务平台。链路这么长意味着任何一个环节出问题都会拖垮整体性能和稳定性。早期我遇到过最典型的例子是模型在一个Jetson设备上推理只要12ms看起来性能很充裕但跑满8路摄像头之后整机帧率还是上不去。排查到最后才发现瓶颈根本不在NPU而在“RTSP拉流 软解码”这条链路上CPU被打满导致调度线程饥饿NPU反而在空转。后来换成硬解把解码从CPU剥离出来8路瞬间就跑顺了。这就是为什么我一直强调边缘视频AI引擎不是“一个模型”而是一整套围绕视频流设计的实时计算框架。明白了这个九段式流水线你再看市面上的边缘AI引擎产品就会清晰很多。有些产品会直接把GStreamer、FFmpeg、DeepStream、TensorRT这些组件打包再用自研的业务模块串联起来最终对外呈现一个统一的分析服务。这种集成方式的好处是成熟稳定缺点是调度和内存管理的复杂度很高需要团队有扎实的系统能力。另一种方式是完全自研流水线用C实现把每个环节做成插件机制。这种方式优点是可以针对业务深度优化缺点是开发周期更长没有三五个有经验的底层开发者根本玩不转。2.2 算力规划方法先评估再选型别拍脑袋我见过太多团队一上来就问“XX芯片能跑几路”这是个错误的提问方式。正确的做法是先定义业务约束再折算成具体的算力需求。折算过程其实只要抓住四个变量输入分辨率、处理帧率、模型复杂度和并发路数。算力需求的基本公式可以概括为单路所需算力约等于输入像素分辨率乘以每秒处理帧数再乘以模型单位像素计算量然后乘以并发路数。举个例子假设模型输入是640x640每帧包含的像素点大约40万个处理帧率是10FPS模型单位像素计算量按640x640输入下约7G次乘加运算估算以YOLOv8s量级为例那么单路算力需求大约就是40万像素乘10帧再乘17.5次运算量折合下来约7 TOPS的整数运算能力。这还只是推理部分的算力如果要用同样的NPU跑图像预处理或者多模型串行还要留出至少20%的余量。不过算力只是一个维度。最容易被忽略的是内存带宽。我实测过一个项目芯片标称算力8 TOPS跑单路模型延迟只要15ms但并发跑到16路的时候每路延迟飙到80ms以上。原因很简单标称算力限制了运算能力但多路视频流的图像数据搬运也占用了内存带宽带宽一旦饱和NPU和CPU都在排队等数据延迟自然就爆炸了。所以选型时不要只看TOPS一定要关注内存类型DDR4还是LPDDR5、内存位宽和实测带宽以及芯片内部是否有独立的高速缓存来降低内存访问压力。另一个容易踩的坑是“抽帧策略”。很多人以为视频是25帧就要每帧都推理实际上绝大多数业务场景根本不需要这么高的推理帧率。人员徘徊检测15帧推理一次已经非常高配了车牌识别往往5帧就够。推理帧率降下来之后算力需求和功耗都成倍下降整个方案的体积和成本都能跟着降。先把业务对延迟和召回率的要求定死再反推帧率和模型复杂度这才是边缘AI选型的正确顺序。2.3 模型如何塞进边缘设备量化、剪枝与算子适配有了算力规划下一步就是把算法模型“塞”进边缘设备。服务器端的浮点模型直接搬到边缘芯片上几乎是跑不动的通常要经过三步改造分别是量化、剪枝和算子适配。量化是第一步也是收益最大的一步。把FP32模型转成INT8理论计算量可以下降接近四倍模型体积缩小到四分之一在NPU上的推理速度能提升两到三倍。实际量化过程中INT8对激活值敏感尤其是检测头部分量化后可能出现大量误检或漏检。我自己常用的做法是先用训练集的一个子集做校准数据校准集要覆盖不同光照、不同角度的场景而不是随便拿几百张图凑数。量化之后还要做完整的端到端评测如果精度掉点超过3%就要考虑混合量化——只量化前几层卷积保留敏感的检测头为FP16或FP32。剪枝的作用是压缩模型结构。边缘设备上识别的目标通常是行人、车辆、安全帽、烟雾火焰等固定类别类别数可能只有个位数而很多预训练模型是为了几百类目标设计的这就有大量冗余参数可以裁。我在一个烟火检测项目里把YOLOv8n的检测头从COCO的80类裁到5类同时去掉部分冗余通道模型FLOPs下降了近四成精度几乎没掉。剪枝要配合微调裁完后再用业务数据继续训几十个Epoch把精度拉回来。算子适配是最后一个坑。不同芯片厂商的NPU支持的算子和类库不一样常见的不支持算子包括某些动态形状的Resize、特定模式的Transpose、部分激活函数等。一旦模型里出现不支持的算子轻则转换失败重则转换成功但推理结果完全不对。我的经验是先查厂商提供的算子支持表在模型设计阶段就避开敏感算子比如用普通卷积替代动态卷积、用CatSlice组合替代部分非标准操作。实在绕不开的就只能把这部分算子切到CPU上执行代价是增加一次NPU到CPU的数据拷贝和同步开销。所以模型改造阶段一定要有一套自动化验证脚本转完一个模型就喂一批真实图像比对输出从源头把算子兼容性问题拦截住。3. 轻量化异构算力平台选型从芯片到整机的决策路线3.1 主流硬件方案对比NPU、GPU、低功耗x86谁更适合哪类场景聊完引擎回到硬件选型上。市面上能承载边缘视频AI引擎的轻量化算力平台大致分三类以GPU为核心的方案典型代表是英伟达Jetson系列、以NPU为核心的方案典型代表是瑞芯微、地平线、昇腾等国产芯片方案、以低功耗x86 CPU搭配集成显卡或VPU的方案。先看GPU方案。Jetson系列在开发者社区里生态最成熟CUDA和TensorRT工具链完善从Orin Nano到AGX Orin算力覆盖从20TOPS到275TOPS很多算法团队的原型验证首选都是它。优点是模型迁移成本低Python快速验证和C工程化都能在同一套环境里完成缺点是拿货周期长、价格偏高而且整机方案折算到单路成本比较贵。如果你的业务场景是几十路以内、对部署数量不敏感的工业现场Jetson是稳妥选择。再看NPU方案。这类芯片通常把CPU、NPU、视频编解码单元集成在一颗SoC里代表产品包括瑞芯微RK3588内置6TOPS NPU支持多路硬编解码、地平线旭日X3和征程系列典型算力5到10TOPS级别高算力版本可以到数十TOPS、昇腾310系列等。NPU方案的强项是单位功耗下的算力比非常高整机功耗往往控制在20W到40W之间体积能做到巴掌大小价格比同算力GPU方案低一个数量级特别适合批量部署的分布式场景。弱项是模型迁移需要依赖各家的推理工具链算子兼容性差异大团队需要有适配的耐心。还有一类是低功耗x86方案常见配置是酷睿低压U或者赛扬J系列配一块Intel集显或者Movidius VPU。这类方案的优势是x86生态极其成熟硬件上跑容器、跑数据库、跑复杂的业务中间件都非常顺畅很多老牌安防厂商的IPC和NVR产品线就是这条路线。缺点是纯CPU做深度学习推理的效率偏低即使加了VPU整体能效比也被NPU和GPU甩开通常仅在部署规模不大、软件栈依赖较强的时候才会优先考虑。三类方案没有绝对的好坏关键看你的约束条件是什么。如果追求生态成熟和开发效率选GPU如果追求大规模部署的性价比选带NPU的SoC如果必须兼容现有x86业务系统那就选低功耗x86加加速卡的组合。我在实际项目里的常态是原型验证用Jetson批量落地用RK3588或昇腾方案的整机两边都留着标准化接口方便业务在平台之间切换。3.2 一个可复用的选型流程需求推导硬件的五步法既然平台选型不能拍脑袋我就把这两年沉淀出来的一个五步选型流程分享出来照着走基本能把坑都避开。第一步列出业务硬约束包括摄像头路数、分辨率、帧率、场景类别数、告警延迟要求、功耗上限、部署环境温度和网络条件。比如“8路1080p、每秒推理5帧、整机功耗不超过30W、部署在户外弱电箱”这个描述一出来硬件范围就缩小了一大半。第二步折算算力需求。按前面提到的公式估算推理算力同时用“分辨率×帧率×通道数”估算解码需求。比如8路1080p每秒推理5帧模型输入640x640那推理算力需求大概在10TOPS量级解码能力至少要支持8路1080p硬解。这一步要留20%到30%的算力冗余因为业务后期一定会加算法。第三步对照芯片规格书和官方白皮书筛选候选平台。重点关注四个指标NPU/GPU算力、视频解码路数、内存类型和带宽、整机功耗。我特别强调内存带宽就是因为在多路视频场景下它往往是真正的瓶颈这个前面已经吃过亏。第四步做一轮模型预适配。把你要跑的模型在候选芯片的推理工具链上转换一遍用真实图片跑通记录转换是否顺利、算子是否有兼容性问题、INT8量化后精度掉多少。这一步看起来费时间但比整机买回来才发现跑不动要省钱得多。第五步进行现场小规模压测。选1路、4路、8路分别跑起来观察CPU、NPU、内存带宽、芯片温度的变化曲线再看连续运行48小时是否稳定。能通过这一步的硬件基本可以放心批量采购。这个流程看起来并不复杂但每一步都需要配套的测试脚本和数据支撑。我团队里现在有一套半自动的硬件评测脚本能输出指定芯片在指定模型下的帧率、延迟、功耗和温度曲线跑完一个平台大概需要两天时间。有了这套流程我就不用再被厂商宣传的“号称能跑几十路”牵着鼻子走了。4. 实操记录8路1080p人员徘徊检测在边缘端的完整落地4.1 硬件清单与系统基础准备理论讲再多不如把一套真实可复现的方案摆出来。下面这个项目是我前阵子在一个园区做的8路1080p摄像头检测人员在重点区域徘徊逗留触发告警要求整机功耗严格控制部署在监控弱电间机柜里。最终选型是RK3588平台具体配置是瑞芯微RK3588 SoC8核CPU、6TOPS NPU、支持同时硬解8路1080p搭配8GB LPDDR4x内存和64GB eMMC存储整机功耗满载大约18W。机箱是金属外壳无风扇被动散热版本外形尺寸大概就是一台迷你路由器大小装在弱电间里完全不占空间也几乎听不到噪音。系统层面我没有用桌面版Ubuntu而是选了Ubuntu Server 22.04配合RK官方的NPU运行时和FFmpeg、GStreamer相关库。之所以用官方BSP配套的系统镜像是因为RKNPU2的驱动和运行时对内核版本有要求自己刷一个通用内核很容易踩驱动兼容性的坑。准备阶段还做了三件事把eMMC根文件系统切换到只读挂载模式业务配置和数据放独立分区配置了一个开机自动拉起服务的systemd服务另外加了一个定时清理日志的定时任务。这些看起来是琐事但在现场没有键盘鼠标的环境下一旦系统异常你得有办法自动恢复而不是跑一趟机房。4.2 引擎侧的关键实现与参数配置引擎的架构我采用的是GStreamer作为视频流处理管道加上自研的推理服务模块。每个摄像头对应一条独立的GStreamer管道管道内部完成RTSP拉流、硬解码、缩放、格式转换然后把帧数据通过共享内存队列传给推理服务。推理服务里跑着量化后的YOLOv8n模型检测类别只有person一类检测输出再交给ByteTrack跟踪模块做时序关联最后经过区域规则判断生成告警。关键配置参数这里贴一份直接参考价值很大。RTSP拉流用的协议是TCP避免UDP在弱网环境下丢包花屏解码用RK的硬件解码插件输出格式设置为NV12直接喂给NPU预处理省掉一次颜色空间转换的开销。推理帧率设置为5FPS因为人员徘徊检测的业务延迟要求是2秒内5FPS足够覆盖一个行人在画面中连续移动形成的轨迹如果追求更平滑的跟踪可以升到8FPS但算力消耗会明显增加。跟踪模块里我设置了检测置信度阈值0.45、NMS阈值0.5跟踪最大生存帧数30帧。区域规则这块兴趣区域用多边形定义判断逻辑很简单同一个跟踪ID的轨迹中心点连续停留超过20秒即触发告警。GStreamer管道大致长这样gst-launch-1.0 rtspsrc locationrtsp://admin:password192.168.1.64:554/stream1 \ latency200 protocolstcp \ ! rtph264depay ! h264parse ! mppvideodec \ ! videoconvert ! video/x-raw,formatNV12,width960,height544 \ ! fdsink fd1 syncfalse这里把解码后的图像统一缩放到了960x544再送入共享内存队列。为什么不是直接1920x1080因为模型输入是640x640与其在NPU预处理阶段做大幅缩放不如让解码后直接缩放节省内存带宽同时960x544也保留了足够的细节供业务截图使用。推理服务端我保留了一个JPEG编码通道告警触发时对原图编码并推送到管理平台方便人工复核。整个系统跑起来之后我又做了一轮线程绑核优化。GStreamer的拉流线程绑定到CPU0和CPU1推理服务的预处理线程绑定到CPU2NPU运行时由内核自动调度网络发送线程绑定到CPU6。绑核之后总线延迟抖动明显减少帧率曲线更平稳了。这个优化的前提是芯片支持CPU亲和性设置RK3588的8核里面不同核的调度特性有差异把实时性要求高的线程绑在独立核上能有效避免和后台任务互相干扰。4.3 实测数据与真实踩坑记录系统稳定运行两周后的实测数据大概是这样的8路1080p视频流全部接入视频解码占用的CPU大约在15%左右主要花在RTSP协议解析和管道调度上NPU的占用率维持在45%到65%之间总内存占用4.5GB整机功耗实测平均16W最高不超过21W。从摄像头画面变化到告警消息推到业务平台的端到端延迟绝大多数情况下在1.2秒到1.8秒之间符合设计指标。这个结果验证了前面“算力规划软硬协同”这套方法的正确性。但整个落地过程并不是一帆风顺的几个大坑值得记录。第一个坑是NPU内存泄漏刚开始每次推理服务处理新模型输入都会小幅增长内存占用跑了两三个小时后系统内存被吃满容器直接被OOM杀掉。排查后定位到是RKNN运行时在重复创建输入张量时没有做内存复用改成启动时一次性分配缓冲区问题就消失了。第二个坑是RTSP断流后的重连风暴某个夜班场景下摄像头因供电问题反复掉线GStreamer管道每次都立即重连导致多个管道同时尝试拉流RK3588的解码单元瞬间被打满系统几乎无响应。最后给每路管道加了指数退避重连策略第一次1秒退避第二次2秒上限30秒才彻底解决。第三个坑是IDE节点的电源能力室外交换机的POE供电只能输出15W而整机峰值功耗达到21W导致设备间歇性掉电重启。后来把设备单独接到自带电源的插座上整机运行恢复正常。这些坑每一个都很有代表性后面我把它们扩展成了一份排查清单放到下一节一起讲。总之这个项目从选型到稳定运行前后用了一周左右。如果把中间踩坑的时间也算进去其实按五步法提前做一轮48小时压测至少能再压缩两到三天的调试时间。5. 边缘AI部署的常见问题排查与避坑清单5.1 六类高频问题与处理实录做边缘视频AI这一年多来我维护了一个问题库凡是在项目现场踩过坑并解决的问题都会记录进去。这里挑六类出现频率最高的整理成一张速查表再做详细说明。问题现象根因方向快速处理方式多种视频跑满但帧率上不去内存带宽饱和或软解码占CPU确认解码为硬解降低预处理分辨率减少不必要的帧拷贝模型转换失败算子不支持查算子支持表替换敏感算子必要时切部分算子到CPU跑着跑着内存持续上涨推理框架未复用缓冲区检查是否有每帧创建的张量改为启动时统一分配摄像头掉线后系统卡死重连风暴指数退避重连限制同一时刻拉流数告警延迟时大时小调度抖动线程绑核把实时任务和后台任务隔离设备运行几天后性能下降散热降频或日志累积检查芯片温度曲线增加散热片/风扇日志独立分区定期清理第一类问题的根因最常见的是解码软硬不分。我遇到过不止一次芯片明明有硬件解码单元但GStreamer管道里没装对插件结果全走软解CPU瞬间饱和。排查方式很简单看CPU占用率软解8路1080p的CPU占用会超过80%而硬解通常压在20%以下。确认硬解之后如果还慢就要计算内存带宽了可以把分辨率往下调或者减少不必要的缩放次数。第三类内存泄漏属于隐蔽型问题。很多推理框架都有内存池机制正常情况下每帧数据会从池里申请、用完释放。如果框架版本有bug或者代码里显式创建了张量但忘记释放内存就会持续上涨。排查时可以用内存监控工具观察进程的RSS曲线如果稳定上涨就基本是泄漏然后把推理主循环里的申请释放逻辑逐段检查重点关照非本框架创建的临时对象。至于第五类延迟抖动多线程环境下的调度抖动几乎无法彻底消除但能控制在可接受范围。我做的线程绑核优化实测能让P95延迟下降约30%。如果你的部署环境是多容器共享CPU还要关注CPU配额和CGroup的隔离配置避免邻居容器抢占资源。5.2 最容易忽略的三件小事供电、网络、日志这三件事技术上没什么难度但每件都坏过我的大事。供电问题在边缘设备上极其隐蔽。开发时用的是实验室适配器功率余量充足但现场设备往往接在POE交换机、工控插排或监控机柜的电源分配单元上这些电源给多台设备供电之后单路输出能力可能已经衰减。我之前遇到过的情况是设备看起来能正常启动但是一跑满8路视频就重启排查了好几天才定位到是供电不足。这里有个实用建议设备满载跑压力测试时用功率计实测整机功耗再确认现场电源至少留有30%的余量最好给边缘设备配独立电源通道。网络问题更多出在细节上。摄像头和边缘设备之间如果走的是多级交换MTU不一致会导致视频流偶发花屏有些弱电间跨楼层用光纤光收发器的衰减会影响RTSP长连接稳定性。部署前先把整个链路的MTU、VLAN划分和带宽占用跑一遍不要等到现场再处理。另外所有边缘设备最好固定IP并把MAC和IP绑定避免DHCP地址漂移导致整个视频分析服务断线。日志问题看着最不起眼实际影响很大。边缘设备存储空间普遍有限如果日志没有做轮转和清理两三个月的运行数据就能把eMMC写满轻则服务异常重则整机启动失败。我现在每个项目都要求日志必须独立分区按大小或天数自动轮转核心告警日志再同步一份到远端。温度曲线和NPU利用率这类监控数据也会定时清理但保留的时间窗口要覆盖最近一次的故障排查窗口我一般保留7天到14天。5.3 部署前就应该定死的一组业务约束最后一个建议也是我认为整篇内容里最值的经验在项目启动之前务必和业务方把一组约束条件以书面形式定死。需要明确的至少包括处理帧率要求也就是画面变化后能在几秒内收到告警识别准确率红线误报率和漏报率各能接受多少视频数据的保存时长和保存位置要求摄像头数量未来一年的扩容预期设备的工作温度范围户外还是室内以及是否有断网自恢复的需求。这些约束直接决定模型选型、帧率策略、算力规划和存储方案。我见过太多项目算法工程师埋头调模型硬件工程师闷头选芯片业务方以为“AI什么都能干”最后交付时才发现漏报率高、告警延迟大、扩容空间不足整个方案推倒重来。说实话边缘AI这个方向现在不缺算法也不缺芯片最缺的是能把端到端链路吃透、能把软硬件统筹规划的人。只要把引擎和平台当成一个整体来设计在选型前把业务约束量化清楚在部署时把电源、网络、日志这些底层稳定性问题处理好边缘视频AI项目没有想象中那么难落地。我个人在实际操作中最大的体会就是别跟风追新架构先把工程细节做扎实。芯片年年出新模型月月迭代但边缘视频AI落地的基本功——流的处理、资源的调度、硬件的适配、现场的故障排查这些能力无论平台怎么换都不过时。希望这篇长文能给你在边缘视频AI的项目里提供一些实战层面的帮助也欢迎你在评论区分享自己踩过的那一两个特别难忘的坑。