Skip to content

Conversation

@gary149
Copy link
Contributor

@gary149 gary149 commented Apr 3, 2025

No description provided.

@gary149 gary149 requested a review from Vaibhavs10 April 3, 2025 09:05

- **Prefer [`safetensors`](https://huggingface.co/docs/safetensors/en/index) over `pickle` for weight serialization.** `safetensors` offers improved safety and performance compared to Python's `pickle`.

- push weights to separate model repositories. Example: prefer uploading individual quantizations/precisions in a standalone repo like [this](https://huggingface.co/jameslahm/yolov10n) over all types/versions in one like [this](https://huggingface.co/kadirnar/Yolov10/tree/main).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure this is true (or I misunderstood) tried to simplify

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

- leverage [safetensors](https://huggingface.co/docs/safetensors/en/index) for weights serialization as opposed to pickle.
### Uploading Weights

- **Use separate repositories for different model weights.** For example, you can store quantization variants for the same model in a single repository, but use separate repositories for different model weights.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this goes a bit against what we preach no, each quant, precision, weight type should go in a new repo?

(the only exception is bartowski and Maziyar because they create so many quants it makes sense to have all in one)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhh no we want a single repo with all the quants it really makes more sense imo. cc @julien-c for final decision

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm i see most GGUF repos put different quants in the same repo, yes (and we have nice UI feature for this)

I'm not sure we ever advocated for different quants of the same model to be in ≠ repos actually no?

We did push for ≠ repos for GGUF vs. other formats (Pytorch, etc)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, I'd consider GGUFs as an exception here and more specifically GGUFs produced by model quantisers. For everything else we recommend having one quant per repo (look at MLX community: https://huggingface.co/mlx-community for example) or MLC

(this is also the reason why MLX-my-repo, gguf-my-repo they all create one quant per repo only)

Even for model releases we try to have one quant per repo:

  1. https://huggingface.co/collections/google/gemma-3-qat-67ee61ccacbf2be4195c265b
  2. https://huggingface.co/collections/kyutai/moshivis-v01-67cef4acae6a5d75d6d6c883

There's a lot more examples for this too across model releases.

Something we actively want to discourage is mixed repos - various quants and pytorch models there and the lines can be quite blurry with it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep.

that being said i think the wording in this PR is fine

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay! don't want to be a blocker here! - we can always reword if people get confused!

@gary149 gary149 merged commit 3a20e3f into main Apr 8, 2025
2 checks passed
@gary149 gary149 deleted the model-release-checklist-capitalize branch April 8, 2025 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants