DocsQuick StartAI News
AI NewsXiaomi Livestreams the Costly Training of MiMo-V2.6
New Model

Xiaomi Livestreams the Costly Training of MiMo-V2.6

2026-09-17T06:07:12.164Z
Xiaomi Livestreams the Costly Training of MiMo-V2.6

Xiaomi has made public the MiMo-V2.6 reinforcement learning training setup, processing approximately 2 billion tokens per step while simultaneously scaling up tool environments and grader capacity. More noteworthy than whether the model reaches the top is that reinforcement learning is evolving from simply adding GPUs into a complex systems engineering discipline.

Xiaomi has put MiMo-V2.6—before its reinforcement learning training is even complete—directly onto a live-streaming page.

On September 17, Luo Fuli, head of Xiaomi’s MiMo foundation model team, revealed that after open-sourcing MiMo-V2.5 in April this year, the team had spent nearly six months investigating one question: How far can reinforcement learning for foundation models ultimately scale? MiMo-V2.6 is currently still in the middle of reinforcement learning training. Training has not yet finished, and no official model weights, API, technical report, or complete evaluation results have been released.

This was not a conventional product launch. Xiaomi publicly displayed the reward curve, training progress, compute consumption, and even GPU failures, while also disclosing several highly aggressive training figures: each training step processes approximately 2 billion tokens, with 1,568 prompts each generating 16 rollouts, and the entire system operating fully asynchronously. As of the disclosure, cumulative training costs had already exceeded $1.25 million, equivalent to approximately RMB 8.4 million.

In other words, MiMo-V2.6 has not yet handed in its exam paper, but Xiaomi has already released the exam-room surveillance footage.

Xiaomi MiMo-V2.6 reinforcement learning live-streaming page, showing the reward curve, training steps, token consumption, and cumulative cost

What Is Being Scaled This Time Is Not a Single Number, but Three Systems

When discussing foundation model scaling in the past, the industry was most familiar with pretraining scale: more parameters, more data, and more GPUs. At the reinforcement learning stage, however, simply increasing compute does not necessarily produce a better model. A model can generate vast numbers of trajectories, but if the task environments are homogeneous and the reward signals are crude, the additional compute may merely mass-produce low-value samples.

The focus of MiMo-V2.6’s public demonstration is the simultaneous scaling of three dimensions:

  1. Compute scale: approximately 2 billion tokens per step, 1,568 prompts, and 16 rollouts generated for each prompt;
  2. Environments and tools: multiple agent task frameworks and tool environments mixed within a single training run;
  3. Grader Compute: increasing compute not only for the model responsible for answering questions, but also for the systems responsible for scoring, verification, and credit assignment.

The first two are relatively easy to understand. The model attempts more paths for the same problem while entering browsers, code repositories, terminals, or other interactive environments to complete tasks. The third is the most noteworthy change this time: the grader is becoming a first-class citizen in the training system.

This means that competition in post-training is shifting from “who can sample more answers” to “who can determine more accurately which actions are genuinely effective.”

What Makes 2 Billion Tokens per Step So Large?

According to the configuration disclosed by Xiaomi, each step includes:

  • 1,568 prompts;
  • 16 rollouts for each prompt;
  • Approximately 25,088 complete or partial agent trajectories in total;
  • A total processing volume of approximately 2 billion tokens.

A rough average works out to around 80,000 tokens processed per trajectory. This figure should not be interpreted as the model outputting 80,000 tokens all at once, because the training statistics may also include context, reasoning processes, tool outputs, environment states, multi-turn interactions, and other system overhead. Even so, it is enough to show that MiMo-V2.6 is not dealing with traditional reinforcement learning for math problems with short answers, but with agent tasks involving long contexts, many steps, and repeated tool calls.

A single coding-agent trajectory might involve reading a repository, searching for symbols, modifying multiple files, running tests, identifying the cause of failures, making further changes, and ultimately submitting a patch. A browsing agent might open multiple pages in succession, cross-check information, handle failed requests, and then formulate an answer. These training samples are not sets of static questions and answers; they are more like complete recordings of operational workflows.

The significance of 2 billion tokens, therefore, is not merely “large volume.” It requires the training system to simultaneously handle environment scheduling, long-sequence reasoning, tool execution, fault recovery, sample filtering, parameter updates, and more. If throughput is insufficient at any stage, GPUs may sit idle while waiting for the environment to return results. If any stage is unstable, an entire batch of expensive rollouts may have to be discarded.

Full Asynchrony Solves the Traffic-Jam Problem in Agent Training

Xiaomi specifically emphasized that MiMo-V2.6 uses fully asynchronous training. This is not an inconsequential engineering footnote.

