Skip to content

perf(compile): stacked V/U init — 13x faster jit_init_decomp_vu compile#951

Closed
danbraunai-goodfire wants to merge 1 commit into
feature/jaxfrom
perf/stacked-vu-init
Closed

perf(compile): stacked V/U init — 13x faster jit_init_decomp_vu compile#951
danbraunai-goodfire wants to merge 1 commit into
feature/jaxfrom
perf/stacked-vu-init

Conversation

@danbraunai-goodfire

Copy link
Copy Markdown
Collaborator

Description

Targeted extraction of the V/U-init compile fix from #941 (bridge task reduce-jax-compilation-time), leaving the rest of that branch behind.

init_decomp_vu_placed compiled a single graph with 2×n_sites sharded outputs (448 at 32L); the SPMD partitioning/layout pass over that many distinct outputs was the 3m31s jit_init_decomp_vu compile on every new-config launch. It now compiles two cheap stages:

  1. init_decomp_vu_stacked — RNG vmap-STACKED per V/U shape (2×n_shapes sharded outputs, 14 at 32L), sharded per-site behind a leading unsharded stack axis.
  2. unstack_decomp_vu — a trivial slice jit (stacked input donated) fanning out to the per-site ZeRO-1 layout.

Bit-identical to the previous jitted per-site init (vmap over the same per-site keys); test_sharding now pins exact array_equal against the jitted per-site reference. (Found in passing: the unjitted eager init_decomp_vu differs from ANY jitted init by ~1 ULP of XLA fusion — pre-existing, previously hidden by the test's allclose.)

Related Issue

Extracted from #941; measurements from bridge task reduce-jax-compilation-time.

Motivation and Context

Every new-config launch of the 32L Llama-8B decomposition paid a 3m31s init compile before the train-step compile even started. Measured on GPU at the full 224-site/32L shape set: 210.5s → 16.3s (12.9×).

How Has This Been Tested?

  • make check clean; sharding tests pass at 1 and 4 simulated CPU devices (pytest param_decomp/tests/test_sharding.py --runmultidevice).
  • Bit-identity of the new init vs the old jitted init pinned by test (exact array_equal, sharded + unsharded).
  • GPU A/B at full production site count on the bridge branch (224 sites, 1 node, tp8): old 210.5s vs new 16.3s; probe runs there showed identical losses/step times.

Does this PR introduce a breaking change?

No. Init values are bit-identical.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E34cK5BaVr6ZFAwRidNp6n

…omp_vu

init_decomp_vu_placed compiled a single graph with 2 x n_sites sharded
outputs (448 at 32L); the SPMD partitioning/layout pass over that many
distinct outputs was a 3m31s compile at 32L/dp128 (210.5s -> 16.3s
measured on GPU at the full 224-site shape set). It now compiles two
cheap stages: the RNG runs vmap-STACKED per V/U shape
(init_decomp_vu_stacked: 2 x n_shapes sharded outputs), then a trivial
slice jit (unstack_decomp_vu, stacked input donated) fans out to the
per-site ZeRO-1 layout.

BIT-identical to the previous jitted per-site init (vmap over the same
per-site keys); test_sharding now pins exact equality against the jitted
per-site reference (the unjitted eager reference differs from ANY jitted
path by ~1 ULP of XLA fusion — pre-existing, previously hidden by
allclose).

Extracted from the bridge task branch (PR #941).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E34cK5BaVr6ZFAwRidNp6n
@danbraunai-goodfire

Copy link
Copy Markdown
Collaborator Author

Superseded by #956, which combines this with #954's CI-fn + sources init fixes (same recipe, one story) rebased onto the merged #955.

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