Sggin/sage-attention-2.2-dgx-spark-aarch64-cu13

SageAttention 2.2 — DGX Spark aarch64 / CUDA 13 wheel

A community build of thu-ml/SageAttention v2.2.0 targeting NVIDIA DGX Spark (GB10, sm_121) on Linux aarch64 with CUDA 13. Also applies to any future aarch64 Linux host running consumer Blackwell silicon — SASS-level testing confirms the kernels emitted for this build execute byte-identically on RTX 50-series (sm_120a) and DGX Spark (sm_121a).

What this wheel is

• SageAttention v2.2.0, unmodified upstream source (no patches, no forks)
• Built with TORCH_CUDA_ARCH_LIST="12.0" against:
  • Python 3.12
  • PyTorch 2.10 / 2.11 (verify your install matches)
  • CUDA 13.x toolchain
  • Linux aarch64 (Ubuntu 24.04, glibc 2.39)
• cuobjdump --list-text confirms kernels target sm_120

Why sm_120 and not sm_121?

Upstream setup.py's SUPPORTED_ARCHS set does not include "12.1", so the build accepts "12.0" as the closest available target. This is the correct target, not a workaround: SASS-level testing on real hardware confirms that sm_120 (RTX 50-series, consumer Blackwell) and sm_121 (DGX Spark, GB10) emit byte-identical SASS for the consumer-Blackwell tensor-core paths used by SageAttention 2.2.

Evidence: Sggin1/DGX-SPARK/fp4_SASS — a SASS-encoder-level investigation of FP4 MMA support on Spark. Test B in findings.md demonstrates that the consumer-Blackwell warp-level MMA path (mma.sync.aligned.kind::mxf4.block_scale...) produces identical encoding 0x70f00e0c0808747f on both sm_120a and sm_121a. The same equivalence applies to the FP8 and INT8 paths exercised by SageAttention 2.2's _qattn_sm89 kernels.

Install

pip install https://huggingface.co/Sggin/sage-attention-2.2-dgx-spark-aarch64-cu13/resolve/main/sageattention-2.2.0-cp312-cp312-linux_aarch64.whl

(Adjust the repo URL after first push.)

Verify

python -c "import sageattention; print(sageattention.__file__)"

/usr/local/cuda/bin/cuobjdump --list-text \
  $(python -c 'import sageattention,os; print(os.path.dirname(sageattention.__file__))')/_qattn_sm80*.so \
  | grep -oE "sm_[0-9]+" | sort -u

Expected output: sm_120.

Reproduce the build

git clone https://github.com/thu-ml/SageAttention /tmp/sage22_build
cd /tmp/sage22_build
git checkout v2.2.0
TORCH_CUDA_ARCH_LIST="12.0" MAX_JOBS=8 python setup.py bdist_wheel

Wheel artifact lands in dist/.

Tested on:

• NVIDIA DGX Spark (GB10, sm_121, Ubuntu 24.04, driver 580.142)
• Python 3.12.x
• CUDA Toolkit 13.x
• PyTorch 2.10.x / 2.11.x (cu130 aarch64)

SHA256

2e570e87b9f2283820ae9ee86b05d5acc468fa7bf814016863770d7264d65e05  sageattention-2.2.0-cp312-cp312-linux_aarch64.whl

Source

Upstream: github.com/thu-ml/SageAttention (Apache 2.0)

This wheel is a build artifact of the upstream v2.2.0 release. No source modifications. License inherits Apache 2.0 from upstream — LICENSE in this repo is the upstream license file unchanged.

See also

• Sggin1/DGX-SPARK/fp4_SASS — SASS-level investigation of consumer-Blackwell FP4 / FP8 paths on Spark
• Sggin1/DGX-SPARK/comfyui_spark_notes — pip-shadowing gotchas to watch for when this wheel gets clobbered by transitive installs
• Triplany/comfyui-dgx-spark — practical ComfyUI integration kit for DGX Spark (community kit that builds and verifies this same wheel)

What this wheel does NOT do

• Does not enable the datacenter-Blackwell tcgen05.mma path (the "1 PFLOP FP4" marketing number). That instruction is ptxas-refused on sm_120a and sm_121a alike — it requires datacenter Blackwell silicon (B200, sm_100a). No software patch recovers it on consumer Blackwell. See fp4_SASS/findings.md Test A.
• Does not include any sm_121-specific patches to upstream SageAttention. The wheel is unmodified v2.2.0; the only difference from PyPI is the build target (12.0) and the host platform (aarch64 + CUDA 13).
• Does not address the SageAttention 3 mosaic-artifact issue on Spark (thu-ml/SageAttention#321). That's a separate kernel-level issue in the Sage 3 Blackwell path.

Disclaimer

Community wheel. Not an official NVIDIA, thu-ml, or HuggingFace release. Built on local hardware; verification output above is what the maintainer observed on their own Spark. Use at your own risk.