What the harness is actually driving
A harness is only useful if it can hold many different models the same way. To do that you have to know what a model is made of and which parts change from one model to the next. This page walks through the pieces, the two main architecture shapes, the open families gradientsmith targets, and the parts you swap while the scoring stays fixed.
The anatomy of a decoder model
Almost every open text model in use today is a decoder-only transformer. The prompt is cut into tokens by a tokenizer. Each token becomes a vector through an embedding table. Those vectors pass through a stack of identical layers. Each layer does two things in order. It mixes information across positions with self-attention, and it transforms each position on its own with a feed-forward network. A residual connection adds the input of each step back to its output, which keeps gradients flowing through a deep stack. A normalization step sits before each of the two operations. After the last layer, a final projection turns the top vector into a score for every token in the vocabulary, and the next token is drawn from that distribution.
The number of layers, the width of each vector, and the number of attention heads set the parameter count. A 0.5 billion parameter model and a 70 billion parameter model share this exact shape. They differ in how tall and wide the stack is.
Attention, and the memory shortcut most open models use
Self-attention lets each token look at earlier tokens and pull in what is relevant. It does this with three projections of every token, called the query, the key, and the value. The query of the current token is compared against the keys of all earlier tokens to decide how much of each value to read. Splitting this into several heads lets the model attend to several kinds of relationship at once.
The keys and values for every earlier token have to be kept in memory while the model generates, which is called the KV cache. Most current open models shrink that cache with grouped-query attention, where several query heads share one set of key and value heads. Qwen2.5 [2024] and Llama 3 [2024] both use it. It cuts the memory a serving harness needs without changing the interface the harness talks to.
Dense and mixture of experts
The feed-forward part of each layer is where the two main architecture shapes split. In a dense model there is one feed-forward network per layer, and every parameter runs on every token. The Qwen2.5 and Llama 3 families are dense. In a mixture-of-experts model there are many feed-forward networks per layer, called experts, and a small router picks a few of them for each token. Mixtral runs 8 experts per layer and uses 2 of them per token [2024]. DeepSeek-V3 has 671 billion parameters in total but activates only 37 billion for any given token [2024].
The reason this matters to a harness is cost and memory. A sparse model can be large and capable while spending the compute of a much smaller one per token, but it still has to fit every expert in memory. A dense model is simpler to serve and simpler to fine-tune, which is part of why the default post-training target here is a dense Qwen coder model rather than a large sparse one [2024].
The open families a harness can target
Open-weights means you can download the parameters, run them on your own hardware, and change them. That is what makes post-training possible at all, since a closed model behind an API cannot be fine-tuned by you. Four families cover most of the current ground. Qwen2.5 is a dense range from 0.5 to 72 billion parameters with a strong coder line [2024]. Llama 3 is a dense range up to 405 billion with a well-documented post-training recipe [2024]. DeepSeek-V3 is a large sparse mixture-of-experts [2024]. Mixtral is a smaller, widely-used sparse model [2024]. A harness that speaks to all of them through one interface can rank them side by side and pick one to improve.
The parts you swap, and the one part you do not
A serving setup is not just the weights. It is a set of parts that can be changed one at a time. The tokenizer sets the vocabulary and the special tokens that mark turns and tools. The base weights can be any family or size. A LoRA adapter is a small set of extra weights that carries a task-specific change without touching the base, which is how the fine-tuning here is done cheaply. A quantization choice trades a little accuracy for a lot less memory by storing weights in fewer bits. The context length can be extended with rope scaling. Each of these is a knob.
The point of a custom harness is that all of that variation sits behind one small interface. The harness hands a model a prompt and asks for a completion. It does not care whether the model is dense or sparse, quantized or not, a base model or a base model plus an adapter. The one thing that never changes is what happens to the answer. It is run through the same deterministic verifier, on the same tasks, with the same scoring. That is what makes two models, or two checkpoints of the same model, actually comparable.
Read the methods page for how the verifier, the adversary, and the two post-training loops are actually implemented, or the references for the technical reports behind each family.