DGEMM with Ozaki Scheme I/II on FP4 Tensor Cores: A Base-13 E2M1 Limb Representation

Daichi Mukunoki; Shun-ichiro Hayashi; Takahiro Katagiri; Tetsuya Hoshino

REVIEW 3 major objections 5 minor 1 cited by

DGEMM with Ozaki Scheme I/II on FP4 Tensor Cores: A Base-13 E2M1 Limb Representation

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read FP4 tensor cores, via a base-13 limb representation of integers, can compute FP64-class matrix products exactly, with an FP4 Ozaki-scheme II implementation that outperforms the FP8 baseline on Blackwell hardware.

desk verdict The base-13 limb representation is a genuinely new and correct idea that makes FP4 tensor cores usable for DGEMM emulation; the measurement story is plausible but the headline performance edge is thinner than the paper's framing suggests. read the letter →

arxiv 2608.06812 v1 pith:O6VHDCXF submitted 2026-08-07 cs.DC

Shun-ichiro Hayashi , Daichi Mukunoki , Tetsuya Hoshino , Takahiro Katagiri This is my paper · ORCID

classification cs.DC

keywords matrixmultiplicationDGEMMemulationmixedprecisionOzakischemeFP4TensorCoresGPUbase-13limbrepresentation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper establishes that FP4 (E2M1) Tensor Cores—the fastest but lowest-precision matrix units on current GPUs—can perform exact integer matrix multiplication and, on top of it, emulate FP64 matrix multiplication (DGEMM) without introducing any error of their own. The enabling observation is that every FP4 value doubled is one of the integers in $S=\{0,\pm1,\pm2,\pm3,\pm4,\pm6,\pm8,\pm12\}$, and that this set shifted by multiples of 13 covers all integers, so any integer can be written in base 13 with FP4-representable digits called limbs. Using this representation, the paper builds both Ozaki schemes I and II on FP4 Tensor Cores, answering the earlier objection that FP4's single mantissa bit makes intermediate sums unusable. On a Blackwell-generation GPU, the FP4 version of Ozaki scheme II matches the accuracy of an existing FP8-based implementation while running 1.10–1.19 times faster in the compute stage and, at problem size $16384^3$, faster end to end; the result is exact with respect to the integer-converted inputs.

What carries the argument

The load-bearing object is the base-13 FP4 limb representation. Every E2M1 value, doubled, is one of $S=\{0,\pm1,\pm2,\pm3,\pm4,\pm6,\pm8,\pm12\}$; Lemma 1 shows that $S$ shifted by multiples of 13 covers all integers, so an arbitrary integer can be written as $N=\sum 13^i c_i$ with greedy representatives $|c_i|\le 8$. The representation turns arbitrary integers into sequences of FP4-representable coefficients before any GEMM; the FP4 MMA multiplies stored halves, so each partial product contributes $c_i c_j/4$, and a $\times2^2$ correction together with the base-13 weights reconstructs the integer product exactly. The same device supplies the exactness bounds (Lemmas 2 and 3) by keeping every intermediate sum inside the FP32 accumulator's exact-integer range, with the Ozaki scheme II cross-term accumulation giving the tightest limit $K\le 58{,}254$.

What would settle it

Run a microbenchmark on the same GPU architecture: choose limb vectors whose squared values sum to exactly $2^{24}+1$ with inner-product length below 58,254, execute the FP4 MMA, and compare every output element to a reference arbitrary-precision integer computation; if any element is off by one or more, the FP32 accumulator rounds inside the claimed exact range, falsifying the exactness premise. A simpler variant is to check whether the accumulator preserves the exact sum of integers up to $2^{24}$ at all.

Watch

Extended reading notes

Core claim

