Héberger un LLM en Europe avec Ollama et un GPU : le guide pratique 2026

Faire tourner un modèle de langage en production sans transmettre la moindre donnée hors de l'Union européenne est devenu une exigence concrète pour de nombreuses équipes techniques. La pression du cadre réglementaire, combinée à la portée extraterritoriale du Cloud Act américain, pousse à reconsidérer les architectures d'inférence reposant sur des APIs hébergées outre-Atlantique.

L'écosystème européen a rattrapé son retard. Scaleway propose désormais des instances H100 SXM dans sa région PAR2, à Paris, et Ollama s'est imposé comme un runtime simple pour servir des modèles open-weight comme Llama, Mistral ou Qwen. Cet article détaille comment combiner les deux pour héberger un LLM en Europe, dans des conditions réellement utilisables en production.

Pourquoi héberger son LLM en Europe

Un cadre réglementaire en mouvement

Deux régulations structurent aujourd'hui les choix d'architecture IA. Le RGPD encadre les transferts de données personnelles hors de l'UE, et l'AI Act ajoute une couche d'obligations sur la documentation, la transparence et la gestion des risques.

Le calendrier de l'AI Act est en pleine évolution. Les obligations relatives aux modèles d'IA à usage général (GPAI) sont entrées en application le 2 août 2025. Les obligations de transparence prévues à l'article 50 entrent en vigueur en août 2026. En revanche, l'accord politique sur le Digital Omnibus intervenu en mai 2026 reporte l'application des obligations applicables aux systèmes à haut risque (Annexe III) à décembre 2027. Le mouvement réglementaire est clair, même si certaines échéances bougent : la conformité par défaut devient l'option la plus économique à terme.

S'y ajoute le Cloud Act de 2018 : il autorise les autorités américaines à demander l'accès à des données détenues par un fournisseur de droit américain, y compris quand ces données résident physiquement en Europe. Choisir un hébergeur européen pour héberger un LLM n'est donc pas seulement une question de latence ou de coût : c'est un levier juridique sur le périmètre d'extraterritorialité.

Un écosystème de modèles ouverts mature

Les modèles open-weight couvrent désormais l'essentiel des cas d'usage d'entreprise : synthèse documentaire, génération de code, classification, extraction structurée. Mistral, Llama, Qwen ou DeepSeek sont distribués sous des licences permettant un déploiement auto-hébergé.

Cela rend possible une approche hybride : une API propriétaire pour les tâches non sensibles, un LLM auto-hébergé en Europe pour tout ce qui touche aux données clients, RH ou stratégiques.

Ollama : le runtime à considérer en premier

Ollama est un runtime open source qui simplifie le service de modèles au format GGUF (issu de llama.cpp). Il gère le téléchargement des poids, le chargement sur GPU et expose une API HTTP compatible avec le protocole OpenAI Chat Completions.

Ce qu'Ollama fait bien

• Démarrage rapide : une commande ollama run mistral et le modèle est disponible.
• Détection GPU automatique : Ollama détecte les cartes NVIDIA compatibles CUDA et s'y attache sans configuration.
• Multi-GPU natif : Ollama répartit automatiquement un modèle sur plusieurs cartes quand la VRAM d'une seule ne suffit pas.
• API standardisée : compatible OpenAI, ce qui facilite la migration d'un code existant.
• Quantification intégrée : les modèles GGUF Q4_K_M ou Q5_K_M réduisent fortement les besoins en VRAM avec une perte de qualité limitée.

Ses limites pour la production

Ollama n'est pas optimisé pour servir des dizaines de requêtes parallèles à très haute throughput — des runtimes comme vLLM ou TGI restent plus efficaces sur ce terrain. Ollama excelle sur des charges modérées : assistants internes, pipelines batch, copilotes métier. Pour des SLA élevés, on combine plusieurs réplicas Ollama derrière un load balancer.

Choisir le bon GPU sur Scaleway Paris

Scaleway a étoffé son catalogue GPU sur la région PAR2 et reste à ce jour l'une des références européennes pour l'inférence LLM. Le choix de l'instance dépend essentiellement de la taille du modèle visé et du niveau de quantification accepté. Les tarifs étant ajustés régulièrement (une révision à la hausse a eu lieu début juin 2026), nous renvoyons à la page pricing officielle pour les montants à jour.

L4 : pour les petits modèles et le développement

La L4 (24 Go de VRAM) suffit pour faire tourner un Mistral 7B ou un Llama 3 8B quantifié en Q4. C'est l'instance d'entrée pour valider un POC ou servir un assistant interne à faible trafic.

L40S : le meilleur ratio pour l'inférence en production

La L40S est conçue pour l'inférence générative. Avec 48 Go de VRAM par GPU, elle permet de charger un Llama 3 70B en Q4 sur deux cartes, ou un modèle de taille intermédiaire en single-GPU. C'est l'instance la plus pertinente pour la majorité des déploiements Ollama en production. Scaleway la propose en configurations 1, 2, 4 ou 8 GPUs.

