Xiaomi MiMo снизилась в цене на 99% — это не маркетинг! Ло Фули опубликовала пост в X, чтобы опровергнуть скептиков

null

Статья | Сянь Сяньчжи

Ло Фули опубликовала сообщение в X, чтобы поставить точку в ценовой войне вокруг Xiaomi MiMo.

26 мая официальный аккаунт Xiaomi MiMo в X выпустил объявление: API серии MiMo-V2.5 навсегда снижаются в цене, максимум на 99%. Все цены на длину контекста едины, пакеты токенов обновлены в 5-8 раз.

Это объявление на целую неделю заполонило китайский AI-круг. Реакции индустрии разделились. Самая крупная группа считает, что это "еще одна ценовая война" — за последние два года отечественные крупные модели, такие как Zhizhipu, DeepSeek, Byte Doudou и Alibaba Tongyi, последовательно снижали цены, все борются за место под солнцем.

Другая часть смотрит с пессимизмом: Xiaomi только что объявила о сокращении прибыли в этом году вдвое, а тут еще AI-бюджет в 600 миллиардов и API сокращены на 90% — классический пример "убыточной борьбы за рынок". Есть и те, кто считает, что это продолжение эффекта DeepSeek — последний подтянул всю отрасль к минимальным ценам, и те, кто не успеют подстроиться, выйдут из игры.

Поэтому, как руководитель MiMo, Ло Фули вчера вечером опубликовала технический блог на 5000 слов, в котором открыто рассказал о расчетах снижения цен.

"Смотрите, это реальная инженерная способность, а не маркетинговый трюк".

Чтобы понять, что именно Ло Фули имел в виду, нужно сначала разобраться, что же именно снизилось на 99%.

Это не полная модель. Скидка 99% распространяется только на один тариф под названием Input (Cache Hit) — то есть "часть, где пользователь повторно читает исторический контекст в длинном диалоге". Новые входные данные (No Cache Hit) снижаются значительно меньше, а снижение стоимости вывода модели (Output) — минимально.

Если представить модель как кофейню, это легко понять.

Вы заказываете латте с полусахаром, в кофейне есть два варианта: либо каждый раз перемалывать зерна, добавлять сироп и молоко — и за это платится каждый раз; либо, зная, что вы будете пить одно и то же каждый день, сделать большую порцию и хранить в морозилке, чтобы потом брать по мере необходимости. MiMo выбрала второй вариант — часть, которую пользователь повторно читает, из "расчетной" превращена в "доступную по требованию", поэтому эта часть практически не стоит денег, и потому можно дать 99% скидки.

Чтобы реализовать "по требованию", в блоге описано шесть инженерных решений, каждое из которых обязательно. Рассмотрим их по порядку.

Первое: уменьшить "память" модели до 1/7

Когда модель ведет диалог, каждый токен требует вычисления "промежуточного состояния", которое сохраняется для следующего шага. Это называется KVCache — можно понять как "краткосрочную заметку памяти" модели. После каждого высказывания модель записывает его краткое содержание, чтобы в следующий раз обращаться к нему, не прослушивая все заново.

Традиционные модели используют "Full Attention" на каждом слое — то есть каждый токен смотрит на все остальные токены диалога, и заметка растет очень быстро. В MiMo-V2.5-Pro архитектура изменилась: из 70 слоев 60 используют только последние 128 токенов (SWA, Sliding Window Attention), а только 10 слоев — полный просмотр.

Результат — объем KVCache уменьшился в 7 раз по сравнению с полным вниманием, и вычислительная нагрузка тоже снизилась в 7 раз.

Это — первый фундамент снижения затрат. Например, раньше каждый сотрудник компании должен был запомнить все протоколы совещаний, что перегружало память и снижало эффективность. Новое правило снизило нагрузку 60 сотрудников до 1/7, оставив 10 "архивных менеджеров" для всей истории — общая память компании осталась такой же, а эффективность выросла в 7 раз.

Второе: сделать так, чтобы сэкономленное пространство SWA действительно использовалось

Архитектурно уменьшение заметки до 1/7 — первый шаг, но чтобы реально реализовать "теоретические 1/7" в "фактические 1/7", есть еще одна преграда.

