Zum Inhalt springen
Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.

Qwen-Image 2.1: Blockkausale Attention, Prefix-KV-Cache und Turbo

Ein quellengestützter Guide zum Single-Stream-Diffusion-Transformer von Qwen-Image 2.1: gemeinsame Text-/Bild-Tokens, blockkausale Maskierung, 3-Achsen-RoPE, Prefix-KV-Cache und 8-Schritt-Turbo-Zeitplan.

8 Min. Lesezeitflozi00
aiqwenmultimodalarchitecturediffusionattentionkv-cacheinference

Qwen-Image 2.1 macht einen Teil der Sequenz eines Diffusion-Transformers über die Denoising-Schritte hinweg unveränderlich. Text- und Referenzbild-Tokens bilden ein blockkausales Präfix. Das verrauschte Zielbild darf dieses Präfix lesen, aber das Präfix nicht das Zielbild. Zusätzlich werden Präfix-Tokens mit Zeitpunkt null statt mit dem aktuellen Rauschpegel moduliert. Ihre Hidden States, Keys und Values bleiben deshalb von einem Denoising-Schritt zum nächsten gültig.

Das ist der Mechanismus hinter dem Prefix-KV-Cache von Qwen-Image 2.1. Sein Lebenszyklus unterscheidet sich von einem autoregressiven LLM-Cache: Wiederverwendet werden feste Konditionierungsdaten, während alle Zielbild-Tokens in jedem Diffusionsschritt gemeinsam neu berechnet werden. Dieser Artikel behandelt den veröffentlichten Basis-Checkpoint vom 20. September 2026 und den selbst hostbaren Turbo-Checkpoint vom 9. Oktober 2026. Die Quellen wurden am 10. Oktober anhand unveränderlicher Modell- und Diffusers-Revisionen geprüft.123

Die veröffentlichte Pipeline

Qwen-Image 2.1 ist ein einheitliches Modell für Text-zu-Bild-Erzeugung und Bildbearbeitung. Dieselbe Pipeline verarbeitet einen Prompt, bis zu zehn Referenzbilder und eine verrauschte Zielfläche. Der visuelle Generator mit 7B Parametern ist ein Single-Stream-Diffusion-Transformer mit 32 Blöcken. Offizielle Integrationen existieren für Diffusers und ComfyUI; Serving-Pfade sind für vLLM-Omni, SGLang und LightX2V dokumentiert.12

Die vollständige Pipeline besteht aus drei relevanten Stufen:

  1. Ein Qwen3-VL-Encoder bildet Prompt und Referenzbilder auf kontextualisierte Darstellungen mit Breite 4.096 ab.
  2. Ein VAE bildet Referenz- und Zielbilder auf ein latentes Gitter mit 64 Kanälen und 16-facher räumlicher Verkleinerung ab.
  3. Der visuelle Transformer mit 32 Blöcken sagt für jedes Ziellatent am aktuellen Denoising-Zeitpunkt das Flow-Update voraus.

Der Checkpoint verwendet die Qwen Research License statt Apache 2.0. Self-Hosting wird technisch unterstützt, vor einem produktiven Einsatz müssen jedoch Lizenz und Pflichten der Anwendung geprüft werden.4

Ein Stream für Text, Referenzbilder und Ziel

TT sei die Anzahl gewöhnlicher Textpositionen nach der Prompt-Kodierung, CkC_k die Anzahl latenter Tokens des Referenzbilds kk und NN die Anzahl der Ziellatente. Für Breite WW, Höhe HH und den VAE-Skalierungsfaktor 16 gilt:

Ck=WkHk162,N=WH162,S=T+∑kCk+N.C_k=\frac{W_kH_k}{16^2},\qquad N=\frac{WH}{16^2},\qquad S=T+\sum_k C_k+N.

