Skip to content

chore(model): deprecate legacy model support - #5025

Merged
yaoyu-33 merged 4 commits into
mainfrom
yuya/deprecate-legacy-models
Jul 23, 2026
Merged

chore(model): deprecate legacy model support#5025
yaoyu-33 merged 4 commits into
mainfrom
yuya/deprecate-legacy-models

Conversation

@yaoyu-33

@yaoyu-33 yaoyu-33 commented Jul 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

  • deprecate Gemma 1, Gemma 2, Llama 2, Mistral 7B, Mistral Small 3 24B, Nemotron H v1, and the legacy NemotronForCausalLM bridge
  • emit rank-zero FutureWarning notices from AutoBridge and legacy Nemotron H recipe entry points, with removal scheduled for Megatron Bridge 0.7.0
  • warn for nvidia/Nemotron-4-340B-Instruct before config loading because the public repository does not expose an AutoBridge-readable HF config
  • mark the same support status in the main model table, model guides, and Fern nightly docs
  • remove model-specific unit tests, functional tests, checkpoint/quantization coverage, and H100/GB200 launch scripts for deprecated support
  • exclude deprecated recipes and variants from shared test matrices while retaining coverage for Llama 3, Ministral 3, Nemotron Nano v2, and Nemotron 3
  • keep bridges and recipes in place for the deprecation window; they are no longer actively maintained or validated

Llama 3, Ministral 3, Nemotron Nano v2, and Nemotron 3 are not deprecated.

Testing

  • uv run --no-sync pre-commit run --all-files
  • focused ruff check, ruff format --check, Python compile, and deprecated-reference audits
  • PYTHONPATH=src:3rdparty/Megatron-LM uv run --no-sync mypy --strict --follow-imports=skip src/megatron/bridge/models/_deprecation.py
  • focused warning/detection smoke test

Focused pytest collection could not run locally on macOS. Normal uv run dependency sync is blocked by the Linux-only nvidia-resiliency-ext wheel; the no-sync worktree lacks an importable Megatron-Core installation, and the reduced environment reaches a Triton dependency unavailable on macOS. Linux CI covers the remaining validation.

@copy-pr-bot

copy-pr-bot Bot commented Jul 22, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@yaoyu-33 yaoyu-33 added feature New capabilities, enhancements, or enablement work area:model Model implementations and HF bridge logic needs-review PR is ready for code review and waiting on a reviewer labels Jul 22, 2026
@yaoyu-33

yaoyu-33 commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test 0b68d05

@yaoyu-33
chore(model): deprecate legacy model support
c581694 
Signed-off-by: yaoyu-33 <yaoyu.094@gmail.com>
@yaoyu-33
yaoyu-33 force-pushed the yuya/deprecate-legacy-models branch from 0b68d05 to c581694 Compare July 22, 2026 17:00
@yaoyu-33

yaoyu-33 commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test c581694

@claude

claude Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Light Review

Docs-heavy deprecation PR plus a new _deprecation.py helper that warns via AutoBridge and recipe decorators. The AutoBridge detection logic, shape heuristics, and the dist-rank-0 guard look correct, and Mistral3ForConditionalGeneration (Ministral 3) is correctly excluded from the MistralForCausalLM heuristic. One coverage gap below.

Findings

  • [Medium] Deprecated llama2 / gemma2 recipes are not decorated with @deprecated_model. The PR decorates all 12 nemotronh recipe functions in src/megatron/bridge/recipes/nemotronh/h100/nemotronh.py, but the equally-deprecated Llama 2 and Gemma 2 recipes get no decorator:

    • src/megatron/bridge/recipes/llama/h100/llama2.py -> llama2_7b_pretrain_2gpu_h100_bf16_config (exported as llama2_7b_pretrain_config)
    • src/megatron/bridge/recipes/gemma/h100/gemma2.py -> all 9 gemma2_* pretrain/sft/peft configs

    These families are marked deprecated in the docs and detected by AutoBridge, but a user invoking the recipe directly (e.g. gemma2_2b_pretrain_config()) never constructs an AutoBridge and gets no FutureWarning -- inconsistent with Nemotron H. Consider @deprecated_model("Llama 2") / @deprecated_model("Gemma 2 (2B, 9B, and 27B)") on those functions for parity.

Test coverage notes

  • There is no Llama 2 / Gemma 2 recipe-warning test analogous to test_nemotron_h_v1_recipe_warns, because those recipes are undecorated (see finding). Adding the decorators + a matching test closes the gap.

Suggested test cases

  • tests/unit_tests/models/test_model_deprecation.py::test_deprecated_model_detection
  • tests/unit_tests/models/test_model_deprecation.py::test_active_model_detection
  • tests/unit_tests/models/test_model_deprecation.py::test_auto_bridge_warns_for_deprecated_model
  • tests/unit_tests/models/test_model_deprecation.py::test_legacy_nemotron_warns_before_config_load
  • tests/unit_tests/models/test_model_deprecation.py::test_nemotron_h_v1_recipe_warns

No perf tests impacted (no scripts/performance/configs/ changes).

