Memory-Bound but Not Bandwidth-Limited: The Physical AI Inference Gap in Batch-1 LLM Decode

Resumo Técnico: Limitado por Memória, mas Não por Largura de Banda: O Gap da Inferência de IA Física no Decode de LLM em Batch-1

Declaração do Problema

Sistemas de IA física (robôs, veículos autônomos, copilotos de borda) operam tipicamente sob uma carga de trabalho de decode autoregressivo de fluxo único, batch-1. Ao contrário do serviço em nuvem, que otimiza para o throughput via grandes batches, a IA física aguarda o próximo token para um único usuário ou agente. A premissa predominante da indústria é que esta carga de trabalho é estritamente limitada pela largura de banda da HBM, o que significa que a latência escala inversamente com a largura de banda de pico ($B_{peak}$). Consequentemente, assume-se que a escada de implantação seja $L4 \to L40S \to A100 \to H100$, onde uma maior largura de banda resulta diretamente em menor latência e menor custo por token.

Este artigo desafia essa suposição, argumentando que, para o decode em batch-1 em silício rápido (ex: H100), o gargalo muda da largura de banda da memória para o overhead de lançamento de kernel pela CPU. Os autores postulam que uma memória mais rápida não se traduz em ganhos proporcionais de latência porque o custo fixo de lançar kernels torna-se a fração dominante do tempo de passo em GPUs de alta largura de banda, enquanto GPUs mais lentas permanecem verdadeiramente limitadas por largura de banda.

Metodologia

O estudo é um experimento de medição controlada, não um modelo teórico, conduzido em hosts de nuvem Modal utilizando quatro GPUs NVIDIA: H100 SXM5, A100-80GB SXM4, L40S e L4.

• Carga de Trabalho: Três transformers GQA de 7–8 parâmetros (Qwen-2.5-7B, Mistral-7B-v0.3, Llama-3.1-8B) com pesos bf16 e atenção SDPA.
• Escopo: 44 células válidas cobrindo 4 comprimentos de contexto (2048 a 16384) e 4 GPUs.
• Métricas:
  • $R_{floor}$: A razão entre o piso analítico de memória ($t_{floor} = (W+K)/B_{peak}$) e o tempo de passo observado ($t_{obs}$). Um valor de 1.0 indica utilização perfeita de largura de banda.
  • Teste A/B de CUDA Graphs: Um experimento de falsificação comparando a execução "eager" contra a execução "grafada" (reprodução de DAG capturada) para isolar o overhead de lançamento.
  • Matriz de Stack de Software: Comparações de backends de atenção (SDPA, FlashAttention-2/3, FlashInfer) e caminhos de quantização (bf16, bnb-nf4, AutoAWQ+Marlin, GPTQ+ExLlamaV2).

Principais Resultados

1. A Escada Invertida de Custo por Token

O estudo revela uma divergência acentuada na utilização de largura de banda:

• L4 (300 GB/s): Alcança ~81% da largura de banda de pico da HBM ($R_{floor} \approx 0.81$). A carga de trabalho é verdadeiramente limitada por memória.
• H100 (3350 GB/s): Alcança apenas ~27% da largura de banda de pico da HBM ($R_{floor} \approx 0.27$).
• Implicação: A vantagem de 11x de largura de banda da H100 sobre a L4 não gera um ganho de velocidade de 11x. Em vez disso, a H100 é retida pelo overhead de lançamento, enquanto a L4 é retida pelo tráfego de memória.

2. Teste de Falsificação de CUDA Graphs

Os autores isolaram o mecanismo removendo o overhead de lançamento da CPU via CUDA Graphs:

• Na H100 (ctx=2048): CUDA Graphs melhorou a latência em 1.259× (IC de 95% [1.253, 1.267]). Isso confirma que o overhead de lançamento representa aproximadamente 20% do tempo de passo.
• Na L4 (ctx=2048): A mesma intervenção rendeu apenas uma melhoria de 1.028×.
• Conclusão: O "imposto de lançamento" é a restrição vinculante na H100 para o decode em batch-1, enquanto a largura de banda é a restrição vinculante na L4.

3. Seleção de Kernel de Atenção

Ao contrário da crença de que variantes do FlashAttention são sempre superiores:

• Na H100 em batch-1, o despachante padrão do PyTorch SDPA (36.05 µs/camada) superou o FlashAttention-3 explícito (79.25 µs), o FlashInfer (48.20 µs) e até o contexto do FlashAttention-2 (44.35 µs).
• A restrição vinculante é a sequência de lançamentos de kernels, não o throughput do kernel de atenção em si.

4. Quantização e Implementação de Kernel na L4

Na L4, limitada por largura de banda, a quantização sozinha é insuficiente; a implementação do kernel importa:

• bf16: 62.32 ms/passo.
• bnb-nf4: 59.36 ms/passo (ganho negligível devido ao overhead de desquantização).
• AutoAWQ + Marlin: 45.24 ms/passo (ganho de 1.38×). O Marlin é ajustado para Ampere (SM80), não para Ada (SM89).
• GPTQ + ExLlamaV2: 17.36 ms/passo (ganho de 3.59×). Os kernels do ExLlamaV2 são ajustados para Ada (SM89), realizando com sucesso as economias teóricas de largura de banda.
• Resultado: Uma L4 com ExLlamaV2 (17.36 ms) é significativamente mais rápida que uma H100 com execução eager padrão (14.83 ms) e competitiva com uma H100 usando CUDA Graphs (11.78 ms), apesar de a H100 possuir 11x mais largura de banda de pico.

Significância e Alegações

O artigo afirma demonstrar que a escada de implantação padrão ($L4 \to H100$) está invertida para cargas de trabalho de IA física:

1. Dominância do Overhead de Lançamento: Em GPUs rápidas (H100) com contextos curtos, o overhead de lançamento de kernel por CPU domina o tempo de passo, tornando a largura de banda de memória de pico amplamente irrelevante.
2. Implementação de Kernel > Upgrade de Hardware: Para o decode de streaming em batch-1, otimizar a implementação do kernel (ex: usar ExLlamaV2 na L4) produz reduções de latência maiores do que atualizar para uma GPU de maior largura de banda.
3. Eficiência de Custo: Nas taxas publicadas da Modal (Maio de 2026), uma L4 com kernels otimizados serve tokens a um custo aproximadamente 6x menor do que uma H100 com CUDA Graphs, apesar da H100 possuir especificações brutas superiores.
4. Limitação de Escopo: Os autores declaram explicitamente que estes achados se aplicam a transformers GQA de 7–8B, batch-1, bf16 e decode de fluxo único. Eles não afirmam que estes resultados se generalizam para grandes batches (onde o imposto de lançamento diminui), diferentes arquiteturas (MHA/MQA) ou outro hardware (AMD, Blackwell).

O artigo conclui que para a inferência de IA física, o rótulo "limitado por memória" é incompleto; o sistema é frequentemente limitado por lançamento em silício de alto desempenho e limitado por largura de banda em silício de borda, exigindo alavancas de otimização diferentes (CUDA Graphs vs. kernels especializados) em vez de um simples caminho de upgrade de hardware.