Самостоятельно разместить Ollama на LLM сервере и взять под контроль цензуру AI

Ключевые термины

Перед началом настройки вот термины, которые с наибольшей вероятностью могут запутать читателей этого руководства. Этот краткий словарь с самого начала проясняет терминологию Linux, GPU и локальных моделей.

Почему самостоятельный хостинг LLM стоит того

Если вы уже проделали сложную работу — арендовали GPU сервер, установили Ubuntu, научились работать с SSH и поддерживали собственные сервисы в рабочем состоянии — быстро становится раздражающим, когда размещённый AI всё ещё контролирует последний этап. Он может отклонить совершенно обычный запрос, скрыть ответ под слоем дисклеймеров, изменить стиль ответа без предупреждения и направлять каждый запрос через чужие границы. Для многих технических пользователей это настоящее разочарование: не только то, что говорит модель, но и кто контролирует уровень обслуживания, когда она это говорит.

Это руководство о решении этой проблемы с помощью открытых и локальных моделей, а не о трюках обхода для проприетарных API. Вы будете самостоятельно размещать Ollama на Ubuntu GPU сервере, запускать вывод локально, проверять, что путь GPU реален, и видеть, что меняется при выборе другого семейства моделей. Одно заблуждение, которое нужно развеять с самого начала: самостоятельный хостинг не означает автоматически неограниченность. Это означает, что вы контролируете гораздо большую часть стека — и вы перестаёте зависеть от контролируемого поставщиком пути обслуживания — но модель, которую вы запускаете, всё ещё может иметь собственное поведение выравнивания.

📝 Примечание: Команды в этом руководстве проверены в соответствии с текущей документацией Ollama, но показанные ниже выходные данные терминала являются репрезентативными примерами, а не живыми снимками тестирования производительности. Используйте их как образец успеха, а не как утверждение производительности.

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

Точный GPU сервер Ubuntu, используемый в этом руководстве

Это пошаговое руководство основано на реальной машине 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:

nvidia-smi

❗Если Ubuntu говорит, что nvidia-smi отсутствует, не предполагайте, что на сервере нет GPU. Распространённая проблема на арендованных Ubuntu-серверах — карта присутствует, но всё ещё привязана к nouveau вместо драйвера NVIDIA. Сначала проверьте раздел “Исправление проблемы драйвера Nvidia на Ubuntu“.

Здоровый результат на сервере этого класса должен выглядеть примерно так:

Как только nvidia-smi работает и GPU видна, продолжайте с проверками ниже.

Что вы хотите подтвердить, просто: установленный GPU видна, она сообщает примерно 16GB VRAM на этом хосте, и драйвер загружен корректно. Если вы на сервере с несколькими GPU, та же команда должна перечислить каждую карту.

nvidia-smi -L

❗ Важно: Текущая документация поддержки GPU в Ollama использует драйвер NVIDIA 531+ как реальный минимум для поддерживаемого NVIDIA inference. Рассматривайте 531+ как требование для этого руководства, даже если вы видели старые заметки сообщества, цитирующие более низкие версии.

Теперь подтвердите, что хост действительно является Ubuntu-окружением, которое предполагает это руководство:

lsb_release -a

Наконец, проверьте свободное место на диске перед началом загрузки моделей. Сама установка небольшая; модели — нет. Как только вы выйдете за пределы крошечных тестов, библиотека 20B-30B может быстро съесть десятки гигабайт, поэтому 100GB+ свободного места — правильный подход перед серьёзной работой с локальными моделями.

df -h /

Если эти проверки пройдены, вы устранили основные неизвестные инфраструктуры: GPU присутствуют, базовая линия драйвера разумна, Ubuntu подтверждена, и на диске есть место для реальных загрузок моделей. Это точка, где установка Ollama становится чистым следующим шагом вместо предположения.

Исправление проблемы драйвера Nvidia на Ubuntu

Следуйте шагам ниже, чтобы исправить проблемы с командой “nvidia-smi”.

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Если этот вывод показывает карту NVIDIA и строку типа Kernel driver in use: nouveau, установите рекомендуемый пакет драйвера Ubuntu вместо установки только nvidia-utils.

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

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

Просканируйте вашу систему и перечислите доступные проприетарные драйверы (например, драйверы NVIDIA GPU), которые можно установить.

ubuntu-drivers devices

Затем установите рекомендуемый пакет драйвера. В нашем случае это было: nvidia-driver-595-open:

apt install -y nvidia-driver-595-open
reboot

После перезагрузки повторно запустите:

nvidia-smi
nvidia-smi -L

Установите Ollama и подтвердите, что служба работает корректно

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

Запустите установщик точно так, как задокументировано:

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

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

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

sudo systemctl status ollama --no-pager

Здесь вы ищете три вещи: файл модуля присутствует, служба включена для загрузки, и Active: active (running) подтверждает, что сервер действительно работает.

Сначала установите учетную запись пользователя Linux-службы конкретным образом, и только после этого подумайте о том, как и где будет обрабатываться хранилище модели.

getent passwd ollama

