Поднимаем Llama 3 в облаке: Ollama и Open WebUI

Локально запустить LLM сегодня можно за десять минут — например, с помощью LM Studio. Но как только модели нужно дать доступ команде, подключить RAG или встроить ее в сервис — такого подхода зачастую недостаточно.

В этой статье мы разберем, как развернуть LLM на сервере, какие ресурсы для этого понадобятся и с какими сложностями можно столкнуться.

Перейдем к практике

Развернуть модель в облаке или на собственном сервере можно несколькими способами — выбор зависит от задач и доступных ресурсов.
В качестве базового решения рассмотрим связку Ollama + Open WebUI. Это типичная архитектура «движок + интерфейс», которая сочетает простоту запуска с возможностью дальнейшего расширения. 

Ollama отвечает за запуск и управление жизненным циклом моделей — их загрузку, запуск и остановку. Инструмент предоставляет удобный CLI и HTTP API для взаимодействия.

Open WebUI — веб-интерфейс с привычным чат-форматом, админкой и возможностями расширения.

План следующий:

1. выберем модель;

2. развернем Ollama и Open WebUI в докере;

3. разберем несколько важных настроек Ollama;

4. проверим RAG на локальных документах.

Выбор модели

Начать поиск моделей для Ollama можно со следующих репозиториев: https://ollama.com/search или https://huggingface.co.

При выборе модели важно учитывать несколько параметров:

Семейство модели. Разные семейства оптимизированы под разные задачи: генерацию текста, следование инструкциям, мультиязычность и т.д.
Для сравнения можно посмотреть llm leaderboard;

• Количество параметров. Чем больше параметров, тем выше потенциальное качество, но вместе с этим растут и требования к ресурсам;

• Базовая vs Instruct-модель. Базовая модель хорошо подходит для генерации текста, также ее можно использовать для дообучения. Instruct-модель дополнительно обучена следовать инструкциям пользователя;

• Квантование. Это способ с некоторой потерей качества уменьшить размер модели за счет снижения точности весов. Обозначение «q» показывает количество бит на вес: чем меньше — тем больше потерь в качестве;

• Контекстное окно. Объем текста, который модель может учитывать в рамках одного запроса. 4K–8K токенов обычно достаточно для коротких диалогов, 32K–128K токенов подходят для работы с большими документами и длинными переписками;

• Размер модели. Это объем файлов модели на диске. 

В идеале модель должна полностью помещаться в VRAM — это обеспечивает максимальную скорость инференса. Если видеопамяти недостаточно или GPU отсутствует, модель можно частично или полностью запускать в оперативной памяти (RAM), однако скорость работы в таком режиме будет заметно ниже.

На практике желательно иметь дополнительный запас памяти, поскольку часть памяти дополнительно расходуется на KV-cache и обработку контекста.

Например, модели размером:

• 8 ГБ желательно запускать с 10–12 ГБ VRAM;

• 20–24 ГБ обычно требуют около 32 ГБ VRAM;

• 40+ ГБ — уже 48 ГБ VRAM и выше.

Что будем использовать

В качестве примера возьмем Llama 3.1. Она считается одним из самых сильных open-weight решений, старшая версия 405B по ряду бенчмарков  сопоставима с GPT-4 и Claude, однако требует серьезной инфраструктуры: нескольких GPU и сотен гигабайт памяти.

Для практики будем использовать более компактный вариант: llama3.1:8b-instruct-q8_0. Размер модели составляет около 8,5 ГБ, поэтому для комфортной работы желательно иметь видеокарту с объемом VRAM от 10 ГБ с учетом дополнительных затрат памяти на инференс.

Разворачиваем Ollama и Open WebUI в Docker

В этом примере используем образ из AI-маркетплейса Selectel, в конце приложим готовый docker-compose.yml

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

Закажем сервер с уже предустановленным Docker и образами Ollama и Open WebUI.

Для этого открываем панель управления, выбираем Продукты → AI-маркетплейс. 

Нажимаем Создать сервер.

Доступно несколько готовых образов для разных AI-сценариев. В нашем случае в источнике выбираем OPENWEBUI — образ с предустановленными Ollama и Open WebUI.

Обратите внимание: Ollama устанавливается автоматически только при создании сервера с GPU.

В конфигурации без видеокарты Open WebUI работает только как интерфейс для подключения к внешним LLM.

Для создания сервера с GPU нажмите Добавить GPU. 

