What are model weights, and how does training change them?

Model weights are the learned numbers a neural network uses to turn an input into an output. Training changes those numbers. Inference applies them. That distinction explains why downloading a model is different from downloading an application, why a long conversation does not automatically retrain a model, and why a successful training run is not yet evidence that you have a better assistant.

This is the companion to our practical guide to model inference. Start there for local versus hosted execution and a working inference request. Here, we will follow a weight through an update, save a tiny trained model, and use the same distinction to decide when adapting a language model is worth trying.

What is actually inside a weight file?

A neural network has a structure, called its architecture, and numerical parameters that fit that structure. A simple model might multiply an input by a learned weight and add a learned bias. A language model uses large collections of numerical arrays, called tensors, in operations such as attention and transformations between layers. The term weights often refers collectively to its learned parameters, including values that are not literally multipliers.

Those values influence the model’s behavior together. They are not a folder of documents or a table with one fact per cell. You cannot reliably locate a service’s current owner by opening a weight file and searching for its name. Models can nevertheless memorize and reveal training material, so “it is only numbers” is not a reason to dismiss the sensitivity of the data used to produce them.

The architecture is the arrangement of computations. The weights are the learned values used in those computations. The runtime is the software that executes them. For text models, a matching tokenizer maps between text and token identifiers. These are related artifacts, not interchangeable names for the same thing. The Transformers documentation describes model loading and configuration separately from tokenizer loading and text encoding.

A parameter count tells you how many learned values a model has, not how useful it will be for your task. As idealized storage arithmetic, seven billion values at two bytes each occupy 14 billion bytes, or 14 GB in decimal units. That excludes file metadata, runtime allocations and everything else needed to execute or train the model. It is not a GPU purchase recommendation.

How training changes a weight

Training starts with parameters and examples. A forward pass runs the current model on an example. A loss function assigns a numerical penalty to the difference between the model’s prediction and the training target. Gradients describe how the loss changes with each trainable parameter. An optimizer uses those gradients to update the parameters.

Backpropagation computes gradients through a network; it is not the update itself. In PyTorch’s optimization tutorial, loss.backward() calculates gradients and optimizer.step() changes the parameters. Gradients are reset at the intended update boundaries because PyTorch accumulates them by default. The learning rate controls the scale of an update, while a batch determines which examples contribute to it. An epoch is a pass through the training dataset.

Consider the deliberately small model prediction = w * x + b. It has two trainable parameters: a weight w and a bias b. For one example with x = 1 and target 3, start with both parameters at zero. The prediction is zero and the squared-error loss is (0 - 3)^2 = 9.

The gradients for that example are 2 * (prediction - target) * x for the weight and 2 * (prediction - target) for the bias. Both are -6. With a learning rate of 0.1, subtracting the scaled gradients changes both parameters to 0.6. The new prediction is 1.2 and the loss is 3.24. One update improved this one example. It did not establish that the model has learned the right function for every input.

Train, save and use a two-parameter model

You can make the distinction visible without a GPU, a model download or a framework. The following Python 3 example uses only the standard library. It fits synthetic points generated by y = 2x + 1 using full-batch gradient descent, then saves the two learned parameters as JSON. Run it in a new working directory: it creates toy-weights.json and refuses to overwrite an existing file.

This is a teaching example, not a language model, an incident predictor or a benchmark. Its hand-written derivatives are elementary gradient descent. Real neural networks use automatic differentiation to calculate gradients across much larger computational graphs.

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 that code as train_toy.py and run python3 train_toy.py, or download the complete example. The rounded output is w=2.000000, b=1.000000, prediction(3)=7.000000. The saved floating-point values need not be exactly two and one. The final calculation loads them and predicts a value without changing them: that is the inference part.

The program knows the architecture because we wrote w * x + b into it. The JSON file does not contain an executable implementation of that calculation. It also does not contain the examples, the learning rate or a complete history of training. That is why “I have the weights” and “I can reproduce the training run” are different claims.

Pretraining and fine-tuning are different starting points

Pretraining builds a model’s initial learned behavior from a broad training objective. For a causal language model, a common objective is predicting the next token from preceding tokens. The training text supplies the target tokens, so this is self-supervised learning rather than a process in which a person labels every next-token answer. Other model families use other objectives. The Hugging Face course’s explanation of pretraining and transfer learning gives the broader context.

Fine-tuning starts from an already trained model and continues training for a narrower purpose. Supervised fine-tuning can use examples of an input and the desired response. Preference-based post-training uses another kind of feedback about which outputs are preferred; it is not simply another name for supervised fine-tuning. The InstructGPT paper, for example, describes separate demonstrations, preference comparisons and reinforcement-learning stages. None of these labels guarantees that the resulting model is correct, safe or better at your particular work.