The central discovery is that the sparse 16-value set of E2M1 FP4, which cannot represent integers directly, becomes the integer set $S=\{0,\pm1,\pm2,\pm3,\pm4,\pm6,\pm8,\pm12\}$ when every value is doubled, and that this set, shifted by all multiples of 13, covers every integer. From this the paper constructs a positional base-13 limb representation: any integer $N$ decomposes as $N=\sum_{i=0}^{p-1} 13^i c_i$ with $c_i\in S$, each limb stored as the E2M1 value $c_i/2$. Because the greedy conversion keeps $|c_i|\le 8$, limb products are at most 64, so inner products over lengths up to 116,508 (Ozaki scheme I) or 58,254 (Ozaki scheme II, cross-term bound) stay inside the integer-exact range of the FP32 accumulator; the FP4 Tensor Core GEMM therefore performs an exact integer GEMM. On this base the paper constructs both Ozaki schemes, with the FP4 version of scheme II using 19 carefully chosen two-limb moduli ($169,115,113,\ldots,53$) whose product exceeds $2^{123}$, requiring 75 FP4 GEMMs and an exact single-pass CRT reconstruction in integer arithmetic. On a Blackwell-generation GPU, this implementation is 1.10–1.19 times faster in the compute stage than the existing FP8-based Ozaki scheme II implementation, and end to end it is faster at $16384^3$; the paper attributes the gap to a theoretical factor of 1.04 from FP4's 2:1 throughput advantage versus the 75/39 GEMM-count ratio, multiplied by a higher attained fraction of peak performance from kernel fusion.

Load-bearing premise

The bit-exactness claims rest on the assumption that the FP4 Tensor Core hardware multiplies the stored FP4 values exactly and accumulates the weighted sums in FP32 registers without any rounding for inner-product lengths up to 58,254 (and up to 116,508 for Ozaki scheme I); if the microarchitecture rounds anywhere inside that range, the exactness proofs no longer apply.

Editorial extensions

If this is right

INT8 Tensor Core integer GEMM can be reproduced bit-exactly on FP4 Tensor Cores alone, using three limbs per operand and nine FP4 GEMMs.
Both Ozaki scheme I and scheme II admit FP4 versions; the scheme II version needs 19 moduli and 75 FP4 GEMMs for the FP64 mantissa, with exact reconstruction by an integer direct CRT.
On hardware with FP4 at twice the throughput of FP8, the FP4 Ozaki scheme II has a theoretical compute-stage advantage of 1.04x over the FP8 version, independent of implementation tuning.
Measured on a Blackwell-generation GPU, the FP4 implementation is 1.10–1.19x faster than the FP8 baseline in the compute stage across all tested sizes and is faster end to end at $16384^3$, while the output is exact relative to the integer-converted inputs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The representation scheme is not tied to E2M1's particular value list; any low-precision format whose value set is an affine image of a small integer set could get an analogous exact limb decomposition with a different base, so the idea may transfer to future formats.
If future GPUs push the FP4-to-FP8 throughput ratio beyond the break-even value of about 1.9 derived here, the theoretical advantage of FP4-based Ozaki scheme II over FP8 would widen, making this kind of emulation an increasingly attractive substitute on hardware that cuts FP64 and INT8 units.
A direct test of the FP32 accumulator's exact-integer range on shipped hardware, independent of the paper's setup, would settle whether the bit-exact claims hold beyond the one GPU generation measured here.
The bit-exact emulation of integer GEMM with nine FP4 GEMMs suggests FP4 Tensor Cores could also substitute for missing INT8 units on accelerators that only provide FP4/FP8 paths, apart from FP64 emulation.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The base-13 limb representation is the real contribution here. It is a clean idea, proved carefully, and it removes the specific reason prior Ozaki-scheme work rejected FP4: intermediate sums no longer need to live in FP4. The bit-exact INT8 GEMM emulation is a nice bonus. I checked the counting and the exactness bounds in Sections III-V; Lemma 3's four conditions are correctly stated and the 3.6x margin over the tested inner-product length is comfortable. The mathematical core holds up.

The implementation work is also substantial. Epilogue fusion for the 19-moduli residue GEMMs, fused limb decomposition, and exact single-pass CRT in integer arithmetic are all sensible and well explained. The runtime model is honest: it separates the theoretical 1.04 advantage (from FP4:FP8 throughput ratio and GEMM counts) from the 1.06-1.14 attained-peak gap, and the measurements track the model well.

The soft spot is the performance headline, not the math. The end-to-end advantage at 16384 is 4% (0.96x time) against GEMMul8-FP8, which the paper itself says is used unmodified and untuned for this single GPU. Attained fraction of peak is exactly the quantity most sensitive to baseline maturity, so a tuned FP8 baseline could close or reverse that edge. Twelve runs with no variance on one GPU is also thin evidence for a 4% difference. That said, the authors do not oversell: they report the compute-stage advantage of 1.10-1.19x separately, explain the decomposition, and provide source code. The accuracy evaluation is more solid, with bit-for-bit agreement between OzI-FP4 and OzII-FP4 and single-rounding accuracy at phi=0.

The only assumption I would want flagged more prominently is that FP32 accumulate on these tensor cores is exact over the stated integer range. That is standard for this line of work, and the paper gives a range with margin, but it is not independently verified on this specific hardware. Minor, not disqualifying.

Who is this for? Numerical library developers and researchers working on low-precision tensor core emulation. It deserves a serious referee rather than a desk reject. I would send it out with a request for a tuned baseline and variance reporting, but the central idea is publishable and likely to be built on.

Referee Report

3 major / 5 minor

Summary. The paper proposes using FP4 (E2M1) Tensor Cores to emulate FP64 DGEMM through Ozaki schemes I and II. Its core idea is a base-13 limb representation: every E2M1 value doubled is an integer in S={0,±1,±2,±3,±4,±6,±8,±12}, and S covers all residue classes modulo 13, so arbitrary integers can be decomposed into FP4-representable limbs. The authors prove exactness conditions for FP32 accumulation, design a set of 19 moduli for Ozaki scheme II, implement OzI-FP4 and OzII-FP4 as fused Triton kernels, and evaluate on an RTX PRO 6000 Blackwell against GEMMul8-FP8/INT8 and cuBLAS DGEMM. The central claims are that FP4 Tensor Cores can bit-exactly emulate INT8 integer GEMM, that OzII-FP4 has a theoretical 1.04x advantage over an FP8 counterpart when FP4 throughput is twice FP8 throughput, and that the implementation achieves 1.10-1.19x compute-stage speedup and a 0.96x end-to-end time at N=16384^3 relative to GEMMul8-FP8.

Significance. This is a timely and genuinely novel contribution to low-precision emulation of high-precision arithmetic. The base-13 limb representation is elegant, the mathematical lemmas are stated with explicit bounds, the public code is a concrete strength, and the runtime model transparently separates a theoretical throughput factor from an attained-fraction factor. If the performance and exactness claims hold, the paper opens FP4 Tensor Cores to scientific-computing workloads that currently rely on shrinking FP64 units. The main risks are experimental robustness (a single GPU, an untuned baseline, no variance reporting) and an unverified microarchitectural assumption about exact FP32 accumulation in FP4 MMA; these do not undermine the mathematical construction but do affect the headline claims as stated.

major comments (3)

[§VII-B/C, Table I] The headline end-to-end advantage at 16384^3 is reported as a median of 12 runs, with no variance or confidence interval, and the comparison baseline GEMMul8-FP8 is explicitly described in §VII-C as 'used as distributed, targeting multiple GPUs, without tuning to this GPU.' Since the compute-stage advantage is 1.10-1.19x and the model attributes most of it to a gap in attained fraction of peak performance (61-65% vs 53-61%), the 0.96x end-to-end time at the largest size is fragile. Please report the run-to-run spread (e.g., min-max or standard deviation), test statistical significance, and either tune the FP8 baseline for this GPU or justify why the distributed default is the appropriate comparison. Without this, the claim of 'actually exceeding it' is not yet supported.
[§III Lemma 2, §V Lemma 3] The bit-exactness claims rely on the FP4 MMA instruction performing exact FP32 accumulation with round-to-nearest for values that are exactly representable within the stated ranges. This is an undocumented microarchitectural property; the paper cites the FP32 integer exactness range but does not independently verify the behavior of the FP4 Tensor Core accumulator. Please add a microbenchmark that compares an OzII-FP4 or the INT8-emulation result against a CPU integer GEMM for random inputs at K near the stated bounds (e.g., K=50,000), or cite an authoritative hardware specification. If the accumulator instead truncates or uses an extended internal format, the exactness argument may need revision.
[§VII-A, Fig. 6, Conclusion] The accuracy evaluation shows that the proposed method is at most 0.9 bit better than GEMMul8-FP8 at small exponent spreads (φ≤4) but up to 1.5 bits worse at φ≥8, with a steeper degradation (5.9 bits from φ=0 to φ=32 versus 3.5 bits for the FP8 version). The conclusion's statement that the method 'kept accuracy at or above the DGEMM level' therefore needs qualification: this holds for modest dynamic ranges within a row, but for wide exponent spreads the effective accuracy is below the FP8-based Ozaki implementation and below ideal FP64 rounding. Please state this limitation explicitly in the abstract or conclusion, or provide evidence that the test distribution is representative of target workloads.

