Publishing weights people can trust

The other side of every lesson so far

At some point you will fine-tune something worth sharing. Everything you have learned about vetting other people’s releases is now a specification for your own: publish the things whose absence made you distrust somebody else.

The whole job is about four hours, most of it writing.

The files

Ship the same shape everyone else ships, because tooling assumes it.

config.json                     # architecture, matching the base
generation_config.json          # eos_token_id, default sampling
tokenizer.json / tokenizer_config.json   # including chat_template
model.safetensors               # or sharded, never pickle
README.md                       # the model card
LICENSE

If you trained a LoRA, publish the adapter and say clearly which base revision it applies to. An adapter without a pinned base is a puzzle for whoever downloads it. Publishing a merged full-weight copy as well is a kindness for people whose serving stack cannot load adapters, at the cost of the disk.

If you publish a GGUF conversion, say which quantisation and from which source revision, because conversions are where silent quality loss enters the ecosystem.

The model card, in the order people read it

One paragraph: what it is and what it is for. Base model, what you tuned it on, the task you built it for. Somebody deciding in thirty seconds should be able to leave here.

Intended use and out-of-scope use. Be specific about out-of-scope. It is the section that protects both of you, and it is the one most people skip. If it is a support-ticket classifier in English and Hindi, say that it has not been evaluated on other languages rather than staying quiet.

Training data. Where it came from, how much, what licence or terms it carried, what you removed, and the date. If it contains anything personal, say what and say how you handled it. If you generated part of it with another model, say which model, because that carries terms of its own.

Evaluation. The number, and everything needed to reproduce it: the harness with its commit, shot count, decoding settings, and whether it is single-sample. Report the base model’s score under the identical configuration next to yours: that comparison is the only one that shows what your work did, and a card that omits it invites the reader to assume the worst.

Limitations, in your own words. What it gets wrong, which inputs break it, where it is worse than the base. This section is the strongest trust signal on the page for exactly the reason you found it persuasive in other people’s cards.

Licence and provenance. Your licence, the base model’s licence, the naming requirement if the base has one, and a line saying what a downstream user inherits.

The bits that go wrong

The licence you cannot grant. A fine-tune inherits the base’s terms. Tagging a Llama derivative Apache 2.0 does not make it Apache 2.0; it makes your card wrong. Where the base requires a name prefix or an attribution line, comply at the point of publishing, not after someone tells you.

A chat template that is missing or subtly different. If you changed the format during training, the template in tokenizer_config.json must match what you trained on, or every user gets degraded output and blames the model. Test it by loading your own repository fresh in a clean directory and running one generation. Half of broken community releases fail exactly here.

A missing or wrong eos_token_id. The symptom is generation that never stops, and it will be reported to you as the model rambles.

Weights that do not match the config. Load your own upload from scratch before announcing it. It takes four minutes and catches the shard that failed to upload.

Safety, without theatre

Say what tuning you did or did not do to refusal behaviour. If you removed safety tuning, say so plainly rather than describing the model as uncensored and leaving the reader to guess what changed. Give a contact route for reports. Decide in advance what you will do if you learn the model is being used for something you find intolerable: usually the honest answer is that you can update the card and stop distributing it, and you cannot recall what has been downloaded. Saying that in the card is more useful than an acceptable-use policy you have no way to enforce.

The test for a good release is simple: hand your own card to the vetting checklist from the previous lesson. If your model would fail your own ten-minute review, fix the card before you announce it.