Lokale Large Language Models wirken anfangs blitzschnell. Man lädt ein Modell mit 7B oder 13B Parametern und gibt einen kurzen Prompt ein,

Lokale Large Language Models fühlen sich anfangs blitzschnell an. Man lädt ein Modell mit 7B oder 13B Parametern, gibt einen kurzen Prompt ein, und die Token strömen in einem angenehmen Tempo über den Bildschirm. Dann fügt man einen langen Codeblock ein, oder der Chatverlauf bläht sich über ein Dutzend Interaktionen auf, und das Modell beginnt zu kriechen. Die Verlangsamung erfolgt selten sanft. Es ist ein Abgrund. In einem Moment produziert die GPU noch Token; im nächsten zeigt der Systemmonitor steigenden Speicherdruck an, und die Generierung stockt. Man kann nicht mit einer einfachen Formel vorhersagen, wann genau das passiert. Der einzige zuverlässige Wegweiser ist die Hardware selbst.

Die versteckten Kosten des Kontextes

Jeder generierte Token fügt dem KV-Cache einen Zustand hinzu. Dieser Cache speichert die Keys und Values, die während der Prefill- und Generierungsphasen berechnet werden, und belegt zusammen mit den Modellgewichten, Attention-Buffern und dem Runtime-Overhead Speicherplatz. Auf einer typischen Consumer-GPU mit 12 GB oder 16 GB VRAM konkurriert der KV-Cache schließlich mit allem anderen um den Platz. Wenn der dedizierte Videospeicher voll ist, wirft das Betriebssystem keinen Fehler aus und stoppt nicht. Es leitet den Überlauf stillschweigend in den Shared Memory um, wobei Daten über den PCIe-Bus zwischen der GPU und dem System-RAM hin- und hergeschoben werden. Dieser Bus ist zwar schnell für Dateiübertragungen, aber im Vergleich zur Speicherbandbreite innerhalb einer Grafikkarte ist er extrem langsam. Das Ergebnis ist kein geringfügiger Leistungsabfall, sondern ein Zusammenbruch.

Drei Anzeichen dafür, dass der Abgrund erreicht ist

Beobachten Sie Ihre Hardware-Monitore, während das Modell läuft. Sobald der Leistungseinbruch eintritt, werden Sie drei klare Anzeichen sehen.

• Shared VRAM steigt. Dies ist Speicher, den der GPU-Treiber aus dem dedizierten Video-RAM in den vom Host-Betriebssystem verwalteten Pool verschoben hat. In dem Moment, in dem dieser Wert über Null steigt, haben Sie die Grenze überschritten.
• System-RAM-Auslastung bläht sich auf. Der Überlauf muss irgendwohin, und dieses Ziel ist Ihr Hauptspeicher. Wenn die RAM-Auslastung steigt, während das Modell Token generiert, werden Daten von der GPU ausgelagert.
• Eval-Geschwindigkeit sinkt um die Hälfte oder mehr. Eine Verlangsamung um 10 % könnte auf Thermal Throttling oder Hintergrundprozesse hindeuten. Ein Einbruch um 50 % oder mehr bedeutet, dass sich der Flaschenhals von den Tensor Cores zur Speicherbandbreite und PCIe-Latenz verschoben hat. Wenn die Generierung von zweistelligen auf einstellige Werte fällt, sind Sie bereits in den Abgrund gestürzt.

Warum Ihr schneller Benchmark wahrscheinlich lügt

Ein kurzer Smoke Test vermittelt falsche Sicherheit. Wenn Sie das Modell mit einem hundert-Token-Prompt testen, einen gesunden Durchsatz sehen und die Sache damit abhaken, haben Sie lediglich die „Flitterwochen-Phase“ gemessen. Der KV-Cache ist fast leer. Die Layer wurden noch nicht durch einen langen Prefill belastet. Der wahre Speicherbedarf zeigt sich erst, nachdem das Modell einen umfangreichen Prompt verarbeitet hat und der Cache seine tatsächliche Arbeitsgröße erreicht hat. Sie müssen mit tiefem Prefill und langen Generierungsläufen testen. Lassen Sie den Kontext tatsächlich anwachsen. Erst dann wird sich der Speicherdruck stabilisieren und Ihnen das wahre Limit aufzeigen.

