Ollama Cloud GPU : exécuter un serveur API distant sécurisé

Ollama Cloud GPU : exécuter un serveur API distant sécurisé

L’exécution d’un serveur Ollama cloud GPU vous donne un contrôle direct sur le modèle, la quantification, l’environnement d’exécution et le cheminement des données. Elle vous confère également une responsabilité opérationnelle qu’une installation sur ordinateur portable masque : l’API Ollama locale n’est pas une frontière d’authentification exposée au public. Une configuration distante sûre maintient Ollama sur un port de bouclage privé et place TLS ainsi que l’authentification de l’appelant au niveau d’un proxy périphérique.

Ce guide présente un déploiement pratique NVIDIA/Docker pour un serveur Ollama cloud GPU, une périphérie HTTPS Caddy qui accepte un jeton Bearer de type OpenAI, ainsi qu’une configuration de client distant. Il s’adresse aux développeurs indépendants et aux petites équipes IA qui souhaitent exécuter un modèle à poids ouverts sur une capacité GPU louée sans publier le port 11434 sur Internet.

En bref : exécutez Ollama avec son port hôte lié à 127.0.0.1, bloquez l’accès public au port 11434 dans le pare-feu cloud et n’exposez qu’un proxy inverse HTTPS sur les ports 80/443. Configurez ce proxy pour qu’il valide un jeton avant de transmettre le trafic à Ollama.

Ollama documente 127.0.0.1:11434 comme liaison par défaut et indique que les requêtes API d’un serveur local ne nécessitent pas d’autorisation. C’est pratique pour le développement local, mais cela signifie qu’un point de terminaison accessible à distance sans protection constitue une mauvaise frontière de sécurité. Gardez à portée de main la FAQ d’Ollama et l’introduction à l’API pendant votre déploiement.

Ce que protège cette architecture Ollama cloud GPU

L’architecture comporte quatre frontières, chacune ayant un rôle distinct :

Client distant / SDK OpenAI
        |
        | HTTPS + jeton Bearer
        v
Proxy périphérique public (Caddy, ports 80/443 uniquement)
        |
        | HTTP localhost
        v
API Ollama (127.0.0.1:11434)
        |
        v
Environnement d’exécution GPU et volume des modèles

Le proxy périphérique est le seul composant qui accepte le trafic Internet. Ollama reste accessible uniquement depuis le même hôte. Cela évite qu’une erreur de pare-feu cloud, un mappage Docker accidentellement ouvert ou un appelant non authentifié ne se transforme en accès direct à votre serveur de modèles.

Pour un système de production comptant plusieurs utilisateurs, utilisez un réseau superposé privé ou un proxy sensible à l’identité avec des identités individuelles et une possibilité de révocation. L’exemple de jeton Bearer unique ci-dessous constitue un point de départ pratique pour serveur à serveur, et non un remplacement du SSO, des pistes d’audit par utilisateur, des limites de débit ou de l’application de politiques.

Avant de louer un GPU : dimensionnez la charge de travail, pas le téléchargement

Un Ollama cloud GPU est un choix judicieux lorsque vous avez besoin de contrôler les fichiers de modèle, une quantification spécifique, un environnement d’exécution privé ou l’utilisation soutenue d’une famille de modèles. Ce n’est pas automatiquement le choix le moins coûteux pour un trafic irrégulier ou un produit qui change fréquemment de modèles.

Commencez par la balise de modèle réelle, la quantification, la fenêtre de contexte et le nombre de requêtes simultanées. Les poids du modèle ne représentent qu’une partie du budget mémoire : le contexte et les requêtes parallèles consomment de la VRAM supplémentaire. La documentation d’Ollama indique que le traitement de requêtes parallèles augmente l’allocation effective de contexte, et la sortie de ollama ps montre si un modèle est entièrement sur GPU, entièrement sur CPU ou réparti entre les deux. Consultez les guides sur les exigences VRAM des modèles Ollama 70B et les exigences de mémoire GPU pour les LLM avant de vous engager sur une configuration GPU.

