The latest commit in flashinfer-ai/flashinfer (2026-11-08) is a corrective change that fixes three boundary-check defects in the `cake_gqa_nondet_train` path of FlashInfer, a kernel library for LLM serving. This path is Cake's variable-length causal GQA training attention built for head dimension 256, which handles sequences of differing lengths together as one batch. This change is a correctness fix that does not alter the kernel or the execution plan.
All three fixes concern validation of input boundaries. The backward checks that the host-side sequence boundary lists `cu_seqlens_q_host` and `cu_seqlens_k_host` are either both provided or both absent, and that they match the operand sizes — and it does so before the memory allocation and the early return for the case where there is no query or key. The device tile counter is an int32, so its value wraps around once it exceeds 2^31 tiles; the range check rebuilds the boundary table as int64 in that case to filter out invalid ranges. Finally, `host_boundaries` now defaults to `None`, and backward returns one gradient per forward argument, so that `apply` calls with nine arguments keep working. On the test side, 130 lines were added that exercise the checks against a wrapped-around int32 tile table in a child process.
There is no performance change. Comparing 9 shapes × 3 operations (forward, backward, step) on GB200, GB300 and R200 under the same mode as FlashInfer main, every row fell within the A/A noise band (GB200 ±0.69%–±3.34%, GB300 ±0.12%–±1.19%, R200 ±0.27%–±9.94%), which is the intended outcome for a correctness fix.
That said, the evidence reaches only a narrow range. The int64 path never triggered in any of the measured shapes, and the behavior of shapes that can grow to 2^31 tiles was not confirmed by measurement. In the 8 small-call layouts as well, two GB300 forward rows (`tails_small` 0.950x, `tile_edges` 0.980x) fell outside the ±3.21%, ±0.91% band, but since the change does not touch the forward code, this is reported as measurement noise for calls of 14~31 us. For reference, the step was 0.992x–1.039x versus the deterministic Cake package (`cake_gqa_det_train`, PR #9121), and 1.050x–1.262x versus the fastest same-precision non-Cake implementation for each row. In other words, this commit is closer to a safety mechanism that filters out invalid ranges than to a speed contest.