Loading by Identity: Auto Classes, Revisions, and Weights

A model identifier looks like a simple string, but Transformers treats it as the start of a resolution process. This chapter follows that process from an identifier or local directory to a selected configuration, model class, preprocessing package, and set of weights. The practical value is knowing what the loader is deciding for you, which choices belong in a reproducible experiment, and when “loading a model” crosses the boundary into executing code.

The input contract from the previous chapter makes the problem sharper. It is not enough to find any tokenizer and any model with a matching name. The loader must recover the components that belong together, select a class capable of the requested task, and retrieve an artifact state that can be identified later. Auto* classes and from_pretrained() provide the common route, but they do not remove the underlying decisions.

From an identifier to a model class

An Auto class is a factory, not a model instance that can be created with an ordinary constructor. Its job is to select a concrete implementation based on metadata. The configuration is central to that selection. It identifies the model type and may record architecture names that help choose among compatible classes. The mapping from configuration classes to model classes is maintained by Transformers, so the caller can request a task-level family such as a causal language model or sequence classifier without memorizing the model-specific class name.

The process begins by resolving configuration information. If a caller uses a local directory, the loader looks for the configuration saved with the model. If the caller uses a Hub identifier, the loader resolves the configuration from the repository and records the revision context associated with that file. The configuration can then be used to choose the concrete class. If the requested Auto family has no mapping for that configuration, the process stops with an incompatibility rather than inventing a model class.

This is why task selection matters. AutoModel may select a representation-producing backbone, while AutoModelForSequenceClassification asks for a class with a classification head. A checkpoint can be associated with more than one possible task in principle, but the requested task still has to be supported by the architecture and the available mapping. The Auto class makes the selection interface stable; it does not make a classification head appear on an architecture that cannot support it.

There are two related construction paths. from_config() builds a model from the blueprint but does not load learned weights. It is useful when a user wants to inspect an architecture, create a randomly initialized model, or supply weights through another controlled path. from_pretrained() uses the configuration as part of a larger protocol: it selects the model class, resolves checkpoint files, and loads the learned parameters. Confusing these paths creates a subtle failure because a randomly initialized model can have the right shapes and methods while having none of the behavior associated with the pretrained checkpoint.

The distinction also clarifies what an Auto class does not own.