Comment choisir un cloud GPU abordable pour Ollama en 2026

La requête « best cheap gpu cloud for ollama 2026 » n’a pas de réponse unique et durable. Un GPU bon marché à l’heure qui impose une décharge vers le CPU, manque de marge de contexte ou reste inactif la majeure partie de la journée n’est pas bon marché à l’usage. Comparez les candidats avec la même balise de modèle et le même ensemble de prompts, puis consignez :

• temps GPU facturé, stockage, trafic sortant et temps de configuration ;
• temps de chargement du modèle et résidence sur le GPU selon ollama ps ;
• temps jusqu’au premier jeton, latence de bout en bout et requêtes échouées ;
• fenêtre de contexte et concurrence réellement prises en charge ; et
• coût par sortie acceptée, et pas uniquement coût par heure de GPU.

Utilisez le comparatif des clouds GPU de Flatkey pour évaluer l’adéquation des fournisseurs, ainsi que son guide des prix de location de GPU afin de ne pas négliger les postes de coût liés à l’instance elle-même. Réalisez un court projet pilote reproductible avant de réserver de la capacité.

Étape 1 : préparer l’hôte NVIDIA

Ce guide suppose un hôte GPU Linux pris en charge, Docker, un pilote NVIDIA et une installation de NVIDIA Container Toolkit. Vérifiez d’abord que l’hôte détecte son GPU :

nvidia-smi

Configurez ensuite l’environnement d’exécution NVIDIA de Docker et vérifiez qu’un conteneur peut voir le même périphérique :

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Exemple d’image CUDA ; utilisez un tag compatible avec le pilote et le système d’exploitation de votre hôte.
docker run --rm --gpus all \
  nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

La documentation Docker d’Ollama utilise NVIDIA Container Toolkit et --gpus=all pour les conteneurs reposant sur NVIDIA. Si cette commande de validation échoue, arrêtez-vous ici et corrigez la couche pilote/environnement d’exécution ; le dépannage du modèle ne ferait que masquer la cause racine.

Avant de démarrer le conteneur, configurez le pare-feu de votre cloud ou votre groupe de sécurité :

1. Autorisez SSH uniquement depuis une plage source approuvée, un bastion ou un réseau privé.
2. Autorisez TCP 80 et 443 uniquement si ce serveur utilisera un nom d’hôte HTTPS public.
3. N’autorisez pas TCP 11434 depuis l’internet public.
4. Si vous utilisez un pare-feu hôte tel qu’UFW, alignez ses règles sur le pare-feu cloud au lieu de vous appuyer sur une seule couche.

Étape 2 : exécuter Ollama en privé sur l’hôte GPU

Utilisez un volume nommé afin que les fichiers de modèle survivent à la recréation d’un conteneur. L’adresse de bouclage à gauche de -p est intentionnelle : elle permet à Caddy, sur la même machine, d’atteindre Ollama tout en empêchant une connexion externe directe au service.

docker pull ollama/ollama:<verified-ollama-tag>

docker run -d \
  --name ollama \
  --restart unless-stopped \
  --gpus all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama:<verified-ollama-tag>

Remplacez <verified-ollama-tag> par le tag de version testé par votre équipe ; ne faites pas évoluer silencieusement un service de production en récupérant une image non examinée lors du redémarrage. Ollama prend également en charge une installation Linux native et un service systemd, mais la même limite s’applique : conservez la liaison de bouclage et placez l’accès distant derrière un proxy authentifié. Le guide Linux officiel documente à la fois le flux de travail du service et son mécanisme de surcharge par variables d’environnement.

Téléchargez un petit modèle de test adapté au GPU sélectionné. Cet exemple utilise un tag actuel issu des exemples de compatibilité OpenAI d’Ollama ; remplacez-le par le modèle exact et la quantification que vous prévoyez de servir.

docker exec ollama ollama pull qwen3:8b

curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "Répondez avec un contrôle de santé GPU en trois mots."}],
    "stream": false
  }'

docker exec ollama ollama ps

ollama ps constitue une vérification d’acceptation utile pour un déploiement Ollama cloud GPU. Une indication de processeur 100% GPU signifie que le modèle chargé est entièrement sur le GPU ; une répartition CPU/GPU peut convenir à un test, mais elle signale qu’il faut mesurer le compromis entre latence et mémoire avant la production.

Étape 3 : ajouter un point d’entrée d’API HTTPS avec un jeton Bearer

Ollama peut exposer son API via un proxy et fournit à la fois son interface native /api et une interface locale compatible OpenAI /v1. Ses exemples de client OpenAI local utilisent une valeur de clé API qu’Ollama ignore, ce qui explique précisément pourquoi le proxy ci-dessous effectue la vérification d’autorisation avant de transmettre le trafic. La documentation de compatibilité OpenAI d’Ollama indique également clairement que cette compatibilité est partielle ; prévoyez donc un véritable test d’intégration plutôt que de faire une supposition générale.

Ce modèle Caddy permet à un client de type OpenAI d’utiliser Authorization: Bearer <token>. Caddy valide cet en-tête, le supprime avant que la requête n’atteigne le service local, puis transmet la requête via la boucle locale.

Générez d’abord un jeton à entropie élevée et enregistrez-le dans le gestionnaire de secrets de votre équipe. Ne le placez pas dans le contrôle de code source ni dans un historique de shell que vous ne maîtrisez pas.

openssl rand -hex 32

Créez une surcharge systemd pour Caddy et définissez la valeur générée comme OLLAMA_API_TOKEN :

# sudo systemctl edit caddy
[Service]
Environment="OLLAMA_API_TOKEN=replace-with-your-secret-manager-value"

Configurez ensuite /etc/caddy/Caddyfile avec un nom d’hôte dont le DNS pointe vers le serveur :

ollama.example.com {
    @authorized {
        header Authorization "Bearer {$OLLAMA_API_TOKEN}"
    }

    handle @authorized {
        reverse_proxy 127.0.0.1:11434 {
            # The edge checked this header; Ollama does not need the token.
            header_up -Authorization
        }
    }

    handle {
        respond "Unauthorized" 401
    }
}

Utilisez un véritable nom DNS à la place de ollama.example.com. Caddy traite une adresse de site de domaine comme un site HTTPS avec un certificat géré ; assurez-vous que le DNS et les ports entrants prévus sont prêts avant de le recharger. Le sélecteur de requêtes Caddy, les blocs handle mutuellement exclusifs et les contrôles d’en-tête du proxy inverse documentent les directives utilisées ci-dessus.

Validez et rechargez la configuration :

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl daemon-reload
sudo systemctl reload caddy

Testez les deux côtés de la frontière. La première requête doit réussir depuis l’hôte. La seconde doit réussir via TLS uniquement lorsque le jeton est correct. Une troisième requête sans celui-ci doit renvoyer 401.

# Host-local health check
curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Remote request through the edge
curl -sS https://ollama.example.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Expected: HTTP 401
curl -i https://ollama.example.com/api/chat

Ne remplacez pas l’authentification par jeton par une authentification basique pour ce modèle de client précis sans modifier la conception du client. HTTP Basic et les SDK OpenAI utilisent tous deux l’en-tête Authorization. La périphérie à jeton porteur ci-dessus préserve la structure habituelle du SDK OpenAI et maintient le point de terminaison Ollama local privé.

Étape 4 : appeler l’API Ollama distante depuis un client OpenAI

Ollama documente http://localhost:11434/v1 comme son URL de base locale compatible avec OpenAI. Une fois la périphérie HTTPS en place, modifiez uniquement l’hôte et utilisez le jeton du proxy comme clé API du client :

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://ollama.example.com/v1/",
    api_key=os.environ["OLLAMA_API_TOKEN"],
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
        {"role": "user", "content": "Give me a concise deployment checklist."}
    ],
)

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

Il s’agit d’une API distante Ollama cloud GPU, mais elle ne remplace pas automatiquement toutes les fonctionnalités d’OpenAI. Avant de faire passer du trafic en production, testez les points de terminaison et les comportements exacts utilisés par votre application : streaming, appels d’outils, sorties structurées, embeddings, entrées visuelles, gestion des erreurs, limites de contexte et délais d’expiration du client. Le modèle lui-même détermine également ce qui est pertinent ou pris en charge.

Étape 5 : ajuster délibérément la concurrence et la résidence des modèles

Évitez d’augmenter le parallélisme parce qu’un serveur est calme lors d’un unique test curl. Ollama documente une fenêtre de contexte par défaut de 4 096 jetons, un paramètre de file d’attente des requêtes et une gestion des modèles parallèles dépendante de la mémoire. Chaque requête parallèle ajoutée augmente l’allocation effective de contexte ; ainsi, une Ollama cloud GPU qui peut traiter une requête peut néanmoins échouer sous trafic simultané.

Suivez cet ordre de déploiement contrôlé :

1. Chargez un modèle avec la quantification prévue et exécutez un ensemble d’invites représentatif.
2. Enregistrez la VRAM, la latence et la résidence GPU avec nvidia-smi et ollama ps.
3. Augmentez la longueur du contexte ou le nombre de requêtes parallèles une à la fois.
4. Définissez une politique explicite de surcharge : mettre en file d’attente, rejeter ou acheminer vers une solution de secours.
5. Répétez après chaque modification du modèle, du pilote, de l’environnement d’exécution ou de la fenêtre de contexte.

La FAQ d’Ollama documente OLLAMA_CONTEXT_LENGTH, OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE et OLLAMA_KEEP_ALIVE. Elle indique également que les réponses 503 peuvent signaler une file d’attente surchargée. Conservez un runbook pour ces signaux au lieu de les traiter comme des échecs d’API aléatoires.

Pour une architecture plus générale de serveur auto-hébergé, consultez comment créer un serveur d’inférence compatible avec OpenAI. Ce guide couvre des considérations plus larges concernant l’edge, le repli et les tests d’acceptation ; cet article reste centré sur un flux de travail Ollama distant sécurisé.

Quand ne pas exécuter un serveur GPU cloud Ollama

L’auto-hébergement est utile lorsque l’infrastructure elle-même fait partie des exigences du produit. Il est moins pertinent lorsque l’objectif est simplement d’appeler le meilleur modèle disponible pour une charge de travail variable. Envisagez une API de modèle gérée ou un repli hybride lorsque :

• le trafic est irrégulier et le GPU restera inactif ;
• vous avez besoin de plusieurs familles de modèles ou de changements fréquents de modèles ;
• votre équipe ne peut pas maintenir les pilotes, les volumes de modèles, TLS, la rotation des jetons, l’observabilité et la réponse aux incidents ; ou
• le coût par sortie acceptée du parcours GPU est plus élevé une fois les nouvelles tentatives et le temps des opérateurs inclus.

Flatkey peut servir de solution de comparaison ou de repli : une clé et un solde pour plus de 300 modèles officiels et plus de 1 000 outils facturés à l’appel. Conservez une interface client compatible avec OpenAI et comparez le parcours auto-hébergé à une alternative gérée en utilisant les mêmes prompts, critères de réussite et politique de délai d’expiration.

Liste de contrôle de production pour un GPU cloud Ollama

• [ ] Le GPU est visible à la fois via nvidia-smi et un test GPU Docker.
• [ ] Le port Docker d’Ollama est mappé uniquement sur 127.0.0.1:11434.
• [ ] Le port 11434 n’est pas public dans le pare-feu cloud ni dans le pare-feu de l’hôte.
• [ ] Le proxy sert HTTPS sur un véritable nom d’hôte et rejette les requêtes sans jeton.
• [ ] Le jeton bearer est stocké hors de la base de code et dispose d’un processus de rotation documenté.
• [ ] Une requête distante /api/chat réussit avec le jeton et échoue sans celui-ci.
• [ ] Un test distant /v1/chat/completions réussit depuis le SDK réel utilisé par votre application.
• [ ] Le tag exact du modèle, la quantification, la fenêtre de contexte et l’objectif de concurrence sont documentés.
• [ ] ollama ps, la télémétrie GPU, les journaux du proxy et les taux de 5xx font partie du runbook.
• [ ] Vous avez testé un scénario de surcharge, de redémarrage et de rotation de jeton.
• [ ] Vous avez comparé le parcours Ollama cloud GPU avec une référence d’API gérée lorsque la flexibilité des modèles ou la disponibilité est importante.

Foire aux questions

Ollama authentifie-t-il lui-même une API distante ?

Ne vous fiez pas à l’API locale pour l’authentification distante. Les exemples de serveur local d’Ollama omettent l’autorisation ou utilisent une valeur de clé API que le serveur local ignore. Gardez le service privé et exigez une authentification au niveau d’un proxy TLS, d’une frontière de réseau privé ou d’une passerelle tenant compte de l’identité.

Puis-je utiliser un SDK OpenAI avec un GPU cloud Ollama ?

Oui, Ollama documente une URL de base locale /v1 compatible avec OpenAI ainsi que des exemples de clients courants. Pointez le SDK vers le chemin /v1/ de votre proxy HTTPS et laissez ce proxy valider le jeton bearer. Testez les points de terminaison exacts que vous utilisez, car la compatibilité constitue un sous-ensemble et non une garantie inconditionnelle.

Quel est le meilleur cloud GPU économique pour Ollama en 2026 ?

Le meilleur cloud GPU économique pour Ollama en 2026 est celui qui convient à votre véritable modèle, contexte et niveau de concurrence sans temps d’inactivité caché ni déport vers le CPU. Exécutez le même benchmark court sur quelques candidats et comparez le coût par sortie acceptée, et non le tarif horaire affiché par un fournisseur.

Pourquoi mon conteneur Ollama s’exécute-t-il sur le CPU plutôt que sur le GPU ?

Commencez par vérifier l’hôte avec nvidia-smi, puis confirmez que Docker peut voir le GPU après la configuration de NVIDIA Container Toolkit. Enfin, examinez ollama ps : un modèle peut être partiellement ou entièrement sur le CPU s’il ne tient pas dans la mémoire GPU disponible.

Dois-je exposer directement le port 11434 pour éviter un saut de proxy ?

Non. Le petit saut de proxy local est le bon compromis pour TLS, l’authentification des appelants, la rotation des secrets et une frontière publique explicite. Exposer un simple serveur de modèle local transforme un raccourci d’infrastructure en un risque inutile de sécurité et d’abus.

Recommandation finale

La méthode fiable pour exécuter un serveur Ollama cloud GPU est simple : valider l’environnement d’exécution GPU, lier Ollama à l’interface de bouclage, utiliser un proxy HTTPS avec vérification de jeton porteur, et tester les appels natifs /api et compatibles OpenAI /v1 depuis le client que vous allez réellement livrer.

Vous bénéficiez ainsi du contrôle d’un modèle auto-hébergé sans transformer un point de terminaison local non authentifié en API publique. Évaluez l’adéquation du modèle, le contexte, la concurrence et le coût des sorties acceptées avant d’étendre le serveur — et conservez une référence d’API gérée pour les charges de travail où l’exploitation de votre propre GPU ajoute plus de complexité que de valeur.

Sources

• Installation d’Ollama sous Linux et recommandations systemd
• Déploiement d’Ollama avec Docker et GPU NVIDIA
• FAQ Ollama : exposition réseau, résidence GPU, contexte, file d’attente et concurrence
• Introduction à l’API Ollama et URL de base locales
• Compatibilité d’Ollama avec OpenAI
• Correspondances d’en-têtes Caddy, blocs handle et configuration du proxy inverse