Tarification d'Ollama Cloud vs GPU auto-hébergé : quelle configuration choisir ?

“Ollama in the cloud” can now mean two different things.

You can use Ollama Cloud, where Ollama runs selected models on infrastructure it manages. Or you can install Ollama yourself on a rented cloud GPU and run the same kind of local Ollama server you would run on a workstation.

The interface can look almost identical. The infrastructure is not.

With Ollama Cloud, Ollama chooses and operates the hardware. You consume a hosted model through the Ollama CLI or API.

With a self-hosted GPU, you choose the hardware, install Ollama, download the model, decide how much context to allocate, and control when the GPU runs.

A simple way to choose is:

Neither approach is inherently better.

‍

‍

They solve different operational problems.

What is Ollama Cloud?

Ollama Cloud is Ollama's hosted inference service.

Cloud models still appear through the familiar Ollama interface, but their inference is offloaded to Ollama's infrastructure rather than your own GPU. You can run one through the CLI with a cloud-tagged model such as:

ollama run gpt-oss:120b-cloud

or call Ollama's hosted API directly. Ollama describes cloud models as a way to run larger models that would not fit on a personal computer while continuing to use the same local tools and API conventions.

That makes Ollama Cloud fundamentally different from putting Ollama on a cloud VM.

With Ollama Cloud, the model is remote.

With self-hosted Ollama on a cloud GPU, the machine is remote, but Ollama and the model are running on that machine under your control.

That distinction matters for cost, model availability, data flow, hardware control, and troubleshooting.

How much does Ollama Cloud cost?

As of August 2026, Ollama lists these individual plans:

New Max subscriptions are currently paused while Ollama adds capacity. Team plans start at five seats, so the minimum seat charge is $125 per month.

‍

‍

There is an important detail behind those numbers.

Ollama does not describe individual plan limits as a fixed number of tokens. Usage depends on the model and the amount of input, cached input, and output processed. Different cloud models consume different amounts of the allowance because they require different amounts of compute.

That makes an exact “$20 buys X million tokens” comparison impossible from the subscription price alone.

Ollama Cloud pricing and GPU rental aren't directly comparable

A hosted inference subscription and a rented GPU charge you for different things.

Ollama Cloud sells access to managed model inference.

A cloud GPU sells you a running machine.

On Compute with Hivenet, an RTX 5090 currently starts at €0.75 per GPU-hour, billed per second while the instance runs.

That means self-hosted GPU cost is easy to calculate:

But that table tells you nothing about how many useful tokens those hours produce.

A small model serving continuous batched traffic can produce far more work per GPU-hour than a large reasoning model receiving occasional requests.

Ollama Cloud has the opposite problem for comparison: the subscription price is clear, but individual plan allowances are intentionally expressed as usage levels rather than a universal token quota.

So there is no responsible universal break-even point between “Ollama Pro at $20” and “rent a GPU.”

You need the workload.

When Ollama Cloud makes more sense

Ollama Cloud is the simpler answer when you want the model rather than the infrastructure.

It is especially useful when:

• the model is too large for hardware you want to operate yourself
• your usage fits comfortably inside the plan limits
• you want to use the same Ollama CLI without managing CUDA or Linux
• you want large models for occasional requests
• you do not care which specific GPU serves the model
• you do not need to pin a particular local checkpoint or runtime configuration

Ollama's current cloud catalog includes models that are substantially larger than typical desktop-GPU workloads, and cloud models are automatically run at their full supported context length.

For experimentation, that is convenient.

You can concentrate on whether the model works for the task.

When self-hosted Ollama makes more sense

Self-hosting becomes useful when the infrastructure itself matters.

You choose:

• the exact GPU
• how much VRAM is available
• the model build
• whether the model stays loaded
• context length
• which ports exist
• how the API is exposed
• whether Ollama's cloud features are enabled
• when the server starts and stops

