CXL-SSDs für LLM-Prefix-Caching: Byte-Adressierbarkeit bringt ohne Chunk-Bewusstsein nichts

Ein September-2026-Systems-Paper beginnt mit einem Ergebnis, das so manche CXL-Marketingdeck beschwichtigen sollte: Steckt man ein unmodifiziertes, generisches CXL-SSD in einen LLM-Prefix-Caching-Stack, ist es rund 3× langsamer als lokales DRAM und nicht schneller als eine normale NVMe-SSD — und der sequenzielle Standard-Prefetcher, den man zur Reparatur greifen würde, lässt die mittlere Time-to-First-Token (TTFT) nahezu unverändert, während er irrelevante NAND-Reads durchführt¹. Das Paper — Bridging LLM Serving and CXL-SSDs with Chunk-Aware KV Cache Management (Chung, Noh, Kim und Kollegen, Sogang University mit Samsung Electronics und ETRI, arXiv:2609.26828, cs.AR, eingereicht am 20. September 2026) — verdient dann seine konstruktive Hälfte: LM-CXD, ein auf LLM-Prefix-Caching spezialisiertes CXL-SSD, das die semantische Lücke zwischen der Serving-Engine (die weiß, welche KV-Chunks als nächstes konsumiert werden) und dem Gerät (das deren Platzierung und Bewegung kontrolliert) schließt — mittlere TTFT um bis zu 2,6× über dem Standard-CXL-SSD mit compute-asynchronem Prefetching gesenkt, um 4,03× mit lageweisem Prefetching, im Schnitt innerhalb von 1,5× zu lokalem DRAM¹.

Das Negative-Ergebnis ist der tragende Teil, denn es trennt sauber zwei Behauptungen, die CXL-Marketing gern verschmilzt. Behauptung eins: Der Block-I/O-Pfad ist für KV-Retrieval teuer, unabhängig vom darunterliegenden Medium — CPU-Cache-Konkurrenz, Host-DRAM-Staging-Kopien, Syscall-Bookkeeping. Behauptung zwei: CXLs byte-adressierbares, memory-semantisches Interface entfernt diese Kosten. Das Paper belegt Behauptung eins mit einem schönen Experiment (eine Ramdisk, die DRAM hinter dem Block-Interface hält, bleibt 1,8× langsamer als direktes DRAM — mit keinem einzigen NAND im System) und widerlegt dann die naive Lesart von Behauptung zwei: Den Block-Pfad zu entfernen macht ein CXL-SSD für diese Workload nicht schneller als eine NVMe-SSD, weil die verbleibenden Kosten — NAND-Latenz und geräteseitiges Thrash in einer begrenzten DRAM-Region — von Adressierbarkeit überhaupt nicht adressiert werden¹.

Dieser Guide geht den ganzen Stack in Arithmetik durch: die Interface-Kosten-Dekomposition, die Silizium-Realität von CXL- gegen PCIe-Bandbreite, warum Chunk-Granularitäten und NAND-Granularitäten kollidieren, warum jeder Prefetcher ohne Engine-Wissen spekulieren und verlieren muss, und die lageweise Pipelining-Schranke, die entscheidet, ob sich NAND-Latenz wirklich unter Rechenzeit verstecken lässt. Jede aus dem Paper zitierte Zahl wurde gegen den vollständigen HTML-Text verifiziert, nicht gegen das Abstract².

1. Das Problem: Prefix-Caching ist aus dem DRAM herausgewachsen, und der Block-Pfad ist der Grund, warum SSDs wehtun

Moderner LLM-Traffic — RAG-Kontexte, Multi-Turn-Chat, agentische Loops — sendet Präfixe von zig- bis hunderttausenden Tokens wieder und wieder. Prefix-Caching nutzt die für diese Präfixe berechneten KV-Caches wieder, um redundantes Prefill zu überspringen, und Systeme wie LMCache erweitern den Cache über den GPU-Speicher hinaus in Host-DRAM und Storage³. Aber Host-DRAM ist teuer und durch Speicherkanäle und DIMM-Kapazität begrenzt, also landet die kalte Ebene in Produktionstacks auf NAND-basierten NVMe-SSDs. NAND exponiert diese Kapazität nur über das Block-Interface, und die Charakterisierung der Paper-Autoren einer Prefix-Reuse-Workload (Qwen3-4B auf vLLM mit LMCache, 128k-Präfix, 32-Token-Chunks, vier Storage-Konfigurationen) führt die verschlechterte TTFT auf genau drei Kosten zurück¹:

