Как запустить Ollama на VPS и настроить доступ к API

Что вы создаете

Вы разворачиваете одну языковую модель с открытыми весами на собственном сервере, доступ к которой осуществляется через HTTP API и, при желании, через чат-интерфейс в браузере. Ollama отвечает за загрузку модели, размещение её в оперативной памяти и обработку запросов на http://127.0.0.1:11434. Установка выполняется одной командой. Все сложные аспекты вынесены за рамки этого процесса: выбор модели, которая поместится в RAM вашего VPS, и предотвращение случайной публикации неавторизованного сервера инференса в открытый доступ.

Сначала два важных предупреждения. VPS без GPU выполняет работу с небольшими моделями медленно, а встроенная аутентификация в API полностью отсутствует. Оба этих аспекта подробно разобраны ниже, так как именно здесь чаще всего возникают проблемы.

Реальная оценка ресурсов в цифрах

Объем оперативной памяти, необходимый для работы модели, примерно равен размеру её файла плюс около одного гигабайта на накладные расходы среды выполнения и дополнительный объем для контекстного окна. Стандартные теги большинства популярных моделей в Ollama, включая llama3.2:3b, llama3.1:8b и mistral:7b, используют 4-битную квантованную версию (с пометкой Q4_K_M), что требует около половины гигабайта ОЗУ на каждый миллиард параметров. Не все модели по умолчанию используют Q4: крошечные модели, такие как smollm2:135m, поставляются в 16-битном формате, поэтому перед расчетами проверяйте строку квантования на странице модели в библиотеке. Арифметика проста, и именно она определяет всё. Последний параметр вы задаете самостоятельно: увеличение num_ctx сверх стандартного небольшого значения Ollama позволяет использовать более длинные промпты, но увеличивает объем KV-кэша в оперативной памяти, поэтому определитесь с длиной контекста, прежде чем оценивать, поместится ли модель.

Модель на 3B, такая как llama3.2:3b, занимает около 2 ГБ при загрузке и требует около 4 ГБ свободной оперативной памяти для работы. Модель на 7B или 8B, такая как mistral:7b или llama3.1:8b, занимает около 5 ГБ на диске и требует около 8 ГБ ОЗУ, а для комфортной работы — 16 ГБ. Модели на 13B или 14B требуют примерно 16 ГБ. Любая модель в диапазоне от 30B до 70B требует сервер с большим объемом оперативной памяти или, что более реалистично, GPU; на CPU VPS она либо не поместится, либо будет отвечать настолько медленно, что станет бесполезной.

Теперь о скорости, так как это то, что люди часто недооценивают. Вывод (inference) на CPU ограничен пропускной способностью памяти, а не тактовой частотой, а VPS с общими vCPU обладают скромной пропускной способностью. Ожидайте скорость от нескольких до чуть более десяти токенов в секунду: модель 7-8B Q4 может выдавать от 4 до 10 токенов в секунду, модель 3B — от 10 до 25. GPU примерно на порядок быстрее. Эти цифры приведены намеренно приблизительно; честный подход — измерить показатели на вашем собственном сервере, как показано в шаге запуска ниже. Доверяйте своему eval rate, а не цифрам из любой статьи, включая эту.

Практический вывод: небольшие квантованные модели на CPU действительно полезны для черновиков, суммаризации и классификации, если вы готовы смириться с темпом работы. Для чего-то большего или более быстрого закладывайте бюджет на GPU-инстанс. Если вы хотите увидеть, как эта арифметика применяется от начала до конца на конкретной модели, запуск Nemotron 3.5 Lightning на VPS описывает, какой тег выбрать, сколько ОЗУ на самом деле нужно и справляется ли конфигурация только на CPU. А если ни одна конфигурация на CPU вас не устраивает и вы думаете не об аренде GPU-инстанса, а о покупке собственного сервера, руководство по проверке готового локального AI-сервера перед покупкой подскажет, какие цифры скорости и VRAM требовать у поставщика и какие расходы на гарантию, таможню и электропитание остаются за рамками спецификации.

Чтобы сопоставить конкретную модель с конкретным сервером, оцените объем необходимой памяти здесь:

Установка Ollama

Существует два чистых способа установки. Официальный скрипт — самый простой вариант для «чистой» VPS:

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

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

Этот скрипт создает системного пользователя с именем ollama, устанавливает бинарный файл в /usr/local/bin/ollama и регистрирует systemd-сервис ollama.service, который запускается при загрузке системы и слушает порт 127.0.0.1:11434. Убедитесь, что сервис запущен:

