01A language model is a next-token predictor
Strip away every wrapper and an LLM is this: text goes in, the model outputs a probability distribution over the next token, one token gets sampled, appended to the input, and the whole thing repeats until the model emits a stop token. That’s the loop. Karpathy’s one-line version: “the entire function of an LLM is to predict the next token.” Mechanically, it’s the autocomplete on your phone — trained on vastly more text, with vastly more capacity, and given more context.
Two pieces of machinery make the loop possible:
The tokenizer — the model’s alphabet. It doesn’t read letters or words; it reads tokens, subword chunks produced by byte-pair encoding, which splits text into the most frequent chunks it can find. “The cat sat” becomes something like ["The", " cat", " sat"]; an unfamiliar word like “tokenization” might split into ["token", "ization"]. Roughly 1.3–1.5 tokens per English word. The tokenizer is fixed before training and stays frozen forever — the one part of the pipeline that’s exactly reversible.
The transformer — the neural network that takes the tokens and predicts. We meet it properly next section; for now: it’s the part with the parameters, and it’s what makes the prediction good.
One property of the loop explains everything downstream: the model has no memory of its own outputs. It doesn’t “remember” generating a token a second ago — the token is in the window, and the window is the only state there is. The output becomes the input; the snake eats its own tail. That’s why context windows (101-02) matter so much: for the model, the conversation is the context.
Token — the unit an LLM reads and writes, roughly a word fragment. When you hear “128K context” or “tokens per second” or “token pricing,” this is the unit. The model never sees letters, and never sees meaning — only token IDs mapped to numbers.
Every “intelligent” thing you watch these tools do — reading files, writing code, calling tools, delegating to subagents — is this loop plus scaffolding. Function calling is a particularly clean example: the model doesn’t “call” anything; it emits a sequence of tokens that happens to match a tool’s schema (name, arguments as JSON), and the framework parses those tokens and executes the tool for real. The agent is the loop plus the scaffolding — the model itself is just the predictor.
02The transformer: what makes it a model
Why not a simpler predictor? A model that just counts word pairs (“the” → “cat” 12% of the time) fails immediately, 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. You need the network to weigh everything at once.
That’s what attention does. The transformer (Vaswani et al., 2017, “Attention Is All You Need”) is built from layers in which every token computes a weighted blend of every other token — the weights are learned, so each token learns which other tokens matter for predicting it. Stack dozens of layers and representations become progressively more abstract: early layers track words and syntax, later layers track entities, roles, and structure. The architecture is also parallel — all tokens processed at once — which is why GPUs are the right tool and why the whole thing scales.
The committee analogy: imagine a meeting where, before anyone speaks, every member reads everyone else’s notes and weighs each note by relevance to their own. Round 1: who’s talking about what. Round 2: now with the gist of what everyone said. Round 3: now with the underlying arguments. After enough rounds, each speaker’s contribution is a distillation of the entire room — which is exactly what a token’s final representation is: a compressed summary of the whole context, weighted toward what matters for predicting what comes next.
That property — every token attends to every token — is why context quality dominates model quality, why “lost in the middle” degradation (101-02) is architectural fact, not bug, and why the model has no state outside the window: attention is recomputed fresh on every call.
03Training vs inference: compression and decompression
The same model has two completely different lives, and almost everything people get confused about in LLMs is a conflation of the two.
Training is the expensive, offline phase: feed the network trillions of tokens, have it predict, measure how wrong it was, and nudge its parameters to be less wrong — repeated billions of times across weeks on GPU clusters. The model changes during training; at the end you have a frozen file of weights.
Inference is the cheap, online phase: the frozen model runs forward once per request — predict, append, repeat — in milliseconds. The model does not change. It cannot learn from your conversation, no matter how it feels. 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: you hand it a prompt, and it reconstructs the most plausible continuation from the compressed store. It’s lossy — it keeps the gist and discards the exact bytes. That single fact explains two otherwise-magical things: why the model produces novel, never-seen combinations (it stored the rules, not the strings), and why it hallucinates (a lossy decompression invents plausible details — compression artifacts). More in 101-06.
The book analogy: training is an author reading every book ever written and internalizing how language and the world work; inference is that same person continuing your sentence mid-conversation. Only one of those activities ever changes them.
Your local GPU box is an inference machine, full stop. The .gguf files in the model library are the trained weights — the training happened at a lab somewhere; Mizuki only ever decompresses. A ~7B model quantized to q8_0 is roughly 1 byte per parameter, ~7 GB — that’s why it runs comfortably on a 16 GB RTX 4080, and why frontier models with hundreds of billions of parameters physically cannot. When people say “local vs cloud,” the model is the same species; only the decompression location and speed differ.
04The three stages of training
The public story (“they scrape the internet and ask it questions”) collapses three very different phases into one. Real model training is a pipeline:
- Stage 1 — Pretraining Next-token prediction at planetary scale: trillions of tokens from the web, books, and code, for weeks. This is the compression stage — it produces a base model: fluent, deeply knowledgeable, but not an assistant. Feed a base model a question and it will happily complete it as text (“What is the capital of France? The capital of France is…” — and then maybe keep writing an essay about France). 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 is what turns a text-completer into something that answers questions, follows instructions, and refuses (some) harmful requests. Notably, a small amount of high-quality data does most of the work — LIMA (Zhou et al., 2023) showed ~1,000 carefully curated examples sufficed for strong alignment behavior. Alignment is a tutoring problem, not a data-scale problem.
- Stage 3 — RLHF / RLVR Reinforcement learning: the model optimizes against a reward signal rather than imitating examples. RLHF (human feedback): humans rank candidate 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 — the reward is “right answer / passing tests,” no human needed. RLVR is the quiet revolution of 2024–2025: it’s what produced DeepSeek-R1’s long “thinking” traces and the reasoning-model genre.
The apprenticeship analogy: pretraining is growing up reading everything ever written; SFT is being tutored on how to answer questions well; RLHF/RLVR is practice with a coach who says “good” or “bad” — and only the last stage decides whether you’re polite, reliable, and willing to show your work.
RLHF vs RLVR — both are “reinforcement learning” (optimize a reward, not next-token accuracy). RLHF’s reward comes from humans judging outputs; RLVR’s comes 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 an SFT artifact; its fluency and world knowledge are pretraining. And this is why model choice matters in an agent stack: two models with similar benchmark scores can differ wildly in how they behave as agents, because stage 3 — not size — determines instruction-following and reward-chasing behavior.
05Parameters: what they are, why size matters
A parameter is a number — a weight in the network — and the model’s entire knowledge and skill is distributed across billions of them. Think of each parameter as a tiny dial: training turns the dials in concert until the network, as a whole, produces good next tokens. No single dial “knows” anything; knowledge is the pattern across all of them — which is exactly why the model is fuzzy (lossy) rather than precise, and why it can’t “look anything up” (that’s what tools and retrieval are for, 101-05).
Storage math is the part that touches your stack daily: parameters are stored at roughly 2 bytes each in half precision (FP16), so a 7B model is ~14 GB, 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 always parameter count, and it’s the single biggest driver of what a model can hold and do.
Why size matters is empirically precise, not vibes: scaling laws (Kaplan et al., 2020) showed model loss falls as a smooth power law of parameter count, data, and compute — predictable 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. When a model “forgets” or underperforms locally, the first suspect is not the model class — it’s a small quantized model 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, because it inverts cause and effect.
The point it misses: to predict the next token well — to assign high probability to exactly the right continuation — the network must have learned 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 cooking recipe without knowing what kitchens are; you cannot predict the next line of code without knowing what the function is for. Karpathy again: to predict text well, the model learns a great deal about the world, because the world generates the text. He goes further: compression and intelligence are deeply related — the better the compression, the more the model must understand.
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 the move right is the entire skill. One next-token step is dumb; the aggregate — a trillion training examples shaping the distribution, then thousands of steps composing a reply — is where the ability lives.
The same logic shows why 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, which is the seed of hallucination (101-06). But the “parrot” framing fails on the evidence: the model generalizes to combinations never seen in training, writes code that runs, and reasons through problems it was never shown. Mimicry that generalizes that far is more than memorizing.
There is no separate “creative module” or “logic module” anywhere in the stack. The design taste that produces a lecture page and the code that deploys it come from the same single mechanism — one loop, trained to imitate the full distribution of human text, which includes design systems and Python. The difference between “creative” and “analytical” outputs is context and scaffolding (prompts, references, tool use), not model 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 didn’t have at smaller sizes — few-shot reasoning, arithmetic chains, instruction following — like a phase transition. Wei et al. (2022) named this “emergent abilities”: capabilities that appear absent in small models and “emerge” abruptly past a threshold. It fed a lot of “the singularity is a staircase” rhetoric.
It’s contested, and the strongest critique is devastating. Schaeffer et al. (2023), “Are Emergent Abilities of Large Language Models a Mirage?”, showed that most documented emergence is a measurement artifact. When the metric is coarse (e.g., exact-match accuracy: 0% until the model gets a whole answer right, then suddenly 60%), smooth underlying improvement looks like a sudden jump — the metric hits a threshold, not the model. Switch to a fine-grained metric (token-level probability) and the curve is smooth from the start. Capability scales continuously; our perception of sudden 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 genuinely experienced as emergence by everyone using these models, even if the physics underneath is continuous.
The boiling-water analogy: heat input is continuous; the boil looks sudden — and the phase transition is real, but it’s a threshold of a continuous process, not a new kind of water. Emergence is like that: a real threshold in capability space, born of a smooth curve in training space.
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 exactly what you already use them for. And the models in your daily stack — DeepSeek V4 Flash via your own API, Claude Code headless, local Qwen on Mizuki — all sit far past most of these thresholds. The capabilities that actually differentiate your stack (tool use, long-horizon tasks, memory) are mostly post-training and scaffolding wins. That’s not a put-down of the models; it’s the thesis of this course — the model is the engine, the agent is the chassis.
Your subagents — Mara, Kyra, Sachi — are the same underlying capability with different system prompts, memories, and tool permissions. They demonstrably behave like different specialists. That is emergence in its most honest form: not a magic new power, but 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 ever 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 — and 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 (“an LLM is a lossy compression of the internet”), the next-token loop, and the LLM-as-OS analogy. The canonical 60-minute mental model.
-
[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.”