Selon l’uti­li­sa­tion prévue, dif­fé­rents types de serveurs peuvent être per­ti­nents pour faire fonc­tion­ner Ollama. Pour de petits chatbots, un VPS suf­fi­sam­ment puissant suffit souvent. En revanche, les agents IA, les charges de travail liées au coding ou les modèles très vo­lu­mi­neux né­ces­si­tent gé­né­ra­le­ment un GPU, voire un matériel dédié. Ollama simplifie con­si­dé­ra­ble­ment l’exécution de grands modèles de langage en local ou sur un serveur : il gère les modèles, les lance et les rend ac­ces­sibles via une API simple.

Essai gratuit de VPS
Testez gra­tui­te­ment un VPS pendant 30 jours

Laissez-vous con­vaincre par les avantages des serveurs virtuels. Essayez votre VPS en toute tran­quil­lité pendant 30 jours !

Qu’est-ce qu’Ollama ?

Ollama est un logiciel qui permet d’exécuter des grands modèles de langage (LLM) comme Gemma, Qwen, DeepSeek ou d’autres modèles com­pa­tibles lo­ca­le­ment ou sur votre propre serveur. Le logiciel propose une interface en ligne de commande simple ainsi qu’une API REST, qui per­met­tent de lancer des modèles et de les intégrer dans vos propres ap­pli­ca­tions. Ollama ne sert donc pas seulement à discuter avec un modèle dans le terminal, mais aussi de moteur d’exécution de modèles pour vos propres outils, as­sis­tants ou en­vi­ron­ne­ments de dé­ve­lop­pe­ment.

Ollama est par­ti­cu­liè­re­ment in­té­res­sant pour les uti­li­sa­trices et uti­li­sa­teurs qui ne sou­hai­tent pas in­ter­ro­ger des modèles via un service Cloud tiers, mais les exécuter sur leur propre in­fras­truc­ture. Lorsque vous utilisez des modèles locaux, les in­te­rac­tions se font en local, et le logiciel prend en charge le char­ge­ment et l’exécution des modèles ainsi que l’accès via la CLI ou l’API. Pour les débutants, c’est pratique, car ils n’ont pas besoin de créer eux-mêmes un en­vi­ron­ne­ment d’inférence complet à partir de zéro et peuvent démarrer avec quelques commandes seulement.

Note

Dans de nombreux projets d’IA, Ollama sert uni­que­ment de backend de modèles : il exécute les modèles de langage lo­ca­le­ment ou sur un serveur Ollama et les expose via une API. Sur cette base, il est possible d’utiliser des fra­me­works d’agents comme OpenClaw avec Ollama pour au­to­ma­ti­ser des flux de travail complexes. Dans ce type de con­fi­gu­ra­tion, Ollama prend en charge l’inférence des modèles, tandis qu’OpenClaw gère des tâches comme l’uti­li­sa­tion d’outils, les processus d’agents multi-étapes ou les actions au­to­ma­ti­sées.

Quel serveur convient à votre projet ?

Avant de commencer l’ins­tal­la­tion, vous devez définir pré­ci­sé­ment l’usage prévu pour Ollama. Toutes les ap­pli­ca­tions n’ont pas besoin d’un GPU, mais les exigences aug­men­tent ra­pi­de­ment dès que vous souhaitez obtenir des réponses fluides, traiter plusieurs requêtes en parallèle ou utiliser des modèles d’in­tel­li­gence ar­ti­fi­cielle plus vo­lu­mi­neux. La taille du modèle est un facteur dé­ter­mi­nant : à titre indicatif, Ollama re­com­mande au moins 8 Go de mémoire vive (RAM) pour les modèles 7B, au moins 16 Go de RAM pour les modèles 13B et au moins 64 Go de RAM pour les modèles 70B, mais les besoins réels varient selon le modèle, la quan­ti­fi­ca­tion et la taille du contexte. La quantité de VRAM dis­po­nible sur le GPU joue également un rôle important, car elle influence fortement la vitesse, la longueur du contexte et l’uti­li­sa­bi­lité pratique.

Cas d’usage 1 : tâches tex­tuelles simples, tests et petits chatbots

Si vous souhaitez utiliser Ollama prin­ci­pa­le­ment pour des essais, de la gé­né­ra­tion de texte simple, de petits bots d’as­sis­tance ou des tests internes, un serveur privé virtuel (VPS) suf­fi­sam­ment per­for­mant sans GPU dédié est suffisant. Dans ce scénario, ce sont dans la plupart des cas de petits modèles d’IA qui tournent. Ceux-ci né­ces­si­tent au minimum 8 Go de RAM, mais en pratique, il est judicieux de prévoir une marge afin que le système d’ex­ploi­ta­tion, Docker et les processus en arrière-plan ne ra­len­tis­sent pas le serveur. Pour un serveur Ollama de démarrage, 16 Go de RAM cons­ti­tuent donc une base plus con­for­table, même si certains petits modèles d’IA peuvent fonc­tion­ner avec moins de mémoire. Prévoyez un espace de stockage suffisant, car en plus de l’ins­tal­la­tion Docker, il faut en­re­gis­trer les fichiers de modèles, qui peuvent ra­pi­de­ment atteindre plusieurs gi­gaoc­tets.

Le grand avantage d’un VPS réside dans ses coûts maî­tri­sables et sa mise à dis­po­si­tion simple. Son principal in­con­vé­nient est une vitesse nettement in­fé­rieure à celle des serveurs GPU. Pour l’ap­pren­tis­sage, les projets de dé­mons­tra­tion et les API simples, un VPS avec 4 vCPU, 16 Go de RAM et un stockage SSD constitue néanmoins une bonne option de départ.

Cas d’usage 2 : bots de con­nais­sances internes, petites API et em­bed­dings

Si vous souhaitez utiliser Ollama comme backend pour une petite base de con­nais­sances interne, pour la Retrieval-Augmented Ge­ne­ra­tion (RAG) ou pour des em­bed­dings, les exigences de­vien­nent plus élevées. Il ne s’agit plus seulement de générer une réponse de chat ponc­tuelle, mais souvent de gérer des appels API répétés, des trai­te­ments en arrière-plan et un fonc­tion­ne­ment plus stable dans la durée. Ces scénarios peuvent encore fonc­tion­ner sur un serveur CPU ou un grand VPS, mais davantage de mémoire vive devient important afin que les modèles et les données n’aient pas à être rechargés en per­ma­nence. Un serveur avec 16 à 32 Go de RAM est nettement plus con­for­table pour ce type de tâches.

Si plusieurs uti­li­sa­teurs accèdent si­mul­ta­né­ment au service, il peut aussi être in­té­res­sant d’opter pour un pro­ces­seur avec plus de cœurs ou de passer à un serveur GPU. Ollama prend en charge, en plus de la gé­né­ra­tion de texte, les em­bed­dings via l’API, ce qui le rend in­té­res­sant pour les ap­pli­ca­tions de recherche et de gestion des con­nais­sances. Pour de petites équipes ou des outils internes, un grand VPS ou un petit serveur dédié sans GPU peut donc déjà suffire, à condition de ne pas exiger des temps de réponse ex­trê­me­ment faibles. En revanche, ceux qui sou­hai­tent une ex­pé­rience uti­li­sa­teur vraiment fluide devraient envisager un GPU, même dans ce cas. De manière générale, plus votre service est in­te­rac­tif et utilisé en parallèle, plus un serveur purement CPU atteindra ra­pi­de­ment ses limites.

Cas d’usage 3 : as­sis­tants de pro­gram­ma­tion et agents fluides

Dès qu’Ollama doit être utilisé pour des as­sis­tants de pro­gram­ma­tion, des agents semi-autonomes ou d’autres flux de travail in­te­rac­tifs, un GPU devient fortement re­com­mandé. La raison est simple : ce type d’ap­pli­ca­tions profite énor­mé­ment d’une gé­né­ra­tion de réponses rapide et de modèles capables de traiter un contexte plus large de manière fluide. Les longueurs de contexte standard dépendent notamment de la quantité de VRAM dis­po­nible. Pour les agents, la recherche Web, les outils de dé­ve­lop­pe­ment ou des contextes de travail plus longs, la do­cu­men­ta­tion re­com­mande au moins 64 000 AI‑Tokens de contexte.