Traditional synchronous reinforcement learning is like a convoy that must depart and arrive together. Most tasks in a batch may finish quickly, but as long as a few environments respond slowly, tool calls time out, or generated sequences become too long, the entire batch must wait for the slowest task. Agent training is more prone to this kind of long tail than pure-text training: some tasks finish in seconds, some require compiling large projects, and others may become stuck because of web pages, containers, or GPU failures.

An asynchronous system allows completed trajectories to proceed to subsequent computation without waiting for all tasks to align. This can significantly improve the utilization of GPUs and environment clusters, while also making it better suited to mixing different types of task frameworks.

The trade-offs are equally apparent. The more asynchronous the system becomes, the harder it is to maintain strict consistency between the policy version that generated a rollout and the number of updates the model has undergone by the time the data is used for training. Feeding data generated by an older policy into a newer policy’s training introduces policy staleness. Differences in task completion times may also cause the training data distribution to be dominated by faster tasks.

Thus, “fully asynchronous” is not simply a configuration option that can be switched on. It requires the team to handle version tracking, sampling weights, data replay, load balancing, and anomalous-sample isolation. The GPU failures shown in the live stream actually demonstrate that the system is dealing with large-scale heterogeneous workloads under real operating conditions, rather than presenting a polished recording after the fact.

Scaling Environments Is Harder Than Adding Prompts

MiMo-V2.6’s second direction is multi-task agent reinforcement learning: mixing multiple frameworks, environments, and tools within a single run.

This is not the same as combining different datasets for training. Static datasets generally require only a unified input-output format, whereas agent environments each have their own state machines and failure modes. Coding tasks require repositories, dependencies, compilers, and test suites. Browsing tasks require network environments and webpage interactions. Office tasks may involve file systems, spreadsheets, and document applications.

What the model needs to learn in these environments is not merely how to “call tools.” It must determine when to call them, which tool to select, how to interpret the returned results, and how to recover when execution fails. A genuinely useful agent often succeeds not through a single tool call, but by maintaining its objective across dozens of actions.

The benefit of mixed training across multiple environments is that it reduces the model’s overfitting to a single agent scaffold. A model that scores highly only within a fixed coding framework may perform significantly worse when moved to a Cursor- or Claude Code-style loop, or to a company’s proprietary toolchain. Mixing different frameworks into training is equivalent to repeatedly changing the model’s operating console, forcing it to learn more fundamental patterns of task planning and tool use.

But the more environments there are, the less comparable their rewards become. One task may earn an unambiguous score of 1 by passing all tests, while another web-based task can only be graded by degree of completion. Some tasks must be scored using a combination of models and rules. Determining how different tasks should contribute appropriate training signals is a harder problem than deploying more containers.

Grader Compute: Giving the Evaluators More Compute, Too

The most informative concept introduced this time is Grader Compute—the allocation of more computational resources to the scoring process itself.

For verifiable tasks, scoring may seem straightforward: Did the code pass the tests? Is the mathematical answer equivalent? Did the tool call accomplish its objective? But once a task becomes a long-chain agent workflow, the final result alone is not enough to determine the value of each individual step.

For example, suppose a coding agent makes ten changes and ultimately passes the tests. Which changes actually mattered? Did a particular search provide a crucial clue? Was a failed test an unproductive action, or a necessary intermediate step in identifying the problem? If the training system assigns only a single score to the entire trajectory at the end, the reward signal will be extremely sparse.

Xiaomi’s Agentic In-group Credit Assignment can be understood as performing finer-grained comparison and credit assignment among rollouts within the same group, while combining test cases and scoring criteria to allocate rewards. The 16 rollouts are not generated merely to select the highest-scoring answer. They can also serve as references for one another: Which steps repeatedly appear across successful paths? Which actions merely increase the trajectory length? Which trajectories appear to score highly but are actually exploiting loopholes in the tests?

This is also why graders need more compute. High-quality grading may involve:

  • Executing complete test suites rather than merely checking the final text;
  • Comparing multiple candidate trajectories within a group;
  • Verifying completion against each item in the scoring criteria;
  • Re-running tool calls to confirm that results are reproducible;
  • Using additional models to inspect intermediate steps;
  • Detecting reward hacking, test leakage, and false success.

In the past, graders were often treated as a rule at the end of the training pipeline. Now, they increasingly resemble a separate inference system. The model is responsible for exploration, while the grader is responsible for establishing reliable feedback. If the former scales rapidly while the latter falls behind, training ends up in a situation where “students keep practicing more problems while the grading standards keep getting worse.”

Our assessment is that Grader Compute is likely to become a key bottleneck in the next phase of reinforcement learning scaling. Rollout compute can be purchased, and tool environments can be expanded with more containers, but accurate, stable reward functions that are difficult for models to exploit remain a scarce asset.

Live-Streaming Training Is Valuable, but It Is Not Yet a Report Card

