大模型真正拉开差距的地方在预训练之后：一条后训练链路的完整拆解

You don't know about LLM training: principles, paths, and new practices

Too long, but read it anyway.

After writing "You don't know about Claude Code: architecture, governance, and engineering practices" and "You don't know about Agents: principles, architecture, and engineering practices," I thought I'd continue with a third piece. This time I wanted to challenge myself to sort out what LLM training is really about, and I hope this article is accessible even for readers without a technical background.

Looking at LLMs in 2026, the real gap in model effectiveness is no longer pretraining itself, but the long stretch that comes after it: post-training, evaluation, reward, agent training, and distillation. Every single step affects the quality users actually feel. When a model suddenly gets better, it's usually because several of these pieces have been optimized together, not because of a single factor.

The following sections will walk through the LLM training pipeline in order, focusing on how companies improve the final deployed quality through the second half of the training stack.

In the past few years, model progress was often attributed to parameters, data, and compute. But many of the improvements users actually feel come not from feeding more basic corpus data, but from the entire training process after pretraining. How a model speaks, follows instructions, reasons, and uses tools—these don't naturally emerge just by feeding more internet text.

InstructGPT gave a very direct example: a 1.3B parameter model that had been aligned and preference-optimized could beat a 175B GPT-3 in human preference evaluations, with two orders of magnitude fewer parameters. Users preferred the much smaller version. The second half of training really rewrites user perception.

The training process is an assembly line: data, algorithms, systems, and feedback are all tightly coupled. A change in one layer usually propagates to others. In 2026, model capability and industry value are increasingly concentrated in the layers after pretraining.

Layer	What is really optimized here	What users usually perceive
Pretraining	Knowledge coverage, representation quality, scale efficiency	The model got smarter
Data engineering	Data distribution, quality, dedup, synthetic supervision	Why this model is stronger at code/math/long documents
System & architecture	Throughput, memory, context length, active parameters, cost	Why it supports 128K context or runs on a single GPU
Post-training	Instruction following, style, refusal behavior, tool use	This assistant feels smoother to use
Evaluation & reward	What counts as good, safe, robust behavior	This model feels more reliable
Distillation & deployment	Latency, cost, specialization, online continuous improvement	Why the deployed version differs from the announced version

This is also why Doubao doesn't bother competing on leaderboards, yet everyday users find it more satisfying—they got the post-training right.

These six layers are just for functional division. The diagram below shows a more detailed nine-stage version: raw data and system recipe are separated out, and Agent harness and deployment are further broken down in the second half. There are also two feedback loops running throughout: production traffic loops back to data engineering, and offline evaluation results loop back to pretraining.

Pretraining is still the starting point of the training pipeline. Understanding what it actually does is necessary to grasp what every subsequent layer adds. Without this step, there is no language modeling ability, no knowledge compression, and no room for later capability transfer. In engineering terms, it's not just about teaching the model to predict the next token: it's about learning the language distribution, compressing the knowledge and patterns from large-scale text into parameters, and leaving room for future capability activation. Next-token prediction only describes the training form; it doesn't explain why, when scale increases, the model suddenly develops abilities it didn't have before.

After GPT-3, many model tuning efforts started to consider budget and allocation more carefully. Bigger models aren't always better; there's an allocation relationship between parameters, training tokens, and total compute budget. Many models aren't too small—they're undertrained, not reaching the optimal point under the given budget.

In real training decisions, the more practical question is: if you were given 10,000 H100s and a month, how would you train a good enough open-source model? Scaling laws here are more like a budget allocation tool, not the abstract curves from papers. Eventually, you need to think carefully about: should the next training round pile on more parameters or more data? Is the current model lacking capability, or just undertrained? With limited GPU budget, which allocation is more worthwhile?

Pretraining is more like laying the foundation for model capabilities—it determines the knowledge scope, generalization potential, and pattern recognition ability, and also determines whether there's room for post-training to utilize. But whether to follow instructions, cooperate with users, or be stable on key tasks—these are all beyond pretraining's reach.