Il devient ainsi clair qu’un simple VPS avec CPU n’est gé­né­ra­le­ment pas le choix idéal pour de tels projets. Un serveur Cloud avec GPU NVIDIA récent, combiné à une quantité suf­fi­sante de RAM et à un stockage NVMe rapide, est plus approprié. Cela permet d’exécuter des modèles de taille moyenne de manière nettement plus con­for­table. Des flux de travail d’agents multi‑étapes de­vien­nent également pra­ti­cables de cette façon. Pour des projets in­di­vi­duels ambitieux, des pro­to­types et des équipes de dé­ve­lop­pe­ment, c’est le meilleur compromis entre coûts et per­for­mances.

Cas d’usage 4 : ap­pli­ca­tions pro­fes­sion­nelles avec plusieurs uti­li­sa­teurs

Si vous souhaitez utiliser Ollama comme élément fixe d’une ap­pli­ca­tion pro­fes­sion­nelle, les exigences évoluent à nouveau. Il ne s’agit plus seulement de savoir si un modèle fonc­tionne en principe, mais s’il tourne de manière stable, re­pro­duc­tible et per­for­mante sous charge. Dans de tels scénarios, vous devez prévoir suf­fi­sam­ment de RAM, un GPU per­for­mant, des marges pour plusieurs processus pa­ral­lèles, de la su­per­vi­sion et assez d’espace de stockage pour plusieurs modèles. Comme Ollama met les modèles à dis­po­si­tion via une API, il peut très bien servir de backend de modèles interne, mais le choix du serveur doit être conçu en fonction de la dis­po­ni­bi­lité et du com­por­te­ment sous charge.

Un serveur dédié GPU per­for­mant ou un serveur Cloud GPU pro­fes­sion­nel est ici, en règle générale, un bien meilleur choix qu’un petit VPS. Dans ce domaine, 64 Go de RAM ou plus sont judicieux, associés à un GPU NVIDIA puissant et à une in­fras­truc­ture d’ex­ploi­ta­tion propre avec stockage per­sis­tant pour les fichiers de modèles. Pour les ap­pli­ca­tions en pro­duc­tion en par­ti­cu­lier, il est important que Docker et, le cas échéant, la con­fi­gu­ra­tion de NVIDIA Container Toolkit soient cor­rec­te­ment mis en place, afin que le GPU puisse réel­le­ment être utilisé dans le conteneur Docker.

Cas d’usage 5 : modèles très grands et inférence haut de gamme

Si vous souhaitez exécuter des modèles très vo­lu­mi­neux de l’ordre de 70B ou plus, vous entrez clai­re­ment dans le segment haut de gamme. Pour les modèles 70B, Ollama indique au moins 64 Go de RAM comme exigence minimale ap­proxi­ma­tive. En pratique, les serveurs basés sur la vir­tua­li­sa­tion ne suffisent pas dans ce cas, en par­ti­cu­lier si les temps de réponse doivent être bons ou si plusieurs processus tournent en parallèle. Pour de tels scénarios, un serveur dédié avec un matériel GPU très per­for­mant est nettement plus réaliste qu’un VPS classique.

Dans un contexte pro­fes­sion­nel, cela implique des systèmes GPU spé­cia­li­sés avec beaucoup de VRAM, par exemple des serveurs équipés de cartes NVIDIA A100 ou NVIDIA H100 ou d’en­vi­ron­ne­ments haute per­for­mance dotés de ca­rac­té­ris­tiques com­pa­rables. C’est coûteux, mais pour les grands modèles, les contextes longs et les charges de travail pro­duc­tives haut de gamme, c’est quasiment in­con­tour­nable.

Vue d’ensemble : quel serveur pour quel usage ?

Objectif Matériel re­com­mandé Coûts estimés
Bot ou API simple VPS avec 4 vCPU, 16 Go de RAM et SSD +
Bots internes de gestion des con­nais­sances ou em­bed­dings Grand VPS ou petit serveur dédié avec 16 à 32 Go de RAM + / ++
Coding et agents IA Serveur Cloud GPU avec GPU moderne ++
Ap­pli­ca­tions pro­fes­sion­nelles Serveur Cloud GPU per­for­mant ou serveur dédié avec beaucoup de RAM ++ / +++
High-end, 70B et plus Serveur dédié avec A100, H100 ou GPU haut de gamme com­pa­rable +++

Légende des coûts : + = faible, ++ = moyen, +++ = élevé

Comment installer Ollama avec Docker sur un serveur ?

Dans la section suivante, nous pré­sen­tons l’ins­tal­la­tion d’Ollama avec Docker sur un serveur Linux. Pour les débutants, la com­bi­nai­son Ollama avec Docker est par­ti­cu­liè­re­ment pratique, car Ollama s’exécute dans un conteneur et nécessite moins de mo­di­fi­ca­tions directes du système. Pour utiliser l’ac­cé­lé­ra­tion GPU sous Linux avec une carte NVIDIA, vous avez en plus besoin du NVIDIA Container Toolkit afin que Docker puisse trans­mettre le GPU au conteneur.

Étape 1 : se connecter au serveur

Connectez-vous d’abord en SSH à votre serveur. Pour cela, vous avez besoin de l’adresse IP du serveur ainsi que d’un uti­li­sa­teur disposant de droits sudo.

ssh NOM_UTILISATEUR@ADRESSE_IP_DU_SERVEUR
bash

Lorsque vous vous connectez pour la première fois, votre système vous demande de confirmer la clé de l’hôte. Saisissez yes, puis votre mot de passe ou utilisez votre clé SSH. Vous vous trouvez ensuite dans le terminal de votre serveur et pouvez commencer la con­fi­gu­ra­tion.

Étape 2 : mettre le système à jour

Avant d’installer Docker et Ollama, vous devez mettre à jour les listes de paquets et ac­tua­li­ser les paquets existants. Vous vous assurez ainsi que votre système utilise les dernières mises à jour de sécurité et versions de paquets. Sur les serveurs fraî­che­ment déployés, c’est une première étape ju­di­cieuse avant d’installer d’autres logiciels.

sudo apt update && sudo apt upgrade -y
bash

Étape 3 : installer Docker

Pour Ubuntu 24.04, Docker re­com­mande l’ins­tal­la­tion via le dépôt APT officiel. Le fichier de dépôt actuel au format Deb822 est alors configuré sous /etc/apt/sources.list.d/docker.sources. Sont notamment pris en charge Ubuntu 24.04 et plusieurs ar­chi­tec­tures comme amd64 et arm64. Pour cela, installez d’abord les paquets auxi­liaires né­ces­saires :

sudo apt install ca-certificates curl -y
bash

Créez ensuite le ré­per­toire pour le trousseau de clés :

sudo install -m 0755 -d /etc/apt/keyrings
bash

Té­lé­char­gez ensuite la clé of­fi­cielle de Docker :

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
bash

Con­fi­gu­rez main­te­nant le dépôt Docker comme suit :

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF
bash

Mettez ensuite de nouveau à jour la liste des paquets :

sudo apt update
bash

Installez Docker Engine, y compris le plugin Compose :

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
bash

Vérifiez ensuite que Docker fonc­tionne cor­rec­te­ment :

sudo systemctl status docker
bash

Vous devriez voir l’in­di­ca­tion active (running), qui confirme que Docker est en cours d’exécution.

Image: Indicateur d’état de Docker sur votre serveur Ollama
L’in­di­ca­tion « active » confirme que Docker est en cours d’exécution.

Vous pouvez lancer un conteneur de test :

sudo docker run hello-world
bash

Si un message de con­fir­ma­tion s’affiche, Docker est installé avec succès.

Image: Conteneur Hello-World sur votre serveur Ollama
Si Docker est installé avec succès, vous pouvez lancer le conteneur Hello-World comme premier test.

Étape 4 : utiliser Docker sans sudo (optionnel)

Par défaut, Docker est gé­né­ra­le­ment exécuté avec sudo sous Linux. Si vous souhaitez malgré tout utiliser Docker sans sudo, exécutez ces commandes :

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker
bash

Vous devrez peut-être vous dé­con­nec­ter puis vous re­con­nec­ter pour que l’ap­par­te­nance au groupe soit plei­ne­ment prise en compte. Vous pouvez ensuite tester si Docker fonc­tionne sans sudo :

docker run hello-world
bash

Étape 5 : installer le NVIDIA Container Toolkit pour les GPU NVIDIA

Cette étape est né­ces­saire uni­que­ment si votre serveur dispose d’un GPU NVIDIA et si vous souhaitez qu’Ollama utilise ce GPU dans le conteneur Docker. Commencez par installer les paquets né­ces­saires :

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
bash

Ajoutez ensuite le dépôt NVIDIA :

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
bash

Mettez à jour la liste des paquets et installez le toolkit :

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
bash

Con­fi­gu­rez Docker pour la prise en charge du runtime NVIDIA :

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
bash

Si vos pilotes GPU sont cor­rec­te­ment installés et que nvidia-smi fonc­tionne sur l’hôte, Docker pourra ensuite trans­mettre les res­sources GPU aux con­te­neurs.

Étape 6 : démarrer le conteneur Ollama

Vous pouvez main­te­nant démarrer Ollama lui‑même comme conteneur Docker. L’image of­fi­cielle s’appelle ollama/ollama. Pour un fonc­tion­ne­ment uni­que­ment sur CPU, utilisez la commande suivante :

sudo docker run -d \
-v ollama:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollama
bash

Si vous utilisez un GPU NVIDIA et que vous avez déjà terminé l’étape 5, démarrez le conteneur de cette façon :

sudo docker run -d \
--gpus=all \
-v ollama:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollama
bash

Étape 7 : vérifier si le conteneur est en cours d’exécution

Vérifiez ensuite avec la commande suivante dans le terminal si le conteneur a bien été démarré sur votre serveur Ollama :

sudo docker ps
bash

Dans la sortie, un conteneur portant le nom ollama doit ap­pa­raître. Vous devez également voir que le port 11434 a été publié ; dans cette con­fi­gu­ra­tion, il peut être ac­ces­sible depuis d’autres machines selon les règles réseau et firewall.

Image: Capture d’écran de la sortie de docker ps
La commande « docker ps » fournit un aperçu de vos con­te­neurs. Le conteneur Ollama devrait main­te­nant y ap­pa­raître.

Étape 8 : té­lé­char­ger et démarrer un premier modèle

Dès que le conteneur est en cours d’exécution, vous pouvez démarrer un modèle. La do­cu­men­ta­tion of­fi­cielle montre à titre d’exemple l’appel via docker exec. Vous exécutez ainsi la commande Ollama di­rec­te­ment dans le conteneur en cours d’exécution.

sudo docker exec -it ollama ollama run llama3
bash

Lors du premier démarrage, Ollama té­lé­charge d’abord le modèle. Selon la taille du modèle et la connexion de votre serveur, cela peut prendre un certain temps. Vous accédez ensuite à une console in­te­rac­tive dans laquelle vous pouvez poser des questions di­rec­te­ment.

Image: Ollama avec Llama3
Après avoir démarré Llama3 (ou un autre modèle de langage), vous pouvez interagir avec le LLM dans la console de chat.

Si vous préférez essayer un autre modèle que Llama3, vous pouvez utiliser un autre nom de modèle en con­sé­quence. Vous trouverez les modèles dis­po­nibles dans la bi­blio­thèque Ollama. La do­cu­men­ta­tion y mentionne notamment des modèles récents comme Gemma 3, Qwen3, DeepSeek-R1 et d’autres.

Étape 9 : tester l’API Ollama

Ollama met au­to­ma­ti­que­ment à dis­po­si­tion une API locale après le démarrage. Selon la do­cu­men­ta­tion of­fi­cielle, l’URL de base par défaut est http://localhost:11434/api. Vous pouvez effectuer un test simple di­rec­te­ment sur le serveur avec curl.

Un exemple de requête de gé­né­ra­tion simple avec le modèle pré­cé­dem­ment té­lé­chargé pourrait res­sem­bler à ceci :

curl http://localhost:11434/api/generate -d '{
"model": "gemma3",
"prompt": "Expliquez en deux phrases ce qu’est Ollama.",
"stream": false
}'
bash

