The Center of Capability Gains Is Shifting from Pretraining to Post-Training

Over the past few years, the industry has largely advanced model capabilities along the pretraining path of “more parameters, more data, more compute.” But this path is showing clear diminishing marginal returns: data and compute investments grow exponentially while capability gains flatten. Meanwhile, a more efficient path has been repeatedly validated—keep the base model unchanged, significantly increase compute investment in the post-training stage, and scale reinforcement learning to hundreds of downstream domains. This can deliver equally significant capability leaps.

Recent flagship model upgrades offer convincing examples: capability improvements did not rely on a brand-new, larger-scale pretraining run, but were achieved through systematically reinforced post-training on existing base models. The underlying logic can be summarized in one sentence: pretraining injects the “prior” of knowledge and skills into the model, while post-training converts that potential into reliable, controllable, reproducible action capability. Pretraining determines the ceiling; post-training determines how much of that ceiling you can actually realize.

The Post-Training Stack: From Supervised Fine-Tuning to RL with Verifiable Rewards

Modern post-training typically consists of three progressive stages:

1. Supervised fine-tuning (SFT): Train the model’s basic instruction-following ability with high-quality instruction–response pairs, solving the problem of “understanding instructions.”
2. Preference alignment (e.g., RLHF, direct preference optimization, and other general methods): Use human preference data or AI feedback to make outputs better match human expectations, solving the problem of “giving satisfying answers.”
3. Reinforcement learning with verifiable rewards (RLVR): For tasks whose outcomes can be objectively verified—code, math, tool calling—use “whether the task succeeds” directly as the reward signal to train the policy, solving the problem of “actually getting things done.”

The third stage is the core engine of recent capability leaps. Unlike traditional approaches that rely on human-labeled reward models, verifiable rewards come directly from task outcomes: whether unit tests pass, whether code compiles and runs, whether tool calls return expected results, whether output formats comply. These signals are unambiguous, hard to game, and can be generated automatically by machines—making them naturally suitable for scaling to hundreds of downstream domains.

Learning Loops Built on Real Tasks: Models Need to “Do Real Work”

Post-training capability gains increasingly depend on the model’s repeated attempts and feedback in real tasks, rather than imitation of static examples. Take programming: the model needs to actually modify code, run tests in an environment, and keep iterating based on error messages. Professional domains like 3D modeling and financial research similarly require their own tool environments and verification mechanisms. This means the training system must build a complete “task–environment–verification–feedback” loop:

• Task generation: Build task pools stratified by domain and difficulty.
• Environment execution: Provide the model with real tools in a sandbox (interpreters, modeling software, data analysis tools, etc.).
• Result verification: Automatically determine success or failure via test cases, rendered-output comparison, numerical tolerance, and so on.
• Policy update: Feed reward-annotated trajectories back to the training framework to update model parameters.

Here is illustrative pseudocode showing the typical structure of such a training loop:

# Pseudocode: reinforcement learning training loop for real-world tasks
for batch in task_loader:
    trajectories = []
    for task in batch:
        env = SandboxEnv(task.domain)          # Domain sandbox: interpreter/modeling tools, etc.
        obs = env.reset()
        for step in range(MAX_STEPS):
            action = policy(obs)               # Model decision: edit code / call tools
            obs, done, info = env.step(action)
            if done:
                break
        reward = env.verify(task.expectation)  # Test pass rate / rendering consistency / numerical error
        trajectories.append((task, env.history, reward))
    trainer.update(trajectories)               # Update policy based on group-relative advantages

Compared with training on offline data, this “learning by doing” loop lets the model acquire not surface patterns, but the reasoning and execution ability of “act–observe–correct.” This is the fundamental reason why multi-step, long-horizon capabilities—such as agent tasks and complex software engineering—have improved so significantly.

Four Pillars of Post-Training Infrastructure

Scaling reinforcement learning to hundreds of domains takes far more than algorithms—engineering infrastructure often determines success or failure:

