Comparatif · IA & agents
Ollama, LM Studio, Open WebUI : les docs
Docs Ollama, LM Studio et Open WebUI lues le 2026-10-18. Aucun test n’a été exécuté, et aucun prix n’est recopié.
Ollama, LM Studio et Open WebUI ne font pas le même métier dans les docs lues le 2026-10-18. Ollama sert des modèles, en local ou via son API cloud. LM Studio est une application locale qui charge un modèle et expose un serveur. Open WebUI est une interface que vous hébergez, branchée sur Ollama ou sur une API compatible OpenAI. Les mettre sur une seule ligne de « performances » n’a pas de sens tant qu’on n’a pas dit qui exécute le modèle. Aucun test n’a été exécuté pour écrire cette page, et aucun prix n’est recopié.
Ollama
Pages lues : Quickstart, Introduction API, compatibilité OpenAI.
Ollama se télécharge pour macOS, Windows ou Linux. Le quickstart dit d’ouvrir l’app, ou de lancer ollama dans le terminal, puis de suivre les invites : compte pour les modèles cloud, ou un modèle local. Les requêtes cloud peuvent partir sans installation, avec une clé. Les requêtes locales n’ont pas besoin de cette clé.
Deux bases sont documentées. L’API Ollama cloud est https://ollama.com/api, le serveur local http://localhost:11434/api. La compatibilité OpenAI est https://ollama.com/v1 ou http://localhost:11434/v1. Un client Anthropic a aussi une base documentée, https://ollama.com ou http://localhost:11434. Créer ou supprimer un modèle demande le serveur local. La page le dit. L’API cloud ne suffit pas pour ça.
La compatibilité OpenAI est un sous-ensemble. En local, le client OpenAI exige une valeur de clé, qu’Ollama ignore. Le cloud, sur /v1/responses, est documenté comme sans état : previous_response_id et conversation ne sont pas pris en charge. La recherche web intégrée via cette route, et le rejeu d’outils custom, non plus. Je n’ai pas envoyé les requêtes d’exemple. Les noms de modèles qui y figurent restent des exemples de la doc.
Le quickstart décrit aussi un lancement d’agent, ollama launch claude, et des branchements vers Claude Desktop ou ChatGPT Desktop. Ces commandes n’ont pas été lancées. La doc traite donc Ollama comme un fournisseur de modèles pour d’autres applications, en plus de sa propre fenêtre.
LM Studio
Pages lues : LM Studio API, quickstart REST, endpoints OpenAI.
LM Studio se lance en application. Le serveur local s’active depuis la page Developer, ou avec lms server start. L’adresse par défaut lue est http://localhost:1234. Le quickstart dit de télécharger un modèle avec lms get si aucun n’est là, et que /api/v1/chat charge le modèle tout seul s’il n’est pas déjà en mémoire. Je n’ai pas vérifié ce chargement.
Depuis la version 0.4.0, l’API native v1 est sous /api/v1/*. Elle documente le chat, la liste des modèles, le chargement, le déchargement, le téléchargement et son statut. Le chat natif est à état : on ne renvoie pas tout l’historique à chaque requête. L’authentification est coupée par défaut. La page dit qu’on peut exiger un jeton, envoyé en Authorization: Bearer. Un serveur laissé ouvert sans ce jeton accepte donc les appels. Ce n’est pas une mesure de risque, c’est le réglage documenté.
La même API native peut attacher des serveurs MCP éphémères, ou ceux déjà configurés dans LM Studio, sur /api/v1/chat et sur /v1/responses. Le tableau de la page REST dit que /v1/chat/completions et /v1/messages n’ont pas cette case. Les outils custom, à l’inverse, sont indiqués sur les routes compatibles OpenAI et Anthropic, pas sur /api/v1/chat. Si vous avez déjà un client OpenAI, la page compatibilité dit de changer le base URL vers http://localhost:1234/v1. Les routes citées sont models, responses, chat completions, embeddings et completions.
Les pages ouvertes décrivent ce serveur local. Elles ne décrivent pas une API cloud du même genre que https://ollama.com. Je n’ai pas cherché, au-delà de ces trois pages, si une offre hébergée existe.
Open WebUI
Pages lues : accueil et connexion à Ollama.
Open WebUI se décrit comme une plateforme que vous hébergez, utilisable hors ligne, avec des extensions. Elle parle le protocole Ollama, en général sur le port 11434, et les API compatibles OpenAI. Quand le backend est surtout compatible OpenAI, la page Ollama renvoie vers un autre guide. Le protocole Ollama sert ici à gérer les modèles et à les télécharger depuis l’admin. Le chat n’est pas l’unique usage documenté.
L’accueil donne un exemple Docker qui publie le port 3000 vers le 8080 du conteneur, avec un volume pour /app/backend/data et une variable WEBUI_SECRET_KEY. L’image :main inclut embeddings, extraction de documents et reconnaissance vocale. L’image :slim est indiquée plus petite sur la page, 196 MB au lieu de 1,62 GB, et s’appuie sur des services externes pour ces fonctions. Ce sont des tailles écrites par Open WebUI, pas des prix, et pas des mesures faites ici.
Une fois lancé, Open WebUI tente de joindre Ollama. Depuis Docker, si Ollama est sur la machine hôte, l’URL documentée est http://host.docker.internal:11434. On peut ajouter plusieurs instances. La répartition lue est un tirage aléatoire, pas un équilibre selon la charge. Les identifiants de modèles doivent coïncider, sinon les entrées ne fusionnent pas. Le préfixe d’identifiant sert à les distinguer quand les noms se répètent.
Open WebUI ne remplace pas le runtime dans ce montage. Le modèle tourne dans Ollama, ou dans le serveur compatible OpenAI que vous avez déclaré. L’interface ajoute le navigateur, les connexions, et les plugins dont la page d’accueil donne le lien. Je n’ai pas ouvert le guide des plugins.
Ce que les pages séparent
| Point relu | Ollama | LM Studio | Open WebUI |
|---|---|---|---|
| Rôle | Sert le modèle, local ou cloud | Application locale, charge et décharge le modèle | Interface hébergée, branchée à un runtime |
| Adresse lue | localhost:11434 ou ollama.com | localhost:1234 | localhost:3000 dans l’exemple Docker |
| Clé par défaut | Cloud : oui. Local : non | Serveur local sans auth, jeton en option | WEBUI_SECRET_KEY dans l’exemple Docker |
| API compatible OpenAI | Sous-ensemble documenté, /v1 | /v1 sur le serveur local | Consomme une API compatible, ne la publie pas dans les pages lues |
| Chat à état | Cloud Responses : sans état, d’après la page compatibilité | /api/v1/chat à état | Non décrit sur les deux pages ouvertes |
| MCP | Non repris sur les pages Ollama ouvertes | Sur le chat natif et /v1/responses | Non repris sur les deux pages ouvertes |
Aucune ligne n’est un score. Une case vide veut dire que la page ouverte ne traitait pas le sujet.
Cas où l’autre option reste préférable
Ollama reste préférable si vous voulez un démon local et une API, ou l’API cloud sans rien installer. Il reste préférable si un autre programme, dont Open WebUI, doit tirer les modèles via le protocole sur le port 11434. Le cloud Ollama reste préférable au serveur local si vous ne voulez pas garder les fichiers du modèle sur la machine. La clé doit alors rester côté serveur, comme le quickstart le dit. Le local reste préférable si la requête ne doit pas sortir : les pages lues disent qu’une requête locale n’envoie pas de clé.
LM Studio reste préférable si vous voulez charger et décharger le modèle depuis l’app ou via /api/v1/models/load, et un chat à état sur la machine. Il reste préférable si le MCP doit partir du même poste, sur le chat natif ou /v1/responses. Il reste un mauvais défaut si le serveur doit être joignable hors de la machine sans jeton : l’auth est coupée tant que vous ne l’activez pas. Ollama cloud reste préférable dans ce cas-là, parce que les pages LM Studio lues ne décrivent pas d’équivalent hébergé.
Open WebUI reste préférable si plusieurs personnes passent par un navigateur, et si le modèle tourne déjà dans Ollama ou dans un serveur compatible OpenAI. Il reste préférable à l’app LM Studio si vous voulez l’image Docker, le volume de données, et le téléchargement de modèles Ollama depuis l’admin. Il ne devient pas préférable comme runtime. Sans Ollama ou sans API compatible derrière, les pages lues ne montrent pas où le modèle s’exécute.
Un fournisseur cloud autre que celui d’Ollama reste préférable si vous ne voulez ni disque local, ni GPU, ni conteneur. Aucune de ces pages ne donne une taille de GPU. Un chiffre de mémoire vidéo lu ailleurs ne serait pas une mesure faite ici, et aucun prix de ce fournisseur n’est recopié.
Ce qui n’a pas été fait
Aucun test n’a été exécuté. Aucun modèle n’a été téléchargé, aucune requête locale ou cloud n’a été envoyée, aucun temps de réponse n’a été chronométré. Aucun prix n’est recopié.