如何自建人脸识别大模型

我要自己训练一个用来对图像数据抠出人脸, 并对所有抠出的人脸进行 embedding 得到高维度向量的大模型.

为了完成这个任务, 需要多少张用于训练的图像? 多少GPU卡(及规格)? 需要在什么软件环境下进行训练, 预估要训练多久?

训练完后要进行人脸识别, 在亿级别人脸向量库进行比对, 召回要又快又准.

如果模型重新训练了, 采用原来的大模型对图像 embedding 得到的高维度向量是不是要重新使用新模型进行 embedding? 原来模型 embedding 生成的向量是不是无法使用了? “高维度向量”能或者不能复用的原理是啥?

另外, huggingface 中是否已经有了类似功能的开源大模型?

今天就聊聊上面这些问题.

我把这件事拆成三笔账：训练这笔账、检索这笔账、还有最容易被漏掉的"模型换代"这笔账。

第一笔账：训练一个能打的人脸embedding模型，到底要花多少

先纠正一个常见的认知偏差：你要训练的不是一个模型，而是两个 —— 一个负责从图片里把脸抠出来并对齐（检测），一个负责把对齐后的脸变成一个能比对的向量（embedding）。检测这一步，工业界基本不会从零训练，RetinaFace、SCRFD 这类开源检测器已经足够成熟，自己训练的边际收益很低，真正值得投入算力的是第二步。

数据量级上，可以参考人脸识别领域事实上的标杆 —— InsightFace 团队公开的几个训练集：

• MS1M 清洗版大约510万张图、9.3万个身份；
• Glint360K 是1709万张图、36万个身份；
• 再往上还有 WebFace42M，4200万张图。

这里有个反直觉的点： 决定模型效果上限的主要是身份数（类别数），而不是图片总数。图片数只是决定每个人的姿态、光照、遮挡覆盖得够不够全。所以如果只是想跑出一个能用的基线，几十万身份、千万级图片就是一个合理的起点，不需要一上来就对标WebFace42M那个量级。

GPU 这块可以拿两个真实存在的训练配置做锚点(下面是 AI 給的数据)：用 MS1MV2、Glint360K 这类数据训练时，常见配置是4张A100、每卡跑128的batch size；数据量上到 WebFace42M 这种级别、骨干换成ResNet-200，实际用到过64张V100的集群。换算成直觉的话，如果你的目标是几十万身份以内的基线验证，单机8卡A100起步、训练几天到一周内能看到收敛;如果真要对标工业级大规模效果，就得往数十张卡、一到两周甚至更久的周期去规划 —— 这中间的浮动很大程度上取决于有没有用Partial FC（专门解决"分类头维度=身份数"导致显存爆炸问题的工程手段）、混合精度训练、DALI这类数据加载加速工具，这几项经常能带来数倍的吞吐差异，比单纯堆卡数更划算。

软件环境这块不复杂：PyTorch是目前的主流选择（InsightFace官方训练分支就是PyTorch实现），多机多卡用 torchrun 启动，数据吞吐大的话上 DALI；训练过程中要定期在 LFW、CFP-FP、AgeDB、IJB-C 这几个学术界公认的基准上验证效果, 而不是只盯着训练 loss —— 很多项目在这一步偷懒, 等到上线才发现模型在训练集之外的场景表现很差。

不过在你真的去申请这堆 GPU 资源之前，我建议先做一件成本几乎为零的事： 去 HuggingFace 上把现成的开源模型跑一遍，看看差距有多大。这个方向的开源生态其实已经相当成熟了 ——

• InsightFace 的 buffalo_l 系列模型本身就是“检测 + 对齐 + embedding”一体化的成熟方案；
• fal 团队发布的 AuraFace-v1 是专门解决"ArcFace训练数据不能商用"这个痛点的开源替代，用可商用数据重新训练了一版结构类似的模型；
• ONNX Model Zoo上也有标准化的 ArcFace ResNet100 可以直接拿来部署推理。

如果拿业务场景的几千张真实数据去测这些开源模型，发现准确率跟业务要求差距只有几个百分点，那微调（在开源权重基础上用自己的数据继续训练）就能解决问题，成本比从零训练低一个数量级；只有当差距大到几十个百分点 —— 通常意味着你的场景跟公开基准的分布有系统性差异，比如极端逆光、低分辨率监控画面、特殊人群 —— 从零训练才真正划算。当然，如果产品要商用而数据授权是硬约束（原版 MS1M/Glint360K 明确限制非商用），这就不只是技术问题了，得优先解决数据合规。

第二笔账：亿级检索,如何提高召回率

假设你的 embedding 模型已经训练好了, 接下来要在亿级人脸库里做比对。这里的核心矛盾很直接:暴力比对在这个量级下延迟不可接受，必须用近似索引换速度，但近似换来的代价就是召回率打折。

