Qwen 3.8 27B на VPS без GPU через Ollama

Чи можна запускати Qwen 3.8 27B на VPS без GPU?

Щоб запустити Qwen 3.8 27B на VPS, спочатку потрібно знайти наявний тег моделі. Станом на 4 August 2026 у бібліотеці Ollama взагалі немає запису qwen3.8. Найближчий випущений тег 27B — qwen3.6:27b: 27.8 billion параметрів, квантизація Q4_K_M, ліцензія Apache 2.0. Усі наведені нижче команди й числа використовують цей тег в Ollama v0.32.5, випущеній 27 July 2026.

Коротка відповідь: так, на VPS із 32 GB або більше, але повільно. Для щільної моделі 27B у форматі Q4 потрібно приблизно 17 GB RAM лише для ваг, ще до збереження першого токена контексту. Тому тарифи на 8 GB і 16 GB одразу не підходять. На типовому VPS із двоканальною DDR4 пропускна здатність становитиме приблизно 3 токенів за секунду. Це повільніше, ніж читає більшість людей.

Звідки взялося число 3.8? Найімовірніше, з кількості параметрів. На сторінці Ollama для qwen3.6:27b указано 27.8B параметрів, а число 27.8 легко згодом запам’ятати як 3.8. Також існує qwen3.5:27b — така сама збірка Q4_K_M із попереднього релізу. Перед копіюванням будь-якої команди перевірте актуальний список на сторінці тегів qwen3.6 в Ollama. Якщо пізніше буде випущено справжню qwen3.8, наведені тут розрахунки все одно залишаться актуальними, оскільки вони залежать від кількості параметрів і кількості бітів на вагу, а не від номера версії.

Який тег Ollama завантажувати та як це перевірити

Якщо завантажити тег, якого не існує, з’явиться чітка помилка, тому це можна швидко перевірити безпосередньо на сервері. Тег, який існує, усе одно може не запускатися локально. Саме це часто вводить в оману у випадку з GLM 5.2, який є в бібліотеці, але обслуговується лише з cloud Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show виводить архітектуру, кількість параметрів, довжину контексту та квантизацію фактично встановленого тега. Якщо в рядку параметрів зазначено 27.8B, а в рядку квантизації — Q4_K_M, у вас збірка, для якої написано цей посібник. У бібліотеці також є qwen3.6:27b-q8_0 і qwen3.6:27b-bf16 з тими самими вагами, але з вищою точністю, а також набір тегів 35b-a3b, які є моделями MoE (mixture of experts) і поводяться на CPU зовсім інакше. Нижче наведено докладніші відомості про них.

Кількість параметрів, помножена на кількість байтів на вагу

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Формула має один рядок. Кількість байтів ваг = кількість параметрів * кількість бітів на вагу / 8. За точної ширини 4 біти 27.8 мільярда параметрів займали б 13.9 GB. Розмір опублікованого тегу Q4_K_M становить 17 GB. На практиці це відповідає 4.89 бітам на вагу.

Ця різниця не є помилкою. Формати K-quant не зберігають кожен tensor із номінальною розрядністю. Для tensor, які найбільше втрачають якість під час стиснення, використовують 5 або 6 бітів. Шари token embedding і output зазвичай залишають у форматі Q6_K або Q8_0. Назва формату вказує на середнє значення, а фактичне середнє наближається до 4.9. Такий самий ефект видно на іншому кінці шкали: 56 GB для BF16 відповідає 16.1 бітам на вагу, а не фіксованим 16, оскільки файл також містить метадані та таблицю embedding із повною точністю.

Для цієї моделі немає опублікованого тегу Q5_K_M, тому рядок 19.8 GB обчислено за типовим для цього формату значенням 5.7 бітів на вагу, а не виміряно. Q8_0 майже вдвічі збільшує розмір порівняно з Q4 — до 30 GB. На системі, що працює лише на CPU, це подвоює обсяг передавання даних у пам’яті для кожного token і приблизно вдвічі зменшує швидкість у token per second. Саме тому Q4_K_M є правильним варіантом за замовчуванням. Якщо вам потрібне порівняння якості, а не лише використання пам’яті, детальніше порівняння Q4, Q8 і fp16 показує, на якому етапі якість вихідних даних починає погіршуватися.

Скільки коштує KV cache зі зростанням контексту

