Скільки відеопам'яті потрібно моделі: розрахунок VRAM

Модель на 7 мільярдів параметрів займає 14 ГБ у fp16 або 4 ГБ у 4-бітній квантизації — різниця у 3.5 раза за того самого набору ваг. Купити GPU-сервер, не порахувавши VRAM заздалегідь, — часта помилка: карта або простоює наполовину, або модель не влазить і падає з CUDA out of memory. Розберемо, як порахувати потрібний обсяг точно, а не на око.

Навіщо рахувати VRAM заздалегідь

Відеопам'ять — єдиний ресурс GPU, який не можна розширити на льоту, на відміну від оперативної пам'яті чи диска. Коли модель важить більше, ніж є VRAM, інференс або не запуститься, або драйвер почне вивантажувати шари у системну RAM через --gpu-memory-utilization чи аналог, і швидкість впаде у рази. Розрахунок до купівлі сервера економить і гроші, і час на перезбирання конфігурації.

Правило просте: рахувати потрібно не лише ваги моделі, а й контекст, батч та службові буфери CUDA. Іноді саме контекст «з'їдає» половину карти на довгих діалогах.

Формула розрахунку VRAM для інференсу

Базова оцінка обсягу пам'яті під ваги:

VRAM_GB = (params_billion * bytes_per_param) * 1.2

Коефіцієнт 1.2 — запас на активації, KV-кеш та фрагментацію пам'яті. bytes_per_param залежить від точності: 2 байти для fp16/bf16, 1 байт для int8, 0.5 байта для int4. Для моделі на 13 млрд параметрів у fp16 отримуємо 13 * 2 * 1.2 ≈ 31.2 ГБ — вже не влізе в одну карту з 24 ГБ VRAM.

Окремо додайте KV-кеш: він зростає лінійно з довжиною контексту і кількістю одночасних запитів. Для 7B-моделі з контекстом 8192 токена і одним діалогом кеш займає приблизно 1-2 ГБ, а при десяти паралельних сесіях — уже 10-20 ГБ.

Як квантизація змінює вимоги до пам'яті

Квантизація зменшує точність ваг, але різко знижує обсяг VRAM і майже не псує якість відповідей при 8 і 4 бітах. Нижче — орієнтир для моделі на 7 млрд параметрів.

Для запуску на CPU взагалі без GPU варто подивитися квантизацію GGUF у llama.cpp — там та сама формула працює вже для оперативної пам'яті, а не відеопам'яті.

VRAM для дообучення відрізняється від інференсу

Fine-tuning потребує у 3-4 рази більше пам'яті, ніж звичайний інференс тієї самої моделі, тому що потрібно зберігати градієнти та стан оптимізатора. Повне дообучення 7B-моделі у fp16 займає близько 60-70 ГБ VRAM — це вже кілька GPU. Метод LoRA знімає цю проблему: навчаються лише невеликі адаптерні матриці, а базові ваги лишаються замороженими у 4-бітній квантизації.

Із LoRA та квантизацією QLoRA дообучення тієї самої 7B-моделі вкладається у 10-12 ГБ VRAM — доступно на одній карті середнього класу замість кластера.

Скільки VRAM потрібно популярним моделям

Значення включають запас на контекст 4096 токенів для одного користувача; за зростання навантаження закладайте додатково 10-20% на кожен паралельний потік запитів.

Яку відеокарту обрати під бюджет

Для 7B-моделі у 4-бітній квантизації вистачить карти з 8 ГБ VRAM — завдання для Ollama на VDS з однією споживчою відеокартою. Для 13B у fp16 чи чат-сервісу з кількома одночасними користувачами потрібна карта з 24 ГБ VRAM. Для 70B без квантизації розумної альтернативи кластеру з кількох GPU немає — беріть int4-версію і одну карту з 48 ГБ або розносьте шари по двох картах через vLLM із tensor parallelism.

• До 8 ГБ VRAM — моделі 7B в int4, особисті та невеликі проєкти.
• 16-24 ГБ VRAM — 7-13B у fp16 або 34B в int4.
• 48 ГБ і вище — 70B в int4 або fine-tuning середніх моделей.
• Кілька GPU — 70B у fp16 або навчання з нуля.

Підсумок: як не помилитися з розрахунком

Перед замовленням сервера порахуйте пам'ять за формулою, додайте KV-кеш під реальну довжину контексту та кількість паралельних запитів, а тоді накиньте 15-20% запасу на фрагментацію. Дешевше взяти карту із запасом по VRAM один раз, ніж потім переносити модель і втрачати час на міграцію ваг.

• Визначте кількість параметрів моделі і цільову точність (fp16, int8, int4).
• Порахуйте базовий обсяг за формулою і додайте KV-кеш під контекст.
• Для дообучення закладайте у 3-4 рази більше пам'яті, ніж для інференсу, або застосуйте LoRA.
• Беріть GPU із запасом 15-20% понад розрахунок — на фрагментацію і зростання навантаження.

Часті питання

Що станеться, коли відеопам'яті не вистачить, — модель просто відмовиться запускатися?

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

Чи сильно квантизація погіршує якість відповідей на практиці?

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

Чи потрібно враховувати кількість одночасних користувачів чату під час підбору відеокарти?

Так, кількість одночасних діалогів напряму впливає на обсяг потрібної пам'яті, адже кожен активний запит тримає власний кеш контексту поверх базових ваг моделі. Коли сервіс розрахований на кілька паралельних користувачів, карту варто підбирати із запасом під це, а не лише під поодинокий тестовий запит у консолі під час перевірки перед купівлею сервера.

Чи вдасться запустити дуже велику модель, коли вона не вміщається у відеопам'ять однієї карти?

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