1. 复现目标

这次要复现的论文是：

Toward real text manipulation detection: New dataset and new solution

目标不是简单跑通一个 demo，而是尽量按作者公开的 baseline 路线，复现 DrLuo/RTM 仓库中的 ASCFormer，为后续论文改进实验打基础。

一开始的预期路线很明确：

1. 准备官方代码仓库
2. 准备 RTM 数据集
3. 准备官方 checkpoint
4. 搭环境
5. 先跑通 checkpoint 推理
6. 再做 baseline 指标复现和后续改进实验

---

2. 我的硬件和环境背景

本机环境大致如下：

• GPU：NVIDIA GeForce RTX 5060 Laptop GPU
• 系统路线：Windows + WSL2 Ubuntu
• 目标仓库：DrLuo/RTM
• 主要子项目：ASCFormer

作者 README 给出的官方环境要求是：

• Python 3.8
• PyTorch 2.0.0
• CUDA 11.8
• mmengine 0.7.0
• mmcv 2.0.0
• mmsegmentation 1.0.0rc6（更准确地说，这个仓库是本地 pip install -e . 路线）

这套环境本质上是一条老版本官方路线。

---

3. 前期其实推进得很顺

在真正卡死之前，前面很多事情其实都完成了：

• 论文方向和 baseline 选定
• 官方仓库 clone 完成
• RTM 数据集下载并放到指定目录
• 数据集完整性检查通过
• 官方 checkpoint 下载并放到正确路径
• Python 3.8 环境搭好
• 后来又补建了 WSL 新环境，验证 GPU 在 WSL 中可见

也就是说，这次失败不是因为数据没准备好，也不是因为路径没配好，更不是因为 repo 一开始就坏了。

---

4. 第一个真正的问题：RTX 5060 太新，官方旧环境跑不动

最早的核心问题，是我尝试按官方思路装：

• torch==2.0.0
• torchvision==0.15.1
• torchaudio==2.0.1
• CUDA 11.8

结果在本机 RTX 5060 上，虽然包能装，torch.cuda.is_available() 也可能返回 True，但真正做 GPU 张量计算时，会报类似这类错误：

CUDA error: no kernel image is available for execution on the device

这一步非常关键，因为它说明：

问题不是 WSL 坏了，不是 PyTorch 根本装不上，而是官方旧版 PyTorch/CUDA 对这代新显卡支持不合适。

换句话说：

老代码未必坏，
但“官方旧环境 + RTX 5060”这组组合本身就不稳定。

---

5. 我尝试过“新环境承载老代码”，但这条路也没有走成正式 baseline

既然旧版 torch 2.0.0 + cu118 在本机不稳，我后面就切到了另一条路：

• 在 WSL 中新建环境
• 换到更新版 PyTorch
• 保证本机 5060 至少能正常跑 GPU

这条路在工程上并不是完全没成果，反而推进了不少：

• 新环境里 GPU 可见
• torch 2.11.0+cu128 可运行
• 新版 natten 可导入
• 一些替代实现、fallback 结构、局部模块单测都跑通过
• 甚至真实 img + ela + dct 的推理链路也打通过，预测图也导出来了

但问题在于：

这条线虽然能跑，不代表它就是论文需要的正式 baseline。

因为后面我明确观察到：

• fallback/替代实现和原始 natten 结构不完全等价
• 加载 checkpoint 时有不少 missing / unexpected keys
• 预测 mask 和真值偏差明显
• 也就是说，这条线只能证明“链路通了”，不能证明“官方 ASCFormer baseline 已经严谨复现成功了”

所以我后来把这条路线重新定义成：

功能验证分支 / fallback 分支

而不是正式 baseline。

---

6. 真正卡死的位置：clean 副本卡在 full mmcv

为了避免 fallback 分支污染正式复现，我后来重新开了一个官方 clean 副本，目标非常克制，只做第一轮“无数据集构建检查”：

1. natten 能不能导入
2. 配置文件能不能加载
3. 原版 backbone 能不能 build

前两步其实都通过了：

• natten 可导入
• configs/ascformer/ascformer_rtm.py 可正常加载

真正卡住的是第 3 步：原版 backbone build

最开始看到的直接报错是：

ModuleNotFoundError: No module named 'mmcv'

继续往下排查以后，问题逐渐收缩成：

• 当前环境里没有可用的 full mmcv
• mim install mmcv==2.0.0 拿不到匹配 wheel
• 一旦拿不到 wheel，就会退回源码编译
• 一源码编译，又会撞到新的兼容性问题

这一步的本质不是“少装了个包”，而是：

当前环境组合拿不到可直接使用的 full mmcv 预编译包，
而源码编译 full mmcv 又失败了。

---

7. 我为了解决 mmcv，又继续踩了几层坑

为了继续往前，我做过几轮排查和修补：

7.1 先排查是不是构建工具缺失