Si tout fonc­tionne cor­rec­te­ment, vous recevez une réponse JSON du modèle. Vous savez ainsi que non seulement le conteneur est en cours d’exécution, mais aussi que l’API est ac­ces­sible cor­rec­te­ment.

Image: Appel à l’API Ollama
L’API vous fournit di­rec­te­ment la réponse au format JSON.

Étape 10 : utiliser Docker Compose comme al­ter­na­tive

Pour un serveur Ollama fonc­tion­nant en continu, Docker Compose est souvent plus pratique qu’une longue commande docker run. Vous pouvez ainsi en­re­gis­trer la con­fi­gu­ra­tion dans un fichier et la modifier plus fa­ci­le­ment par la suite. Créez d’abord un ré­per­toire pour votre con­fi­gu­ra­tion :

mkdir -p ~/ollama
cd ~/ollama
bash

Créez ensuite un fichier nommé compose.yaml. Nous utilisons ici l’éditeur nano, mais vous pouvez utiliser n’importe quel éditeur de texte :

nano compose.yaml
bash

Pour un fonc­tion­ne­ment sur CPU, insérez le contenu suivant :

services:
    ollama:
        image: ollama/ollama
        container_name: ollama
        ports:
            - "11434:11434"
        volumes:
            - ollama:/root/.ollama
        restart: unless-stopped
volumes:
    ollama:
yaml

Pour un fonc­tion­ne­ment sur GPU NVIDIA, vous pouvez ajouter une con­fi­gu­ra­tion GPU selon votre en­vi­ron­ne­ment Docker. En pratique, pour les débutants, la variante la plus simple et la plus facile à re­pro­duire reste le démarrage direct avec docker run --gpus=all, car les con­fi­gu­ra­tions Compose peuvent lé­gè­re­ment varier selon la version de Docker. L’essentiel est dans tous les cas que Docker utilise cor­rec­te­ment l’en­vi­ron­ne­ment d’exécution NVIDIA. NVIDIA décrit ex­pli­ci­te­ment cette condition préalable dans la do­cu­men­ta­tion de son Toolkit.

Démarrez ensuite le service avec la commande suivante :

sudo docker compose up -d
bash
Image: Démarrer le conteneur avec Compose
La gestion du conteneur Ollama avec Docker Compose est plus pratique en cas d’uti­li­sa­tion fréquente.

Vérifiez à nouveau le statut :

sudo docker compose ps
bash
Image: Statut du conteneur
Vous pouvez afficher le statut de votre conteneur Ollama avec Compose.

Étape 11 : in­di­ca­tions im­por­tantes pour l’uti­li­sa­tion pratique

Si vous souhaitez utiliser Ollama avec Docker en pro­duc­tion ou le mettre à dis­po­si­tion d’autres appareils sur le réseau, vous ne devez pas exposer le service sur Internet sans mesures de pro­tec­tion. Ollama utilise par défaut le port 11434. Dans la con­fi­gu­ra­tion Docker présentée ici, l’API est publiée sur l’hôte via -p 11434:11434. Selon la con­fi­gu­ra­tion de votre réseau et de votre firewall, elle peut donc être ac­ces­sible depuis l’extérieur. Pour limiter l’accès au serveur lui-même, liez plutôt le port uni­que­ment à 127.0.0.1, par exemple avec -p 127.0.0.1:11434:11434, puis dé­fi­nis­sez des règles de firewall adaptées et res­tric­tives.

Gardez à l’esprit que les modèles sont stockés lo­ca­le­ment et qu’il faut donc prévoir suf­fi­sam­ment d’espace disque. Les modèles sont stockés dans le volume Docker ollama, ce qui peut ra­pi­de­ment re­pré­sen­ter plusieurs gi­gaoc­tets selon les modèles té­lé­char­gés. Sous Linux, le même principe s’applique : les modèles occupent beaucoup d’espace. Pour les contextes longs, les agents IA ou les ap­pli­ca­tions de dé­ve­lop­pe­ment, la quantité de VRAM dis­po­nible est également im­por­tante, car Ollama adapte la longueur de contexte standard en fonction de la VRAM dis­po­nible.

Aller au menu principal