O modelo roofline

01 · Conceito

Conceito

Um relatório de profiling cai na sua mesa. O kernel de decode do Qwen3.8-27B atinge três décimos de um por cento da taxa de ponto flutuante de pico da GPU. A leitura óbvia é que alguém escreveu um kernel péssimo e que uma reescrita recupera duas ordens de grandeza. O modelo roofline existe para dizer a você, em uns trinta segundos e sem tocar no código, que essa leitura está quase certamente errada e que o kernel talvez já esteja perfeito.

Williams, Waterman e Patterson publicaram o modelo em 2009 justamente para tornar esse julgamento barato. Ele comprime uma máquina em dois números e um kernel em um. A máquina contribui com sua taxa aritmética de pico e sua memory bandwidth de pico. O kernel contribui com sua arithmetic intensity, as operações que realiza por byte que precisa mover da memória. O desempenho atingível é então o menor entre o que as unidades aritméticas podem entregar e o que o sistema de memória consegue alimentar:

onde $\beta$ é a bandwidth em bytes por segundo e $I$ é a intensidade em operações por byte. Plotado com a intensidade no eixo horizontal e o desempenho no vertical, ambos em escala logarítmica, isso desenha uma reta inclinada de coeficiente um que para abruptamente num teto horizontal. A dobra é o ridge point, a intensidade na qual os dois limites se igualam:

Usando os números classe H100 informados pelo fabricante na lição 9.1, aproximadamente mil teraflops densos em bf16 contra 3,35 TB/s de HBM3, o ridge point cai perto de 300 operações por byte, em agosto de 2026 e sujeito a todas as ressalvas que esses números carregam. À esquerda do ridge, o sistema de memória é a restrição. À direita, a aritmética é. Esse é o modelo inteiro, e ele basta para precificar a maioria das propostas de otimização antes de alguém escrever código.

Posicione o Qwen3.8-27B nele. O prefill de um prompt de 8.192 tokens carrega a intensidade estabelecida na lição 7.3, cerca de 8.192 operações por byte de peso, porque cada peso buscado serve todas as posições do prompt simultaneamente. Isso é aproximadamente 27 vezes além do ridge point, então o prefill corre sobre o teto plano de compute. Seu desempenho atingível é $P_{\text{pico}}$, e as perguntas honestas de engenharia ali são sobre ocupação dos tensor cores, tiling e formato numérico, porque é isso que move você ao longo de um teto contra o qual você de fato está pressionado. O time to first token responde à aritmética. Comprar FLOPs para o prefill é uma compra defensável.

O decode em batch 1 carrega intensidade perto de um. Seu desempenho atingível é, portanto,

o que, contra um teto de mil teraflops, é cerca de 0,34 por cento do pico. Então o relatório de profiling descreve um kernel sentado exatamente sobre seu roofline. Ele não é ineficiente. Ele está num teto diferente. Nada no fluxo de instruções pode ser reordenado para corrigir isso, porque as unidades aritméticas nunca foram o recurso escasso, e essa é a correção que poupa times de meses de micro-otimização de kernel que recupera percentuais de um dígito. Fazer batch de 32 sequências move o ponto para intensidade 32 e permite cerca de 107 teraflops, um ganho de aproximadamente trinta e duas vezes, ainda uma ordem de grandeza aquém do ridge, ainda no teto inclinado, e obtido inteiramente por mudar a carga de trabalho em vez do kernel.

O layout híbrido coloca dois pontos distintos no gráfico para um só modelo, o que é o que torna o Qwen3.8-27B interessante de perfilar. As 16 camadas de full attention leem um histórico de key-value que cresce a 64 KiB por token, o número derivado na lição 7.2, enquanto a aritmética que cada nova query realiza contra esse histórico cresce na mesma taxa. A intensidade delas é aproximadamente constante e baixa, mas os bytes absolutos por passo sobem, então, conforme o contexto se alonga, essas camadas consomem uma fatia crescente do tempo de passo no teto de bandwidth. As 48 camadas de Gated DeltaNet se comportam de forma diferente. Elas leem e atualizam um estado recorrente fixo de aproximadamente 3 MiB por camada, cerca de 144 MiB no total no caminho float32 de referência, não importa quão longa a conversa tenha ficado. O ponto delas não se move. Três quartos da profundidade do modelo, portanto, contribuem com um custo constante e limitado a cada passo de decode, enquanto um quarto contribui com um custo crescente — que é a barganha arquitetural reenunciada em termos de roofline.

Transformar isso de esboço em evidência exige contadores reais, não estimativas. Profilers de kernel reportam bandwidth atingida e aritmética atingida separadamente e conseguem posicionar um kernel medido sobre um roofline medido, incluindo tetos secundários para L2 e memória compartilhada. Essa distinção importa porque a intensidade estimada que você deriva no papel e a intensidade que um kernel de fato exibe divergem sempre que caching, padding ou layout de memória diferem da idealização.

O retorno é um hábito. Antes de otimizar, estime a intensidade, compare com o ridge point e deixe o gráfico dizer se você está comprando bytes ou operações. A lição 9.4 aplica esse hábito a silício específico, onde uma peça mais nova muda os dois tetos ao mesmo tempo e também a capacidade por baixo deles.