The Second Growth Curve of Trillion-Parameter Models: How Post-Training Unlocks General Reasoning Potential

1. An Ongoing Paradigm Shift

Over the past few years, the capability growth of large models has been almost strictly positively correlated with pre-training scale: more parameters, more data, and more compute equated to stronger models. However, this curve is approaching both physical and economic boundaries—high-quality corpora is dwindling, single pre-training runs have become prohibitively expensive for all but a few teams, and marginal returns are diminishing.

A recent upgrade path of a flagship model provided a representative signal: it reused a base model released months prior without conducting a larger-scale pre-training run, yet it achieved the strongest comprehensive capabilities in its series to date. It supports million-token contexts, features native visual understanding, and has made significant progress in real-world terminal programming, financial document analysis, and 3D modeling tasks.

The core variable behind this is singular: scaled investment in post-training compute, along with the expansion of reinforcement learning (RL) to hundreds of downstream domains. In other words, model capability improvement increasingly relies on repeated trials and feedback in real-world tasks, rather than simply “feeding more data.”

2. Why Post-Training is Becoming More Cost-Effective Than Pre-Training

To understand this shift, we must first clarify the division of labor between pre-training and post-training.

Pre-training addresses the “compression of world knowledge” problem: it compresses statistical patterns from massive amounts of text, code, and image-text data into parameters, endowing the model with general language understanding and generation capabilities. The output is a base model that “knows a little about everything, but not enough to be an expert.”

Post-training addresses “behavioral alignment and capability elicitation”: through supervised fine-tuning, reinforcement learning, and preference optimization, it teaches the base model how to think, act, and self-correct in specific tasks. The output is a usable system that knows which knowledge to invoke and which steps to execute in specific scenarios.

The key insight is that trillion-parameter base models already possess sufficient knowledge capacity and reasoning potential. The bottleneck is not “whether the model knows,” but “whether it knows how to use it.” Post-training is precisely the process that translates latent capabilities into explicit behaviors, offering a significantly higher ROI than training an even larger base model.

From an engineering perspective, this path offers three practical advantages:

• Cost control: Post-training compute is typically one to two orders of magnitude lower than pre-training, allowing for higher iteration frequency.
• Risk management: The base model remains unchanged, keeping capability boundaries stable and avoiding unpredictable regressions that a new pre-training run might introduce.
• Fast feedback loops: Models can continuously collect data based on real-world task distributions and optimize accordingly, forming a “deploy—feedback—retrain” flywheel.

3. Scaling RL to Hundreds of Downstream Domains: Engineering Implications

“Scaling RL to hundreds of downstream domains” sounds abstract, but in engineering terms, it requires a highly complex system design. We can break it down into four layers.

3.1 Task Space Construction

RL requires four elements: environment, state, action, and reward. For a general model, the “environment” consists of various real-world tasks: writing code, calling tools, analyzing documents, operating 3D software, and executing multi-step engineering workflows. Scaling to hundreds of domains first requires standardizing these tasks into reproducible, scorable environments.

A typical construction approach looks like this:

# Pseudo-code: Task environment registry and sampling
class TaskEnv:
    def reset(self) -> State: ...
    def step(self, action) -> tuple[State, Reward, Done]: ...
    def verify(self, state, action) -> bool: ...   # Verifiable reward
TASK_REGISTRY = {
    "code_terminal": TerminalEnv,
    "doc_analysis":   DocumentQAEnv,
    "3d_modeling":    BlenderLikeEnv,
    "tool_use":       ToolCallEnv,
    # ... hundreds of domains
}
def sample_batch(n):
    domains = weighted_sample(TASK_REGISTRY.keys(), n)
    return [TASK_REGISTRY[d]() for d in domains]

The core challenge here is not “whether it can run,” but whether the reward signal is reliable. Code tasks can use unit tests and terminal execution results as verifiable rewards; document analysis can use standard answer comparisons. However, open-ended tasks like 3D modeling and multi-step engineering often require composite rewards (intermediate checkpoints + final product evaluation + process constraints).

3.2 Reward Design and Credit Assignment

In long-horizon tasks, the final reward is sparse, making it difficult for the model to know which step was executed correctly. A common practice is to introduce Process Reward Models (PRMs) or hierarchical rewards:

• Coarse-grained: Whether the task is completed and the output is usable;
• Medium-grained: Whether key intermediate steps are correct (e.g., code compiles, function signatures match);
• Fine-grained: Whether the reasoning chain is self-consistent and tool calls are reasonable.

