Chinese-CLIP 与 SigLIP2：录像检索模型的效果、性能和硬件选型

资源有限的 CPU 或 RK3588 设备优先选 Chinese-CLIP RN50；以中文检索为主、算力充足的 PC 或服务器，优先对比 Chinese-CLIP ViT-B/16；需要多语言和更广语义覆盖时，再评估 SigLIP2 Base 224。 SigLIP2 更现代，并不自动等于中文监控检索更准确。

本文比较图文编码模型，不把目标检测、视频硬解码和向量数据库的性能混为一谈。公开基准用于判断模型潜力，设备实测用于判断部署成本，最终选择还应使用同一批标注监控录像验证。

三种模型有什么差别

Chinese-CLIP 的参数来自官方模型表。SigLIP2 按Google 官方 checkpoint的张量元数据计数：视觉塔 92,884,224、文本塔 282,303,744，另有两个标量，总计 375,187,970。这里区分了约 86M 的 ViT-B 骨干与含池化头的完整视觉塔。

持续建立录像索引主要运行图像编码器；用户输入搜索词时再运行文本编码器。因此，SigLIP2 的整套模型比 ViT-B/16 大很多，并不代表它每帧图像编码也同样多几倍计算量。反过来，文本查询少也不代表文本塔不占内存：预热、缓存和并行工作实例可能保留它。

中文效果：公开基准能说明什么

下表使用 Chinese-CLIP 官方公开的 zero-shot R@1，即正确结果排在第一位的比例。单位为百分比，提升是百分点；未与 fine-tune 结果混用。

数据见官方 Results.md。MUGE 的该表只公开文字找图像；不列来源未确认的反向分数。这组结果支持把 ViT-B/16 作为中文检索的优先对比候选，但不能直接换算为监控录像的准确率或漏检率。

SigLIP2 的论文讨论多语言、语义理解、定位和密集特征的改进，并使用多种训练目标。它们不等于与 Chinese-CLIP 在同一中文监控语料、同一抽帧策略上的对照结果。当前不能据此宣布 SigLIP2 Base 一定超过 Chinese-CLIP ViT-B/16，也不能把它命名为已证明更好的监控高质量档。

对于衣着、动作、场景和对象关系，应使用同一批标注片段比较。例如“大类别正确、颜色错误”和“对象正确、动作错误”应单独统计。全帧语义编码也不是小目标检测器；远处小物体、遮挡和夜间画面不能只靠更大的模型解决。

CUDA、OpenVINO、RK NPU 和 AMD 怎么选

CUDA 是 NVIDIA 的推理路径，OpenVINO 的 Intel GPU 路径也不能当成 AMD 加速。Windows AMD 可研究 ONNX Runtime DirectML，Linux AMD 可研究 MIGraphX，其中 Windows x64 DirectML 已接入，Linux MIGraphX 尚未接入。

上游ROCm Execution Provider 说明还提示 ORT 1.23 起移除该旧后端。驱动、GPU 型号和运行时版本必须一起验证，不能根据显卡品牌推断任意模型都能部署。AMD 视频硬解码与 AMD 图文模型推理也是两项不同能力。

RN50 的卷积结构通常更容易做边缘部署。ViT 类模型需要关注 Attention、LayerNorm、Softmax、矩阵乘法及图转换。对于 RKNN，应检查转换后的执行图、CPU 辅助工作和数据搬运，而不是只看 NPU 标称 TOPS。SigLIP2 的视觉塔与 ViT-B/16 接近量级；其工程成本还包括更大的文本塔及分词器。现有三个转换版本已经通过基本验证，后续模型版本仍需重新验收。

已测设备上的图像编码延迟

以下样本来自 2026-10-02 前后的已验模型版本，三款模型均采用各自配套预处理。数值是热态单图路径中位数，不含冷启动，不是整机可承诺的录像路数。

在这组 RK3588 样本中，ViT-B/16 与 SigLIP2 的图像耗时相近，RN50 明显更轻。不能由此给其他 GPU、另一种量化方案或另一套 NPU 核心配置套用固定吞吐比例。B580 和 AMD 没有在本文列出同口径延迟，就不填猜测的 FPS。