1. CPU-Cache-Konkurrenz. Block-I/O läuft auf Host-Threads, die sich den Last-Level-Cache (LLC) mit den Inferenz-Threads teilen — für völlig andere Zwecke. Isoliert man die L3-Partition der I/O-Threads mit Intel Cache Allocation Technology (CAT), werden bis zu 44% der P99-TTFT zurückgewonnen — ein großer, schwanzlastiger Preis für etwas so Banales wie Syscalls im Page-Cache⁴.
2. Host-DRAM-Staging. Das Block-Interface zwingt jeden Chunk durch das Host-DRAM, bevor die GPU ihn lesen kann, denn die GPU kann nur aus gepinnten, in den Adressraum gemappten Seiten DMAen. Mit VTune gemessen: Auf einer Ramdisk steigen Schreibzugriffe von 6% auf 33% des DRAM-Traffics, das DRAM ist pro Retrieval 3,6× so lange beschäftigt. Eine Pinned-DRAM-Baseline mit 1,34 s mittlerer TTFT fällt auf 5,27 s auf ext4-über-brd, und ext4 zu entfernen gewinnt nur 0,2 s der 3,9-s-Lücke zurück — die Staging-Kopie ist der dateisystemunabhängige Teil¹.
3. Die NAND-Latenz selbst. NAND durch DRAM zu ersetzen (die Ramdisk) schließt im Steady-State 61% der TTFT-Lücke der SSD zu direktem DRAM — gut die Hälfte der SSD-Verlangsamung ist also das Medium, der Rest das Interface.

Die ersten zwei Kosten sind Eigenschaften des Interfaces, nicht des Mediums. Das ist der erste dauerhafte Befund des Papers: Eine Ramdisk — pures DRAM, über den Block-Pfad serviert — bleibt 1,8× langsamer als direktes DRAM. Und die naheliegenden Fluchtwege scheitern aus strukturellen Gründen. Host-seitiges Prefetching überlappt NAND-Latenz, reint aber die DRAM-Kapazitätsspannung: Man nutzt SSDs, weil Host-DRAM begrenzt ist, doch vorgeladene Chunks müssen vor dem Konsum wieder Host-DRAM belegen. GPUDirect Storage (GDS) umgeht CPU und Host-DRAM, entfernt aber die Block-Orientierung des Pfads nicht: cuFileRead legt die Daten in einem VRAM-Staging-Puffer ab; anschließend formatiert und kopiert load_and_reshape sie in vLLMs paged-KV-Layout. Das ist eine zusätzliche Staging-zu-Ziellayout-Kopie pro Chunk; das Paper berichtet weiterhin eine Performance-Lücke⁵.

2. Warum byte-adressierbar nicht schneller bedeutet: das Silizium darunter

CXL ist ein cache-kohärenter Interconnect, aufgebaut auf PCIe-Infrastruktur. Ein CXL-Type-3-Gerät exponiert Host-managed Device Memory (HDM) über das CXL.mem-Protokoll, gemappt in den physischen Adressraum des Hosts, angesprochen mit ordinary Load/Store-Instruktionen⁶. Ein CXL-SSD bolt das auf eine SSD-Architektur: Controller, On-Device-DRAM (die DRAM-Region, die Hits mit Speicherlatenz serviert) und NAND-Flash hinter einem Flash-Translation-Layer¹.

