FlashLoop, oder: Wer einen Transformer loopt, vervierfacht die Rechnung — und wirft das Meiste wieder weg

Das Verkaufsargument gelooped Transformer ist eine arithmetische Häresie: Tiefe ohne Parameter. Statt 32 einzigartige Blöcke zu stapeln, nimmt man ein kleines Modell und wendet denselben Block R-mal pro Token an — der Universal-Transformer-Move, 2025-2026 wiederbelebt von der Ouro-Familie und von Huginn-3.5B, das die Rekursionszahl als Regler für Testzeit-Rechenzeit behandelt¹²³. Weniger Gewichte auf der Platte, mehr Rechnung pro Token, und im Prinzip tauscht man Paramet­erspeicher gegen FLOPs zu einem Kurs, den man selbst bestimmt.

Die Rechnung kommt bei der Inferenz. FlashLoop — ein trainingsfreies Inferenz-Framework von Wanqi Yang und Shiwei Liu (ELLIS Institute Tübingen / Max-Planck-Institut für Intelligente Systeme / Tübingen AI Center, arXiv:2609.29812, 24. September 2026) — eröffnet mit den Zahlen, die geloopte Transformer teuer machen, und sie sind drastisch: Laut Paper dauert auf einer A100 das Prefill eines 32K-Token-Prompts bei Ouro-2.6B (vier Loops) 27 Sekunden gegenüber 3 Sekunden bei LLaMA-3.1-8B, und Ouros loop-übergreifender KV-Cache wird mit 48 GiB angesetzt gegenüber 4 GiB beim LLaMA-Modell⁴. Ein Modell mit etwa einem Drittel der Parameter kostet die neunfache Prefill-Zeit und das zwölffache Cache-Speicher. Die Diagnose des Papers: Ein N-Block-geloopter Transformer mit R Loops führt R x N Block-Auswertungen aus und, in eigenen Worten, "each additional loop incurs another Transformer pass and requires caching another set of KV states" — Berechnung und Cache wachsen beide linear mit der Loop-Tiefe⁴.

Der Ansatz des Papers beruht auf der Beobachtung, dass ein Teil dieses Wachstums redundant ist: Mit fortschreitender Rekursion konzentrieren sich Hidden-State-Änderungen auf eine schrumpfende, verschachtelte Teilmenge von Tokens; die wichtigen Attention-Spalten sind dünn besetzt und stabil über Loops hinweg; und das KV-Residuum zwischen benachbarten Loops schrumpft so weit, dass man es aggressiv komprimieren kann. Dieser Guide prüft zuerst die Mathematik, dann das Silizium: warum KV-Traffic Decode in einer illustrativen Roofline-Rechnung begrenzen kann, was die drei Komponenten tatsächlich berechnen, ob die Speicher-Arithmetik die Schlagzeile von 6× reproduziert und was "lossless" an Genauigkeitspunkten kostet. Alle Zahlen stammen entweder wörtlich aus dem Paper oder sind in den Zellen berechnet und als solche markiert; die Simulation in Zelle 2 ist ein klar gekennzeichnetes Toy-Analog.

1. Warum Loopen FLOPs und KV-Bytes koppelt

Schreibe den geloopten Block wie das Paper: H^(r) = F_theta(H^(r-1)), mit F_theta geteilt über alle Loops r = 1..R. Naiv wird F_theta auf alle Tokens in jedem Loop angewendet, "while a separate pair of keys and values, (K^(r), V^(r)), is stored for each loop" — die effektive Rechnung pro Token sind also R Durchgänge über die geteilten Gewichte, und der Cache trägt R eigene KV-Tensoren⁴. Das ist die gesamte Kopplung: Anders als bei einem normalen Transformer, bei dem Tiefe und KV-Footprint getrennte Achsen sind, skalieren beim geloopten Transformer beide mit R. Tiefe verdoppeln verdoppelt FLOPs und Cache, identisch.

KV-Traffic kann das Batch-1-Decode dominieren; der tatsächliche Engpass hängt jedoch von Modell, Kontext, Kernel und Hardware ab. Die folgende Verhältnisrechnung nutzt die 32K-KV-Größe des Papers als hypothetisches Verkehrsbeispiel. Sie ist weder eine gemessene Decode-Intensität noch ein Messergebnis auf einer 40GB-A100.

