Чому завантаження моделі розміром 17 ГБ не означає, що для її роботи потрібно 17 ГБ пам’яті
Дізнайтеся, як активні параметри, загальна кількість параметрів, зростання кешу KV та зусилля для міркувань визначають реальну вартість пам’яті та обчислень для роботи мовної моделі локально.
Джерела: A 17 GB AI Model Sounds Small. Running It Is a Different Story.
Оголошують про нову відкриту модель — у заголовках стверджується, що вона конкурує з набагато більшими системами, і одна цифра привертає увагу всіх: розмір завантаження становить лише 17 ГБ. Це здається ознакою того, що серйозна допомога у програмуванні стала доступною для звичайної робочої станції, але як тільки ви завантажуєте справжню базу коду чи довге спілкування, процес вичерпує пам’ять. Розмір файлу, кількість активних параметрів та кількість пам’яті, яка насправді потрібна працюючій моделі, — це три різні величини. У цій статті пояснюється, як вони пов’язані, щоб ви могли оцінити справжню вартість запуску моделі перед тим, як планувати обладнання на основі заголовків.
Кількість параметрів — це слабший показник, ніж раніше
Під час порівняння мовних моделей більшість людей спочатку звертають увагу на кількість параметрів. Це цілком логічний підхід: параметри — це навчені ваги мережі, і здається природним, що чим більше їх, тим модель більша, розумніша та дорожча.
Сучасні архітектури значно послабили цю залежність. Одним із перших поворотних моментів стали дослідження DeepMind Chinchilla щодо оптимального для обчислень навчання. Вони показали, що модель з 70 мільярдами параметрів, навчена на значно більшому обсязі даних, може перевершити набагато більші моделі, включаючи Gopher з 280 мільярдами параметрів, якщо обидві використовують приблизно однакову кількість ресурсів для навчання.
Висновок полягав не в тому, що малі моделі кращі. Це було більш нюансово та корисно: спосіб, у який модель використовує свої параметри, може бути настільки ж важливим, як і їхня кількість. Ця ідея стала основою для іншої архітектури, яка зараз домінує у обговореннях ефективних моделей — Mixture of Experts.
Активні параметри проти загальної кількості параметрів
Модель типу Mixture of Experts (MoE) містить багато підмереж-експертів. Замість того, щоб проходити кожен токен через усю мережу, невеликий рутер обирає кількох експертів для кожного токена, і лише ці експерти виконують роботу.
Корисною аналогією є компанія з 100 співробітниками. Для будь-якого запиту клієнта може знадобитися лише п’ятеро з них, тож можна сказати, що п’ятеро людей є „активними“ для цього запиту. Проте компанія все одно змушена утримувати, розміщувати та оплачувати роботу всіх 100 співробітників, адже наступний запит може знадобити інших п’ятьох.
Моделі MoE поводяться аналогічним чином:
- Кількість активних параметрів — це приблизна кількість параметрів, які беруть участь у створенні одного токена.
- Загальна кількість параметрів — це загальна кількість елементів моделі.
Різниця між ними може бути величезною. Відомим прикладом є DeepSeek-V3: загалом близько 671 мільярда параметрів, з яких приблизно 37 мільярдів активуються за кожен токен. Тому генерація одного токена коштує значно дешевше, ніж у моделі з 671 мільярдом параметрів. Однак це не означає, що DeepSeek-V3 у всіх практичних аспектах поводиться як модель з 37 мільярдами параметрів, і саме тут багато порівнянь дають хибні результати.
Витрати на обробку та пам’ять — це окремі бюджети
Кількість активних параметрів є хорошим показником для оцінки обчислювальних витрат: скільки операцій множення та накопичення потрібно для кожного токена, а отже, наскільки швидко можна генерувати токени на певному обладнанні.
Пам’ять — це окремий бюджет. Механізм висновків не може видалити експертів, які не були обрані для поточного токена, оскільки маршрутизатор може вибрати будь-кого з них для наступного токена. Усі вони мають залишатися доступними, зазвичай у GPU або об’єднаній пам’яті, адже завантаження ваг з диска для кожного токена було б надто повільним.
Тож модель може бути дешевою у обчисленні, але все одно вимагати багато пам’яті. Це можна описати за допомогою компактного правила:
Активні параметри показують, скільки обчислень потрібно для кожного токена. Загальний розмір моделі вказує, скільки пам’яті має бути доступною.
Ці два показники пов’язані, але вони відповідають на різні запитання та не можуть замінюватися один одним.
Що насправді міститься у завантаженні розміром 17 ГБ
Ось чому опис „модель ШІ розміром 17 ГБ“ є оманливим. Файл з квантованими вагами справді може мати такий розмір. Квантування дозволяє зберігати кожну вагу у меншій кількості бітів — наприклад, 4 замість 16 — що кілька разів зменшує розмір файлу за рахунок незначних втрат у якості.
Але файл на вашому SSD є лише одним із елементів, необхідних для роботи процесу. Крім нього потрібна пам’ять для:
- ваг, які після завантаження потрапляють у пам’ять,
- власних витрат часу на обробку даних,
- тимчасових буферів, які використовуються під час обчислень,
- контексту, зберіганого у кеші KV,
- та всього того, що вже використовує операційна система та інше програмне забезпечення.
Отже, файл розміром 17 ГБ не означає, що пристрій із 17 ГБ вільної пам’яті зможе комфортно запускати модель або взагалі її запустити, коли обсяг контексту зросте.
Дані, отримані спільнотою щодо Qwen3.8-27B, конкретизують це питання. Квантована версія моделі об’ємом близько 17 ГБ може потребувати значно більше пам’яті після завантаження довгого контексту, а при стандартній довжині контексту моделі у 262 144 токенів сам лише кеш KV стає дуже великим. Щоб зрозуміти чому, потрібно подивитися, як модель запам’ятовує розмову.
Сама розмова займає пам’ять
Трансформер не читає ваш запит один раз та відкидає його. Під час генерації кожного нового токена він звертається до кожного попереднього токена в контексті. Перерахунок внутрішнього представлення всього контексту для кожного нового токена був би надзвичайно повільним, тому двигуни інференсу зберігають проміжні результати замість цього.
Цей механізм — це KV cache, скорочення від key/value cache. Для кожного токена в контексті кожен шар уваги зберігає вектор ключа та вектор значення. Тому об’єм кешу зростає приблизно лінійно з довжиною контексту: модель, яка легко працює з коротким чатом, може стати значно об’ємнішою, якщо до неї подати десятки чи сотні тисяч токенів, наприклад, цілий репозиторій.
Згідно з інформацією про модель Qwen3.8-27B на Hugging Face, ця модель підтримує нативний контекст довжиною 262,144 токенів. Вона використовує гібридну архітектуру, у якій лише деякі шари застосовують традиційну механіку уваги, що саме дозволяє робити використання такого довгого контексту практичним.
Один з аналізів архітектури оцінює обсяг даних KV-кешу у форматі FP16 на кожен токен для шарів, які все ще використовують традиційний кеш, приблизно у 64 КБ. Якщо помножити це на 262 144 токенів, отримаємо приблизно 16,8 ГБ простору KV-кешу, не враховуючи інші елементи. Орієнтовний бюджет пам’яті для сеансу з повним контекстом виглядає так:
- ваги моделі: приблизно 17 ГБ
- KV-кеш у режимі повного контексту: приблизно 17 ГБ
- додаткові витрати пам’яті та буфери: додатково
Модель ніколи не стає програмою розміром 17 ГБ. Ви завантажили 17 ГБ квантованих ваг, а фактичне навантаження може бути приблизно вдвічі більшим або навіть більше. Тут також зрозуміло, чому довжина контексту є ключовим фактором при обмеженій пам’яті: скорочення довжини контексту приблизно вдвічі зменшує обсяг кешу, а багато систем можуть квантувати сам кеш KV для подальшого скорочення обсягу, хоча це призводить до певної втрати точності. Ці дані з спільноти є оцінками; порівняйте їх із даними про використання пам’яті, які надає ваша система.
Як гібридна увага дозволяє ефективно обробляти довгі контексти
Саме архітектура робить ситуацію цікавою. У звичайному трансформері кожен шар уваги має власні записи KV, тому обсяг кешу зростає як з кількістю шарів, так і з кількістю токенів.
Згідно з опублікованими аналізами його архітектури, Qwen3.8-27B використовує гібридний підхід. Із 64 шарів лише відносно невелика кількість використовує повну увагу, тоді як більшість — лінійну увагу. Шари з лінійною увагою узагальнюють минуле до стану фіксованого розміру замість того, щоб зберігати ключі та значення для кожного токена, тому вони не збільшують обсяг кешу. Лише шари з повною увагою мають витрати за кожен токен, саме тому показник за один токен є настільки низьким.
Саме такі хитрощі роблять можливими дуже довгі вікна контексту. Без них пам’ять, необхідна для чверті мільйона токенів, швидко стане непридатною для використання будь-де, крім обладнання дата-центру.
Тож щоразу, коли модель рекламує величезне вікно контексту, поставте додаткове запитання: що робить архітектура, щоб зробити цей контекст доступним? Лише довжина контексту сама по собі нічого не говорить.
Перемога в тесті-бенчмарку — це не загальна перемога
У заголовках новин є ще одна тенденція: модель „перемагає Claude“ чи „перемагає GPT“ у певному тесті-бенчмарку, і робиться висновок, що вона краща в цілому. Тести-бенчмарки оцінюють конкретні завдання за певних умов, і один бал мало що говорить про все інше.
Qwen3.8-27B добре ілюструє це. Опубліковані результати показують високі показники у кодуванні:
- Terminal-Bench 2.1, який тестує роботу в терміналі: 73.0
- SWE-bench Pro, який тестує виправлення реальних проблем у репозиторіях: 61.7
- GPQA Diamond, набір запитань з науки рівня магістратури: 89.2
Якщо порівнювати показники моделей Opus 4.6 Max у рамках однієї таблиці порівняння, результати є неоднозначними. У тесті Terminal-Bench 2.1 Qwen поступається показнику 78,2 у Opus 4.6 Max. У тесті SWE-bench Pro його показник 61,7 є кращим за 53,4 у Opus. У тесті GPQA Diamond його показник 89,2 є нижчим за 91,3.
Яка модель краща? Це залежить від завдання. Робота з терміналом, виправлення помилок на рівні репозиторію та вирішення наукових задач рівня магістратури вимагають різних навичок, так само як і завдання для агентів з довгостроковими цілями. Кожен тест є доказом певної здатності, а не універсальним рейтингом інтелекту.
Методологія також має велике значення. Інструменти оцінки, стратегії формулювання запитань, доступні інструменти, методика оцінювання та налаштування моделі можуть вплинути на результати, а постачальники не завжди тестують конкуруючі моделі за однакових умов. Твердження на кшталт „Модель X краща за Модель Y“ не враховує важливої частини. Точна версія звучить приблизно так:
За цих умов Модель X отримала вищий бал, ніж Модель Y, у цьому тестуванні.
Це менш захоплююче, але набагато корисніше.
Зусилля з міркувань — це прихований множник витрат
Навіть після розуміння параметрів та обсягу пам’яті ще одна змінна може тихо вплинути на вартість запуску моделі: стільки часу вона витрачає на міркування перед відповіддю.
Моделі, орієнтовані на міркування, все частіше пропонують параметр для цього. Qwen3.8 підтримує параметр reasoning_effort із рівнями low, medium та xhigh, причому за замовчуванням обирається xhigh; у його документації ці рівні чітко описані як засоби контролю глибини та витрат на міркування.
Компроміс є простим: більше міркувань може допомогти при складних задачах, але кожен крок міркувань генерує токени — це призводить до більшої кількості обчислень, більшої затримки та, у випадку довгих ланцюгів міркувань, до збільшення обсягу KV-кешу. Тому двоє людей, які використовують однакову модель, можуть мати дуже різні витрати лише через цей один параметр.
Це особливо актуально для агентів, які займаються кодуванням та виконують завдання різного рівня складності. Порівняйте запит на перейменування змінної та запит на дослідження незнайомого репозиторію, пошук архітектурної помилки, зміну шести файлів, запуск тестів, діагностику несправностей та створення патча. Для першого зовсім не потрібен такий рівень міркувань, як для другого. Використання максимальних зусиль для обробки кожного запиту схоже на те, якби ви залучали старшого інженера до обговорення етикетки на кнопці: це працює, але є неефективним використанням ресурсів.
Існує один нюанс, на який вказує й сама документація Qwen. Зниження ресурсів може прискорити виконання кожного окремого кроку, але призвести до більшої кількості спроб чи невдач у багатокрокових завданнях агента, що може скасувати всі переваги. Практичний підхід — вимірювати загальну вартість виконання завдання, а не затримку за кожен крок, та направляти прості та складні завдання до різних налаштувань, якщо це дозволяють інструменти. Жодне окреме налаштування не підходить для всього.
Чому ефективні активні ресурси все ще мають велике значення
Незважаючи на всі ці застереження, легко було б вирішити, що історія про потужні малі локальні моделі — це просто рекламний хіт. Це не так. Прогрес справжній: моделі з невеликим бюджетом на активні ресурси тепер можуть виконувати серйозні завдання з програмної інженерії, які кілька років тому було дуже складно запустити локально.
Єдина корекція, яка потрібна, — це те, що ефективні обчислення не означають автоматично малого використання пам’яті.
Це розрізнення має ще більше значення у масштабах дата-центру. Провайдер, який обслуговує тисячі користувачів, завантажує ваги один раз та ділиться ними між усіма запитами. На відміну від цього, кеш KV належить кожній окремій розмові. Зменшення кількості пам’яті, необхідної для кожної активної розмови, дозволяє прийняти більше одночасних користувачів на тому самому обладнанні, що безпосередньо знижує витрати на обслуговування моделі.
Якщо дивитися з цієї точки зору, архітектурні деталі, які здаються складними науковими трюками, такі як гібридна увага чи стиснення кешу KV, стають важливими економічними факторами. Моделі не обов’язково мають бути маленькими скрізь; їм потрібна ефективність там, де інфраструктура знаходиться під найбільшим тиском.
Коли модель об’ємом 17 ГБ справді є вигідною
Є ще й дуже позитивний аспект. Багато реальних завдань вимагають короткого контексту:
- одного файлу,
- однієї конкретної проблеми з програмуванням,
- невеликого проєкту,
- звичайного чату.
У таких випадках добре квантований модель цієї категорії може справді вразити. Для тестування не потрібен великий хмарний сервер. Ви можете запустити потужну модель на пристрої для споживачів, зберігати свої дані на власному обладнанні та уникати оплати за кожен токен у API під час кожного експерименту. Щоб побачити приклад такої робочої схеми, перегляньте створення локальної копії Angry Birds за допомогою Qwen3.8-27B та Pi.
Це розширює коло людей, які можуть експериментувати з сучасними технологіями штучного інтелекту, що, мабуть, важливіше, ніж те, чи на три бали вищий один показник тестування, ніж інший.
Чотири запитання, які варто поставити замість „Скільки параметрів?“
Наступного разу, коли у заголовку зазначена невелика кількість параметрів або невеликий розмір файлу для завантаження, розгляньте ці чотири запитання.
Скільки параметрів є активними?
Це вказує на обчислювальні ресурси, необхідні на один токен, а отже, приблизно на швидкість генерації моделлю на вашому обладнанні.
Скільки параметрів існує в загалі?
Це вказує на загальний обсяг використання ресурсів та є основним фактором, який визначає кількість пам’яті, необхідної для зберігання ваг моделі.
Яким буде розмір кешу KV?
Це залежить від архітектури та довжини контексту, яку ви плануєте використовувати, і стає провідним фактором при довгих контекстах.
Скільки часу модель витрачає на міркування перед відповіддю?
Це впливає на затримку, споживання токенів та витрати, і його можна налаштовувати для кожного завдання окремо.
Разом ці чотири відповіді розкривають набагато більше інформації, ніж коли-небудь зможе це зробити розмір файлу для завантаження.
Моделі стали ефективнішими, але не обов’язково меншими за розміром
Загальною тенденцією є справжнє підвищення ефективності в усій структурі: кращі стратегії навчання та масштабування даних, краще спрямування обчислень до експертів, краща квантація, кращі архітектури уваги та можливість налаштування процесу міркувань під час виконання завдань.
Жоден з цих факторів не робить ефективні обчислення тотожними малому розміру пам’яті:
- Модель типу MoE може активувати лише частину своїх параметрів на кожен токен, залишаючись при цьому дуже великою мережею.
- Квантована модель може займати невелику кількість місця на диску, але потребувати значно більше пам’яті під час виконання завдань.
- Довге вікно контексту може змусити сам діалог споживати гігабайти пам’яті.
- Вищий рівень міркувань може зробити однаковий запит набагато більш ресурсомістким з точки зору обчислень.
Тож краще запитання — не про те, скільки параметрів має модель. Воно більше схоже на таке:
Скільки пам’яті та обчислювальних ресурсів потрібно для цього конкретного завдання, від завантаження моделі до створення кінцевого токена?
Ключові висновки
- Розмір завантажуваної моделі включає лише її ваги; кеш KV, додаткові витрати під час роботи та буфери збільшують потреби, і при довгому контексті вони можуть подвоїти фактичні вимоги.
- Активні параметри описують обчислювальні ресурси на один токен, тоді як загальна кількість параметрів визначає, скільки пам’яті має бути вільною.
- Розмір кешу KV зростає з довжиною контексту та сильно залежить від архітектури, тому гібридні схеми уваги є важливими для довгих контекстів.
- Переваги в тестах є специфічними для конкретних завдань та залежать від методології; сприймайте їх як „кращі у цій оцінці“, а не як „кращі в цілому“.