Das VLM repräsentiert jede Referenzbildposition zunächst gröber. Die Diffusers-Implementierung vervierfacht jede solche Position, weil sie einer 2×2-Gruppe von VAE-Latenten entspricht, und ersetzt diese erweiterten Positionen anschließend durch die tatsächlichen Referenzlatente mit 64 Kanälen. Die Ziellatente werden angehängt. Lineare Eingabeprojektionen bilden Textbreite 4.096 und Latentbreite 64 auf die gemeinsame Transformer-Breite 4.096 ab.5

Jeder Transformer-Block verwendet 32 Attention-Heads mit Breite 128. Für die gemeinsame Sequenz [B, S, 4096] haben die nicht fusionierten Q-, K- und V-Tensoren jeweils die Form [B, S, 32, 128]. Das ist gewöhnliche Multi-Head Attention und keine GQA: Jeder Query-Head hat einen eigenen Key- und Value-Head. Q und K werden vor RoPE je Head per RMS-Norm normalisiert. Das Attention-Ergebnis kehrt auf Breite 4.096 zurück; ein SwiGLU-Feed-Forward-Pfad erweitert auf 12.288 und projiziert zurück.65

Blockkausale Attention schafft die Cache-Grenze

Jede Position erhält eine Bildblock-ID: -1 für Text, eine eigene nichtnegative ID für jedes Referenzbild und eine weitere ID für das Ziel. Für Query-Position ii und Key-Position jj ist Attention – abgesehen von Padding-Keys – genau dann erlaubt, wenn:

Aij=1⟺(j≤i)  ∨  (gi=gj∧gi≥0).A_{ij}=1\quad\Longleftrightarrow\quad (j\le i)\;\lor\;(g_i=g_j\land g_i\ge0).

Text ist strikt kausal. Jeder Bildblock ist intern bidirektional, sodass alle latenten Positionen eines Bildes in derselben Schicht miteinander interagieren. Zwischen Blöcken bleibt die Sequenzreihenfolge kausal. Daraus folgt:

  • Ein Referenzbild kann früheren Text und jede Position in sich selbst nutzen, aber keinen späteren Text, keine späteren Bilder und nicht das verrauschte Ziel.
  • Späterer Prompt-Text kann ein vorheriges Referenzbild lesen.
  • Der abschließende Zielblock kann das vollständige Präfix und jede Position im Ziel lesen.

Direkt benachbarte Referenzbilder behalten unterschiedliche IDs, selbst wenn sie kein Text trennt. Sie als einen Bildblock zu behandeln, würde dem früheren Bild fälschlich erlauben, das spätere bidirektional zu lesen. Diese Maske ist mehr als eine Attention-Optimierung: Sie definiert die Abhängigkeitsgrenze, die Prefix-Wiederverwendung mathematisch zulässig macht.5

Konditionierung mit Zeitpunkt null macht das Präfix invariant

Diffusion speist normalerweise den aktuellen Zeitpunkt in jedes Token ein. Würden Referenz-Tokens mit dem aktuellen Zeitpunkt moduliert, änderten sich ihre Schichtzustände und K/V-Projektionen in jedem Denoising-Schritt, obwohl ihre Pixel unverändert sind. Qwen-Image 2.1 setzt causal_condition=true und erzeugt ein zusätzliches Timestep-Embedding für t=0t=0.65

In jedem Block wählen Text- und Referenzbildpositionen Skalen und Residual-Gates aus t=0t=0; Zielpositionen wählen die Werte des aktuellen trt_r. Eine einzelne, gemeinsam verwendete Modulationsprojektion erzeugt diese Parameter für alle 32 Blöcke. Zusammen mit der Attention-Maske können Präfixzustände weder von trt_r noch von Ziellatenten abhängen:

