Skip to content

fix(docker): install TransformerEngine from rolling wheels - #1796

Merged
guapisolo merged 2 commits into
mainfrom
fix/docker-consume-te-wheels
Jul 26, 2026
Merged

fix(docker): install TransformerEngine from rolling wheels#1796
guapisolo merged 2 commits into
mainfrom
fix/docker-consume-te-wheels

Conversation

@guapisolo

Copy link
Copy Markdown
Collaborator

Summary

Install the complete TransformerEngine 2.17 wheel triplet from each CUDA
variant's rolling wheels release.

Symptom & Reproduction

  • Symptom: The Docker build downloads validated TransformerEngine wheels,
    then discards or bypasses them and resolves TransformerEngine from PyPI or a
    source build.
  • Reproduction: Inspect the TransformerEngine installation layer after the
    rolling releases contain complete 2.17 meta, CUDA core, and torch wheels.

Root Cause

  1. docker/Dockerfile:108 deletes the downloaded TransformerEngine wheels on
    the CUDA 13 path.
  2. docker/Dockerfile:114 installs TransformerEngine 2.17 outside the
    rolling-release contract on both CUDA paths.

Fix

Select the cu12 or cu13 core by image variant, require exactly one 2.17
meta/core/torch triplet, and install only those local wheels without dependency
resolution. Validate the installed versions and the torch wheel's exact pin to
the selected CUDA core.

Verification

  • git diff --check
  • Parsed the changed RUN instruction with /bin/sh.
  • Ran docker/build.py --dry-run for cu13-x86, cu13-aarch64, and
    cu12-x86.
  • Checked all three release triplets' wheel METADATA.
  • Confirmed every torch wheel exact-pins its selected CUDA core.
  • Ran the consumer metadata gate for all three wheel triplets.
  • Ran native TransformerEngine GPU sanity on an H200 environment.
  • Ran native TransformerEngine GPU sanity on a GB300 environment.
  • Verified the triplet cardinality gate rejects a missing wheel.
  • Verified the triplet cardinality gate rejects duplicate wheels.
  • Full Docker image assembly was not run locally because the host Docker
    installation does not provide buildx.
  • PR CI owns full Docker image assembly.

Review Focus

  • Scrutinize the wheel cardinality and selected-core checks in
    docker/Dockerfile.
  • Scrutinize the --no-deps install against the complete rolling-release
    contract.

The CUDA image downloads complete TransformerEngine wheel sets but discards them and rebuilds 2.17 from PyPI, keeping image builds dependent on source compilation.

Select the cu12/cu13 core per variant, require the exact 2.17 meta/core/torch triplet, install only those local wheels, and validate installed versions plus the torch wheel core pin.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

The PR Docker gate built only amd64, so arm64 failures in the release build could land on main unnoticed.

Build the cu13 PR tag as one amd64+arm64 manifest, extract the TransformerEngine triplet verification into a bind-mounted helper, and wire that helper into exact Docker build triggers.
@guapisolo
guapisolo merged commit 1e1afc0 into main Jul 26, 2026
9 checks passed
@guapisolo
guapisolo deleted the fix/docker-consume-te-wheels branch July 26, 2026 06:02
yueming-yuan added a commit that referenced this pull request Jul 26, 2026
#1796 switched TransformerEngine to the rolling wheels installed with
--no-deps. That pins the three TE dists to exactly those wheels, which is the
point, but it also drops transformer_engine_torch's own runtime requirements:
einops, onnx, onnxscript, pydantic, nvdlfw-inspect.

transformer_engine.pytorch imports onnxscript unconditionally on its core
import path (module/__init__ -> layernorm_linear -> base -> _common -> export
-> onnx_extensions), so every image built since #1796 fails at

    ModuleNotFoundError: No module named 'onnxscript'

as soon as anything touches TE -- which is every GPU test.

verify_transformer_engine.py did not catch it because it only compared
versions and metadata and called find_spec('transformer_engine'), which
resolves the package directory without importing it. Check that every non-TE
requirement of transformer_engine_torch is actually installed, so the build
fails at the layer that introduced the gap instead of shipping a green image.
yueming-yuan added a commit that referenced this pull request Jul 27, 2026
#1796 switched TransformerEngine to the rolling wheels installed with
--no-deps. That pins the three TE dists to exactly those wheels, which is the
point, but it also drops transformer_engine_torch's own runtime requirements:
einops, onnx, onnxscript, pydantic, nvdlfw-inspect.

transformer_engine.pytorch imports onnxscript unconditionally on its core
import path (module/__init__ -> layernorm_linear -> base -> _common -> export
-> onnx_extensions), so every image built since #1796 fails at

    ModuleNotFoundError: No module named 'onnxscript'

as soon as anything touches TE -- which is every GPU test.

verify_transformer_engine.py did not catch it because it only compared
versions and metadata and called find_spec('transformer_engine'), which
resolves the package directory without importing it. Check that every non-TE
requirement of transformer_engine_torch is actually installed, so the build
fails at the layer that introduced the gap instead of shipping a green image.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants