From input text to intelligent output

LLM ArchitectureExplained

Type a sentence below and watch it travel the whole pipeline — interactively.
New to this? Take the full From Zero to Transformer course.
Data / Vector
→ Flow of information
Embedding

A note from the author

Shahzad Asghar, CISSP, CISM · Written in a personal capacity

I wrote these pages while explaining large language models to colleagues who had to decide whether to deploy one. Architecture matters to a decision-maker for one reason: it tells you what the system cannot do, however well the demo went.

I have spent more than twenty years building data and AI systems in international development and humanitarian organisations, including over a decade in United Nations agencies: leading a data analysis group whose systems served more than 700,000 refugees, then heading data and digital solutions for a regional commission, with earlier work at UNICEF, UNOCHA and CIDA. I hold the CISSP and CISM security certifications. What I publish here is what I wish someone had handed me before my first AI project. If you work through it and want to compare notes on your own situation, I am happy to connect and discuss.

Connect on LinkedIn · Continue in the AI Learning Hub

Input text — edit me
Try another language — tokenization handles any script — tokens
↓   split into tokens
Tokens
↓   map each token to an ID
Token IDs — the numbers the model actually reads
1

Tokenization

Text is split into tokens (words or sub-words), each given a numeric ID.

Handles any languageBreaks text into reusable piecesRare words split into sub-words
Token IDs
↓
Embedding Layer  ·  look up a dense vector for every ID
↓
Embeddings (dmodel dimensions — shown as 4 for clarity)
2

Embeddings & Attention Scores

Vectors are compared with each other to decide what each token should pay attention to.

Captures meaning & relationshipsQueries · Keys · ValuesSoftmax turns scores into weights

Each token produces a Query (what it's looking for), a Key (what it offers) and a Value (what it passes on). Click a token to see what it attends to.

Highlight matrix:
Scores · QKᵀ / √dₖ
rows = queries · columns = keys
→
Selected query attends to
click a token below
→
Context
weighted sum
of values
3

The Transformer Block

Attention and a feed-forward network, repeated many times, refine every token's meaning.

Looks at all tokens at onceResidual Add & Norm keeps it stableStacked × L layers deep
× 12 layers
Input
→
Multi-Head
Attention
→
+
→
Feed Forward
Network
→
+
→
Output
Tip: click any block above to learn what it does. Drag the slider to change how many times the block repeats.
12 ×
4

Context Window

The model can only "see" a fixed number of recent tokens at once.

Larger window = more contextLimited by model capacityWindow: 16K tokens
16K
Visible to the model Current position Next tokens — to be generated
5

Output Tokens

The decoder predicts the next token, samples one, appends it, and repeats.

Autoregressive — one token at a timeSampled from probabilitiesRuns until an EOS token
Generated so far
0.70
Low = focused & predictable · High = diverse & surprising
↻ append & repeat — each token feeds back in as new context
LLM decoder · next-token probabilities
6

End-to-End Flow

The whole journey, start to finish. Press play to trace it — or click any stage to jump there.

⌨
Input Text
your prompt
✂
Tokenization
text → IDs
⬡
Embeddings
IDs → vectors
▤
Transformer
× L blocks
▭
Context Window
what it sees
◎
Output Tokens
one at a time
💡

Key takeaway

LLMs convert text into numbers, understand relationships through attention, process information through many layers, and generate coherent text — one token at a time.

Attention variants, and why models change it

Everything above describes one attention mechanism: every token compares itself with every earlier token, scoring them with softmax(QK⁠T / √dk)V. That is the version in the original Transformer paper, and almost no model serves it unchanged.

The reason is the cache rather than the mathematics. During generation the keys and values for every earlier token are kept so they are not recomputed each step. That cache grows with the number of heads, the number of layers and the length of the conversation, and on long contexts it becomes larger than the model weights. Each variant below trades some property of attention for a smaller cache or a cheaper comparison.

How the main attention variants differ. Cache cost is per token, relative to multi-head attention.
Variant What it changes Cache cost What you give up
Multi-head attention (MHA) Nothing. Every head keeps its own keys and values. Baseline, the highest Nothing in quality. It is the memory cost that makes it impractical at long context.
Grouped-query attention (GQA) Several query heads share one set of keys and values. Divided by the group size A small amount of head independence. The usual default in open-weight models, because the quality cost is slight.
Sliding window attention Each token attends only to a fixed window of recent tokens. Capped by the window, not the conversation Direct links to distant tokens. Information from far back has to travel indirectly, layer by layer.
Multi-head latent attention (MLA) Keys and values are compressed into a smaller latent vector, and that is cached instead. A fraction of the baseline Simplicity. The compression and expansion are extra work, and the latent size becomes another thing to tune.
Sparse attention An index selects a subset of earlier tokens for each query rather than comparing against all of them. Grows with the subset, not the context Certainty about what was read. Quality now depends on the selector, and anything it misses is invisible to the model.
Hybrid attention and state space Most layers become recurrent state-space layers, with attention kept in a few. Constant per token in the recurrent layers Exact recall of a specific distant token, which a fixed-size state holds less reliably. The retained attention layers exist to cover that.

Read the column that matters for the decision in front of you. If the constraint is the cost of serving long conversations, the cache column is the one to look at. If the constraint is whether the model can reliably quote something said much earlier, read the last column instead, because that is where every one of these designs pays for the saving.