Традиционная система KVCache выделяет одинаковое количество памяти для всех слоев, исходя из "максимальной потребности". То есть, даже если 60 слоев SWA требуют только небольшого буфера, система выделяет для них столько же, как и для 10 слоев полного внимания — и сэкономленные ресурсы остаются неиспользованными.

Команда Ло Фули предложила разделить KVCache на два независимых пула: для 10 слоев полного внимания выделяется "большой" пул, по длине всей последовательности, а для 60 слоев SWA — "маленький" пул, только по 128 токенов.

Например, раньше каждому сотруднику выдавали "шкаф для хранения документов на 100 лет", а на самом деле им нужен был шкаф на неделю. Новая схема — выделять место по реальной необходимости. В результате в офисе могут работать в 5 раз больше сотрудников на той же аппаратуре — параллельная обработка увеличилась в 5 раз.

Это кажется простым, но без этого преимущества архитектуры SWA теряли бы смысл.

Третье: сделать так, чтобы "повторное чтение" действительно попадало в кеш

Когда заметка уменьшена до 1/7 и пространство реально используется, нужно решить старую проблему — повысить вероятность попадания в кеш по префиксу.

Многие диалоги начинаются одинаково — один и тот же системный промпт, одна и та же база кода, один и тот же длинный документ. Эти результаты можно сохранить и повторно использовать. Этот механизм называется префиксным кешем.

Но в режиме SWA есть ловушка: если два запроса имеют одинаковые токены, это не значит, что KVCache тоже совпадает. Возможно, префикс уже был рассчитан, но часть вне окна SWA давно выброшена. Если система будет считать, что одинаковые токены гарантируют кеш, то можно получить устаревшие или поврежденные данные, и качество модели упадет.

Ло Фули обновила правила: кеш работает только внутри "безопасной длины окна" — то есть, только для той части, которая точно есть в памяти.

Например, в библиотеке есть миллион книг, и вы хотите взять три книги "Три тела". Раньше система говорила: "Эта книга есть", и вы шли, чтобы обнаружить, что на полке осталась только обложка и первая часть, а остальные — взяты. Такой "ложный кеш" — зря потраченное время. Новая система говорит: "Я обещаю дать вам только те части, которые есть полностью", — сначала выдаст первую книгу, а остальные доставит позже.

Это кажется более строгим, и вероятность попадания снижается, но на самом деле — наоборот. Благодаря SWA объем KVCache уменьшился в 7 раз, и в результате вмещается гораздо больше данных, что повышает реальную вероятность попадания.

В блоге приведены реальные цифры: в популярных системах кеш-отдача достигает 93%, у активных пользователей — 95% и выше.

Это означает, что 95% повторных запросов не требуют вычислений на GPU — их можно взять из кеша. Это и есть физическая основа скидки в 99%.

Четвертое: разместить "кеш" на SSD, встроенном в GPU

Когда кеш попадает в память, возникает вопрос: где его хранить.

Память GPU (HBM) очень дорогая и ограниченная — у H100 в 8-карточной системе всего 640 ГБ. А KVCache может занимать десятки терабайт. Поэтому используют многоуровневую систему хранения: наиболее свежие данные — в памяти GPU (L1), чуть старее — в оперативной памяти CPU (L2), самые старые — в распределенном кеше (L3).

Общая практика — создавать отдельные кластеры для L3, с выделенными серверами и дата-центрами, платя ежемесячную аренду.

Команда Xiaomi пошла другим путем: разработала собственный GCache — распределенный кеш, который размещается прямо на SSD, встроенном в GPU. И работает он вместе с задачами обучения и инференса на одной машине.

Проще говоря: другие арендуют склады для хранения данных, а Xiaomi обнаружила, что у GPU есть свободный "гараж", и просто хранит там данные. Это экономит деньги.

В блоге говорится: "Дополнительные затраты на хранение — ноль".

Это очень мощное решение. В обычных расчетах стоимости AI-компаний хранение — постоянная статья расходов: чем больше модель и чем больше пользователей, тем больше затрат. GCache устраняет эти расходы полностью. В сочетании с малым объемом SWA и вероятностью попадания 93-95%, время жизни данных в L3 увеличивается с минут до часов или даже дней — чем дольше, тем больше шансов, что история будет успешно использована, и скидка в 99% будет оправдана.

Пятое: маршрутизировать кешированные запросы по кратчайшему пути

Когда кеш есть и он работает, важно правильно направлять запросы.