Ein PCIe-5.0-x16-Link überträgt ungefähr 64 GB/s je Richtung vor Protokoll-Overhead. Die tatsächlich nutzbare Bandbreite für CXL.mem-Loads hängt von Gerät, Topologie und Zugriffsmuster ab und liegt unter der Link-Nennrate; das Paper misst hier keine allgemeingültige Type-3-Bandbreite. Adressierbarkeit hebt daher das Link-Limit nicht auf. Bei einem Miss auf die Geräte-DRAM-Region läuft der Zugriff weiterhin über CXL.mem zum Controller, danach folgen FTL und NAND-Read. Für sein Z-NAND-Modell setzt das Paper tR = 3 µs an¹.

Deshalb ist „byte-adressierbar" eine Programmiermodell-Eigenschaft, keine Performance-Eigenschaft:

• Der DMA-Tribut ist derselbe Link. Ob der Quellpuffer der GPU gepinntes Host-DRAM oder ein per cudaHostRegister gemapptes CXL-Gebiet ist — der Host-zu-GPU-Transfer durchquert dieselbe PCIe-Hierarchie. Adressierbarkeit entfernt die Staging-Kopie, nicht den Transfer.
• Cache-Line-Traffic überquert trotzdem den Link. Ein zufälliger Cache-Line-Pull aus dem Geräte-DRAM kostet ein volles CXL.mem-Transaktionspaar (Request-Line, Return-Line, mit Kohärenzzustand). Burstige KV-Fills mit 2-MiB-Hugepage-Granularität amortisieren das gut; ein mis-getriebener, pointer-chasender Retrieval-Tun es nicht.
• Konkurrenz verschwindet nicht, sie verlagert sich. Mit dem Block-Pfad verschwinden die I/O-Threads — aber unter Last konkurriert jeder CXL-SSD-Read weiter um den geteilten Link, die Bandbreite der Geräte-DRAM-Region und die NAND-Kanäle des FTL.

Die nächste Zelle kostet den ganzen Retrieval-Pfad für ein realistisches Einzel-Retrieval aus — 18 GiB KV (ein 128k-Token-Präfix für Qwen3-4B: 36 Layers, GQA mit 8 KV-Heads à 128 Dimensionen, BF16, in 56-Token-Chunks) — unter jedem Backend, als Wallclock und als gelieferte GB/s. Die Bandbreitenwerte sind ausdrücklich angenommene, stilisierte Raten und keine Messungen des Papers. Die erste Charakterisierung des Papers verwendet 32-Token-Chunks; die spätere Qwen3-4B-Evaluation verwendet 56-Token-Chunks¹.

import math
 
# Interface-cost arithmetic for one 128k-token KV retrieval (Qwen3-4B shape:
# GQA 8 KV heads x 128 head dim, BF16, 36 layers, 56-token LMCache chunks).
# Stylized bandwidths; ratios, not absolute times, are the point.
TOK, LAYERS, CHUNK_TOK = 131072, 36, 56
KV_TOK_LAYER = 2 * 8 * 128 * 2                 # K+V bytes per token per layer
CHUNK_B  = CHUNK_TOK * KV_TOK_LAYER * LAYERS   # bytes per KV chunk
NCHUNK   = math.ceil(TOK / CHUNK_TOK)  # final chunk can be partial
PAYLOAD  = TOK * KV_TOK_LAYER * LAYERS
 
B_HOST, B_PCIE = 40e9, 20e9    # host DRAM rw, host<->GPU link (every path pays this)
B_NVME, B_GDS  = 7e9, 12e9     # NVMe steady read, GDS NVMe->VRAM DMA
B_VRAM         = 40e9          # VRAM-internal copy bandwidth (load_and_reshape)
SYS_US         = 15e-6         # per-chunk block-path kernel/bookkeeping charge
 
base = PAYLOAD / B_PCIE        # the DMA toll no path avoids
rows = [
 ("pinned host DRAM",      [(1, B_PCIE)]),
 ("ramdisk (brd+ext4)",   [(1, B_HOST), (1, B_PCIE)]),
 ("local NVMe O_DIRECT",   [(1, B_NVME), (1, B_PCIE)]),
 ("GDS NVMe -> VRAM",      [(1, B_GDS), (1.35, B_VRAM)]),
 ("CXL-SSD, DRAM hit",    [(1, B_PCIE)]),
 ("CXL-SSD, NAND miss",   [(1, B_NVME), (1, B_PCIE)]),
]
print(f"payload {PAYLOAD/2**30:.2f} GiB in {NCHUNK} chunks (up to {CHUNK_B/2**20:.2f} MiB each) "
      f"(multi-hugepage: {CHUNK_B/2**20 > 2})")
