2. MERLIC运行时架构与资源模型

MERLIC 的运行时并不是一个“单线程跑完所有事”的黑盒，而是由若干职责明确的子系统协同工作：图像采集负责把相机数据搬进内存，处理管线负责执行工具链，通信负责与 PLC、机器人或上位系统交换结果，显示负责把图像与结果渲染到操作界面。理解这四个环节各自的资源占用特征，是后续做性能优化与现场调试的前提。因为当你发现“界面卡顿”时，问题可能出在显示渲染，而不是处理管线；当你发现“节拍变慢”时，瓶颈可能在采集等待或通信握手，而不是工具本身。

一、四个环节的资源画像

先建立整体认识。MERLIC 运行时中，图像采集主要消耗 CPU 与内存带宽，GPU 占用通常很低；处理管线是 CPU 密集型环节，部分工具（如匹配、滤波、深度学习推理）会显著调用 GPU；通信以 CPU 和网络 I/O 为主，内存占用小但延迟敏感；显示则同时涉及 CPU（图像缩放、叠加绘制）与 GPU（纹理上传、合成渲染），在高分辨率、高刷新率下 GPU 占用会明显上升。

二、图像采集：带宽与缓冲是核心

采集环节的资源消耗主要来自三部分：相机驱动取流、图像数据拷贝、以及缓冲区管理。以一台 500 万像素彩色相机、30 fps 为例，单帧原始数据约 15 MB（Bayer 或 RGB 取决于传输格式），每秒需要搬运约 450 MB。如果使用 GigE Vision，还要考虑网络包重组带来的 CPU 开销；如果使用 USB3 Vision，则 CPU 占用相对低，但受 USB 控制器带宽限制。

MERLIC 在采集端通常采用双缓冲或环形缓冲策略。缓冲数量不足会导致丢帧或采集线程阻塞；缓冲过多则增加内存占用与延迟。现场调试时，可以观察采集线程的 CPU 占用是否稳定：如果出现周期性尖峰，往往是缓冲区切换或驱动重传导致。建议将采集缓冲区设置为 3～5 帧，既能吸收短时抖动，又不会引入过大延迟。

三、处理管线：CPU 密集，GPU 按需介入

处理管线是 MERLIC 的核心计算环节。每个工具（如模板匹配、Blob 分析、测量、OCR、深度学习推理）在管线中按顺序执行，前一个工具的输出作为后一个工具的输入。传统 2D 工具以 CPU 为主，占用与图像分辨率、ROI 大小、搜索范围强相关。例如，模板匹配的耗时大致与搜索区域面积成正比；如果能在管线中先做 ROI 裁剪，再送入匹配工具，CPU 占用可以显著下降。

深度学习类工具（如分类、检测、分割）会调用 GPU。此时需要关注显存占用与 GPU 利用率两个指标。显存不足会导致推理回退到 CPU，速度骤降；GPU 利用率长期接近 100% 则说明推理是瓶颈，需要降低输入分辨率、减少模型复杂度或增加批处理。MERLIC 允许在工具层面配置推理设备与精度模式，现场应根据节拍要求权衡。

四、通信：延迟敏感，占用不高但影响节拍

通信环节包括与 PLC 的周期数据交换、与机器人的触发握手、以及与上位系统的结果上报。MERLIC 支持多种通信方式，如 TCP/IP、Modbus TCP、PROFINET、OPC UA 等。通信本身的 CPU 与内存占用通常不高，但它对节拍的影响往往被低估：如果处理管线在等待通信确认，或者通信线程与处理线程争抢锁，就会造成管线停顿。

现场调试时，可以观察通信周期与处理周期的关系。理想情况下，通信应在处理管线执行期间并行完成，而不是串行等待。如果发现通信延迟波动大，应检查网络配置、交换机负载以及对端设备的响应时间。对于硬实时要求高的场景，建议将通信与处理放在不同线程，并设置合理的超时与重试策略。

五、显示：容易被忽视的 GPU 消耗大户

显示环节负责将图像、ROI、结果叠加层渲染到 MERLIC 的操作界面或自定义前端。很多人会忽略显示的资源消耗，但在高分辨率、高刷新率、多图层叠加的场景下，GPU 占用可能超过处理管线。例如，在 4K 显示器上以 60 fps 刷新，同时叠加多个 ROI 框、文字标签和结果图形，GPU 需要频繁上传纹理并执行合成，显存带宽和算力都会被占用。

优化显示环节的思路包括：降低预览刷新率（如从 60 fps 降到 30 fps）、减少不必要的叠加层、使用更小的预览分辨率、以及避免在显示线程中做图像格式转换。如果现场只需要看结果数值而不需要实时图像，可以关闭或降低图像预览，把 GPU 资源留给处理管线。

六、资源模型小结与现场判断

把四个环节放在一起看，MERLIC 运行时的资源模型可以概括为：采集吃带宽，处理吃 CPU/GPU，通信吃延迟，显示吃 GPU。现场遇到性能问题时，先定位瓶颈环节，再针对性优化，而不是盲目升级硬件或降低所有参数。

在实际项目中，建议先用系统监控工具（如 Windows 任务管理器、GPU-Z、性能计数器）记录各环节的资源曲线，再结合 MERLIC 的日志与工具耗时统计，判断瓶颈到底在哪。只有把资源模型和现场数据对应起来，后续的优化才有依据，而不是凭感觉调参。