搭建私有模型仓库，核心是解决模型文件的存储、版本管理和分发问题，而不是重新造一个 Git 或对象存储。如果团队已有对象存储（如 MinIO、S3）和容器环境，优先用现成方案组合，避免自研元数据服务。判断方向：模型数量少、仅内部使用，用 MLflow 或 DVC 加对象存储就够；需要细粒度权限、审计和 Web 界面，再考虑自建模型注册中心。
私有模型仓库的搭建应先明确使用场景：是仅存储大文件，还是需要版本追踪、权限控制和 API 分发。多数团队用对象存储 + 元数据库（如 MLflow）即可满足，不必自研。关键动作是定义模型命名规范、版本策略和访问控制，而非追求功能大而全。边界在于：如果模型更新频率低、团队规模小，直接使用共享文件系统加校验和也能临时过渡，但缺少审计和回滚能力。
先分清存储、注册与分发三层
模型仓库通常包含三层：存储层（对象存储或文件系统）、注册层（元数据、版本、标签）和分发层（API 或 CLI 下载）。存储层用 MinIO 或云厂商对象存储即可，注册层可选 MLflow Model Registry、DVC 或自建数据库表。分发层根据消费方决定：训练任务用内网挂载或 SDK 拉取，推理服务用 HTTP 接口。不要一开始就三层全自研，优先用 MLflow 覆盖注册和分发，存储复用现有对象存储。
用 MLflow 搭建最小可用仓库
MLflow 提供模型注册和实验跟踪，后端可接 MySQL/PostgreSQL 存元数据，artifact 存到 S3 兼容存储。以下是一个最小化 docker-compose 骨架，用于启动 MLflow 服务并连接 MinIO：
version: '3'
services:
minio:
image: minio/minio
command: server /data --console-address ":9001"
environment:
MINIO_ROOT_USER: minioadmin
MINIO_ROOT_PASSWORD: minioadmin
ports:
- "9000:9000"
- "9001:9001"
volumes:
- ./minio-data:/data
mlflow:
image: ghcr.io/mlflow/mlflow:v2.9.2
command: mlflow server --backend-store-uri postgresql://user:pass@db:5432/mlflow --default-artifact-root s3://mlflow/ --host 0.0.0.0
ports:
- "5000:5000"
depends_on:
- minio
- db
db:
image: postgres:15
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
POSTGRES_DB: mlflow
volumes:
- ./pg-data:/var/lib/postgresql/data启动后，通过 MLflow 客户端注册模型并设置版本。注意：MLflow 的 artifact 存储需要配置 S3 访问密钥，可在环境变量中注入 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY，并设置 MLFLOW_S3_ENDPOINT_URL 指向 MinIO。
模型上传与版本管理的关键动作
模型文件通常较大，直接提交到 Git 会拖慢仓库。推荐用 DVC 或 MLflow 的 artifact 日志接口上传。以下是一个用 MLflow 记录模型并注册的 Python 骨架：
import mlflow
from mlflow.models import infer_signature
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("my-model")
with mlflow.start_run():
# 训练或加载模型
model = ...
signature = infer_signature(X_train, model.predict(X_train))
mlflow.sklearn.log_model(
sk_model=model,
artifact_path="model",
signature=signature,
registered_model_name="my-model"
)版本管理上，建议用语义化版本（如 v1.2.0）作为标签，同时保留 MLflow 自动生成的版本号。关键动作：每次注册模型时写入训练数据版本、代码 commit 和评估指标，方便回溯。不要依赖手动重命名文件来管理版本。
权限与分发：别让仓库变成公开网盘
私有仓库需要控制谁可以下载和注册模型。MLflow 本身不带细粒度权限，可在前面加一层反向代理（如 Nginx）做 Basic Auth，或集成 OAuth2 代理。如果团队使用 Kubernetes，可以用 Istio 或 OPA 做策略控制。分发方面，推理服务不应直接挂载对象存储，而是通过模型仓库的 API 获取指定版本，并缓存到本地。以下是一个下载模型的 API 请求骨架（假设用 MLflow 的 REST API）：
GET /api/2.0/mlflow/model-versions/get-download-uri?name=my-model&version=3
Authorization: Bearer <token>响应中会返回临时下载链接，推理服务用该链接拉取模型文件。注意：临时链接有效期不宜过长，建议结合内网访问限制。
验证清单
- 模型上传后，能否通过版本号准确拉取到对应文件？
- 元数据中是否记录了训练数据版本和代码 commit？
- 未授权用户访问模型下载接口是否被拒绝？
- 删除模型版本时，是否同步清理了存储中的 artifact？
- 推理服务拉取模型失败时，是否有重试和告警？
常见问题
模型文件很大，用 Git LFS 还是对象存储？
Git LFS 适合代码仓库中偶尔存放小模型，但大模型（数百 MB 以上）会拖慢克隆速度，且 LFS 存储成本较高。推荐用对象存储 + 元数据管理，Git 只存代码和配置。
没有 Kubernetes，能用 Docker Compose 搭吗？
可以。MLflow + MinIO + PostgreSQL 用 Docker Compose 就能跑起来，适合小团队或测试环境。生产环境需考虑高可用和备份，但架构不变。