Розгорніть Ollama на LLM-сервері самостійно та візьміть під контроль цензуру ШІ

Ключові слова

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

Чому варто самостійно розгортати LLM

Якщо ви вже зробили найскладніше — орендували GPU-сервер, встановили Ubuntu, розібралися з SSH та підтримуєте власні служби в робочому стані — то швидко починає дратувати те, що хмарний ШІ все одно контролює останній відрізок. Він може відмовити у цілком звичайному запиті, заховати відповідь за застереженнями, без попередження змінити стиль відповідей та передавати кожен запит через чиїсь обмеження. Для багатьох технічних користувачів саме в цьому і полягає справжнє розчарування: не стільки в тому, що говорить модель, а в тому, хто контролює шар обслуговування, коли вона це робить.

Цей посібник присвячений вирішенню цієї проблеми за допомогою відкритих та локальних моделей, а не трюкам для обходу пропрієтарних API. Ви самостійно розгорнете Ollama на Ubuntu GPU-сервері, запустите інференс локально, перевірите, що шлях через GPU є реальним, і побачите, що змінюється, коли ви обираєте іншу сімейство моделей. Одна хибна думка, яку варто розвіяти одразу: самостійне розгортання не означає автоматично необмеженість. Це означає, що ви контролюєте значно більшу частину стека — і перестаєте залежати від шляху обслуговування під контролем постачальника — але модель, яку ви запускаєте, може все одно мати власну поведінку вирівнювання.

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

Після завершення у вас буде працюючий сервіс Ollama на Ubuntu, перевірений локальний API за адресою 127.0.0.1:11434, підтвердження того, що інференс із підтримкою GPU дійсно відбувається, та обґрунтоване порівняння між популярною вирівняною моделлю та менш обмеженою альтернативою. Цей посібник розрахований на читачів, які добре знайомі з SSH, Ubuntu, sudo та systemd, але не мають попереднього досвіду роботи з Ollama.

Конкретний Ubuntu GPU-сервер, використаний у цьому посібнику

Цей посібник прив’язаний до реальної однопроцесорної Ubuntu-машини з одним GPU, оскільки розпливчасті поради «має працювати на більшості серверів» — це те, від чого посібники із самостійного розгортання стають оманливими. Еталонна машина тут — це фактичний клас хоста, використаного для цього посібника: тип машини, яку просунутий індивідуальний користувач, лабораторія або невелика команда дійсно б орендували, коли хочуть приватний локальний інференс, не переходячи одразу до стійки корпоративних прискорювачів. Далі буде обговорено поведінку з кількома GPU, оскільки Ollama змінюється, коли модель не вміщується на одній карті, але сприймайте цю частину як контекст на майбутнє, а не як доказ із цього конкретного сервера.

GPU-сервер — Ryzen 9 3950X + RTX 4070 Ti Super

На практиці це дуже потужне налаштування для повсякденних моделей класу 8B і все ще корисне для більших локальних завдань аж до моменту, коли 16GB VRAM стає реальним обмеженням. Модель на кшталт llama3.1:8b приблизно з 4.9GB легко вміщується на цій карті. Модель на кшталт gpt-oss:20b приблизно з 14GB — це той тип тесту верхньої межі для одного GPU, який все ще має сенс тут. Модель на кшталт qwen3:30b приблизно з 19GB краще сприймати як орієнтир того, що змінюється на більшому або двопроцесорному хості з GPU, а не як чисте вміщення на цій конкретній машині.

Це розмежування важливе, оскільки мета цієї статті — не втиснути найбільше можливе число в заголовок. Мета — показати, як виглядає розумний самостійно розгорнутий LLM-сервер, коли вам потрібна конфіденційність, локальний контроль і достатньо пам’яті GPU для запуску корисних моделей без постійних компромісів. Саме цей клас обладнання робить самостійний інференс реалістичним, а не теоретичним.

Це також пояснює кілька рішень, які ви побачите далі: mistral використовується спочатку, оскільки вона дає швидке та нескладне підтвердження того, що стек працює, тоді як порівняння поведінки залишається в класі 8B, де ця машина почувається комфортно. qwen3:30b все одно з’являється пізніше, але як теоретичний приклад типу моделі, яка може запустити розміщення на кількох GPU на більшому хості, а не як живий доказ із цього сервера. З урахуванням цих очікувань, наступний крок — перевірити хост перед встановленням Ollama.

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

Почніть з nvidia-smi. Якщо ця команда відсутня або не виконується, зупиніться і спочатку виправте драйвер NVIDIA. Не встановлюйте Ollama, оскільки несправний стек NVIDIA змусить кожен подальший симптом виглядати як збій застосунку, тоді як насправді це збій платформи.

Спочатку виконайте перевірку GPU:

❗Якщо Ubuntu повідомляє, що nvidia-smi відсутній, не припускайте, що сервер не має GPU. Поширена проблема на орендованих Ubuntu-машинах полягає в тому, що карта присутня, але все ще прив’язана до nouveau замість драйвера NVIDIA. Спочатку перевірте розділ «Виправлення проблеми з драйвером Nvidia на Ubuntu».

Справний результат на цьому класі серверів має виглядати приблизно так:

Після того як nvidia-smi працює і GPU видимий, продовжте наведені нижче перевірки.

Що вам потрібно підтвердити — це просто: встановлений GPU видимий, він відображає приблизно 16GB VRAM на цьому хості, і драйвер завантажений коректно. Якщо ви на багатопроцесорному GPU-сервері, та сама команда має відображати кожну карту.

❗ Важливо: Актуальна документація підтримки GPU для Ollama використовує NVIDIA driver 531+ як реальний мінімум для підтримуваного інференсу NVIDIA. Вважайте 531+ вимогою для цього посібника, навіть якщо ви бачили старіші нотатки спільноти з нижчими версіями.

Тепер переконайтеся, що хост дійсно є середовищем Ubuntu, яке передбачає цей посібник:

Нарешті, перевірте вільний дисковий простір перед тим, як починати завантаження моделей. Сам інсталятор займає небагато; моделі — ні. Коли ви вийдете за межі невеликих тестів, бібліотека моделей 20B–30B може швидко з’їсти десятки гігабайт, тому 100GB+ вільного простору — правильний підхід перед серйозною роботою з локальними моделями.

Якщо ці перевірки пройдені, ви усунули основні невідомі інфраструктури: GPU присутні, базовий рівень драйвера в нормі, Ubuntu підтверджено, і на диску є місце для реального завантаження моделей. Саме в цей момент встановлення Ollama стає чистим наступним кроком, а не здогадкою.

Виправлення проблеми з драйвером Nvidia на Ubuntu

Виконайте наведені нижче кроки, щоб виправити проблеми з командою «nvidia-smi».

Якщо у виводі відображається карта NVIDIA та рядок на кшталт Kernel driver in use: nouveau, встановіть рекомендований пакет драйвера Ubuntu замість встановлення лише nvidia-utils.

Встановіть пакет ubuntu-drivers-common (необхідний для керування драйверами) та заголовки ядра для вашого поточного ядра.

Скануйте систему та перегляньте список доступних пропрієтарних драйверів (наприклад, драйверів NVIDIA GPU), які можна встановити.

Потім встановіть рекомендований пакет драйвера. У нашому випадку це: nvidia-driver-595-open:

Після перезавантаження повторно виконайте:

Встановлення Ollama та перевірка справності служби

Підтримуваний шлях для Ubuntu — офіційний інсталятор Ollama, а не спеціальний потік через tarball і не обхід через Docker. Це важливо, оскільки цей посібник спрямований на отримання надійної локальної служби з передбачуваними налаштуваннями за замовчуванням, інтеграцією systemd та коректною поведінкою щодо прав власності в Linux.

Запустіть інсталятор точно так, як описано в документації:

На справній системі скрипт встановлює бінарний файл, створює службового користувача ollama, додає правильні членства в групах за наявності, записує модуль systemd і запускає службу, прив’язану до 127.0.0.1:11434.

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

