Wie man GPT-OSS-120B mit mehr als 500 Tokens pro Sekunde auf NVIDIA-GPUs ausführt

• Das OpenAI-Open-Source-LLM GPT-OSS-120B wurde in einer NVIDIA-GPU-Umgebung auf eine Leistung von mehr als 500 Tokens pro Sekunde optimiert
• Verschiedene Inferenz-Frameworks wie TensorRT-LLM, vLLM und SGLang wurden parallel getestet, wodurch sowohl die Hopper- als auch die Blackwell-Architektur unterstützt wird
• Bei der Arbeit wurden Kompatibilitätsfehler behoben sowie neue Antwortformate wie Harmony, KV-Cache-aware Routing und Eagle-basiertes Speculative Decoding integriert
• Nach dem Vergleich von Tensor Parallelism und Expert Parallelism wurde zur geringeren Latenz Tensor Parallelism gewählt und auf Blackwell der TensorRT-LLM-MoE-Backend eingesetzt
• Für die Zukunft sind weitere Optimierungen geplant, unter anderem Speculative Decoding mit einem kleinen Draft-Modell

---

Überblick

• Mit der Veröffentlichung von OpenAIs neuesten Open-Source-LLMs GPT-OSS-120B ging Baseten direkt an die Umsetzung von Top-Performance
  • Baseten ist ein offizieller Launch-Partner von OpenAI
• Auf Basis echter Nutzerdaten von OpenRouter wurde in einer NVIDIA-GPU-basierten Umgebung die bessere Performance gegenüber Wettbewerbern nachgewiesen
• Dank des flexiblen Inferenz-Stacks und der Expertise des Modell-Engineering-Teams konnten Optimierungspatches innerhalb von Stunden ausgerollt werden
• Bereits während der ersten Stunden der Blogserien wurden zusätzlich 100 Tokens pro Sekunde gewonnen, bei 100 % Verfügbarkeit

Leistungsgoptimierung

• Es wurden Tests und Benchmarks mit verschiedenen Inferenz-Frameworks wie TensorRT-LLM, vLLM und SGLang durchgeführt
• Gleichzeitig wurde die Kompatibilität mit den GPU-Architekturen Hopper und Blackwell sichergestellt
• Baseten integrierte den Flexible Inference Stack und Schlüsselkomponenten wie NVIDIA Dynamo
• Es wurden fortlaufend bewährte Optimierungstechniken wie KV-cache-aware routing und Speculative Decoding (auf Basis von Eagle) angewendet

Im Folgenden sind die Kernschritte für die gleichzeitige Erreichung von SOTA-Performance und vollständiger Kontextfenster-Unterstützung zusammengefasst

Schritt 1: Erste Inferenzausführung

• Der erste Schritt ist, die Erstinferenz (baseline inference) so schnell wie möglich auszuführen, unabhängig von der gewählten Methode
• Inspiriert von der GPU-Performance liefen parallel mehrere Ingenieure Tests mit vLLM, SGLang und TensorRT-LLM parallel
• TensorRT-LLM, das beste Performance lieferte, wurde rasch betriebsbereit gemacht
• Für Hopper (mit den meisten H100-GPUs) und Blackwell (mit deutlich höherer Geschwindigkeit durch B200) wurde die TensorRT-LLM-Unterstützung sichergestellt
• Dank der Flexibilität der Baseten Inference Runtime war es einfach, neue Architekturen aufzunehmen und Werkzeuge im Stack schnell auszutauschen

Schritt 2: Kompatibilitätsfehler beheben

• Neue Modellarchitekturen gehen bei der Framework-Integration oft mit häufigen Bugs einher
• GPT-OSS enthält neue Features wie das Harmony-Antwortformat, wodurch es bei der Integration in bestehende Frameworks zu Fehlern kam
• Zur Sicherung von Geschwindigkeit und Genauigkeit wurden wiederholte Korrekturen und Tests durchgeführt; wirksame Fixes wurden in Open Source eingebracht
• Durch die Zusammenarbeit der globalen Open-Source-Community laufen verschiedene Optimierungspfade und Bugfixes inzwischen sehr schnell

Schritt 3: Modellkonfiguration optimieren

• Obwohl OpenAI angibt, dass GPT-OSS 120B auch auf einer einzelnen H100 läuft, ist in der Praxis eine Parallelisierung über 4–8 GPUs für bessere Performance vorteilhaft
• Tensor Parallelism ist bei der Latenz stark, Expert Parallelism bei Durchsatz (throughput)
  • Da Baseten auf Latenzoptimierung ausgerichtet ist, wurde Tensor Parallelism gewählt
