The fastest way to misunderstand modern AI is to think “LLM architecture” means one stable design. It does not. The transformer introduced in 2017 is still the core skeleton, but the systems people actually deploy in 2026 are no longer just “big dense transformers.” Many of the models setting the pace now are sparse Mixture-of-Experts systems, and several leading open-weight families are also natively multimodal. TensorOps went so far as to call MoE “the default architecture of frontier AI in 2026,” while Meta’s Llama 4 release explicitly described its new open-weight flagship models as both MoE and natively multimodal. DeepSeek’s April 2026 V4 preview made that shift concrete: 1.6 trillion total parameters in the Pro model, but only 49 billion active per token.
That architectural shift is not an academic footnote. Gartner forecast worldwide AI spending at $2.52 trillion in 2026, up 44% year over year, and separately said generative AI model spending in 2026 was still expected to grow 80.8%. McKinsey’s survey work shows why that matters: 65% of respondents in its early-2024 global survey said their organizations were regularly using generative AI in at least one business function, and by the 2025 edition 71% reported regular gen-AI use while 88% reported AI use in at least one function. Once that many organizations are paying real inference bills, “architecture” stops being theory and becomes budgeting, latency, throughput, deployment topology, and model selection.
My argument in this guide is simple: the history of large language models makes more sense if you organize it by the bottleneck each era solved, not by the release dates of famous products. That is why I use an original framework here: the Five Generations of LLM Architecture. If you learn that framework, you can hear about GPT-4, DeepSeek, Qwen, GLM, Kimi, or the next model that ships next quarter and immediately ask the right question: what bottleneck was this architecture designed to break?
Why most how LLMs work explainers are already out of date
Most “how do LLMs work” articles still explain a dense transformer, full stop: token embeddings go in, attention layers mix information, feed-forward layers transform it, and the model predicts the next token. That description is not wrong. It is just incomplete enough to mislead an engineering team making a real platform decision. A dense transformer activates essentially all of its parameters for every token. A mixture of experts LLM does not. That single difference changes inference cost, memory pressure, routing behavior, parallelism strategy, and how you interpret parameter counts. TensorOps’ 2026 field guide framed this as the central shift in frontier-model design: MoE breaks the link between total model capacity and per-token compute.
The easiest example is the one the industry keeps talking around but rarely explains clearly. DeepSeek-V4-Pro publicly reports 1.6 trillion total parameters and 49 billion active parameters per token. SemiAnalysis reported that GPT-4 used a sparse MoE design with about 1.76 trillion total parameters and roughly 280 billion active per forward pass. By simple arithmetic, that means DeepSeek-V4-Pro activates about 3% of its total parameters per token, while the SemiAnalysis estimate for GPT-4 implies roughly 16% active parameters. Those are not cosmetic differences. They are the difference between “how large the model’s memory is” and “how much of that memory you actually pay to use on each token.”
That is why “LLM parameters explained” has to mean more than repeating a single headline number. In 2020, saying GPT-3 had 175 billion parameters told you something useful about the model’s capacity and about its inference footprint. In 2026, a trillion-parameter headline can hide a model with an active footprint closer to a few tens of billions or a few hundreds of billions. When I explain sparse vs dense LLM architecture to enterprise teams, this is the first mental reset I force: total parameters tell you how much knowledge and specialization the model can store; active parameters tell you much more about the cost and latency you will feel in production.
There is a second reason older explainers age badly: they often confuse architecture with product behavior. The ChatGPT era made many readers think the big breakthrough was “chat.” It was not. The architectural story is that dense scaling made raw capability possible, and the post-training stack, including instruction tuning, preference tuning, and RLHF-style alignment, made that capability usable. Then the sparse era made frontier-class capability economically viable at much larger scales. If you miss that sequence, you miss the GPT architecture evolution that actually mattered.
So the durable question is not “What is the architecture of the current model?” The durable question is “Which generation of architectural thinking does this model belong to?” That is what the next section is built to answer.
The Five Generations of LLM Architecture
Here is the framework I use: the Five Generations of LLM Architecture classify language-model eras by the constraint they removed.
Generation 1: Sequential Memory. Pre-2017 language systems were dominated by recurrent neural networks and LSTMs, which processed sequences one step at a time. Their fundamental pain point was long-range dependency: the signal needed to travel through many time steps, and gradient-based learning became increasingly difficult as dependency length grew. Bengio’s 1994 analysis formalized that problem, and Hochreiter and Schmidhuber’s 1997 LSTM introduced gated memory specifically to address decaying error flow across long intervals. Representative systems in this generation include LSTM language models and seq2seq LSTM systems such as Sutskever et al.’s sequence-to-sequence model and Google’s GNMT, which used deep LSTM encoders and decoders with attention. The next generation became necessary because even when recurrence worked, it still imposed a sequential training bottleneck.
Generation 2: Attention and Parallelization. The 2017 transformer removed recurrence from the core architecture and replaced it with self-attention plus positional encoding. Vaswani et al. described the transformer as based solely on attention mechanisms, “dispensing with recurrence and convolutions entirely,” while also being more parallelizable and faster to train. BERT and GPT-1/GPT-2 proved that this architecture generalized in two strategically different directions: encoder-heavy bidirectional understanding in BERT, and decoder-only autoregressive generation in GPT. The limitation that remained was not architectural expressiveness; it was how much capability you could buy with more data, more compute, and more parameters.
Generation 3: Dense Scaling. Between 2020 and 2022, the industry’s dominant bet was that the basic transformer architecture was “good enough,” and that capability would primarily come from scale. Kaplan et al.’s scaling-laws work showed that loss followed remarkably regular power laws with model size, dataset size, and compute, and GPT-3 turned that research instinct into a product-defining result by showing major gains in few-shot performance at 175 billion parameters. DeepMind’s Chinchilla then sharpened the lesson: scale mattered, but compute-optimal scale mattered more than blindly adding parameters. The next generation became necessary because bigger models were still not reliably helpful, steerable, or safe enough for assistant-style products.
Generation 4: Alignment and Instruction-Following. This is the generation many non-specialists mistake for a new base architecture. It was not. The dominant shift was training methodology. InstructGPT showed that a 1.3B model aligned with supervised fine-tuning plus reinforcement learning from human feedback could be preferred by humans over the raw 175B GPT-3 base model on the target prompt distribution. In parallel, FLAN and later instruction-tuning work showed that finetuning on many instruction-framed tasks dramatically improved zero-shot generalization. ChatGPT then packaged that post-training turn into the interface the world remembers. The next generation became necessary because raw assistant quality was no longer the only constraint; serving cost and multimodal breadth were now the bottlenecks.
Generation 5: Sparse Activation and Multimodal Fusion. In 2024–2026, the defining shift is conditional computation. Modern frontier systems increasingly use sparse MoE layers so they can store far more parameters than they activate per token, making frontier-scale capability economically tractable. At the same time, leading systems are converging on unified backbones that fuse text with vision and, increasingly, other modalities. DeepSeek-V4-Pro’s 1.6T/49B ratio, Meta’s Llama 4 MoE family with native multimodality, and Qwen3’s top-end MoE variants all point in the same direction. Generation 5 exists because dense scale hit an inference wall: the industry needed more capacity without multiplying per-token cost at the same rate.
The crucial subtlety is that these generations are not mutually exclusive modules in a museum. Modern models stack them. A current assistant may use a Generation 2 transformer backbone, a Generation 3 scaling recipe, a Generation 4 post-training stack, and a Generation 5 sparse or multimodal architecture. In practice, I classify a model by the design decision that most strongly explains why it exists in its current form. That is the mental model that scales.
Generations 1–2: how attention broke the sequential bottleneck
Generation 1 was the era of memory under duress. Before transformers, recurrent models processed language in order, one token after another. That matched the structure of text, but it also hard-wired a training constraint: information had to pass through a long chain of recurrent states. Bengio and colleagues showed in 1994 why learning long-term dependencies with gradient descent was difficult. Hochreiter and Schmidhuber’s LSTM, published in 1997, was a direct response to that failure mode, designed to preserve gradient flow over much longer spans through gated memory cells. If you want the big picture, Generation 1 is the era when the field kept trying to teach networks not to forget what happened 50, 100, or 500 tokens ago.
Seq2seq systems were the best version of that world, not an escape from it. The 2014 sequence-to-sequence paper by Sutskever, Vinyals, and Le showed that deep LSTMs could map one sequence into another effectively enough to push translation forward. Google’s GNMT system in 2016 took that family of ideas to production scale with deep LSTM encoders and decoders, attention, residual connections, and wordpiece tokenization. Those systems were important because they proved that learned end-to-end sequence modeling could beat older phrase-based pipelines. But they were also where the limits became obvious. GNMT still had to wrestle with recurrent computation, expensive training, and the practical difficulty of handling longer sequences cleanly.
Attention began as a workaround before it became the main event. Bahdanau, Cho, and Bengio’s 2014 attention paper diagnosed a key bottleneck in RNN encoder-decoder models: forcing the entire input sequence through a single fixed-length vector made performance degrade, especially on longer sentences. Their solution was to let the decoder “soft search” over relevant parts of the source sentence when producing each output token. That was the intellectual bridge between the recurrent era and the transformer era. Attention first arrived as a patch for bottlenecked memory. Then it became the organizing principle of the whole architecture.
Transformer architecture explained in one practitioner sentence: every token builds a weighted view of the other tokens it should pay attention to, the model mixes those views through stacked layers, and positional information tells it where each token sits in the sequence. The 2017 transformer paper made two strategic moves at once. First, it replaced recurrence with self-attention, which let the model relate distant tokens directly rather than step information through many recurrent updates. Second, it made training far more parallelizable because tokens in a training sequence could be processed together rather than strictly one after another. Vaswani et al. explicitly framed the transformer as more parallelizable and significantly faster to train while outperforming strong recurrent baselines on machine translation.
Positional encoding was not a side detail; it was the price of removing recurrence. RNNs get order “for free” because they consume tokens in order. A transformer does not. Once the architecture stopped stepping through tokens sequentially, it needed another way to represent order. That is why the transformer paper added positional encodings to token embeddings. This sounds mechanical, but it is exactly the kind of architectural trade that matters in the history of large language models: remove one bottleneck and you must explicitly reintroduce the useful bias you lost.
BERT and GPT were the proof that the transformer was not a translation trick. BERT showed that deep bidirectional transformer encoders could become a general-purpose language-understanding backbone, achieving state-of-the-art results across major NLP benchmarks with minimal task-specific modification. GPT-1 showed the complementary path: a decoder-only transformer pretrained on unlabeled text and then fine-tuned across tasks. GPT-2 then pushed the same decoder-only direction harder, demonstrating that a large autoregressive transformer trained on WebText could perform multiple tasks in a zero-shot or lightly prompted way without task-specific supervision. That split still matters today. BERT-era models proved the transformer could understand language broadly; GPT-style models proved autoregressive pretraining could unify generation and many downstream tasks in one scalable recipe.
Why Generation 2 won so decisively: it solved two problems at once. It improved the model’s ability to capture long-range relationships, and it aligned much better with modern hardware because parallel training throughput improved dramatically. That hardware fit matters more than many conceptual explainers admit. A beautiful architecture that fights your accelerators rarely becomes the dominant one. The transformer did the opposite. It was mathematically cleaner for long-range interactions and operationally friendlier to large-scale GPU training. That is why the field reorganized around it so quickly.
If you want the background before this point in the story, the cleanest companion read is the deep learning fundamentals underpinning all five generations. But the short version is this: Generation 1 fought forgetting; Generation 2 removed the sequential bottleneck altogether.
Generations 3–4: scaling laws, GPT-3, and the alignment turn
Generation 3 began when the industry stopped asking whether transformers worked and started asking how far scale could push them. Kaplan et al.’s scaling-laws paper was one of the most consequential empirical results in modern ML because it suggested that language-model loss behaved with unusual regularity as you scaled parameters, data, and compute. That result shifted research culture. It implied that once the architecture was good enough, the main gains might come not from fancy structural tinkering but from increasing scale in a disciplined way. There is a reason the 2020–2022 period felt like a land rush: the research paradigm had become legible.
GPT-3 turned that paradigm into a public fact. The GPT-3 paper showed that a 175B-parameter dense transformer could perform surprisingly broad few-shot and zero-shot tasks simply by conditioning on natural-language prompts and examples in context. That result did not mean scaling solved everything, but it changed the burden of proof. After GPT-3, the default assumption inside many labs was that raw capability would continue to climb if you kept scaling dense autoregressive transformers. This was the high tide of dense scaling as the central answer.
Then Chinchilla forced a corrective that serious infrastructure teams still underestimate. DeepMind’s compute-optimal training work argued that many large language models were undertrained relative to their parameter counts. For a fixed compute budget, model size and number of training tokens should scale together more closely; bigger was useful, but not if you starved the model of data. Chinchilla’s 70B model, trained on far more tokens, outperformed several much larger dense models. That matters for large language model architecture evolution because it marks the moment when “just add parameters” stopped being a credible strategy on its own. Dense scaling matured from brute force into a three-way trade among parameters, tokens, and compute.
But the biggest limitation of Generation 3 was usability, not benchmark potential. Raw next-token predictors are not automatically good assistants. They can be verbose, evasive, unhelpful, or simply misaligned with what users want. InstructGPT made that point painfully clear. OpenAI reported that a 1.3B instruction-following model fine-tuned with human demonstrations and RLHF preferences was preferred by human raters over the original 175B GPT-3 on the target prompt distribution. That is one of the most important facts in the GPT architecture evolution story: a smaller aligned model can beat a far larger base model for the use case people actually care about.
Generation 4 is therefore best understood as the alignment turn. Instruction tuning gave models a supervised prior over how humans ask for work to be done. Preference learning and RLHF pushed outputs toward usefulness, harmlessness, and stylistic compliance. FLAN showed that instruction tuning across many tasks improved zero-shot generalization broadly, and later scaling work on instruction-finetuned models showed those gains often grew with both model size and task diversity. OpenAI’s ChatGPT launch made the point visible to the public by describing the system as a sibling model to InstructGPT, trained to follow an instruction and provide a detailed response.
This is where many architecture discussions go soft and start hand-waving. They should not. Alignment is not fluff layered on top of “the real model.” In practice, post-training is what turns a capable but erratic base model into an assistant people can trust inside a product. When engineering teams argue about quality differences between two model versions, they are often arguing about the post-training stack as much as the base pretraining run. That is also why how architecture choices shape effective prompting strategy is more than a prompting article: prompting works differently when a model has been aggressively instruction-tuned versus when it remains closer to raw next-token behavior.
Generation 4 also explains why the market started caring about model “helpfulness” as a first-class property. Scaling improved latent capability. Alignment made that capability legible and steerable. Without Generation 4, Generation 3 would likely have remained impressive but narrower, stronger at benchmark-style pattern completion than at mass-market assistant behavior. With Generation 4, the interface layer and the training layer finally snapped together. That is why the assistant product form exploded after late 2022 even though the base architectural skeleton was still largely “just” a transformer.
If you care less about internals and more about the workflow implications, the useful companion article here is what working with these models actually looks like day-to-day for a data scientist. But for architecture, the takeaway is sharper: Generation 3 made models broadly capable; Generation 4 made them broadly usable.
Generation 5: Mixture-of-Experts, active parameters, and multimodal fusion
Generation 5 starts from a hard infrastructure truth: dense transformers hit an inference wall. SemiAnalysis argued in 2023 that the real brick wall for frontier LLMs was inference, not training, and described sparse architectures as the route to decoupling training compute from inference compute. That same logic echoes through today’s MoE deployments. If every parameter must be loaded and used for every generated token, scaling quickly runs into memory-bandwidth, latency, and serving-cost constraints. Sparse activation is the architectural answer to that problem.
The roots of that answer predate the current hype by a long time. Jacobs and Jordan’s early 1990s mixture-of-experts work introduced the basic idea of multiple specialized submodels combined by a gating mechanism. Shazeer et al.’s 2017 sparsely gated MoE layer brought the concept into modern deep learning more forcefully by showing conditional computation could increase model capacity by orders of magnitude without proportional compute growth. Switch Transformer then pushed the idea toward trillion-parameter language models with simpler routing and better training stability. Generation 5 did not invent MoE; it finally made MoE the practical answer to frontier-scale language modeling.
A practical transformer architecture explained for the MoE era looks like this: the model usually keeps the familiar transformer backbone, but some of the dense feed-forward blocks are replaced with banks of experts. A router scores experts for each token and dispatches the token to the top one or two experts, while shared layers or shared experts preserve a common representation across the whole model. IBM’s overview captures the general idea, TensorOps shows how it is implemented in current LLMs, and Meta’s Llama 4 write-up makes the deployment consequence explicit: all parameters are stored in memory, but only a subset are activated while serving the model.
This is the cleanest way to understand sparse vs dense LLM architecture. In a dense model, parameter count and compute cost rise together. In an MoE model, total parameters and active compute partially decouple. That does not mean MoE is “free.” You still pay memory, routing overhead, expert-parallel communication, more complicated serving, and sometimes trickier load balancing. But the decoupling is real enough to change what is economically feasible. Switch Transformer reported trillion-parameter-class sparse models with constant computational cost per example relative to the activated path, and TensorOps describes the same principle as the defining modern advantage: enormous representational capacity at the cost profile of something much smaller.
The 2026 numbers make the point better than any analogy. DeepSeek’s official V4 preview release states that V4-Pro has 1.6T total parameters and 49B active parameters, while V4-Flash has 284B total and 13B active. TensorOps’ 2026 landscape summary places DeepSeek-V4 alongside other leading open MoE models such as Qwen3-235B-A22B, Llama 4 Maverick, Mistral Large 3, and Kimi K2. On the closed-model side, SemiAnalysis reported GPT-4 as a sparse design around 1.76 trillion total parameters with roughly 280 billion active per token. If you remember only one Generation 5 mental model, remember this: frontier capability is increasingly bought with total parameters, but frontier cost is increasingly controlled by active parameters.
That is also why “bigger” became a less meaningful standalone adjective. A 1.6T model that activates 49B per token is not operationally comparable to a hypothetical 1.6T dense model. The dense model would be punishingly expensive to serve. The sparse model can be much more tractable, though still demanding. SemiAnalysis argued that a trillion-parameter dense model could not achieve practical assistant throughput on then-current H100 servers, while sparse activation made models larger than a trillion parameters plausible for broad deployment. This is the architecture decision that actually moves the cost needle in production: not the headline capacity alone, but how much of that capacity fires per token.
MoE is only half of Generation 5. The other half is multimodal fusion. Meta’s Llama 4 announcement described Scout and Maverick as the first open-weight natively multimodal Llama models and Meta’s first built with a mixture-of-experts architecture. The company also described “early fusion” into a unified backbone so text and vision tokens could be jointly processed, rather than treating vision as a bolt-on late-stage component. That matters because it signals where leading design is headed: not separate specialist models glued together after the fact, but increasingly unified architectures that can reason across modalities end to end. If you want the dedicated deep dive here, the right handoff is how these architectures extend into multimodal systems that combine text, vision, and audio.
Generation 5 is also where architecture becomes visibly commercial. Gartner’s 2026 spending forecast and its separate 80.8% growth projection for generative-AI model spending make clear that model economics are no longer niche concerns. When spending is growing this quickly, the active-vs-total parameter distinction affects procurement, deployment footprint, cloud cost, and vendor strategy. The teams I see making the best architectural decisions do not ask “What is the smartest model?” in isolation. They ask a harder question: “What level of intelligence can we sustain at our required latency, concurrency, and budget?” Generation 5 exists because that is now the right question.
This is also why current model work bleeds into systems work. A no-code agent platform, a coding copilot, and a multimodal customer-support assistant may all sit on the same class of backbones, but their economics and evaluation needs differ wildly. That is why how this same class of models powers no-code AI agents is ultimately about the same architectural trend, and why no serious architecture discussion is complete without how to evaluate whether a model is actually good once you understand its architecture. MoE gives you new knobs. It also gives you new failure modes: routing imbalance, serving complexity, and often benchmark ambiguity when people quote total parameters as if they were active compute.
Where architecture is headed next: not away from transformers overnight, and not toward some magical single leap that makes today’s systems obsolete. The most plausible near-term path is continued stacking of three ideas: transformer backbones, more aggressive sparsity and routing sophistication, and more compute spent at inference time on reasoning or tool use rather than only during pretraining. That is partly an inference on my part, but it is an evidence-backed one: the leading open releases in 2025–2026 are still transformer-based, increasingly sparse, increasingly multimodal, and increasingly shaped by post-training behavior rather than by radical departures from the backbone itself.
FAQ
What is the difference between a transformer and an LLM? A transformer is an architecture; an LLM is a model category. The transformer is the underlying design introduced in 2017: stacked self-attention and feed-forward layers with positional information. An LLM is what you get when you take a transformer-style architecture, train it at very large scale on huge corpora, and usually add a post-training stack so it can follow instructions or act as an assistant. BERT and GPT are both transformer-based, but they are architecturally different uses of the transformer family. Modern assistant models are usually transformer-based LLMs, not “transformers” in the abstract.
How do LLMs work in the shortest accurate explanation? They learn a probability distribution over token sequences and use that distribution to predict the next token, over and over, while self-attention lets each token representation depend on relevant context from earlier or surrounding tokens. That description is faithful to GPT-style models and compatible with the transformer architecture explained in the research literature. What changes across generations is how efficiently the model can build and use those representations: recurrence in Generation 1, parallel self-attention in Generation 2, larger dense pretraining in Generation 3, better post-training in Generation 4, and sparse or multimodal computation in Generation 5.
Why do Mixture-of-Experts models activate only some parameters? Because conditional computation is the whole point. MoE systems keep many experts in reserve but use a router to choose only the most relevant experts for each token or example. That lets the model store much more capacity than it pays to execute on every forward pass. Shazeer’s sparsely gated MoE paper, Switch Transformer, IBM’s overview, TensorOps’ field guide, Meta’s Llama 4 description, and DeepSeek’s official V4 release all tell the same story in different language: MoE exists to increase capacity without scaling per-token compute linearly with total parameter count.
Is bigger always better for LLM architecture? No, and this is one of the most abused assumptions in AI writing. Kaplan et al. showed that scale matters, but Chinchilla showed that scale must be compute-optimal, not just parameter-maximal. Then InstructGPT showed that a much smaller aligned model could beat a far larger base model on human preference for the intended task. In practice, “better” depends on the bottleneck you care about: raw capability, latency, cost, controllability, domain adaptation, or multimodal behavior. Bigger models often buy you more capacity. They do not automatically buy you the best product.
How many parameters does GPT-4 actually have? OpenAI has not publicly confirmed the exact number. The most widely cited architecture estimate still comes from SemiAnalysis, which reported GPT-4 as a sparse MoE model around 1.76 trillion total parameters with roughly 280 billion active parameters per token. TensorOps’ 2026 field guide treats GPT-4’s rumored sparse design as the early signal of the current MoE era, though it also notes that the exact total is not perfectly clean because in MoE transformers the replicated feed-forward experts and the shared attention layers are not the same thing. So the honest answer is: no official public count, but the 1.76T total and ~280B active estimate remains the industry’s most cited working figure.
What comes after transformers? My view is that “after transformers” is the wrong framing for the next few years. What comes next is more likely to be post-transformer layering than post-transformer replacement: sparse transformers, multimodal transformers, retrieval-augmented systems, agentic systems, and inference-time reasoning stacks built on top of transformer backbones. Meta’s Llama 4, DeepSeek V4, and Qwen3 all reinforce that point. The backbone is still recognizably transformer-like; the innovation frontier has shifted to sparsity, routing, modality fusion, and post-training behavior. If a true post-transformer break arrives, it will have to beat the transformer not only in capability but also in tooling, scaling behavior, and hardware fit.
Do I need to understand architecture to work with LLMs? Not to get started. Yes, if you want to make consistently good decisions. The difference between a dense model and an MoE model affects serving cost. The difference between a raw base model and an aggressively instruction-tuned model affects prompting behavior. The difference between a text-only backbone and a natively multimodal backbone affects what tasks you should even attempt. You do not need to derive attention equations from scratch to be effective, but if you understand the five generations, you will make better choices about model selection, evaluation, and deployment. For the workflow side, what working with these models actually looks like day-to-day for a data scientist is the practical companion piece.
Are multimodal models a separate category from LLMs? Increasingly, no. In the earlier wave, multimodal systems were often built by bolting separate encoders and decoders together. In the current wave, leading model families are moving toward unified backbones that process text and vision together more natively. Meta’s Llama 4 is the clearest open-weight example: native multimodality, early fusion, and MoE in one architecture. That does not erase the term “LLM,” but it does mean that in practice the boundary between “language model” and “multimodal foundation model” is getting blurrier. The better question is whether the model’s backbone and training stack were built to reason across modalities from the start.
What is the simplest way to place any new model into the right generation? Ask three questions in order. First, what bottleneck is it solving: memory, parallelism, dense scale, alignment, or sparse/multimodal efficiency? Second, is the key novelty in the base architecture or in the post-training stack? Third, when people praise the model, are they really praising total capacity, active compute, or assistant behavior? If you can answer those three questions, you can usually classify the model correctly and, more importantly, you can explain why it was built that way. That is the real value of the Five Generations framework.