We’ve seen this failure mode before in machine learning: tune a model hard for one job, then discover it has become worse at useful things it could handle before. The model may get better at the narrow task we paid for, but its broader reasoning, math, or coding performance can take a nasty hit.
Amazon Nova’s proposed answer is called Self-Distilled Reasoning, or SDR. The basic idea is pretty approachable: before supervised fine-tuning, have the base model generate reasoning traces for training examples that originally contain only prompts and final answers. Those traces then become part of the fine-tuning data.
The interesting part is not merely that SDR adds more tokens. It is intended to keep the tuned model closer to the problem-solving behavior it had before customization, without requiring humans to hand-write reasoning for every training record.
The problem: supervised fine-tuning can suppress reasoning
Supervised fine-tuning, usually shortened to SFT, trains a model on examples of desired input and output behavior. That can be a very practical way to customize a model for legal review, document extraction, tool calling, summarization, or other specialized work.
But many real SFT datasets include only an input and the desired final answer. They do not include intermediate reasoning. If a reasoning-capable model is trained in reasoning mode on those bare input-output pairs, the loss calculation covers both its reasoning tokens and its answer tokens. With no examples demonstrating useful intermediate reasoning, the training objective can push the model toward skipping that process.
That is the core reasoning-suppression concern. Even if reasoning is enabled later at inference time, a model fine-tuned without reasoning traces may no longer use it effectively. We should be careful here: this is an experimental finding for the described setup, not a universal law governing every model and dataset. Still, it is a meaningful warning for teams treating SFT as a harmless layer on top of a capable base model.
Why turning reasoning on can matter
The experiments describe a sizable gap between configurations that use reasoning during training and inference and those that leave it disabled in both places. On the LLaVA CoT dataset, the base model had the same 12.30% target performance in either mode before merging.
After fine-tuning and model merging, the difference became much more visible. At a full merge weight of 1.0, target performance was 65.17% with reasoning enabled and 47.90% with reasoning disabled, a 17.27 percentage-point advantage. At merge weights of 0.5 and 0.7, reasoning-on also led by 11.7 and 12.6 points, respectively.
The practical takeaway is refreshingly unglamorous: keep the setting consistent. If a customization workflow trains with reasoning enabled, evaluate and deploy it with reasoning enabled. If we change modes between training and inference, we are no longer making a clean comparison, and we may be leaving performance on the table.
Model merging helps, but it creates a trade-off
A familiar response to capability loss is model merging. In this setup, that means interpolating between the specialized fine-tuned checkpoint and the original base model. A lower merge weight retains more of the base model, while a higher weight leans more heavily on the custom model.
That can recover broader capabilities, including reasoning behavior, but it puts us in the old tuning triangle. More of the base model can preserve general performance, while more of the fine-tuned model may deliver better results on the target task. Getting the balance right requires testing rather than vibes, which is probably for the best.
The reported math-retention result shows why this matters. Vanilla SFT reduced average math performance from 70% for the base model to 6%, a 64-point collapse. SDR reportedly recovered nearly all of that lost capability. Compared with model merging, SDR reached nearly the same math performance, 70% versus 68%, while improving target performance by more than 6.5% on average.
Those are promising results, but they should be read as benchmark results for this method and model family. Teams considering SDR should still validate it on their own task distribution, quality bar, and operational constraints. That same caution shows up across other Amazon AI tooling too, especially once we start mixing customization, orchestration, and safety layers such as Bedrock guardrail checks.
How Self-Distilled Reasoning works
SDR uses the base reasoning model as its own teacher. Instead of obtaining “golden” reasoning traces from a separate, stronger model and then manually validating them, the workflow generates traces from the base Amazon Nova 2 Lite model and attaches them to existing SFT examples.
The proposed pipeline has three stages:
- Run each training example through the base reasoning model to generate an intermediate reasoning trace.
- Add that trace before the original target answer in the training dataset.
- Fine-tune with reasoning mode enabled, so the model receives supervision for both the generated reasoning and the final answer.
This is self-distillation. The model is being trained using representations generated by its own base version. The appeal is straightforward: it avoids the cost of building a human-authored reasoning dataset and does not depend on a separate teacher model. If you have been following Amazon’s broader platform push, it fits neatly with the same “use the platform model to scaffold the next layer” logic we’ve seen in Bedrock AgentCore memory workflows.
Two ways to generate the traces
The method lays out two trace-generation paths. Basic reasoning asks the model to work through a question naturally from the user input alone. That more closely resembles normal inference, because the model does not see the answer it is expected to reach.
Guided reasoning also provides the known target answer, then asks the model to reconstruct a plausible path toward it while behaving as if it does not already know the result. That makes it easier to create a rationale aligned with the training annotation, but it introduces an obvious risk: the answer could leak directly into the reasoning trace.
To reduce that risk, the described workflow filters out mentions of the answer from generated reasoning. That is an important detail. If the trace simply exposes the target, the model could learn a shortcut instead of a useful decision process. We have all seen systems ace the test in ways that tell us very little about whether they learned the underlying task.
The implementation details worth carrying forward
The example implementation uses the Amazon Bedrock Converse API to create the training traces and writes them into a dataset using reasoning-content blocks. It uses Amazon Nova Lite with a maximum of 4,096 output tokens, temperature set to 0.3, top-p at 0.9, and top-k at 50.
Those settings are not magic numbers. Lower temperature is intended to make traces more consistent for training, while top-p and top-k constrain the range of token choices without making the output completely rigid. The right values will vary by task, but consistency matters because these generated traces become training targets.
For teams adapting the approach, a sensible checklist looks like this:
- Start with a representative evaluation set that measures both the target task and capabilities you do not want to lose.
- Use the same reasoning-mode configuration during training and evaluation.
- Inspect generated traces for answer leakage, repetition, unsupported claims, and formatting failures before scaling the pipeline.
- Compare vanilla SFT, merged checkpoints, and SDR rather than assuming the newest workflow wins for every dataset.
- Track operational cost, since generating traces for every example adds an inference pass before fine-tuning begins.
That last point matters more than it sounds. If we are generating a fresh reasoning trace for every record, preprocessing cost and latency become part of the tuning budget, not a footnote. Teams already operating in Amazon’s stack will probably recognize the same trade-off from adjacent customization workflows, including Lex-assisted NLU tuning.
Where SDR was tested
The reported experiments focus on three datasets without native reasoning traces: MedMCQA, CoCoHD, and Invoice-OCR. MedMCQA is a medical question-and-answer dataset with 10,000 training samples. CoCoHD involves generating structured JSON from long congressional-hearing contexts, while Invoice-OCR extracts structured fields from invoice images.
Those tasks matter because they are not the usual toy arithmetic examples. They cover question answering, long-context document extraction, and multimodal document understanding. If SDR can preserve general ability while handling such different customization jobs, that makes the approach more interesting than a narrow benchmark trick.
Still, we should keep our feet on the ground. Generated reasoning traces can inherit the base model’s mistakes, and a plausible explanation is not automatically a faithful account of how a model arrived at an answer. SDR is best understood as a training regularization technique that supplies dense intermediate supervision, not as proof that every emitted trace is a reliable explanation.