Ollama : servir un LLM local et l’appeler par API sans l’exposer

Ollama fait tourner un modèle de langage sur votre machine et l’expose par une API HTTP, native ou compatible OpenAI. Pratique pour brancher un script ou un outil existant, à condition de ne pas ouvrir ce port au réseau sans réfléchir : l’API locale n’a pas d’authentification.

Installer

Sous Linux, le script officiel tient en une ligne. Sous macOS et Windows, le dépôt GitHub propose aussi un installeur à télécharger (Ollama.dmg, OllamaSetup.exe).

curl -fsSL https://ollama.com/install.sh | sh
ollama -v

La page Linux décrit aussi une installation manuelle, avec un service systemd ollama lancé sous un utilisateur dédié. Ses journaux se lisent avec journalctl -e -u ollama.

Gérer les modèles

ollama pull gemma4      # télécharger un modèle
ollama run gemma4       # discuter dans le terminal
ollama ls               # modèles présents sur le disque
ollama ps               # modèles chargés en mémoire
ollama stop gemma4      # décharger
ollama rm gemma4        # supprimer

Par défaut, un modèle reste en mémoire 5 minutes avant d’être déchargé. Le paramètre keep_alive d’une requête prend le pas sur le réglage serveur OLLAMA_KEEP_ALIVE. Pour savoir quel modèle tient sur votre machine, voir ce billet.

L’API native

Ollama écoute par défaut sur 127.0.0.1, port 11434. Points d’entrée principaux : POST /api/chat et POST /api/generate pour générer, GET /api/tags pour les modèles locaux, GET /api/ps pour ceux chargés en mémoire, POST /api/embed pour les embeddings, POST /api/pull pour télécharger un modèle, GET /api/version. Hors service systemd, ollama serve démarre le serveur à la main.

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{ "role": "user", "content": "Pourquoi le ciel est-il bleu ?" }],
  "stream": false
}'

Sans "stream": false, la réponse arrive en flux. Les paramètres du modèle passent dans un objet options, par exemple num_ctx pour la taille du contexte.

Compatibilité OpenAI

Ollama expose aussi /v1/chat/completions, /v1/completions, /v1/models, /v1/embeddings et /v1/responses. Un client OpenAI existant n’a qu’à changer d’URL de base ; la clé est exigée par le client mais ignorée par Ollama.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1/",
    api_key="ollama",  # exigée par le client, ignorée par Ollama
)

reponse = client.chat.completions.create(
    model="gemma4",
    messages=[{"role": "user", "content": "Résume ce journal en trois lignes."}],
)
print(reponse.choices[0].message.content)

Ne pas exposer l’API sans protection

La documentation est explicite : l’API locale ne demande pas d’authentification. Tant qu’elle écoute sur 127.0.0.1, seule la machine elle-même l’atteint. La variable OLLAMA_HOST change l’adresse d’écoute, et les exemples de la FAQ utilisent 0.0.0.0:11434, c’est-à-dire toutes les interfaces.

Si un accès distant est nécessaire, on combine :

• une écoute sur une seule interface plutôt que sur toutes ;
• un filtrage du port 11434 au pare-feu, ouvert aux seules machines autorisées ;
• ou Ollama laissé sur 127.0.0.1 derrière un proxy comme Nginx, que la FAQ mentionne. La FAQ montre la redirection, pas l’authentification ni le TLS : c’est au proxy de les porter.

Sous Linux, avec le service systemd, sudo systemctl edit ollama.service puis :

[Service]
Environment="OLLAMA_HOST=<ip_interface>:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ufw status verbose

La sortie doit montrer Status: active et Default: deny (incoming). Sinon, sur une machine administrée à distance, autorisez d’abord SSH, puis activez le pare-feu ; sudo ufw default deny incoming rétablit la politique entrante si besoin.

sudo ufw allow 22/tcp    # seulement si l'accès est distant
sudo ufw enable
sudo ufw allow proto tcp from <sous_reseau_autorise> to any port 11434
sudo ufw status verbose

Le contrôle se fait ensuite depuis une machine autorisée, puis depuis une machine qui ne l’est pas : curl http://<ip_interface>:11434/api/version doit répondre dans le premier cas seulement.

Sous macOS, la FAQ passe par launchctl setenv ; sous Windows, Ollama hérite des variables d’environnement de l’utilisateur et du système, et se redémarre après modification.

Dernier réglage, OLLAMA_ORIGINS ajoute des origines aux requêtes cross-origin, autorisées par défaut depuis 127.0.0.1 et 0.0.0.0. Il concerne les pages web qui appellent l’API, pas l’authentification.

Ce qu’il faut retenir

• L’API écoute par défaut sur 127.0.0.1:11434 et ne demande aucune authentification.
• pull, run, ls, ps, stop et rm couvrent la gestion courante des modèles.
• /api/chat avec "stream": false pour un script, /v1/ pour réutiliser un client OpenAI.
• OLLAMA_HOST=0.0.0.0 ouvre l’API à tout le réseau : écoute sur une interface, pare-feu ou proxy authentifiant, jamais rien.

In English

Install Ollama, manage its models, call the native or OpenAI-compatible API on port 11434, and only open it to the network behind filtering, since the local API requires no authentication. Ollama listens on 127.0.0.1 by default, an OpenAI client works once pointed at the /v1/ endpoint, and OLLAMA_HOST changes the listening address.

Sources & vérification

Relevé sur : Documentation Ollama et ufw, relevé 2026-10

• Ollama, dépôt GitHub (installation, API) github.com
• Ollama, référence API (docs/api.md) github.com
• Ollama, CLI reference docs.ollama.com
• Ollama, FAQ docs.ollama.com
• Ollama, Linux docs.ollama.com
• Ollama, Modelfile (paramètre num_ctx) docs.ollama.com
• Ollama, OpenAI compatibility docs.ollama.com
• Ollama, Authentication docs.ollama.com
• Ubuntu, page de manuel ufw(8) manpages.ubuntu.com
• Ubuntu Wiki, UFW (sortie de status verbose) wiki.ubuntu.com

Comment les billets sont vérifiés et corrigés