kvpress: KV-Cache-Kompression als Sammlung austauschbarer Presses
LLM KV cache compression made easy
Auf einen Blick
- Was ist das?
- NVIDIA/kvpress komprimiert den Key-Value-Cache von Transformer-Modellen während der Prefill-Phase. Das Repository liefert mehrere veröffentlichte Verfahren als einheitliche Python-Klassen und eine eigene Transformers-Pipeline. Wer lange Kontexte auf begrenztem Speicher fahren will, findet hier eine Testumgebung, aber keinen fertigen Inferenzserver.
- Für wen ist es gedacht?
- kvpress passt zu Forschenden und Entwicklern, die verschiedene KV-Kompressionsverfahren auf demselben Modell und demselben Prompt vergleichen wollen, ohne jedes Paper neu zu implementieren.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Speicherproblem, das kvpress adressiert
Der Key-Value-Cache wächst linear mit der Kontextlänge. Das README nennt eine konkrete Zahl: 1M Tokens mit Llama 3.1-70B in float16 benötigen bis zu 330GB Speicher. Diese 330GB sind kein Rechenaufwand, sondern reiner Cache, der während der Generierung gehalten werden muss. Wer lange Dokumente, Codebasen oder Transkripte verarbeiten will, stößt damit an die Grenze der verfügbaren Beschleuniger, bevor das Modell überhaupt ein Token ausgibt. kvpress setzt genau dort an und komprimiert den Cache während der Prefill-Phase. Die Zielgruppe ist im README klar benannt: Forschende und Entwickler, die neue Kompressionsmethoden entwickeln und vergleichen wollen. Es ist kein Serving-Framework und will laut Eigendarstellung keines sein.
Presses als einheitliche Schnittstelle über verschiedene Paper
Die zentrale Abstraktion heißt Press. Alle aktuellen Presses sind training free und erben von BasePress in kvpress/presses/base_press.py. Viele davon erben zusätzlich von ScorerPress in kvpress/presses/scorer_press.py und arbeiten nach demselben Muster: Sie berechnen für jedes Key-Value-Paar einen Wichtigkeitswert und verwerfen die Paare mit dem niedrigsten Wert. Was sich unterscheidet, ist allein die Herkunft dieses Werts. KnormPress nutzt die inverse Norm des Keys. SnapKVPress mittelt die Attention-Gewichte der letzten Queries. TOVAPress nimmt das Attention-Gewicht der letzten Query, gemittelt über alle Heads. StreamingLLMPress behält nur die ersten und die letzten Tokens und braucht dafür überhaupt keine Scores. PyramidKVPress verteilt das Cache-Budget schichtweise, mit mehr Budget in unteren und weniger in oberen Layern. QFilterPress projiziert die Key-Repräsentationen auf die Haupt-SVD-Komponente der Query-Vektoren, um Attention-Scores anzunähern. Jede dieser Klassen verweist im README auf ihre jeweilige Publikation, was den Vergleich zwischen den Verfahren stark vereinfacht. Wer eine neue Methode baut, implementiert dieselbe Basisklasse und bekommt den Rest der Infrastruktur geschenkt.
Wie die Pipeline den Cache tatsächlich beschneidet
Beim Import registriert kvpress eine Transformers-Pipeline unter dem Namen kv-press-text-generation. Diese Pipeline übernimmt Chat-Templates und Tokenisierung, sodass ein Aufruf wie pipe(context, question=question, press=press) genügt. Entscheidend ist der Datenfluss: Die Kompression greift auf die Kontext-Tokens, nicht auf die Frage. Das README begründet das ausdrücklich damit, dass man die Kompression so für verschiedene Fragen gegen denselben komprimierten Kontext evaluieren kann. Der Kontext wird also einmal komprimiert und danach mehrfach befragt. Jede Press trägt ein Attribut compression_ratio, das den Grad der Kompression angibt. Ein Wert von 0.5 bedeutet nach dieser Lesart, dass die Hälfte der Cache-Einträge entfällt. Diese Trennung von Kontext und Frage ist der Grund, warum sich das Werkzeug gut für reproduzierbare Vergleiche eignet: Der komprimierte Cache bleibt über Fragen hinweg stabil.
DecodingPress: Kompression während der Generierung
Standardmäßig komprimiert kvpress nur beim Prefill. Das README bezeichnet die Kompression während der Dekodierung als experimentelles Feature, das über den Wrapper DecodingPress läuft. Dieser Wrapper presst den Cache periodisch während der Token-Generierung und kann dabei einen Puffer aktueller Hidden States halten. Die Parameter sind konkret: base_press nimmt eine beliebige ScorerPress, compression_interval steht standardmäßig auf 512 Schritten, target_size auf 2048 Tokens, hidden_states_buffer_size auf 256. Manche Presses brauchen den Puffer nicht und können ihn auf 0 setzen. Der wesentliche Unterschied zum Prefill-Modus: DecodingPress arbeitet nicht mit einem compression_ratio, sondern mit target_size. Nach jedem Intervall wird die Kompression so berechnet, dass die Cache-Größe genau target_size entspricht. Das README schränkt ein, dass nicht alle Presses mit DecodingPress kompatibel sind, weil sich die Kompression beim Dekodieren grundlegend von der beim Prefill unterscheidet. Unterstützt werden nur ScorerPresses als Basis. Wer eine andere Press-Klasse einspannt, sollte mit Fehlverhalten rechnen.
Installation und erste Schritte
Der einfachste Weg ist pip install kvpress. Für eine lokale Installation aus dem Repository empfiehlt das README uv: git clone https://github.com/NVIDIA/kvpress.git, dann cd kvpress und uv sync. Wer die Evaluationswerkzeuge und Flash Attention mitnehmen will, nutzt uv sync --extra eval --extra flash-attn. Im Beispielcode wird das Modell Qwen/Qwen3-8B mit device_map="auto" und dtype="auto" geladen, die Press ist ExpectedAttentionPress(compression_ratio=0.5). Für die Dekodierungsvariante zeigt das README ein zweites Beispiel mit meta-llama/Llama-3.1-8B-Instruct und model_kwargs={"attn_implementation": "flash_attention_2"}, dort mit KnormPress als Basis, compression_interval=10 und target_size=512. Auffällig ist, dass das zweite Beispiel explizit die Flash-Attention-2-Implementierung setzt, während das erste sie offen lässt. Wer die Beispiele nachbaut, sollte diesen Unterschied bewusst behandeln, denn die Attention-Implementierung bestimmt, welche Zwischengrößen überhaupt verfügbar sind.
Wo kvpress an Grenzen stößt
Die Kompression ist verlustbehaftet, und das README liefert keine Angaben dazu, wie stark die Antwortqualität bei welchem compression_ratio einbricht. Wer 0.5 setzt, halbiert den Cache, aber ob die Antwort auf die eigene Frage noch trägt, lässt sich nur empirisch klären. Dafür gibt es im Repository offenbar Werkzeuge: ein Wikipedia-Notebook, einen Hugging-Face-Space und einen Leaderboard-Space. Diese Ressourcen sind der vorgesehene Weg, um die Qualität für ein Modell und eine Aufgabe einzuschätzen. Ein zweiter Punkt betrifft DecodingPress. Das README nennt die Kompatibilität ausdrücklich eingeschränkt und markiert das Feature als experimentell. Wer es produktiv einsetzt, arbeitet auf einer Fläche, die der Maintainer selbst noch nicht als stabil bezeichnet. Drittens ist kvpress kein Server. Es gibt keine Angaben zu kontinuierlichem Batching, zu Mehrbenutzerbetrieb oder zu Durchsatz unter Last. Für diese Fragen ist das Projekt schlicht nicht gebaut.
Alternative Ansätze und der Unterschied im Vorgehen
Der naheliegende Vergleich ist vLLM. vLLM ist ein Inferenzserver mit Paged Attention, bei dem der Cache in Blöcke fester Größe zerlegt und über Anfragen hinweg verwaltet wird. Der Unterschied liegt nicht im Ziel, sondern im Angriffspunkt: vLLM verwaltet den Cache, damit viele Anfragen parallel durch denselben Speicher passen, und komprimiert ihn nicht inhaltsabhängig. kvpress dagegen entscheidet pro Key-Value-Paar, ob es verworfen wird, und zwar auf Basis eines Scores aus der jeweiligen Publikation. Ein weiterer Unterschied ist die Betriebsform: kvpress läuft als Transformers-Pipeline in einem Prozess, vLLM als Dienst mit Scheduler. Wer Speicher sparen will, ohne Qualität zu opfern, kann auch auf Quantisierung des Caches setzen, etwa in niedrigere Bit-Breiten. Das ist ein anderer Trade-off: Quantisierung reduziert die Genauigkeit jedes Eintrags, kvpress entfernt ganze Einträge. Welcher Weg bei einer konkreten Aufgabe besser abschneidet, lässt sich aus dem README nicht ableiten.
Pflege, Versionen und Lizenz
Die letzten Releases sind v0.5.4 vom 2. Juli 2026, v0.5.3 vom 9. April 2026 und v0.5.2 vom 1. April 2026. Der letzte Push auf main datiert vom 7. September 2026. Die Versionsnummern liegen alle in der 0.x-Reihe, was bedeutet, dass die API noch nicht als stabil zugesagt ist. Zwischen v0.5.2 und v0.5.3 liegen acht Tage, zwischen v0.5.3 und v0.5.4 knapp drei Monate. Wer kvpress einbindet, sollte die Versionsnummer festnageln und bei jedem Update die Press-Klassen prüfen, die tatsächlich verwendet werden. Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung und Modifikation erlaubt, solange die Lizenzbedingungen eingehalten werden. Das README nennt optionale Abhängigkeiten über uv sync --extra eval --extra flash-attn. Wer diese Extras aktiviert, zieht weitere Pakete mit eigenen Lizenzen ein, darunter flash-attn. Diese Abhängigkeiten sind gesondert zu prüfen. Eine rechtliche Bewertung kann hier nicht geleistet werden, und das README enthält dazu auch keine Hinweise.
Redaktionelles Fazit
kvpress passt zu Forschenden und Entwicklern, die verschiedene KV-Kompressionsverfahren auf demselben Modell und demselben Prompt vergleichen wollen, ohne jedes Paper neu zu implementieren. Wer einen produktionsreifen Serving-Stack mit kontinuierlichem Batching und mehreren gleichzeitigen Nutzern braucht, sollte zuerst prüfen, ob vLLM oder TensorRT-LLM die gewünschte Methode bereits mitbringt, denn kvpress ist laut README ausdrücklich als Benchmark- und Entwicklungsrahmen für Forschende und Entwickler beschrieben. Vor dem ersten Einsatz im eigenen Projekt sind drei Dinge zu klären: ob die gewählte Press-Klasse mit dem Zielmodell und der Attention-Implementierung läuft, welcher compression_ratio bei der eigenen Aufgabe noch akzeptable Antworten liefert, und ob die Lizenz- und Abhängigkeitslage von flash-attn im eigenen Build akzeptabel ist.
Community-Notizen