When NPUs Are Not Always Faster: A Stage-Level Analysis of Mobile LLM Inference

Resumo Técnico: Quando as NPUs Nem Sempre São Mais Rápidas

Declaração do Problema
A implantação de Modelos de Linguagem de Grande Porte (LLMs) em dispositivos móveis depende cada vez mais de execução heterogênea envolvendo tanto CPUs quanto Unidades de Processamento Neural (NPUs). No entanto, pesquisas anteriores não conseguiram caracterizar sistematicamente a eficácia das NPUs nos níveis de operador e pipeline. Os benchmarks existentes frequentemente fornecem apenas taxa de transferência agregada ou comparam CPUs e GPUs, deixando uma lacuna na compreensão de como as NPUs se comportam sob cargas de trabalho específicas de LLMs, particularmente no que diz respeito às características computacionais distintas das etapas de Prefill (intensivas em computação) e Decode (limitadas por memória). Há uma falta de dados sobre se o descarregamento para NPUs realmente melhora a latência ou a eficiência energética ao contabilizar as sobrecargas de comunicação, quantização e agendamento.

Metodologia
Os autores apresentam um framework de benchmarking multinível e consciente de etapas em um System-on-Chip heterogêneo CPU–NPU (Snapdragon 8 Gen 3). O estudo utiliza o motor de inferência llama.cpp e avalia quatro modelos quantizados (Llama-3.2-3B, Llama-3.1-8B, Qwen3-4B e Qwen3-8B).

As inovações metodológicas chave incluem:

1. Análise em Nível de Etapa: Separar a inferência na etapa de Prefill (GEMM em lote) e na etapa de Decode (GEMV autoregressivo) para analisar a divergência de desempenho.
2. Perfilamento em Nível de Operador: Distinguir entre op-usec (tempo de computação puro) e call-usec (tempo total de invocação incluindo agendamento e sincronização) para quantificar a sobrecarga de orquestração.
3. Decomposição de Pipeline Baseada em OPMASK: Uma metodologia controlada usando quatro modos de execução para isolar e medir as contribuições de latência de três componentes específicos do pipeline da NPU:
   • Comunicação: Despacho de solicitações CPU–NPU e tratamento de respostas.
   • Quantização: Conversão dinâmica de formato de dados (por exemplo, F32 para INT8).
   • Computação: Execução real nas unidades NPU.
     Ao habilitar esses componentes incrementalmente, os autores calculam a sobrecarga específica de cada etapa sem modificação de hardware.

Principais Resultados
O estudo revela uma reversão de desempenho contra-intuitiva onde as NPUs não superam universalmente as CPUs:

• Etapa de Prefill (Superioridade da CPU): Na etapa de Prefill, intensiva em computação, a CPU supera consistentemente a NPU em 1,27× a 1,62×. Isso é atribuído à memória limitada on-chip da NPU (8 MiB VTCM) que restringe o "tiling" de dados para matrizes grandes, intrínsecos HVX menos otimizados em comparação com bibliotecas GEMM de CPU maduras, e sobrecarga de operadores não suportados que retornam à CPU.
• Etapa de Decode (Ganho Limitado da NPU): Embora a NPU mostre uma vantagem de 1,55×–1,67× no operador central MUL_MAT (GEMV) devido à memória de armazenamento temporário gerenciada por software eficiente e DMA, a aceleração de ponta a ponta é marginal (1,05×–1,20×).
• Gargalos de Sobrecarga: Dois fatores principais corroem os benefícios da NPU:
  1. Taxa de Agendamento: Para operadores leves (por exemplo, RMS_NORM), o call-usec é 8×–22× maior que o op-usec devido aos custos de comunicação de ida e volta entre CPU e NPU.
  2. Fallback entre Backends: Operadores que carecem de suporte nativo da NPU (por exemplo, FLASH_ATTN_EXT) retornam à CPU com uma penalidade de latência de 1,5× devido à sincronização de coerência de cache e reordenação de tensores.
• Consumo de Energia: Contrariando expectativas, aumentar o descarregamento para NPUs leva a um maior consumo total de energia, com o esgotamento da bateria aumentando em até 51% para prompts mais longos. Isso é impulsionado pelo tempo de execução aumentado na etapa de Prefill e pela sobrecarga cumulativa de agendamento e fallbacks.
• Decomposição de Pipeline: A sobrecarga de comunicação é negligenciável no Prefill (<3,2%), mas aumenta no Decode (9,9%–13,0%) devido ao despacho de alta frequência de operações de granularidade fina.

Significado e Diretrizes de Design
O artigo afirma ser o primeiro estudo a combinar perfilamento competitivo CPU–NPU com consciência de etapa, granularidade em nível de operador e decomposição de pipeline. Com base nessas descobertas, os autores derivam três diretrizes de design para arquitetos de NPU e integradores de sistema:

1. Seleção de Backend Consciente de Etapa: Roteirizar a etapa de Prefill para CPUs multinúcleo (aproveitando bibliotecas maduras e caches maiores) e a etapa de Decode para a NPU.
2. Reduzir a Latência de Despacho: A latência de despacho da NPU para operadores leves deve ser reduzida abaixo de 10 µs. Técnicas como despacho em lote, filas de comando persistentes ou fusão de operadores são necessárias para mitigar a taxa de agendamento.
3. Melhorar a Cobertura de Operadores: Operadores críticos como FLASH_ATTN devem ser implementados nativamente na NPU para eliminar a penalidade de fallback e realizar plenamente os benefícios de aceleração na fase de decodificação.

Os autores concluem que realizar inferência eficiente de LLMs em dispositivos exige ir além de estratégias simples de descarregamento, rumo a uma execução consciente de etapas e a um melhor co-design sistema-hardware.