Konzeptkarte

PagedAttention — Speicherverwaltung für LLMs mit langem Kontext

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist PagedAttention — Speicherverwaltung für LLMs mit langem Kontext?

PagedAttention überträgt das Paging aus dem virtuellen Speicher von Betriebssystemen auf den KV-Cache und steigert die effektive GPU-Speicherauslastung von 20-40 % auf über 96 % — aus einer A100, die unter 4 gleichzeitige Anfragen mit 32.000 Tokens Kontext bediente, wird eine, die 30 bis 50 bedient.

PagedAttention ist die Speicherverwaltungstechnik, die groß angelegtes LLM-Serving von einem speichergebundenen Engpass in ein lösbares technisches Problem verwandelt hat. Sie wurde 2023 vom vLLM-Team eingeführt und überträgt die älteste Idee im Betriebssystem-Design — paginierten virtuellen Speicher — auf die eine Ressource, die den GPU-Speicher während der Inferenz dominiert: den KV-Cache, den laufenden Speicher der Key- und Value-Vektoren, den jede Transformer-Schicht beim Generieren von Tokens akkumuliert.

Was es ist und warum es wichtig ist

Jedes Token, das ein LLM erzeugt, fügt einem Cache pro Attention-Head und pro Schicht einen Key-Vektor und einen Value-Vektor hinzu — ein Cache, der für die gesamte Dauer der Anfrage im GPU-Speicher resident bleiben muss. Allein eine einzelne Konversation mit 32.000 Tokens gegen ein Modell mit 70 Milliarden Parametern kann mehrere Gigabyte an Cache belegen. Vor PagedAttention allozierten Serving-Engines diesen Cache als einen zusammenhängenden Block, dessen Größe sich nach der bei der Aufnahme deklarierten maximalen Sequenzlänge der Anfrage richtete — unabhängig davon, wie viele Tokens die Anfrage tatsächlich erzeugen würde. Eine Anfrage, die einen 32k-Kontext anforderte, aber nur 200 Tokens generierte, reservierte trotzdem den vollen Umfang von 32.000 Slots, und keiner dieser Plätze wurde freigegeben, bevor die Anfrage abgeschlossen war. Multipliziert man diese Verschwendung über Dutzende gleichzeitiger Anfragen unterschiedlicher Länge, werden 60-80 % des nominell „verfügbaren" GPU-Speichers strukturell unbrauchbar: vorhanden auf dem Beschleuniger, aber in Stücke fragmentiert, die zu klein oder zu ungünstig zugewiesen sind, um eine neue Anfrage zu bedienen. Die praktische Konsequenz war unmissverständlich — Engines lehnten neue Aufträge ab, während sie auf Gigabytes von brachliegendem Speicher saßen.

Warum es zählt

Engines vor vLLM reservierten bei der Aufnahme einer Anfrage einen vollständigen zusammenhängenden Block in Größe der maximalen Sequenzlänge, wodurch bei 30-50 gleichzeitigen Anfragen unterschiedlicher Länge 60-80 % des GPU-Speichers durch Fragmentierung verschwendet wurden.
Pages (KV-Cache-Blöcke fester Größe) werden über eine anfragespezifische Block-Table auf physischen Speicher abgebildet, bedarfsgerecht alloziert und einzeln freigegeben, sobald eine Anfrage abgeschlossen ist — genau wie beim Mapping von virtuellem auf physischen Speicher in einem Betriebssystem.
Pages mit identischem Token-Inhalt können zwischen Anfragen geteilt werden, was die Grundlage für Prefix-Caching und SGLangs RadixAttention bildet.

Kernpunkte

