Open WebUI et llama.cpp : comment configurer une recherche web locale avec Qwen et Docker sous Windows

Open WebUI peut fonctionner avec des modèles locaux via llama.cpp et même effectuer des recherches web, mais sans configuration manuelle les résultats sont souvent faibles. L'auteur d'un guide pratique a montré comment assembler une configuration fonctionnelle sur Windows avec Qwen, Docker et des modèles séparés pour l'embedding et le reranking, pour que la recherche commence à retourner des réponses significatives.

Comment fonctionne la configuration

L'idée de base est simple : llama.cpp exécute un serveur local avec plusieurs modèles GGUF, et Open WebUI sert d'interface au-dessus. Pour la génération principale, l'auteur utilise deux versions d'un grand modèle Qwen3.

5-27B-UD-Q4_K_XL — avec et sans reasoning. Séparément sont exécutés un modèle compact Qwen3.5-2B pour les tâches auxiliaires, Qwen3-Embedding-4B pour la vectorisation et Qwen3-Reranker-4B pour le réordonnancement des résultats de recherche.

Cet arrangement est nécessaire car la recherche web dans Open WebUI est essentiellement liée à un pipeline RAG. Si vous laissez les paramètres par défaut, le système peut formellement trouver des pages, mais extrait mal le sens, perd des fragments de texte pertinents et retourne des réponses faibles. Selon l'auteur, c'est exactement ce qui rendait la recherche presque inutile dans la configuration par défaut.

Le guide est orienté vers un matériel assez spécifique : Windows 10 22H2, RTX 3090 avec 24 GB VRAM et 32 GB de RAM. Même sur une telle machine, le grand modèle ne se charge pas instantanément : la première réponse peut prendre jusqu'à une minute, et tout chargement parallèle supplémentaire consomme rapidement la mémoire vidéo.

Paramètres clés

L'idée la plus importante de l'article est que vous devez configurer non seulement le modèle de chat, mais toute l'infrastructure autour de lui. L'auteur exécute les modèles dans llama-server, et Open WebUI se connecte via une URL locale via Docker.

• Modèle principal pour les réponses — Qwen3.5-27B-UD-Q4_K_XL, séparément en mode instruct et thinking.
• Modèle auxiliaire — Qwen3.5-2B-BF16 : il génère les titres de chat et effectue les petites tâches de fond plus rapidement que le grand modèle.
• Pour la recherche web, des modèles séparés Qwen3-Embedding-4B-f16 et Qwen3-Reranker-4B-f16 sont utilisés.
• Apache Tika est connecté en tant que moteur d'extraction de contenu, et Open WebUI est exécuté via Docker Compose.
• Brave Search est choisi comme fournisseur de recherche ; l'auteur mentionne également Exa, Tavily, Serper, Linkup et Valyu.

Une nuance séparée concerne les paramètres de llama.cpp. Dans la configuration, l'auteur désactive mmap, limite le nombre de modèles chargés simultanément via `--models-max 1`, configure le déchargement de VRAM par délai d'attente et divise le contexte entre les requêtes parallèles. Ce n'est pas cosmétique : si vous chargez un deuxième modèle lourd simultanément avec le modèle principal, les performances chutent fortement.

Dans l'interface Open WebUI, il y a aussi des endroits critiques. Dans le panneau d'administration, vous devez explicitement spécifier l'URL du serveur de modèles local, puis sélectionner un petit modèle pour les tâches locales et externes de l'interface, et dans la section Documents connecter Tika, le modèle d'embedding et un endpoint de rerank externe. Ce n'est qu'après cela que la recherche web commence à fonctionner comme une chaîne complète, plutôt que comme un simple wrapper sur une requête de navigateur.

Limitations et nuances

Même après la configuration, un tel schéma ne transforme pas la pile locale en remplacement des services en nuage payants. L'auteur affirme explicitement que le résultat ne correspond toujours pas aux solutions propriétaires, mais peut être suffisant si la confidentialité, le fonctionnement hors ligne ou la possibilité d'exécuter des modèles non restreints sans APIs externes est importante.

Il y a aussi des compromis pratiques. Si vous spécifiez un modèle de reasoning pour les tâches auxiliaires de l'interface, Open WebUI commence à dépenser trop de temps même pour la génération du titre du chat. Avec la recherche web, les modèles d'embedding et de reranking sont chargés en supplément, donc la charge VRAM et les latences augmentent davantage. Pour vérifier ce qui est actuellement chargé, l'auteur recommande de consulter les logs du llama-server.

L'article contient aussi plusieurs extensions pour ceux qui veulent aller plus loin. Au lieu de Tika, vous pouvez essayer Docling pour des documents plus complexes. SearXNG convient à un moteur de recherche local, bien que ses backends puissent être temporairement bannis. Le chargeur web basé sur Playwright a fonctionné pour l'auteur, mais était trop lent — la latence était mesurée en minutes, pas en secondes. Plus tard, il a également réduit le contexte du modèle principal à 32768 tokens : cela a aidé à éliminer les blocages quand l'onglet de chat était ouvert, car le modèle a cessé d'occuper plus de VRAM libre que ce que le système pouvait soutenir de manière stable.

Ce que cela signifie

Le matériel montre bien qu'une pile AI locale peut déjà aujourd'hui être assemblée à partir de composants ouverts, mais la qualité dépend non pas tant d'un « meilleur modèle » que de la combinaison correcte de génération, embedding, reranking et extraction de contenu. Pour les développeurs, c'est une recette pratique : si Open WebUI avec recherche web fonctionne mal pour vous, vous devez commencer non pas par remplacer le modèle, mais par reconstruire toute la configuration RAG.