# Cell 1: the looped-transformer cost model at the paper's 32K configuration
S = 32768
GiB = 1024 ** 3
mv = 48.0 * GiB                 # paper: Ouro-2.6B cross-loop KV at 32K, R=4, BF16
 
for R_ in (1, 2, 4):
    print(f"R={R_}: block evaluations per generated token = R x N = {R_}N")
 
# paper: 32K prefill on one A100, Ouro-2.6B (R=4) vs LLaMA-3.1-8B
t_ouro, t_llama = 27.0, 3.0
kv_ouro, kv_llama = 48.0, 4.0
print(f"prefill 32K on A100: Ouro-2.6B (R=4): {t_ouro:.0f} s   LLaMA-3.1-8B: {t_llama:.0f} s   ratio {t_ouro/t_llama:.1f}x")
print(f"peak KV@32K:           Ouro-2.6B: {kv_ouro:.0f} GiB  LLaMA-3.1-8B: {kv_llama:.0f} GiB  ratio {kv_ouro/kv_llama:.1f}x")
print(f"Ouro-2.6B has ~{8/2.6:.2f}x fewer parameters, but {t_ouro/t_llama:.0f}x the prefill time and {kv_ouro/kv_llama:.0f}x the KV memory")
 
# implied KV payload per (token, loop) cell
print(f"implied bytes per (token, loop): {mv/(S*4):,.0f} B  (includes all layers in a loop)")
 
# A100-SXM4-40GB theoretical ridge; illustrative ratio, not a device result
bw, tflops = 1555.0, 312.0        # GB/s, BF16 TFLOPS
ridge = tflops * 1e12 / (bw * 1e9)
flops = 2 * 2.6e9 * 4                  # upper-bound proxy: all 2.6B weights used in each loop
print(f"A100 ridge point: {tflops:.0f} TFLOPS / {bw:.0f} GB/s = {ridge:.0f} FLOPs/byte")
print(f"illustrative FLOPs per KV byte (weight traffic omitted): {flops/mv:.2f}")
print(f"-> {ridge/(flops/mv):.0f}x below the theoretical ridge under these assumptions")

R=1: block evaluations per generated token = R x N = 1N
R=2: block evaluations per generated token = R x N = 2N
R=4: block evaluations per generated token = R x N = 4N
prefill 32K on A100: Ouro-2.6B (R=4): 27 s   LLaMA-3.1-8B: 3 s   ratio 9.0x
peak KV@32K:           Ouro-2.6B: 48 GiB  LLaMA-3.1-8B: 4 GiB  ratio 12.0x
Ouro-2.6B has ~3.08x fewer parameters, but 9x the prefill time and 12x the KV memory
implied bytes per (token, loop): 393,216 B  (includes all layers in a loop)
A100 ridge point: 312 TFLOPS / 1555 GB/s = 201 FLOPs/byte
illustrative FLOPs per KV byte (weight traffic omitted): 0.40
-> 497x below the theoretical ridge under these assumptions

Die 393.216 B pro Token und Loop folgen aus 48 GiB / (32K × 4); sie umfassen alle Layers im wiederholten Block. Die 0,40 FLOPs pro KV-Byte setzen vereinfachend voraus, dass alle 2,6 Mrd. Parameter viermal verwendet werden, und lassen Gewichts- und anderen Speicherverkehr weg. Das veranschaulicht einen möglichen KV-Bandbreitenengpass, ist aber kein gemessener Roofline-Punkt. Außerdem übersteigt das 48-GiB-KV-Beispiel allein die 40GB-Kapazität der A100-SXM4-40GB aus der separaten Effizienzstudie. Ohne nicht dokumentiertes Offloading oder eine andere A100-Konfiguration können diese Zahlen nicht denselben vollständig residenten 32K-Ouro-2.6B-Lauf beschreiben⁴.

2. der Redundanzbefund — was das Paper wirklich gemessen hat

Der empirische Kern von FlashLoop, Abschnitt 3 des Papers, ist eine Charakterisierung der loop-übergreifenden Dynamik über die Ouro-Modelle und Huginn-3.5B hinweg — drei Befunde zunehmender Dünnbesetztheit mit der Loop-Tiefe⁴:

