Автор: Сян Сяньчжи
Ло Фулі опублікувала допис у X, щоб закінчити скандал зі зниженням ціни на MiMo від Xiaomi.
26 травня офіційний акаунт Xiaomi MiMo на X опублікував оголошення: серія MiMo-V2.5 API постійно знижує ціни, максимальне зниження — 99%. Усі довжини контексту мають єдину ціну, пакети токенів збільшено в 5–8 разів.
Цей оголошення тиждень поспіль ходило по китайському AI-середовищі. Перша реакція галузі розділилася на кілька лагерів. Найбільший з них стверджував, що це «ще одна хвиля цінової війни» — протягом останніх двох років китайські великі моделі від Zhipu, DeepSeek, ByteDance DouBao та Alibaba Tongyi по черзі знижували ціни, і ніхто не залишився поза цим.
Інша сторона дивиться пессимістично: Xiaomi щойно оголосила, що прибуток за цей рік скоротився наполовину, але все ще вкладає 60 мільярдів юанів у ШІ та відразу зрізає API на 90% — класичний приклад «збиткового захоплення ринку». Хтось вважає, що це продовження ефекту DeepSeek — той самий DeepSeek знизив цінову базу всієї галузі до підлоги, і хто не дотримується — той вибуває.
Тож як керівник MiMo, Ло Фулі вночі безпосередньо оприлюднила технічний блог обсягом 5000 слів, розкривши всім інженерні розрахунки щодо зниження ціни.
Подивіться, це реальна інженерна здатність, а не маркетинговий хід.
Щоб зрозуміти, про що говорить Ло Фулі, спочатку треба зрозуміти, що саме знизилося на 99%.
Це не зниження ціни на повну модель. Знижка 99% стосується лише одного тарифу під назвою Input (Cache Hit) — тобто частини, де користувачі повторно читають історію діалогу у довгих розмовах. Знижка на звичайні нові вхідні дані (No Cache Hit) значно менша, а знижка на вихідні дані моделі (Output) — найменша.
Якщо ти уявляєш модель як кав’ярню, це стає зрозумілішим.
Ви замовляєте лате з півпорцією цукру, і кав’ярня має два способи його приготування: кожного разу знову мелють кавові зерна, додають сироп і молоко — кожен раз витрачаючи сировину та працю; але модель знає, що цього тижня ви щодня п’єте той самий лате з півпорцією цукру, тому готує велику кількість і зберігає її в холодильнику, а потім просто відмірює по одній порції. MiMo зробив саме друге — замінив повторне читання користувачами з «розрахунку на місці» на «отримання з готового»; тому реальна вартість цієї частини майже 0, і природно можна надати знижку 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 архівних працівників відповідають за всю історію. Загальна пам’ять компанії не знизилася, але ефективність зросла в 7 разів.
Проект 2: Зробити простір, зекономлений SWA, справді корисним
На архітектурному рівні зменшення ноутбука до 1/7 — це перший крок, але перетворити «теоретичні 1/7» на «фактичні 1/7» — це ще одна перешкода.
Традиційна система KVCache розподіляє відеопам’ять для всіх шарів за принципом «максимально можливого використання». Це означає: навіть якщо 60 шарів SWA потребують лише звичайного блокнота, система виділяє кожному шару «великий архівний блокнот» — простір, який SWA зекономив, залишається порожнім і не використовується.
Команда Ло Фулі розбила KVCache на два окремі пули. Для повної уваги (Full Attention) 10 шарів використовують «великий пул» з виділенням за повною довжиною; для SWA 60 шарів використовують «малий пул» з виділенням лише за вікном у 128 токенів.
Наприклад, раніше компанія видає кожному співробітнику «архівний шафу, що вміщує 100 років документів» — але 60 співробітників насправді потребують лише «маленької шафи для тижневого обсягу документів», і 99% простору в цих великих шафах залишаються порожніми. Новий підхід — розподіляти шафи згідно з реальними потребами. В результаті в офісі можна розмістити понад у 5 разів більше співробітників — та ж сама GPU може обслуговувати у 5 разів більше одночасних користувачів.
Цей крок здається простим, але без нього переваги попередньої архітектури SWA дорівнюють нулю.
Проект 3: Забезпечити, щоб «повторне читання старими користувачами» справді потрапляло в кеш
Ноутбук знизився до 1/7 + простір реально доступний, наступним кроком потрібно вирішити стару проблему: коефіцієнт потрапляння в кеш префіксів.
Багато діалогів користувачів мають однакове початкове формулювання — однаковий системний запит, однакову бібліотеку коду, однаковий довгий документ. Система зберігає результати, отримані раніше, і при наступному збігові просто повторно використовує їх. Цей механізм називається кешуванням префіксів.
Але в режимі SWA є одна проблема: однакові токени двох запитів не означають, що KV все ще існує. Пріфікс може бути обчислений, але частина за межами вікна SWA вже була видалена. Якщо система продовжить використовувати старе правило «однаковий токен = спрацьовування», ви отримаєте недійсні або перезаписані дані, і ефективність моделі різко впаде.
Команда Luo Fuli оновила правила до «вікна безпечної довжини» — обіцяє лише «ту частину, яку ви можете повністю позичити».
Наприклад, у бібліотеці 1 мільйон книг, і ви хочете позичити повний комплект з трьох томів «Трьох тіл». Стара архітектура повідомить вам: «Ця книга є», ви біжите — а на полиці лише обкладинка й перший том, два інші вже позичені. Така «псевдопопадання» змушує вас марно бігати й повторно запитувати. У новій системі правило змінено: вона обіцяє вам лише те, що може надати повністю — спочатку ви отримуєте перший том, а потім вам доставляють два інші.
Звучить так, ніби стало строгіше і точність знизилася. Але насправді навпаки: через те, що SWA зменшує розмір KVCache до 1/7, у тому самому обсязі пам’яті може розміститися у кілька разів більше даних, і реальна частота успішних звернень значно зростає.
У блозі Ло Фулі наведено реальні цифри: у середньому частота успішного доступу до кешу на сервері в основних фреймворках становить 93%, а у користувачів з високою активністю та довгим періодом використання — понад 95%.
Значення цієї цифри: 95% запитів «повторного читання» взагалі не вимагають обчислень на GPU — дані просто отримуються з кешу. Ось фізична основа знижки 99%.
Проект 4: Встановити «кеш» у вбудований SSD GPU
Точність зросла, наступне питання: де розміщені ці кеші.
Пам’ять VRAM (HBM на GPU) дорога й обмежена — восьмикарточна система H100 має лише 640 ГБ VRAM, але для MiMo потрібно зберігати KVCache у розмірі десятки ТБ. Тому необхідно використовувати ієрархію: найсвіжіші дані зберігаються у VRAM (L1), трохи старіші — у оперативній пам’яті CPU (L2), а холодні дані — у розподіленому кеші (L3).
Це те саме, що керування грошами. Готівка в гаманці — це відеопам’ять — доступна в будь-який момент, але її мало. Баланс банківської картки — це оперативна пам’ять CPU — для зняття потрібно 30 секунд, але можна зберігати багато. Депозит — це L3 розподілений кеш — для зняття потрібно 2 хвилини, але набагато дешевше.
У галузі прийнято створювати окремий кластер сховищ для L3, використовуючи спеціалізоване обладнання та спеціалізовані приміщення з щомісячною оплатою оренди.
Підхід команди зберігання Xiaomi відрізняється. Вони розробили власну розподілену кеш-систему під назвою GCache, яку безпосередньо розгорнуто на SSD, вбудованих у GPU-машини — разом із завданнями навчання та висновку на тій самій машині.
Інші орендували склад, щоб зберігати великий обсяг даних; Xiaomi виявила, що гараж з GPU-серверами порожній, і прямо зберегла дані там. Зекономлено щомісячну орендну плату.
Додаткові витрати на зберігання дорівнюють 0.
Ця справа має більше впливу, ніж здається. У звичайній «обчислювальній таблиці AI-компаній» витрати на зберігання є фіксованими витратами — чим більша ваша модель і чим більше користувачів, тим довший рахунок за зберігання. Підхід 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 може обслуговувати більше користувачів. Інша половина логіки зниження цін полягає саме в цьому — вища ефективність обчислювальної потужності на одиницю та нижчі витрати на одного користувача.
Проект шість: зробити так, щоб модель "друкувала" швидше
П’ять попередніх пунктів оптимізують сторону «читання» — зводячи до мінімуму витрати користувача на повторне читання історичного контексту. Шостий пункт оптимізує сторону «запису» — тобто процес генерації наступного токена моделлю.
Традиційні моделі можуть генерувати лише один токен за раз. 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 дозволяє знизити і цю другу половину витрат, замкнувши таким чином прибуткову модель цілісного зниження цін.
Зв’яжіть шість речей у ланцюжок зниження витрат:
Архітектура SWA → KVCache 1/7 → Дві ємності справді звільняють капацитет → На одному GPU можна розмістити понад 5 разів більше паралельних запитів → Частота спрацьовування кешу префіксів 93–95% → 95% запитів майже не вимагають обчислень → GCache зводить витрати на зберігання до нуля → Менеджер завдань пріоритизує запити з попаданням у кеш → MTP також економить на генерації → Час GPU на запит знижується на порядок → Витрати на одиницю знижуються на 95%+ → Ціна падає на 99%, а маржа залишається позитивною.
Будь-який відсутній етап призведе до розриву ланцюга на одному з ланцюгів. Зниження на 99% — це не маркетингове число, а накопичений ефект шести інженерних опор і реального онлайн-підтвердження.
Поглянувши назад на початкові інтерпретації галузі, кожна з них мала частину правди. Цінова війна між китайськими компаніями великих моделей за останні два роки — це правда;小米 зменшив прибуток наполовину, але все ще інвестує в ШІ — це правда; DeepSeek знизив ціни в галузі до мінімуму — це також правда.
Але, опублікувавши цей технічний блог і детально розібравши технічні деталі, Руо Фулі, безумовно, сподівається відповісти на звинувачення щодо цінової війни, щоб «технічні питання залишилися технічними, а маркетингові — маркетинговими».
В своєму блозі вона написала, що ефективність висновку моделей серії MiMo-V2.5 не є результатом однієї точкової проривної зміни в окремому етапі, а виникла завдяки багатовимірній синергічній оптимізації. Hybrid SWA дозволяє одночасно вигодувати як prefill, так і decode, але неправильно оптимізована реалізація KVCache може збільшити витрати на всіх етапах. З метою досягнення цієї мети команда MiMo системно перебудувала управління KVCache, ієрархічний кеш, дерево кешування префіксів, вирішила ключові проблеми SWA KVCache, оптимізувала стратегії планування та ланцюжки Prefill/Decode, а після перевірки в реальних умовах онлайн-середовища — реально реалізувала теоретичну перевагу ефективності в продуктивному середовищі. Лише тепер Hybrid SWA повністю розкриває свої архітектурні переваги щодо поєднання міцності та ефективності під час довгих висновків. У поєднанні з конфігурацією MoE та різноманітними оптимізаціями багатомодального висновку це значно підвищує продуктивність онлайн-сервісів висновку.
Це системний підхід до AI-інженерії, а також метод зниження витрат, який варто розглянути й індустрії.
Для цінової війни не потрібно писати блоги, потрібно — реалізовувати інженерні рішення.