Чи потрібен VPS із GPU для запуску нейромереж?

Чи потрібен вам VPS із GPU, чи достатньо CPU?

VPS із GPU змінює дві характеристики локального запуску моделі: швидкість генерації токенів і максимальний розмір моделі, що взагалі поміщається в пам’яті. Більше нічого він не змінює. Якщо ваше навантаження — quantized chat model від 7B до 27B, яка відповідає одній людині за раз, embedding job із невеликим обсягом або транскрибування мовлення за допомогою Whisper small, звичайний CPU VPS із достатнім обсягом RAM уже впорається. Почніть із CPU, виміряйте показник, який вас непокоїть, а потім переходьте на потужнішу конфігурацію.

Причина — пропускна здатність пам’яті. Коли language model генерує один токен, вона читає з пам’яті всі потрібні ваги. 8B model, quantized до 4 bits, займає приблизно 4.9 GB на диску й приблизно стільки само в пам’яті, тому генерація одного токена потребує переміщення близько 4.9 GB. Поділіть пропускну здатність пам’яті машини на це число — і отримаєте верхню межу в tokens per second. Цей єдиний розрахунок пояснює майже кожен benchmark, який ви прочитаєте.

Що насправді дає GPU

Пропускна здатність. Серверна DDR5 на сучасному хості передає десятки гігабайтів за секунду. Пам’ять GPU (VRAM, відеопам’ять) передає від сотень до понад тисячі гігабайтів за секунду. Співвідношення цих показників визначає приріст швидкості, і він значний.

Ємність і швидкість. CPU-сервер із 64 GB RAM може завантажити модель 70B у 4-бітному форматі. Вона працюватиме зі швидкістю, ближчою до читання, ніж до діалогу. GPU допоможе лише тоді, коли модель поміщається у VRAM, оскільки після перенесення шарів у системну RAM знову починає працювати повільний шлях.

Пропускна здатність пакетної обробки. Цей аспект часто недооцінюють. GPU, який генерує відповідь для одного користувача, більшість часу простоює, оскільки очікує на дані з пам’яті. Якщо одночасно обробляти 20 запитів, те саме читання ваг обслуговує всі 20 запитів. Сукупна кількість токенів за секунду зростає в кілька разів, тоді як швидкість для окремого користувача майже не знижується. CPU-рушії інференсу, наприклад llama.cpp, також підтримують пакетну обробку; приріст залежить від обладнання та робочого навантаження. Якщо ви створюєте API, до якого звертається багато клієнтів, саме пакетна обробка є головним аргументом на користь GPU, а не вища швидкість обробки одного потоку.

Обробка промпту. Читання довгого промпту обмежене продуктивністю обчислень, а не пам’яті, і саме тут GPU має найбільшу перевагу. Контекст на 30,000 токенів, який CPU обробляє за хвилину, GPU обробляє за кілька секунд. У системах retrieval, які додають документи до кожного запиту, це постійно помітно.

Приблизні значення та як їх інтерпретувати

Фактична пропускна здатність також нижча за результат ділення bandwidth на розмір моделі, оскільки attention під час обробки контексту, що зростає, створює додаткове навантаження, якого просте ділення не враховує.

Для порівняння: дорослі під час мовчазного читання англійською мовою в середньому читають приблизно 4.0–4.3 слова за секунду: 238 слів за хвилину для non-fiction і 260 — для fiction. Швидкість від 15 tokens за секунду вже сприймається одним читачем як звичайний набір тексту. Тому багато конфігурацій, що працюють лише на CPU, цілком придатні для повсякденного використання.

Як розрахувати VRAM перед придбанням

Розмір файлу моделі — це мінімум, а не необхідний обсяг. Врахуйте ваги, KV cache (key-value cache, пам’ять для кожного токена, яку зберігає attention), а також приблизно 1 GB накладних витрат.

