build(base): advance trainers-main to NVIDIA MCore 2a75ac12 and replay the 10 Baseten patches

[XiaohanZhangCMU]

Advance trainers-main to NVIDIA MCore 2a75ac12 (2026-08-13) and replay our 10 Baseten patches on top, so the history reads [nvidia main 0..t][our patches] instead of our patches sitting on a base from 2026-07-05.

This is the MCore half of the Megatron-Bridge base bump. The bridge cannot move without it: upstream's current bridge expects an MCore our fork was 280 commits behind, while carrying 10 patches upstream does not have.

Why now

The Kimi-K3 work needed a bridge newer than our fork's base, and cherry-picking it onto an old base left the K3 modelling code running against a tree three weeks older than the one it was written for. Bumping the base instead makes that mismatch go away, and keeps the lineage clean for the next model that lands upstream first.

What replayed

All 10 patches, unchanged in intent:

Patch	Author
fix(tensor-parallel): avoid int32 stride overflow in frozen linear dgrad	Kimbrian
moe: clear dispatcher forward state after combine	Kimbrian
fix(mla): use int64 row offsets in fused RoPE kernels	Paras
support LoRA on absorbed GLM MLA	Paras
fix(dsa): align packed-CP indexer causal masks (#16)	Jack
fix(dsa): fall back for unsupported odd cuDNN top-k (#19)	Jack
build: drop the fast-hadamard-transform git source pin	Kimbrian
fix(te): pass pad_between_seqs explicitly for tail-padded THD under CP (#25)	Jack
build(deps): relax the flash-linear-attention ceiling	Xiaohan
fix(pp): honour the explicit pp_rank under a custom pipeline layout	Xiaohan

The three conflicts, and how each was resolved

tensor_parallel/layers.py - upstream had added grad_output = grad_output.to(ctx.input_dtype) ahead of the dim() > 2 dispatch our patch replaces. Kept upstream's cast and our dim() == 3 fast path, so both intents survive. Verified by count: the cast still appears at both of its upstream call sites.

tests/unit_tests/tensor_parallel/test_layers.py - purely additive on both sides, no overlapping test names. Union: upstream's three FP32-output tests plus our test_LinearWithFrozenWeight_3d_non_contiguous_grad_output.

transformer/moe/token_dispatcher.py - two additive blocks. Union: upstream's get_expert_zero_copy_buffers plus our _clear_forward_state, and our five = None resets in _HybridEPManager.

pyproject.toml - the one resolution that is not a union. Upstream now pins flash-linear-attention==0.5.1, which is below the floor Kimi-K3 needs: before 0.5.2, chunk_kda accepts A_log and dt_bias through **kwargs and silently discards them, training a different KDA forget gate with nothing raised. Resolved to >=0.5.2,<0.6 - upstream's 0.5.x line, floored where K3 becomes correct. This conflict did not exist on the old base, and it is the clearest argument for bumping rather than cherry-picking.

A warning for anyone repeating this

Do not resolve this replay with -X theirs. It exits zero, reports every patch applied, and silently deletes upstream lines our patches never touched - it dropped one of the two to(ctx.input_dtype) casts here, and Ian's async_ckpt_use_cpu_shm on the bridge side. Every conflict above was resolved by hand and then checked per file for both directions: our intent present, no upstream line missing.

Testing

Not run: MCore's suite needs GPUs. Static checks only - every changed file parses, no conflict markers, and each patch's marker symbols are present (int32 strideA comment, _clear_forward_state, pad_between_seqs, get_expert_zero_copy_buffers).

The real gate is the validation matrix on the paired bridge PR, which has to cover GLM-5.2 THD-CP, DSv4-Flash, MiMo and Qwen as well as Kimi-K3, because these patches serve all of them.

Landing this: GitHub will say CONFLICTING, and that is correct

A base bump does not merge into the branch it replaces - it is the new branch. Merging would ask git to reconcile our replayed patches with the pre-replay originals still on trainers-main, and the only conflicts are the submodule gitlink and the files our own patches touch on both sides.

Do not resolve it with a merge commit. I tried that first (-s ours, which keeps the right tree) and it dragged the entire old trainers-main line in as a second parent: 31 commits above upstream instead of 13, with every Baseten patch appearing twice - once replayed, once as the pre-replay original. That is exactly the muddied lineage this PR exists to remove, so it is reverted.

Land it by pointing trainers-main at this branch:

git fetch origin
git push --force-with-lease origin origin/<this-branch>:refs/heads/trainers-main

The previous tip is preserved as backup/trainers-main-20260819, matching the existing backup/trainers-main-20260704 convention.

Verifying the history is clean

git merge-base --is-ancestor <upstream-tip> <this-branch>   # upstream untouched
git log --oneline <upstream-tip>..<this-branch>             # only our commits
git log --merges --oneline <upstream-tip>..<this-branch>    # empty

Every commit above the upstream tip is authored by a Baseten engineer, none rewrite upstream history, and there are no merge commits.

[XiaohanZhangCMU]

Closing. The approach here was wrong: I targeted 2a75ac12 (the specific commit the new bridge pins) and hit three conflicts, which is a sign the base was picked for convenience rather than for lineage.

The right shape is to cherry-pick our trainers-main patches onto Megatron-LM's main, giving a linear NVIDIA-then-Baseten history with no conflicts. Reopening as a fresh PR once that is prepared.