3. 模型注册表概述
在边缘AI设备的开发与运维中，模型的生命周期管理远比传统软件复杂。一个训练好的模型需要经过版本迭代、精度评估、硬件适配、格式转换、压缩量化、安全校验等多个环节，才能最终部署到边缘设备上。如果缺乏统一的管理机制，团队很容易陷入"模型文件散落在各人电脑里"、"部署到设备上的版本无法追溯"、"回滚时找不到上一版参数"等混乱局面。模型注册表（Model Registry）正是为解决这些问题而生的核心基础设施。本章将深入剖析模型注册表的定义、核心功能，并重点厘清它与模型仓库（Model Repository/Model Store）的本质区别，为后续在边缘AI场景中落地应用打下坚实基础。
上图清晰地展示了模型注册表与模型仓库在定位上的根本差异。模型仓库解决的是"文件存储与版本编号"问题，而模型注册表解决的是"模型资产治理与生命周期管理"问题。在边缘AI场景中，由于设备数量多、环境差异大、OTA升级频繁，这种治理能力尤为重要。下面我们逐一展开。
3.1 模型注册表的定义与核心功能
3.1.1 核心原理：从"文件管理"到"资产治理"
模型注册表是一个集中化的、带版本控制的、记录模型元数据及生命周期状态的系统。它不仅仅保存模型文件本身，更重要的是保存与模型相关的所有上下文信息，包括：训练数据集版本、训练脚本Git提交ID、超参数配置、评估指标（mAP、F1、延迟、功耗）、量化参数、目标硬件平台、部署状态、审批记录等。在边缘AI场景中，模型注册表还额外记录每个模型版本在哪些设备型号上验证通过、哪些设备批次正在运行、回滚策略等。
从数据模型角度看，模型注册表的核心实体包括：模型（Model）、模型版本（Model Version）、元数据（Metadata）、审批记录（Approval Record）、部署记录（Deployment Record）。其中，模型版本是注册表的核心单元，每个版本拥有全局唯一的标识（如 model_name:version），并关联一组不可变的元数据。
关键认知：模型注册表不是简单的"带版本的文件服务器"，而是一个面向治理的元数据管理系统。它让模型从"个人产物"转变为"团队资产"。
3.1.2 核心功能清单
| 功能模块 | 具体能力 | 边缘AI场景中的价值 |
|---|---|---|
| 版本管理 | 支持语义化版本号、分支、标签；版本不可变 | 精确追踪每个设备上运行的模型版本，支持快速回滚 |
| 元数据管理 | 自定义键值对、结构化字段、文件附件 | 记录模型在特定芯片（如RK3588、Jetson Orin）上的精度与延迟 |
| 生命周期状态机 | Draft → Validation → Approved → Released → Deprecated → Archived | 防止未验证的模型被部署到生产设备 |
| 审批与审计 | 角色权限、审批流、操作日志 | 满足行业合规要求，明确责任边界 |
| 模型血缘追踪 | 记录训练数据、代码、超参数、评估结果 | 当设备端出现精度问题时，可快速定位是数据、代码还是模型问题 |
| 部署关联 | 记录模型与设备组、OTA任务的关联关系 | 支持灰度发布、按设备型号差异化部署 |
3.1.3 操作流程：模型注册与状态流转
在边缘AI项目中，一个模型从训练完成到设备上线，通常经历以下注册流程：
- 创建模型记录：在注册表中创建模型条目，填写模型名称、任务类型（检测/分类/分割）、目标硬件平台。
- 上传模型版本：上传模型文件（如
.onnx、.tflite），并填写元数据：训练框架、数据集版本、评估指标、量化方式（INT8/FP16）、模型大小。 - 自动校验：注册表触发自动化流水线，对模型文件进行格式校验、SHA256校验、基础精度冒烟测试。
- 人工审批：算法负责人审核评估指标是否达标，硬件工程师审核在目标设备上的仿真结果。
- 标记发布：审批通过后，将模型版本标记为
Released，此时才允许被OTA系统引用。 - 部署跟踪：记录实际部署的设备批次、部署时间、运行状态。若发现问题，可一键回滚到上一个
Released版本。
3.1.4 常见误区与总结
误区一：认为模型注册表只是"给模型文件加个版本号"。实际上，没有元数据和状态管理的版本号毫无意义，无法支撑审计和回滚决策。
误区二：将注册表与CI/CD割裂。在边缘AI中，注册表应作为CI/CD流水线的核心节点，模型只有通过注册表校验才能进入部署环节。
误区三：忽略元数据的标准化。不同团队使用不同字段名（如 accuracy vs map），会导致后续检索和自动化门禁失效。
3.2 模型注册表与模型仓库的区别
3.2.1 核心原理：分层理解
模型仓库（Model Repository）是底层存储设施，通常基于对象存储（S3、MinIO）或文件系统实现，提供模型文件的持久化存储和版本化文件访问。它关心的是字节：文件是否完整、路径是否正确、下载是否快速。而模型注册表是构建在仓库之上的治理层，关心的是语义：这个模型版本代表什么、是否可用、谁批准的、部署在哪里。
用一个类比来理解：模型仓库如同一个仓库货架，每个箱子（模型文件）贴有编号（版本号），可以随时取用；而模型注册表如同资产管理系统，记录每个箱子的采购来源、质检报告、存放位置、领用记录、报废状态。没有资产管理系统，仓库货架依然能工作，但无法回答"哪个箱子在哪个设备上使用"、"哪个箱子质量不合格"等问题。
3.2.2 对比分析表
| 对比维度 | 模型仓库 (Model Repository) | 模型注册表 (Model Registry) |
|---|---|---|
| 核心定位 | 存储与传输 | 治理与生命周期 |
| 数据内容 | 模型二进制文件、版本标签 | 元数据、状态、审批记录、血缘、部署关联 |
| 操作粒度 | 文件级（上传/下载/删除） | 模型版本级（注册/审批/发布/回滚） |
| 查询能力 | 按路径或标签查询 | 按元数据、状态、设备型号、指标范围查询 |
| 权限控制 | 粗粒度（读写权限） | 细粒度（角色+状态+操作类型） |
| 审计能力 | 有限（访问日志） | 完整（谁在何时将哪个版本从Draft改为Released） |
| 与CI/CD集成 | 作为制品库被拉取 | 作为门禁节点，控制流水线是否继续 |
| 典型工具 | MinIO、S3、Harbor（容器镜像类比） | MLflow Model Registry、Kubeflow Model Registry、自研系统 |
3.2.3 案例拆解：边缘安防设备公司的模型管理演进
某边缘安防设备公司，主要产品是内置AI芯片的IPC摄像头，支持人形检测、车辆识别等功能。团队最初使用MinIO作为模型仓库，目录结构为 models/检测模型/v1.0.0/model.onnx。随着设备出货量增加，问题逐渐暴露：
- 现象1：现场反馈某批次设备（芯片型号A）检测准确率下降，但无法确认该批次设备运行的是哪个模型版本。
- 现象2：算法团队同时迭代多个模型，仓库中出现了
v1.0.0_final、v1.0.0_final_v2等混乱标签。 - 现象3：OTA团队手动下载模型并部署，无法追踪部署范围，回滚时需要逐个设备操作。
该公司引入MLflow Model Registry后，进行了以下改造：
- 标准化元数据：每个模型版本强制填写芯片型号、精度（mAP@0.5）、INT8量化后延迟（ms）、模型大小（KB）。
- 状态门禁：只有标记为
Released的版本才能被OTA系统读取。算法团队提交的Draft版本无法被部署。 - 部署关联：每次OTA任务在注册表中创建部署记录，关联设备批次（如"芯片A批次20240301"）和模型版本。
- 自动回滚：当设备端上报精度异常时，运维人员查询注册表，找到该批次设备当前运行的模型版本，一键回滚到上一个
Released版本。
结果对比：改造前，定位一次现场问题平均需要2-3天（人工排查设备日志、猜测模型版本）；改造后，通过注册表查询部署记录，10分钟内即可定位问题版本并启动回滚。同时，模型标签混乱问题彻底消失，因为注册表强制使用语义化版本号，且版本不可变。
经验总结：对于边缘AI团队，建议采用"仓库+注册表"双层架构。仓库负责存储，注册表负责治理。如果团队规模较小，可先使用MLflow等开源工具快速搭建；当设备规模超过千台时，务必考虑自研或定制注册表，以支持设备维度的高级查询和批量操作。
3.2.4 常见误区与总结复盘
误区一：认为"有了模型仓库就不需要注册表"。仓库解决的是"文件不丢"，注册表解决的是"模型可用、可追溯、可回滚"。在边缘AI中，设备分散、网络不稳定，一旦部署错误版本，修复成本极高，因此治理能力不可或缺。
误区二：将注册表与模型训练平台混淆。训练平台（如Kubeflow）负责"产生模型"，注册表负责"管理模型"。两者应通过API集成，而非合并。
误区三：忽略注册表本身的可用性设计。注册表是OTA部署链路的关键依赖，必须考虑高可用、备份恢复和离线容灾。否则注册表宕机，可能导致整个设备更新流程停滞。