数据、模型与文件托管

研究项目应先按资产性质选择存储，再决定同步工具。代码、数据、模型、日志和论文附件的更新频率、体积、权限与引用方式不同，不应全部塞进一个 Git 仓库。

Hugging Face Hub

Hub 为模型、数据集和 Space 提供版本化仓库与说明页面。公开资产应提供 Model Card 或 Dataset Card，至少记录来源、许可、用途、限制、数据划分和评估协议。

hf auth login
hf download owner/model-name --local-dir models/model-name
hf upload owner/model-name ./checkpoints/final .

大文件由 Hub 的存储机制处理，但“能上传”不等于“允许公开”。医疗、用户和合作方数据必须先确认授权、去标识化和访问控制；Token 放在凭据存储或环境变量中。

Dropbox

Dropbox 适合共享草稿、图源、行政文件和不需要 Git 语义的中小型资料。避免让训练程序直接在多人同步目录中高频写 Checkpoint：部分写入、冲突副本和同步延迟会让状态难以判断。

比较稳妥的模式是：程序写本地工作目录，任务完成后把确认过的结果同步到共享目录；共享目录建立明确的只读、归档和命名规则。

Git LFS 与 DVC 的边界

场景	更合适的选择
少量、与代码提交紧密绑定的大文件	Git LFS
数据版本和处理管线需要追踪	DVC
发布模型或标准数据集供他人使用	Hugging Face Hub
团队临时文件和写作资料同步	Dropbox
大规模对象、Checkpoint 和服务产物	S3 兼容对象存储，如 R2

研究资产放置约定

project/
├── src/              Git
├── configs/          Git
├── data/             本地缓存；通过脚本、DVC 或 Hub 获取
├── checkpoints/      Hub 或对象存储
├── logs/             实验平台与归档存储
├── results/          审查后的表格可进入 Git
└── figures/          论文最终图和可复现源文件进入 Git

每项重要资产都要能回答：由什么代码生成、基于哪版数据、校验值是什么、谁有访问权限、何时可以删除。同步服务不是备份策略；至少保留一个独立副本并定期验证恢复。

参考：Hugging Face Hub 文档、Dropbox 帮助中心、DVC 文档。