hprefix(ℓ)=fℓ ⁣(hprefix(ℓ−1),t=0),htarget,r(ℓ)=gℓ ⁣(hprefix(ℓ−1),htarget,r(ℓ−1),tr).h_{\mathrm{prefix}}^{(\ell)}=f_\ell\!\left(h_{\mathrm{prefix}}^{(\ell-1)},t=0\right), \qquad h_{\mathrm{target},r}^{(\ell)}=g_\ell\!\left(h_{\mathrm{prefix}}^{(\ell-1)},h_{\mathrm{target},r}^{(\ell-1)},t_r\right).

Beim ersten Denoising-Schritt verarbeitet kv_cache_mode="extract" die vollständige gemeinsame Sequenz und speichert Post-RoPE-K/V des Präfixes für jede Schicht. Spätere Schritte verwenden "cached": Nur Zielzustände durchlaufen die Transformer-Blöcke, während gecachte Präfix-K/V mit frisch berechneten Ziel-K/V zusammengefügt werden. Die Implementierung klont die Präfixausschnitte. Eine lediglich zusammenhängende View könnte bei Batchgröße eins sonst die vollständige Prefill-K/V-Allokation über alle Schritte festhalten.57

Der Cache beseitigt die wiederholte Transformer-Verarbeitung des Präfixes. Er beseitigt nicht die Attention des Ziels auf dieses Präfix. In jedem Schritt und jeder Schicht vergleichen NN Ziel-Queries weiterhin P+NP+N Keys mit P=T+∑CkP=T+\sum C_k. Diese Unterscheidung entspricht dem allgemeinen KV-Cache-Guide: Gecachte Projektionsarbeit und Attention auf die gecachte Historie sind verschiedene Kosten.

Der Prefix-Cache tauscht Rechenaufwand gegen Speicher

Der veröffentlichte Transformer cacht zwei Tensoren für 32 Schichten, 32 Heads und Head-Breite 128. Für Batchgröße BB, Präfixlänge PP und bb Bytes je gecachtem Skalar betragen die logischen Nutzdaten:

Mprefix KV=2×32×32×128×B×P×b.M_{\mathrm{prefix\ KV}}=2\times32\times32\times128\times B\times P\times b.

Bei BF16 und Batchgröße eins sind das 524.288 Bytes = 0,5 MiB pro Präfix-Token. Ein Referenzbild mit 1.024×1.024 Pixeln liefert 64×64 = 4.096 latente Tokens und damit 2 GiB reine Präfix-K/V. Ein Referenzbild mit 2.048×2.048 Pixeln liefert 16.384 Tokens und 8 GiB. Prompt-Text ergänzt 0,5 MiB je endgültiger gemeinsamer Textposition. Das sind Berechnungen der Tensor-Nutzdaten, keine gemessenen VRAM-Spitzen.68

Die reale Allokation umfasst zusätzlich Transformer- und Qwen3-VL-Gewichte, VAE-Zustand, Ziellatente, Aktivierungen, Attention-Arbeitsbereiche, Allokator-Rundung und backendabhängige Puffer. Tensorparallelität kann Projektionen und Cache anders aufteilen. Wird echte Classifier-Free Guidance aktiviert, führt Diffusers einen positiven und einen negativen Transformer-Durchlauf aus und legt für beide einen eigenen Prefix-Cache an; Rechenaufwand und Cache-Nutzdaten verdoppeln sich annähernd. Der produktive Standard ist Guidance-Skala 1 ohne negativen Pfad.79

Ohne Cache durchlaufen Präfix-Tokens bei RR Denoising-Schritten alle Blöcke RR-mal. Mit Cache geschieht das einmal; in den übrigen R−1R-1 Schritten durchlaufen nur Ziel-Tokens die Blöcke. Der Attention-Term vom Ziel zum Präfix bleibt in jedem Schritt bestehen. Der Speedup hängt daher von P/NP/N, Auflösung, Attention-Backend, Speicherbandbreite und den Kosten anderer Pipelinestufen ab. Bei der Bildbearbeitung mit großen Referenzbildern kann der Cache viel Berechnung sparen und zugleich erhebliche VRAM-Mengen belegen.

