Skip to main content
The CUTLASS Profiler is a command-line driven test and profiling environment for CUTLASS computations defined in the CUTLASS Instance Library. It can execute and profile GEMM, Sparse GEMM, Conv2d, and Conv3d kernels with comprehensive performance metrics.

Building the Profiler

The CUTLASS Profiler can be compiled from the CUTLASS build directory:
By default, only one tile size (typically 128x128) is instantiated for each data type, math instruction, and layout to reduce compilation time.

Building All Kernels

To instantiate all available kernels (warning: this results in tens of thousands of kernels and very long build times):

Building a Subset of Kernels

For practical use, compile only the kernels you need using wildcard patterns:

Basic Usage

View the help message to see all available options:

Profiling Modes

The profiler supports several execution modes:
  • --mode=profile - Regular verification and profiling (default)
  • --mode=dry_run - No kernels are launched or workspaces allocated
  • --mode=enumerate - Lists all operation kinds and operations
  • --mode=trace - Executes a single device-side computation with no other kernel launches

Getting Device Information

Profiling GEMM Operations

Basic GEMM Profiling

Profile a single problem size:

Example Output

Sweeping Problem Sizes

Use ranges to sweep over problem dimensions:

Tensor Core Operations

Profile kernels using Tensor Cores:
Example output:

Advanced Profiling Options

Filtering Kernels

Use wildcard patterns to filter which kernels to profile:

Controlling Profiling Duration

Data Distribution

Control how input tensors are initialized:

Verification Options

Output and Reporting

CSV Output

Save profiling results to a CSV file:

Adding Tags for Analysis

Prepend custom columns for easier pivot table generation:

JUnit XML Output

Generate JUnit-compatible XML reports:

Performance Optimization Features

Find the best performing kernel for your problem:
1

Search across all parameters

Enable exhaustive search to find the optimal kernel configuration:
2

Optimize for fixed problem size

Tune kernel parameters for a specific GEMM shape:
3

Sweep multiple shapes

Test multiple problem sizes:

CUDA Graphs

Reduce kernel launch overhead by using CUDA graphs:

Cluster Configuration (Hopper/Blackwell)

Control cluster shapes on modern architectures:

Profiling Convolutions

Conv2d Forward Propagation

Example output:

Hopper-Specific Features

Instantiation Levels

Control the number of kernel variants generated:
The instantiation level is a 4-digit number controlling:
  • Digit 0: Instruction Shape
  • Digit 1: MMA Shape Multiplier
  • Digit 2: Cluster Shape
  • Digit 3: Schedule Pruning

Mixed Input Data Types

Profile mixed precision kernels:

Performance Analysis Tips

The “Math” metric shows computational throughput in GFLOP/s. Compare this against the theoretical peak of your GPU:
  • NVIDIA H100: ~989 TFLOPS (FP16 Tensor Core)
  • NVIDIA A100: ~312 TFLOPS (FP16 Tensor Core)
  • NVIDIA V100: ~125 TFLOPS (FP16 Tensor Core)
Efficiency = (Measured GFLOP/s) / (Theoretical Peak) × 100%
Compare the “Memory” and “Math” metrics:
  • If memory bandwidth is saturated but GFLOP/s is low, the kernel is memory-bound
  • If GFLOP/s is high but memory bandwidth has headroom, the kernel is compute-bound
Optimal kernels on modern GPUs should be compute-bound for large problem sizes.
Tile sizes affect both performance and resource usage:
  • Larger tiles (256×256) are better for large matrices
  • Smaller tiles (64×64 or 128×128) may be better for smaller problems
  • Use --cta_m, --cta_n, --cta_k to override tile sizes

Common Profiling Workflows

Functional Testing

Quick functional test across various problem sizes:

Performance Comparison

Compare CUTLASS against cuBLAS:

Batch Processing with Kernel Lists

Profile specific kernels from a file:

Next Steps

Optimization Techniques

Learn strategies to optimize CUTLASS kernels for your workload

Benchmarks

View performance benchmarks across different architectures