minor comments (5)

[§III, Lemma 1] The proof of the gap-free range is only sketched as 'by induction'; please include the induction step explicitly or refer to an appendix, since the bound X_p=(13^p-1)/3 is used in the limb-count arguments.
[§V-A] The exhaustive verification producing the exceptional two-limb moduli {115,117,143,169} is not described; please state the search method or provide the checking code, so readers can reproduce the modulus list.
[§VII-A, Fig. 6] Please clarify whether the maximum error is taken over one 128x128 output tile or over multiple random matrices, and specify the number of trials and random seed; this affects the interpretation of the smooth degradation curves.
[§VII-C, Eq. (4)] The model's memory-bound term D/β would benefit from an explicit definition of D for each method, since the preprocessing bytes moved are central to the end-to-end comparison.
[Abstract] The abstract contains '163843' where a superscript is intended; this should be typeset as 16384^3.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the base-13 construction, exactness bounds, and theoretical 1.04x advantage are derived independently of the measured speedup.

full rationale

The paper's derivation chain is self-contained. Lemma 1 proves the base-13 limb representation directly; Lemma 2 and Lemma 3 derive the exactness conditions from the 24-bit FP32 integer range, the INT32 residue-composition bound, and the CRT unique-reconstruction inequality, none of which assume the target result. The theoretical advantage factor 1.04 is computed from the nominal FP4:FP8 throughput ratio (2) and the mathematically required GEMM counts (75 vs 39), with no fitted parameters. The measured compute-stage advantage 1.10-1.19 is then decomposed into that nominal factor and a measured attained-fraction ratio (1.06-1.14), so the decomposition is an arithmetic account of a measurement, not a prediction derived from it. The runtime model (4) uses independently measured effective peak R and bandwidth beta as a consistency check; even if R were fitted, it validates the runtime breakdown, not the speedup claim. The paper explicitly notes limitations - shared-exponent quantization loss, the untuned GEMMul8 baseline, and the hardware exactness assumption behind Lemma 3 - but these affect robustness or comparison fairness, not the logical derivation. There is no load-bearing self-citation: cited Ozaki-scheme results are external algorithmic foundations, not uniqueness theorems imported to force the present choice. No circular step is present.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central mathematical lemma is proven and relies only on standard integer arithmetic and the definition of E2M1. The load-bearing hardware assumptions are the exact FP32 accumulation range and the exact FP4 multiply behavior; these are domain assumptions about the Tensor Core microarchitecture. No free parameters are fitted to data; the scale exponents are part of the algorithm, and the measured peak rates are inputs to the performance model.

assumptions (4)

domain assumption The E2M1 FP4 format has exactly the value set {0, ±0.5, ±1, ±1.5, ±2, ±3, ±4, ±6}.
Standard definition of E2M1 as per OCP MX spec; not proven in this paper.
domain assumption The FP32 accumulator can hold all integers up to 2^24 exactly.
IEEE 754 single precision has 24-bit significand, so integers up to 2^24 are exact; used in Lemma 2 and Lemma 3.
domain assumption The FP4 Tensor Core MMA computes the product of the stored E2M1 values exactly and accumulates in FP32 without rounding within the stated bounds.
Assumed hardware behavior; central to the error-free claim.
standard math Chinese remainder theorem for pairwise coprime moduli.
Used in Ozaki scheme II reconstruction.

how reviews work

0 comments

Cite this review

Pith. "Pith review of DGEMM with Ozaki Scheme I/II on FP4 Tensor Cores: A Base-13 E2M1 Limb Representation." pith.science (2026). https://pith.science/paper/O6VHDCXF