Тут ви шукаєте три речі: файл модуля присутній, служба увімкнена для завантаження та Active: active (running) підтверджує, що сервер дійсно запущений.

Спочатку конкретно встановіть обліковий запис службового користувача Linux, і лише після цього подумайте про те, як і де буде керуватися зберігання моделей.

Цей єдиний рядок пояснює багато майбутньої поведінки. Моделі в Linux зберігаються під власністю служби, і якщо ви пізніше перемістите їх на інший диск без виправлення прав для користувача ollama, ви самі спричините проблему.

Ще одна перевірка завершує цикл щодо прив’язки за замовчуванням:

⚠️ Попередження: Ollama за замовчуванням не вимагає автентифікації для локального API. Це нормально, коли він прив’язаний до 127.0.0.1, але відкривати порт 11434 безпосередньо в інтернет як захищену публічну службу небезпечно.

Якщо служба не запускається коректно, спочатку зверніться до журналів, а не перевстановлюйте все наосліп:

Це найшвидший спосіб виявити проблеми з правами доступу, помилки запуску, проблеми виявлення драйверів або проблеми прив’язки. Після того як служба справно працює на localhost, наступне, що потрібно зрозуміти, — це поведінка розміщення на GPU під час виконання.

Як Ollama насправді використовує один або кілька GPU

Хоча сервер, використаний у цьому посібнику, має один GPU, поведінку з кількома GPU все одно варто розуміти, оскільки багато користувачів можуть працювати на більших машинах або планувати розширення в майбутньому. Багато плутанини з двома GPU починається з хибних очікувань: «У мене дві карти, тож обидві мають постійно працювати». Саме так Ollama не працює. Практичне правило значно простіше: якщо модель вміщується на одному GPU, Ollama зазвичай тримає її на одному GPU. Він розподіляє навантаження між кількома GPU лише тоді, коли модель не вміщується комфортно на одній карті.

Використовуйте ці дві перевірки разом, щоб побачити продуктивність GPU:

ollama ps показує, як обробляється завантажена модель. 100% GPU означає, що модель повністю розміщена в пам’яті GPU. 100% CPU означає, що апаратне прискорення GPU не використовується. Змішаний стан означає, що частина навантаження або розміщення вийшла за межі шляху GPU. watch -n 1 nvidia-smi доповнює це, показуючи в реальному часі використання VRAM на кожній карті під час завантаження моделі.

Найшвидший спосіб зрозуміти ці ролі такий:

📝 Примітка: CUDA_VISIBLE_DEVICES — це засіб контролю видимості, а не перемикач «використовувати обидва GPU». Якщо вам коли-небудь потрібно обмежити доступ до GPU, надавайте перевагу UUID з nvidia-smi -L над числовими ідентифікаторами, оскільки порядок GPU може змінюватися між середовищами та після перезавантажень.

Запустіть свою першу локальну модель і перевірте інференс на GPU

На цьому етапі вам не потрібна величезна модель, щоб довести, що сервер працює. Вам потрібен швидкий, чесний успіх. mistral — хороший перший вибір для завантаження, оскільки вона невелика, швидко завантажується і легко запускається, навіть попри те, що llama3.1:8b буде пізніше базовою лінією для порівняння поведінки.

Почніть із завантаження моделі:

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

Щоб довести, що це інференс із підтримкою GPU, а не резервний варіант із CPU, перевірте стан виконання:

А щоб побачити, що вже є на диску, перегляньте локальний інвентар:

mistral — правильний перший доказ, оскільки вона дає швидку відповідь, не перетворюючи перевірку налаштування на тривале очікування. Пізніше llama3.1:8b стає кориснішою, оскільки є більш потужною вирівняною базовою лінією для порівняння поведінки моделей.

Нарешті, перевірте, де інсталяція Linux зберігає моделі:

Цей шлях — /usr/share/ollama/.ollama/models — є стандартним сховищем моделей Linux, задокументованим Ollama.

