Compare the Three Models

What you will learn

In this lesson you will turn run records, validation measurements, fixed-prompt samples, and operational evidence into defensible conclusions. You will create one table for the controlled 50M comparison and a separate table for the larger-data training path.

Where you are in the build

corpus -> tokenizer -> token files -> model -> training -> checkpoint -> samples
|
v
MODEL COMPARISON
|
v
next experiment

Comparison is not a victory lap for the largest model. It is the engineering process of identifying what changed, what evidence improved, what remained weak, and which next experiment is justified.

Before you begin

Collect the run records, encoding reports, training output, checkpoint paths, and generated samples. Do not regenerate only the prompts that made one model look good.

Freeze the evaluation protocol before running missing samples:

  • the exact prompt strings;
  • maximum new tokens;
  • greedy or sampling mode;
  • temperature;
  • top-k and top-p;
  • repetition penalty;
  • no-repeat n-gram size;
  • random seed;
  • stop-text behavior;
  • device used for generation.

If any setting changes, label the results as a new comparison series.

Files you should already have

Controlled comparison artifacts:

tokenizer/learning_50m_tokenizer.json
checkpoints/iteration_1_learning_50m/<verified checkpoint>
checkpoints/iteration_2_learning_50m/<verified checkpoint>
checkpoints/iteration_3_learning_50m/<verified checkpoint>

Larger-data artifacts:

tokenizer/balanced_tokenizer.json
checkpoints/iteration_2_balanced/<verified checkpoint>
tokenizer/800m_tokenizer.json
checkpoints/iteration_3_800m/<verified checkpoint>

You may complete the controlled comparison without completing the expensive larger-data runs. Mark missing experiments honestly rather than inventing values.

Files this lesson will create

This lesson creates your final comparison report. Use the tables on this page and the run-record worksheet. Include raw samples or links to them so conclusions can be audited.

Key ideas in plain language

A fair comparison starts by naming the question

“Which model is better?” is too broad. Better at what, under which data, token budget, runtime, and decoding settings?

The controlled comparison asks:

With the same 50M corpus, the same tokenizer, the same bounded example counts, the same epoch count, and the same prompt protocol, what changes as the model architecture grows?

The larger-data comparison asks:

What behavior and operational cost did the intended Iteration 2 balanced run and Iteration 3 800M run produce when model, data, tokenizer, and compute scaled together?

Controlled does not mean perfectly identical

The 50M path controls corpus, tokenizer, selected example counts, and epoch count. Iteration 1 uses a 128-token context while Iterations 2 and 3 use 256 tokens, so the exact windows and processed-token totals differ. Report those totals and describe architecture as the main planned variable rather than the only physical difference.

Larger-data results combine several causes

The balanced and 800M runs differ in corpus contents, corpus size, tokenizer, encoded token count, parameter count, and training budget. A stronger result can be real and useful without proving which one of those changes caused it.

Loss is comparable only under the same prediction contract

Cross-entropy loss and perplexity depend on token boundaries and held-out data. The controlled runs share the 50M tokenizer and validation tensor, so their validation losses can be compared with appropriate attention to context and budget.

Do not rank validation loss or perplexity from the 50M, balanced, and 800M tokenizers in one column. A tokenizer that splits text differently changes the number and difficulty of predictions.

Samples need a rubric, not a feeling

Use the same prompts and score observable behavior. Keep every output so a reader can see why a score was assigned.

Dimension01234
Token and word formationMostly broken fragmentsFrequent damageCommon words with some damageMostly stable wordsStable formation throughout
Local grammarNo usable structureOccasional fragmentsShort grammatical spansMostly grammatical sentencesSustained grammatical clauses
Prompt relevanceUnrelatedWeak associationIntermittently relatedUsually on topicConsistently continues the task
Long-range consistencyImmediate contradictionLoses thread quicklyHolds a short threadMaintains a paragraph ideaSustains and develops the idea
RepetitionImmediate loopHeavy repetitionNoticeable repeated phrasesMinor repetitionVaried continuation
Factual restraintIncoherent certaintyFrequent invented specificsPlausible but unreliableSome uncertainty where appropriateBetter restraint, still requires verification

This rubric is an observational course tool, not a benchmark of general intelligence or safety.

Run the comparison lab

Step 1: generate missing controlled samples

Use every model’s verified checkpoint with the shared 50M tokenizer. The command pattern is:

PowerShell:

python generate_text.py `
--checkpoint <controlled checkpoint path> `
--tokenizer tokenizer/learning_50m_tokenizer.json `
--prompt "The purpose of a firewall is" `
--max-new-tokens 64 `
--temperature 0.7 `
--top-k 40 `
--top-p 0.9 `
--repetition-penalty 1.15 `
--no-repeat-ngram-size 3 `
--seed 42 `
--device <cpu or cuda>

Linux and macOS use the same arguments with backslash line continuations.

Replace only the checkpoint and the device required to load it. Repeat for all five prompts.

Step 2: complete the controlled evidence table

Use measured values:

FieldIteration 1Iteration 2Iteration 3
Model profilegpt_first_cpu.jsongpt_42m.jsongpt_100m.json
Parameters8,092,80042,112,00098,506,080
Corpus50M50M50M
Tokenizer50M50M50M
Context length128256256
Training examples20,00020,00020,000
Validation examples1,0001,0001,000
Epochs333
Global step<your value><your value><your value>
Processed tokens<your value><your value><your value>
Best validation loss<your value><your value><your value>
Device and precision<your value><your value><your value>
Batch size<your value><your value><your value>
Throughput<your value><your value><your value>
Elapsed time<your value><your value><your value>
Verified checkpoint<your path><your path><your path>

Step 3: score controlled behavior

Create one row per prompt and model:

PromptIterationWord formationGrammarRelevanceConsistencyRepetitionFactual restraintEvidence note
The purpose of a firewall is1<0-4><0-4><0-4><0-4><0-4><0-4><quote or observation>

Do not average the numbers without retaining the evidence notes. A single total can hide whether a model improved grammar while becoming more confidently wrong.

Step 4: complete the larger-data table

FieldIteration 2 balancedIteration 3 800M
Corpus YAMLconfigs/corpus_balanced.yamlconfigs/corpus_800m.yaml
Actual accepted characters<report value><report value>
Actual training tokens<encoding report value><encoding report value>
Tokenizertokenizer/balanced_tokenizer.jsontokenizer/800m_tokenizer.json
Parameters42,112,00098,506,080
Context length256256
Epoch target318
Global step<your value><your value>
Processed tokens<your value><your value>
Validation loss<within-run value; do not rank across columns><within-run value; do not rank across columns>
Device and precision<your value><your value>
Throughput<your value><your value>
Elapsed time<your value><your value>
Verified checkpoint<your path><your path>

Score the same fixed prompts with the behavioral rubric. Compare observable behavior, but state directly that data, tokenizer, model, and compute changed together.

What the comparison process is doing

You are triangulating three kinds of evidence:

  1. Training evidence shows how optimization progressed on selected training windows.
  2. Validation evidence shows next-token performance on held-out documents under the same tokenizer contract.
  3. Behavioral evidence shows what one-token-at-a-time generation does under fixed prompts and decoding controls.

Operational evidence adds cost and reliability: throughput, elapsed time, peak memory, checkpoint size, interruption recovery, and system stability.

What success looks like

A successful report:

  • contains both tables rather than mixing the experiment paths;
  • uses actual counts from reports and trainer output;
  • retains all fixed-prompt samples;
  • records the decoder settings;
  • compares loss only where tokenization and validation data permit it;
  • links every claim to an observation;
  • reports surviving failure modes;
  • names limitations;
  • proposes the next experiment from evidence.

Stop and check

Do not publish a conclusion if:

  • one model used different prompts or sampling settings without a separate series;
  • a checkpoint was paired with the wrong tokenizer;
  • processed tokens and global steps were omitted;
  • controlled and larger-data validation losses were ranked together;
  • only selected good samples were retained;
  • the proposed cause is not isolated by the experiment.

Common problems and exact responses

ProblemWhy it weakens the resultExact response
“The largest model is best” with no measurementsModel size is being substituted for evidenceComplete the tables and cite specific loss, behavior, and operational observations.
One lucky continuation is shownSampling variance and selection bias are hiddenInclude every fixed prompt and seed, including failures.
Perplexity from different tokenizers is rankedPrediction units are not comparableKeep within-tokenizer loss trends separate and use fixed-prompt behavior for cross-tokenizer observations.
Equal epochs are called equal computeDataset, batch, and context determine work per epochReport processed tokens, optimizer steps, throughput, and elapsed time.
Sampling settings changed for one modelDecoder policy became a confounding variableStart a new labeled comparison series or rerun with the frozen settings.
A fluent falsehood receives a high quality scoreStyle was mistaken for factual reliabilityScore factual restraint separately and mark every unsupported claim.
No next experiment is justifiedThe report summarizes but does not guide engineeringSelect the dominant limitation and change one major variable to test it.

What to record

Preserve the complete commands, artifact identities, hardware and precision, run tables, raw outputs, rubric scores, evidence notes, loss curves, checkpoint paths, interruptions, limitations, and final decision. The comparison should be reproducible by another engineer with access to the same artifacts.

Under the hood

Parameter count, corpus size, token count, context length, batch size, optimizer steps, epochs, and sampling policy are different controls:

ControlQuestion it answers
ParametersHow much representational capacity does the architecture have?
Corpus content and qualityWhat text and patterns are available to learn?
Encoded tokensHow much tokenized data exists?
Context lengthHow much history fits in each example and generation?
Batch sizeHow many examples contribute to each update?
Optimizer stepsHow many weight updates completed?
EpochsHow many passes were made through selected examples?
Sampling policyHow were learned logits converted to output?

Use this evidence-to-next-experiment guide:

EvidencePlausible next experiment
Training and validation loss remain highInspect batches and tokenizer, then test more optimizer steps or a justified learning-rate change
Training improves while validation worsensImprove split quality, deduplication, regularization, or stop earlier
Loss improves but one topic remains weakInspect accepted corpus coverage and source quality for that topic
Text loops despite improving validationCompare checkpoints and then test one decoding control or training-budget change
Hardware is underutilizedMeasure batch size, workers, transfers, precision, and kernel support
Run is memory-limitedReduce batch size or context in a new documented experiment before changing architecture
Fluent factual errors persistImprove data and evaluation, and retain the limitation; a larger model alone does not guarantee truth

Check your understanding

  1. What question does the controlled comparison answer?
  2. Why is the controlled path not perfectly identical across all tensor operations?
  3. Why must balanced and 800M perplexity remain separate?
  4. What does the behavioral rubric add beyond loss?
  5. Why are processed tokens and optimizer steps both useful?
  6. Which conclusion can be supported when model, corpus, tokenizer, and compute all changed?
  7. What is your next experiment, and which evidence justifies it?

You have completed the course when you can explain the complete artifact chain, reproduce every run, distinguish operational success from model quality, and choose a next experiment without automatically choosing a larger model.

Next lesson

Return to the BuildLLM Learning Lab course home, use the glossary for reference, complete the run-record worksheet, and keep the troubleshooting guide with future experiments.

Discover more from DrDeathLabs

Subscribe now to keep reading and get access to the full archive.

Continue reading