Add sm_121a (NVIDIA GB10 / DGX Spark) to the NVFP4 build targets

Open Beginner friendly
  • Is something wrong?
#336 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
build-system

Research direction

Start in packages/ltx-kernels/setup.py: read the comment above _NVFP4_ARCHES and the _nvfp4_gencode() function that maps TORCH_CUDA_ARCH_LIST tokens to arch names. Add "121a" to the list and a branch for tokens starting with "12.1". Done when building with TORCH_CUDA_ARCH_LIST=12.1 produces an extension whose cuobjdump output includes sm_121a. The optional warning for arches that map to nothing can be a separate change.

Written by the indexing model from the issue text.

Description

First, thanks for shipping ltx-pipelines with the split checkpoints and the opt-in ltx-kernels build — getting LTX-2.5 running on a non-datacenter Blackwell box was refreshingly straightforward, and the FP8/NVFP4 notes in setup.py are unusually clear about why the arch-specific targets matter.

I'd like to propose adding one more Blackwell target: sm_121a, which is the NVIDIA GB10 used in the DGX Spark. It looks like a two-line change, and everything needed on the toolchain side is already in place.

What happens today

On a GB10 (compute capability 12.1), the NVFP4 path builds and imports fine, but the first quantize_nvfp4 call fails:

torch.AcceleratorError: CUDA error: no kernel image is available for execution on the device
  ltx_kernels/nvfp4/functional.py -> _quantize_op -> quantize_nvfp4

cuobjdump --list-elf on the built extension shows:

sm_100a sm_110a sm_120a

which matches _NVFP4_ARCHES in packages/ltx-kernels/setup.py. The device is sm_121, so no image matches.

The toolchain already supports it

Using the pinned nvidia-cuda-nvcc wheel that --group kernels installs (CUDA 13.2):

$ nvcc --list-gpu-arch | tr ' ' '\n' | grep 121
compute_121

And — this is the part that matters given the comment above _NVFP4_ARCHES about software emulation on non-a targets — the hardware conversion intrinsic is emitted for sm_121a. Compiling a one-liner that calls __nv_fp4x2_e2m1(float2):

target cvt.rn.satfinite.e2m1x2 in PTX
sm_120a yes
sm_121a yes
sm_110a yes

So sm_121a gets the same hardware E2M1 path as the other three — no fallback to the 1312-instruction software emulation described in the comment.

Suggested change

In packages/ltx-kernels/setup.py:

-_NVFP4_ARCHES = ["100a", "110a", "120a"]
+_NVFP4_ARCHES = ["100a", "110a", "120a", "121a"]

and in _nvfp4_gencode():

         elif tok.startswith("12.0"):
             sel.append("120a")
+        elif tok.startswith("12.1"):
+            sel.append("121a")
One small UX note that might be worth a line of its own

Without the second hunk, setting TORCH_CUDA_ARCH_LIST=12.1 doesn't raise — _nvfp4_gencode() returns an empty list, the extension is skipped entirely, and the failure only surfaces later as the no kernel image error at generation time. A warning when a requested arch maps to nothing would make that much easier to diagnose. Entirely optional, and I realise the current behaviour is deliberate for toolchains too old to emit Blackwell code.

Happy to help

I have a GB10 box and I'm already building this from source, so I'm glad to test a branch or open a PR with the two hunks above — whichever is more useful to you. I can also report back generation numbers (nvfp4 vs bf16, same prompt and seed) on GB10 if that's of interest; the practical pull for us is memory: ~18.7 GB for the distilled NVFP4 transformer vs ~42 GB for bf16, which is the difference between LTX co-existing with another model on one 128 GB box or not.

Thanks again for the work — and for making the kernels opt-in and the arch logic readable enough to diagnose this from the outside.

Dominant language
Python
Stars
10k
Forks
1.6k
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Lightricks/LTX-2

All issues in Lightricks/LTX-2

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.