关于飞牛 AI 相册模型包的几点技术反馈
我对飞牛 AI 相册相关模型包做了解包、ONNX 结构检查和文件哈希比对。这里主要想反馈三件事：模型来源与授权说明不够清楚、相同基础运行时被重复分发，以及模型没有按不同硬件提供精度和性能优化。
下面的结论都来自本地下载文件的实际检查，主要是技术反馈。授权部分只作提醒，不对飞牛的实际授权情况作判断。
一、模型来源与授权说明
目前下载到的模型包包括：
人脸识别-标准模型-1.0.0.zip智能识别-基础模型-1.0.0.zip智能识别-增强模型-1.0.0（需8G内存）.zip
这些文件采用带密码的压缩包，并主要通过网盘和种子分发。密码保护和分发渠道本身不能说明是否获得授权，但会增加用户核对模型来源、版本和文件完整性的难度。（PS: 这个密码我不会分享。）
其实一年前我就发过帖子，当时就很疑惑：为什么飞牛会采用“网盘 + 种子”这种方式分发模型。
1. 文件比对结果
解压 人脸识别-标准模型-1.0.0.zip，其中的 face-model-1.0.0 包含三个 ONNX 文件：
det.onnx
rec.onnx
genderage.onnx
将它们与 InsightFace v0.7 Model Zoo 的 buffalo_l.zip 逐字节比较，结果如下：
| 飞牛模型 |
buffalo_l 对应文件 |
文件大小 |
SHA256 |
比对结果 |
det.onnx |
det_10g.onnx |
16,923,827 bytes |
5838f7fe053675b1c7a08b633df49e7af5495cee0493c7dcf6697200b85b5b91 |
完全相同 |
rec.onnx |
w600k_r50.onnx |
174,383,860 bytes |
4c06341c33c2ca1f86781dab0e829f88ad5b64be9fba56e56bc9ebdefc619e43 |
完全相同 |
genderage.onnx |
genderage.onnx |
1,322,532 bytes |
4fde69b1c810857b88c64a335084f1c3fe8f01246c9a191b48c7bb756d6652fb |
完全相同 |
这说明三个 ONNX 文件与 InsightFace 发布的 buffalo_l 包中对应文件完全一致。
在本次解包得到的 face-model-1.0.0 中，没有看到模型来源、LICENSE、NOTICE、Model Card、授权说明或第三方组件清单。
InsightFace 官方将代码和预训练模型分开说明：项目代码采用 MIT License，而官方提供的预训练模型标注为仅供非商业研究使用。可参考 InsightFace License 说明 和 v0.7 model packages。
所以，这里更希望官方把模型来源、具体版本和授权状态说明白：
- 如果已经有适用于当前产品的使用和再分发授权，可以直接说明；
- 如果没有相应的再分发许可，可以考虑只提供模型导入和校验功能，让用户从官方来源自行下载，并明确提示上游使用条件。
可以优先采用 InsightFace 官方下载链接；如果已经取得再分发许可，也可以使用统一的飞牛官方下载页并公开 SHA256 清单。这样比密码压缩包和多个网盘地址更方便用户验证文件，下载和校验链路也更清楚。
另一种方案是，飞牛自己准备合规数据并训练自有模型。这条路的周期和成本都会更高，但从长期看可以拥有更清晰的授权边界。
二、相同 Python/CUDA 运行时被重复分发
人脸识别包和相册分类识别包都包含：
python-wheel-1.0.4
solib-1.0.0
两个功能包中的同名文件经过 SHA256 比较，内容逐字节相同：
| 文件 |
单份大小 |
SHA256 |
比对结果 |
python-wheel-1.0.4 |
441,451,618 bytes |
E63128BFB9FF22B3DCC7257450713945F8F2EC9EC2B133B355E148363A864E0A |
完全相同 |
solib-1.0.0 |
1,209,516,937 bytes |
B6918453EA9756E30C104BF4C53895EABAD838785D6EDD8675DB347F27077A58 |
完全相同 |
重复部分的体积约为：
每重复一份：压缩状态 1.65 GB，解压状态 2.30 GB
两个功能包合计：压缩状态 3.30 GB，解压状态 4.61 GB
其中，python-wheel-1.0.4 同时包含：
- ONNX Runtime CPU 1.19.0
- ONNX Runtime GPU 1.19.0
- OpenVINO 2024.4
- OpenCV、NumPy、SciPy、scikit-image、scikit-learn 等依赖
solib-1.0.0 解压后还包含约 1.86 GB 的 CUDA 12、cuDNN 9、cuBLAS、cuFFT、cuRAND 等共享库。
这种打包方式虽然能固定依赖版本、降低部署差异，但代价也比较明显：
- CPU-only 用户也要下载 CUDA 和 cuDNN；
- 不同 AI 功能各自保存一份完全相同的 Python wheel 和
.so；
- 下载、磁盘占用、备份和升级成本都会增加；
- 相同共享库分散在不同目录，不便于统一复用和维护；
- 依赖升级或安全修复时，需要同步更新多个模型包。
现在飞牛软件中心已经通过插件提供 ROCm 运行时，说明运行时组件化是有现成基础的。按这个思路，CPU、OpenVINO、CUDA/cuDNN/TensorRT 也可以做成独立组件，由软件中心根据设备和功能按需安装，不必随每个模型包重复携带。
可以考虑拆成下面几层：
公共 Python 运行时
公共基础依赖
CPU / ONNX Runtime 后端
OpenVINO 后端插件
CUDA / cuDNN / TensorRT 后端插件
ROCm 后端插件
独立模型包
模型包本身只保留：
模型文件
模型配置
预处理和后处理代码
依赖版本声明
模型来源及授权信息
公共运行时可以通过版本化目录、硬链接、reflink、容器公共层或内容寻址存储复用。这样既能固定版本，也能避免同一份运行时被多个功能包重复安装。
三、模型没有按设备提供精度和性能优化
当前三个 ONNX 都是原始 FP32 模型：
- 权重类型为 FLOAT32；
- 没有
QuantizeLinear、DequantizeLinear；
- 没有 QDQ、
QLinearConv 或 MatMulInteger；
- 没有 FP16 版本；
- 没有看到设备能力检测和模型变体选择逻辑。
模型规模如下：
| 模型 |
参数量 |
FP32 文件大小 |
主要计算量 |
| 人脸检测 |
4.23M |
16.92 MB |
约 13.34 GMAC，输入 640×640 |
| 人脸识别 |
43.58M |
174.38 MB |
约 6.31 GMAC，输入 112×112 |
| 年龄性别 |
0.318M |
1.32 MB |
约 9.36 MMAC，输入 96×96 |
人脸检测和人脸识别的计算量较大，在纯 CPU NAS 上长期使用 FP32，会增加推理延迟、内存带宽占用和功耗。年龄性别模型本身较小，优化收益相对有限，可以降低优先级。
比较现实的做法是保留 FP32 兼容版本，再按硬件提供不同变体：
| 设备类型 |
建议方案 |
| 通用 x86-64 CPU |
FP32 兼容版本 |
| 支持 AVX2/VNNI 的 CPU |
静态 INT8 QDQ，优先采用逐通道权重量化 |
| Intel/OpenVINO 环境 |
OpenVINO INT8，使用真实业务数据校准 |
| 支持高效 FP16 的 NVIDIA GPU |
TensorRT FP16 混合精度 |
| 支持高效 INT8 的 RTX 等 GPU |
可选 TensorRT INT8，并进行校准和精度验证 |
| AMD ROCm 环境 |
在硬件和算子支持合适时提供 FP16 |
这里需要注意，不能简单理解为“CPU 一律 INT8、CUDA 一律 FP16”。中老型号 CPU 对 INT8 指令的支持差异较大，部分老款 NVIDIA 显卡也没有高效 FP16/INT8 单元。更稳妥的做法是启动时检测 CPU 指令集、GPU 架构和可用 Execution Provider，再选择实际更快的模型；不满足条件时自动回退到 FP32。
量化不能只看模型文件变小了多少，还要做校准、准确率回归和端到端性能测试。人脸识别模型尤其需要检查：
- FP32、INT8、FP16 输出 embedding 的一致性；
- 不同后端之间 cosine 相似度的变化；
- 已有人脸库能否跨精度继续使用；
- 是否需要重新提取特征或调整识别阈值。
参考资料：
四、我认为可以优先确认的事项
- 公布模型来源、版本、SHA256 和授权说明，方便用户核对。
- 将 Python、CUDA 等公共运行时从功能模型包中拆出，改为共享依赖或后端插件。
- 根据实际硬件按需安装 CPU、OpenVINO、CUDA 或 ROCm 后端。
- 为主要模型提供 FP32、INT8、FP16 等经过验证的版本，并自动选择合适的后端。
- 公布不同硬件上的速度、内存占用和准确率测试结果，方便用户判断实际收益。
备注
我与 InsightFace 没有任何关联，也是飞牛 NAS 的用户。
以上内容只是从专业从业者和最终用户角度提供参考。
如果官方需要，我也愿意参与后续测试、量化验证和方案讨论。
