Xiaomi выжимает эффективность из гибридного sliding window attention в MiMo v2.5

Xiaomi выпустила инженерный разбор того, как устроен инференс для семейства моделей MiMo-V2.5 (включая MiMo-V2.5-Pro). Архитектура сочетает гибридное скользящее окно внимания (Hybrid SWA), разреженную активацию MoE и мультимодальные энкодеры для текста, изображений, аудио и видео. У MiMo-V2.5-Pro 70 слоёв: 10 из них считают внимание по всей последовательности (Full Attention), а 60, только в пределах скользящего окна размером 128 токенов (SWA). Поскольку SWA-слои составляют 6/7 всех слоёв, суммарные вычисления и объём кэша ключей-значений (KVCache) у гибридной архитектуры примерно в 7 раз меньше, чем у полного внимания. Так как декодирование токенов упирается в пропускную способность памяти, а при длинном контексте объём KVCache может превышать объём весов модели, такое сокращение почти напрямую снижает стоимость генерации на длинных последовательностях. По эффективности KVCache MiMo-V2.5 и MiMo-V2.5-Pro занимают второе место среди сравниваемых моделей, уступая только DeepSeek-V4-Pro и DeepSeek-V4-Flash; выигрыш минимален на коротких последовательностях и растёт с длиной контекста.

Однако теоретическая экономия не реализуется сама собой. MiMo-V2 и MiMo-V2.5 были одними из первых моделей с Hybrid SWA, и на момент запуска ни один open-source инференс-фреймворк не поддерживал SWA полноценно. Xiaomi выбрала SGLang v0.5.5 в качестве бэкенда, но его система кэширования HiCache не умела работать с SWA: ранняя поддержка эмулировала SWA, сохраняя кэш целиком, что сводило на нет всю экономию памяти. Причина в конфликте требований к хранению: слоям с полным вниманием нужен кэш на всю последовательность (сложность O(N)), а SWA-слоям, только кэш в пределах окна (O(W)). При едином пуле памяти система вынуждена резервировать O(N) для всех слоёв, и разреженность SWA не используется. Решение, разделить KVCache на два независимых пула (для Full Attention и для SWA) с единой абстракцией на уровне системы. Это дало SWA-кэшу строгое ограничение хранения O(W), повысило эффективность использования объёма кэша примерно в 7 раз и позволило почти полностью совместить по времени предвыборку кэша с хоста на GPU и сами вычисления, сведя стоимость чтения кэша почти к нулю.

Отдельная проблема, переиспользование префиксов запросов. Стандартное правило RadixAttention ("одинаковые токены на входе → одинаковый кэш") работает для полного внимания, но ломается при SWA: логический срок жизни узла в дереве префиксов не совпадает с физическим сроком жизни SWA-кэша, и узел дерева может формально соответствовать полной последовательности токенов, а физически от неё в кэше осталось только окончание или вообще ничего. Если система по-старому считает совпадение токенов признаком попадания в кэш, планировщик может получить "ложное попадание", вычисления внимания прочитают вытесненные или перезаписанные данные, что напрямую портит корректность ответа модели. Xiaomi переработала семантику дерева префиксов под правило "безопасной по окну длины": формальная доля попаданий в кэш при этом чуть снижается, зато при том же объёме хранения помещается в разы больше токенов, а эффективная доля попаданий на фиксированный бюджет памяти заметно растёт. Дополнительно пришлось синхронизировать состояние трёх уровней HiCache (устройство, хост, бэкенд хранения), поскольку асинхронный конвейер данных легко рассинхронизирует кэш полного внимания и валидные индексы SWA, рассинхронизация ведёт к обрезке совпадения и лишним пересчётам. Эти доработки особенно помогают при длинных агентных сессиях, общих системных промптах для многих пользователей и повторяющихся вызовах инструментов к одной и той же кодовой базе.

В основе всей системы лежит GCache, собственная высокопроизводительная система кэширования, которую команда хранения данных Xiaomi изначально разрабатывала для обучения моделей, потому что доступные open-source решения плохо ускоряли распределённые файловые системы. Позже GCache адаптировали в отдельный продукт для распространения весов моделей и в качестве третьего уровня (L3) KVCache для инференса. Она поддерживает и файловую, и KV-семантику, многоуровневое кэширование между памятью, диском и удалённым хранилищем, персистентность в разделяемой памяти, сквозное копирование без промежуточных буферов (zero-copy), высококонкурентный неблокирующий ввод-вывод и RDMA. На современных GPU-машинах с 8 сетевыми картами по 400 Гбит/с даже при раздельном развёртывании prefill/decode инференс-фреймворкам обычно не удаётся насытить сеть, настолько, что в индустрии обсуждают снижение спецификаций сетевых карт ради экономии. GCache отдаёт приоритет сетевым картам GPU перед фронтенд-картами и использует NUMA-биннинг и affinity по общей физической линии. В тестах при размере блока ввода-вывода 1 МБ пропускная способность чтения по RDMA в одном процессе достигает 170 ГБ/с при задержке 280 микросекунд, а в сценариях с GDR (прямым доступом GPU к памяти), около 350 ГБ/с за счёт более высокой пропускной способности HBM.

