PFlash acelera prefill 10x em 128K tokens na RTX 3090

O problema que ninguém quer encarar

Se você já rodou um modelo local com contexto grande, sabe: o decode é rápido, mas o prefill é um pesadelo. Em uma RTX 3090 com 24 GB, o llama.cpp leva mais de 4 minutos para processar 128 mil tokens antes de gerar a primeira resposta. Você fica olhando para a tela preta enquanto o cache é preenchido. PFlash, um projeto open source recém-publicado, ataca exatamente esse gargalo com uma técnica chamada speculative prefill e promete 10x de aceleração no prefill para contextos longos.

O que é o PFlash

PFlash é uma implementação em C++/CUDA que usa um modelo auxiliar pequeno (o drafter) para identificar quais partes do prompt são realmente importantes para o modelo principal. Em vez de processar o prompt inteiro token por token – que custa O(S²) – o modelo principal só pré-computa os spans que o drafter sinaliza como relevantes. O resultado: em um teste com Qwen3.6-27B Q4_K_M em 128K tokens, o PFlash entregou um TTFT (time to first token) de 24,8 segundos contra 257 segundos do llama.cpp vanilla – uma redução de 10,4x. Em 64K, a aceleração foi de 10x (13,5s vs 134,95s), mantendo a recuperação NIAH intacta.

O repositório está disponível no GitHub (Luce-Org/lucebox-hub) sob licença MIT. Sem Python, sem Triton, sem PyTorch no loop de inferência – apenas C++ e CUDA.

Como funciona na prática (visão de operador)

O speculative prefill não é uma ideia nova – ela foi proposta nos papers Speculative Prefill (Liu et al.) e Splitwise –, mas o PFlash implementa o conceito de forma enxuta e integrada. O drafter roda inline no mesmo processo, carregado junto com o modelo principal, e gera máscaras de atenção esparsa. O modelo principal então só executa a atenção nos tokens selecionados, reduzindo drasticamente o custo quadrático.

Do ponto de vista de API, você ganha um parâmetro a mais: o tamanho do bloco de prefill especulativo. A latência cai, mas o throughput do decode permanece o mesmo (~74 tok/s no teste). O trade-off? O drafter consome recursos extras de VRAM e compute. Nos testes com 24 GB, parece que cabe, mas para modelos maiores ou contextos ainda mais longos, o overhead pode crescer.

O que isso muda na prática

Para quem desenvolve agentes locais ou aplicações que exigem processamento de documentos longos (RAG, sumarização de logs, análise de código), o ganho de 10x no prefill transforma a experiência. Em vez de esperar minutos, você espera segundos. Mas a pergunta prática: você precisa recompilar seu pipeline para adotar o PFlash? Sim, se você usa llama.cpp como backend. O PFlash não é um drop-in replacement – é uma alternativa que exige integração, e que atualmente suporta apenas modelos quantizados Q4_K_M (embora a técnica generalize).

Uma ação imediata: se você mantém um servidor de inferência local, teste o PFlash em cargas de trabalho com contextos acima de 32K. A redução de TTFT pode justificar o esforço de migração, especialmente se você sofre com timeouts ou experiência de usuário degradada.

Tensão: isso escala? compensa?

Olhando com cuidado: o speculative prefill depende da qualidade do drafter. Se o drafter errar os spans importantes, o modelo principal pode perder informações críticas – e você pode obter respostas incompletas. Os testes mostram que a recuperação NIAH se mantém, mas em cenários reais com ruído, a história pode ser diferente. Além disso, o custo do drafter não é trivial: para cada token do prompt, você executa o drafter parcialmente. Em prompts muito curtos, o overhead pode até piorar a latência. O ganho real aparece em contextos longos, onde a complexidade quadrática domina. A pergunta que fica: para contextos de 8K ou 16K, o prefill do llama.cpp já é aceitável; a aceleração extra vale a complexidade extra?

Conclusão

PFlash ataca um dos gargalos mais dolorosos da inferência local com contexto longo e entrega resultados impressionantes em benchmarks. Se você opera com 64K+ tokens e sente na pele os minutos de espera, vale a pena testar. Mas, como toda otimização agressiva, o diabo está nos detalhes: a acurácia do drafter e o custo de integração. O código está aberto – mãos à obra.