Выбираем GPU-конфигурацию и в фильтре по типу видеокарт выбираем желаемое железо, в нашем случае — A2. Эта карта оптимальна для старта: ее 16 ГБ видеопамяти позволят запустить модель и оставить запас под длинный контекст.

Не забываем про настройки доступа. Обязательно сохраните пароль суперпользователя (root) и добавьте свой SSH-ключ. Это позволит вам подключаться к серверу напрямую через терминал.

Далее нажимаем Создать сервер. Когда сервер создался — не спешим нажимать Перейти в GUI, так как это сообщение о готовности сервера, в фоне еще идет запуск Docker-контейнеров.

При подключении к серверу вы увидите приветствие и важное замечание о безопасности.

Если вывести список контейнеров, то по статусу видим, что Open WebUI еще запускается.

Также видим, что у Open WebUI проброшены порты и по публичному IP сервера на 3000 порту мы получим доступ к веб-интерфейсу.

Не публикуйте Open WebUI и Ollama в интернет без ограничений доступа. Особенно это важно при работе с внутренними документами и RAG. В рамках демонстрации ограничим доступ с помощью iptables.

Разрешим входящий трафик на порт 3000 только с нашего публичного адреса

iptables -t raw -A PREROUTING -s X.X.X.X -p tcp –dport 3000 -j ACCEPT# Замените X.X.X.X на ваш публичный ip

Запретим все остальные  подключения к порту 3000

iptables -t raw -A PREROUTING -p tcp –dport 3000 -j DROP

Скачиваем модель 

Контейнер с Ollama уже работает, поэтому, пока ждем Open WebUI, можно скачать модель.

docker exec ollama ollama pull llama3.1:8b-instruct-q8_0

Этой командой мы скачиваем модель в Ollama внутри Docker-контейнера.

Переходим в Open WebUI

Дожидаемся, когда статус Open WebUI будет healthy.

Теперь Open WebUI будет доступен по публичному (белому) IP нашего сервера на порту 3000.

При первом входе нужно пройти регистрацию администратора — после этого вы получите доступ к привычному чат-интерфейсу.
Первый запрос и запросы после длительного простоя могут быть медленными, так как модель приходится заново загружать в VRAM. Зададим простой вопрос, чтобы проверить, что все работает. На скриншоте ниже — ответ модели на просьбу объяснить теорему Пифагора:

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Пара подводных камней

Обработка параллельных запросов

По умолчанию запросы обрабатываются последовательно. Сделаем два одновременных запроса:

Видим, что пока выполняется первый запрос, второй ожидает:

Только после выполнения первого запроса получаем ответ на второй.

Чтобы разрешить параллельную обработку запросов, нужно задать переменную окружения OLLAMA_NUM_PARALLEL. 
При этом важно учитывать, что с ростом числа параллельных запросов увеличивается и потребление памяти: в документации Ollama указано, что требуемая память масштабируется пропорционально OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH.

TTFT — Time To First Token

Вы подняли LLM, написали запрос, и… ждете ответ несколько минут. В Ollama модели выгружаются из памяти после периода простоя, и при новом запросе сначала происходит загрузка модели в память, а потом уже обработка запроса.

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

Список моделей у пользователей пуст

В Open Web UI есть встроенная админка, вы сможете создавать: группы, пользователей и настраивать права.

Если вы создали пользователей и группы, все им разрешили, но у пользователей список доступных моделей пуст, то в настройках администратора проверьте права доступа в самой модели.

Переходим в Панель администратора → Настройки → Модели.

В настройках модели нажимаем на Доступ.

Далее Добавить доступ

Добавляем доступ для нужных групп и пользователей.

Теперь, модель должна быть доступна для пользователей.

Отредактируем docker-compose:

nano /opt/openwebui/compose/docker-compose.yml

Добавим OLLAMA_NUM_PARALLEL и OLLAMA_KEEP_ALIVE в переменные окружения для Ollama командой:

ollama:     image: «docker-registry.selectel.ru/ollama/ollama:0.17.6»     container_name: ollama     restart: always     healthcheck:       test: ollama —version || exit 1     entrypoint: ollama serve     environment:       OLLAMA_KEEP_ALIVE: 1h       OLLAMA_NUM_PARALLEL: 4     volumes:       — «ollama-data:/root/.ollama»     deploy:       resources:         reservations:           devices:             — driver: nvidia               count: all               capabilities: [gpu]

Если запускаете модель на CPU,  добавьте в окружение OLLAMA_DEVICE=cpu и удалите секцию с GPU-ресурсами:

  deploy:       resources:         reservations:           devices:             — driver: nvidia               count: all               capabilities: [gpu]

Если вы не хотите скачивать модель руками, то можно создать entrypoint.sh. Этот скрипт автоматически скачивает модель сразу при старте контейнера, избавляя вас от необходимости заходить внутрь и вводить команды вручную:

#!/bin/bash

/bin/ollama serve &

pid=$!

sleep 5

ollama pull <ИМЯ-ВАШЕЙ-МОДЕЛИ>

wait $pid

И в docker-compose заменить entrypoint: ollama serve на entrypoint: [«/usr/bin/bash», «/entrypoint.sh»].

Перезапускаем сервис:

docker compose -f /opt/openwebui/compose/docker-compose.yml down ollama

docker compose -f /opt/openwebui/compose/docker-compose.yml up -d ollamа

Теперь проверим еще раз.

Как видим, запросы выполняются параллельно.

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

Такой подход хорош, если нужно быстро получить результат без погружения в детали.
Далее можно расширять инструментарий: есть поддержка MCP, можно настроить RAG для работы с локальными файлами или подключить Tools.
Ниже готовый docker-compose.yml для самостоятельной установки. 

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

• Docker и Docker Compose;

• NVIDIA-драйверы (если планируете запуск на GPU);

• NVIDIA Container Toolkit (иначе контейнеры не смогут использовать GPU).

services:   openwebui:     image: «ghcr.io/open-webui/open-webui:v0.8.8-cuda»     container_name: openwebui     restart: always     ports:       — «3000:8080»     volumes:       — «open-webui:/app/backend/data»     environment:       OLLAMA_BASE_URL: http://ollama:11434       ENABLE_EVALUATION_ARENA_MODELS: false       RAG_TEXT_SPLITTER: markdown_header       CHUNK_SIZE: 1800       CHUNK_OVERLAP: 200       ENABLE_RAG_HYBRID_SEARCH: false       RAG_TOP_K: 15     gpus: all   ollama:     image: «ollama/ollama:0.17.6»     container_name: ollama     restart: always     entrypoint: ollama serve     healthcheck:       test: ollama —version || exit 1     environment:       OLLAMA_HOST: 0.0.0.0:11434       OLLAMA_KEEP_ALIVE: 1h       OLLAMA_NUM_PARALLEL: 4     volumes:       — «ollama-data:/root/.ollama»     gpus: all volumes:   open-webui:   ollama-data:

Рабочее пространство

Просто чат с моделью — скорее всего, не то, что ожидается от своей LLM-инфраструктуры.

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

Knowledge

Знания — это встроенная система,которая позволяет создавать коллекции документов и использовать их как контекст для LLM при генерации ответов. Это полезно, когда модель должна опираться на внутренние руководства, спецификации или любые другие данные, не входящие в ее обучение. По сути, это RAG.

RAG (Retrieval-Augmented Generation) — это подход, при котором языковая модель отвечает не только на основе данных, полученных во время обучения, но и использует внешние источники: документы, инструкции, регламенты и код.

Работает это следующим образом: на этапе индексации данные делятся на фрагменты — чанки, и для каждого из них считается embedding — векторное представление содержимого. Когда приходит запрос, для него тоже строится embedding, после чего система ищет в векторной базе ближайшие фрагменты по метрике сходства и передает их в контекст LLM.

Такой подход позволяет работать с закрытыми данными, получать ответы на основе актуальной информации и снижать количество галлюцинаций модели. В Open WebUi есть встроенная поддержка RAG: можно загружать документы, создавать базы знаний и использовать их как источник контекста для модели.
В боковом меню Open WebUI перейдите в раздел Рабочее пространство.

Создадим новую коллекцию, для этого нажимаем Знания → New knowledge.

Для проверки возьмем пару первоапрельских RFC.

Дадим название коллекции RFC, и краткео описание First April RFC
Нажимаем Создать знание.

Загрузим файлы в формате PDF.

Для этого нажимаем на «+» → Добавить контент → Загрузить файлы.

Выбираем файлы, которые нужно загрузить:

После загрузки файлы будут отображаться в коллекции.

И попросим модель ответить с учетом «внутреннего» документа.

Первый блин комом.
RAG почти всегда требует настройки, на качество ответов влияют:

• способ разбиения документов на чанки;

• размер чанков текста;

• overlap между чанками;

• системный промпт;

• качество исходных документов. 

В более сложных сценариях обычно используют отдельные embedding-модели и специализированные векторные базы данных для повышения точности поиска.
Рекомендуем разбивать большие файлы на логические части и использовать понятные названия и описания это упростит поиск и управление коллекциями. Пока же мы используем решение «из коробки», поэтому ограничимся настройкой встроенных параметров.
Переходим в Панель администратора → Настройки → Documents.

Механизм извлечения контента — как ни странно, по умолчанию этот параметр может быть не задан, тогда выставим значение «По умолчанию». Разделитель текста — Токен.

Немного уменьшим размер чанков — сделаем 800, перекрытие — 120.

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

Поиск. Включим режим полного контекста и немного перепишем промпт. Мы добавим в шаблон RAG жесткую инструкцию: отвечать строго по предоставленному тексту, чтобы минимизировать галлюцинации модели.

В завершение в настройках файлов укажем поддерживаемые форматы документов, с которыми планируем работать.

Сохранимся и сначала проверим, работает ли вообще RAG. Введем запрос с ключевыми словами.

Отлично, теперь проверим семантический поиск.

Все работает! Давайте теперь представим, что у нас есть некие внутренние инструкции, и попросим LLM отвечать на их основе.

Prompts

Промпты — это готовые шаблоны запросов.

Этот раздел позволяет сохранять часто используемые сценарии и быстро вызывать их через специальные команды (slash commands) прямо в чате.

Для демонстрации работы с промптами создадим новую коллекцию знаний.

И добавим туда инструкции по настройке VLAN — статья с сайта xgu.ru и выдуманный VLAN-план компании.

Код:# VLAN Deployment Overview ## Purpose Документ описывает VLAN-схему, IP-адреса управления, назначение портов и свободные порты на коммутаторах. — # Office A ## Management Access — Switch Name: `a-office-sw` — Management VLAN: `VLAN 99` — Management IP: `192.168.99.10` ### SSH Access «`bash ssh admin@192.168.99.10 «` — ## VLAN Allocation | VLAN ID | Name | Purpose | Subnet | Status | |———-|————|————————|——————-|—————| | 10 | USERS | Employee workstations | 10.10.10.0/24 | Active | | 20 | VOICE | IP telephony | 10.10.20.0/24 | Planned | | 30 | SERVERS | Local servers | 10.10.30.0/24 | Active | | 99 | MGMT | Network management | 192.168.99.0/24 | Active | — ## Port Allocation | Ports | VLAN | Usage | |————-|——|————————| | Gi0/1-12 | 10 | User workstations | | Gi0/13-18 | 30 | Servers | | Gi0/19-23 | FREE | Reserved / unused | | Gi0/24 | trunk| Uplink to core switch | — ## Planned VLANs | VLAN ID | Purpose | Notes | |———-|—————|———————————| | 20 | IP telephony | Reserved for future deployment | — ## Trunk Configuration ### Allowed VLANs — 10 — 20 — 30 — 99 ### Native VLAN — 99 — # Office B ## Management Access — Switch Name: `b-office-sw` — Management VLAN: `VLAN 199` — Management IP: `192.168.199.10` ### SSH Access «`bash ssh admin@192.168.199.10 «` — ## VLAN Allocation | VLAN ID | Name | Purpose | Subnet | Status | |———-|————|————————|———————|—————| | 110 | USERS | Employee workstations | 10.20.10.0/24 | Active | | 120 | VOICE | IP telephony | 10.20.20.0/24 | Planned | | 130 | SERVERS | Local servers | 10.20.30.0/24 | Active | | 199 | MGMT | Network management | 192.168.199.0/24 | Active | — ## Port Allocation | Ports | VLAN | Usage | |————-|——|—————————| | Gi0/1-10 | 110 | User workstations | | Gi0/11-16 | 130 | Servers | | Gi0/17-23 | FREE | Reserved / unused | | Gi0/24 | trunk| Uplink to distribution | — ## Planned VLANs | VLAN ID | Purpose | Notes | |———-|—————|———————————| | 120 | IP telephony | Reserved for future deployment | — ## Trunk Configuration ### Allowed VLANs — 110 — 120 — 130 — 199 ### Native VLAN — 199 — # Security Recommendations — Disable all unused ports. — Configure all access ports explicitly. — Restrict allowed VLANs on trunk ports. — Do not use VLAN 1 for production traffic. — Use separate management VLANs. — Shutdown unused interfaces. — # Quick Access Summary | Office | Switch | Management IP | Access Method | |————|—————|——————|—————-| | Office A | a-office-sw | 192.168.99.10 | SSH | | Office B | b-office-sw | 192.168.199.10 | SSH |

Попросим LLM помочь с конфигурацией с учетом «внутренней документации».

Получилось не совсем то, что мы хотели.

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

Результат — ну, почти. IP-адрес настраивать мы не просили.
Это короткий вариант для демонстрации, в реальности будет больше инструкций. Если вам всегда нужно определенное поведение — опишите его в системном промпте Open WebUI.

Настройка сценариев через промпты 

Если же сценариев несколько, то удобно добавить несколько промптов в рабочее пространство.
Перейдем в Рабочее пространство → Промпты → Добавить промпт.

Теперь в чате достаточно ввести символ «/» и выбрать нужный промпт.

После этого шаблон автоматически подставится в поле ввода.

Подробнее о промптах можно почитать в документации.

Skills

Если промпт — это скорее шаблон запроса, то skills можно рассматривать как набор правил для выполнения конкретной задачи. Например, это могут быть инструкции для ревью кода, стандарты написания технических текстов или пошаговые сценарии устранения неполадок.

По смыслу skills похожи на подключаемый системный промпт: они помогают заранее описать, как модель должна действовать в определенном сценарии, и не повторять эти правила в каждом запросе.

Это удобный способ зафиксировать внутренние практики компании: требования к оформлению ответов, правила диагностики, стандарты конфигураций или чек-листы для типовых задач. Чем точнее описан skill, тем стабильнее модель будет воспроизводить нужный подход в ответах.

В Open WebUI  есть два режима работы навыков в зависимости от способа активации.

Навыки, выбранные пользователем в чате через «$»:

• при упоминании навыка в чате символом «$», его полное содержимоемгновенно внедряется в системный промпт;

• подходит для разовых задач, требующих детальных правил.

Навыки, прикрепленные к модели:

• используют архитектуру ленивой загрузки для экономии контекстного окна;

• в системный промпт загружается только легкий “манифест” — имя и краткое описание навыка;

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

• хорошо подходит для постоянных наборов правил, когда не все нужны в каждом сообщении.

Для демонстрации используем первый вариант. Перейдем в Рабочее пространство → Навыки → Новый навык.

Добавим Python Style Guide и сравним, как LLM напишет код с ним и без него.

Сначала попросим LLM написать простую merge-функцию.

Теперь, тот же самый запрос, но с подключенным навыком.

Да, суть не изменилась, но изменился doc-string и нет лишних комментариев. На практике skills отлично работает для написания тестов, именно в том формате, которые приняты в компании или команде.

Tools

Модели могут использовать дополнительные инструменты для расширения своих возможностей.

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

В Open WebUI можно написать собственный инструмент или использовать готовые из community-каталога. Например, Web Search. 

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

Добавим свой инструмент

Перейдем в Рабочее пространство → Инструменты → Новый инструмент.

Добавим простой код для tcp-проверок.

import socket class Tools:    def tcp_check(self, host: str, port: int = 53) -> str:        «»»        Проверка TCP-доступности хоста.        «»»        try:            with socket.create_connection((host, port), timeout=3):                return f»{host}:{port} доступен»        except Exception as e:            return f»{host}:{port} недоступен: {e}»

Добавим инструмент в чате, для этого нажмем на Интеграции, далее Инструменты и включим наш инструмент.

Проверяем:

Отлично, демонстрационный пример работает.
Далее можно добавить работу с базой данных, Docker или, например,
Atlassian MCP. Последний обеспечивает интеграцию с Jira и Confluence: тогда модель сможет работать с задачами, документацией и проектами внутри экосистемы Atlassian напрямую через API — от вашего имени.

Заключение

Будем честны: Llama 3.1 8B — это не замена больших, коммерческих моделей и не универсальное решение для сложных задач. Для серьезной логики ее часто не хватает — модель начинает галлюцинировать там, где требуется глубокий контекст.

Но это хороший вариант, чтобы познакомиться с экосистемой self-hosted LLM.
На такой модели уже можно обкатывать пайплайны и переносить часть простых задач: первичную классификацию запросов, работу с внутренними документами, генерацию шаблонных ответов или вызов небольших утилит. На модель, как минимум, можно перенести например health checks, если вы активно используете ИИ-агентов, то это может быть неплохим решением для экономии токенов.

Я вижу главный профит селф-хостинга в облаке не в том, чтобы запустить модель на 8B. Смысл в том, когда какой-то модели перестанет хватать, вам не нужно бежать в магазин за картами типа RTX 4090 или A100. Вы просто пересобираете инстанс под рабочую лошадку на 70B, сохраняя при этом все свои наработки, доступы и, главное, конфиденциальность данных.

Источник: habr.com