Эта одна строка объясняет много будущего поведения. Модели на Linux находятся под владением службы, и если вы позже переместите их на другой диск без исправления разрешений для пользователя ollama, вы создадите собственный сбой.

Еще одна проверка закрывает цикл на привязке по умолчанию:

ss -tlnp | grep 11434

⚠️ Предупреждение: Ollama не требует аутентификации в локальном API по умолчанию. Это нормально, когда он привязан к 127.0.0.1, но небезопасно открывать порт 11434 непосредственно в Интернет, как если бы это была укрепленная общедоступная служба.

Если служба не запускается чисто, сначала перейдите к журналам вместо того, чтобы слепо переустанавливать:

journalctl -u ollama -n 100 --no-pager

Это самый быстрый способ поймать проблемы с разрешениями, ошибки запуска, проблемы обнаружения драйверов или проблемы с привязкой. Как только служба будет здорова на localhost, следующее, что нужно понять, — это как размещение GPU ведет себя во время выполнения.

Как Ollama на самом деле использует один или несколько GPU

Несмотря на то, что сервер, используемый в этом руководстве, имеет один GPU, понимание поведения с несколькими GPU все еще стоит изучить, потому что многие пользователи могут работать на более мощных машинах или расширяться позже. Много путаницы с двумя GPU начинается с неправильного ожидания: “У меня есть две карты, поэтому обе должны работать все время.” Так Ollama не работает. Практическое правило намного проще: если модель помещается на один GPU, Ollama обычно будет держать ее на одном GPU. Он распределяет нагрузку на несколько GPU только когда модель не помещается комфортно на одну карту.

Используйте эти две проверки вместе, когда вы хотите увидеть производительность GPU:

ollama ps

watch -n 1 nvidia-smi

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 позже станет базовым для сравнения поведения.

Начните с загрузки модели:

ollama pull mistral

Теперь пропустите через него небольшой запрос, чтобы машина делала что-то полезное, а не просто административные задачи. Ответ может занять несколько секунд.

ollama run mistral "In one sentence, explain why people self-host LLMs."

Чтобы доказать, что это GPU-поддерживаемый вывод, а не резервный вариант CPU, проверьте состояние выполнения:

ollama ps

И чтобы увидеть, что уже находится на диске, выведите список локального инвентаря:

ollama list

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

Наконец, проверьте, где установка Linux хранит модели:

sudo du -sh /usr/share/ollama/.ollama/models

Этот путь — /usr/share/ollama/.ollama/models — это стандартное хранилище моделей Linux, задокументированное Ollama.

Как только вы увидите успешный ответ, 100% GPU в ollama ps и увеличение использования диска в ожидаемом месте, у вас есть первое значимое доказательство того, что локальный стек работает.

Докажите, что это сервер, а не просто оболочка CLI

Командная строка удобна, но причина самостоятельного размещения Ollama заключается не только в том, чтобы общаться внутри терминала. Это запуск локального сервера вывода, который другие инструменты, скрипты и приложения могут вызывать без отправки запросов через чужой API. Самое быстрое доказательство — один чистый HTTP-запрос к нативной конечной точке Ollama.

Отправьте локальный запрос generate с отключенной потоковой передачей, чтобы первый ответ было легко проверить:

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Успешный ответ должен вернуться в виде 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 также предоставляет локально конечные точки /v1:

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Примечание: Этот ярлык “совместимый с OpenAI” легко неправильно прочитать. Это не означает, что вы общаетесь с OpenAI, и это не меняет того факта, что сервер по-прежнему локальный. Это только означает, что форма запроса достаточно знакома инструментам и SDK, созданным по шаблону API OpenAI. Базовый 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, и вы больше не маршрутизируете локальные подсказки через уровень модерации, принадлежащий поставщику. Это реальный сдвиг в конфиденциальности и контроле. Что это не доказало, так это то, что каждая локальная модель будет вести себя одинаково или что каждый отказ в будущем был вызван облачным провайдером.

Вот где вступает в игру выбор модели. Если вы хотите практический эффект меньшего количества дисклеймеров, более прямых ответов или поведения, менее склонного к отказам, вы не получите это, говоря “самостоятельно размещено” громче. Вы получите это, выбрав другое семейство модели или тонкую настройку — и поняв компромиссы, которые с этим связаны.

Выберите менее ограниченную локальную модель

Если вы хотите провести честный тест, сравнивайте модели, которые занимают примерно одинаковый размер. Именно поэтому в этом руководстве используется llama3.1:8b в качестве основной выровненной базовой модели и dolphin3 в качестве менее ограниченной модели для сравнения. Обе они имеют размер около 4.9GB, что облегчает интерпретацию различий в поведении без слишком резкого изменения требований к оборудованию.

Загрузите модели для сравнения локально:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Вот практическое описание трёх названий, которые вы, скорее всего, встретите в этой части экосистемы Ollama:

⚠️ Предупреждение: Другая тонкая настройка — это не “та же модель с удалённой цензурой”. Она может изменить прямолинейность, плотность дисклеймеров и готовность следовать фреймингу пользователя, но также может изменить тон, фактичность, согласованность и общую личность.