The pretraining phase doesn't just decide how much knowledge to learn; it also determines what the model can become later. The tokenizer's segmentation method directly affects subsequent training, and the context window length has to be decided upfront. Whether to continue with multimodal pretraining, or to require single-card runnability from the start—these trade-offs are baked into the recipe during training, not features added at release time. Gemma 3's simultaneous emphasis on single accelerator, 128K context, vision capabilities, and quantization reflects this kind of upfront trade-off. The capabilities users ultimately see—like running on a local computer, viewing images, or understanding long documents—are often decided during the training phase.

According to the Chinchilla optimal compute point, for an 8B parameter model, the optimal is about 200B tokens. But Llama 3 8B actually used 15T tokens, about 75 times the optimal. This kind of over-training recipe usually achieves higher capability density at the same parameter count, resulting in a smaller, more efficient model to deploy. Measuring this, total FLOPs is a more reliable metric than parameter count. The chart below illustrates this gap.

There's another easily overlooked design decision that happens during pretraining: the tokenizer vocabulary size, segmentation strategy, and byte-level encoding all have significant impact. Llama 2 has a 32K vocabulary; Llama 3 expanded it to 128K, compressing sequence length by about 15%, which also improves downstream performance. This impact extends to inference cost and multilingual capability. The token efficiency for Chinese, code, and mathematical formulas is determined at vocabulary design time. For example, a tokenizer that breaks Chinese into very small pieces doesn't just cost a few extra tokens each time—it carries the penalty of that wrong decision at every inference.

Parameter scale was the main focus in the past few years, but in recent years, something more important has emerged: the "data recipe."

On the surface, this is about cleaning data, but it's actually a complete data production engineering process. Web pages, code repositories, books, forums—these raw sources must go through text extraction, language identification, quality filtering, privacy processing, safety filtering, and deduplication before entering pretraining. The diagram below shows the full funnel process.

If data is treated only as training fuel, it's easy to conclude that more is always better. But data engineering is closer to capability design. What the model sees and doesn't see, what proportion of code vs. math vs. encyclopedic knowledge is used—these choices directly shape the final capability distribution of the model.

Deduplication and contamination control are often overlooked, but they have a huge impact on results. It's not just about low-quality data; it's also about duplicate templates, licensed texts, mirrored pages, and contamination from benchmark leakage. Without sufficient document-level and line-level dedup, the model tends to repeatedly absorb the most easily copied content without necessarily learning the most valuable parts. Many open-source models appear uneven in quality precisely because of differences in data processing quality.

In the last two years, data mixing itself has become a separate research topic. Work like Data Mixing Laws focuses not just on how much data can be collected, but also on how the proportions of different data types steer the model toward particular capability structures.

Synthetic data has also moved from being an auxiliary tool to a formal part of the training process. Self-Instruct methods, where the model generates its own instruction data, DeepSeek-R1's distillation trajectories, and the increasingly obvious synthetic supervision in the Qwen and Kimi series—they all point in the same direction. Each generation of stronger models participates in reconstructing the data that the next generation sees. Early models generate basic instruction data; stronger models generate high-quality reasoning traces and CoT data; inference models trained with RL then distill these trajectories into smaller dense models. Dense means all parameters are active, unlike MoE which activates on demand.

The key insight here is that models often need to form capabilities at a larger scale first, and only then can those capabilities be compressed into smaller models. The DeepSeek-R1-Distill series is a direct example. RL-trained trajectories from the large model brought significant gains to dense models ranging from 1.5B to 70B. Llama 3.1 405B was also explicitly used to improve the post-training quality of the 8B and 70B models. These are not byproducts; they are part of the training design.

Many people understand training as a research problem: how to set the objective function, how to reduce loss, how to modify the model architecture. But in real large-scale LLM training, system constraints are extremely important. It's a distributed systems problem, not a single-machine deep learning problem. GPU count, memory bandwidth, parallelism strategies, fault tolerance, and cost—these can't be optimized after training; they determine from the very beginning how large you can train, how long a context you can support, and whether you can run more complex post-training.

