Quand vous lancez un modèle local, ses fichiers occupent de l’espace disque et son exécution dépend de la mémoire et du processeur de votre machine. Ollama Cloud déplace l’inférence, c’est-à-dire la production de la réponse, vers des serveurs distants. Vous pouvez ainsi tester des modèles qui seraient trop lourds pour votre PC, mais vos requêtes quittent alors l’ordinateur. Le choix dépend donc autant de votre matériel que de votre tolérance à l’envoi de données et de votre façon d’utiliser l’outil.
Qu’est-ce qui part dans le cloud, et qu’est-ce qui reste local ?
Ollama Cloud n’est pas un réglage qui rend votre carte graphique plus puissante : le calcul du modèle est effectué sur l’infrastructure distante d’Ollama. Votre ordinateur sert à préparer et transmettre la demande, puis à afficher le résultat. L’interface de travail peut rester celle d’Ollama, mais le modèle ne tourne pas sur votre GPU. La documentation officielle décrit un usage depuis l’application, le terminal ou une application qui appelle l’API, sans téléchargement du modèle cloud. Pour situer cette fonction parmi les autres usages de l’intelligence artificielle, retenez cette distinction simple : le cloud déplace l’inférence, pas nécessairement le reste de votre environnement de travail.
En mode local, les fichiers du modèle sont stockés sur votre ordinateur et l’inférence utilise ses ressources. Ollama indique qu’une installation locale expose notamment son API sur http://localhost:11434. À titre de repère matériel concret, son démarrage rapide donne pour Gemma 4 E2B un téléchargement d’environ 7,2 Go et recommande 8 Go de mémoire vidéo disponible, ou de mémoire unifiée sur Mac ; une fenêtre de contexte plus grande demande davantage de mémoire. Ces valeurs concernent ce modèle local précis, pas les modèles cloud ni tous les modèles Ollama.
La politique de confidentialité d’Ollama fait une différence explicite entre les deux modes : selon sa politique de confidentialité, l’entreprise indique ne pas voir le contenu traité localement, tandis que les prompts et réponses cloud sont traités de façon transitoire pour fournir le service et ne servent pas à entraîner ses modèles. Le choix local/cloud porte donc aussi sur le trajet des données. Ne transmettez pas de mots de passe, de clés privées, de données personnelles ou de fichiers de jeu confidentiels sans avoir évalué les règles de votre situation.
Quels critères regarder avant de choisir ?
Commencez par votre contrainte principale. Si le modèle souhaité dépasse la mémoire de votre carte graphique, le cloud évite de télécharger ses poids et de faire l’inférence sur votre PC. Si vous voulez limiter la transmission de vos prompts, travailler hors ligne ou contrôler le modèle exécuté, choisissez plutôt un modèle local adapté à votre machine. Le cloud dépend d’une connexion internet et de l’accès au compte ou à la clé API ; le local dépend surtout des ressources disponibles et de l’espace disque.
Vérifiez ensuite le nom exact du modèle dans le catalogue Ollama au moment du test. La liste des modèles hébergés évolue : un exemple documenté aujourd’hui ne garantit pas que le même nom, les mêmes capacités ou les mêmes conditions d’accès seront toujours disponibles. La documentation distingue également le nom à utiliser selon le chemin d’accès : dans l’application ou la CLI, un nom peut se terminer par :cloud, tandis que l’API directe utilise le nom renvoyé par le catalogue, par exemple gemma4:31b. Ne transformez pas automatiquement l’un en l’autre ; copiez le nom adapté au mode utilisé.
Enfin, vérifiez les conditions d’usage du compte avant d’automatiser un test. Ollama renvoie vers la page de consommation et les offres plutôt que de présenter un tarif ou un quota fixe dans la documentation Cloud. Ne déduisez donc pas qu’un modèle est gratuit ou qu’un nombre donné de requêtes est inclus à partir de son seul nom. Consultez les informations affichées dans votre compte avant d’envoyer des tâches répétées ou volumineuses.
Comment Ollama Cloud se compare-t-il à l’API locale ?
Les deux modes peuvent s’utiliser depuis une application, mais les adresses et l’authentification changent. L’API locale répond sur http://localhost:11434/api ; l’API cloud directe se trouve sur https://ollama.com/api. Les interfaces compatibles OpenAI utilisent pour leur part le chemin /v1 sur les deux hôtes. La documentation expose ainsi plusieurs points d’accès, mais ils ne signifient pas que l’exécution cloud est devenue locale.
Avec la CLI ou l’application Ollama, connectez-vous à votre compte puis choisissez un modèle cloud. La commande locale qui appelle le serveur Ollama peut rester sur localhost, mais le modèle désigné comme cloud sera exécuté sur l’infrastructure distante. Avec une application qui appelle directement Ollama Cloud, vous n’avez pas besoin d’installer Ollama sur la machine qui envoie la requête ; vous devez toutefois posséder une clé API et l’utiliser côté serveur ou dans un environnement protégé. Si vous voulez piloter des modèles locaux avec des requêtes HTTP, l’API Ollama avec curl suit justement cette logique d’appel, même si l’adresse et l’authentification diffèrent pour le cloud.
Pour un joueur, le cloud peut être pratique pour résumer des journaux, expliquer une erreur de configuration ou tester une génération de texte sans mobiliser la VRAM utilisée par un jeu. Il ne garantit pas à lui seul une réponse plus rapide : la latence réseau, le modèle, la charge et les conditions du service interviennent aussi. Pour une assistance qui doit lire des fichiers locaux, vérifiez également ce que votre outil transmet réellement. Le simple fait qu’Ollama soit installé sur votre PC ne signifie pas que chaque pièce jointe ou chaque prompt restera sur celui-ci.
Comment lancer un premier test sans exposer une clé ?
Pour commencer dans l’application ou le terminal, installez Ollama si nécessaire, ouvrez-le et suivez ses étapes de configuration. Connectez-vous, puis sélectionnez un modèle indiqué comme cloud dans le catalogue actuel. Dans un terminal, une commande de type ollama run nom-du-modele:cloud lance une session interactive ; remplacez le nom d’exemple par l’identifiant exact affiché par Ollama. Une invite de connexion ou un message d’accès refusé indique généralement qu’il faut vérifier l’état du compte et l’accès au modèle.
Pour un test direct de l’API hébergée, créez une clé dans votre compte, puis placez-la dans une variable d’environnement du terminal. La documentation propose OLLAMA_API_KEY et une requête curl vers https://ollama.com/api/chat, avec Authorization: Bearer $OLLAMA_API_KEY. Le code d’exemple utilise un nom comme gemma4:31b, transmet un message dans le tableau messages et peut fixer "stream": false pour recevoir une réponse non diffusée progressivement. Ce réglage permet de lire le résultat d’un seul bloc ; il ne change pas le lieu d’exécution.
Ne remplacez jamais la variable par une vraie clé dans un exemple que vous publiez ou envoyez à quelqu’un. Gardez-la hors du code côté navigateur, des captures d’écran, des dépôts de code et des journaux de terminal partagés. La documentation d’authentification précise que les clés directes n’expirent pas et qu’elles peuvent être révoquées dans les paramètres. Si vous soupçonnez une fuite, révoquez la clé concernée et créez-en une nouvelle plutôt que de continuer à l’utiliser.
Pour l’API locale, le parcours est différent : le serveur écoute par défaut à l’adresse http://localhost:11434, et l’API locale ne demande pas de clé d’authentification. Mais si vous utilisez ce serveur local pour appeler un modèle cloud après connexion à Ollama, le calcul du modèle reste distant. Le port local indique où votre application joint le serveur Ollama sur votre ordinateur, pas où les poids du modèle sont exécutés.
Comment vérifier que le test utilise bien le cloud ?
Contrôlez d’abord l’adresse appelée et le nom du modèle. Une requête vers https://ollama.com/api/chat est un accès direct à l’API hébergée ; une requête vers http://localhost:11434/api/chat passe par le serveur local Ollama. Dans ce deuxième cas, inspectez le nom de modèle fourni : il peut désigner un modèle cloud accessible après connexion, ou un modèle téléchargé et exécuté localement. L’hôte seul ne suffit donc pas à distinguer tous les scénarios d’exécution.
Vérifiez ensuite que le serveur répond et que la réponse correspond à votre prompt. Avec une requête non diffusée, l’exemple Ollama renvoie le texte dans message.content. Si l’appel échoue, séparez le diagnostic : connexion internet et adresse, session Ollama ou clé API, nom de modèle, puis format JSON et en-tête Authorization. Ne partagez pas la clé pour obtenir de l’aide ; supprimez-la des traces avant de publier une commande ou un journal.
Enfin, comparez un prompt court et non sensible dans les deux modes si vous hésitez. Notez le modèle exact, le temps perçu, la qualité utile pour votre tâche et les ressources consommées sur le PC. Ce test maison ne démontre pas une performance générale : il indique seulement quel parcours convient à votre configuration et à votre usage. Si la confidentialité locale est prioritaire, vérifiez que le modèle choisi est bien local et que l’application ne l’a pas remplacé par un modèle cloud avant d’y envoyer des contenus personnels.
Questions fréquentes
Faut-il télécharger le modèle pour utiliser Ollama Cloud ?
Non, les modèles cloud ne sont pas téléchargés sur votre ordinateur pour l’inférence. Avec l’application ou la ligne de commande, Ollama utilise un nom de modèle cloud après connexion au compte. Pour l’accès direct à l’API hébergée, vous envoyez une requête à ollama.com avec une clé API. Le modèle choisi et vos échanges sont traités à distance.
Ollama Cloud fonctionne-t-il sans compte ?
Non pour les modèles cloud utilisés depuis l’application ou la CLI : il faut vous connecter à Ollama. Pour appeler directement l’API hébergée sur ollama.com, il faut une clé API dans l’en-tête d’autorisation. En revanche, une API Ollama locale sur votre propre machine ne demande pas d’authentification par défaut.
Mes prompts sont-ils utilisés pour entraîner les modèles ?
La politique de confidentialité d’Ollama indique que les prompts et réponses traités par ses modèles hébergés ne sont pas utilisés pour entraîner des modèles. Elle précise aussi que le contenu est traité de manière transitoire pour fournir le service. Cela ne rend pas le cloud équivalent au traitement local : pour des données sensibles, vérifiez les règles applicables à votre cas et privilégiez le local si vous ne voulez pas transmettre le contenu.
Comment repérer une erreur de connexion ou d’authentification ?
Commencez par vérifier que vous êtes connecté si vous utilisez l’application ou la CLI, ou que la variable OLLAMA_API_KEY est définie dans le terminal qui lance curl. Pour l’API hébergée, contrôlez aussi l’adresse en https et l’en-tête Authorization: Bearer. Ne collez jamais la clé dans un script public, un dépôt Git ou le code d’une page web.