That makes self-hosted Ollama particularly useful for development environments, private experiments, internal model services, repeatable benchmarks, and workloads where you want to know exactly what machine produced the result.

You are also responsible for that machine.

Someone has to install the software, monitor disk and VRAM, manage network access, and update the runtime.

Control and responsibility arrive together.

Does self-hosted Ollama send prompts to Ollama?

For models running locally in Ollama, Ollama says it does not receive your prompts or responses.

In this context, “local” means local to the Ollama server. If you install Ollama on a Hivenet VM, the model is local to that VM even though the VM itself is in a data center rather than under your desk.

When you use Ollama Cloud, prompts and responses are processed by Ollama's hosted service. Ollama says that content is not stored, logged, or used for training.

If you want to prevent an Ollama installation from using Ollama Cloud features at all, Ollama provides:

OLLAMA_NO_CLOUD=1

or the equivalent disable_ollama_cloud server setting. This also disables Ollama's hosted web-search functionality.

That is a useful option for environments where you want the runtime to stay strictly on your own instance.

What GPU does Ollama need?

There is no single Ollama GPU requirement.

Ollama is the runtime. The model determines most of the memory requirement.

A small 4B or 8B model may fit easily on modest hardware.

A quantized 20B or 30B model can fit comfortably within a 32GB GPU.

A 70B model requires far more memory and may need multiple GPUs, CPU offloading, or a larger-memory accelerator.

Ollama officially supports NVIDIA RTX 50-series GPUs, including the RTX 5090, and currently lists NVIDIA driver version 531 or newer among its NVIDIA requirements.

Si vous avez des doutes sur le dimensionnement du modèle, commencez par notre guide VRAM pour la RTX 5090.

Pour les modèles plus volumineux, le guide des configurations GPU pour Llama 3.3 70B explique pourquoi le 70B nécessite plus qu'une seule carte de 32 Go.

Ollama ajuste la longueur du contexte en fonction de la VRAM disponible

C'est l'un des comportements d'Ollama les plus utiles à comprendre.

Ollama choisit actuellement une longueur de contexte par défaut basée sur la VRAM disponible :

Ollama recommande au moins 64K pour les charges de travail intensives en contexte, comme les agents de codage et la recherche web, tout en avertissant qu'une augmentation du contexte accroît l'utilisation de la mémoire.

‍

‍

Une RTX 5090 dispose de 32 Go de VRAM, Ollama se situe donc actuellement dans le palier de contexte par défaut de 32K sur une seule carte.

C'est un point de départ raisonnable.

N'augmentez pas le contexte à 128K simplement parce que le modèle annonce une fenêtre de 128K.

Le cache KV supplémentaire doit bien être stocké quelque part.

Un modèle peut tenir en mémoire alors que son contexte maximal ne le peut pas

Supposons qu'un modèle consomme 14 Go sur une carte de 32 Go.

Il reste donc 18 Go.

Cette mémoire restante doit couvrir le runtime et le cache de contexte.

Un contexte de 128K peut consommer beaucoup plus de mémoire cache KV qu'un contexte de 32K. Les requêtes parallèles augmentent encore ces besoins.

C'est pourquoi dire « le fichier du modèle fait 14 Go » et « le modèle nécessite 14 Go de VRAM » ne sont pas des affirmations équivalentes.

Pour Ollama spécifiquement, utilisez :

ollama ps

pour voir comment le modèle en cours d'exécution est réparti.

Ollama indique le contexte actif et précise si le modèle tourne entièrement sur le GPU, entièrement sur le CPU, ou s'il est réparti entre les deux. Sa documentation recommande de conserver le modèle intégralement sur le GPU pour obtenir les meilleures performances lorsque cela est possible.

Un bon exemple d'utilisation d'Ollama avec un seul GPU

Pour la configuration pratique, nous utiliserons :

gpt-oss:20b