print(f"{'path':26s} {'stages':>6s} {'wall ms':>9s} {'deliv GB/s':>10s} {'vs pinned':>9s}")
for name, stages in rows:
    t = sum(PAYLOAD * f / b for f, b in stages) + SYS_US * (NCHUNK if "NVMe" in name or "ramdisk" in name else 0)
    print(f"{name:26s} {len(stages):5d}  {t*1000:9.1f} {PAYLOAD/t/1e9:9.2f} {t/base:9.2f}x")
 
# Why byte-addressable != faster, mechanically:
# 1) the DMA toll is the same PCIe link for pinned DRAM and CXL-mapped memory;
# 2) block paths add host-DRAM staging passes (writes 6% -> 33% of DRAM traffic
#    in the paper, DRAM busy 3.6x as long per retrieval);
# 3) I/O shares the LLC -- isolating the I/O partition with Intel CAT recovers
#    up to 44% of P99 TTFT in the paper. Overlapped degradation, stylized:
print("\nretrieval overlapped with decode, LLC partitioning off (stylized):")
for drop in (0.30, 0.44):
    t = PAYLOAD / (B_PCIE * (1 - drop))
    print(f"  effective DMA -{int(drop*100)}% -> {PAYLOAD/t/1e9:5.2f} GB/s ({t/base:4.2f}x slow-down)")

Output eines echten Laufs (Python 3, Seed 260926828):

payload 18.00 GiB in 2341 chunks (up to 7.88 MiB each) (multi-hugepage: True)
path                       stages   wall ms deliv GB/s vs pinned
pinned host DRAM               1      966.4     20.00      1.00x
ramdisk (brd+ext4)             2     1484.7     13.02      1.54x
local NVMe O_DIRECT            2     3762.5      5.14      3.89x
GDS NVMe -> VRAM               2     2298.0      8.41      2.38x
CXL-SSD, DRAM hit              1      966.4     20.00      1.00x
CXL-SSD, NAND miss             2     3727.4      5.19      3.86x
 
retrieval overlapped with decode, LLC partitioning off (stylized):
  effective DMA -30% -> 14.00 GB/s (1.43x slow-down)
  effective DMA -44% -> 11.20 GB/s (1.79x slow-down)

Das sind illustrative Rechnungen mit seriellen Transfers, keine Replikationen der TTFT-Messungen. Die gewählten Raten ergeben 1,54× für Ramdisk und 3,89× für NVMe gegenüber gepinntem DRAM; sie verifizieren weder die gemessenen 1,8× noch die rund 3× des Papers. Das Toy setzt einen CXL-DRAM-Hit per Annahme gleich schnell wie gepinntes DRAM und einen CXL-NAND-Miss gleich schnell wie NVMe an. Reale Zeiten hängen zusätzlich von CXL-Transaktionen, Controller, Parallelität und Überlappung ab. Der gemessene Paper-Befund lautet, dass das Standard-CXL-SSD NVMe nicht schlägt, während Chunk-bewusste Koordination die TTFT verbessert¹.

3. Das CXL-SSD-Paradox: ein besseres Interface, keine bessere TTFT

Das Experiment in § 4.1 des Papers sollte man sich merken. Die Autoren lassen die Multi-Turn-Q&A-Workload gegen eine Standard-CXL-SSD-Implementierung laufen — dieselben 2-MiB-Hugepages und derselben Clock-Eviction, die auch das eigene Gerät des Papers nutzt, LMCache-Asynchrones-Laden aktiviert, kein geräteseitiges Prefetching — und gegen dasselbe Gerät mit Cylons Standard-Next-n-Sequenz-Prefetch-Politik, n = 4 Seiten pro DRAM-Miss⁷. Ergebnis: Das CXL-SSD ohne Spezialisierung verbessert die Performance über die SSD-Baseline nicht; die P99-TTFT regrediert über die der SSD hinaus; und Next-n lässt die mittlere TTFT nahezu unverändert, manche Turns werden schlechter. Der Zählervergleich ist präzise: Next-n stellt 19.198 Async-Loads aus, aber die Evictions steigen von 369.104 auf 387.840 und die NAND-Reads von 1.494.131 auf 1.504.029 — Prefetching erzeugte NAND-Traffic und Evictions, statt sie zu sparen¹.