@misc{pith2026260806812,
  author       = {Pith},
  title        = {Pith review of: DGEMM with Ozaki Scheme I/II on FP4 Tensor Cores: A Base-13 E2M1 Limb Representation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O6VHDCXF}},
  note         = {Machine review of arXiv:2608.06812}
}

abstract

This paper proposes a method and its implementation for emulating FP64 matrix multiplication (DGEMM) by constructing, on FP4 (E2M1; 2 exponent bits and 1 mantissa bit) Tensor Cores, Ozaki schemes I and II, which realize high-precision matrix multiplication on low-precision arithmetic units. Prior implementations were based on INT8 and FP8, and the use of the faster FP4 had not been realized. The key property is that every FP4 value becomes an integer when doubled, and that shifting this integer set by multiples of 13 covers all integers. Converting an arbitrary integer into base-13 FP4 limbs by this property keeps intermediate sums error-free in FP32 accumulators, which makes FP4 Tensor Cores usable for Ozaki schemes I and II. By the same principle, the integer GEMM of INT8 Tensor Cores can also be emulated bit-exactly on FP4 Tensor Cores. When FP4 Tensor Cores have twice the throughput of FP8, Ozaki scheme II on FP4 theoretically achieves slightly higher performance than its FP8 counterpart. This paper further proposes kernel implementation optimizations raising the attained fraction of peak performance, obtaining a measured speedup on top of the theoretical advantage. We verify this on an RTX PRO 6000 Blackwell, achieving performance competitive with that of an existing FP8-based implementation of Ozaki scheme II, and actually exceeding it at a large problem size ($16384^3$).

Figures

Figures reproduced from arXiv: 2608.06812 by the authors.