Le package actuel du modèle Ollama pèse environ 14 Go et dispose d'une fenêtre de contexte de 128K. Ollama précise que le modèle MXFP4 est conçu pour fonctionner sur des systèmes disposant d'au moins 16 Go de mémoire.

Cela en fait un exemple confortable pour une RTX 5090 de 32 Go.

Nous ne l'utilisons pas parce qu'il s'agit du seul modèle Ollama pertinent.

Nous l'utilisons parce qu'il laisse suffisamment de marge pour démontrer le déploiement sans avoir à choisir un modèle minuscule qui ne nous apprendrait rien sur la mémoire GPU.

Étape 1 : lancer une VM RTX 5090

Créez une machine virtuelle dans Compute avec Hivenet.

Pour ce tutoriel, utilisez :

1. 1 × RTX 5090
2. Ubuntu
3. Accès SSH
4. suffisamment d'espace de stockage pour les modèles que vous comptez télécharger

Chaque RTX 5090 offre 32 Go de VRAM GDDR7. Les configurations GPU Hivenet peuvent évoluer au-delà d'une seule carte lorsque votre charge de travail nécessite plus de capacité.

Le Guide de démarrage rapide du calcul couvre la création de VM et l'accès SSH.

Une fois connecté, vérifiez le GPU :

nvidia-smi

Vous devriez voir la RTX 5090 avant d'installer Ollama.

Étape 2 : installer Ollama

L'installateur Linux actuel d'Ollama est :

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

L'installation Linux standard configure également Ollama pour qu'il s'exécute en tant que service.

Vérifiez-le :

ollama -v

Vérifiez ensuite le service :

sudo systemctl status ollama

S'il n'est pas en cours d'exécution :

sudo systemctl start ollama

Étape 3 : exécuter un modèle

Téléchargez et lancez le modèle 20B :

ollama run gpt-oss:20b

Lors de la première utilisation, Ollama télécharge le modèle.

Une fois chargé, saisissez une requête simple :

Explique pourquoi la VRAM du GPU limite la taille d'un modèle de langage local.

Une fois que vous avez obtenu une réponse, quittez la session interactive avec :

/bye

Le serveur Ollama continue de fonctionner.

Étape 4 : vérifier qu'Ollama utilise bien le GPU

Exécutez :

ollama ps

Vous voulez que la colonne PROCESSOR affiche :

100% GPU

Ollama utilise ce champ pour indiquer si un modèle est entièrement chargé sur le GPU, entièrement sur le CPU, ou réparti entre la mémoire du CPU et du GPU.

Consultez également :

nvidia-smi

pendant que le modèle est chargé.

Vous devriez voir Ollama consommer de la mémoire GPU.

Si ollama ps indique une répartition CPU/GPU, cela signifie que le modèle ou le contexte configuré est trop volumineux pour la capacité du GPU.

Il est généralement préférable pour les performances de réduire le contexte ou de choisir un modèle plus petit plutôt que de transférer silencieusement une grande partie de l'inférence sur le CPU.

Étape 5 : appeler Ollama via son API native

Ollama expose son API localement sur :

http://localhost:11434

par défaut.

Testez-la :

curl http://localhost:11434/api/chat \
 -d '{
   "model": "gpt-oss:20b",
   "messages": [
     {
       "role": "user",
       "content": "Donnez-moi trois utilisations pratiques pour un modèle à poids ouverts de 20B."
     }
   ],
   "stream": false
 }'

Vous disposez désormais d'une API de modèle fonctionnant sur la RTX 5090.

Aucune application web distincte n'est requise.

Étape 6 : utiliser l'API compatible avec OpenAI

Ollama prend également en charge certaines parties de l'API OpenAI.

Cela facilite la connexion de logiciels déjà conçus pour un point de terminaison de type OpenAI vers un serveur Ollama auto-hébergé.

Installez le client :

pip install --upgrade openai

Ensuite :

from openai import OpenAI

client = OpenAI(
   base_url="http://localhost:11434/v1/",
   api_key="ollama",
)