systemctl status ollama
ollama --version

systemctl status ollama

Если вы уже используете Docker, воспользуйтесь контейнером:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

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

Загрузка и запуск первой модели

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull загружает слои модели на диск (около 2 GB для этой модели). run загружает их в память и открывает приглашение >>>. Введите вопрос. Первый токен может генерироваться несколько секунд, пока веса загружаются с диска в RAM, после чего начнется потоковый вывод ответа. Введите /bye, чтобы выйти из чата; Ollama продолжит работать в фоновом режиме.

Проверьте, что загружено и как это размещено в памяти:

ollama ps

Столбец PROCESSOR показывает фактическое состояние. 100% CPU означает, что GPU не используется, именно поэтому скорость работы низкая. Измерьте реальную скорость с помощью флага verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

Строка eval rate, выведенная в конце, показывает количество токенов в секунду на данном оборудовании. Это значение следует использовать для планирования ресурсов.

Где хранятся модели и сколько дискового пространства выделить

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

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

При интерактивном запуске от имени вашего пользователя они находятся в ~/.ollama/models. Внутри контейнера они располагаются в именованном томе ollama. Это важно, так как квантованные веса быстро занимают место: модель 3B весит около 2 GB, 7-8B — около 5 GB, 14B — около 9 GB. Загрузив четыре модели для сравнения, вы незаметно потратите 20 GB. Рассчитывайте объем диска исходя из количества моделей, которые планируете хранить, а остальные удаляйте с помощью ollama rm <model>. Если на этом же VPS уже работает что-то требовательное к ресурсам, например PhotoPrism или Immich с библиотекой фотографий, сначала вычтите этот объем из свободного места, а остаток считайте своим реальным бюджетом для моделей.

Запуск в качестве управляемой службы

Скрипт установки уже зарегистрировал ollama.service, поэтому служба перезапускается при загрузке системы автоматически. Стоит изменить время удержания модели в оперативной памяти, а в некоторых конфигурациях — адрес привязки. Оба параметра лучше задать через drop-in файл systemd, чтобы обновление Ollama не перезаписало ваши настройки:

sudo systemctl edit ollama.service

Добавьте следующие строки под заголовком [Service], который отобразит редактор:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Параметр OLLAMA_KEEP_ALIVE определяет время, в течение которого модель остается в памяти после последнего запроса (по умолчанию 5 минут). Увеличьте это значение на сервере, к которому вы обращаетесь в течение дня, чтобы избежать повторной загрузки весов при каждом запросе. Установите 0 на системе с ограниченными ресурсами, чтобы освобождать RAM сразу после завершения запроса. Если вы хотите, чтобы модель находилась в памяти постоянно, а не в течение фиксированного интервала, в разделе постоянное удержание модели Ollama в памяти описано использование поля keep_alive в запросах, а также способы прогрева весов после перезагрузки, чтобы избежать задержки при первом запросе. Команда systemctl edit выполняет перечитывание файлов юнитов, после чего перезапустите службу для применения изменений:

sudo systemctl restart ollama

Критически важный аспект безопасности

По умолчанию Ollama использует привязку к 127.0.0.1:11434, поэтому доступ к ней имеют только процессы на самом VPS. Это поведение по умолчанию является корректным. Не меняйте его.

У API отсутствует аутентификация. Вообще. Нет ни API-ключа, ни логина, ни ограничения частоты запросов. Единственный список разрешенных источников, OLLAMA_ORIGINS, управляет только тем, какие домены в браузере могут обращаться к API (CORS); он никак не препятствует работе curl или скриптов с других машин. Любой, кто может подключиться к порту 11434, может запустить любую загруженную вами модель, скачать новые, удалить их или загрузить ваш CPU или GPU на полную мощность на неограниченное время. Сканеры вроде Shodan индексируют тысячи открытых экземпляров Ollama, и любой открытый сервер обнаруживается и подвергается злоупотреблению в течение нескольких часов.

Поэтому вот главная ошибка, которую нельзя совершать: не устанавливайте OLLAMA_HOST=0.0.0.0 и не открывайте порт 11434 в вашем файрволе. Это сделает сервер инференса без аутентификации доступным для всего интернета. Никакие настройки не сделают работу 11434 на 0.0.0.0 безопасной, так как ни одна из документированных настроек Ollama не добавляет аутентификацию к локальному API, а список разрешенных источников — это не логин. Это правило касается именно данного сервиса, а не запрещает открывать порты в принципе: самохостинг-релей RustDesk для удаленного рабочего стола должен принимать публичный трафик для выполнения своих функций, но он обеспечивает безопасность за счет собственной аутентификации по ключу и ограниченного, документированного списка портов, чего у Ollama нет.

