加载 Ming-Image-0.1-Design 时进程直接抛错退出，先查依赖还是先查权重路径，主要看报错停在哪个阶段：堆栈停在 import 或库初始化，优先查依赖与运行时版本；已经进到读配置、读权重张量阶段才报错，优先查权重文件完整性、分片命名和路径权限。在没拿到完整报错原文之前就改配置、换版本或重下权重，通常会把问题变复杂。建议先把完整堆栈和退出码存成日志，再按缺依赖、路径与文件不完整、显存不足这三类分别判断。

判断顺序建议是：先留完整堆栈与退出码，按关键词把报错归入依赖、权重文件与路径、显存三类中的一类，再逐类确认。依赖问题看 import 阶段和版本声明，权重问题看文件大小、分片数与路径可达性，显存问题看加载阶段的设备读数与日志。三类之外的情况需要结合具体环境确认，不要靠反复重下权重或随意替换版本来试。

把完整报错原文和退出码留下，先分类型

重跑一次加载脚本，把标准输出和错误输出一起写入文件，并保留退出码：

python -u run_load.py > load.log 2>&1; echo "exit=$?"

不要只看最后一行。用下面的方式把关键行连同行号拉出来，判断它出现在堆栈的哪一层：

grep -nE "Traceback|Error|ModuleNotFound|ImportError|CUDA|out of memory|safetensors|No such file|Permission|raise" load.log

先归类再动手，比盲改配置有效。三类（及相邻阶段）报错的判别对照如下：

验证方式：每改一处，用同一条命令重跑，确认报错是消失、前移还是换成了新的关键词。风险边界：设备上有其他进程占用时，不要一看到报错就断定模型文件损坏或版本不兼容。

确认权重文件是否完整：大小、分片数、校验

排除依赖之后，先看清权重目录里到底有什么，不要默认下载一定完整：

ls -lh ./weights
du -sh ./weights

接着核对分片数量。常见命名形如 model-00001-of-00008.safetensors，of 后面的总数就是应有分片数；目录里通常还有索引文件（常见为 model.safetensors.index.json），其中 weight_map 列出的分片应与磁盘文件一一对应。下面这行仅为示例，索引文件名要按项目实际替换：

python -c "import json,os; idx=json.load(open('./weights/model.safetensors.index.json')); shards=sorted(set(idx.get('weight_map',{}).values())); [print(s, os.path.exists('./weights/'+s), os.path.getsize('./weights/'+s) if os.path.exists('./weights/'+s) else '-') for s in shards]"

判断依据：每个分片都存在，且没有接近 0 字节的文件。项目若提供校验文件（如 .sha256、MANIFEST 之类），用 sha256sum 逐项比对；没有对应校验值时，只能确认大小和分片清单一致，不要凭感觉宣布文件损坏。

验证方式：补下缺失分片后再跑一次加载，看 missing key 或 header 类报错是否消失。风险边界：重新下载要使用同一个 revision 或同一份发布包，混用不同提交的分片容易出现 missing/unexpected keys。

确认依赖与运行时版本是否匹配

先记录当前解释器和已装包，方便回退：

python -V
python -c "import sys; print(sys.executable)"
pip freeze > before.txt
python -m pip show torch
python -m pip list | grep -iE "torch|transformers|safetensors|accelerate|diffusers|numpy"

包名按项目实际依赖替换，不限于示例里的几个。识别报错中的版本相关行：如果 traceback 最后一行指向某个库的 .py 或 .so 文件，说明失败发生在该库内部；出现 cannot import name、has no attribute、undefined symbol，通常与库版本或编译环境有关；而 ModuleNotFoundError 是包根本没装，或没装进当前这个解释器。

允许的版本区间以项目自带的依赖声明为准，比如 requirements.txt、pyproject.toml、environment.yml 或安装说明中写明的范围。不要凭记忆直接装最新版，也不要看到版本号与期望不同就立刻降级。可以先在一个干净的虚拟环境里按声明安装一次，用同一份加载脚本复现：干净环境正常而原环境异常，多半是原环境被其他包污染。

验证方式：用 pip check 看依赖冲突，或在干净环境里复现同一报错。风险边界：涉及 GPU 的包要和本机驱动、运行库匹配，换版本前保留 before.txt 便于回退。

确认路径与权限：相对路径、软链接、读取权限

文件存在不等于能读到。要在运行模型的同一台机器、同一个用户下打印真实路径：

python -c "import os; p='./weights'; print(os.getcwd()); print(os.path.abspath(p)); print(os.path.realpath(p))"
readlink -f ./weights

相对路径的工作目录由启动方式决定，从不同目录启动同一个脚本，解析结果可能不同，所以配置里建议写绝对路径。软链接要看 ls -l 的箭头指向，再用 readlink -f 确认目标真实存在；链接目标被移动或删除时，路径看起来还在，读取会失败。

ls -l ./weights
id
test -r ./weights/config.json && echo readable

如果 test 不通过，再确认运行用户与该文件属主、权限位的关系。必要时只对该目录补读权限，不要扩大范围：

chmod -R u+r ./weights

验证方式：用启动模型的同一个用户执行 test -r，能读到文件后再重跑加载。风险边界：不要直接给 777；容器场景还要确认挂载路径与容器内路径是否一致。

排除前三类后，再回到显存与设备可见性

依赖、文件完整性、路径权限都确认过之后，剩下的常见原因就落在显存和设备可见性上。先看设备是否真的被当前进程看到：

nvidia-smi
echo $CUDA_VISIBLE_DEVICES
python -c "import torch; print(torch.cuda.is_available(), torch.cuda.device_count())"

nvidia-smi 能看到卡，但 torch.cuda.device_count() 为 0，通常是驱动、运行时或可见性设置的问题，而不是权重文件的问题。nvidia-smi 里的显存占用和占用进程也要一起看，加载前显存已被别的进程占满，加载时就会直接报显存相关错误。

日志特征：CUDA out of memory 一般会给出已分配和可用的量，属于容量问题；device not available、no kernel image 这类更偏向设备或编译匹配，需要和依赖那条线一起确认。验证方式：在空闲设备上重跑，或用 CUDA_VISIBLE_DEVICES 指定一张卡复现，看报错是否稳定出现。风险边界：不要用重试或延长等待去掩盖确定性报错；如果只是别的进程释放后就能过，说明问题是显存占用波动，不是模型文件损坏。