[feat] bump to 1.3.0: torch 2.12.1 / torchrec 1.7.0 / fbgemm 1.7.0 / numpy 2 (+ cu130 TRT)

[tiankongdeguiji]

TorchEasyRec 1.3.0 — torch 2.12.1 / torchrec 1.7.0 / fbgemm 1.7.0 / numpy 2

Upgrades the dependency stack (including the numpy-2 migration) and cuts the 1.3.0 release, adding a CUDA-13 + TensorRT image.

Dependency stack

Component	Old	New
tzrec	1.2.21	1.3.0
torch	2.11.0	2.12.1
triton	3.6.0	3.7.1 (ptxas-swapped, see below)
fbgemm_gpu	1.6.0	1.7.0
torchrec	1.6.0	1.7.0
torch_tensorrt	2.11.0	2.12.1 (cu130 only)
numpy	<2	unconstrained (numpy 2)
dynamicemb	…e0c1fbb	…5dc46a2.cu130
fbgemm_gpu_hstu	…+cu12.9	…9fd44403
CUDA images	cu126 / cu129 / cpu	+ cu130 (CUDA 13 + TRT)
Docker image tag	1.2	1.3

numpy 2 migration

Drops the numpy<2 cap. graphlearn 1.3.7 → 1.3.8 (numpy-2 sampler), pandas unconstrained, faiss 1.14.3 (cu12/cu13). Source fix: np.string_ → np.bytes_ (removed in numpy 2). All device images resolve and import cleanly on numpy 2 with no scipy / scikit-learn source builds.

triton 3.7.1 — bundled ptxas WGMMA fix (H20 workaround removed)

Stock triton 3.7.1 bundles ptxas 12.8.93, which mis-compiles the HSTU WGMMA kernel on sm_90 (Hopper/H20) into a shared-memory OOB — an illegal memory access in _hstu_attn_bwd during autotuning. This was introduced when release/3.7 downgraded ptxas 12.9.86 → 12.8.93 (commit 6c96454f2f); it is not the triton#9514 sync bug (verified: #9514 alone does not fix it). The 1.3.0 image ships a repackaged triton 3.7.1 wheel with ptxas swapped back to 12.9.86 — only the ptxas binary is replaced, preserving the manylinux wheel torch's inductor is coupled to — so it is default-on, needs no DISABLE_MMA_V3, and keeps Hopper v3 perf.

The DISABLE_MMA_V3 / _force_mma_v2 test workaround is removed: the HSTU tests now run the shipped v3/WGMMA path (validated on a real H20 — the four previously-gated tests pass with 0 failures / 0 errors), so unittest_h20_ci now guards the ptxas fix against regression. FAQ Q15 rewritten accordingly. The DISABLE_MMA_V3 runtime knob is retained as an escape hatch.

CUDA 13 + TensorRT image

New cu130 image (also the default tzrec-devel:1.3 / :latest): the CUDA 13.0 toolchain on the cu129 software stack, plus torch_tensorrt 2.12.1 / TensorRT 10.16 for TRT export and inference. cu126/cu129 stay TRT-free (torch_tensorrt 2.12 has no CUDA-12 build) and degrade gracefully (has_tensorrt=False, as the cpu image already does); AOTI export/predict is unaffected.

Required source changes

• tzrec/optim/optimizer.py — re-sync the apply_split_helper monkeypatch to fbgemm 1.7.0. It gained make_persistent / preallocated_host_buffer params and its internal TBE caller now passes them, so the old override raised TypeError on every fused-embedding table construction. The tzrec momentum1 (TF-Adagrad) init customization is preserved.
• tzrec/acc/aot_utils.py — keep the pytorch#178147 inductor int-array-dedup backport (still absent in torch 2.12.1; lands in 2.13.0+).
• tzrec/utils/dynamicemb_util.py — restore the None→[] coercion torchrec 1.7.0 dropped for EmbeddingCollectionContext list-fields (dynamicemb still forwards None, which otherwise breaks the sharded EC forward).
• torchrec 1.6→1.7 and torch 2.11→2.12.1 private APIs otherwise need no source change (the only torchrec removal, TrainPipelineContext.output_dist_embeddings_requests, is unused by tzrec).