Warum macht ein Prefetcher es schlechter? Weil der gesamte CXL-SSD-I/O durch die begrenzte DRAM-Region muss und die Platzierungspolitik eines Standardgeräts nicht weiß, was kommt. Sechzehn parallele Sessions teilen sich eine 16-GiB-Region, während jede GiB-große Präfixe braucht — das heißt Thrash: Chunks werden wiederholt zwischen DRAM und NAND evictet und neu geladen. Next-n kann nicht helfen, weil es mis-getrieben und spekulativ ist: Es muss erst einen DRAM-Miss erleiden, um überhaupt zu triggern, rät die nächsten sequenziellen Seiten anhand der Adresse, und wenn sein Tipp zu spät oder falsch kommt, zahlt es einen Extra-Miss und verbrennt NAND-Bandbreite für Seiten, die niemand wollte. Der Teufelskreis, den das Paper benennt, ist strukturell: Mis-getriebenes Prefetching muss den Miss erleiden, den es zu verhindern versucht¹.

Und hier ist die Granularitäts-Kollision, die Spekulation aussichtslos macht. LMCache-Einheit ist der Chunk — je nach Modell 32 bis 128 Tokens, bei diesen Shapes rund 8–40 MiB KV-Bytes —, während die Geräteeinheit die 2-MiB-Hugepage ist, selbst eine Ausrichtung über 4-KiB-OS-Seiten, abgebildet auf NAND-Seiten (Dutzende KiB) gruppiert in Erase-Blocks (typisch Hunderte KiB bis wenige MiB). Ein Lageweis-Lesezugriff will eine Layer über viele Chunks — weder seitenförmig noch chunkförmig. Ein Gerät, das nur Seiten sieht, kann keine der beiden Zugriffsformen servieren und schon gar nicht vorhersagen: KV-Reuse folgt der Baumstruktur der Präfixe — Systemprompt, abgerufene Dokumente, Gesprächshistorie — nicht dem Adresslayout eines flachen Arrays. Die Serving-Engine kennt die Form dieses Baums zur Prefix-Lookup-Zeit, bevor sich ein Byte bewegt. Das Gerät sieht sie nie. Diese Asymmetrie — nicht das Fehlen von Prefetching — ist die Lücke.

Die gemessenen Zähler zeigen den Mechanismus ohne synthetische Cache-Trace: Die Next-n-Konfiguration des Papers löst 19.198 asynchrone Prefetch-Loads aus; dennoch steigen die NAND-Reads gegenüber keinem Prefetching um 9.898 und die Evictions um 18.736. Diese Werte belegen zusätzlichen Traffic in diesem Benchmark; sie sagen nicht, wie viele vorgeladene Seiten nie genutzt wurden oder wie sich die Hit-Rate allgemein verhält. LM-CXD macht stattdessen die bekannten KV-Chunks und den Fortschritt für Gerät und Serving-Engine sichtbar und pinnt begrenzte Fenster während des Bedarfs¹.

4. LM-CXD: den Co-Designpreis ausrechnen, Eigenschaft für Eigenschaft

Der Move des Papers: das CXL-SSD nicht länger als generisches Speichergerät behandeln, sondern den KV-Chunk zur Einheit machen, die das Gerät indiziert, bewegt, über Fortschritt berichtet und zur GPU transferiert. Drei Eigenschaften, jede schließt einen spezifischen gemessenen Fehlschlag¹:

Eigenschaft 1: Chunk-Identität wird I/O. LMCache Prefix-Lookup berechnet für jede Anfrage bei Ankunft ohnehin Chunk-Hashes — so findet es das längste gecachte Präfix. LM-CXDs gemeinsame Strukturen (Prefix-Lookup-Tabelle von Chunk-Hash zu Ort, Pin-Map zum Schutz im Flug befindlicher Fenster vor Clock-Eviction, Free-Queue fürs Chunk-Löschen, eine Prefetch-Queue von Chunk-Hashes und ein Prefetch-Plan-Pool fürs Lageweise) leben in einer reservierten Region des Geräte-DRAM, les- und schreibbar für LMCache und den Gerätecontroller ohne Syscalls, Interrupts oder Kopien. LM-CXD löst Chunk-Hashes gegen den eigenen Index auf, überspringt Chunks, die schon in der DRAM-Region liegen, und stellt die NAND-Reads selbst aus — Chunk-Matching auf Host-Seite kostet unter Compute-Asynchronem Prefetching (CAP) 6–7 Mikrosekunden pro Chunk, gegen 160 Mikrosekunden pro Chunk, die das Standardgerät fürs Kopieren verbraucht¹.

Eigenschaft 2: Die Engine handelt nach Gerätefortschritt. LM-CXD protokolliert Dispatch- und Abschluss-Zustand pro Session im Geräte-DRAM. LMCache pollt ihn, admittiert eine Session, sobald ihre ersten zwei Fenster Chunks disponiert sind (nicht abgeschlossen), und DMAet fertige Chunks zur GPU, während die Session in vLLMs nicht-blockierendem WAITING_FOR_REMOTE_KV-Zustand wartet — unter der Rechnung anderer Sessions. Das ist die bidirektionale Hälfte: Hints fließen Engine-zu-Gerät, Fortschritt Gerät-zu-Engine, und die Admission wartet nicht länger auf den Abschluss von Loads, die sie überlappen kann. Promotions werden pro Scheduler-Schritt gedeckelt mit einer bedingungslosen Promotion, damit der Dispatcher zwischen Admissions ablaufen kann.

Eigenschaft 3: Geräte-DRAM ist der Quellpuffer der GPU. Die DRAM-Region ist per cudaHostRegister gepinntes Memory; DMA zieht Chunks direkt vom Geräte-DRAM in den VRAM ohne Host-Staging. Die Fenster-Disziplin (ein Pin-Budget pro Rank, dimensioniert nach Region, Rang-Anzahl und Workload; zwei Fenster vorgeladen; das nächste Fenster startet erst, wenn ein anderes entpinnt) macht Prefetching erst in einer Region möglich, die keinen ganzen Präfix halten kann — das dritte Design-Prinzip des Papers, NAND-Latenz unter begrenztem Geräte-DRAM verstecken, konkret gemacht.

Dann zwei Prefetch-Methoden, jede in ihr Workload-Regime gepasst. CAP terminiert Fenster-Prefetch hinter Lookup-Hints, während andere Sessions rechnen — die Benchmark-Antwort für paralleles Multi-Turn-Serving. Lageweises Prefetching geht weiter: Es verfolgt einen Plan pro Anfrage, konvertiert Chunks von Chunk-Major nach Layer-Major in einer eigenen Staging-Area des Geräte-DRAM und nutzt einen Strided-cudaMemcpy3DAsync-Deskriptor, so dass der DMA selbst den Layout-Wechsel ausdrückt (zwei Kopien pro Layer statt zwei pro Chunk). Ein konstanter n-tiefer Lookahead-Puffer lässt NAND-Reads der Layer-Konsumation vorauslaufen; das Paper läuft mit Prefetch-Grad 7 auf Qwen3-VL-32B.

5. Wann lageweises Prefetching hilft: gemessene Queue- und Prefill-Zeiten

Lageweises Retrieval startet NAND-Reads vor dem Verbrauch der jeweiligen Layer. Ob das hilft, hängt von der verfügbaren Rechenzeit zur Überlappung, der Zahl paralleler Sessions und den für Lookahead reservierten Geräte-DRAM-Puffern ab. Ein Per-Layer-FLOP-Modell allein sagt das Ergebnis nicht voraus: Es lässt die tatsächlichen Kernel, Scheduling, Cache-Hits, Konkurrenz und Request-Zulassung aus. Tabelle 5 des Papers liefert stattdessen gemessene Zeiten des Request-Lebenszyklus¹:

Lageweises Prefetching hat in diesem Vergleich keine eigene Zulassungs-Queue: Es integriert das Retrieval in das Prefill. Bei Qwen3-4B mit 64k kommen dadurch 1,40 s Prefill hinzu, während nur 0,51 s CAP-Queue wegfallen; CAP gewinnt für diese Workload. Bei Qwen3-VL-32B sind die zusätzlichen 0,30 s Prefill kleiner als die 1,06 s CAP-Queue; hier gewinnt das lageweise Verfahren. Die geringe mittlere Prefill-Differenz von 0,02 s bei Llama bedeutet keinen sicheren Latenzschwanz: Bei 16k bleibt die P99-NAND-Wartezeit innerhalb von 1,3× zum Standardgerät, weil eine verspätete Layer wenig Rechenzeit zum Verbergen ihres Reads bietet¹.

Lookahead kostet Kapazität, selbst wenn es Latenz verdeckt. Das Paper berichtet etwa 9 GiB lageweise Puffer für beide Qwen-Modelle mit 64k-Präfixen; das verdrängt über die Hälfte der 16-GiB-Geräte-DRAM-Chunk-Region. Llama bei 16k nutzt 2,5 GiB. Die Ergebnisse gelten für die evaluierten Modelle, Präfixlängen und Parallelität; ein optimaler Lookahead-Grad für andere Deployments folgt daraus nicht¹.

6. Was der Co-Design real kauft, gemessen

Über fünf Modelle (Qwen3-4B, Ministral-8B, Qwen3-Coder-30B-A3B, Qwen3-VL-32B, Llama-3.1-70B — alle GQA) auf dem CxS-Multi-Turn-Benchmark (16 Sessions, 6 Turns) und einer agentischen Coding-Trace (AIPerf, 48 Sessions, 128k–160k-Präfixe): TTFT sinkt um 2,51× und 2,6× im Schnitt unter CAP für Qwen3-4B und Ministral-8B; 4,03× für Qwen3-VL-32B lageweise; 1,74× für Llama-70B; gesamt im Schnitt innerhalb von 1,5× zu lokalem DRAM¹. Die mittlere gefühlte NAND-Zeit pro Anfrage fällt von 139–920 ms (Standard, über die vier Modelle) um mindestens 3× am Median und 2,5–4,1× am P90 unter LM-CXD — mit ehrlichen verbleibenden Schwänzen im Bereich Hundert-Millisekunden. Auf der agentischen Trace ist die mittlere TTFT fast identisch mit dem Standardgerät (der meiste dieses KV bleibt per Reuse-Häufigkeit heiß in der DRAM-Region) und der Gewinn ein um 17% niedrigerer P90 — Chunk-bewusstes Prefetching zahlt sich exakt dort aus, wo Reuse sporadisch ist, und nirgendwo sonst.

Die DRAM-Regions-Sensitivitätstabelle ist die sauberste Preisstellung der semantischen Lücke: Bei 8/16/32 GiB Region liegt die Standard-CXL-SSD bei 6,26/6,53/1,98 s TTFT, LM-CXD hält 2,78/2,40/1,90 s. Das Standardgerät ist hochgradig regionsgrößenempfindlich (3×-Schwankung); LM-CXD bewegt sich über den Sweep hinweg unter 1,5× und schlägt bei 8 GiB das Standardgerät bei 16 GiB um 2,3×. Der Lifecycle-Split zeigt warum: Queue-und Prefill-Zeiten des Standardgeräts steigen bei kleinen Regionen beide um rund dreifach, während LM-CXD auf Dispatch admittiert und gepinnte Fenster kopiert, also wächst sein Anstieg allein in die Queue. Der Gemeinsame-Strukturen-Overhead ist in der anderen Richtung vernachlässigbar — 22 MiB, 0,13% einer 16-GiB-Region, für alles, was CAP braucht¹.

7. Anti-Hype: Was dieses Paper nicht belegt

