feat(sm100): add FP8 activation support - #73
Draft
mgoin wants to merge 1 commit into
Draft
Conversation
Extend UMMA to FP8 and add native block-scaled MXFP4 x MXFP8 execution using the existing weight packing and GEMM layouts. Keep packed input-scale strides consistent for indexed rows and logical K tails. Expose the existing precise-math policy for fused input processing needed by the vLLM MXFP8 activation path. Co-authored-by: Codex <codex@openai.com> Signed-off-by: mgoin <mgoin64@gmail.com>
This was referenced Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds SM100-family FP8 activations to the existing UMMA path and native group-32 E8M0 MXFP4 × MXFP8 / MXFP8 × MXFP8 execution, with BF16 outputs. Dense, indexed, grouped-contiguous and grouped-masked GEMMs reuse the existing weight packing, routing and output handling.
The native path keeps activations in shared memory and stages canonical weight fragments and block scales into TMEM. Input scale normalization and indexed gathers use the physical packed row stride, including logical K tails such as GPT-OSS K2880 padded to K2944. Existing BF16 and ordinary FP8 automatic dispatch remain unchanged; the native MXFP8 contract uses BM64/BM128 with a bounded initial schedule. This is functional support, not a broad configuration-tuning sweep.
The existing input processor also gains an optional precise-math setting, including its cache keys. The vLLM companion needs this to preserve CUDA activation rounding when fusing activation and MXFP8 quantization; other callers retain the current default.
17 files, +465/-25. Publication tree is identical to the validated
4dc0f5dsnapshot. Output staging #74 is a separate follow-up; A4 #75 has overlapping shared implementation that must be reconciled before both support PRs merge. Open Humming PRs were checked: the current tuning PRs target SM90 and do not duplicate this support.Validation on NVIDIA B300 (SM103), PyTorch 2.13.0+cu130, CUDA 13.0; the generated target is sm_100f, requiring CUDA >=12.9:
The implementation campaign passed 177 BF16/plain-FP8 cases, 17 native-format/layout cases, five shared indexed-loader cases and the public input-scale tests. The subsequent scale-tail correction passed 40 strict cases and 24 tensor-operation memchecks. The precise-math/cache regression passes. These counts describe the separate recorded runs, not one final full-suite invocation. Changed Python Ruff checks and
git diff --checkpassed.With the vLLM companion, actual GPT-OSS-20B MXFP4 weights run under TP2 with BF16 model dtype and group-32 MXFP8 activations. Full 1,319-question GSM8K, zero-shot/low reasoning/temperature 0: corrected A8 baseline scored 1221/1319 with the existing helper, or 1239/1319 with the common signed-decimal extraction audit; every response stopped normally. The numeric extractor has documented limitations, so this is a descriptive quality check, not an accuracy-equivalence claim. No DeepSeek/Kimi model weights or A4 model evaluation were used.
AI assistance: implementation, review and validation used OpenAI Codex, including GPT-6 Astra. Kept as a draft for maintainer review and integration with the companion changes.