Resumo Técnico: RIGEL – Engenharia Reversa do Caminho de Computação de Tensores Metal 4.1 no Apple M4 Max

Declaração do Problema

A especificação Metal 4.1 da Apple (lançada com o Xcode 27/macOS 27.0) introduz um caminho de computação tensorial por meio da operação matmul2d no Metal Performance Primitives (MPP), suportando formatos de baixa precisão como fp8 (E4M3), fp4 e MXFP4 de escala de bloco. No entanto, a especificação documenta a interface de software enquanto obscurece deliberadamente o comportamento do hardware. Ela declara os tipos de dados como "suportados" sem esclarecer se são acelerados por hardware ou emulados, deixa o layout do fragmento de tensor cooperativo "opaco" e não fornece detalhes sobre alvos de despacho, larguras de acumulador ou restrições microarquiteturais. Consequentemente, os desenvolvedores não conseguem determinar se as operações de baixa precisão oferecem ganhos de desempenho ou apenas benefícios de pegada de memória, nem podem otimizar kernels sem conhecer o modelo de execução subjacente.

Metodologia: O Harness RIGEL

Os autores apresentam o RIGEL, um framework de caracterização empírica projetado para recuperar fatos ocultos do hardware através de microbenchmarking. A metodologia baseia-se em uma "barra de descoberta": um achado só é considerado uma contribuição se for oculto pela especificação ou contradiz a mesma.

Os componentes principais do harness RIGEL incluem:

• Verificação com Gatilho de Checksum: Para distinguir entre erro de quantização de entrada e erro de acumulação de hardware, o harness computa uma referência float64 usando exatamente os mesmos bytes quantizados consumidos pela GPU. Os resultados são descartados se excederem as tolerâncias de erro por tipo de dado.
• Rastreamento de Proveniência: Cada célula de medição é vinculada a um commit específico de código, receita de geração de entrada, semente aleatória e hash de ambiente (build do OS, toolchain, dispositivo). Todas as figuras são regeneradas a partir de CSVs commitados via um alvo make reproduce.
• Comparação de Baseline: As reivindicações de desempenho são validadas contra quatro baselines: roofline de ALU escalar, GEMM com tiling de threadgroup ingênuo, instruções de matriz simdgroup legadas e caminhos MPP fp16 padrão. Um kernel deve superar o baseline mais forte em pelo menos 1.10× para ser considerado uma vitória; formatos de baixa precisão devem atingir 1.5× o throughput de fp16 para serem considerados "acelerados" em vez de "emulados".
• Triangulação: O alvo de despacho é determinado via três sinais independentes: tetos de throughput, comparação com matriz simdgroup e atribuição de potência por trilho (rail).

O estudo foi conduzido em um único Apple M4 Max (40 núcleos de GPU, 64 GB de memória unificada) rodando macOS 27.0 beta. A geração M4 é observada como pré-datando os "Aceleradores Neurais" introduzidos na família A19/M5.

Principais Achados e Resultados

1. Alvo de Execução: Sem Unidade de Matriz Dedicada

Ao contrário das especulações de que a Apple poderia ter introduzido uma unidade de tensor dedicada análoga à da NVIDIA, o RIGEL confirma que o matmul2d executa inteiramente nos núcleos de shader da GPU via o caminho de matriz simdgroup legado.

• Teto de Throughput: O matmul2d com fp16 em tiles atinge o pico de 14.8 TFLOP/s, o que é aproximadamente 46% do roofline de ALU escalar de fp16 (32 TFLOP/s). Nenhum datapath oculto excede o teto da ALU.
• Proximidade de Desempenho: O MPP matmul2d supera um GEMM com tiling ingênuo em 2.9–5.5×, mas vence a matriz simdgroup legada por apenas 1.05–1.21×, indicando que ele desce para o mesmo pipeline.
• Atribuição de Potência: Sob carga sustentada, o consumo de energia da GPU aumenta significamente enquanto a residência de hardware ativa atinge 100%. Embora a medição direta de potência do ANE (Apple Neural Engine) tenha sido bloqueada pelo OS beta, a falta de throughput além do caminho exclusivo da GPU sugere que não há offloading para o ANE.

2. O "Título": fp8 é Emulado, Não Acelerado

O achado mais significativo é que o fp8 (E4M3) matmul2d do Metal 4.1 é emulado, não acelerado por hardware.

• Throughput: O fp8 sustenta apenas 0.94× o throughput de fp16 (atingindo o pico de 0.941× em 2048³).
• Implicação: Como os operandos fp8 têm metade do tamanho dos fp16, um kernel limitado por memória deveria ser mais rápido. O fato de ser mais lento indica que a operação é limitada por computação e incorre em puro overhead de unpack. No M4 Max, o fp8 é um recurso de pegada de memória e faixa dinâmica, não um recurso de desempenho. A aceleração real é prevista para chegar com a geração M5.

3. Semântica Numérica e Restrições Ocultas

• Largura do Acumulador: O acumulador interno é pelo menos fp32. Um caso de teste hostil (somando um termo grande e 127 termos pequenos) mostrou que o matmul2d de fp8 produziu o resultado exato (455.9375), enquanto um acumulador fp16 teria perdido precisão (estagnando em 448).
• Layout de Fragmento: O layout de fragmento de tensor cooperativo 8×8 opaco foi reconstruído. É um fragmento base unificado de 8×8 onde cada lane SIMD possui duas linhas verticalmente adjacentes de uma coluna dentro de seu quadrante. Este layout é consistente entre as entradas (A, B) e a saída.
• Restrições de Alinhamento: Inlines de tensor vinculados ao host exigem que o stride interno seja alinhado em 128 bytes. Esta restrição é aplicada via uma nota SFINAE nos headers, mas está ausente da especificação, fazendo com que portas ingênuas falhem com erros de compilador enganosos.
• Saturação: Formatos E4M3 limitam-se a ±448 em overflow (sem codificação de infinito), enquanto E5M2 produz ±∞.

4. Oportunidades de Otimização

Usando o layout de fragmento recuperado, os autores implementaram um kernel fundido de GEMM + bias + GELU.

• Ganho de Desempenho: No regime de cache residente, este kernel fundido supera o caminho decomposto em +6.5% a +12.9%.
• Mecanismo: A vitória vem de evitar o tráfego de memória O(n²) fundindo o epílogo in-register. O benefício diminui conforme o compute O(n³) domina.
• Limitação de Atenção: Tentativas de fundir FlashAttention (substituindo unidades de matriz por código escalar) resultaram em kernels de 3.6–5× mais lentos que o caminho decomposto, pois a alta largura de banda de memória do M4 torna o round-trip S×S barato, e os overheads de fusão superaram os benefícios.

Contradições e Portões de Versão

O artigo identifica várias discrepâncias entre a especificação e a realidade:

• Portão de Versão: O Metal 4.1 requer Xcode 27 e macOS 27.0. Binários compilados com Xcode 27 (Metal 4.1) recusam-se a carregar no macOS 26.5, contradizendo a afirmação da especificação de disponibilidade a partir de "Xcode 26.1+".
• Ausência de Recurso: Os formatos de baixa precisão (fp8, fp4) e blocos de tensor de escala de bloco (MXFP4) do 4.1 estão ausentes sob a toolchain 4.0, apesar de as tabelas de recursos da especificação sugerirem o contrário.

Significância e Conclusão

O RIGEL fornece a primeira caracterização empírica do caminho de tensor Metal 4.1 no Apple Silicon. Sua principal significância reside em desmistificar a realidade do hardware por trás de uma interface deliberadamente opaca.

• Ele esclarece que o M4 Max carece de uma unidade de matriz dedicada, colocando as expectativas de desempenho de fp8 no contexto correto (pegada vs. velocidade).
• Ele recupera o layout de fragmento 8×8 "específico do dispositivo", permitindo otimizações conscientes do layout.
• Estabelece uma metodologia reprodutível e com verificação de checksum para engenharia reversa de primitivas de alto nível.

O artigo conclui que, embora o fornecedor documente a interface, o comportamento do hardware deve ser descoberto empiricamente. Os achados são totalmente reproduzíveis via código licenciado pela MIT, CSVs e scripts de regeneração, oferecendo uma base concreta para desenvolvedores que implantam modelos quantizados em Apple Silicon antes da chegada de aceleradores de tensor dedicados em gerações futuras.