• Auf Blackwell wurde ein TensorRT-LLM-MoE-Backend genutzt, das die CUDA-Kernel-Leistung gegenüber dem bisherigen Triton-Backend verbessert
• Für Hopper- und Blackwell-Umgebungen wurden jeweils optimierte Einstellungen veröffentlicht, und in der Model API wird das Blackwell-Setup genutzt

Weitere Leistungsoptimierung

• Mit der ersten Optimierungsrunde wurde bereits SOTA-Durchsatz und -Latenz erreicht, doch es gibt weiterhin viel Verbesserungspotenzial
• Die wichtigsten geplanten Updates sind die Einführung von Speculative Decoding
  • Dieses Verfahren lässt ein schnelleres kleines „Draft“-Modell Tokens vorhersagen, die anschließend vom Hauptmodell validiert werden
  • Baseten empfiehlt Eagle 3, nutzt im Inferenz-Stack jedoch je nach Scenario flexibel mehr als 10 Algorithmen
• Speculative Decoding decodiert mehrere Tokens auf einmal und ermöglicht so eine effiziente Beschleunigung

[jjw951215]

Ich hätte doch auch nur eine kleine, niedliche H100, wenn mir sie nur jemand geben würde...

[GN⁺]

Hacker News Kommentar

• widely-available H100 GPUs
  Als ich in meinem Teilekasten zu Hause gewühlt habe, fragte ich mich: Warum gibt es keine H100-GPU für 25.000 US-Dollar?

  • Auf der NVIDIA-Produktseite habe ich selbst gesehen, dass H100 wirklich als „GPU“ geführt wird. Wir brauchen meines Erachtens einen klareren Namen, der besser zwischen „verbraucherorientierter Hardware, die primär fürs Gaming genutzt wird, aber nur sehr eingeschränkt für LLM-Inferenz geeignet ist“, und „Business-Hardware, deren Hauptzweck KI-Training oder LLM-Inferenz ist“, unterscheidet.
  • Ich habe mit Ollama ein 20B-Modell auf acht Titan X-Karten (Baujahr 2015) ausgeführt. Ollama verteilte die gesamten 15 GB VRAM gleichmäßig auf die acht Karten, und die Token-Rate war sogar schneller als die reine Lesegeschwindigkeit.
  • Solche GPUs kann man wirklich leicht mieten. Wenn man den Betrieb nicht dauerhaft rund um die Uhr plant, ist es deutlich günstiger, Hosting zu nutzen als selbst zu kaufen. Für den privaten Einsatz brauche ich selten modernste datacenterklassige Karten; in solchen Fällen reichen Mac Studio oder Strix Halo aus, sind aber etwas langsamer.
  • Dieser Kommentar hat meinen Tag gerettet. Das war klar aus Datacenter-Perspektive gedacht, und das schnellste Teil in meinem Fach ist wohl ein altes iPhone 8.
  • Dass ein „25.000-Dollar-Setup daheim“ nicht vorhanden ist, bedeutet nur, dass man so ein Gerät zwar bekommen könnte, es ist aber kein Hinweis darauf, dass man es sich auch leisten kann.

• Ich habe GPT-OSS-120B auf einem MacBook Pro (M4, 128 GB RAM) während eines Fluges über den Atlantik ausprobiert.
  Es ist nur dann schnell, wenn das Kontextfenster klein ist und die Gesamtzahl der Token gering bleibt. Geht sie über 10.000, dauert fast alles lange und baut sich in der Queue auf.
  MCPs, Websuche, URL-Patching und Ähnliches sind bereits zu einem sehr wichtigen Teil der LLM-Nutzung geworden. Fehlen diese Funktionen, sinkt der Nutzen eines LLM deutlich.
  Die für Offline-Betrieb vorab eingerichteten CLI/TUI-Coding-Tools (z. B. opencode) liefen mit dem Modell nicht zuverlässig.
  Bei OSS-Modellen gibt es noch weitere Auffälligkeiten, neben den bereits in früheren Kommentaren häufig genannten:

  • Früher konnte man Wikipedia lokal speichern; daher glaube ich, dass bald viele Daten via MCP freigelegt werden und AIs lokal wie bei „Websuche“ abgefragt werden. 99 % der Websuchen finden auf denselben 100 bis 1000 Seiten statt. Zusammengefasst reichen ein paar GB, um vieles abzudecken — die Urheberrechtsfragen bleiben damit bestehen.
  • Ich frage mich, ob man Ollama, LMStudio oder llama.cpp nutzt ggerganov Tweet
  • Ich frage mich, wie ihr iogpu.wired_limit_mb gesetzt habt. Beim Standardwert kann die GPU nur etwa 70 % des RAM, also rund 90 GB, nutzen. Um mehr auszuschöpfen, muss der Wert angepasst werden.
  • Ich habe es mit einem M2 Max gemacht. Bei kurzen Sessions waren es über 60 Token/s, bei längeren sank es auf 30. Ich frage mich, was die Ursache ist; es schien kein Thermal-Issue zu sein.
  • Ich glaube, das ist Compute-bound Prefill (hohes CPU-Bandbreiten-/Rechenverhältnis) versus Decode. Selbst bei 10.000 Kontext-Token dauert es weniger als 0,5 Sekunden bis zum ersten Token.

