If you have been using LLMs, or at least reading about them, you might have come across confusing terms used to describe models, such as base, instruct, thinking, and reasoning. I think understanding these terms is important for anyone starting with LLMs. These labels give us clues about a model’s training, intended behavior, and how it operates when answering. Understanding the distinction helps us choose a suitable model and configuration for our use case.

Why does a model family have different versions?

Different releases within a model family can differ in their training, intended behavior, and supported modes. Within the Qwen family, for example, you’ll encounter names such as Qwen3-0.6B-Base, Qwen2.5-0.5B-Instruct, and Qwen3-0.6B.

For this article, we are going to use two checkpoints—saved sets of model parameters: Qwen/Qwen3-0.6B-Base and Qwen/Qwen3-0.6B. The first is a base release. The second is post-trained and supports both thinking and non-thinking modes, despite having no Instruct suffix. Qwen model card.

This illustrates why base, instruct, and reasoning describe overlapping properties. Our two checkpoints give us three conditions to compare: base, post-trained with thinking disabled, and the same post-trained checkpoint with thinking enabled.

We are going to examine how the checkpoints respond to four tasks under each condition. I ran these tasks to inspect how the checkpoints follow task instructions and output requirements:

Task	input	What we want to inspect
Extract available information	Order Z17 was due at 14:00; it will now arrive at 14:30.	Can the model extract the order ID and revised time, rather than the original time?
Handle missing information	Extract the details from “Order K82 is delayed. A new arrival time has not been given.”	Can it preserve the known order ID and use null for the missing time?
Track changes to a quantity	A van starts with 12 boxes, unloads 5, then loads 3 additional boxes.	Can it apply the changes and return a count of 10?
Follow ordering constraints	Visit A, B, C, and D once, with A before B, C before A, and D after B.	Can it combine the constraints into the order C, A, B, D?

That gives us twelve task runs. The tasks have answers we can check, but they are illustrative rather than a comprehensive evaluation of either checkpoint.

Each request also specifies a JSON object to return. This lets us assess two requirements separately: does the response contain the expected values, and does it follow the requested format? A response can contain the correct answer yet add prose, repeat the object, or wrap it in a Markdown code block. Those additions matter when an application needs to parse the response as JSON.

We’ll start with what a base model learns during pretraining.

1. What a base model learns during pretraining

For a text-generating model such as Qwen, pretraining involves learning to predict how text continues. The training process compares predictions with actual text and adjusts the model’s parameters. A checkpoint released from that stage is commonly called a base model.

Predicting text can involve much more than completing a sentence grammatically. Text contains explanations, programs, calculations, and questions followed by answers. Models can acquire capabilities useful for those tasks through pretraining.

For the four evaluated tasks, I supplied the base checkpoint with each request as plain text, including the instruction to return JSON. I did not include examples showing how to answer. Let’s start with the first request:

Extract the order ID and revised delivery time from:
"Order Z17 was due at 14:00; it will now arrive at 14:30."
Return only JSON with keys order_id and revised_time.

In my recorded run, the base model returned:

The JSON should be in the following format:

{
  "order_id": "Z17",
  "revised_time": "14:30"
}

Here's the extracted data:

{
  "order_id": "Z17",
  "revised_time": "14:30"
}

The model extracted the correct values, but added explanatory text and repeated the object. In this response, it performed the extraction without satisfying the JSON-only instruction.

Can examples in the prompt help the base model?

The base checkpoint extracted the right values, but added unwanted text. What happens if we demonstrate the desired response pattern in the prompt?

To explore that question, I ran a separate few-shot prompting demonstration with the same base checkpoint. This demonstration is outside the twelve evaluated task runs. I supplied two completed examples, followed by the original delivery update with its answer left unfinished:

Text: Order P10 will arrive at 09:15.
JSON: {"order_id":"P10","revised_time":"09:15"}
Text: Order J20 is delayed; no new time is available.
JSON: {"order_id":"J20","revised_time":null}
Text: Order Z17 was due at 14:00; it will now arrive at 14:30.
JSON:

The first completed example shows how to extract a supplied arrival time. The second shows how to represent a missing time with null. The final JSON: leaves the target response for the model to complete.

The generated response began with the desired object, then invented another example:

{"order_id":"Z17","revised_time":"14:30"}
Text: Order Q17 was due at 15:30; it will now arrive at 15:50.
JSON: {"order_id":"Q17","revised_time":"15:50"}

Few-shot prompting can help a base model follow a task by demonstrating the desired response pattern. This is a form of in-context learning: the examples change the context supplied during inference, while the model’s weights remain unchanged.

