Як запустити Qwen 3.6 27B на VPS через 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 RAM повністю не підходять. На типовому 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 завантажити та як це перевірити

Якщо завантажити тег, якого не існує, система поверне зрозумілу помилку. Тому це можна швидко перевірити безпосередньо на сервері.

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, оскільки файл також містить metadata і таблицю embedding у повній точності.

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

Вартість KV-кешу зі збільшенням контексту

Ваги мають фіксований обсяг. KV-кеш (кеш ключів і значень, стан уваги, який модель зберігає для кожного вже обробленого токена) зростає лінійно разом із довжиною контексту. Саме через нього більшість користувачів фактично вичерпує 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 використовує в останніх щільних моделях цього класу розміру: 64 шари, 8 голів ключів/значень у GQA (grouped-query attention) і розмірність голови 128. Це становить 256 KiB на токен у f16, тобто 8 GB для 32k токенів і 32 GB для 128k. Не покладайтеся на мої розрахунки для власної системи. Завантажте модель і перегляньте стовпець SIZE у ollama ps. У ньому ваги, кеш і накладні витрати вказано одним значенням.

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

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

Що вміщується в 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 cache на headless Linux VPS, якщо для операційної системи та невеликого запасу залишається приблизно 1.5 GB. Нуль означає, що самі ваги не вміщуються, тому не вміщується нічого.

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

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

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

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

Генерація одного токена щільною моделлю означає одноразове читання з пам’яті всіх ваг. Не частини ваг. Усіх ваг. Тому швидкість обмежує не кількість ядер, а пропускна здатність пам’яті, поділена на розмір ваг. Для 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-планах менше значення дає вищу швидкість.

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

Якщо щільна модель 27B працює надто повільно, перед переходом до іншого рішення перевірте теги 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-інференс підходить, коли робота виконується асинхронно й ніхто не чекає на результат: наприклад, нічне узагальнення великої добірки документів або щоденна класифікація, яка запускається, поки ви спите. Орендуйте GPU, щойно людина починає чекати на результат або запити надходять частіше, ніж один раз на 30 секунд. CPU-only сервер не має запасу для пакетної обробки, тому черга просто зростає.

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

Є і третій варіант, про який часто забувають. Залиште 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 — це кількість токенів за секунду під час генерації. prompt eval rate — швидкість prefill. load duration — час читання ваг із диска. Саме тому задано OLLAMA_KEEP_ALIVE=60m: на CPU повторне завантаження 17 GB із диска для кожного запиту коштує більше, ніж саме виконання запиту.

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

ollama ps

Стовпець SIZE показує фактичний обсяг використаної пам’яті разом із KV cache. Він має бути близьким до обсягу ваг плюс значення для вашої довжини контексту в таблиці KV. Для 8192 токенів і 8-бітного 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 означає, що тег відсутній у бібліотеці. Команда qwen3.8:27b дає саме цей результат, як і будь-яка помилка в номері версії. Перевірте тег на сторінці бібліотеки, перш ніж звинувачувати мережу.

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

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

Що насправді дає модель 27B, яка працює лише на CPU

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

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

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

FAQ

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

Ні. Станом на 4 серпня 2026 року в бібліотеці Ollama немає простору імен qwen3.8. Доступні теги 27B — qwen3.5:27b і qwen3.6:27b. Обидва є збірками 27.8-мільярдної щільної моделі у форматі Q4_K_M. Число 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?

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

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

Розділіть пропускну здатність пам’яті на розмір ваг, а потім візьміть 50–70% отриманого значення. VPS із двоканальною DDR4-3200 має теоретичну межу близько 3 токенів за секунду, але фактично забезпечує приблизно 2. Сервер із двоканальною DDR5-4800 має теоретичну межу близько 4.5, але фактично забезпечує приблизно 3. Серверні платформи з більшою кількістю каналів виглядають значно краще на папері, але пропускна здатність пам’яті розподіляється між усіма орендарями хоста. Тому виміряйте власний результат за допомогою 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, що працює постійно, вигідніший.