Der NInfer-Fork wurde von einem Einzelentwickler in einer Woche intensiver Praxistests mit drei simultanen Claude-Code-Sessions stabilisiert — entstanden, weil upstream Issues und Pull Requests zu langsam aufgegriffen wurden. Das Herzstück ist ein komplett neu geschriebener NVFP4-KV-Cache für QIn3.8-27B mit einem eigenen MMA-Kernel (mma_nvfp4_e4m3, m16n8k64), der Hardware-E4M3-Blockscales für das QK-Matmul nutzt. Technisch unterscheidet er sich vom zwischenzeitlich nachgezogenen Upstream-NVFP4-Pfad vor allem durch Hadamard-Rotation auf K und Q zur Ausreißerunterdrückung, während V zur PV-Berechnung per dediziertem Decode-Kernel zu BF16 dequantisiert wird. Der fused-append-Mechanismus quantisiert K/V direkt während der Generierung ohne separaten Pass, was den Overhead minimiert. Für das Kontext-Management ersetzt das HostKVSafetyNet die upstream LRU-Lösung durch ein gepinntes Host-Arena-System mit Scatter-Gather-Allokation, Arena-Kompaktierung und einem zweistufigen Prefix-Matching — zuerst per Execution-Frontier, dann per Rewrite-Checkpoint-Fallback. Bei denkenden Modellen sorgt ein Session-Key-Fallback dafür, dass weggelassene Reasoning-Tokens zwischen Turns die Caching-Kette nicht brechen. Gemessen über 260+ Requests mit drei parallelen Sessions zwischen 330k und 470k Token wurden keinerlei Re-Prefills auf gecachten Turns registriert.