Providing examples improved the beginning of the base model’s response. In this run, the response started directly with the target object, without the explanatory introduction from the earlier response. However, the additional examples meant the complete output was still unsuitable for an application expecting a single JSON object. We would need a suitable stopping rule or further output handling.

For an assistant, we want responses to requests to be more consistent. Instruction tuning aims to encourage that behavior through additional training.

2. How instruction tuning shapes assistant behavior

In the few-shot demonstration, I supplied examples as part of the prompt. Another approach is to use instruction–response examples during training, so they guide changes to the model’s parameters.

For our extraction task, an illustrative training pair could look like this:

Request:
Extract the order ID and revised delivery time from:
"Order Z17 was due at 14:00; it will now arrive at 14:30."
Return only JSON with keys order_id and revised_time.

Desired response:
{"order_id":"Z17","revised_time":"14:30"}

The request supplies the context, and the desired response provides the target tokens the model is trained to predict. Training adjusts the parameters to make responses like the desired examples more likely. Training on instruction–response examples in this way is a form of supervised fine-tuning, or SFT, commonly called instruction tuning.

The distinction from few-shot prompting is where the examples are used. During instruction tuning, examples guide parameter updates. During few-shot prompting, they remain part of the input at inference time, with the weights unchanged.

Instruction tuning sits within the broader category of post-training: subsequent training that adapts a pretrained checkpoint. A recipe may also use preferences between responses or reinforcement learning to encourage desired behavior. The InstructGPT paper describes one influential recipe combining demonstrations with reinforcement learning from human feedback. It is one recipe, rather than a mandatory sequence for all models labeled Instruct.

Preparing our request

Our example uses Qwen3-0.6B, a post-trained checkpoint that supports conversational instruction following and thinking modes. It expects conversational messages in a particular format. A chat template identifies who is speaking and where the assistant should respond.

Hugging Face’s Transformers library provides apply_chat_template() to prepare this format. Using our checkpoint’s tokenizer and the extraction request stored in prompt:

formatted_input = tokenizer.apply_chat_template(
    [{"role": "user", "content": prompt}],
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=False,
)

This prepares the input using Qwen’s template, with thinking disabled for this comparison. We then tokenize the formatted input and pass it to the model to generate a response.

How did the post-trained checkpoint respond?

Let’s return to the original extraction request. With thinking disabled, the post-trained checkpoint generated:

```json
{
  "order_id": "Z17",
  "revised_time": "14:30"
}
```

The values are correct, and the response contains one object rather than the base model’s explanatory text and repeated object. However, the Markdown fences are extra characters around the JSON document. The complete response therefore still fails our instruction to return only JSON.

This run shows a difference in how the two checkpoints package the answer. It also shows why instruction-following behavior needs to be checked against the application’s requirements: a response can look appropriate to a reader while still requiring handling before a JSON parser can consume it.

We have now looked at how additional training shapes assistant behavior and how to prepare inputs for the resulting checkpoint. Where does reasoning fit?

3. What changes in a reasoning model?

The term reasoning model usually refers to a model developed to improve problem solving, particularly for tasks that benefit from intermediate steps. This can involve additional training and spending more computation while generating an answer. Models without a reasoning label can also solve problems involving several steps.

Consider our visit-order task. The model must combine three constraints: A before B, C before A, and D after B. It could generate a final route directly. It could also generate intermediate text: list the constraints, propose an order, and check that order before answering.

This generated intermediate reasoning text is commonly called a chain of thought. As the model generates tokens, they become part of the context for subsequent generation, so they can provide working material for reaching an answer.

Both modes use computation to process the input and generate tokens. This is called inference-time compute. With thinking enabled, generating intermediate reasoning tokens uses additional computation before producing the final answer. The trade-off is greater computational cost for a potentially better answer, without a guarantee of improvement.

How does a model learn this behavior?

Developers can use supervised fine-tuning on worked solutions that include intermediate steps. They can also use reinforcement learning, which updates the model to favor responses that receive higher rewards—for example, solutions with a correct, checkable result.

Those worked solutions may come from another model. Training a model to learn from another model’s outputs is a form of distillation. These approaches can be combined; there is no single training recipe for every reasoning model. The DeepSeek-R1 report describes examples of reinforcement learning and distillation.

Reasoning-oriented training can also coexist with instruction tuning. Qwen’s training recipe produces models that follow instructions and support both thinking and non-thinking modes within a single checkpoint. Qwen calls this hybrid thinking modes. These are overlapping capabilities, rather than three mandatory stages of base → instruct → reasoning. Qwen3 training description—see “Post-training”.

