AI 平台对象存储：模型、数据集和结果不能混用一个桶

AI 平台对象存储：模型、数据集和结果不能混用一个桶

AI 平台离不开对象存储：模型权重、训练数据、评测集、推理结果、日志归档、用户上传文件都会放进去。为了方便，很多团队早期把所有东西放进一个 bucket，通过路径区分。短期没问题，长期会遇到权限混乱、生命周期策略冲突、成本难归因和误删风险。

对象存储不是一个大文件夹。AI 平台要按资产类型设计边界。

一、先区分资产类型

flowchart TD
  A[Object Storage] --> B[Model Weights]
  A --> C[Datasets]
  A --> D[Inference Results]
  A --> E[Logs]
  A --> F[User Uploads]

模型权重需要版本化和只读访问，数据集需要权限隔离和 lineage，推理结果需要短期保留，日志归档需要生命周期过期，用户上传文件需要隐私和删除能力。它们的访问模式和治理规则完全不同。

如果全部混在一个 bucket，只靠路径命名管理，权限策略会越来越难写。更稳的方式是按资产类型或敏感级别拆 bucket，再用统一标签做成本和租户归因。

二、生命周期策略要独立

lifecycle:
  inference-results:
    expire_days: 30
  logs:
    expire_days: 90
  model-weights:
    retain: versioned

推理临时结果可以短期过期，日志可以按合规要求保留，模型权重则要保留可回滚版本。生命周期策略如果共用，很容易出现该删的不删、该留的被删。

对象版本也要谨慎。模型和配置适合开启版本，临时结果不一定需要。版本化会增加成本，必须结合资产价值决定，而不是全局打开。

三、权限要最小化

{
  "service": "inference-worker",
  "allow": ["read:model", "write:result"],
  "deny": ["read:dataset-raw"]
}

推理服务通常只需要读取模型、写结果，不应该读取原始训练数据。训练任务需要读取数据集、写 checkpoint，不一定能读取用户上传文件。服务账号权限要按职责拆分，避免一个万能 Key 横行平台。

跨租户场景更要小心。对象路径中带 tenant_id 只是第一步，权限策略也要限制租户范围。不要依赖应用代码自觉拼对路径，存储层也要提供防线。

四、元数据要进入平台

{
  "object_uri": "s3://models/ranker/v3",
  "asset_type": "model",
  "owner": "search-team",
  "checksum": "sha256:xxx",
  "created_at": "2026-07-03"
}

对象存储本身不适合承担完整资产目录。平台应该有元数据表，记录对象 URI、资产类型、版本、owner、checksum、租户、生命周期和引用关系。这样才能知道哪些对象还在被使用，哪些可以清理。

没有元数据，清理对象会非常危险。没人敢删旧模型、旧结果和旧数据集，成本会不断上涨。资产目录是对象存储治理的眼睛。

访问审计也要打开。谁读取了数据集，哪个服务下载了模型，哪个任务写入了结果，都应该能查到。对象存储一旦承载 AI 平台核心资产，就不能只靠 bucket 名字管理，审计日志是最后一道追责线索。

五、总结

AI 平台对象存储要按模型、数据集、推理结果、日志和用户上传等资产类型划清边界。生命周期、权限、版本和元数据都要独立设计。

对象存储可以很便宜，也可以因为治理混乱变得很贵。不要把它当一个无限大的公共文件夹。