Xiaomi MiMo знизила ціну на 99% — це не маркетинг! Ло Фулі відповідає критикам у X, спростовуючи їхні прогнози

null

Лю | Сянь Сяньчжи

Ло Фулі опублікувала повідомлення в X, щоб поставити крапку у цій хвилі зниження цін на Xiaomi MiMo.

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

Це оголошення протягом тижня активно обговорювали у внутрішньому AI-середовищі. Реакція галузі поділилася на кілька груп. Найбільша з них вважає, що це "ще один раунд цінової війни" — за останні два роки від Zhituo, DeepSeek, Byte Doudou до Alibaba Tongyi, китайські великі моделі постійно знижують ціни, всі борються за виживання.

Інша група дивиться на це з песимізмом: Xiaomi щойно оголосила про зниження прибутку наполовину цього року, а тут ще AI-інвестиції у 600 мільярдів юанів і 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 зменшився у 7 разів порівняно з Full Attention, обчислювальні ресурси теж зменшилися у 7 разів.

Це перший фундамент зниження витрат. Уявімо: раніше кожен співробітник мав запам’ятовувати всі протоколи наради, але через це його мозок був перевантажений і продуктивність падала. Новий підхід зменшує навантаження на 60 співробітників до 1/7, залишаючи 10 архівних менеджерів для всього історичного контенту — загалом пам’ять компанії не погіршується, але продуктивність зростає у 7 разів.

Другий крок: зробити так, щоб зекономлений простір SWA справді використовувався

Архітектурно зменшення блокнота до 1/7 — перший крок, але потрібно ще перетворити "теоретичне" зменшення у "реальне". Тут є перехідний бар’єр.

Звичайна система KVCache розподіляє пам’ять рівномірно для всіх рівнів за максимальною можливою потребою. Тобто, навіть якщо 60 рівнів SWA потребують лише невеликого блокнота, система все одно резервує великий — і зекономлене місце йде даремно.

Команда Ло Фулі пропонує розділити KVCache на два окремі пулі: для 10 рівнів Full Attention — великий пул, що виділяє пам’ять під всю довжину; для 60 рівнів SWA — малий пул, що виділяє лише 128 токенів.

Уявімо: раніше кожен співробітник отримував "шкаф для зберігання документів на 100 років", але насправді потрібно лише "міні-шафу на тиждень". Новий підхід — розподіляти ресурси відповідно до реальних потреб. Це дозволяє збільшити кількість користувачів у системі у понад 5 разів на одній GPU — тобто одночасно обслуговувати більше клієнтів.

Цей крок здається простим, але без нього переваги SWA були б марною розробкою.

Третій крок: зробити так, щоб повторне читання старих користувачів справді попадало у кеш

Зменшення блокнота до 1/7 і реальне використання цього простору — це добре, але потрібно ще вирішити проблему "попадання у кеш" для префіксів.

Багато користувачів починають діалог однаковим чином — одна й та сама системна підказка, одна й та сама довга документація. Система зберігає ці обчислення, щоб при повторі можна було швидко використовувати їх. Це називається префіксним кешем.

Але у режимі SWA виникає проблема: якщо два запити мають однакові токени, це ще не означає, що KVCache ще актуальний. Можливо, префікс обчислено, але частина за межами вікна SWA вже застаріла і видалена. Якщо система буде вважати, що однакові токени — це "попадання у кеш", вона може отримати некоректні дані, і модель працюватиме неправильно.

Ло Фулі оновила правила: тепер кеш працює лише у межах "безпечної довжини вікна" — тобто, система гарантує, що кешовані дані — це саме ті, що ще актуальні.

Уявімо: у бібліотеці 1 мільйон книг, і ви хочете взяти трилогію "Три тіла". Раніше система казала: "Ця книга є", і ви йшли, але виявлялося, що усього лише обкладинка і перша частина — решта вже взято. Це — "фальшиве попадання", і ви витрачаєте час даремно. Нові правила гарантують, що ви отримаєте лише ті частини, що ще доступні — наприклад, першу книгу, а решту — підгрузять пізніше.

