El equipo PyTorch de Meta publicó los detalles arquitectónicos sobre In-Kernel Broadcast Optimization (IKBO), una técnica de fusión de kernel que elimina uno de los patterns silenciosamente caros en inferencia RecSys: materializar tensores de broadcast antes de las capas de interacción. En un request de recomendación típico, ~15 user embeddings se replican 70x para matchear un batch de 1024 candidatos, después se droppean inmediatamente tras la matmul. IKBO codifica la lógica de broadcast en el kernel GPU mismo — acepta batch sizes mismatched, hace index lookups dentro del kernel, nunca materializa el tensor replicado. Los números clave en H100 SXM5: 4x speedup acumulativo en el kernel de compresión lineal (1,944ms → 0,482ms), 6,4x throughput en Flash Attention end-to-end incluyendo costo de broadcasting (vs baseline CuTeDSL FA4-Hopper), y 621 BF16 TFLOPs sostenidos sobre un workload que antes estaba IO-bound a 250 TFLOPs.
El insight técnico es que el broadcast es un concern de data-layout, no una necesidad computacional, y los savings cascadean a través de cuatro etapas de co-design progresivo. Etapa 1 — matmul decomposition — corre el GEMM user-side en su batch natural de 15 filas y el GEMM candidate-side en 1024, después broadcastea solo el resultado chico, cortando el compute user-side 70x. Etapa 2 — memory alignment — pad K a múltiplos de 8 para loads TMA 128-bit alineados en Hopper, balanceando el pipeline L1/TEX de 84% saturado a balanceado y bajando la latencia GEMM de 0,984ms a 0,400ms. Etapa 3 — in-kernel broadcast fusion — pliega el broadcast-add en el epílogo del GEMM candidate vía index lookup, eliminando 0,87 GB de tráfico DRAM intermedio. Etapa 4 — warp-specialized multi-stage fusion vía TLX — particiona el CTA en producer + dos consumer warp groups que ping-pong tiles para overlappear stalls WGMMA, fusiona los GEMMs user y candidate en un único kernel persistent, y levanta el L2 throughput de 74% a 84% del peak. La historia de Flash Attention es aún más interesante: la SDPA estándar se sienta en ~60 FLOPs/Byte (IO-bound), mientras IKBO FA empuja la intensidad aritmética a ~833 FLOPs/Byte al ratio 70:1 — pasada el balance point H100 de 495 FLOPs/Byte, poniéndola firmemente compute-bound donde la warp specialization y el TMA async de Hopper sí pagan.
Lectura ecosystem: esta es una clase de optimización en la que la mayoría de ML engineers no han pensado, pero generaliza ampliamente. Cualquier workload de inferencia con dimensiones de batch mismatched — user/item, vendor/product, ranking jerárquico con broadcast multi-nivel — tiene el mismo pattern. El código vive en `pytorch/FBGEMM/tree/main/fbgemm_gpu/experimental/ikbo` (todavía no mergeado en PyTorch core), y Meta lo deployó a través del RecSys de producción incluyendo MTIA. Dos paths de adopción: los autores de modelos integran los kernels IKBO directo, o un pass de compilador ML swapea ops estándar por equivalentes IKBO en tiempo de inferencia. Para builders corriendo ranking, retrieval o recommendation a gran escala, el match de shape del workload es lo que determina si conseguís 2x, 4x o 6x; el ratio candidate-to-user escala los savings linealmente. La capa TLX (warp specialization basada en Triton) también vale trackear por sí misma — es el tipo de control de kernel de bajo nivel que ha sido difícil de conseguir sin ir a CUDA crudo, y la inversión de Meta acá sugiere que va a mergearse upstream.
Movida práctica: si corrés RecSys, ranking, o cualquier pipeline de inferencia donde una dimensión de tensor es mucho más chica que otra (pensá personalización, vendor selection, retrieval reranking), chequeá si tu kernel hot-path materializa tensores de broadcast. Si lo hace, el módulo experimental de IKBO vale un benchmark — Meta reporta hasta 2/3 de reducción de latencia neta sobre modelos co-designados, robusto a través de batch sizes 256-4096 y ratios de 10:1 a 10.000:1. El ratio 70:1 en su benchmark default es realista para ranking de ads y personalización de feed. Si estás en AMD o hardware no-Hopper, el insight arquitectónico (fold broadcast en epílogo del kernel, eliminá materialización) porta — los números específicos no, pero el pattern sí. Para ML compiler folks, el path de transformación en tiempo de inferencia es el que vigilar; si el pass de compilador de Meta va upstream, esto se vuelve gratis para el resto del ecosistema.