Skip to content

[BugFix][Quant] Guard scale tails and FP32 absmax#15

Open
JayceSu98 wants to merge 1 commit into
deepseek-ai:mainfrom
JayceSu98:jayce/bugfix-quant-per-token-bf16-amax-fp32
Open

[BugFix][Quant] Guard scale tails and FP32 absmax#15
JayceSu98 wants to merge 1 commit into
deepseek-ai:mainfrom
JayceSu98:jayce/bugfix-quant-per-token-bf16-amax-fp32

Conversation

@JayceSu98

@JayceSu98 JayceSu98 commented May 28, 2026

Copy link
Copy Markdown

Context

This updates the existing Quant PR to cover the complete Quant-side fix from the H100 CuTeDSL full correctness and benchmark run.

The earlier version of this PR only handled the BF16 per-token FP32 amax issue. Full coverage also exposed tail-tile scale-grid and packed E5M6 store bounds issues, so this PR now keeps the Quant fixes together in one review instead of opening duplicate overlapping PRs.

Problems Found

Full H100/CuTeDSL coverage exercises quantization shapes where token counts, hidden sizes, scale blocks, and packed E5M6 groups do not always land exactly on a kernel tile boundary.

That exposed two TileKernels-side issues:

  • Tail tiles could load or store scaling factors outside the real scaling-factor grid.
  • Per-token scale generation used in_config.dtype as the absmax fragment dtype, even though that dtype describes input storage rather than the reduction accumulator.

For BF16 and narrow quantization paths, using the input storage dtype as the absmax accumulator can round or overflow the scale path before the final cast, producing byte mismatches against the PyTorch reference.

Fix

  • Guard scale loads in cast-back and per-block lossless paths with the real scale-grid dimensions.
  • Guard scale stores in per-block and per-token cast paths with the real token/channel scale extents.
  • Guard packed E5M6 output stores for token and hidden tail tiles.
  • Use T.float32 fragments for per-token absmax reductions before computing reciprocal scales.

Why this belongs in TileKernels

These are kernel-level bounds and accumulator-dtype issues. The implementation schedules aligned tile work for performance, but memory accesses and reduction precision must still follow the logical tensor/scaling-factor layout. The fix is not tied to one CuTeDSL package version.

Relationship to Existing PRs

Validation

Validated as part of the H100 PCIe CuTeDSL full correctness and benchmark run after the matching TileLang CuTeDSL fixes were applied.

Local sanity checks for the current branch:

  • git diff --check origin/main..82fbd40
  • ruff check on the changed TileKernels Python files

JayceSu98 jayce.su@enflame-tech.com authored and validated this patch.

Co-authored-by: dingsg shengge.ding@enflame-tech.com

The full H100/CuTeDSL correctness run covers token and hidden sizes that do not land exactly on the kernel tile, scaling-factor block, or E5M6 packing granularity. Those edge tiles exposed two independent quantization issues.

First, cast-back and lossless/per-token cast kernels could load or store scaling factors for padded token/channel blocks. The same edge condition also applied to packed E5M6 output rows and columns, where the final tile may not contain a full logical token row or hidden group.

Second, per-token scale generation used in_config.dtype as the absmax fragment dtype. That dtype describes the input tensor storage, not the reduction accumulator. For BF16 and narrow quantization paths, keeping absmax in the input dtype can round or overflow the scale path before the final output cast, producing byte mismatches against the PyTorch reference.

Guard scale loads/stores and packed E5M6 stores with the real token/channel extents, keep invalid scale lanes zero-initialized, and use FP32 fragments for per-token absmax reductions before computing the reciprocal scale.

Co-authored-by: dingsg <shengge.ding@enflame-tech.com>
@JayceSu98 JayceSu98 force-pushed the jayce/bugfix-quant-per-token-bf16-amax-fp32 branch from 88a6293 to 82fbd40 Compare June 12, 2026 06:43
@JayceSu98 JayceSu98 changed the title [BugFix][Quant] Accumulate per-token BF16 amax in FP32 [BugFix][Quant] Guard scale tails and FP32 absmax Jun 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant