O time PyTorch da Meta publicou os detalhes arquiteturais sobre In-Kernel Broadcast Optimization (IKBO), uma técnica de fusão de kernel que elimina um dos patterns silenciosamente caros na inferência RecSys: materializar tensores de broadcast antes das camadas de interação. Numa request de recomendação típica, ~15 user embeddings são replicados 70x para combinar um batch de 1024 candidatos, depois droppados imediatamente após a matmul. IKBO codifica a lógica de broadcast no próprio kernel GPU — aceita batch sizes mismatched, faz index lookups dentro do kernel, nunca materializa o tensor replicado. Os números chave no H100 SXM5: 4x speedup cumulativo no kernel de compressão linear (1,944ms → 0,482ms), 6,4x throughput em Flash Attention end-to-end incluindo custo de broadcasting (vs baseline CuTeDSL FA4-Hopper), e 621 BF16 TFLOPs sustentados num workload que antes estava IO-bound a 250 TFLOPs.
O insight técnico é que broadcast é um concern de data-layout, não uma necessidade computacional, e os savings cascateiam por quatro estágios de co-design progressivo. Estágio 1 — matmul decomposition — roda o GEMM user-side no seu batch natural de 15 linhas e o GEMM candidate-side em 1024, depois broadcasta só o resultado pequeno, cortando compute user-side 70x. Estágio 2 — memory alignment — pad K para múltiplos de 8 para loads TMA 128-bit alinhados no Hopper, balanceando o pipeline L1/TEX de 84% saturado para balanceado e baixando a latência GEMM de 0,984ms para 0,400ms. Estágio 3 — in-kernel broadcast fusion — dobra o broadcast-add no epílogo do GEMM candidate via index lookup, eliminando 0,87 GB de tráfego DRAM intermediário. Estágio 4 — warp-specialized multi-stage fusion via TLX — particiona o CTA em producer + dois consumer warp groups que ping-pongam tiles para sobrepor stalls WGMMA, funde os GEMMs user e candidate num único kernel persistent, e levanta o L2 throughput de 74% para 84% do peak. A história Flash Attention é ainda mais interessante: a SDPA padrão fica em ~60 FLOPs/Byte (IO-bound), enquanto IKBO FA empurra a intensidade aritmética para ~833 FLOPs/Byte na razão 70:1 — passado o balance point H100 de 495 FLOPs/Byte, colocando-a firmemente compute-bound onde a warp specialization e o TMA async do Hopper realmente pagam.
Leitura ecossistema: essa é uma classe de otimização em que a maioria dos ML engineers não tem pensado, mas generaliza amplamente. Qualquer workload de inferência com dimensões de batch mismatched — user/item, vendor/product, ranking hierárquico com broadcast multi-nível — tem o mesmo pattern. O código vive em `pytorch/FBGEMM/tree/main/fbgemm_gpu/experimental/ikbo` (ainda não mergeado no PyTorch core), e a Meta deployou através do RecSys de produção incluindo MTIA. Dois paths de adoção: autores de modelos integram os kernels IKBO direto, ou um pass de compilador ML troca ops padrão por equivalentes IKBO em tempo de inferência. Para builders rodando ranking, retrieval ou recommendation em larga escala, o match de shape do workload é o que determina se você consegue 2x, 4x ou 6x; a razão candidate-to-user escala os savings linearmente. A camada TLX (warp specialization baseada em Triton) também vale rastrear por si — é o tipo de controle de kernel de baixo nível que tem sido difícil de conseguir sem ir pro CUDA cru, e o investimento da Meta aqui sugere que vai ser mergeado upstream.
Movimento prático: se você roda RecSys, ranking, ou qualquer pipeline de inferência onde uma dimensão de tensor é muito menor que outra (pense personalização, vendor selection, retrieval reranking), cheque se seu kernel hot-path materializa tensores de broadcast. Se sim, o módulo experimental do IKBO vale um benchmark — a Meta reporta até 2/3 de redução de latência líquida em modelos co-designados, robusto através de batch sizes 256-4096 e razões de 10:1 a 10.000:1. A razão 70:1 no benchmark default é realista para ranking de ads e personalização de feed. Se está em AMD ou hardware não-Hopper, o insight arquitetural (dobrar broadcast no epílogo do kernel, eliminar materialização) porta — os números específicos não, mas o pattern sim. Para ML compiler folks, o path de transformação em tempo de inferência é o que vigiar; se o pass de compilador da Meta for upstream, isso vira grátis para o resto do ecossistema.