Disaggregierte Quantisierung: Prefill- und Decode-Kosten auf zwei Formate verteilen

Ein Paper von September 2026 aus dem Umfeld von NVIDIA und ISTA greift eine Annahme an, die so selbstverständlich eingebacken ist, dass die meisten Quantisierungsarbeiten sie nie aussprechen: dass ein Modell eine quantisierte Repräsentation braucht¹. Disaggregated Quantization: Specializing LLM Prefill and Decode (Panferov, Kleinegger, Priyadarshi, Blankevoort und Alistarh, arXiv:2609.26333, cs.LG, eingereicht am 22. September 2026) beobachtet, dass die beiden Phasen der LLM-Inferenz für Gegenteiliges bezahlen. Prefill verarbeitet den ganzen Prompt in einem Rutsch — das ist eine GEMM, begrenzt durch Arithmetik, also beschleunigen niedrigpräzise Rechenformate (NVFP4) ihn. Decode lädt bei Batch eins für jedes generierte Token sämtliche Gewichte aus dem Speicher, um ein einziges Token zu berechnen — das ist ein Speicherbandbreiten-Problem, also beschleunigen kompakte Gewichte (1-3 Bit) es. Disaggregierte Quantisierung (DQ) spezialisiert deshalb Rechenformate, Gewichte und sogar die Speicherplatzierung pro Phase statt pro Modell¹.

Das Paper ist kein neuer Quantisierer. Es ist ein phasenspezifischer Serving- und Trainingsansatz mit drei zunehmend aufwendigen Ausbaustufen: Aktivierungsquantisierung nur beim Decode deaktivieren; einen separaten rechennativen NVFP4-Prefill-Checkpoint auf dasselbe Antwortziel hin trainieren; und diesen zweiten Checkpoint von SSD streamen. Die Schnittstelle zwischen den Phasen bleibt der KV-Cache mit unveränderten Layer- und Head-Dimensionen¹. Die Varianten mit separaten Gewichten erfordern zwei Artefakte, die gespeichert und qualifiziert werden müssen. Die 1,78-fache TTFT-Verbesserung gilt für 8K Kontext in einem angepassten llama.cpp-Fork, und das Genauigkeitsplus von 32,5 Punkten erreicht keine BF16-Parität¹.

1. Der Roofline-Split: Warum die Phasen unterschiedliche Achsen haben

Die ganze Methode fällt aus einer einzigen Rechnung heraus. Ein linearer Stack mit P Parametern, der einen Prompt der Länge L verarbeitet, führt etwa 2·P·L Operationen aus. Beim Prefill lädt er die P Gewichte einmal pro Prompt; beim Decode mit Batch eins lädt er alle P Gewichte pro generiertem Token, um nur 2·P nützliche Operationen auszuführen. Gegen die bewegten Gewichtsbytes gemessen liegt die arithmetische Intensität bei 16·L/bw ops/byte für Prefill und 16/bw für Decode, wobei bw die Bits pro Gewicht sind — das Verhältnis der beiden ist exakt die Promptlänge.

Für eine illustrative Balance-Rechnung nutzen wir 273 GB/s Speicherbandbreite des DGX Spark und die Hälfte des beworbenen Sparse-FP4-Peaks von 1 PFLOP als nominellen Dense-FP4-Peak. NVIDIA veröffentlicht den theoretischen Sparse-Wert, keine gemessenen 500 Dense-TOPS. Diese FP4-Referenz sagt für BF16- oder eigene LUT-Kernel keinen tatsächlichen Crossover voraus².

# CELL 1: roofline split -- prefill vs decode vs weight precision
# Arithmetic intensity (AI) measured against WEIGHT bytes, per linear stack.
#   prefill: ops = 2*P*L, weight bytes = P*bw/8 once per prompt -> AI = 16*L/bw
#   decode (batch 1): ops = 2*P, weight bytes = P*bw/8 per token -> AI = 16/bw
# Machine: DGX Spark (NVIDIA spec sheet): 1000 TOPS FP4 *with sparsity*
# -> nominal 500e12 dense ops/s; 273 GB/s LPDDR5x.
 
FP4_DENSE_OPS = 500e12
MEM_BW = 273e9
 
def ai_decode(bw): return 16.0 / bw
def ai_prefill(L, bw): return 16.0 * L / bw
 