Здається, що це суворіше і зменшує точність, але насправді — навпаки. Оскільки KVCache зменшився у 7 разів, збереження більшої кількості даних збільшує реальну ймовірність попадання у кеш.

У блозі наведено реальні дані: у популярних системах кешування серверів середній рівень попадань — 93%, у високочастотних користувачів — понад 95%.

Що означає цей показник? 95% повторних запитів не потребують обчислень GPU — їх можна просто взяти з кешу. Це — фізична основа знижки у 99%.

Четвертий крок: зберігати кеш у SSD, що належить GPU

Зросла ймовірність попадання у кеш, тепер питання — де його зберігати.

Відеопам’ять (HBM) дуже дорога і обмежена — у H100 восьмикартовій системі всього 640 ГБ. Але KVCache може займати десятки терабайт. Тому потрібно багаторівневе зберігання: найновіше — у швидкій пам’яті GPU (L1), старіше — у системній пам’яті CPU (L2), ще старіше — у розподіленому кеші (L3).

Як у фінансах: готівка — у гаманці (пам’ять GPU), її швидко взяти, але мало; баланс — у банківській картці (пам’ять CPU), взяти — довше, але багато; депозити — у розподіленому сховищі (L3), взяти — ще довше, але дешевше.

Зазвичай для L3 створюють окремий кластер з обладнанням і окремим дата-центром, платять щомісяця.

Команда Xiaomi розробила власну систему GCache — розподілений кеш, що безпосередньо зберігається у SSD GPU — і працює разом із моделями для тренування і inference на одній машині.

Простими словами: інші орендують склад для зберігання великих даних, а Xiaomi зрозуміла, що у GPU-обладнаних серверах цей "гараж" порожній, і просто зберігає дані там. Це — економія на оренді.

У блозі написано: "Додаткові витрати на зберігання — 0".

Це дуже важливо: у звичайних обліках AI-компаній зберігання — це постійний витратний рядок. Чим більша модель і більше користувачів — тим більша ця стаття. GCache зменшує цю статтю до нуля. У поєднанні з малим розміром SWA і точністю кешу 93-95%, час життя KVCache у L3 (TTL) збільшився з кількох хвилин до кількох годин або днів — чим довше TTL, тим ширше вікно для попадання у кеш історичного контексту, і тим вищий кеш-коефіцієнт, а отже — і знижка у 99%.

П’ятий крок: маршрутизація запитів до найкоротшого шляху

Кешування, пошук і дешевизна — це добре, але потрібно ще правильно маршрутизувати запити.

Команда Xiaomi створила власну систему маршрутизації LLM-Router, яка виконує три функції:

1. Аффінна маршрутизація. Запити з однаковим префіксом спрямовуються на одну машину, щоб максимізувати повторне використання кешу.

2. Багатозначне розбиття за довжиною. Короткі запити (0-64К), середні (64-256К), довгі (256К-1М) — у різні канали, щоб короткі не затримували довгі.

3. TTFT-оптимізація. У черзі очікування на inference пріоритет мають запити з меншим обсягом обчислень (тобто ті, що мають високий кеш-коефіцієнт) — щоб не блокуватися через нові, важкі запити.

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

Ця стратегія підвищила кеш-коефіцієнт L2 на 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 справді зменшила прибутки і вкладає у AI; DeepSeek справді знижує цінову планку.

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

У блозі вона пише, що ефективність MiMo-V2.5 не досягнута окремими проривами, а є результатом багатовимірної системної оптимізації. Гібридний SWA дозволяє одночасно покращити prefill і decode, але невдало реалізований KVCache може збільшити витрати. Усе це — системна перебудова управління KVCache, рівнева кеш-пам’ять, дерево префіксного кешу, оптимізація маршрутизації і ланцюгів prefill/decode, що підтверджено реальними сценаріями. В результаті, гібридний SWA отримав архітектурну перевагу у довгих текстах. Комбінуючи MoE і мультимодальні оптимізації, команда значно підвищила продуктивність сервісів inference.

Це системний підхід у AI-інженерії і цінний приклад для галузі у зниженні витрат.

Цінова війна не потребує блогів — потрібна технічна реалізація.