Xiaomi Releases HySparse2, Targeting Long-Horizon Reasoning for Agents

Xiaomi Reveals the Architecture First; MiMo-V3 Has Not Yet Been Officially Released

On September 24, Xiaomi’s MiMo team unveiled HySparse2, the core architecture for the next-generation MiMo-V3. It is not a new model that has already been made available for download, but a hybrid sparse-attention architecture redesigned for long-horizon, multi-turn Agent tasks.

Xiaomi’s direction is clear: less Prefill computation, a smaller KV Cache, and more precise long-context retrieval.

The focus of this update is not to keep expanding the context window from hundreds of thousands of tokens to a million tokens. Instead, it aims to solve a more practical problem: when an Agent continuously calls browser, search, code-execution, and file-parsing tools, how can the model truly “remember, find, and afford” the information it needs?

Based on the information disclosed so far, MiMo-V3 remains at the architecture-preview stage. Xiaomi has not released the complete model weights, parameter count, launch date, or official capability evaluations. Therefore, HySparse2 currently looks more like an infrastructure roadmap revealed in advance by the MiMo team than a complete model launch.

The Most Expensive Part of an Agent Is Not Outputting—It Is Reading History

In conventional chat scenarios, a model typically generates a few hundred tokens, and the input is relatively manageable. Agents work very differently: the model may generate only a single tool call, while the tool returns an entire webpage, a PDF dozens of pages long, a batch of code files, or tens of thousands of tokens of execution logs.

After each tool call, the model must reread the newly returned content and continue planning based on everything that has already happened. After several rounds, the context can rapidly expand from 8K or 32K to hundreds of thousands or even millions of tokens.

There are two costs that are easy to confuse here.

• Prefill cost: The model initially reads a segment of input and builds the Key-Value state needed for subsequent generation. The longer the input, the more tokens must be processed during Prefill, and the higher the computational load and latency generally are.
• KV Cache cost: The model stores the already processed context in GPU memory as a KV Cache and reuses it directly during subsequent generation. The longer the history, the larger the cache and the greater the memory pressure.

In multi-turn Agent tasks, the model’s output is often very short. What actually consumes computing power is the long input returned by tools. This workload can be understood as “Prefill-dominated”: the model is not spending most of its time writing answers, but continually reading new material and revisiting history.

This is why simply expanding the context window cannot solve the problem. A larger window only means that the model can theoretically accommodate more content. If the entire context is recomputed every round, costs will increase along with the context length. If history is discarded aggressively to save costs, the Agent may forget earlier decisions, miss critical evidence, or repeatedly call the same tools.

HySparse2 targets precisely this contradiction.

From Hybrid SWA to HySparse2, Xiaomi Continues to Refine the Attention Structure

Xiaomi previously used Hybrid SWA in the MiMo-V2 series, combining full attention with sliding-window attention.

Full attention allows each token to access a broad range of context, providing strong long-distance information integration, but it also incurs high computational and caching costs. Sliding-window attention focuses only on a local neighborhood, making it cheaper and suitable for most continuous text, but it may fail to see critical information from much earlier in the context.

The idea behind Hybrid SWA is to assign each type of attention a different role: a small number of layers handle broader information exchange, while the remaining layers use window constraints to control costs. It is similar to having a few researchers search an entire library while most researchers look only within the current chapter.

HySparse goes a step further. Public descriptions indicate that it combines one Full Attention layer with multiple Sparse Attention layers into a Hybrid Block. When processing the context, the Full Attention layer simultaneously generates the KV Cache and determines which tokens are important. The subsequent Sparse Attention layers no longer perform full-scale selection independently; instead, they reuse the important-token indices and cache already obtained earlier.

The advantage is that expensive global filtering does not need to be repeated at every layer. The model retains a pathway for accessing important long-distance information without requiring every layer to bear the full cost of global attention.

HySparse2 further upgrades the KV-sharing and sparse-selection mechanisms. According to the MiMo team, its key change is the introduction of a two-level KV-sharing mechanism, while reorganizing model computation around the Prefill and Decode stages.

Two-Level KV Sharing: The Core Idea Is to Run Only Half the Model During Prefill

To understand HySparse2, it is first necessary to distinguish between Prefill and Decode.

Prefill reads a new round of input into the model and builds the KV Cache used for subsequent generation. Decode then generates the output one token at a time based on the existing cache. Their computational characteristics differ: Prefill is more oriented toward large-batch matrix operations, while Decode is more constrained by GPU memory bandwidth and cache access.

In inference services, Prefill and Decode are increasingly being separated onto different nodes. The reason is simple: if Prefill for long inputs is mixed with token-by-token generation, an Agent that suddenly returns a large amount of webpage content could slow down generation requests from other users in the same batch.

HySparse2 takes advantage of this Prefill-Decode decoupling. According to the design disclosed by Xiaomi’s team, when building the KV Cache during the Prefill stage, only half of the model’s structure needs to run, while one Full Attention layer is retained to handle global information selection. Because the Prefill node does not need to host the complete model weights, deployment may also require less GPU memory and fewer node resources.

It is important to note that “running only half the model” does not mean the model’s capabilities are permanently cut in half, nor does it mean that half of the model parameters are simply deleted. It is closer to this: given the characteristics of the Prefill stage, only the computational paths needed to build the cache are activated and deployed; during the subsequent Decode stage, generation still follows the complete architecture.

The experimental results cited in related descriptions indicate that, in long-context tests at the million-token scale, HySparse2 reduced Prefill computation by approximately 5.02× and reduced the KV Cache by approximately 4.5×. Another disclosure states that Prefill nodes need to host only about half of the model weights. These figures are highly attractive for inference deployment, but they must ultimately be evaluated together with model size, hardware type, batch size, sequence length, and any loss in accuracy. They cannot be directly equated with a fivefold reduction in online costs.

