Architectures de serving LLM
Déployer un LLM en production nécessite une architecture robuste qui gère la latence, la disponibilité, et les coûts. Voici les patterns éprouvés.
Solutions de serving
vLLM
Moteur d'inférence haute performance, standard de facto :
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3-70b-instruct \
--tensor-parallel-size 4 \
--port 8000- API compatible OpenAI
- PagedAttention, continuous batching
- Tensor parallelism multi-GPU
- Support quantization (AWQ, GPTQ)
TGI (Text Generation Inference) - HuggingFace
docker run --gpus all \
-p 8080:80 \
ghcr.io/huggingface/text-generation-inference \
--model-id meta-llama/Llama-3-70b-instruct \
--num-shard 4- Optimisé pour les modèles HuggingFace
- Flash Attention intégré
- Watermarking et safety built-in
- Intégration native avec HuggingFace Hub
Ollama (développement et edge)
ollama run llama3:70b- Installation en une commande
- Gestion automatique des modèles
- Idéal pour le développement local et les petits déploiements
- API REST simple
Load Balancing pour LLM
# nginx.conf pour LLM serving
upstream llm_backend {
least_conn; # Préférer le serveur le moins chargé
server gpu-node-1:8000;
server gpu-node-2:8000;
server gpu-node-3:8000;
}Particularités du load balancing LLM :
- Requêtes de durée variable (10ms à 60s)
- least_conn meilleur que round_robin
- Health checks sur le nombre de requêtes en file d'attente
Auto-scaling
Scale-to-zero avec RunPod/Modal
# Modal : scale automatique avec cold start
import modal
app = modal.App("llm-serving")
@app.cls(gpu="A100", container_idle_timeout=300)
class Model:
@modal.enter()
def load(self):
self.llm = LLM(model="meta-llama/Llama-3-70b-instruct")
@modal.method()
def generate(self, prompt: str) -> str:
return self.llm.generate(prompt)Métriques de scaling
- Scale up : Queue depth > 10 ou latence p95 > 5s
- Scale down : GPU utilization < 20% pendant 5 minutes
- Minimum 1 instance pour éviter les cold starts
Failover et résilience
- Multi-provider : Fallback API (OpenAI → Anthropic → self-hosted)
- Circuit breaker sur chaque backend
- Timeout agressif (30s) avec retry sur un autre nœud
- Graceful degradation : modèle plus petit si le principal est saturé
Pattern recommandé pour la production
Client → API Gateway → Load Balancer → [vLLM instances]
→ Rate Limiter ↗
→ Auth/Quota ↗
→ Fallback (API) ← si self-hosted down