Существует три безопасных способа доступа к модели извне сервера:

• Оставьте доступ локальным. Если единственный клиент — это другая программа на том же VPS, cron-скрипт, бот или MCP-сервер, связывающий ваши инструменты с моделью, оставьте привязку на 127.0.0.1 и обращайтесь к программе через http://127.0.0.1:11434. Ничего не будет выставлено наружу, и дополнительные меры не потребуются.
• Используйте частный туннель. Подключите VPS к VPN-сети WireGuard, которую вы хостите самостоятельно, установите OLLAMA_HOST на адрес туннеля (например, 10.8.0.1, а не 0.0.0.0), и подключаться смогут только участники VPN. Публичный интернет по-прежнему не увидит ничего на порту 11434.
• Установите перед сервисом обратный прокси с аутентификацией. Выполните TLS termination и потребуйте пароль или токен на уровне nginx, Traefik или Caddy, а затем проксируйте запрос на 127.0.0.1:11434. Ollama сохранит привязку к localhost; прокси будет единственным компонентом, слушающим публичный порт. Это аналогично настройке SSL-сертификата Let's Encrypt в nginx перед любым локальным сервисом.

Вариант с обратным прокси — это именно то, что предложит вам далее интерфейс чата, добавив полноценную систему входа.

Добавление интерфейса чата с помощью Open WebUI за TLS

Open WebUI — это self-hosted интерфейс для чата. Запустите его в Docker и направьте на локальный Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Флаг --network=host — важная деталь при работе на Linux VPS. Он помещает контейнер в сетевое пространство имен хоста, поэтому 127.0.0.1 внутри контейнера становится собственным loopback-интерфейсом хоста, и контейнер обращается к Ollama по адресу 127.0.0.1:11434 без необходимости прослушивания Ollama на других интерфейсах. Рецепт с bridge-сетью, который можно встретить в других источниках, --add-host=host.docker.internal:host-gateway с OLLAMA_BASE_URL=http://host.docker.internal:11434, здесь не работает: это имя разрешается в шлюз Docker-моста, а сервис, привязанный к 127.0.0.1 на хосте, недоступен через мост, поэтому Open WebUI просто сообщает об отсутствии соединения с Ollama.

Минусом использования host-сети является то, что Open WebUI теперь прослушивает порт 8080 на всех интерфейсах хоста; любое отображение -p игнорируется, о чем Docker выводит предупреждение. Поэтому закройте 8080 как на хосте, так и в брандмауэре провайдера, и оставьте TLS reverse proxy единственной точкой входа. При первом посещении Open WebUI предложит создать учетную запись администратора; эта учетная запись является вашим уровнем аутентификации, поэтому выберите надежный пароль.

Чтобы открыть чат с ноутбука по HTTPS, установите TLS reverse proxy перед 127.0.0.1:8080. Если вы уже используете несколько Docker-приложений на сервере, Traefik с автоматическим TLS для множества приложений подойдет лучше всего: один блок меток выпускает сертификат и направляет chat.example.com на Open WebUI. Такая маршрутизация по меткам для каждого приложения используется для всех остальных веб-интерфейсов на сервере, будь то панель мониторинга или что-то более развлекательное, например Halcyon, который представляет библиотеку Jellyfin как видеопрокат 90-х, каждое на своем доменном имени и за своей авторизацией. Правило из раздела безопасности остается в силе: прокси владеет публичным портом и авторизацией, в то время как Ollama остается на localhost, а порт 8080 самого Open WebUI остается закрытым брандмауэром.

Использование OpenAI-совместимого endpoint в вашем коде

Ollama поддерживает подмножество API чата OpenAI по адресу /v1, поэтому большинство клиентских библиотек OpenAI работают после изменения двух параметров: базового URL и любого фиктивного ключа.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

Параметр api_key обязателен для клиентской библиотеки, но игнорируется Ollama, поэтому подойдет любая строка. model должен быть именем модели, которую вы уже загрузили; при указании неизвестного имени возвращается ошибка 404 с кодом model 'x' not found. Обычный вызов curl работает по тому же принципу:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Таким же образом модель подключается к инструментам агентов и редакторам кода. Если вы уже ведете разработку на сервере, локальная модель может использоваться в скриптах и плагинах наряду с запуском Claude Code на VPS внутри tmux, что позволяет выполнять простые черновики локально и конфиденциально без затрат на платный API, оставляя сложные задачи для облачных моделей.

Режимы сбоев и соответствующие им сообщения

Процесс «убит» (Killed) в процессе генерации. Вы запускаете большую модель, терминал выводит Killed, а в журнале сервера (journalctl -u ollama) появляется строка, начинающаяся с llama-server process has terminated. Это формулировка в Ollama 0.40.3, проверено 12 октября 2026 года; в более старых версиях выводилось llama runner process has terminated: signal: killed. Linux OOM killer остановил процесс, так как модели потребовалось больше оперативной памяти, чем есть на сервере. Подтвердите причину с помощью sudo dmesg | grep -i oom, где вы увидите строку наподобие Out of memory: Killed process .... Решение заключается в использовании модели меньшего размера или с более сильной квантованием, например llama3.2:3b вместо 13B, либо в добавлении swap, чтобы нагрузка, лишь немного превышающая объем физической памяти, обрабатывалась медленно, а не завершалась аварийно. Swap превращает мгновенный сбой в медленный ответ; он не сделает модель 70B пригодной для работы на 4 ГБ ОЗУ. Завершение процесса происходит без уведомлений, если вы не наблюдаете за терминалом. Поэтому на сервере, к которому вы обращаетесь удаленно, привязка юнита OnFailure= к ollama.service, который отправляет уведомления в настраиваемый вами ntfy server для push-оповещений, позволит узнать о сбое в момент его возникновения, вместо того чтобы обнаружить его при следующем запросе.

Ollama отказывается загружать модель. Запрос сразу завершается ошибкой вместо аварийного завершения, а в журнале сервера фиксируется model is too large for system memory (Ollama 0.40.3, проверено 12 октября 2026 года). В более старых версиях при вводе команды выводилось Error: model requires more system memory (X GiB) than is available (Y GiB). Это вежливая версия описанного выше сбоя: Ollama выполнила вычисления и остановилась сама, не дожидаясь действий OOM killer. Выберите модель, требования которой не превышают объем свободной оперативной памяти (проверьте через free -h), уменьшите длину контекста или перейдите на более мощный VPS. Никакой флаг не заставит модель «влезть» в память, если ее физически не хватает.

Первый токен генерируется очень долго, затем все работает нормально. «Холодная» модель ничего не выводит от пяти до тридцати секунд, а затем начинает потоковую передачу. Эта пауза вызвана загрузкой весов с диска в оперативную память при первом обращении, и медленные накопители усугубляют ситуацию. После загрузки модель остается в памяти в течение времени, заданного OLLAMA_KEEP_ALIVE, поэтому второй запрос обрабатывается мгновенно. Если первая загрузка превышает таймаут в пути прохождения запроса, вы получите ошибку вместо медленного ответа, а анализ того, какой уровень сообщил о превышении времени ожидания контекста (context deadline exceeded), покажет, кто именно потерял терпение: клиент, прокси или сам процесс загрузки. Увеличьте это значение, если задержки мешают, и используйте ollama ps, чтобы проверить, загружена ли модель в данный момент.

Все работает просто медленно. Десять токенов в секунду или меньше, без каких-либо ошибок. Это работа CPU-инференса в штатном режиме. ollama ps показывает 100% CPU, что означает отсутствие GPU. Это не ошибка, и никакая настройка не превратит CPU в GPU, так как основным ограничением является пропускная способность памяти. Однако на виртуальной машине стоит проверить одну настройку: Ollama выбирает количество потоков на основе физических ядер, которые она обнаруживает, а гипервизор может передавать эти данные неверно. В сессии ollama run --verbose попробуйте /set parameter num_thread 4 (или количество ваших vCPU), повторите тот же запрос и оставьте значение, которое дает лучший eval rate. Помимо этого, используйте модель меньшего размера, смиритесь со скоростью или перейдите на инстанс с GPU. Перед тем как делать выводы о неисправности, измерьте реальную скорость с помощью --verbose. Если ожидание вызвано длиной ответа, а не скоростью генерации, ограничение ответа через num_predict не позволит модели тратить минуты на генерацию текста, который вы не собирались читать.

Connection refused при обращении с другой машины. С вашего ноутбука вы получаете curl: (7) Failed to connect to <ip> port 11434: Connection refused. Это штатное поведение: Ollama привязывается только к localhost. Не «исправляйте» это привязкой к 0.0.0.0, так как это именно та ошибка с открытием доступа, о которой говорилось выше. Обращайтесь к модели через VPN или через аутентифицирующий прокси.

