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

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

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

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

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

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

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

Моделі випускають із точністю 16 біт, що відповідає 2 GB на мільярд параметрів. Саме тому майже ніхто не запускає моделі у release precision на 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 токенів за секунду. Такі невеликі моделі добре виконують вузькі завдання: класифікацію, вилучення тегів, коротке резюмування та переписування абзацу відповідно до внутрішнього стилю. Вони слабко працюють із багатокроковим міркуванням і кодом, що охоплює кілька файлів. Жодні підказки цього не виправлять.

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

Що працює на VPS із 8–16 GB RAM

Саме на цьому рівні self-hosted модель стає загалом корисною. На VPS із 8 GB RAM можна запускати модель 7B або 8B у 4-бітному режимі. Ваги займатимуть приблизно 4.8 GB. Доступний контекст — 8k. На VPS із 16 GB RAM можна запускати модель 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 за короткого контексту та має достатній запас на 48 GB або 64 GB. Модель 70B у 4 біти займає приблизно 42 GB, тому їй потрібно 64 GB ще до додавання будь-якого кешу.

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

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

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

Для генерації одного токена потрібно один раз прочитати з пам’яті всі активні ваги. Уникнути цього неможливо, тому швидкість генерації на 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 через активність сусідньої віртуальної машини, а не помилка у вашій конфігурації.

Читання промпту — це інша операція, ніж генерація відповіді. Обробка промпту обмежена обчислювальною потужністю, тому вона масштабується за кількістю ядер. Саме тут 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 цього не змінить. Усе, що їх оточує, можна розгорнути на власному сервері: інтерфейс, шар пошуку, цикл агента, журнали. Сама модель залишається віддаленим API. У матеріалі Чи можна розгорнути Claude на власному сервері це питання розглянуто докладно.

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

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

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

free -h
nproc
lscpu | grep 'Model name'

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

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 з витратами на обладнання ще до придбання будь-якого з них.