Resumo Técnico: SparsePixels: Convolução Eficiente para Dados Esparsos em FPGAs

1. Definição do Problema

Redes Neurais Convolucionais (CNNs) padrão implantadas em FPGAs (Field-Programmable Gate Arrays) para experimentos de física de partículas frequentemente sofrem com alta latência de inferência e longos intervalos de iniciação. Essa ineficiência surge porque a convolução padrão exige o processamento denso de cada pixel de entrada, independentemente de o pixel conter informação semântica ou não. Em muitas aplicações modernas de detectores, como o rastreamento de múons em câmaras de gás ou a identificação de neutrinos em Câmaras de Projeção Temporal de Argônio Líquido (LArTPCs), os dados de entrada são espacialmente esparsos. Por exemplo, uma trilha de múon pode ocupar menos de 0,3% de uma imagem 2D, e trilhas de neutrinos em LArTPCs podem ter tão pouco quanto 0,01% de pixels não nulos.

Implementações atuais de FPGA, como as que utilizam a biblioteca hls4ml, geralmente dependem de I/O (Entrada/Saída) por streaming para gerenciar restrições de recursos. Embora o streaming reduza o uso de recursos, ele processa os pixels sequencialmente, levando a latências que escalam linearmente com o tamanho da imagem (por exemplo, varrendo milhares de pixels vazios). Isso torna as CNNs padrão inviáveis para sistemas de gatilho (trigger) em tempo real em experimentos de física de altas energias, que exigem latências de decisão na ordem de microssegundos ou sub-microssegundos para lidar com taxas de colisão de 40 MHz.

Métodos de convolução esparsa existentes para GPUs (ex: MinkowskiEngine, SpConv) frequentemente permitem que o conjunto de pixels ativos se "dilate" através das camadas, aumentando o custo computacional, ou dependem de fluxos de dados irregulares que resultam em tempos de execução dependentes da entrada. Em sistemas com limites estritos de latência, o tempo de execução variável é inaceitável.

2. Metodologia: O Framework SparsePixels

Os autores introduzem o SparsePixels, um framework projetado para implementar convolução esparsa em FPGAs que mantém um tempo de execução constante e independente da entrada. A filosofia central é reter e computar seletivamente apenas um pequeno subconjunto pré-especificado de pixels ativos, ignorando o restante, garantindo que a contagem total de operações permaneça fixa para cada entrada.

2.1 Arquitetura Central

O framework consiste em cinco camadas esparsas especializadas projetadas para Síntese de Alto Nível (HLS):

1. Redução de Entrada Esparsa: A primeira camada identifica os pixels ativos (aqueles que excedem um limiar) e os extrai para arrays compactos. Para evitar endereços de escrita dependentes de dados (que causam problemas de escalonamento em HLS), os autores empregam uma árvore de redução binária recursiva. Este esquema eficiente em hardware varre a entrada em um padrão fixo para popular dois arrays: um array de características (afeat) e um array de hash de coordenadas (ahash). O número de pixels retidos é limitado por um hiperparâmetro, $N_{max}^{active}$.
2. Convolução Esparsa: Esta camada realiza uma convolução que preserva a esparsidade. Crucialmente, um pixel de saída é computado apenas se o respectivo pixel de entrada na mesma localização estiver ativo. Isso evita a "dilatação" do conjunto ativo observada em outros métodos esparsos. O algoritmo itera sobre os arrays esparsos de tamanho fixo em vez da grade completa da imagem. A contagem de iterações depende de $N_{max}^{active}$, não do tamanho do kernel $K$, pois as posições do kernel são determinadas via verificações de deslocamento (offset) em vez de loops explícitos sobre todas as $K^2$ posições.
3. Ativação Esparsa: Aplica não-linearidade elemento a elemento ao array de características esparsas.
4. Pooling Esparso: Realiza o downsampling da representação esparsa mapeando coordenadas e acumulando características para pixels que caem no mesmo pool.
5. Flattening Esparso: Converte a representação esparsa final de volta para um array denso para conexão com camadas densas padrão (MLP).

2.2 Detalhes de Implementação

• Tempo de Execução Constante: Como o sistema opera em arrays de tamanho fixo ($N_{max}^{active}$), preenchidos com flags de invalidade se a entrada tiver menos pixels ativos, a latência de inferência é independente da esparsidade real da entrada.
• Treinamento: Uma biblioteca Python foi desenvolvida para treinar essas CNNs esparsas usando Treinamento Consciente de Quantização (QAT) com o backend QKeras. O treinamento mimetiza o comportamento do HLS, incluindo a restrição de $N_{max}^{active}$ fixo.
• Alvo de Hardware: O design visa FPGAs AMD/Xilinx Alveo (xcu250) usando Vitis HLS, operando a 200 MHz.

3. Principais Contribuições

1. Método de Convolução Esparsa: Uma abordagem inovadora para FPGAs que seleciona adaptativamente pixels ativos, mas impõe um orçamento de computação fixo ($N_{max}^{active}$), garantindo latência constante independentemente da esparsidade da entrada.
2. Implementação de Prova de Conceito: Uma demonstração de ganhos significativos de velocidade de inferência em FPGA com dados de imagem espacialmente esparsos, com desempenho de modelo comparável às CNNs padrão.
3. Ferramental Open-Source: Uma biblioteca Python liberada publicamente para treinar CNNs esparsas e módulos C++ HLS para implantação, facilitando a adoção pela comunidade de física de partículas.

4. Resultados Experimentais

Os autores avaliaram o SparsePixels em três conjuntos de dados: uma variante esparsa do MNIST, detecção de neutrinos MicroBooNE e classificação de jatos (jet flavor tagging) do LHC. Os modelos foram compactos (~4k parâmetros) e comparados contra baselines de CNN padrão implementadas com I/O de streaming.

• Desempenho vs. Latência: No conjunto de dados MicroBooNE (imagens de 63×63, ~4k pixels), uma CNN padrão de 8 bits exigiu 48,665 µs (9.733 ciclos de clock) para inferência. A variante "sparse-large" do SparsePixels (computando em apenas 20 pixels ativos, <1% da entrada) alcançou um tempo de inferência de 0,665 µs (133 ciclos de clock). Isso representa um aceleração de 73× com uma perda de desempenho negligenciável (<2% de queda no ROC AUC).
• Escalabilidade: Acelerações semelhantes foram observadas para o MNIST (até 41×) e para o jet tagging do LHC (até 112×).
• Utilização de Recursos: Embora as CNNs esparsas utilizem mais recursos (devido ao unrolling de loops para paralelismo) do que o streaming de CNNs padrão, o uso de recursos permanece bem dentro dos orçamentos on-chip (ex: ~20% de LUTs para os maiores modelos).
• Intervalo de Iniciação (II): O II para as CNNs esparsas é determinado exclusivamente pela camada de redução de entrada esparsa (a primeira camada), já que as camadas subsequentes operam em paralelo sobre os arrays esparsos de tamanho fixo.

5. Significância e Limitações

Significância:
O artigo afirma que o SparsePixels permite a implantação de CNNs em regimes de latência ultra-baixa (sub-microssegundo) exigidos pelos gatilhos modernos de física de partículas, onde as CNNs padrão são atualmente inviáveis devido à latência. Ao trocar uma pequena quantidade controlável de precisão por acelerações massivas, o framework permite algoritmos online mais sofisticados em experimentos como o High-Luminosity LHC.

Limitações e Trabalhos Futuros:

• Restrições de Paralelização: A implementação atual realiza o unrolling total dos loops para minimizar a latência, o que limita o tamanho máximo de entrada e a complexidade do modelo devido à exaustão de recursos da FPGA. Trabalhos futuros visam introduzir controle flexível sobre a paralelização para trocar latência por eficiência de recursos.
• Ajuste de Hiperparâmetros: A escolha de $N_{max}^{active}$ é atualmente empírica. Os autores propõem tornar este parâmetro (e potencialmente o limiar) treinável em versões futuras.
• Quantização: O backend atual utiliza quantização uniforme por camada. Atualizações futuras planejam adotar Quantização de Alta Granularidade (HGQ) para maior controle.

Os autores concluem que o SparsePixels oferece um caminho viável para a leitura eficiente de dados em experimentos com requisitos de latência de nível de microssegundos, preenchendo a lacuna entre a necessidade de modelos de ML complexos e as rigorosas restrições de tempo dos gatilhos de hardware em tempo real.