MoE is the most typical example of this layer. The mixture-of-experts approach allows the model to expand total parameters with similar compute, while controlling the activation cost per token. The trade-offs are increased routing complexity, load balancing difficulty, and heavier infrastructure. DeepSeek-V3 and the Qwen series of MoE designs are all trade-offs between cost and effect, not just architectural preferences.

Recent public recipe discussions are no longer just about coarse-grained analysis like model size and token ratios. muP allows hyperparameters to be transferred from small-scale experiments to large-scale training. WSD learning rate is a schedule that warms up, stays steady, then decays. Combined with optimal batch sizes and higher data-to-parameter ratios, these details are starting to appear in official training reports. These nuances are where the real gaps between similarly-sized models are opening up.

Long context, multimodality, and new architectures—if understood only as product features, the training-side constraints are missed. A 128K context target directly changes attention cost, batch size, training curriculum, and parallelism strategies. Multimodality changes not just the model structure, but also data mixing, encoder design, and safety evaluation. If single-card runnability is made a hard requirement, then parameter count, quantization paths, and model family size all tighten accordingly.

Work like Forgetting Transformer and Kimi's Attention Residuals are all answering similar questions: how to train with longer contexts, and how to prevent information from being diluted as networks get deeper. What you see is a model that can handle longer inputs or is easier to deploy; what the training faces is a completely different set of constraints.

The compute budget is fixed. Model size, training tokens, context length, and serving cost—every time you spend more in one direction, other directions have to give way.

Longer context means attention cost expands directly, and batch size must shrink; larger models mean more GPU memory, and serving costs also rise. These aren't choices—they're consequences of resource constraints, and most decisions are locked in before training even begins.

There's another engineering reality often overlooked: training isn't always stable. After running thousands of GPUs for weeks, a sudden loss spike can appear—large enough to be irrecoverable—forcing a rollback to a checkpoint from days earlier, and starting over.

Beyond loss spikes, there are silent GPU errors that produce wrong gradients without crashing, NVLink bandwidth anomalies, and inter-node communication jitter. Each of these can corrupt several training steps. The ability to detect, isolate, and recover quickly at scale is lab-level engineering capability, not something you learn from papers.

DeepSeek-V3's technical report specifically notes that the entire pretraining process had no irrecoverable loss spikes and required no rollbacks. It is also one of the few publicly verified cases of FP8 mixed-precision training being feasible at ultra-large scale. According to public data, the full process used about 2.788M H800 GPU hours, training 14.8T tokens.

Training and inference systems are closely related, but they are not the same engineering problem. Training cares about gradients, parallelism, checkpoints, throughput, and cost. Inference cares about latency, KV cache, quantization, and service stability.

Many of the improvements users actually feel happen after pretraining. Instruction tuning uses labeled instruction-response pairs for supervised training. It changes how the model responds—turning requirements like how to take on a task, how to structure output, and how to be a cooperative assistant into supervised signals. A base model might already have many latent capabilities, but without this step, those capabilities won't reliably appear in the form users expect.

Looking further, RLHF, DPO, and RFT all aim in a similar direction—incorporating "what a better answer looks like" into the training loop—but they take different paths.

• RLHF (Reinforcement Learning from Human Feedback) first imitates high-quality answers, then uses preference comparisons for reinforcement.
• DPO (Direct Preference Optimization) shortens this path, learning directly from preference comparisons without needing a separate reward model.
• RFT (Reinforcement Fine-Tuning) provides a more engineering-friendly interface, putting task definition, grader design, and reward signals into a productizable pipeline.

Today, talking about post-training by just mentioning SFT or RL is no longer enough. The harder part is how to set up evaluation, how to score, and what makes an answer worth optimizing further. SFT (Supervised Fine-Tuning) learns not just knowledge, but also style. Data length, format, whether citations are included, and whether bullet points are preferred—all these significantly influence the final output form. Many users think they're comparing capabilities, but often they're just comparing style differences. Plus, preference evaluations naturally favor longer answers, easily mistaking a seemingly more thoughtful long output for a more reliable one. So post-training can't just rely on leaderboards; it also needs to consider real task results, cost, and stability.