Ваги мають фіксований обсяг. KV cache (кеш ключів і значень, стан attention, який модель зберігає для кожного вже обробленого токена) зростає лінійно разом із довжиною контексту. Саме через нього більшість користувачів фактично вичерпує RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Ці цифри ґрунтуються на архітектурі, яку Qwen використовує в останніх dense-моделях цього класу розміру: 64 шари, 8 key/value heads у режимі GQA (grouped-query attention) і розмірність head 128. Це становить 256 KiB на токен у f16, тобто 8 GB для 32k токенів і 32 GB для 128k. Не покладайтеся на мої розрахунки для власної системи. Завантажте модель і перегляньте стовпець SIZE у ollama ps. Він показує ваги, cache і накладні витрати одним значенням.

Саме тому контекст 256K у картці моделі є заголовковою характеристикою, а не практичним планом. Заповнення цього контексту у f16 потребувало б 64 GB cache додатково до вагів, тоді як машина вже використала 17 GB для вагів. Ollama не надає повне вікно за замовчуванням. Вона завантажує значно менше вікно, а ви навмисно збільшуєте його за допомогою OLLAMA_CONTEXT_LENGTH. Ця змінна діє на рівні всього сервера. Водночас налаштування num_ctx для окремого запиту дає змогу залишити невелике значення за замовчуванням для всіх інших запитів і надати більше вікно одному тривалому завданню. Збільшуйте значення поетапно та після кожної зміни перевіряйте ollama ps.

Два параметри зменшують cache щонайменше вдвічі. OLLAMA_KV_CACHE_TYPE=q8_0 зберігає cache у 8 біт замість 16, зменшуючи його обсяг для 32k токенів із 8 GB до 4 GB. Для цього потрібен flash attention, тому також встановіть OLLAMA_FLASH_ATTENTION=1 і підтвердьте зменшення у ollama ps, а не припускайте, що параметр застосувався. OLLAMA_NUM_PARALLEL=1 має таке саме значення. Ollama може одночасно обслуговувати кілька запитів, і кожен слот отримує власну частину контексту. Тому залишений за замовчуванням parallelism непомітно множить обсяг cache, закладений у розрахунок. Якщо цим сервером користуватиметься більше однієї людини, саме це множення створює проблему. Кількість одночасних користувачів, яких може обслуговувати self-hosted модель, визначається слотами cache і довжиною черги задовго до того, як її починає визначати кількість ядер.

Що вміщується в 8, 16, 32 і 64 GB RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Читайте ці два числа як тисячі токенів контексту, які вміщуються разом із вагами за кешу f16 на headless Linux VPS, де для операційної системи та невеликого запасу залишається приблизно 1.5 GB. Нуль означає, що самі ваги не вміщуються, тому не вміщується нічого.

8 GB і 16 GB — це не прикордонні випадки. 17 GB ваг не вміщуються у 16 GB RAM, і жодне налаштування контексту цього не змінить. Додавання swap також не допоможе. Ollama відображає файл GGUF у пам’ять, тому після перевищення обсягу RAM резидентні сторінки ядро починає витісняти та знову читати з диска, і кожен токен завантажує з диска вже гігабайти даних. Сервер працює з високим iowait і генерує значно менше одного токена за секунду.

32 GB — мінімальний практичний обсяг. Ваги займають 17 GB, тому залишається приблизно 13 GB. Цього вистачає приблизно для 32k токенів контексту f16 із запасом. Ваги Q8_0 обсягом 30 GB на цьому рівні взагалі не вміщуються.

64 GB — комфортний варіант. Для Q4 залишається місце приблизно для 128k токенів контексту, а ваги Q8_0 вміщуються разом із приблизно 64k токенами контексту. Перш ніж платити за 64 GB заради Q8, чітко визначте, що саме ви купуєте: трохи кращий результат із удвічі меншою швидкістю на машині, яка й без того працювала повільно. Для більшості користувачів Q4 із довшим контекстом є кращим компромісом.

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

Генерація одного токена з dense-моделі означає одноразове читання кожної ваги з пам’яті. Не частини ваг. Усіх ваг. Тому швидкість обмежує не кількість ядер, а пропускна здатність пам’яті, поділена на розмір ваг. Для Q4 це 17 GB передавання даних пам’яті на токен.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Це граничні значення, а не результати вимірювань. Реальна швидкість зазвичай становить приблизно 50–70 відсотків від наведеного показника, оскільки затримки пам’яті та неповне попереднє завантаження не дають досягти теоретичного максимуму. VPS із двоканальною DDR4-3200 має граничну швидкість 3 токенів за секунду, тому очікуйте приблизно 2. Сервер із двоканальною DDR5-4800 має граничну швидкість 4.5, тому очікуйте приблизно 3.

