Open WebUI и llama.cpp: как настроить локальный веб-поиск с Qwen и Docker на Windows
Если веб-поиск в Open WebUI у тебя выдавал мусор, проблема, скорее всего, не в самой оболочке, а в конфигурации RAG-цепочки. Автор разобрал рабочую связку с lla

Open WebUI может работать с локальными моделями через llama.cpp и даже выполнять веб-поиск, но без ручной настройки результаты часто оказываются слабыми. Автор практического гайда показал, как собрать на Windows рабочую связку с Qwen, Docker и отдельными моделями для эмбеддинга и реранкинга, чтобы поиск начал выдавать осмысленные ответы.
Как устроена связка
Базовая идея проста: llama.cpp поднимает локальный сервер с несколькими GGUF-моделями, а Open WebUI выступает интерфейсом поверх него. Для основной генерации автор использует две версии одной большой модели Qwen3.
5-27B-UD-Q4_K_XL — с reasoning и без него. Отдельно запускаются компактная Qwen3.5-2B для служебных задач, Qwen3-Embedding-4B для векторизации и Qwen3-Reranker-4B для пересортировки результатов поиска.
Такой расклад нужен потому, что веб-поиск в Open WebUI фактически завязан на RAG-пайплайн. Если оставить стандартные настройки, система может формально находить страницы, но плохо извлекает смысл, теряет релевантные куски текста и выдаёт слабые ответы. По словам автора, именно это и делало поиск почти бесполезным в дефолтной конфигурации.
Гайд ориентирован на довольно конкретное железо: Windows 10 22H2, RTX 3090 с 24 ГБ VRAM и 32 ГБ оперативной памяти. Даже на такой машине большая модель загружается не мгновенно: первый ответ может занять до минуты, а лишняя параллельная загрузка быстро съедает видеопамять.
Ключевые настройки
Самая важная мысль статьи — нужно настраивать не только чат-модель, но всю инфраструктуру вокруг неё. Автор выносит модели в llama-server, а Open WebUI подключает к нему по локальному URL через Docker.
- Основная модель для ответов — Qwen3.5-27B-UD-Q4_K_XL, отдельно в режимах instruct и thinking.
- Служебная модель — Qwen3.5-2B-BF16: она генерирует названия чатов и выполняет мелкие фоновые задачи быстрее большой модели.
- Для веб-поиска используются отдельные Qwen3-Embedding-4B-f16 и Qwen3-Reranker-4B-f16.
- В качестве движка извлечения контента подключается Apache Tika, а сам Open WebUI запускается через Docker Compose.
- Поисковым провайдером выбран Brave Search; автор также упоминает Exa, Tavily, Serper, Linkup и Valyu. Отдельный нюанс — параметры llama.cpp. В конфиге автор отключает mmap, ограничивает число одновременно загруженных моделей через `--models-max 1`, настраивает выгрузку из VRAM по таймауту и делит контекст между параллельными запросами. Это не косметика: если загрузить вторую тяжёлую модель одновременно с основной, производительность резко проседает. В интерфейсе Open WebUI тоже есть критичные места. В административной панели нужно явно прописать URL локального сервера моделей, затем выбрать маленькую модель для локальных и внешних задач интерфейса, а в разделе Documents подключить Tika, embedding-модель и внешний rerank endpoint. Только после этого веб-поиск начинает работать как полноценная цепочка, а не как формальная надстройка над браузерным запросом.
Ограничения и нюансы
Даже после настройки такая схема не превращает локальный стек в замену платным облачным сервисам. Автор прямо пишет, что результат всё равно не дотягивает до проприетарных решений, но может быть достаточным, если важны приватность, офлайн-контур или возможность запускать unrestricted-модели без внешних API. Есть и практические компромиссы.
Если указать рассуждающую модель для служебных задач интерфейса, Open WebUI начинает тратить слишком много времени даже на генерацию названия чата. При веб-поиске дополнительно подгружаются embedding- и reranking-модели, так что нагрузка на VRAM и задержки растут ещё сильнее. Проверять, что именно сейчас загружено, автор советует по логам llama-server.
В статье есть и несколько расширений для тех, кто хочет пойти дальше. Вместо Tika можно попробовать Docling для более сложных документов. Для локального поискового движка подходит SearXNG, хотя его бэкенды могут временно баниться.
Веб-загрузчик на базе Playwright у автора запускался, но работал слишком медленно — задержка измерялась уже минутами, а не секундами. Позже он также уменьшил контекст основной модели до 32768 токенов: это помогло убрать зависания при открытой вкладке чата, потому что модель перестала занимать больше свободной VRAM, чем система могла стабильно выдержать.
Что это значит
Материал хорошо показывает, что локальный AI-стек сегодня уже можно собрать из открытых компонентов, но качество зависит не столько от одной «лучшей модели», сколько от правильной связки генерации, эмбеддинга, реранкинга и извлечения контента. Для разработчиков это практичный рецепт: если Open WebUI с веб-поиском у тебя работает плохо, начинать нужно не с замены модели, а с пересборки всей RAG-конфигурации.