The Model Landscape: A Taxonomy of Modern AI Models

A taxonomy, not a leaderboard

Ask an architect which model to use and the weak answer names a model. The strong answer names the dimensions that decide, then reads the current field against them. The reason is simple: the leaderboard churns almost monthly. New releases, new versions, new price cuts and new context limits arrive faster than any procurement cycle can absorb, and a recommendation pinned to a specific model is stale before the contract is signed. What does not churn is the set of axes along which models differ. Those axes are the durable object worth learning.

This matters because most model decisions are not really about which model is best in the abstract. They are about which model fits a particular workload given constraints on data residency, latency, cost, customization and operational capacity. Two teams inside the same company can correctly reach opposite conclusions because their workloads sit at different points on the same axes. A taxonomy makes that legible. It turns an argument about favorites into a structured question with a defensible answer that survives the next release cycle.

The rest of this piece walks the six dimensions that carry the most decision weight: openness (how you source and where the model runs), size (the capability-versus-cost trade), architecture (how compute is spent per token), training stage (what the model was shaped into), and modality and specialization (what inputs it handles and what it was tuned for). None of these is a ranking. Each is a spectrum, and a given model is a point in that space. Learn the space, and you can place any new model the day it ships.

By openness

Openness is the highest-level split because it governs how you obtain the model and where the inference physically happens. At one end sit closed frontier models, reached only through a hosted API: you send tokens to the provider and receive a response, and the weights never leave their infrastructure. At the other end sit open-weight models, whose trained parameters you can download and run inside your own environment. This is a sourcing axis first and a capability axis a distant second, which is why it deserves the top of the taxonomy.

The consequences ripple through everything downstream. Closed models mean your data crosses a boundary to the provider, you inherit their pricing, roadmap and deprecation schedule, and you run no infrastructure. Open-weight models keep inference inside your perimeter, remove the per-token meter in favor of a fixed operational cost, and let you fine-tune freely, but you own the GPUs and the serving stack. Neither end is universally correct. The right answer is workload-dependent, and mature enterprises usually run a portfolio of both routed behind a gateway.

One precision worth keeping: open-weight is not the same as open-source. You typically receive the finished weights, not the training data or the process that produced them, and some open-weight licenses carry real usage restrictions. Treat the license as you would any third-party software license. This dimension is deep enough to warrant its own treatment; the full trade-off framework lives in the Open vs Closed deep-dive.

By size

The size axis trades capability against cost, latency and footprint. Large frontier models carry the most parameters and tend to lead on the hardest, most open-ended reasoning, but they cost the most per token, respond more slowly, and demand serious hardware to serve. Small models, often grouped as SLMs, carry far fewer parameters. They are cheaper, faster, and light enough to run on modest infrastructure or closer to the edge, at the cost of some ceiling on the most demanding tasks.

The important trend for an architect is that the small end has been rising steadily. Better data curation, distillation from larger models, and improved training recipes have made small models far more capable than their parameter count once implied. The instinct to reach for the largest available model on every task is now frequently wrong. It overpays, adds latency, and buys capability the workload never uses.

Practically, size is a dial you set per workload, not once for the enterprise. High-volume, latency-sensitive, or narrowly scoped tasks push toward the small end, where cost and speed compound across millions of calls. Genuinely hard, low-volume, high-value reasoning pushes toward the large end, where a few extra points of capability justify the premium. Most real systems end up mixing sizes and routing between them.

By architecture

Architecture describes how a model spends compute internally, and the split that matters most commercially is dense versus mixture-of-experts (MoE). In a dense model, every parameter participates in processing every token: total capacity and per-token compute rise together, locked in step. In an MoE model, the parameters are divided into many expert subnetworks, and a router activates only a small subset of them for each token. Total capacity can be very large while the compute actually spent per token stays much smaller.

The consequence is a decoupling that dense architectures cannot offer. MoE lets a model hold a great deal of total knowledge while keeping the marginal cost of each token closer to a smaller model's. The trade is that all those parameters still have to be held in memory even though only a fraction fire per token, so MoE tends to be memory-hungry to serve. Routing also adds its own engineering and load-balancing considerations. It is not a free lunch; it is a different bill.

   DENSE                          MIXTURE-OF-EXPERTS (MoE)
   every param fires              router picks a few experts
   per token                      per token

   token                          token
     |                              |
     v                              v
  [ ALL params ]                [  router  ]
     |                          /    |    \
     v                        E1   (E2)   E3   (E4)  E5
   output                          |           |
                                   v           v   only these fire
   capacity == compute         capacity >> compute-per-token

