Які AI-моделі можна розгорнути на власному сервері

Що визначає, які AI-моделі можна розгорнути на власному сервері

Можливість розгорнути певні AI-моделі на власному сервері визначається одним показником: обсягом RAM на сервері. Сімейство моделі та фреймворк мають значно менше значення, ніж те, чи поміщаються ваги в пам’яті із достатнім запасом. У цьому матеріалі наведено розрахунки, які допоможуть це визначити. Встановлення runtime — окреме завдання. Воно описане в посібнику із запуску Ollama на VPS.

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

Розрахунок обсягу: біти на параметр

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

weights in GB = (parameters in billions x bits per weight) / 8

Більшість моделей випускають із точністю 16 бітів. Це 2 GB на мільярд параметрів. Деякі моделі вже частково квантизовані. Наприклад, OpenAI gpt-oss було додатково навчено з вагами mixture of experts у форматі 4 bit MXFP4. У будь-якому разі майже ніхто не запускає ваги з точністю 16 бітів на VPS. Нижче наведено квантизації, з якими ви фактично працюватимете, і їхню реальну середню кількість бітів на вагу:

• Q8_0 зберігає приблизно 8.5 бітів на вагу, тобто близько 1.1 GB на мільярд параметрів.
• Q6_K зберігає приблизно 6.6 бітів, тобто близько 0.83 GB на мільярд параметрів.
• Q5_K_M зберігає приблизно 5.7 бітів, тобто близько 0.71 GB на мільярд параметрів.
• Q4_K_M зберігає приблизно 4.8 бітів, тобто близько 0.6 GB на мільярд параметрів.

Для розрахунків використовуйте 0.6 GB на мільярд параметрів. Q4_K_M — практичний варіант за замовчуванням для сервера з обмеженою пам’яттю: на більшості завдань втрата якості порівняно з 8 бітами невелика, а файл майже вдвічі менший. Нижче 4 бітів втрата якості швидко зростає. Тому модель 70B, стиснута до 2 бітів, зазвичай відповідає гірше, ніж модель 32B із 4 бітами того самого покоління. Якщо пам’яті недостатньо, спочатку перейдіть на менший клас розміру, а не зменшуйте точність нижче 4 бітів.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

У наведеному вище стовпці ваг застосовано правило 0.6 GB на мільярд параметрів. Реальні файли GGUF відрізняються від цього значення лише на кілька відсотків, оскільки шари embedding і output зберігаються з вищою точністю, ніж решта моделі. Модель 3B із 4 бітами займає приблизно 1.8 GB. Модель 8B — 4.8 GB. Модель 32B — 19.2 GB, а модель 70B — 42 GB.

Чому довжина контексту потребує більше RAM, ніж ваги

KV-кеш (key-value cache, стан attention, який модель зберігає для кожного токена в поточному діалозі) — це друга складова витрат. Його виділено під час завантаження моделі. Розмір кешу визначається вказаною довжиною контексту. Кеш зростає лінійно разом із цією довжиною.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

За стандартної для Ollama довжини контексту ця модель 8B використовує для кешу пів гігабайта. За 8192 токенів вона використовує 1 GB. За довжини контексту 128k, яку вказано в її картці, вона використовує 16 GB. Це більше ніж утричі перевищує обсяг ваг. Для 70B ситуація протилежна: її кеш за довжини контексту 128k займає 40 GB, тобто менше за обсяг її ваг. Це можливо завдяки grouped query attention, який не дає вартості на токен зростати майже так само швидко, як кількість параметрів.

Стандартна довжина контексту Ollama на сервері лише з CPU становить 4096 токенів. Якщо доступний GPU, Ollama натомість вибирає значення за замовчуванням на основі VRAM: 32k за обсягу від 24 до 48 GiB і 256k за обсягу від 48 GiB. Збільште це значення за допомогою змінної OLLAMA_CONTEXT_LENGTH на сервері. Потім перевірте, яке значення фактично отримала запущена модель, у стовпці CONTEXT виводу ollama ps. Обчислення використання пам’яті для цього параметра розглянуто в статті про num_ctx і довжину контексту.