1. Token-Update-Redundanz. Hidden-State-Updates konzentrieren sich auf eine kleine Teilmenge von Tokens mit nicht vernachlässigbaren Änderungen; diese aktiven Mengen sind "approximately nested" — aktive Tokens eines späteren Übergangs sind größtenteils eine Teilmenge der im vorherigen Übergang aktiven. Weil Keys und Values unabhängig aus der Repräsentation jedes Tokens berechnet werden, induziert Token-Dünnbesetztheit mechanisch KV-Update-Dünnbesetztheit.
2. Attention-Spalten-Redundanz. Loop-übergreifende Differenzen im Attention-Output konzentrieren sich auf eine dünne Teilmenge von Attention-Spalten (Key/Value-Indizes), deren Wichtigkeit über benachbarte Loops stabil ist — stabil genug, dass die Attention-Statistiken des vorherigen Loops vorhersagen, welche Spalten im nächsten wichtig sind. Die konkrete Zahl des Papers: In Loop 3/4 von Ouro-1.4B "updating only 10% of the columns can reconstruct over 90% of exact attention output"⁴.
3. KV-Speicher-Redundanz. Das Residuum X^(r) - X^(r-1) zwischen benachbarten KV-Zuständen schrumpft mit der Loop-Tiefe, sodass es sich billiger quantisieren lässt als der volle Zustand: Die Quantisierung loop-übergreifender Residuen ergibt geringeren Rekonstruktionsfehler als die Quantisierung voller KV-Zustände beim gleichen Bit-Budget, und der Vorteil wächst mit der Loop-Tiefe.

Das Paper drückt keine per-Loop-Perzentiltabelle des marginalen Zustands in Prosa aus — die exakten Abklingkurven leben in seinen Abbildungen (2 und 3), die das Paper als sinkende Residuum-Magnituden mit der Tiefe ausweist, sowie in Abbildung 8 (Anhang B), gemessen über Huginn-3.5Bs 32 Loops. Was im Text prüfbar ist: die Verschachtelungsaussage, die 10%-Spalten-für-90%-Output-Zahl und die Richtung jedes monotonen Befunds. Die folgende Zelle gibt nicht vor, ihre Messungen zu reproduzieren — sie baut ein gekennzeichnetes Toy mit der qualitativen Form, die sie berichten (geometrisch abfallende Update-Normen, verschachtelte aktive Mengen nach der eigenen Tabelle-5-Loop-Planung des Papers, schwerlastige Spaltenmassen), damit die Zahlen des nächsten Abschnitts einen konkreten Referenten haben.

# Cell 2: toy analog of the lazy-update pattern (NOT the paper's data)
# A clearly-labeled toy: 4096-token context, 4 loops. Each loop's hidden-state
# update has a Frobenius norm decaying geometrically (rho=0.45), with the mass on
# a shrinking nested top-k token subset at the paper's own Table 5 schedule for
# Ouro-2.6B (loops 1-2 dense, loop 3: 20% tokens, loop 4: 8%).
import random
 
rng = random.Random(2609)
S = 4096
rho = 0.45
active = list(range(S))
mag, norms, fracs = 1.0, [], []
for r in range(1, 5):
    mag *= rho if r > 1 else 1.0
    if r == 3:
        active = sorted(rng.sample(active, int(0.20 * S)))
    elif r == 4:
        active = sorted(rng.sample(active, int(0.08 * S)))
    norms.append(mag)
    fracs.append(len(active) / S)
 
print("loop r : ||dH^r|| (a.u.) : active-token fraction")
for r in range(4):
    print(f"  {r+1}    :   {norms[r]:.4f}      :  {fracs[r]*100:5.1f}%")
print("")
print("marginal change contributed by loop r, as % of loop-1 change:")
tot = sum(norms)
for r in range(4):
    print(f"  loop {r+1}: {norms[r]/norms[0]*100:6.2f}%  (cumulative {sum(norms[:r+1])/tot*100:5.1f}% of all change)")
print("")
print("token-update FLOPs actually spent under the nested schedule:")
rel = sum(fracs)
print(f"  100% + 100% + 20% + 8% = {rel*100:.0f}% of a dense 4-loop pass")
 
# toy attention-column mass (heavy tail analog; NOT the paper's measurement)
rng2 = random.Random(42)
S2 = 4096
w = sorted((rng2.paretovariate(1.07) for _ in range(S2)), reverse=True)
tot2 = sum(w)
print("")
print("toy attention: top 10% of key columns carry " + f"{100*sum(w[:S2//10])/tot2:.1f}" + "% of probability mass")
print("  (paper, Ouro-1.4B loop 3/4: updating 10% of the columns reconstructs over 90%)")

