Lesson: Share your work on the Hub

You have run a model and fine-tuned one. The last step of Phase 1 turns your work outward: you put a model on the Hugging Face Hub so other people (including future you) can load it with the same from-pretrained call you have been using on other people’s models all along. This is not an afterthought. Almost every model you have used in this track exists because someone took this step. Sharing is the engine that makes the ecosystem work, and now you join the supply side.

Keep a notebook open. You will need a free Hugging Face account; if you do not have one, create it at the Hugging Face join page before you start.

First, prove who you are

Uploading writes to your account, so the library needs an authentication token. You log in once and the token is cached. In a notebook:

from huggingface_hub import notebook_login

notebook_login()

In a terminal, the equivalent is to log in with the hf auth login command. Either way you paste a token from your account settings, and from then on the upload calls know who you are and which namespaces you can write to.

There are three routes onto the Hub, and they trade convenience for control. For almost all work you want the first.

1. The push-to-hub API (use this)

If you fine-tuned with the Trainer, the easiest path is to ask it to upload as it trains. Turn on the push-to-hub flag in your TrainingArguments:

from transformers import TrainingArguments

training_args = TrainingArguments(
    "bert-finetuned-mrpc", save_strategy="epoch", push_to_hub=True
)

Now every time the Trainer saves (here, every epoch) it pushes to a repository in your namespace named after the output directory. When training finishes, one final call uploads the last version and, importantly, generates a model card for you:

trainer.push_to_hub()

That auto-generated card records the hyperparameters and the evaluation results from your run, which is a real head start on documentation.

Even without the Trainer, the same method lives directly on model and tokenizer objects. Load (or build, or fine-tune) them, then push:

model.push_to_hub("dummy-model")
tokenizer.push_to_hub("dummy-model")

The first call creates the repository named dummy-model in your profile and uploads the model files; the second adds the tokenizer files to the same repo. Push the tokenizer too, always: a model without its matching tokenizer is unusable, because the next person needs the exact same text-to-numbers conversion you trained with. To upload into an organization you belong to, put the organization in the repository name (for example, my-org/dummy-model).

2. The Hugging Face Hub Python library

A step lower, the Hugging Face Hub package gives you direct repository tools, useful when you are managing repos programmatically rather than pushing one model. You can create a repo and upload individual files:

from huggingface_hub import create_repo, upload_file

create_repo("dummy-model")
upload_file(
    "config.json",
    path_in_repo="config.json",
    repo_id="your-username/dummy-model",
)

The create-repo call also takes a private flag to hide the repo, and a repository type of dataset or space to make something other than a model. The upload-file route uses plain HTTP and needs no git, though it caps individual files at 5GB. This is the same library that the push-to-hub method is built on, exposed for when you want the finer control.

3. Git and git-lfs (the barebones path)

At the bottom, a Hub repository is just a git repository, with one twist: model weight files are large, so they are tracked by git-lfs (Git Large File Storage) instead of plain git. You install git-lfs once, then clone the repo, save your model and tokenizer into the folder with the save-pretrained methods, then commit and push exactly as you would any repository. git-lfs automatically handles the big files (the weights), while small files (config and tokenizer JSON) go through normal git. You rarely need this path, but knowing the Hub is git underneath demystifies the higher-level calls: they are doing this for you.

What actually gets uploaded

Whichever route you take, a usable model repo contains a predictable set of files: a config file (config.json, the architecture and its settings), the weights (a large file, tracked by git-lfs), and the tokenizer files (the vocabulary, the tokenizer config, and the special-tokens map). That is exactly the set the from-pretrained call expects to find, which is why someone else can load your model with a single line. Sharing is just making that file set public under a name.

The model card is the product

A repository of weights with no explanation is nearly useless to anyone else, so the most important file you write is the model card: a README file at the root of the repo, in Markdown. It is where you tell people what the model does, what data it was trained on, what it is good and bad at, and how to use it. The Trainer’s auto-generated card gives you the metrics and hyperparameters; you add the human context (intended use, limitations, examples). Think of the card as the model’s documentation and its honesty statement at once. A good card is the difference between a model others adopt and a pile of weights nobody touches.

Why this matters when you use AI

Sharing closes a loop you have been benefiting from the whole track. Every pretrained model you loaded, every fine-tune you built on, exists because someone uploaded it with a name and (you hope) a model card. Contributing back is not charity; it is how the ecosystem compounds, and it is also plain practical: a model on the Hub is versioned, loadable from anywhere, and easy to hand to a teammate or a deployment system with one string. The model-card discipline matters most of all. The same honesty you learned to demand in lesson 1 (biases in, biases out; know the limits) is what you owe the next person when you publish. A model card that names the training data and the failure modes is what makes your work trustworthy, and trust is the currency the whole Hub runs on.

What you should remember

Sharing uses the same from-pretrained world in reverse: you upload a model under a name, and anyone can load it with one line. Almost every model you used got there this way.
Authenticate once with a notebook-login call (or the hf auth login command); the token is cached for later uploads.
Prefer the push-to-hub API. The push-to-hub flag in TrainingArguments uploads during training; a trainer push-to-hub call finalizes and generates a starter model card; and the same method works on the model and tokenizer objects directly.
Always push the tokenizer with the model. A model without its matching tokenizer cannot be used.
Under the hood it is git plus git-lfs. Weights are large files tracked by git-lfs; the Hugging Face Hub library and the push-to-hub method are conveniences over that.
The model card (a README file) is the real deliverable. Document the intended use, training data, and limitations. A good card is what turns weights into something others adopt.

A model you keep is a result; a model you share, with an honest card, is a tool other people can build on. That is the whole point of the Hub, and it closes Phase 1: you can now run, adapt, and share.