Команда Xiaomi создала собственную систему маршрутизации LLM-Router, которая занимается тремя задачами:

1. Аффинное распределение. Запросы с одинаковым префиксом идут на одну машину, чтобы кеш был максимально эффективен.

2. Разделение по длине. Короткие запросы (0-64К), средние (64-256К) и длинные (256К-1М) обрабатываются разными каналами, чтобы не тормозить короткие.

3. TTFT-оптимизация. В очереди на инференс приоритет имеют запросы с меньшей вычислительной нагрузкой — те, что хорошо кешируются, чтобы не блокировать новые или тяжелые запросы.

Например, в аэропорту: все пассажиры на один рейс собираются в один зал, чтобы ускорить обработку бага — это аффинное распределение. Разделение по багажу — чтобы быстрые пассажиры с ручной кладью проходили быстрее, а крупные чемоданы — отдельно. При посадке на самолет — приоритет у тех, кто летит быстро и без багажа, чтобы самолет вылетел раньше — это TTFT.

Эта стратегия повысила кеш-отдачу на 25%, пропускную способность на сервере — на 30%, а задержки по длинным запросам — на 30% снизились.

Это означает, что одна GPU может обслуживать больше пользователей. Вторая часть снижения цен — повышение эффективности: больше работы за те же ресурсы, меньшие издержки на пользователя.

Шестое: ускорить "печать" модели

Предыдущие пять мер оптимизируют "чтение" — снижение стоимости повторного чтения истории до нуля. Шестая — оптимизация "письма" — генерации следующего токена.

Традиционно модель генерирует по одному токену за раз. В MiMo поддерживается Multi-Token Prediction (MTP) — предсказание сразу трех токенов. Если модель правильно предсказывает, можно пропустить промежуточные вычисления.

Например, как при наборе текста: чтобы написать "今天天气", нужно нажать 4 раза. MTP — это автодополнение, которое угадывает, что вы хотите написать, и если угадает правильно, то пропускаете эти нажатия.

В тестах на агентных сценариях MTP ускоряет декодирование первых 128 токенов в 2.3 раза, а с 128 до 256 — в 1.5 раза.

Это важно, потому что скидка в 99% в основном касается Input (Cache Hit), но при реальной работе input и output — часть одного запроса. Если output не снижен, то экономия достигается только наполовину. MTP позволяет снизить и вывод, и вход, делая всю систему более выгодной.

Объединим все шесть решений в цепочку снижения затрат:

SWA → KVCache 1/7 → разделение на два пула → одна GPU — 5+ раз больше одновременных пользователей → кеш-отдача 93-95% → 95% запросов без вычислений → GCache — нулевые затраты на хранение → маршрутизация кешированных запросов → MTP — ускорение генерации → снижение времени GPU на запрос в разы → снижение стоимости более чем на 95% → снижение цен на 99%, при этом прибыль остается.

Любой пропуск звена разрывает цепочку. Снижение на 99% — не маркетинговый трюк, а результат шести инженерных решений и реальных онлайн-экспериментов.

Обзор индустрии показывает разные интерпретации: ценовая война в Китае — правда; сокращение прибыли Xiaomi — правда; снижение цен DeepSeek — тоже правда.

Но Ло Фули в своем блоге подробно разобрала технические детали, чтобы опровергнуть мнение о ценовой войне, подчеркнув, что "технические вопросы — техническим решениям, маркетинг — маркетингу".

Она пишет, что эффективность модели MiMo-V2.5 достигается не одним отдельным улучшением, а многомерной совместной оптимизацией. Гибридный SWA позволяет одновременно улучшить prefill и decode, но не полностью оптимизированный KVCache может увеличить издержки. В рамках этого команда системно переработала управление KVCache, уровни кеширования, дерево префиксного кеша, решая ключевые проблемы SWA KVCache, оптимизировала стратегию маршрутизации и цепочки Prefill/Decode, протестировала в реальных сценариях — и добилась, чтобы теоретические преимущества перешли в реальные показатели в производственной среде. Только тогда гибридный SWA проявил свои преимущества в длинных диалогах по эффективности и скорости. В сочетании с MoE и мультимодальными оптимизациями удалось значительно повысить производительность онлайн-инференса.

Это системный подход к AI-инженерии и пример для отрасли по снижению затрат.

Ценовая война не требует блогов — нужны реальные инженерные решения.