Build / infra

• Dockerfile: PIP_MIRROR default → mirrors.aliyun.com; cu130 nvidia-* / cuda-toolkit metadata handling; dropped the executorch metadata strip (unnecessary once numpy is unconstrained).
• RDMA userspace-driver installer moved to the hpn-driver mirror (the previous bucket now returns 403).
• Docs: SID model docs, dynamicemb / hstu versions, FAQ Q15 (ptxas story), install commands, image names.
• Pre-commit hooks bumped to latest stable (mdformat kept at 0.7.22).

Images

All device images (cpu / cu126 / cu129 / cu130) are built, CI-validated on the numpy-2 stack, and promoted to tzrec-devel:1.3* (:1.3 / :latest = cu130), digest-verified. The workflows validate against the promoted release images.

🤖 Generated with Claude Code

[github-actions]

When fbgemm passes a preallocated_host_buffer, it is adopted as-is — the use_init_value / torch.full(init_value) fill (the whole purpose of this monkeypatch, for TF-Adagrad initial_accumulator_value) is silently skipped for host-placed shards. If this path is ever hit for momentum1, the accumulator starts at the pool's contents (typically zeros) instead of init_value, so Adagrad behavior would differ between HBM-placed and host-placed tables.

Consider adding after line 168:

if use_init_value:
    host_buffer.fill_(init_value)

or assert not (use_init_value and preallocated_host_buffer is not None) if the combination is believed unreachable. Note this branch (and the make_persistent one) is currently not exercised by any test — a small unit test calling apply_split_helper directly with a preallocated 1-D CPU buffer would cover both.

[github-actions]

Two robustness notes on this new patch:

1. It's the only monkeypatch in this file living inside the blanket try/except Exception: pass (all others are under if has_dynamicemb:). If dynamicemb.shard.embedding moves or the patch throws against a future wheel (the dynamicemb pin was bumped in this same PR), the exception is swallowed, has_dynamicemb stays False, every dynamicemb CI test silently skips, and users get the misleading "dynamicemb is not installed" RuntimeError. Consider logging the swallowed exception in the except branch so breakage fails loudly.

2. The wrapper hardcodes the 5 current parameters and forwards them positionally; if a future dynamicemb adds a context field, construction will TypeError at runtime. Forwarding trailing *args, **kwargs would make it drift-tolerant.

[github-actions]

The repackaged wheel (ptxas 12.9.86 swap) reuses the stock 3.7.1 version string, so pip freeze/SBOMs can't distinguish it from PyPI triton, and any later reinstall or dependency re-resolution silently reverts the ptxas fix with no version signal. The previous scheme used a distinguishing local version (3.6.0+565c08520).

Consider republishing as e.g. 3.7.1+ptxas12986 — PEP 440 local versions still satisfy the triton==3.7.1 pins in requirements/cu1*.txt — and optionally adding --hash=sha256:... here. Relatedly, those requirements files resolve stock PyPI 3.7.1, so pip-based (non-docker) installs on Hopper still hit the FAQ Q15 crash; pointing them at the repackaged wheel (as already done for faiss/dynamicemb) or adding a comment referencing FAQ Q15 would be more consistent.

[github-actions]

This tarball comes from a bucket outside the project's own tzrec OSS bucket (the shuyao/ path segment looks like a personal directory) and its install.sh runs as root with no integrity check. Anyone who can overwrite that object gets code execution in every future image build, and the result ships to a public registry. Consider mirroring the tarball into tzrec.oss-accelerate.aliyuncs.com/third_party/ and/or verifying a pinned sha256sum before executing.

[github-actions]

