flash-attn-wheels

flash-attention family prebuilt wheels (mirror)

Byte-identical mirror of prebuilt attention wheels that Odyssey training projects install, re-hosted on the Hugging Face CDN because the GitHub release-asset endpoint they used to be fetched from times out mid-download often enough to break uv sync.

Nothing under wheels/ is rebuilt or repackaged (see wheels-repacked/ below for the one exception). Each file there is the exact upstream artifact, so a uv.lock hash pinned against the original GitHub URL keeps validating after the URL swap.

Consuming

Reference a wheel by direct URL in [tool.uv.sources]:

flash-attn = [
    { url = "https://huggingface.co/gueraf/flash-attn-wheels/resolve/main/wheels/v2.8.3/flash_attn-2.8.3+cu12torch2.9cxx11abiTRUE-cp312-cp312-linux_x86_64.whl", marker = "python_full_version == '3.12.*' and platform_machine == 'x86_64' and sys_platform == 'linux'" },
]

The repo is public, so no HF_TOKEN is needed at install time.

Paths keep the upstream release tag as a directory (wheels/<upstream-tag>/<filename>). That is load-bearing: dev-c914365-p1 and dev-c914365-p2 both publish a wheel named flash_attn-2.8.3+cu12torch2.9cxx11abiTRUE-cp310-cp310-linux_x86_64.whl, and a flat layout would silently collapse the two into one.

Contents

wheels-repacked/ — local-version metadata fixed

The +cu…abiTRUE/FALSE builds under wheels/ carry a local version segment in the filename that their METADATA Version: and .dist-info directory name do not (e.g. filename 2.8.3+cu12torch2.9cxx11abiTRUE, METADATA 2.8.3). uv takes the expected version from the filename and the installed version from the dist-info, so every uv run / uv sync uninstalls and reinstalls them — it never converges.

wheels-repacked/<upstream-tag>/<same filename> holds the same wheels with exactly two changes:

• METADATA Version: set to the filename's full version (local segment included);
• <name>-<version>.dist-info/ renamed to match, and RECORD regenerated for the new paths.

Every other archive member is byte-identical in content — each was verified against the original wheel's RECORD hash while repacking. Filenames are unchanged, so the tag directories still keep dev-c914365-p1/-p2 apart. These are not byte-identical to the original upstream release assets. Their byte-identical GitHub twins are the releases gueraf/flash-attention@repacked-<upstream-tag> (same filenames), which Odyssey resolves by default: GitHub's asset CDN is cacheable by uv, whereas HF resolve/ answers cache-control: no-store and uv re-downloads on every run. The originals under wheels/ are kept unchanged.

Verified with uv 0.11.32: against the original URL, uv sync --dry-run -v reports Installed version does not match resolved version … 0.1.0 vs. 0.1.0+cu12torch2.9cxx11abitrue and a reinstall on every run; against the repacked URL it reports Requirement already installed / Would make no changes.

integrity records how each file was checked when mirrored:

• lock-pinned — the sha256 above equals the hash an existing uv.lock in the odyssey repo already pinned for the upstream URL, so the bytes are provably the ones every project was already resolving.
• CRC-only — no uv.lock pinned this URL (the pyprojects referencing it resolve x86_64-only, so the aarch64 wheel never entered a lock). It was verified by a full zip CRC pass instead. Flagged rather than filled in from the row beside it, because an unfalsifiable check is worse than a named gap.

An HTTP 200 is not integrity evidence here: one wheel in this set first arrived truncated (209,605,440 of 253,510,452 bytes) with a 200 status, and only the sha256 comparison caught it.

Adding a wheel

Download from upstream, verify its sha256 against the upstream checksum or an existing lock pin, upload under wheels/<upstream-tag>/ keeping the original filename, and add a row above.