A wooden card index drawer pulled open on a desk under a lamp, the filing cards inside blank and unmarked

Reading a model card

By the end of this guide you will be able to open a model's page, find the handful of facts that decide whether it is usable for you, and ignore the rest. It is for anyone who has been sent a link to a model and is not sure what they are looking at. It is one of the guides.

A model card is documentation written by whoever published the weights. Quality varies enormously. Some are thorough, some are a paragraph and a file list. The skill is knowing which questions to ask of it.

What this assumes

  • The basic vocabulary the card will use without explaining: parameters, quantization, context window, fine-tuning and LoRA. Each links to a short glossary entry.
  • What your machine can hold, which the hardware pages cover, so the file sizes mean something when you get to them.
  • Which file formats your app accepts. GGUF is common for local-first setups. A card offering only some other format may still be usable, but through a different runtime.

Steps

  1. Establish what kind of page you are on. There are three common kinds, and people link to all of them interchangeably. An original release from the lab that trained the model. A fine-tune or merge by someone else, built on top of that release. A conversion or quantization of either, where the weights are unchanged in intent but repackaged. The third kind is what you usually download. It should name its upstream source. If it does not, that is a mark against it.

  2. Find the base model and follow it up the chain. A conversion points at a fine-tune which points at an original. Walk up until you reach a lab you recognise. Most of the substantive documentation, including licence and training details, lives at the top of that chain, not on the page you landed on.

  3. Read the licence, and read it before you get attached. Some weights are permissively licensed, some restrict commercial use, some require you to accept terms before downloading, and some fine-tunes inherit conditions their author did not restate. If you plan to build anything on the model, this is the first thing to check, not the last.

  4. Check the variant. Cards usually list a base model and one or more tuned variants, marked with words like instruct or chat. Base models continue text and will not answer questions the way you expect. If the card does not say, the file names usually do.

  5. Check the context length, and check for a second number. Cards often state a native context length and a larger extended one reached by some technique. The extended figure is usually a ceiling, not a recommendation, and quality can fall off well before it. Also note that the length the model supports and the length you can afford in memory are different questions, covered in will this model fit in memory?.

  6. Read the file list as carefully as the prose. This is where the practical decisions are made. Sizes tell you what fits. Suffixes tell you the quantization level, which is the subject of picking a quantization. Multi-part files need reassembly or an engine that understands them. If one entry is oddly small compared to the others, it may be an adapter rather than a full model, which needs the base weights alongside it.

  7. Look for what the card says it is bad at. Better cards list intended use, known limitations, the languages it was trained on and any evaluation the authors ran. Take stated strengths with scepticism and stated weaknesses seriously, because authors rarely invent flaws.

  8. Branch on hardware class before you commit. On a card with a large VRAM pool you can take a higher-precision entry from the file list. On a unified-memory laptop, start lower and work up. Either way, match the file to the GPU page for your machine before you start the download.

Common mistakes

  • Downloading from a repackager's page without following the chain back to the original, so you never see the licence.
  • Reading the prose and skipping the file list, where the decisions actually are.
  • Treating an extended context figure as a working setting rather than a ceiling.
  • Grabbing an adapter, such as a LoRA, and wondering why it will not load on its own.
  • Assuming an undated card describes the current state of the model. Weights get updated in place, and the text does not always follow.

Related