Для рядків із потужними серверами є важливе застереження. Платформа EPYC із дванадцятьма каналами має пропускну здатність пам’яті 460.8 GB/s і граничну швидкість 27.1 токенів за секунду, але ви не орендуєте цілий EPYC. Пропускна здатність пам’яті є спільним ресурсом усього хоста, яким користуються всі орендарі цієї машини, тому слайс на 8 vCPU не отримує дванадцять каналів ексклюзивної пропускної здатності. У посібниках, орієнтованих на GPU, це часто повністю ігнорують. Саме тому два VPS-плани з однаковою кількістю vCPU можуть відрізнятися за швидкістю втричі на тій самій моделі.

Більша кількість vCPU з тієї самої причини перестає допомагати вже на ранньому етапі. Коли ядра запитують дані швидше, ніж контролер пам’яті може їх передати, додаткові потоки лише збільшують накладні витрати на планування. Встановіть OLLAMA_NUM_THREAD на кількість фізичних ядер, виконайте вимірювання, а потім спробуйте половину цього значення. На багатьох shared-планах менше значення дає вищу швидкість.

Обробка prompt працює інакше. Prefill, тобто прохід за вхідними даними до появи першого токена, більше залежить від обчислень, ніж від пропускної здатності пам’яті, тому його швидкість зростає разом із кількістю ядер. На практиці це означає довгу паузу перед початком виведення для великого prompt, після якої встановлюється повільна стабільна швидкість, описана вище. Вимірюйте обидві частини окремо за допомогою --verbose. Ця команда виводить prompt eval rate і eval rate для кожного запиту.

Якщо dense-модель 27B працює надто повільно, перед відмовою від CPU перевірте теги qwen3.6:35b-a3b. Вони активують приблизно 3 мільярди параметрів на токен замість усіх 27.8 мільярда, тому обсяг передавання даних пам’яті на токен зменшується майже на порядок, хоча файл на диску стає більшим. Ви обмінюєте більший обсяг RAM на вищу швидкість. Вибір runtime також має значення: Ollama і llama.cpp надають різні засоби налаштування CPU поверх того самого базового коду inference.

Коли натомість варто орендувати GPU на годину

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Та сама формула, застосована до опублікованої пропускної здатності пам’яті GPU, дає відповідь іншої категорії. Споживча карта на 24 GB має для цих ваг теоретичну межу 59 токенів за секунду. Сучасна карта для дата-центру досягає 197. Цю різницю не усунути налаштуванням кількості потоків. Пам’ять карти працює зі швидкістю 1008 GB/s, тоді як VPS — зі швидкістю в десятки GB/s.

Тому визначайте межу за характером навантаження, а не за особистими вподобаннями. CPU inference підходить, коли обробка відбувається асинхронно і ніхто не очікує на результат: наприклад, нічне узагальнення набору документів або нічне завдання класифікації, яке виконується, поки ви спите. Орендуйте GPU, щойно людина починає очікувати на результат або запити надходять частіше, ніж один раз на 30 секунд. CPU-only сервер не має запасу для batching, тому черга просто зростає.

Порівняння вартості не таке очевидне, як може здатися. VPS на 64 GB оплачується за кожну годину місяця незалежно від того, завантажена модель чи ні, тоді як GPU instance оплачується лише за години роботи. Якщо фактичне використання становить 2 години на день, орендований GPU може бути водночас швидшим і дешевшим. Спочатку визначте duty cycle, а потім розрахуйте вартість. У матеріалі Як вибрати VPS із GPU описано, що перевірити безпосередньо в instance, а vLLM випереджає Ollama під час обслуговування паралельних запитів на GPU пояснює перевагу vLLM завдяки коректному batching.

Є і третій варіант, про який часто забувають. Залиште 27B на CPU для пакетної обробки, а перед інтерактивним контуром розмістіть hosted API model. Ніщо не вимагає, щоб одна модель обслуговувала обидва сценарії.

Встановіть Ollama та виміряйте продуктивність власного сервера

Скрипт встановлення є офіційним і налаштовує службу systemd, яка працює від імені окремого користувача ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

Команда ollama --version має вивести 0.32.5 або новішу версію. Перевірте free -g, перш ніж щось завантажувати. Якщо у стовпці total у рядку Mem указано менше ніж 32, зупиніться та виберіть меншу модель. Завантаження 17 GB моделі, яку ви не зможете запустити, витратить годину часу й багато дискового простору.

