Skip to content

feat(sm100): add FP8 activation support - #73

Draft
mgoin wants to merge 1 commit into
mainfrom
mgoin/sm100-a8-support
Draft

feat(sm100): add FP8 activation support#73
mgoin wants to merge 1 commit into
mainfrom
mgoin/sm100-a8-support

Conversation

@mgoin

@mgoin mgoin commented Sep 6, 2026

Copy link
Copy Markdown
Collaborator

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 4dc0f5d snapshot. 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:

# From the Humming checkout, using the existing managed environment.
CUDA_VISIBLE_DEVICES=0 PYTHONPATH="$PWD" /home/mgoin/code/vllm/.venv/bin/python -m pytest tests/kernels/humming/test_umma.py -q
CUDA_VISIBLE_DEVICES=0 PYTHONPATH="$PWD" /home/mgoin/code/vllm/.venv/bin/python -m pytest tests/process_input/test_transform.py -k precise_activation -q

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 --check passed.

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.

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>
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