Після того як ви побачите успішну відповідь, 100% GPU в ollama ps та збільшення використання диска в очікуваному місці, у вас буде перший вагомий доказ того, що локальний стек працює.

Доведіть, що це сервер, а не просто обгортка CLI

Командний рядок — це зручно, але причина самостійного розгортання Ollama полягає не лише в тому, щоб спілкуватися в терміналі. Мета — запустити локальний сервер інференсу, який інші інструменти, скрипти та застосунки можуть викликати, не надсилаючи запити через чужу межу API. Найшвидший доказ — один чистий HTTP-запит до нативного endpoint’у Ollama.

Надішліть локальний запит generate з вимкненим потоковим режимом, щоб першу відповідь було легше перевірити:

Успішна відповідь має повернутися у форматі JSON і виглядати приблизно так:

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

Контрольний список успіху простий: HTTP-запит працює локально, повертається коректний JSON, присутній done: true, і відповідь моделі знаходиться в response. Саме в цей момент Ollama перестає бути «CLI, який просто завантажує моделі» і стає інфраструктурою, яку ви можете реально інтегрувати в локальні інструменти та автоматизацію.

Якщо вам потрібна сумісність із програмним забезпеченням, яке очікує формат запиту у стилі OpenAI, Ollama також надає локальні endpoint’и /v1:

📝 Примітка: Мітку «OpenAI-compatible» легко неправильно зрозуміти. Це не означає, що ви спілкуєтеся з OpenAI, і це не змінює той факт, що сервер залишається локальним. Це лише означає, що форма запиту достатньо знайома для інструментів та SDK, побудованих за шаблоном OpenAI API. Базова URL-адреса залишається http://localhost:11434/v1/, а будь-який ключ API-заповнювача, на якому наполягають деякі клієнтські бібліотеки, можна ігнорувати для локального використання Ollama.

Звідки насправді походять обмеження моделей

Цю частину зазвичай зводять до однієї розпливчастої ідеї «цензури», але технічно тут задіяні три різні шари: шар обслуговування постачальника, вирівнювання моделі та навчання з інструкціями, а також поведінка запиту/виконання, яку ви контролюєте самостійно. Самостійне розгортання кардинально змінює деякі з цих шарів. Але не всі.

Простий спосіб уявити це:

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Результати:
– Шар обслуговування під контролем постачальника зникає з локального шляху
– Межа локальної мережі та журналювання стає вашою
– Власне навчання та вирівнювання моделі залишаються разом із моделлю

Після розмежування шарів попередні кроки налаштування набувають значно більшого сенсу:

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

Те, що ваше поточне налаштування вже довело, є вужчим, але все одно важливим: ви контролюєте процес сервера, ви контролюєте межу API, і ви більше не маршрутизуєте локальні запити через шар модерації, що належить постачальнику. Це реальний зсув у конфіденційності та контролі. Що це не довело — так це те, що кожна локальна модель поводитиметься однаково або що кожна майбутня відмова була спричинена хмарним провайдером.

Саме тут на перший план виходить вибір моделі. Якщо ви хочете практичного ефекту у вигляді менше застережень, більш прямих відповідей або меншої кількості відмов, ви досягнете цього не тим, що гучніше скажете «самостійно розгорнуто». Ви досягнете цього, обравши інше сімейство моделей або fine-tune — і розуміючи компроміси, які з цим пов’язані.

Вибір менш обмеженої локальної моделі

Якщо ви хочете чесного тесту, порівнюйте моделі приблизно одного розмірного класу. Саме тому в цьому посібнику використовується llama3.1:8b як популярна вирівняна базова лінія, а dolphin3 — як менш обмежена порівняльна модель. Обидві важать приблизно 4.9GB, що дозволяє легше інтерпретувати різницю в поведінці без надмірної зміни апаратного сліду.

Завантажте порівняльні моделі локально:

Ось практичне пояснення для трьох назв, які ви найімовірніше зустрінете в цій частині екосистеми Ollama:

