[bug]: Windows model import crashes in torch_cpu.dll after repeated Safetensors mmap loads; pread avoids the crash

快速结论：在 Windows 上使用 Scan Folder / Install in place 批量导入多个 Safetensors 检查点时，同一后端进程内反复进行模型探测可能让 python.exe 在 torch_cpu.dll 中以原生访问冲突崩溃；优先排查 Safetensors 的 mmap 加载方式以及探测结果对象是否被长期保留。

适用环境：InvokeAI v6.14.2，Windows 11 64-bit（build 10.0.26300），Python 3.12.11，PyTorch 2.7.1+cu128，torchvision 0.22.1+cu128，safetensors 0.8.0，spandrel 0.4.2，numpy 1.26.4，blake3 1.0.9，NVIDIA RTX 5090（32 GB VRAM），系统内存 128 GB；使用 Invoke Launcher 安装，模型方式为 Scan Folder / Install in place。

最快修复方案：暂无确认的一步修复方案。Issue 中验证过的做法是升级到 v7 版本（维护者关闭该 Issue 时说明已在 v7 修复）。在 v6.14.2 上可优先尝试：将模型探测阶段的 Safetensors 加载后端改为 backend="pread"，并在每次模型分类完成后释放分类结果、异常/回溯引用并执行垃圾回收。

注意事项：上述 pread + 引用清理是报告者在本机 6.14.2 上验证过的本地 workaround，并非该 Issue 中的上游补丁；Issue 未给出具体代码 diff。单独处理某个检查点可能不会复现，该崩溃与同一进程内的重复探测有关。已解决的状态以 v7 为准确认。

问题场景

用户在 Windows 上运行 InvokeAI 6.14.2，打开 Model Manager，选择 Add Model → Scan Folder，指向包含多个混合 SD 1.x 与 SDXL .safetensors 检查点的本地文件夹，并启用 Install in place，然后不重启后端、依次导入多个检查点。前几个检查点可以正常哈希和识别，之后某次模型探测让 Python 后端直接退出。报告者还使用 InvokeAI 的模型探测代码在 Web 服务器之外复现了同样问题，说明与浏览器和前端无关。

报错原文

Faulting application: python.exe
Faulting module: torch_cpu.dll
Exception code: 0xc0000005
Fault offset: 0x0000000006013f94
Process exit code: 3221225477

torch/storage.py, line 466, in __getitem__
safetensors/torch.py, line 360, in load_file
spandrel/__helpers/loader.py, line 109, in _load_safetensors
spandrel/__helpers/loader.py, line 79, in load_state_dict_from_file
spandrel/__helpers/loader.py, line 43, in load_from_file
invokeai/backend/spandrel_image_to_image_model.py, line 69
invokeai/backend/model_manager/configs/spandrel.py, line 52
invokeai/backend/model_manager/configs/factory.py, line 697

原因分析

根据 Issue 讨论，模型识别路径上存在两个叠加问题：

默认的 Safetensors mmap 加载后端在 Windows 上多次加载后可能触发 torch_cpu.dll 中的原生访问冲突，导致进程以退出码 3221225477 终止，Python 层无法捕获异常。报告者指出，崩溃取决于同一进程内反复进行模型探测，而不是某个检查点文件损坏；出问题的检查点在全新 Python 进程中单独探测可以成功。
切换到 backend="pread" 后，每次失败的 Spandrel/模型分类尝试仍可能通过结果详情以及异常/回溯引用链保留已加载的 state，造成 RAM 持续增长。报告者观察到每导入一个检查点，内存增加约等于该 .safetensors 文件大小且不回落，长期累积可能触发 Windows error 1455。

因此，原生崩溃的可能原因与 mmap 路径有关；而内存持续增长与分类结果、异常/回溯引用未释放有关。safetensors 文件结构本身并非原因。

环境排查

确认 InvokeAI 版本：Issue 环境为 v6.14.2；维护者表示已在 v7 修复。
确认操作系统为 Windows 11 64-bit，并检查 Windows 事件查看器中是否出现 torch_cpu.dll、异常代码 0xc0000005 和退出码 3221225477。
确认 Python 3.12.11、PyTorch 2.7.1+cu128、torchvision 0.22.1+cu128、safetensors 0.8.0、spandrel 0.4.2、numpy 1.26.4、blake3 1.0.9 等依赖版本是否与 Issue 环境一致。
确认显卡为 NVIDIA RTX 5090（32 GB VRAM），CUDA 环境为 cu128。
确认导入方式为 Scan Folder + Install in place，并观察是否在连续导入多个检查点后才崩溃。
观察任务管理器中 python.exe 的提交内存是否在每次导入后持续上升、不回落。

解决步骤

优先升级到 v7 版本：Issue 维护者在关闭时明确说明“This should be fixed on any v7 Version”，这是该 Issue 中确认过的修复路径。
如果暂时必须留在 6.14.2，可优先尝试报告者的本地 workaround：在模型探测阶段将 Safetensors 加载后端从默认 mmap 改为 backend="pread"，避免触发 torch_cpu.dll 的原生访问冲突。
在每次模型分类完成后，清理/移除分类结果中的结果详情，释放分类结果对象以及异常/回溯引用，并执行垃圾回收，避免已加载的 state 被引用链长期持有。
完成上述组合修改后，在一个后端会话内重新执行 Scan Folder / Install in place 的完整批量导入流程。
如果不想自行修改代码，可先用 v7 验证问题是否消失；Issue 未提供官方 6.14.2 补丁，因此不要在 6.14.2 上期待现成的配置项修复。

验证方法

在同一后端会话中连续导入扫描文件夹里的全部检查点，确认：RAM 在检查点被检查时会临时上升，但每次安装完成后回落到大约相同的总系统占用（报告者环境约为 24.8 GB），不出现逐次累积；不再出现 torch_cpu.dll 访问冲突或 Windows error 1455；不需要重启后端；所有支持的检查点都被识别为 SD 1.x 或 SDXL，而不是停留在 Unknown。若升级到 v7，则在相同导入流程下确认不再崩溃即可。