GPU Support

Paddock serves a GPU generation only after that generation has been brought up, tuned and benchmarked on the real hardware. Cards outside that list are refused at startup with a message naming what is supported. 37 of the 85 cards below are validated. Some of the rest have kernels in the build and can be forced to run; others have none at all, and the table says which is which.

Requirements

Paddock requires an NVIDIA driver that supports CUDA 13; the engine is built against the CUDA 13 API. You do not need the CUDA toolkit installed, only the driver. The server runs a model on a single GPU today.

The driver is the whole dependency. Paddock ships no NVIDIA maths libraries and fetches none at runtime: the executables import no NVIDIA library, the kernel pack imports only the operating system, and the binaries do not contain the names of cuBLAS or the CUDA runtime anywhere, so they could not ask for them. The one NVIDIA binary the engine loads is the display driver.

Find Your Card

This is the same table the Studio shows on its own GPU page, from the same list the engine checks at startup, so the answer here and the answer on your machine cannot disagree.

No card matches that.

What The Badges Mean

Both middle badges are refused at startup and the message looks similar, but only one of them can be overridden into working. Ada and Hopper have kernels in this build; the A100, Blackwell Ultra and the Jetson Thor boards do not.

Why The List Is Exact

Paddock matches your card's compute capability exactly, major and minor. It does not accept a card because the number is close, and this is deliberate: CUDA's own forward compatibility will happily load sm_120 code onto any 12.x device, so a GB10 appears to work right up until the first tensor-core kernel built for sm_120a specifically is launched, and then the request dies mid-flight. A startup check that refuses by name is the only version of this that does not waste your afternoon.

The same rule is why a generation moves onto the supported list only when its testing finishes. Serving on an untested die means either unknown performance or a failure partway through a request, and a clear "not yet" is better than either.

Running On An Unsupported GPU

Setting PADDOCK_UNVALIDATED_ARCH=1 serves anyway, for bring-up and testing. Every log line from such a run is stamped UNVALIDATED, so a number measured this way can never be mistaken for a supported result. Do not run production traffic this way.

It only helps a card marked Unvalidated. On one marked Not in this build there are no kernels to load, so the override changes nothing.

Not Supported At All

• AMD GPUs (ROCm) and Apple hardware (Metal).
• CPU inference. Paddock is a GPU engine; the CPU never runs the math.

GPU Kernels

Paddock's CUDA kernels are compiled into the runner, and the engine reads the device's capability at startup to pick the right one. The build carries native code for the generations the table marks Validated or Unvalidated, and for nothing else. Kernels are written per architecture rather than shared, which is where the performance comes from; see the published benchmarks for what that is worth on each board.

GPU Telemetry

The server samples GPU telemetry through NVML on a background thread, decoupled from inference. A snapshot is available at GET /api/gpu and a live stream over WebSocket at GET /api/gpu/stream; the embedded Studio uses the same feed. When NVML is not present the endpoint reports that telemetry is unavailable.