Asking a model to work through a problem step by step can also elicit a reasoning trace. That prompt alone does not establish how the model was trained or whether generating the trace improves its answer.

We are now going to use the same Qwen checkpoint with thinking disabled and enabled to inspect what changes in its output.

thinking enabled versus disabled

We are going to repeat the extraction request with the same checkpoint, this time setting enable_thinking=True:

formatted_input = tokenizer.apply_chat_template(
    [{"role": "user", "content": prompt}],
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True,
)

Before generating a response, let’s inspect the formatted input for our order Z17 request.

With thinking disabled, the template produces:

<|im_start|>user
Extract the order ID and revised delivery time from: "Order Z17 was due at 14:00; it will now arrive at 14:30." Return only JSON with keys order_id and revised_time.<|im_end|>
<|im_start|>assistant
<think>

</think>

The user’s request is followed by the assistant prefix and an empty thinking block. All of this text comes from preparing the input; the model has not generated its response yet. Generation starts after the closing </think> marker.

With thinking enabled, the template produces:

<|im_start|>user
Extract the order ID and revised delivery time from: "Order Z17 was due at 14:00; it will now arrive at 14:30." Return only JSON with keys order_id and revised_time.<|im_end|>
<|im_start|>assistant

With thinking enabled, the template does not supply the empty thinking block. Qwen’s mode documentation describes how this setting controls the response format.

We then tokenize the formatted input and generate a response. With thinking enabled, the model generated a <think>...</think> block followed by its final answer. For order Z17, the generated thinking included this passage:

“The original sentence has both the original due time and the revised arrival time. But the user specifically asked for the revised delivery time, so I need to focus on that.”

After closing the thinking block, the model returned:

{
  "order_id": "Z17",
  "revised_time": "14:30"
}

Both modes extracted the expected values, but their formatting and generation costs differed:

Mode	Expected values	JSON-only final answer	Generated tokens	Local generation time
thinking disabled	Correct	No: included Markdown fences	30	0.840 s
thinking enabled	Correct	Yes	314	10.093 s

Of the 314 generated tokens, 287 covered the thinking block through its closing delimiter. The remaining 27 covered the final answer, including the stop token. Most generated tokens therefore belonged to the intermediate output.

Now let’s use the missing-information task:

“Order K82 is delayed. A new arrival time has not been given.”

The request asked for the same two fields, using null for missing information. Here are the values returned by each mode:

Mode	order_id	revised_time
thinking disabled	null	null
thinking enabled	"K82"	null

Only the revised time was missing. With thinking disabled, the model also discarded the supplied order ID. With thinking enabled, it preserved that ID and correctly represented the unavailable time as null.

For the first request, both modes extracted the right values, while their formatting, token usage, and generation time differed. For the missing-information request, thinking mode also preserved information that direct mode lost.

4. What the labels tell you—and what you still need to check

We have seen differences in the final answers, but can we also trust the intermediate reasoning? Let’s return to the visit-order task: visit A, B, C, and D once, with A before B, C before A, and D after B. These constraints determine the order C, A, B, D.

thinking mode returned that correct route. However, its trace also considered C, A, D, B and stated “D after B: yes”—although D appears before B in that sequence.

A correct final answer therefore does not guarantee correct intermediate steps. This example also does not establish faithfulness: whether the trace accurately explains what influenced the model’s answer. That is a separate question explored in Anthropic’s research on chain-of-thought faithfulness.

We still need to check the final answer against the task’s requirements, even when the model produces a convincing explanation.

The labels become more useful when we understand what each one describes:

Label	What the label describes
Base / pretrained	A checkpoint released from pretraining, before subsequent adaptation.
Instruct / instruction-tuned	Adaptation intended to improve responses to instructions.
Reasoning / thinking	Emphasis on problem solving, sometimes offered through a distinct checkpoint and sometimes through a mode within one checkpoint.

These properties can overlap. Our post-trained Qwen checkpoint follows instructions and supports both thinking and non-thinking modes. Turning thinking off changes how we invoke that checkpoint; it does not turn it into a base model.

When choosing a model, read its training description, use its expected input format, and check which thinking controls it supports. Then evaluate representative tasks for answer correctness, output requirements, latency, and token usage together.

For our delivery feature, the practical question is whether a particular checkpoint and configuration can reliably extract the right information, return usable output, and meet the application’s response-time budget. The labels help us understand our options; evaluating the behavior tells us whether those options meet our needs.

---

Companion experiment: the notebook includes all twelve task runs, the two additional base-model examples, exact revisions, settings, and saved outputs. Open the companion notebook · Setup and execution instructions.