response = client.chat.completions.create(
   model="gpt-oss:20b",
   messages= [
       {
           "role": "user",
           "content": "Expliquez le parallélisme tensoriel en termes simples."
       }
   ],
)

print(response.choices[0].message.content)

Documentation d'Ollama /v1/chat/completions, /v1/responses, les embeddings, la liste des modèles et d'autres points de terminaison compatibles avec OpenAI, bien qu'il ne prétende pas à une compatibilité totale avec toutes les fonctionnalités de l'API OpenAI.

Cette nuance est importante lorsque vous migrez une application existante.

Testez les fonctionnalités que vous utilisez réellement.

Étape 7 : connexion sécurisée depuis votre propre ordinateur

Ollama se lie par défaut à :

127.0.0.1:11434

par défaut.

Pour le développement, je vous conseille de conserver ce réglage.

L'API locale d'Ollama effectue ne nécessite pas d'authentification, par conséquent, exposer directement le port 11434 à l'internet public sans couche d'authentification est une mauvaise pratique par défaut.

Utilisez plutôt le transfert de port SSH.

Sur votre propre ordinateur, prenez la commande SSH fournie par Hivenet pour l'instance et ajoutez :

-L 11434:localhost:11434

Dans l'idée :

ssh \
 -L 11434:localhost:11434 \
 <votre-cible-ssh-hivenet-habituelle>

Ensuite, les logiciels sur votre ordinateur peuvent utiliser :

http://localhost:11434

tandis que le serveur Ollama proprement dit reste lié à l'interface de bouclage (loopback) de la machine virtuelle.

Il s'agit d'une configuration de développement plus propre que d'exposer une API d'inférence non authentifiée au monde entier.

Si vous avez besoin d'une API publique, ajoutez une véritable barrière de sécurité

Pour une utilisation en production, un tunnel SSH ne constitue évidemment pas une architecture d'application.

Si le service Ollama doit être accessible par d'autres systèmes, placez une couche HTTPS authentifiée devant lui.

Ollama documente l'exposition de son service via des proxies inverses tels que Nginx et permet de modifier l'adresse de liaison via OLLAMA_HOST.

L'essentiel est que :

OLLAMA_HOST=0.0.0.0:11434

rend le service accessible sur le réseau.

Cela ne ajoute pas d'authentification.

L'exposition réseau et le contrôle d'accès sont des tâches distinctes.

Comment augmenter la longueur de contexte d'Ollama

Sur un GPU de 32 Go, Ollama utilise par défaut un contexte de 32 000 jetons.

Si votre charge de travail nécessite davantage, vous pouvez définir le contexte du serveur via :

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Ollama recommande spécifiquement au moins 64 000 jetons pour les outils de développement, les agents et les flux de travail intensifs en recherche web.

Si Ollama s'exécute en tant que service systemd sous Linux, configurez la variable d'environnement via le service plutôt que de démarrer manuellement un second serveur :

sudo systemctl edit ollama.service

Ajoutez ensuite :

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=64000"

Rechargez et redémarrez :

sudo systemctl daemon-reload
sudo systemctl restart ollama

Vérifiez ensuite :

ollama ps

Ne présumez pas que le contexte plus large est adapté simplement parce qu'Ollama démarre.

Surveillez l'emplacement du GPU et la VRAM.

Maintenir le modèle en mémoire peut améliorer le temps de réponse

Par défaut, Ollama conserve actuellement un modèle en mémoire pendant cinq minutes après son utilisation.

Vous pouvez contrôler cela via le paramètre keep_alive de l'API.

Par exemple, pour maintenir le modèle chargé :

curl http://localhost:11434/api/generate \
 -d '{
   "model": "gpt-oss:20b",
   "keep_alive": -1
 }'

Ou pour le décharger immédiatement après une requête :

