Drei Optimierungen für schnellere MoE-Inferenz auf NVIDIA DGX Spark

Ingenieure, die große Sprachmodelle optimieren, stoßen oft an eine Grenze, an der mehr Rechenleistung die Generierung nicht beschleunigt. Eine aktuelle technische Bewertung des Modells Ling-3.0-flash auf der NVIDIA-DGX-Spark-Hardware ergab, dass die Decoding-Leistung durch die Speicherbandbreite und nicht durch die reine Rechenkraft begrenzt war. Durch die gezielte Bekämpfung spezifischer Engpässe beim Lesen der Gewichte und bei der Token-Verifikation erreichten die Forscher erhebliche Latenzreduzierungen ohne Genauigkeitsverlust.

Was passiert ist

Die Bewertung konzentrierte sich auf Ling-3.0-flash, ein Mixture-of-Experts-(MoE)-Modell von Inclusion AI mit insgesamt 124 Milliarden Parametern, aber nur 5,1 Milliarden aktiven Parametern pro Token. Bei einer Batch-Größe von eins zeigten Profilierungstools, dass die Zeit für die Token-Generierung von zwei Operationen dominiert wurde: der MoE-Berechnung selbst und der Ausgabe-Layer-Projektion, bekannt als LM-Head. Diese Schritte erforderten das Lesen großer Mengen an Gewichtungsdaten aus dem Speicher, was einen Engpass schuf, den Standardoptimierungstechniken nicht vollständig beheben konnten.

Um dies zu lösen, testete das Team drei unterschiedliche Optimierungen. Erstens ersetzten sie den standardmäßigen FlashInfer-MXFP4-MoE-Backend durch die Humming-Kernel-Bibliothek. Zweitens wandten sie online FP8-Quantisierung speziell auf den LM-Head an, um dessen Speicherbedarf zu reduzieren. Drittens implementierten sie spekulatives Decoding mit Multi-Token-Vorhersage unter Verwendung der im Modell integrierten NEXTN-Ebene. Jede Änderung zielte auf einen anderen Aspekt der Inferenz-Pipeline ab, von der Effizienz der Kernel-Ausführung über das Datenvolumen bis hin zur Reduktion der Schrittanzahl.

Die Ergebnisse wurden sowohl auf synthetischen Workloads als auch auf dem vollständigen GSM8K-Testset gemessen. Während synthetische Tests aufgrund repetitiver Ausgabemuster massive Gewinne zeigten, demonstrierte die reale Bewertung auf 1.319 GSM8K-Fragen eine Steigerung des Decode-Durchsatzes um 42,5 % und eine Reduktion der mittleren Latenz um 24,5 %. Entscheidend war, dass diese Verbesserungen ohne statistisch nachweisbare Veränderung der Modellgenauigkeit einhergingen; der Score blieb bei 96,82 % im Vergleich zum Baseline-Wert von 96,89 %.

Wie es funktioniert

Die erste Optimierung nutzt Humming, eine unabhängige Kernel-Bibliothek, die die NVIDIA CUDA Runtime Compilation verwendet, um Code zu generieren, der auf die spezifischen Dimensionen des Modells zugeschnitten ist. Im Gegensatz zum Baseline-Pfad von FlashInfer, der viele generische Ziele kompiliert, erstellt Humming spezialisierte Binärdateien für die tatsächlichen Matrixformen, die von Ling-3.0-flash verwendet werden. Diese Spezialisierung reduziert die Zeit pro ausgegebenem Token, indem sichergestellt wird, dass die GPU nur die für die schmale Zwischengröße des Modells erforderlichen Anweisungen ausführt.

Die zweite Technik adressiert den LM-Head, der verborgene Zustände auf ein Vokabular von über 157.000 Tokens projiziert. In der Baseline-Konfiguration verwendet diese Ebene BF16-Präzision, was für jedes generierte Token erhebliche Speicherbandbreite erfordert. Durch den Wechsel zu online FP8-Quantisierung nur für diese Ebene halbiert das System das Volumen der während jedes Schritts gelesenen Gewichtungsdaten. Diese Änderung ist exklusiv gegenüber der Baseline-Option FP32-LM-Head und erfordert eine sorgfältige Konfiguration, um Kompatibilitätsprobleme mit anderen Teilen des Modells zu vermeiden.

