Ask HN: ChatGPT kann 700 Millionen Menschen bedienen – warum kann ich dann nicht einmal ein einziges GPT-4 lokal ausführen?

• Sam Altman hat bekannt gegeben, dass ChatGPT wöchentlich rund 700 Millionen Nutzer bedient
• Wenn man ein Modell auf GPT-4-Niveau lokal ausführt, sind VRAM-Mangel und Geschwindigkeitseinbußen gravierend; gefragt wird daher, wie OpenAI diese massive Nutzung mit niedriger Latenz und hoher Leistung bewältigt
• Gewünscht sind Einblicke in Modelloptimierung, verteilte Verarbeitung, spezialisierte Hardware und Load-Balancing-Verfahren jenseits eines simplen GPU-Clusters

---

Zusammenfassung der wichtigsten Kommentare

1. Struktur für verteilte Inferenz im großen Maßstab

• Model Sharding
  • Parameter werden verteilt über mehrere GPUs gespeichert
  • Geht eine Anfrage ein, berechnet jede GPU ihren eigenen Parameteranteil und anschließend werden die Ergebnisse zusammengeführt
• Tensor Parallelism
  • Berechnungen innerhalb einer einzelnen Schicht werden parallel auf mehreren GPUs ausgeführt
• Pipeline Parallelism
  • Schichten werden in mehrere Stufen aufgeteilt und wie in einer Pipeline sequentiell und gleichzeitig verarbeitet
• Gemischte Parallelisierung optimiert GPU-Speicher und Rechenlast

2. Optimierung von Speicher und Geschwindigkeit

• Quantisierung: Parameter werden in niedrigere Bit-Genauigkeit umgewandelt, um den VRAM-Bedarf zu senken
• Layer Offloading: Bei Bedarf werden einige Schichten in den CPU-Speicher verschoben
• LoRA / Adapter Layers: Nur bestimmte Aufgaben werden feinabgestimmt, sodass kein vollständiges Neuladen des gesamten Modells nötig ist
• KV Caching: Kontext wird wiederverwendet, um wiederholte Berechnungen zu vermeiden

3. Spezialisierte Hardware und Networking

• Umfassender Einsatz aktueller NVIDIA H100, A100 und teilweise TPUs
• Extrem schnelle Datenübertragung zwischen GPUs über NVLink und NVSwitch, zwischen Clustern über InfiniBand
• Aufbau eines globalen Backbone-Netzwerks zwischen Rechenzentren zur Minimierung der Latenz

4. Geografische Verteilung und Load Balancing

• Platzierung von GPU-Farmen in mehreren Regionen weltweit
• GeoDNS verbindet Nutzeranfragen mit der nächstgelegenen Region
• GPU-Cluster werden je nach Traffic-Muster dynamisch hoch- und herunterskaliert
• Bei Lastspitzen in einer bestimmten Region wird Traffic global umverteilt

5. Optimierung der Anfrageverarbeitung

• Batch Inference: Anfragen mehrerer Nutzer werden gebündelt und gemeinsam inferiert
• Vorverarbeitung mit kleinen Modellen: Einfache Anfragen werden mit kleinen Modellen bearbeitet, nur komplexe Anfragen gehen an große Modelle
• Ergebnis-Caching: Ergebnisse identischer oder ähnlicher Prompts werden direkt aus dem Cache zurückgegeben
• Prompt Engineering verhindert unnötige Verschwendung von Tokens

6. Betriebs- und Kostenoptimierung

• Monitoring und Scheduling der GPU-Auslastung minimieren ungenutzte Ressourcen
• Effizientere Stromnutzung im Rechenzentrum und Einsatz von Flüssigkühlung
• Eigene Compiler- und Runtime-Optimierungen erhöhen die Inferenzgeschwindigkeit
• Automatisierte Pipelines für Modell-Updates und Deployment

Beispielhafter Ablauf der Gesamtarchitektur

1. Eingang der Nutzeranfrage → Routing zur nächstgelegenen Region per GeoDNS
2. Preprocessing → einfache Anfragen an kleine Modelle, nur komplexe Anfragen an große Modelle
3. Verteilte Inferenzverarbeitung
   • Einsatz von Model Sharding + Tensor Parallelism + Pipeline Parallelism
   • Austausch von Zwischenergebnissen über Hochgeschwindigkeitsnetzwerke zwischen GPUs
4. Postprocessing und Ergebnis-Caching → Cache-Speicherung für identische oder ähnliche Anfragen
5. Antwortausgabe → Ergebnisbereitstellung innerhalb von 1~2 Sekunden

[popkins]