Вы открыли 11434 в интернет. Если вы установили OLLAMA_HOST=0.0.0.0, открыли порт в брандмауэре и теперь видите загрузки моделей, которые вы не запускали, или загрузку CPU на 100% неизвестными клиентами — вас обнаружили и используют. Это главная ошибка, а не частный случай. Привяжитесь обратно к 127.0.0.1 или адресу VPN, закройте порт 11434 в брандмауэре и настройте аутентификацию. Считайте, что любой, кто мог обратиться к этому адресу, пока он был открыт, уже отправлял запросы к вашей модели.

Резервное копирование и обновления

Состояние системы минимально. Модели можно загрузить повторно, поэтому резервному копированию подлежат только том с данными Open WebUI, учетные записи, история чатов, настройки и созданные вами drop-in файлы systemd. Выполните резервное копирование тома с помощью временного контейнера:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Обновите Ollama, повторно запустив скрипт установки; обновите Open WebUI с помощью docker pull ghcr.io/open-webui/open-webui:main, а затем пересоздайте контейнер. Примечание по дисковому пространству для ветки 0.40: Ollama 0.40.2 начала фоновое обновление моделей, загруженных в более ранних версиях, сохраняя исходные копии в качестве резервных. Они занимают дополнительное место на диске, пока их не удалить. В версии 0.40.3 (11 октября 2026) это фоновое обновление было приостановлено. Проверяйте df -h после обновления и читайте примечания к выпуску, чтобы найти команду для удаления этих резервных копий. Не фиксируйте версии на длительный срок: качество моделей и среда выполнения быстро меняются, поэтому читайте примечания к выпуску и проводите повторное тестирование на своем оборудовании, вместо того чтобы доверять цифрам прошлого квартала.

FAQ

Можно ли действительно запустить LLM на VPS только с CPU?

Да, с определенными ограничениями. Небольшие квантованные модели в диапазоне от 3B до 8B параметров работают на CPU и вполне пригодны для черновиков, суммаризации и классификации, хотя и медленно — со скоростью от нескольких единиц до десятков токенов в секунду на общем vCPU. Модели от 13B и выше будут работать крайне медленно или вовсе не поместятся в RAM. Для высокой скорости или работы с большими моделями требуется инстанс с GPU.

Сколько RAM нужно для каждой модели?

Приблизительный расчет для 4-битных (Q4) версий, которые наиболее популярны: около 0.5 GB RAM на миллиард параметров для весов модели, плюс примерно 1 GB на накладные расходы и немного дополнительной памяти для контекста. Таким образом, для модели 3B нужно около 4 GB свободной памяти, для 7-8B — около 8 GB, а для 14B — около 16 GB. Проверяйте доступный объем с помощью free -h и оставляйте запас для операционной системы и других процессов на сервере.

Есть ли аутентификация в Ollama API?

Нет. В Ollama нет встроенной аутентификации, API-ключей или ограничения частоты запросов (rate limit); любой, кто имеет доступ к порту 11434, получает полный контроль. Настройка OLLAMA_ORIGINS ограничивает только источники запросов из браузера (CORS), а не круг лиц, которые могут подключиться. Именно поэтому по умолчанию сервис привязывается к 127.0.0.1, и именно поэтому вы никогда не должны открывать порт 11434 на 0.0.0.0 для доступа из Интернета. Обращайтесь к нему локально, через частный VPN или через reverse proxy, который добавит авторизацию.

Как добавить веб-интерфейс для чата?

Запустите Open WebUI в Docker с параметром --network=host, чтобы контейнер использовал сетевой стек хоста и мог обращаться к локальному Ollama по адресу http://127.0.0.1:11434. Затем настройте TLS reverse proxy перед портом 8080 для доступа с вашего ноутбука. Держите порт 8080 закрытым на межсетевом экране, чтобы прокси оставался единственной точкой входа. Учетная запись администратора в Open WebUI обеспечивает авторизацию, а пароль задается при первом запуске.

Как обращаться к модели из собственного приложения?

Используйте совместимый с OpenAI endpoint по адресу http://127.0.0.1:11434/v1. Укажите этот базовый URL в любом OpenAI SDK, передайте любую строку в качестве API-ключа (он игнорируется) и установите model в значение имени модели, которую вы загрузили. Существующий код для OpenAI обычно работает без изменений, за исключением базового URL и ключа.