**Figure 2.** Overall structure of OzI-FP4. The inputs are decomposed into base-13 FP4 limbs by the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Overall structure of OzII-FP4 (same format as Fig. 2). After scaling, [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Three optimization stages of the OzI-FP4 pipeline (FP64 input [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

**Figure 6.** Figure 6: Accuracy comparison (inner-product length [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

**Figure 7.** Figure 7: Breakdown of the end-to-end time of the three FP64 emulations [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Spec Sheets Are Not Kernels: An ISA- and Source-Level Audit of INT8 Availability on NVIDIA Blackwell Ultra
cs.AR 2026-08 accept novelty 7.0 of 10

On NVIDIA Blackwell Ultra, INT8 W8A8 is undeployable by default because the PTX ISA, CUTLASS, vLLM, and SGLang all lack a fifth-generation INT8 tensor-core path, despite the datasheet listing INT8 support.

Reference graph

Works this paper leans on

19 extracted references · 14 canonical work pages · cited by 1 Pith paper

[1]

NVIDIA Blackwell Ultra GPU datasheet,

NVIDIA, “NVIDIA Blackwell Ultra GPU datasheet,” NVIDIA Corporation, 2025. [Online]. Available: https://resources.nvidia.com/ en-us-blackwell-architecture/blackwell-ultra-datasheet

work page 2025
[2]

Nvidia leans on emulation to squeeze more HPC oomph from AI chips in race against AMD,

T. Mann, “Nvidia leans on emulation to squeeze more HPC oomph from AI chips in race against AMD,” The Register, Jan. 18, 2026. [Online]. Available: https://www.theregister.com/2026/01/18/ nvidia fp64 emulation/

work page 2026
[3]

OCP microscaling formats (MX) specification, version 1.0,

Open Compute Project, “OCP microscaling formats (MX) specification, version 1.0,” 2023. [Online]. Available: https://www.opencompute.org/ documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf

work page 2023
[4]

Introducing NVFP4 for efficient and accurate low-precision inference,

E. Alvarez, O. Almog, E. Chung, S. Layton, D. Stosic, R. Krashinsky, and K. Aubrey, “Introducing NVFP4 for efficient and accurate low-precision inference,” NVIDIA Technical Blog, Jun. 24, 2025. [Online]. Available: https://developer.nvidia.com/blog/ introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/

work page 2025
[5]

Error-free trans- formations of matrix multiplication by using fast routines of matrix multiplication and its applications,

K. Ozaki, T. Ogita, S. Oishi, and S. M. Rump, “Error-free trans- formations of matrix multiplication by using fast routines of matrix multiplication and its applications,”Numerical Algorithms, vol. 59, no. 1, pp. 95–118, 2012

work page 2012
[6]

Ozaki scheme II: A GEMM- oriented emulation of floating-point matrix multiplication using an integer modular technique,

K. Ozaki, Y . Uchino, and T. Imamura, “Ozaki scheme II: A GEMM- oriented emulation of floating-point matrix multiplication using an integer modular technique,” 2025, arXiv:2504.08009. 2https://github.com/FP4-is-All-you-Need/Oz-FP4

arXiv 2025
[7]

Double-precision matrix multi- plication emulation via Ozaki-II scheme with FP8 quantization,

Y . Uchino, K. Ozaki, and T. Imamura, “Double-precision matrix multi- plication emulation via Ozaki-II scheme with FP8 quantization,” 2026, arXiv:2603.10634

arXiv 2026
[8]

GEMMul8 (GEMMulate): GEMM emulation and its extension to BLAS-like matrix operations using INT8/FP8 matrix engines based on the Ozaki scheme II,

RIKEN Center for Computational Science, “GEMMul8 (GEMMulate): GEMM emulation and its extension to BLAS-like matrix operations using INT8/FP8 matrix engines based on the Ozaki scheme II,” GitHub software repository, 2026. [Online]. Available: https: //github.com/RIKEN-RCCS/GEMMul8

work page 2026

Show all 19 references

[9]

DGEMM using tensor cores, and its accurate and reproducible versions,

D. Mukunoki, K. Ozaki, T. Ogita, and T. Imamura, “DGEMM using tensor cores, and its accurate and reproducible versions,” inProc. ISC High Performance 2020, LNCS 12151, 2020, pp. 230–248

2020
[10]

DGEMM on integer matrix multi- plication unit,

H. Ootomo, K. Ozaki, and R. Yokota, “DGEMM on integer matrix multi- plication unit,”The International Journal of High Performance Comput- ing Applications, vol. 38, no. 4, pp. 297–313, 2024, arXiv:2306.11975

2024 arXiv
[11]

ozIMMU: FP64 equivalent GEMM by the Ozaki scheme with Int8 tensor cores,

H. Ootomo, “ozIMMU: FP64 equivalent GEMM by the Ozaki scheme with Int8 tensor cores,” GitHub software repository, 2024. [Online]. Available: https://github.com/enp1s0/ozIMMU

2024
[12]

Performance enhancement of the Ozaki scheme on integer matrix multiplication unit,

Y . Uchino, K. Ozaki, and T. Imamura, “Performance enhancement of the Ozaki scheme on integer matrix multiplication unit,”The International Journal of High Performance Computing Applications, vol. 39, no. 3, pp. 462–476, 2025, arXiv:2409.13313

2025 arXiv
[13]

DGEMM using FP64 arithmetic emulation and FP8 tensor cores with Ozaki scheme,

D. Mukunoki, “DGEMM using FP64 arithmetic emulation and FP8 tensor cores with Ozaki scheme,” inProc. SCA/HPCAsia Workshops 2026, 2026, pp. 303–311, arXiv:2508.00441

2026
[14]

High-performance and power- efficient emulation of matrix multiplication using INT8 matrix engines,

Y . Uchino, K. Ozaki, and T. Imamura, “High-performance and power- efficient emulation of matrix multiplication using INT8 matrix engines,” inProc. SC Workshops ’25, 2025, pp. 1824–1831, arXiv:2508.03984

2025
[15]

EmuGEMM: Fused tensor core kernels for precision emulation in matrix multiplication,

D. Lu, A. Maeder, M. Luisier, and A. N. Ziogas, “EmuGEMM: Fused tensor core kernels for precision emulation in matrix multiplication,” 2026, arXiv:2606.25453

2026 arXiv
[16]

Guaranteed DGEMM accuracy while using reduced precision tensor cores through extensions of the Ozaki scheme,

A. Schwarz, A. Anders, C. Brower, H. Bayraktar, J. Gunnels, K. Clark, R. G. Xu, S. Rodriguez, S. Cayrols, P. Tabaszewski, and V . Podlozhnyuk, “Guaranteed DGEMM accuracy while using reduced precision tensor cores through extensions of the Ozaki scheme,” inProc. SCA/HPCAsia 202...

2026
[17]

GNU MP: The GNU multiple precision arithmetic library,

T. Granlund and the GMP development team, “GNU MP: The GNU multiple precision arithmetic library,” Ed. 6.3.0, 2023. [Online]. Available: https://gmplib.org/

2023
[18]

Triton: An intermediate language and compiler for tiled neural network computations,

P. Tillet, H. T. Kung, and D. Cox, “Triton: An intermediate language and compiler for tiled neural network computations,” inProc. MAPL 2019, 2019, pp. 10–19

2019
[19]

Matrix multiplication in multiword arithmetic: Error analysis and application to GPU tensor cores,

M. Fasi, N. J. Higham, F. Lopez, T. Mary, and M. Mikaitis, “Matrix multiplication in multiword arithmetic: Error analysis and application to GPU tensor cores,”SIAM Journal on Scientific Computing, vol. 45, no. 1, pp. C1–C19, 2023

2023

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.

[1] [1]

NVIDIA Blackwell Ultra GPU datasheet,

NVIDIA, “NVIDIA Blackwell Ultra GPU datasheet,” NVIDIA Corporation, 2025. [Online]. Available: https://resources.nvidia.com/ en-us-blackwell-architecture/blackwell-ultra-datasheet

work page 2025

[2] [2]

Nvidia leans on emulation to squeeze more HPC oomph from AI chips in race against AMD,

T. Mann, “Nvidia leans on emulation to squeeze more HPC oomph from AI chips in race against AMD,” The Register, Jan. 18, 2026. [Online]. Available: https://www.theregister.com/2026/01/18/ nvidia fp64 emulation/

work page 2026

[3] [3]

OCP microscaling formats (MX) specification, version 1.0,

Open Compute Project, “OCP microscaling formats (MX) specification, version 1.0,” 2023. [Online]. Available: https://www.opencompute.org/ documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf

work page 2023

[4] [4]

Introducing NVFP4 for efficient and accurate low-precision inference,

E. Alvarez, O. Almog, E. Chung, S. Layton, D. Stosic, R. Krashinsky, and K. Aubrey, “Introducing NVFP4 for efficient and accurate low-precision inference,” NVIDIA Technical Blog, Jun. 24, 2025. [Online]. Available: https://developer.nvidia.com/blog/ introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/

work page 2025

[5] [5]

Error-free trans- formations of matrix multiplication by using fast routines of matrix multiplication and its applications,

K. Ozaki, T. Ogita, S. Oishi, and S. M. Rump, “Error-free trans- formations of matrix multiplication by using fast routines of matrix multiplication and its applications,”Numerical Algorithms, vol. 59, no. 1, pp. 95–118, 2012

work page 2012

[6] [6]

Ozaki scheme II: A GEMM- oriented emulation of floating-point matrix multiplication using an integer modular technique,

K. Ozaki, Y . Uchino, and T. Imamura, “Ozaki scheme II: A GEMM- oriented emulation of floating-point matrix multiplication using an integer modular technique,” 2025, arXiv:2504.08009. 2https://github.com/FP4-is-All-you-Need/Oz-FP4

arXiv 2025

[7] [7]

Double-precision matrix multi- plication emulation via Ozaki-II scheme with FP8 quantization,

Y . Uchino, K. Ozaki, and T. Imamura, “Double-precision matrix multi- plication emulation via Ozaki-II scheme with FP8 quantization,” 2026, arXiv:2603.10634

arXiv 2026

[8] [8]

GEMMul8 (GEMMulate): GEMM emulation and its extension to BLAS-like matrix operations using INT8/FP8 matrix engines based on the Ozaki scheme II,

RIKEN Center for Computational Science, “GEMMul8 (GEMMulate): GEMM emulation and its extension to BLAS-like matrix operations using INT8/FP8 matrix engines based on the Ozaki scheme II,” GitHub software repository, 2026. [Online]. Available: https: //github.com/RIKEN-RCCS/GEMMul8

work page 2026