1. High-throughput training frameworks: Decoupling trajectory generation from parameter updates, adopting asynchronous scheduling, and optimizing GPU memory and KV cache reuse are prerequisites for keeping large clusters continuously and highly utilized.
2. Long-context inference: Mainstream model context windows have grown from tens of thousands to hundreds of thousands or even millions of tokens. Long context supports massive trajectory replay during training and is essential for handling large codebases and long documents; chunked attention, sparse attention, and KV cache compression are common general-purpose techniques for controlling memory and latency.
3. Sandbox environment systems: Hundreds of domains mean hundreds of tool environments. Standardized environment images, second-level snapshot rollback, and strict resource isolation determine whether training can scale safely, reproducibly, and in parallel.
4. Task scheduling systems: How multi-domain tasks are mixed and sampled, how difficulty is progressively layered, how failed tasks are recycled and reused, and how “reward hacking” is monitored—all require mature scheduling and observability mechanisms.

Evaluation: From Static Benchmarks to Real End-to-End Tasks

Capability leaps also force evaluation methods to upgrade. Traditional benchmarks dominated by multiple-choice questions and static Q&A are saturating and offer limited discriminative power. More challenging evaluation directions include:

• Real end-to-end programming tasks: Put the model in a real operating environment and assess the complete process of multi-step debugging, running, and fixing.
• Professional document analysis: Assess the model’s accuracy in extracting and computing information from complex tables and cross-document references.
• Professional tool calling: Require the model to drive modeling, design, and data analysis tools to complete end-to-end deliverables.

A more important lesson for enterprises: evaluation should be close to your own business. Public benchmarks only provide horizontal reference. Building an internal evaluation set that matches your business distribution and whose answers can be automatically verified is the only reliable way to measure whether a model—especially one customized through post-training—is genuinely useful.

Inference Efficiency and Deployment Options

After post-training, the delivery format is an unavoidable question. A recent industry trend worth noting is “same capability, two versions”: while maintaining model capability, inference-side optimizations provide a high-speed version with roughly 2–3x faster output. The underlying general techniques include speculative decoding, quantization, more aggressive batching, and caching strategies. Latency-sensitive scenarios (such as interactive programming and real-time agents) can prioritize the high-speed version, while offline batch-processing scenarios should weigh throughput against cost.

For access models, APIs suit rapid integration and elastic scaling; open weights suit enterprises with data compliance and deep customization requirements, facilitating private deployment and continued fine-tuning. The two routes are not mutually exclusive—first using APIs to quickly validate business value, then building proprietary capabilities on open weights—is a pragmatic path for many enterprises.

A Practical Checklist for Enterprises

If you want to apply the “post-training releases potential” approach to your own scenarios, check the following items one by one:

1. Task data first: Sort out high-frequency, high-value real tasks and construct automatically verifiable answers (test cases, reference results, tolerance standards). Without reliable verification signals, reinforcement learning is out of the question.
2. Compute and environment preparation: Although scaled post-training costs less than pretraining from scratch, it still requires stable GPU compute, container platforms, object storage for checkpoints and environment images, and logging, monitoring, and alerting for observing training stability. Cloud platforms are a common choice—for example, Baidu AI Cloud offers general capabilities such as model fine-tuning, inference deployment, and compute scheduling, and can be evaluated as one option for enterprises conducting post-training experiments and private deployment.
3. Small steps, fast iterations: First establish the “task–sandbox–verification–training” loop in one domain (such as an internal code assistant), verify the benefits, then expand horizontally—avoid spreading across too many directions at the start.
4. Security and control: Tool environments involve real systems, so be sure to implement least-privilege permissions, operation auditing, and output content filtering.

Conclusion

“Keep the base model, train hard on post-training” is becoming a cost-effective path for upgrading large model capabilities. It reveals a simple rule: model capability growth increasingly resembles how human experts grow—not by reading more books, but by practicing repeatedly in real tasks, gaining feedback, and continuously correcting course. For developers and enterprises, understanding and mastering this post-training methodology—including RL with verifiable rewards, real-task loops, supporting engineering infrastructure, and business-aligned evaluation—is the way to turn technical potential into real business value during periods of rapid model capability evolution.