Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · September 14, 2026 · repo

ZLUDAAMD ROCmLibTorchSpeedstu/CUDA-for-AMD-Windowslocal-aiagent-infrastructure

CUDA-for-AMD-Windows: The ZLUDA Stack That Validated One GPU and Said So

A Windows repo that wires ZLUDA, AMD's HIP SDK, and LibTorch together, then tells you the one card it works on and the one library it cannot give you

A repository whose README opens with "WORKING REPRODUCIBLE STACK IS NOW UPLOADED" in capital letters would normally be the kind you close in ten seconds. Then you get to the second paragraph and it says the validated hardware is one graphics card, the Radeon RX 9060 XT, and that every other AMD GPU is a candidate, not a guaranteed working device. A page later it tells you cuDNN is unavailable on the stack it ships. Most "CUDA on AMD" projects promise the moon and hand you a segfault. This one hands you a scope statement.

Speedstu/CUDA-for-AMD-Windows reached the Hacker News front page on September 13. It is small, it is new, it has no releases, and the reason it is worth an article is that its author did the thing almost nobody in the local-AI compatibility space does: wrote down what was tested, what was not, and which version of every layer was under the test.

What it actually is

Strip the capital letters and the repo is a set of PowerShell scripts plus documentation. It does not reimplement CUDA. It wires together three pieces of other people's software into a runtime that a CUDA-targeted Windows application can be launched against:

ZLUDA, the open project that translates CUDA calls to AMD's HIP, pinned to the official v6-preview.69 Windows release (a May 4 pre-release whose entire changelog is one typo fix). AMD's HIP SDK for Windows, version 6.4, which you install yourself. And LibTorch 2.3.0 with the cu118 CUDA build, which the installer downloads (about 2.66 GB) for anyone who wants CUDA-facing PyTorch on the AMD card.

The stack diagram in the README is honest about what sits where:

CUDA-targeted Windows application
              |
            ZLUDA
              |
 cuBLAS / cuSPARSE / cuFFT compatibility
              |
 rocBLAS / hipBLASLt / rocSPARSE / HIP
              |
           AMD GPU

install.ps1 detects the GPU and its gfx target, verifies the driver and HIP libraries, downloads the pinned ZLUDA build and LibTorch, checks their SHA-256 hashes, writes a runtime config and a GPU report, and runs ZLUDA's own cuda_check.exe against the result. run-zluda.ps1 stages the compatibility DLLs beside the target executable and sets the HIP paths for that one run. doctor.ps1, gpu-scan.ps1, and test-runtime.ps1 are the diagnostics. Project-owned scripts are MIT; ZLUDA, ROCm, the CUDA components, and LibTorch keep their own licenses.

That is the whole thing. No custom DLLs, no forked ZLUDA, no magic.

What "validated" means here

The word does a lot of work in this repo, so it is worth reading exactly what it covers. The validation document is dated September 13 and names the full stack: Windows x64, RX 9060 XT (gfx1200, RDNA4), ZLUDA v6-preview.69, HIP SDK 6.4, LibTorch 2.3.0+cu118, ZLUDA_CC=8.6, and, in bold, no recovered or custom overlay DLLs.

cuda_check.exe reported nvcuda, cuBLAS (via rocBLAS), cuBLASLt (via hipBLASLt), cuSPARSE (via rocSPARSE), and cuFFT as OK. cuDNN 8 and 9: unavailable on this stable Windows HIP SDK configuration.

Then the integration test, which is the part that separates this from a device-enumeration demo. The generated runtime was staged next to an existing CUDA-enabled LibTorch PPO trainer. The run logged a 2,216,347-parameter model, three fused CUDA kernels reporting ready, 65,536 collected timesteps, one PPO learn phase of about 5.6 seconds, and one completed iteration at 8,428 overall steps per second before the author stopped it. The document says in so many words that the purpose was reproducibility validation, not a throughput benchmark, and that older tuned runs of the same family reached roughly 70,000 to 109,000 steps per second under a different training configuration. It then lists what the test does not prove: cuDNN-dependent applications can fail, unsupported PTX and CUDA APIs may fail, custom CUDA extensions are workload-specific, other AMD architectures remain unverified until tested.

I have read a lot of compatibility READMEs. This is the first one I can remember that has a section titled "What this does not prove."

The A/B against its own history

There is a second honest thing in the repo, and it is the one I would point a skeptic at. The project started life with a custom cuBLAS/cuBLASLt/HIP overlay, recovered DLLs whose source and provenance the author says are incomplete and which contain third-party AMD binaries. Those DLLs are fingerprinted in manifests/recovered-artifacts.sha256 and deliberately not published.

On September 13 the author ran a controlled A/B, ten iterations per runtime on the same RX 9060 XT PPO workload, discarding the first iteration as warmup. The public upstream path reached 13,278 median overall steps per second. The recovered custom overlay reached 12,876. The custom overlay was about 3 percent slower, so upstream stays the default.

Read that again from the author's side. The special sauce lost to the boring path, and the repo says so in the Performance section rather than burying it. That is the discipline I mean when I say the product is the validation, not the stack.

The two pins that decide what you can run

Here is where the repo's honesty pays off for you, because the two version pins in the validation document are also its ceiling.

LibTorch 2.3.0 is the April 2024 PyTorch release. It is old. Anything that needs a newer torch (recent transformers features, newer attention kernels, torch.compile improvements from the last two years) is out of scope until someone re-validates a newer LibTorch on this path, and the README says newer HIP SDK versions "should be treated as unverified until reported." If your goal is a current llama.cpp or vLLM-class inference server, this is not that.

The second pin is the stable Windows HIP SDK, which does not ship MIOpen, so there is no cuDNN. The README is precise about what that costs: convolution-heavy software that requires cuDNN "can need a newer/nightly HIP stack or additional work," while dense, GEMM-heavy LibTorch training does not necessarily need it. The validated PPO workload completed without it. So: MLP and transformer-style dense compute through cuBLAS and cuBLASLt, yes; CNN training and any model whose hot path is convolution, no, or not yet.

The remaining limitations are listed, not hidden: ZLUDA is not a complete CUDA implementation, Windows exposes a subset of ROCm, NCCL and TensorRT and some custom CUDA extensions may fail, and ZLUDA_CC=8.6 is a CUDA-facing compatibility value, not the AMD architecture.

Put this into practice

If you have an AMD card on Windows and a CUDA-only binary you cannot rebuild, this is the lowest-friction path I have seen to finding out whether it runs, because the diagnostics come first.

Start with the scanner before the installer. Install a current AMD driver and the HIP SDK 6.4 with HIP Libraries, clone the repo, and run:

.\scripts\gpu-scan.ps1
.\scripts\doctor.ps1

The scanner prints your card, its gfx target, and one of two statuses: validated-reference (only the RX 9060 XT today) or unverified candidate. If you see the second, you are the experiment. That is fine, but know it before you download 2.66 GB.

Then the installer, skipping LibTorch unless you need CUDA-facing PyTorch:

powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -SkipLibTorch
.\scripts\test-runtime.ps1

test-runtime.ps1 treats the five core groups (nvcuda, cuBLAS, cuBLASLt, cuSPARSE, cuFFT) as pass/fail and reports cuDNN separately. If cuDNN is the one your application needs, stop here and save the afternoon.

Finally, launch the real thing against the staged runtime:

.\scripts\run-zluda.ps1 -Program C:\path\to\app.exe

Whether it works or fails, the repo asks you to file a GPU compatibility report from the scanner's JSON output, and it says failed tests are useful too. If you have a card other than the 9060 XT, that report is the most valuable thing you can contribute; the project's stated plan is to grow evidence one GPU and one application at a time.

One habit to take away regardless of whether you ever touch this repo: pin every layer, hash every download, and write down the single configuration you actually ran. The validation document here is a template you could copy for any local-AI setup guide.

Honest limitations

Everything in the validation is one author, one machine, one card. The RX 9060 XT is the entire tested surface, and the repo's own scanner will tell you so for any other GPU. A CI badge exists, but the training-workload validation is a manual run on September 13, not something CI reproduces.

The performance numbers are from a PPO trainer the author wrote, not a standard benchmark, and the historical 70,000 to 109,000 steps-per-second figures come from a different training configuration than the validation run, which the document flags but which makes them hard to compare with anything else.

The version pins are the ceiling. LibTorch 2.3.0 is more than two years old, and the repo offers no validated path to a newer torch or to the nightly HIP stack that would bring MIOpen. If you need cuDNN, this repo currently tells you to look elsewhere.

ZLUDA itself is a preview series. The pinned release's changelog is a one-line typo fix, which says nothing about stability either way; it says the pin was chosen for reproducibility, not for features.

And the star count is small, in the low hundreds and disagreeing across trackers by about 20 percent on the afternoon I checked, so there is no community-scale evidence yet of how many cards beyond one this works on.

Where this leaves you

The stack this repo ships is modest: three upstream components, some scripts, and a validated path on one GPU. What it models is not modest. It names its scope, publishes the A/B where its own custom work lost, fingerprints what it will not distribute, and keeps a document titled "What this does not prove."

If you have the card, run the scanner tonight. If you have a different card, run it anyway and file the report; the project has told you plainly that it needs that data more than it needs stars. And the next time a compatibility README promises everything, look for the section that lists what was actually tested. If it is missing, you already know something.

Sources: Speedstu/CUDA-for-AMD-Windows README, docs/VALIDATION.md, ZLUDA v6-preview.69 release, PyTorch v2.3.0 release, Hacker News thread.

Medium metadata

  • Title: CUDA-for-AMD-Windows: The ZLUDA Stack That Validated One GPU and Said So
  • Subtitle: A Windows repo that wires ZLUDA, AMD's HIP SDK, and LibTorch together, then tells you the one card it works on and the one library it cannot give you
  • Tags: AMD, CUDA, Local LLM, Open Source, Machine Learning
  • Canonical: fervorai.dev article URL once published
  • Hero image: a single graphics card on a lab bench under a clip-on lamp, a hand-lettered tag reading "tested", Ralph Steadman style, no other text