Partial download surfaces as "Cannot detect the model type" rather than a download error

A partially-failed download surfaces as Cannot detect the model type, which points at the model registry rather than at the download.

Setup: v2.1.6 at 4dbf980, Linux, 1×H100, pip install -e ., modelscope 1.39.1, downloading from ModelScope.

Running examples/qwen_image/model_inference/Qwen-Image-Distill-Full.py, some shards failed to fetch. The log says so:

2026-09-02 02:02:47,612 | WARNING | modelscope_hub.download | 4 file(s) failed to download
Loading models from: [
    ".../diffusion_pytorch_model-00003-of-00009.safetensors",
    ".../diffusion_pytorch_model-00004-of-00009.safetensors",
    ".../diffusion_pytorch_model-00001-of-00009.safetensors",
    ".../diffusion_pytorch_model-00007-of-00009.safetensors",
    ".../diffusion_pytorch_model-00009-of-00009.safetensors"
]

Loading continued with those 5 of 9 shards and failed with:

ValueError: Cannot detect the model type. File: [...5 shards...].
Model hash: fcc81cc37454f5cd5d5dc572f15bb3a9

Re-running the same script once the download completed worked and produced an image. Same commit, same script; the only difference was that all 9 shards were present.

As far as I can tell, download_if_necessary resolves the path with glob.glob(...) over whatever is on disk, and since hash_model_file covers the keys and shapes of the files it is given, an incomplete shard set hashes to a value that is genuinely not in model_configs.py. The error at model_loader.py:101 is then the "unknown model" one.

I realise a network failure isn't reproducible on demand, and that re-running is already the intended recovery (download() passes ignore_file_pattern=downloaded_files), which is exactly what worked for me. So the ask is small: would you accept a hint in the message, something like

raise ValueError(f"Cannot detect the model type. File: {path}. Model hash: {model_hash}. "
                 f"If the download was interrupted, some files may be missing; re-running will fetch them.")

or would you prefer a completeness check earlier, at the download step? I didn't want to guess, since this path is shared by every model family.

The current message appears in a few open issues (#1144, #1252, #1462). I haven't checked whether any of them share this cause.

Start in diffsynth/core/loader/config.py at download_if_necessary and then inspect diffsynth/models/model_loader.py:101, where the misleading error is raised. Reproduce or reason through loading an incomplete shard set, and compare it with a completed download. Done means interrupted downloads produce a useful download-related hint without changing successful loading.