Автор: Сян Сяньчжи
Ло Фули опубликовала запись в X, чтобы положить конец скандалу с понижением цены MiMo от Xiaomi.
26 мая официальный аккаунт Xiaomi MiMo на X опубликовал объявление: API серии MiMo-V2.5 постоянно снижает цены, максимальное снижение — 99%. Все длины контекста имеют единую цену, пакеты токенов увеличены в 5–8 раз.
Это объявление неделю доминировало в китайском AI-сообществе. Первоначальная реакция отрасли разделилась на несколько лагерей. Самый крупный из них заявил, что это «ещё одна волна ценовой войны» — последние два года китайские крупные модели, от Zhipu, DeepSeek и ByteDance DouBao до Alibaba Tongyi, поочерёдно снижали цены, и никто не остался в стороне.
Другая точка зрения пессимистична: Xiaomi только что объявила, что прибыль за этот год сократилась вдвое, а теперь еще тратит 60 млрд на ИИ и сокращает расходы на API на 90% — типичная стратегия «продажи по убыточным ценам ради захвата рынка». Некоторые считают, что это продолжение эффекта DeepSeek — последний опустил ценовой ориентир всей отрасли до пола, и кто не последует — тот выйдет из игры.
Таким образом, как руководитель MiMo, Ло Фули вчера вечером сразу же опубликовала технический блог объемом 5000 слов, открыв всем бухгалтерские данные о снижении цен.
Смотрите, это реальные инженерные возможности, а не маркетинговые уловки.
Чтобы понять, что говорит Ло Фули, сначала нужно разобраться, что именно снизилось на 99%.
Это не снижение цены на всю модель. Скидка 99% применяется исключительно к тарифу Input (Cache Hit) — то есть той части, где пользователь повторно читает исторический контекст в длинном диалоге. Снижение для обычных новых запросов (No Cache Hit) значительно меньше, а для вывода модели (Output) — минимальное.
Если вы представите модель как кофейню, это станет понятнее.
Вы заказываете латте с половиной порцией сахара, и в кофейне есть два способа приготовления: либо каждый раз молоть кофе, наливать сироп и молоко — при этом оплачивая сырьё и труд каждый раз; либо модель знает, что на этой неделе вы каждый день пьёте один и тот же латте с половиной порцией сахара, поэтому готовит большую ёмкость и хранит её в холодильнике, а затем просто отмеряет порцию по стакану. MiMo на этот раз выбрал второй вариант — вместо расчёта повторяющихся запросов пользователей в реальном времени они стали просто извлекать их из готового хранилища, поэтому реальная стоимость этой части близка к нулю, и естественно можно предложить скидку 99%.
Для реализации функции «снять сейчас» в техническом блоге описано шесть инженерных компонентов, каждый из которых необходим. Рассмотрим их по одному.
Проект 1: Сжать «память» модели до 1/7
При диалоге с вами модель вычисляет и сохраняет «промежуточное состояние» для каждого токена, чтобы использовать его на следующем шаге. Это называется KVCache — можно представить его как «блокнот краткосрочной памяти» модели. Каждый раз, когда модель что-то говорит, она записывает краткое содержание этой фразы в блокнот и в следующий раз просто обращается к записям, не переслушивая всё, что вы уже сказали.
В традиционных моделях каждый слой использует «Полное внимание» — то есть каждый токен просматривает все токены всего диалога, и блокнот становится все толще. MiMo-V2.5-Pro изменил архитектуру: из 70 слоев 60 слоев смотрят только на последние 128 токенов (SWA, Sliding Window Attention), а только 10 слоев — «архивариусов» — смотрят на все.
В результате объем KVCache сокращается до 1/7 от объема полного внимания, а вычислительная нагрузка также составляет 1/7.
Это первый фундамент снижения затрат. Например, раньше каждому сотруднику компании требовалось запоминать все протоколы встреч, из-за чего у всех не хватало памяти, а эффективность была низкой. Новое правило снизило когнитивную нагрузку 60 сотрудников до 1/7, оставив только 10 архивариусов, отвечающих за всю историю — общая способность компании к запоминанию не снизилась, но эффективность выросла в семь раз.
Проект 2: Сделать освободившееся место SWA действительно пригодным для использования
Сжатие ноутбука до 1/7 в архитектуре — это первый шаг, но чтобы превратить «теоретические 1/7» в «фактические 1/7», нужно преодолеть еще один барьер.
Традиционная система KVCache выделяет видеопамять для всех слоев по принципу «максимально возможного использования». То есть: даже если 60 слоев SWA требуют лишь маленькой тетради, система выделяет каждому слою «большой архивный том» — пространство, сэкономленное SWA, просто зарезервировано впустую, как будто экономии не было.
Команда Ло Фули разделила KVCache на два отдельных пула. Для 10 слоев Full Attention используется «большой пул» с выделением по полной длине, а для 60 слоев SWA — «малый пул» с выделением только по окну в 128 токенов.
Например, раньше компания выдавала каждому сотруднику шкаф, способный хранить файлы на 100 лет — но 60 сотрудникам на самом деле нужны лишь небольшие шкафы для хранения файлов за неделю, при этом 99% пространства в этих больших шкафах остаются пустыми. Новый подход предполагает выделение шкафов в соответствии с реальными потребностями. В результате в офисе может разместиться более чем в пять раз больше сотрудников — количество одновременно обслуживаемых пользователей на одном GPU увеличилось в пять раз.
Этот шаг выглядит просто, но без него преимущества архитектуры SWA, описанных ранее, оказываются напрасными.
Проект 3: Убедитесь, что «повторное чтение старыми пользователями» действительно попадает в кэш
Ноутбук сжат до 1/7 + пространство действительно доступно; следующий шаг — решить старую проблему: коэффициент попаданий в кэш префиксов.
Многие диалоги пользователей начинаются одинаково — одна и та же системная подсказка, один и тот же кодовый репозиторий, один и тот же длинный документ. Система сохраняет результаты этих вычислений и при повторном совпадении сразу использует их повторно. Этот механизм называется кэшированием префиксов.
Но в режиме SWA есть одна ловушка: совпадение токенов двух запросов не означает, что KV-данные всё ещё актуальны. Возможно, префикс был вычислен, но часть данных за пределами окна SWA уже была удалена. Если система по старому правилу «совпадение токенов = попадание» повторно использует эти данные, вы получите недействительные или перезаписанные данные, и производительность модели резко упадёт.
Команда Luo Fuli обновила правила до «оконной безопасной длины» — обещает только «ту часть, которую вы можете полностью занять».
Например, в библиотеке есть 1 миллион книг, и вы хотите взять всю серию из трех томов «Трех тел». Старая система сообщила бы вам: «Эта книга есть», — вы идете туда, а на полке оказывается только обложка и первая часть, две остальные уже выданы. Такая «ложная положительная» ситуация заставляет вас потратить время впустую и снова запрашивать книгу. Новая система работает по другому принципу: она обещает вам только ту часть, которую вы сможете получить полностью — сначала выдает вам первую часть, а затем доставляет остальные две.
Звучит так, будто стало строже и точность снизилась. Но на самом деле наоборот: благодаря SWA размер KVCache сокращается в 7 раз, поэтому при том же объеме памяти помещается в несколько раз больше данных, и реальная точность значительно возрастает.
В блоге Ло Фули приведены реальные онлайн-данные: средняя частота попаданий в кэш сервера в рамках основных фреймворков составляет 93%, а у пользователей с высокой активностью и длительным циклом — более 95%.
Значение этого числа: 95% запросов «повторного чтения» вообще не требуют вычислений на GPU — данные извлекаются напрямую из кэша. Именно это лежит в основе физической основы скидки 99%.
Проект 4: Установить «кэш» во встроенный SSD GPU
Точность повысилась, следующий вопрос: где размещены эти кэши.
Память HBM на GPU дорогая и ограниченная — восьмикарточная система H100 имеет всего 640 ГБ памяти, но для MiMo требуется хранилище KVCache объемом в десятки ТБ. Поэтому необходимо использовать многоуровневую систему: недавно используемые данные хранятся в памяти GPU (L1), немного более старые — в оперативной памяти CPU (L2), а холодные данные — в распределенном кэше (L3).
Это то же самое, что управлять деньгами. Наличные в кошельке — это видеопамять — можно использовать сразу, но вместить немного. Баланс банковской карты — это оперативная память CPU — чтобы получить доступ, нужно 30 секунд, но можно хранить много. Депозит — это распределенный кэш L3 — чтобы получить доступ, нужно 2 минуты, но намного дешевле.
В отрасли принято выделять отдельный кластер хранения для L3, с использованием специализированного оборудования и отдельного серверного помещения, с ежемесячной оплатой аренды.
Подход команды Xiaomi Storage отличается. Они самостоятельно разработали распределенный кэш под названием GCache, который напрямую развернут на SSD, встроенных в GPU-машины, — совместно с задачами обучения и вывода на одном и том же сервере.
Другие арендовали склад специально для хранения больших объемов данных; Xiaomi обнаружила, что гараж с GPU-машинами пустует, и сразу же разместила данные там. Сэкономлены ежемесячные арендные платежи.
Дополнительные расходы на хранение составляют 0.
Это дело обладает большей силой, чем кажется. В традиционных «расчетах вычислительных мощностей ИИ-компаний» стоимость хранения является фиксированным расходом — чем больше ваша модель и чем больше пользователей, тем длиннее счет за хранение. Подход GCache полностью устраняет эту статью расходов. В сочетании с компактным размером SWA и коэффициентом попаданий 93–95% время жизни KVCache на L3 (TTL) увеличивается с нескольких минут до нескольких часов и даже дней — чем дольше TTL, тем шире окно попаданий для исторического контекста, тем выше коэффициент попаданий в кэше, и тем устойчивее становится скидка в 99%.
Проект 5: Направлять запросы, попавшие в кэш, по кратчайшему пути
Кэш может хранить, искать и стоит недорого; последний шаг — как направлять правильные запросы на правильные серверы.
Xiaomi разработала собственную систему планирования под названием LLM-Router, которая выполняет три задачи:
Первое — согласованное планирование. Запросы с одинаковым префиксом направляются на один и тот же сервер, чтобы максимизировать повторное использование кэша.
Во-вторых, разделение по длине. Короткие запросы (0–64 КБ), средние запросы (64 КБ–256 КБ) и длинные запросы (256 КБ–1 МБ) направляются в разные каналы обработки, чтобы короткие запросы не замедлялись из-за длинных.
Третье — оптимизация TTFT. В очереди ожидания вывода приоритизируйте запросы с небольшим объемом реальных вычислений (то есть те, которые часто попадают в кэш) — чтобы они не блокировались запросами с "новым вводом", требующими больших вычислений.
Например, при обычном расписании аэропорта все пассажиры, летящие в одно и то же направление, собираются в одном зале ожидания и используют общую систему получения багажа — это согласованное планирование. Пассажиры с ручной кладью и пассажиры с тремя большими чемоданами проходят через разные контрольно-пропускные пункты, чтобы быстрые не задерживались медленными — это разделение по длине. При посадке первыми пропускают тех, у кого только ручная кладь — они быстрее садятся, позволяя самолету вылететь раньше — это оптимизация TTFT.
Эта стратегия планирования на практике повысила коэффициент попаданий в кэш L2 на 25%, пропускную способность ввода на одном сервере на 30% и снизила P90 задержку длинных запросов на 30%.
Одна и та же GPU может обслуживать больше пользователей. Вторая половина логики снижения цен здесь — более высокая эффективная производительность на единицу вычислительной мощности и более низкая стоимость на одного пользователя.
Проект 6: Ускорить «печатание» модели
Первые пять пунктов направлены на оптимизацию стороны «чтения» — снижение стоимости для пользователя повторного чтения исторического контекста до почти нуля. Шестой пункт оптимизирует сторону «записи» — то есть процесс генерации следующего токена моделью.
Традиционные модели могут генерировать только один токен за раз. MiMo нативно поддерживает 3 уровня MTP (Multi-Token Prediction) — прогнозирование следующих 3 токенов одновременно, и если промежуточный токен предсказан правильно, промежуточные вычисления пропускаются.
Например, традиционный набор текста — это печать по одному символу: чтобы набрать «сегодня погода», нужно нажать 4 клавиши. MTP работает как автозаполнение, которое предсказывает ваши следующие 1–2 символа — если оно угадывает правильно, вам не нужно нажимать эти клавиши.
MiMo MTP в агентных сценариях: ускорение на 2,3 раза для первых 128 токенов, на 1,5 раза для токенов 128–256.
Значение этого заключается в том, что скидка в 99% применяется исключительно к Input (Cache Hit), но при реальном обслуживании пользователей модель обрабатывает input и output в рамках одного и того же запроса — если output не оптимизирован, общая стоимость запроса снижается лишь наполовину. MTP позволяет снизить и вторую половину, связанную с output, замыкая таким образом всю прибыльную модель снижения цен.
Свяжите шесть вещей в одну цепочку снижения затрат:
Архитектура SWA → KVCache 1/7 → Двойной пул действительно высвобождает емкость → На одном GPU помещается более чем в 5 раз больше параллельных задач → Коэффициент попаданий в кэш префиксов 93–95% → 95% запросов почти не требуют вычислений → GCache снижает стоимость хранения до нуля → Планировщик приоритизирует запросы с попаданием в кэш → MTP также экономит ресурсы при генерации → Время GPU на один запрос снижается на порядок → Стоимость на единицу падает более чем на 95% → Цены снижены на 99%, при этом маржа остается положительной.
Если пропущен хоть один этап, цепочка разорвется на одном из звеньев. Снижение на 99% — это не маркетинговое число, а накопительный эффект, полученный в результате сложения шести инженерных опор и реальной онлайн-проверки.
Возвращаясь к первоначальным интерпретациям отрасли, каждая из них содержала долю правды. Две последние года — это действительно была ценовая война между китайскими компаниями, разрабатывающими крупные языковые модели; действительно, прибыль Xiaomi сократилась вдвое, но она всё ещё вкладывается в ИИ; действительно, DeepSeek опустила ценовые стандарты отрасли до самого дна.
Но то, что Luo Fuli в этот раз открыла технический блог и подробно разобрала технические детали, несомненно, является попыткой опровергнуть утверждения о ценовой войне и провести четкую грань: «Технические вопросы — это технические вопросы, маркетинговые вопросы — это маркетинговые вопросы».
В своем блоге она написала, что эффективность вывода моделей серии MiMo-V2.5 достигнута не за счет одноточечного прорыва в одном из этапов, а как результат многоаспектной совместной оптимизации. Hybrid SWA позволяет одновременно улучшить как prefill, так и decode, однако неоптимизированная реализация KVCache может повысить затраты на всех этапах. С этой целью команда MiMo систематически переработала управление KVCache, иерархическое кэширование и дерево кэширования префиксов, решила ключевые проблемы SWA KVCache, оптимизировала стратегии планирования и цепочки Prefill/Decode, а после проверки в реальных онлайн-сценариях успешно реализовала теоретические преимущества эффективности в производственной среде. Только теперь Hybrid SWA полностью раскрыл свои архитектурные преимущества — сочетание мощности и эффективности при выводе длинных текстов. В сочетании с конфигурацией MoE и различными оптимизациями мультимодального вывода это значительно повысило производительность онлайн-сервисов вывода.
Это системный подход к инженерии ИИ, а также метод снижения затрат, заслуживающий внимания и использования отраслью.
Для ценовой войны не нужно писать блоги, для реализации инженерных решений — нужно.