curl http://localhost:11434/api/generate \
 -d '{
   "model": "gpt-oss:20b",
   "keep_alive": 0
 }'

Maintenir le modèle en mémoire réduit les délais de rechargement.

Cela signifie également que la VRAM reste occupée.

Sur une machine hébergeant plusieurs modèles, cela devient un élément de la gestion de la mémoire.

Ollama peut traiter plusieurs requêtes, mais la VRAM détermine toujours vos limites.

Ollama prend en charge le traitement simultané lorsque la mémoire disponible est suffisante.

Si plusieurs modèles doivent être chargés et que la mémoire GPU est insuffisante, les requêtes peuvent être mises en file d'attente pendant qu'Ollama décharge les modèles inactifs pour libérer de l'espace. Pour l'inférence sur GPU, Ollama précise qu'un nouveau modèle doit tenir entièrement dans la VRAM pour être chargé simultanément avec d'autres modèles déjà présents sur le GPU.

C'est l'une des raisons pour lesquelles un modèle occupant la quasi-totalité des 32 Go est moins flexible qu'un modèle de 14 Go.

La VRAM inutilisée peut servir à :

• le contexte
• les requêtes parallèles
• un autre modèle
• le cache
• une marge de manœuvre pour l'exécution

Le modèle le plus volumineux que vous pouvez charger est rarement le meilleur modèle à déployer.

Ollama peut-il utiliser plusieurs GPU ?

Oui.

Ollama peut détecter plusieurs GPU compatibles, et son planificateur utilise la VRAM disponible lors du placement des modèles. Vous pouvez également restreindre les GPU NVIDIA visibles par Ollama en utilisant :

CUDA_VISIBLE_DEVICES

Ollama recommande d'utiliser les UUID de GPU plutôt que des identifiants numériques pour garantir une sélection stable des périphériques.

L'utilisation de plusieurs GPU devient nécessaire lorsqu'un modèle ne tient plus sur une seule carte.

C'est le sujet que nous abordons dans notre guide des configurations GPU pour Llama 3.3 70B.

Pour une mise en production sérieuse, je vous conseille toutefois de comparer Ollama avec un moteur de service spécifiquement conçu pour l'inférence à haut débit avant de conclure que l'architecture multi-GPU d'Ollama est la solution finale pour votre projet.

Ollama ou vLLM ?

Ollama est d'une commodité exceptionnelle.

Il gère le téléchargement des modèles, les formats, le service local, l'allocation matérielle, une interface en ligne de commande simple et des API, le tout au sein d'une interface unique.

Cela le rend idéal pour :

• le développement
• l'expérimentation locale et distante
• les outils internes
• les points de terminaison de modèles individuels
• le test de familles de modèles
• les applications déjà conçues autour de l'API Ollama

vLLM a des priorités différentes.

Il est conçu pour l'inférence en production, le traitement par lots continu, la gestion du cache KV, le service distribué et les points de terminaison compatibles OpenAI à haut débit.

Nous comparons déjà ces options dans vLLM vs TGI vs TensorRT-LLM vs Ollama.

La question pertinente n'est pas de savoir quel projet est le « meilleur ».

Il s'agit de déterminer si vous préférez un environnement d'exécution de modèle pratique ou un serveur d'inférence optimisé pour le débit.

Ollama Cloud ou l'API d'inférence Hivenet ?

Une autre distinction mérite d'être faite.

Ollama Cloud est un service de modèles géré, articulé autour de l'interface et du catalogue de modèles Ollama.

L'API d'inférence Hivenet est également une solution d'inférence gérée, accessible via des points de terminaison compatibles avec OpenAI.

Si votre seul besoin est de « fournir une API de modèle à mon application », les deux appartiennent à la catégorie de l'inférence gérée plutôt qu'à celle de la location de GPU.

Si votre besoin est le suivant :

Je souhaite installer Ollama moi-même, choisir mon point de contrôle, contrôler la machine et décider quand le GPU fonctionne,

