
Mcore Testing
OfficialFreeStreamline testing for Megatron-LM systems.
Free · Opens the source repo
What Mcore Testing does
Mcore Testing is a comprehensive testing framework designed specifically for the Megatron-LM model. It provides a structured approach to unit and functional testing, ensuring that developers can validate their models effectively. The skill includes a well-defined test layout, which organizes tests into unit and functional categories, and utilizes YAML recipes to manage test configurations. This organization allows for easy navigation and modification of test cases, making it straightforward for developers to add new tests or adjust existing ones.
The testing framework operates by invoking a series of scripts that manage the execution of tests in a distributed environment. Unit tests are run using Pytest and are designed to operate across multiple GPUs, leveraging the power of distributed computing to efficiently handle large-scale tests. Functional tests, on the other hand, are executed through shell scripts that orchestrate end-to-end testing scenarios. This dual approach ensures that both individual components and the overall system functionality are thoroughly validated.
One of the key features of Mcore Testing is its ability to handle flaky tests gracefully. Developers can temporarily disable tests without deleting them by appending a suffix to the test scope. This feature enhances discoverability and allows for easy re-enabling of tests when necessary. Additionally, the framework includes automatic retries for known transient failures, which helps maintain the integrity of the testing process.
Mcore Testing is particularly suited for developers working with Megatron-LM who need a robust solution for testing their models. It is ideal for teams that require a structured testing process to ensure high-quality outputs from their machine learning models, especially in environments where continuous integration is a priority.
When to use it
Use Mcore Testing when developing and validating models with Megatron-LM, particularly in CI/CD environments where automated testing is crucial.
When not to use it
This skill is not suitable for testing models outside of the Megatron-LM framework or for projects that do not require a distributed testing setup.
What you can build with it
Unit Testing Megatron-LM Models
Developers can create and run unit tests for their Megatron-LM models, ensuring each component functions correctly.
Functional Testing Scenarios
Use Mcore Testing to set up and execute end-to-end functional tests that validate the overall behavior of your models.
Continuous Integration Setup
Integrate Mcore Testing into your CI/CD pipeline to automate the validation of model changes and maintain code quality.
How to install Mcore Testing
View source1. Install with the skills CLI
npx skills add nvidia/skills/mcore-testing --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiaTesting Guide
Answer-First Testing Facts
For questions about disabling tests without deleting them:
- Functional recipe entries stay in YAML; disable by suffixing scope with
-broken, for examplescope: [mr-github]->scope: [mr-github-broken]. - Unit-test skips use pytest markers instead:
@pytest.mark.flaky_in_devskips in the default dev environment, and@pytest.mark.flakyskips in LTS. - Do not delete the test case or recipe entry when the goal is discoverability and easy re-enable.
Test Layout
tests/
├── unit_tests/ # pytest, 1 node × 8 GPUs, torch.distributed runner
├── functional_tests/ # end-to-end shell + training scripts
│ └── test_cases/
│ └── {model}/{test_case}/
│ ├── model_config.yaml # training args
│ └── golden_values_{env}_{platform}.json
└── test_utils/
├── recipes/
│ ├── h100/ # YAML recipes for H100 jobs
│ └── gb200/ # YAML recipes for GB200 jobs
└── python_scripts/ # helpers (recipe_parser, golden-value download, …)
How Tests Execute
The GitHub Actions runner invokes launch_nemo_run_workload.py, which uses
nemo-run to launch a DockerExecutor container. The repo is bind-mounted
at /opt/megatron-lm; training data is mounted at /mnt/artifacts.
Unit tests are dispatched through torch.distributed.run:
- Ranks 0 and 3 are tee-d to stdout; all other ranks write only to log files.
- Per-rank log files land at
{assets_dir}/logs/1/and are uploaded as a GitHub artifact after the run.
Functional tests are driven by
tests/functional_tests/shell_test_utils/run_ci_test.sh. Only rank 0 runs the
pytest validation step; training output from all ranks is uploaded as an artifact.
Flaky-failure auto-retry: launch_nemo_run_workload.py retries up to
3 times for known transient patterns (NCCL timeout, ECC error, segfault,
HuggingFace connectivity, …) before declaring a genuine failure.
Recipe YAML Structure
Recipes live in tests/test_utils/recipes/ and are parsed by
tests/test_utils/python_scripts/recipe_parser.py. Each file expands a
cartesian products block into individual workload specs:
type: basic
format_version: 1
maintainers: [mcore]
loggers: [stdout]
spec:
name: "{test_case}_{environment}_{platforms}"
model: gpt # maps to tests/functional_tests/test_cases/{model}/
build: mcore-pyt-{environment}
nodes: 1
gpus: 8
n_repeat: 5
platforms: dgx_h100
time_limit: 1800
script_setup: |
...
script: |-
bash tests/functional_tests/shell_test_utils/run_ci_test.sh ...
products:
- test_case: [my_test]
products:
- environment: [dev, lts]
scope: [mr-github]
platforms: [dgx_h100]
Key runtime placeholders: {assets_dir}, {artifacts_dir}, {test_case},
{environment}, {platforms}, {n_repeat}.
Disabling a Test Without Deleting It
To temporarily disable a test case in a recipe YAML, suffix its scope value
with -broken — do not delete the entry:
# before (test runs in CI)
scope: [mr-github]
# after (test is skipped; entry preserved for easy re-enable)
scope: [mr-github-broken]
Running Unit Tests Locally
All unit tests initialize a torch.distributed group, so every invocation
requires GPU access and must go through torch.distributed.run:
# Full suite
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests
# Single file
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests/models/test_gpt_model.py
# Single test
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests/models/test_gpt_model.py::TestGPTModel::test_constructor
# Filter by name substring
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests -k optimizer
Marker filters
# Exclude flaky tests during development
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests -m "not flaky and not flaky_in_dev"
# Include experimental tests
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
tests/unit_tests --experimental
CI parity
Use tests/unit_tests/run_ci_test.sh to reproduce a CI bucket failure exactly.
For ad-hoc runs, prefer the direct torch.distributed.run invocations above.
Gotchas
pyproject.tomlsetsaddopts = --durations=15 -s -rA— stdout is not captured (-s), so ranks interleave during multi-rank runs. Override with--capture=fdwhen debugging a specific rank.tests/unit_tests/conftest.pylooks for test data under/opt/dataand attempts a download if missing. Supply it manually or skip data-dependent tests when running outside the canonical container.
Adding a Unit Test
- Create
tests/unit_tests/<category>/test_<name>.py. - Use fixtures from
tests/unit_tests/conftest.py. - Apply markers as needed:
@pytest.mark.internal— skipped onlegacytag@pytest.mark.flaky_in_dev— skipped indevenvironment (CI default; use this to disable a flaky test without blocking the standard pipeline)@pytest.mark.flaky— skipped inltsenvironment@pytest.mark.experimental—latesttag only
- Verify locally (see Running Unit Tests Locally above).
- If the test needs a dedicated CI bucket, add an entry to
tests/test_utils/recipes/h100/unit-tests.yaml.
Adding a Functional / Integration Test
-
Create
tests/functional_tests/test_cases/<model>/<test_name>/. -
Write
model_config.yamlwithMODEL_ARGS,ENV_VARS, andTEST_TYPE. -
Add a YAML recipe under
tests/test_utils/recipes/h100/(andgb200/if needed). Required fields:scope,environment,platform,n_repeat,time_limit. -
Push the PR, add the label "Run functional tests" to trigger a full run.
-
After a successful run, download golden values:
python tests/test_utils/python_scripts/download_golden_values.py \ --source github --pipeline-id <run-id> -
Commit the downloaded golden values.
Common Pitfalls
| Problem | Cause | Fix |
|---|---|---|
| Test passes locally but fails in CI | Different environment or data path | Check DATA_PATH, DATA_CACHE_PATH, and the environment tag (dev vs lts) |
| Golden value mismatch after a code change | Numerical regression | Download new golden values via download_golden_values.py after a clean run |
cicd-integration-tests-gb200 not triggered | GB200 jobs require maintainer status | Ask a maintainer to trigger, or add the Run functional tests label |
Frequently asked questions about Mcore Testing
Similar skills
Spring Boot Testing
Master testing techniques for Spring Boot 4 applications.
GitHub Issues
Manage GitHub issues efficiently with MCP tools.
Geofeed Tuner
Optimize your IP geolocation feeds in CSV format.
Batch Files
Master Windows batch scripting for automation and task management.
Adobe Illustrator Scripting
Automate your Illustrator workflows with ExtendScript.
Plugin Structure
Create and organize Claude Code plugins effectively.
