PFlash: 10× schnelleres Prefill bei 128K-Kontext auf RTX 3090
PFlash ist eine Open-Source-Implementierung (MIT-Lizenz, github.com/Luce-Org/lucebox-hub), die zwei neuere Forschungsarbeiten erstmals gemeinsam in einer produktionsnahen C++/CUDA-Pipeline kombiniert: Speculative Prefill (Liu et al., arXiv 2502.02789) und FlashPrefill (Fan et al., 2026). Das Grundprinzip: Ein kleines Draft-Modell (Qwen3-0.6B, BF16) analysiert den vollständigen Prompt und bewertet die Wichtigkeit einzelner Token. Der rechenintensive 27B-Ziel-Modell prefillt anschließend nur die relevanten Spans – nicht den gesamten Kontext. Dadurch entfällt ein Großteil des quadratisch skalierenden O(S²)-Aufwands. Auf einer RTX 3090 (24 GB VRAM) sinkt die TTFT für Qwen3.6-27B Q4_K_M bei 128K von ~257 s auf 24,8 s (10,4×) und bei 64K von ~135 s auf 13,5 s (10,0×). Da Drafter-Gewichte (1,3 GB), BSA-Scratch (~600 MB) und DFlash-Daemon (15 GB Target + 3 GB Draft + 3 GB KV) nicht gleichzeitig in den VRAM passen, orchestriert ein Parking-Mechanismus die Gewichte per stdin-Protokoll zwischen den Phasen (~3 s Overhead pro Request). Needle-in-a-Haystack (NIAH)-Tests bestätigen, dass die Retrieval-Qualität trotz selektivem Prefill erhalten bleibt. Die vier zentralen CUDA-Kernel (mean_K, score, select, sparse_fwd) wurden von Grund auf neu geschrieben, da die FlashPrefill-Referenzimplementierung in Triton vorliegt und libtorch (~2 GB) im 24-GB-Setup nicht tragbar ist.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
PFlash: 10× schnelleres Prefill bei 128K-Kontext auf RTX 3090
PFlash ist eine Open-Source-Implementierung (MIT-Lizenz, github.com/Luce-Org/lucebox-hub), die zwei neuere Forschungsarbeiten erstmals gemeinsam in einer produktionsnahen C++/CUDA-Pipeline kombiniert: Speculative Prefill (Liu et al., arXiv 2502.02789) und FlashPrefill (Fan et al., 2026). Das Grundprinzip: Ein kleines Draft-Modell (Qwen3-0.6B, BF16) analysiert den vollständigen Prompt und bewertet die Wichtigkeit einzelner Token. Der rechenintensive 27B-Ziel-Modell prefillt anschließend nur die relevanten Spans – nicht den gesamten Kontext. Dadurch entfällt ein Großteil des quadratisch skalierenden O(S²)-Aufwands. Auf einer RTX 3090 (24 GB VRAM) sinkt die TTFT für Qwen3.6-27B Q4_K_M bei 128K von ~257 s auf 24,8 s (10,4×) und bei 64K von ~135 s auf 13,5 s (10,0×). Da Drafter-Gewichte (1,3 GB), BSA-Scratch (~600 MB) und DFlash-Daemon (15 GB Target + 3 GB Draft + 3 GB KV) nicht gleichzeitig in den VRAM passen, orchestriert ein Parking-Mechanismus die Gewichte per stdin-Protokoll zwischen den Phasen (~3 s Overhead pro Request). Needle-in-a-Haystack (NIAH)-Tests bestätigen, dass die Retrieval-Qualität trotz selektivem Prefill erhalten bleibt. Die vier zentralen CUDA-Kernel (mean_K, score, select, sparse_fwd) wurden von Grund auf neu geschrieben, da die FlashPrefill-Referenzimplementierung in Triton vorliegt und libtorch (~2 GB) im 24-GB-Setup nicht tragbar ist.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.