🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

Este artigo revela que o overhead de despacho do WebGPU, em vez da qualidade do kernel, é o principal gargalo para a inferência de LLM de lote único em navegadores, demonstrando que medições simples superestimam os custos devido à confluência de sincronização e concluindo que reduzir a contagem de despachos por meio de amortização é a estratégia de otimização mais eficaz.

Autores originais: Jędrzej Maczan

Publicado 2026-08-11

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Jędrzej Maczan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você esteja tentando rodar um videogame massivo e complexo em um computador, mas tem que fazer isso através de um gerente muito rigoroso e atento à segurança, que não deixa você tocar diretamente no hardware. Este é o mundo de rodar Inteligência Artificial (especificamente Grandes Modelos de Linguagem, ou LLMs) dentro de um navegador web. Esses modelos são os cérebros por trás de chatbots que podem escrever histórias, resolver matemática e manter conversas. Para fazer com que eles rodem rápido no seu laptop ou celular sem precisar de um supercomputador, os desenvolvedores usam uma ferramenta especial chamada WebGPU. Pense na WebGPU como um tradutor universal que permite ao seu navegador conversar com a sua placa de vídeo (a parte que geralmente renderiza videogames) para que ela possa realizar os cálculos pesados da IA.

No entanto, há um porém. No passado, quando os desenvolvedores tentavam tornar esses modelos de IA mais rápidos, eles focavam em tornar os passos matemáticos individuais (chamados de "kernels") mais eficientes, como polir o motor de um carro. Mas este artigo faz uma pergunta diferente: E se o carro estiver bom, mas o motorista estiver gastando tempo demais entrando e saindo do veículo? No mundo do navegador, cada passo matemático exige um "dispatch" — um pedido enviado do navegador para a placa de vídeo para começar a trabalhar. O grande mistério era: Quanto tempo é realmente desperdiçado apenas enviando esses pedidos, versus fazendo a matemática de fato? Entender isso é crucial porque, se desperdiçarmos muito tempo apenas pedindo para o computador trabalhar, o chatbot parecerá lento e travado, não importa o quão inteligente seja a matemática.

O Engarrafamento de "Pare e Siga"

O pesquisador neste artigo descobriu que todos estavam medindo a velocidade desses pedidos de IA de forma errada. Imagine que você está cronometrando quanto tempo um entregador leva para deixar um pacote. Se você cronometrar desde o momento em que ele sai do armazém, dirige até a casa, entrega o pacote e depois dirige de volta até o armazém para pegar o próximo, você está medindo a viagem de ida e volta completa. Mas no mundo real da IA, o motorista não dirige de volta ao armazém após cada pacote individual. Ele entrega uma pilha inteira de pacotes de uma só vez e só dirige de volta uma vez ao final.

O artigo mostra que as medições anteriores eram como cronometrar essa viagem de ida e volta para cada único pacote. Eles estavam confundindo o tempo que leva para enviar o pedido (o dispatch) com o tempo que leva para esperar que o computador diga "Ok, terminei" (sincronização). Esse "tempo de espera" é enorme — é uma pausa de 450 microssegundos. Quando os pesquisadores adicionaram esse tempo de espera a cada passo, eles pensaram que o custo de enviar um pedido era cerca de 20 vezes maior do que realmente era.

Ao usar um novo método chamado "sequential-dispatch", o autor descobriu como cronometrar apenas o ato de enviar o pedido, sem a longa espera entre eles. Eles descobriram que o custo real é muito menor: entre 24–36 microssegundos em alguns sistemas (Vulkan) e 32–71 microssegundos em outros (Metal). Curiosamente, esse custo é o mesmo se o computador estiver usando números "float32" ou "float16" (duas maneiras diferentes de armazenar números decimais), provando que o atraso vem das regras do navegador, não da matemática em si.

O Verdadeiro Gargalo: Muitas Paradas

Uma vez que souberam o custo real de um único pedido, a equipe perguntou: "Isso realmente importa?" Para descobrir, eles realizaram um experimento controlado. Eles pegaram um modelo de IA padrão e mudaram a forma como ele era empacotado. Em vez de enviar 876 pequenos pedidos para a placa de vídeo para processar uma palavra de texto, eles "fundiram" (colaram juntos) alguns dos passos para que a placa tivesse que receber apenas 564 pedidos.

Aqui está o ponto crucial: eles não tornaram a matemática dentro dos pedidos mais rápida. Eles não mudaram o código para ser mais inteligente ou usar menos memória. Eles apenas reduziram o número de vezes que o navegador tinha que bater na porta da placa de vídeo.

O resultado? A IA ficou 53% mais rápida. O tempo que levou para gerar a primeira palavra de uma resposta caiu de 71,4 ms para 41,6 ms.

Este experimento provou que, na configuração mais comum (processando uma palavra por vez, conhecida como "batch size 1"), o maior problema não é que a matemática é lenta demais ou que a memória está cheia. O problema é simplesmente que existem muitos "bater na porta". O autor explicitamente descartou a ideia de que um código matemático melhor ou menos uso de memória fosse o motivo do aumento de velocidade. A única coisa que mudou foi o número de dispatches.

O Que Isso Significa para o Futuro

O artigo conclui que, se quisermos que os navegadores executem chatbots de IA de forma suave, precisamos parar de tentar aperfeiçoar cada passo matemático individual e começar a focar em agrupá-los. É como perceber que, para fazer um caminhão de entrega chegar mais rápido a uma casa, você não deve apenas fazer o motorista correr mais rápido; você deve apenas garantir que ele carregue uma caixa maior para que não precise fazer tantas viagens.

O autor sugere que a solução reside na "amortização de dispatch" — uma forma sofisticada de dizer que precisamos espalhar o custo desses "bater na porta" sobre muitas tarefas, para que o atraso não prejudique tanto. Eles apontam que isso pode exigir mudanças não apenas no software que executa a IA, mas potencialmente nas próprias regras da WebGPU, talvez permitindo que o navegador aceite um "grafo de comando" (uma rota pré-planejada) em vez de verificar cada passo individualmente.

Embora essas descobertas sejam baseadas em hardware específico (como a NVIDIA RTX 5090) e uma maneira específica de rodar a IA, a mensagem é clara: por enquanto, o segredo para uma IA mais rápida no seu navegador não é um motor mais rápido; são menos paradas.

Resumo Técnico: Medindo e Reduzindo o Overhead de Dispatch de WebGPU para Inferência de LLM

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) estão sendo cada vez mais implantados em ambientes de navegador e de borda (edge) utilizando o WebGPU como um padrão multiplataforma. Enquanto a engenharia de desempenho existente para esses sistemas foca em quantização, otimização de kernel e eficiência de memória, o custo do dispatch de operações WebGPU permanece mal caracterizado.

Um problema crítico identificado é que as medições de desempenho padrão de "operação única" — cronometrando uma única operação de ponta a ponta — confundem o custo do próprio dispatch com o custo da sincronização completa entre GPU e CPU. Na decodificação autorregressiva do mundo real, a sincronização ocorre apenas uma vez por token, não uma vez por operação. Consequentemente, medições de operação única superestimam o custo por dispatch em aproximadamente 20x, obscurecendo o verdadeiro gargalo de desempenho. Além disso, permanece incerto se as limitações de throughput em batch size 1 são causadas pela qualidade do kernel (eficiência do shader) ou pelo mero número de dispatches necessários.

Metodologia

O autor introduz um método de medição de dispatch sequencial para isolar o verdadeiro custo marginal de um único dispatch.

