Matmul#

class nvmath.distributed.linalg.advanced.Matmul( a, b, /, c=None, *, distributions: Sequence[Distribution], alpha=None, beta=None, qualifiers=None, quantization_scales=None, options: MatmulOptions | dict[str, Any] | None = None, stream: AnyStream | int | None = None, )[source]#

Create a stateful object encapsulating the specified distributed matrix multiplication computation \(\alpha a @ b + \beta c\) and the required resources to perform the operation. A stateful object can be used to amortize the cost of preparation (planning in the case of matrix multiplication) across multiple executions (also see the Stateful APIs section).

The function-form API matmul() is a convenient alternative to using stateful objects for single use (the user needs to perform just one matrix multiplication, for example), in which case there is no possibility of amortizing preparatory costs. The function-form APIs are just convenience wrappers around the stateful object APIs.

Using the stateful object typically involves the following steps:

Problem Specification: Initialize the object with a defined operation and options.
Preparation: Use plan() to determine the best algorithmic implementation for this specific matrix multiplication operation.
Execution: Perform the matrix multiplication computation with execute().
Resource Management: Ensure all resources are released either by explicitly calling free() or by managing the stateful object within a context manager.

Detailed information on what’s happening in the various phases described above can be obtained by passing in a logging.Logger object to MatmulOptions or by setting the appropriate options in the root logger object, which is used by default:

>>> import logging
>>> logging.basicConfig(
...     level=logging.INFO,
...     format="%(asctime)s %(levelname)-8s %(message)s",
...     datefmt="%m-%d %H:%M:%S",
... )

A user can select the desired logging level and, in general, take advantage of all of the functionality offered by the Python logging module.

Parameters:

