Open-Weights Model Jumps to Fourth on Global Intelligence Index: How Large-Scale RL Drives a New Capability Paradigm

1. Background: The Gap Between Open-Weights and Closed-Source Models Is Being Redefined

For the past two years, capability competition among large models has centered on the closed-source camp. With ample compute budgets, proprietary training data, and complete product loops, closed-source models have long held the lead in general reasoning, code generation, and agentic tasks. Open-weights models iterated quickly but often lagged by a body length in comprehensive evaluations, with gaps at times reaching double-digit score margins.

That landscape is changing. A recent third-party comprehensive evaluation shows an open-weights model scoring 55 on the intelligence index—an 11-point improvement over its previous generation and fourth place globally. Once its weights are released, it will become the highest-scoring open-weights model, and the intelligence-index gap between open-weights and closed-source models narrows from 12 points to 3. Behind this shift is not simple parameter stacking but a capability leap driven by large-scale reinforcement learning compute investment in the post-training stage.

For developers and enterprise technical decision-makers, this means two things: first, open-weights models now have the capability foundation to take on complex production tasks; second, model selection criteria need to shift from “parameter count and benchmark scores” to “post-training strategy, context engineering, and agentic capability.”

2. Technical Path: Why “Large-Scale Reinforcement Learning”

2.1 Pretraining Sets the Floor, Post-Training Sets the Ceiling

The training pipeline for mainstream large models typically has three stages: pretraining, supervised fine-tuning (SFT), and reinforcement learning from human feedback or verifiable rewards (RLHF / RLVR). Pretraining gives the model its foundation of language understanding and world knowledge, but it often performs inconsistently on instruction following, long-horizon reasoning, and tool calling. The role of post-training is precisely to convert these “latent capabilities” into “capabilities that can be reliably invoked.”

Traditional post-training is constrained by compute budgets, so RL sampling scale, task coverage, and training rounds are relatively limited, and models tend to overfit on a small set of tasks with insufficient generalization. The core of this capability improvement lies in substantially increasing post-training RL compute and conducting large-scale joint training across hundreds of downstream domains.

2.2 Key Mechanisms of Large-Scale Joint Training

“Joint training” here means mixing training signals from different domains and task formats under the same RL framework, so the model optimizes simultaneously across diverse reward environments. Key engineering considerations include:

• Task pool construction: Cover hundreds of downstream domains—code, math, knowledge QA, tool calling, multi-turn dialogue—with a verifiable reward function defined for each domain.
• Reward modeling and verification: Use rule-based rewards for automatically verifiable tasks (e.g., code passing unit tests, math answers matching), and reward-model scoring for open-ended tasks, while controlling reward noise.
• Sampling efficiency optimization: RL is extremely sensitive to sampling throughput. Optimizations such as batch scheduling on the inference side, KV cache reuse, and parallel sampling are needed to complete large-scale training within limited compute.
• Stability control: Long-horizon RL training is prone to reward hacking and policy collapse, requiring KL constraints, reward normalization, and curriculum learning to maintain stability.

# Illustration: joint training task sampling and reward computation flow (pseudocode)
def rl_step(policy, task_pool, batch_size):
    tasks = sample_tasks(task_pool, batch_size)          # multi-domain task sampling
    rollouts = policy.generate(tasks, max_tokens=8192)   # parallel trajectory sampling
    rewards = []
    for task, traj in zip(tasks, rollouts):
        if task.verifiable:
            rewards.append(rule_reward(task, traj))      # rule-verifiable reward
        else:
            rewards.append(reward_model.score(task, traj))  # model-scored reward
    rewards = normalize(rewards)                          # reward normalization
    loss = policy_gradient(policy, rollouts, rewards)     # policy gradient
    loss += kl_penalty(policy, ref_policy)                # KL constraint against drift
    return loss

The direct benefit of this training paradigm: the model reaches or approaches the level of the strongest closed-source models on code, agent, and knowledge benchmarks, with the most significant gains in Agent capabilities.

3. Capability Structure: 3 Trillion Parameters + 1M Context

3.1 Parameter Scale and Sparsity

The model uses a 3-trillion-parameter scale. Note that very large models typically rely on sparse activation architectures (such as Mixture of Experts, MoE), activating only part of the parameters at inference to control per-inference cost while maintaining capability. For enterprise deployment, this means memory footprint and throughput should be planned based on activated parameters rather than total parameters.

