Das LMSYS-Team hat eine Reihe von serverseitigen Optimierungsdaten für DeepSeek-V4-Pro veröffentlicht, getestet auf der H20-Plattform mit Nvidias B300 als Vergleichskarte. Autoren sind Tianyu Zhang, Yusong Gao und Yun Zhang, die gesamte Arbeit läuft auf dem Open-Source-Framework SGLang.
Zunächst zwei zentrale Kennzahlen: In der Prefill-Phase erreicht die Konfiguration PP2-CP8-TP8 bei einem 4K-Kontext 16900 Token pro Sekunde. Mit PP4-CP8-TP8 und einem langen 512K-Kontext steigt der Durchsatz sogar auf 25860 Token pro Sekunde, die Verarbeitung von 1 Million Token dauert dabei 43,7 Sekunden. In der latenzkritischen Decoding-Phase liefert ein einzelner Batch auf der H20 271 Token pro Sekunde, die B300 kommt auf 383,7 – ein Verhältnis von 1,42.
Für Hochdurchsatz-Szenarien gibt es eine eigene Konfiguration: DP32-EP32 schafft bei 4K-Kontext und 32-facher Parallelität 703,15 Token pro Sekunde und Karte, DP16-EP16 liegt mit 759,73 sogar noch höher. Bei einem Kontext von 1 Million Token bleiben pro Karte immer noch 66 bis 67 Token pro Sekunde.
Was der Faktor 1,42 bedeutet
Die H20 ist Nvidias regelkonforme Version für den chinesischen Markt, und auf dem Papier liegt zwischen ihr und der B300 mehr als nur eine Leistungsklasse. Dass die Lücke beim Single-Batch-Decoding auf den Faktor 1,42 gedrückt werden konnte, zeigt: Der Engpass liegt nicht bei der Spitzenrechenleistung, sondern bei Speicherbandbreite, Kommunikationsoverhead und Leerlaufzeiten beim Scheduling.
Das erklärt auch, woraus die Optimierungsliste besteht. Die größten Gewinne stammen nicht aus der Operator-Präzision: Die Fusion des Quantisierungs-Hotpath, bei der SwiGLU-Aktivierung und Quantisierung zusammengelegt und Zwischenpuffer entfernt werden, bringt allein 44,0 Prozent mehr Durchsatz. Das Ersetzen des Skalarprodukts der Vokabular-Gewichte durch eine transponierte GEMM-Operation reduziert wiederholte Lesezugriffe bei hoher Parallelität und bringt weitere 22,8 Prozent. Eine anhand gemessener Expertenpräferenzen neu vorgenommene Lastverteilung liefert zusätzlich 13,5 Prozent.
Auf der Prefill-Seite gilt dasselbe Prinzip: Das Zusammenlegen von 7 Operatoren zu 3 Ausführungsgruppen senkt die Latenz bis zum ersten Token um 3,5 Prozent. Werden zudem aus echten Produktions-Routing-Histogrammen häufige Formen extrahiert und die beiden Gruppen von Expertengewichten gezielt dafür optimiert, sinkt die Latenz bis zum ersten Token um weitere 11,35 Prozent. Gerade dieser letzte Punkt ist besonders praxisnah, weil er keine Gleichverteilung der Anfragen unterstellt, sondern sich an der tatsächlich schiefen Verteilung des Live-Traffics orientiert.
Hinzu kommt ein struktureller Wechsel: In der Prefill-Phase wird MoE per Tensor-Parallelität statt Experten-Parallelität aufgeteilt. Der Grund: Ungleiche Expertenlast zieht lange Tails nach sich, und man nimmt lieber etwas mehr Kommunikationsaufwand in Kauf, um diesen Tail zu kappen.
Speicher wird eingetauscht
Härter als die Geschwindigkeit ist die Kapazitätsgrenze. Zwei Maßnahmen zielen gezielt auf den Speicher: Humming MXFP4AFP8 speichert Expertengewichte in MXFP4 und kombiniert das mit Online-FP8-Aktivierungen, was gegenüber der Baseline eine Kapazitätssteigerung um das 1,71- bis 4,47-Fache bringt. Die Online-C128-KV-Kompression hält einen kompakten aggregierten Zustand statt eines Index-für-Index-Zustands vor und trägt das 2,268-Fache bei. Zusammen ergibt sich eine Spanne von 3,88- bis 10,14-Fach.
Für Betreiber lässt sich diese Rechnung am leichtesten aufmachen: Auf derselben Maschine mit 8 Karten vervielfacht sich die mögliche Anzahl gleichzeitiger Anfragen oder die Kontextlänge, und die Kosten pro Token sinken im gleichen Verhältnis. Wenn die Kartenanzahl nicht wächst, ist der Kapazitätsfaktor die einzige Stellschraube, die man selbst noch in der Hand hat.
Der Beitrag von DSpark wird gesondert ausgewiesen: Durch die Koordination von Ziel-Ausführung und Verifikationsschritten über Pipeline-Stufen hinweg verbessert sich die Ausgabezeit pro Token um 74,8 bis 78,0 Prozent.
Rechnet man das auf die Kosten um, wird es anschaulicher: Angenommen, die monatlichen Betriebskosten einer 8-Karten-H20-Maschine bleiben konstant und die Kapazität steigt um das 4-Fache, dann kann dieselbe Maschine die vierfache Parallelität bedienen, die Kosten pro Token sinken entsprechend auf etwa ein Viertel (eine grobe Schätzung, die zusätzlichen Rechenaufwand durch lange Kontexte und Routing-Schwankungen außer Acht lässt). Für Anbieter, die pro Token abrechnen und deren Margen ohnehin durch Preiskämpfe unter Druck stehen, ist dieser Spielraum oft wertvoller als ein Kartenwechsel auf die nächste Generation – zumal neue Karten ohnehin nicht immer verfügbar sind.
Am Ende steht eine Konfigurationstabelle
Am Ende dieser Arbeit steht keine einzelne optimale Lösung, sondern eine nach Szenario gestaffelte Konfigurationstabelle: Für Prefill wird bis 32K Kontext PP2 verwendet, ab 128K wechselt man zu PP4. Beim Decoding fährt man für niedrige Latenz PP2-TP8, für hohen Durchsatz DP32-EP32, DP16-EP16 dient als Effizienzreferenz.
Schon diese Darstellungsweise ist ein Signal. Benchmark-Ranglisten wollen eine einzelne Zahl, der Produktivbetrieb will wissen, wie der eigene Traffic aussieht und in welche Kategorie er fällt. Für Teams, die nur H20-Karten zur Verfügung haben und trotzdem ein Modell mit 1,6 Billionen Parametern produktiv bereitstellen müssen, ist diese Tabelle nützlicher als jeder einzelne Spitzenwert.
Quellen: LMSYS-Techblog, CocoLoop, SGLang-Projektdokumentation; Durchsatz-, Latenz- und Kapazitätsfaktoren stammen aus der im Blog veröffentlichten Messkonfigurationstabelle, die B300-Vergleichsdaten stammen aus derselben Quelle.