KV-Cache zwischen Qwen3-Modellen übertragen statt neu zu prefillen

Stellen Sie sich einen Coding-Agenten vor, der seit zwanzig Minuten läuft. Er hat ein Repository durchgelesen, die Doku geöffnet, eine Handvoll Tools aufgerufen und auf Qwen3-14B knapp 30K Tokens Kontext angehäuft. Dann kommt er an den einen Schritt, bei dem ein stärkeres Modell wirklich helfen würde.

Den nächsten Schritt an Qwen3-32B zu schicken ist der einfache Teil. Die bereits geleistete Arbeit zu behalten ist der schwere. Das 32B-Modell muss den gesamten angesammelten Kontext noch einmal durchkauen, bevor es ein einziges Token ausgeben kann. Dieser Durchlauf heißt Prefill, und sein Ergebnis ist der KV-Cache des Modells.

Ein aktueller Forschungs-Preprint von NVIDIA stellt eine zugespitzte Frage. Das kleinere Modell hat für dieses Gespräch schon einen KV-Cache aufgebaut – ließe sich dieser Zustand in den Cache des größeren Modells umwandeln, statt das größere Modell ihn aus Rohtext neu aufbauen zu lassen? Im berichteten Experiment mit Qwen3 14B → 32B braucht der Mapper 277,6 ms bei 32.768 Tokens, gegenüber 6.975,3 ms für ein erneutes Prefill auf dem Zielmodell. Das ist etwa Faktor 25 für diese eine Phase. Ein vielversprechendes Ergebnis, aber deutlich enger gefasst als „25-mal schnellere LLM-Inferenz“.

Warum ein Modellwechsel Arbeit verschwendet

Der KV-Cache ist der Attention-Zustand, den ein autoregressiver Transformer beim Lesen eines Prompts aufbaut. Sobald er existiert, muss das Modell die Attention über den gesamten Präfix nicht für jedes erzeugte Token neu berechnen.

Innerhalb eines Modells funktioniert diese Wiederverwendung ganz natürlich. Serving-Systeme cachen bereits Präfixe und schieben KV-Zustand zwischen kompatiblen Workern hin und her; NVIDIA TensorRT-LLM etwa unterstützt KV-Cache-Wiederverwendung und KV-Austausch für disaggregiertes Serving.

Beim Modellwechsel bricht das zusammen.

Qwen3-14B
   │
   │  30K-token conversation
   ▼
14B KV cache
   │
   ✕ cannot simply hand this to 32B
   │
Qwen3-32B normally re-prefills the text

Modelle unterschiedlicher Größe haben unterschiedlich viele Schichten und unterschiedliche interne Repräsentationen. Ein gemeinsamer Tokenizer oder dieselbe Modellfamilie macht ihre Caches nicht austauschbar. NVIDIA behandelt das als Problem der Repräsentationsabbildung.

14B KV cache
     ↓
model-pair mapper
     ↓
32B-compatible KV cache
     ↓
32B starts decoding

Die Studie beschränkt sich bewusst auf Paare innerhalb einer Familie mit passendem KV: Quelle und Ziel müssen in der Zahl der KV-Heads und der Head-Dimension übereinstimmen. Die getesteten Paare stammen aus Qwen3, Llama 3.1 und Ministral 3. Der Wechsel zwischen Familien, etwa von Qwen zu Llama, bleibt eine offene Frage.

Eine lineare Brücke reicht – überraschenderweise

Interessant ist nicht, dass sich überhaupt ein Mapper trainieren lässt. Interessant ist, dass ein recht schlichter Mapper in geschlossener Form bei mehreren Modellpaaren gut abschneidet.

Die Analyse der linearen Struktur im Paper zeigt: Für Qwen3 14B → 32B erklärt die beste einzelne Quellschicht etwa 56 % der Varianz der Ziel-Keys und 32 % der Varianz der Values. Bündelt man eine Auswahl von Quellschichten, steigen diese Werte auf etwa 79 % und 65 %.

Der eingesetzte Mapper beruht auf drei Ideen.

Nützliche Quellschichten auswählen. Eine Zielschicht kopiert nicht einfach die Quellschicht in derselben Tiefe. Die Methode sucht die Quellschichten, deren KV-Zustände diese Zielschicht am besten vorhersagen, und verkettet deren Features.

Keys und Values getrennt fitten, pro Ziel-Head. Die Brücke selbst ist eine Ridge-Regression, die für jede Zielschicht und jeden Head unabhängig gelöst wird, mit einem Fit für Keys und einem für Values. Eine abgespeckte Version der Mathematik sieht so aus:

import numpy as np

def fit_ridge(x, y, lam=0.01):
    """Fit Y ≈ XW + b. Conceptual demo, not NVIDIA's implementation."""
    x_mean = x.mean(axis=0, keepdims=True)
    y_mean = y.mean(axis=0, keepdims=True)
    xc = x - x_mean
    yc = y - y_mean
    eye = np.eye(xc.shape[1], dtype=xc.dtype)
    w = np.linalg.solve(xc.T @ xc + lam * eye, xc.T @ yc)
    b = (y_mean - x_mean @ w).squeeze(0)
    return w, b

def map_cache(x, w, b):
    return x @ w + b

Im echten Mapper ist x viel größer, weil es die KV-Features aller ausgewählten Quellschichten verkettet, und jeder Ziel-Head bekommt seinen eigenen Fit. Für die Kalibrierung dienen 500 FineWeb-Edu-Sequenzen mit je 1.024 Tokens, heruntergesampelt auf rund 128K Beobachtungen auf Token-Ebene pro Ziel-Head.

Die Position vor dem Abbilden der Keys entfernen. Dieses Detail sollte man sich am ehesten merken. RoPE rotiert Keys je nach Position eines Tokens; bildet man rotierte Keys direkt ab, lernt man womöglich die Positionsverteilung der 1.024-Token-Kalibrierdaten statt des Inhalts. Die Methode macht daher zuerst die RoPE-Rotation des Quellmodells rückgängig, bildet die positionsfreie Inhaltsrepräsentation ab und wendet dann das RoPE des Zielmodells an.

source key
    ↓
strip source RoPE
    ↓
map content representation
    ↓
apply target RoPE
    ↓
target key

Dadurch funktioniert der Mapper auch an Positionen, die er bei der Kalibrierung nie gesehen hat, einschließlich des 32K-Latenztests.

Was die Schlagzeilenzahl abdeckt

Hier die berichteten Latenzen für Qwen3 14B → 32B auf einem 8xH100-Knoten:

• 64 Tokens: 14,0 ms fürs Mapping gegenüber 61,7 ms für erneutes Prefill, etwa 4-mal schneller.
• 8K Tokens: 67,8 ms gegenüber 1.154,8 ms, etwa 17-mal schneller.
• 32K Tokens: 277,6 ms gegenüber 6.975,3 ms, etwa 25-mal schneller.

Diese Zahlen sollte man genau lesen. Sie vergleichen die Laufzeit des Mappers mit der Zeit, die das empfangende Modell für ein erneutes Prefill braucht. Sie bedeuten keine 25-fache Beschleunigung der gesamten Generierung, denn das Decoding muss danach trotzdem laufen. Das Paper nennt auch einen Vorbehalt fürs Deployment: In einem echten Serving-Setup mit mehreren Prozessen muss der abgebildete Cache womöglich zum Zielprozess übertragen werden, und der Mapper-Benchmark rechnet das nicht in eine Zahl inklusive Netzwerk um.

Die Qualität ist bei manchen Paaren gut, bei anderen schlecht. Qwen3 14B → 32B behält 97,6 % der durchschnittlichen Eigengenauigkeit des 32B-Ziels über die fünf berichteten Benchmarks. Qwen3 8B → 32B behält 87,5 %, Llama 3.1 8B → 70B 72,8 % und Ministral 3B → 8B 76,2 %. Ministral 3B → 14B und 8B → 14B fallen mit dem linearen Mapper dagegen auf nur 44,2 % und 41,6 % durchschnittliche Retention. Passende KV-Dimensionen sind in dieser Studie eine Voraussetzung, kein Versprechen einer sauberen Übergabe.

Wo das Agenten hilft

Lang laufende Agenten sind genau der Ort, an dem wiederholtes Prefill wehtut.

So könnte eine Routing-Policy auf dieser Basis aussehen:

"""Illustrative serving API. The paper does not provide this interface."""
state = agent.run(model="qwen3-14b", task=task)

if state.needs_stronger_reasoning:
    mapped_kv = kv_bridge.convert(
        source_model="qwen3-14b",
        target_model="qwen3-32b",
        kv_cache=state.kv_cache,
    )
    state = agent.resume(
        model="qwen3-32b",
        kv_cache=mapped_kv,
    )