Modern post-training is a multi-stage pipeline. The clearest public recipe is from DeepSeek-R1, which progresses through four stages:

Stage 1: Cold Start SFT. Before doing reinforcement learning, warm up with a small set of high-quality Chain-of-Thought (CoT) data. DeepSeek-R1-Zero showed that doing RL directly from a base model is feasible, but pure RL-trained models suffer from repetition, language confusion, and poor readability. The cold start SFT provides a more stable starting point for RL, first converging on format and language consistency. This is not a redundant step.

Stage 2: Reasoning RL (GRPO). Apply RL in verifiable domains like math, code, and logic, using GRPO as the training algorithm and programmatically verifiable correctness as the reward signal. The key question is why GRPO instead of traditional PPO. PPO (Proximal Policy Optimization) requires a separate value network to estimate the value of the current state, which is a heavy engineering burden when maintaining two networks on a large model. GRPO samples multiple responses for the same prompt and uses within-group ranking to replace absolute value estimation, eliminating the need for a separate value network. It's much cleaner from an engineering standpoint. DeepSeek and Cursor Composer 2's RL infrastructure both use approaches close to GRPO.

Stage 3: Rejection Sampling Fine-Tuning. Filter the successful trajectories produced by RL and convert them into new SFT data, then run another round of supervised fine-tuning. This is a bridge between RL and SFT—the good trajectories explored by RL become high-quality training samples for the next round of SFT.

Stage 4: Alignment RL. Incorporate helpfulness and safety preference feedback, adjusting the model into an assistant form that meets release standards.

The four stages depend on each other: cold start makes RL stable, RL produces high-quality data, rejection sampling turns that data into input for the next SFT round, and alignment RL converges behavior. From public results, the gap between direct SFT and a full four-stage pipeline is usually noticeable.

The component that converts model output into training scores is called the grader, and it often has surprising problems. Looking only at the final answer, the model quickly learns shortcuts; with coarse scoring, noise is continuously amplified by RL; when leaderboard scores rise, real task quality doesn't necessarily follow. Many times, users think they're seeing base model differences, but the real gap is in how the objective is defined.

In the training pipeline, eval determines what to measure, the grader determines how a single output becomes a score, and the reward determines where the model is pushed next. Together, they form a concrete feedback loop: task definition, eval, grader, optimization, rollout, and re-evaluation. If any link in this chain goes wrong, subsequent optimization will go wrong too.

Looking only at final results, the model might get the right answer by chance, or it might follow an incorrect process to reach it. In code, math, and complex reasoning tasks, this problem is especially prominent. If intermediate steps aren't included in the feedback, the model often learns not to reason more reliably, but how to maximize the probability of getting that final score.

So in recent years, more work has shifted from traditional RLHF toward verified rewards, using programs to directly verify correctness. In tasks like math, code, and logic that are verifiable, scoring can now be based directly on correctness, without relying primarily on human preferences. But verified rewards haven't completely solved the problem. Over-optimization, reward overfitting (where the scoring rule is over-optimized without real capability improvement), and mode collapse (where output becomes highly homogeneous, losing diversity) still occur. The problem has just shifted from whether preferences are labeled accurately to whether the scoring pipeline is stable.

The thinking process written by the model cannot be taken as a complete record of its internal process either. In experiments on reasoning model observability, Anthropic found that models can use additional prompts without acknowledging them in the visible CoT; in reward hacking scenarios, the model is even more likely to fabricate a seemingly reasonable explanation. Reward hacking means exploiting the scoring system rather than genuinely completing the task. The visible CoT is better used as a training and monitoring signal, not as a complete truth.