loop r : ||dH^r|| (a.u.) : active-token fraction
  1    :   1.0000      :  100.0%
  2    :   0.4500      :  100.0%
  3    :   0.2025      :   20.0%
  4    :   0.0911      :    8.0%
 
marginal change contributed by loop r, as % of loop-1 change:
  loop 1: 100.00%  (cumulative  57.4% of all change)
  loop 2:  45.00%  (cumulative  83.2% of all change)
  loop 3:  20.25%  (cumulative  94.8% of all change)
  loop 4:   9.11%  (cumulative 100.0% of all change)
 
token-update FLOPs actually spent under the nested schedule:
  100% + 100% + 20% + 8% = 228% of a dense 4-loop pass
 
toy attention: top 10% of key columns carry 79.3% of probability mass
  (paper, Ouro-1.4B loop 3/4: updating 10% of the columns reconstructs over 90%)

Die Kurzfassung des Befundes: Späte Loops kosten wie volle Durchgänge, liefern aber wie Deltas. In der Form des Toys liefern die Loops 3 und 4 zusammen unter 30% des Gesamt-Updates, während eine dichte Implementierung sie weiterhin mit 50% der FLOPs und 50% des neuen KV-Speichers in Rechnung stellt. Zu beachten, was das Toy nicht behauptet: Es sagt nicht, dass der letzte Loop nahe null liegt (9% Gesamtänderung sind nichts Geringes), und das Paper behauptet das auch nicht — seine eigene Tabelle 5 hält 8-10% der Tokens und Spalten bis zum Ende aktiv, und seine Genauigkeitsspalten (Abschnitt 4 unten) zeigen, dass sie komplett zu streichen nicht frei wäre.

3. Was FlashLoop tatsächlich berechnet — und die Speicher-Arithmetik, die daraus folgt

Das Framework besteht aus drei Komponenten, alle zur Inferenzzeit, trainingsfrei, laut Paper⁴:

• Loop-übergreifende Token-Sparse-Updates. Nach dichten frühen Loops ordnet jeder Loop die zuvor aktualisierten Tokens nach normierter Hidden-State-Änderung und behält eine Top-k-Teilmenge für die weitere Verfeinerung. Übersprungene (konvergierte) Tokens verwenden Hidden- und KV-Zustände des vorherigen Loops wieder, und da spätere Auswahlen auf frühere aktive Mengen beschränkt sind, verschachteln sich die aktiven Mengen. Neue KV-Einträge werden nur für aktive Tokens geschrieben.
• Loop-bewusste Sparse-Attention. Jeder Sparse-Loop ordnet die Key-Spalten nach den Attention-Statistiken des vorherigen Loops, wählt Top-K unter einem loop-spezifischen Budget und berechnet nur die Beiträge dieser Spalten neu — über Gleichung 3 des Papers, eine Rang-K-Korrektur des Attention-Outputs des vorherigen Loops. Entscheidend: Ein Softmax über die ausgewählten Spalten allein würde ihre Masse auf 1 renormalisieren und sie überschätzen, daher cached FlashLoop die globale Wahrscheinlichkeitsmasse der Spalten aus der vollen Verteilung des vorherigen Loops und reskaliert.
• Loop-übergreifende KV-Residuum-Quantisierung. Die K/V-Zustände des ersten Loops bilden eine quantisierte INT4-Basis (gruppenweise asymmetrisch, Gruppe 64, post-RoPE-Keys per Kanal, Values per Token, die 64 jüngsten Tokens bleiben BF16); jeder weitere Loop speichert nur das quantisierte Residuum X^(r) - X_hat^(r-1), und zwar nur für aktive Tokens⁵.

Für die Nutzdatenrechnung muss man die 48 GiB zunächst auf alle vier Loops verteilen und dann die Retention pro Loop anwenden. Bei Ouro-2.6B und 32K entfallen 12 GiB BF16 auf jeden Loop. INT4 benötigt ein Viertel der BF16-Bytes; Loops 1–2 halten alle Tokens, danach bleiben 20 % und 8 % aktiv:

# Illustrative ideale Nutzdaten, nicht der gemessene Peak-Speicher des Papers.
baseline_gib, loops, context = 48.0, 4, 32768
retained = [1.0, 1.0, 0.20, 0.08]
int4_vs_bf16 = 4 / 16
packed_gib = (baseline_gib / loops) * int4_vs_bf16 * sum(retained)
# Letzte 64 Tokens BF16 statt INT4: nur die Differenz addieren.
tail_extra_gib = baseline_gib * (64 / context) * (1 - int4_vs_bf16)
total_gib = packed_gib + tail_extra_gib
print(f"ideal INT4 payload: {packed_gib:.2f} GiB")
print(f"BF16-tail extra:    {tail_extra_gib:.2f} GiB")
print(f"ideal total:        {total_gib:.2f} GiB")
print(f"ideal reduction:    {baseline_gib / total_gib:.2f}x")

