LLM models at a glance: kinds and how to choose
Cloud APIs and open models, size, MoE, thinking, multimodal and roles. A brief map of how to sort the many LLM models and how to pick one.
Sort LLM models by how they are offered, their size, what they were tuned for, the inputs they take, and their role, and the landscape becomes clear. Do not choose by name; decide by comparing on questions from your own use.
What an LLM model is
An LLM model is a set of learned weights, trained on huge amounts of text. They all work the same way, repeating choosing the next token by probability. The differences lie in the training data, the size, the tuning after training, and the inputs they handle.
Model names and versions change within months. This article centers on the parts that change slowly, how to sort and how to choose, and keeps specific names to a minimum as examples from October 2026.
Sort along five axes
| Axis | Split | What it changes |
|---|---|---|
| How it is offered | Cloud API / open model (weights distributed) | Where data goes, operational effort, the best performance available |
| Size | Parameter count. Dense models that use everything / MoE that uses a part | Capability, speed, GPUs needed |
| Tuning purpose | Base model / instruction-following / think-then-answer | Ease of use, depth of answers, time |
| Inputs | Text only / multimodal, taking images and more | Where it can be used |
| Role | Generation / embedding / reranking / guardrails | Its job within a system |
Cloud API models
Anthropic (Claude), OpenAI (GPT), Google (Gemini) and others offer models through APIs. You get top-level performance without owning GPUs. In exchange, your input is sent to the provider's servers.
Many providers line up tiers that differ in capability, speed and cost. Claude, for example, has these four as of October 2026 (per the official documentation).
| Model | Positioning |
|---|---|
| Claude Fable 5.1 | For demanding reasoning and long-horizon agentic work |
| Claude Opus 5.5 | The starting point for most uses. Long-running coding and knowledge work |
| Claude Sonnet 5.5 | A balance of speed and intelligence |
| Claude Haiku 5.5 | High-volume, speed-sensitive work such as classification, extraction and routing |
All of them have a 1M-token context, take text and images as input, and adjust how much they think. Other providers line up tiers in a similar way. When unsure, start in the middle tier, move up if it falls short, and down when the volume is large.
Open models
These are models whose weights are distributed so you can run them on your own PC or servers. You can use them without sending data out, and they are what local LLMs and serving many users run.
- Families: Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS (OpenAI's open models) and more. Major inference engines such as vLLM support them
- Examples (checked on distribution pages):
gpt-oss-20b(runs within 16 GB of memory, Apache 2.0),gpt-oss-120b(one 80 GB GPU, Apache 2.0),Qwen3.8-27B(Apache 2.0), and the Japanese-strengthened Swallow series - Licenses: from permissive ones like Apache 2.0 and MIT to ones with their own terms. Check per model whether commercial use is allowed
- What "open" means: even if the weights are public, the training data and method may not be. Some call these "open-weight" to tell them apart
What drives performance
- Parameter count: bigger tends to be more capable, but slower and needs more memory. Check the memory with the memory estimator
- MoE (mixture of experts): holds many experts and uses only some for each token. Size memory by total parameters, compute by the part used
- Context length: how much it reads at once. Longer lets you pass long documents, but costs and waits grow too
- Think-then-answer models: thinking before answering makes them stronger on hard problems, at the cost of time and tokens
- Quantization: shrinks open models by using fewer bits. Trade a little quality to run on a smaller GPU
How to choose
- Can data leave? If not, run an open model in your own environment. If so, cloud APIs are easy and strong
- The quality you need: the top tier for hard reasoning and long work, the middle for everyday work, the lower tier for bulk classification and extraction
- Volume and cost: if you run a lot, first try whether a smaller model or lower tier is enough
- Japanese: model cards often do not say. Check with Japanese questions
- Finally, compare on your own questions: narrow to two or three candidates and measure quality, speed and cost on the same set of questions
Using different models for different roles in one system is normal: a larger model for chat, an embedding model for search, and a small, fast model for routing and classification.
Checklist
- Did you first decide whether data can leave?
- Did you check the candidates' licenses and terms of use?
- For an open model, does it fit your GPU?
- Did you compare two or three candidates on questions from your own use (including Japanese)?
- Did you record model names and versions so you can compare on the same questions when swapping?