En 2026, déployer des LLM en production sans dépendre d'API propriétaires est devenu une priorité pour de nombreuses entreprises. Entre les coûts d'API qui explosent à l'échelle (500-5000€/mois pour une utilisation intensive), les problèmes de latence réseau, et les contraintes de confidentialité des données, les modèles open-source auto-hébergés représentent une alternative crédible.
Ollama simplifie drastiquement le déploiement de LLM locaux : une seule commande pour installer Llama 3.3 70B, Mistral Large, CodeLlama ou DeepSeek. Open WebUI fournit une interface ChatGPT-like qui tourne sur votre infrastructure. Ensemble, ils permettent de passer de 1500€/mois d'API calls à 80€/mois de serveur cloud — sans sacrifier la qualité pour 80% des cas d'usage.
Pourquoi Ollama + LLM Open-Source en 2026 ?
Analyse de Coûts : API Propriétaires vs Auto-Hébergement
Prenons un cas réel : startup SaaS avec 500 utilisateurs actifs générant 1M tokens/jour (génération de contenu, chatbot support, résumés). Comparons les coûts sur 12 mois.
| Solution | Infra/mois | Tokens/mois | Total/mois | Total/an |
|---|---|---|---|---|
| OpenAI GPT-4 Turbo | 0€ | 3000€ (30M tokens) | 3000€ | 36 000€ |
| Claude Sonnet 4.5 | 0€ | 900€ (30M tokens) | 900€ | 10 800€ |
| Ollama + Llama 3.3 70B (GPU cloud) | 180€ (L4 24GB) | 0€ | 180€ | 2 160€ |
| Ollama + Llama 3.3 70B (serveur dédié) | 89€ (Hetzner GPU) | 0€ | 89€ | 1 068€ |
| Ollama + Mistral 7B (CPU only) | 29€ (VPS 16 vCPU) | 0€ | 29€ | 348€ |
Économies réalisables :
- -94% de coûts en passant de Claude API à Ollama + Llama 3.3 sur serveur dédié (10 800€ → 1 068€/an)
- -99% de coûts en passant de GPT-4 à Ollama + Mistral 7B sur VPS (36 000€ → 348€/an)
- ROI immédiat : amortissement en 1 mois pour volume > 100k tokens/jour
- Scalabilité linéaire : 10x plus d'utilisateurs = +1 serveur GPU (180€/mois), pas +900€/mois en API calls
Cas d'Usage Idéaux pour Ollama
| Cas d'usage | Modèle recommandé | Justification |
|---|---|---|
| Chatbot support client interne | Llama 3.3 8B | Données sensibles, pas de latence critique, volume élevé |
| Génération de documentation technique | CodeLlama 34B | Spécialisé code, qualité > latence, offline OK |
| Résumés automatiques de réunions | Mistral 7B | Tâche simple, volume très élevé, coût critique |
| Assistant de code dans IDE | DeepSeek Coder 33B | Meilleure qualité code, doit être local (latence) |
| Analyse de contrats (données confidentielles) | Llama 3.3 70B | RGPD strict, données ultra-sensibles, qualité max |
| Classification de tickets support | Mistral 7B (quantized Q4) | Tâche simple, latence <500ms nécessaire |
Installation Ollama : macOS, Linux, Docker
Installation macOS (Apple Silicon M1/M2/M3)
Ollama exploite le GPU intégré des puces Apple Silicon via Metal. Un Mac M3 Max 128GB peut exécuter Llama 3.3 70B à ~15 tokens/s.
# Installation en une commande
curl -fsSL https://ollama.com/install.sh | sh
# Vérifier l'installation
ollama --version
# ollama version 0.3.14
# Lancer le serveur (démarre automatiquement en arrière-plan)
ollama serve
# Télécharger et exécuter Llama 3.3 70B
ollama run llama3.3:70b
# Première exécution : téléchargement du modèle (~40GB)
# Ensuite : conversation interactive démarre
>>> Explique-moi le RAG en 3 phrases simples.
# Test rapide de performance
>>> /bye # Quitter la conversation
# Lister les modèles téléchargés
ollama list
# NAME SIZE MODIFIED
# llama3.3:70b 40GB 2 minutes ago
Résultat attendu : Sur un Mac M3 Max, première réponse en ~8s, tokens suivants à ~15 tok/s. Utilisation RAM : ~50GB pour le modèle 70B.
Installation Linux (Ubuntu/Debian)
# Installation
curl -fsSL https://ollama.com/install.sh | sh
# Si vous avez un GPU NVIDIA, installer les drivers CUDA
# Vérifier la détection GPU
nvidia-smi
# Lancer Ollama
ollama serve
# Dans un autre terminal : télécharger plusieurs modèles
ollama pull llama3.3:70b # 40GB - meilleure qualité
ollama pull llama3.3:8b # 4.7GB - plus rapide
ollama pull mistral:7b # 4.1GB - multilingue excellent
ollama pull codellama:34b # 19GB - spécialisé code
# Test de latence comparative
time ollama run llama3.3:8b "Résume Docker en 2 phrases"
# real 0m2.341s (~15 tokens/s sur RTX 4090)
time ollama run llama3.3:70b "Résume Docker en 2 phrases"
# real 0m5.127s (~8 tokens/s sur RTX 4090)
# Lancer Ollama comme service systemd (production)
sudo systemctl enable ollama
sudo systemctl start ollama
sudo systemctl status ollama
Installation Docker (Production Multi-Plateforme)
# docker-compose.yml pour Ollama + Open WebUI
version: '3.8'
services:
# Ollama : serveur de modèles
ollama:
image: ollama/ollama:latest
container_name: ollama
volumes:
- ollama_data:/root/.ollama # Stockage des modèles
ports:
- "11434:11434"
environment:
- OLLAMA_HOST=0.0.0.0
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu] # Nécessite nvidia-docker
restart: unless-stopped
# Open WebUI : interface ChatGPT-like
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
- WEBUI_AUTH=false # Ou true avec gestion users
volumes:
- open_webui_data:/app/backend/data
depends_on:
- ollama
restart: unless-stopped
volumes:
ollama_data:
open_webui_data:
# Démarrer les services
docker-compose up -d
# Attendre que Ollama soit prêt (~10s)
sleep 10
# Télécharger les modèles dans le container
docker exec -it ollama ollama pull llama3.3:70b
docker exec -it ollama ollama pull mistral:7b
docker exec -it ollama ollama pull codellama:34b
# Vérifier les logs
docker-compose logs -f ollama
# Accéder à Open WebUI
# Ouvrir http://localhost:3000 dans le navigateur
# Interface prête, modèles disponibles dans le dropdown
# Monitoring GPU (si NVIDIA)
watch -n 1 nvidia-smi
# Attendu : utilisation GPU à ~90% pendant inférence
Comparaison de Modèles : Llama, Mistral, CodeLlama, DeepSeek
| Modèle | Taille | RAM Requise | Vitesse (RTX 4090) | Qualité | Cas d'usage |
|---|---|---|---|---|---|
| Llama 3.3 70B | 40GB | 48GB | 8-12 tok/s | ⭐⭐⭐⭐⭐ | Usage général, qualité max, similaire GPT-4 Turbo |
| Llama 3.3 8B | 4.7GB | 8GB | 35-50 tok/s | ⭐⭐⭐⭐ | Latence critique, chatbots simples, CPU viable |
| Mistral 7B | 4.1GB | 8GB | 40-60 tok/s | ⭐⭐⭐⭐ | Multilingue excellent, coût minimal, CPU OK |
| Mistral Large 2 | 123GB | 140GB | 4-6 tok/s | ⭐⭐⭐⭐⭐ | Multilingue top-tier, concurrence GPT-4 |
| CodeLlama 34B | 19GB | 24GB | 12-18 tok/s | ⭐⭐⭐⭐ | Génération de code, documentation technique |
| DeepSeek Coder 33B | 18GB | 24GB | 14-20 tok/s | ⭐⭐⭐⭐⭐ | Meilleur pour code Python/JS/TS, meilleur que CodeLlama |
| Qwen2.5 72B | 41GB | 48GB | 7-11 tok/s | ⭐⭐⭐⭐⭐ | Multilingue (chinois excellent), maths, raisonnement |
Benchmarks de Qualité (Tests MMLU, HumanEval, MT-Bench)
Scores sur benchmarks académiques (plus le score est élevé, meilleur est le modèle). MMLU = connaissances générales, HumanEval = génération de code, MT-Bench = conversations multi-tours.
| Modèle | MMLU | HumanEval | MT-Bench | Équivalent API |
|---|---|---|---|---|
| Llama 3.3 70B | 82.0% | 69.5% | 8.2/10 | ≈ GPT-4 Turbo, Claude Sonnet 3.5 |
| DeepSeek Coder 33B | 66.4% | 78.6% | 7.1/10 | ≈ GPT-3.5 Turbo (code meilleur) |
| Mistral 7B | 62.5% | 40.2% | 6.8/10 | ≈ GPT-3.5 Turbo |
| Llama 3.3 8B | 68.4% | 62.2% | 7.4/10 | ≈ GPT-3.5 Turbo |
| Référence : GPT-4 Turbo | 86.4% | 67.0% | 8.9/10 | — |
| Référence : Claude Opus 4.5 | 88.7% | 84.9% | 9.0/10 | — |
Conclusion des benchmarks : Llama 3.3 70B atteint 95% de la qualité de GPT-4 Turbo sur la plupart des tâches. Pour 80% des cas d'usage production, c'est largement suffisant — surtout quand ça coûte 0€ en tokens vs 3000€/mois.
Intégrations : Python, REST API, Compatibilité OpenAI
Intégration Python Native (ollama-python)
# Installation
pip install ollama
# Exemple 1 : Chat completion simple
import ollama
response = ollama.chat(
model='llama3.3:70b',
messages=[
{
'role': 'system',
'content': 'Tu es un assistant technique expert en cloud computing.'
},
{
'role': 'user',
'content': 'Explique la différence entre Kubernetes et Docker Swarm en 3 points.'
}
]
)
print(response['message']['content'])
# Output attendu :
# 1. **Complexité** : Kubernetes offre plus de fonctionnalités (auto-scaling,
# rolling updates, service mesh) mais nécessite plus de configuration.
# Docker Swarm est plus simple à démarrer.
# 2. **Écosystème** : Kubernetes domine l'industrie (CNCF, support cloud natif),
# Docker Swarm est en déclin.
# 3. **Scale** : Kubernetes scale à des milliers de nodes, Swarm convient
# pour clusters <100 nodes.
# Exemple 2 : Streaming (réponses token par token)
import ollama
stream = ollama.chat(
model='llama3.3:8b',
messages=[{'role': 'user', 'content': 'Écris un haiku sur le DevOps'}],
stream=True
)
for chunk in stream:
print(chunk['message']['content'], end='', flush=True)
# Output (progressif) :
# Code déployé tard
# Pipeline qui tourne sans fin
# Café, logs, succès
print() # Newline finale
# Exemple 3 : Génération de code avec métriques
import ollama
import time
start = time.time()
response = ollama.chat(
model='codellama:34b',
messages=[
{
'role': 'user',
'content': """Écris une fonction Python qui :
1. Lit un fichier CSV
2. Filtre les lignes où colonne 'status' == 'active'
3. Groupe par 'category' et compte les occurrences
4. Retourne un dict {category: count}
Utilise pandas. Inclus la gestion d'erreurs."""
}
],
options={
'temperature': 0.2, # Moins de créativité pour code
'top_p': 0.9
}
)
elapsed = time.time() - start
code = response['message']['content']
print(code)
print(f"
⏱️ Généré en {elapsed:.2f}s")
print(f"📊 {len(code.split())} mots, {response['eval_count']} tokens")
# Output attendu :
# import pandas as pd
# from typing import Dict
#
# def count_active_by_category(filepath: str) -> Dict[str, int]:
# """
# Compte les entrées actives par catégorie depuis un CSV.
# ...
# """
# try:
# df = pd.read_csv(filepath)
# active_df = df[df['status'] == 'active']
# counts = active_df.groupby('category').size().to_dict()
# return counts
# except FileNotFoundError:
# raise ValueError(f"File not found: {filepath}")
# except KeyError as e:
# raise ValueError(f"Missing column: {e}")
#
# ⏱️ Généré en 8.3s
# 📊 142 mots, 487 tokens
API REST : Compatibilité OpenAI (drop-in replacement)
# Ollama expose une API compatible OpenAI à /v1/chat/completions
# Vous pouvez utiliser le SDK OpenAI directement !
from openai import OpenAI
# Pointer vers Ollama au lieu d'OpenAI
client = OpenAI(
base_url='http://localhost:11434/v1',
api_key='ollama' # Requis par le SDK mais non utilisé par Ollama
)
# Code IDENTIQUE à OpenAI API
response = client.chat.completions.create(
model='llama3.3:70b',
messages=[
{
'role': 'system',
'content': 'Tu es un expert en sécurité web.'
},
{
'role': 'user',
'content': 'Explique XSS et donne un exemple d\'exploit + mitigation.'
}
],
temperature=0.7,
max_tokens=500
)
print(response.choices[0].message.content)
# Migration d'OpenAI vers Ollama = changer 2 lignes (base_url + model)
# Tout le reste du code reste identique !
# Exemple : appel REST direct avec curl
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama3.3:8b",
"messages": [
{
"role": "user",
"content": "Quelle est la capitale de la France ?"
}
],
"temperature": 0.1
}'
# Réponse JSON (format OpenAI)
{
"id": "chatcmpl-xyz",
"object": "chat.completion",
"created": 1735689600,
"model": "llama3.3:8b",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "La capitale de la France est Paris."
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 18,
"completion_tokens": 9,
"total_tokens": 27
}
}
Intégration LangChain (RAG, Agents, Tool Use)
# Installation
pip install langchain langchain-community ollama
# RAG avec Ollama : système Q&A sur documentation
from langchain_community.llms import Ollama
from langchain.embeddings import OllamaEmbeddings
from langchain.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.chains import RetrievalQA
from langchain.document_loaders import TextLoader
# 1. Charger la documentation
loader = TextLoader("docs/kubernetes-guide.txt")
documents = loader.load()
# 2. Splitter en chunks
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50
)
texts = text_splitter.split_documents(documents)
# 3. Créer les embeddings (modèle nomic-embed-text optimisé pour RAG)
embeddings = OllamaEmbeddings(model="nomic-embed-text")
# 4. Indexer dans ChromaDB
vectorstore = Chroma.from_documents(
documents=texts,
embedding=embeddings,
persist_directory="./chroma_db"
)
# 5. Créer la chaîne RAG
llm = Ollama(model="llama3.3:70b", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
return_source_documents=True
)
# 6. Poser des questions
result = qa_chain({"query": "Comment configurer l'auto-scaling dans Kubernetes ?"})
print(result['result'])
print(f"
Sources : {len(result['source_documents'])} documents utilisés")
# Output :
# Pour configurer l'auto-scaling dans Kubernetes, utilisez un
# HorizontalPodAutoscaler (HPA). Définissez les métriques cibles
# (CPU, mémoire ou custom metrics) et les limites min/max de replicas.
# Exemple : kubectl autoscale deployment nginx --cpu-percent=50 --min=2 --max=10
#
# Sources : 3 documents utilisés
Déploiement Production : Docker Compose, GPU, Load Balancing
Architecture Production Recommandée
# docker-compose.production.yml
version: '3.8'
services:
# NGINX : load balancer pour distribuer sur plusieurs workers Ollama
nginx:
image: nginx:alpine
ports:
- "80:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
depends_on:
- ollama-worker-1
- ollama-worker-2
restart: unless-stopped
# Worker Ollama 1 (GPU 0)
ollama-worker-1:
image: ollama/ollama:latest
container_name: ollama-worker-1
environment:
- OLLAMA_HOST=0.0.0.0:11434
- CUDA_VISIBLE_DEVICES=0 # GPU 0
volumes:
- ollama_models:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
device_ids: ['0']
capabilities: [gpu]
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
interval: 30s
timeout: 10s
retries: 3
restart: unless-stopped
# Worker Ollama 2 (GPU 1)
ollama-worker-2:
image: ollama/ollama:latest
container_name: ollama-worker-2
environment:
- OLLAMA_HOST=0.0.0.0:11434
- CUDA_VISIBLE_DEVICES=1 # GPU 1
volumes:
- ollama_models:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
device_ids: ['1']
capabilities: [gpu]
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
interval: 30s
timeout: 10s
retries: 3
restart: unless-stopped
# Open WebUI : interface utilisateur
open-webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://nginx:80
- WEBUI_AUTH=true
- WEBUI_JWT_SECRET_KEY=${JWT_SECRET}
volumes:
- open_webui_data:/app/backend/data
depends_on:
- nginx
restart: unless-stopped
# Prometheus : monitoring métriques
prometheus:
image: prom/prometheus:latest
ports:
- "9090:9090"
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
restart: unless-stopped
# Grafana : dashboards
grafana:
image: grafana/grafana:latest
ports:
- "3001:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
volumes:
- grafana_data:/var/lib/grafana
- ./grafana/dashboards:/etc/grafana/provisioning/dashboards:ro
depends_on:
- prometheus
restart: unless-stopped
volumes:
ollama_models:
open_webui_data:
prometheus_data:
grafana_data:
# nginx.conf : load balancing round-robin entre workers
upstream ollama_backend {
least_conn; # Distribue vers le worker le moins chargé
server ollama-worker-1:11434 max_fails=3 fail_timeout=30s;
server ollama-worker-2:11434 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://ollama_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# Timeouts élevés pour LLM (génération peut prendre 30s+)
proxy_connect_timeout 60s;
proxy_send_timeout 120s;
proxy_read_timeout 120s;
# Streaming support
proxy_buffering off;
proxy_cache off;
}
# Healthcheck endpoint
location /health {
access_log off;
return 200 "OK\n";
add_header Content-Type text/plain;
}
}
Optimisations GPU : Quantization, Batching, Model Caching
# Télécharger plusieurs versions quantifiées du même modèle
# Q8 : précision maximale (~95% de la qualité FP16), 50% de RAM en moins
# Q4 : précision réduite (~90% qualité), 75% de RAM en moins
# Q2 : très compressé (~80% qualité), 85% de RAM en moins
ollama pull llama3.3:70b # FP16 : 140GB VRAM
ollama pull llama3.3:70b-q8 # Q8 : 70GB VRAM (recommandé prod)
ollama pull llama3.3:70b-q4_k_m # Q4 : 40GB VRAM (bon compromis)
ollama pull llama3.3:70b-q2_k # Q2 : 25GB VRAM (dernier recours)
# Test de qualité comparative
echo "Explique la différence entre REST et GraphQL en 2 phrases." | \
ollama run llama3.3:70b-q8
# Activer le model caching (garde le modèle en VRAM entre requêtes)
# Évite le reload (30s de latence) à chaque requête
export OLLAMA_KEEP_ALIVE=24h # Garde les modèles chargés 24h
# Tester la latence avec/sans caching
# Premier appel (cold start) : ~35s (load model + génération)
time ollama run llama3.3:70b "Test" --verbose
# Deuxième appel (warm) : ~3s (génération seulement)
time ollama run llama3.3:70b "Test 2" --verbose
# Monitoring GPU : vérifier l'utilisation VRAM
watch -n 1 nvidia-smi
# Output attendu (pendant inférence) :
# GPU 0: NVIDIA RTX 4090 | 95% | 22000MB / 24564MB | 350W / 450W
# GPU 1: NVIDIA RTX 4090 | 12% | 1200MB / 24564MB | 80W / 450W
Cas Réel : Startup Réduisant ses Coûts API de 80%
Contexte : TechDoc SaaS, plateforme de génération de documentation technique pour développeurs. 2000 utilisateurs actifs, 2,5M tokens/jour en input + output. Utilise GPT-4 Turbo depuis 12 mois.
Problèmes rencontrés :
- Coût API OpenAI : 4200€/mois (75M tokens × 0.056€/1M tokens moyenne)
- Latence réseau : 2-5s de RTT vers API OpenAI (serveurs en EU)
- Rate limits : blocages à 500 req/min pendant pics de trafic
- Inquiétudes RGPD : données utilisateurs (code propriétaire) envoyées à OpenAI US
Solution déployée :
- Migration vers Ollama + Llama 3.3 70B (Q8 quantization)
- Infra : serveur Hetzner AX102 (2× RTX 4090, 128GB RAM, 89€/mois) + Load balancer (20€/mois)
- Temps de migration : 3 jours (1 jour config infra, 2 jours tests qualité)
- Changements code : 8 lignes modifiées (changement base_url OpenAI SDK)
Résultats après 6 mois :
| Métrique | Avant (GPT-4 API) | Après (Ollama) | Variation |
|---|---|---|---|
| Coût mensuel | 4200€ | 109€ (serveur + backup) | -97% ✅ |
| Latence p50 | 3.2s | 1.8s | -44% ✅ |
| Latence p99 | 12s (rate limits) | 4.1s | -66% ✅ |
| Qualité output (éval humaine) | 92% | 89% | -3% ⚠️ |
| Disponibilité | 99.7% (SLA OpenAI) | 99.95% (self-hosted) | +0.25% ✅ |
| Incidents rate limits | 12-15/mois | 0 | -100% ✅ |
Retour d'expérience CTO :
"La migration vers Ollama a été étonnamment simple. Nous avons économisé 25 000€ sur 6 mois tout en améliorant la latence et en éliminant les rate limits. La légère baisse de qualité (89% vs 92%) est imperceptible pour nos utilisateurs — nous avons mesuré via A/B test et NPS identique. Pour 80% de nos use cases, Llama 3.3 est indiscernable de GPT-4. Nous gardons GPT-4 API uniquement pour 2-3% des requêtes ultra-complexes (via fallback automatique). ROI : récupération de l'investissement migration en 2 semaines."
Bonnes Pratiques Production
Monitoring et Alertes
# prometheus.yml : scraping métriques Ollama
global:
scrape_interval: 15s
scrape_configs:
# Métriques GPU via NVIDIA DCGM
- job_name: 'nvidia-gpu'
static_configs:
- targets: ['dcgm-exporter:9400']
# Métriques système (node_exporter)
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
# Métriques custom Ollama (via wrapper)
- job_name: 'ollama'
static_configs:
- targets: ['ollama-exporter:8000']
# Alertes critiques (alertmanager)
# alerts.yml
groups:
- name: ollama
rules:
# GPU temperature > 85°C
- alert: GPUOverheating
expr: nvidia_gpu_temperature_celsius > 85
for: 5m
annotations:
summary: "GPU overheating on {{ $labels.instance }}"
# VRAM utilization > 95%
- alert: VRAMSaturation
expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.95
for: 2m
annotations:
summary: "VRAM near saturation on GPU {{ $labels.gpu }}"
# Latence p95 > 10s
- alert: HighLatency
expr: histogram_quantile(0.95, ollama_request_duration_seconds) > 10
for: 5m
annotations:
summary: "High latency detected (p95 > 10s)"
# Error rate > 5%
- alert: HighErrorRate
expr: rate(ollama_requests_failed_total[5m]) / rate(ollama_requests_total[5m]) > 0.05
annotations:
summary: "Error rate above 5%"
Backup et Disaster Recovery
#!/bin/bash
# backup-ollama.sh : sauvegarde automatique des modèles
BACKUP_DIR="/mnt/backups/ollama"
MODELS_DIR="/root/.ollama/models"
DATE=$(date +%Y%m%d_%H%M%S)
# Créer backup compressé
echo "📦 Creating backup..."
tar -czf "$BACKUP_DIR/ollama_models_$DATE.tar.gz" "$MODELS_DIR"
# Upload vers S3 (ou équivalent)
aws s3 cp "$BACKUP_DIR/ollama_models_$DATE.tar.gz" \
s3://my-bucket/ollama-backups/ \
--storage-class GLACIER # Stockage froid économique
# Garder seulement les 7 derniers backups locaux
ls -t "$BACKUP_DIR"/ollama_models_*.tar.gz | tail -n +8 | xargs rm -f
echo "✅ Backup complete: ollama_models_$DATE.tar.gz"
echo "📊 Size: $(du -h $BACKUP_DIR/ollama_models_$DATE.tar.gz | cut -f1)"
# Ajouter à crontab pour backup quotidien 3h du matin
# 0 3 * * * /root/backup-ollama.sh >> /var/log/ollama-backup.log 2>&1
Rate Limiting et Queue Management
# Implémenter un rate limiter avec Redis + Celery
# Évite la saturation GPU lors de pics de trafic
from celery import Celery
from redis import Redis
import ollama
app = Celery('ollama_tasks', broker='redis://localhost:6379/0')
redis_client = Redis(host='localhost', port=6379, db=0)
@app.task(
rate_limit='100/m', # Max 100 requêtes/minute par worker
time_limit=120, # Timeout 2 minutes
soft_time_limit=90 # Warning à 90s
)
def generate_completion(prompt: str, model: str = "llama3.3:70b"):
"""
Génère une completion via Ollama avec rate limiting.
Utilise une queue Redis pour gérer les pics de charge.
"""
try:
response = ollama.chat(
model=model,
messages=[{'role': 'user', 'content': prompt}]
)
return response['message']['content']
except Exception as e:
# Log l'erreur et retry avec exponential backoff
raise generate_completion.retry(exc=e, countdown=2 ** generate_completion.request.retries)
# Utilisation côté client
from celery.result import AsyncResult
# Soumettre la tâche à la queue
task = generate_completion.delay(
prompt="Explique les microservices en 3 phrases",
model="llama3.3:8b"
)
# Attendre le résultat (ou traiter en async)
result = task.get(timeout=120)
print(result)
# Monitoring de la queue
from celery import chain
stats = app.control.inspect().stats()
print(f"Queue length: {stats}") # Nombre de tâches en attente
Troubleshooting : Problèmes Courants et Solutions
| Symptôme | Cause probable | Solution |
|---|---|---|
| Génération très lente (>30s) | Modèle trop gros pour RAM/VRAM disponible, swap utilisé | Utiliser version quantifiée (Q4) ou modèle plus petit (8B au lieu de 70B) |
| Erreur "out of memory" | VRAM GPU insuffisante | Passer à Q4 quantization ou upgrader GPU (minimum 24GB pour 70B) |
| GPU non détecté (CPU fallback) | Drivers NVIDIA manquants ou nvidia-docker non installé | Installer CUDA toolkit + nvidia-docker, vérifier nvidia-smi |
| Qualité inférieure à attendue | Température trop élevée (créativité excessive) ou modèle inadapté | Baisser temperature (0.1-0.3 pour tâches factuelles), essayer autre modèle |
| Latence augmente après 1h d'usage | GPU throttling thermique (>85°C) | Améliorer refroidissement, réduire charge (moins de workers concurrents) |
| Réponses incohérentes en français | Modèle non optimisé pour français | Utiliser Mistral 7B ou Qwen2.5 (meilleurs multilingues) |
| Première requête prend 30-60s | Cold start : chargement du modèle en VRAM | Augmenter OLLAMA_KEEP_ALIVE (garder modèle chargé), ou preload au démarrage |
Ressources et Formation
Pour maîtriser le déploiement de LLM open-source en production et intégrer Ollama dans vos applications, notre formation Claude API pour Développeurs couvre également les alternatives open-source (Llama, Mistral), les architectures hybrides (API + self-hosted), et les stratégies de migration. Formation de 2 jours, finançable OPCO.
Nous proposons aussi un module spécialisé "LLM Self-Hosted en Production" (1 jour) sur Ollama, vLLM, et optimisations GPU. Contactez-nous via le formulaire de contact.
Questions Fréquentes
Ollama est-il vraiment gratuit pour un usage commercial ?
Oui. Ollama est open-source (licence MIT) et peut être utilisé commercialement sans restriction. Les modèles (Llama 3.3, Mistral, etc.) ont des licences permissives autorisant l'usage commercial. Seule contrainte : vous payez l'infrastructure (serveur GPU/CPU). Coût typique : 50-200€/mois selon volume vs 500-5000€/mois pour API propriétaires équivalentes.
Quelle différence entre Ollama et une API comme OpenAI/Claude ?
Ollama exécute les modèles localement (sur votre machine ou serveur), les API propriétaires sont hébergées par le fournisseur. Avantages Ollama : coût nul par token, données 100% privées, pas de rate limits, fonctionne offline. Inconvénients : nécessite infrastructure GPU pour performances optimales, qualité inférieure aux meilleurs modèles propriétaires (GPT-4, Claude Opus) sur tâches complexes.
Quels modèles choisir pour la production en 2026 ?
Pour usage général : Llama 3.3 70B (meilleur rapport qualité/performance, similaire à GPT-4 Turbo). Pour latence critique : Llama 3.3 8B ou Mistral 7B (réponses <1s sur CPU). Pour code : CodeLlama 34B ou DeepSeek Coder 33B. Pour multilingue : Mistral Large 2 ou Qwen2.5. Règle : utilisez le plus petit modèle qui remplit vos critères de qualité.
Peut-on déployer Ollama sans GPU ?
Oui, Ollama fonctionne sur CPU mais c'est 10-50x plus lent. Pour production CPU uniquement : limitez-vous à modèles 7B-13B quantifiés (Q4_K_M) et acceptez 5-15s de latence par réponse. Pour production sérieuse : GPU obligatoire. Minimum viable : RTX 4090 24GB (500€ occasion) ou NVIDIA L4 cloud (0.50€/h). Pour scale : A100 40GB (2-3€/h) ou H100 (4-6€/h).
Comment migrer d'OpenAI API vers Ollama sans réécrire le code ?
Ollama est compatible avec l'API OpenAI. Changez uniquement l'URL de base (http://localhost:11434/v1) et le modèle (llama3.3:70b). Vos appels `client.chat.completions.create()` fonctionnent tels quels. Seule différence : pas de support natif pour function calling (utilisez Prompt Engineering ou LangChain pour tool use). Migration = 5 lignes de code modifiées.