For an SRE team, the important distinction is between changing what information is available at request time and changing learned behavior. A current ownership directory can be supplied in the prompt or retrieved when needed. Those supplied passages condition the response; by themselves, they do not update the generator’s weights. Retrieval-augmented generation combines retrieved context with generation. It is possible to train components of such systems, but ordinary retrieval during a request is not itself a training step.

Suppose an assistant uses an outdated service owner. If the authoritative directory changed yesterday, replacing or retrieving the current directory directly addresses the missing information. Fine-tuning a stale owner into another checkpoint creates a maintenance problem. If the directory is correct but the assistant repeatedly fails to produce a stable routing format despite clear instructions and examples, adapting its behavior may be a reasonable experiment. First isolate which failure you actually have.

Where LoRA and quantization fit

Full fine-tuning can update the base model’s trainable parameters. LoRA, short for low-rank adaptation, instead keeps selected base weight matrices frozen and trains smaller matrices that represent an adjustment. At use time, the base computation and the learned adjustment contribute together. Depending on the model and tooling, the adjustment can remain an adapter or be merged into weights. The PEFT LoRA guide explains that relationship.

A small adapter is not a small standalone replacement for its base model. You still need the compatible base revision and the configuration that says where the adapter applies. Reduced trainable parameter count can make an experiment more manageable, but it does not remove data preparation, evaluation or the need to fit the actual training workload into available hardware.

Quantization addresses numerical representation, such as storing values with fewer bits. That is different from learning a task-specific adjustment. Some quantization methods include calibration or training-related steps, and quantized bases can be combined with adapter training. The terms are not synonyms. The Transformers quantization overview describes the available approaches without implying that every method behaves identically.

Training memory is also more than weight storage. Depending on the method, it includes gradients, optimizer state, intermediate activations and other runtime allocations. Sequence length, batch size, precision and which parameters are trainable all affect the requirement. Use the chosen training method’s measured configuration rather than multiplying a download size by a universal rule.

What should travel with the checkpoint?

A checkpoint is saved state at a point in training. What it contains depends on the saving procedure. A weights-only artifact may be enough to load parameters into a compatible implementation for inference. Resuming training can require optimizer state and other progress information as well. PyTorch’s saving and loading guide distinguishes saving a model’s state from saving a broader training checkpoint.

For a language-model experiment, retain the exact base revision, architecture configuration, tokenizer and chat template, adapter configuration if applicable, training code and configuration, dataset version, and evaluation definition. Record licensing and permitted uses separately. Download access does not settle whether training data can be reused, an adapted model can be redistributed, or a provider is permitted to process your operational records. Obtain those permissions for the actual data and destination before the experiment.

This record matters when an apparent improvement disappears after deployment. A different tokenizer, prompt template, adapter, quantization setting or runtime can mean you are no longer testing the setup that produced the result. Keep the complete setup attached to the result, not just a memorable model name.

Did changing the weights improve the work?

Consider a hypothetical incident-routing assistant. Its task is to propose a service owner from a permitted incident excerpt and a supplied ownership directory, explain the evidence, and say when the directory is insufficient. Training examples can demonstrate that response. They should not also serve as the proof that the model learned to handle new incidents.

Compare the base and adapted setups on held-out routing tasks within the same permitted data and hardware constraints. Judge useful completed tasks, not training loss or parameter count alone. A lower loss shows closer fit to the selected training objective on the measured data; it does not establish that a proposed owner is correct on a new incident.

Separate examples used for updates, a validation set used while choosing the experiment, and a final test set not used for those choices. Google’s dataset-splitting guide explains both this separation and how duplicates undermine it. For incident records, keep related excerpts from the same incident together when splitting: otherwise a near-copy of the answer can appear on both sides. Do not repeatedly choose new settings against the final test and continue calling it independent.

For each held-out case, preserve the input, the applicable directory version and the expected owner or justified abstention. Compare both setups with the same supplied evidence and record other settings. If you change the prompt at the same time as the adapter, report a comparison of two complete setups rather than claiming that the weight change alone caused the improvement. The same principle underlies our explanation of what a benchmark result belongs to.

An assistant that consistently emits valid JSON but routes an unknown service to a confident guess has improved its formatting, not necessarily its usefulness. Review missing-owner and changed-owner cases as well as familiar services. Keep consequential routing or paging subject to the existing service controls; a learned answer is not permission to act.

If the task cannot be evaluated on representative held-out records, do not treat successful training as grounds to replace the working setup. Keep the existing approach while building that evidence. When current information is the missing ingredient, improve the information path first; when stable behavior is the problem, compare a training experiment against a clear prompting baseline. Training changes numbers. The reason to adopt those changes is that they help complete the intended work under conditions you can actually support.