在 PCB 生产线上，缺陷检测并不只是模型推理问题。现场系统需要同时处理两类工作：一类是对历史图像或待检图片进行集中质检、留存标注结果；另一类是持续接入产线视频流，在节拍约束下把检测结果送回给管理端。两类工作对吞吐、延迟、存储和运维的要求不同。若把它们压在同一条处理链路中，批处理容易挤占实时资源，实时流又难以提供完整的追溯与管理能力。
一、方案概览：把检测、流媒体和管理端放到同一运行边界
独角鲸PCB将 PCB 缺陷检测组织为一个可由 Web 端统一管理的系统：批量图片检测由 YOLOv5 链路承担，实时 RTSP 视频流检测由 YOLOv8 链路承担；Flask 提供管理界面和 RESTful API，MediaMTX 负责 RTSP 流服务，SQLite 承担本地检测历史与统计数据的轻量化存储。系统面向划痕、缺损、污渍和气泡等常见 PCB 缺陷的识别与分类。
项目采用 MIT 开源许可证发布，支持商业化使用，并允许在遵守许可证条款的前提下进行修改、分发与二次开发。
这种组合的重点不在于把多个组件放进同一项目，而在于划清职责边界。管理端负责配置、任务控制、历史查询和资源观察；检测执行端负责解析输入并调用对应模型；流媒体服务保持 RTSP 接入与多端观看能力；本地数据层保存需要回看的检测结果。对需要先从单台产线或边缘设备落地的场景，这种边界比一开始引入复杂分布式架构更直接。
二、双检测链路：把离线质检与在线响应分开
批量图像检测和实时流检测看似都在调用目标检测模型，实际上面对的是不同的输入节奏。批量任务可以以文件集为单位上传和执行，更关注结果标注、报告生成与历史回溯；RTSP 检测则要面对持续到达的帧，需要控制排队、解码、推理和回传的累计延迟。独角鲸PCB 以 YOLOv5 处理批量检测、以 YOLOv8 处理实时流，避免让单一路径同时兼顾两类调度模型。
管理端可在检测页面配置 RTSP 地址、检测参数和模型选择，并通过仪表板查看运行状态与缺陷统计。这样，操作人员不必直接进入推理脚本修改参数；任务配置与日常检查被放到浏览器界面中，适合由产线质检、设备运维和算法人员分别承担各自的操作环节。历史记录支持按时间、缺陷类型检索并导出报告，使在线检测不止停留在当前画面。
三、实时路径的取舍：硬件加速、低延迟与跳帧控制
系统以 22+ FPS 实时检测、约 30 ms 端到端延迟和 95% 以上准确率作为设计指标；这些指标不应视为脱离硬件、样本分布和测量方法的通用结论。
跳帧和低延迟模式是实时链路中值得关注的工程决策。输入帧持续积压时，逐帧推理会让展示结果越来越滞后；选择跳过部分帧可控制计算负载，把有限推理资源优先用于较新的画面。其代价是可能遗漏短暂出现的缺陷，因此跳帧比例应与产线速度、相机帧率、PCB 运动距离和可接受漏检窗口一起确定，而不是作为固定开关。
四、控制面与数据面：让结果能被查看、筛选和追溯
Flask 服务承担系统控制面：Web 仪表板、检测控制、历史记录、系统监控和设置页面均通过该服务对外呈现。RESTful API 让外部系统或前端页面能够以统一方式访问功能，但实际可调用的接口路径、字段与鉴权策略仍应以代码和接口文档为准。将控制面与模型执行路径拆开后，算法升级不必等同于管理页面重构，检测参数调整也不必直接改动模型逻辑。
项目采用 SQLite 作为本地轻量级存储，适合保存单机或边缘设备上的检测记录、统计信息和配置数据。它的优势是部署简单、无需额外数据库服务；相应地，在多工位并发写入、跨设备汇总或长期存放大量图片时，需要评估文件体积、备份策略、锁竞争和数据迁移路径。若后续需要集中管理多条产线，可在不改变检测链路职责的前提下，把数据汇聚层替换为更适合并发和中心化运维的存储服务。
五、部署与安全：生产上线前先收紧默认边界
系统运行需要 Python 3.8 及以上版本、Linux 环境（推荐 Ubuntu 18.04 及以上）、Sophon BM1684X 开发板或兼容设备、至少 4 GB 内存和 20 GB 存储。服务启动后，Web 管理端默认使用 5000 端口，MediaMTX 的 RTSP 示例地址使用 8554 端口。部署时应把数据库路径、监听地址、端口与 RTSP 流地址放在可管理的配置中，并为设备 SDK、模型文件和流媒体进程建立明确的启动顺序与故障检查项。
系统默认账号为 admin、默认密码为 admin123；生产环境应立即替换默认凭据。实际投产时，这一步应视为最低要求：应关闭或替换默认凭据，使用强密码和最小权限角色，限制管理端与 RTSP 端口的网络暴露范围，并对检测历史、导出文件和配置备份设置访问控制。系统监控页面可用于观察 CPU、内存和磁盘资源，但还应将推理进程存活、RTSP 连接状态、磁盘余量和异常重启纳入日常巡检。
六、验收应围绕生产链路，而不是只看单项模型指标
对 独角鲸PCB 这类系统，建议把验收拆为四组：首先验证批量图片的上传、推理、标注结果和报告导出是否能形成闭环；其次验证 RTSP 断连、重连、持续输入和多路接入时的延迟与稳定性；再验证用户角色、默认凭据替换、历史数据检索和备份恢复；最后在目标 BM1684X 设备、实际相机分辨率和代表性缺陷样本上记录 FPS、端到端延迟、漏检和误检情况。只有测量口径与生产输入一致，性能数字才具备工程决策价值。
结语
独角鲸PCB 的设计价值，在于把批量图片检测、RTSP 在线检测、流媒体接入和 Web 运维放在清晰的职责边界内。YOLOv5 与 YOLOv8 的双链路分工回应了离线回溯和在线响应的不同需求，BM1684X 加速与跳帧策略则面向边缘侧的资源和时延约束。对于准备从单线试点开始的 PCB 缺陷检测项目，这套架构提供了可继续验证和扩展的起点；后续重点应放在真实产线数据、设备环境和安全配置上的验收，而非脱离上下文地比较单一指标。