Überträgt betriebssystemartiges Virtual-Memory-Paging auf den KV-Cache (C160) — Blöcke fester Größe von z. B. 16 Token-Slots, abgebildet über eine anfragespezifische Block-Table; gibt Pages einzeln frei, sobald Anfragen abgeschlossen sind.
Ersetzt die zusammenhängende Allokation, die von vornherein Platz für die maximale Sequenz reservierte (was 60-80 % des GPU-Speichers verschwendete), durch bedarfsgerechte Allokation; auf einer A100 80GB mit 70B-Modell und 32k-Kontext unterstützt naive Allokation <4 gleichzeitige Anfragen gegenüber 15-20 unter PagedAttention.
Hebt die effektive GPU-Speicherauslastung bei gleichzeitigen Workloads unterschiedlicher Länge von 20-40 % auf über 96 % — das zentrale Ergebnis des SOSP-2023-Papers.
Ermöglicht Prefix-Caching und RadixAttention (SGLang), indem Pages mit identischem Inhalt zwischen Anfragen geteilt werden können; ein gemeinsam genutzter System-Prompt von 2.000 Tokens über 50 gleichzeitige Anfragen spart 50 × 2.000 × (KV-Tensorgröße pro Token) an GPU-Speicher.
Kernel-Overhead pro Schritt von 5-15 % (nicht zusammenhängendes K/V-Gather gegenüber zusammenhängend) im Austausch für 3- bis 5-mal mehr gleichzeitige Anfragen auf derselben Hardware — der zentrale Trade-off.
Grundlage, die Continuous Batching (C245) bei Long-Context- und agentischen Workloads erst realisierbar macht — ohne paginierte Allokation kann Continuous Batching keine neuen Anfragen aufnehmen, solange Long-Context-Anfragen zusammenhängenden Speicher belegen.
Implementiert in: vLLM (Originalimplementierung, Open Source) · NVIDIA TensorRT-LLM (produktionsreif, GPU-optimiert) · SGLang (erweitert um RadixAttention) · LMDeploy (Huawei, Mobile + Edge).
SAP AI Core nutzt vLLM-kompatible Engines mit paginierter Allokation für das Modell-Serving des Generative AI Hub; die Kapazitätsplanung für gleichzeitige Joule- oder SAP-AI-Agent-Sitzungen muss das KV-Cache-Page-Budget pro Sitzung berücksichtigen.
Praktische Wirkung von Prefix-Caching: In einem Joule-Deployment, in dem alle Anfragen einen 2.000-Token-SAP-Kontext-Prompt teilen, reduziert Prefix-Caching die TTFT (Time to First Token) um 40-60 % und den KV-Cache-Speicher um 30-50 % — eine erhebliche Kostenreduktion im großen Maßstab.
Fehlermodus: Page Eviction — wenn der GPU-Speicher trotz paginierter Allokation erschöpft ist (sehr lange Kontexte plus hohe Gleichzeitigkeit), lagert die Engine kalte Pages in den CPU-RAM aus (Swap); Eviction verursacht Latenzspitzen von 100-500 ms, sichtbar als Verschlechterung der p99-Latenz; das Signal ist eine hohe Swap-Rate in den vLLM-Metriken.

Begriffe auf dieser Seite

PagedAttention: Speicherverwaltungsalgorithmus, der den LLM-KV-Cache in Pages fester Größe unterteilt, die über eine anfragespezifische Block-Table abgebildet werden, nach dem Vorbild des Virtual-Memory-Paging von Betriebssystemen; eingeführt im vLLM-Paper (Kwon et al., SOSP 2023); die zentrale Technik, die eine 3- bis 5-fache GPU-Durchsatzverbesserung bei gleichzeitigen LLM-Workloads unterschiedlicher Länge ermöglicht.
KV-cache: Die Key- und Value-Tensoren jedes Tokens im Kontextfenster eines LLM, im GPU-Speicher zwischengespeichert, um eine erneute Berechnung der Multi-Head-Attention über frühere Tokens zu vermeiden; kann pro Long-Context-Konversation 1-10 GB belegen; der primäre GPU-Speicher-Engpass beim LLM-Serving.
Block table: Anfragespezifische Datenstruktur, die logische Token-Positionen auf die physischen Pages abbildet, welche deren K/V-Vektoren enthalten; analog zu einer Page-Table in einem Virtual-Memory-System eines Betriebssystems; der Mechanismus, der die logische Sequenzlänge vom physischen Speicherlayout entkoppelt.
Prefix caching: Wiederverwendung derselben KV-Cache-Pages für das gemeinsame Präfix mehrerer Anfragen (z. B. einen gemeinsamen System-Prompt oder Few-Shot-Beispiele); ermöglicht durch den Page-Sharing-Mechanismus von PagedAttention; reduziert die TTFT um 40-60 % und den KV-Cache-Speicher um 30-50 % bei Joule-Deployments, in denen alle Anfragen einen SAP-Kontext-Prompt teilen.
RadixAttention: Erweiterung des Page-Sharing von PagedAttention auf beliebige gemeinsame Präfixe über einen Radix-Baum, implementiert in SGLang (Zheng et al., 2023); erzielt gegenüber einfachem Prefix-Caching zusätzliche 20-40 % Speicherersparnis, indem auch Nicht-Präfix-Teilstrings geteilt werden.
Page eviction: Der Rückfallmechanismus, wenn der GPU-Speicher trotz paginierter Allokation erschöpft ist: Kalte Pages (nicht kürzlich zugegriffene) werden in den CPU-RAM geschrieben und bei Bedarf neu geladen; verursacht Latenzspitzen von 100-500 ms, sichtbar als p99-Verschlechterung; der zentrale Fehlermodus, der über die swap_rate-Metrik von vLLM zu überwachen ist.
TTFT (Time to First Token): Die Latenz von der Einreichung der Anfrage bis zum Erscheinen des ersten Tokens in der Antwort; die Nutzererfahrungs-Metrik, die am empfindlichsten auf KV-Cache-Speicherdruck und Prefix-Caching reagiert; Zielwert für interaktive Joule-Sitzungen sind <500 ms TTFT.
Continuous batching: Die LLM-Serving-Technik (C245), die neue Anfragen mitten in der Generierung aufnimmt, statt auf den Abschluss des aktuellen Batches zu warten; nur mit PagedAttention praktikabel, da naive zusammenhängende Allokation Speicher bis zum Abschluss einer vollständigen Sequenz belegt.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →