Ollama Cloud ou serveur local : quelles différences ?

Ce que change Ollama Cloud, et ce qui ne change pas

Ollama Cloud exécute le modèle sur ollama.com au lieu de votre propre matériel, tout en conservant la même commande ollama et la même API REST que vous utilisez déjà. Deux éléments changent : le nom du modèle demandé et l’emplacement de l’identifiant d’authentification. Le reste de votre application reste exactement identique.

Cette facilité constitue aussi un risque. Dans votre code, une requête adressée à un modèle cloud ressemble à une requête adressée à un modèle local. Il est donc facile de perdre de vue quels prompts sont exécutés sur une machine que vous contrôlez et lesquels sont envoyés à une entreprise que vous ne contrôlez pas. Ce guide établit cette distinction, puis montre comment conserver un modèle local comme solution de repli. Une seule valeur de configuration détermine ainsi le côté utilisé.

Si vous n’avez pas encore configuré la partie locale, commencez par exécuter Ollama sur votre propre VPS. Tout ce qui suit suppose que ollama fonctionne sur une machine Linux.

Deux façons d’accéder à Ollama Cloud

Il existe deux méthodes pour accéder aux modèles hébergés. Elles ne sont pas interchangeables. La méthode choisie détermine l’emplacement du credential, le nom du modèle à utiliser et ce qu’une capture de paquets sur votre serveur afficherait.

Première méthode : votre daemon local relaie la requête. Vous vous authentifiez une fois, puis vous demandez un modèle dont le nom se termine par -cloud.

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

Certains modèles cloud portent plutôt un tag cloud seul, comme gemma4:cloud. C’est la forme désormais utilisée dans la documentation cloud d’Ollama pour l’application et la CLI. Traitez les deux suffixes, -cloud ou :cloud, comme indiquant un modèle cloud.

ollama signin associe cette machine à votre compte ollama.com. ollama signout dissocie la machine du compte. Après l’authentification, votre application continue à utiliser le port local habituel :

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

Relisez cette URL. Elle indique localhost, mais l’inférence n’a pas lieu à cet emplacement. Le daemon local reconnaît le suffixe -cloud, relaie la requête vers ollama.com et vous retransmet la réponse au fil de sa réception. C’est tout l’intérêt de la première méthode : une application déjà configurée pour utiliser l’API Ollama sur le port 11434 ne nécessite aucune modification de code, seulement un autre nom de modèle.

Deuxième méthode : votre client appelle directement ollama.com. Le daemon local n’intervient pas. Créez une clé sur https://ollama.com/settings/keys, puis envoyez-la comme bearer token.

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

Observez le nom du modèle. Avec la deuxième méthode, il s’agit de gpt-oss:120b, sans suffixe -cloud. Ce suffixe sert à indiquer à votre daemon local de relayer la requête vers le service distant. Il ne doit donc être utilisé qu’avec la première méthode. Lorsque vous appelez https://ollama.com, vous êtes déjà connecté au service distant et vous utilisez le nom simple. La liste officielle de ces noms est fournie par l’hôte lui-même :

curl https://ollama.com/api/tags

Exécutez cette commande au lieu de faire confiance à une liste de modèles publiée dans un article, y compris celui-ci. Le catalogue évolue et api/tags est toujours à jour.

Quels appels client changent et lesquels ne changent pas

Les bibliothèques officielles Python et JavaScript prennent l’hôte et les en-têtes lors de la création du client. Rien ne change après cette ligne. Dans le premier cas, le constructeur est vide, car la valeur par défaut correspond au daemon local :

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

Dans le second cas, le constructeur contient l’hôte et le token :

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

L’appel client.chat(), la boucle de streaming, la liste des messages et la structure de la réponse sont identiques dans les deux cas. C’est pourquoi le passage d’un service hébergé à un service auto-hébergé consiste à modifier la configuration, pas à réécrire le code. L’interface compatible avec OpenAI se comporte de la même manière en local : configurez un SDK OpenAI pour utiliser http://localhost:11434/v1/ avec api_key='ollama', une valeur fictive exigée par le SDK et ignorée par le serveur local.

Où se trouve l’identifiant, et qui peut l’utiliser

