[feat] Add native SM103a VSA support

[lishunyang12]

Purpose

Enable the native MiniMax-H3 VSA forward on B300/GB300 (SM103a) instead of falling back to Triton. The existing SM100a Python/module/environment names remain unchanged for compatibility.

Changes

• Build the shared data-center Blackwell VSA source into both SM100a and SM103a cubin images.
• Recognize compute capability 10.3 in build-time detection and runtime dispatch.
• Keep non-data-center Blackwell device passes behind the existing architecture guard.
• Extend correctness, dispatch, FastH3 routing, benchmark, packaging, and documentation coverage to SM103a.

Test Plan

pre-commit run --all-files
python -m pytest -q \
  tests/test_block_sparse_sm100a.py \
  tests/test_block_sparse_sm100a_dispatch.py \
  tests/test_fasth3_packaging.py
python -m pytest -q fastvideo/tests/attention/test_vsa_h3_sm100a_route.py
python tests/bench_block_sparse_sm100a.py

The CUDA wheel was also built locally and inspected with cuobjdump to verify that both SM100a and SM103a images contain the 64-token and 128-token VSA kernels.

Test Results

B300 correctness and performance

pre-commit: all hooks passed
kernel/dispatch/packaging: 47 passed
FastH3 route, odd-block transport, and fullgraph: 25 passed

B300 kernel benchmark, seq_len=109632, heads=7, head_dim=128,
logical blocks=1713 (padded to 1714), prefix_blocks=8, topk=64:
Triton p50:       4.922096 ms
Native SM103a:    2.219104 ms
Speedup:          2.2181x
max_abs:          0.00390625
relative_l2:      0.00328595

8x B300 FastH3 E2E, USP=8, Ring=1, 1344x768, 24 FPS,
4 inference steps, seed=1101, one excluded warmup plus one measured request:
10 s: dense 7.902 s, VSA 6.270 s, 1.26x
15 s: dense 12.817 s, VSA 8.480 s, 1.51x

All generated videos completed and decoded successfully. The main DiT used the native FastVideo VSA path; the short token-refiner used the expected dense SDPA fallback.

GPUs 4-7 had unrelated resident processes holding memory during the E2E A/B, although they showed 0% SM utilization before and after the run. The paired comparison used identical conditions; the kernel correctness and direct benchmark were validated independently.

Generated videos

Requested duration	Before: Dense	After: native SM103a VSA
10 s	dense-10s.mp4	vsa-sm103a-10s.mp4
15 s	dense-15s.mp4	vsa-sm103a-15s.mp4

The complete output metadata and SHA256 checksums are in the
artifact README.

Checklist

• I ran pre-commit run --all-files and fixed all issues
• I added or updated tests for my changes
• I updated documentation if needed
• I considered GPU memory impact of my changes

Model/pipeline-only SSIM and support-matrix checks are not applicable to this kernel architecture extension.

[mergify]

Merge Protections

🔴 1 of 1 protections blocking · waiting on 🤖 CI

	Protection	Waiting on
🔴	PR merge requirements	🤖 CI

🔴 PR merge requirements

Waiting for

• check-success=fastcheck-passed
• check-success=full-suite-passed

This rule is failing.

• check-success=fastcheck-passed
• check-success=full-suite-passed
• #approved-reviews-by>=1
• check-success~=pre-commit
• title~=(?i)^\[(feat|feature|bugfix|fix|refactor|perf|ci|doc|docs|misc|chore|kernel|new.?model|skill|skills|infra)\]

[github-actions]

Welcome to FastVideo! Thanks for your first pull request.

How our CI works:

PRs run a three-tier CI system:

1. Pre-commit — formatting (yapf), linting (ruff), type checking (mypy). Runs immediately on every PR.
2. Fastcheck — six core GPU lanes run automatically via Buildkite (~10-15 min).
3. Merge gate — a reviewer adds ready; changed paths select only the relevant integration, training, golden, or SSIM coverage.

Before your PR is reviewed:

• pre-commit run --all-files passes locally
• You've added or updated tests for your changes
• The PR description explains what and why

If pre-commit fails, a bot comment will explain how to fix it. Fastcheck and merge-gate results appear in the Checks section below.

Useful links:

• Contributing Guide
• Development Roadmap
• Slack

[alexzms]

Looks good to me.