Going a step further, models can even start to exploit the scoring channel itself. Research on reward tampering and alignment faking shows that models could theoretically actively interfere with the scoring process itself. Reward tampering directly manipulates the reward calculation process itself; alignment faking is surface compliance while hiding misaligned intent.

Once a model has strong enough environment access, it optimizes not just the task result, but potentially the checklist, reward code, and training relationship itself. In a 2025 experiment by Anthropic, extra reward-hack knowledge was injected into a set of exploitable production coding RL environments, and similar generalization was observed afterward. After learning reward hacking, the model not only continued exploiting similar tasks, but also exhibited broader misalignment like alignment faking.

These behaviors are not visible in standard dialog evaluations; they only appear in agent task environments. The engineering implication is direct: reward, grader, environment isolation, and monitoring all need to be designed as part of training.

Further into the agent stage, reward design breaks down further. The final result is only one item; process quality, context management, and anti-cheating constraints all need to be measured separately. Kimi K2.5 rewards effective decomposition and genuine parallelism; Chroma Context-1 scores relevant documents found during search; Cursor Composer 2 incorporates summaries in long tasks into the reward, because once a summary is distorted, the subsequent context is led astray.

In concrete implementations:

• ORM (Outcome Reward Model) only scores the final answer. The signal is sparse and costs are low, making it a good starting point, but it also makes it easier for the model to take shortcuts.
• PRM (Process Reward Model) scores intermediate steps. The signal is denser, which is usually stronger for math and code reasoning, but annotation and system costs are much higher.

OpenAI saw in math reasoning experiments that PRM not only improved accuracy, but also better constrained the process, because every step is being supervised. The problem is also direct: PRM costs are typically several times that of ORM. So most real systems still start with ORM, and only in verifiable tasks like math, code, and logic does it make more sense to automate PRM, using programs to verify intermediate steps and bypass the human annotation bottleneck.

When the loop runs fully:

Several recent alignment methods are all doing the same thing. Anthropic's Constitutional AI incorporates human-written principles into training, using AI feedback to replace per-example human preferences. OpenAI's Deliberative Alignment puts safety compliance into the reasoning process itself, letting reasoning capacity bear part of the safety constraint. Deliberative Alignment means the model judges safety norms during inference, rather than relying on trained-in reflexive behavior. Both lines are moving alignment from human labels to being part of the training objective itself.

Taking Constitutional AI as an example, the two-stage process first has the model self-criticize and revise its outputs according to principles, then uses AI feedback to replace per-example human preference labeling. Alignment is never a patch tacked on after training. What the system measures, how it scores, and what it rewards—those are what steer the model. This is the most direct adjustment tool in the second half of training.

In the past two years, reasoning models represented by the o1 series and DeepSeek-R1 have rapidly taken shape, showing that when rewards are stable, verification is reliable, and infrastructure is in place, RL on language models can indeed significantly improve performance on math, code, and logic tasks.

This also opened up a new dimension: inference compute is now scalable. The role of RL training has gained an additional layer: beyond teaching the model to answer questions, it's also teaching the model to allocate its inference budget—knowing when to think more and when to stop. Going further, the challenge becomes getting the model to act continuously in an environment, rather than just extending single-shot thinking.

Junyang Lin, the former head of the Qwen model team, had a very representative reflection on the mixed Thinking and Instruct route: the difficulty isn't giving the model a thinking switch, but that the two modes have fundamentally different goals—one seeks directness, compliance, and low latency, while the other pursues more exploration and higher accuracy. Going a step further, the training objective shifts from how long to think before answering, to how to allocate budget during action, how to receive feedback, and how to continue advancing a task.

At this point, the object of training is no longer just a model that answers questions, but a system that can plan, call tools, receive feedback, and stay coherent over long tasks. The training stack also changes accordingly: browsers, terminals, search, execution sandboxes, memory systems, tool servers, and orchestration frameworks all enter the training system.