Bei OpenAI wird für Inferenz nicht nur NVIDIA-Hardware, sondern auch AMDs MI300X eingesetzt; fürs Training allerdings ausschließlich NVIDIA.
Bei der Inferenz ist man geradezu besessen davon, im Verhältnis zu den Investitionskosten irgendwie möglichst viel VRAM zu sichern.
Bei Microsoft ist es ähnlich: Für Inferenz werden NVIDIA und AMD ebenfalls gemischt eingesetzt.

[popkins]

Vor allem in den asiatischen Azure-Regionen liegt der von OpenAI genutzte AMD-Anteil ungefähr bei
Nvidia 8 / AMD 2.

[GN⁺]

Hacker-News-Kommentare

• Ich arbeite bei Google direkt an solchen Systemen (meine persönliche Meinung) und kann mit Sicherheit sagen, dass kluge Leute alle Aspekte des Problems ernsthaft durchdenken. Mehr kann ich nicht sagen, aber ich möchte Material teilen, das Kollegen geschrieben haben. Es gibt eine hervorragende Erklärung zur Beschleunigerarchitektur und dazu, wie man für hohe Geschwindigkeit optimiert, im scaling book. Wenn euch besonders der Teil zur Inferenz interessiert, hilft das Kapitel zu Inferenz. Zusätzlich empfehle ich die Guides von Unsloth. Dort werden verschiedene Modelle tiefgehend analysiert, Optimierungen gefunden und gut aufbereitet. Neben dem Gemma-3n-Guide gibt es noch viele weitere Guides

  • Weniger mystisch ausgedrückt: Inferenz ist größtenteils zustandslos. Man muss also nicht wie beim Training über Hunderttausende Maschinen hinweg Speicher-Konsistenz oder Maschinenausfälle berücksichtigen. Man muss nur kleine Datenmengen sauber an sehr große Maschinen schicken. Die Forschungsmaschinen an meinem früheren Arbeitsplatz waren extrem leistungsstarke Systeme mit 8 GPUs, und solange das Modell in den gesamten VRAM passte, konnte praktisch jede Aufgabe ordentlich verarbeitet werden. Die Geheimzutat für große Skalierung war „eine gewaltige Menge Kapital“. NVIDIA hat uns auch schon vergoldete DGX-Maschinen geschickt, aber die hatten keine besonders hohe Dichte und waren extrem teuer. Die meisten großen Firmen haben zuverlässige RPC- und Orchestrierungssysteme, daher liegt der wirklich schwierige Teil nicht in der Nachrichtenübermittlung, sondern darin, das Modell passend auf die vorhandene Hardware zu bringen (das ist allerdings nicht mein Spezialgebiet)

  • Moderne große Inferenz-Racks, gut bekannte RDMA- und Low-Latency-Networking-Techniken sowie starke MLA- und Cache-Optimierungen müssen nicht als geheimnisvolle Technologie dargestellt werden. Diese Dinge sind bereits öffentlich gut verstanden, und wenn bekannte Unternehmen etwas sehr stark Custom bauen, ist das wegen Altlasten-Kompatibilität oft eher belastend. Wirklich wichtig ist, gute Strukturen und Prozesse für den Betrieb großer Systeme zu haben. Dazu gehören ganz unterschiedliche Bereiche: Beschaffung von Geräten, SRE-Training bis hin zu RTL für neue TPUs. Wenn jemand 10x voraus wäre, würde man das sofort merken (jemand mit 10 Jahren Erfahrung mit Large-Scale-Inferenz bei einem TOP-5-Unternehmen)

  • Bei der Aussage „Wir sind kluge Leute, die über alle Probleme wirklich ernsthaft nachdenken“ kann man im Grunde sagen: Es ist Time-Sharing im Stil von Mainframes aus den 1970ern

  • Ich frage mich, ob Google dank TPUs bei der Inferenz eigener Modelle deutlich profitabler ist, als NVIDIA-Karten zu mieten. Soweit ich weiß, beschafft OpenAI GPUs größtenteils über die Partnerschaft mit Microsoft. Sowohl die Links als auch das Buch waren spannend zu lesen

  • Der Satz „Selbst ‚kleine‘ Modelle laufen heute schon nahe an den Hardware-Grenzen“ ist mir aufgefallen. Das klingt ähnlich wie in den 60er- und 70er-Jahren: „Selbst kleine Programme laufen an den Grenzen der Hardware.“ Auch wenn Optimierung und Effizienz im Software Engineering teilweise verschwunden sein mögen, leben sie in der LLM-Entwicklung eindeutig weiter