In other words, HySparse2’s real value is not merely that it “runs fewer layers.” It turns the results of global information selection into a shareable resource, allowing multiple sparse-attention layers and different inference stages to avoid redundant work as much as possible.

It Addresses the Agent’s “Long-Range Memory,” Not Ordinary Long-Text Reading

Ordinary long-text question answering focuses on whether a model can find an answer within a fixed document. Long-horizon Agents face a much more chaotic history: webpage content, user constraints, tool outputs, failed attempts, intermediate code, environment states, and the model’s own plans appear in an alternating sequence.

The importance of this information is not uniform.

A tool-generated log may contain tens of thousands of tokens, while only a single error message actually affects the next decision. A webpage may contain extensive navigation and advertising, with only a few data points in one table being relevant to the task. In a code repository, the key clue may be hidden in a configuration file opened several rounds earlier.

If the model stores all KV states, GPU memory usage will quickly grow. If it stores only the most recent window, it can easily lose evidence from earlier rounds. HySparse2’s sparse-selection mechanism attempts to strike a balance between the two: preserving the continuous processing capability of local context while providing a stable access path to important long-distance tokens.

This is particularly meaningful for the following tasks:

1. Browser Agents: Continuously visit multiple pages and compare prices, specifications, policies, and cited sources.
2. Software-engineering Agents: Repeatedly read code, build logs, test results, and patch histories to locate cross-file problems.
3. Data-analysis Agents: Call SQL, Python, or spreadsheet tools over multiple rounds while retaining intermediate variables and anomaly information.
4. Research Agents: Gradually filter evidence from large numbers of papers, reports, and webpages before producing a final conclusion with citations.
5. Long-running automation tasks: Tasks that last for hours or longer, where historical state cannot simply be truncated as the context grows.

For these scenarios, retrieval accuracy is more important than context length alone. A model that can accommodate a million tokens but cannot reliably recover critical facts has limited practical value.

Xiaomi’s Assessment: Agent Reasoning Is Shifting from “Model Capability” to “System Cost”

Over the past two years, one of the focal points of competition among model developers has been context-window size. 128K, 200K, and 1M tokens have successively become key metrics at product launches. But once Agents begin making real tool calls, developers quickly discover that the question is no longer merely “Can it fit?” but “How much will it cost to include it every round?”

The emergence of HySparse2 indicates that Xiaomi’s MiMo team is shifting its focus from single-context capabilities to the total cost of ownership for long-running tasks.

This direction aligns with the evolution of today’s inference infrastructure: model services are beginning to distinguish between Prefill and Decode; caches are evolving from simple temporary states into core resources that require fine-grained management; and attention mechanisms are gradually shifting from full access toward “prioritizing important information.” For Agents, low latency no longer depends only on generation speed. It also depends on whether the model can quickly complete the next round of reading and decision-making after a tool returns its output.

However, HySparse2 also presents clear engineering challenges.

First, if sparse selection makes a mistake, what gets discarded may not be an ordinary token but a critical piece of evidence that determines whether the task succeeds. The model must maintain stable importance judgments at lower cost, placing greater demands on training data, long-context reinforcement learning, and attention distributions.

Second, a sparse structure may not automatically deliver ideal hardware acceleration. Reducing attention computation in theory does not mean that GPU kernels will achieve a linear speedup in practice. If the sparse access pattern is irregular, memory-access and scheduling overhead may offset part of the gains. The final results will also depend on whether Xiaomi provides mature inference-engine support and whether mainstream GPUs and domestic accelerators can fully exploit this structure.

Third, Prefill-Decode decoupling increases the complexity of service orchestration. Cache transfer, batch processing across different requests, and elastic scaling between Prefill and Decode nodes all require support from the inference framework. For developers deploying a model on a single machine, the architectural benefits may be less obvious than they are for large-scale cloud services.

What It Means for Developers

If you are simply calling a chat model for short-text question answering, HySparse2 will not immediately change how you develop at the API level. Those most affected are teams that have already built Agents into long-running systems.

In the future, when evaluating an Agent model, developers should look beyond general capabilities, tool-calling accuracy, and context-window size and also consider several additional metrics:

• Whether key facts can be reliably retrieved after multiple rounds of tool calls;
• How Prefill latency changes as the context grows from 32K to 256K or 1M tokens;
• Whether KV Cache usage grows linearly with history length;
• Whether sparse attention causes information loss across rounds;
• After separating Prefill and Decode, whether overall throughput, time to first token, and cost per unit improve.

More realistically, HySparse2 cannot yet become a product that developers can directly integrate. The complete specifications, weights, inference framework, license, and API service for MiMo-V3 have not yet been announced. What Xiaomi has released this time is an architectural signal: competition among next-generation models will not be limited to parameter size and benchmark scores. It will also depend on whether Agents can run for long periods without being overwhelmed by context costs.

If MiMo-V3 can ultimately convert HySparse2’s experimental results into stable online performance, Xiaomi will establish a differentiated path in long-context Agent infrastructure. Compared with simply pursuing larger dense models, this approach is closer to the realities of enterprise deployment: Is there enough GPU memory? Will Prefill become a bottleneck? Can history be retained? And how much computing power will each completed task actually consume?

As of September 24, MiMo-V3 has still not been officially released. HySparse2 is worth watching, but for now it should be viewed as an architectural bet aimed at the Agent era, rather than as the conclusion of a product that has already been fully validated.

References

• IT Home: Xiaomi Publicly Reveals MiMo-V3’s Core HySparse2 Architecture — The MiMo team’s public introduction to HySparse2’s design goals, long-horizon multi-turn Agent scenarios, and architectural evolution.