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

[popkins]

Dans le cas d'OpenAI, non seulement du matériel Nvidia, mais aussi les MI300X d'AMD sont utilisés pour l'inférence ; pour l'entraînement, c'est uniquement Nvidia.
Pour l'inférence, ils cherchent par tous les moyens à maximiser la VRAM obtenue par rapport aux coûts d'investissement.
Dans le cas de Microsoft, c'est pareil : pour l'inférence, ils mélangent Nvidia et AMD.

[popkins]

Surtout dans les régions Azure d’Asie, la part d’AMD utilisée par OpenAI est d’environ 2 pour AMD contre 8 pour Nvidia.

[GN⁺]

Avis Hacker News

• Je travaille chez Google sur ce type de systèmes (avis personnel), et je peux dire avec certitude que des gens très intelligents réfléchissent sérieusement à tous les aspects du problème. Je ne peux pas en dire beaucoup plus, mais je voudrais partager des ressources rédigées par des collègues. Il y a une excellente explication de l’architecture des accélérateurs et des méthodes d’optimisation permettant d’atteindre de hautes performances dans le scaling book. Si ce qui vous intéresse en particulier est l’inférence, le chapitre sur l’inférence vous aidera. Je recommande aussi le guide d’unsloth. Ils creusent en profondeur différents modèles pour trouver des optimisations, puis les présentent de façon claire. En plus du guide Gemma 3n, il y a plusieurs autres guides

  • Pour l’expliquer de façon un peu moins mystique, l’inférence est (la plupart du temps) une tâche sans état. Il n’y a donc pas à se soucier, comme pour l’entraînement, de la cohérence mémoire entre des centaines de milliers de machines ni des pannes de machines. Il suffit surtout d’acheminer de petites quantités de données vers de très grosses machines. Les machines de recherche là où j’ai travaillé étaient des monstres ultra-performants avec 8 GPU, et tant que le modèle tenait dans la VRAM totale, on pouvait faire tourner correctement n’importe quelle charge. L’ingrédient secret du passage à l’échelle, c’était « une quantité énorme de capital ». NVIDIA nous a même envoyé des machines DGX plaquées or, qui n’étaient pas très denses et coûtaient extrêmement cher. La plupart des grandes entreprises disposent déjà de RPC fiables et de systèmes d’orchestration ; la vraie difficulté n’est donc pas le transport des messages, mais l’adaptation du modèle au matériel qui le fait tourner (ce n’est pas mon domaine d’expertise)

  • Les racks modernes dédiés à la grande échelle pour l’inférence, les techniques bien connues de RDMA et de réseau à faible latence, les optimisations solides de MLA et de cache n’ont pas besoin d’être présentés comme des technologies mystérieuses. Tout cela est déjà bien compris publiquement, et lorsqu’une grande entreprise fait quelque chose de très custom, cela peut même parfois devenir un fardeau à cause des contraintes de compatibilité avec l’existant. Ce qui compte vraiment, c’est d’avoir de bons systèmes et de bons processus pour exploiter de grands ensembles. Cela couvre des domaines allant de l’approvisionnement matériel à la formation SRE, jusqu’au RTL pour de nouveaux TPU. Si quelqu’un avait 10x d’avance, on le saurait immédiatement (personne ayant 10 ans d’expérience en grande échelle d’inférence dans le TOP-5)

  • À propos de la formule « nous sommes des gens intelligents qui réfléchissons très sérieusement à tous les problèmes », en réalité on peut aussi voir ça comme du time-sharing à la manière des mainframes des années 1970

  • Je me demande si, grâce aux TPU, l’inférence de ses propres modèles n’est pas bien plus rentable pour Google que la location de cartes NVIDIA. D’après ce que je sais, OpenAI obtient la plupart de ses GPU via son partenariat avec Microsoft. Le lien et le livre étaient tous deux passionnants à lire

  • La phrase « aujourd’hui, même les “petits” modèles fonctionnent au plus près des limites du matériel » m’a marqué. Cela sonne un peu comme le « même les petits programmes tournent au plus près des limites du matériel » des années 60 et 70. Même si l’optimisation et l’efficacité ont disparu dans une partie de l’ingénierie logicielle, elles sont toujours bien vivantes dans le développement des LLM

