Amazon Nova’s self-distilled reasoning post turns fine-tuning into a reasoning-retention problem

AWS’s July 21 post on self-distilled reasoning for Amazon Nova 2 customization makes the fine-tuning risk concrete: if teams tune a reasoning model on supervised data that contains only inputs and final answers, they can suppress the reasoning behavior they expected to preserve.

That is the useful part of the announcement. The blog post, published in AWS’s Artificial Intelligence blog by Rushil Anirudh, Anupam Dewan, and Shiva Mahalingam, is not just another “better fine-tuning recipe” claim. It reframes supervised fine-tuning, or SFT, for reasoning models as a retention problem. The operational question is not only whether a custom checkpoint improves on a target dataset. It is whether the model still knows how to use the intermediate reasoning machinery that made the base model valuable.

AWS calls the proposed method Self-Distilled Reasoning, or SDR. The recipe is straightforward: use the base Amazon Nova 2 Lite model to generate reasoning traces for SFT examples that lack them, prepend those traces to the original answer, then fine-tune with reasoning mode turned on. In AWS’s framing, the reasoning trace becomes in-training regularization. The model is not learning only the desired output; it is also being supervised to preserve a style of problem-solving close to the base model’s own behavior.

That matters because many real SFT datasets are not built for reasoning models. They are built as conventional labeled datasets: prompt in, answer out. For older customization workflows, that could be enough. For reasoning-enabled systems, it creates a mismatch. The model is trained under a loss that sees final outputs but does not see the intermediate thinking tokens. AWS’s hypothesis is that this can teach the model to bypass reasoning, even when reasoning is enabled later at inference time. The result is a custom model that may look better on a narrow task while losing general capabilities that product teams assume are still present.

AWS’s evidence is internal to its own experiments, so it should be read as a vendor result rather than an independently reproduced benchmark. Still, the numbers are sharp enough to be operationally useful. In the post’s Table 2, AWS reports that the base Nova 2 Lite model scores 70 percent on its math control when inference reasoning is enabled. After vanilla SFT without reasoning traces, the math-control result falls to 0 percent for MedMCQA, 6.3 percent for CoCoHD, and 9.6 percent for Invoice-OCR. The same table reports SDR rows that recover most of the control performance: 67.9 percent for MedMCQA with Nova 2 Lite Basic traces, 65.8 percent for CoCoHD with supervised traces, and 67.9 percent for Invoice-OCR with supervised traces.

The target-task side of the table is more nuanced, which is why the post is more useful than a simple “SDR always wins” pitch. On MedMCQA, AWS reports target performance rising from 63.8 percent for no-reasoning SFT without merging to 66.6 percent with Nova 2 Lite Basic SDR. On Invoice-OCR, the no-reasoning SFT row without merging is 88.1 percent, while the supervised SDR row is 87.9 percent and the basic SDR row is 86.1 percent. On CoCoHD, the no-reasoning SFT row without merging and the supervised SDR row are both 61.3 percent, while the basic SDR row is 55.4 percent. The practical lesson is not that trace-prefill maximizes every target score. It is that teams should measure target quality and retained general capability together, because optimizing one view can hide damage in the other.

AWS compares SDR with model merging, a post-hoc recovery method that interpolates a fine-tuned checkpoint back toward the base model. The company says model merging can recover reasoning-related capability, but introduces a tuning trade-off: more base-model weight may recover general skills while giving back gains from the task-specific SFT checkpoint. SDR is pitched as a way to put the retention signal into training instead of repairing the checkpoint after the fact. AWS summarizes this as nearly identical math performance versus model merging, 70 percent compared with 68 percent, while improving target performance by more than 6.5 percent on average.

There is a second useful finding in the partial-reasoning ablation. AWS says it ran LoRA SFT ablations on 10,000 training samples from the LLaVA CoT benchmark and evaluated with MathVista as the target benchmark plus a math control. Without SDR, AWS reports that reducing reasoning-data coverage below 75 percent causes the math control to collapse: 66.6 percent at 75 percent reasoning coverage, 21.7 percent at 50 percent, 3.3 percent at 25 percent, and 2.5 percent at 0 percent. With SDR prefill, the post says the math control stays in the 64 percent to 72 percent range across those mixes. AWS also reports that models trained with 25 percent or less reasoning data and no prefill produce zero median reasoning tokens at inference, while an SDR-prefilled model with 0 percent original reasoning data produces 859 median reasoning tokens. The base Nova 2 Lite model is reported at 1,254 median reasoning tokens.