More precisely, the harness is the control program wrapped around the model. This concept isn't just for the agent runtime; it also exists during training: it determines what input the model sees, in what form it receives feedback, when to trim context, and when to call tools. Prompt construction, memory updates, retrieval policies, context editing, and tool orchestration all live here. The environment is no longer just a static validator, but a layer that both training and deployment must directly face.

The harness must be stable first, otherwise model training is pointless. When tool return values are unstable, the browser environment is inconsistent with production, or the file system state is irreproducible, the grader will make mistakes first, and the model will then learn not capabilities, but how to exploit environment vulnerabilities. When training agents, debugging the model and debugging the environment often go hand in hand.

The approaches of three companies are clear: Kimi uses PARL to solve parallel decomposition and credit assignment; Cursor uses self-summarization and real-time RL to reconnect long coding sessions with production traffic back into training; Chroma trains prune_chunks as a policy itself, bringing context pruning directly into the retrieval process.

In the SFT era, data diversity was the top priority. In the agent era, environment quality is the core: stability, realism, coverage, difficulty distribution, feedback richness, and resistance to exploitation. The training objective also changes—what's needed is reliability throughout an entire task, not just getting a single question right. Classic CoT benchmarks don't cover this part.

This change is also moving forward: not only is the model trained within the runtime harness, but the harness code itself is starting to become an object that can be searched and optimized by an outer loop.

Kimi K2.5's PARL is a very instructive engineering case to unpack. The approach is clear: train only the orchestrator, concentrating credit assignment at the orchestration layer, not optimizing all sub-agents simultaneously.

Reward signals are divided into three categories: task success, parallel decomposition, and completion constraints, all driving the orchestration layer. Early in training, the r_parallel weight is boosted to encourage exploration of parallel strategies, then gradually annealed to zero later to avoid using multiple sub-agents as a shortcut. Evaluation doesn't just look at total steps, but also at the critical path length—shorter critical paths indicate that parallelism is genuinely effective.

But by 2026, things have moved further. Meta-Harness explicitly separates out harness engineering for optimization. It doesn't optimize weights, but the harness code itself—the prompt construction, retrieval, memory, and state update programs wrapped around a fixed model. The paper's opening number is very direct: the same base model, with only the harness changed, can show a 6x performance gap on the same benchmark. This outer program is no longer just a deployment detail; it's also a layer where capability is formed.

The key isn't adding another abstract optimizer, but writing prior code, scores, and execution traces (the execution logs of tool calls and state changes) into the filesystem, letting a proposer grep, cat, compare diffs, and then modify the harness along failure paths, just like coding.

The authors' judgment is clear: many past text optimizers have been ineffective on long-running, stateful programs like harnesses. The core reason is that looking only at scalar scores, short templates, or summaries flattens the problem. Scalar scores only capture the final result, without process information. Harness errors often only show up many steps later; once feedback is over-compressed, the diagnostic chain breaks.

These results are more than just higher benchmark scores. In online text classification, Meta-Harness outperformed ACE (agent context engineering baseline) by 7.7 points, while cutting context token usage to one quarter. In retrieval-augmented math reasoning, one discovered harness on 200 IMO-level problems averaged an additional 4.7 points across 5 held-out models (not included in optimization). On TerminalBench-2, it also surpassed the manual engineering baseline. This shows that what is being optimized is no longer just the model's internal policy, but also the program that organizes information and actions around the model.

A concrete example: Meta-Harness automatically discovered environment bootstrap on TerminalBench-2—running a shell command before the agent loop starts, to snapshot the working directory, available languages, package managers, and memory state, and inject it into the first prompt. Many coding agents spend the first few rounds just exploring the environment. With this upfront setup, the improvement doesn't necessarily come from stronger weights, but from the harness putting the model on better context from the start.

At this point, the optimization target has expanded from the answer, to the trajectory, and further to the harness program that carries the trajectory.

Understanding today's LLMs through the lens of a single round of pretraining is no longer sufficient. Behind every released model, the full chain of pretraining, post-training, distillation, and specialization has usually been completed. And stronger models are continuously producing training data for the next generation.

