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

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

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

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

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

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

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

Моделі випускають із точністю 16 бітів. Це 2 GB на мільярд параметрів. Саме тому майже ніхто не запускає моделі з точністю релізу на 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-bit із контекстом 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, поки модель формує відповідь. Ненульові значення 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 RAM

Модель 32B у 4-бітному форматі займає приблизно 19.2 GB, тому вона поміщається на тарифі з 32 GB RAM за короткого контексту та без проблем працює на VPS із 48 GB або 64 GB RAM. Модель 70B у 4-бітному форматі займає приблизно 42 GB, тому їй потрібно 64 GB RAM ще до виділення пам’яті під cache.

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

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

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

Паралельні запити — ще одна причина вибрати більший обсяг пам’яті. Ваги спільно використовуються одночасними запитами, але кожен активний запит потребує власного KV-кешу. Тому для десяти одночасних користувачів моделі 8B з контекстом 8k потрібно в десять разів більше 1 GB кешу додатково до ваг. Обслуговування одночасних користувачів однією 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 одразу резервує цей обсяг пам’яті, навіть якщо кожен надісланий вами prompt містить 200 токенів.

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

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

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

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