ideal INT4 payload: 6.84 GiB
BF16-tail extra:    0.07 GiB
ideal total:        6.91 GiB
ideal reduction:    6.95x

Die ideale Nutzdatenreduktion liegt damit in der Größenordnung des berichteten 6,06×-Peak-KV-Ergebnisses, nicht bei 1,75×. Der Unterschied lässt sich aus diesen Angaben nicht einem einzigen Mechanismus zuordnen: Quantisierungsmetadaten, Allokationsgranularität, tatsächliche Sequenzlängen und die Definition des Peak-KV-Speichers können beitragen. Die 6,06× aus Tabelle 1 stammen aus Benchmark-Läufen; die 82,8 % aus Abbildung 6 betreffen eine separate 32K-Kontextskalierung und dürfen nicht unmittelbar vom 48-GiB-Ouro-2.6B-Beispiel abgezogen werden⁴. Sparse Attention verändert Lesezugriffe und Rechenaufwand; Token-Retention und INT4 erklären primär die Nutzdatengröße. Ohne gemessene Zeitanteile begründet diese Rechnung keine Amdahl-Grenze für das 1,64×-End-to-End-Ergebnis.

4. "Lossless": was es in diesem Paper operativ bedeutet

Das Abstract behauptet, FlashLoop erreiche "lossless accuracy while achieving up to 1.64x end-to-end speedup and up to 6x KV-cache memory reduction"⁴. In den Tabellen bedeutet "lossless" Durchschnittsgenauigkeit innerhalb von Bruchteilen eines Prozentpunkts auf fünf Benchmarks — Math-Scores auf MATH-500 und GSM8K, plus ARC-Challenge, HellaSwag, WinoGrande — unter dem EleutherAI-Harness, nicht bit-exakte Outputs und kein statistischer Test. Die Deltas aus Tabelle 1, exakt wiedergegeben⁴:

• Ouro-1.4B: +0,37 Durchschnittspunkte (70,48 vs 70,11), 1,59-fache Beschleunigung, 5,85× KV
• Ouro-1.4B-Thinking: −0,88 (66,23 vs 67,11) — MATH-500 fällt von 46,80 auf 46,20; 1,59×, 5,85×
• Ouro-2.6B: −0,13 (71,08 vs 71,21), die die Schlagzeile tragenden 1,64×, 6,06× KV
• Ouro-2.6B-Thinking: −0,36 (72,24 vs 72,60), mit MATH-500 59,00 auf 55,60; 1,64×, 6,06×
• Huginn-3.5B: +0,17 (42,77 vs 42,60) mit GSM8K unten von 27,52 auf 25,70; 1,52×, 5,18×

Zwei Muster, die das Paper selbst benennt. Basismodelle sind robuster gegen die Kompression als ihre Thinking-Pendants — ein MATH-500-Rückgang um 3,4 Punkte bei Ouro-2.6B-Thinking ist nicht nichts, und das Paper sagt, Thinking-Modelle "may be more sensitive to cross-loop compression"⁴. Und die Ablation ist wirklich informativ: Ersetzt man die loop-übergreifende Residuum-Quantisierung durch direkte INT4-Quantisierung der vollen KV-Zustände (ihre "Per-loop KIVI4"-Zeile), fällt Ouro-1.4Bs Drei-Benchmark-Durchschnitt von 68,56 auf 67,12 — die Residuum-gegen-voll-Unterscheidung ist einen ganzen Genauigkeitspunkt wert, was direkte Evidenz dafür ist, dass der dritte Redundanzbefund des Papers einen Mechanismus hat, nicht nur eine Korrelation. Alternative Cache-Strategien verlieren weit mehr: Bei −75% KV fällt H2O bei Ouro-1.4B von 70,11 auf 62,81, die Last-Step-Reuse-Baseline landet bei 68,33, FlashLoop hält 70,48. Der Langkontext-Check (Anhang F) hält die WikiText-2-Perplexität bei 8K-32K (10,526 vs 10,513 bei 8K; 5,321 vs 5,589 bei 32K — die 32K-Zahl ist schlechter, nicht besser), Needle-in-a-Haystack bei 84,5% vs 83,0% Single-Needle und 7,5% vs 9,2% Multi-Needle. Ein Multi-Needle-Abfall um 1,7 Punkte in der Langkontext-Evaluation bei einem Schema, das bei Ouro-1.4B in Loop 4 nur 10 % der Spalten behält, ist die Art stiller Regression, die ein "lossless"-Label nicht decken sollte — und das Paper verdient Anerkennung dafür, es zu drucken.