Розраховуйте cache окремо, а не додавайте фіксований відсоток, оскільки quantizing ваг не quantize cache. Для кожного токена модель із full attention зберігає key і value для кожного шару та кожної KV head, використовуючи 2 bytes на число у FP16 — це тип cache за замовчуванням в Ollama. Metadata моделі Ollama, перевірені 2026-10-27, вказують для Llama 3.1 8B 32 layers і 8 KV heads по 128 dimensions. Це дає 128 KiB на токен: приблизно 1.07 GB для 8k context і 2.15 GB для 16k. Отже, 4.9 GB 8B model потребує приблизно 7 GB VRAM для 8k і приблизно 8 GB для 16k. 27B model у 4 bits займає близько 17 GB (Gemma 3 27B у бібліотеці Ollama). Metadata Gemma 3 містить sliding window на 1,024 tokens, тому значна частина її cache не збільшується. Плануйте щонайменше 20 GB. 70B model у 4 bits займає приблизно 43 GB (Llama 3.3 70B). Її FP16 cache із 80 layers додає приблизно 2.7 GB для 8k і 5.4 GB для 16k, тому потрібна card на 48 GB із мінімальним запасом або дві менші cards. Той самий розрахунок працює і для значно більших моделей, а розрахунок VRAM для моделі на 2.8 trillion parameters, як-от Kimi K3 показує, коли вибір card узагалі перестає бути головним питанням.

Найбільше це важливо для довгих context. У full-attention models на кшталт Llama 3.1 KV cache зростає лінійно разом із довжиною context і при 128k tokens може перевищити самі ваги. Models зі sliding-window або chunked attention працюють інакше: документація Hugging Face Transformers називає Mistral, Gemma 2 і Llama 4 прикладами, у яких cache відповідних layers перестає зростати після досягнення розміру window або chunk, тому загальний обсяг збільшується повільніше. Якщо ви плануєте використовувати довгі context, спочатку розрахуйте cache і перевірте можливості вашого engine щодо cache quantization. В Ollama OLLAMA_KV_CACHE_TYPE=q8_0 використовує приблизно вдвічі менше пам’яті, ніж стандартний f16, а cache quantization працює лише тоді, коли ввімкнено Flash Attention. Також явно задайте довжину context. Ollama визначає значення за замовчуванням на основі VRAM: 4k для обсягу менше 24 GiB, 32k для 24–48 GiB і 256k для 48 GiB або більше. На card обсягом 48 GB із 70B model це значення за замовчуванням потребує значно більше cache, ніж уміщує card.

Перевірте фактичну конфігурацію машини

На GPU-інстансі спочатку переконайтеся, що драйвер бачить відеокарту.

nvidia-smi

У таблиці мають бути назва GPU, версія драйвера та обсяг використаної пам’яті із загального. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver означає, що NVIDIA-SMI не може звернутися до драйвера. Перевірте, чи встановлено драйвер і чи завантажено його kernel module. У стандартному образі Ubuntu зазвичай потрібно виконати sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, а потім перезавантажити систему, щоб завантажити новий модуль. Для compute-машин документація Ubuntu рекомендує sudo ubuntu-drivers install --gpgpu. Ця команда вибирає гілку server-драйвера.

Для контейнерів самого драйвера недостатньо. Docker потрібен NVIDIA Container Toolkit, щоб передати пристрій у контейнер.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Потім перевірте, що передавання пристрою працює всередині контейнера:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Має з’явитися така сама таблиця. Рядок docker: Error response from daemon: could not select device driver із назвою gpu capability, яку він не може задовольнити, означає, що Docker не знайшов device driver, який відповідає запиту. Перевірте, чи встановлено toolkit, потім повторно виконайте рядок nvidia-ctk і restart. У Compose еквівалентом є запис deploy.resources.reservations.devices, у якому driver має значення nvidia, а список capabilities містить gpu. Цей запис додається до звичайних service definitions, описаних у Docker Compose на VPS.

Вимірювання перед оновленням

Запустіть модель, яку ви плануєте використовувати, на наявному сервері та зафіксуйте показники. У випадку з самостійним хостингом LLM через Ollama на VPS для цього достатньо одного прапорця:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Вивід завершується даними про час виконання. eval rate — це швидкість генерації в токенах за секунду. prompt eval rate показує, як швидко машина обробила ваш вхідний запит. Ці два числа вказують на те, яке саме оновлення допоможе: низький показник eval rate свідчить про обмежену пропускну здатність пам'яті, а низький prompt eval rate на довгих вхідних даних — про недостатню обчислювальну потужність.

На машині з GPU переконайтеся, що модель дійсно завантажилася в пам'ять відеокарти:

ollama ps

У стовпці PROCESSOR має бути значення 100% GPU, якщо модель повністю помістилася, або значення на кшталт 43%/57% CPU/GPU, якщо ні. Часткове розділення моделі зазвичай працює гірше, ніж ви очікуєте, оскільки кожен токен все одно очікує на завершення обробки повільною частиною системи.

Питання вартості

GPU instances оплачуються за час provisioned compute, а не за кількість токенів. Тарифи та плату за зупинені instances встановлює provider. GPU, який постійно працює для кількох запитів на день, більшу частину оплаченого часу простоює. Ключовим фактором беззбитковості є utilization: завантажений GPU має низьку вартість токена, а незавантажений — це прямі втрати.