• Mehrere Ingenieure haben vLLM, SGLang und TensorRT-LLM parallel ausprobiert. TensorRT-LLM gilt offenbar als am schnellsten, ist aber meistens am schwierigsten zu konfigurieren, zieht neue Architekturen nur unzureichend nach und ist wegen des direkten Kompilierens im exakt gleichen Hardware-/Treiber-/Bibliotheks-Stack wie die Prod-Umgebung sehr umständlich. Für eine Zeitlang war Multimodal fast unmöglich; selbst ein prominentes Llama-Multimodal-Modell funktionierte nicht korrekt. Ob das wertvoll ist, ist fraglich, aber z. B. läuft GPT-OSS-120B auf H100 mit vLLM problemlos und liefert solide 130~140 t/s. Nach dem Titel hätte man 500 t/s pro GPU erwartet, aber in Wahrheit ist es Tensor-Parallel-Setup. Dass gpt-oss separat für TRT-LLM paketiert wurde, ist irgendwie komisch. TRT-LLM selbst ist sowieso ein etwas verwirrendes Tool.

  • Wer TRT-LLM in der Praxis nutzt, merkt: Auf DX-Seite gibt es viele Hürden. Bei Multimodal setze ich nach wie vor häufig vLLM ein. Trotzdem haben wir bei großem Volumen und Low-Latency wie in unserem Produktiv-Traffic in Benchmarks immer wieder gesehen, dass TRT-LLM besser abschneidet, deshalb haben wir dort stark in dieses Tooling investiert.

• GPT-OSS 20B ist wirklich einfach zu installieren. Dank Llama lief es auf meinem Mac in 5 Minuten.

  • Wenn genug CPU-Ressourcen vorhanden sind, lässt sich 120B ebenfalls problemlos betreiben. Zu Hause reichte es auf dem LLM-CPU-Inferenzserver, die GGUF-Datei herunterzuladen, git pull zu machen und llama-server neu zu bauen; danach lief es sofort. 40 t/s ohne Änderungen und etwa 50 t/s nach etwas Tuning. Schade, dass es inzwischen schon deutlich bessere Modelle als 120B gibt, sodass ein Betrieb nicht zwingend nötig ist. Ich finde es großartig, wie ggerganov und das llama.cpp-Team LLMs für den persönlichen Einsatz demokratisiert haben.
  • Alle sagen, dass LLM-Setup schwierig sei. Aber warum richtet man das nicht einfach per LLM ein? Wenn selbst so eine einfache Aufgabe nicht geht, frage ich mich, welche Bedeutung LLM dann noch haben sollen.
  • Ich habe es gestern getestet und in jeder Session kamen weiterhin falsche Fakten. Geschwindigkeit und Komfort sind gut, aber ohne Genauigkeit ist es bedeutungslos.
  • Wenn genug Speicher vorhanden ist, läuft 120B ebenfalls wirklich einfach.

• Beim Lesen habe ich gelernt, dass man enorme Datenvorbereitung und Tuning braucht, um ein Modell sauber zu betreiben. Ich dachte bis dahin, die Standardeinstellungen würden ausreichen.

  • Meiner Meinung nach sollten große Unternehmen vor dem Release ihrer LLMs enger mit beliebten Inferenz-Engine-Entwicklern zusammenarbeiten, damit diese ihre eigenen LLMs ebenfalls unterstützen. Viele Dinge sind noch experimentell, aber es wird gerade großer Aufwand investiert, damit Entwickler LLMs auch auf preiswerter Hardware einsetzen können.

• Im US AI Action Plan steht „Open-Source- und Open-Weights-KI fördern“ direkt vor „Frontier KI zum Schutz der freien Meinungsäußerung und der amerikanischen Werte“. Das ist nicht unbedingt logisch, aber OpenAI-OSS-Modelle jetzt zu lesen, fühlt sich etwas gruselig an. Dass sich ein OSS-Modell-Anbieter zu Hardware äußert, ist dennoch gut; für die meisten Entwickler ist Hardware die Einstiegshürde, also freut es mich, dass darüber gesprochen wird.

  • Auch der Punkt „Frontier KI soll Freiheit und amerikanische Werte schützen“ wurde erwähnt; ich bin noch dabei, meine Gedanken dazu zu sortieren, bitte etwas Geduld. KI-Modelle tragen zwangsläufig eine Weltanschauung in sich und ich bevorzuge eher eine westliche. Das hat es öfter geschafft, bessere Gesellschaften zu erzeugen. Zumindest wäre es wünschenswert, dass Modelle ihre eigene Weltanschauung dokumentieren und sich daran orientieren, statt Nutzer stillschweigend sozialtechnisch in ihrer Denkweise umzuprogrammieren.

• Kennt jemand eine Website, die klar sagt, welche LLMs gut auf welchem OS und welcher GPU laufen? Meine bisher zuverlässigste empirische VRAM-Formel war: Parameterzahl × (Precision/8) × 1.2 (Hinweis)

  • Ich habe versucht, so einen Rechner zu bauen, aber in der Praxis gibt es zu viele Variablen (gleichzeitige Last etc.). Die Formel ist grob korrekt, aber bei hoher gleichzeitiger Last ist es sicherer, den Wert zu verdoppeln.
  • Wenn man auf Hugging Face seine Hardware-/Software-Spezifikationen einträgt, zeigt das auf jeder Modell-Detailseite an, ob das Modell nutzbar ist Hugging Face Einstellungen
  • Ich habe eine gute Internetanbindung, daher ist es am schnellsten, die Modellgewichtsdateien herunterzuladen und sie selbst mit verschiedenen Runnern (llama.cpp, LM Studio, vLLM, SGLang usw.) zu testen. Wegen der vielen Variablen bei Runner/Implementierung/Hardware hat sich noch keine Rechnung exakt mit realen Erfahrungen gedeckt. Man kommt am Ende nur durch tatsächliches Ausprobieren weiter.
  • Danke für eure Meinungen. Wenn Berechnungen schwer sind, wäre es sinnvoll, eine Community-DB aufzubauen, auf der alle Runner, Hardware, Modell, Parameter, Quantisierung, Funktionalität, Tokens/s und ähnliche Kennzahlen durch die Community experimentell geteilt werden. Das wäre sehr praktikabel, wenn man sofort nach Hardware/Runner-Kombination filtern könnte.

• Die exakten Zahlen zur realen Array- oder Layergröße von GPT-OSS-120B zu finden, ist überraschend schwer. In statisch typisierten Sprachen könnte man die Größe der Arrays „einfach so“ erkennen; ich möchte aber wissen, wie die realen Daten (nicht nur die Gewichte) fließen und wie breit der Ausgabestream ist. Ich bin gespannt, wie hoch die maximale „Token-Output“-Bandbreite bei Gigabit-Ethernet ist, deshalb habe ich nach dem GitHub-Repo gpt-oss gesucht, aber kaum etwas gefunden.

  • Ich frage mich, welche Anwendungen alle aufeinanderfolgenden Tokens per Streaming verarbeiten (wobei das Token-Sampling regelkonform erfolgt). Man sollte dabei berücksichtigen, dass man typischerweise vor dem Sampling Logits aufbereiten und Tokens zurückgeben muss, damit Grammatik passt, bevor die nächste Inferenz startet.
  • In der Hugging Face Modellkonfiguration sind 2.880 Werte zu sehen (dtype-Multiplikation).

• GPT-OSS läuft auf Blackwell-Chips schneller dank fp4-Unterstützung. Wir bauen derzeit eine Trainings-/Inferenz-Engine in Rust und fügen fp8- und fp4-Support in cudarc und candle hinzu. cudarc PR, candle PR, Mixlayer – wir arbeiten daran, diese Modelle in der Mixlayer-Engine zu unterstützen.

  • Ich bin RTX Pro 6000-Nutzer und frage mich, ob eine Inferenz von gpt-oss-120b derzeit möglich ist. Die PRs scheinen bereits gemergt zu sein; ich frage mich, ob der reale Lauf schon funktioniert.