transformer-engine-torch 2.13.0 (torch 2.8 / CUDA 12.8 / cp312)

Pre-built transformer-engine-torch PyTorch bindings, built from the upstream sdist because NVIDIA only publishes a source distribution for this package on pypi.nvidia.com.

Build matrix

Package version	2.13.0
Source	https://pypi.nvidia.com/transformer-engine-torch/transformer_engine_torch-2.13.0.tar.gz
Python	3.12 (cp312)
Torch	2.8.0+cu128
CUDA toolkit	12.8
Platform	linux x86_64
Build flags	NVTE_FRAMEWORK=pytorch, NVTE_NO_LOCAL_VERSION=1, --no-build-isolation

SHA256

39021a72775a0db890d6eb0a2368ee238c05c22bdc9b7871cd21fc36cd1145d4  transformer_engine_torch-2.13.0-cp312-cp312-linux_x86_64.whl

Usage (pixi)

transformer-engine-torch = { url = "https://github.com/evolutionaryscale/wheels/releases/download/transformer-engine-torch/v2.13.0-pt2.8-cu128-cp312/transformer_engine_torch-2.13.0-cp312-cp312-linux_x86_64.whl" }

Note: this wheel is ABI-locked to the build matrix above. Bumping torch minor, CUDA major, or Python minor requires a new wheel.

stream-ep v0.1.7 (depth-1 meta_head backpressure)

RDMA dispatch meta-ring head/tail backpressure — StreamEP PR #5 (commit fb92c5f).

• Adds per-(channel,dst) meta_head backpressure so meta-slab reuse waits on the slowest forwarder warp; kRdmaMetaRingDepth becomes a run-ahead throughput knob rather than a correctness parameter.
• Verified 2-node (world=16): internode correctness (dispatch / dispatch_grads / combine), validate_multi_iter 20/20 fwd+bwd, intranode integration + pytest suites all green.
• Known limitation: does not resolve the production-depth internode_dispatch CPU timeout hang — it is pre-existing (reproduces identically on main) at 82ba5b depth.

Build: cp312, cu128 ABI, linux_x86_64. Supersedes v0.1.6.

stream-ep v0.1.6 (num_sms auto-pick / EP=16 IMA fix)

