PrintGuard 2.0 — ShuffleNetV2 + 少样本原型网络，通过 LiteRT 的 TFLite，约 5 MB，可在浏览器（Pyodide）和 CPython 上无需修改直接运行 [P]

大家好，大约一年前我在这里分享了 PrintGuard，它是一个基于 ShuffleNetV2 骨干网络并由原型网络分类的少样本 FDM 故障检测器——来自我论文的模型，附带了一个 hub 和 Web UI。v2.0 今天发布，是对模型周围一切的完全重写，所以我想带大家了解有哪些变化和哪些没有变化。 没有变化的是模型。它仍然是 ShuffleNetV2 编码器，通过最近原型进行分类，训练用于少样本 FDM 故障检测，代码在 [Edge-FDM-Fault-Detection](https://github.com/oliverbravery/Edge-FDM-Fault-Detection) 中（仓库里附有技术说明）。 改变的是运行时：模型现在是通过 LiteRT 导出的约 5 MB TFLite 文件，通过最近原型进行分类，并带有每台打印机的灵敏度和阈值滑块，直接映射到原型距离——因此您可以针对相机和光线进行调整，而无需重新训练。 对这个子社区来说有趣的是模型周围的架构。v2.0 是一个单一的 Python 引擎，可在 CPython（hub 模式）和浏览器中的 Pyodide（本地模式）上无需修改运行。所有特定于模式的内容都限制在每个运行时的一个 `Platform` 实现中——这两种模式不会出现偏差，因为它们执行相同的文件。 `Platform` 合约上的方法正是那些不可移植的方法：`infer(rgb)`、`discover_cameras()`、`open_camera(id, source)`、`http(...)`、`encode_jpeg(rgb)`、`load_state` / `save_state`。 在 CPython 端，`infer` 是 CPU 线程上的 `ai-edge-litert`，`discover_cameras` 遍历 MediaMTX 路径列表，`open_camera` 是每个 RTSP 流的 PyAV 读取器线程。 在浏览器端，`infer` 是通过 JS 桥接的 WASM 中的 LiteRT.js，`discover_cameras` 是 `enumerateDevices()`，`open_camera` 是 `getUserMedia` 加上 canvas 抓取。 UI 仅用于展示，并使用统一的 JSON 命令/事件协议——在 hub 模式下通过 WebSocket，在本地模式下通过页面内的 Pyodide 桥接。引擎无法分辨它运行在哪种传输方式上。 **没有其他任何地方存在特定于模式的逻辑**；如果某个功能需要运行时服务，它会在两侧扩展 `Platform` 合约。 推理调度完全动态且具有公平意识：1. 对观察到的推理延迟的平滑估计持续得出可持续的总速率（`workers / latency`）。2. 该容量在使用的相机之间进行水填充（最大最小公平）：没有相机被分配超过其原生 fps 的帧率，多余部分流向能够使用的相机。3. 空闲工作线程选取最过期的相机，并在调度时抓取其**最新**帧。帧携带序列标识，因此同一帧永远不会被推理两次，结果始终描述当前状态，而不是积压。 在 RTSP 上，MediaMTX 在连接时爆发缓冲的 GOP，因此流 fps 从 SDP `average_rate` 中获取（如果可用），否则仅在预热后测量。 缺陷流水线是每台打印机得分流之上的监控器。连续 `N` 帧 `score ≥ threshold` 会触发在链接的 OctoPrint 或 Moonraker 服务上配置的操作（仅警报、暂停或取消），失败时重试；警报事件携带操作及其结果，UI 错误信息流获得一份副本，快照发送到每个启用的通知渠道（ntfy、Telegram、Discord）。 故障安全行为是我最希望得到反馈的部分，因为我有强烈的看法。打印机的*监视*状态门控推理： |链接服务报告|是否监视？|原因| |:-|:-|:-| |未链接服务|是|没有可门控的依据| |`printing`|是|作业需要监控| |无状态 / `unknown`|是|无法判断 → 监视| |`offline`（不可达）|是|失去信号不能停止监控| |`idle` / `paused` / `error`|否（待机）|明确不在打印| 只有*明确*的“不在打印”才会停止推理。然后看门狗会在相机断开、画面冻结或打印机服务停止响应时，在仪表板*和*通过通知渠道发出警告，并宣布暂停失败，绝不忽略。 我很想听听这种立场如何与那些在打印机服务中运行多个可靠性不一的打印机的人互动。 有一个[实时浏览器演示](https://oliverbravery.github.io/PrintGuard/)（整个引擎在 Pyodide + LiteRT.js WASM 中），[Docker 镜像](https://github.com/oliverbravery/PrintGuard/pkgs/container/printguard)支持多架构，[架构文档](https://github.com/oliverbravery/PrintGuard/blob/main/docs/architecture.md)更详细地介绍了上述所有内容，并附有引擎布局和缺陷流水线的图表。 这是一个重大版本——1.x 的任何内容都无法迁移，2.0 hub 从全新配置开始。非常欢迎反馈问题，特别是关于公平调度器、CORS / 混合内容 / `host.docker.internal` 边缘情况以及 LiteRT ↔ Pyodide 桥接的问题。让我们保持故障检测的开源、本地化和对所有人可访问。