@yaoyu-33
test(model): remove deprecated model coverage
ee5a06a 
Signed-off-by: yaoyu-33 <yaoyu.094@gmail.com>
@yaoyu-33

yaoyu-33 commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test ee5a06a

@yaoyu-33

yaoyu-33 commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test 16d2f10

@yaoyu-33
fix(model): preserve lazy loading for deprecation warnings
163d3fb 
Signed-off-by: yaoyu-33 <yaoyu.094@gmail.com>
@yaoyu-33

yaoyu-33 commented Jul 23, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test 163d3fb

@yaoyu-33
yaoyu-33 merged commit 327bcc7 into main Jul 23, 2026
113 checks passed
@yaoyu-33
yaoyu-33 deleted the yuya/deprecate-legacy-models branch July 23, 2026 20:03
nvegesna-netizen added a commit to nvegesna-netizen/Megatron-Bridge that referenced this pull request Sep 14, 2026
@nvegesna-netizen
fix(model): correct inverted sliding-window layer parity on the Gemma…
f5e9f68 
…2 TE path

Gemma2TEDotProductAttention applied sliding-window attention to even
1-indexed layers and full causal attention to odd ones. That is the exact
inverse of both the unfused Gemma2DotProductAttention oracle and
HuggingFace: transformers builds layer_types as "sliding_attention" when
(i + 1) % 2 is truthy over its 0-indexed i, and mcore's layer_number is
i + 1, so HF layer 0 is mcore layer 1 and slides.

Every layer therefore got the wrong mask under
use_transformer_engine_attention, silently training a different model
rather than failing. The stale comment quoting the oracle as "% 2 == 0"
described the pre-fix oracle, which was corrected in NVIDIA-NeMo#4875; the HF-derived
guard that would have caught this lived in test_gemma2_provider.py, deleted
in NVIDIA-NeMo#5025.

Also:
- Re-anchor the SWA masking test on the unfused oracle instead of comparing
  the TE path against itself. The previous form passed with the inversion
  present and would have failed once it was fixed.
- Set _QUERY_PRE_ATTN_SCALAR != _HEAD_DIM in the test fixture. They were
  both 64, so 1/sqrt(query_pre_attn_scalar) coincided with the default
  1/sqrt(head_dim) and removing the Gemma2 scale logic entirely would still
  have passed.
- Re-apply the attention constraints in finalize(). apply_overrides_and_finalize()
  setattrs then calls finalize() and never re-runs __post_init__, so enabling
  the flag through the canonical override path selected the TE attention class
  while leaving attention_backend at auto and skipped the softcap validation.
  Follows the gemma4_provider.py precedent.

Signed-off-by: Nitin Vegesna <nvegesna@nvidia.com>
nvegesna-netizen added a commit to nvegesna-netizen/Megatron-Bridge that referenced this pull request Sep 26, 2026
@nvegesna-netizen
fix(model): correct inverted sliding-window layer parity on the Gemma…
a636113 
…2 TE path

Gemma2TEDotProductAttention applied sliding-window attention to even
1-indexed layers and full causal attention to odd ones. That is the exact
inverse of both the unfused Gemma2DotProductAttention oracle and
HuggingFace: transformers builds layer_types as "sliding_attention" when
(i + 1) % 2 is truthy over its 0-indexed i, and mcore's layer_number is
i + 1, so HF layer 0 is mcore layer 1 and slides.

Every layer therefore got the wrong mask under
use_transformer_engine_attention, silently training a different model
rather than failing. The stale comment quoting the oracle as "% 2 == 0"
described the pre-fix oracle, which was corrected in NVIDIA-NeMo#4875; the HF-derived
guard that would have caught this lived in test_gemma2_provider.py, deleted
in NVIDIA-NeMo#5025.

Also:
- Re-anchor the SWA masking test on the unfused oracle instead of comparing
  the TE path against itself. The previous form passed with the inversion
  present and would have failed once it was fixed.
- Set _QUERY_PRE_ATTN_SCALAR != _HEAD_DIM in the test fixture. They were
  both 64, so 1/sqrt(query_pre_attn_scalar) coincided with the default
  1/sqrt(head_dim) and removing the Gemma2 scale logic entirely would still
  have passed.
- Re-apply the attention constraints in finalize(). apply_overrides_and_finalize()
  setattrs then calls finalize() and never re-runs __post_init__, so enabling
  the flag through the canonical override path selected the TE attention class
  while leaving attention_backend at auto and skipped the softcap validation.
  Follows the gemma4_provider.py precedent.

Signed-off-by: Nitin Vegesna <nvegesna@nvidia.com>

This branch was previously deployed

2 inactive deployments
public — 163d3fbb Deployed Jul 23, 2026 by copy-pr-bot[bot] via release / finalize / publish-docs #3182
test — 163d3fbb Deployed Jul 23, 2026 by copy-pr-bot[bot] via cicd-wait-in-queue #18583
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

area:model Model implementations and HF bridge logic feature New capabilities, enhancements, or enablement work full-test-suite needs-review PR is ready for code review and waiting on a reviewer

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@yaoyu-33