Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#3,105 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
python, pytorch
Área
documentation, machine-learning, performance

Línea de trabajo

Comienza revisando la implementación de TransformerEngine NVFP4 y cualquier prueba unitaria que cubra el empaquetado de FP4, las escalas, la saturación y los round trips; después, compáralos con el NVIDIA developer blog enlazado. El issue estará terminado cuando los maintainers confirmen o corrijan el tamaño de bloque, la codificación de escalas, el endianness, los vectores de referencia y el comportamiento fuera de rango.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
3.6k
Forks
851
Merge medio
4 d 20 h
PR fusionados (30 d)
56

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NVIDIA/TransformerEngine

Todos los issues de NVIDIA/TransformerEngine

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.