Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#3,105 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
ドキュメント
明瞭さ
説明が足りない
活発さ
静か
技術スタック
python, pytorch
領域
documentation, machine-learning, performance

調査の方向性

まず TransformerEngine NVFP4 の実装と、FP4 のパッキング、スケール、飽和、ラウンドトリップを対象とするすべてのユニットテストを確認し、次にリンクされた NVIDIA developer blog と比較します。maintainer がブロックサイズ、スケールエンコーディング、エンディアン、リファレンスベクトル、範囲外の動作を確認または修正した時点で、この issue は完了です。

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Python
スター
3.6k
フォーク
851
平均マージ
5日 1時間
マージ済み PR（30日）
52

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA/TransformerEngine のほかの issue

NVIDIA/TransformerEngine の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。