• Un H100 coûte 20 000 dollars et dispose de 80 Go de VRAM. On peut imaginer 100 000 dollars de cartes de ce type dans un seul serveur rack 2U. Si on remplit un rack entier avec ce genre d’équipement, en ajoutant CPU, RAM et refroidissement, on arrive à environ un million de dollars par rack (sans compter les coûts d’exploitation et le personnel de maintenance). Même l’équipement « bon marché » se compte à une échelle énorme. J’espère qu’au moment où la bulle IA éclatera, il deviendra réaliste de faire tourner de bons modèles en local. Dans 10 ans, peut-être que ces serveurs à 100 000 dollars se vendront 3 000 dollars sur eBay, et que des électriciens recevront des demandes pour installer du 240V dans des garages ou des salles serveur improvisées

  • Pas besoin d’attendre 10 ans : on peut déjà acheter des DGX-1 sur eBay pour moins de 10 000 dollars. 256 Go de VRAM (HBM2), NVLink, 512 Go de RAM, CPU 40 cœurs, SSD 8 To, HBA 100 Gbit. Les produits hors marque NVIDIA peuvent s’acheter à 6 000 dollars. En revanche, c’est très lourd, bien plus bruyant qu’on ne l’imagine, et une seule machine consomme presque tout un circuit 240V 16A. Elle produit aussi 13 000 BTU de chaleur par heure

  • Même si la bulle IA n’éclate pas, il est probable que ces serveurs finissent sur eBay dans 10 ans. Les data centers mettront à jour leur matériel et revendront l’occasion à des tiers

  • Personnellement, je soupçonne que les modèles ouverts utilisent bien moins de calcul qu’on ne le pense. Dans les modèles récents de type Mixture of Experts, grâce au top-k sampling — c’est-à-dire une structure où seuls certains experts (paramètres) sont activés puis évalués —, même un modèle SOTA ne demande pas forcément beaucoup plus de calcul qu’un modèle non-MoE de 70-80B

  • Dans le service IA à l’échelle d’une entreprise, la vraie question n’est pas tant « comment servir les utilisateurs ? » que le fait que les investisseurs attendent un jour un ROI. L’infrastructure nécessaire peut être construite tant qu’il y a de l’investissement. Même sans optimisation, on peut toujours construire autant d’entrepôts et de racks que nécessaire pour servir la demande

  • Je ne suis pas Américain, donc le passage sur le 240V m’a fait rire

• Vous avez peut-être quelques milliers de dollars ; eux ont des dizaines de milliards. On parle d’un ordre de grandeur de 1 000 contre 10 000 000 000. Leur efficacité est aussi supérieure d’un ou deux ordres de grandeur grâce à l’échelle. Et il est déjà possible de faire tourner sur un MacBook (24 Go de RAM) des modèles locaux comparables aux performances du GPT-4 des débuts. Lien de comparaison des performances

  • Si on répartit 700 millions d’utilisateurs sur une journée ou une semaine, cela peut ne représenter en réalité qu’environ 10 millions de sessions actives simultanément. Un utilisateur individuel ne peut pas accumuler une semaine de ressources de calcul pour les utiliser d’un coup, alors qu’un fournisseur de service peut simplement dimensionner horizontalement pour les pics. C’est pour cela qu’à niveau de performance équivalent, un environnement local demande beaucoup plus de matériel

• Même un seul nœud GPU fournit déjà énormément de FLOPs et de bande passante mémoire. Lorsqu’on traite peu de requêtes, le GPU passe souvent son temps à attendre que les poids soient streamés depuis la RAM vers les unités de calcul. Si l’on regroupe les requêtes par batch, on peut lire un ensemble de poids une seule fois et traiter plusieurs requêtes en parallèle, ce qui maximise l’efficacité. En plus, on peut compresser le modèle en 8 bits ou moins pour réduire la quantité de données à streamer, et les GPU récents prennent en charge le calcul en 8 bits/4 bits. Les modèles Mixture of Experts n’utilisent qu’une partie des paramètres pour chaque token, donc nécessitent de charger moins de poids. Les techniques de speculative decoding utilisent un petit modèle pour prédire à l’avance plusieurs tokens, puis le modèle principal n’accepte que ceux qui correspondent. Toutes ces optimisations combinées donnent une efficacité remarquable (basé sur une expérience de directeur de l’équipe inférence chez Databricks)

