<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>flozi00 TechHub</title>
    <link>https://flozi.net/de</link>
    <description>Deep Dives zu Servern, GPUs, KI-Infrastruktur und modernen IT-Systemen.</description>
    <language>de</language>
    <lastBuildDate>Fri, 25 Sep 2026 10:10:37 GMT</lastBuildDate>
    <atom:link href="https://flozi.net/feed.de.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Wie wir GLM auf B300 in Produktion betreiben: MTP k=5-Tuning</title>
      <link>https://flozi.net/de/blog/glm-b300-mtp-nvls</link>
      <guid isPermaLink="true">https://flozi.net/de/blog/glm-b300-mtp-nvls</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Produktionsnotizen aus dem Betrieb eines GLM-MoE auf 8x B300: die Akzeptanzraten-Mathematik hinter Speculative Decoding, was die gemessene log_stats-Kette ueber k=2-k=3 sagt, und warum NVLS-Fehler default lautlos bleiben.</description>
      <category>llm-inferenz</category>
      <category>speculative-decoding</category>
      <category>mtp</category>
      <category>b300</category>
      <category>nccl</category>
      <category>produktion</category>
    </item>
    <item>
      <title>Agent-Fleet-Tokenökonomie ist Cache-Ökonomie: Der 60-fache Dollar-Spread im Detail zerlegt</title>
      <link>https://flozi.net/de/guides/ai/agent-fleet-cost-cache-elasticity</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/agent-fleet-cost-cache-elasticity</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Der selbstberichtete Tag mit 44 Agenten, 4 Milliarden Tokens und 1.300 Dollar gegen 80.000 Dollar — Zeile für Zeile gegen live Preislisten nachgerechnet, in Cache-Rabatt, Modell-Spread und Looping-Anteil zerlegt und als Capacity-Planungs-Checkliste für alle aufgebaut, die eine interne Agenten-Flotte betreiben.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>prompt-caching</category>
      <category>agents</category>
      <category>economics</category>
      <category>gpu-memory</category>
    </item>
    <item>
      <title>BOOST und das Ende des Prefetch: Warum Grace Hopper beide Speichertiere gleichzeitig will</title>
      <link>https://flozi.net/de/guides/ai/boost-host-memory-concurrent-tiering</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/boost-host-memory-concurrent-tiering</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>BOOST (arXiv:2609.13592) bis zum Bandbreiten-Ledger zerlegt: Warum Prefetch-Tiering beim Decode strukturell HBM-Schreibbandbreite verbrennt, warum konkurrenter, proportionaler Zugriff die Host-Tier addiert statt stiehlt, die α-Mathematik hinter +31% Durchsatz und 4,3% TPOT bei iso-batch — und der NVLink-C2C-Scope-Guard, der PCIe-x86-Hosts aus der Behauptung heraushält.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>gpu</category>
      <category>gpu-memory</category>
      <category>inference</category>
      <category>hardware</category>
      <category>kv-cache</category>
    </item>
    <item>
      <title>Der Cache-Read-Preiskrieg des Septembers 2026, der nicht dreiseitig war</title>
      <link>https://flozi.net/de/guides/ai/cache-read-price-war-sept-2026</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/cache-read-price-war-sept-2026</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Die Presse erzählte die Geschichte von drei Frontier-Labs, die am 21./22. September 2026 geschlossen die Preise senkten. Die Preislisten sagen etwas anderes: Ein Anbieter senkte Cache-Reads auf 0,05x, einer brachte neue SKUs mit unangetastetem Cache-Multiplizierer, und einer tat gar nichts. Zerlegt bis zur Arithmetik, mit Barrie-förmigen Tageskosten pro Anbieter in Python.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>prompt-caching</category>
      <category>agents</category>
      <category>economics</category>
      <category>pricing</category>
    </item>
    <item>
      <title>CXL-SSDs für LLM-Prefix-Caching: Byte-Adressierbarkeit bringt ohne Chunk-Bewusstsein nichts</title>
      <link>https://flozi.net/de/guides/ai/cxl-ssd-chunk-aware-kv-cache</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/cxl-ssd-chunk-aware-kv-cache</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Ein September-2026-Paper der Sogang University (arXiv:2609.26828) fragt, ob CXL-SSDs NVMe im LLM-Prefix-Caching ersetzen können — und startet mit einem klaren Nein: ein CXL-SSD ohne Anpassung ist rund 3× langsamer als lokales DRAM und nicht schneller als eine NVMe-SSD; ein generischer Next-n-Prefetcher lässt die TTFT praktisch unverändert und verbrennt nur NAND-Bandbreite. Die interessante Hälfte ist die konstruktive: LM-CXD, ein mitgestalteter CXL-SSD, der KV-Chunks zu geräte­sichtbaren I/O-Einheiten macht, den NAND-zu-DRAM-Fortschritt an die Serving-Engine meldet, Geräte-DRAM als GPU-zugänglichen Puffer nutzt und lageweise KV-Bewegung unter die GPU-Rechnung pipelint — bis zu 2,6× (compute-asynchron) und 4,03× (lageweise) niedrigere TTFT gegenüber dem Standardgerät, innerhalb von 1,5× zu lokalem DRAM. Dieser Guide kostet jeden Schritt des Interface-Stacks in Bandbreiten- und Latenz-Arithmetik durch, arbeitet heraus, warum CXLs Memory-Semantik Lades nicht gratis macht, warum Prefetching ohne Engine-Wissen spekulieren und verlieren muss — und was unverifiziert bleibt, weil es noch keine CXL-SSD zu kaufen gibt.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>caching</category>
      <category>hardware</category>
    </item>
    <item>
      <title>CXMT bei 10 % DRAM-Umsatz: Die DUV-Anatomie eines Aufstiegs und seine EUV-Decke</title>
      <link>https://flozi.net/de/guides/ai/cxmt-10pct-dram-euv-ceiling</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/cxmt-10pct-dram-euv-ceiling</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Counterpoint setzt CXMT im zweiten Quartal 2026 auf 10 % des weltweiten DRAM-Umsatzes – zwei Jahre früher als von der UBS projiziert. Wir zerlegen, wie ein reiner DUV-Speicherhersteller mit SAQP bei 11,95 nm Half-Pitch dank des HBM-Pivots der Marktführer dorthin kam, rechnen Anteils-, Kostenkeil- und Yield-Ökonomie in Python nach und lokaliseren die strukturelle Decke: PAM3-Timing bei Overlay-Rauschen des Mehrfach-Patterning, ein 30-%-Keil bei den Kosten pro Bit und zwei Generationen Rückstand bei HBM.</description>
      <category>ai</category>
      <category>hardware</category>
      <category>memory</category>
      <category>dram</category>
      <category>supply-chain</category>
    </item>
    <item>
      <title>DeepSeek-V4.1-Flashs KV-Cache-Kompression, bis ins Byte geprüft: 890 Bytes pro Token sind ein Design, kein Wunder</title>
      <link>https://flozi.net/de/guides/ai/deepseek-v41-flash-kv-compression-techniques</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/deepseek-v41-flash-kv-compression-techniques</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>DeepSeek-V4.1-Flash (arXiv:2609.19969, DeepSeek-AI, 17. September 2026) beansprucht 890 Bytes globalen KV-Cache pro Token — ungefähr 1/4 gegenüber dem eigenen V4-Flash-Vorgänger in HBM und 1/8 im persistenten Speicher — dazu 1M-Token-Kontext, 552B Backbone-Parameter mit nur 8B aktiv im Prefill und 16B im Decode. Dieser Guide nimmt den Anspruch mechanisch auseinander: wie CED das globale KV des Decoders aus dem finalen Hidden State des Encoders projiziert (K und V werden zu per-Layer-Lineaprojektionen einer geteilten Repräsentation), wie CSA2 drei multiplikative Kompressionsdimensionen mit statisch zugewiesenen Full/Reindex/Reuse-Modi in einer 3x6-Encoder- und 5x4-Decoder-Kadenz stapelt, wie MXFP4 auf einem Norm-Argument steht (größtes RMSNorm-Gewicht ~1 → das 512-Kanal-Latent ist durch sqrt(512) ≈ 22,6 begrenzt gegen einen darstellbaren Bereich von 2688 — 118,8-facher Headroom, daher kostet der weggelassene globale Scale nichts), und wie SWA Bounded Replay die exakte Rekonstruktion über L x n_win = 5.120 Token gegen 128 Token tauscht. Wir jagen einem Byte-Ledger nach, das die 890 aus der veröffentlichten Konfiguration reproduziert (unser bester Kandidat: 864, 3,0% daneben — das Paper veröffentlicht keinen Ledger), bepreisen den Replay-Overhead pro Prompt-Länge und benennen die Falsifikationssignale: Auswahlfehler einer einzelnen Schicht, die alle Downstream-Reuse-Schichten vergiften, positionsabhängige Cache-Hit-Zustände, die mathematisch nicht identisch sind, und E2M1s 1-Bit-Mantisse konzentriert genau dort, wo Needle-Retrieval über lange Kontexte lebt. Jede abgeleitete Zahl ist in lauffähigen Zellen berechnet und als unsere markiert.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>effizienz</category>
      <category>kv-cache</category>
      <category>deepseek</category>
    </item>
    <item>
      <title>Disaggregierte Quantisierung: Prefill- und Decode-Kosten auf zwei Formate verteilen</title>
      <link>https://flozi.net/de/guides/ai/disaggregated-quantization-phase-split</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/disaggregated-quantization-phase-split</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Ein Paper von September 2026 (arXiv:2609.26333) behandelt ein Modell nicht mehr als ein einziges Quantisierungsproblem. Prefill ist rechenbegrenzt, also beschleunigt niedrigpräzise NVFP4-Arithmetik; Decode ist bandbreitenbegrenzt, also beschleunigen 1-3-Bit-Gewichte. Disaggregierte Quantisierung spezialisiert Formate, Gewichte und Speicherplatzierung pro Phase: Das Weglassen der Aktivierungsquantisierung allein beim Decode ist kostenlose Genauigkeit, ein separat trainierter NVFP4-Prefiller hebt einen eingefrorenen 1-Bit-GGUF-Decoder um +32,5 MMLU-Pro-Punkte, und ein von der SSD gestreamter Prefiller kauft ein 1,78-faches TTFT bei 8K Kontext — bezahlt mit einem zweiten Checkpoint, der gespeichert und qualifiziert werden muss, einer SSD-Amortisation, die nur bei langen Prompts aufgeht, und einer 1-Bit-Steuer, die bestehen bleibt. Dieser Guide rechnet Roofline, Crossover-Mathematik und ein Bits-gegen-Genauigkeit-Spielzeug in echten Zellen durch.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>quantization</category>
    </item>
    <item>
      <title>FlashLoop, oder: Wer einen Transformer loopt, vervierfacht die Rechnung — und wirft das Meiste wieder weg</title>
      <link>https://flozi.net/de/guides/ai/flashloop-looped-transformer-kv-redundancy</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/flashloop-looped-transformer-kv-redundancy</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Geloopte Transformer (Ouro, Huginn) führen einen gewichtsgeteilten Block R-mal pro Token aus, um Tiefe ohne Parameter zu kaufen — und der KV-Cache stellt die Rechnung: Auf einer A100 braucht Ouro-2.6B für einen 32K-Prompt 27 Sekunden gegenüber 3 Sekunden für LLaMA-3.1-8B, und der loop-übergreifende KV-Cache belegt 48 GiB gegenüber 4 GiB. FlashLoop (arXiv:2609.29812, Yang und Liu, Tübingen) zeigt, dass das Meiste, was das Loopen berechnet und speichert, redundant ist: konvergierte Tokens hören auf, sich zu ändern, ein stabiler kleiner Satz an Attention-Spalten dominiert den Output, und die KV-Residuen zwischen benachbarten Loops schrumpfen so weit, dass sie sich auf 4 Bit quantisieren lassen. Das Ergebnis: bis zu 1,64× End-to-End-Beschleunigung und bis zu 6× KV-Cache-Ersparnis bei \&quot;lossless accuracy\&quot;. Dieser Guide prüft die Mathematik und das Silizium: warum Decode bandbreitenbegrenzt ist bei einer arithmetischen Intensität von ~0,4 FLOPs/Byte gegen eine A100-Ridge von 201, was Token-Sparse-Updates und Top-K-Spaltenrekonstruktion tatsächlich berechnen (mit lauffähigem Toy), was ein naives Speichermodell ihres INT4-Basis-plus-Residuen-Schemas vorhersagt gegenüber den 6,06× des Papers (Antwort: 1,75× — die Lücke ist der interessante Teil), und wie viel von den 1,64× ein Amdahl-Blick auf einen echten Serving-Stack überleben lässt. Der \&quot;lossless\&quot;-Anspruch wird ehrlich bepreist: Die Deltas liegen zwischen +0,37 und −0,88 Prozentpunkten, und die Thinking-Varianten verlieren am meisten.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>effizienz</category>
      <category>kv-cache</category>
      <category>looped-transformers</category>
    </item>
    <item>
      <title>Gumbel-Watermarking ist endlich produktiv — und die Compliance-Asymmetrie, die niemand eingepreist hat</title>
      <link>https://flozi.net/de/guides/ai/gumbel-watermark-art50-compliance-asymmetry</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/gumbel-watermark-art50-compliance-asymmetry</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Im August 2026 gingen zwei Implementierungen derselben Idee von 2022 im selben rechtlichen Zeitfenster live: Anthropic brachte SynthID-Text-basiertes Watermarking in Claude unter dem EU-Code of Practice (Nature 2024: H=4 Sliding-Window-Seed, M=2^m K.o.-Turnier über m=30 Bernoulli-g-Wert-Schichten), und vLLM brachte keyed Gumbel-Max-Sampling (--watermark-config gumbel, Philox-PRF, context_width=4) mit einem gewichtsfreien Detektor. Dieser Guide macht, was die Ankündigungen nicht tun: Er leitet den Gumbel-Max-Trick her (argmax aus log p plus iid Gumbel-Rauschen ist ein exakter kategorialer Sampler), zeigt in Python, wie ein keyed PRF aus dem Rauschen ein detektierbares Signal macht (z=+28 bei N=200 voll markiert, z=+1,15 bei 5% Markierung), übersetzt Anthropics eigene Limitations-Sektion in Mathematik (wenige Wahlmöglichkeiten = schwaches Signal; die Null-Lücke pro Token liegt in unseren Läufen exakt bei -ln 32) und verankert das Ganze in Art. 50(2) EU AI Act (maschinenlesbares Marking, anwendbar seit 2. August 2026, mit der Omnibus-Verordnung 2026/1744 und ihrer viermonatigen Übergangsfrist bis 2. Dezember 2026 für Bestandssysteme). Die These: Art. 50(2) verlangt eine Eigenschaft (beweisbares Marking), die geschlossene Endpunkte liefern und nach eigenem Ermessen hinter einem Detektor halten können — während Open-Weight-Serving sie nur vorwärts liefern kann: Der Betreiber kann die Herkunft seines eigenen Streams beweisen, niemand kann Abwesenheit beweisen, und Downstream-Fine-Tunes löschen die Marke.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>watermarking</category>
      <category>security</category>
      <category>compliance</category>
      <category>regulation</category>
    </item>
    <item>
      <title>HBF als dritte KV-Tier: 24x Sessions oder 5x schlechtere Latenz — das Medium ist in Ordnung, die Placement-Politik entscheidet</title>
      <link>https://flozi.net/de/guides/ai/hbf-flash-kv-tier-hot-cold</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/hbf-flash-kv-tier-hot-cold</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>High-Bandwidth Flash als KV-Tier zerlegt: Warum arXiv:2609.25782 mit demselben Medium 24x mehr Concurrent-Sessions und −7,6 kW/Node erreicht, das arXiv:2608.11668 bei 2–5,5x schlechterer End-to-End-Latenz misst. Die entscheidende Variable ist die Placement-Politik: Write-on-Evict-Cold-Pool vs. Mooncake-artiger SSD-Offload-Stream. Endurance-, Latenzbudget- und Leistungs-Arithmetik in Python nachgerechnet.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>gpu</category>
      <category>gpu-memory</category>
      <category>inference</category>
      <category>hardware</category>
      <category>kv-cache</category>
      <category>storage</category>
    </item>
    <item>
      <title>KernelOPTs agentische Kernel-Suche: Die Verifikationskaskade funktioniert, der Speedup verblasst mit der Schwierigkeit</title>
      <link>https://flozi.net/de/guides/ai/kernelopt-agentic-kernel-search-fade</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kernelopt-agentic-kernel-search-fade</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Ein Red-Hat-Paper von September 2026 (arXiv:2609.30059) hetzt fünf profiling-geführte LLM-Agenten auf compiler-generierte Triton-Kernels — lässt jeden cuBLAS- und cuDNN-Aufruf unangetastet — und schaltet das Ergebnis hinter eine vierstufige Verifikationskaskade, die bei jedem Fehler auf die torch.compile-Baseline zurückfällt. Das Engineering ist wirklich gut: dispatch-bewusstes Targeting, NCU-geführte Beam-Search, Modell-Verifikation mit float64-Fallback und ein Performance-Gate, das korrekte, aber nutzlose per-Kernel-Gewinne in ehrliche Fallbacks verwandelt. Die Ergebniskurve ist der interessante Teil: 1,40× geometrisches Mittel über torch.compile auf Level 1 (51 von 100 optimiert), 1,15× auf Level 2 (31 von 100) und 1,07× auf Level 3 (12 von 50) — über alle Probleme, ungelöste mit der erhaltenen 1,0×-Baseline gezählt. Der agentische Speedup kollabiert, je schwerer die Probleme werden, und 61 von 85 Fallbacks sind schlicht Library-Dominanz: Der Großteil der Laufzeit eines kompilierten Modells steckt in Vendor-Aufrufen, die die Methode nicht anfasst — eine Amdahl-Grenze, die dieser Guide in Zahlen setzt, samt effektiver Geomean-Arithmetik passraten-gewichteter Speedups und der Frage, warum float64-Modellverifikation Numerik-Fehler sieht, die per-Kernel-Tests strukturell verpassen.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>gpu</category>
      <category>kernels</category>
      <category>compilers</category>
    </item>
    <item>
      <title>KREX: Kernel-Benchmarking auf geteilten GPUs, ohne die Suche des Agenten zu korrumpieren</title>
      <link>https://flozi.net/de/guides/ai/krex-shared-gpu-benchmark-corruption</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/krex-shared-gpu-benchmark-corruption</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Ein Systempaper von HKUST und Alibaba Group (arXiv:2609.30057, September 2026) greift eine versteckte Kopplung an, die die Welle der LLM-Kernel-Agenten erzeugt hat: Agenten brauchen verlässliches GPU-Timing, und bestehende Systeme kaufen es, indem sie eine komplette GPU pro Benchmarking-Kommando reservieren — verschwenderisch, denn die Timing-Phase macht nur rund 8,5% der medianen Kommando-Dauer aus. KREX verengt Exklusivität auf die Timing-Phase: Agenten markieren kritische Regionen, die Runtime blockiert neue GPU-Submissions, drainiert ausstehende Arbeit, friert die Prozessbäume der Siblings via Freezer-Cgroups ein und pinst die messenden Threads auf reservierte CPU-Kerne — nur innerhalb dieser Regionen. Ergebnis: bis zu 3,4× Benchmarking-Durchsatz auf NVIDIA H20 (2,6× auf AMD MI308X) bei p95-Timing-Inflation von 0,30%/1,58%/3,90% für Kernel über 10 ms/1 ms/0,1 ms. Dieser Guide setzt die beiden rechnerischen Kerne des Papiers in Zahlen: wie ein verzerrter Vergleicher einen Hill-Climbing-Agenten fehlleitet (eine falsche Messung ist schlimmer als eine langsame), und warum regionsgranulare Exklusivität fast nichts kostet — inklusive der Frage, warum kurze Kernel strukturell stärker leiden und wo die 1/d-Amortisierungs-Story nur zur Hälfte stimmt.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>gpu</category>
      <category>kernels</category>
      <category>benchmarking</category>
      <category>systems</category>
    </item>
    <item>
      <title>Wer bezahlt den KV-Cache? Messregeln sind getarnte Preisentscheidungen</title>
      <link>https://flozi.net/de/guides/ai/kv-cache-metering-billing-attribution</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kv-cache-metering-billing-attribution</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>arXiv:2609.24991 nimmt eine H100 mit vLLM und vier Tenants, zeigt aber, dass allein die Messregel — Tokenzählung oder GPU-Zeitanteil — einen retrieval-lastigen Tenant von 16,5 % auf 4,8 % der Rechnung verschiebt. Wir verifizieren die Lücke von 11,7–13,6 Prozentpunkten am Primärtext, zerlegen die Kapitalkosten der KV-Residenz mit Python und prüfen die Synthetik-Vorbehalte, die das Papier seinen Seam-Zahlen selbst mitgibt.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>prompt-caching</category>
      <category>economics</category>
      <category>gpu-memory</category>
      <category>kubernetes</category>
    </item>
    <item>
      <title>Risikokontrollierte KV-Eviction: Der Zuverlässigkeitsvertrag — und der Full-KV-Fallback, den niemand ausliefert</title>
      <link>https://flozi.net/de/guides/ai/kv-eviction-risk-contract</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kv-eviction-risk-contract</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Ein Paper der Korea University aus dem September 2026 (arXiv:2609.27981) dreht KV-Cache-Eviction vom Budget-first zum Risk-first: Man legt fest, wie oft ein Request material degradieren darf, und eine Learn-then-Test-Kalibrierung wählt das Retention-Level — oder fällt auf Full KV zurück, wenn nichts zertifiziert wird. Dieser Guide zerlegt die Finite-Sample-Maschinerie, reproduziert die Zertifizierungs-Cutoffs in Python und beziffert die ehrlichen Teile: den Kalibrierungspopulations-Geltungsbereich, den RULER-32K-Full-KV-Fallback und die 5-10 Prozentpunkte zusätzliche Retention, die die Garantie kostet.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>kv-cache</category>
      <category>eviction</category>
      <category>statistik</category>
      <category>zuverlaessigkeit</category>
      <category>long-context</category>
    </item>
    <item>
      <title>KITE: Das Modell skalieren, die KV-Rechnung einfrieren — welche Prefill-Invariante arXiv:2609.27294 wirklich beweist (und was nicht)</title>
      <link>https://flozi.net/de/guides/ai/kv-invariant-two-tower-scaling</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kv-invariant-two-tower-scaling</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>StepFuns KITE-Papier (arXiv:2609.27294) skaliert ein 33,8B-Quellmodell zu einem 67B-Zwei-Turm-MoE, dessen Prefill-KV-Kosten am kleinen Turm festgenagelt bleiben. Wir verifizieren die 67B/2,15B-Active-Zahlen, die Loss-Leiter 1,5900 vs. 1,6006/1,5921 und den 6,7 %/31,6 %-Inferenz-Proxy am Primärtext — und zerlegen dann die drei Hype-Brecher, die das Abstract nicht trägt: das Co-Training-Risiko der Turm-Trennung, den Unterschied zwischen Loss und Capability, und die Decode-FLOPs, die die KV-Invariante nicht berührt.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>kv-cache</category>
      <category>architecture</category>
      <category>economics</category>
      <category>gpu-memory</category>
    </item>
    <item>
      <title>KV-Cache-Tensordecomposition: Wo Low-Rank-Kompression mathematisch tot ist (und wo nicht)</title>
      <link>https://flozi.net/de/guides/ai/kv-tensor-decomposition-full-rank-modes</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kv-tensor-decomposition-full-rank-modes</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Singulärwertspektren aller vier KV-Cache-Tensorachsen auf Mistral-7B-v0.3 und Llama-2-13B: Token- und Feature-Achsen sind niedrigrangig, Kopf- und Layer-Achsen praktisch vollrangig — jedes „2x KV-Kompression gratis”-Versprechen, das über Köpfe oder Layer mischt, kämpft also gegen Lineare Algebra, nicht gegen Implementierungsrauschen. Tucker schlägt CP/TT/t-SVD bei gleichem Speicher um 2x-5x, weil es die vollrangigen Modi unangetastet lässt; Keys bevorzugen 2D-Entfaltungen, Values 4-Wege-Tucker, und ein Mode-Pinning-Theorem zertifiziert alles aus gemessenen Spektren allein. Mit einem lauffähigen Mixed-Rank-Python-Demo, dessen Pinned-vs-Forced-Rekonstruktionssweep den Fehlerfloor des Papiers reproduziert.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>kv-cache</category>
      <category>tensor-decomposition</category>
      <category>lineare-algebra</category>
      <category>gpu-memory</category>
    </item>
    <item>
      <title>KVSET: Der älteste Trick der Cache-Analyse löst gerade das Prefix-Cache-Sizing für LLMs</title>
      <link>https://flozi.net/de/guides/ai/kvset-working-set-prefix-cache-sizing</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/kvset-working-set-prefix-cache-sizing</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>KVSET (arXiv:2609.27746) ist keine neue Methode — es ist Mattsons LRU-Stack-Distanz-Algorithmus von 1970, aufgerichtet vor KV-Seiten, und er verwandelt Kapazität-für-Kapazität-Cache-Simulation in einen einzigen Durchlauf über den Trace. Dieser Guide führt den Algorithmus komplett auf einem toy-agentic Trace aus, verifiziert die Ein-Pass-Kurve gegen naive Multi-Simulation, extrahiert das Working Set und markiert, wo die LRU-Scope- und Trace-Form-Caveats zuschlagen.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>kv-cache</category>
      <category>prefix-caching</category>
      <category>gpu-memory</category>
      <category>capacity-planning</category>
    </item>
    <item>
      <title>Leaderboard-Margen gegen verborgene Modellauswahl: Welche Gewinne überleben k geheime Varianten?</title>
      <link>https://flozi.net/de/guides/ai/leaderboard-hidden-selection-noise</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/leaderboard-hidden-selection-noise</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Nicht „Leaderboards sind nutzlos.“ arXiv:2609.28177 zerlegt: das Gauße Margenmodell hinter Hidden-Selection-Sensitivitätskurven, warum die benötigte Schwelle von z=1,645 Richtung 2,7 wächst, je mehr Varianten k bei rho_w=0,56 umfasst, warum die Korrelation zum gerankten Score passen muss (0,90 gepoolt vs 0,46 Item-Resampling vs 0,92 Subject-Resampling), und das 394-Claims-Audit, das 391 ohne statistische Unterstützung findet — bevor Selektion überhaupt eingeht. Mit Simulation.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>evaluation</category>
      <category>leaderboards</category>
    </item>
    <item>
      <title>Greedy Decoding ist nicht präzisionsinvariant: BF16-vs-FP16-Flips, Margin-Gating und die Kernel-Reihenfolgen-Achse</title>
      <link>https://flozi.net/de/guides/ai/precision-variant-greedy-decode-flips</link>
      <guid isPermaLink="true">https://flozi.net/de/guides/ai/precision-variant-greedy-decode-flips</guid>
      <pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
      <description>Zwei Papers vom September 2026 zersetzen die Annahme, Greedy Decoding sei deterministisch. Das erste (arXiv:2609.26621, TMLR 2026) zeigt: dasselbe Modell, derselbe Prompt und derselbe Greedy-Algorithmus liefern in BF16 versus FP16 auf identischer Hardware unterschiedliche Ausgaben — 49 bis 100 Prozent der Prompts divergieren über sechs Modelle von 1,1B bis 7B — und verfolgt den Flip bis zu einem einzigen kleinen Top-Two-Logit-Margin am lm_head, nicht bis zu 22 angehäuften Body-Fehlern. Eine margin-gebrochene FP32-lm_head-Neuberechnung kauft 22 bis 36 Prozentpunkte exakte Übereinstimmung bei unter 4 Prozent Latenz zurück — und, kontraintuitiv, breitere FP32-Berechnung verschlechtert die Übereinstimmung. Das zweite (arXiv:2609.25624) greift die geräteübergreifende Achse an: Frameworks wählen pro Architektur andere GEMM-Kernel, andere Reduktionsreihenfolgen flippen Tokens, und die Lösung sind Kernels mit fester Konfiguration, deren Reduktionsreihenfolge eine reine Funktion der Problemform ist — bitweise identische lineare Ausgaben über Ampere, Ada und Hopper, 1,17- bis 3,1-mal schneller als der FP32-State of the Art. Dieser Guide führt die zugrundeliegende Float-Nichtassoziativität, das flippende Argmax und das Margin-Kriterium in ausführbarem Python mit echten Ausgaben vor und verortet die ehrlichen Grenzen beider Papers.</description>
      <category>ai</category>
      <category>machine-learning</category>
      <category>llm</category>
      <category>inference</category>
      <category>numerics</category>
    </item>
  </channel>
</rss>