Die CXL-SSD-Ergebnisse beruhen auf einem emulierten Gerät. Für diese Evaluation war kein kommerzielles CXL-SSD erhältlich; Host-GPUs und Serving-Software waren real, während LM-CXD auf einer modifizierten NVMeVirt-Plattform läuft (Page-Fault-abgefangenes DRAM mit injiziertem Z-NAND-Timingmodell, NUMA-Knoten-Speicher als CXL-Stellvertreter), validiert gegen den Cylon-Emulator auf bimodaler Latenz und Per-Miss-Breakdown (übereinstimmende ≈6,2 Mikrosekunden Gerätezeit; der Rest ist Cylons KVM/QEMU-Exit-Overhead, keine Gerätephysik)⁷. Jede absolute Zahl erbt Emulationsfehler; übertragbar sind die Mechanismus-Behauptungen.

Die beobachtete mittlere 1,5×-Lücke zu DRAM hat bekannte Ursachen. Selbst voll spezialisiert bleibt Geräte-DRAM begrenzt, NAND-Reads bleiben im Schwanz, und LM-CXDs Queue-Zeit-Komponente verschwindet nicht — bei 32-GiB-Regionen konvergieren die beiden Geräte laut Paper, und LM-CXDs Prefill erreicht das Niveau von lokalem DRAM, die Queue-Zeit bleibt als Rest. Chunk-bewusstes Design verengt die Lücke; es schließt sie nicht.

Co-Design schneidet in beide Richtungen. LM-CXDs bidirektionales Interface kostet Host-Bookkeeping (1,2–2,4% eines Retrieves — klein, aber nicht null), die Lookahead-Puffer verdrängen bei 64k-Präfixen mehr als die Hälfte der Chunk-Region, und Lageweise ist ein Nettoverlust für klein-Präfixige, schnell dekodierende Modelle (Qwen3-4B: +1,40 s Prefill, um 0,51 s Queue-Wartung zu sparen). Der paper-eigene Modellvergleich zeigt keine einzelne Prefetch-Methode, die überall gewinnt — CAP für paralleles Serving, Lageweise für große Einzel-Session-Lasten — was die übliche Signatur eines echten Systems ist statt eines Benchmark-Artefakts.

KV-Cache-Regenerierbarkeit ist tragend. LM-CXD verwirft lebende Chunks aus erassten NAND-Lines, statt sie zu relokieren — kein Garbage Collection —, denn KV kann immer neu berechnet werden. Das ist ein Prefix-Caching-spezifischer Freibrief; das Design generalisiert nicht auf Storage, dessen Daten einen Erasure überleben müssen¹.

Byte-Adressierbarkeit hilft diesem Design durch Wegfall des Block-Stagings. Im gemessenen Aufbau kostete DRAM hinter dem Block-Interface 1,8× gegenüber direktem DRAM-Zugriff. LM-CXD entfernt diesen Pfad und ergänzt Chunk-bewusstes Scheduling. Das Paper beweist weder die Notwendigkeit von Byte-Adressierbarkeit für jedes mögliche Storage-Design noch eine allgemeine Gleichheit von Geräte-DRAM-Hits und lokalem DRAM. Die 2,6–4,03× vergleichen vollständige LM-CXD-Konfigurationen mit dem Standard-CXL-SSD; sie lassen sich nicht einem einzelnen Mechanismus zuschreiben.

Für Praktiker destilliert sich die Checkliste auf: (1) Heiße Präfixe zuerst in schlichtes DRAM halten — die Standard-CXL-SSD verliert um 3× gegen lokales DRAM, selbst LM-CXD konzediert 1,5×; (2) wenn eine NAND-Ebene unvermeidlich ist und CXL-SSDs materialisieren, hilft nichts Generisches — chunk-sichtbare Interfaces fordern, fensteriges gepinntes Prefetching, Dispatch-progrediente Admission und lageweise Konvertierung; (3) das Geräte-DRAM-Budget explizit planen und das Per-Layer-Transfer-gegen-Rechenzeit-Verhältnis bei den eigenen Präfixlängen prüfen, bevor irgendjemandem 4× versprochen werden.

Fußnoten