Задайте параметри середовища виконання в override-файлі systemd, а не у своїй оболонці. Модель працює всередині служби, тому не бачить ваше інтерактивне середовище.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Вивід --verbose містить потрібні результати вимірювання. eval rate — це швидкість генерації в tokens per second. prompt eval rate — швидкість попереднього заповнення. load duration — час, потрібний для читання ваг із диска. Саме тому встановлено OLLAMA_KEEP_ALIVE=60m: на CPU повторне завантаження 17 GB із диска для кожного запиту коштує більше, ніж обробка самого запиту. Стандартний тайм-аут простою становить п’ять хвилин. Цього недостатньо для пакетної черги з паузами між елементами, тому витрати на завантаження повторюються знову й знову. Параметри утримання моделі в пам’яті охоплюють поле keep_alive для окремого запиту та налаштування, яке зберігається після перезавантаження.

Поки модель завантажена, перевірте використання пам’яті з другого термінала.

ollama ps

Стовпець SIZE показує фактичний обсяг пам’яті, включно з KV cache. Він має бути близьким до обсягу ваг плюс значення в рядку для вашої довжини контексту в таблиці KV. Для 8192 tokens і 8-bit cache очікуйте приблизно ще один гігабайт понад обсяг ваг. Якби cache залишався у форматі f16, це було б 2 GB. У стовпці PROCESSOR має бути значення 100% CPU. Якщо вказано інше значення, якийсь процес використовує GPU, і наведені в цьому посібнику показники швидкості не описують ваш сервер.

Типові збої та точні рядки, які ви побачите

Модель відмовляється завантажуватися. Ollama виводить рядок із назвами обох значень у форматі model requires more system memory (18.6 GiB) than is available (15.2 GiB). Це прийнятний варіант збою, оскільки Ollama виконав перевірку до виділення пам’яті, а не передав проблему ядру. Зменште довжину контексту, виберіть менший тег або перейдіть на тарифний план із більшими ресурсами.

Процес завершується посеред відповіді. Клієнт не показує нічого корисного, а journalctl -u ollama -n 50 показує, що сервіс перезапускається. Виконайте dmesg -T | tail. Рядок із текстом Out of memory: Killed process ... (ollama) означає, що процес завершив kernel OOM killer. Це відбувається, коли попередня перевірка завантаження пройшла успішно, але під час тривалої розмови кеш перевищив розрахунковий обсяг. Зменште довжину контексту.

Завантаження моделі одразу завершується помилкою. Error: pull model manifest: file does not exist означає, що тега немає в library. Виконання qwen3.8:27b дає саме цей результат. Те саме станеться через будь-яку помилку в номері версії. Перевірте тег на сторінці library, перш ніж звинувачувати мережу.

Усе працює, але система працює нестерпно повільно. Швидкість менше одного токена за секунду на системі з достатнім обсягом RAM вказує на paging, а не на нестачу обчислювальної потужності. Виконайте vmstat 1 під час генерації. Ненульове значення у стовпці si або so означає, що kernel використовує swap. Зменште контекст або кількість завантажених моделей. Стабільно високе значення wa без активності swap означає, що memory-mapped weights повторно зчитуються з диска. Це означає, що вони фактично не вміщуються в пам’ять.

Перший токен з’являється через 30 секунд, після чого виведення пришвидшується. Це prefill, і така поведінка є нормальною. Довгий system prompt обробляється для кожного запиту, який не використовує кеш. Спочатку скоротіть system prompt, а вже потім змінюйте інші параметри.

Для чого насправді придатна модель 27B лише на CPU

Оцінюйте можливості за цифрами, а не за сподіваннями. За швидкості від двох до чотирьох токенів за секунду відповідь на 500 токенів займе від двох до чотирьох хвилин. Для чату це неприйнятно, але для черги завдань цілком придатно. Модель, яка міркує перед відповіддю, працює ще повільніше, оскільки приховані токени міркування генеруються з такою самою низькою швидкістю, як і відповідь. Тому узгодження рівня зусиль під час міркування із завданням — один із небагатьох способів скоротити час відповіді без заміни моделі. Узагальнення документів, масове додавання тегів, вилучення полів із черги файлів і фоновий аналіз коду добре переносять таку швидкість, оскільки ніхто не чекає на відповідь. Допомога під час написання коду перебуває саме на межі. Тому підключення coding agent до моделі, яку ви розгортаєте самостійно, виправдане для фонових завдань, наприклад створення повідомлень комітів і каркасів тестів, але не для вбудованих підказок, на які ви чекаєте в реальному часі.

Аргумент щодо приватності є головним. Модель працює на обладнанні, яке ви орендуєте та контролюєте. Жоден запит не залишає цей сервер, а плата за кожен токен відсутня. Для регульованих даних це має велику цінність навіть за швидкості три токени за секунду. Чесно порівнюйте цей варіант з альтернативою: для self-hosting моделі frontier-класу потрібне на порядок потужніше обладнання, а 27B на CPU — найдешевша точка на цій кривій, за якої результат усе ще варто читати.