This is the part practitioners should pay attention to. The failure mode is not abstract “catastrophic forgetting” in a paper title. It is a deployment-relevant behavior: after a normal-looking fine-tuning job, the model may stop emitting reasoning tokens and lose control-benchmark performance. If a business is paying latency, cost, and integration complexity for a reasoning model, that is not a cosmetic regression. It is a capability loss.

The Nova product page helps explain why this is now a product-level issue. AWS describes Amazon Nova 2 Lite as a reasoning model for everyday tasks, with developer controls for thinking effort, built-in tools including code interpreter and web grounding, remote MCP tool support, and a 1 million-token context window. The same page says Nova models cover use cases including advanced multi-step reasoning, multimodal understanding, and conversational AI, and says Nova 2 Lite customization is available through Amazon Bedrock and Amazon SageMaker AI across pre-training, SFT, and reinforcement fine-tuning. Once reasoning controls and customization are both product surfaces, training-data structure becomes part of the deployment contract.

Teams should respond by changing their fine-tuning acceptance criteria. A target benchmark alone is not enough. Before starting an SFT run on a reasoning-capable model, classify the training set by reasoning coverage: which examples include validated reasoning traces, which include only final answers, and which traces are synthetic or teacher-generated. Then define a retention suite before training begins. It should include the target task, at least one general reasoning or math control, one structured-output control if the application uses JSON or tool calls, and an inference-behavior check that records whether the model actually emits reasoning tokens under the intended serving configuration.

Second, keep the training and inference settings aligned. AWS explicitly says it kept reasoning mode consistent when comparing reasoning-on versus reasoning-off configurations, and its recommendation section warns that maintaining the same reasoning mode during training and inference is critical for optimal performance. If a team trains with reasoning enabled and serves with it disabled, or vice versa, it should treat that as a separate product configuration, not a harmless toggle.

Third, use SDR as a risk-reduction tool, not as a license to stop curating data. AWS says the method has no human annotation cost because the base model generates the reasoning traces, but that does not make every generated trace correct, safe, or appropriate for regulated domains. The post itself distinguishes basic reasoning from guided reasoning and says guided reasoning includes a secondary filtering step to remove answer leakage. Practitioners should add their own checks: remove traces that disclose labels too directly, contradict the final answer, include policy-prohibited content, or create a rationalization that would be unacceptable in audit logs.

Fourth, be careful with stronger teachers. AWS notes that Amazon Nova 2 Pro is in preview on the Nova models page and describes it as its most intelligent model for highly complex workloads, available through early access for Nova Forge customers. In the SDR post, AWS cautions that a stronger teacher is not automatically better: Nova 2 Pro Preview traces can improve target accuracy while causing a proportional drop in general performance, and AWS recommends same-family Lite-generated traces as the default balance for Nova 2 Lite customers. That is a useful warning for teams tempted to synthesize all training traces with the largest available model.

Finally, treat latency as part of the decision. Reasoning traces and reasoning-enabled inference can improve performance, but they can also increase token use and response time. AWS’s own practitioner guide says latency-sensitive teams seeing general-performance regression may use model merging, while teams whose latency constraints can accommodate reasoning should use SDR with Nova 2 Lite-generated traces. That is the right shape of decision: do not decide from benchmark accuracy alone; decide from target quality, retained capability, token cost, latency, and the risk of suppressing the capability the model was chosen for.

The broader shift is that fine-tuning reasoning models is becoming less like ordinary domain adaptation and more like preserving a learned process under new supervision. AWS’s SDR post does not prove a universal law for every model family, dataset, or deployment. It does, however, gives teams a concrete failure mode to test for. If your SFT dataset omits reasoning traces, the default assumption should no longer be “the model will keep reasoning because the base model could.” The safer assumption is: unless you supervise or validate reasoning retention, you may be training it away.

---

Shadowfetch is an independent software company publishing evidence-based journalism. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.