Fixes the EP=16 (2-node, num_rdma_ranks=2) illegal memory access caused by a num_sms auto-pick vs comm-buffer sizing mismatch. Built from chanzuckerberg/StreamEP main @ 311b6ff (PR #3). Supersedes v0.1.5.

quack-kernels v0.4.1+czi.0 (streaming-MoE hooks)

Pure-Python wheel of quack-kernels built from our chanzuckerberg fork of Dao-AILab/quack at the v0.4.1 substrate + 2 additive streaming-MoE hooks.

Source

• Repo: chanzuckerberg/quack (private — code review history lives there)
• Branch: jaime/v0.4.1-port
• Tag: quack-upgrade-v0.4.1-baseline (commit 63895f9)
• Net commits over upstream v0.4.1:
  • 96cba3d fork: pin version to 0.4.1 to work around dynamic-version build issue
  • b5da96e gemm_base: extract per-subtile R2S → SMEM → store into epi_subtile_store hook
  • 63895f9 varlen: add mLensK to decouple per-batch K-length from cu_seqlens_k offsets

Why the wheel lives here, not on the fork

The source repo chanzuckerberg/quack is private and the user-token perms needed to grant it visibility to pixi/uv url= fetches aren't available org-wide. evolutionaryscale/wheels is public, so the URL is anonymously fetchable by everyone's pixi install + CI without per-machine netrc/token setup. The source-of-truth for code review + iteration still lives at chanzuckerberg/quack; only the binary wheel artifact is republished here.

What's in the wheel

quack_kernels-0.4.1-py3-none-any.whl (262 KB, py3 / none / any).
SHA256: 5491795e1ceffae58af85c3f1cf955f7ab161bc33309b358af17b77295e6d953

Default behavior is byte-identical to upstream Dao-AILab/quack v0.4.1. The two added hooks (epi_subtile_store extension point on GemmBase, mLensK field on VarlenArguments) are inert unless an explicit subclass-override or lens_k= kwarg is supplied — so sonic-moe and any other consumer continues to work unchanged.

Consumption (pixi.toml)

quack-kernels = { url = "https://github.com/evolutionaryscale/wheels/releases/download/quack-kernels%2Fv0.4.1%2Bczi.0/quack_kernels-0.4.1-py3-none-any.whl" }

(/ URL-encodes to %2F, + to %2B.)

py312-pt211-cu13-sm80-90

pixi.toml githash c98341046b1062cef41e594571a31a1399fb6493

These wheels were build with pixi install -e wheel-builder and removing the CUDA_HOME env in the pixi.toml.

• ~/.cache/rattler/cache/uv-cache/*/*/*/*/*.whl
• ~/.cache/rattler/cache/uv-cache/*/*/*/*.whl

nvshmem v3.5.19-1+czi.0 (DeepEP recv-queue patch)

Patched NVSHMEM v3.5.19-1 + DeepEP IBGDA recv-queue patch (forward-ported from the original DeepSeek v3.2.5 patch series). Two wheels — the host/device libs and the Python bindings.

Source

• Repo: chanzuckerberg/nvshmem (private mirror of NVIDIA/nvshmem)
• Branch: czi/v3.5.19-1-patched (commit 50a377a)
• Tag: v3.5.19-1+czi.0
• Patch: forward-port of DeepEP's NVSHMEM patches from v3.2.5 → v3.5.19-1; CQ-allocation refactor handled in the port.

The patch series (squashed into one commit on the fork):

• 0001 — Shangyan Zhou — Change QP creating order
• 0002 — Shangyan Zhou — Add recv queue and recv cq for rc qps
• 0003 — Shangyan Zhou — Maintain recv queue's cons_idx
• 0004 — Shangyan Zhou — Init rx_wq counters
• 0005 — Kaichao You — Remove gdrcopy dependency

Why the wheels live here, not on the fork

chanzuckerberg/nvshmem is private (NVIDIA NVSHMEM source bundled — keeping it private out of caution rather than necessity; the source itself is publicly available at NVIDIA/nvshmem). Pixi/uv url= fetches can't authenticate against private repos without per-machine setup, so the binary wheels are republished to evolutionaryscale/wheels (public) for anonymous fetch by every developer + CI run.

What's in the wheels

nvidia-nvshmem-cu12==3.5.19+patched

nvidia_nvshmem_cu12-3.5.19+patched-py3-none-manylinux_2_34_x86_64.whl (110 MB).
SHA256: 00b144a75a3cf92ac33a62fc8aa697d8119f9e53f0c0bbbc24071b80329779c3

Same on-disk layout as NVIDIA's upstream nvidia-nvshmem-cu12==3.5.19 wheel. PEP 440 local-version +patched is treated as preferable to upstream 3.5.19 while still satisfying any ==3.5.19 constraint.

nvshmem4py-cu12==0.2.1 (Python 3.12 bindings)

nvshmem4py_cu12-0.2.1-cp312-cp312-manylinux_2_34_x86_64.whl (1 MB).
SHA256: 9f81b28c69346ca0ebb14f6f27fb11ca3523f59fc5289c4f6dd11132c19f7c9b

Patch fingerprint

The built lib/nvshmem_transport_ibgda.so.4.0.0 contains the unique string "ibgda_create_cq failed for recv_cq (DeepEP patch)". Verify with:

grep -aF "ibgda_create_cq failed for recv_cq" $PREFIX/lib/nvshmem_transport_ibgda.so.4.0.0

Consumption (pixi.toml)

nvidia-nvshmem-cu12 = { url = "https://github.com/evolutionaryscale/wheels/releases/download/nvshmem%2Fv3.5.19-1%2Bczi.0/nvidia_nvshmem_cu12-3.5.19+patched-py3-none-manylinux_2_34_x86_64.whl" }
nvshmem4py-cu12     = { url = "https://github.com/evolutionaryscale/wheels/releases/download/nvshmem%2Fv3.5.19-1%2Bczi.0/nvshmem4py_cu12-0.2.1-cp312-cp312-manylinux_2_34_x86_64.whl" }

Rebuilding from source

See czi/README.md and czi/build.sh on the czi/v3.5.19-1-patched branch of chanzuckerberg/nvshmem. The wheels here were built from the patched commit on May 13; rebuilding from HEAD produces byte-equivalent libs (modulo timestamps in wheel metadata).

flash-attn-pt28-cu12

built with the evolutionaryscale/pixi.toml at e5d94aa6f41d77c8720ec16f490344ddc710f02b.
and

flash-attn = "==2.7.4.post1"

esmfold2-anthropic-kernels v0.2.2

native_trimul: per-call workspaces (fixes per-Np GPU leak); bounded ArgPack.keep. Source: evolutionaryscale/esmfold2-anthropic-kernels@9058e36

esmfold2-anthropic-kernels v0.2.1

Multi-cell CuTe pair transition: one sm_90a cubin per hidden width (1024 and 640), each 168 registers and 0 spill bytes, each sealed with its own canary digest. ESMFold3 (expansion 2.5 -> hidden 640) is served natively. Supersedes v0.2.0, which also shipped a hidden-320 cubin that nothing could dispatch to: the unserved ESMFold3 modules differ in PAIR width (d_model 128), which no hidden cell can reach. Source repo: evolutionaryscale/esmfold2-anthropic-kernels@a711a1a

esmfold2-anthropic-kernels v0.2.0

Multi-cell CuTe pair transition: one sm_90a cubin per hidden width (1024 / 640 / 320), each 168 registers and 0 spill bytes, each sealed with its own canary digest. ESMFold3 (expansion 2.5 -> hidden 640) is now served natively. Source repo: evolutionaryscale/esmfold2-anthropic-kernels@d7fc0b7