Що сталося

Звична схема знайома кожному, хто ставив локальну модель: файл ваг на диску, потім завантаження у відеопам’ять — цілком або блоками. Для Qwen2.5-7B-Instruct у BF16 це вже близько 15 ГБ; у гігантів на кшталт Kimi-K3 йдеться про трильйони параметрів і терабайти навіть за грубим чотирибітним обліком. Огляд питає інакше: чи можна користуватися мережею, не зберігаючи матрицю як список усіх елементів, а відновлюючи її з компактного опису?

Найпряміший хід — гіпермережа: маленька мережа породжує ваги великої. На Wide ResNet для CIFAR-10 число параметрів падає з мільйонів до часток мільйона, але помилка класифікації зростає. Пізніше з’являються координатні предиктори на кшталт NeRN і Big2Small: на вхід ідуть індекси шару й каналу, на вихід — ядро згортки. На ResNet18 і ImageNet точність майже зберігається (приблизно 71,5% → 71,2%), а файл стискається сильніше, якщо рецепт поєднують із квантизацією — щоправда, затримка виводу в одному з замірів зросла приблизно на 30%.

Далі рецепт укорочують ще сильніше. У Kilobyte Models зберігають зерно генератора (seed) і короткий навчальний латент; для невеликої CNN опис укладається приблизно у два кілобайти за точності, близької до повної моделі на MNIST. SeedLM переносить ідею на вже навчену LLM: у кожного блока ваг своє зерно і коефіцієнти суміші на базі регістра зсуву. На Llama 2-7B невизначеність передбачення (perplexity) на WikiText-2 трохи псується за 3–4 біти на вагу; на Llama 3-70B та сама схема б’є сильніше. Seed-Q і AWSRC додають нерівномірні біти й компактну поправку до вже стиснутої основи — якість підтягується, але «магічного архіватора для будь-якої готової моделі» з цього не виходить.

Чому це важливо

Стиснення на диску й економія робочої пам’яті — різні обіцянки. Можна зберігати рецепт у кілобайтах, а перед проходом усе одно розгорнути щільні ваги й зайняти стільки ж відеопам’яті, як і раніше. Можна генерувати блок, помножити, викинути — пік пам’яті нижчий, зато кожне відновлення додає обчислення. У LLM зверху ще кеш ключів і значень уваги за попередніми токенами: він живе своїм життям і від «красивого рецепта» сам не зникає.

Є й жорстка стеля виразності. Короткий опис за фіксованого декодера обирає лише крихітну частку всіх можливих матриць. Тому Kilobyte Models навчають мережу всередині сімейства, яке генератор уміє відтворювати, а не пакують довільний знімок ваг без втрат. Для розробника, який мріє «запустити LLM на кожному чайнику», як колись гру Doom, це тверезий фільтр: частина робіт дає апаратний виграш на ПЛІС (FPGA), частина — акуратні цифри на ResNet, і майже ніде немає готової відповіді «скачав рецепт — отримав ChatGPT у браузері».

На практиці

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

1. Розділяйте три бюджети: розмір файлу, пік пам’яті під час роботи і ціна відновлення ваг на кожному проході.
2. Не рівняйте «менше навчальних параметрів» і «менше гігабайтів на диску» — у рецепт входять латенти, індекси, масштаби й решта звичайних ваг.
3. Для вже навченої LLM дивіться блокові схеми на кшталт SeedLM: економія локальна, а втрата якості залежить від розміру моделі.
4. Якщо потрібен мінімум на диску без прискорення виводу — це нормальний результат; автори Kilobyte Models прямо пишуть, що обчислення проходу вони не стискають.
5. Перш ніж обіцяти «модель у два кілобайти», перевірте, чи навчалася вона під цей генератор, чи хтось намагається стиснути чужий знімок ваг після навчання.

Підсумок

Ідея рецепта замість повної матриці вже не фантазія: гіпермережі, координатні генератори, зерно і латенти дають реальну компактність на диску й іноді допомагають залізу менше читати пам’ять. Але компактність майже завжди купується якістю, часом відновлення або вузьким сімейством моделей. До «LLM на чайнику» шлях ще довгий — зате мапа, куди дивитися в літературі, на Habr зібрана акуратно.