Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Vendor-neutral reference: NVFP4 vs OCP MXFP4 block-structure parameters (request for confirmation)

Aperta
  • Qualcosa non va?
#3,105 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python, pytorch
Ambito
documentation, machine-learning, performance

Direzione di ricerca

Inizia esaminando l’implementazione TransformerEngine NVFP4 e tutti gli unit test che coprono il packing FP4, le scale, la saturazione e i round trip, quindi confrontali con il NVIDIA developer blog collegato. L’issue è completata quando i maintainer confermano o correggono la dimensione del blocco, la codifica delle scale, l’endianness, i vettori di riferimento e il comportamento fuori intervallo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

question

Hi TransformerEngine maintainers,

I am compiling a vendor-neutral numeric format catalog (84 formats, 13
families) with bit-exact conformance vectors. The catalog is open and
lives at https://github.com/gHashTag/t27. NVFP4 is on the near-term
roadmap (Track 2) but I would like to ground its row entry in
parameters confirmed by the upstream implementer rather than guessed
from blog posts. This issue is an information request, not a bug
report.

What I have so far

Based on the public NVIDIA developer blog
(https://developer.nvidia.com/blog/introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/)
and code references in TransformerEngine, I have populated the
following parameter table for NVFP4 alongside its closest OCP MX
counterpart (MXFP4):

Parameter OCP MX MXFP4 NVIDIA NVFP4
Element layout S1E2M1 (4 bits) S1E2M1 (4 bits)
Block size 32 elements 16 elements
Scale format E8M0 (8-bit) FP8 E4M3 (8-bit)
Scale exponent bits 8 (pure exponent) 4
Scale mantissa bits 0 3
Scale dynamic range 2^-127 to 2^127 ~2^-9 to 448
Scale granularity per decade 1 (power-of-two) 8 (3-bit mantissa)
Bits/element including scale 4 + 8/32 = 4.25 4 + 8/16 = 4.50

The element layout S1E2M1 is bit-identical between the two formats;
they diverge at the block-and-scale level. Three structural
consequences follow:

  1. NVFP4 resolves intra-block dynamic range 8x more finely than MXFP4
    within its representable range (3-bit mantissa on FP8 E4M3 scale).
  2. NVFP4 cannot represent per-block scales outside FP8 E4M3 range
    (saturates at 448, underflows below ~2^-9) without higher-level
    rescaling; MXFP4 spans a much wider scale range via E8M0.
  3. Effective bits per element differ: 4.25 (MXFP4) vs 4.50 (NVFP4),
    a 5.9% overhead delta in NVFP4 that any compression-ratio
    comparison should account for.

Specific requests

If a maintainer could confirm or correct any of the following, that
would close out the row and let me publish a sister conformance pack
to the existing MXFP4 pack:

(a) Block size confirmation. Is 16 elements per block the only
supported block size, or is it a default with alternatives?

(b) Scale format confirmation. Is FP8 E4M3 (with the standard
fn saturation flag, no infinities) the canonical scale
encoding? Are there variants that use FP8 E5M2 instead?

(c) Encoding endianness. When 16 four-bit elements are packed
into 64 bits, are the first element bits in the most-significant
or least-significant nibble?

(d) Reference vectors. Does TransformerEngine ship any unit
tests with documented input/output bit-patterns that I can use
as ground-truth boundary vectors (NaN, +/-Inf-equivalent
saturation, smallest normal, smallest subnormal, denormal-block
behavior)?

(e) Round-trip behavior on out-of-range scale. When a tensor's
natural per-block scale would land outside the FP8 E4M3
representable range, is the recommended behavior (i) clamp the
scale and saturate the elements, (ii) error out, or (iii)
something else?

What I will do with confirmed answers

Open a small PR (catalog row + conformance pack) on
gHashTag/t27, with full attribution to this issue and a
cross-link back to the relevant TransformerEngine references. The
pack will follow the same shared row schema as the existing six
packs (GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, E8M0 block
scale), with honest abs_error reporting (no overflow-to-Inf
masked as a match).

Background and methodology are documented in a 16-page methodology
paper (Trinity S^3 AI, 2026-06-08, file
paper3-methodology-2026-06-08-v3-trinity.pdf, SHA-256
f31f5dd243afc7b2ba4a423859a1e1dc67036c3a93affab30acc8d02f0a15eef)
that I plan to upload to arXiv this week.

Async only -- no rush, no specific deadline. If the relevant
maintainer is on vacation or sprint-locked, a one-line "ping us back
in N weeks" is a fine answer.

Thank you for the open release of NVFP4 documentation and for the
maintained NVFP4 reference implementation in TransformerEngine.

-- Dmitrii Vasilev
Trinity S^3 AI
[email protected]
GitHub: @gHashTag

Lingua principale
Python
Stelle
3.6k
Fork
851
Merge medio
4g 15h
PR unite (30g)
54

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NVIDIA/TransformerEngine

Tutte le issue di NVIDIA/TransformerEngine

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.