cuDNN Frontend: a graph API, a Python entry point, and an expanding set of OSS kernels
cuDNN Frontend is NVIDIA's modern, open-source entry point to the cuDNN library and a growing collection of high-performance open-source kernels.
At a glance
- What is it?
- The cuDNN Frontend wraps cuDNN's Graph API in a header-only C++ layer and a Python interface with PyTorch integration, and now ships standalone kernels for attention, MoE grouped GEMM and fused normalization. It is Apache-2.0, targets Hopper and Blackwell, and the dev-tagged release cadence is the first thing to plan around.
- Who is it for?
- Adopt cuDNN Frontend if you are already writing CUDA kernels for Hopper or Blackwell and want cuDNN's graph planning plus inspectable OSS kernels in one place; skip it if you only need portable PyTorch and cannot accept an NVIDIA-GPU-only dependency. Before committing, verify the exact cuDNN runtime version your chosen release requires, confirm the arch tags (SM90, SM100, SM103) cover your target, and pin a specific dev tag rather than tracking develop.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap cuDNN Frontend fills between raw cuDNN and a framework
cuDNN exposes a Graph API: you describe an operation graph and the library picks and runs an implementation. That is a lower-level contract than a framework op, and a higher-level one than hand-written kernels. cuDNN Frontend is the layer NVIDIA puts in front of it, described in the README as a header-only C++ API and a Python interface with native PyTorch integration. The stated targets are Hopper (H100/H200) and Blackwell (B200/GB200/GB300) across FP16, BF16, FP8 and MXFP8.
The audience is narrow on purpose. If you are writing a training loop in PyTorch on an A100, this project is not aimed at you. It is aimed at people who need to control which fused kernel runs, or who need a fusion that the framework does not emit, and who are willing to accept an NVIDIA-only dependency to get it. The second half of the README makes that explicit: the repository is no longer just a wrapper. It is also a distribution channel for open-source kernels, with the stated goal of letting developers inspect, modify and contribute to the core logic.
What actually sits in the repository: two layers, not one
The layout described in the README separates cleanly. The C++ side lives under include/cudnn_frontend, with generated kernels such as the fused RMSNorm + SiLU implementation under include/cudnn_frontend/generated/rms_norm_silu. The Python side lives under python/cudnn, and that is where the newer kernel work is concentrated: gemm/cutedsl for the GEMM variants, block_sparse_attention, flex_attention, hstu, native_sparse_attention and sdpa.
That split matters for adoption. The header-only C++ API is the stable, long-lived surface. The kernel directories are a moving collection, and the README frames the open-sourcing itself as incremental: kernels are published based on customer needs, with the goal of educating developers and enabling customization. Read that as a statement about coverage, not a promise of completeness. A kernel you need may simply not be published yet, and the README does not commit to a schedule for the rest.
The kernel catalogue is organised around transformer training
The list of OSS kernels reads as a map of where transformer training spends time. On the attention side there is SDPA backward for D=256 on SM100, block-sparse attention forward and backward for block-level routing metadata, Flex Attention with reusable interval-mask plans and PyTorch autograd on SM90/SM100/SM103, HSTU attention for packed variable-length sequences using SiLU scores without softmax, and NSA, which the README ties to the Native Sparse Attention paper.
On the MoE side the coverage is denser. There are grouped GEMM kernels for SwiGLU, dSwiGLU, sReLU, dsReLU and GLU, plus a grouped GEMM with a fused Hadamard transform and per-expert AMAX reduction. Several entries exist in two forms: a dense packed-weight layout and a discrete per-expert-pointer layout that the README describes as avoiding weight packing. There is also a grouped weight-gradient kernel. For MoE training, the backward passes (dGLU, dSwiGLU, Wgrad) are present alongside the forward ones, which is the part that usually decides whether a fused kernel is usable in a real training loop rather than only in inference.
The FROST GEMM engine and how you opt in
The most consequential item in the README is FROST, described as a JIT-compiled Blackwell GEMM engine reachable through the ordinary cudnn.pygraph API. The claim is that matmul, grouped (MoE) matmul, block-scaled FP4/FP8 and chained pointwise epilogues are fused into one kernel from the graph you already built. Opt-in is a single environment variable: CUDNN_FRONTEND_ENABLE_FROST_ENGINES=1. Once set, the README states it becomes a candidate for every matmul graph it can serve, ranked against the backend's own plans.
That last clause is the design decision worth pausing on. FROST does not replace cuDNN's heuristics; it competes with them. So the practical question is not whether FROST is faster in the abstract but whether it wins the ranking for your specific shapes, dtypes and epilogue chain. The README does not publish a shape-by-shape comparison, and I have not run one. Treat enabling the flag as the start of a measurement, not the end of one. It also means a graph that runs fine today can select a different engine after an upgrade, which is a reason to keep the flag off in production until you have re-measured.
Getting it running: install, imports and the arch constraint
Installation is from PyPI under the package name nvidia-cudnn-frontend, which is what the README's badge links to. The Python interface is imported as cudnn, and the graph API is reached through cudnn.pygraph, the module named in the FROST description. The kernels live in submodules of python/cudnn, so a grouped SwiGLU kernel is imported from its own path rather than from the top level.
The constraint that will stop most first attempts is hardware. The README names Hopper and Blackwell specifically, and the kernel entries carry SM90, SM100 and SM103 tags. A Flex Attention kernel tagged for SM90/SM100/SM103 is not going to run on an older part, and the SDPA backward entry is explicitly D=256 on SM100. If your fleet is mixed, you are maintaining at least two code paths. The README does not describe a fallback mechanism for unsupported architectures, so plan for one yourself or restrict the feature to the newer nodes.
Where this is the wrong tool, and what to use instead
If your goal is a model that trains on whatever GPU you can rent, cuDNN Frontend is the wrong layer. Plain PyTorch with its own SDPA and GEMM paths will run on a broader set of hardware, and the framework's kernels already cover the common attention and matmul cases. The difference in approach is architectural: PyTorch ships one implementation per op that must work everywhere, while cuDNN Frontend lets you select a graph and, with FROST, lets a JIT engine compete for it. That extra control is only worth paying for when you have a shape or fusion the framework does not serve well.
There is a second case worth naming. If you need a kernel the README does not list, the open-sourcing is described as driven by customer needs rather than by a published roadmap, so the answer may be that you write it yourself against the CuTe DSL kernels that are published. That is a real option here in a way it is not with a closed library, but it is also a real cost.
The third limitation is the release cadence. The three most recent releases at the time of writing are all v1.29.0.dev tags dated one day apart. Development builds are what the repository is publishing, and the default branch is develop. Nothing in the supplied material describes a separate stable channel, so pinning an exact dev tag is the only reproducible option available.
Licence, maintenance and what an upgrade actually costs
The licence is Apache-2.0, which permits modification and redistribution subject to its notice and attribution conditions. That is consistent with the README's framing of the kernels as something you can inspect, modify and contribute to. It is not legal advice, and if you plan to redistribute a modified kernel you should read the licence text and your own obligations rather than rely on this summary.
The maintenance cost is the part that is easy to underestimate. Because FROST is ranked against the backend's own plans, a cuDNN upgrade can change which engine runs your graph without any change on your side. Because the published releases are dev tags, there is no obvious version to hold still on. Because the kernel directory is growing, the import paths for kernels you use are part of the moving surface. The practical pattern is to pin an exact dev tag, record the cuDNN runtime version it was validated against, and re-run your own shape-level comparison whenever either changes. The README does not supply that comparison for you, and the documentation linked from the badges is where the per-kernel API details live.
Editorial conclusion
Adopt cuDNN Frontend if you are already writing CUDA kernels for Hopper or Blackwell and want cuDNN's graph planning plus inspectable OSS kernels in one place; skip it if you only need portable PyTorch and cannot accept an NVIDIA-GPU-only dependency. Before committing, verify the exact cuDNN runtime version your chosen release requires, confirm the arch tags (SM90, SM100, SM103) cover your target, and pin a specific dev tag rather than tracking develop.
Community notes