bal_fp4 = FP4_DENSE_OPS / MEM_BW
print("CELL 1: AI = ops per weight-byte (ops/byte), DGX Spark")
print(f"machine balance point at dense FP4: {bal_fp4:.0f} ops/byte")
print()
print("weight bits | decode AI | prefill AI L=512 | L=8192 | decode is")
for bw in (16.0, 8.0, 4.5, 2.5, 1.5):
    regime = "compute" if ai_decode(bw) >= bal_fp4 else "bandwidth"
    Lx = bal_fp4 * bw / 16.0
    print(f"  {bw:4.1f}      | {ai_decode(bw):8.2f} | {ai_prefill(512, bw):16.2f} | {ai_prefill(8192, bw):6.0f} | {regime}-bound")
    print(f"             nominal FP4-reference crossover L >= {Lx:.0f} tokens")

Output eines realen Laufs (Python 3):

CELL 1: AI = ops per weight-byte (ops/byte), DGX Spark
machine balance point at dense FP4: 1832 ops/byte
 
weight bits | decode AI | prefill AI L=512 | L=8192 | decode is
  16.0      |     1.00 |           512.00 |   8192 | bandwidth-bound
             nominal FP4-reference crossover L >= 1832 tokens
   8.0      |     2.00 |          1024.00 |  16384 | bandwidth-bound
             nominal FP4-reference crossover L >= 916 tokens
   4.5      |     3.56 |          1820.44 |  29127 | bandwidth-bound
             nominal FP4-reference crossover L >= 515 tokens
   2.5      |     6.40 |          3276.80 |  52429 | bandwidth-bound
             nominal FP4-reference crossover L >= 286 tokens
   1.5      |    10.67 |          5461.33 |  87381 | bandwidth-bound
             nominal FP4-reference crossover L >= 172 tokens

Die nur auf Gewichtsbytes bezogene arithmetische Intensität steigt mit der Promptlänge und ist bei Batch-eins-Decode niedrig. Die ausgegebenen Crossover-Längen sind Modellschätzungen mit demselben FP4-Peak für jede Zeile; BF16- und LUT-Kernel haben andere Rechengrenzen, und Attention, Aktivierungsverkehr, Skalen sowie weitere Operationen fehlen. Die gemessenen Batch-eins-Ergebnisse des Papers, nicht diese vereinfachte Balance-Linie, stützen den Schluss, dass kompakte Gewichte Decode und natives FP4-Rechnen langen Prefill begünstigen¹.

2. Die billigste Stufe: Decode-Gewichte behalten, Decode-Aktivierungsquantisierung verwerfen

Die unterste Stufe behält einen Satz Gewichte und ändert nur das Rechenformat pro Phase. NVFP4 quantisiert Gewichte und Aktivierungen (W4A4), was die Tensor-Cores wollen; die nur-gewichtete Variante NVFP4A16 lässt Aktivierungen in höherer Präzision, ist genauer, kann aber die schnelle FP4-GEMM nicht nutzen. Die Beobachtung des Papers: Beim Decode bringt die Aktivierungsquantisierung nichts (Decode ist bandbreitenbegrenzt — die Arithmetik steht ohnehin still) und kostet trotzdem Genauigkeit, weil die pro-Token-Hidden-States, die die Antwort transportieren, auf dasselbe grobe E2M1-Raster gesnappt werden, für das Prefill bereits bezahlt hat. Also: Aktivierungen nur beim Prefill quantisieren, den Aktivierungsquantisierer beim Decode überspringen. Speicher, Prefill-Kosten und Decode-Tempo bleiben unverändert oder minimal besser (das Überspringen macht Decode 2-3 % schneller), und die Decode-Genauigkeit steigt auf allen sieben getesteten Qwen-3- und Gemma-3-Modellen¹.

Tabelle 1 des Papers prüft den Effekt der Aktivierungsquantisierung besser als ein synthetisches MLP. Ihre Familienmittelwerte für Decode-lastige Aufgaben vergleichen dieselben gespeicherten Gewichte: Aktivierungsquantisierung in beiden Phasen ("einheitlich") gegen Abschaltung beim Decode ("formatdisaggregiert")¹:

# CELL 3: Prozentpunktänderungen aus den Familienmittelwerten in Tabelle 1.
rows = {
    "Qwen 3, NVFP4": (61.8, 63.7),
    "Gemma 3, NVFP4": (51.9, 55.0),
    "Qwen 3, LUT2": (34.8, 37.2),
    "Gemma 3, LUT2": (30.8, 32.6),
}
for name, (uniform, split) in rows.items():
    print(f"{name}: {split - uniform:+.1f} Prozentpunkte")