Ihr Limit mit llama.cpp finden

Wenn Sie Modelle über llama.cpp ausführen, können Sie Ihre Grenze mit einfacher Arithmetik und einem geduldigen Testlauf ermitteln.

1. Shared-Memory-Nutzung messen.
Notieren Sie Ihren Basiswert des dedizierten VRAM mit einem minimalen Prompt, führen Sie dann eine Aufgabe mit langem Kontext aus und notieren Sie den Spitzenwert. Subtrahieren Sie den Basiswert vom Spitzenwert. Die Differenz ist das, was aus Ihrer GPU in den Shared System Memory ausgelagert wurde.

2. RAM-Delta berechnen.
Führen Sie dieselbe Subtraktion für den System-RAM durch. Subtrahieren Sie Ihren Basis-RAM vom Spitzen-RAM während des langen Laufs. Diese Zahl sagt Ihnen genau, wie viele Daten von der Grafikkarte in Ihren Hauptspeicher verschoben wurden. Sie quantifiziert das „Leck“ über den Bus.

3. Den Einbruch der Eval-Geschwindigkeit messen.
Vergleichen Sie Ihre Basisrate der Token pro Sekunde mit der Rate, nachdem das Modell ein langes Dokument verarbeitet hat. Möglicherweise sehen Sie, wie ein Modell mit siebzehn Token pro Sekunde dahinläuft, wenn der Kontext noch frisch ist, und nur noch zwei Token pro Sekunde liefert, sobald der Cache aufgebläht ist. Dieser Abfall um fünfzehn Token ist Ihr Warnsignal.

Den Bruchpunkt triangulieren

To map the curve accurately, do not settle for one lonely data point. Run three distinct trials at 16,000 tokens, 32,000 tokens, and 65,000 tokens. Two points might suggest a line, but two dots are just a guess. The third point proves whether you are looking at measurement noise or a real memory wall. Subtract the results between runs to calculate how much extra memory each additional thousand tokens consumes on your specific combination of model, quantization layer, and GPU.

Once you have that slope, you can project forward. Take your per-token cost, multiply it by the target context length, divide by 1024 to move between units, and add the result to your base model VRAM load. The equation looks like this:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

This projection is not prophecy. It is a guidepost derived from actual behavior. Use it to estimate your ceiling before you commit to a full production run.

Why Paper Formulas Fail, and What Quantization Can Fix

Textbook formulas ignore the messy reality of local inference. Different architectures allocate attention buffers differently. Your operating system reserves VRAM for the display driver, compositor, and CUDA context. Driver versions change how aggressively they use shared memory. A theoretical equation cannot know how much VRAM is actually free on your machine at 2:00 PM with a browser full of tabs open. You have to run the model on your specific hardware and watch the meters.

Quantization offers partial relief. Moving the KV cache from f16 to q8_0 halves its memory footprint while keeping precision high enough for nearly all practical tasks. That change buys you headroom. It does not grant immunity. The cache still grows linearly with every token you feed in. Eventually, even the reduced size overwhelms your available dedicated memory and the spillover to system RAM begins. The pressure only stops when the context window is capped or the data stops moving.

The Real Takeaway

Do not trust marketing slides, parameter counts, or back-of-the-envelope math. Load the model. Open your system monitor. Run a 65,000-token thread, watch the RAM climb, and count the tokens per second. The numbers that appear on your specific screen, on your specific GPU, are the only numbers that matter. Context always wins. Your job is to know exactly when it wins on your machine.