Є два способи зменшити обсяг кешу. Запитуйте потрібну довжину контексту, а не довжину, заявлену в картці моделі, оскільки більшість завдань у чаті та програмуванні вміщується в діапазон від 8k до 32k. Або квантизуйте сам кеш до 8 бітів. Це вдвічі зменшує його розмір, але може погіршити відтворення інформації в довгому контексті.

Резидентна модель утримує RAM, доки її не вивантажити

Ollama зберігає модель у пам’яті протягом 5 хвилин після останнього запиту, а потім вивантажує її. Це значення за замовчуванням підходить для ноутбука, але неправильне для сервера: перший запит після кожного періоду бездіяльності знову сплачує час завантаження.

ollama ps
ollama stop qwen3:4b

ollama ps показує, які моделі залишаються в пам’яті. Стовпець SIZE показує обсяг утримуваної пам’яті, а стовпець UNTIL — час завершення цього стану. Щоб назавжди закріпити модель у пам’яті, задайте OLLAMA_KEEP_ALIVE=-1 для сервісу. Значення 0 вивантажує модель одразу після завершення кожної відповіді.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Надішліть один запит, а через десять хвилин знову виконайте ollama ps. Модель усе ще буде у списку. У цьому й полягає суть: вона утримує цю RAM незалежно від того, чи хтось нею користується. Закріплена модель не є вільним ресурсом. На VPS із 16 GB модель 8B із контекстом 8k утримує приблизно 6 GB протягом усього часу роботи сервісу. Тому розраховуйте конфігурацію сервера на модель разом із застосунком, а не лише на модель. У матеріалі Закріплення моделі в пам’яті описано компроміс між цим підходом і затримкою холодного старту.

Що працює на VPS із 4 GB

Зарезервуйте приблизно 1 GB для операційної системи та сервера моделі. Залишиться близько 3 GB. Цього достатньо для моделі розміру від 1B до 4B із точністю 4 біти та стандартним контекстом на 4096 токенів. Станом на August 2026 до цього класу належать Llama 3.2 на 3B, Qwen 3 на 1.7B і 4B, а також невеликі релізи Gemma та Phi. Розглядайте їх як приклади розміру, а не як рекомендації. Назви моделей змінюються кожні кілька місяців, а розрахунок обсягу пам’яті — ні.

Очікуйте приблизно від 6 до 14 токенів за секунду. Такі невеликі моделі добре виконують вузькі завдання: класифікацію, вилучення тегів, короткі резюме та переформулювання абзацу відповідно до стилю організації. Вони погано працюють із багатокроковим міркуванням і кодом, що охоплює кілька файлів. Жодне формулювання prompt цього не виправить.

На цьому рівні основна проблема — swap. Якщо модель не вміщується в пам’ять, Linux не відмовляється завантажувати її. Натомість він переміщує частину пам’яті на диск. Оскільки для генерації кожного токена потрібно один раз прочитати всі ваги, швидкість генерації падає до кількох секунд на токен. Під час відповіді моделі стежте за free -h і стовпцями si та so у vmstat 1. Ігноруйте перший рядок виводу vmstat, оскільки він усереднює показники від моменту завантаження системи. Також пам’ятайте, що ці лічильники охоплюють усю систему, а не лише модель. Якщо показники swap in і swap out дорівнюють нулю, коли сервер простоює, і зростають одразу після початку генерації, модель завелика для цього плану.

Що можна запускати на VPS із 8–16 GB

На цьому рівні self-hosted модель стає загалом корисною. На VPS із 8 GB можна запускати модель 7B або 8B із квантуванням 4 біти. Вона займає приблизно 4.8 GB для ваг і підтримує контекст 8k. На VPS із 16 GB можна запускати модель 13B або 14B із квантуванням 4 біти. Вона займає приблизно 8.4 GB. Інший варіант — залишити модель 8B із точністю 8 біт, якщо важливіша точність, а не кількість параметрів.

Обмеженням є швидкість. Модель 8B на CPU генерує приблизно 3–7 токенів за секунду, а модель 14B — приблизно 1.5–3.5. Людина читає приблизно 5–10 токенів за секунду. Тому модель 8B на CPU VPS працює так, ніби текст повільно набирають вручну. Для фонового завдання цього достатньо, але для інтерактивного чату така швидкість стомлює. Практичні результати запуску Qwen 3 у варіантах 8B і більше на VPS показують, як це виглядає на практиці.

Що працює на VPS із 32–64 GB

Модель 32B у 4-бітному форматі займає приблизно 19.2 GB, тому вона поміщається на тариф із 32 GB за короткого контексту та без проблем працює на VPS із 48 GB або 64 GB. Модель 70B у 4-бітному форматі займає приблизно 42 GB. Це відповідає 43 GB, які Ollama вказує для Llama 3.3 70B у форматі Q4_K_M. Тому така модель поміщається на тариф із 48 GB лише за короткого контексту, а для довшого контексту потрібні 64 GB.

Далі реалістично оцініть швидкість. Модель 32B на CPU працює зі швидкістю приблизно від 0.6 до 1.5 токенів за секунду, а модель 70B — від 0.2 до 0.5. Відповідь обсягом 500 токенів від моделі 70B генерується приблизно 20 хвилин. За такої швидкості запит зазвичай завершується помилкою ще до завершення генерації, оскільки спочатку спрацьовує тайм-аут клієнта або проксі перед Ollama. Саме звідси виникає помилка context deadline exceeded. Це інструменти пакетної обробки. Передайте їм чергу документів на ніч — і швидкість не матиме значення. Розмістіть їх за вікном чату — і швидкість стане критично важливою.

Маршрутизація mixture of experts змінює цей розрахунок. Це єдина архітектурна особливість, яку варто вивчити. Модель MoE пропускає кожен токен лише через невелику частину своїх ваг. Модель із 30B загальних параметрів і 3B активних параметрів на токен потребує обсягу пам’яті, як модель 30B, але генерує майже з тією самою швидкістю, що й щільна модель 3B, оскільки кожен токен обробляється лише активними експертами. На сервері з 32 GB MoE-модель такої конфігурації значно придатніша для роботи, ніж щільна модель 30B. Основне правило: загальна кількість параметрів визначає вимоги до пам’яті, а кількість активних параметрів визначає швидкість.

Наскільки швидкий CPU inference насправді?

Для генерації одного токена потрібно один раз прочитати з пам’яті всі активні ваги. Цього неможливо уникнути, тому швидкість генерації на CPU визначається пропускною здатністю пам’яті, а не кількістю ядер. Гранична швидкість — це пропускна здатність доступної пам’яті, поділена на розмір ваг у байтах. Невеликий shared VPS зазвичай забезпечує 10–25 GB на секунду для всіх своїх vCPU, тому модель розміром 4.8 GB може генерувати не більше приблизно 2–5 токенів за секунду.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Це діапазони, які часто наводять для звичайного обладнання VPS, а не результати тестування одного конкретного сервера. Ваш показник залежить від покоління пам’яті, кількості каналів пам’яті на хості та кількості сусідів, які одночасно конкурують за її пропускну здатність. Виміряйте його самостійно, використавши будь-який тег моделі, який у вас уже є:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Підсумок, надрукований після завершення відповіді, містить рядок eval rate: ... tokens/s. Це швидкість генерації. Не враховуйте перший запуск у межах сеансу, оскільки load duration у цьому ж підсумку також включає читання ваг із диска. У розділі Як правильно вимірювати кількість токенів за секунду описано, як отримати показник, придатний для порівняння.

Тут є два результати, які часто дивують користувачів. Додавання vCPU швидко перестає допомагати, оскільки після приблизно 8 ядер додаткові ядра очікують на пам’ять, а не виконують обчислення. На shared-плані та сама команда може повертати різні показники щогодини. Це CPU steal time через надмірно активного сусіда, а не помилка у вашій конфігурації.

Читання prompt — це інше завдання, ніж генерація відповіді. Обробка prompt залежить від обчислювальної потужності, тому масштабується з кількістю ядер. Саме тут GPU має найбільшу перевагу. CPU читає довгий документ хвилинами, а GPU — секундами. Це перша серйозна перешкода, з якою ви стикаєтеся, підключаючи coding agent до розміщеної вами моделі, оскільки перед кожним запитом повторно надсилаються контекст файлу та визначення інструментів, перш ніж буде згенеровано хоча б один токен відповіді.

Що змінюється після додавання GPU

Арифметика не змінюється, змінюється лише пул, до якого її застосовують. VRAM має жорстке обмеження, тому перед орендою визначте, що саме в неї поміститься:

• 8 GB VRAM достатньо для моделі 7B або 8B у 4 біти за короткого контексту.
• 16 GB достатньо для моделі 14B у 4 біти з практично придатним контекстом або для 8B у 8 біт.
• 24 GB достатньо для моделі 32B у 4 біти, якщо контекст залишається коротким.
• 48 GB достатньо для моделі 70B у 4 біти за помірного контексту. Для довгого контексту та паралельної обробки варто починати приблизно з 80 GB.

Якщо модель не поміщається, Ollama розподіляє її: частина шарів працює на GPU, а решта — на CPU. ollama ps показує цей розподіл у стовпці PROCESSOR, наприклад як 78%/22% CPU/GPU. Сприймайте це як попередження, а не як перевагу. Темп роботи визначає частина на CPU, оскільки кожен токен усе одно очікує на обробку цими шарами. Тому модель, у якої чверть шарів працює на CPU, буде значно ближчою за швидкістю до CPU, ніж до GPU. Якщо бачите розподіл, якого не планували, спочатку зменште довжину контексту. Зазвичай саме cache збільшує вимоги понад доступний обсяг.

Паралельна обробка — ще одна причина вибрати більший обсяг пам’яті. Ваги моделі спільно використовуються одночасними запитами, але для кожного активного запиту потрібен власний KV cache. Тому десять одночасних користувачів моделі 8B із контекстом 8k потребують у десять разів більше 1 GB cache додатково до ваг моделі. Обслуговування одночасних користувачів однією self-hosted моделлю визначає, де буде досягнуто це обмеження.

Потреба в оренді GPU також визначається арифметикою — кількістю токенів, які ви справді генеруєте щомісяця. Точка беззбитковості між GPU VPS і API-токенами містить відповідні розрахунки.

Що не можна розгорнути на власному сервері

Тут є дві різні перешкоди. Важливо визначити, з якою саме ви зіткнулися.

Перша — закриті ваги. Передові комерційні моделі не поширюються, тому файл для завантаження відсутній, і жодний обсяг RAM цього не змінить. Ви можете самостійно розгорнути все, що їх оточує: інтерфейс, шар retrieval, цикл агента, журнали. Сама модель залишається віддаленим API. У матеріалі Чи можна самостійно розгорнути Claude це розглянуто докладно.

Друга — відкриті ваги, які просто надто великі. Найбільші відкриті релізи використовують архітектури mixture of experts із сотнями мільярдів загальних параметрів. Для них діє те саме правило: моделі з 400B загальних параметрів у 4 біти потрібно близько 240 GB лише для ваг, без урахування cache. Для цього потрібне спеціалізоване обладнання, а його оренда на місяць коштує значно дорожче, ніж більшість користувачів витрачає на API-токени за рік. У матеріалі Що потрібно для самостійного розгортання моделі класу Kimi описано реальні вимоги. Такий самий поділ є у власній бібліотеці Ollama: GLM 5.2 доступна лише як cloud-модель, а на VPS фактично завантажується значно менша споріднена модель.