3.2 What a 1M-Token Context Means

Supporting a 1M-token context does more than “fit longer documents”—it changes application architecture:

• Long-document understanding: Complete code repositories, contracts, and technical manuals can be fed directly as input, reducing the engineering complexity of chunking and retrieval.
• Long-horizon agentic tasks: Agents accumulate large historical trajectories across multi-turn tool calls; long context lets the model maintain task state within a single session and reduces information loss.
• Context cache reuse: Combined with prefix caching, repeated long system prompts can be reused, significantly reducing latency and cost in long-context scenarios.

A caveat: long context does not equal “effective use of long context.” In engineering practice, retrieval augmentation, context compression, and placing key information at the top are still needed to ensure stable attention allocation under extremely long inputs.

4. Agent Capabilities: From “Can Answer” to “Can Do”

Agent capability is the most significantly improved direction and the key threshold for open-weights models entering production environments. Agent capability can generally be broken down into the following:

1. Tool calling: Correctly selecting tools, constructing valid parameters, and parsing returned results.
2. Multi-step planning: Decomposing complex goals into executable subtasks and replanning on failure.
3. State management: Maintaining task context across long trajectories and avoiding goal drift.
4. Error recovery: Identifying tool errors and parameter errors and self-correcting.

Large-scale RL improves Agent capability markedly because agentic tasks are naturally suited to RL: task success is verifiable (e.g., whether code runs, whether an API call returns the expected result), reward signals are clear, and training environments can generate in parallel at scale. Compared with static supervised fine-tuning data, RL lets the model learn genuine task-execution strategies through a loop of “trial—feedback—correction.”

5. Practical Implications for Developers

5.1 Don’t Evaluate Models by Total Score Alone

The intelligence index is a composite metric, but different businesses weight capability dimensions very differently. When selecting models, break down evaluation by business scenario:

Scenario	Key capabilities	Evaluation method
Code assistant	Code generation, debugging, cross-file understanding	Pass rate on private repository tasks
Agent workflows	Tool calling, multi-step planning	End-to-end task success rate
Knowledge QA	Factual accuracy, citation reliability	Manual spot checks + hallucination rate
Long-document processing	Long-context recall	Key-information localization accuracy

5.2 Deployment Value of Open Weights

The core advantages of open-weights models lie in controllability and cost structure: private deployment to meet data compliance requirements; continued post-training for vertical domains; inference costs independent of external API pricing. But this also means teams must shoulder engineering responsibilities such as inference optimization, memory planning, and version management. Common implementation paths include:

• Using a container platform to manage inference services uniformly, with monitoring and alerting on latency and GPU memory levels;
• Using object storage to host model weights and evaluation datasets for version traceability;
• Using log services to collect agent trajectories for failure-case analysis and subsequent fine-tuning.

# Illustration: inference service deployment essentials (generic config structure)
service:
  model_path: /models/open-weights
  max_context: 1000000
  prefix_cache: true          # prefix cache reuse to lower long-context cost
  tensor_parallel: 8
  max_batch_tokens: 32768
monitoring:
  metrics: [latency_p99, gpu_mem_used, tokens_per_sec]
  alert: on_error_rate > 0.05

5.3 Post-Training Capability Moves Downstream

Once open-weights models have a foundation approaching closed-source models, competition shifts to “who can tune the model more closely to their business with private data.” This means teams need to build their own post-training capabilities: task definition, reward design, evaluation set construction, and training stability tuning. Large-scale RL is no longer exclusive to a few organizations; it will gradually become a standard capability for mid-size and large teams.

6. Conclusion

An open-weights model rising to fourth on the global intelligence index and narrowing the gap with closed-source models to 3 points marks a new stage in capability competition: pretraining scale is no longer the only variable; post-training RL compute investment and task design are becoming the main engine of capability leaps. With 3-trillion-scale parameters, 1M context, and significantly improved agent capabilities, open-weights models are approaching the strongest closed-source level in comprehensive capability for the first time.

For developers, the pragmatic strategy today is: break down evaluation dimensions by business scenario, validate early how open-weights models actually perform on agentic and long-context tasks, and build private-data post-training and evaluation capabilities in parallel. The capability gap between models is narrowing, and the engineering gap is becoming the new dividing line.