Qwen 3, NVFP4: +1.9 Prozentpunkte
Gemma 3, NVFP4: +3.1 Prozentpunkte
Qwen 3, LUT2: +2.4 Prozentpunkte
Gemma 3, LUT2: +1.8 Prozentpunkte

Das sind Familienmittelwerte der QADD-Experimente des Papers, keine Garantie für jede Workload. Die separate Post-Training-Quantisierungsprüfung verbessert 11 von 13 Punktschätzungen für Modell-Benchmark-Paare; sechs Gewinne sind bei der verwendeten Einzelvergleichsschwelle signifikant, keine Verschlechterung ist signifikant. Eines der acht Modelle, Kimi-K3, nutzt MXFP4 statt NVFP4; der unquantisierte Referenz-Checkpoint von Qwen3.8-2.4T liegt in FP8 vor¹.

3. Volle Disaggregation: Für den Prefill eigene Gewichte kaufen

Formatdisaggregation hat eine selbstauferlegte Decke: Prefill rechnet weiterhin auf einer re-quantisierten Sicht der 1-3-Bit-Decode-Gewichte („Autocast" quantisiert LUT-Gewichte plus Aktivierungen auf dem Flug nach NVFP4), die FP4-GEMM läuft also auf Eingaben, die die kompakte Kodierung bereits beschädigt hat. Die nächste Stufe gibt dem Prefill einen eigenen Checkpoint, der von Anfang an als rechennatives NVFP4 trainiert wird. QADD (quantization-aware distillation with disaggregation) trainiert beide Pfade auf ein Antwortziel in einem einzigen Forward-Backward-Pass und nutzt die SFT-Label-Maske, um Prompt-Positionen durch den Prefill-Pfad und Antwort-Positionen durch Decode zu schicken; Gradienten erreichen die Prefill-Gewichte über die Prompt-Keys und -Values, zu denen Decode später attendet¹. Tabelle 1 mittelt die Genauigkeit über Qwen-3- und Gemma-3-Modellgrößen; die Spalten für Gerätespeicher und Tempo beziehen sich dagegen auf Qwen3-8B und Gemma3-12B auf DGX Spark. Ihre 2-Bit-LUT2-Zeilen zeigen den Zielkonflikt¹:

• 2-Bit nur-gewichtetes Decode: Decode-lastig 38,4 / 33,7, 3,82-facher / 4,15-facher Decode-Speedup, 4,66 / 5,38 GB.
• LUT2-Autocast in beiden Phasen (nicht disaggregiert): Decode-lastig kollabiert auf 34,8 / 30,8 — Aktivierungsquantisierung beim Decode schadet — bei 1,49-fachem / 1,67-fachem Prefill-Speedup.
• Plus Formatdisaggregation: 37,2 / 32,6 — der größte Teil des Kollapses zurückgewonnen bei unveränderten Geräte-GB.
• Plus volle Disaggregation: 45,5 / 38,2 Decode-lastig und 76,6 / 61,3 Prefill-lastig — für LUT3/LUT2 meldet das Papier Gewinne über das nicht-disaggregierte Schema von 6,3 / 5,2 beziehungsweise 10,7 / 7,4 Decode-lastigen Punkten — aber der Gerätespeicher springt auf 8,57 / 11,43 GB: zwei Checkpoints.
• Plus ODP: dieselbe Genauigkeit bei wieder 4,66 / 5,38 GB, der Prefill-Speedup bleibt fast unangetastet (1,47-fach / 1,58-fach).

Der Prefiller ist also nicht nur schneller Prefill; er ist eine Rettungseinrichtung für Niedrigbit-Decode. Aber Zeile vier hat einen Preis: Der Speicher hat sich fast verdoppelt, bis ODP ihn zurückgab — das Thema des nächsten Abschnitts — und jedes voll-disaggregierte Modell wird als zwei Artefakte ausgeliefert.

4. Prefiller für eingefrorene Checkpoints: +32,5 Punkte — gemessen wogegen?

Das Experiment mit eingefrorenem Decoder beginnt mit acht Unsloth-GGUF-Checkpoints von Qwen3.8-27B, von IQ1_S bis Q3_K_XL³. Für Training und Genauigkeitsmessung dequantisieren die Autoren jeden GGUF-Decoder nach BF16 und frieren seine numerischen Gewichte ein; trainiert wird nur der NVFP4-Prefill-Pfad. Die MMLU-Pro-/MMMU-Pro-Werte messen deshalb weder das Tempo eines Low-Bit-Decode-Kernels noch den residenten GGUF-Speicher. Ein separater llama.cpp-Versuch misst TTFT mit dem komprimierten IQ1_S-Checkpoint¹. Die Decode-Quantisierungspipeline bleibt eine Black Box: Das Prefiller-Training braucht ihren Checkpoint, nicht ihre Quantisierungsdaten oder ihren Algorithmus. Auf dem IQ1_S-Decoder (1 Bit) verschiebt der trainierte NVFP4-Prefiller MMLU-Pro von 29,04 auf 61,54 (+32,50 Punkte) und MMMU-Pro von 24,39 auf 59,65 (+35,26; das Abstract rundet auf 35,3), ohne die Decode-Gewichte anzutasten — die 1-Bit-Genauigkeit verdoppelt sich auf beiden Benchmarks mehr als¹. Die Gewinne werden bei höheren Bitbreiten meist kleiner — +19,71 MMLU-Pro bei IQ1_M, +7,42 bei IQ2_XXS und +2,80 bei IQ2_S —, aber nicht monoton. IQ3_XXS gewinnt noch +0,72 MMLU-Pro; IQ3_S und Q3_K_XL verlieren −0,63 und −0,62 MMLU-Pro, und die getesteten 3-Bit-Formate verlieren bis zu 2,77 MMMU-Pro-Punkte¹.

Zwei Fakten gehören zusammen. Erstens passen die Ergebnisse zu einem Repräsentationseffekt: Der Prefiller verändert die aus dem Prompt abgeleiteten KV-Einträge, während die Decoder-Gewichte fest bleiben. Das Paper isoliert keinen eindeutigen kausalen Anteil jeder veränderten Repräsentation. Zweitens zählt die Baseline: BF16-Qwen3.8-27B erzielt 84,62 MMLU-Pro und 75,26 MMMU-Pro in derselben Tabelle, die gerettete 1-Bit-Pipeline liegt mit 61,54 also noch etwa 23 Punkte unter der Vollempfindlichkeit. Die +32,5 sind die Distanz von einer kollabierten 1-Bit-Baseline zu einer deutlich weniger kollabierten — ein Beleg für eine große Genauigkeitserholung unter diesem Messprotokoll, keine BF16-Parität¹.

5. ODP: Der zweite Checkpoint lebt auf der SSD, und die Amortisation hat einen Crossover

Volle Disaggregation auf einem einzelnen Gerät sprengt den Speicher — hier wird die Speicherplatzierung Teil der Quantisierungsentscheidung. Offloaded disaggregated prefill (ODP) nutzt eine Phasen-Asymmetrie: Die Gewichte eines Prefill-Transformer-Blocks werden pro Prompt genau einmal berührt (während die Token Ebene für Ebene durchs Netzwerk strömen) und danach für den Rest der Runde nie wieder gebraucht. Der Prefill-Checkpoint kann also Block für Block von der SSD gestreamt werden, durch zwei rotierende Gerätepuffer, die aus dem eigenen Speicher der Decode-Gewichte herausgeschnitten werden (während des Prefills ungenutzt). Der Gewichts-Footprint auf dem Gerät fällt auf die Decode-only-Zahl zurück; der Preis ist SSD-Verkehr plus eine feste Ladezeit, die nur lange Prompts verstecken können¹.

Das folgende illustrative Modell kombiniert die nominellen 27 Milliarden Parameter und 4,5 Bit pro NVFP4-Gewicht des Papers mit angenommenen 3,5 GB/s dauerhafter SSD-Leserate. Seine 15,19 GB sind eine ungefähre berechnete Gewichts-Nutzlast, keine gemessene Checkpoint-Größe; weitere Tensoren, Metadaten und zusätzlicher Carve-out-Verkehr fehlen. Die Streaming-Kosten sind pro Prompt näherungsweise konstant, während der Rechenanteil linear mit der Promptlänge wächst:

# CELL 2: ODP SSD amortization for the Qwen3.8-27B NVFP4 prefiller.
# Full disaggregation stores a SECOND checkpoint (~4.5 bpw for NVFP4 incl.
# the FP8 block scales). ODP streams it from SSD: each transformer block is
# needed exactly once per prompt, so SSD time is FIXED while prefill compute
# grows linearly in L. Crossover L*: compute time == SSD load time.
# Illustration: paper reports compute overtaking SSD load around 8K for
# its Qwen 3 models on DGX Spark. Assume 3.5 GB/s for this 27B toy and
# back-solve throughput that makes its modeled crossover L* = 8192.
 
P = 27e9          # Qwen3.8-27B parameters
BPW = 4.5         # NVFP4 bits per weight incl. FP8-E4M3 scale per 16 elems
ckpt_gb = P * (BPW / 8) / 1e9
SSD = 3.5         # GB/s sustained
L_star = 8192
 
load_s = ckpt_gb / SSD                       # fixed SSD cost per prompt
T_ops = 2 * P * L_star / load_s             # back-solved FP4 throughput, not a measurement
print("CELL 2: ODP off the 27B NVFP4 prefiller")
print(f"estimated weight payload: {ckpt_gb:.2f} GB at {SSD} GB/s -> fixed load {load_s:.2f} s")
print(f"back-solved NVFP4 throughput: {T_ops/1e12:.0f} TOPS")
print()
print("L tokens | MB SSD / token | load s | compute s | load/compute")
for L in (1024, 2048, 4096, 8192, 16384, 32768):
    mb = ckpt_gb * 1e3 / L
    cs = 2 * P * L / T_ops
    print(f"{L:8d} | {mb:15.2f} | {load_s:6.2f} | {cs:9.2f} | {load_s/cs:11.2f}")
print()
print("crossover sensitivity (L* scales with SSD bandwidth):")
for g in (1.75, 3.5, 7.0):
    print(f"  SSD {g:4.2f} GB/s -> L* = {L_star * SSD / g:6.0f} tokens")

Output eines realen Laufs (Python 3):

CELL 2: ODP off the 27B NVFP4 prefiller
estimated weight payload: 15.19 GB at 3.5 GB/s -> fixed load 4.34 s
back-solved NVFP4 throughput: 102 TOPS
 
L tokens | MB SSD / token | load s | compute s | load/compute
    1024 |           14.83 |   4.34 |      0.54 |        8.00
    2048 |            7.42 |   4.34 |      1.08 |        4.00
    4096 |            3.71 |   4.34 |      2.17 |        2.00
    8192 |            1.85 |   4.34 |      4.34 |        1.00
   16384 |            0.93 |   4.34 |      8.68 |        0.50
   32768 |            0.46 |   4.34 |     17.36 |        0.25
 
crossover sensitivity (L* scales with SSD bandwidth):
  SSD 1.75 GB/s -> L* =  16384 tokens
  SSD 3.50 GB/s -> L* =   8192 tokens
  SSD 7.00 GB/s -> L* =   4096 tokens

In diesem angenommenen Modell übersteigt die Ladezeit unter 8K die Rechenzeit der linearen Schichten. Die ausgegebenen 102 TOPS sind aus dem gewählten 8K-Crossover und der angenommenen SSD-Rate rückgerechnet, kein gemessener Durchsatz. Das Paper misst separat, dass Rechnen in seinen Qwen-3-DGX-Spark-Experimenten die SSD-Last um 8K überholt; für Qwen3.8-27B in llama.cpp wird ODP ab 4K schneller als die nur-gewichtete IQ1_S-Baseline und erreicht bei 8K eine TTFT von 6,90 statt 12,27 s. Das sind verschiedene Vergleiche; der Spielzeug-Crossover sagt die 4K-Baseline-Kreuzung nicht voraus. Eine langsamere SSD verschiebt den modellierten Lade-/Rechen-Crossover nach oben, sofern das Rechentempo gleich bleibt. Die Autoren halten ODP für MoE-Modelle für weniger nützlich, weil pro geladenem Parameter weniger aktive Rechenarbeit anfällt¹.

6. Anti-Hype: Die Rechnung für die Phasenteilung

Das Limitationen-Kapitel und die Tabellen des Papiers beziffern die Kosten ehrlich; die Rechnung hat fünf Posten.

Zwei Artefakte speichern, qualifizieren und konsistent halten. Ein voll-disaggregiertes Deployment besitzt einen Decode-Checkpoint und einen Prefill-Checkpoint (Tabelle 1 für Qwen3-8B: 8,57 GB Gerätespeicher bei voller 2-Bit-Disaggregation gegenüber 4,66 GB für Weight-only). ODP entfernt die Geräte-Residenz, nicht das Artefakt: ein zusätzlicher Prefiller-Checkpoint liegt auf der SSD (die obigen 15,19 GB sind nur eine Nutzlastschätzung) und muss gegen den Decoder versioniert, heruntergeladen und regression-getestet werden — und im Setup des Papers ist jede Decode-Bitbreite mit ihrem eigenen Prefiller gepaart, die Paarungsmatrix wächst also.

Der ODP-Gewinn hängt von der Promptlänge ab. Im llama.cpp-Lauf des Papers ist ODP unter 4K Token langsamer als die nur-gewichtete Baseline; die 4,34 s SSD-Transfer im Spielzeugmodell sind kein gemessener TTFT-Bestandteil. Jedes Deployment, dessen Traffic aus Chat-langen Stößen besteht, bekommt die Speicherersparnis und die Verlangsamung; die 1,78 sind eine Zahl für 8K Kontext, die aus einem Defizit unter 4K heraus erreicht wurde¹.

Der Prefiller wird trainiert, nicht heruntergeladen — außer wenn er es ist. Der +32,5-Punkte-Prefiller hat einen QADD-Lauf auf Reasoning-Traces konsumiert, die vom BF16-Modell destilliert wurden (an der vollständigen Disaggregation führt kein kostenloser Weg vorbei). Die veröffentlichten Artefakte decken Qwen3.8-27B ab; jeder andere Decoder zahlt die Rechnung für seinen eigenen Trainingslauf¹.

Fragen zur Low-Bit-Genauigkeit und zu den Generierungskosten bleiben. Der gerettete IQ1_S erzielt 61,54 MMLU-Pro gegen 84,62 für BF16 in derselben Anhangstabelle — der Prefiller repariert den Schaden, den die 1-Bit-Prefill-Sicht angerichtet hat, nicht den Schaden, den die 1-Bit-Gewichte anrichten. Und oberhalb von 2 Bit kann der Prefiller subtrahieren: Die 3-Bit-Formate verlieren bis zu 2,77 MMMU-Pro-Punkte mit angehängtem NVFP4-Prefiller. Es gibt keine Bitbreite, bei der der zweite Checkpoint bedingungslos positiv ist. Feste Decoder-Gewichte garantieren auch keine festen gesamten Generierungskosten: In Anhang B.5 verändert der Prefiller Antwortlängen und Abbruchraten teils deutlich¹.

Die Implementierungen unterscheiden sich. Die Genauigkeitswerte stammen aus disaggregiertem vLLM mit NIXL und dequantisierten GGUF-Decodern; die ODP-TTFT-Werte aus einem angepassten llama.cpp-Fork mit der komprimierten IQ1_S-Baseline. Alles ist bei Batch eins, single-turn gemessen: Das Paper bewertet kein hochgradig gleichzeitiges Batching und markiert Mehrfach-Turn-Chats als ungetestet — ein erneutes Prefillen von zwischengespeicherten Assistenten-Tokens durch den Prefill-Checkpoint kann andere KV-Einträge liefern als die Decode-Zeit-Repräsentationen der Tokens, und niemand hat gemessen, wie viel das ausmacht¹.

7. Fazit

Disaggregierte Quantisierung ist ein Reframing auf Serving-Ebene mit ungewöhnlich sauberem Mechanismus: Die Roofline lässt die beiden Phasen Gegenteiliges wollen, und das Paper zwingt nicht länger ein Format, beiden zu dienen. Die billige Stufe — Aktivierungsquantisierung beim Decode auslassen — verbessert 11 von 13 Punktschätzungen in der großen PTQ-Prüfung des Papers; sechs Gewinne und keine Verschlechterung sind bei seinen Einzelvergleichstests signifikant. Das stützt die Prüfung für ein konkretes Modell und eine konkrete Workload, begründet aber keinen universellen Standard. Die teuren Stufen sind ein echter Engineering-Trade: ein zweiter, trainierter Checkpoint gegen große Niedrigbit-Genauheitsrückgewinne und FP4-Prefill-Tempo, wobei das SSD-Streaming den Speicherpreis in einen Latenzpreis verwandelt, den nur lange Prompts amortisieren. Die ehrliche Zusammenfassung des 1-Bit-Ergebnisses: Die Phasenteilung erhöht die gemessene Benchmark-Genauigkeit dieses IQ1_S-Decoders deutlich — und die Distanz, die zu BF16 bleibt, ist das offene Forschungsproblem, kein gelöstes.

Fußnoten