Drei-Achsen-RoPE erhält die Bildgeometrie

Die 128 Dimensionen jedes Attention-Heads verteilen sich als (16, 56, 56) auf Frame-, Höhen- und Breitenachse; die RoPE-Basis ist 10.000. Textpositionen erhöhen auf allen drei Achsen eine gemeinsame Koordinate. In einem Bildblock bleibt die Frame-Koordinate an der durch vorherigen Text erreichten Position fest, während Höhen- und Breitenkoordinaten ein um null zentriertes Gitter bilden.65

Dadurch hängen die räumlichen Koordinaten eines Bildes nicht davon ab, an welcher Stelle sein Block im Prompt steht. Wird ein Referenzblock nach hinten verschoben, ändert sich seine Frame-Koordinate, nicht aber sein internes Höhen-/Breitengitter. RoPE verändert Q und K, nicht V, und ändert die Cache-Breite von 128 Werten nicht.

Zwei exakte Attention-Pfade mit unterschiedlichen Betriebsanforderungen

Der Standardprozessor von Diffusers implementiert den blockkausalen Prefill als mehrere exakte Attention-Aufrufe: einen für jedes Text- oder Bildsegment des Präfixes und einen für das Ziel. Ein Textsegment erhält ein kausales Dreieck über sich selbst; ein Bildsegment sieht alle vorherigen Keys und den vollständigen eigenen Block. Das funktioniert ohne Kompilierung, startet aber mehrere Attention-Operationen pro Schicht.5

Der optionale FlexAttention-Prozessor bildet dieselbe Regel als BlockMask mit 128-Token-Blöcken ab und verarbeitet den Prefill in einem Aufruf. Er benötigt PyTorch 2.5 oder neuer und sollte kompiliert werden. Die versionierte Implementierung warnt, dass nicht kompiliertes FlexAttention eine dichte FP32-Score-Matrix materialisiert und bei hoher Auflösung in einen Speichermangel laufen kann. Spätere gecachte Schritte brauchen die blockkausale Maske nicht mehr: Zielzeilen dürfen vollständig auf [gecachtes Präfix, Ziel] zugreifen, sodass das konfigurierte Attention-Backend sie direkt verarbeitet.59

Die Backend-Wahl ist daher eine Betriebsentscheidung und keine Modellqualitätsentscheidung. Prefill-Latenz, Latenz je Denoising-Schritt, VRAM-Spitze, Kompilierungsaufwand, unterstützte Auflösung und Parallelität müssen mit der exakten Laufzeitrevision verglichen werden. Derselbe Checkpoint kann deutlich unterschiedliche Kernelpfade nehmen.

Was Turbo ändert – und was nicht

Qwen-Image 2.1 Turbo hat dieselbe Architektur und dieselben Tensorformen des visuellen Transformers wie das Basismodell. Beide Konfigurationen nennen 32 Schichten, 32 Heads, 128 Dimensionen je Head, Breite 4.096, 64 Latentkanäle und causal_condition=true. Turbo ist ein beschleunigter Checkpoint für eine Trajektorie mit acht Schritten und kein kleinerer Transformer.1011

Die Basispipeline verwendet standardmäßig 40 Denoising-Schritte und verschiebt ihren FlowMatch-Euler-Zeitplan dynamisch mit der Sequenzlänge. Turbo speichert den folgenden Zeitplan aus acht Sigma-Werten in model_index.json und deaktiviert die dynamische Verschiebung:

text
1.000000, 0.978453, 0.954180, 0.926626,
0.895080, 0.845148, 0.704534, 0.414568

Diffusers lädt den gespeicherten Zeitplan automatisch. Nur num_inference_steps zu setzen ersetzt ihn nicht. Acht statt 40 bedeuten fünfmal weniger Denoiser-Durchläufe, aber keinen garantierten fünffachen Wall-Clock-Speedup: Prompt-/Referenzkodierung, VAE-Encode/Decode, Cache-Prefill im ersten Schritt, Speicherbewegungen und Laufzeit-Overhead schrumpfen nicht um denselben Faktor.37

