Open WebUI y llama.cpp: cómo configurar una búsqueda web local con Qwen y Docker en Windows

Open WebUI puede trabajar con modelos locales a través de llama.cpp e incluso hacer búsquedas web, pero sin ajustes manuales los resultados suelen ser pobres. El autor de una guía práctica explica cómo montar en Windows una configuración funcional con Qwen, Docker y modelos separados para embeddings y reranking, de modo que la búsqueda empiece a dar respuestas con sentido.

Cómo funciona el conjunto

La idea básica es sencilla: llama.cpp levanta un servidor local con varios modelos GGUF y Open WebUI actúa como interfaz sobre él. Para la generación principal, el autor usa dos versiones del mismo modelo grande, Qwen3.5-27B-UD-Q4_K_XL: una con reasoning y otra sin él. Aparte se ejecutan el compacto Qwen3.5-2B para tareas auxiliares, Qwen3-Embedding-4B para la vectorización y Qwen3-Reranker-4B para reordenar los resultados de búsqueda.

Este reparto es necesario porque la búsqueda web de Open WebUI depende, en la práctica, de un pipeline RAG. Con la configuración por defecto, el sistema puede encontrar páginas, pero extrae mal su contenido, pierde fragmentos relevantes y genera respuestas débiles. Según el autor, eso era precisamente lo que hacía la búsqueda casi inútil con la configuración predeterminada.

La guía está pensada para un hardware bastante concreto: Windows 10 22H2, una RTX 3090 con 24 GB de VRAM y 32 GB de RAM. Incluso en esta máquina, el modelo grande no se carga al instante: la primera respuesta puede tardar hasta un minuto, y cualquier carga paralela innecesaria agota rápidamente la memoria de vídeo.

Ajustes clave

La idea principal del artículo es que no basta con configurar el modelo de chat: hay que ajustar toda la infraestructura que lo rodea. El autor ejecuta los modelos en llama-server y conecta Open WebUI a él mediante una URL local a través de Docker.

• Modelo principal para las respuestas: Qwen3.5-27B-UD-Q4_K_XL, por separado en modo instruct y thinking.
• Modelo auxiliar: Qwen3.5-2B-BF16, que genera los títulos de los chats y realiza pequeñas tareas en segundo plano más rápido que el modelo grande.
• Para la búsqueda web se usan Qwen3-Embedding-4B-f16 y Qwen3-Reranker-4B-f16 de forma independiente.
• Como motor de extracción de contenido se conecta Apache Tika, y Open WebUI se ejecuta mediante Docker Compose.
• El proveedor de búsqueda elegido es Brave Search; el autor también menciona Exa, Tavily, Serper, Linkup y Valyu.

Los parámetros de llama.cpp merecen mención aparte. En la configuración, el autor desactiva mmap, limita el número de modelos cargados simultáneamente con `--models-max 1`, configura la descarga de la VRAM por tiempo de espera y reparte el contexto entre las solicitudes paralelas. No son ajustes cosméticos: si se carga un segundo modelo pesado junto al principal, el rendimiento cae en picado.

La interfaz de Open WebUI también tiene puntos críticos. En el panel de administración hay que indicar explícitamente la URL del servidor local de modelos, después elegir el modelo pequeño para las tareas locales y externas de la interfaz y, en la sección Documents, conectar Tika, el modelo de embeddings y el endpoint externo de rerank. Solo entonces la búsqueda web funciona como una cadena completa y no como una simple capa sobre una consulta del navegador.

Limitaciones y matices

Ni siquiera con todo configurado este esquema convierte el stack local en un sustituto de los servicios en la nube de pago. El autor reconoce abiertamente que el resultado sigue sin estar a la altura de las soluciones propietarias, pero puede ser suficiente si se priorizan la privacidad, un entorno offline o la posibilidad de ejecutar modelos unrestricted sin API externas.

También hay compromisos prácticos. Si se asigna un modelo de razonamiento a las tareas auxiliares de la interfaz, Open WebUI empieza a dedicar demasiado tiempo incluso a generar el título del chat. Durante la búsqueda web se cargan además los modelos de embeddings y reranking, lo que aumenta todavía más el uso de VRAM y la latencia. Para comprobar qué está cargado en cada momento, el autor recomienda revisar los logs de llama-server.

El artículo incluye varias ampliaciones para quienes quieran ir más allá. En lugar de Tika se puede probar Docling para documentos más complejos. Como motor de búsqueda local sirve SearXNG, aunque sus backends pueden sufrir bloqueos temporales. El cargador web basado en Playwright llegó a funcionar, pero era demasiado lento: el retraso se medía en minutos, no en segundos. Más adelante, el autor también redujo el contexto del modelo principal a 32768 tokens, lo que eliminó los cuelgues con la pestaña del chat abierta, porque el modelo dejó de ocupar más VRAM libre de la que el sistema podía soportar de forma estable.

Qué significa esto

El texto demuestra que hoy ya es posible montar un stack de AI local con componentes abiertos, pero la calidad depende menos de un único «mejor modelo» que de combinar correctamente generación, embeddings, reranking y extracción de contenido. Para los desarrolladores es una receta práctica: si Open WebUI con búsqueda web te funciona mal, no hay que empezar cambiando el modelo, sino reconstruyendo toda la configuración RAG.