Wie verwaltet Paged Attention den KV-Cache bei gleichzeitig ausgeführten lokalen KI-Anfragen?

Paged Attention verwaltet den gleichzeitig genutzten KV-Cache, indem der wachsende Token-Zustand jeder Anfrage auf Blöcke fester Größe abgebildet wird, die unabhängig voneinander zugewiesen und wiederverwendet werden können.

Das ist auf einem KI-Heimserver wichtig, da aktive Chats, Dokumentaufgaben und Agenten selten dieselbe Kontextlänge haben oder gleichzeitig beendet werden. Eine Strategie mit zusammenhängenden Reservierungen verschwendet bei diesen variablen Sequenzen knappen Beschleunigerspeicher. Paging verändert das Speicherlayout, sodass der Scheduler die verfügbare Kapazität dichter nutzen kann.

Gleichzeitige Anfragen erzeugen KV-Caches, die unterschiedlich schnell wachsen

Jede aktive autoregressive Anfrage benötigt den Schlüssel- und Wertzustand für die bereits verarbeiteten Token. Ein Chat kann nach 100 Token enden, während ein anderer über Tausende von Token hinweg fortgesetzt wird. Daher lässt sich der genaue Speicherbedarf beim Start des Batches nicht bestimmen.

Das PagedAttention-Paper identifiziert den dynamisch wachsenden KV-Cache-Speicher als Engpass beim Serving, der das Batching begrenzt, wenn die Zuweisung ineffizient ist.

Auf einem Heimserver mit mehreren Benutzern oder Hintergrundagenten verwandelt diese Variabilität eine große Zahl freien Speichers in viele Live-Zuweisungen unterschiedlicher Größe.

Zusammenhängende Reservierungen fester Größe verschwenden Speicher bei variablen Sequenzen

Eine naive Laufzeitumgebung kann für jede Anfrage einen großen zusammenhängenden Bereich auf Grundlage einer maximalen Länge reservieren. Kurze Anfragen hinterlassen ungenutzten Speicher innerhalb ihrer Reservierung, während längere Anfragen möglicherweise eine Neuzuweisung oder Überdimensionierung erfordern.

vAttention fasst die ursprüngliche Motivation für Paging zusammen: KV-Reservierungen im Voraus erzeugen interne Fragmentierung. Verschwendeter Speicher reduziert die Anzahl der Anfragen, die gleichzeitig aktiv bleiben können.

Das praktische Symptom ist eine Grenze durch nicht genügend Speicher oder ein kleines maximales Batch, obwohl die Summe der tatsächlich verwendeten Token-Zustände niedriger als der verfügbare VRAM zu sein scheint.

PagedAttention unterteilt den KV-Zustand in Blöcke fester Größe

PagedAttention ersetzt den physisch zusammenhängenden Anfragepuffer durch eine logische Folge von Blöcken. Sobald weitere Token eintreffen, weist die Laufzeitumgebung zusätzliche physische Blöcke aus einem gemeinsam genutzten Pool zu.

vLLM erklärt, dass KV-Blöcke in nicht zusammenhängendem physischem Speicher liegen können. Eine Blocktabelle ordnet die logische Token-Reihenfolge der Anfrage diesen physischen Speicherorten zu.

Das Modell verarbeitet weiterhin die korrekte Sequenz. Die Indirektion verändert die Speicherplatzierung, nicht die semantische Reihenfolge der Unterhaltung.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Freigegebene Blöcke kehren beim Abschluss von Anfragen in einen gemeinsamen Pool zurück

Wenn eine Anfrage abgeschlossen wird, können ihre nicht gemeinsam genutzten Blöcke sofort freigegeben und von einer anderen aktiven oder neu zugelassenen Anfrage wiederverwendet werden. Der Server muss nicht warten, bis eine riesige Arena vollständig leer ist.

Der Inferenz-Stack von NVIDIA stellt die KV-Cache-Kapazität als Serving-Ressource bereit, die mit den Gewichten und dem Arbeitsspeicher der Laufzeitumgebung ausbalanciert werden muss.

Diese Wiederverwendung auf Blockebene ist zu Hause besonders wertvoll, da Anfrage­längen unregelmäßig sind: Eine Person stellt eine kurze Frage zum Smart Home, während eine andere einen langen Dokumentassistenten ausführt und ein Hintergrundagent Dateien zusammenfasst.

Paging erhöht die Parallelität durch weniger Fragmentierung, nicht durch kleinere einzelne Token

PagedAttention macht die Schlüssel- und Werttensoren eines einzelnen Tokens nicht grundsätzlich kleiner. Der wichtigste Speichervorteil entsteht dadurch, dass der Speicher näher am tatsächlichen Sequenzwachstum zugewiesen wird und gültige gemeinsame Nutzung ermöglicht wird.

Die verteilte Dokumentation von PyTorch unterscheidet Modellparallelismus von der Verwaltung des Serving-Speichers. Paging ist kein Tensorparallelismus und teilt die Modellgewichte nicht automatisch auf mehrere GPUs auf.

Wenn die Modellgewichte bereits nahezu den gesamten Gerätespeicher belegen, kann Paging keine ausreichende Kapazität für eine hohe Parallelität erzeugen. Es verbessert die Auslastung des verbleibenden KV-Bereichs.

Die Blockverwaltung bringt eigenen Overhead und Scheduling-Grenzen mit sich

Die Laufzeitumgebung verwaltet nun Blocktabellen, Referenzzähler, Zuweisungsentscheidungen und Attention-Kernels, die mit ausgelagerten Layouts umgehen können. Bei extrem kleinen Batches oder nicht unterstützter Hardware kann der Vorteil geringer ausfallen.

Der ZimaSpace-Artikel über gleichzeitige Nutzung durch die Familie und KV-Auslastung zeigt die für Benutzer spürbare Grenze: Speichereffizienz ist wichtig, weil sie bestimmt, wie viele aktive Kontexte gleichzeitig bestehen können, bevor die Warteschlange länger wird.

Testen Sie mehrere Anfrage­längen und Ankunftsmuster statt nur eines synthetischen Batches. Der ZimaSpace-Leitfaden zu gleitenden Kontextfenstern und KV-Speicher eignet sich als Vergleich, da Windowing beeinflusst, wie viel Zustand jede Sequenz behält, während Paging verändert, wie dieser Zustand zugewiesen wird. Erfassen Sie aktive Sequenzen, verwendete KV-Blöcke, Wartezeit in der Warteschlange und Verdrängungen.

Auch der TGI-Scheduler von Hugging Face unterscheidet zwischen Prefill- und Decode-Scheduling beim gleichzeitigen Serving. Der ausgelagerte Speicher hilft dem Scheduler, Aufgaben zuzulassen, doch Fairness und Latenz hängen weiterhin davon ab, wie diese Aufgaben in die Warteschlange eingereiht werden.