⚠️ Попередження: Інше fine-tune — це не «та сама модель із видаленою цензурою». Воно може змінити прямолінійність, щільність застережень і готовність слідувати формулюванням користувача, але також може змінити тон, точність, узгодженість і загальну особистість.

Продуктивність GPU

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

На цьому сервері кращим тестом виконання для верхньої межі є gpt-oss:20b. Він достатньо великий, щоб бути цікавим, і при цьому все ще має сенс на одній карті з 16GB.

Після завантаження моделі підтвердьте стан виконання:

Це практичний доказ, який вам потрібен на цій машині. Він показує, що менші моделі вміщуються легко, і що більша, але все ще реалістична локальна модель може наблизити одну карту з 16GB до межі її використовуваного обсягу, не потребуючи кількох GPU.

Якщо ви пізніше запустите Ollama на хості з двома GPU, модель на кшталт qwen3:30b стає тим типом навантаження, який може продемонструвати розміщення на кількох GPU. Робочий процес той самий — спостерігайте за nvidia-smi, запускайте модель, перевіряйте ollama ps — але мета полягає не в тому, щоб змусити обидві карти працювати заради самого факту. Мета — підтвердити, що Ollama розподіляє модель між кількома GPU лише тоді, коли модель більше не вміщується на одній карті.

Міркування щодо обходу цензури

Для порівняння поведінки тримайте умови під контролем, щоб ви тестували модель більше, ніж випадковість. Використовуйте той самий endpoint, той самий запит, stream: false, низьку температуру та фіксований seed:

Потім повторіть той самий запит із “model”: “dolphin3”. Фіксований seed не усуває всю варіативність, але достатньо зменшує випадковість, щоб полегшити виявлення відмінностей у тоні та дотриманні вимог.

1. Безпечний перший запит: «Чи означає самостійне розгортання LLM, що користувач повністю контролює поведінку моделі? Відповідайте у 4 пунктах. Будьте прямолінійні та пропускайте преамбули.» Типова відповідь llama3.1:8b зазвичай звучить так:

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Типова відповідь dolphin3 на той самий запит часто звучить більш стисло:

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Другий корисний запит: «Напишіть гостре аргументоване обґрунтування з п’яти речень, чому команда, чутлива до конфіденційності, може відмовитися від ШІ під управлінням постачальника. Без вступу та висновку.» llama3.1:8b зазвичай відповідає, але більш виваженим корпоративним тоном. dolphin3 охочіше дотримується запитуваної гостроти. Саме такого роду відмінності ви тут шукаєте: не драматично беззаконного результату, а змін у прямолінійності, формулюванні та щільності застережень.
3. Третя категорія запитів для перевірки може бути такою: попросіть п’ять фактичних причин, чому письменник може надати перевагу локальній моделі для незвичайної, нішевої або нетрадиційної творчої роботи. На практиці обидві моделі відповідають, але dolphin3 зазвичай залишається ближчою до запитуваного тону без повчань та прямих відповідей.

Шаблон виглядає так:

Отже, ось чесні висновки:

1. Вибір локальної моделі суттєво змінює вихідну поведінку.
2. Різні моделі відрізняються прямолінійністю та щільністю застережень.
3. Самостійне розгортання усуває шар обслуговування під контролем постачальника.

Тепер ви контролюєте стек, а не лише запит

Розчарування з початку цього посібника полягало не лише в тому, що модель відмовляла у запиті. Воно полягало в тому, що шар обслуговування, шар політики та межа конфіденційності знаходилися десь в іншому місці. Після цього налаштування ця частина змінилася. Ваш сервер інференсу працює на вашій Ubuntu-машині, локальна межа API належить вам, меню моделей належить вам, і налаштування запитів/виконання за замовчуванням належать вам для налаштування.

Те, що все ще вимагає судження, — це частина, яку жоден інсталятор не може вирішити за вас: вибір моделей, що відповідають вашому варіанту використання, керування ними з розумними налаштуваннями за замовчуванням та безпечне відкриття доступу, якщо ви виходите за межі localhost. Саме так виглядає реальний контроль при самостійному розгортанні. Не магічна свобода від будь-яких обмежень, а власність над стеком, який вирішує, як, де і з якою моделлю відбувається інференс. Якщо ви хочете зробити найкращий наступний крок, почніть зі створення власного Modelfile — або налаштуйте безпечний віддалений доступ перед локальним API, коли будете готові.

