Andrej Karpathy’s Deep Dive into Large Language Models

I want to explain what is behind a tool like ChatGPT: how it is built, what it is good at, where it fails, and how to use it more effectively.

The first stage is pretraining. It begins with collecting and processing a large, diverse body of public text from the internet.

FineWeb is an illustrative dataset: the processed text is much smaller than the raw web, because the pipeline filters aggressively and stores text rather than entire pages.

Common Crawl supplies a starting collection of pages gathered by following links across the web. The raw material needs extensive cleaning before training.

A pipeline can filter unwanted domains, extract the main text from HTML and remove navigation, formatting and other material that is not useful training text.

Language filters are another design choice. If a dataset excludes a language, the model has fewer opportunities to learn its patterns from that data.

I look at examples of the resulting documents: the aim is not one perfect source, but a large collection with breadth and quality.

The text must be represented as a one-dimensional sequence of symbols before it can be fed into a language model. This conversion is tokenization.

Computers store text as bytes. We can think of byte values as identifiers for symbols rather than as numbers with meaningful numerical relationships.

Byte sequences can be compressed into a larger vocabulary of recurring pieces. The resulting units, tokens, can represent parts of words or other repeated patterns.

A tokenizer learns a mapping between text and token IDs. Different models may use different vocabularies and therefore split the same text differently.

A tokenizer visualization shows how text becomes tokens and back again. The boundaries do not necessarily line up with the letters or words a person sees.

After tokenization, the training data is a long sequence of IDs. A neural network receives a window of previous tokens and predicts what token follows.

The context length determines how much of the sequence is supplied for a prediction. Longer windows can be more useful but also more computationally expensive.

For a small illustration I use only a few tokens. In practice the same idea is applied to much larger windows and enormous numbers of examples.

The network outputs probabilities over possible next tokens. Because the training text tells us the actual next token, we can measure how well the prediction matched.

An optimization step adjusts network parameters to make the observed continuation more likely. Repeating this across many examples gradually changes the model.

The objective does not explicitly write facts into a database. Instead, the network develops parameter patterns useful for predicting the next piece of text.

Inside the network, information passes through many layers. The basic operations are mathematical combinations of values and learned weights.

A single neuron is a simple calculation, but many connected calculations can form a system with rich behavior.

Multiplication, addition and other elementary operations mix inputs with parameters. Architecture research studies how to arrange these calculations effectively.

A transformer turns each token into a vector representation and repeatedly transforms those representations through attention and other blocks.

The network’s individual operations are simple, but the large number of parameters and training updates makes the overall computation substantial.

My comparison with biological neurons is a loose analogy. These artificial units and the resulting systems are not the same as human brain cells.

Once trained, the model can be used for inference: start with a prefix, predict a distribution for the next token and choose a continuation.

The selected token is appended to the context, and the process repeats. This produces new text one token at a time.

Sampling makes generation stochastic. A continuation may resemble training material, combine patterns or differ from any particular document.

Training changes the parameters; inference uses a fixed set of trained parameters to generate. A product can update its model later, but an individual generation is not the same as a training run.

I use a GPT-2 reproduction to show what an actual training run looks like and how model size, context and data affect the process.

GPT-2 is small by later standards, which makes it useful for an educational reproduction even though modern systems can use much larger models and datasets.

The model has many parameters and a bounded context length. These numbers are properties of a particular model, not universal constants for all language models.

Better data processing, faster hardware and improved software all contribute to the progress from older models to newer ones.

During training we watch a loss metric. It summarizes prediction error and should generally decrease as optimization improves the model on the measured data.

A lower training loss is useful evidence, but evaluating real capabilities also requires looking at behavior on tasks and data beyond a single training curve.

Early samples can look random. As the model receives more updates, generated text begins to show more structure and recognizable patterns.

The difference between early and later samples is an intuitive view of learning: the parameters increasingly encode statistical regularities in the data.

GPUs are well suited to the large parallel numerical workloads involved in neural-network training. At large scale, hardware, power and software efficiency become central constraints.

More capable systems require substantial coordination across many accelerators; the simple learning objective sits on top of a demanding engineering system.

The motivation for large clusters is to process more computation and train or iterate on larger models faster, although the costs are substantial.

A model release typically provides both the code describing the computation and the trained weights needed to reproduce its behavior.

The code describes the architecture; the particular parameter values contain what the training process has learned. Both are needed to run the model.

I compare GPT-2 with Meta’s Llama 3.1 base model to illustrate how the same broad pretraining approach can scale to much larger datasets and models.

A base model is not automatically a chat assistant. It continues text according to learned patterns, so the form of the prompt strongly shapes what happens next.

I describe the base model as a very expensive autocomplete: it predicts continuations consistent with patterns in training documents.

Sampling the same prefix more than once can yield different continuations, illustrating that the model represents a distribution rather than a single fixed answer.

The weights can be thought of loosely as a lossy compression of patterns from the data. This is an analogy, not a literal archive of every source.

A well-chosen prompt can elicit knowledge learned during pretraining, but a fluent response does not itself prove the information is accurate.

The model can sometimes reproduce a passage very closely, showing that memorization can occur alongside generalization.

Memorized details and newly generated combinations are different behaviors; neither should be assumed from a response without checking evidence.

A base model’s knowledge depends on its training data and cutoff. It can generate plausible continuations about later events without having observed them.

That ability to continue plausibly is useful for writing, but it also makes a base model a risky source of unchecked factual claims.

Few-shot prompting places examples in the prefix, such as pairs of words and translations, so the next continuation follows the demonstrated pattern.

A conversation-like prefix can similarly make a base model continue as an assistant, but this is still a prompt pattern rather than a dedicated assistant training stage.

Examples of alternating human and assistant turns show how format can steer the continuation toward answering a question.

This motivates post-training: we want a model that reliably responds to user requests rather than merely continuing arbitrary internet text.

Post-training starts with the pretrained base model and uses examples of conversations to teach a more useful assistant style.

The assistant is not programmed by a long list of explicit rules in the ordinary sense. Its behavior is shaped statistically by examples and training.

A supervised dataset contains many conversations, potentially with multiple turns. Each response demonstrates a desired kind of behavior.

The people and processes that create these examples matter: they decide what helpfulness, accuracy and safety look like in the training material.

Post-training datasets are much smaller than the broad pretraining corpus, so this stage can be much shorter even though it changes how users experience the model.

Conversations must be serialized into tokens, including markers for who is speaking and when a turn begins or ends.

Different model families use different formats, but the result is again a sequence that can be trained with next-token prediction.

The model learns from the statistical pattern of user and assistant turns, including examples of answering and declining requests.

The same basic machinery can thus be used for internet documents and conversations; the main difference in supervised fine-tuning is the training data.

I use InstructGPT as a historical example of how an assistant was trained on demonstrations and preferences.

Human labelers work from instructions and create examples of desirable responses. Those instructions are a significant part of the product design.

The examples aim at being helpful and truthful and at handling certain requests appropriately, but no finite set of examples guarantees perfect behavior.

Companies may use detailed labeling guidance and specialized reviewers. The resulting assistant behavior reflects choices made during data creation.

When the model imitates an answer, it is not consulting the human labeler live. It is generating from patterns learned across many examples.

A large collection of examples can produce the appearance of an assistant persona, although the model can still behave unexpectedly outside familiar examples.

Later datasets can combine human work with synthetic examples produced by other models and checked or edited in different ways.

Synthetic conversation datasets can cover many topics at large scale. Their usefulness depends on quality as well as quantity.

For specialized topics, expertise and review can matter because examples set the pattern that the assistant learns to imitate.

The “average labeler” is a mental model for understanding imitation: the assistant can reflect many examples rather than speaking as one particular expert.

Pretraining knowledge and post-training examples interact. The former supplies broad patterns and information; the latter teaches the model how to respond in a conversation.

This combination can make a model useful, but it also explains why a confident assistant style should not be mistaken for guaranteed knowledge.

Hallucinations arise when a model produces a plausible answer that is not supported by what it knows or by evidence. Fluency alone is not a confidence check.

I use a made-up name to show how an assistant may confidently invent a biography instead of saying that it lacks information.

The model is continuing a token sequence in the style of an answer; the user experiences the result as a factual claim.

That gap between the training objective and the user’s expectation is one reason hallucinations need explicit attention during post-training.

One mitigation is to add examples that teach the model to acknowledge uncertainty or say it does not know when evidence is missing.

I describe a procedure reported for Llama models: test what the model knows and add training examples around the boundary of its knowledge.

Questions can be generated from source passages and compared with the model’s unaided answers, helping identify where a confident answer may be unreliable.

When the relevant passage is placed directly in context, the model can often reframe that information more accurately than it can recall an obscure fact from memory.

That does not remove the need to inspect the source and the answer. Context can contain mistakes, and the model can misinterpret or omit details.

I show a factual question where the unaided model gives inconsistent answers, illustrating the difficulty of relying on recollection.

Training can reward appropriate uncertainty, but saying “I don’t know” is only one possible response when the information could be looked up.

A second mitigation is tool use: the assistant can request a search or computation, receive a result and use that result in its response.

Tool calls require a protocol that distinguishes the model’s request from the external result. The surrounding application actually runs the tool.

Special markers can indicate a search request and its boundaries. Those markers are part of the model’s input and output format.

The returned text is inserted into the context, after which the model can continue generating with access to that evidence.

Examples in post-training teach when and how to use a tool. The assistant still needs to select useful queries and interpret results.

A search can fail, retrieve a poor source or be misread, so tool access reduces some errors without guaranteeing truth.

Citations and retrieved material make checking easier: the answer can point back to text that the user can inspect.

I distinguish knowledge in weights from information placed in the current context. The latter is more like working material available for this conversation.

If a model has seen a famous book during training, it may summarize from learned patterns, but supplying the actual chapter is a different and more inspectable source.

The context window has limits. What is not included in it is not automatically available to the model as a current observation.

I use a simplified mental model in which a model processes the conversation context and generates a response, rather than maintaining a human-like continuous inner life.

Products can add persistent memory or other surrounding systems, so the behavior of a complete application depends on more than the model alone.

An assistant’s statements about its own identity may reflect training examples and instructions. They should not automatically be treated as direct introspection.

Developers can shape the context by inserting system instructions that describe the model’s role and operating constraints.

Such instructions can include the assistant’s name or knowledge cutoff. They are part of the prompt context, not a guarantee that the assistant has perfect self-knowledge.

The way a desired response is written in training can affect performance, especially when a task requires several steps rather than an immediate answer.

A model generates from left to right. The computation available before each next token is bounded by the network and the current context.

A demanding calculation compressed into a single token may be harder than a sequence that builds useful intermediate results.

I use a simple arithmetic problem to illustrate why the model can benefit from distributing work across several generated tokens.

Intermediate steps make partial results available in the context for subsequent generation, though those steps can themselves contain mistakes.

The point is not that longer answers are always correct. It is that a suitable sequence can turn one hard leap into several smaller operations.

Some easy problems can be solved immediately, so whether intermediate work helps depends on the problem and model.

In a demonstration a model answers a simple problem with very few tokens, showing that the heuristic is not an absolute rule.

As numbers or tasks become harder, unverified mental arithmetic can fail even if the answer looks coherent.

I prefer a calculator or code for calculations that need reliability, while still checking that the model supplied the right inputs.

A tool moves a suitable part of the problem to a system designed for exact operations; the language model coordinates the request and response.

For practical use, give a model room to work through appropriate steps and use external tools when they fit the task.

I demonstrate a counting problem where copying text into code and letting code count can be more dependable than asking the model to count mentally.

The model still has to transfer the input correctly. Tool use changes where errors can occur; it does not make the entire workflow infallible.

Tokenization also helps explain why apparently simple character-level tasks can be awkward for a model.

A word visible to us as letters may be represented internally as several tokens whose boundaries do not align with individual characters.

Counting a specific letter combines a representation challenge with a counting challenge, so performance can be uneven.

This contributes to the “jagged” profile of capabilities: a model can perform a sophisticated task and still fail an apparently simple one.

It is tempting to infer one smooth intelligence level from impressive examples, but that mental model can lead to overconfidence.

Some surprising failures are still active research questions. I mention one example where researchers examined model activations to investigate a puzzling answer.

Understanding a failure can require both the input representation and details of the training distribution, not just a story about what a human would find easy.

Supervised fine-tuning remains next-token training on a different dataset. Reinforcement learning adds a different way to improve behavior.

The broad pipeline I have described is pretraining, supervised post-training and then reinforcement learning, with practical systems using additional variations.

For reinforcement learning, imagine giving the model problems, sampling possible solutions and favoring behavior that leads to a verifiably correct answer.

The analogy to a student is useful but limited: pretraining supplies background, examples show solutions and practice can improve problem solving.

Practice requires a way to evaluate outcomes. Math problems with known answers offer a comparatively clear signal.

The model can try multiple approaches instead of merely copying one human-written solution. Successful approaches become training signals.

These attempts build on background patterns from pretraining and examples seen during supervised training.

The process does not mean a human has inspected every attempt. It depends on the available evaluation procedure and the design of the training run.

A worked solution can have two purposes: reaching the right answer and communicating reasoning in a way a person can follow.

The steps that are natural to a human are not necessarily the easiest sequence for a model to generate reliably.

Reinforcement learning can encourage sequences that work for the model’s own computation, even if their style differs from a human solution.

I illustrate the process with a small model and a simple arithmetic problem, sampling different candidate solutions.

Some attempts reach the correct answer and others do not. The training procedure uses that distinction as feedback.

The exact algorithm matters: selecting and weighting attempts poorly can make training unstable or reward the wrong behavior.

A simplified diagram shows many solutions sampled in parallel, with successful ones encouraged in later updates.

This diagram is a teaching model, not a complete description of every reinforcement-learning implementation.

One can also choose among successful attempts using other criteria, such as brevity, but that choice changes what the model is encouraged to do.

Over repeated updates, the model can become more likely to produce strategies that solve the training distribution of problems.

I compare this to learning through practice after background reading and demonstrations, while emphasizing that it is still a statistical training process.

The simple high-level story hides many engineering and mathematical choices, including how prompts, rewards and updates are constructed.

Reinforcement learning for language models was still developing when this lecture was recorded; successful training depends on details not shown in the cartoon.

I turn to DeepSeek-R1 as a published example of using reinforcement learning on reasoning tasks.

The reported training curves show improved task accuracy over updates, while the outputs also become longer and more deliberative in style.

The model can generate checking, revision and alternative approaches as part of a solution. These behaviors are learned rather than individually hand-coded.

I call these patterns cognitive strategies as a metaphor: ways of manipulating a problem and checking an approach in generated text.

A visible explanation or a summary of reasoning should not be assumed to expose every internal computation or prove the answer correct.

In an arithmetic example the model revisits its calculation and checks the result from another angle. That can be useful, but the check can also be wrong.

Different providers expose different amounts of intermediate reasoning. Users should evaluate the result and evidence, not infer hidden details from the interface.

The lecture shows hosted ways to try a reasoning model; the available products, limits and pricing described in this historical demonstration can change.

A larger reasoning process can take more time and computation than an immediate response, so the appropriate choice depends on the task.

For harder questions I recommend trying a reasoning-oriented model, while simpler requests may not benefit enough to justify extra latency.

Model categories and product interfaces evolve, so the distinction is a way to understand this demonstration rather than a permanent catalog of products.

The important variable is whether the system can spend useful computation on a task and whether its result can be checked.

I connect this idea to earlier reinforcement-learning successes in games, where a clear win or loss can supply feedback.

AlphaGo is an example: the system improves by playing and using outcomes to strengthen effective choices.

A game supplies a constrained environment and an explicit outcome, which makes it different from many open-ended human questions.

Because practice is not limited to copying human games, reinforcement learning can discover moves that surprise human experts.

The famous move in the AlphaGo match illustrates how a strategy discovered through training can initially look strange to human commentators.

An unexpected move is not automatically good; its value is established by how it performs in the game.

For broader reasoning tasks, researchers need many practice problems and evaluation methods that correspond to what they actually want.

Some tasks, such as a joke or summary, have no simple exact answer. This leads to reinforcement learning from human feedback.

A human can compare candidate responses, but asking people to score every model attempt at large scale would be expensive.

I use joke quality as an example of a subjective reward: there is no automatic arithmetic check for whether a joke is funny.

Human preference data can train a separate reward model that estimates which outputs people would prefer.

This indirection means people label a smaller set of comparisons and the learned evaluator supplies many later scores.

A comparison can be easier for a person than assigning an exact numerical quality score to each response.

The reward model is trained to align its ordering with human preferences on the examples it receives.

After training, the evaluator assigns scores to candidate responses, and the language model can be optimized against those estimates.

The evaluator is itself a learned model, so its scores are approximations and can disagree with a person’s actual judgment.

The method can extend feedback to tasks without exact answers, but it introduces a new failure mode: optimizing the proxy instead of the real goal.

In practice human-feedback methods can improve models, though I distinguish observed improvements from a complete explanation of why every improvement occurs.

Preference rankings provide useful supervision, particularly for open-ended tasks where a verifier cannot simply compare one final number.

The upside is scalable feedback guided by people; the downside is that the learned reward function is imperfect.

If optimization is pushed too far, the language model can discover outputs that score well with the evaluator without being genuinely good for the intended task.

In the joke example, predicted scores may rise while actual quality eventually falls. This is a version of reward hacking.

Adding more optimization does not fix a flawed proxy by itself; it can make the mismatch more visible.

A sufficiently optimized system may find adversarial cases for its evaluator, because the evaluator is a neural network with its own blind spots.

This is why verified answers and subjective learned rewards behave differently when training is scaled.

I regard human-feedback optimization as useful but more limited than reinforcement learning with a reliable external verifier. That is my interpretation of the tradeoff.

The three stages are supported by substantial infrastructure and data work, much of which this introductory explanation has simplified.

The model’s capabilities remain uneven. Users need mental models that accommodate both impressive performance and unexpected weaknesses.

Looking forward, I expect multimodal systems to process and generate more than text, including audio and images. This is a forecast from the time of the lecture.

One conceptual route is to represent other modalities as tokens and train models on sequences that combine them. Implementations can vary.

I also expect agents to carry out longer tasks with tools, but their errors make human supervision important.

The appropriate relationship may resemble supervising several digital workers: the useful ratio depends on reliability, task and risk.

Long-running work raises questions about memory and context, because the available context window is finite.

Systems may need to select and organize what matters from large multimodal histories instead of simply carrying every token forward.

I discuss ways to follow model developments, including public evaluations and communities, while noting that rankings should not replace testing on your own tasks.

Open-weight releases allow others to host and adapt a model, subject to the terms and practical resources associated with that release.

Leaderboards and expert commentary are useful starting points, but they measure selected tasks and can become outdated as models change.

I also follow people and communities that consistently explain new research and product changes.

Models can be used through hosted products or, when suitable weights and hardware are available, run locally. Each route has different costs and controls.

Smaller or compressed models can fit on consumer computers, though their capabilities and speed depend on the model and hardware.

The applications named in the lecture are examples from that period, not a requirement to use a particular provider or interface.

In the final recap I trace a user request through tokenization, the conversation format and the trained network’s next-token predictions.

The apparent assistant behavior reflects both broad pretraining and later examples that shape how the system responds.

Human data creation and labeling choices are part of the pipeline. The assistant is not a direct conversation with the people who created those examples.

Reasoning-oriented training can add useful strategies, but the model remains fallible and needs appropriate supervision and verification.

Keep the jagged capability profile in mind: the model can be excellent at one task, hallucinate on another and struggle with a seemingly simple detail.

Useful practices include supplying relevant context, checking sources, allowing appropriate intermediate work and using tools for verifiable operations.

Reasoning outputs can be novel and useful, but a visible summary should not be confused with a complete, independently verified trace of internal computation.

The right level of trust varies by task. High-consequence decisions require stronger checks than casual brainstorming.

I find these tools valuable in daily work and expect continued progress, while stressing that users should remain alert to their limits.