Чесне правило вибору таке: розгортайте модель самостійно, якщо навантаження стабільне, а дані не повинні залишати ваш сервер. Купуйте токени, якщо навантаження нерегулярне або вам справді потрібна якість відповідей передових моделей.

Перевірте доступні ресурси, перш ніж обирати

free -h
nproc
lscpu | grep 'Model name'

Орієнтуйтеся на стовпчик available у free -h, а не на стовпчик total, оскільки total включає пам’ять, яку система вже використовує. Відніміть приблизно 1 GB на операційну систему та сервер моделі. Розділіть залишок на 0.6, щоб отримати найбільшу кількість параметрів у мільярдах, яку можна розмістити за 4 bits. Потім відніміть обсяг KV cache для потрібного вам context. Отримане значення і є відповіддю. На відміну від переліку назв моделей, воно не застаріває.

FAQ

Скільки RAM потрібно для запуску моделі 8B?

Приблизно 4.8 GB для ваг за 4-бітового квантування, плюс KV-кеш для заданої довжини контексту, плюс близько 1 GB для операційної системи та сервера моделі. За контексту 8192 токенів кеш додає приблизно 1 GB, тому тариф із 8 GB підходить, а з 4 GB — ні. Якщо потрібен повний контекст 128k, заявлений у картці моделі, лише кеш займатиме 16 GB, тому знадобиться тариф із 32 GB.

Чому модель працює повільно, хоча VPS має достатньо vCPU?

Тому що швидкість генерації обмежує пропускна здатність пам’яті, а не кількість ядер. Для кожного токена потрібно зчитати весь активний набір ваг із RAM. Коли кілька ядер повністю навантажують канали пам’яті, решта ядер просто очікує. Інша поширена причина — swap. Якщо vmstat 1 показує si і so, що дорівнюють нулю перед надсиланням запиту, а під час відповіді моделі ці значення зростають, найімовірніше, ваги не вміщуються в RAM. Тоді частина кожного токена обробляється з диска, що значно повільніше, ніж може здаватися.

Чи справді довший контекст потребує більше пам’яті?

Так, і обсяг зростає лінійно разом із кількістю токенів. Типова модель 8B використовує близько 128 KiB KV-кешу на токен. Тому 8192 токенів потребують 1 GB, а 131072 токенів — 16 GB. Кеш виділяється під час завантаження моделі, а не в міру зростання розмови. Тому запит на контекст 128k одразу резервує цю пам’ять, навіть якщо кожен надісланий запит містить 200 токенів.

Чи варто запускати велику модель у 2 біти або меншу модель у 4 біти?

Обирайте меншу модель у 4 біти. Якість поступово знижується від 8 до 4 бітів і швидко погіршується нижче 4 бітів. Тому модель 70B, стиснута до 2 бітів, зазвичай дає гірші відповіді, ніж модель 32B у 4 біти з того самого покоління моделей. Сильне квантування проявляється повтореннями та невиконанням інструкцій, а не повідомленням про помилку. Через це проблему легко помилково приписати запиту. Вважайте 4 біти нижньою межею та змінюйте кількість параметрів моделі.

Чи можна самостійно розгорнути модель, здатну конкурувати з найбільшими комерційними моделями?

Не на звичайному VPS. Найпотужніші моделі з відкритими вагами мають сотні мільярдів параметрів. За 4-бітового квантування для них потрібно понад 200 GB RAM ще до виділення KV-кешу. Найпотужніші комерційні моделі взагалі не поширюються для самостійного розгортання. Звичайне обладнання добре підходить для запуску якісної моделі від 8B до 32B для конкретного завдання. У такому випадку вузькоспеціалізована невелика модель із добре сформульованим запитом часто не поступається універсальній. Якщо потрібна якість рівня frontier, порівняйте вартість API з витратами на обладнання, перш ніж купувати будь-який із цих варіантів.