Das Team des Open-Source-Inferenz-Frameworks vLLM hat gemeinsam mit Inferact am 7. Oktober einen technischen Blogbeitrag veröffentlicht, der eine ganze Reihe von Inferenzoptimierungen für DeepSeek-V4.1-Flash beschreibt. In Tests, die agentenbasierte Workloads simulieren, stieg die Geschwindigkeit bei geringer Parallelität um das 1,9-Fache; wird die Ausgabegeschwindigkeit pro Nutzer auf 150 Token pro Sekunde begrenzt, steigt der Gesamtdurchsatz um das 5,3-Fache.
Als Testlast diente der AgentX-Benchmark von SemiAnalysis, den das Team als repräsentativ für Agenten-Serviceszenarien betrachtet: mehrstufige Dialoge, lange Kontexte und eine Session-Affinität, die Prefix-Cache-Trefferquoten aufrechterhält. Die Low-Latency-Konfiguration nutzt Tensor-Parallelismus über vier Karten plus FlashInfer, die High-Throughput-Konfiguration zweifachen Daten-Parallelismus plus Experten-Parallelismus.
Besonderheiten des Modells selbst
Laut Blogbeitrag verwendet V4.1 Flash eine kausale Encoder-Decoder-Architektur mit insgesamt 40 Schichten, wobei Schicht 20 für die Berechnung des globalen KV zuständig ist, das der Decoder nutzt. In der Generierungsphase aktiviert jedes Token rund 16 Milliarden Parameter, in der Prefill-Phase etwa 8 Milliarden. Der globale KV-Cache wird komprimiert und über Schichten hinweg geteilt und belegt bei FP4-Präzision nur etwa 890 Byte pro Token; zusätzlich gibt es ein Sliding-Window-KV, das die letzten 128 Positionen abdeckt und unkomprimiert in FP8 gespeichert wird.
Ein so kleiner Cache hat eine direkte Folge: Über den gesamten Benchmark-Lauf musste der KV-Cache nicht in den Arbeitsspeicher oder auf die Festplatte ausgelagert werden. Bei Agenten-Aufgaben mit langem Kontext ist genau dieses Auslagern oft eine Hauptursache für Latenzverzögerungen.
Die wichtigsten der acht Optimierungen
Das Team listet acht Änderungen auf, von denen einige den größten Effekt zeigen:
- Begrenztes Replay im Sliding Window: Bei einem Prefix-Cache-Treffer werden die letzten 128 Token direkt neu berechnet, kombiniert mit CUDA Graph sinkt die Latenz bis zum ersten Token um etwa 30 Prozent. Bei einem Kontext von rund 100.000 Token sinkt diese Latenz um fast 70 Prozent. Diese Funktion ist bei V4.1 standardmäßig aktiviert und lässt sich mit dem Flag
--no-swa-bounded-replayabschalten. - Sparse-MQA-Scoring-Kernel: bei 512K-Kontext 14- bis 23-mal schneller als die ursprüngliche Implementierung, bei 8K nur 1,2-mal schneller, was sich auf die gesamte Decoding-Phase mit etwa 3 bis 6 Prozent niederschlägt.
- NVFP4-Attention: der KV-Cache fällt 45 Prozent kleiner aus als bei der vorherigen FP8-Lösung, der entsprechende Schritt wird um etwa das 1,45-Fache schneller.
- Engram-Lookup: asynchrones Prefetching kombiniert mit Transparent Huge Pages beschleunigt die schnellsten Lookups um etwa das 10-Fache.
Weitere Änderungen betreffen die Fusion von Operatoren: Mehrere Schritte des Mixture-of-Experts-Routings werden in einem einzigen Kernel zusammengefasst, was bei mittleren Batchgrößen 1,18- bis 1,31-mal schneller ist; die mHC-bezogenen Kernel sind auf GB200 im Vergleich zur TileLang-Version 1,14- bis 1,51-mal schneller.
Bei der Genauigkeit hat das Team Vergleichstests auf GSM8K und GPQA durchgeführt und bezeichnet den Qualitätsverlust als „negligible" (vernachlässigbar), mit einer Abweichung innerhalb von etwa 1,5 Standardfehlern. Weitere Benchmark-Ergebnisse auf anderen Aufgaben nennt der Blogbeitrag nicht.
Wie viel davon in China nutzbar ist
Alle diese Zahlen stammen von Nvidias Blackwell-Plattform. Aufgrund der US-Exportkontrollen ist es für chinesische Institutionen sehr schwer, an Karten wie GB200 oder GB300 zu kommen; NVFP4 ist außerdem ein Datenformat, das es nur auf Blackwell gibt, sodass sich die entsprechenden Vorteile auf H20 oder heimischen Beschleunigerkarten nicht direkt reproduzieren lassen.
Übertragbar ist vor allem der Teil auf Scheduling- und Cache-Ebene. Sliding-Window-Replay, Session-Affinität und der Verzicht auf KV-Auslagerung sind weniger stark an die Hardware gebunden; der Code ist bereits in den vLLM-Hauptzweig eingeflossen, sodass Teams, die dasselbe Modell nutzen, davon allein durch ein Versionsupdate profitieren. Den Fortschritt bei der Integration der einzelnen Kernel verfolgt vLLM zentral in Issue Nummer 57448 auf GitHub. Wie groß der tatsächliche Geschwindigkeitsgewinn auf heimischen Chips ausfällt, hat bislang kein Dritter getestet.
Quellen: offizieller technischer Blog von vLLM, CocoLoop, Beschreibung des AgentX-Benchmarks von SemiAnalysis; die Blog-Daten wurden hinsichtlich der Geschwindigkeitsfaktoren der einzelnen Optimierungen, der Testhardware und der Parallelisierungskonfiguration geprüft.