Peking University's MapFlow Lets Models Reuse Each Other's Attention

Multi-model agents have become a standard architecture. Model A plans, Model B elaborates and wraps up. Hard questions go to the strong model, easy ones to the lightweight, cheap one. The idea is clear: quality where it is needed, savings where possible. But this setup has a hidden cost item that rarely comes up in presentations.

Where the money gets lost

Imagine a typical scenario. A large model has just processed a long document: a contract, a codebase or a dump of logs. It has built an internal representation of the text and holds it in the KV cache. Then a small model steps in. It needs to answer a follow-up question or produce the final report. The large model's cache is of no use to it: a different architecture has different dimensions, layers and attention heads. So the small model dutifully runs the same document from scratch, spending time and money on prefill.

On short requests this goes unnoticed. With long context, several handoffs within a single task and a large stream of users, repeated prefill turns into a noticeable share of latency and of the GPU bill. In effect, you pay for one reading several times, once for each model in the chain.

What MapFlow proposes

A team from Peking University has presented MapFlow. Judging by the title and the opening of the description, the idea is not to recompute everything from scratch but to reuse attention across models. Instead of recomputing on the receiving model's side, the finished results of the previous model's work are mapped into its space.

By analogy: a colleague has written a detailed summary of a long document, and instead of rereading the original, you translate their notes into your own language and work with them. The name seems to reflect the same thing: "map" is the mapping, "flow" is the flow of information from one model to another.

An important caveat. The fragment available to us contains no specific mapping mechanism, no figures on speedup and quality loss, and no list of supported model pairs. These details decide everything, so it is too early to judge the method's practical value. For now, we can say that the direction is right and the problem is real.

Why this matters in practice

The cost of agentic systems is determined mainly not by a single model call but by how many times context is repeated between calls. Today, partial savings come from prefix caching within a single model and from model families sharing a tokenizer. Cross-model attention transfer would cover the case where different models are chained together, for example a large one for planning and a small one for execution.

If the method works in real-world conditions, three groups stand to benefit:

• teams with agents over long documents and repositories, where context is read many times;
• services with "strong model — weak model" routing, where a handoff happens on every request;
• inference providers, for whom prefill is expensive.

Limitations and what to do now

The main questions for any such method are known in advance. How much quality is lost in mapping between different architectures? Does an adapter need to be fine-tuned for each pair of models? Is the approach compatible with popular inference engines such as vLLM and SGLang? And what happens to memory if one model's cache must be held while another is running? Until there are answers, nobody is pushing this into production.

The practical takeaway for developers is simple and doesn't require waiting for the full paper. Measure how many tokens your agent re-prefills when handing off between models, and what share of latency and cost that takes. If the share is noticeable, follow MapFlow and related work. If your contexts are short, the problem doesn't affect you yet, and there is nothing to optimize here.

Until details and reproducible results appear, treat MapFlow as a signal: the market is hitting the cost of rereading, and researchers are starting to look for solutions at the level of attention itself, not only at the level of cache proxies and prompts.