AI 平台模型注册表：别让模型文件散落在对象存储里

AI 平台模型注册表：别让模型文件散落在对象存储里

一、模型文件需要被治理

云原生 AI 平台里，模型权重、Tokenizer、配置、LoRA、量化版本经常被放在对象存储里。早期团队可能用路径约定管理，例如 models/v1/、models/latest/。规模一大，就会出现版本混乱、依赖缺失、权限不清、回滚困难。

模型注册表的价值，是把模型当成平台资产管理，而不是一堆文件。

二、注册表要记录完整元数据

flowchart TD
  A[模型文件] --> B[模型注册]
  B --> C[版本元数据]
  C --> D[部署引用]
  D --> E[灰度与回滚]

模型版本不只包含权重路径，还应包含基础模型、训练数据版本、量化方式、运行镜像、兼容推理引擎、许可信息和校验 hash。缺少这些元数据，平台很难判断一个模型能不能部署。

部署服务不应该直接引用对象存储路径，而应该引用注册表里的模型版本。

三、数据结构要支持追溯

type ModelVersion = {
  modelId: string
  version: string
  artifactUri: string
  runtimeImage: string
  checksum: string
  quantization?: "int8" | "int4"
  createdAt: string
}

checksum 可以防止文件被悄悄替换。runtimeImage 能说明这个模型要用哪个运行时启动。

model_registry_policy:
  require_checksum: true
  immutable_version: true
  record_runtime_image: true
  allow_rollback_reference: true

模型版本一旦发布，应尽量不可变。需要修复就发布新版本，不要覆盖旧文件。

四、注册表要连接发布流程

模型进入注册表后，还要经过评测、审批、灰度和部署。注册表不是单纯目录，而是发布链路的入口。

还要管理清理策略。旧模型不能无限保存，但删除前要确认没有部署、没有回滚依赖、没有审计要求。

注册表还可以和 Kubernetes CRD 结合。平台把模型版本声明成资源，部署控制器根据资源状态拉取文件、校验 checksum、更新推理服务。这样模型发布就能进入声明式流程，而不是依赖脚本手工执行。

apiVersion: ai.example.com/v1
kind: ModelVersion
metadata:
  name: chat-model-v4
spec:
  artifactUri: s3://models/chat/v4
  runtimeImage: inference-runtime:1.8
  checksum: sha256:abc123

CRD 的 status 可以记录是否已校验、是否已部署、哪些服务正在引用。运维排查时，不需要去对象存储里猜路径。

还要给注册表加权限。不是所有人都能注册生产模型，也不是所有服务都能引用所有模型。模型资产往往涉及许可证和客户数据，权限边界必须清楚。

最后，注册表应和评测报告关联。一个模型版本如果没有通过指定评测，就不能进入生产部署。模型治理和质量门禁要绑在一起。

注册表还要提供引用图谱。平台至少要能回答：某个模型版本被哪些推理服务、离线任务、灰度环境和回滚计划引用。否则清理旧模型时，很容易删掉仍被低频任务依赖的版本。

model_reference_graph:
  track_deployment_refs: true
  track_batch_job_refs: true
  block_delete_when_referenced: true
  require_owner_for_orphan_model: true

我更推荐把删除动作设计成两阶段：先标记 deprecated，再等待观察窗口，最后才物理清理。观察窗口内如果仍有服务拉取该版本，注册表应直接阻止删除并把引用方列出来。

五、总结

AI 平台模型注册表要管理模型文件、版本、运行时、校验、部署引用和回滚关系。

模型文件散落在对象存储里，平台迟早会失去可控性。注册表是模型工程化的基础。