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:abc123CRD 的 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 平台模型注册表要管理模型文件、版本、运行时、校验、部署引用和回滚关系。
模型文件散落在对象存储里，平台迟早会失去可控性。注册表是模型工程化的基础。