[Training a 500B LLM from Scratch] 21/25: After Reading So Many Books, How Does It Learn to Answer?

After the main training run, I loaded the model that had read 10T tokens and gave it a short passage: the sun makes water evaporate, water vapor cools and condenses, and small droplets gather until they fall to the ground. Then I added a request: “Explain how rain forms in three sentences, for an elementary school student.”

The answer was long. It covered evaporation, condensation, and precipitation, added a section on the water cycle, and ended with several questions to think about. The knowledge seemed to be there. My request for three sentences had disappeared inside it.

That answer put the excitement of finishing training on hold. The model had read so much, yet it still had something new to learn: understand what the person in front of it wants, then use its knowledge to do that job.

It Can Explain Rain, but Has Missed “Three Sentences”

I broke the request apart and tried again. Asked to explain condensation, the model could describe water vapor cooling into small droplets. Asked to shorten the answer, it produced another long passage. After several checks, the problem became more specific: at least on this task, it needed to learn how to organize an answer around a request.

During pretraining, the model had practiced predicting what comes next from what came before. Books contain knowledge, exercises, contents pages, and many ways of writing. Now a user request appears at the end of the input, and we want an appropriate assistant answer to follow reliably. The training material needs to demonstrate that use explicitly.

I opened a separate record for knowledge errors and behavior errors. If a concept from a particular field was missing, we could add relevant material and continue training. If the concept was understood but the answer ignored sentence count, audience, or format, good conversations could teach the model how to complete the task. The rain question would take that second route first.

The base weights were saved separately. They held the result of the 10T-token main run; new material, compute, and cost would go in a separate ledger. This next stage is called supervised fine-tuning, or SFT. Putting the name aside for a moment, the immediate job was to write the answer I wanted to receive.

Supervised fine-tuning (SFT): Teaching a model to complete tasks using demonstrations made of inputs and ideal answers.

Mid-training: Further training between base pretraining and final assistant training, focused on abilities such as domain knowledge or long-text handling. Projects draw the boundaries of this stage differently.

Put the Answer We Want into the Textbook

I turned the same passage into a conversation:

User:
Use the passage below to explain how rain forms in three sentences,
for an elementary school student.
Passage: The sun makes water on the surface evaporate. The water vapor
rises, cools, and condenses into small droplets. The droplets gather
and fall to the ground when they become heavy enough.

Assistant:
The sun warms water on the ground into water vapor, which rises into the air.
In colder air, the vapor turns into tiny drops that join together.
When the drops become too heavy to stay in the air, they fall as rain.

Those three sentences had three jobs: follow the passage, make sense to an elementary school student, and respect the sentence limit. The review form checked each one. Counting three periods was easy. Checking the meaning required another careful read.

Then a smaller, more practical question appeared. The file said “User” and “Assistant.” How would the model know those names identified roles rather than belonging to the text itself?

The data record stores roles and content separately, for example using messages for the conversation and user and assistant to identify the speaker. Before the record reaches the model, a chat template turns those fields into a token sequence, adding role boundaries and end markers. Training and serving share the same rules so that questions and answers meet in the right places.

The synthetic material created and filtered in Part 10 enters training through the same route. By this stage, though, the files contain specific records that passed review. The number produced by the teacher and the records ultimately accepted can both be traced through versions.

One rain question can test the pipeline. To teach an assistant a broader range of requests, the textbook also needs examples of “Please explain in detail,” “First ask me what information is missing,” and “The passage does not give that date.” Otherwise, three sentences may become a new habit it applies everywhere.

Chat template: Rules that convert structured roles such as user and assistant into a model input sequence, including role markers and end markers.

The Correct Answer Is Already Here. What Is Left to Learn?

Inspecting the first training record, I printed the input beside the prediction targets. The user request came first, followed by the three sentences we had written. With the correct answer supplied, the training program's next job was to check whether the model could predict it at each position.

For example, after “The sun warms water on the,” the target for the next token comes from the reviewed answer. The model assigns probabilities to the next token, the program compares them with the target, and the same check continues through the remaining positions.

The first answer position can use the full question. The second can also see the first position of the correct answer. Every later position can see only what precedes it. Because those preceding tokens are already in the sample, training can calculate predictions for many positions at once. It does not have to wait for the model to freely generate a whole passage and then score it.

The printout also contained a row of zeros and ones. They determined which prediction errors entered the training loss: zeros for the user's request and passage, ones for the assistant answer and its end marker. The model reads the whole sequence; scoring concentrates on the part we want it to learn to write.

The diagram uses short English phrases from the rain example. The upper card contains the user request and passage. Green blocks represent answer prediction targets and the end marker. Zeros below the context and ones below the green blocks indicate whether each part is scored. Each block stands for a stretch of content; actual tokenization is finer.

That row is called a loss mask. Positions marked zero still influence the answer: how the model understands the question affects the errors at answer positions. Those errors propagate backward through the network, allowing attention, feed-forward layers, and other trainable parameters to change.

I checked roles, prediction targets, and masks one by one, then added a multi-turn conversation. The data could proceed only when every answer meant to be learned was selected and the ending was correct. A misplaced boundary could teach the wrong part of an entire batch.