Die dritte Methode verwendet spekulatives Decoding, um mehrere Tokens in einem einzigen Verifikationsdurchgang zu generieren. Ling-3.0-flash enthält eine native NEXTN-Ebene, die als Entwurfsmodell fungiert und nachfolgende Tokens vorhersagt, die dann vom Hauptmodell verifiziert werden. Anstatt ein Token nach dem anderen zu generieren, entwirft das System drei Tokens und verifiziert gleichzeitig vier Positionen. Dieser Ansatz reduziert die Gesamtzahl der erforderlichen Decode-Schritte, erhöht jedoch die Komplexität jedes Verifikationsschritts aufgrund höherer Aktivierungszahlen der Experten.

Wichtige Details

• Ling-3.0-flash hat 124 Milliarden Parameter insgesamt mit 5,1 Milliarden aktiven Parametern pro Token über 42 Ebenen hinweg.
• Der Ersatz des FlashInfer-Backends durch Humming reduzierte die Zeit pro ausgegebenem Token von 27,71 ms auf 25,35 ms, was einem Gewinn von 9,3 % entspricht.
• Die online FP8-Quantisierung des LM-Heads halbierte das Volumen der gelesenen Gewichte für diese Ebene und trug zu einer kumulativen Durchsatzverbesserung von 21,7 % bei.
• Multi-Token-Vorhersage mit NEXTN erreichte auf synthetischen Daten 3,90 akzeptierte Tokens pro Runde und steigerte den Durchsatz in diesem spezifischen Test um 185,1 %.
• Auf dem GSM8K-Benchmark erhöhten die kombinierten Optimierungen den Decode-Durchsatz um 42,5 % und reduzierten die mittlere Latenz um 24,5 %.
• Die Genauigkeit blieb stabil und sank nur um 0,08 Prozentpunkte von 96,89 % auf 96,82 %, was statistisch nicht signifikant ist.

Warum das wichtig ist

Für Entwickler, die agentische Workflows oder Echtzeitanwendungen erstellen, ist die Latenz oft die primäre Einschränkung. Diese Analyse bestätigt, dass die Speicherbandbreite und nicht nur die Rechenleistung der limitierende Faktor für viele MoE-Modelle bei niedrigen Batch-Größen ist. Durch die Fokussierung auf die Reduktion des Gewichtstransfers und die Erhöhung der Tokens pro Schritt können Ingenieure erhebliche Leistungssteigerungen erzielen, ohne größere Hardware-Cluster zu benötigen. Dies ist besonders relevant für Edge-Bereitstellungen oder kostensensible Cloud-Umgebungen, in denen jede Milliseconde zählt.

Allerdings hebt die Studie auch die Risiken hervor, Optimierungen ohne tiefgreifendes Integrationswissen zu kombinieren. Die Forscher fanden heraus, dass die Aktivierung der FP8-LM-Head-Quantisierung und der Multi-Token-Vorhersage zusammen erforderte, dass das Entwurfsmodell das gesamte LM-Head-Modul teilt. Ohne diese spezifische Schnittstelle fiel das System stillschweigend auf eine langsamere Konfiguration zurück und interpretierte FP8-Gewichte als BF16. Dies unterstreicht die Bedeutung, jede Optimierung beim Start zu validieren, anstatt die Kompatibilität basierend auf Tests einzelner Komponenten anzunehmen.

Was Sie tun können

• Profilieren Sie Ihre aktuelle MoE-Inferenz-Pipeline, um festzustellen, ob das Decoding speicherbegrenzt oder rechenbegrenzt ist, bevor Sie Optimierungen anwenden.
• Testen Sie die Humming-Kernel-Bibliothek als Drop-in-Ersatz für FlashInfer, wenn Ihr Modell spezialisierte Matrixdimensionen hat.
• Aktivieren Sie die online FP8-Quantisierung für den LM-Head über die Umgebungsvariable SGLANG_ENABLE_FP8_LM_HEAD, um die Nutzung der Speicherbandbreite zu reduzieren.
• Implementieren Sie Multi-Token-Vorhersage unter Verwendung nativer Entwurfsebenen wie NEXTN, um die Anzahl der sequenziellen Decode-Schritte zu reduzieren.
• Stellen Sie sicher, dass Entwurfs- und Zielmodelle die richtigen Module teilen, wenn Quantisierung mit spekulativem Decoding kombiniert wird, um stille Leistungseinbußen zu vermeiden.
• Benchmarken Sie Änderungen auf realistischen Workloads wie GSM8K, anstatt sich ausschließlich auf synthetische Tests zu verlassen, die die Vorteile des spekulativen Decodings möglicherweise überschätzen.