Making the training process public is, first and foremost, an experiment in transparency. Outsiders usually see only carefully selected benchmarks after a model is released. They rarely see fluctuating reward curves, hardware failures, and rising training costs in real time. By exposing these intermediate states, Xiaomi has at least shown developers that agent reinforcement learning is not a smoothly rising curve, but a complex system that continuously fails, recovers, and recalibrates.

The cumulative expenditure of more than $1.25 million is also eye-catching. Based on estimates of peak consumption mentioned in external reports, training costs can rise rapidly over a short period. However, the dollar figure alone does not mean much: different teams may or may not include GPU depreciation, cloud services, environment clusters, and failed tasks in their cost calculations, making direct comparisons inappropriate.

More importantly, training cost does not equal model capability. Large numbers of rollouts may improve exploration coverage, but they may also amplify reward bias. Increasing grader compute can improve feedback quality, but it may also teach the model to cater to a particular type of automated evaluator. Mixed training across multiple environments can help generalization, but if the task mix is unbalanced, the model may improve in some areas at the expense of others.

As of September 17, Xiaomi had still not disclosed the following critical information about MiMo-V2.6:

  • The base model’s total and active parameter counts;
  • Whether it continues the architectural design of MiMo-V2.5;
  • The context window and multimodal capabilities;
  • Details of the reinforcement learning algorithm, asynchronous strategy, and data replay;
  • Environment types, task mix, and reward normalization methods;
  • Directly comparable results against models from Claude, GPT, Gemini, DeepSeek, Kimi, Qwen, and others;
  • The specific scope of open-sourcing for the weights, inference code, and training framework.

Therefore, the most reasonable conclusion at present is not that “MiMo-V2.6 has already surpassed a particular model,” but that Xiaomi is validating a more systematic approach to agent reinforcement learning. Its ultimate capabilities must still be tested through the official model release, third-party evaluations, and real-world development scenarios.

MiMo-V2.6 Must Prove More Than Just That It Is Better at Solving Problems

The MiMo-V2.5 series had already focused on long-context, multimodal, and agent scenarios. Its flagship version uses a trillion-scale total parameter count, 42 billion active parameters, and a 1-million-token context window, with optimizations centered on software engineering and tool use. If MiMo-V2.6 merely improves a few static benchmark scores, its significance will be limited.

This round of training should truly answer three questions.

First, can cross-environment generalization be achieved? Will the tool-use strategies learned within the training framework remain effective when transferred to developers’ own agent scaffolds?

Second, can reliability on long-horizon tasks be improved? Succeeding at a single tool call is not difficult. The challenge is to avoid drifting away from the objective across dozens of consecutive steps, while recovering from compilation failures, webpage errors, and incorrect assumptions.

Third, do the benefits of large-scale reinforcement learning persist? A rising reward curve does not mean that real capabilities are improving proportionally. If the later stages of training merely optimize for grader preferences, the marginal returns from investing additional tokens will decline rapidly.

These three questions can be answered only through sufficiently open evaluations and technical details. Xiaomi says it will gradually open-source the relevant details over the coming weeks. When that happens, the environment construction methods, asynchronous training stability, in-group credit assignment mechanism, and the grader’s defenses against reward hacking will be more worthy of attention than the final leaderboard scores.

Reinforcement Learning Is Becoming a Competition “Beyond the Model”

The industry trend revealed by MiMo-V2.6 is clear: post-training scaling laws are shifting from a focus on compute alone toward the coordinated scaling of compute, environments, and verification.

The model itself remains important, but agent capabilities increasingly depend on systems beyond the model: where tasks come from, whether tools are stable, whether environments can be reproduced, whether tests cover the actual objective, whether graders can identify false success, and whether failed trajectories can be converted into useful signals. In the future, the gap between teams may not be reflected solely in parameter counts, but also in who possesses more realistic task environments, more reliable automated verification, and higher-throughput training infrastructure.

From this perspective, Xiaomi’s live stream of MiMo-V2.6 training is more significant than a conventional product teaser. It brings to the forefront elements that the industry usually hides in the appendices of technical reports: model capabilities do not emerge solely from a single forward pass, but are jointly shaped by tens of thousands of parallel trajectories, complex tool environments, and expensive grading processes.

But a live stream is ultimately only the process, not the answer.

Whether MiMo-V2.6 is genuinely more capable will depend on whether, after training is complete, it can reliably perform work in unfamiliar code repositories, across different tool frameworks, and on long-horizon tasks. Xiaomi has already disclosed how many tokens and how many dollars it has burned. What it needs to disclose next is how much transferable and reproducible capability those costs have actually delivered.

References

Related Articles

View All

Contact Us

We usually reply quickly during business hours

Scan WeChat

Support: Hub Assistant

WeChat ID: