Question on how to use Hugging Face to download a .safetensors file

Beginners
1

I am very new to Hugging Face. When I try to download a .safetensors file for Comfyui, Hugging Face takes me to a page that does not contain the file I need. The name of the file that I need is at the top, but the page contains multiple files that are not the file I need. However, some of them are .safetensors files. (They usually have names like part1of4.safetensors) I know that everyone is laughing at me but how do I turn the multiple files into the file I need and why can I not just download it as the complete file?

2

Hugging Face hosts files packaged for ComfyUI, but of course it also hosts many files intended for other software; sometimes both can even be present in the same repository. The Hub itself does not necessarily make it obvious which exact artifact a particular ComfyUI workflow expects. So if there is a ComfyUI guide, workflow, or template for the model, I think it is usually safer to start from that guide and follow its link to the exact file you need​:sweat_smile::

I would not try to combine the part1of4.safetensors, part2of4.safetensors, etc. manually yet.

There are a few different things that can look very similar on Hugging Face:

  • a single-file checkpoint intended for tools such as ComfyUI;
  • a standalone diffusion model;
  • a text encoder;
  • a VAE;
  • a Diffusers-format repository containing several components;
  • a large model/component split into several .safetensors shards.

All of those may use the .safetensors file type, so the extension alone does not tell you which one your workflow needs.

The Diffusers documentation on model formats makes this distinction explicitly: Diffusers format and single-file format are different layouts, while safetensors is the file type used to serialize the weights.

My default route would therefore be:

  1. Go back to the ComfyUI workflow, example, template, or tutorial where you saw the required filename.
  2. Find the exact filename it asks for.
  3. Follow the model/file link from that guide if one is provided.
  4. Put that exact file in the directory named by the guide.
  5. Only investigate conversion or merging if the expected artifact genuinely is not published anywhere.

For example, the official ComfyUI Qwen Image example gives exact files such as:

qwen_image_fp8_e4m3fn.safetensors
qwen_2.5_vl_7b_fp8_scaled.safetensors
qwen_image_vae.safetensors

and tells you which ComfyUI directory each one belongs in.

There is also a separate Comfy-Org/Qwen-Image_ComfyUI repository whose model card literally describes the files as “Repackaged model files for ComfyUI” and again lists the appropriate folders.

That is quite different from simply opening the original/upstream model repository and choosing whichever .safetensors file looks closest.

Why the numbered .safetensors files are probably not ordinary 'parts' to concatenate

If you see filenames along the lines of:

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors

especially together with something like:

model.safetensors.index.json

those are normally shards of one model/component.

The index tells the loading library which tensors live in which shard. Hugging Face’s serialization documentation shows this structure directly: the index contains a weight_map mapping tensor names to shard filenames.

So they are not normally equivalent to:

part 1 + part 2 + part 3 + part 4
    -> concatenate bytes
    -> one valid safetensors file

A compatible loader generally reads the shard set using the index.

It is possible to convert/re-save some sharded models into another layout, but that is a separate operation and may not even be necessary for your ComfyUI workflow.

The confusing part: the same model may be published in several useful layouts

This is one reason Hugging Face can be confusing when you are new to it.

For example, the official SDXL repository contains the normal Diffusers component structure — text encoder, VAE, scheduler, etc. — while also publishing a root-level sd_xl_base_1.0.safetensors single-file checkpoint.

So even inside one repository, several different-looking artifacts can legitimately belong to the same model.

For other model families, the ComfyUI-oriented files may instead live in a different repository.

Qwen Image is a good example:

The ComfyUI repository contains files organized around ComfyUI’s loaders and directories rather than requiring the user to infer that structure from the upstream repository.

The ComfyUI Flux examples show another variation. They distinguish between a regular setup using separate model components and an easier single-file FP8 checkpoint version.

So there is no universal rule such as:

“Find the repository for the model and download the .safetensors file.”

There may be many .safetensors files, and they may have completely different roles.

A small decision tree

If you still have the page open, I would check it roughly like this:

