autodl无卡模式下载NTURain 训练集实录：基于 Git 部分克隆与稀疏检出的数据拉取

AOI小白新手上路2026-10-17 14:55

NTURain 训练集获取实录：基于 Git 部分克隆与稀疏检出的数据拉取

记录时间：2026-10-15

执行环境：AutoDL 容器 autodl-container-38ef40b880-8646dcf9

目标数据：hotndy/SPAC-SupplementaryMaterials → Dataset_Training_Synthetic

结论状态：验收通过（33 / 25 / 604M 三重校验全部命中）

目录

  • [0. 摘要（学术型，约 120 字）](#0. 摘要（学术型，约 120 字）)
  • [1. 任务背景与目标](#1. 任务背景与目标)
  • [2. 故障现象与根因定位](#2. 故障现象与根因定位)
    • [2.1 故障现象](#2.1 故障现象)
    • [2.2 根因定位](#2.2 根因定位)
    • [2.3 故障的间歇性特征](#2.3 故障的间歇性特征)
  • [3. 解决方案：两段式部分克隆](#3. 解决方案：两段式部分克隆)
    • [3.1 完整命令序列](#3.1 完整命令序列)
    • [3.2 各参数的作用机理](#3.2 各参数的作用机理)
    • [3.3 分阶段耗时与吞吐实测](#3.3 分阶段耗时与吞吐实测)
  • [4. 验收：三重数字化校验](#4. 验收：三重数字化校验)
  • [5. 与预期的两处偏差校正](#5. 与预期的两处偏差校正)
  • [6. 数据资产清单与命名规则](#6. 数据资产清单与命名规则)
  • [7. 后续步骤](#7. 后续步骤)
  • [8. 可复用命令速查](#8. 可复用命令速查)
  • [9. 方法论提炼](#9. 方法论提炼)

0. 摘要（学术型，约 120 字）

针对视频去雨知识蒸馏研究的数据需求，本文记录 NTURain 合成训练集的获取过程。采用部分克隆与稀疏检出机制，仅拉取目标目录，成功获得 33 个 RAR 归档（25 个雨序列、8 个背景真值），实测 604 MB，与预期一致。结果校正了原论文"24 序列"的表述偏差，确证 t7 场景含 4 个雨变体，为后续解压与蒸馏流水线接线提供经校验的数据资产。

1. 任务背景与目标

1.1 数据在方案中的位置

NTURain 是 VDMamba → NAFNet 视频去雨蒸馏方案的唯一主训练数据集，同时承担三项职能：

用途 数据子集 说明
学生训练 训练集（本次拉取） 有配对 GT，可算 L1/SSIM 重建损失
教师推理对齐 训练集 教师与学生共享同一输入分布
评测 测试集（此前已有） synthetic_NTURain.zip，8 合成 + 7 真实雨

1.2 拉取前的数据缺口

此前本地与实例中已具备 NTURain 测试集 （经三重认证：synthetic_NTURain.zip 与 SPAC 版逐字节相同），但训练集始终缺失------这正是早期教师自训不得不改走"真实雨无监督"替代路线的原因。

本次补齐后，方案才能完整支撑"预训练 + 蒸馏"两阶段流程。

1.3 官方渠道

复制代码 
https://github.com/hotndy/SPAC-SupplementaryMaterials
└── Dataset_Training_Synthetic/          ← 本次目标（603 MB）

仓库总容量约 1481 MB ，训练集占 603 MB，其余约 878 MB（测试集 / videoDemos / SP_Matching_Evaluations / SPAC-CNN_code）本次不下载。

2. 故障现象与根因定位

2.1 故障现象

首次执行 --sparse 单段式 clone 时中途失败：

text 复制代码 
Cloning into 'SPAC-SupplementaryMaterials'...
fatal: unable to access 'https://github.com/hotndy/SPAC-SupplementaryMaterials.git/':
GnuTLS recv error (-110): The TLS connection was non-properly terminated.
bash: cd: SPAC-SupplementaryMaterials: No such file or directory

2.2 根因定位

关键判据是报错发生的阶段：

  • 报错出现在 Cloning into ... 之后、Enumerating objects 之前
  • 此时尚未进入数据传输阶段，仅处于 TLS 连接建立 / 存活阶段

因此可判定：

排查项 结论 依据
仓库是否存在 ✅ 存在 GitHub API 可访问，返回 34 个条目
命令是否正确 ✅ 正确 同一命令结构重试即成功
磁盘空间是否不足 ✅ 无关 报错为 TLS 层，非文件系统层
网络链路 ❌ 故障源 GnuTLS recv error (-110) 是连接被对端重置

→ 根因：国内直连 GitHub 时 TLS 连接被中途掐断，与仓库、命令、本地环境均无关。

2.3 故障的间歇性特征

需要如实记录一点：本次重试成功时并未显式执行 source /etc/network_turbo 学术加速 ，仅将命令由单段式改为两段式（--no-checkout + sparse-checkout + checkout）。

这说明该故障具有间歇性（stochastic）特征，而非确定性失败。工程含义：

  • 判断为网络抖动时，优先重试往往比立即改配置更省时间
  • 但也不应据此认为学术加速无效------它是稳定的兜底手段，建议在连续两次失败后启用：
bash 复制代码 
source /etc/network_turbo

3. 解决方案：两段式部分克隆

3.1 完整命令序列

第 1 步 · 仅拉取对象图，不检出工作区

bash 复制代码 
cd ~ && git clone --progress --depth 1 --filter=blob:none --no-checkout \
  https://github.com/hotndy/SPAC-SupplementaryMaterials.git

实测输出：

text 复制代码 
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 0), reused 7 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (8/8), done.

第 2 步 · 声明稀疏范围并触发按需拉取

bash 复制代码 
cd ~/SPAC-SupplementaryMaterials && \
  git sparse-checkout init --cone && \
  git sparse-checkout set Dataset_Training_Synthetic && \
  git checkout

实测输出：

text 复制代码 
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 35 (delta 1), reused 33 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (35/35), 603.15 MiB | 5.18 MiB/s, done.
Resolving deltas: 100% (1/1), done.
Updating files: 100% (35/35), done.

3.2 各参数的作用机理

参数 层级 作用 本次效果证据
--progress 传输 强制在非交互终端也打印进度 完整可见 Receiving objects 百分比
--depth 1 历史 浅克隆，只取最新 commit 无历史回溯开销
--filter=blob:none 对象 blobless 部分克隆：commit/tree 照常取，文件内容（blob）延后按需拉取 第 1 步仅 8 个对象即完成
--no-checkout 工作区 不检出文件，避免立即触发全量 blob 下载 第 1 步耗时可忽略
init --cone 稀疏 目录级（而非 glob 模式）稀疏规则，更快且更安全 无意外匹配
set Dataset_Training_Synthetic 稀疏 声明唯一需要的工作区目录 仅该目录被 materialize
git checkout 触发 触发按需拉取该目录下的 blob 第 2 步下载 603.15 MiB

核心机制 ：--filter=blob:none 与 --no-checkout 联手"冻结"文件内容下载，直到 sparse-checkout set 明确了范围，再在 checkout 时精确拉取。相比单段式 --sparse，两段式的优势是：

  1. 范围可控------可在 checkout 前二次确认稀疏规则，避免误拉全量
  2. 失败可续------万一 checkout 阶段断线，只需重跑 checkout，不必重做整个 clone
  3. 进度可读 ------下载量以 Receiving objects 明确显现，便于估算时长

3.3 分阶段耗时与吞吐实测

阶段 传输量 对象数 耗时 说明
第 1 步：拉对象图 ≈ 0 8 秒级 印证 blob 过滤生效
第 2 步：拉文件内容 603.15 MiB 35 约 116 s 实测速率 5.18 MiB/s

计算：603.15 MiB ÷ 5.18 MiB/s ≈ 116 s ≈ 1 分 56 秒

工程参考值：按 5 MiB/s 估算，603 MB 数据约需 2 分钟；该速率可作为后续拉取同类数据集体量的基准。

4. 验收：三重数字化校验

核验原则：验收必须用可量化的数字指标，不能用"能否打开 / 能否解压"这类定性判断。（历史教训：曾因压缩包恰好截断在整数 MiB 边界而误判为完整。）

# 校验命令 预期 实测 结果
1 `ls Dataset_Training_Synthetic/*.rar wc -l` 33 33
2 `ls Dataset_Training_Synthetic/t*Rain*.rar wc -l` 25 25
3 du -sh Dataset_Training_Synthetic ≈ 603M 604M ✅

三项全部命中，且第 2 步传输日志明确报告 603.15 MiB，与 GitHub API 预先测得的理论值 603.0 MB 吻合（差异来自 MiB/MB 换算），下载完整性确认成立。

5. 与预期的两处偏差校正

本次拉取同时校正了两处此前的错误预期，均需在后续流程中作为既定事实使用。

5.1 训练集是 RAR 归档，不是解压好的帧目录

Dataset_Training_Synthetic/ 实际内容为 34 个条目：

复制代码 
34 = 1 × readme.md + 25 × tN_Rain_MM.rar + 8 × tN_GT.rar

影响 ：t*_Rain_* 匹配到的是带 .rar 后缀的文件 ，解压前不能当作帧目录直接送进 DataLoader。此前给出的 ls -d t*_Rain_* | wc -l 数目录的验收方式语义错误，已修正为 ls t*_Rain_*.rar | wc -l。

5.2 雨序列实际为 25 个，论文表述为 24 个

场景 雨变体数 序列
t1 / t2 / t3 / t4 / t5 / t6 / t8 各 3 tN_Rain_01 .. 03
t7 4 t7_Rain_01 .. 04

合计 3 × 7 + 4 = 25。

论文原文写的是 "The training set contains 24 synthetic rainy videos and the corresponding ground truth."，与仓库实际不符------很可能是 t7_Rain_04 在论文投稿后补传，或论文笔误。

处理原则 ：以仓库实际为准 ，验收标准按 25 ；同时在校验清单中记录该偏差，避免后续与 nturain_train.txt 比对时误判为数据缺失。

6. 数据资产清单与命名规则

6.1 资产构成

类别 数量 命名 体积 说明
雨序列 25 tN_Rain_MM.rar 460.2 MB 训练输入
背景真值 8 tN_GT.rar 142.8 MB 训练标签
说明文档 1 readme.md --- ---
合计 33 rar --- 603.0 MB 单文件 14--25 MB

6.2 命名规则

text 复制代码 
tN_GT.rar        第 N 个场景的干净背景，一场景一个（8 个）
tN_Rain_MM.rar   第 N 个场景的第 MM 个雨变体（25 个）

6.3 与测试集命名体系的区分 ⚠️

集合 命名形式 相机条件
训练集 t1_Rain_01、t7_Rain_04 场景 × 雨变体
测试集 a1_Rain_01、b1_Rain_01 a 组慢速相机 / b 组快速相机

两套命名体系不可混用，编写数据列表文件时需分别处理。

7. 后续步骤

7.1 立即执行：解压 33 个 RAR

先探环境，再决定安装方式：

bash 复制代码 
which unrar unar 7z p7zip 2>/dev/null; echo "---"; python -c "import rarfile" 2>&1 | tail -1

若均缺失：

bash 复制代码 
apt-get update && apt-get install -y unrar

解压示例（先单文件试跑，确认无误再批量）：

bash 复制代码 
cd ~/SPAC-SupplementaryMaterials/Dataset_Training_Synthetic
unrar x -o+ -y t1_Rain_01.rar

本地兜底：Windows 端 WinRAR 位于 D:\Ccopy\Program Files\WinRAR\，可用 UnRAR.exe x -o+ -y <file>.rar . 静默解压。

⚠️ 不要用 Windows 自带的 tar.exe（bsdtar）解 rar ------它会报 Parsing filters is unsupported。

7.2 数据列表对齐

bash 复制代码 
ls -d t*_Rain_*  | wc -l    # 解压后应为 25 个目录
ls -d t*_GT*     | wc -l    # 应为 8

核对 VDMamba-main/lists/nturain_train.txt：若只列 24 条，需补齐 t7_Rain_04，否则训练时会静默少一个序列。

7.3 接入蒸馏流水线

数据就位后即可进入 VDMamba → NAFNet 方案的 P2 接线阶段：教师预生成输出/特征 → 学生按配对数据训练。

8. 可复用命令速查

bash 复制代码 
# ===== 一次性拷贝版：拉取任意仓库的指定子目录 =====
REPO="https://github.com/hotndy/SPAC-SupplementaryMaterials.git"
DIR="Dataset_Training_Synthetic"

cd ~ && git clone --progress --depth 1 --filter=blob:none --no-checkout "$REPO"
DIRNAME=$(basename "$REPO" .git)
cd "$DIRNAME" && \
  git sparse-checkout init --cone && \
  git sparse-checkout set "$DIR" && \
  git checkout

# ===== 验收 =====
ls "$DIR"/*.rar | wc -l      # 期望 33
du -sh "$DIR"                # 期望 ≈ 603M

连接失败时的对策序列：

bash 复制代码 
# 1) 先重试（故障具间歇性）
# 2) 连续两次失败 → 开学术加速
source /etc/network_turbo
# 3) 仍失败 → 换 GitHub 代理
git clone --progress --depth 1 --filter=blob:none --no-checkout \
  https://ghfast.top/https://github.com/hotndy/SPAC-SupplementaryMaterials.git

9. 方法论提炼

本次拉取沉淀出四条可复用于其他数据集获取的规则：

① "blobless + no-checkout + sparse" 是只取子目录的标准范式

不需要完整历史、不需要全仓库内容时，三者组合能把传输量压到最小。判据是第一步的 Enumerating objects 数量------本次仅 8 个对象，说明 blob 过滤确实生效；若该数字接近仓库文件总数，则说明 filter 未生效。

② 传输故障的定位看"报错发生的阶段"

  • 报错在 Cloning into 之后、Enumerating objects 之前 → 连接层问题（网络），非仓库/命令问题
  • 报错在 Receiving objects 中途 → 传输层问题，优先考虑续传或换渠道
  • 报错在 Updating files → 本地层问题，检查磁盘与权限

本次属第一类，重试即通。

③ 验收必须数字化，且要用"与理论值交叉核对"的方式

本次的完整闭环是：GitHub API 预查理论体积（603.0 MB）→ 传输日志实测（603.15 MiB）→ 本地 du 复核（604M）+ 条目计数（33 / 25）。三方一致才判为成功。仅凭"命令没报错"或"能解压"不足以验收。

④ 论文描述与仓库实际不一致时，以仓库为准并显式记录偏差

"24 序列 vs 25 序列"这类偏差不会导致报错，但会污染后续所有实验的对齐基准。正确做法是：记录偏差 → 定下新标准 → 在后续所有校验点使用新标准，而不是让偏差在流水线里静默传递。

文档结束 · 2026-10-15

相关推荐
samFuB1 小时前
【矢量】全国省会、地市、县市驻地点位数据（更新至2024年）
大数据
cspttty1 小时前
2027校招：大数据管理与应用专业如何匹配电商运营与供应链管培生能力要求
大数据·数据库
天府云创1 小时前
Anthropic重做Git：Scion——Agent时代的版本管理系统
git·svn·版本控制·软件设计·迭代升级·scion
岁月刘声机1 小时前
国标实施｜《法律法规电子文件》三项标准正式施行，电子文档可信闭环成关键
大数据·人工智能·microsoft
阿乔外贸日记2 小时前
美国买家资产包装套路与应收款尽调框架，580万应收账款案例解析
大数据·服务器·人工智能·microsoft·云计算
小羊没烦恼！2 小时前
在.net中读写config文件的各种方法
java·大数据·运维·服务器·前端·数据库·oracle
scaryFann2 小时前
职责半径与交接契约：企业智能体团队的边界建模方法
大数据·人工智能
zhixingheyi_tian3 小时前
Spark Configuration 与 AI
大数据
骑着蜗牛撵大象3273 小时前
Spring AI + Qwen3.8 周报助手：从事项采集到人工确认卡的闭环实战
人工智能·spring·elasticsearch·自动化·大模型应用·qwen3.8·rag溯源
热门推荐
01「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03GitHub 镜像站点04历年考研数学一、数学二、数学三真题试卷及答案PDF05几个好用的ip纯净度检测网站06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07Telegram APK 下载安装完整指南 — 2026年最新08Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10苹果iPA游戏软件资源下载网站