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

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

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

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

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

Объем оперативной памяти, занимаемый моделью, примерно равен размеру её файла плюс около одного гигабайта накладных расходов во время выполнения, а также дополнительный объем для контекстного окна. Модели в Ollama по умолчанию используют 4-битную квантование (обозначается как Q4), что требует около половины гигабайта ОЗУ на каждый миллиард параметров. Арифметика проста, и именно она определяет всё.

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

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

Практический вывод: небольшие квантованные модели на CPU действительно полезны для черновиков, суммаризации и классификации, если вы готовы смириться с темпом работы. Для всего, что требует большего размера или скорости, закладывайте бюджет на инстанс с GPU.

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

Установка 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 сразу после завершения запроса. systemctl edit автоматически перезагружает файлы юнитов, поэтому выполните перезапуск для применения изменений:

sudo systemctl restart ollama

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

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

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

Итак, вот единственная ошибка, которую нельзя допускать: не задавайте OLLAMA_HOST=0.0.0.0 и не открывайте порт 11434 в firewall. Это публикует неаутентифицированный inference server для всего Интернета. Никакая конфигурация не делает прямой доступ к 11434 на 0.0.0.0 безопасным, потому что в Ollama нечего настраивать: аутентификация там просто отсутствует. Это правило относится к данному сервису, а не запрещает открывать порты вообще: самостоятельно размещённый relay RustDesk для удалённого рабочего стола должен принимать публичный трафик, чтобы выполнять свою задачу, и обеспечивает это собственной аутентификацией по ключу и коротким документированным списком портов. У Ollama нет ни того, ни другого.

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

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

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

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 должен быть именем модели, которую вы уже загрузили; при указании неизвестного имени вернется ошибка model "x" not found, try pulling it first. Обычный вызов 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, либо в журнале сервера появляется llama runner process has terminated: signal: killed. Процесс остановил Linux OOM killer, потому что модели требуется больше оперативной памяти, чем есть на сервере. Подтвердите причину с помощью sudo dmesg | grep -i oom. В выводе будет строка вроде Out of memory: Killed process ... (ollama). Решение — использовать меньшую модель или модель с более агрессивной квантизацией, выбрать llama3.2:3b вместо 13B либо добавить swap. Тогда нагрузка, которая лишь немного превышает объём физической памяти, будет медленно выполняться вместо аварийного завершения. Swap превращает мгновенное падение в медленный ответ. Он не делает запуск модели 70B практичным на сервере с 4 GB памяти. Сообщение о завершении обычно не появляется, если вы случайно не наблюдаете терминал. Поэтому на сервере, к которому вы подключаетесь удалённо, назначьте для ollama.service отдельный юнит OnFailure=, отправляющий уведомления на развёрнутый вами сервер ntfy для push-уведомлений. Так вы узнаете о сбое сразу, а не при следующем запросе.

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

Первый токен появляется очень нескоро, затем всё работает нормально. Холодная модель не выводит ничего от пяти до тридцати секунд, а затем начинает передавать ответ в обычном режиме. При первой загрузке веса считываются с диска в RAM, а медленное хранилище увеличивает это время. После загрузки модель остаётся в памяти в течение OLLAMA_KEEP_ALIVE, поэтому на второй запрос отвечает сразу. Если первая загрузка превышает тайм-аут на каком-либо участке цепочки вызовов, вы получите ошибку, а не медленный ответ. Определение слоя, который сообщил об истечении контекста выполнения показывает, у какого компонента не хватило времени: у клиента, прокси или самой загрузки. Увеличьте это значение, если паузы мешают. Используйте ollama ps, чтобы проверить, загружена ли сейчас модель.

Всё работает слишком медленно. Скорость составляет десять токенов в секунду или меньше, при этом ошибки отсутствуют. Это штатный режим работы инференса на CPU. ollama ps показывает 100% CPU, что означает отсутствие GPU. Это не ошибка, и никакие настройки её не исправят, так как ограничением является пропускная способность памяти, а не конфигурация. Используйте модель меньшего размера, смиритесь со скоростью или перейдите на инстанс с GPU. Перед тем как делать выводы о неисправности, измерьте реальную скорость с помощью --verbose.

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, открыли брандмауэр и теперь видите загрузку моделей, которые вы не запускали, или процессор загружен на 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, а затем пересоздайте контейнер. Не фиксируйте версии на длительный срок: качество моделей и среда выполнения быстро меняются, поэтому читайте примечания к выпускам и проводите тестирование производительности на своем оборудовании, вместо того чтобы полагаться на показатели прошлого квартала.

FAQ

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

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

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

Примерное правило для стандартных 4-битных квантованных моделей: около 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, получает полный контроль над ней. Именно поэтому по умолчанию она привязывается к 127.0.0.1, и именно поэтому вы никогда не должны открывать порт 11434 на 0.0.0.0 для доступа из интернета. Обращайтесь к ней локально, через частную VPN или через reverse proxy, который добавляет авторизацию.

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

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

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

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