我先后补过：

• setuptools
• packaging
• Cython
• ninja

也确实解决过一些表层问题，比如：

• pkg_resources 缺失
• build isolation 里依赖不齐

但这些都只是“往前推进了一步”，没有真正解决最终问题。

---

7.2 再排查是不是 WSL 没有 CUDA toolkit

后来源码编译 mmcv 时又报：

CUDA_HOME environment variable is not set

于是继续排查：

• CUDA_HOME 为空
• which nvcc 没结果
• /usr/local/cuda* 不存在

这说明：

WSL 里虽然能跑 PyTorch GPU，但没有可用于编译 CUDA 扩展的 toolkit。

于是我又安装了：

• cuda-toolkit-12-8

装完之后也确认了：

• nvcc --version 正常
• /usr/local/cuda-12.8 存在

这一步说明：

问题已经不是“没有 CUDA 工具链”了。

---

7.3 最后确认：不是单纯缺包，而是版本组合根本不顺

当 CUDA toolkit 也补齐后，源码编译 mmcv==2.0.0 还是失败。
而且失败点已经从环境基础设施，推进到了 PyTorch 头文件 / NumPy / mmcv 源码构建接口 这类更深层兼容问题。

尤其是在 torch 2.11.0 + cu128 这套组合下，最终暴露出的本质是：

• 这套环境拿不到合适的 mmcv 2.0.0 wheel
• 只能退回源码编译
• 而源码编译又和当前版本栈撞上

所以最终可以把问题说得非常明确：

这次复现失败，不是因为 RTM/ASCFormer 代码仓库本身跑不起来，
而是因为“官方 baseline 所依赖的旧环境”与“本机 RTX 5060 所逼出来的新环境”
之间存在代际兼容性断层。

---

8. 最终我得出的客观结论

结论一：本机 5060 不适合做“官方 baseline 严格复现”的主战场

不是完全不能研究，也不是完全不能跑点东西。

而是：

• 可以做代码阅读
• 可以做局部模块验证
• 可以做 fallback 功能验证
• 可以做环境兼容探索

但是：

不适合继续硬磕“官方 ASCFormer baseline 严格复现”这条主线。

---

结论二：这次失败不是完全没有价值

这次虽然没在本机把 baseline 完整复现成功，但并不是纯浪费时间。
至少明确排除了几条错误路线：

1. 不是数据集有问题
2. 不是 checkpoint 有问题
3. 不是仓库一开始就坏了
4. 不是 WSL 完全不能用
5. 不是单纯少装一个依赖包
6. 真正的问题核心是：环境代际兼容性

这个结论很重要，因为它能避免后面继续在同一台机器上无休止试错。

---

结论三：正式复现更适合转到兼容服务器上做

如果后面还要严肃复现 ASCFormer baseline，我认为更合理的做法是：

• 换一台更接近作者年代环境的机器
• 优先 Linux 服务器
• 优先 3090 / 4090 / A5000 / A6000 / A100 这类更成熟的卡
• 按官方 README 里的 Python 3.8 + torch 2.0.0 + cu118 + mmcv 2.0.0 去搭

也就是说：

不是 baseline 不行，而是本机这条硬件-软件组合不适合作为它的复现场。

---

9. 这次复现失败给我的最大教训

这次最大的教训其实不是某个命令怎么写，而是：

9.1 新显卡不等于更适合复现老论文

硬件越新，不一定越容易复现旧论文。
相反，老论文依赖的老版本 PyTorch / CUDA / mmcv，有时候在新显卡上更容易出兼容问题。

9.2 “能跑”不等于“复现成功”

把模型链路跑起来、甚至把预测图导出来，并不自动等于 baseline 严格复现成功。
如果结构已经改了、依赖已经换代了、权重对位也不完整，那更准确的说法只能是：

功能验证通过

而不是：

正式 baseline 复现成功

9.3 复现前先看“环境代际”

以后复现论文，尤其是 OpenMMLab 生态这类项目，先看的不只是代码和数据，而是：

• 论文发表时间
• 官方依赖版本
• 目标 GPU 代际
• 当前系统能不能拿到匹配 wheel

这一步如果前面不判断，后面很容易陷入长时间的环境泥潭。

---

10. 后续打算

这次在本机上的 ASCFormer 复现，我准备先停在这里。
后续如果继续推进，会优先考虑：

1. 在兼容服务器上复现官方 baseline
2. 服务器复现成功后，把它作为正式实验主战场
3. 本机 5060 只保留为调试机和辅助开发环境

---

11. 一句话总结

如果要用一句话总结这次失败：

这次 RTM / ASCFormer 在 RTX 5060 + WSL 本机上的复现失败，
本质上不是代码仓库坏了，也不是单个依赖没装好，
而是“官方旧 baseline 环境”和“本机新显卡环境”之间存在明显的代际兼容性断层。

---