• L’un des ingrédients secrets d’OpenAI, ce sont des milliards de dollars de pertes. Ils ont perdu 5 milliards de dollars en 2024. Article lié

  • Ces derniers temps, l’approche agentic a changé beaucoup de choses. Avant, c’était 1 requête pour 1 traitement ; maintenant, on exécute en parallèle des centaines de traitements pour une seule tâche. C’est grâce à ce parallélisme que OAI/Azure ont un avantage par rapport aux modèles locaux

  • Si l’on supprimait la R&D pour ne faire que servir les modèles existants, j’ai l’impression qu’ils pourraient atteindre le seuil de rentabilité

  • C’est exactement le point essentiel. L’investissement de Microsoft, jusqu’à 10 milliards de dollars, a couvert le pré-entraînement, la R&D et les coûts d’inférence, et malgré cela il reste encore des milliards de pertes. C’est une logique de capitalisme orienté croissance à la sauce VC

• Pour l’inférence à grande échelle, traiter les requêtes par batch en une seule fois est bien plus efficace qu’un modèle où chaque utilisateur a son propre GPU (comme en environnement personnel). Si vous voulez connaître quelques astuces d’ingénierie de niveau intermédiaire, vous pouvez jeter un œil à l’article que notre équipe a publié sur le blog de Fin AI. (OpenAI et d’autres utilisent probablement aussi des techniques propriétaires qui n’y figurent pas.) Post lié

  • C’est la vraie réponse centrale. Parmi tout ce qui est discuté plus haut, c’est le batching qui réduit drastiquement les coûts. Par exemple, si traiter une requête coûte 50 000 dollars, le batching permet d’en traiter 100 en même temps pour presque aucune perte supplémentaire, toujours avec ces 50 000 dollars. Je ne sais pas combien d’utilisateurs une seule machine peut réellement servir, mais je dirais probablement quelques centaines. Cela signifie qu’on peut faire passer le coût effectif de 50 000 à 500 dollars, à condition d’avoir assez d’utilisateurs. Le goulet d’étranglement du traitement LLM, c’est surtout le temps nécessaire pour charger les poids sur le GPU ; au lieu de traiter chaque requête séparément, on fait en sorte que les calculs de plusieurs requêtes soient réalisés ensemble pour maximiser l’efficacité. Par exemple, si trois ensembles de poids (A, B, C) tiennent dans le cache GPU et qu’il y a deux requêtes (1, 2), l’approche classique consiste à charger les poids pour chaque requête séparément, alors que l’approche par batch consiste à charger les poids une seule fois puis à effectuer les calculs pour plusieurs requêtes. Si l’on compare le temps de chargement des poids et le temps de calcul, la différence de vitesse avant et après batching devient spectaculaire. En pratique, le chargement des poids est bien plus lent que le calcul ; plus il y a d’utilisateurs, plus l’écart se creuse. En réalité, il faut aussi de la mémoire d’activation pour servir davantage d’utilisateurs, donc il faut équilibrer le nombre de personnes par cluster GPU. En conclusion, le matériel pour servir des LLM est très coûteux, mais une fois qu’on l’a, il est possible de servir simultanément des centaines d’utilisateurs avec presque aucune dégradation des performances

• Le fait d’avoir 700 millions d’utilisateurs par semaine ne dit pas grand-chose sur la charge réelle. Même si la plupart des utilisateurs de ChatGPT l’utilisaient une heure par jour toute la semaine, 96 % du temps les ressources seraient encore inactives. Beaucoup de gens n’utilisent que des modèles moins complexes. Le simple fait de parler d’« utilisateurs hebdomadaires » suggère qu’une partie des utilisateurs actifs quotidiens ne l’utilisent même pas une fois par jour. Les défis essentiels sont : 1) construire des serveurs dans lesquels le modèle tient en mémoire et qui peuvent traiter les tokens assez vite, 2) disposer d’un nombre suffisant de serveurs pour absorber le débit de tokens aux heures de pointe, 3) répartir efficacement toutes les requêtes sur les serveurs. Il y a bien sûr des détails supplémentaires, mais au fond le dernier point ressemble un peu à l’exploitation d’un moteur de recherche. Tout l’état est contenu dans l’historique de conversation, donc rien n’impose qu’un même chat soit toujours traité par le même serveur. Quand vous voyez le message « Thinking... », rien ne vous dit si le modèle est réellement en train de calculer ou s’il attend simplement qu’un serveur se libère dans la file