Credit assignment relies on the RL algorithm itself (e.g., policy gradient methods with advantage estimation) and trajectory sampling strategies. For tasks with million-token contexts, handling truncation, segmentation, and advantage backpropagation for ultra-long trajectories is also necessary.

3.3 Training Framework and Sandbox Scheduling

This is often the most underestimated component. RL across hundreds of domains means hundreds of execution environments involving code execution, browser operations, graphics software calls, and file system I/O. To run these concurrently while ensuring secure isolation, you need:

• Sandbox environments: Each rollout executes in an isolated container with restricted network, file system, and resource limits;
• Task scheduling system: Dynamically allocates compute based on domain, priority, and resource requirements to prevent long-tail tasks from degrading overall throughput;
• State snapshot and recovery: Supports resuming from interruptions, preventing long tasks from restarting entirely due to a single point of failure;
• Observability: Logs every action, reward, and exception for subsequent data analysis and reward model iteration.

A simplified scheduling illustration:

def rollout_worker(task, policy, sandbox_pool):
    env = task.make_env()
    state = env.reset()
    trajectory = []
    while not env.done:
        action = policy.act(state)
        with sandbox_pool.acquire() as sbx:
            next_state, reward, done = sbx.execute(env, action)
        trajectory.append((state, action, reward))
        state = next_state
    return trajectory

3.4 Long-Context Inference Optimization

Million-token contexts combined with multi-step tasks impose stringent requirements on the inference system: KV Cache memory footprint, attention computational complexity, and cross-step state reuse. Engineering solutions typically combine paged attention, sparsification, state compression, and incremental inference to reduce overhead, making long-trajectory RL feasible at an acceptable cost.

4. Three Typical Directions for Capability Improvement

Based on publicly available evaluation dimensions, the capability improvements brought by scaled post-training are concentrated in three types of tasks—precisely the areas most critical for enterprise applications.

4.1 Real-World Terminal Programming

Unlike algorithm-puzzle-style code generation, terminal programming tasks require the model to complete a full workflow in a real shell environment: file operations, dependency installation, debugging, and test verification. This tests the combined capabilities of long-horizon planning + tool calling + error recovery.

Evaluations for these tasks typically use “task completion rate” as the metric—whether the model can bring the target environment to the expected state within a limited number of steps. The improvement path relies primarily on RL using massive real-world terminal trajectories, allowing the model to learn a “explore first, verify next, converge last” workflow.

4.2 Agents and Tool Calling

The core of an agent is the “perception—decision—execution—feedback” loop. During the post-training phase, the model must learn to:

• Distinguish when to answer directly and when to call a tool;
• Select the correct tool and parameters;
• Handle exceptions or empty results returned by tools;
• Maintain goal consistency across multi-turn interactions.

This capability heavily depends on RL in real tool environments, rather than static dataset fine-tuning.

4.3 Domain-Specific Knowledge Work

Tasks like financial document analysis, legal clause comparison, and technical manual comprehension require the model to locate key information in long documents, perform cross-paragraph reasoning, and output structured conclusions. Million-token context capabilities allow the model to ingest an entire document at once, while RL trains it to “read the document with the question in mind” rather than “reading everything and guessing the question afterward.”

5. Implications for Developers and Enterprises

This technical path offers three direct insights for practical work.

First, do not evaluate solely on parameter count. A sufficiently post-trained trillion-parameter model can significantly outperform a larger but under-trained model on specific tasks. During evaluation, prioritize real-world task completion rates for your target scenarios over general leaderboard scores.

Second, your post-training data is your moat. If an enterprise has massive real-world business trajectories (support tickets, code commits, operation logs, review records), this data is the most valuable fuel for reinforcement learning. The ability to construct verifiable reward signals determines whether you can translate this data into model capability.

Third, use long context in conjunction with task design. A million-token context is not about “stuffing as much as possible,” but about providing complete context for long documents and multi-step tasks. In practice, combine techniques like retrieval, chunking, and state summarization to prevent irrelevant context from diluting the model’s attention.

6. Conclusion

The trillion-parameter base model provides the capability ceiling, but post-training determines how much of that ceiling can be realized. As marginal returns from pre-training diminish, scaled RL + real-world task feedback loops are becoming the second growth curve for model capabilities.

For developers, this implies two things: first, stronger general capabilities can be obtained at a lower cost; second, if you possess high-quality task data, you have the opportunity to build truly differentiated capabilities on top of general models. The improvement of model capabilities is shifting from “training larger models” to “letting models learn through repeated trials and feedback in real tasks”—and this is perhaps the most significant shift to watch in the current wave of technological evolution.