vLLM’s padding made FlashInfer’s MoE kernels crash or silently corrupt output on Blackwell RTX GPUs. My fix shipped in v0.7.1.
I added 35 regression tests. An NVIDIA maintainer tightened them, reran them and showed 23 fail without the fix. The maintainers then made the FP8 and MXFP8 backends handle padding the same way (#5977).
At decode batch sizes, FlashInfer’s fused activation kernels and its top-k and top-p samplers left most of the GPU idle. Both now split each row across several thread blocks when the batch is small (the samplers on Hopper GPUs only).
On a GH200, SiLU-and-multiply for 16 tokens went from 4.96 to 1.95 µs, and top-p sampling for one request over a 151,936-token vocabulary from 34.6 to 9.2 µs. Both times are my own measurements, posted in the pull requests.
CUB’s merge sort, merge, batched copy and run-length encoding APIs moved from a bare CUDA stream to execution environments, so callers can also pass a tuning policy. Existing calls still work.
FlashInfer also merged my test fix #5382. Its sparse MLA rework (#4802) credits me as coauthor and replaced a decode autotuner sweep that I had shown was timing cached inputs (#4683). Another contributor fixed an FP8 KV-cache bug I found and reproduced (#4984).
Still open on November 5, 2026: FlashInfer MLA decode on Hopper, 1.43–2.02x faster at batch 1 with 8 to 64 heads (#4906); FlashAttention 3 prefill with an FP8 KV cache, 1.28–1.69x faster than FlashInfer’s FlashAttention 2 path (#4977); and an approved CUB fill fix that nearly doubles throughput for 1 KiB values (#11919).