Щоб перевірити будь-який із цих сценаріїв, потрібні реальні структуровані дані. Більшість публічних data API вимагає обліковий запис ще до того, як ви зможете виміряти пропускну здатність. Demo endpoint Strasmore (ми його підтримуємо) виконує read-only SQL-запити до даних ринку США за 22 роки без ключа та реєстрації: GET-запит до https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 повертає JSON, який можна безпосередньо передати в prompt loop. Разом із даними повертається точний SQL-запит, що їх сформував, тому модель має що узагальнювати, а результат можна незалежно перевірити. Обмеження становлять 500 рядків і 20 секунд на виклик. Цього з запасом достатньо для системи зі швидкістю два токени за секунду. Повний список стовпців наведено за адресою https://api.strasmore.com/v1/schema.

Якщо ви вперше встановлюєте Ollama, повний посібник із запуску Ollama на VPS описує налаштування сервісу, HTTP API і правила firewall, які в цьому посібнику вважаються вже налаштованими. Не відкривайте порт 11434 для інтернету. Ollama не має власної автентифікації, тому будь-хто, хто отримає доступ до цього порту, зможе використовувати вашу модель і читати ваші prompt-и.

FAQ

Чи є модель Qwen 3.8 27B в Ollama?

Ні. Станом на 4 серпня 2026 року в бібліотеці Ollama немає простору імен qwen3.8. Доступні теги 27B — це qwen3.5:27b і qwen3.6:27b, обидва є збірками Q4_K_M щільної моделі з 27.8 мільярда параметрів. Число 3.8 у пошуковому запиті майже напевно є кількістю параметрів 27.8B, яку запам’ятали як номер версії. Перевірте https://ollama.com/library/qwen3.6/tags, щоб переглянути актуальний список, і виконайте pull qwen3.6:27b, якщо потрібна найновіша випущена модель 27B. Неіснуючий тег завершується помилкою Error: pull model manifest: file does not exist.

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

32 GB — практичний мінімум для Q4_K_M. Ваги займають 17 GB, операційній системі потрібно приблизно 1.5 GB, а KV cache додає близько 1 GB на кожні 4000 токенів контексту у форматі f16. План на 16 GB взагалі не вміщує ваги, а swap не допомагає, оскільки файл відображається в пам’ять, і kernel повторно читає його з диска для кожного токена. 64 GB дають змогу використовувати довгий контекст або ваги Q8_0 розміром 30 GB.

Скільки токенів за секунду видаватиме модель 27B на CPU?

Розділіть пропускну здатність пам’яті на розмір ваг, а потім візьміть 50–70 відсотків отриманого значення. VPS із двоканальною DDR4-3200 має теоретичну межу близько 3 токенів за секунду й забезпечує приблизно 2. Система з двоканальною DDR5-4800 має теоретичну межу близько 4.5 і забезпечує приблизно 3. Серверні платформи з більшою кількістю каналів виглядають значно краще на папері, але пропускна здатність пам’яті спільно використовується всіма tenant на host. Тому виміряйте власний показник за допомогою ollama run qwen3.6:27b --verbose і прочитайте рядок eval rate.

Використовувати Q4 чи Q8 на VPS лише з CPU?

Q4_K_M — майже в усіх випадках. Q8_0 займає 30 GB проти 17 GB, тому потрібен план на 64 GB. Він також переміщує майже вдвічі більше даних пам’яті на кожен токен, що приблизно вдвічі зменшує кількість токенів за секунду. Для більшості завдань різниця в якості між Q4_K_M і Q8_0 у моделі 27B невелика. Краще використайте RAM для довшого контексту, оскільки це змінює можливості моделі, а не лише спосіб формулювання відповідей.

Коли оренда GPU дешевша за VPS із великим обсягом RAM?

Коли коефіцієнт використання низький або коли на результат чекає людина. GPU з 24 GB пам’яті досягає приблизно 59 токенів за секунду на цих вагах, тоді як типовий VPS забезпечує 2 або 3. GPU оплачується лише за години роботи. VPS із 64 GB оплачується весь місяць незалежно від того, завантажена модель чи ні. Визначте, скільки годин на день ви справді генеруєте токени. Якщо це менше двох або трьох годин, погодинна оренда GPU зазвичай вигідніша і за швидкістю, і за вартістю. Для безперервної пакетної обробки з низьким пріоритетом вигіднішим буде постійно увімкнений VPS.