alors Compute with Hivenet est le produit adapté.

Cette distinction permet de garder une approche cohérente en matière d'infrastructure.

Les modèles dans le cloud peuvent disparaître ; les modèles locaux restent sous votre contrôle

Il existe une différence opérationnelle qui mérite davantage d'attention.

Ollama retire périodiquement les modèles hébergés dans le cloud au gré de l'évolution de son catalogue. Sa documentation avertit explicitement que les applications dépendant de modèles cloud retirés pourraient nécessiter une mise à jour. Les modèles locaux ne sont pas affectés par ces suppressions.

C'est la norme pour un service de modèles géré.

Quelqu'un doit bien assurer la maintenance du catalogue.

Mais cela signifie qu'un nom de modèle hébergé doit être considéré comme une dépendance externe.

Lorsque vous hébergez vous-même un fichier de modèle, vous contrôlez le moment où ce point de contrôle change.

La charge vous incombe également : les mises à jour de sécurité, la compatibilité du moteur d'exécution, le stockage et les mises à niveau des modèles ne se font plus automatiquement suite à une modification du catalogue par le fournisseur.

Les services gérés sacrifient une part de contrôle au profit de la maintenance.

L'auto-hébergement sacrifie la maintenance au profit du contrôle.

Ne louez pas un GPU pour imiter maladroitement Ollama Cloud

Si vous avez besoin d'un modèle pour vingt minutes, Ollama Cloud est probablement le point de départ le plus simple.

Lancer une machine virtuelle GPU, configurer Linux, télécharger un point de contrôle de 20 Go, sécuriser une API et supprimer l'environnement par la suite, cela relève du travail d'infrastructure.

Ce travail devient justifié lorsque vous en tirez un bénéfice :

• matériel fixe
• mémoire GPU prévisible
• points de contrôle personnalisés
• fichiers de modèles privés
• mises à niveau contrôlées
• reproductibilité des benchmarks
• services internes à exécution longue
• une économie de charge de travail qui justifie votre propre instance

Sinon, utilisez le service géré.

L'intérêt de l'auto-hébergement est de garder le contrôle, pas de prouver que vous savez administrer Linux.

Ne payez pas non plus pour un GPU inutilisé

L'erreur inverse consiste à laisser un GPU auto-hébergé tourner au cas où le modèle serait nécessaire plus tard.

À 0,75 € de l'heure, une seule RTX 5090 fonctionnant en continu coûte :

24 × 0,75 € = 18 € par jour

et environ :

30 × 18 € = 540 € sur un mois de 30 jours

avant même de prendre en compte les autres ressources.

Hivenet utilise une facturation à la seconde à la demande ; les charges de travail Ollama intermittentes devraient donc tirer parti de la possibilité d'arrêter le calcul lorsqu'il n'est pas nécessaire.

Un point de terminaison auto-hébergé ne devient rentable que si le modèle d'utilisation est cohérent.

Quelle configuration Ollama choisir ?

Utilisez Ollama localement sur votre propre matériel lorsque votre machine dispose déjà de suffisamment de mémoire GPU et que vous souhaitez la configuration privée la plus simple.

Utilisez Ollama Cloud lorsque vous souhaitez utiliser des modèles hébergés sans avoir à gérer un serveur GPU, en particulier si le modèle est plus volumineux que votre matériel disponible.

Utilisez Ollama sur un GPU loué lorsque vous souhaitez bénéficier du flux de travail Ollama tout en conservant le contrôle sur le modèle, le matériel, la configuration, le chemin des données ou l'environnement d'exécution.

Utilisez vLLM sur des GPU loués lorsque l'inférence en production à haut débit est plus importante que la simplicité d'utilisation locale d'Ollama.

Utilisez une API d'inférence gérée lorsque la gestion de la couche de service n'apporte aucune valeur ajoutée à votre projet.

C'est une distinction plus pertinente que de tenter de déclarer une méthode de déploiement universellement moins coûteuse.