512维的人脸向量，亿级规模下裸存储就要接近200GB，这还没算索引结构本身的开销，所以内存规划从一开始就不能假设能全塞进内存，得把量化压缩或者磁盘索引方案纳入设计。索引选型上有个值得注意、容易被低估的结论：图索引类算法（比如 HNSW）在十亿规模上能在每秒万级到十万级查询量的区间做到90%以上的召回率，而经典的IVF类算法在同样规模下召回率要求一旦超过60%，查询速度就会明显掉下来。也就是说，"亿级规模、还要求高召回"这两个目标同时要，图索引通常是更靠谱的起点 —— 不过这不是免费的，图索引的内存占用普遍比压缩型的 IVFPQ 方案更高，如果内存预算紧张，IVFPQ 仍然是更经济的选择，这是一个真实的权衡，不存在无条件更优的方案。

工程落地上，可以采用 PostgreSQL pgvector/vchord 等向量插件, 或分布式向量数据库，取决于你的库是不是会持续增长、频繁增删。人脸库现实中几乎必然会不断有新身份入库，而 Faiss 对增量添加向量的支持比较有限，如果入库频率高，向量数据库原生的增量索引能力能省不少运维成本。

如果需要国产化技术栈的话, 人大金仓、海量、南大通用、Higobase、HaloDB、OB 等很多厂商都支持向量功能.

第三笔账，embedding 模型换代之后, 旧向量还能用吗

文章开头的直觉是对的： 默认情况下，旧模型算出来的向量，不能直接跟新模型的向量放在一起比对。原理并不复杂 —— embedding 向量本质上是模型训练出来的一套"坐标系"，这套坐标系是随机初始化加训练过程共同决定的，哪怕架构、数据完全一样，只是随机种子不同，两次训练学出来的坐标系都不是天然对齐的。旧向量A和B之间的距离，是在旧坐标系里定义的；新向量A'和B'的距离，是在新坐标系里定义的；拿旧向量去跟新向量算相似度，这个数字本身没有意义 —— 哪怕是同一张脸，新旧模型给出的向量在空间里的位置也可能毫不相关。如果新模型换了架构或者输出维度都变了（比如从512维换成1024维），这个问题更直接，连算相似度的前提都不满足。

所以按默认做法，模型一旦重新训练，亿级库里的历史向量理论上都要作废，得用新模型把所有历史人脸图片重新跑一遍推理 —— 这个动作行业里有个专门叫法，"回填"（backfilling）。对亿级规模来说，回填是一笔实打实的算力和时间成本，这也是这个问题在工业界被认真对待、而不是纸上谈兵的原因。

但这件事不是无解的。Amazon 在2020年提出了一个专门的训练框架(Towards Backward-Compatible Representation Learning)来解决这个问题，思路挺巧妙：不是在两个模型都训练完之后再去想办法对齐，而是在训练新模型的过程中，就强迫新模型的坐标系跟旧模型保持兼容 —— 具体做法是让新模型的分类头同时去拟合旧模型定下的分类边界，相当于把旧坐标系焊在新模型的训练目标里当锚点。用这个框架训练出来的新模型，表征能力可以比旧模型更强，但输出的向量能直接跟旧向量放进同一个库比对，不需要回填。这个方法在人脸识别任务上做过验证，效果是成立的。

不过得说句实话，这不是免费的午餐。这个方案必须在训练新模型之前就规划好，如果模型已经练完了才想起要兼容，这条路走不通 —— 它是训练期方案，不是事后补救方案。而且后续有研究专门指出，为了保持向后兼容，新模型的性能上限会被明显压制,相当于新模型被旧模型拖了后腿，这是真实存在的精度和兼容性之间的权衡，不是白拿的。如果第一版模型训练时压根没考虑这件事,现在也不是完全没有退路 —— 还有一条更工程化的路子,就是单独训练一个轻量的"转换函数",把旧向量映射到新坐标系,不需要重新设计训练损失,但翻译过程本身会引入额外误差,精度通常不如从训练源头就做兼容设计,而且这类链式的兼容改造也不能无限叠加下去,每多兼容一代,对新模型性能的压制也会跟着累积。

如果是我来做这个决策，会这样安排： 既然模型迭代几乎是必然会发生的事，从第一版模型开始就应该把兼容性约束设计进训练流程，这样以后每次升级只需要给新增数据跑新模型，不用把亿级库推倒重来。如果现在已经练完第一版、没考虑这茬，也不必一次性回填全库 —— 可以按活跃度分桶，热数据（高频查询的人脸）优先用新模型回填，冷数据先保留旧向量兜底，检索时新旧向量分别做召回再融合，把成本摊到较长周期里，而不是逼自己一次性扛下全部计算量。

要验证新旧向量到底能不能混用，有个几乎零成本的办法：挑几万张图，分别用新旧模型跑出向量，看同一个人在两套向量体系里的相似度是不是明显高于不同人之间的相似度。如果这个数字接近随机，说明确实不兼容，老老实实回填；如果表现良好，说明兼容性成立，可以直接混用。这个验证应该在小规模上先做,而不是等全量上线了才发现问题 —— 很多团队恰恰是跳过了这一步。

写在最后

这三笔账里，第一笔（训练成本）和第二笔（检索成本）是可以用钱和时间硬堆出来的，真正需要提前想清楚、事后很难打补丁的是第三笔（模型换代兼容性）。如果你现在就打算长期维护这套系统，把兼容性设计放进第一版模型的训练目标里，可能是这整套方案里性价比最高的一个决定。