MiniMax M2.7: The Model That Ran Its Own RL Experiments and Got 30% Better Without a Human Touching the Code

# MiniMax M2.7 architectural components
# Source: reconstructed from NVIDIA technical blog + arXiv:2501.08313 (MiniMax-01 predecessor)
# + MiniMax M2.1 post-training blog

import torch
import torch.nn as nn
import torch.nn.functional as F

class QKRMSNorm(nn.Module):
    """
    Query-Key Root Mean Square Normalization.
    Applied to Q and K before attention score computation.

    ← WHY: at long context (200K tokens), raw attention logits QK^T/sqrt(d_k)
      grow large because Q and K vectors can have large norms.
      Large logits → softmax becomes peaky/saturated → attention collapses to
      attending to a few tokens regardless of content.

    ← QK RMSNorm normalizes Q and K before the dot product:
      attention logits become bounded → training stable at 200K+ context.
      This is cheaper than full LayerNorm and more numerically stable than
      clipping attention logits.

    ← Why RMS and not full LayerNorm?
      RMSNorm: divides by root mean square, no mean subtraction.
      Empirically matches LayerNorm quality at lower compute cost.
    """
    def __init__(self, dim: int, eps: float = 1e-8):
        super().__init__()
        self.scale = nn.Parameter(torch.ones(dim))
        self.eps = eps

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # x: [batch, heads, seq_len, head_dim]
        rms = x.pow(2).mean(-1, keepdim=True).sqrt() + self.eps
        return self.scale * (x / rms)


class MoEFFNLayer(nn.Module):
    """
    Mixture-of-Experts Feed-Forward Network.
    256 expert FFNs total, top-k active per token.

    ← WHY 256 experts (not 8 or 32)?
      More experts = more parameter capacity without proportional inference cost.
      Each expert can specialize in different token patterns/domains.
      Trade-off: routing becomes more complex, load balancing harder.

    ← WHY top-k routing (not learned gating)?
      Top-k guarantees exactly k experts per token → predictable compute per step.
      Predictable compute is critical for efficient distributed training scheduling.
    """
    def __init__(
        self,
        hidden_dim: int,
        expert_dim: int,
        num_experts: int = 256,
        top_k: int = 2,           # ← only 2 of 256 experts run per token
    ):
        super().__init__()
        self.num_experts = num_experts
        self.top_k = top_k

        # Router: maps each token to a probability distribution over experts
        self.router = nn.Linear(hidden_dim, num_experts, bias=False)

        # Expert FFNs: all 256 exist in memory, only top_k compute per token
        # ← This is why parameters >> active compute: 256 experts in memory,
        #   only 2 activated → 128x parameter efficiency ratio
        self.experts = nn.ModuleList([
            nn.Sequential(
                nn.Linear(hidden_dim, expert_dim, bias=False),
                nn.SiLU(),
                nn.Linear(expert_dim, hidden_dim, bias=False),
            )
            for _ in range(num_experts)
        ])

        # Auxiliary loss weight for expert load balancing
        # ← MiniMax decreased this coefficient from M1 to M2:
        #   Lower aux_loss_coeff → less regularization pressure on routing
        #   → experts can specialize more → better performance
        #   → risk: some experts become underutilized (solved by monitoring)
        self.aux_loss_coeff = 0.001

    def forward(self, x: torch.Tensor) -> tuple[torch.Tensor, torch.Tensor]:
        # x: [batch * seq_len, hidden_dim]
        batch_seq, hidden_dim = x.shape

        # Step 1: compute routing logits and select top-k experts per token
        logits = self.router(x)                              # [B*S, num_experts]
        scores, indices = torch.topk(logits, self.top_k, dim=-1)  # [B*S, top_k]
        scores = F.softmax(scores, dim=-1)                   # normalize weights

        # Step 2: compute auxiliary loss (load balancing)
        # ← Without this, all tokens might route to the same few experts
        # ← Measures deviation from uniform expert utilization
        router_probs = torch.softmax(logits, dim=-1)
        expert_usage = router_probs.mean(dim=0)  # average utilization per expert
        aux_loss = self.aux_loss_coeff * (expert_usage * expert_usage).sum() * self.num_experts

        # Step 3: run top-k expert FFNs and combine weighted outputs
        output = torch.zeros_like(x)
        for k in range(self.top_k):
            expert_idx = indices[:, k]    # which expert for each token
            expert_weight = scores[:, k]  # routing weight for this expert

            # ← Only the selected expert runs for each token
            # In practice this uses scatter/gather operations for GPU efficiency
            for token_idx in range(batch_seq):
                eid = expert_idx[token_idx].item()
                expert_out = self.experts[eid](x[token_idx].unsqueeze(0))
                output[token_idx] += expert_weight[token_idx] * expert_out.squeeze(0)

        return output, aux_loss

# MiniMax M2.7 self-evolution loop (reconstructed from blog description)
# Source: minimax.io/news/minimax-m27-en + github.com/MiniMax-AI/MiniMax-M2.7
# The loop that ran 100+ rounds and achieved 30% improvement

import json
from typing import Callable

