Cline erreicht 11.840 Token pro Sekunde auf einer einzigen GPU mit Nemotron 3.5 Super VL

Von 6.058 auf 11.840 Token pro Sekunde

NVIDIA hat Nemotron 3.5 Super VL am 15. Oktober veröffentlicht. Laut Cline ist das Modell als schnelle, lokal betreibbare Option konzipiert, die in Bereichen wie Dokumentenverständnis, Programmierung und Finanzbuchhaltung ordentliche Ergebnisse liefert. Cline zufolge ist es deutlich schneller als andere Modelle seiner Kategorie, und dank seiner geringen Größe lässt es sich praktikabel für Spezialanwendungen nachtrainieren.

Über eine Zusammenarbeit mit NVIDIA erhielt Cline Zugang zu einer NVIDIA DGX Station, die über ein GPU-Speicherbudget von 252 GB verfügt. Ausgangspunkt war die vLLM-Basiskonfiguration (Version 0.32.0rc1.dev190+g3f1bcfd82), die 67 GB Speicher belegte. Selbst damit maß Cline in einem Test mit 512 Input-/Output-Token und 256 parallelen Streams aggregiert 6.058 Token pro Sekunde. Das Unternehmen weist darauf hin, dass die Basiskonfiguration des Modells bereits auf Inferenz mit hohem Durchsatz abgestimmt ist.

Die fünf Optimierungsschritte

Cline nennt fünf Änderungen, mit denen der Durchsatz gesteigert wurde:

• MTP-Decoding: Das Team nutzte den MTP-Decoding-Head, der mit dem Modell ausgeliefert wird. Mit MTP3 stieg der Durchsatz auf rund 7.000 Token pro Sekunde. Verwendet wurde die OMP1-Konfiguration, da mehrere Threads zusätzlichen Koordinationsaufwand verursachen.
• Asynchrones Scheduling: Bei vielen gleichzeitigen Ausgaben leistet die GPU schwere Kernel-Arbeit, während die CPU aufwendige Scheduling-Aufgaben übernimmt. Asynchrones Scheduling verhindert, dass die Pipeline blockiert wird, solange die GPU rechnet.
• Mamba-Kernel zurück auf FlashInfer: Das Modell nutzt für Attention-Layer einen KV-Cache und für Mamba-Layer einen rekurrenten Zustand samt kurzer Convolution-Historie. Der Wechsel des Mamba-Kernels auf FlashInfer hob den Durchsatz auf 7.800 Token pro Sekunde. Cline erklärt, es sei unklar, warum das funktioniert, und es könne sein, dass es nicht auf jeder GPU-Konfiguration klappt.
• Lookahead von MTP 3 auf MTP 1: Mehr Draft-Token vorherzusagen hilft nicht zwangsläufig, da sie verifiziert werden müssen und fehlgeschlagene Verifizierungen Modellzeit verschwenden. Bei 256 parallelen Threads hat die GPU bereits genug sinnvolle Arbeit, sodass sich der zusätzliche Overhead nicht lohnte. Das steigerte den Durchsatz auf 9,5K.
• Mamba-Zustand von FP32 auf FP16: Cline stellte den Mamba-Zustand auf FP16 mit stochastischem Runden um. Das senkt die Präzision und könnte die Eval-Werte verringern, das Team hielt es angesichts des Ziels maximalen Durchsatzes aber für vertretbar.

Das Endergebnis lag bei aggregiert 11.840 Output-Token pro Sekunde.

Einschränkungen und Clines Prognosen

Cline betont, dass Inference Engineering stark vom Kontext abhängt und die Skalierung vom Traffic-Profil bestimmt wird. Entscheidungen wie MTP 1 statt MTP 3 oder der FlashInfer-Kernel funktionierten für diesen Lasttest, könnten den Durchsatz laut Unternehmen unter anderen Lasten aber genauso gut verschlechtern. Auch die FP16-Umstellung könnte die Eval-Werte senken. Der Rat lautet, das beste Traffic-Profil zu bestimmen und die Inferenz ausschließlich darauf abzustimmen.

Das Unternehmen formulierte außerdem drei längerfristige Prognosen. Erstens: Man werde selbst hosten und Dutzende paralleler lokaler agentischer Threads betreiben können. Cline verweist auf ein Video mit 32 parallelen Clines, die Nemotron 3.5 Super VL auf einer einzigen DGX Station ausführen, und beschreibt es als echtes Material ohne Beschleunigung.

Zweitens: Der Betrieb selbst gehosteter Modelle werde günstiger sein, als für Inferenz zu bezahlen. Clines Überschlagsrechnung, die API-Nutzung mit einer voll ausgelasteten GPU vergleicht, ergab einen Preisnachlass von 66 % bei der Inferenz, sofern die GPU vollständig ausgelastet ist.

Drittens: Autoscaling werde agentisch. Cline stellt sich einen Agenten mit Zugriff auf Grafana-Metriken vor, der Lasttests auf einer zurückgehaltenen GPU durchführt, die beste Konfiguration für den Traffic an einem Endpunkt findet und den Traffic anschließend sicher dorthin migriert.

Was das für Self-Hosting bedeutet

Die Ergebnisse sind Clines eigene Messungen an einem konkreten Setup, einer einzelnen GB300 mit 256 parallelen Anfragen, und das Unternehmen warnt selbst, dass sie sich möglicherweise nicht auf andere Workloads übertragen lassen. Dennoch zeigt die Anleitung, wie viel Durchsatz sich bei einem Open-Weight-Modell allein durch Konfigurationsentscheidungen herausholen lässt. Für Teams, die Self-Hosting erwägen, lautet Clines Botschaft, dass die Einsparungen davon abhängen, die GPU voll auszulasten und die Konfiguration an den tatsächlichen Traffic anzupassen.