FAQ d'Ollama Cloud

Qu'est-ce qu'Ollama Cloud ?

Ollama Cloud est le service d'inférence hébergé d'Ollama. Les modèles marqués « Cloud » utilisent l'infrastructure gérée par Ollama plutôt que votre GPU local, tout en restant accessibles via l'interface en ligne de commande et les API d'Ollama.

Ollama Cloud est-il gratuit ?

Ollama propose actuellement un forfait gratuit pour une utilisation légère du cloud. L'offre Pro coûte 20 $ par mois, tandis que les options Team et Max offrent des capacités et une concurrence différentes.

Combien coûte Ollama Pro ?

Ollama propose actuellement l'offre Pro à 20 $ par mois ou 200 $ par an. Elle inclut 50 fois plus de capacité cloud que l'offre gratuite et permet jusqu'à trois modèles cloud simultanés.

Ollama Cloud facture-t-il au jeton ?

Les forfaits individuels d'Ollama utilisent des limites d'utilisation dépendantes du modèle plutôt qu'un quota fixe de jetons. La consommation est influencée par les entrées, les entrées mises en cache, les sorties et les besoins en calcul du modèle.

Ollama peut-il fonctionner sur un GPU cloud ?

Oui. Ollama peut être installé sur une machine virtuelle Linux équipée d'un GPU. Le modèle s'exécute alors sur le GPU associé à cette machine virtuelle plutôt que via Ollama Cloud.

Ollama prend-il en charge la RTX 5090 ?

Oui. La liste actuelle du matériel NVIDIA pris en charge par Ollama inclut explicitement la RTX 5090.

De combien de VRAM Ollama a-t-il besoin ?

Les besoins dépendent du modèle, de la précision et de la longueur de contexte configurée. Ollama n'a pas de besoin fixe en VRAM.

Quelle longueur de contexte Ollama utilise-t-il sur une RTX 5090 ?

Ollama utilise par défaut un contexte de 32K pour les systèmes dotés de 24 à 48 Gio de VRAM. Une RTX 5090 de 32 Go entre dans cette catégorie. Des contextes plus larges peuvent être configurés, mais nécessitent de la VRAM supplémentaire.

Quel port Ollama utilise-t-il ?

L'API locale d'Ollama utilise le port 11434 par défaut et se lie à 127.0.0.1.

L'API locale d'Ollama nécessite-t-elle une authentification ?

Non. Ollama ne nécessite pas d'authentification pour son API sur localhost:11434. Si vous exposez un serveur auto-hébergé à distance, ajoutez une couche de sécurité appropriée plutôt que de supposer que l'API authentifie elle-même les utilisateurs.

Ollama envoie-t-il les prompts locaux vers le cloud ?

Ollama indique que les prompts et les réponses des modèles exécutés localement ne sont pas envoyés à ollama.com. Les modèles cloud sont traités par le service hébergé d'Ollama ; Ollama précise que le contenu des prompts et des réponses n'est ni stocké, ni enregistré, ni utilisé pour l'entraînement.

Puis-je désactiver Ollama Cloud ?

Oui. Définissez OLLAMA_NO_CLOUD=1 ou activez disable_ollama_cloud dans la configuration du serveur Ollama. Cela désactive les fonctionnalités de modèles dans le cloud et de recherche web hébergée.

Ollama peut-il utiliser plusieurs GPU ?

Oui. Ollama prend en charge les systèmes multi-GPU et vous permet de restreindre les GPU NVIDIA visibles avec CUDA_VISIBLE_DEVICES.

Ollama est-il meilleur que vLLM ?

Ils ont des forces différentes. Ollama met l'accent sur la gestion pratique des modèles et l'utilisation locale ou cloud via une interface unique. vLLM est conçu pour l'inférence en production à haut débit et le service distribué. Le meilleur choix dépend de votre charge de travail.

‍