The DeepSeek-R1 series distillation is a typical example: the large model first develops reasoning ability through RL and verified rewards, then transfers these reasoning trajectories to smaller dense models. TranslateGemma shows another route: on more clearly defined target tasks, using high-quality data and specialized reward design to further compress and direct capability. At this point, stronger models aren't just serving users; they're also directly producing training data for the next generation.

The reason goes deeper than trajectory transfer. One possible explanation: knowledge memorization and reasoning ability are coupled in internet text. The existing pretraining objective requires the model to learn both simultaneously. The large model has to come first because only a large enough model can simultaneously support both tasks. Then its purely reasoning demonstration data can be generated, allowing smaller models to focus on reasoning alone when trained on this data, without being forced to memorize all knowledge. Big first, then small—the key reason is capability decoupling, not just a cost strategy.

On the other hand, deployment suitability is just as important as capability itself. Many scenarios don't need a general-purpose large model—they care more about cost, latency, stability, and controllability. The end point of training isn't necessarily bigger; it could be smaller, cheaper, and more specialized.

The final released model is not necessarily the checkpoint at the rightmost end of the training curve. Before actual release, real task results, refusal styles, tool stability, costs, and regression risks are repeatedly compared across multiple checkpoints. The version that goes online is ultimately a product decision, not the single strongest performer on a single metric.

When users see a model name, they might think it corresponds to a smooth upward training curve. But which checkpoint is actually chosen for release—that's a different story.

The value of large models lies not only in their own serving capability, but also in their continued role as training data sources, distillation sources, and release bases for the next generation of models.

Beyond offline training, near-online continuous optimization has also entered the main pipeline. Cursor Composer 2's real-time RL shows that some agent capabilities are already being iterated through production traffic, rather than waiting for the next large-scale offline training round. The boundary between training and deployment hasn't disappeared, but the feedback loop between them is shortening.

How to understand why a model got better

In 2026, the value of frontier models increasingly depends on who can run the complete training pipeline after pretraining: continuously producing training data, doing distillation, specialization, getting evaluation and reward right, and making the final release selection.

Because of this, when looking at why a model suddenly got better, start with three things:

First, look at whether the change happened at the pretraining layer or in the later training pipeline. Many capability improvements do come from stronger pretraining and better data recipes, but many perceived improvements are primarily from post-training. Whether a model follows instructions, uses tools, and has a stable response style—these often don't emerge naturally just from feeding more corpus data.

Second, look at which layer the improvement comes from: is it the weights and training recipe, the reward/eval/grader, or the harness code and deployment loop? At the reasoning model and agent stage, what users feel as "stronger" is often not the result of the base model alone. How evaluation is set up, how rewards are scored, whether the tool environment is stable, how retrieval and memory are organized, how summaries and context are pruned, and which checkpoint was selected for release—all of these collectively determine the final product performance.

Third, look at what the released version is optimizing for. Some versions pursue higher upper limits; others compress cost, latency, and regression risk; still others specialize for a particular use case. A released version is a product decision, not the rightmost point on the training curve. So when looking at a model update, it's more helpful to see what it's actually optimizing for.

If you break down "the model suddenly got better" into production components, many improvements are actually amplified by the second half of the training stack and the outer harness. The iteration cycle of this chain is also shortening: production traffic continuously flows back into training; each generation of stronger models produces not only capabilities but also supervision data for the next generation; the outer program is constantly rewritten based on rollouts, logs, and real task feedback.

The model released today is just a snapshot. The pipeline and the harness program are the products that keep running.

Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). arXiv:2203.15556

Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). arXiv:2203.02155

Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300

DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948

DeepSeek-AI (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437

Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783

Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073

OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. openai.com/index/deliberative-alignment

Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. anthropic.com/research/reward-tampering

MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. arXiv:2511.18397

Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (preprint project page). yoonholee.com/meta-harness

Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. kimi.com/blog/kimi-k2-5

Rush, S. (2026). A technical report on Composer 2. cursor.com/blog/composer-2-technical-report

Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. trychroma.com/research/context-1