Also: "Lossless" bedeutet hier Durchschnitts-Benchmark-Parität, demonstriert auf fünf Aufgaben mit Deltas innerhalb von etwa einem Punkt. Das ist eine starke und nützliche Aussage. Es ist keine Verlustfreiheit im Wassertzeichen-Sinn von Bit-Exaktheit, und ein Marketing-Überflug des Abstracts würde genau die zwei Zeilen verlieren, die die echte Information tragen — die Thinking-Modell-Deltas und die Multi-Needle-Zahl.

5. Fazit

Was Loop-Tiefe kauft: eine parametereffiziente Skalierungsachse mit, diesem Paper zufolge, ausbeutbarer Struktur — späte Loops sind Refactoring-Arbeit, keine frische Berechnung, und ein trainingsfreier Fahrplan (dichter Warmlauf, dann verschachtelte Token-Dünnbesetztheit, Top-K stabile Spalten, INT4-Residuum-Ketten) kann das Meiste ihrer Kosten zurückholen. Die Messergebnisse sind real: 1,52-1,64× End-to-End, 5,18-6,06× Peak-KV, durchschnittliche Genauigkeits-Deltas innerhalb eines Punktes, auf fünf öffentlichen Benchmarks über fünf geloopte Modelle, wobei die stärkste adversariale Evidenz ist, dass die naiven Alternativen (H2O, Last-Step-Reuse) mehrere Punkte verlieren, wo FlashLoop Bruchteile verliert.

Was die Schlagzeile einschränkt: Das korrigierte Nutzdatenmodell ergibt etwa 6,95× und liegt nahe der berichteten 6,06×-Peak-KV-Reduktion; Metadaten und Versuchsbedingungen sind für einen exakten Abgleich nötig. Das 1,64×-End-to-End-Ergebnis gilt für das Benchmark-Setup des Papers. Seine 32K-Kontextskalierung auf A100-SXM4-40GB darf nicht mit dem separaten 48-GiB-KV-Beispiel für Ouro-2.6B vermischt werden. Zudem zeigen Thinking-Varianten und Multi-Needle-Langkontext-Retrieval Genauigkeitsverluste, die für den Einsatz entscheidend sein können.

Was den Ansatz widerlegen würde: ein gelooped Modell, dessen späte Loops nicht redundant sind — eines, in dem späte Loop-Updates zwar klein in der Norm, aber tragfähig sind (die Norm-Konzentrationsaussage ist genau die Art von Ding, die auf Out-of-Distribution-Kontexten scheitert, und der Kalibrierungssatz hier waren 128 WikiText-2-Sequenzen, gewählt mit einer 5%-Rekonstruktionsfehler-Schwelle). Die Dünnbesetztheits-Planung des Schemas wird einmal pro Modell auf In-Domain-Text kalibriert; die ehrliche offene Frage ist, ob Verschachtelung und Spaltenstabilität Prompts überleben, die WikiText in nichts ähneln. Außerdem: adversariale Kontexte, die sich auf genau die Spalten konzentrieren, die die Planung streicht. Das Paper testet das nicht, und das Toy hier auch nicht — aber das ist das Experiment, das widerlegen würde, und die 2-Bit-Quantisierungs-Zeile in ihrer Abbildung 5 (klare Degradation) zeigt, dass die Klippe in Richtung Kompression existiert.

Das Fazit zur Grundrate: FlashLoop ist ein durchweg gutes Systemspaper mit einer etwas zu großen Schlagzeile. Der Redundanzbefund ist der Inhalt; das Framework ist der Beweis der Ausbeutbarkeit; die Zahlen überstehen die Prüfung größtenteils, und diejenigen, die Sternchen brauchen — lossless, 6×, 1,64× — haben jeweils zwei Tabellen tiefer im Paper eine vollständigere Version, die ein Betreiber lesen sollte, bevor er das Abstract zitiert.

6. Quellen