Funktionsweise und Trade-offs von KV-Caching bei LLM-Inferenz

X-Post0xSeroAnleitung

Ein technischer Leitfaden von Avi Chawla, geteilt von 0xSero, erklärt die Mechanismen des Key-Value-Cachings (KV-Caching) in Transformern. Das Verfahren verhindert redundante Berechnungen bei der autoregressiven Generierung von Tokens und beschleunigt die Inferenz in der Praxis um etwa das Fünffache, verlagert den Engpass jedoch auf den GPU-Speicher.

Das Wichtigste

  1. Autoregressive Redundanz: Um das jeweils nächste Token vorherzusagen, wird nur der Hidden State des neuesten Tokens benötigt. Ohne Caching müssten Key- (K) und Value-Vektoren (V) aller vorherigen Tokens bei jedem Schritt neu berechnet werden, was O(n²) Berechnungsaufwand verursacht.
  2. Ablauf des KV-Cachings: Pro neuem Token werden nur Q, K und V für diesen Schritt berechnet. Die neuen K- und V-Vektoren wandern in den Cache, während die Attention-Berechnung das neue Query mit allen gecachten Keys und Values abgleicht.
  3. Time-to-First-Token (TTFT): Vor der Generierung durchläuft der gesamte Prompt den Prefill-Schritt, um den Cache aufzubauen. Dieser Schritt ist rechenintensiv und erklärt die Verzögerung bis zum Erscheinen des ersten Tokens.
  4. Speicher-Trade-off: Das Verfahren spart Rechenleistung auf Kosten von VRAM. Bei Modellen wie Qwen 2.5 72B mit 32k Kontext belegt der Cache pro Anfrage mehrere Gigabyte und übersteigt bei vielen gleichzeitigen Nutzern oft das Gewicht des Modells selbst.
  5. Gegenmaßnahmen: Architekturen wie Grouped-Query Attention (GQA), Multi-Query Attention (MQA) sowie Ansätze wie Paged Attention werden genutzt, um den VRAM-Bedarf im Serving-Stack (vLLM, TGI, TensorRT-LLM) zu begrenzen.

Warum das relevant ist

Für Entwickler und Administratoren von KI-Infrastruktur ist das Verständnis von KV-Caching essenziell, um Latenzen, Time-to-First-Token und den VRAM-Bedarf bei hoher Last oder langen Kontextfenstern exakt zu planen und zu optimieren.

Einordnung

Chawla schlüsselt die mathematische Notwendigkeit hinter KV-Caching schrittweise auf. Der Beitrag zeigt deutlich, warum die Skalierung von Kontextfenstern nicht primär an der Rechenleistung, sondern am VRAM-Verbrauch scheitert. Die Ausführungen verdeutlichen auch, warum moderne Serving-Frameworks wie vLLM stark auf Speicherverwaltungstechniken wie Paged Attention und Architekturen wie GQA angewiesen sind.

Original-Post

0xSero

@0xSero · 9. August 2026

Great article t.co/KIpAG85sA0

269 Likes2 Antworten343 Lesezeichen36.448 Aufrufe

Auf X ansehen
Ausgewählte Antworten (2)
  • @knowixbuilds @0xSero giving it a good read before retiring for the night.
  • @iamsbmalik @0xSero Agree 💯

Erwähnte Links

Zusammenfassung von KI erstellt (Gemini 3.8 Flash, 27. September 2026). Sie kann Fehler enthalten – maßgeblich ist die Originalquelle.

Ähnliche Einträge

Inhaltlich ähnlich, ermittelt über die KI-Suche.

  • Link:lmcache.ai

    LMCache: Modularer KV-Cache für skalierbare LLM-Inferenz

    LMCache ist eine modulare Open-Source-Infrastruktur für den Key-Value-Cache (KV-Cache) bei LLM-Inferenzen. Das System speichert, komprimiert, durchsucht und teilt vorberechnete KV-Caches über GPU-, CPU- und externe Speicher hinweg, um redundante Prefill-Berechnungen zu minimieren.

    KI & AI· Tool

  • Repository:LMCache/LMCache

    LMCache: Skalierbare KV-Cache-Verwaltung für LLM-Inferenz

    LMCache ist ein Open-Source-Projekt unter Apache-2.0-Lizenz, das als spezialisierter Management-Layer für den KV-Cache bei LLM-Inferenz dient. Es optimiert Latenz und Kosten beim Serving von Sprachmodellen auf GPUs von Nvidia und AMD.

    11.660SternePython

    KI & AI· Tool

  • X-Post:Mia

    Performance-Update für Qwen3.8 Flash Next auf DGX Spark

    Mia (@MiaAI_lab) hat ein Performance-Update für das Modell Qwen3.8 Flash Next auf einem einzelnen DGX Spark vorgestellt. Die Aktualisierung steigert die Generierungsrate auf bis zu 108 Tokens pro Sekunde bei mehreren Streams und erweitert den KV-Cache auf 1M.

    520Lesezeichen75.709Aufrufe

    KI & AI· Ankündigung

  • X-Post:Neko Legends

    LLM-Inferenz im Dauerbetrieb: Stille GPU-OOMs und Monitoring-Lücken

    Neko Legends berichtet von Stabilitätsproblemen beim produktiven Betrieb von GLM-5.3-Flash (1M-ctx) auf einem 4×-Spark-Cluster. Das System fiel nach 13 Stunden durch einen unbemerkten GPU-OOM aus, während der Health-Check weiterhin grünes Licht signalisierte.

    18Lesezeichen683Aufrufe

    KI & AI· Diskussion

  • Artikel:Kimi Team (Yu Zhang et al.)

    Kimi Linear: Hybride lineare Attention-Architektur übertrifft Full Attention

    Das Kimi-Team stellt Kimi Linear vor, eine hybride lineare Attention-Architektur, die Full Attention in Tests über kurze und lange Kontexte sowie im RL-Scaling übertrifft. Sie senkt den KV-Cache-Bedarf um bis zu 75 Prozent und steigert den Decoding-Durchsatz bei Kontexten von 1 Million Token um das bis zu Sechsfache.

    KI & AI· Forschung

Zurück zur Wissensbasis

Lassen Sie uns über Ihr Projekt sprechen

Kontakt aufnehmen

Standorte

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Wien
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Dieser Inhalt wurde teilweise mithilfe von KI erstellt.