- Ollama ne propose pas de modèles hébergés dans le cloud sous forme de service API : c’est un moteur d’inférence local que vous exécutez sur votre propre matériel.
- Vous pouvez déployer Ollama sur des machines virtuelles cloud (AWS EC2, Compute Engine de Google Cloud, machines virtuelles Azure) afin de combiner la simplicité d’utilisation d’Ollama avec la scalabilité du cloud.
- Les fournisseurs cloud spécialisés dans les GPU, tels que Lambda Labs, Vast.ai et RunPod, proposent des instances GPU plus économiques que les grands fournisseurs cloud pour l’exécution d’Ollama.
- Le coût d’Ollama dans le cloud s’élève à 0,50 à 3 $/heure pour des instances GPU, contre 0,50 à 5 $ par million de jetons pour les API commerciales — le seuil de rentabilité dépend du volume d’utilisation.
Ollama ne fournit pas de modèles hébergés dans le cloud sous forme de service API géré. Ollama est un moteur d’inférence local qui exécute des modèles open source sur votre propre matériel. Toutefois, vous pouvez déployer Ollama sur une infrastructure cloud — machines virtuelles AWS EC2, Google Cloud, Azure ou fournisseurs spécialisés dans les GPU — afin de bénéficier de la puissance de calcul du cloud tout en conservant l’interface simple d’Ollama. Cette approche vous confère un contrôle total sur l’environnement d’exécution et peut s’avérer plus économique que les API commerciales pour des volumes d’utilisation élevés.
Ce qu’est Ollama (et ce qu’il n’est pas)
Ollama est un moteur d’inférence open source qui exécute des modèles de langage volumineux localement. Il gère le téléchargement des modèles, leur quantification et leur inférence via une interface CLI simple et une API REST. Selon le dépôt officiel Ollama, il prend en charge des modèles issus des familles Llama, Mistral, Gemma, Qwen et DeepSeek entre autres.
Ollama ne fonctionne pas comme un fournisseur cloud. Il n’héberge pas de modèles sur ses propres serveurs ni ne facture à l’usage du jeton. Lorsque vous exécutez Exécuter llama3.3, le modèle s’exécute sur la machine ayant lancé la commande — votre ordinateur portable, un serveur de centre de données ou une machine virtuelle cloud que vous payez séparément.
Le terme «ollama cloud » désigne généralement l’un des trois schémas de déploiement suivants :
- Exécuter Ollama sur une machine virtuelle cloud dotée d’une accélération GPU
- Déployer Ollama dans une plateforme d’orchestration de conteneurs (Kubernetes, ECS)
- Utiliser Ollama sur une instance cloud dédiée au GPU pour une montée en charge à la demande
Exécuter Ollama sur les principaux fournisseurs cloud
Instances GPU EC2 d’AWS
AWS propose des instances EC2 équipées de GPU dans les familles G, P et Inf. Pour les charges de travail Ollama, l’instance g5.xlarge (1 × NVIDIA A10G, 24 Go de VRAM) débute à environ 1,01 $/heure à la demande dans la région us-east-1, tandis que la g5.12xlarge (4 × A10G, 96 Go de VRAM) coûte environ 5,67 $/heure.
Pour déployer Ollama sur EC2 :
# Lancer une instance Ubuntu 22.04 g5.xlarge avec l’AMI Deep Learning
# Se connecter en SSH à l’instance
sudo apt update
curl -fsSL https://ollama.com/install.sh | sh
# Vérifier que le GPU est détecté
nvidia-smi
# Exécuter un modèle
ollama run llama3.3:70b
A Llama 3.3 70B nécessite environ 40 Go de VRAM en quantification 4 bits, ce qui implique d’utiliser une g5.12xlarge ou une instance plus grande. Llama 3.1 8B nécessite environ 5 Go de VRAM en quantification 4 bits, ce qui convient parfaitement à une g5.xlarge.
Google Cloud Platform
GCP propose des instances GPU via les familles de machines N1 et A2 de Compute Engine. Une instance n1-standard-4 dotée d’un NVIDIA T4 (16 Go de VRAM) coûte environ 0,62 $/heure, tandis qu’une a2-highgpu-1g équipée d’un A100 (40 Go de VRAM) coûte environ 3,67 $/heure dans la région us-central1.
# Créer une instance avec GPU
gcloud compute instances create ollama-instance
--zone=us-central1-a
--machine-type=n1-standard-4
--accelerator=type=nvidia-tesla-t4,count=1
--image-family=ubuntu-2204-lts
--image-project=ubuntu-os-cloud
--maintenance-policy=TERMINATE
# Connexion SSH et installation
gcloud compute ssh ollama-instance --zone=us-central1-a
curl -fsSL https://ollama.com/install.sh | sh
ollama run mistral:7b
Microsoft Azure
Les machines virtuelles de la série NC d’Azure intègrent des GPU NVIDIA adaptés aux charges de travail d’inférence. Une NC6s_v3 (1 × V100, 16 Go de VRAM) coûte environ 3,06 $/heure, tandis qu’une NC24ads_A100_v4 (1 × A100, 80 Go de VRAM) coûte environ 3,67 $/heure dans la région Est des États-Unis.
L’installation suit le même schéma : provisionner une machine virtuelle Ubuntu dotée d’un GPU, installer les pilotes NVIDIA si l’on n’utilise pas une image préconfigurée, puis exécuter le script Installation d'Ollama .
Fournisseurs cloud spécialisés dans les GPU
Les fournisseurs cloud spécialisés dans les GPU offrent souvent un meilleur rapport performance/prix que les grands fournisseurs cloud pour les déploiements Ollama :
| Fournisseur | GPU | VRAM | Coût/heure | Adapté à |
|---|---|---|---|---|
| Lambda Labs | A100 | 40 Go | $1.10 | DeepSeek R1 Distill Llama 70B, Llama 3.3 70B |
| Vast.ai | RTX 4090 | 24 Go | $0.34-$0.54 | Mistral 7B, Llama 3.1 8B, Phi-4 |
| RunPod | A40 | 48 Go | $0.79 | Mistral Large 3 (instance unique), Llama 3.3 70B |
| Paperspace | A4000 | 16 Go | $0.76 | Modèles plus petits jusqu’à environ 14 milliards de paramètres |
Lambda Labs propose la configuration la plus simple : les instances sont livrées avec les pilotes NVIDIA et CUDA déjà installés. Après avoir lancé une instance depuis leur tableau de bord :
ssh ubuntu@
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:32b
Vast.ai fonctionne comme un marché de capacité GPU inutilisée, offrant les prix les plus bas, mais avec une disponibilité variable. Vous soumissionnez des offres ou louez des instances via leur interface web, puis vous vous connectez en SSH pour installer Ollama.
Comparaison des coûts : Ollama dans le cloud contre les services API
La pertinence économique d’Ollama hébergé dans le cloud dépend de votre volume d’utilisation. Utilisez le calculateur auto-hébergement vs API pour déterminer votre seuil de rentabilité.
| Modèle | Coût de l’API (par million de jetons) | GPU cloud | Coût de l'instance par heure | Jetons par heure au seuil d'équilibre |
|---|---|---|---|---|
| Llama 3.3 70B | 0,10 $ en entrée / 0,32 $ en sortie | Lambda A100 40 Go | $1.10 | ~3,4 millions de jetons de sortie |
| Mistral Large 3 | 2,00 $ en entrée / 6,00 $ en sortie | RunPod 4×A40 | $3.16 | ~530 000 jetons de sortie |
| Qwen3 32B | 0,08 $ en entrée / 0,28 $ en sortie | Vast.ai RTX 4090 | $0.54 | ~1,9 million de jetons de sortie |
| DeepSeek R1 | 0,50 $ en entrée / 2,15 $ en sortie | Lambda 4×A100 | $4.40 | ~2 millions de jetons de sortie |
Si vous traitez plus de jetons que le volume seuil d'équilibre par heure, Ollama hébergé dans le cloud devient moins coûteux. Pour les charges de travail ponctuelles ou à faible volume, des API telles que Claude Sonnet 5 (2,00 $ en entrée / 10,00 $ en sortie par million de jetons) ou Gemini 3.6 Flash (1,50 $ en entrée / 7,50 $ en sortie par million de jetons) offrent une meilleure rentabilité, sans frais liés à un temps d'inactivité.
Schémas de déploiement
Instances à la demande
Démarrez une instance GPU lorsque vous en avez besoin, exécutez votre charge de travail, puis mettez fin à l'instance. Cette approche convient bien au traitement par lots, au développement ou à des inférences occasionnelles. Tous les principaux fournisseurs de services cloud et de GPU prennent en charge la tarification à la demande.
Instances Spot / préemptibles
Les instances Spot d'AWS, les machines virtuelles préemptibles de GCP et les machines virtuelles Spot d'Azure proposent des réductions de 60 à 90 %, mais peuvent être interrompues avec un préavis de 30 secondes à 2 minutes. Elles conviennent aux traitements par lots tolérants aux pannes, où il est possible de sauvegarder l'avancement du traitement.
Sur Vast.ai, les instances interrompables s'exécutent aux prix du marché, sans garantie de non-interruption : elles offrent les tarifs les plus bas, mais exigent une gestion robuste des erreurs.
Orchestration de conteneurs
Pour les déploiements en production, exécutez Ollama dans Kubernetes avec des pools de nœuds GPU. Cela permet la mise à l'échelle automatique, l'équilibrage de charge et une haute disponibilité. Utilisez l'image officielle Ollama Docker :
docker pull ollama/ollama
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama
Ensuite, déployez-la sur votre cluster en définissant les demandes de ressources GPU dans la spécification de votre pod.
Sélection des modèles pour les déploiements cloud
Choisissez les modèles en fonction du budget VRAM de votre GPU. Utilisez le Calculateur de VRAM pour estimer les besoins :
- VRAM de 16 à 24 Go (T4, RTX 4090, A10G) : Mistral 7B (~4,5 Go en quantification 4 bits), Llama 3.1 8B (~5 Go), Phi-4 (~9 Go), Qwen3 14B (~9 Go), Gemma 3 12B (~8 Go)
- VRAM de 40 à 48 Go (A100 40 Go, A40) : Llama 3.3 70B (~40 Go), DeepSeek R1 Distill Llama 70B (~40 Go), Mistral NeMo 12B (avec marge pour un contexte plus large)
- VRAM de 80 Go et plus (A100 80 Go, H100) : Llama 4 Scout (~65 Go), DeepSeek R1 (~400 Go, nécessite 4×A100 ou équivalent), Mistral Large 3 (~400 Go)
Les modèles nécessitant plus de 80 Go de VRAM requièrent des configurations multi-GPU ou du parallélisme tensoriel, que Ollama ne prend pas nativement en charge à ce jour (version 0.3). Pour ces modèles, envisagez plutôt des frameworks tels que vLLM ou TGI, ou utilisez des API commerciales.
Optimisation des performances
Plusieurs paramètres influencent la vitesse d'inférence d'Ollama sur les GPU cloud :
- Quantification: Par défaut, Ollama utilise la quantification 4 bits (Q4_0). Utilisez
ollama pull model:q8_0pour la quantification 8 bits (meilleure qualité, consommation de VRAM doublée) oumodel:q2_Kpour la quantification 2 bits (plus rapide, qualité réduite). - Fenêtre de contexte: Défini via le paramètre
num_ctx. Des contextes plus longs consomment davantage de VRAM : un contexte de 32 K nécessite nettement plus de mémoire qu’un contexte de 4 K pour le même modèle. - Taille du lot (batch size): Augmentez le paramètre
num_batchpour les charges de travail axées sur le débit, lorsque la latence importe moins que le nombre de jetons par seconde. - Couches GPU: Ollama transfère automatiquement toutes les couches vers le GPU. Sur des instances disposant d'une VRAM limitée, il revient automatiquement sur le CPU pour les couches qui ne tiennent pas dans la VRAM, ce qui réduit drastiquement la vitesse.
Questions fréquemment posées
Ollama propose-t-il son propre hébergement cloud ?
Non. Ollama est un logiciel auto-hébergé qui exécute des modèles sur votre propre infrastructure. Il n’existe aucun service cloud officiel Ollama ni aucune API gérée. Lorsque les gens font référence aux « modèles Ollama cloud », ils désignent l’exécution du logiciel Ollama sur une infrastructure cloud qu’ils provisionnent eux-mêmes via AWS, GCP, Azure ou des fournisseurs spécialisés dans les GPU.
Puis-je utiliser le format d’API d’Ollama avec des modèles cloud ?
Oui. Une fois Ollama lancé sur une machine virtuelle cloud, il expose une API REST sur le port 11434, compatible avec le format d’API OpenAI. Vous pouvez configurer n’importe quel client compatible OpenAI pour qu’il pointe vers l’adresse IP et le port de votre instance cloud. Cela vous permet d’utiliser les modèles hébergés par Ollama comme substituts directs aux API commerciales dans de nombreuses applications, bien que vous assumiez pleinement la responsabilité de la disponibilité, de la montée en charge et de la sécurité.
Quel fournisseur cloud est le moins cher pour exécuter Ollama ?
Les fournisseurs spécialisés dans les GPU, tels que Lambda Labs (1,10 $/heure pour un A100 40 Go) et Vast.ai (0,34 à 0,54 $/heure pour un RTX 4090), proposent des tarifs nettement inférieurs à ceux d’AWS, de GCP et d’Azure pour une capacité équivalente de mémoire GPU. Lambda Labs offre une meilleure fiabilité et un meilleur support ; Vast.ai propose les prix les plus bas, mais avec une disponibilité variable. Pour les charges de travail en production nécessitant des accords de niveau de service (SLA), les grands fournisseurs cloud offrent des garanties supérieures, moyennant un coût plus élevé.
Quel est le coût d’exécution de Llama 3.3 70B dans le cloud par rapport aux API ?
Llama 3.3 70B nécessite environ 40 Go de VRAM en quantification 4 bits. Une instance Lambda Labs A100 40 Go coûte 1,10 $/heure. Si vous générez 3,4 millions de jetons de sortie par heure (~945 jetons/seconde en continu), vous atteignez le seuil d’équilibre avec le tarif d’API de 0,32 $ par million de jetons. En dessous de ce seuil, les API sont moins coûteuses. Au-dessus, l’instance cloud devient plus avantageuse. La plupart des charges de travail réelles sont ponctuelles plutôt que continues, ce qui favorise la tarification par API, sauf si vous exécutez des traitements par lots de façon ininterrompue.
Ollama peut-il s’étendre sur plusieurs GPU dans le cloud ?
Ollama détecte et utilise automatiquement plusieurs GPU sur une seule instance, mais il exécute un modèle par GPU plutôt que de répartir un seul modèle sur plusieurs GPU (parallélisme tensoriel). Cela signifie qu’une instance 4×A100 peut exécuter quatre instances distinctes de modèles ou traiter efficacement quatre requêtes simultanées, mais ne peut pas charger un modèle unique de 400 Go comme Mistral Large 3, qui dépasse la capacité d’un seul GPU. Pour le parallélisme multi-GPU, privilégiez plutôt vLLM, TensorRT-LLM ou Text Generation Inference.
L’exécution d’Ollama dans le cloud est-elle sécurisée ?
Par défaut, Ollama écoute sur 0.0.0.0:11434, exposant ainsi son API à tout client réseau. Sur des instances cloud dotées d’une adresse IP publique, cela signifie que votre point de terminaison d’inférence est accessible publiquement, à moins que vous ne configuriez des règles de pare-feu, des groupes de sécurité ou un accès VPN. Définissez la variable d’environnement OLLAMA_HOST=127.0.0.1:11434 pour limiter l’accès au localhost, puis utilisez un tunnel SSH, un proxy inverse avec authentification ou un VPN afin de sécuriser l’accès à distance. Les déploiements cloud doivent également implémenter la journalisation des requêtes, la limitation de débit et la validation des entrées afin de prévenir les abus.
