Preparing the GPT Model for Classification Fine-Tuning

A pre-trained GPT model has already learned general patterns from a large amount of text. That general knowledge is valuable, but the model was not built to answer one specific question, such as whether a message is spam or not spam. To use it for a classification task, two things must happen before fine-tuning begins: its final layer has to be adapted so it produces one output for each class the task requires, and the model has to be placed on the device where it will run. This article walks through the setup step that adapts the final layer, and then the step that prepares the model to run on an available device.

The setup is short, but every line changes something specific. As you read it, ask two questions about each line: what object is being changed, and what value does that object end up holding? Keeping those two questions in mind will make the rest of the article easier to follow.

The key idea is that only one part of the model is swapped out. The replacement is a single assignment to the model's out_head attribute. Nothing else in the setup code redefines the model, so the rest of the GPT architecture stays exactly as it was loaded. Only the final layer, the one that turns internal representations into outputs, is changed.

Read the diagram as a comparison. On the left is the model as it was loaded, with its original output layer. On the right is the same model after the assignment. The output layer is the only element marked as changed. The rest of the architecture is shown on both sides because it carries over untouched.

The replacement follows the pattern described in the setup. The left side of the assignment names the spot in the model that gets overwritten. The right side creates a new torch.nn.Linear object, and the assignment stores that object in place of the old layer. Here is the replacement in the form the setup describes, with num_classes set to 2 before the layer is created:

Read the anatomy from left to right. The attribute on the left is the location being overwritten. The call on the right defines the new layer's shape. The in_features value is fixed at 768 in this setup, while the out_features value is taken from num_classes. This means that changing the number of classes changes only the output side of the layer.

The value of num_classes becomes the out_features argument, so it determines how many outputs the new layer produces. Each output position corresponds to one class. With num_classes equal to 2, the layer produces two outputs, one for each class. Changing the task to a different number of classes means changing only that value.

After the output layer is replaced, the setup prepares where the model will run. The setup code first creates a device object. It selects CUDA when torch.cuda.is_available() reports that CUDA is available, and selects the CPU otherwise. The device is chosen based on what the machine offers rather than being hard-coded. The final line, model.to(device), applies that choice to the model.

The flowchart traces one decision. The check asks whether CUDA is available. A yes answer selects cuda, and a no answer selects cpu. Both paths then reach the same final step, model.to(device), which moves the model onto the selected device. The device is therefore chosen at run time from what the machine offers, and the model follows that choice.

Notice the order of the setup. The device selection comes after the output layer replacement. The model is first adapted to the classification task, and then it is placed on the device where it will run. Both steps happen before any training or fine-tuning begins.