• Eine einzelne H100 kostet 20.000 Dollar und hat 80 GB VRAM. Man kann sich gut vorstellen, dass in einem 2U-Rackserver Karten im Wert von 100.000 Dollar stecken. Wenn so etwas ein ganzes Rack füllt und CPU, RAM und Kühlung dazukommen, liegt man bei etwa einer Million Dollar pro Rack (Betriebskosten und Wartungspersonal nicht eingerechnet). Selbst „günstige“ Ausrüstung hat also enorme Größeneinheiten. Ich hoffe, dass man gute lokale Modelle realistisch betreiben kann, wenn die AI-Blase platzt. In 10 Jahren könnten solche 100.000-Dollar-Server vielleicht für 3.000 Dollar bei eBay verkauft werden, und Elektriker könnten Anfragen bekommen, in Garagen oder provisorischen Serverräumen 240V zu installieren

  • Man muss keine 10 Jahre warten, man kann sofort eine DGX-1 für unter 10.000 Dollar bei eBay kaufen. 256 GB VRAM (HBM2), NVLink, 512 GB RAM, 40-Core-CPU, 8 TB SSD und 100-Gbit-HBA. Produkte ohne NVIDIA-Branding gibt es sogar für 6.000 Dollar. Allerdings sind sie sehr schwer, unerwartet laut und ziehen fast einen kompletten 240V/16A-Stromkreis. Gleichzeitig erzeugt ein einzelnes Gerät 13.000 BTU Wärme pro Stunde

  • Selbst wenn die AI-Blase nicht platzt, ist es sehr wahrscheinlich, dass diese Server in 10 Jahren bei eBay landen. Rechenzentren werden ihre Hardware aufrüsten und die gebrauchten Systeme an Dritte verkaufen

  • Ich vermute persönlich, dass offene Modelle viel weniger Rechenleistung nutzen, als wir denken. Bei aktuellen Mixture-of-Experts-Modellen sorgt die Top-k-Auswahl dafür, dass nur einige Experten (Parameter) aktiviert und ausgewertet werden. Deshalb braucht selbst ein SOTA-Modell nicht unbedingt viel mehr Compute als ein Non-MoE-Modell mit 70–80B

  • Beim AI-Serving auf Unternehmensebene lautet die eigentliche Frage nicht „Wie bedienen wir Nutzer?“, sondern dass Investoren irgendwann ROI erwarten. Die nötige Infrastruktur kann man, solange Kapital fließt, in praktisch beliebigem Umfang bauen. Selbst ohne Optimierung kann man einfach so viele Lagerhallen und Racks bauen, wie nötig sind, und damit den Dienst bereitstellen

  • Ich bin kein Amerikaner, deshalb fand ich die 240V-Geschichte lustig

• Wenn du ein paar tausend Dollar hast, haben sie viele Milliarden Dollar. Das ist der Unterschied zwischen 1.000 und 10.000.000.000. Ihre Effizienz ist außerdem durch Skalierung noch um ein bis zwei Größenordnungen besser. Außerdem kann man selbst auf einem MacBook (24 GB RAM) lokale Modelle betreiben, die an die Leistung von GPT-4 zum Start herankommen. Link zum Leistungsvergleich

  • Wenn man 700 Millionen Nutzer über einen Tag oder eine Woche zeitlich verteilt, sind vielleicht nur 10 Millionen Sessions gleichzeitig aktiv. Einzelne Nutzer können keine Rechenressourcen einer ganzen Woche ansammeln und auf einmal verbrauchen, aber ein Anbieter muss in einer horizontal skalierten Architektur nur die Peaks abdecken. Deshalb braucht eine lokale Umgebung bei gleichem Leistungsanspruch deutlich mehr Hardware

• Schon ein einzelner GPU-Knoten liefert sehr hohe FLOPs und Speicherbandbreite. Bei wenigen Requests wartet die GPU meist darauf, dass Gewichtsdaten aus dem RAM in die Recheneinheiten gestreamt werden. Wenn man Requests bündelt und als Batch verarbeitet, kann man einen Satz Gewichte einmal laden und mehrere Requests parallel verarbeiten, was die Effizienz maximiert. Zusätzlich kann man das Modell auf 8 Bit oder niedrigere Formate komprimieren, um die zu streamende Datenmenge zu verringern, und moderne GPUs unterstützen 8-Bit-/4-Bit-Rechenoperationen. Mixture-of-Experts-Modelle verwenden pro Token nur einen Teil der Parameter, sodass weniger Gewichte geladen werden müssen. Speculative Decoding nutzt ein kleines Modell, das mehrere Tokens vorhersagt, und das Hauptmodell übernimmt nur diejenigen, die übereinstimmen. All diese Optimierungen zusammen ergeben eine hervorragende Effizienz (basierend auf Erfahrung als Director des Inferenz-Teams bei Databricks)

• Eine der geheimen Zutaten von OpenAI sind Verluste in Milliardenhöhe. 2024 wurden 5 Milliarden Dollar Verlust gemacht. Artikel dazu

  • Inzwischen ist die agentische Arbeitsweise aufgekommen, wodurch sich viel verändert hat. Früher war es 1 Request = 1 Verarbeitung, heute laufen für eine einzelne Aufgabe hunderte Verarbeitungen gleichzeitig. Gerade weil diese Parallelisierung möglich ist, haben OAI/Azure Vorteile gegenüber lokalen Modellen

  • Wenn man R&D herausnehmen und nur bestehende Modelle bereitstellen würde, könnte man vermutlich den Break-even erreichen

  • Das bringt es genau auf den Punkt. Selbst nachdem Microsoft mit bis zu 10 Milliarden Dollar Vortraining, R&D und Inferenzkosten mitfinanziert hat, bleiben immer noch Verluste in Milliardenhöhe. Das ist VC-getriebener, wachstumsorientierter Kapitalismus

• Bei Large-Scale-Inferenz ist es viel effizienter, Requests gebündelt im Batch zu verarbeiten, als einzelnen Nutzern jeweils GPU-Kapazität zuzuweisen, wie im persönlichen Umfeld. Wenn ihr mittlere Engineering-Tricks sehen wollt, könnt ihr euch den Beitrag ansehen, den unser Team im Fin-AI-Blog geschrieben hat. (OpenAI und andere nutzen wahrscheinlich noch zusätzliche, nicht öffentliche Techniken.) Relevanter Post

  • Das ist wirklich die zentrale Antwort. Mehr als all die anderen Dinge oben ist Batching genau die Methode, die die Kosten massiv senkt. Wenn es zum Beispiel 50.000 Dollar kostet, einen einzelnen Request zu verarbeiten, kann man dank Batching mit denselben 50.000 Dollar fast ohne Verlust 100 Requests gleichzeitig abarbeiten. Ich weiß nicht genau, wie viele Nutzer man real pro Hardware bedienen kann, aber vermutlich sind es Hunderte. Das würde die effektiven Kosten von 50.000 Dollar auf 500 Dollar senken, sofern genügend Nutzer da sind. Der Engpass bei LLM-Verarbeitung ist meistens die Zeit, die Gewichte auf die GPU zu laden. Statt jeden Request separat zu verarbeiten, maximiert man die Effizienz, indem man die Berechnung vieler Requests gemeinsam ausführt. Wenn zum Beispiel drei Gewichtssätze (A, B, C) in den GPU-Cache passen und es zwei Requests (1, 2) gibt, lädt der normale Ansatz die Gewichte für jeden Request einzeln, während der Batching-Ansatz die Gewichte einmal lädt und dann mehrere Requests berechnet. Vergleicht man die Zeit fürs Laden der Gewichte mit der Rechenzeit, wird der Geschwindigkeitsunterschied vor und nach dem Batching sehr deutlich. In der Realität ist das Laden der Gewichte viel langsamer als die Berechnung, daher wächst der Unterschied mit steigender Nutzerzahl. Praktisch braucht man zusätzlich Aktivierungsspeicher, um mehr Nutzer zu bedienen, daher muss man austarieren, wie viele Nutzer pro GPU-Cluster sinnvoll sind. Fazit: Hardware für LLM-Serving ist sehr teuer, aber wenn man sie bereits besitzt, kann man Hunderte Nutzer gleichzeitig fast ohne Leistungseinbußen bedienen

• 700 Millionen Nutzer pro Woche sagen nicht besonders viel über die tatsächliche Last aus. Selbst wenn die meisten ChatGPT-Nutzer jeden Tag eine Stunde lang die ganze Woche über aktiv wären, wären 96 % der Zeit Leerlauf. Viele nutzen außerdem nur weniger komplexe Modelle. Dass man ausdrücklich von „wöchentlichen Nutzern“ spricht, bedeutet eher, dass selbst unter den täglich aktiven Nutzern ein Teil nicht einmal einmal pro Tag aktiv ist. Die Kernaufgaben sind: 1) Server zu bauen, auf denen das Modell in den Speicher passt und Tokens schnell genug verarbeitet werden können, 2) genügend Server bereitzustellen, um die kumulierte Token-Durchsatzspitze abzudecken, und 3) alle Requests effizient auf die Server zu verteilen. Es gibt natürlich viele Details, aber die letzte Aufgabe fühlt sich ehrlich gesagt ähnlich an wie der Betrieb einer Suchmaschine. Der gesamte Zustand steckt in der Chat-Historie, daher muss nicht derselbe Chat immer auf demselben Server laufen. Wenn „Thinking...“ angezeigt wird, ist nicht sichtbar, ob das Modell wirklich rechnet oder ob es in einer Warteschlange auf einen freien Server wartet

