Points clés
- Machine unique : 1 GPU, 10-50 utilisateurs simultanés, configuration simple.
- Multi-GPU : 2-8 GPU, 50-200 utilisateurs, orchestration Kubernetes.
- Entreprise : 5-50 GPU, 500+ utilisateurs, distribué, hautement disponible.
- Équilibrage de charge : Round-robin distribue les requêtes sur les pods GPU.
- Surveillance : Suivez la latence, la profondeur de la file d'attente, l'utilisation des GPU, les taux d'erreur.
- En avril 2026, Kubernetes est la norme pour les déploiements d'entreprise d'LLM.
Comment passer à l'échelle d'une machine unique à un système distribué ?
Progression de la machine unique à la production :
| Étape de déploiement | Nombre de GPU | Utilisateurs simultanés | Disponibilité SLA | Configuration d'infrastructure |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
Comment implémenter l'équilibrage de charge ?
L'équilibreur de charge achemine les requêtes vers le pod d'inférence le moins occupé.
Round-robin : Distribuez équitablement sur les pods (plus simple).
Moins chargé : Envoyez vers le pod avec la queue la plus courte (meilleure latence).
Sessions persistantes : Le même utilisateur utilise toujours le même pod (pour le contexte, mais risqué si le pod échoue).
# Service Kubernetes avec équilibrage de charge
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # Round-robin sur les podsComment implémenter la redondance et le basculement ?
La haute disponibilité nécessite des composants redondants :
Réplicas de pods : Plusieurs pods d'inférence. Si l'un échoue, les autres traitent les requêtes.
Contrôles de santé : Kubernetes supprime automatiquement les pods non sains.
Redondance de stockage : Fichiers modèles répliqués sur les nœuds.
Basculement DNS : Si tout un centre de données échoue, routez vers une installation de secours.
Que devez-vous surveiller ?
Les déploiements d'entreprise doivent surveiller :
- Latence : Temps par requête (centiles p50, p95, p99).
- Profondeur de la file d'attente : Nombre de requêtes en attente. >10 = surchargé.
- Utilisation des GPU : Devrait être 70-90 %. <50 % = surdimensionné. >95 % = sous-dimensionné.
- Taux d'erreur : % de requêtes échouées. Devrait être <0.1 %.
- Débit : Tokens/sec sur tous les pods.
- Disponibilité : % de temps où le service est disponible (cible 99.9 %).
- Coût par requête : €/requête (matériel amorti).
Comment optimiser les coûts à l'échelle ?
À l'échelle, concentrez-vous sur :
- Utilisation des GPU : Plus élevé est moins cher par requête. Cible 80-90 %.
- Quantification de modèles : Q4 vs FP16 utilise 4× moins de VRAM, même vitesse. Réduit les GPU requis.
- Taille de lot : Les plus grands lots = coût inférieur par requête (mais latence plus élevée).
- Auto-scaling : Descendez la nuit, montez pendant la journée (économisez 30-50 % des coûts cloud).
- Multi-tenancy : Exécutez 2-3 modèles par GPU (si la VRAM le permet). Utilisation plus élevée.
Erreurs courantes en matière de mise à l'échelle d'entreprise
- Ignorer les exigences de latence. Accordez-vous sur la SLA de latence p99 avant le déploiement. Une latence de 2 secondes peut sembler correcte jusqu'à ce que les utilisateurs se plaignent.
- Sur-approvisionnement pour la charge maximale. Si la charge maximale est 100 utilisateurs pendant 2 heures/jour, n'achetez pas de matériel pour 100 utilisateurs simultanés toute la journée. Utilisez l'auto-scaling.
- Mauvaise isolation des défaillances. Si un crash de pod fait tomber l'équilibreur de charge, l'architecture est mauvaise. Testez les scénarios d'défaillance.
- Surveillance des mauvaises métriques. Surveiller l'utilisation des GPU mais pas la latence est à l'envers. La latence impacte les utilisateurs.
- Supposer que les outils open-source se mettent à l'échelle en entreprise. Ollama fonctionne super bien pour 1 utilisateur. Pour 500 utilisateurs simultanés, vous avez besoin de surveillance et d'orchestration d'entreprise.
Quelles sont les questions courantes sur la mise à l'échelle des LLM locaux ?
De combien de GPU avons-nous besoin pour le déploiement en entreprise ?
Dépend des exigences de concurrence et de latence. 100 utilisateurs simultanés sur modèle 7B : ~5-8 GPU. 500 utilisateurs simultanés : 20-30 GPU. Formule : (utilisateurs simultanés × latence attendue) / (tokens/sec par GPU).
Quelle est la différence entre l'équilibrage de charge et l'auto-scaling ?
L'équilibrage de charge distribue les requêtes sur les pods existants. L'auto-scaling ajoute/supprime des pods en fonction de la charge. Les deux sont nécessaires : l'équilibrage de charge répartit le travail maintenant, l'auto-scaling ajuste la capacité.
Comment gérez-nous les défaillances de GPU ?
Kubernetes replanifie automatiquement les pods vers des GPU sains. Si un GPU échoue, Kubernetes le marque comme indisponible et route le trafic vers d'autres pods. Ayez de la redondance : si vous avez besoin de 8 GPU, approvisionnez 10.
Quel SLA de latence devons-nous viser ?
La latence p99 <2 secondes est standard pour les chatbots. p99 <500ms pour l'autocomplétion en temps réel. Définissez la SLA en fonction de l'expérience utilisateur, puis choisissez le matériel/taille de lot pour la satisfaire.
Comment surveiller un cluster d'inférence distribué ?
Surveillez par pod et au niveau du cluster : utilisation des GPU, profondeur de la file d'attente, latence (p50/p95/p99), taux d'erreur, débit et disponibilité. Utilisez Prometheus + Grafana ou équivalent.
La mise à l'échelle locale est-elle moins chère que le cloud ?
Oui, à l'échelle. Le point d'équilibre est ~500k tokens/mois. Locale : coût initial élevé (€400k-1,5M matériel), puis faible coût par requête. Cloud : pas de coût initial, coût élevé par requête (€0,15-60/1M tokens).
Sources
- Documentation Kubernetes -- kubernetes.io/docs
- Guide de déploiement vLLM -- docs.vllm.ai/en/serving/distributed_serving.html
- Surveillance Prometheus -- prometheus.io