NVIDIA Accelerated Computing Hub: timed GPU courses with a hardware price tag

What this repository is: course material, not a library

The Accelerated Computing Hub is described as a home for open learning materials related to GPU computing: user guides, tutorials and other works freely available for anyone interested in the subject. The stated intention is a living project where documents, examples, best practices, optimizations and new features become visible and accessible quickly.

That is the whole scope, and it is worth being precise about it. Nothing here is a package you depend on. There is no API, no library and no build you integrate into a product. What you get is material organised as courses, with the repository layout reflecting that: tutorials/ with a subdirectory per course, Accelerated_Python_User_Guide/ at the top level, plus brev/, docs/, events/ and resources/.

The primary language recorded for the repository is Jupyter Notebook, which is a useful clue about the delivery model. The syllabi are .ipynb files under tutorials/accelerated-python/notebooks/syllabi/, each with an estimated length in its name, such as an eight-hour course and a two-hour course, and a two-day one. A file named for its duration is an unusual and honest convention: it tells an instructor what they are committing to before they open it.

Other governance files are present as well, including CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and a pre-commit configuration, which is the level of formality you would expect from material intended to be reused by third parties.

Terms for prose and for code, and the non-commercial clause

Two sets of terms apply to two kinds of content, and the distinction is the most important thing on this page for anyone outside NVIDIA.

Written materials, named as user guides, documentation and presentations, are under Creative Commons CC BY-NC-SA 4.0. Code, meaning notebook code and coding examples, is under Apache 2.0, with the text at the top of the repository.

The asymmetry matters more than it first appears. That one is permissive and carries an explicit patent grant, so using it inside a product or an internal training pipeline is unproblematic, while CC BY-NC-SA carries three obligations: attribution, share-alike on derivatives, and non-commercial use. The third one is the constraint. If you charge for a course, if the prose is embedded in a paid product offering, or if your organisation's use is characterised as commercial, the written material is not available to you under those terms, while the code around it is.

Attribution and share-alike also persist: adapt a guide and you owe attribution and must distribute the adaptation under the same terms, which is a real obligation if you intend to edit a notebook into your own curriculum.

None of this is a criticism of the choice. An educational repository that reserves commercial use of its prose while opening its code is a coherent position, and separating the two licences makes it explicit rather than hidden in a single file. It simply has to be read before a curriculum is built on top of it, not after.

The syllabus model: courses sized in hours and days

The tutorials table is the index and it is structured as a course catalogue, with columns for content, a Docker Compose file, the Brev instance type required, and the provider that can supply it.

The titles carry the durations directly. There is a CUDA Python tutorial on CuPy, cuDF, CCCL and kernels at eight hours; another on CuPy, SIMT and Tile at eight hours; a shorter one on cuda.core and CCCL at two hours; a PyHPC course on NumPy, CuPy and mpi4py at four hours; and a longer PyHPC course covering CuPy, kernels, MPI, JAX, OpenMP and interop at two days.

Two observations follow. The accelerated-python track is a stack curriculum rather than a single course: it moves from library-level Python (CuPy, cuDF) through programming models (SIMT, Tile) through collectives and parallelism (CCL, MPI) to interoperability, which is a coherent progression for someone learning GPU Python properly rather than a single trick. And the durations are honest enough to plan around, since a two-day course cannot be squeezed into an afternoon.

Alongside the accelerated-python track sit courses in other domains: a CUDA C++ tutorial, a standard parallelism tutorial, an NVIDIA Warp tutorial, an nvmath-python tutorial, Sim2Real blogs, a GPU deployment tutorial written as a markdown guide, and a Newton robot tasks tutorial.

The diversity is the point. This is not one course with variations; it is a catalogue spanning C++, Python, math libraries, robot simulation and deployment.

Running the courses: Brev Launchables, Colab, a generated branch

The tutorials are interactive and can be run on two platforms, NVIDIA Brev or Google Colab, with documentation for creating and deploying Brev Launchables in docs/brev.md.

The Docker Compose column is where this repository shows unusual care. Most entries have a compose file checked in next to the course, such as tutorials/cuda-cpp/brev/docker-compose.yml, tutorials/stdpar/brev/docker-compose.yml, tutorials/warp/brev/docker-compose.yml and tutorials/sim2real-blogs/brev/docker-compose.yml. That means the environment is versioned with the course instead of being a set of blog posts about environment setup.

The syllabi entries work differently, and the difference is visible in the URLs. Several point at a generated branch rather than the main branch, for example a generated compose file for the CUDA Tile tutorial or the eight-hour CuPy, SIMT and Tile course. Generated compose files derived from notebooks is a reasonable design: the environment follows the notebook, so they cannot drift, and they are regenerated rather than edited by hand.

The consequence for a learner is that the compose file for a syllabus course is not something you will find in the directory next to the notebook. You either follow the generated link or run the notebook on Colab, which is the lower-friction path for a first pass and the path most people will take.

The GPU deployment tutorial has no compose file at all in the table, which fits a course that is about building a deployment rather than running a notebook.

Hardware requirements, stated per course

This is the part of the table that saves you the most time, and the part most course advertisements would leave out.

Single-GPU courses specify an instance type: L40S, L4, or T4 for the CUDA C++, Warp, Sim2Real, nvmath-python and several accelerated-python courses, and A10G for the CUDA Tile tutorial and the CuPy, SIMT and Tile course. The CUDA Tile path also lists A10G or newer Ampere, Ada or Blackwell hardware, which is a forward-looking requirement for a tile-based programming model.

Multi-GPU courses state exact shapes: 4xL4, 2xL4, 2xL40S, or 1x L40S. That is not a suggestion; a course configured for four devices will not run correctly on one, and a single-card learner is excluded from a meaningful share of this catalogue.

Software floors are given too, and they are precise. The standard parallelism course lists Linux 6.1.24+, 6.2.11+, or 6.3+ for HMM, which tells you the kernel version matters for that material. Several accelerated-python and PyHPC entries add that the host driver must support CUDA 13. The Newton tutorial goes further with an NVIDIA GPU with a CUDA 13.1-compatible driver, and it is the one entry that also documents a local CPU path, so you can follow it without a GPU at all.

Providers are listed as well, with AWS, Google Cloud, Crusoe and other providers named across the catalogue. Port flexibility is the recurring requirement, and it is what makes a four-GPU instance reachable from a container on a laptop.

What is inside each course, by domain

Mapping the catalogue to topics shows how broad it is, and where the depth lies.

The C++ and systems material is the CUDA C++ tutorial and the standard parallelism tutorial. The latter is about C++ standard parallelism on the GPU rather than about CUDA's own model, and its kernel-version floor is a reminder that it depends on the host system underneath.

The Python material is the deepest part: CuPy as the array library, cuDF for tabular data, CCCL for collective and parallel primitives, then SIMT and Tile as the two programming models, and cuda.core as a lower-level interface. The PyHPC courses add mpi4py, JAX, OpenMP and interop, which is the multi-node and multi-framework half of the story.

The domain-specific libraries get their own entries: NVIDIA Warp for what the README describes as a simulation-oriented framework, and nvmath-python for the math library.

Then there is the applied end. Sim2Real blogs cover simulation to real transfer, the Newton tutorial covers robot tasks, and the GPU deployment tutorial is a markdown guide on building a deployment from scratch rather than a notebook.

Read together, that is a curriculum from kernels to clusters to robots, with one course for the operational end that most academic material omits. Support questions are directed to the NVIDIA CUDA Developer Forums, on the accelerated computing category.

Where this hub is the wrong tool

It is a curated collection with real constraints, and the constraints are structural rather than fixable.

The first is hardware access. Courses requiring 4xL4 or 2xL40S are only runnable on a paid cloud instance with Flexible Ports, or on a cluster you already have. For a learner without either, the effective catalogue is much smaller than the table lists. That is not a criticism of the courses, it is a fact about who can complete them, and it is why the durations and instance types are printed next to every course rather than hidden.

The second is the non-commercial clause on written material, covered above. For a company building internal training from these guides, that clause is a blocker on the prose and not on the code, which is an awkward split to design a course around.

The third is currency. This is a curated collection tied to specific toolchains, with entries naming CUDA 13 and kernel floors for particular courses. A tutorial pinned to a library version teaches a version, and nobody curates that indefinitely, so expect to spend time reconciling a notebook with what is installed.

The fourth is that it is not a substitute for the official documentation. These are courses, and courses make pedagogical choices, including simplification. The reference material linked from CUDA documentation remains the place to check what an API actually does, and a course should not be the only source you trust for a production decision.

Editorial conclusion

Adopt this hub if you are running GPU training and want material that is scoped to hours rather than to a semester, because each entry declares its own duration and its own hardware, from a two-hour notebook on cuda.core and CCCL to a two-day PyHPC course on four L4s. Do not adopt it in a paid training programme without reading the terms, since the written guides are CC BY-NC-SA 4.0 and the non-commercial clause is exactly what an organisation selling courses trips over. Verify four things first. Match the hardware row, not the tutorial name: several entries require four L4s or two L40S, the standard parallelism course lists Linux kernel floors of 6.1.24, 6.2.11 or 6.3 for HMM, and several require a host driver supporting CUDA 13. Check where you will run them, since Brev Launchables and Google Colab are the two documented paths and the compose files are generated on a separate generated branch rather than committed next to the notebook. Decide which courses need a multi-GPU provider with port flexibility, which excludes a laptop. And confirm the split between prose terms and code terms before reusing a single slide. Start with the accelerated-python syllabus entry and see whether the hardware you have matches its row before planning a schedule around it.

Frequently asked questions

Official sources

1. Issues
2. NVIDIA/accelerated-computing-hub on GitHub
3. README