Є три практичні підходи. Стабільне навантаження з низьким обсягом запитів залишайте на CPU VPS. Поодинокі складні запити надсилайте до hosted API та оплачуйте їх за кількість токенів. Орендуйте GPU погодинно для batch jobs, fine-tuning або масового embedding run, а потім знищуйте instance. Поєднувати ці підходи нормально. Описані в контроль витрат AI agent на always-on VPS правила бюджетування також застосовні, але тут джерелом втрат є простій, а не кількість токенів.

Що все ще добре працює без GPU

Ембединги при невеликих обсягах. Мала модель для ембедингів обробляє сотні коротких документів за хвилину на кількох ядрах CPU, а індекс, який ви будуєте один раз, не потребує високої швидкості.

Whisper small та base для транскрипції. Faster-whisper на CPU транскрибує майже в реальному часі для моделі small, чого достатньо для конвеєра, який працює вночі.

Квантовані чат-моделі розміром приблизно до 27B для одного або двох користувачів. Повільно, але читабельно та придатне для використання.

Будь-що, що можна назвати пакетним завданням (batch job). Якщо ніхто не дивиться на екран, швидкість виконання — це питання планування, а не вимога.

Що дійсно потребує GPU: навчання або донавчання (fine-tuning), окрім невеликих адаптерів, обслуговування багатьох одночасних користувачів, генерація зображень і відео, а також мовлення в реальному часі, де затримка є критичним параметром продукту.

FAQ

Скільки VRAM потрібно для моделі 7B або 8B?

Близько 7 GB для 4-бітної квантизованої моделі 8B з контекстом 8k і близько 8 GB з контекстом 16k, якщо використовується кеш FP16 за замовчуванням в Ollama. Ваги займають приблизно 4.9 GB, KV-кеш додає близько 1.07 GB для 8k або 2.15 GB для 16k, а решта — приблизно 1 GB службових витрат. Відеокарта з 8 GB вміщує модель для 8k, але для 16k запасу майже немає. Відеокарта з 12 GB залишає достатньо місця для довшого контексту. Перемикання кешу на q8_0 приблизно вдвічі зменшує його частку. Якщо ви плануєте використовувати контекст 128k, окремо розрахуйте обсяг кешу, оскільки він може стати більшим за ваги моделі.

Чи можна запускати Ollama без GPU?

Так. Ollama автоматично переходить на CPU і потребує лише достатнього обсягу RAM для завантаження моделі. Для 4-бітної моделі 8B очікуйте приблизно 5–12 токенів за секунду залежно від швидкості пам’яті. Для одного користувача це близько до швидкості читання. Довгі промпти є основною проблемою на CPU, оскільки обробка 30,000 токенів контексту обмежена продуктивністю процесора і займає значно більше часу, ніж генерація відповіді.

Чому моя GPU лише трохи швидша за CPU?

Найчастіша причина — модель повністю не помістилася у VRAM, тому частина шарів виконується на CPU, і кожен токен очікує повільнішу частину обчислень. Запустіть ollama ps і перевірте, чи в стовпці PROCESSOR відображається 100% GPU. Якщо видно розподіл між GPU і CPU, використайте меншу квантизацію або меншу модель. Інша поширена причина — короткий тест, у якому час завантаження моделі переважає над самим вимірюванням.

Чи виправдана GPU VPS для одного користувача?

Зазвичай ні. Середня швидкість мовчазного читання англійською для дорослих становить приблизно 4.0–4.3 слова за секунду. Перш ніж порівнювати CPU-сервер із цією швидкістю, кількість токенів за секунду потрібно перерахувати у слова за секунду. Для одного користувача витрати можуть бути виправдані довгими промптами, генерацією зображень і fine-tuning. Найсильнішим аргументом є одночасне обслуговування багатьох користувачів, оскільки batching дає змогу одній GPU спільно використовувати читання ваг для кількох запитів.

Орендувати GPU погодинно чи використовувати її постійно?

Орендуйте GPU погодинно, якщо навантаження виникає періодично: для fine-tuning, масового створення embeddings або пакетної транскрипції. Постійний запуск виправданий лише тоді, коли відеокарта більшість часу зайнята, оскільки за provisioned GPU compute платять за час, а не за кількість згенерованих токенів. Для асистента з низьким трафіком CPU VPS або hosted API з оплатою за токени дешевші, ніж неактивна GPU.