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

Open WebUI peut exploiter des modèles locaux via llama.cpp et même effectuer des recherches web, mais sans configuration manuelle, les résultats restent souvent médiocres. L'auteur d'un guide pratique montre comment assembler sous Windows une stack fonctionnelle avec Qwen, Docker et des modèles dédiés à l'embedding et au reranking, afin que la recherche produise enfin des réponses pertinentes.

Comment s'articule la stack

Le principe est simple : llama.cpp lance un serveur local qui héberge plusieurs modèles GGUF, et Open WebUI sert d'interface par-dessus. Pour la génération principale, l'auteur utilise deux variantes d'un même grand modèle, Qwen3.5-27B-UD-Q4_K_XL : l'une avec reasoning, l'autre sans. À côté tournent le compact Qwen3.5-2B pour les tâches annexes, Qwen3-Embedding-4B pour la vectorisation et Qwen3-Reranker-4B pour le reclassement des résultats de recherche.

Cette répartition s'explique par le fait que la recherche web d'Open WebUI repose en pratique sur un pipeline RAG. Avec les réglages par défaut, le système peut techniquement trouver des pages, mais il en extrait mal le sens, perd des passages pertinents et produit des réponses faibles. Selon l'auteur, c'est précisément ce qui rendait la recherche presque inutile dans la configuration par défaut.

Le guide cible un matériel bien précis : Windows 10 22H2, une RTX 3090 avec 24 Go de VRAM et 32 Go 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 superflu consomme rapidement la mémoire vidéo.

Les réglages clés

Le message central de l'article : il ne suffit pas de configurer le modèle de chat, il faut paramétrer toute l'infrastructure qui l'entoure. L'auteur héberge les modèles dans llama-server et y connecte Open WebUI via une URL locale, à travers Docker.

• Modèle principal pour les réponses : Qwen3.5-27B-UD-Q4_K_XL, décliné séparément en modes instruct et thinking.
• Modèle utilitaire : Qwen3.5-2B-BF16. Il génère les titres des conversations et exécute les petites tâches d'arrière-plan plus vite que le grand modèle.
• La recherche web s'appuie sur des modèles dédiés : Qwen3-Embedding-4B-f16 et Qwen3-Reranker-4B-f16.
• Apache Tika sert de moteur d'extraction de contenu, et Open WebUI lui-même tourne via Docker Compose.
• Brave Search a été retenu comme fournisseur de recherche ; l'auteur mentionne aussi Exa, Tavily, Serper, Linkup et Valyu.

Les paramètres de llama.cpp méritent une attention particulière. Dans sa configuration, l'auteur désactive mmap, limite le nombre de modèles chargés simultanément avec `--models-max 1`, programme le déchargement de la VRAM après un délai d'inactivité et répartit le contexte entre les requêtes parallèles. Rien de cosmétique : charger un second modèle lourd en même temps que le principal fait chuter brutalement les performances.

L'interface d'Open WebUI comporte elle aussi des points critiques. Dans le panneau d'administration, il faut renseigner explicitement l'URL du serveur de modèles local, puis choisir le petit modèle pour les tâches locales et externes de l'interface. Dans la section Documents, il faut ensuite connecter Tika, le modèle d'embedding et l'endpoint de rerank externe. Ce n'est qu'à ce stade que la recherche web fonctionne comme une véritable chaîne, et non comme une simple surcouche formelle à une requête de navigateur.

Limites et subtilités

Même une fois configurée, cette architecture ne fait pas de la stack locale un substitut aux services cloud payants. L'auteur l'écrit sans détour : le résultat reste en deçà des solutions propriétaires, mais il peut suffire si la confidentialité, un environnement hors ligne ou la possibilité de faire tourner des modèles unrestricted sans API externe comptent pour vous.

Il faut aussi accepter des compromis pratiques. Si l'on assigne un modèle de raisonnement aux tâches annexes de l'interface, Open WebUI passe beaucoup trop de temps, même pour générer un titre de conversation. Lors d'une recherche web, les modèles d'embedding et de reranking se chargent en plus, ce qui accroît encore la pression sur la VRAM et les temps de latence. Pour vérifier ce qui est chargé à un instant donné, l'auteur recommande de consulter les logs de llama-server.

L'article propose aussi plusieurs pistes pour aller plus loin. Docling peut remplacer Tika pour les documents plus complexes. SearXNG convient comme moteur de recherche local, même si ses backends peuvent être temporairement bannis. Le chargeur web basé sur Playwright a bien démarré chez l'auteur, mais il s'est montré trop lent : la latence se comptait en minutes, et non plus en secondes. Plus tard, l'auteur a aussi réduit le contexte du modèle principal à 32768 tokens. Cela a supprimé les blocages lorsque l'onglet de chat restait ouvert, car le modèle a cessé d'occuper plus de VRAM libre que le système ne pouvait en supporter de manière stable.

Ce que cela signifie

Ce retour d'expérience montre bien qu'on peut déjà assembler une stack d'IA locale à partir de composants ouverts, mais que la qualité dépend moins d'un unique « meilleur modèle » que de la bonne articulation entre génération, embedding, reranking et extraction de contenu. Pour les développeurs, c'est une recette concrète : si la recherche web d'Open WebUI fonctionne mal chez vous, ne commencez pas par changer de modèle, mais par reconstruire toute la configuration RAG.