H100 : modèles très lourds et fine-tuning

Les H100 PCIe et H100 SXM offrent 80 Go de VRAM par carte. Elles sont sur-dimensionnées pour de l'inférence Ollama classique mais deviennent pertinentes pour le fine-tuning ou pour servir des modèles non quantifiés à basse latence. L'arrivée des H100 SXM en PAR2, hébergées dans le datacenter DC5 (alimentation en énergie renouvelable certifiée GO), ouvre la voie à des charges de travail européennes auparavant réservées aux hyperscalers américains.

Tableau récapitulatif

• L4 (24 Go) : Mistral 7B, Llama 3 8B Q4. POC et trafic faible.
• L40S (48 Go) : Llama 3 70B Q4 sur 2 GPUs, ou modèles de taille intermédiaire en single-GPU. Production standard.
• H100 PCIe (80 Go) : Llama 70B non quantifié, fine-tuning 7B-13B.
• H100 SXM (80 Go) : très haute throughput, fine-tuning lourd, multi-noeuds.

OVH et Outscale proposent des alternatives crédibles côté souveraineté (certifications HDS, SecNumCloud) mais avec une couverture GPU plus limitée à ce jour. Le choix tient autant à l'écosystème environnant (object storage, réseau privé, certifications) qu'au seul tarif GPU.

Quantification : trouver le bon compromis

La quantification GGUF compresse les poids du modèle pour les faire tenir dans des budgets VRAM plus modestes. Les ordres de grandeur pour un Llama 70B :

• FP16 natif : environ 140 Go de VRAM — impossible sur un seul GPU grand public.
• Q5_K_M : environ 50 Go — tient sur une H100 80 Go.
• Q4_K_M : environ 40 Go — tient sur deux L40S 48 Go en multi-GPU.

La dégradation de qualité induite par Q4_K_M ou Q5_K_M dépend du modèle et de la tâche. Pour les usages conversationnels et les tâches d'extraction, la perte est souvent acceptable. Pour du raisonnement multi-étapes ou de la génération de code complexe, validez votre cas d'usage avec un mini-benchmark sur vos prompts réels avant de figer l'architecture.

Déployer Ollama sur Fransys : le flux concret

Fransys est une plateforme qui orchestre du Kubernetes managé sur infrastructure européenne (Scaleway, OVH, Hetzner, Outscale) avec une interface visuelle. Concrètement, vous construisez votre infrastructure en glissant-déposant des blocs sur un canvas — sans YAML, sans kubectl. Pour héberger Ollama sur un GPU Scaleway, le parcours tient en quelques étapes.

Étape 1 : créer un cluster avec GPU

À la création d'un cluster, l'assistant Fransys demande si vous avez besoin de GPU. En répondant Yes, la carte interactive filtre automatiquement les régions compatibles. Scaleway expose actuellement des nodes GPU à Paris et Varsovie. Vous sélectionnez Paris (PAR2) puis ajoutez un node pool avec une typologie GPU — les options apparaissent préfixées gpu avec les caractéristiques de la carte. L'AutoPilot peut aussi gérer le dimensionnement en mode budget.

Étape 2 : ajouter un bloc Docker pour Ollama

Vous glissez un bloc Docker depuis la sidebar vers le canvas. Au départ, l'interface n'affiche que les paramètres essentiels : source, image, port. Vous choisissez :

• Source : External (l'image vient d'un registry public)
• Image : ollama/ollama
• Port : 11434

Dès que l'image est renseignée, l'interface s'enrichit avec les onglets Resources, Storage, Environment variables et la section Ingress. C'est le principe des blocs Fransys : la configuration se révèle progressivement, pour ne montrer que ce qui a du sens à chaque étape.

Étape 3 : attacher un volume persistant pour les poids

Un Llama 70B Q4 pèse environ 40 Go. Sans volume persistant, Ollama re-téléchargerait les modèles à chaque redéploiement. Dans l'onglet Storage du bloc, vous définissez :

• Une taille adaptée aux modèles que vous prévoyez d'héberger (100 à 200 Go est un bon point de départ si vous voulez en tester plusieurs)
• Le point de montage : /root/.ollama

Le volume survit aux redéploiements, restarts et mises à jour de l'application. À noter que les backups automatiques de volumes sont en cours de développement chez Fransys — pour les modèles, ce n'est pas un sujet (ils sont re-téléchargeables), mais à garder en tête si vous stockez d'autres données sur le même volume.

Étape 4 : configurer les variables Ollama

Dans l'onglet Environment variables, quelques réglages font la différence en production :

