Model weights: change two numbers and watch an answer move

Open a downloaded model in a text editor and its gigabytes will not explain much. They contain learned numbers called weights, which a program uses to turn inputs into outputs. To see what those numbers do, begin with a model small enough to calculate on paper: two values, one input and an answer that starts out wrong.

The inference guide covers running models locally or through hosted services. Here, change a weight, save the tiny model and connect that experiment to a larger decision: whether a language model needs new information or a change in learned behavior.

Two numbers need a calculation to belong to

Our toy multiplies an input by a weight and adds a bias. A file containing those two numbers cannot do anything without the matching calculation. Its structure is the architecture; its learned values are parameters. Language models use many more parameters, arranged in arrays called tensors throughout calculations such as attention.

Those language-model values work together rather than each holding a labeled fact you can look up. Searching a weight file is no reliable way to find today’s service owner. Yet numerical storage does not prevent a model from memorizing and revealing training data. Recognizable training information can still appear in generated answers.

Text also needs a tokenizer, which maps it to numbered units before calculation. The right weights with the wrong mapping may receive different units than expected. Transformers documents model/configuration loading and tokenizer loading separately because the values, calculation and text mapping must agree.

Parameter count tells part of the storage story. Seven billion values at two bytes each occupy 14 billion bytes (14 decimal GB) before metadata and runtime allocations. That explains a large download, not the usefulness of its answers or the full memory needed to run and train it.

Move the prediction from zero toward three

Set the weight and bias to zero. Give the model input 1 and target 3: it predicts 0. The difference is −3, and squaring it gives error 9. Producing that prediction is the forward pass; the chosen error measure is the loss. Training now has a specific quantity to reduce.

For this squared error, the derivative with respect to the weight is 2 * (prediction - target) * x; for the bias it is 2 * (prediction - target). Both are −6 here. These gradients describe how small changes affect loss. In a multilayer network, backpropagation calculates gradients through the layers without applying the update itself. In PyTorch's tutorial, loss.backward() calculates them and optimizer.step() changes the values.

With learning rate 0.1, the optimizer subtracts 0.1 times each gradient. Subtracting −0.6 adds 0.6 to both numbers. Now prediction = w * x + b produces 1.2 for input 1, and squared error drops from 9 to 3.24. The learning rate determines step size. This step helped this example; other inputs still need checking.

The script uses five examples together for each update. That group is a batch, and a full pass through the dataset is an epoch. Its hand-written derivatives average the five gradients. PyTorch accumulates gradients by default, so its training loop must clear them at the intended boundary. These choices determine which examples contribute to the next update.

Train the tiny model, then reopen what it learned

The standard-library Python example fits invented points from y = 2x + 1 using full-batch gradient descent and saves two parameters. Use a new directory: it creates toy-weights.json and refuses to overwrite an existing file. No framework, model download or GPU is needed.

This is elementary gradient descent with hand-written derivatives, not a language model, incident predictor or benchmark. Real networks usually use automatic differentiation across much larger calculations.

import json
from pathlib import Path

points = [(-2.0, -3.0), (-1.0, -1.0), (0.0, 1.0),
          (1.0, 3.0), (2.0, 5.0)]
w, b = 0.0, 0.0
learning_rate = 0.1

for _ in range(100):
    errors = [(w * x + b) - y for x, y in points]
    dw = sum(2 * error * x for error, (x, _) in zip(errors, points)) / len(points)
    db = sum(2 * error for error in errors) / len(points)
    w -= learning_rate * dw
    b -= learning_rate * db

checkpoint = {"architecture": "scalar-linear-v1", "w": w, "b": b}
path = Path("toy-weights.json")
with path.open("x", encoding="utf-8") as handle:
    json.dump(checkpoint, handle)

loaded = json.loads(path.read_text(encoding="utf-8"))
assert loaded["architecture"] == "scalar-linear-v1"
before = (loaded["w"], loaded["b"])
prediction = loaded["w"] * 3.0 + loaded["b"]
assert (loaded["w"], loaded["b"]) == before
print(f"w={w:.6f}, b={b:.6f}, prediction(3)={prediction:.6f}")

Save the script as train_toy.py and run python3 train_toy.py, or download it. Its rounded output is w=2.000000, b=1.000000, prediction(3)=7.000000; the stored floating-point values need not be exactly two and one. Loading those values and predicting without changing them is inference.

The JSON still needs w * x + b to make a prediction. It also lacks the training points, learning rate and history. A file can be sufficient to use the learned relationship without being sufficient to reproduce how it was learned.