Stale device list: requirements/extra.txt now pins the 20260630.5dc46a2 build as cu130-only wheels, and the default tzrec-devel:1.3 image is the cu130 variant — but this comment still offers only cu126/cu129. Add cu130 (and confirm cu126/cu129 wheels of the new build actually exist on OSS before keeping them listed).

[github-actions]

Same stale device list as dynamicemb.md: the version string was updated to 20260626.9fd44403, but DEVICE可选cu126/cu129 was kept while requirements/extra.txt (and CI) now use the cu130 wheel of this build. cu130 is missing from the list; verify cu126/cu129 wheels of this build exist.

[github-actions]

Stale comment: the _force_mma_v2 workaround this refers to was removed in this PR (the sibling comment in test_attn_cutlass was rewritten; this one was missed).

Suggested change

	# Same WGMMA-bwd workaround as test_attn_cutlass; harmless on the
	# pure-CUTLASS NFUNC path (no Triton kernel runs).

[github-actions]

DOCKER_TAG_SUFFIX=-u3 (previously empty) looks like leftover state from image-build iteration — the next person running this script will unknowingly produce 1.3-<device>-u3 tags. Consider resetting to empty after promotion, or documenting the suffix convention.

[github-actions]

Fully unconstrained numpy will silently pick up a future numpy 3.x. Given the codebase just completed the 1.x→2.x migration, an upper bound documents what's validated:

Suggested change

	numpy
	numpy<3

[github-actions]

Code review summary (multi-area review)

Overall this is a well-executed release bump. The monkeypatch re-syncs (apply_split_helper → fbgemm 1.7.0, SharderData migration in plan_util.py/dynamicemb_util.py) are internally consistent with no stragglers, the np.string_→np.bytes_ numpy-2 migration is complete (no other removed aliases remain in the tree), the FAQ Q15 rewrite matches the shipped triton wheel and the workaround removal, and docs/version references were updated thoroughly. The torch #178147 backport stays correctly gated for 2.12.1, and trt_utils.py already degrades gracefully for the now-TRT-free cu126/cu129 stacks.

Noteworthy items are posted as inline comments (init-value skip on the preallocated_host_buffer path, silent-disable hazard around the new dynamicemb patch, triton wheel version shadowing, unverified RDMA tarball, stale cu126/cu129 device lists in docs, leftover -u3 tag suffix, unconstrained numpy, stale test comment). A few findings land on files this PR doesn't touch, so they go here:

• setup.py:81 — the tzrec[gpu] extra still resolves requirements/cu129.txt, while this PR flips requirements-gpu.txt to requirements/cu130.txt. Before the PR both were cu129; now pip install tzrec[gpu] yields a different stack (cu12 faiss, no torch-tensorrt) than the repo's own GPU requirements. If keeping the PyPI extra CUDA-12-friendly is intentional, a comment or a separate cu130 extra would make it explicit.
• tzrec/ops/utils.py:81 — clear_triton_caches is now dead code: its only caller (_force_mma_v2) was removed here, and its docstring still motivates itself via the removed DISABLE_MMA_V3 workflow. Remove it, or keep it deliberately as a general utility with an updated docstring.
• Test-coverage suggestions (advisory): this PR is itself the failure mode the fbgemm monkeypatch risks — upstream grew two kwargs and the old override raised TypeError. A small signature-parity test (inspect.signature of upstream apply_split_helper vs the tzrec override) would turn the next such break into a unit-test failure instead of a runtime crash. Similarly, a one-line assertion that DynamicEmbeddingCollectionContext() yields [] (not None) for its list fields would catch both coercion regressions and signature drift.
• Dockerfile minor: the plain pip install torch==2.12.1 after the --no-deps install re-resolves and downloads the multi-GB nvidia-* wheels only to uninstall them — running the Requires-Dist sed strip before the second install would avoid that. Also, mirrors.aliyun.com serves HTTPS; the generated pip.conf could use https:// and drop trusted-host now that the default mirror is public.

🤖 Generated with Claude Code