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