TensorRT-LLM 1.4 RC ändert KV-Cache-Standards

TensorRT-LLM 1.4.0 Release Candidate benötigt ein gestaffeltes Upgrade

NVIDIA hat am 22. Oktober UTC den Open-Source-Release-Kandidaten TensorRT-LLM „v1.4.0rc1“ veröffentlicht. Die Versionshinweise behandeln Modellunterstützung, Bereitstellung von APIs, KV-Cache-Verwaltung, Dekodierungspfade und hardwarespezifische Optimierungen. Ein Release Candidate ist ein nützliches Integrationsziel für Teams, die eine dieser Änderungen benötigen, aber es ist nicht dasselbe wie ein allgemein bewährter Produktions-Build. Die Notizen selbst weisen auf bekannte Probleme hin. Eine davon betrifft abgebrochene Streaming-Anfragen mit disaggregierter Bereitstellung und dem standardmäßigen Python-KV-Cache-Transceiver auf A100; Ein anderer sagt, dass ein JSON-Schema-Bereitstellungsbeispiel mit Qwen3-Modellen eine unbegrenzte Ausgabe zurückgeben kann. Diese Vorbehalte sollten Teil jedes Evaluierungsplans sein und nicht hinter der Funktionsliste verborgen bleiben.

Cache-Standardwerte sind eine Kompatibilitätsänderung

In den Notizen werden zwei API-Änderungen als inkompatible Änderungen gekennzeichnet: Der KV-Cache-Manager V2 und der Python-KV-Cache-Transceiver werden zu Standardeinstellungen, und nicht verwendete „LlmRequest“-Felder werden entfernt. Ein von einer früheren Version aktualisierter Dienst kann daher sein Verhalten ändern, selbst wenn dies in seiner eigenen Konfigurationsdatei nicht der Fall ist. Teams, die Prefill- und Decodierungstrennung, Anfrageabbrüche oder einen externen Cache-Connector verwenden, sollten diese Pfade explizit testen. NVIDIA fügt einen Mooncake-Connector für den KV-Cache-Manager V2 hinzu, eine API zum Ausleihen von Ressourcen für Übertragungs-Backends, natives KV-Ereignis-Streaming und Routing-Load-Exposition. Dabei handelt es sich um nützliche Grundelemente für Operatoren, die Arbeit platzieren und den Status zwischen Workern verschieben müssen, aber die Freigabeseite stellt nicht für jede Topologie einen Durchsatzgewinn dar.

Das spezifische Stornierungsproblem verdeutlicht das Risiko eines versteckten Zustandsübergangs. Ein Client kann einen Stream schließen, nachdem er genügend Ausgabe erhalten hat; Der Server verfügt noch über den Cache-Status und die abzugleichende Übertragungsarbeit. Wenn ein Transceiver nach diesem Abbruch ausfällt, können spätere Generierungsanforderungen beeinträchtigt sein. Ein kontrollierter Auslastungstest sollte normale Abschlüsse mit absichtlichen Client-Trennungen kombinieren, Fehlerraten und Cache-Bereinigung prüfen und auf derselben Hardware und demselben Bereitstellungsmodus wiederholen, die für die Bereitstellung geplant sind. Ein einfacher Latenz-Benchmark für eine Anforderung würde diesen Fehlermodus übersehen. Es wird berichtet, dass das Problem beim A100 aufgetreten ist, daher sollte es nicht als universell für alle GPUs gelten.

Modell- und Präzisionsunterstützung wird erweitert

Die Version bietet Unterstützung für die Checkpoints DeepSeek-V4.1-Flash und NVFP4 GLM-5.3-Flash sowie ein experimentelles Modeling V2-Ziel für Qwen3.8-Flash-Next NVFP4. Außerdem werden DFlash-Draft-Checkpoints für LiLiCorr erwähnt und das Fallback-Verhalten für Nemotron-H NVFP4 auf Hopper geändert. Jeder Eintrag ist ein Kompatibilitätsanspruch für ein bestimmtes Modellformat und einen bestimmten Ausführungspfad. Dies ist keine Aussage darüber, dass die Modellausgaben oder die Leistung bei allen Präzisionen identisch sind. Teams sollten die Lizenz, den Tokenizer, die Chat-Vorlage, die numerische Toleranz und die repräsentative Ausgabequalität eines Kontrollpunkts überprüfen, bevor sie eine bekanntermaßen gute Bereitstellung ersetzen. Die Quantisierung kann den Speicher reduzieren oder den Durchsatz verbessern und gleichzeitig das Edge-Case-Verhalten ändern, insbesondere bei langen oder strukturierten Ausgaben.

NVIDIA listet außerdem Optionen für RoPE-Präzision bei der NVFP4-Cold-Page-Komprimierung, eine progressiv gefüllte Host-Cache-Ebene und Neuverteilungsparameter für Cache-V2-Pools auf. Diese Knöpfe legen Ressourcenkompromisse offen, mit denen ein ausgelasteter Server-Cluster konfrontiert ist: GPU-Speicher, Host-Speicher, Übertragungszeit und Antwortlatenz. Eine nützliche Messung zeigt alle vier, wobei p50 und Tail-Latenz unter derselben Eingabeaufforderungslängenverteilung liegen. Die Versionshinweise erwähnen viele Hardware-Pfade, darunter Rubin-Unterstützung, Blackwell CuTe DSL-Arbeit und Aufmerksamkeitsvarianten. Sie sollten als architekturspezifische Entwicklungen behandelt werden, bis sie auf den vorgesehenen Maschinen getestet werden. Eine Schlagzeile über eine GPU-Familie sollte nicht in das Budget einer anderen kopiert werden.

Strukturierte Ausgabe und Determinismus erfordern ihre eigenen Tests

Der Vorbehalt für das JSON-Schema-Beispiel für Qwen3 ist wichtig für Agentensysteme, die begrenzte maschinenlesbare Antworten erwarten. Eine Schemafunktion ist betrieblich nicht nützlich, wenn ein Client unbegrenzt warten oder ein abgeschnittenes Objekt akzeptieren kann, ohne es zu merken. Die Version fügt außerdem deterministische FP32 GVR V2 Top-K-Dekodierung hinzu und berücksichtigt Seeds pro Anfrage in bestimmten Batch-Sampling-Pfaden. Deterministisches Verhalten ist auf die angegebenen Pfade beschränkt und kein pauschales Versprechen, dass jeder verteilte Lauf Byte für Byte reproduziert. Teams sollten Antwortobergrenzen festlegen, die geparste Ausgabe validieren, die Modell- und Dekodierungseinstellungen protokollieren und wiederholte Durchläufe unter dem genauen Batch-Plan vergleichen, der in der Produktion verwendet wird.

Eine Entscheidung für die Leser vom 25. Oktober

Wenn der aktuelle Stack stabil ist und keine der neuen Modell- oder Cache-Funktionen benötigt wird, kann der Release Candidate ein Evaluierungsziel bleiben. Wenn ein benötigter Prüfpunkt oder Connector dies erfordert, führen Sie das Upgrade auf einem isolierten Dienst durch und erfassen Sie ein Vorher-Nachher-Profil, das Abbruch, Vorabfüllung/Dekodierungsübertragung, strukturierte Ausgabe, Qualität und Ressourcennutzung abdeckt. Behalten Sie einen getesteten Downgrade-Pfad für Konfigurations- und Cache-Verhalten bei. Dabei handelt es sich um eine redaktionelle Empfehlung aus der veröffentlichten Änderungs- und Problemliste und nicht um die Behauptung, dass der Kandidat überall unsicher sei. Der Digest vom 25. Oktober präsentiert die Originalveröffentlichung vom 22. Oktober mit intakten Einschränkungen; Es wird keine endgültige Verfügbarkeit von 1.4.0 vorausgesetzt.