Dans le chemin 2, l’identifiant est OLLAMA_API_KEY dans votre environnement. Ne le laissez pas apparaître dans l’historique du shell ni dans votre dépôt. Pour un service systemd, placez-le dans une ligne Environment= ou dans un fichier d’environnement appartenant à root et doté du mode 600.

Le chemin 1 est celui qui surprend le plus. La connexion appartient au daemon, pas à vous. La FAQ Ollama indique que, sous Linux, l’identité du service se trouve dans /usr/share/ollama/.ollama/id_ed25519.pub, qui appartient à l’utilisateur de service ollama. L’API locale n’effectue aucune authentification par requête. Tout appelant pouvant atteindre le port 11434 utilise donc votre compte et consomme votre quota. Cela convient tant que le daemon écoute sur loopback. Dès que vous définissez OLLAMA_HOST=0.0.0.0:11434 pour y accéder depuis une autre machine, un port ouvert devient une relation de facturation ouverte. Vous devez donc lire comment placer une authentification devant un endpoint Ollama avant d’élargir l’adresse d’écoute.

Pourquoi le même modèle offre moins de contexte en local

C’est la différence qui surprend ceux qui pensent qu’un modèle se comporte de la même façon dans les deux cas. Ce n’est pas le cas, et la cause tient à la mémoire.

Ollama choisit une longueur de contexte locale par défaut en fonction de la mémoire vidéo détectée sur la machine.