Routing auf ein größeres Modell ist nicht neu; das funktioniert schon heute. Neu ist, dass der Berechnungszustand mit dem Gespräch mitreisen könnte. Ein Recherche-Agent könnte günstig auf einem kleinen Familienmitglied erkunden, für eine schwierige Denkstrecke an ein größeres übergeben und für Routinearbeit wieder zurückwechseln. Die Abbildungen sind gerichtet, also brauchen 14B → 32B und 32B → 14B getrennte Mapper, und das Paper begründet sowohl Qualitätssteigerung als auch Kostensenkung.

Im Mehrrunden-Experiment wechselten sich Qwen3 14B und 32B in 100 CoQA-Gesprächen ab. Bis Runde 10 hatte sich die Lücke von klein nach groß um etwa 1,7 Prozentpunkte vergrößert, und die Drift von groß nach klein wuchs um rund 0,33 Punkte pro Runde. Das ist ein ordentlicher Beleg für Wechsel innerhalb eines Gesprächs, auch wenn die Forscher selbst warnen, dass sich lineare Drift über viel längere Sitzungen aufbauen könnte.

Grenzen, die in Produktion zählen

Das Paper ist gut genug, um die Sicht auf Modell-Routing zu verändern. Einschalten lässt es sich in einem Serving-Stack aber noch nicht.

• Der Kompatibilitätsrahmen ist eng. Alle berichteten Experimente bleiben innerhalb von Modellfamilien, nutzen dichte Modelle mit voller Attention und umfassen sechs Paare mit identischer Zahl an KV-Heads und Head-Dimension. Über Familien hinweg oder bei abweichenden KV-Formen wurde die Methode nicht erprobt.
• Jedes Paar braucht eine eigene Validierung. Zwei Ministral-Mappings scheitern mit Ridge-Regression deutlich, obwohl ihre KV-Architektur passt. Ein nichtlineares MLP holt bei diesen Paaren auf HellaSwag etwa 24 bis 37 Prozentpunkte Retention zurück, was ermutigend ist, aber zeigt, dass die einfache lineare Geschichte nicht überall gilt.
• Der Mapper ist nicht klein. Die evaluierten Mapper haben etwa 1,01 bis 3,36 Mrd. Parameter und belegen 4 bis 12 GB pro Richtung. Qwen3 14B → 32B liegt bei rund 1,07 Mrd. Parametern und 4 GB. Das Fitten dauert etwa 47 bis 87 Minuten pro Paar auf einem einzelnen 8xH100-Knoten.

Weil die Abbildungen gerichtet sind, sammelt ein Router über viele Modelle paarspezifischen Zustand an. Bei der durchschnittlichen Mappergröße aus dem Paper sind das 39 GB bei drei Modellen, 79 GB bei vier und 131 GB bei fünf. Die Mapper können im Hostspeicher oder auf Storage statt im VRAM liegen, aber es bleibt Infrastruktur, die man betreiben muss.

Noch etwas: Zum Paper gibt es derzeit keine offizielle Implementierung. Der arXiv-Eintrag enthält das Paper und seinen Quelltext, aber kein NVIDIA-Repository für diesen Mapper, die Snippets oben sind also Erklärungen und kein einsatzfertiger Code. Für den Serving-Kontext lohnen die TensorRT-LLM-Doku zur KV-Cache-Wiederverwendung und der arXiv-Eintrag des Papers.

Was man im Kopf behalten sollte

KV-Caches galten bisher meist als Zustand, der zu einem Modell gehört. Wird die Übertragung zwischen Modellen zuverlässig genug, fällt diese Annahme weg.

Für Agenten-Infrastruktur ist die spannende Zukunft nicht nur ein Router, der pro Anfrage ein Modell wählt. Es ist ein Router, der einen gewachsenen Gesprächszustand zwischen kompatiblen Modellen verschiebt, ohne die vollen Kontextkosten ein zweites Mal zu zahlen.

Nichts davon macht KV-Caches allgemein portabel. Die Decoding-Kosten bleiben, Routing über Familien hinweg ist nicht gelöst, und die schwächsten Paare zeigen, warum man jedes Paar testen muss. Aber das Ergebnis für Qwen3 14B → 32B zeigt, dass die im Attention-Zustand eines Modells gespeicherte Arbeit von einem anderen Modell günstiger wiederverwendet werden kann, als sie aus Text neu zu berechnen.

Lässt sich das auf echte Serving-Systeme übertragen, wird das Kaskadieren zwischen Modellen für lang laufende Agenten deutlich interessanter. Die Frage ist dann nicht mehr nur, welches Modell den nächsten Schritt beantwortet, sondern auch, wie viel von der Rechenarbeit des vorherigen Modells mitkommen kann.