• OLLAMA_HOST=0.0.0.0:11434 pour que le service écoute sur le port exposé du conteneur.
• OLLAMA_KEEP_ALIVE=24h (voire -1) pour conserver le modèle chaud en VRAM. La valeur par défaut de 5 minutes est trop courte en production : vous payez le temps de chargement à chaque pic de trafic.
• OLLAMA_NUM_PARALLEL pour calibrer le nombre de requêtes traitées en parallèle selon la VRAM disponible.
• OLLAMA_MAX_LOADED_MODELS si vous servez plusieurs modèles depuis la même instance.

Étape 5 : exposition et SSL

Sur Fransys, l'exposition est automatique. Dès que le bloc est déployé, une URL *.fransysapp.com est attribuée, avec un certificat SSL Let's Encrypt généré et renouvelé automatiquement. Pour un domaine custom (ex. llm.votreentreprise.com), vous l'ajoutez dans la section Ingress, créez un CNAME ou un A record côté DNS, et Fransys s'occupe du certificat. Le load balancer et les health checks sont gérés au niveau du cluster, vous n'avez rien à configurer côté trafic.

Étape 6 : gérer l'authentification

Point important d'honnêteté : Ollama n'embarque pas d'authentification native. Exposer votre instance sur Internet sans contrôle d'accès est à proscrire — vous offririez votre GPU à n'importe qui. Plusieurs approches sont possibles :

• Sidecar applicatif : un second bloc Docker (un middleware d'authentification que vous maintenez) en frontal d'Ollama, qui valide une clé d'API ou un JWT avant de proxifier.
• Auth réseau : restreindre l'accès à un VPN d'entreprise ou à un Zero Trust (Tailscale, Cloudflare Access) pointant sur l'URL Fransys.
• Auth applicative : si l'instance n'est appelée que par votre backend, garder l'URL non publique et faire transiter les appels uniquement depuis votre application elle-même hébergée sur le même cluster Fransys (communication interne).

L'option la plus simple pour un usage interne reste l'auth réseau via Zero Trust. Pour un produit destiné à des utilisateurs externes, le sidecar applicatif est plus robuste.

Industrialiser : scaling et observabilité

Une fois le bloc Ollama en place, l'industrialisation s'appuie sur les briques natives de la plateforme.

Scaling

Le scaling horizontal d'Ollama est possible en augmentant le nombre de réplicas et de nodes GPU, le load balancer Fransys distribuant le trafic automatiquement. Attention : chaque réplica consomme sa propre VRAM, et donc son propre GPU dédié. Le scaling GPU coûte cher — il vaut souvent mieux dimensionner large dès le départ que de multiplier les petites instances.

Observabilité

Les onglets Metrics et Logs du bloc remontent en temps réel la consommation CPU/RAM et les logs Ollama. Pour le suivi GPU détaillé (utilisation, mémoire, température), vous pouvez logger les sorties de nvidia-smi en tâche périodique ou pousser les métriques vers un Prometheus externe.

Coûts

Un GPU loué à l'heure tourne 24/7 : à faible volume, une API managée européenne (Mistral, Albert) reste souvent moins chère. Le seuil de bascule dépend de votre volume d'inférence et de la sensibilité des données. Faites le calcul avant de figer l'architecture.

Limites et compromis à connaître

Auto-héberger un LLM n'est pas magique. Quelques points méritent une honnêteté préalable :

• Coût fixe vs variable : une instance GPU tourne en continu, même la nuit. Le break-even avec une API managée n'est pas immédiat.
• Qualité des modèles ouverts : sur les tâches très complexes (raisonnement long, génération de code expert), les modèles propriétaires conservent une avance sur les open-weight 70B.
• Disponibilité GPU : les H100 peuvent être indisponibles ponctuellement lors de pics de demande. Prévoyez une stratégie de fallback.
• Authentification : Ollama n'en propose pas nativement. C'est à vous d'ajouter une couche de contrôle d'accès.
• Mises à jour : drivers GPU, versions d'Ollama, modèles. Sur Fransys, la gestion des nodes est managée ; le suivi applicatif d'Ollama reste à votre charge.

L'approche pragmatique consiste souvent à mixer : un LLM auto-hébergé pour les données sensibles et les volumes prévisibles, une API européenne pour absorber les pics ou traiter les requêtes non confidentielles.

Conclusion : un stack européen désormais réaliste

Combiner Ollama et un GPU Scaleway en région PAR2 permet aujourd'hui d'héberger un LLM en Europe dans des conditions techniques crédibles, à un coût maîtrisé, et avec une exposition juridique minimale au Cloud Act. La maturité de l'écosystème open-weight rend cette option viable pour la majorité des usages internes d'entreprise.

L'arbitrage clé est moins technique que méthodologique : monter une équipe DevOps pour gérer Kubernetes brut, ou s'appuyer sur une plateforme qui abstrait cette complexité. Fransys correspond à la seconde approche, avec un déploiement par blocs visuels sur des GPU européens, et un focus marqué sur la souveraineté de l'infrastructure sous-jacente.

Testez gratuitement Fransys pour déployer votre instance Ollama sur GPU européen.