Model Families and Generations Explained
Anyone working with large language models and AI systems encounters a jungle of names on a daily basis. At first glance, a typical model name often looks like a random concatenation of brand names, numbers, size designations, and cryptic abbreviations. However, these names try to express three different dimensions at once: which maker the model comes from, which technological generation it stems from, and which specific variant or size it concerns.
Because providers try to cram this information into one short string, confusion quickly arises. It helps to understand how these names are structured and how the underlying logic works. Once you recognize the structure behind the naming, you can more quickly assess what you're dealing with, what impact a switch will have on your infrastructure, and when it's necessary to rerun your evaluations.
The structure of a model name
In practice, a structured model name consists of four recognizable building blocks. Not every provider uses all of them explicitly, but at its core, the structure can almost always be traced back to the same elements.
| Element | Function | Point of Attention |
|---|---|---|
| Family name | Identifies the maker or the product line. | Indicates the general architecture philosophy. |
| Generation number | Indicates a major architecture leap or training round. | Shift in base characteristics and dataset. |
| Size designation | Indicates the scale of capacity or parameters. | Only comparable within the same family. |
| Suffix | Specifies the tuning, task, or mode. | Determines the actual suitability for interaction. |
The family name links the model to a specific organization or a recognizable brand line. Within a family name, successive models often share similar choices in tokenization, base architecture, and design principles.
The generation number indicates a temporal or technological step. A subsequent number usually means the developer has refreshed the base training data, changed the network architecture, or applied a fundamentally different training process.
The size designation refers directly or indirectly to the model's capacity. This sometimes happens explicitly via the number of parameters, but more often with more abstract terms such as 'small', 'medium', or 'large'.
Finally, the suffix indicates the specific post-processing or target audience. Think of designations that indicate whether the model purely completes text, is tuned for following instructions, or is optimized for specific tasks such as reasoning, code generation, or chatting.
The difference between generations and variants
One of the most important distinctions when selecting models is the difference between a new generation and a new variant within an existing generation. This distinction largely determines the impact on an existing software application.
A new generation represents a fundamental revision. The maker has trained the model from scratch on a new dataset, possibly introduced a different context length, or changed the structure of the layers. As a result, the subtle nuances of the model also change: the way it responds to instructions, its language proficiency, and its tendency toward incorrect assumptions. If you switch to a new generation, you should treat the model as an entirely new component of your system. All prompts, edge cases, and evaluations must be retested.
A new variant within the same generation usually involves an interim update. Think of renewed tuning (fine-tuning) to improve safety properties, an expansion of supported languages, or more efficient quantization. Although the base capabilities largely remain the same, even small variant updates can cause unexpected behavioral changes. Detailed information on capturing and managing these interim changes can be found on the page about model versions and deprecation.
Note: A higher generation number does not automatically yield better results for your specific application domain. New generations are often optimized on general benchmarks, which can cause specific niches to perform differently than in the previous generation.
Why a higher version number is no guarantee
It is a common misconception to assume that a newer generation is superior across the board to the older one. When developers build a new generation, priorities shift during the training process. A model may, for example, be significantly improved in logical reasoning and multilingualism, but at the same time be more strictly tuned in terms of safety, causing it to refuse to answer certain creative tasks more quickly.
In addition, changes in the tokenizer can mean that certain domain-specific terms or code snippets are processed more efficiently or, conversely, less efficiently. For those who want to assess in advance which variant best fits a specific use case, the overview on choosing a model offers concrete tools for evaluating these trade-offs.
Size designations: the sense and nonsense of parameter counts
In addition to the generation, a model's size forms an important selection criterion. In the open-source domain, size is often expressed in the number of parameters the model was trained with. For closed models, relative terms such as 'nano', 'micro', 'small', 'medium', or 'large' are often used.
It is essential to understand that parameter counts only provide a useful comparison when you compare two models within the same the same model family and generation. A model with 8 billion parameters from a new generation can perform better on many tasks than a model with 70 billion parameters from an outdated generation. This is due to smarter training architectures, better data quality, and more efficient tuning.
Moreover, the theoretical and practical fundamentals of the model play a major role. If you want to dive deeper into the precise workings of weights and storage formats, check out the explanation about parameters and weights in the learning section.
An additional complication with size designations is the emergence of distilled models. Here, the knowledge of a very large model is transferred to a smaller model. A small distilled model can perform excellently on specific tasks while the total number of parameters remains modest. For a deeper dive into this technique, we refer to the article about distilled models.
Suffixes and the impact of tuning
The letters or words attached to the end of a model name tell you how the model is conditioned. A base model (often referred to as base or simply without a suffix) is purely trained to predict the most logical next word. If you ask a base model a question like "What is the capital of France?", it will not infrequently respond with "And what is the capital of Germany?", because it sees the input as the start of a multiple-choice test.
To make a model usable for interaction, instruction tuning is applied. You can recognize this by suffixes such as:
- Instruct / Chat: The model is optimized to answer questions directly and hold a dialogue.
- Code: The model has received additional training on programming languages and technical documentation.
- Vision / VL: The model can process images as input in addition to text (multimodal).
- Reasoning / Thought: The model uses an internal intermediate step to break down complex problems step by step before answering.
The difference in behavior between a base model and an instruction-tuned model is many times greater than the difference between two successive sizes of the same model. In application development, you work with instruction-tuned variants in the vast majority of cases.
Aliases: navigating moving targets
In many cloud environments and API services, developers encounter so-called aliases or pointer names . These are generic names such as model-latest or model-preview. These aliases point behind the scenes to a specific, hosted model. When the provider offers an update, the alias is redirected to the new model.
Although this is convenient for prototyping, it carries major risks in a production environment. An update to the underlying endpoint can cause your application to give different answers from one day to the next, handle structured input (such as JSON) differently, or refuse in a different way. To ensure consistent results, it is necessary to hedge against this risk. More background on this can be found in the guide about reproducibility.
Best practice for code and configurations
The rule of thumb for software architecture is clear: always use the most specific, versioned model designation supported by the provider in your code, scripts, and configuration files. Only use generic aliases in experimental environments to discover whether a new version adds value.
If you use an intermediate layer or dynamic distribution of requests, it is wise to explicitly specify the specific model. Detailed strategies for managing multiple endpoints can be found in the documentation about model routing.
Open versus closed models: a difference in precision
There is a clear difference in how the open model community and commercial closed providers name their products.
In open models (models whose weights have been publicly released), naming is generally very transparent and detailed. The name almost always includes the family name, the generation, the exact parameter count, the tuning status, and often the quantization level (such as 4-bit or 8-bit). This is necessary because developers need to run the model locally or on their own infrastructure, where memory usage must be calculated precisely.
In closed services (models that are only accessible via an API), providers more often choose marketing-oriented names. Parameter counts and exact network architectures are rarely disclosed. Instead, abstract designations are used to indicate speed and price tiers. However, closed providers often provide date-based version numbers (such as a suffix with a date) to allow specific versions to still be called.
Dealing with changed naming by providers
It regularly happens that a provider overhauls its naming system partway through a product's life cycle. A line that was first indicated with numbers suddenly gets color names, or a size designation is dropped in favor of a new brand name. This can cause confusion in internal documentation and reports.
The most effective method to handle this is to maintain an internal index. Within your own organization, give each model a fixed, internal ID. Link this internal ID in a configuration file to the provider's actual API string. Should the provider change the name of the model or the endpoint, you only need to update the reference in the configuration file, while your internal logs, evaluations, and codebooks remain consistent.
Practical reading order for an unfamiliar model name
When you are confronted with an unfamiliar string in a repository or API documentation, use the following step-by-step plan to parse the name:
- Find the family name: Which organization or brand line is behind this model?
- Determine the generation: Is this a first, second, or later generation within this family? How does this relate to the current state of the art?
- Identify the variant and size: What size class is this, and is it a base model or a tuned version?
- Check the version indicator: Does the name contain a specific date or version number, or is it a generic alias?
- Assess the suitability: Only after going through the above steps does it make sense to determine whether the model is a good fit for your application in terms of content and infrastructure.
By using this systematic approach, you avoid wasting time testing models that don't match your requirements in terms of tuning or size.