a – A distributed tensor representing the first operand to the matrix multiplication (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
b – A distributed tensor representing the second operand to the matrix multiplication (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
c – (Optional) A distributed tensor representing the operand to add to the matrix multiplication result (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
distributions – Sequence specifying the distribution across processes of matrices a, b and c/d. The distribution needs to be BlockCyclic or compatible.
alpha – The scale factor for the matrix multiplication term as a real or complex number. The default is \(1.0\).
beta – The scale factor for the matrix addition term as a real or complex number. A value for beta must be provided if operand c is specified.
qualifiers – Specify the matrix qualifiers as a numpy.ndarray of matrix_qualifiers_dtype objects of length 3 corresponding to the operands a, b, and c. See Matrix and Tensor Qualifiers for the motivation behind qualifiers.
quantization_scales – Specify scale factors for the matrix multiplication as a MatmulQuantizationScales object. Alternatively, a dict containing the parameters for the MatmulQuantizationScales constructor can also be provided. The scale factors can be provided as scalars or tensors. If a scale factor is provided as a tensor, it must be from the same package and on the same memory space (CPU or GPU device) as the operands of the matmul. If a scale factor is provided as a scalar, and the execution space is GPU, a CPU->GPU copy is inevitable. To avoid this copy, provide the quantization scale as one-element array on the GPU. Allowed and required only for narrow-precision (FP8 and lower) operations.
options – Specify options for the matrix multiplication as a MatmulOptions object. Alternatively, a dict containing the parameters for the MatmulOptions constructor can also be provided. If not specified, the value will be set to the default-constructed MatmulOptions object.
stream – Provide the CUDA stream to use for executing the operation. Acceptable inputs include cudaStream_t (as Python int), cupy.cuda.Stream, and torch.cuda.Stream. If a stream is not provided, the current stream from the operand package will be used. See Stream Semantics for more details on stream handling.

Semantics:

The semantics of the matrix multiplication follows numpy.matmul semantics, with some restrictions on broadcasting. In addition, the semantics for the fused matrix addition are described below:

For in-place matrix multiplication (where the result is written into c) the result has the same shape as c.

Narrow-precision support:

Matrix multiplication with narrow-precision operands is supported, in FP8, MXFP8, and NVFP4 formats.

FP8 and MXFP8

FP8 and MXFP8 use float8_e4m3fn or float8_e5m2 data types. The difference is the scaling mode: FP8 (block_scaling=False) uses per-tensor scaling where a single scalar scale is applied to each operand; MXFP8 (block_scaling=True) uses microscaling with 32-element blocks arranged in 128x128 tiles.

Note

FP8 requires a device with compute capability 8.9 or higher (Ada, Hopper, Blackwell or newer architecture). MXFP8 requires a device with compute capability 10.0 or higher (Blackwell or newer architecture). Please refer to the compute capability table to check the compute capability of your device.

For FP8 operations:

For each operand a scaling factor needs to be specified via quantization_scales argument.
Maximum absolute value of the result (amax) can be requested via result_amax option in options argument.
Custom result type (both FP8 and non-FP8) can be requested via result_type option in options argument.

For MXFP8 operations:

block_scaling option must be set to True and block scaling factors need to be specified via quantization_scales argument. Utilities in nvmath.linalg.advanced.helpers.matmul can be used to create and modify block scaling factors, see e.g. create_mxfp8_scale().
When the result type is a narrow-precision data type, the auxiliary output "d_out_scale" will be returned containing the scales used for result quantization.

Layout Requirements

Due to the requirements of narrow-precision GEMM kernels, the contracting dimension K must be contiguous (stride-1) for both operands. The following layout constraints apply to both FP8 and MXFP8:

Operand a must be (K, M) with column-major layout.
Operand b must be (K, N) with column-major layout.

Attention

Epilog support for MXFP8 is still evolving in the underlying cuBLASLt library, so not every combination of epilog, data type, and layout is guaranteed to work. If running into unsupported combinations, a cuBLASLt error will be raised either at planning time or at execution time that will reveal the root cause. These gaps are expected to be filled in future cuBLASLt releases.

For more details on the FP8 and MXFP8 formats in cuBLAS, see the cublasLtMatmul documentation.

NVFP4

Added in version 1.0: NVFP4 support.

NVFP4 uses float4_e2m1fn_x2 data type with block scaling (16-element blocks arranged in 128x64 tiles).

Note

NVFP4 matrix multiplication requires a device with compute capability 10.0 or higher (Blackwell or newer architecture), and PyTorch 2.9 or newer for float4_e2m1fn_x2 dtype support. Please refer to the compute capability table to check the compute capability of your device.

For NVFP4 operations:

block_scaling option must be set to True and block scaling factors need to be specified via quantization_scales argument.
When the result type is a narrow-precision data type, the auxiliary output "d_out_scale" will be returned containing the scales used for result quantization.

Layout and Packing Requirements

FP4 data is per-byte packed: float4_e2m1fn_x2 stores 2 FP4 values per byte. The block scaling (VEC16_UE4M3) assigns one scale factor per 16 consecutive elements along the innermost (stride-1) dimension of each operand. The layout requirements below ensure that this innermost dimension corresponds to the contracting dimension K for both operands.

Operand a must be (K//2, M) with stride[-2] == 1 and stride[-1] >= K//2, i.e., column-wise packed along K. Note that stride[-1] can be larger than K//2 to support sliced views, as long as the stride remains 16-byte aligned.
Operand b must be (K//2, N) with stride[-2] == 1 and stride[-1] >= K//2, i.e., column-wise packed along K. Note that stride[-1] can be larger than K//2 to support sliced views, as long as the stride remains 16-byte aligned.

If your data has the stride-1 axis along a dimension other than K, you must repack it before calling matmul().

When the result type is also FP4, the output is column-major packed along the M dimension: (M//2, N), strides (1, M//2).

Attention

Epilog support for NVFP4 is still evolving in the underlying cuBLASLt library, so not every combination of epilog, data type, and layout is guaranteed to work. If running into unsupported combinations, a cuBLASLt error will be raised either at planning time or at execution time that will reveal the root cause. These gaps are expected to be filled in future cuBLASLt releases.

Helper Functions

The nvmath.linalg.advanced.helpers.matmul module provides helpers for working with FP4 encoding/decoding and NVFP4 block scales, see e.g. quantize_to_fp4(), unpack_fp4(), get_block_scale_offset(), to_block_scale(), expand_block_scale().

Note

These helpers operate on the local data (i.e. local tensor and local block scales) on each process.

For more details on the NVFP4 format in cuBLAS, see the cublasLtMatmul documentation. For usage examples, see the relevant files in the examples/distributed/linalg/advanced/matmul directory.

Examples

>>> import numpy as np
>>> import nvmath.distributed
>>> from nvmath.distributed.distribution import Slab
>>> from nvmath.distributed.linalg.advanced import matrix_qualifiers_dtype

Get process group used to initialize nvmath.distributed (for information on initializing nvmath.distributed, you can refer to the documentation or to the Matmul examples in nvmath/examples/distributed/linalg/advanced):

>>> process_group = nvmath.distributed.get_context().process_group

Get my process rank:

>>> rank = process_group.rank

Create two 2-D float64 ndarrays on the CPU (using Slab distributions to distribute the matrices across processes):

>>> M, N, K = 1024, 1024, 1024
>>> a_shape = Slab.X.shape(rank, (K, M))
>>> b_shape = Slab.X.shape(rank, (K, N))
>>> a = np.asfortranarray(np.random.rand(*a_shape))
>>> b = np.asfortranarray(np.random.rand(*b_shape))

We will define a matrix multiplication operation followed by an AllReduce epilog using the specialized matrix multiplication interface.

Create a Matmul object encapsulating the problem specification above:

>>> qualifiers = np.zeros((3,), dtype=matrix_qualifiers_dtype)
>>> qualifiers[0]["is_transpose"] = True  # a is transposed
>>> distributions = [Slab.X, Slab.X, Slab.Y]
>>> mm = nvmath.distributed.linalg.advanced.Matmul(
...     a, b, distributions=distributions, qualifiers=qualifiers
... )

Options can be provided above to control the behavior of the operation using the options argument (see MatmulOptions).

Next, plan the operation. The epilog is specified, and optionally, preferences can be specified for planning:

>>> epilog = nvmath.distributed.linalg.advanced.MatmulEpilog.ALLREDUCE
>>> mm.plan(epilog=epilog)

Now execute the matrix multiplication, and obtain the result r1 as a NumPy ndarray.

>>> r1 = mm.execute()

Finally, free the object’s resources. To avoid having to explicitly make this call, it’s recommended to use the Matmul object as a context manager as shown below, if possible.

>>> mm.free()

Note that all Matmul methods execute on the current stream by default. Alternatively, the stream argument can be used to run a method on a specified stream.

Let’s now look at the same problem with CuPy ndarrays on the GPU.

>>> device_id = nvmath.distributed.get_context().device_id
>>> import cupy as cp
>>> with cp.cuda.Device(device_id):
...     a = cp.asfortranarray(cp.random.rand(*a_shape))
...     b = cp.asfortranarray(cp.random.rand(*b_shape))

Create a Matmul object encapsulating the problem specification described earlier and use it as a context manager.

>>> with nvmath.distributed.linalg.advanced.Matmul(
...     a, b, distributions=distributions, qualifiers=qualifiers
... ) as mm:
...     mm.plan(epilog=epilog)
...
...     # Execute the operation to get the first result.
...     r1 = mm.execute()
...
...     # Update operands 'a' and 'b' in-place (see reset_operands() for an
...     # alternative).
...     with cp.cuda.Device(device_id):
...         a[:] = cp.random.rand(*a_shape)
...         b[:] = cp.random.rand(*b_shape)
...
...     # Execute the operation to get the new result.
...     r2 = mm.execute()

All the resources used by the object are released at the end of the block.

Further examples can be found in the nvmath/examples/distributed/linalg/advanced/matmul directory.

Methods

execute( *, release_workspace=False, stream: AnyStream | int | None = None, )[source]#

Execute a planned distributed matrix multiplication.

Parameters:

release_workspace – A value of True specifies that the stateful object should release workspace memory back to the package memory pool on function return, while a value of False specifies that the object should retain the memory. This option may be set to True if the application performs other operations that consume a lot of memory between successive calls to the (same or different) execute() API, but incurs a small overhead due to obtaining and releasing workspace memory from and to the package memory pool on every call. The default is False.
stream – Provide the CUDA stream to use for executing the operation. Acceptable inputs include cudaStream_t (as Python int), cupy.cuda.Stream, and torch.cuda.Stream. If a stream is not provided, the current stream from the operand package will be used. See Stream Semantics for more details on stream handling.

Returns:

The result of the specified matrix multiplication (epilog applied), which remains on the same device and belongs to the same package as the input operands. If an epilog (like nvmath.distributed.linalg.advanced.MatmulEpilog.RELU_AUX) that results in extra output is used, or an extra output is requested (for example by setting result_amax option in options argument), a tuple is returned with the first element being the matrix multiplication result (epilog applied) and the second element being the auxiliary output provided as a dict.

free()[source]#

Free Matmul resources.

It is recommended that the Matmul object be used within a context, but if it is not possible then this method must be called explicitly to ensure that the matrix multiplication resources (especially internal library objects) are properly cleaned up.

plan( *, preferences=None, epilog=None, epilog_inputs=None, stream: AnyStream | int | None = None, )[source]#

Plan the matrix multiplication operation, considering the epilog (if provided).

Parameters:

preferences – This parameter specifies the preferences for planning as a MatmulPlanPreferences object. Alternatively, a dictionary containing the parameters for the MatmulPlanPreferences constructor can also be provided. If not specified, the value will be set to the default-constructed MatmulPlanPreferences object.
epilog – Specify an epilog \(\mathcal{F}\) as an object of type MatmulEpilog to apply to the result of the matrix multiplication: \(\mathcal{F}(\alpha a @ b + \beta c)\). The default is no epilog. See cuBLASMp documentation for the list of available epilogs.
epilog_inputs – Specify the additional inputs needed for the selected epilog as a dictionary, where the key is the epilog input name and the value is the epilog input. The epilog input must be a tensor with the same package and in the same memory space as the operands (see the constructor for more information on the operands). If the required epilog inputs are not provided, an exception is raised that lists the required epilog inputs. Some epilog inputs are generated by other epilogs. For example, the epilog input for MatmulEpilog.DRELU is generated by matrix multiplication with the same operands using MatmulEpilog.RELU_AUX.
stream – Provide the CUDA stream to use for executing the operation. Acceptable inputs include cudaStream_t (as Python int), cupy.cuda.Stream, and torch.cuda.Stream. If a stream is not provided, the current stream from the operand package will be used. See Stream Semantics for more details on stream handling.

Notes

Epilogs that have BIAS in their name need an epilog input with the key 'bias'. Epilogs that have DRELU need an epilog input with the key 'relu_aux', which is produced in a “forward pass” epilog like RELU_AUX or RELU_AUX_BIAS. Similarly, epilogs with DGELU in their name require an epilog input with the key 'gelu_aux', produced in the corresponding forward pass operation.

See Matmul for an example, and further examples can be found in the nvmath/examples/distributed/linalg/advanced/matmul directory.

release_operands()[source]#

Added in version 0.9.0.

This method does two things:

Releases internal references to the user-provided operands, so that this instance no longer contributes to their reference counts.
Frees any internal copies (mirrors) that were created when the user-provided operands reside in a different memory space than the execution (i.e., copies made during construction or within reset_operands() / reset_operands_unchecked()).

This functionality can be useful in memory-constrained scenarios, e.g. where multiple stateful objects need to coexist. Leveraging this functionality, the caller can reduce memory usage while retaining the planned state.

Parameters:: None
Returns:: None

Semantics:

Preserves the planned state of the stateful object.
Repeated calls are safe: if the operands are already released, the call is a no-op and an informational message is logged.
After calling this method, reset_operands() (or reset_operands_unchecked()) must be called to supply new operands before calling execute() again. Failure to do so will result in a runtime error. Device-side copies will be re-allocated as needed.
For cross-space scenarios (e.g. CPU operands with GPU execution, or GPU operands with CPU execution): execution is guaranteed to be always blocking. It is therefore always safe to call this method after calling execute() without additional synchronization.
When the operands are in the same memory space as the execution (e.g. GPU operands with GPU execution): in such case, this method drops this instance’s internal reference to the user-provided operands. If the reference count of the operands reaches zero, their memory may be freed, so particular attention should be paid. The caller is responsible to ensure that if such deallocation happens, it is ordered after pending computation (e.g. by retaining a reference until the computation is complete, or by synchronizing the stream). Failure to do so is analogous to use-after-free.

See Overview, Stateful APIs: Design and Usage Patterns for operand lifecycle and usage patterns, and Stream Semantics for stream ordering rules.

reset_operands( *, a=None, b=None, c=None, alpha=None, beta=None, quantization_scales=None, epilog_inputs=None, stream: AnyStream | int | None = None, )[source]#

Reset one or more operands held by this Matmul instance.

Changed in version 0.9: All parameters are now keyword-only.

Parameters:

a – A distributed tensor representing the first operand to the matrix multiplication (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
b – A distributed tensor representing the second operand to the matrix multiplication (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
c – (Optional) A distributed tensor representing the operand to add to the matrix multiplication result (see Semantics). The currently supported types are numpy.ndarray, cupy.ndarray, and torch.Tensor.
alpha – The scale factor for the matrix multiplication term as a real or complex number. The default is \(1.0\).
beta – The scale factor for the matrix addition term as a real or complex number. A value for beta must be provided if operand c is specified.
quantization_scales – Specify scale factors for the matrix multiplication as a MatmulQuantizationScales object. Alternatively, a dict containing the parameters for the MatmulQuantizationScales constructor can also be provided. The scale factors can be provided as scalars or tensors. If a scale factor is provided as a tensor, it must be from the same package and on the same memory space (CPU or GPU device) as the operands of the matmul. If a scale factor is provided as a scalar, and the execution space is GPU, a CPU->GPU copy is inevitable. To avoid this copy, provide the quantization scale as one-element array on the GPU. Allowed and required only for narrow-precision (FP8 and lower) operations.
epilog_inputs – Specify the additional inputs needed for the selected epilog as a dictionary, where the key is the epilog input name and the value is the epilog input. The epilog input must be a tensor with the same package and in the same memory space as the operands (see the constructor for more information on the operands). If the required epilog inputs are not provided, an exception is raised that lists the required epilog inputs. Some epilog inputs are generated by other epilogs. For example, the epilog input for MatmulEpilog.DRELU is generated by matrix multiplication with the same operands using MatmulEpilog.RELU_AUX.
stream – Provide the CUDA stream to use for executing the operation. Acceptable inputs include cudaStream_t (as Python int), cupy.cuda.Stream, and torch.cuda.Stream. If a stream is not provided, the current stream from the operand package will be used. See Stream Semantics for more details on stream handling.

Semantics:

Only the operands explicitly passed are updated. At least one operand is required (all of them after release_operands()), otherwise a ValueError is raised.
This method will perform various checks on the new operands to make sure:
- The distributions, shapes, strides, datatypes match those of the old ones.
- The packages that the operands belong to match those of the old ones.
- If input tensors are on GPU, the device must match.

Examples

>>> import cupy as cp
>>> import nvmath.distributed
>>> from nvmath.distributed.distribution import Slab

>>> process_group = nvmath.distributed.get_context().process_group

Get my process rank:

>>> rank = process_group.rank

Create two 3-D float64 ndarrays on the GPU (using Slab distributions to distribute the matrices across processes):

>>> M, N, K = 128, 128, 256
>>> a_shape = Slab.X.shape(rank, (M, K))
>>> b_shape = Slab.Y.shape(rank, (K, N))
>>> device_id = nvmath.distributed.get_context().device_id
>>> with cp.cuda.Device(device_id):
...     a = cp.asfortranarray(cp.random.rand(*a_shape))
...     b = cp.asfortranarray(cp.random.rand(*b_shape))

Create an matrix multiplication object as a context manager

>>> d = [Slab.X, Slab.Y, Slab.X]
>>> with nvmath.distributed.linalg.advanced.Matmul(a, b, distributions=d) as mm:
...     # Plan the operation.
...     mm.plan()
...
...     # Execute the MM to get the first result.
...     r1 = mm.execute()
...
...     # Reset the operands to new CuPy ndarrays.
...     with cp.cuda.Device(device_id):
...         a_new = cp.asfortranarray(cp.random.rand(*a_shape))
...         b_new = cp.asfortranarray(cp.random.rand(*b_shape))
...     mm.reset_operands(a=a_new, b=b_new)
...
...     # Execute to get the new result corresponding to the updated operands.
...     r2 = mm.execute()

Note that if only a subset of operands are reset, the operands that are not reset hold their original values.

With reset_operands(), minimal overhead is achieved as problem specification and planning are only performed once.

For the particular example above, explicitly calling reset_operands() is functionally equivalent to updating the operands in-place, i.e, replacing mm.reset_operands(a=a_new, b=b_new) with a[:]=a_new and b[:]=b_new. Note that updating the operand in-place should be adopted with caution as it can only yield the expected result when the operand memory space is accessible from the execution space.

For more details, please refer to inplace update example.