[Pfannkuchensack]

Summary

PyTorch's Linux CUDA wheel pulls in Triton, but the Windows wheel does not, so Windows NVIDIA installs had no Triton and every Triton kernel (today: SageAttention) needed a manual triton-windows install that a later sync removed again.

• The cuda extra now installs triton-windows>=3.7,<3.8 on Windows x64, matching the Triton that torch 2.13 is built against. Windows ARM64 is excluded (no wheel), so the ARM64 lock gate keeps passing.
• uv.lock adds only triton-windows 3.7.1.post27. The rest of the lock diff is uv rewriting dependency markers into equivalent simpler forms; no other package, version, wheel or source changes (checked by comparing old and new lock entries and evaluating every rewritten marker across all supported platform/extra combinations).
• The manual install guide now uses the cuda extra with --torch-backend=cu130 (Invoke 7+), which also pins the tested torch build; cu126 installs stay without the extra.
• SageAttention docs drop the manual Triton step for launcher installs; the FAQ entry on the Triton startup error now says which installs have no Triton.

Related Issues / Discussions

None.

QA Instructions

• uv lock --locked with uv 0.11.28 (CI's version): passes.
• scripts/check_platform_locks.py ./uv.lock: passes (linux/aarch64 and win32/ARM64, 0 packages missing a wheel).
• pytest tests/test_check_platform_locks.py: 16 passed.
• Fresh uv sync --locked --extra cuda --extra test on Windows x64: triton-windows 3.7.1.post27 imports with torch 2.13.0+cu130, the triton not found warning at startup is gone, and a Triton kernel compiled and ran correctly on an RTX 4090.
• Manual-install commands dry-run against PyPI (uv pip install --dry-run): "invokeai[cuda]==7.0.0a3" --torch-backend=cu130 resolves on win_amd64 and Linux x86_64 (torch 2.13.0+cu130); the documented cu126 commands without the extra still resolve; [cuda] with cu126 is unsatisfiable, which is why the guide restricts it to cu130.
• Docs site build not run.

Review

Fixed during review: the FAQ and SageAttention docs first claimed every NVIDIA install has Triton (Windows ARM64 does not) and listed Intel as having none (the xpu extra ships triton-xpu).

Remaining: on Windows x64 NVIDIA installs, diffusers and bitsandbytes now import Triton at startup (~80 ms); nothing is compiled at startup and no code path changes behavior because of it, the same as on Linux today.

Compatibility / Rollout

Launcher installs (uv sync --frozen --extra cuda) pick up Triton on the next update or repair. Users who installed triton-windows by hand are moved to the locked version.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[Pfannkuchensack]

Linux CUDA test run. Machine: Verda 2× NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GB, sm_120), driver 580.178.04, Ubuntu 26.04.1, torch 2.13.0+cu130, cuDNN 9.20, Triton 3.7.1. The PR head was compared with its merge base on main; each GPU ran one lane, pinned by UUID.

Linux unchanged, verified:

• uv sync --locked --extra cuda --extra test works.
• uv pip freeze is identical to the merge base.
• scripts/check_platform_locks.py ./uv.lock passes.
• FLUX/Krea-2 generations are bit-identical to the merge base.

[joshistoast]

yolo