MapFlow из Пекинского университета даёт моделям переиспользовать внимание друг друга

Мультимодельные агенты стали обычной архитектурой. Модель А планирует, модель Б детализирует и подводит итог. Сложные вопросы уходят сильной модели, простые достаются лёгкой и дешёвой. Идея понятная: качество там, где оно нужно, экономия там, где можно. Но у этой схемы есть скрытая статья расходов, о которой редко говорят в презентациях.

Где теряются деньги

Представьте типичный сценарий. Большая модель только что обработала длинный документ: контракт, кодовую базу или выгрузку логов. Она построила внутреннее представление текста и держит его в KV-кэше. Затем в дело вступает маленькая модель. Ей нужно ответить на уточняющий вопрос или оформить итоговый отчёт. Кэш большой модели ей не подходит: у другой архитектуры другие размерности, слои и головы внимания. Поэтому маленькая модель честно прогоняет тот же документ с нуля и тратит время и деньги на префилл.

На коротких запросах это незаметно. На длинном контексте, на нескольких передачах за одну задачу и при большом потоке пользователей повторный префилл превращается в ощутимую долю задержки и счёта за GPU. Получается, что вы платите за одно чтение несколько раз, по разу на каждую модель в цепочке.

Что предлагает MapFlow

Команда Пекинского университета представила MapFlow. Судя по заголовку и началу описания, идея в том, чтобы не пересчитывать всё заново, а переиспользовать внимание между моделями. Вместо повторного вычисления на стороне принимающей модели уже готовые результаты работы предыдущей отображаются в её пространство.

По аналогии: коллега написал подробный конспект длинного документа, и вы не перечитываете оригинал, а переводите его заметки на свой язык и работаете с ними. Название, по-видимому, отражает то же самое: «map» — отображение, «flow» — поток информации от одной модели к другой.

Важная оговорка. В доступном нам фрагменте нет ни конкретного механизма отображения, ни цифр по ускорению и потере качества, ни списка поддерживаемых пар моделей. Эти детали решают всё, поэтому оценивать практическую пользу метода рано. Пока можно сказать, что направление правильное и проблема настоящая.

Почему это важно на практике

Стоимость агентных систем в основном определяется не одним вызовом модели, а количеством повторов контекста между вызовами. Сегодня для частичной экономии есть префикс-кэширование внутри одной модели и семейства моделей с общим токенизатором. Кросс-модельный перенос внимания закрывал бы случай, когда в связке стоят разные модели, например большая для планирования и малая для исполнения.

Если метод заработает в реальных условиях, выиграют три группы:

• команды с агентами над длинными документами и репозиториями, где контекст читается многократно;
• сервисы с маршрутизацией «сильная модель — слабая модель», где хендофф происходит на каждом запросе;
• провайдеры инференса, для которых префилл стоит дорого.

Ограничения и что делать сейчас

Главные вопросы к любому такому методу известны заранее. Сколько качества теряется при отображении между разными архитектурами? Нужно ли дообучать адаптер для каждой пары моделей? Совместим ли подход с популярными движками инференса, такими как vLLM и SGLang? И что происходит с памятью, если надо держать кэш одной модели, пока работает другая? Пока ответов нет, в продакшн это не тащат.

Практический вывод для разработчика простой и не требует ждать статью целиком. Измерьте, сколько токенов ваш агент префиллит повторно при передаче между моделями и какую долю задержки и стоимости это занимает. Если доля заметна, следите за MapFlow и родственными работами. Если контексты короткие, проблема вас пока не касается, и оптимизировать здесь нечего.

До появления деталей и воспроизводимых результатов относитесь к MapFlow как к сигналу: рынок упирается в стоимость повторного чтения, и исследователи начинают искать решения на уровне самого внимания, а не только на уровне кэш-прокси и промптов.