kernels

name	kernels
description	How prime-rl vendors, builds, and ships CUDA kernels (the `deps/prime-kernels` submodule and the `prime-kernels` wheel). Use when adding a kernel, building it locally, calling one from training code, or publishing prebuilt wheels.

CUDA kernels

CUDA kernels live in their own monorepo, prime-kernels, checked out here as the git submodule deps/prime-kernels, alongside prime-rl's other submodules. That repo is the wheel root (setup.py, pyproject.toml) and prime_kernels/ inside it is the importable package: one folder per kernel, holding the kernel's Python surface and, for compiled kernels, its C++/CUDA sources under csrc/, all declared in the single manifest prime_kernels/kernels.toml. See deps/prime-kernels/README.md once the submodule is initialized.

Nothing about a kernel lives in prime-rl. prime-rl pins a prime-kernels commit for local source builds and a prime-kernels release for installs. prime-kernels builds and publishes its own wheels. prime-rl stays a pure-Python wheel; never add compiled extensions to it.

Living under deps/ means tool.ruff.extend-exclude = ["deps"] in pyproject.toml already covers it — prime-rl lints none of it.

Calling a kernel from prime-rl

Kernels are compiled for exact compute capabilities and may not be built at all, so always gate. Never import prime_kernels.<name> directly in training code:

import prime_kernels

if prime_kernels.is_available("flash_moe"):
    flash_moe = prime_kernels.load("flash_moe")

prime_kernels.status() maps every kernel to or the reason it is not — log it once at startup rather than failing a run halfway through. is the same answer for one kernel ( when it is usable), which is what a test's skip guard wants; is just that call compared to .