Ask with input 4 instead of 3 and the same weights give about 9. Change the training targets and train again to learn different values. One asks the model another question; the other teaches it another relationship.

Today’s owner directory is an input, not a training project

Imagine an incident router whose directory assigned a service to storage yesterday and to the data team today. Supplying today’s directory changes the input, much as input 4 changed the toy’s prediction without retraining. The Hugging Face course describes how language models initially learn from text, commonly by predicting the next token from earlier text; other model families use other objectives. That initial learning is pretraining.

Changing how the router responds is another task. Fine-tuning continues training an existing model: supervised examples can pair incident reports with desired responses. Preference-based post-training instead gives feedback about preferred outputs. The InstructGPT paper distinguishes demonstrations, comparisons and reinforcement learning stages. These alter learned behavior, not the contents of the latest directory.

The directory can reach the model through Retrieval-augmented generation: fetch relevant material, then generate using it. An ordinary retrieval call does not update the generator’s weights, although surrounding components can themselves be trained. Tomorrow’s source can change without producing a new model file.

For the changed owner, retrieve the current directory. If that directory is already correct but the assistant ignores the required routing format despite clear instructions and examples, training may address a different question: can it use the information more consistently? Keep those problems separate rather than teaching yesterday’s owner into another checkpoint.

A learned adjustment and a smaller representation are different changes

Training can change the base parameters or keep them fixed and learn an adjustment. Imagine retaining a calculation and adding a small learned correction. LoRA adds smaller matrices (arrays of numbers used in calculations) to selected base matrices, which stay frozen. Both contribute during use. The PEFT guide explains saving the adjustment separately or merging it into the base.

That separate adjustment file is an adapter. It needs the compatible base and configuration identifying where its corrections belong. Attaching it elsewhere would not recreate the trained computation. Fewer learned values can make the experiment smaller, but the full computation still runs and its data and evaluation still require care.

Quantization instead represents values in fewer bits. It changes how numbers are stored, rather than adding a learned task correction. It can accompany adapters, and some methods use calibration or training to choose the representation. The quantization overview describes those approaches. A smaller download and better learned routing behavior are not the same result.

During training, memory also holds intermediate results needed to work backward, gradients and optimizer state used to choose updates. A weight file alone therefore understates the requirement. Longer sequences and larger batches add work to retain; precision, method and which values are trainable affect the total too.

Save enough to explain tomorrow’s reload

Reopen the router tomorrow and reproducing its answers needs the matching calculation and learned values. Resuming training may also require optimizer state and training progress. A checkpoint saves that state; PyTorch's saving guide distinguishes what is needed for use and for continuing training.

If the reopened model behaves differently, ask whether it received the same token IDs and chat formatting, and whether the expected adapter loaded on the same base revision. Keep tokenizer, chat template and base/adapter configuration with the file. Training code, settings and dataset version explain where the values came from; the evaluation definition explains what was considered better. Establish permissions for the actual data, processing, training and redistribution. Permission to download alone settles none of those other uses.

Runtime or quantization changes can also affect the result. The saved setup record lets a team reconstruct the tested combination before interpreting changed behavior. Without it, “same model” may hide different inputs and calculations.

Give the adapted router an incident it has not seen

Supply a permitted unseen incident and today’s owner directory. Ask for the owner and supporting information, or an acknowledgment that the directory is insufficient. Training examples can demonstrate that response; the new report tests whether the learned pattern extends beyond those examples.

Run base and adapted setups on the same unseen work under the same data and hardware constraints. Lower training loss means a better fit to the training objective. If the report still goes to the wrong team, that improvement has not solved the routing task.

Keep near-copies together. A paraphrased report should not cross from its original’s training set into testing. Use development examples to choose settings and reserve final tests for the selected candidate. Repeatedly adjusting to those final answers turns them into development material too. Google's splitting guide explains the split and duplication risk.

Keep the unseen report, applicable directory and expected owner or justified abstention beside both responses. A reviewer can then inspect the actual difference. Changing prompt and adapter together compares two setups; the benchmark guide explains why that cannot isolate the weights’ contribution.

Finally, remove the service from the test directory. A neatly formatted JSON response naming its old owner would still misroute the report. A useful adapted router leaves the owner unresolved. Changed and missing owners test whether improved formatting preserved the reason for routing; consequential paging still follows organizational controls.

The toy learned two useful numbers for its invented line. The incident router faces a richer question: can those changed values help it use a new report and current directory without inventing a missing owner? Keep the base if unseen cases do not improve. Carry the adapter forward when those cases show what the change actually bought.