Skip to content

Add fail-closed PP byte-boundary contract for exact lanes - #52

Closed
kiddyboots216 wants to merge 3 commits into
fix/one-round-fp32-swiglu-trainerfrom
pr/pp-byte-alignment
Closed

Add fail-closed PP byte-boundary contract for exact lanes#52
kiddyboots216 wants to merge 3 commits into
fix/one-round-fp32-swiglu-trainerfrom
pr/pp-byte-alignment

Conversation

@kiddyboots216

@kiddyboots216 kiddyboots216 commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Add a fail-closed PP byte-boundary contract for exact lanes

Stack position: after the scoped one-round FP32 SwiGLU fix.

Problem

Pipeline parallelism must not change the byte program used by an exact
trainer/sampler pair. Unsupported cuts, dtypes, layer identities, or malformed
packed-sequence metadata could otherwise engage partially or change forward
semantics silently.

Change

  • Admit only certified decoder-layer cuts with contiguous coverage and the
    required embedding/final-norm/head placement.
  • Validate resolved parameter and wire dtypes, preserved global layer
    identity, and complete value-correct varlen metadata.
  • Use two-pass engagement: validate every stage first, then mark the contract
    active, so a late failure cannot leave earlier stages partially engaged.
  • Fail closed for unsupported model families and unsupported bi_fused PP
    loss construction.

Validation

  • CPU PP contract suite: 30 passed at the restacked head, including negative
    cases for rogue FP32 parameters, malformed metadata, invalid cuts, and
    partial engagement.
  • Two-GPU PP1-versus-PP2 gate: four scheduling/layout modes passed in the
    qualified environment.
  • Endpoint replay: 16,384/16,384 decision tokens were byte-identical between
    PP1 and PP2, K3 = 0.0.

Admission defaults remain conservative; this PR establishes the contract and
gates rather than broadening production topology by assertion. It contains
production code and conventional tests only; design drafts and campaign
receipts are not included.

Generality follow-up (2026-08-13)

exact_contract_family() now treats the resolution-time _exact_contract_family stamp as authoritative, including a stamped None for generic models. Direct-construction configs that predate stamping retain the shared legacy resolver. The classifier no longer owns a hard-coded Qwen model-type set, so admitting another family is a resolver/registry change backed by byte evidence rather than classifier surgery.

@broly-code-security-scanner

Copy link
Copy Markdown

Broly Security Scan

Note

Clean scan
No vulnerabilities detected in this PR.

Note

Re-scan this PR anytime with /broly scan — useful after /broly undismiss, or to refresh findings without a new push.

Broly — SAST (zai-org/GLM-5.2) · Secrets · SCA · IaC · GH Actions · Base Images · Supply Chain Threats · Exploit Chains · Adversarial Verification

We're continuously improving Broly's accuracy and finding quality — your feedback is valuable. False positives, missed findings, bugs, and feature requests all welcome.

Ask in #security-engineering   Powered by Together AI

Exact value programs engage a byte-boundary admission when split for
pipeline parallelism: pipeline_module_split validates that cuts land only
on decoder-layer boundaries (the trainer's materialized BF16 residual
stream — a natural rounding boundary of the serving program), that pruning
preserved global layer identity so layer-position-keyed kernel selection
cannot flip, that embed/final-norm/head placement matches the uncut
program, and that the model family is certified (Qwen3.5 dense; the exact
Qwen3.6-35B-A3B MoE and GLM-5.2 programs RAISE).

Admission validates resolved reality, not configuration metadata: the model
must declare bfloat16 (the Qwen3.5 config adapter propagates the
checkpoint's declaration) AND its per-stage parameters must be bf16 — fp32
exceptions only from an explicit pin allowlist (the exact GDN's
A_log/dt_bias) or uniformly-fp32 masters under a declared bf16
mixed-precision compute intent threaded from _parallelize. As ground truth,
_pp_forward asserts the actual wire dtype (received inter-stage tensor and
emitted hidden must be bf16) on every scheduled forward.

Marked stage forwards fail closed on per-microbatch metadata: the complete
varlen set (position_ids, cu_seq_lens_q/k, max_length_q/k) is required and
VALUE-validated (int32, strictly increasing, endpoints [0, total_tokens],
q/k span equality, max_length >= longest span) — a missing or malformed
cu_seq_lens would otherwise silently merge packed documents into one
attention span. make_pp_loss_fn refuses ce_mode='bi_fused' explicitly
instead of substituting a different lm-head program under PP (PP for exact
lanes is a forward/scoring envelope until a bi_fused PP loss program
exists). Every engagement logs per stage; validation is two-pass so a
failure cannot leave earlier stages marked.
Add conventional CPU admission tests and two-GPU PP1-versus-PP2 byte gates. Unsupported-family errors and test documentation describe the enforced invariants directly.
exact_contract_family() now reads the config._exact_contract_family
stamp written at model resolution; a present stamp is authoritative
(including a stamped None on generic models). Configs that predate
stamping fall back to the shared resolve_exact_contract_family()
legacy-flag resolver, so direct-construction paths classify exactly as
before. The local Qwen model-type set moves out of this module; adding
a family is now a stamp/registry entry plus byte evidence rather than
surgery on the classifier.

@qywu qywu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PP byte-boundary contract looks solid, and the SwiGLU scoping in this branch is the correct version — fused_silu_and_mul stays byte-identical to base (verified on H100: 0.00% of elements differ) while exact_fp32_silu_and_mul is gated behind _qwen35_exact_contract. That's the design #51's body describes but doesn't implement.

The blocker is purely structural.

This branch is not stacked on #51

git merge-base fix/one-round-fp32-swiglu-trainer pr/pp-byte-alignment is e7beb672, with 4 commits on each side. Two of the four commits here (459f8a5e, 261921d6) are a divergent duplicate of #51's SwiGLU work rather than a continuation of it, which is why git merge-tree reports add/add conflicts on:

tests/models/test_qwen35_exact_swiglu_grad_engagement.py
tests/models/test_qwen35_exact_swiglu_policy.py
tests/ops/test_exact_fp32_silu_and_mul.py
src/xorl/ops/fused_silu_and_mul.py
src/xorl/models/transformers/qwen3_5{,_moe}/modeling_qwen3_5{,_moe}.py

So #51 and this PR contain two different implementations of the same operator change, and merging in the declared order requires discarding one of them by hand.

This branch also inherits #49's diverged base — see my review there.

Also

pre-commit run --all-files fails ruff-format at this head on 3 files added by this PR:

src/xorl/distributed/pp_byte_contract.py
tests/distributed/test_pp_byte_alignment.py
tests/distributed/test_pp_byte_contract.py

The body says "production code and conventional tests only" with a clean validation section. main passes pre-commit cleanly, so this would fail lint CI on merge — it just hasn't run, because lint.yml triggers only on branches: [main].

Requested changes

  1. Rebase onto #51's actual head (or onto whatever survives if #51 is closed in favour of this branch's scoping — which I'd suggest, see my review on #51), dropping the duplicated SwiGLU commits.
  2. Run pre-commit run --all-files.

I couldn't verify the PP1-vs-PP2 replay claims — those artifacts aren't in the diff and there's no test CI in the repo. Flagging that as a gap in what review can establish here, not as a doubt about the result.

@kiddyboots216

Copy link
Copy Markdown
Contributor Author

Superseded by #57, which consolidates the complete exact trainer-serving stack directly onto main.

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