Prefix-Caching kann in reduzierter Präzision außerdem andere Ausgabebits erzeugen. Diffusers dokumentiert, dass gecachter und ungecachter Pfad dieselbe Berechnung unterschiedlich kacheln; eine Abweichung um eine ULP kann sich über 32 Blöcke und mehrere Schritte verstärken. Beide liegen innerhalb derselben Toleranz zur FP32-Referenz. Für reproduzierbare Deployments müssen dennoch Checkpoint, Zeitplan, Präzision, Backend, Kompilierungszustand und use_kv_cache festgelegt werden.

Betriebsgrenzen

Die Architektur ist nützlich, weil sie unveränderliche Konditionierung vom zeitabhängigen Ziel trennt, ohne bidirektionale Interaktion innerhalb eines Bildes aufzugeben. Der Vorteil bleibt bedingt: Prefix-Wiederverwendung spart wiederholte Präfixberechnung, während hochauflösende Referenzen eine große persistente K/V-Allokation erzeugen. Turbo reduziert die Schrittzahl, lässt aber die Transformer-Breite pro Schritt und die Ziel-Attention unverändert.

Für die Kapazitätsplanung müssen Ziel- und Referenzlatentenzahlen aus den tatsächlichen Abmessungen nach dem Resize berechnet, ein positiver und optional ein negativer Cache berücksichtigt sowie VRAM-Spitzen während Prefill und späteren Schritten gemessen werden. Cache-Präzision ist von Gewichtsquantisierung zu trennen. Basis und Turbo sollten mit identischen Prompts, Seeds, Auflösungen, Referenzen, Backends und Ausgabekriterien verglichen werden. Acht-Schritt-Erzeugung ist ein anderer Checkpoint mit anderer Trajektorie und nicht das 40-Schritt-Modell mit geändertem Schleifenzähler.

Primärquellen und Revisionsgrenze

Die folgenden Modell- und Implementierungslinks sind fest auf Revisionen gesetzt. Das Qwen-Release-Repository ist auf die Ankündigungsrevision vom 9. Oktober fixiert, Diffusers auf die für die Implementierungsanalyse verwendete Revision. Bei einem Upgrade müssen Cache-Layout und Backend-Verhalten erneut geprüft werden.

Footnotes

  1. Qwen, Qwen-Image-2.1-Release-Repository auf 1993c3a: Veröffentlichungstermine, Integrationen und Turbo-Verwendung. ↩ ↩2

  2. Qwen, Qwen-Image-2.1-Checkpoint auf d26bb61. ↩ ↩2

  3. Qwen, Qwen-Image-2.1-Turbo-Checkpoint auf d65dbc9: Zeitplan mit acht Schritten und Verwendung. ↩ ↩2

  4. Qwen, Lizenz von Qwen-Image 2.1 Turbo. ↩

  5. Hugging Face, QwenImage21Transformer2DModel auf Diffusers 1d5d056: Sequenzaufbau, Maske, RoPE, Blöcke, Prozessoren und Cache. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  6. Qwen, Konfiguration des Basis-Transformers. ↩ ↩2 ↩3 ↩4

  7. Hugging Face, QwenImage21Pipeline auf derselben Diffusers-Revision: Zeitplan, CFG und Cache-Lebenszyklus der Denoising-Schleife. ↩ ↩2 ↩3

  8. Qwen, VAE-Konfiguration des Basismodells. ↩

  9. Hugging Face, Diffusers-Dokumentation zu Qwen-Image 2.1 auf derselben Revision: Standardschritte und Anforderungen für kompiliertes FlexAttention. ↩ ↩2

  10. Qwen, Index der Basispipeline und Scheduler-Konfiguration. ↩

  11. Qwen, Konfiguration des Turbo-Transformers und Pipeline-Index. ↩