Loss mask: An array marking which token positions contribute to the training score. Here, it keeps assistant answers and skips user prompts and padding.

Connect It to the Training Program We Already Have

The rain sample now had an input, correct answer, and scored positions. Next, it had to enter the Megatron training process built earlier.

The data center, Slurm, and multi-GPU communication stayed in place. The main changes concerned how material was read, how it became a batch, and how loss was aggregated. I put the required adjustments in one table and checked them against the sample:

The GPT training entry point in the selected Megatron version already multiplies per-position loss by loss_mask and counts selected positions. The conversation data must connect to that path correctly: masks need to be split and batched together with their corresponding prediction targets.

As of November 2026, Hugging Face's SFT documentation also offers assistant_only_loss and requires a chat template that can identify assistant spans. It packages the same idea in its own interface. My 500B job stays with Megatron, implementing the rule along the existing data and loss paths.

Once a small batch worked, I inspected memory and communication records. Input lengths and scored positions had changed, so the old configuration needed to pass acceptance again. Only then had a conversation truly joined the system that could update 500B parameters.

One Sample Works. How Many Do We Need?

The next question brought me back from the program to the textbook. Learning the rain question alone was a long way from becoming a general assistant. I divided the first batch of tasks into five groups: following instructions, answering from supplied material, multi-turn clarification, math and code, and handling boundaries or missing information.

Each group then expanded across languages, lengths, and difficulty levels. That list made gaps concrete. Were there too few long Chinese passages, too few conversations that required clarification, or math answers whose reasoning had not received enough review?

The first round would contain 10,000 examples to check error types and production cost, followed by an expansion to 100,000. The full allocation was 30,000, 30,000, 10,000, 20,000, and 10,000 across the five groups. The first two cover common general-assistant interactions; the other three add different ways of handling a task. Later additions would follow review pass rates, coverage gaps, and gains on independent tasks.

For budgeting, I assumed 2,000 tokens per input-and-answer pair, of which 600 belonged to the answer. One pass through 100,000 examples would mean about 200 million input tokens and 60 million positions contributing to answer loss. The prompt context also needs computation, so the compute ledger counts the entire input. The answer portion is tracked separately when examining the learning signal.

The material now had a countable boundary. How long to study it still depended on training results. I would save versions at one-quarter, one-half, and one full pass, scheduling one pass for the first round. Part 7 discussed the value of rereading. The same approach applied here: inspect intermediate versions for gains and regressions, then decide whether a second pass is worthwhile.

Input tokens: Content positions the model reads and computes over, including the prompt and answer.

Answer tokens: Positions in the assistant's output. This article takes training loss mainly from these positions.

Learn the New Requests and Keep the Old Abilities

Before updating, I looked back at the base weights. They held the accumulated learning from 10T tokens. This round would adjust how the model used that ability. I therefore began by comparing several smaller learning rates on the 10,000-example development training set, each run starting from the same base weights.

The first round would still update all model parameters, letting the whole network adapt to the tasks. Short comparisons would check instruction following, factual accuracy, and existing abilities together. A candidate with a suitable adjustment size could then move to 100,000 examples. Learning rate, input tokens, effective answer tokens, and work per update would be recorded together to give comparisons a common basis.

How are the first learning-rate trials and low-rank adaptation arranged?

The three peak learning-rate candidates are 2×10⁻⁶, 5×10⁻⁶, and 1×10⁻⁵, all below the 8×10⁻⁵ peak candidate for main training in Part 16. Each comparison uses the same 10,000-example development training set and effective answer-token count, with checkpoints at matching positions. The candidates span a factor of five, first locating a range that changes behavior while preserving base abilities, then narrowing it.

Full updates retain gradients and optimizer states for all trainable parameters. Low-rank adaptation freezes the original weights and trains a smaller set of added parameters, reducing trainable state and saved data. I keep it as a development tool for quick data comparisons or narrow tasks. The first main candidate for the general assistant uses full updates; independent task performance and cost will determine the final version.

The moment most likely to invite complacency was when the rain answer finally contained only three sentences. That change was not enough. I switched to snow and requested two sentences, then supplied equipment instructions and asked for detailed steps, then asked for a date absent from the passage.

These new questions tested the same ability: choose how to answer from the request in front of you. Meanwhile, the base model's knowledge, math, code, and long-text tasks continued to run. A substantial regression in one category would send me back to the sample mix and update size. If needed, a small amount of general material could be added, with its loss rules and quantity recorded separately.

Catastrophic forgetting: A substantial decline in some previously acquired abilities while a model learns a new task.

Reviewers could not see version names, and answer order rotated. Each answer was checked separately for facts, instructions, audience, and information boundaries. The version we kept had to respond better on new tasks while retaining useful older abilities.

I stored the selected checkpoint with the dataset version, chat template, and comparison report. The original rain question stayed at the beginning of the record, a reminder of where this round started: the model could already discuss a great deal of knowledge. We were teaching it to understand the request before deciding how to speak.

The next test soon exposed another problem. Given the same calculation, the model could fail once and succeed after several retries. It could reach the right answer, but not reliably enough. I laid the attempts side by side to see whether they could become lessons of their own.