Производительность GPU

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

На этом сервере лучший тест верхнего диапазона — gpt-oss:20b. Он достаточно большой, чтобы быть интересным, но при этом имеет смысл на одной карте 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

После загрузки модели подтвердите состояние выполнения:

ollama ps

Это практическое доказательство, которое вам нужно на этой машине. Оно показывает, что меньшие модели легко помещаются и что большая, но все еще реалистичная локальная модель может довести одну карту 16GB близко к её полезному пределу без необходимости нескольких GPU.

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

Рассмотрение обхода цензуры

Для сравнения поведения держите условия контролируемыми, чтобы вы тестировали модель больше, чем случайность. Используйте один и тот же endpoint, один и тот же prompt, stream: false, низкую температуру и фиксированное seed:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Затем повторите тот же запрос с “model”: “dolphin3”. Фиксированное seed не устраняет всю дисперсию, но снижает достаточно случайности, чтобы различия в тоне и соответствии были легче заметны.

1. Безопасный первый prompt: “Означает ли самостоятельное размещение 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 на тот же prompt часто звучит более лаконично:

   - 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. Второй полезный prompt: “Напишите острый аргумент из пяти предложений о том, почему конфиденциальная команда может отклонить управляемый поставщиком AI. Без введения и без заключения.” llama3.1:8b обычно соответствует, но в более взвешенном корпоративном тоне. dolphin3 более охотно следует запрошенной остроте. Это именно то различие, которое вы ищете здесь: не драматичный беззаконный вывод, а изменения в прямолинейности, фреймировании и плотности дисклеймеров.
3. Третья категория prompt для валидации может быть следующей: попросите пять фактических причин, по которым писатель может предпочесть локальную модель для необычной, нишевой или немейнстримовой творческой работы. На практике обе модели отвечают, но dolphin3 обычно остается ближе к запрошенному беспристрастному тону и прямым ответам.

Паттерн выглядит так:

И таким образом, вот честные выводы:

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

Теперь вы контролируете весь стек, а не только промпт

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

То, что все еще требует суждения — это часть, которую никакой установщик не может решить за вас: выбор моделей, соответствующих вашему случаю использования, управление ими с разумными стандартными параметрами и безопасное предоставление доступа, если вы выходите за пределы localhost. Это настоящая форма контроля самостоятельного хостинга. Не магическая свобода от каждого ограничения, а владение стеком, который решает, как, где и с какой моделью происходит вывод. Если вы хотите лучший следующий шаг, начните с создания пользовательского Modelfile — или поместите безопасный удаленный доступ перед локальным API, когда вы будете готовы.

Что делать после базовой настройки

На этом этапе основное обещание выполнено. Сервер работает, API работает, путь GPU реален, и различия в поведении модели больше не являются абстрактными. Следующий шаг — это не «слепо устанавливать больше вещей». Это настройка частей стека, которые теперь принадлежат вам.

Настройка поведения модели с помощью Modelfile

Modelfile — это самый чистый способ изменить локальные значения по умолчанию для подсказок без изменения весов модели. Начните с проверки текущего определения модели, чтобы понять, что вы расширяете:

ollama show --modelfile dolphin3

Затем создайте простую локальную вариацию:

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

Создайте её с новым именем модели и протестируйте:

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

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

Защита настройки

Привязка к localhost — хороший стандарт, но это не конец истории безопасности. Сначала перепроверьте текущий адрес прослушивания:

ss -tlnp | grep 11434

Если цель — сохранить Ollama только локальным, явно закрепите это поведение с помощью переопределения systemd:

sudo systemctl edit ollama

Добавьте следующее:

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

Затем перезагрузите и перезапустите сервис:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Если вам позже потребуется удалённый доступ, не публикуйте 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 практическое меню выглядит так:

Автозапуск и обслуживание

После интересной части приходит часть, которая сохраняет локальный сервер LLM полезным через месяц. Подтвердите поведение при загрузке, держите сервис в актуальном состоянии, следите за логами и знайте, как выгрузить большие модели, когда вам нужна VRAM обратно.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

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

journalctl -u ollama -n 100 --no-pager

Для повседневных операций с моделями это команды, которые вы будете использовать чаще всего:

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

И если хранилище модели должно переместиться на больший диск, подготовьте каталог для пользователя сервиса перед переориентацией Ollama:

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Затем установите OLLAMA_MODELS через systemctl edit ollama. Эта деталь владения — это то, что предотвращает превращение миграции хранилища в проблему с разрешениями.

Справочник по устранению неполадок

Когда что-то ломается, самый быстрый путь — это обычно сопоставление симптома с правильным уровнем вместо попыток случайных циклов переустановки. Используйте эту таблицу как первый проход:

Если вы помните только одно операционное правило из этого раздела, пусть это будет: относитесь к Ollama как к реальному сервису, а не как к одноразовой утилите CLI. Логи, владение, адреса привязки и пути хранилища имеют такое же значение, как и окно подсказок.