PFlash: RTX 3090에서 128K 컨텍스트 기준 llama.cpp 대비 10배 빠른 프리필 속도
핵심 요약
27B 모델 대상 C++/CUDA 기반 speculative prefill 기술로 128K 컨텍스트 프리필 속도를 10배 개선함.
- 성능 최적화 — 27B 모델에서 128K 컨텍스트 프리필 속도를 10배 이상 향상함.
- 기술적 구현 — 파이썬이나 PyTorch 없이 C++/CUDA만으로 speculative prefill을 구현함.
- 메모리 관리 — 24GB VRAM 환경에서 모델 가중치를 동적으로 관리하여 단일 GPU에서 구동함.
- 품질 논쟁 — 10배의 속도 향상에 따른 모델 성능 저하 가능성에 대해 커뮤니티 내 의구심이 존재함.
안녕하세요 동료 Llamas 여러분, 지난번에 올린 글에 보내주신 따뜻한 말씀과 훌륭한 피드백에 감사드립니다. 공유할 만한 새로운 것을 준비했습니다. 항상 그렇듯 여러분의 시간은 소중하므로 짧게 말씀드리겠습니다.
저희는 양자화된 27B 타겟 모델에서 긴 컨텍스트 디코딩을 위한 speculative prefill을 C++/CUDA 전용으로 구축했습니다. 프로세스 내부에 로드된 작은 드래프터가 전체 프롬프트에 걸쳐 토큰 중요도를 점수 매기고, 무거운 타겟 모델은 중요한 스팬(span)만 프리필합니다.
저장소: github.com/Luce-Org/lucebox-hub (오픈 소스, MIT).
Qwen3.6-27B Q4_K_M, RTX 3090, 단일 샷 기준 비교: 128K에서 24.8초 TTFT vs 기존 llama.cpp 257초 = 약 10.4배 (64K에서는 13.5초 vs 134.95초 = 10.0배), NIAH 검색 성능은 끝까지 유지됩니다. 추론 루프 내에 파이썬, Triton, PyTorch는 없습니다.
문제점
24GB 3090에서 Q4_K_M Qwen3.6-27B는 빠르게 디코딩되지만(DFlash spec decode 사용 시 약 74 tok/s), 프리필은 O(S²)로 확장됩니다. 131K 토큰 프롬프트에서 기존 llama.cpp는 콜드 상태에서 248.4초가 걸립니다(llama-bench pp131072 --no-warmup -r 1, 527.6 tok/s). 첫 토큰이 나오기 전까지 빈 화면을 4.1분 동안 바라봐야 합니다. 디코드는 빠르지만 대기 시간이 사용자 경험을 망칩니다. 워밍업된 상태는 더 낫지만(128K에서 169.3초) 여전히 고통스럽고, 컨텍스트를 늘릴수록 이차함수적으로 증가합니다.
기반 기술
이 작업은 최근 발표된 두 가지 훌륭한 논문을 기반으로 합니다:
- Speculative Prefill (Liu et al, arXiv 2502.02789) 및 Cross-Family Speculative Prefill (SambaNova, ICLR 2026). 핵심 통찰: 작은 드래프트 모델의 긴 프롬프트에 대한 어텐션 패턴은 답변에 중요한 토큰을 정확히 예측합니다. 드래프터를 실행하고 토큰별 중요도를 점수 매겨 상위 스팬만 유지하고 나머지는 버립니다.
- FlashPrefill (Fan et al, 2026). 블록 희소 어텐션을 사용하여 드래프터 자체가 128K에서 O(S²) 비용을 지불하지 않게 합니다.
- FA-2 기반 sm_80+ 희소 포워드를 위한 mit-han-lab/Block-Sparse-Attention (BSA).
- 런타임을 위한 ggml / llama.cpp. 저희는 libggml*.a를 링크하며 libllama은 사용하지 않습니다.
저희의 기여는 이 두 알고리즘을 24GB 소비자용 카드에서 프로세스 내 C++/CUDA로 구성한 것입니다. 저희가 알기로는 이 두 논문이 오픈 소스 구현에서 결합된 적은 없었습니다.
구축 내용
- 프로세스 내 구성. 드래프터 포워드(커스텀 Qwen3-0.6B BF16 ggml 그래프), FlashPrefill 점수 매기기, 희소 어텐션, 타겟 프리필, DFlash spec decode가 모두 하나의 ggml 할당자를 공유하는 하나의 C++/CUDA 프로세스에서 실행됩니다. 추론 루프 내에 서브프로세스, IPC, 파이썬, Triton, PyTorch는 없습니다.