Medição Sequencial: Em vez de cronometrar uma única operação com sincronização imediata, o método submete $N$ operações idênticas à fila e realiza uma única sincronização ao final. O tempo total é dividido por $N$ , amortizando o custo de sincronização de uma única vez e revelando o verdadeiro overhead de dispatch.
Experimento de Fusão Controlada: Para determinar o impacto da contagem de dispatch versus a qualidade do kernel, o autor conduziu um experimento de fusão de kernel. Eles fundiram grupos de operações para reduzir a contagem de dispatch por passagem forward de 876 para 564. Crucialmente, os shaders WGSL subjacentes (lógica de computação) permaneceram inalterados, e a redução no tráfego de memória intermediária foi insignificante (<1,8 MB, <1 µs). Esta configuração isola a contagem de dispatch como a única variável.
Implementação: As medições foram realizadas usando o torch-webgpu, um backend customizado do PyTorch, através de múltiplos fornecedores de hardware (NVIDIA, AMD, Apple, Intel) e backends (Vulkan, Metal, Dawn, wgpu).

Resultados Principais

1. Custo Real por Dispatch

Usando o método sequencial, o autor mediu o custo real por dispatch, descobrindo que ele é independente do tipo de dado (float32 vs. float16):

Vulkan: 24–36 µs por dispatch.
Metal: 32–71 µs por dispatch.
Superestimação: Medições de operação única superestimam esses custos em ~20x (por exemplo, medindo ~497 µs no Dawn, onde ~450 µs são atribuídos à sincronização).

2. Contagem de Dispatch como o Gargalo

O experimento de fusão controlada demonstrou que reduzir a contagem de dispatch melhora significamente o throughput sem alterar a qualidade do kernel:

Reduzir os dispatches de 876 para 564 resultou em um aumento de 53% no throughput (tokens por segundo).
O Tempo para o Primeiro Token (TTFT) caiu de 71,4 ms para 41,6 ms.
Como a computação e o tráfego de memória foram mantidos constantes, o autor conclui que a contagem de dispatch, e não a qualidade do kernel, é o principal gargalo para a inferência de LLM em batch size 1.

3. Decomposição de Overhead

A análise dos componentes de overhead de dispatch revelou que a submissão do command buffer é o fator dominante:

Submit: ~12,9 µs (40% do tempo total de CPU).
Encoder Create/Finish: ~12,5 µs combinados (39%).
Configuração de Pipeline/Bind Group: <1,5 µs cada.
Isso indica que o principal gargalo reside no overhead da API ao submeter comandos, e não na configuração de pipelines ou vinculação de recursos.

Significância e Alegações

O artigo afirma preencher uma lacuna na engenharia de desempenho de WebGPU ao caracterizar o overhead de dispatch, um fator anteriormente deixado como "trabalho futuro" em estudos de estado da arte como o LlamaWeb.

Estratégia de Otimização: Para inferência em batch size 1 no WebGPU, a estratégia de otimização eficaz é reduzir a contagem de dispatch (via fusão ou amortização) em vez de otimizar kernels individuais.
Implicações da Especificação: O autor sugere que ganhos de desempenho mais profundos podem exigir mudanças na própria especificação do WebGPU. Eles propõem mecanismos de amortização de dispatch análogos aos CUDA Graphs (captura e replay de grafo de comando) para evitar a revalidação e re-submissão de cada operação, embora reconheçam que isso deve ser ponderado contra os modelos de segurança do navegador que exigem validação por operação.
Limitações de Escopo: O autor nota modestamente que seus resultados de fusão causal são específicos para a plataforma testada (RTX 5090, Dawn, Vulkan) e batch size 1. Eles não alegam que esses resultados sejam universais para todos os batch sizes, observando que a computação de kernel começa a dominar em batch sizes maiores.

Em conclusão, o trabalho estabelece que benchmarks de operação única são enganosos devido à confusão de sincronização e identifica a redução da contagem de dispatch como o caminho crítico para uma inferência prática e de alto desempenho baseada em navegador.