• Eines der größten Geheimnisse dafür, dass LLMs im großen Maßstab gut laufen, ist die „Batch-Größe“. Moderne LLMs nutzen meist eine „Mixture of Experts“-Architektur, bei der nur ein Teil der Gesamtparameter jeweils aktiv ist. Dadurch wird die Verarbeitung großer Batches viel effizienter. Wenn du GPT-4 zu Hause betreiben wolltest, müsstest du das gesamte Modell in den VRAM bekommen, dafür wären mehrere GPUs wie die H100 nötig (etwa 40.000 Dollar pro Stück). Für die private Nutzung würdest du solche Karten aber nicht einmal annähernd auslasten. Das ist ähnlich wie die Frage: „Warum kann Apple iPhones für Milliarden Menschen bauen, ich aber nicht einmal eins in meiner Garage?“

  • Kurz gesagt: Die Inferenzlast verteilt sich gut über viele Nutzer und läuft dadurch effizient

  • Dann frage ich mich, ob eine Architektur möglich wäre, bei der selten genutzte Teile im Hauptspeicher und häufig genutzte Teile im VRAM liegen

  • Die Analogie passt wirklich sehr gut

• Ein Trick, den man auch zu Hause umsetzen kann und der bei der Leistung von Cerebras eine wichtige Rolle spielt, ist Speculative Decoding. Dabei sagt ein viel kleineres Draft-Modell Tokens mit deutlich weniger Rechenaufwand und Speicherbedarf voraus, und das Hauptmodell übernimmt diejenigen Tokens, die es selbst vermutlich ebenfalls gewählt hätte. In gut abgestimmten Setups sind bis zu 3x Geschwindigkeitsgewinn möglich. Bei Structured Output kann man außerdem „Fast Forwarding“ nutzen, bei dem vorhersehbare Tokens übersprungen werden, etwa indem bei JSON das Anfangsformat schon vorausgefüllt wird. Das kann die Geschwindigkeit ebenfalls um bis zu 3x steigern

  • In LM Studio kann man speculative drafting mit gpt-oss-120b und gpt-oss-20b ausprobieren. Allerdings hatte ich nicht den Eindruck, dass es gefühlt viel schneller wird

• Der Kern von LLM-Inferenz ist Matrix-Vektor-Multiplikation. Wenn mehrere Anfragen gleichzeitig verarbeitet werden sollen, kann man die Vektoren der einzelnen Queries sammeln, zu einer Matrix zusammenfassen und dann per Matrix-Matrix-Multiplikation gleichzeitig berechnen. Aus Sicht der Hardware ist eine einzelne Matrix-Matrix-Multiplikation viel effizienter, als Matrix-Vektor-Multiplikation mehrfach zu wiederholen. Genau das ist Batching. Der zweite Trick ist Speculative Decoding. Inferenz hat zwei Phasen: Prompt-Verarbeitung und Token-Generierung, und beide sind in Wirklichkeit dieselbe Struktur, nämlich ein Forward Pass. Die Prompt-Verarbeitung lässt sich per Matrix-Matrix-Multiplikation parallelisieren, und nur das letzte Ergebnis wird als Startpunkt für die Token-Generierung verwendet. Da man zukünftige Tokens normalerweise nicht im Voraus kennt, lässt sich dieser Teil üblicherweise nicht parallelisieren. Deshalb sagt ein schnelles Draft-Modell die nächsten N Tokens voraus, diese werden in den Eingabeprompt eingefügt, und dann läuft auf dem Hauptmodell ein paralleler Forward Pass. Von den erzeugten N Tokens können alle bis einschließlich des ersten übereinstimmenden Tokens sofort als gültige Tokens übernommen werden. Theoretisch kann man so 2x bis 4x schnellere Inferenz erwarten. Ich habe das beruflich nicht selbst implementiert, vermute aber, dass zusätzlich Dinge wie parallele Gruppierung nach Query-Länge oder Echtzeit-Load-Balancing eingesetzt werden, um Ressourcenungleichgewichte zu vermeiden (denn nicht alle Requests haben dieselbe Länge)