Do you know the exact filename ComfyUI asks for?
|
+-- Yes
|   |
|   +-- Is that exact filename linked from a ComfyUI guide/workflow/template?
|   |       |
|   |       +-- Yes -> use that link and the directory specified there.
|   |       |
|   |       +-- No  -> search the exact filename, not only the model name.
|   |
|   +-- The HF page instead shows model-00001-of-0000N.safetensors?
|           |
|           +-- Check whether there is also a *.safetensors.index.json.
|               If yes, you are probably looking at a sharded model/component,
|               not "pieces" that should simply be concatenated.
|
+-- No
    |
    +-- Go back to the ComfyUI workflow/tutorial first.
        Determine:
        - the required filename;
        - what loader node consumes it;
        - and which models/ directory it belongs in.

The loader node is also useful information.

A workflow using a normal checkpoint loader is asking for something different from one loading a diffusion model, text encoder, and VAE separately.

For example, current ComfyUI examples commonly give instructions of the form:

diffusion model -> ComfyUI/models/diffusion_models/
text encoder    -> ComfyUI/models/text_encoders/
VAE             -> ComfyUI/models/vae/

while some easier single-file workflows use:

checkpoint -> ComfyUI/models/checkpoints/

The Flux example page demonstrates both styles on the same page.

If the guide really does point to the sharded files

There is one important exception to the simple “find a ComfyUI single file” rule.

Some workflows or custom nodes can use models/components in their original Transformers/Diffusers-style layout, including sharded weights.

So seeing four shards does not by itself prove that you are in the wrong repository.

If the actual ComfyUI documentation or custom-node documentation intentionally points to that sharded repository, then the correct solution may be to keep all of those files together with their index rather than convert them.

That is why I would identify the workflow and loader before doing any conversion.

A few secondary things to check only if the exact model is already correct

If you eventually establish that you have the correct model/file but ComfyUI still cannot see or load it, then there are several separate troubleshooting branches:

  • correct ComfyUI model directory;
  • a nested subdirectory that the relevant workflow/template is not finding;
  • wrong precision/variant (fp8, bf16, etc.);
  • wrong component type despite a similar filename;
  • an older workflow referring to a renamed or moved artifact;
  • a custom node expecting a different model layout;
  • gated model access or authentication.

Those are worth checking after the artifact identity is settled. Otherwise it is very easy to spend time debugging the wrong file.

So if I were troubleshooting this from scratch, I would start with just three pieces of information:

1. The exact filename ComfyUI says it needs
2. The workflow/tutorial/template where that filename appears
3. The Hugging Face page you arrive at

From those three things it should usually be possible to tell whether you are looking at:

  • the correct downloadable ComfyUI file;
  • a different component;
  • an upstream Diffusers/Transformers repository;
  • a sharded model that should remain sharded;
  • or a model that actually needs conversion.

I would definitely check that before attempting to merge anything.

3

John6666, Thank you for your help. The files are called model-00001-of-0000N.safetensors. There is a a *.safetensors.index.json. So I am looking at a sharded model/component. One final question.

What is a sharded model/component?

4

What is a sharded model/component?

Oh. Basically, these are just files that have been split up because the model is too large, but you may need to be a little careful about how you handle them:

A sharded model is basically one logical model whose weights are stored across several physical files.

For example:

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json

The reason is mostly practical: very large checkpoints are easier to store and load when they are split into smaller files. Hugging Face Transformers supports this directly for large checkpoints.

The important part is that these are not quite like ordinary split archive files that you should simply concatenate back together. The model.safetensors.index.json file contains a map telling the loader which tensors are stored in which shard. A compatible loader reads that index and loads the shards as one logical checkpoint.

So I would avoid manually merging them unless the software/documentation specifically tells you to convert them.

Also, when I said model/component, I meant that sometimes the entire model is sharded, while in other cases only one large part of a larger pipeline — for example a text encoder — is sharded.

For ComfyUI specifically, I would probably check the instructions for the workflow, plugin/custom node, or model you are trying to use. It may expect you to:

  • keep all the shards together and load them as-is;
  • download the whole repository;
  • place them in a particular model directory; or
  • use a separate ComfyUI-ready single-file version instead.

So the existence of the shards itself is not necessarily a problem. The main thing is to follow the loading/layout expected by the particular ComfyUI workflow rather than trying to turn them into one file first.