01A language model is a next-token predictor
Strip away the wrappers and an LLM is this: text goes in, the model outputs a probability distribution over the next token, one token is sampled, appended to the input, and the loop repeats until a stop token. That’s the loop. Karpathy’s one-liner: “the entire function of an LLM is to predict the next token.” It’s your phone’s autocomplete, trained on vastly more text.
Two pieces of machinery make the loop possible:
The tokenizer — the model’s alphabet. It reads tokens, not letters or words: subword chunks from byte-pair encoding. “The cat sat” becomes ["The", " cat", " sat"]; “tokenization” might split into ["token", "ization"]. Roughly 1.3–1.5 tokens per English word. It is fixed before training and frozen forever.
The transformer — the neural network that takes the tokens and predicts. It holds the parameters; we meet it next section.
The model has no memory of its own outputs. It doesn’t “remember” the token it generated a second ago — that token is in the window, and the window is the only state. That’s why context windows (101-02) matter: for the model, the conversation is the context.
Token — the unit an LLM reads and writes, roughly a word fragment. “128K context,” “tokens per second,” and “token pricing” all use this unit. The model never sees letters or meaning, only token IDs mapped to numbers.
Everything “intelligent” these tools do is this loop plus scaffolding: reading files, calling tools, delegating to subagents. In function calling, the model doesn’t “call” anything; it emits tokens matching a tool’s schema (name, arguments as JSON), and the framework parses and executes them.
02The transformer: what makes it a model
Why not a simpler predictor? A model that counts word pairs (“the” → “cat” 12% of the time) fails, because language is long-range. In “The cat, which had been sleeping on the windowsill for three hours, finally jumped onto the ___,” the relevant word is six clauses back. The network must weigh everything at once.
That’s what attention does. The transformer (Vaswani et al., 2017, “Attention Is All You Need”) is built from layers where every token computes a weighted blend of every other token, with learned weights. Stack dozens of layers and representations grow abstract: early ones track words and syntax, later ones entities and roles. It is parallel (all tokens at once), which is why GPUs fit and why it scales.
The committee analogy: after a few rounds, each member’s contribution distils the whole room — much like a token’s final representation.
Every token attends to every token. That is why context quality dominates model quality, why “lost in the middle” degradation (101-02) is architectural fact rather than bug, and why the model has no state outside the window: attention is recomputed on every call.
03Training vs inference: compression and decompression
The same model has two different lives. Almost all confusion about LLMs conflates them.
Training is the expensive, offline phase: feed the network trillions of tokens, have it predict, measure the error, and nudge the parameters to be less wrong — repeated billions of times over weeks on GPU clusters. The model changes; the result is a frozen file of weights.
Inference is the cheap, online phase: the frozen model runs forward once per request (predict, append, repeat) in milliseconds. It does not change and cannot learn from your conversation. Every API call, every local Ollama session, every agent loop is inference.
Karpathy’s framing is the best mental model in the field: an LLM is a lossy compression of the internet. Training compressed something like 10 TB of text into a ~140 GB file of weights, roughly 100× compression. Inference is decompression on demand: hand it a prompt and it reconstructs the most plausible continuation. It’s lossy: it keeps the gist, drops the exact bytes. So it produces novel, never-seen combinations (it stored the rules, not the strings) — and it hallucinates, because a lossy decompression invents plausible details as compression artifacts. More in 101-06.
Your local GPU box is an inference machine, full stop. The .gguf files in the model library are the trained weights: training happened at a lab, and Mizuki only ever decompresses. A ~7B model quantized to q8_0 is roughly 1 byte per parameter, ~7 GB, which is why it runs on a 16 GB RTX 4080, and why frontier models with hundreds of billions of parameters cannot.
04The three stages of training
The public story (“they scrape the internet and ask it questions”) collapses three very different phases into one. Real training is a pipeline:
- Stage 1 — Pretraining Next-token prediction at planetary scale: trillions of tokens from the web, books, and code, for weeks. It produces a base model: fluent and deeply knowledgeable, but not an assistant. Ask it a question and it completes text (“What is the capital of France? The capital of France is…”). It has no notion of being helpful; it’s a document simulator.
- Stage 2 — SFT (supervised fine-tuning) Show the model tens of thousands of curated instruction–response pairs and have it imitate them. This turns a text-completer into something that answers questions, follows instructions, and refuses (some) harmful requests. A small amount of high-quality data does most of the work: LIMA (Zhou et al., 2023) showed ~1,000 curated examples sufficed for strong alignment behavior.
- Stage 3 — RLHF / RLVR Reinforcement learning: the model optimizes against a reward signal, not imitated examples. RLHF (human feedback): humans rank outputs, a reward model learns the ranking, and the model is tuned to maximize it (InstructGPT, Ouyang et al., 2022). RLVR (verifiable rewards): for math and code, correctness is checkable, so the reward is “right answer / passing tests.” RLVR is the quiet revolution of 2024–2025: it produced DeepSeek-R1’s long “thinking” traces.
The apprenticeship analogy: pretraining is growing up reading everything ever written, SFT is tutoring, and RLHF/RLVR is practice with a coach who says “good” or “bad.”
RLHF vs RLVR — both are “reinforcement learning” (optimize a reward, not next-token accuracy). RLHF’s reward comes from humans judging outputs; RLVR’s from a checker (math solver, unit tests). RLVR scales better because checkers are cheap and objective, which is why reasoning models exist.
When you pay per token, you’re renting the output of all three stages, not the training. The model’s “thinking” traces are an RLVR artifact; its helpfulness is SFT; its fluency and world knowledge are pretraining. This is why model choice matters in an agent stack: two models with similar benchmark scores can differ wildly as agents, because stage 3, not size, determines instruction-following.
05Parameters: what they are, why size matters
A parameter is a number, a weight in the network; the model’s knowledge is spread across billions of them. Think of each as a tiny dial: training turns the dials together until the network produces good next tokens. No single dial “knows” anything; knowledge is the pattern across all of them. That is why the model is fuzzy (lossy), and why it can’t “look anything up” (101-05).
Storage math touches your stack daily. Parameters are stored at roughly 2 bytes each in half precision (FP16), so a 7B model is ~14 GB and a 70B is ~140 GB. Quantization (301-03) shrinks this: q8_0 stores ~1 byte per parameter, which is how Mizuki runs 7B-class models in ~7 GB of VRAM. The “B” in model names (7B, 70B, 671B) is parameter count.
Why size matters is empirically precise: scaling laws (Kaplan et al., 2020) showed model loss falls as a smooth power law of parameter count, data, and compute — enough that labs budget GPU time against them. Chinchilla (Hoffmann et al., 2022) added the other half: parameters and data must scale together (roughly 20 tokens of training data per parameter is compute-optimal).
Bigger is not automatically better — a well-trained, well-aligned 7B routinely beats a sloppy 70B on real agent tasks, because stage 3 and data quality dominate at the margin.
This is why your local fleet tops out at 7B–32B while your API calls reach hundreds of billions: VRAM is the constraint, and ~2 bytes per parameter is the physics. A local model that “forgets” is usually just small and quantized, doing its best with the dials it has.
06“It’s just predicting the next token” — true, and beside the point
The claim is technically exact: at inference, the only operation is sampling a token from a probability distribution, a million times. It is also one of the most misleading true sentences in AI.
The point it misses: to predict the next token well, the network must assign high probability to the right continuation, which requires learning an enormous amount about what produces text: grammar, factual structure, causality, code semantics, how conversations work. The prediction task is the training pressure that forces world models into the weights. You cannot predict the next word of a recipe without knowing what kitchens are. Karpathy: the model learns about the world because the world generates the text; compression and intelligence are deeply related.
The chess analogy: saying an LLM is “just predicting the next token” is like saying a chess engine is “just picking the best move.” The move is trivial; the accumulated evaluation that makes it right is the whole skill.
The “stochastic parrot” critique is half-right. The model is a statistical machine with no external grounding: it can’t check its claims against the world, the seed of hallucination (101-06). But the parrot framing fails on the evidence: it generalises to combinations never seen in training, writes code that runs, and reasons through problems it was never shown.
There is no separate “creative module” or “logic module” in the stack. The design taste that produces a lecture page and the code that deploys it come from the same mechanism: one loop trained on the full distribution of human text, design systems and Python included. The difference between “creative” and “analytical” outputs is context and scaffolding (prompts, references, tool use), not architecture.
07Emergent abilities: real, contested, and what to believe
The story that circulated in 2022–2023: past a certain scale, models suddenly develop abilities they lacked at smaller sizes, like a phase transition: few-shot reasoning, arithmetic chains, instruction following. Wei et al. (2022) named this “emergent abilities”: capabilities absent in small models that “emerge” abruptly past a threshold.
It’s contested, and the strongest critique is devastating. Schaeffer et al. (2023), “Are Emergent Abilities of Large Language Models a Mirage?”, showed most documented emergence is a measurement artifact. With a coarse metric such as exact-match accuracy, a model scores 0% until it gets a whole answer right, then suddenly 60%: the metric hit a threshold, not the model. Use a fine-grained metric (token-level probability) and the curve is smooth from the start. Capability scales continuously; our perception of jumps comes from measuring with a hammer.
What’s still real: smooth curves still cross thresholds that matter. At some parameter count a model becomes useful: able to follow multi-step instructions well enough to hold a system prompt, use tools, and complete real work. That crossing is experienced as emergence, even if the physics underneath is continuous.
The boiling-water analogy: heat input is continuous; the boil looks sudden. The phase transition is real, but it’s a threshold of a continuous process, not a new kind of water.
Practical takeaway: don’t bet on “scale alone produces new powers.” Do bet that bigger, better-trained, better-aligned models keep getting more reliable at what you already use them for. The models in your daily stack all sit far past most of these thresholds: DeepSeek V4 Flash via your own API, Claude Code headless, local Qwen on Mizuki. The capabilities that differentiate your stack (tool use, long-horizon tasks, memory) are mostly post-training and scaffolding wins.
Your subagents (Mara, Kyra, Sachi) share one underlying capability with different system prompts, memories, and tool permissions, yet behave like different specialists: emergence in its most honest form, the same smooth curve pointed at different problems by scaffolding.
08Key takeaway
An LLM is a frozen, lossy compression of human text in the form of a next-token predictor: pretraining shaped it, SFT and RLHF/RLVR made it an assistant, and inference runs it without changing it. Size buys capacity, alignment buys behavior, and “emergent” abilities are mostly smooth capability curves crossing useful thresholds. Everything you call “agent intelligence” is scaffolding around one autoregressive loop. Once you see the loop, the rest of this course is detail.
09Go deeper
Top references (free)-
[1]
Karpathy — “Intro to Large Language Models” (YouTube, 1 hr)
https://www.youtube.com/watch?v=zjkBMFhNj_gThe lossy-compression framing, the next-token loop, and the LLM-as-OS analogy.
-
[2]
Vaswani et al. — “Attention Is All You Need” (arXiv:1706.03762, 2017)
https://arxiv.org/abs/1706.03762The transformer paper: attention, parallel training, and why the architecture took over.
-
[3]
Ouyang et al. — “Training language models to follow instructions with human feedback” (arXiv:2203.02155, InstructGPT, 2022)
https://arxiv.org/abs/2203.02155The RLHF recipe that every assistant model descends from.
-
[4]
DeepSeek-AI — “DeepSeek-R1” (arXiv:2501.12948, 2025)
https://arxiv.org/abs/2501.12948RLVR at scale: verifiable rewards producing long reasoning traces. The model genre your own API runs on.
-
[5]
Wei et al. — “Emergent Abilities of Large Language Models” (arXiv:2206.07686, 2022)
https://arxiv.org/abs/2206.07686The original emergence claims.
-
[6]
Schaeffer et al. — “Are Emergent Abilities of Large Language Models a Mirage?” (arXiv:2304.15004, 2023)
https://arxiv.org/abs/2304.15004The rebuttal: metric artifacts, smooth underlying curves. Read 5 and 6 together.
-
—
Hugging Face — “What are Large Language Models?” (llm course / blog)
https://huggingface.co/blog/large-language-modelsTokenizers, parameters, and the training pipeline in one readable pass.
-
—
Ollama — model files & GGUF (docs)
https://docs.ollama.com/modelsHow local weights are stored and quantized; the practical side of “2 bytes per parameter.”