FP8 dense: per-tensor activation scale couples the sequences in a batch #94

layers/fp8_dynamic.py quantizes a dynamic FP8 linear's activations with one per-tensor amax over the whole [T, K] batch (quant_per_tensor, called at line 126). The FP8 LM head does the same over [num_reqs, hidden]. So each sequence's FP8 grid, and its outputs, depend on the other sequences prefilled or decoded in the same batch.

Evidence (offline engine, production flags, two ~60-token prompts as one varlen prefill): with the total row count held fixed, so GEMM kernel selection cannot change, prompt 0's rows first depend on the partner prompt's content at L04 gdn.out_proj. Per-row FP8 removes that dependence. The file is the same on c23d2d5 and on the r7 rebuild, so this is not new.

This is secondary to a larger, accepted effect: cuBLAS bf16 kernels picked by total M change narrow GEMM rows (first divergence L00 attn_mix, 1 ulp), and over 48 layers that grows to 0.4-1.7 nats on top-5 logprobs between a batched and a single prefill. The top-1 token did not flip in the cases measured.

Test and candidate fix on branch 5080/r7-batchfix:

• 4519efb test(fp8): pin a dynamic fp8 linear row against the other rows of its batch (fails before, passes after)
• dc17c4f fix(fp8): scale dynamic fp8 activations per row so batched sequences stay independent: per-row Triton quant, unit-scale _scaled_mm, then a row-scale multiply; M=1 keeps the old path. Eager cost +0-6 us at M=2 and about +44% at M=4096 for 2560->16384.

Not merged: it changes numerics for every multi-row FP8 prefill and bs=2 decode, so it needs an NLL A/B (nll_eval.py) and a decode tok/s A/B first.