Що робити після базового налаштування

На цьому етапі основна обіцянка виконана. Сервер працює, API працює, шлях через GPU реальний, і відмінності в поведінці моделей більше не є абстрактними. Наступний крок — це не «встановлювати більше речей наосліп». Це налаштування тих частин стека, які тепер належать вам.

Налаштування поведінки моделі за допомогою Modelfile

Modelfile — це найчистіший спосіб змінити локальні налаштування запитів за замовчуванням, не торкаючись самих ваг моделі. Почніть з перегляду поточного визначення моделі, щоб зрозуміти, що ви розширюєте:

Потім створіть просту локальну варіацію:

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Зберіть її під новою назвою моделі та протестуйте:

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

Захист налаштування

Прив’язка до localhost є хорошим налаштуванням за замовчуванням, але це не кінець історії безпеки. Спочатку повторно перевірте поточну адресу прослуховування:

Якщо мета — залишити Ollama лише локальним, явно зафіксуйте цю поведінку за допомогою перевизначення systemd:

Додайте наступне:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Потім перезавантажте та перезапустіть службу:

Якщо вам пізніше знадобиться віддалений доступ, не публікуйте 11434 напряму. Замість цього поставте перед ним зворотний проксі з TLS та автентифікацією:

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Попередження: Сприймайте публічний доступ як окремий проект із посилення захисту. Ollama сам по собі є локальним сервером інференсу, а не готовим до виробництва публічним шлюзом API із вбудованою автентифікацією, обмеженням частоти запитів та налаштуваннями для роботи в інтернеті.

Рекомендовані моделі для цього обладнання

Після того як базова інсталяція працює, найбільш цінним покращенням є вибір моделей, які дійсно добре підходять для цієї машини, замість погоні за найбільшим заголовком. Для сервера з одним 4070 Ti SUPER, використаного тут, практичне меню виглядає так:

Варіант використання	Модель	Розмір	Очікуване розміщення	Чому підходить для цієї машини
Перший успіх	mistral	4.4GB	Один GPU	Швидка, проста перевірка з мінімальними труднощами
Загальна базова лінія	llama3.1:8b	4.9GB	Один GPU	Потужна популярна точка відліку
Менш обмежена 8B	dolphin3	4.9GB	Один GPU	Найкраще порівняння «один до одного» з llama3.1:8b
Рівень міркування	gpt-oss:20b	14GB	Зазвичай один GPU	Сильніше міркування при цьому все ще вміщується без проблем
Локальний рівень вищої якості	qwen3:30b	19GB	Потрібен подвійний GPU або більший Збережіть 15% на всі хостинг-послуги Перевірте свої навички і отримайте Знижку на будь-який план хостингу Використовуй код: Skills Почати Як встановити 3x-ui та вибрати правильну конфігурацію для обходу цензури Table of Contents Ключові слова Як встановити 3x-ui на VPS і вибрати правильну конфігурацію проти цензури Що таке 3x-ui... Що таке хостинг електронної пошти? Як це працює, чому це важливо і коли вам це потрібно Table of Contents Від вхідних до ідентичності: роль хостингу електронної пошти Ключові слова Що таке хостинг електронної пошти насправді... Ваш перший тиждень на сервері Linux — 35+ основних команд Table of Contents Ключові слова: Швидкий довідник перед початком Вступ: Початок подорожі сервером День 1: Підключення та дослідження Крок... We use cookies to improve your experience on alexhost.com, analyze site performance and traffic, and support our marketing efforts. We may also share information about your use of our site with our social media, advertising, and analytics partners. By clicking one of the buttons below, you can choose your cookie preferences. Note: Some technical cookies will be stored regardless of your choice. Accept All Cookies Necessary Cookies Only Decline All