В 2026 году в индустрии растёт озабоченность стоимостью хранения. В отличие от вендоров, использующих выделенные машины под хранилище, GCache совместно размещается прямо на GPU-машинах, забирая часть памяти у узлов prefill и decode вместе со встроенными NVMe SSD, это даёт нулевую дополнительную стоимость хранения. Обратная сторона совместного размещения, высокая частота отказов GPU-машин: с момента запуска GCache сталкивалась с отказами хост-машин практически каждый день. Команда усилила логику обработки отказов, а благодаря распределению ключей через консистентное хеширование заранее группирует идентификаторы сессий так, чтобы связанные сессии оказывались на разных узлах, это снижает радиус поражения при отказе одного узла. Аппаратные средства нижележащей платформы позволяют заранее обнаруживать неисправности и автоматически переносить данные, а для редких внезапных сбоев, которые нельзя предугадать, короткий таймаут SDK позволяет инференс-фреймворку быстро обнаружить промах кэша и пересчитать нужные данные заново, почти не влияя на онлайн-инференс.

Ключевые факты

• У MiMo-V2.5-Pro 70 слоёв: 10 с полным вниманием и 60 со скользящим окном (128 токенов), гибридная схема снижает вычисления и объём KVCache примерно в 7 раз против полного внимания, с наибольшим выигрышем на длинном контексте.
• По эффективности KVCache модели Xiaomi занимают второе место среди сравниваемых, уступая только DeepSeek-V4-Pro и DeepSeek-V4-Flash.
• Готовые open-source фреймворки (SGLang v0.5.5/HiCache) не поддерживали SWA-кэш полноценно; Xiaomi разделила KVCache на два независимых пула (Full Attention и SWA), подняв эффективность использования объёма кэша примерно в 7 раз.
• Стандартное правило переиспользования кэша по совпадению токенов (RadixAttention) при SWA даёт ложные попадания и портит корректность ответов, потребовалась переработка дерева префиксов под "безопасную по окну" длину совпадения.
• Собственная система кэширования GCache совмещена с GPU-машинами (нулевая доп. стоимость хранения), даёт RDMA-чтение до 170 ГБ/с (280 мкс) и до ~350 ГБ/с при GDR, но сталкивается с почти ежедневными отказами хост-машин и компенсирует это консистентным хешированием, аппаратным мониторингом и быстрым таймаутом SDK для пересчёта.

Почему это важно

Материал показывает, что архитектурная экономия (гибридное внимание вместо полного) сама по себе не даёт прироста в продакшене, её съедают инженерные накладные расходы: несовместимость с готовыми системами кэширования, рассинхронизация распределённого кэша, узкие места сети. Xiaomi детально показывает, какие именно системные доработки нужны, чтобы теоретическая экономия KVCache в 7 раз реально превратилась в более дешёвый и быстрый инференс на длинном контексте.

Кому это важно

Материал адресован инженерам инференс-систем и MLOps-командам, которые обслуживают большие языковые модели с длинным контекстом: тем, кто выбирает или дорабатывает фреймворки вроде SGLang, проектирует многоуровневое кэширование KV, а также архитекторам инфраструктуры, которые ищут способы снизить стоимость хранения и сетевые узкие места при обслуживании LLM.

Как это применить

Ключевые идеи переносимы на любой стек с гибридным вниманием: разделять пулы KVCache под разные типы слоёв вместо единого пула на O(N); менять правило попадания в кэш префиксов так, чтобы оно учитывало реальный физический срок жизни данных, а не только совпадение токенов; синхронизировать состояние кэша между уровнями (устройство/хост/удалённое хранилище) явно, а не полагаться на асинхронный конвейер; и рассматривать совместное размещение кэш-системы на GPU-машинах как способ обнулить дополнительные расходы на хранение, при условии, что заложена устойчивость к частым отказам узлов.

Можно ли доверять

Это инженерный отчёт от команды разработчиков модели и инфраструктуры Xiaomi (блог MiMo), содержащий конкретные архитектурные параметры (число слоёв, размер окна), сравнение с моделями DeepSeek по эффективности KVCache и измеренные бенчмарки RDMA-пропускной способности. Источник первичный и детальный, но это собственная публикация вендора без независимой проверки третьей стороной, приведённые цифры описывают внутренние тесты Xiaomi, а не воспроизведённые внешними исследователями результаты.

Риски и подводные камни

Совместное размещение системы кэширования на GPU-машинах ради экономии хранения оборачивается высокой частотой отказов хостов (по признанию самой команды, почти ежедневно), что требует постоянных инженерных усилий на отказоустойчивость. Переработка правил попадания в кэш под SWA, источник тонких ошибок корректности: если семантика дерева префиксов рассинхронизируется с реальным состоянием кэша, модель может получить вычисления по вытесненным или перезаписанным данным, что незаметно портит ответы, а не просто снижает скорость.

«С момента запуска GCache сталкивалась с отказами хост-машин практически каждый день.»

— команда MiMo, блог Xiaomi