class SelfEvolutionLoop:
    """
    The autonomous scaffold optimization loop that built M2.7.

    M2.7 is the first MiniMax model that "deeply participated in its own evolution."
    This loop ran over 100 rounds fully autonomously:
    analyze failure → plan → modify → evaluate → keep/revert → repeat

    ← THIS is the architectural innovation: the model is not just a tool
      in the pipeline; it is an agent WITHIN the pipeline that modifies
      the pipeline itself.

    ← What gets modified: scaffold code (the agent harness that orchestrates
      RL experiments), sampling parameters (temperature, frequency penalty,
      presence penalty), workflow guidelines for the model, loop detection,
      memory mechanisms.

    ← What stays fixed: model weights (this is NOT online RL during deployment.
      The model modifies the SCAFFOLDING, not its own parameters, within each loop.
      Model weight updates happen via standard RL training on the improved data
      produced by the optimized scaffold.)
    """

    def __init__(
        self,
        model,                    # M2.7 instance (the agent doing the optimization)
        eval_fn: Callable,        # evaluation function on internal benchmark
        scaffold_code: str,       # the current agent harness code
        max_rounds: int = 100,
    ):
        self.model = model
        self.eval_fn = eval_fn
        self.scaffold_code = scaffold_code
        self.max_rounds = max_rounds
        self.history = []

    def run(self) -> dict:
        """
        Execute the self-evolution loop.
        Returns: best scaffold code + final performance metrics.
        """
        baseline_score = self.eval_fn(self.scaffold_code)
        best_score = baseline_score
        best_scaffold = self.scaffold_code

        for round_num in range(self.max_rounds):
            # Step 1: Analyze failure trajectories from recent evaluations
            # ← M2.7 reads evaluation logs and identifies failure patterns
            failure_analysis = self.model.analyze(
                prompt=f"""
                Review these evaluation results and failure trajectories:
                {self._get_recent_failures()}

                Identify: (1) what the scaffold does wrong, (2) what patterns
                appear in failures, (3) what specific change would most likely
                improve performance.

                Return: analysis in JSON format.
                """,
                output_format="json",
            )

            # Step 2: Plan changes to the scaffold
            change_plan = self.model.plan(
                failure_analysis=failure_analysis,
                current_scaffold=self.scaffold_code,
            )
            # ← Specific changes discovered autonomously by M2.7:
            #   - systematically search for same bug patterns in other files
            #   - optimize sampling parameters (temperature, frequency penalty)
            #   - add loop detection to the agent loop
            #   - design more specific workflow guidelines

            # Step 3: Modify scaffold code
            modified_scaffold = self.model.modify_code(
                original=self.scaffold_code,
                change_plan=change_plan,
            )

            # Step 4: Evaluate the modified scaffold
            new_score = self.eval_fn(modified_scaffold)

            # Step 5: Decide to keep or revert (simple threshold)
            # ← THIS is the trick: conservative acceptance criterion
            # Keep only if improvement is real (not noise)
            if new_score > best_score + 0.01:  # 1% minimum improvement threshold
                best_score = new_score
                best_scaffold = modified_scaffold
                self.scaffold_code = modified_scaffold  # update current state
                print(f"Round {round_num}: KEPT +{new_score - baseline_score:.2%}")
            else:
                print(f"Round {round_num}: REVERTED (no significant improvement)")

            self.history.append({
                "round": round_num,
                "score": new_score,
                "kept": new_score > best_score,
                "change": change_plan,
            })

        return {
            "best_scaffold": best_scaffold,
            "baseline_score": baseline_score,
            "final_score": best_score,
            "improvement": (best_score - baseline_score) / baseline_score,
            # ← Actual result: 30% improvement on internal evaluation set
        }

Researcher: "The training run for experiment exp_2024_0315 has been failing
for 6 hours. Loss is NaN starting at step 4,200. Please investigate and fix."

Step 1: Log ingestion and analysis
  Agent reads: training logs (200K tokens of CUDA output, loss curves,
               gradient norms, system metrics)
  ← 200K context window critical here: cannot fit 6 hours of training logs
    into a shorter context. Agent reads the raw logs, not a summary.

  Agent output: "Gradient norm spike at step 4,187 → NaN at step 4,200.
                Correlates with batch containing unusual sequence lengths.
                Root cause hypothesis: numerical overflow in attention computation
                with long sequences in this batch."

Step 2: Verification
  Agent: queries training database for the specific batch at step 4,187
  Agent: retrieves sequence length distribution → confirms 3 sequences > 128K tokens
  Agent: cross-checks with QK RMSNorm logs → normalization not applied to these
         sequences (bug in preprocessing pipeline)

Step 3: Fix
  Agent: generates code patch for preprocessing pipeline
  Agent: creates merge request with test coverage
  Agent: runs smoke test on subset → passes

Step 4: Restart
  Agent: restarts training from checkpoint at step 4,150
  Agent: monitors for 30 minutes → stable

Total time: under 3 minutes (documented as achieved in production)
Human involvement: zero until researcher reviews the merge request

22 ML competitions from Kaggle, real data science tasks
M2.7 medal rate: 66.6%

Ranking:
  1. Opus-4.6:    ~72% medal rate
  2. MiniMax M2.7: 66.6% medal rate   ← #2 globally
  3. GPT-5.4:     ~64% medal rate (approximate)

← This is the hardest external validation of M2.7's agentic capability.
   ML competitions require: data exploration, feature engineering, model
   selection, hyperparameter tuning, ensembling, and submission formatting.
   All autonomously in a time-limited environment with real data.

M2.7 ELO: 1495
Status: Highest among open-source models
← Includes complex Excel editing, PPT creation, multi-round Word revisions
← 97% skill adherence rate with 40+ complex skills each >2,000 tokens