For an architect this dimension is mostly invisible at the API surface and highly visible on your own infrastructure. If you consume a model through a hosted endpoint, the provider absorbs the serving trade-offs and you mainly see the effect in price and latency. If you self-host, dense versus sparse changes your memory budget, your hardware selection and your throughput math directly. Read the architecture when you own the serving; treat it as a cost-and-latency signal when you rent it.

By training stage

The same base model can ship as radically different products depending on what happens after pretraining. This is the dimension teams most often overlook, because two models with the same lineage can behave nothing alike. Training stage, not raw size, frequently explains why one variant follows instructions cleanly while another rambles, or why one shows its reasoning and another answers in a sentence.

Three stages are worth distinguishing. A base model has been pretrained to predict text and nothing more; it is a raw completion engine, powerful but not aligned to follow instructions or hold a conversation, and rarely what you want to deploy directly. An instruct or chat model has been post-trained, through instruction tuning and preference optimization, to follow directions and behave as an assistant; this is the familiar product surface. A reasoning model is further shaped to spend extra inference-time compute working through problems step by step before answering, trading latency and token cost for stronger performance on hard, multi-step tasks.

The practical lesson is to name the stage you actually need before comparing models. A high-volume extraction task wants a fast instruct model, not a reasoning model burning tokens to think about a trivial job. A hard analytical task may justify the reasoning premium. And a base model is a starting material, not a deployable product. How each stage is produced, and what post-training actually does, is the subject of the Training Pipeline deep-dive.

By modality and specialization

The last two axes describe what a model consumes and what it was tuned to do. Modality is about inputs and outputs. Text-only models handle language alone. Multimodal models accept combinations of text, images, audio or video, widening the range of problems they can address. Embedding models are a distinct class that many teams forget to account for: they do not generate text at all but convert inputs into vectors for search, retrieval and clustering, and they are the quiet backbone of most retrieval systems. Audio and speech models handle transcription and synthesis. These are different tools, not points on a single quality scale.

Specialization is orthogonal to modality. A general model is trained broadly to handle a wide spread of tasks. A code model is tuned specifically for programming and tends to outperform a general model of similar size on code. A domain-tuned model has been adapted to a field such as medicine, law or finance, trading breadth for depth in its niche. General-purpose is the safe default, but for a workload that lives entirely in one domain, a specialized model can deliver better results at lower cost.

Read across the table and the point of the taxonomy becomes concrete: each row decides something different, so a model is not one score but a position on six axes at once. A large closed multimodal reasoning model and a small open-weight dense embedding model are not competitors on a ladder; they are answers to entirely different questions. The multimodal and embedding dimensions each go deeper in their own right, in the Multimodality deep-dive.

The architect view

The discipline this taxonomy enforces is to choose along the dimensions your workload actually weights, rather than reaching for whatever tops a benchmark this month. A model that wins a headline reasoning test can still be the wrong shape for a task that needs sub-second latency, in-perimeter data residency, or a cost per call low enough to survive millions of invocations. Rank answers one narrow question. Fit answers yours. The two coincide less often than the leaderboard implies.

So the workflow is to state the constraints first, then place the model. Name where the data must live, and openness narrows the field. Name the volume and latency budget, and size and architecture narrow it further. Name whether the task is routine or genuinely hard, and training stage falls out. Name the inputs and the domain, and modality and specialization finish the specification. Only then does comparing named candidates make sense, and by then you are comparing a short list of models that could plausibly fit rather than admiring a leaderboard.

The durable payoff is stability. Specific models will churn underneath you, and they should; the field improves quickly and you want to ride that. But the axes hold. The model you evaluate a year from now will still be somewhere on the openness, size, architecture, stage, modality and specialization spectra, and the constraints of your workload will still select a region of that space. Learn the dimensions, keep a review cadence for the candidates that occupy them, and read the field against your requirements the way any procurement discipline reads a market. That is how a decision survives the next release, and the one after that.