Course: Course 3 — LLM Fine-Tuning Masterclass
Module: FTDD-08 — Qwen3
Duration: ~45 minutes (spoken at ~140 wpm)
Format: Verbatim transcript with [SLIDE N] cues. Read aloud or use as speaker notes.
[SLIDE 1 — Title]
This is deep-dive eight: Qwen3. In the last module we looked at DeepSeek-R1, the reasoning distillation reference. Qwen3 is the other canonical reasoning reference, and it teaches a different lesson. R1 proves reasoning emerges and transfers. Qwen3 proves you can put a reasoner and a fast assistant into a single set of weights and ship it to real traffic. It is the production workhorse.
[SLIDE 2 — The production problem]
Here is the tension a dedicated reasoner creates. A model like R1 always deliberates. For a competition math problem, that is exactly what you want — a long, self-correcting chain that arrives at the right answer. But most production traffic is not competition math. It is summarize this email. Rewrite this in a friendlier tone. What is the syntax for a Python list comprehension. For those, the deliberation is pure latency tax. The user waits seconds for a chain they never asked for, and the answer is no better.
On the other side, a fast assistant that always answers directly cannot deliberate when the question actually warrants it. So you have two extremes. The naive fix is two models: a reasoner for hard questions, a fast assistant for easy ones. That doubles your operational surface — two sets of weights, two serving configs, a router to decide which gets which query, and a failure mode where the router misroutes. Production teams hate this.
[SLIDE 3 — Qwen3's answer: fusion]
Qwen3's answer is fusion. One set of weights, with both modes coexisting, switched by a thinking budget. The same model produces a long deliberate chain or a fast direct answer, selected at inference time. No router. No second model. One deployment serves both workloads.
A thinking budget — a single parameter — decides how much the model deliberates on a given query. This is why Qwen3 is the deployed workhorse where R1 is the research touchstone. R1 proves the science. Qwen3 proves the engineering. Production needs the hybrid property, and Qwen3 is the model most teams running an open reasoner actually deploy.
[SLIDE 4 — The four-stage pipeline]
The post-training pipeline. Four stages. The first two echo R1; the third is the novel contribution.
Stage one, long-CoT cold start. As with R1, seed the model with long chain-of-thought data to anchor the reasoning format. Install the deliberation habit and the output template. This stage does not maximize capability — it installs the shape.
Stage two, reasoning RL. GRPO-style, verifiable rewards — math correctness, code execution, structured logic. Same family as R1. This scales reasoning capability. By the end of stage two, you have a strong thinking model.
So far this is structurally the same as R1's first two stages. The divergence is next.
[SLIDE 5 — Stage 3, the fusion]
Stage three, thinking-mode fusion. This is what makes Qwen3 a hybrid rather than a dedicated reasoner. The team takes the thinking model from stage two and fuses it with a non-thinking — fast, direct — model. They construct a dataset containing both thinking and non-thinking responses across a broad range of tasks, then fine-tune a single model on the combined data so it can produce either mode depending on the control signal.
The key engineering insight is that the thinking pathways and the direct-response pathways are not mutually exclusive in the weights. They can coexist, and a control token or budget parameter selects which the model expresses. After fusion, the model has both capabilities installed in one set of parameters. This is what R1 does not do. R1 ships a pure reasoner. Qwen3 ships a model that can be either.
[SLIDE 6 — The thinking budget]
The thinking budget is the single parameter that makes the hybrid useful in production. It controls how many tokens the model may spend inside its think block before producing a final answer. Low budget, the model produces a short or empty deliberation and answers directly — chatbot speed. High budget, the model deliberates at length, self-corrects, arrives at a more reliable answer — reasoner quality. Same weights.
This is adaptive compute at the inference layer. Simple queries get a fast direct answer because the model spends no thinking tokens. Hard queries get a long chain because the budget permits it. You set a default budget appropriate to your workload. A latency-sensitive chatbot sets it low. A batch math-solver sets it high.
[SLIDE 7 — Why the budget matters operationally]
Without a budget, a hybrid model still needs a per-query router to decide thinking versus non-thinking, and that router is itself a failure mode. The budget collapses routing into a single continuous parameter. You do not need a classifier to decide is this query hard. You set a default and the model spends within it.
The trade-off. The budget is a latency-quality dial, and it is not free. A model that always thinks at a high budget is as slow as a dedicated reasoner. A model that never thinks loses the reasoning advantage. The production discipline is choosing the budget that matches your latency SLA and your accuracy target. Qwen3 gives you the knob. Using it well is an engineering judgment.
[SLIDE 8 — Why Qwen3 is the workhorse]
Qwen3 was pretrained on thirty-six trillion-plus tokens. The family spans dense models from zero-point-six billion to thirty-two billion and a mixture-of-experts flagship at two-hundred-thirty-five billion total, twenty-two billion active. This scale matters for the hybrid thesis. The base is strong — broad world knowledge, multilingual, from pretraining alone. And critically, the non-thinking mode inherits this strength. A fused model is only a good hybrid if the non-thinking mode is a genuinely capable assistant, not a degraded reasoner. The pretraining scale is what guarantees that.
Put the pieces together. The hybrid property solves the routing problem. The thinking budget gives you a single latency-quality dial. The pretraining scale ensures the non-thinking mode is strong enough for general traffic. And the family spans the size range teams actually deploy. For most teams, a Qwen3 variant is the default.
[SLIDE 9 — R1 vs Qwen3]
R1 and Qwen3 are complementary references. R1 is the distillation reference — it proved reasoning emerges from RL and transfers via SFT-only. Study it when you are building a student by distilling from a teacher. Qwen3 is the hybrid reference — it proved you can fuse modes and control with a budget. Study it when you are deploying one model that must serve both a chatbot and a reasoner.
The strongest teams know both. Qwen3's own distillation work drew on R1's recipe, and the field's thinking-model conventions now borrow from Qwen3's budget mechanism. These are not competing approaches. They are two halves of the open reasoning story.
[SLIDE 10 — Anti-patterns]
Three anti-patterns. First, defaulting to max budget everywhere. The budget is a latency-quality dial. Running trivial queries through long chains wastes tokens. Set the default to your workload. Second, treating fusion as two models glued together. Fusion is one set of weights with two modes. Building a router re-creates the problem fusion solved. Third, ignoring the non-thinking mode in evaluation. Evaluate both modes against their respective benchmarks, or you will misjudge the model for production.
[SLIDE 11 — What you can now do]
You can now explain why thinking-mode fusion is the key innovation over a dedicated reasoner. You can draw the four-stage pipeline and what each stage contributes. You can predict how a low versus high thinking budget changes latency, tokens, and quality. And you can distinguish Qwen3 from R1 — hybrid for production, R1 for distillation.
Next, deep-dive nine: llama.cpp and vLLM. You have built and fused a model. Now you have to serve it. Let's look at the two serving stacks every fine-tuner needs to know.
End of module FTDD-08. Duration: approximately forty-five minutes at one-hundred-forty words per minute.
# Teaching Script — Module FTDD-08: Qwen3 **Course**: Course 3 — LLM Fine-Tuning Masterclass **Module**: FTDD-08 — Qwen3 **Duration**: ~45 minutes (spoken at ~140 wpm) **Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes. --- [SLIDE 1 — Title] This is deep-dive eight: Qwen3. In the last module we looked at DeepSeek-R1, the reasoning distillation reference. Qwen3 is the other canonical reasoning reference, and it teaches a different lesson. R1 proves reasoning emerges and transfers. Qwen3 proves you can put a reasoner and a fast assistant into a single set of weights and ship it to real traffic. It is the production workhorse. [SLIDE 2 — The production problem] Here is the tension a dedicated reasoner creates. A model like R1 always deliberates. For a competition math problem, that is exactly what you want — a long, self-correcting chain that arrives at the right answer. But most production traffic is not competition math. It is summarize this email. Rewrite this in a friendlier tone. What is the syntax for a Python list comprehension. For those, the deliberation is pure latency tax. The user waits seconds for a chain they never asked for, and the answer is no better. On the other side, a fast assistant that always answers directly cannot deliberate when the question actually warrants it. So you have two extremes. The naive fix is two models: a reasoner for hard questions, a fast assistant for easy ones. That doubles your operational surface — two sets of weights, two serving configs, a router to decide which gets which query, and a failure mode where the router misroutes. Production teams hate this. [SLIDE 3 — Qwen3's answer: fusion] Qwen3's answer is fusion. One set of weights, with both modes coexisting, switched by a thinking budget. The same model produces a long deliberate chain or a fast direct answer, selected at inference time. No router. No second model. One deployment serves both workloads. A thinking budget — a single parameter — decides how much the model deliberates on a given query. This is why Qwen3 is the deployed workhorse where R1 is the research touchstone. R1 proves the science. Qwen3 proves the engineering. Production needs the hybrid property, and Qwen3 is the model most teams running an open reasoner actually deploy. [SLIDE 4 — The four-stage pipeline] The post-training pipeline. Four stages. The first two echo R1; the third is the novel contribution. Stage one, long-CoT cold start. As with R1, seed the model with long chain-of-thought data to anchor the reasoning format. Install the deliberation habit and the output template. This stage does not maximize capability — it installs the shape. Stage two, reasoning RL. GRPO-style, verifiable rewards — math correctness, code execution, structured logic. Same family as R1. This scales reasoning capability. By the end of stage two, you have a strong thinking model. So far this is structurally the same as R1's first two stages. The divergence is next. [SLIDE 5 — Stage 3, the fusion] Stage three, thinking-mode fusion. This is what makes Qwen3 a hybrid rather than a dedicated reasoner. The team takes the thinking model from stage two and fuses it with a non-thinking — fast, direct — model. They construct a dataset containing both thinking and non-thinking responses across a broad range of tasks, then fine-tune a single model on the combined data so it can produce either mode depending on the control signal. The key engineering insight is that the thinking pathways and the direct-response pathways are not mutually exclusive in the weights. They can coexist, and a control token or budget parameter selects which the model expresses. After fusion, the model has both capabilities installed in one set of parameters. This is what R1 does not do. R1 ships a pure reasoner. Qwen3 ships a model that can be either. [SLIDE 6 — The thinking budget] The thinking budget is the single parameter that makes the hybrid useful in production. It controls how many tokens the model may spend inside its think block before producing a final answer. Low budget, the model produces a short or empty deliberation and answers directly — chatbot speed. High budget, the model deliberates at length, self-corrects, arrives at a more reliable answer — reasoner quality. Same weights. This is adaptive compute at the inference layer. Simple queries get a fast direct answer because the model spends no thinking tokens. Hard queries get a long chain because the budget permits it. You set a default budget appropriate to your workload. A latency-sensitive chatbot sets it low. A batch math-solver sets it high. [SLIDE 7 — Why the budget matters operationally] Without a budget, a hybrid model still needs a per-query router to decide thinking versus non-thinking, and that router is itself a failure mode. The budget collapses routing into a single continuous parameter. You do not need a classifier to decide is this query hard. You set a default and the model spends within it. The trade-off. The budget is a latency-quality dial, and it is not free. A model that always thinks at a high budget is as slow as a dedicated reasoner. A model that never thinks loses the reasoning advantage. The production discipline is choosing the budget that matches your latency SLA and your accuracy target. Qwen3 gives you the knob. Using it well is an engineering judgment. [SLIDE 8 — Why Qwen3 is the workhorse] Qwen3 was pretrained on thirty-six trillion-plus tokens. The family spans dense models from zero-point-six billion to thirty-two billion and a mixture-of-experts flagship at two-hundred-thirty-five billion total, twenty-two billion active. This scale matters for the hybrid thesis. The base is strong — broad world knowledge, multilingual, from pretraining alone. And critically, the non-thinking mode inherits this strength. A fused model is only a good hybrid if the non-thinking mode is a genuinely capable assistant, not a degraded reasoner. The pretraining scale is what guarantees that. Put the pieces together. The hybrid property solves the routing problem. The thinking budget gives you a single latency-quality dial. The pretraining scale ensures the non-thinking mode is strong enough for general traffic. And the family spans the size range teams actually deploy. For most teams, a Qwen3 variant is the default. [SLIDE 9 — R1 vs Qwen3] R1 and Qwen3 are complementary references. R1 is the distillation reference — it proved reasoning emerges from RL and transfers via SFT-only. Study it when you are building a student by distilling from a teacher. Qwen3 is the hybrid reference — it proved you can fuse modes and control with a budget. Study it when you are deploying one model that must serve both a chatbot and a reasoner. The strongest teams know both. Qwen3's own distillation work drew on R1's recipe, and the field's thinking-model conventions now borrow from Qwen3's budget mechanism. These are not competing approaches. They are two halves of the open reasoning story. [SLIDE 10 — Anti-patterns] Three anti-patterns. First, defaulting to max budget everywhere. The budget is a latency-quality dial. Running trivial queries through long chains wastes tokens. Set the default to your workload. Second, treating fusion as two models glued together. Fusion is one set of weights with two modes. Building a router re-creates the problem fusion solved. Third, ignoring the non-thinking mode in evaluation. Evaluate both modes against their respective benchmarks, or you will misjudge the model for production. [SLIDE 11 — What you can now do] You can now explain why thinking-mode fusion is the key innovation over a dedicated reasoner. You can draw the four-stage pipeline and what each stage contributes. You can predict how a low versus high thinking budget changes latency, tokens, and quality. And you can distinguish Qwen3 from R1 — hybrid for production, R1 for distillation. Next, deep-dive nine: llama.cpp and vLLM. You have built and fused a model. Now you have to serve it. Let's look at the two serving stacks every fine-tuner needs to know. --- *End of module FTDD-08. Duration: approximately forty-five minutes at one-hundred-forty words per minute.*