The kernel cache
The first time a kernel runs on a device, it is compiled, and for kernels with several exact implementations each one is timed. Both results are saved, so later runs start in about a second.
To do that work ahead of time, run dspk autotune or dspk.runtime.autotune(), or use File → Tune
this device in the app. It covers a grid of common sizes; a size off the grid still tunes when
it is first met.
Where it is
Section titled “Where it is”One SQLite database, default.db, in CubeCL’s folder of your cache directory:
| OS | Location |
|---|---|
| Linux, macOS | $XDG_CACHE_HOME/cubecl/, by default ~/.cache/cubecl/ |
| Windows | %LOCALAPPDATA%\cubecl\ |
| No user directory | The temporary directory, cubecl/ |
Controls
Section titled “Controls”| Setting | Effect |
|---|---|
DSPK_CACHE_DIR=/some/dir |
Puts the cache there (shared machines, CI, read-only home) |
DSPK_KERNEL_CACHE=0 |
No compiled-kernel cache; autotune decisions still persist |
Deleting the folder is safe: the next run tunes and compiles again. It grows with every runtime, device and kernel variant, to about 130 MB after the full test suite on three runtimes.
Don’t confuse it with LLVM
Section titled “Don’t confuse it with LLVM”The CPU runtime’s LLVM (~/.local/share/tracel) is a build-time download, not this cache. It’s bundled
in the Python wheel.
If a process aborts at exit
Section titled “If a process aborts at exit”An upstream issue (tracel-ai/cubecl#1981) can abort
a process after its work is done, with thread local panicked on drop (exit code 134). dsp-kitchen
works around it. Code that opens devices through CubeCL directly, or calls
dspk_core::compute::shutdown_devices itself, can still hit it; DSPK_KERNEL_CACHE=0 avoids it, at
the cost of compiling kernels in every process.