[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

Un VPS sans GPU se trouve dans le niveau inférieur. Un modèle local démarre donc avec 4,096 tokens de contexte, tandis qu’une machine équipée d’une carte graphique avec beaucoup de mémoire démarre avec 262,144. Les modèles cloud ignorent ces niveaux : Ollama indique qu’ils utilisent par défaut leur longueur de contexte maximale, car vous ne gérez pas la mémoire qui contient ce contexte.

Le même prompt qui fonctionne avec gpt-oss:120b-cloud peut donc être tronqué silencieusement avec un modèle local sur une petite machine. Augmentez explicitement la limite locale :

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Avec systemd, définissez-la avec Environment="OLLAMA_CONTEXT_LENGTH=32768" à l’aide de systemctl edit ollama.service, puis exécutez systemctl daemon-reload && systemctl restart ollama. Tenez compte du coût : un contexte plus long nécessite un cache key-value plus volumineux. Ce cache consomme de la RAM en plus de celle requise par les poids du modèle. Si vous allez trop loin, la génération ralentit ou le modèle ne se charge pas. Définir correctement num_ctx et OLLAMA_CONTEXT_LENGTH explique les calculs, tandis que quels modèles tiennent dans la mémoire dont vous disposez réellement traite la question des poids.

Ce qui quitte réellement votre machine

Soyez précis sur ce point, car c’est la raison principale pour laquelle la plupart des lecteurs choisissent l’auto-hébergement.

En exécution locale, rien ne quitte la machine. La politique de confidentialité d’Ollama l’indique clairement : pour l’utilisation locale, « Nous ne collectons pas, ne stockons pas, ne transmettons pas et n’avons pas accès à vos prompts, réponses, interactions avec les modèles ni aux autres contenus que vous traitez localement. » Une réserve s’applique toutefois : télécharger un modèle reste un téléchargement depuis ollama.com, et la politique mentionne les « métadonnées de téléchargement des modèles » ainsi que votre adresse IP parmi les données collectées. Le registre sait quels modèles vous avez téléchargés. Il ne sait pas ce que vous leur avez demandé.

Avec le chemin cloud, le prompt complet et la completion complète sont envoyés à un tiers. Il n’existe pas de version partielle de ce fonctionnement. Chaque token que vous envoyez et chaque token que vous recevez sont traités sur ollama.com. La politique indique que l’entreprise traite « vos prompts et vos réponses de manière transitoire pour fournir le service », qu’elle « n’utilise pas vos entrées ni vos sorties pour entraîner des modèles d’IA » et qu’elle applique des « mesures techniques conçues pour limiter la conservation du contenu des prompts et des réponses ». C’est un engagement raisonnable. Il reste toutefois l’engagement d’un tiers concernant les données que vous lui transmettez, et non une propriété de votre propre machine. Évaluez-le comme n’importe quelle promesse de fournisseur et relisez-le avant d’envoyer des données que vous êtes contractuellement ou légalement tenu de conserver sur votre propre infrastructure.

Le piège concerne le chemin 1. Votre code indique http://localhost:11434, vos règles de pare-feu n’ont pas changé et votre prompt traverse toujours Internet, car le suffixe -cloud du nom du modèle assure le routage. Une URL localhost ne vous indique pas où l’inférence a été effectuée. C’est le nom du modèle qui le précise. Ce point est particulièrement important lorsque le prompt contient des données que vous auto-hébergez précisément pour les garder privées : si vous utilisez un outil de suivi de localisation auto-hébergé afin que votre historique de déplacements ne parvienne jamais à un tiers, demander à un modèle -cloud d’en résumer une semaine envoie malgré tout cet historique à ollama.com.

Sur un serveur qui ne doit jamais transmettre un prompt, supprimez complètement ce choix. Ollama documente un mode local uniquement : définissez OLLAMA_NO_CLOUD=1 dans l’environnement du service, ou "disable_ollama_cloud": true dans ~/.ollama/server.json, puis redémarrez le service. Le daemon n’a alors plus accès aux modèles cloud ni à la recherche web. Le nom accidentel d’un modèle cloud ne peut donc rien divulguer.

Conserver un modèle local comme solution de repli

Comme les deux chemins utilisent la même API, vous pouvez effectuer ce choix à l’exécution plutôt que de créer une branche distincte dans le code.

La version la plus simple ne nécessite aucun code. Laissez votre application utiliser le daemon local et définissez le nom du modèle dans la configuration. Avec llama3.2, l’exécution se fait sur votre propre serveur. Avec gpt-oss:120b-cloud, le même daemon transmet les requêtes à ollama.com. Une seule variable d’environnement suffit, sans redéploiement.

Si vous voulez que le modèle local soit utilisé par défaut et que le cloud prenne le relais en cas de surcharge, initialisez les deux clients et choisissez celui à utiliser pour chaque requête :

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx est fourni comme dépendance du package ollama ; aucune installation supplémentaire n’est donc nécessaire. ConnectError couvre le cas où un daemon est arrêté. ResponseError couvre le cas où un daemon est démarré mais refuse la requête, par exemple lorsque le modèle local n’a jamais été téléchargé.

La ligne print n’est pas décorative. Un fallback silencieux signifie qu’une invite que vous vouliez conserver sur votre propre matériel est envoyée discrètement à un tiers dès que votre daemon redémarre pendant une mise à niveau. Journalisez chaque fallback. Pour toute donnée sensible, levez une erreur au lieu d’utiliser le fallback. Pour un déploiement axé sur la confidentialité, la stratégie la plus sûre consiste à échouer explicitement.

Un autre point rend le modèle local réellement utilisable par défaut : gardez-le en mémoire. Le chargement initial sur un VPS sans GPU peut prendre plusieurs dizaines de secondes. C’est précisément ce qui pousse souvent à utiliser le chemin cloud. Conserver le modèle en mémoire avec keep_alive supprime cette pénalité de la première requête.

À comparer avant de vous engager

Ne comparez pas uniquement les prix et ne faites pas confiance à un prix lu dans un article, y compris à la date indiquée dans celui-ci. Comparez quatre éléments et vérifiez chacun d’eux sur les pages du fournisseur :

• Disponibilité des modèles. Exécutez curl https://ollama.com/api/tags pour afficher le catalogue hébergé actuel. Les modèles que vous pouvez exécuter localement sont plutôt limités par votre RAM et votre VRAM.
• Limites de contexte. Les modèles hébergés utilisent par défaut leur limite maximale. Les modèles locaux utilisent par défaut la limite correspondant au niveau de VRAM, comme indiqué plus haut. Si votre charge de travail concerne de longs documents, ce critère suffit à trancher.
• Limites de débit. L’inférence hébergée est soumise à un quota. Si vous dépassez la limite, l’API répond 429 Too Many Requests. Votre propre serveur n’a pas de limite de débit, mais il a plutôt une limite stricte de concurrence. Il s’agit d’une panne différente, souvent plus grave.
• Politique de conservation. Lisez le texte officiel de la politique, notez la date à laquelle vous l’avez consulté et vérifiez-le à nouveau avant tout renouvellement.

Pour l’aspect financier, ne refaites pas les calculs ici. Quand un GPU VPS devient plus avantageux que la facturation au token explique correctement le seuil de rentabilité, y compris l’élément souvent oublié : un serveur GPU inactif est facturé au même tarif qu’un serveur utilisé.

Et un routeur devant plusieurs fournisseurs ?

La troisième option est un routeur, c’est-à-dire un proxy qui présente une seule API à votre application et distribue les requêtes entre plusieurs backends. Un proxy LiteLLM auto-hébergé ou un service hébergé comme OpenRouter font tous deux cela. L’intérêt est réel : une seule configuration côté client, plusieurs modèles et un basculement automatique lorsqu’un fournisseur rencontre une panne ou une dégradation temporaire. Il s’agit du prolongement naturel du mécanisme de fallback présenté plus haut, généralisé à plus de deux backends.

Il faut toutefois bien comprendre le coût de cette architecture. Un routeur hébergé est un opérateur supplémentaire qui voit vos prompts. La question de la conservation des données que vous posiez à un fournisseur doit donc désormais être posée à deux opérateurs. Un routeur auto-hébergé conserve ce relais sur votre propre machine, mais vous confie un second service à exploiter, mettre à jour et monitorer. Les routeurs résolvent le choix du modèle et la disponibilité. Ils ne résolvent pas les problèmes de confidentialité, car le prompt arrive toujours à l’endroit vers lequel le routage l’envoie.

Les erreurs que vous verrez réellement

L’API documente les codes d’état, et chacun correspond à un problème différent. 429 Too Many Requests signifie que vous avez atteint une limite de débit : ralentissez et réessayez au lieu de vous reconnecter en boucle. 502 Bad Gateway est le code propre à ce sujet : il est renvoyé lorsqu’un modèle cloud est inaccessible. Sur le chemin 1, cela signifie donc que votre daemon fonctionne et que le service en amont ne fonctionne pas. 404 Not Found associé à un nom de modèle signifie que le modèle n’existe pas sur l’hôte interrogé. Il s’agit généralement d’un nom -cloud envoyé directement à https://ollama.com, ou d’un modèle local que vous n’avez jamais téléchargé. La connexion à un compte n’a rien à voir avec ce problème pour les modèles locaux, car l’API locale ne demande aucune authentification. Les erreurs sont renvoyées au format JSON. Pendant un flux, elles apparaissent sous la forme d’une ligne telle que {"error":"an error was encountered while running the model"} dans la réponse NDJSON. C’est pourquoi un client de streaming naïf peut afficher une réponse partielle, puis s’arrêter sans explication. Analysez chaque ligne du flux et vérifiez la présence d’une clé error.

Côté local, le cas classique est un refus de connexion sur le port 11434. Cela signifie que rien n’écoute sur ce port. Vérifiez systemctl status ollama. Si le daemon fonctionne, vérifiez si OLLAMA_HOST l’a configuré sur un autre port. L’autre cas classique est une requête qui fonctionne depuis votre shell, mais échoue depuis un conteneur, parce que le localhost du conteneur n’est pas celui de l’hôte.

Enfin, il existe un mode d’échec sans aucun message d’erreur : l’absence d’accès à Internet. Le chemin cloud cesse complètement de fonctionner, tandis que le chemin local ne remarque rien. Si votre machine est utilisée en déplacement ou si votre fournisseur rencontre un incident de routage, cette différence constitue l’ensemble du produit.

Quand chaque choix est pertinent

Utilisez Ollama Cloud lorsque la charge est intermittente, lorsque le modèle est trop volumineux pour votre VPS ou lorsque vous évaluez encore l’intérêt de vous appuyer sur un modèle. Payer à la requête revient moins cher que de payer un GPU inutilisé qui ne fonctionne que vingt minutes par jour. Un modèle de 120 milliards de paramètres ne tiendra pas sur une machine louée au prix d’un déjeuner.

Exécutez le modèle vous-même lorsque les prompts ne doivent pas quitter votre infrastructure, lorsque la machine doit fonctionner hors ligne ou lorsque la charge est suffisamment constante pour qu’un GPU loué reste utilisé. Une charge constante est l’indicateur le plus fiable : l’inférence facturée à l’usage coûte cher précisément lorsqu’elle fonctionne en permanence. Si le débit de traitement d’une seule requête avec Ollama devient le goulot d’étranglement, vLLM gère mieux la charge concurrente qu’Ollama, et il s’agit alors de changer de moteur, pas d’hôte. Si vous préférez acheter cette configuration privée plutôt que la construire, comparer le devis d’un serveur d’IA privé vendu uniquement sur devis avec sa propre construction sur un GPU loué montre ce qu’implique réellement la construction et dans quels cas une API standard constitue un meilleur achat.

Dans la plupart des déploiements réels, les deux approches sont utilisées. Cela convient si la répartition est décidée explicitement. Placez le nom du modèle dans la configuration, journalisez chaque basculement et vous pourrez toujours répondre à la seule question importante ici : lesquels de ces prompts ont quitté votre infrastructure ?

FAQ

Ollama Cloud voit-il mes prompts ?

Oui. Avec le chemin hébergé, le prompt complet et la réponse complète sont envoyés à ollama.com, puis traités sur ses serveurs. La politique de confidentialité d’Ollama indique que l’entreprise traite « vos prompts et vos réponses de manière transitoire pour fournir le service » et qu’elle « n’utilise pas vos entrées ou vos sorties pour entraîner des modèles d’IA ». Elle décrit également des mesures destinées à limiter la conservation des données. Il s’agit d’un engagement du fournisseur concernant des données que vous lui avez déjà transmises. Pour les modèles locaux, la même politique indique que l’entreprise « ne collecte pas, ne stocke pas, ne transmet pas et n’a pas accès à vos prompts, réponses, interactions avec les modèles ou autres contenus que vous traitez localement ». Si le contenu ne doit jamais quitter votre infrastructure, seul le chemin local répond à cette exigence.

Pourquoi mon application pointe-t-elle toujours vers localhost alors que le modèle s’exécute dans le cloud ?

Parce que le daemon local agit comme un proxy. Lorsque vous exécutez ollama signin, puis demandez un modèle cloud dont le nom se termine par -cloud ou :cloud, votre daemon transmet cette requête à ollama.com et renvoie la réponse en streaming via le port 11434. L’URL de votre application ne change pas, ce qui est précisément l’objectif : aucune modification du code n’est nécessaire. Cela signifie aussi que l’adresse localhost ne vous apprend rien sur l’emplacement de l’inférence. Vérifiez le nom du modèle, pas l’URL. Un tag cloud dans le nom indique que le prompt a traversé Internet.

Pourquoi le même modèle me fournit-il un contexte beaucoup plus court en local ?

Ollama choisit une valeur locale par défaut en fonction de la mémoire vidéo disponible : environ 4k tokens avec moins de 24 GiB de VRAM, 32k entre 24 et 48 GiB, et 256k à partir de 48 GiB. Un VPS sans GPU appartient au niveau inférieur. Par défaut, les modèles cloud utilisent leur longueur de contexte maximale, car la mémoire qui la contient appartient au fournisseur. Augmentez la valeur locale avec OLLAMA_CONTEXT_LENGTH, soit sous la forme OLLAMA_CONTEXT_LENGTH=32768 ollama serve, soit avec une ligne Environment= dans systemctl edit ollama.service. N’oubliez pas qu’un contexte plus long nécessite un cache key-value plus volumineux en RAM. Sur un petit serveur, l’augmenter peut donc ralentir la génération ou empêcher le chargement du modèle.

Puis-je basculer automatiquement vers un modèle local lorsque le cloud est inaccessible ?

Oui, et cela ne nécessite que quelques lignes, car les deux chemins utilisent la même API. Créez deux objets Client : le premier sans argument host pour le daemon local, et le second avec host="https://ollama.com" ainsi qu’un en-tête Authorization: Bearer. Interceptez ensuite httpx.ConnectError et ollama.ResponseError autour du premier appel. Choisissez délibérément le sens du basculement. Utiliser d’abord le local avec un fallback cloud signifie qu’un prompt que vous vouliez conserver privé peut quitter la machine lors d’un simple redémarrage du daemon. Journalisez donc chaque fallback et, pour les traitements sensibles, déclenchez une erreur au lieu d’effectuer le fallback.