Post-Training Scaling vs. New Base Models: Two Technical Paths for Upgrading Large Models

1. Background: Capability Improvement Enters a Fork in the Road

Over the past two years, large model iteration mostly followed a familiar path: train a larger base model, run a longer pretraining phase, and finish with a standard alignment stage. More recent industry signals, however, show leading teams splitting into two distinct directions.

One path keeps the previous-generation base model and channels all additional investment into post-training, using large-scale reinforcement learning to raise the ceiling of model capability. The other starts over, training a new base model at trillion-parameter scale and then performing alignment and reinforcement on top of it.

Both paths position coding and agentic capability as the headline direction. They represent two answers to the same question: as the data dividend from pretraining begins to plateau, where should the next stage of capability growth come from?

This article does not focus on specific products. Instead, it treats these two paths as technical paradigms and examines their underlying logic, key levers, costs, risks, and how practitioners can decide which one to take.

2. Clarifying Concepts: What Pretraining and Post-Training Actually Determine

• Pretraining: next-token prediction over massive corpora. It builds the model’s knowledge base, its representations of language and code, and its prior distribution over reasoning behavior. Pretraining determines the distribution of potential — what the model might be able to do.
• Post-training: supervised fine-tuning (SFT), reinforcement learning from human feedback (RLHF), reinforcement learning with verifiable rewards (RLVR), agentic reinforcement learning, and related methods. Post-training determines the realization of potential — what the model can reliably and consistently do.

A useful analogy is that pretraining mines the ore, while post-training smelts and refines it. Ore grade, meaning base model quality, sets the theoretical ceiling for the final product. Smelting technique, meaning post-training methods, determines the actual yield. This explains why both paths can be reasonable: if the grade is too low, no process can produce high purity; if the grade is sufficient but the process is outdated, the ore is wasted either way.

It is also worth noting that the industry’s understanding of post-training has shifted. Early post-training was roughly equivalent to alignment, with the goal of making outputs conform to human preference. Today, scaling the reinforcement learning stage is increasingly seen as a first-class engine alongside pretraining scaling. By expanding task environments and increasing exploration compute, teams can directly optimize verifiable capabilities such as reasoning, coding, and tool use, rather than merely tuning parameters.

3. Path One: Squeezing the Existing Base Model to Its Limits

The premise behind this path is that the base model’s potential has not been exhausted. The bottleneck is not whether the model “knows” something, but whether that capability has been activated. Investment concentrates on three levers.

3.1 Long-Horizon Task Environments: Immersing the Model in Real Engineering Chains

Traditional SFT data mostly consists of single-turn Q&A and isolated code snippets. Task duration is measured in turns. The core of post-training scaling is to upgrade the training unit from a single dialogue turn to a complete task chain: understanding a code repository, locating a defect, modifying multiple files, running tests, and submitting a fix. A single task may span dozens or even hundreds of tool calls. Expanding the environment pool from thousands to hundreds of thousands or more means the model encounters orders of magnitude more real engineering patterns during training.

The value of long-horizon environments is that they naturally provide sparse but trustworthy terminal rewards, such as whether tests pass or whether the task completes. This forces the model to learn planning, trial and error, and self-correction instead of relying on step-by-step human labels. This is fundamentally different from simply accumulating more single-turn Q&A data: the former trains the ability to complete tasks, while the latter trains the ability to imitate answers.

3.2 Environment Diversity: Preventing Capability Imbalance

A narrow environment causes the model to overfit to a specific interaction pattern. A mature approach uses an environment matrix covering multiple scenario types:

• Terminal operations: build, deployment, and troubleshooting in a shell environment.
• Repository-level code tasks: bug fixing, feature development, and refactoring.
• Cross-tool collaboration: coordinated use of code editors, browsers, retrieval systems, and executors.
• Data analysis and document processing tasks.

Diversity not only improves generalization but also suppresses reward hacking. When environments are sufficiently heterogeneous, it becomes hard for the model to find a shortcut that succeeds across all of them.

3.3 Compute and Training Duration: Simple but Effective Brute Force

A defining characteristic of reinforcement learning training is that rollout sampling costs far more than gradient updates. The most direct way to raise the ceiling is to increase sampling compute and extend training time, giving the model more attempts through which effective strategies can emerge.

Industry experience suggests, however, that the returns curve in the RL stage is steeper and more fragile than in pretraining. Mid-training plateaus are common, and continued training may produce a sudden jump. Alternatively, training may stagnate for a long time and be accompanied by entropy collapse, meaning a loss of output diversity. Therefore, simply adding compute must be paired with stability measures.

3.4 Key Engineering Challenges: Reward Design, Stability, and Data Flywheel

• Reward design: verifiable tasks such as unit tests and successful compilation provide clean rewards but limited coverage. Open-ended tasks require model-based scoring or rubric-based evaluation, which introduces noise and exploitable gaps.
• Training stability: KL constraints prevent the policy from drifting too far from the base model. Entropy regularization prevents premature convergence. Curriculum learning schedules environments from easy to hard.
• Data flywheel: weaknesses discovered during training are used to generate targeted environments, which are then fed back into training.