• L’un des plus grands secrets du bon fonctionnement des LLM à grande échelle, c’est la « taille de batch ». Aujourd’hui, la plupart des LLM utilisent une architecture « Mixture of Experts » qui n’active à chaque instant qu’une partie des paramètres totaux. Cela rend le traitement par lots à grande échelle bien plus efficace. Si vous vouliez faire tourner GPT-4 chez vous, il faudrait pouvoir loger tout le modèle dans la VRAM, donc plusieurs GPU de type H100 seraient nécessaires (environ 40 000 dollars l’unité). Mais à l’échelle d’un usage personnel, vous ne pourriez pas vraiment exploiter ce type de cartes. C’est un peu comme demander : « pourquoi Apple peut fabriquer des iPhone pour des milliards de personnes, alors que moi je n’arrive même pas à en faire un dans mon garage ? »

  • En résumé, la charge d’inférence se répartit bien sur un grand nombre d’utilisateurs, ce qui permet un fonctionnement efficace

  • Je me demande donc s’il serait possible d’avoir une architecture où les parties rarement utilisées résident en mémoire principale, et les parties fréquemment utilisées en VRAM

  • L’analogie est très juste

• Une astuce qu’on peut aussi mettre en œuvre à la maison, et qui joue un rôle important dans les performances de Cerebras, c’est le speculative decoding. Cette méthode utilise un modèle brouillon bien plus petit pour prédire des tokens avec beaucoup moins de calcul et de mémoire, puis le modèle principal adopte les tokens qu’il aurait lui-même sélectionnés. Dans une architecture bien conçue, on peut obtenir jusqu’à 3x d’accélération. De plus, pour les structured outputs, on peut appliquer du « fast forwarding » en sautant les tokens prévisibles, par exemple en préremplissant le format initial en JSON, ce qui peut aussi aller jusqu’à 3x plus vite

  • Dans LM Studio, on peut essayer le speculative drafting en combinant gpt-oss-120b et gpt-oss-20b. Cela dit, je n’ai pas l’impression que le gain soit si sensible

• Le cœur de l’inférence LLM, c’est la multiplication matrice-vecteur. Lorsqu’il faut traiter plusieurs requêtes en même temps, on peut regrouper les vecteurs de chaque requête pour former une matrice, puis calculer le tout d’un seul coup via une multiplication matrice-matrice. Du point de vue du matériel, il est bien plus efficace de faire une seule multiplication matrice-matrice que de répéter plusieurs multiplications matrice-vecteur. C’est précisément cela, le batching. La deuxième astuce, c’est le speculative decoding. L’inférence se compose de deux étapes, le traitement du prompt et la génération des tokens, et dans les deux cas la structure de calcul sous-jacente est la même : un « forward pass ». Le traitement du prompt peut être parallélisé sous forme de multiplications matrice-matrice, et seul le dernier résultat sert ensuite de point de départ à la génération de tokens. Mais comme on ne connaît pas à l’avance les futurs tokens, cette étape n’est normalement pas parallélisable. On utilise donc un modèle brouillon rapide pour prédire les N prochains tokens, on les injecte dans le prompt d’entrée, puis on exécute un forward pass parallèle avec le modèle principal. Parmi les N tokens générés, tous ceux jusqu’au premier token correspondant peuvent être validés immédiatement comme tokens de sortie. En théorie, on peut espérer une accélération de l’inférence de 2 à 4x. Je ne l’ai pas implémenté moi-même dans mon travail, mais j’imagine qu’en plus ils appliquent aussi des techniques comme le regroupement parallèle par longueur de requête ou l’équilibrage de charge en temps réel (puisque toutes les requêtes n’ont évidemment pas la même longueur, et qu’il faut éviter les déséquilibres de ressources)