Ask HN : ChatGPT peut servir 700 millions de personnes, alors pourquoi je n’arrive même pas à faire tourner un seul GPT-4 en local ?

• Sam Altman a annoncé que ChatGPT traite environ 700 millions d’utilisateurs par semaine
• Lorsqu’on exécute un modèle de niveau GPT-4 en local, les problèmes de manque de VRAM et de baisse de vitesse sont sévères, et la question est de savoir comment OpenAI gère un tel volume d’usage avec une faible latence et de hautes performances
• L’auteur veut comprendre les techniques de modèle optimisé, traitement distribué, matériel dédié et équilibrage de charge qui vont au-delà d’un simple cluster de GPU

---

Résumé des principaux commentaires

1. Architecture d’inférence distribuée à très grande échelle

• Model Sharding
  • Les paramètres sont répartis et stockés sur plusieurs GPU
  • Lorsqu’une requête arrive, chaque GPU calcule sur sa partie des paramètres, puis les résultats sont fusionnés
• Tensor Parallelism
  • Les calculs à l’intérieur d’une même couche sont exécutés en parallèle sur plusieurs GPU
• Pipeline Parallelism
  • Les couches sont divisées en plusieurs étapes, traitées de manière séquentielle et simultanée comme dans un pipeline
• Le traitement parallèle hybride optimise la mémoire GPU et la charge de calcul

2. Optimisation mémoire et vitesse

• Quantization : conversion des paramètres vers une précision de bits plus faible pour réduire l’usage de VRAM
• Offloading de couches : déplacement de certaines couches vers la mémoire CPU si nécessaire
• LoRA / Adapter Layers : seul un travail spécifique est affiné (fine-tuning), évitant de recharger l’ensemble du modèle
• KV caching : réutilisation du contexte pour éliminer les calculs répétés

3. Matériel dédié et réseau

• Usage massif des derniers NVIDIA H100, A100 et de certains TPU
• Transferts de données ultra-rapides via NVLink et NVSwitch entre GPU, et via Infiniband entre clusters
• Mise en place d’un réseau backbone mondial entre datacenters pour minimiser la latence

4. Répartition géographique et équilibrage de charge

• Déploiement de fermes de GPU dans plusieurs régions du monde
• GeoDNS connecte les requêtes utilisateurs à la région la plus proche
• Extension/réduction dynamique des clusters GPU en fonction des patterns de trafic
• Redispatch global du trafic lorsqu’une région subit une concentration de charge

5. Optimisation du traitement des requêtes

• Batch inference : regroupement des requêtes de plusieurs utilisateurs pour une inférence unique
• Prétraitement par de petits modèles : les requêtes simples sont traitées par des modèles légers, seuls les cas complexes appellent un grand modèle
• Mise en cache des résultats : les résultats pour des prompts identiques ou des requêtes similaires sont renvoyés immédiatement depuis le cache
• Prompt engineering pour éviter le gaspillage inutile de tokens

6. Optimisation de l’exploitation et des coûts

• Monitoring et scheduling de l’utilisation GPU pour minimiser les ressources inactives
• Amélioration de l’efficacité énergétique des datacenters et adoption du refroidissement liquide
• Optimisation maison du compilateur et du runtime pour accélérer l’inférence
• Exploitation de pipelines automatisés pour les mises à jour et déploiements de modèles

Exemple de flux d’architecture global

1. Réception de la requête utilisateur → routage vers la région la plus proche via GeoDNS
2. Prétraitement → les requêtes simples vont vers un petit modèle, les requêtes complexes seulement vers un grand modèle
3. Traitement d’inférence distribué
   • application de model sharding + tensor parallelism + pipeline parallelism
   • échange des résultats intermédiaires via un réseau haut débit entre GPU
4. Post-traitement et mise en cache des résultats → stockage en cache pour les requêtes identiques ou similaires
5. Retour de la réponse → résultat fourni en 1 à 2 secondes