A schematic training loop:

# Post-training reinforcement learning main loop (illustrative)
env_pool = build_environments(...)      # terminal, repository, and cross-tool environments
policy = load_base_model()              # reuse the existing base model
for step in range(train_steps):
    tasks = curriculum.sample(env_pool, k=batch_tasks)        # curriculum sampling by difficulty
    trajs = rollout(policy, tasks, max_turns=long_horizon)    # long-horizon multi-turn interaction
    rewards = [verify(t) for t in trajs]                      # tests passed / task completed
    if too_easy(rewards) or too_hard(rewards):
        env_pool = regenerate_environments(weak_points(trajs))  # data flywheel
    policy = rl_update(policy, trajs, rewards,
                       kl_ref=base_model, entropy_beta=0.01)    # stability constraints

4. Path Two: Training a New Base Model from Scratch

The logic behind the new-base-model path is that when task complexity approaches the representational limits of the existing base model, post-training can only optimize within the existing potential distribution. Marginal returns diminish. At that point, the only way forward is to return to pretraining and raise the ceiling itself through larger parameter scale, higher-quality data mixtures, and more carefully staged training schedules. A representative schedule moves from general pretraining to continued pretraining focused on code and reasoning, followed by long-context extension.

The costs are equally clear:

• Compute and cycle time: pretraining at trillion-parameter scale takes months, and the iteration cadence is slow.
• Front-loaded risk: base model quality problems often surface only during post-training or evaluation, making rework extremely expensive.
• Ecosystem migration: engineering assets such as inference optimization, quantization schemes, and context caching must be re-adapted.

Mixture-of-experts (MoE) architectures are currently the mainstream choice for scaling parameter count. The total parameter size is increased to expand knowledge capacity, while routing mechanisms activate only a subset of parameters per inference step to control inference cost. MoE also introduces new engineering challenges in training stability, load balancing, and expert parallelism.

5. A Rational Comparison of the Two Paths

Dimension	Post-Training Scaling	New Base Model
Iteration cycle	Short: weeks to months	Long: measured in quarters
Compute structure	Concentrated in sampling and RL training	Concentrated in pretraining
Capability ceiling	Constrained by base model potential	Higher theoretical ceiling
Main risks	Reward hacking, entropy collapse, capability imbalance	Data and stability issues, high rework cost
Ecosystem compatibility	Fully reuses existing inference and tooling	Requires re-adaptation and optimization
Best-fit stage	Highest ROI when base model potential is not exhausted	Necessary when task complexity exceeds base model limits

More importantly, the two paths are not opposing doctrines. They are relay stages in the same iteration flywheel. In the first several releases after a base model ships, post-training scaling offers the highest return on investment. When post-training gains plateau and failure cases point to insufficient base model capability rather than insufficient activation, it is time to start a new base model.

Evaluation can inform this decision. Analyze failure trajectories. If errors concentrate on factual mistakes, long-context attention loss, or other base-model-level issues, a new base model is warranted. If failures concentrate on planning inconsistency, immature tool use, or other policy-level issues, continue investing in post-training.

6. Practical Recommendations for Developers and Enterprises

1. Evaluate long-horizon success rate rather than single-turn scores. Build task-chain evaluation sets that reflect real business workflows. Give the model a defect ticket from a real repository and measure end-to-end fix rate, average number of interaction turns, and regression test pass rate. This reflects engineering reality better than single-turn code completion scores.
2. When building your own post-training loop, prioritize environments and rewards. Environment quality determines the training ceiling. Tasks should come from real workflows, verification should be automated, and difficulty should be graduated. It is better to have reward signals with high confidence but narrow coverage than broad coverage with low confidence.
3. Use cloud infrastructure to reduce experimentation costs. Training and evaluation involve massive sampling, storage, and scheduling. Managed model services, container compute, object storage, logging, and monitoring can be used to connect environment sandboxes, trajectory storage, and metric dashboards into an automated pipeline, allowing the team to focus on environment design and reward engineering.
4. Maintain version governance across base models and post-training runs. Record the base model snapshot, environment pool version, and hyperparameter configuration for every post-training version. This ensures reproducibility and traceability when problems arise.

7. Conclusion

Pretraining determines the distribution of potential; post-training determines the realization of that potential. Squeezing an existing base model tests an engineering team’s precision in environment design, reward modeling, and training stability. Training a new base model tests a team’s command of data, compute, and patience. For observers, the more useful question than “whose benchmark score is higher” is whether a team understands where each gain comes from and where the next unit of investment should go. For practitioners, the answer is the same: first diagnose whether the capability bottleneck lies in the base model or in its activation, then decide whether to squeeze or rebuild, so that every unit of compute is spent on the real constraint.