嵌入式检测常见问题：卡顿、掉帧、误检、漏检排查做嵌入式视觉项目，代码跑起来只是第一步。真正让人头秃的是各种"玄学问题"：明明测试好的模型，现场就是卡顿；实验室精度 95%，客户现场误检满天飞。这篇把实际项目中踩过的坑系统梳理一遍。卡顿问题排查卡顿的表现是画面一卡一卡的，不像视频那样流畅。根本原因是处理速度跟不上采集速度，帧之间时间间隔不均匀。排查方向1：CPU/NPU 占用过高先用htop看 CPU 占用：htop如果某个核心长期 100%，就是瓶颈所在。常见情况：ONNX Runtime 默认用所有 CPU 核心，和采集线程抢资源解决：限制推理线程数，留核心给采集和显示session_options=ort.SessionOptions()session_options.intra_op_num_threads=4# 不要用满所有核心NPU 占用可以用 RK 的rknn_server工具查看，或者看/sys/kernel/debug/rknpu下的状态文件。排查方向2：内存不足嵌入式板子内存就 2G/4G，Python + OpenCV + ONNX Runtime 本身就吃几百 MB，再开几个大数组就紧张了。free-h# 看 available 列，如果低于 200MB 就危险了内存不足时系统会频繁 swap（交换到磁盘），磁盘 IO 变成瓶颈，整个系统变卡。解决：预分配内存，复用 buffer，避免频繁np.zeros关闭不必要的后台进程如果模型大，考虑量化到 INT8 减少内存占用排查方向3：IO 瓶颈CSI 摄像头走 MIPI 总线一般没问题，USB 摄像头在带宽紧张时会卡。特别是 USB 2.0（480Mbps 理论带宽），640×480 30FPS YUYV 格式需要约 147Mbps，两个摄像头就超了。排查方法：# 查看USB设备lsusb-t# 看USB版本，480M=USB2.0, 5000M=USB3.0解决：USB 摄像头用 MJPEG 格式压缩传输，减少带宽多摄像头分到不同 USB 总线上用v4l2-ctl --list-formats-ext看摄像头支持的格式# 用MJPEG格式采集，CPU解码cap.set(cv2.CAP_PROP_FOURCC,cv2.VideoWriter_fourcc('M','J','P','G'))掉帧问题分析掉帧和卡顿相关但不同。卡顿是"慢"，掉帧是"丢"。摄像头出了 30 帧，你只处理了 15 帧，丢了 15 帧。排查方向1：采集线程跟不上如果VideoCapture.read()本身就很慢，问题在采集层。# 测采集速度cap=cv2.VideoCapture(0)times=[]for_inrange(100):t=time.perf_counter()ret,frame=cap.read()times.append(time.perf_counter()-t)avg=sum(times)/len(times)*1000print(