三款模型均通过模型装配和基本图文检索验证，但真实中文监控效果还缺统一标注语料对照。不同模型的余弦分数不可直接互相比大小，参考实现输出一致也不能替代检索准确率评估。

内存、显存与 NPU 占用怎么估算

参数存储的基础公式是：参数数量 × 每参数字节数。下表使用十进制 MB，是理论参数存储量，不是模型文件大小、进程 RSS、GPU 显存峰值或已验量化部署承诺。

真实峰值还包括激活、推理工作区、运行时 arena、图优化或编译缓存、输入输出缓冲，以及多个并行实例。模型压缩后的下载大小也不能等同于解压后的权重或常驻内存。INT8 还涉及校准、算子覆盖和准确率损失；不代表本产品三模型已全部采用 INT8。

利用率是时间窗口内的忙碌程度。低抽帧率下，GPU 或 NPU 可以短时很忙、长时间空闲；单个进程 100% CPU 也可能只是占满一颗核心。应同时记录单帧延迟、持续吞吐、峰值内存、功耗和业务响应时间，不据一张占用率截图给模型排名。

录像索引需要多少吞吐

后台图像编码需求约为 参与路数 × 每路抽帧率，不是摄像头原始帧率。图像向量入库后，文字查询产生自己的向量，再在同一模型空间中搜索。

flowchart LR
  V[正在录制的视频] --> S[按预算取画面] --> I[图像编码器] --> Q[对应模型的向量索引]
  T[用户查询文字] --> E[文本编码器] --> Q
  Q --> R[定位录像时间并回放]

例如 16 路、每秒 2 帧会请求 32 次图像编码/秒。按上述 RK3588 单链 RN50 中位延迟计算，单链理想上限约 20.5 次/秒，尚未计入其他工作，因此不能说 32 次/秒在该设备上必然轻松。

若改为 16 路、每五秒 1 帧，请求量为 3.2 次/秒。用请求量 × 单帧秒数估算单链推理忙碌时间，RN50 约 15.6%，ViT-B/16 约 60.4%。这不是整机 CPU/NPU 利用率，也没有证明多工作实例会线性加速。AKStream.Next 还设有节点总编码预算，超出预算的采样会延后，不能假定每路都达到请求帧率。

向量存储也会随采样累积。仅原始 FP32 向量，百万条约需 RN50 4.096 GB、ViT-B/16 2.048 GB、SigLIP2 3.072 GB，还未计入索引和元数据。因此 RN50 的推理较轻，不代表其向量库也最小。

实际选择与验收方法

统一使用同一批录像、同样抽帧、查询和正确答案；分别记录 R@1/R@5、误命中、漏片段和定位误差。性能测试应分冷启动与热态，并测 batch=1、长期采样、并发查询和向量建索引期间的完整流程。单独记录图像与文字编码、取帧、入库和查询耗时，才知道瓶颈是否真的在模型。

模型、配套分词器和预处理共同定义向量空间。切换模型后使用独立索引，不能把 RN50 的向量交给 ViT-B/16 或 SigLIP2 查询。应用的默认模型仍是 RN50；公开基准更高不意味着自动改变每台边缘设备的默认配置。

下载与离线安装

模型权重及大型 CUDA/OpenVINO 运行库独立分发；首次配置可以允许下载，也可安装后再补齐。官网提供 R2 下载与本机中转两个入口，文件保存后还须校验 SHA256。没有互联网时，在联网电脑下载对应模型/后端包，校验后拷贝到设备，按 WebUI 的离线说明解压到模型目录；运行库按对应平台安装并重启加载。

下载文件不会自动开启智能检索，也不替代功能授权。更换权重内容、分词器或向量维度应使用兼容的模型空间与客户端版本，不能仅用一个更大的模型包覆盖旧索引。

Windows x64 和 ARM64 正式包已内置对应架构的 DirectML 与 ONNX Runtime，无需上传 R2 或下载 DirectML 包；模型仍使用单独的 ONNX 权重。x64 的 AMD RN50 已实机验收，ARM64 已接入原生运行库和 Qualcomm GPU 检测，Adreno 推理性能仍待实机验证；虚拟机不保证具备可用 DirectX 12 GPU。切换后端后需重启服务加载运行库。