nemo-mbridge-perf-hierarchical-context-parallel
Operational guide for enabling hierarchical context parallelism in Megatron-Bridge, including config knobs, code anchors, pitfalls, and verification.
- License 许可
- Apache-2.0
- 最近更新
- 2026-10-08
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- nemo-mbridge-perf-hierarchical-context-parallel
- license
- Apache-2.0
- description
- Operational guide for enabling hierarchical context parallelism in Megatron-Bridge, including config knobs, code anchors, pitfalls, and verification.
- when_to_use
- Scaling context parallelism beyond KV heads, or investigating a commit that changed CP config and caused OOM or a regression; 'hierarchical_context_parallel_sizes', 'a2a+p2p', 'hierarchical CP', 'CP beyond KV heads', 'multi-level CP'.
02 资源文件 5
- 参考文档BENCHMARK.md4.4 KB
- 参考文档card.yaml2.7 KB
- 参考文档evals/evals.json1.5 KB
- 参考文档skill-card.md3.9 KB
- 其他skill.oms.sig4.7 KB
03 SKILL.md 正文
Hierarchical Context Parallel Skill
This skill covers hierarchical context parallelism: nested context-parallel process
groups used by cp_comm_type="a2a+p2p" and configured with
hierarchical_context_parallel_sizes.
For what hierarchical CP is, when to use it, and the decision tree
(a2a+p2p vs pure a2a vs p2p), see:
- @docs/training/hierarchical-context-parallel.md
- @skills/nemo-mbridge-perf-hierarchical-context-parallel/card.yaml
Enablement
Minimal Bridge override:
cfg.model.context_parallel_size = 4
cfg.model.cp_comm_type = "a2a+p2p"
cfg.model.hierarchical_context_parallel_sizes = [2, 2]
cfg.dist.use_decentralized_pg = False
Required constraints:
prod(hierarchical_context_parallel_sizes) == context_parallel_sizeseq_length % (2 * context_parallel_size) == 0- Transformer Engine
>= 1.12.0
Code Anchors
Upstream config and validation:
context_parallel_size: int = 1
"""Splits network input along sequence dimension across GPU ranks."""
hierarchical_context_parallel_sizes: Optional[list[int]] = None
"""Degrees of the hierarchical context parallelism. Users should provide a list to specify
the sizes for different levels. Taking the a2a+p2p cp comm type as example, it contains
groups of two levels, so the first value of the list indicates the group size of the a2a
communication type, and the second value indicates the group size of the p2p communication
type.
"""
if args.hierarchical_context_parallel_sizes:
from numpy import prod
assert args.context_parallel_size == prod(args.hierarchical_context_parallel_sizes)
if "a2a+p2p" in args.cp_comm_type:
assert args.hierarchical_context_parallel_sizes is not None, \
"--hierarchical-context-parallel-sizes must be set when a2a+p2p is used in cp comm"
Bridge MPU path:
parallel_state.initialize_model_parallel(
...
context_parallel_size=model_config.context_parallel_size,
hierarchical_context_parallel_sizes=model_config.hierarchical_context_parallel_sizes,
...
)
...
return ProcessGroupCollection.use_mpu_process_groups()
Bridge decentralized-PG path:
pg_collection = ProcessGroupCollection(
...
cp=cp_pg,
tp_cp=tp_cp_pg,
hcp=None,
ep=ep_pg,
...
)
Implementation Map
The code anchors above show the config declarations and argument validation.
Validation (MCore)
TransformerConfig.__post_init__ enforces that a2a+p2p requires HCP sizes and the product matches CP.
Process group creation
parallel_state.initialize_model_parallel creates hierarchical CP sub-groups
when HCP sizes are provided via create_hierarchical_groups. Bridge currently
gets those groups through the MPU-backed ProcessGroupCollection.
TE integration
TEDotProductAttention passes the hierarchical groups to Transformer Engine
when a2a+p2p is used. Requires Transformer Engine >= 1.12.0.
Pitfalls
- Bridge HCP is MPU-only today: If
use_decentralized_pg=True, Bridge initializes flat CP groups and leaves HCP unset. - No checked-in Bridge recipe currently exercises HCP directly.
- Single-GPU load helpers clear
hierarchical_context_parallel_sizes. - Silent broken training on old stacks: If you use
a2a+p2pwithout settinghierarchical_context_parallel_sizes, MCore now asserts. Older versions would silently disable CP communication, so each rank attended only to its local chunk and produced artificially high throughput with broken gradients. - Product must match:
prod(hierarchical_context_parallel_sizes)must exactly equalcontext_parallel_size. A mismatch triggers an assertion. - Verify in logs: Look for the process group initialization output. You should see
HIERARCHICAL_CONTEXT_PARALLEL_GROUPSbeing created. If you only seeCONTEXT_PARALLEL_GROUP, HCP is not active.
Verification
No dedicated Bridge end-to-end test exists yet for HCP (see @skills/nemo-mbridge-perf-hierarchical-context-parallel/card.yaml
follow_up_validation). Use the existing unit tests and log inspection instead.
Run the decentralized-PG unit test to confirm the flat-CP behavior is preserved:
uv run python -m pytest tests/unit_tests/training/test_decentralized_pg.py -q
For a manual smoke check, launch a 4-GPU run with a small recipe and
cp_comm_type=a2a+p2p plus hierarchical_context_parallel_sizes=[2,2]:
CUDA_VISIBLE_DEVICES=0,1,2,3 uv run python -m torch.distributed.run --nproc_per_node=4 \
scripts/training/run_recipe.py \
--recipe llama32_1b_pretrain_config \
model.context_parallel_size=4 \
model.cp_comm_type=a2a+p2p \
"model.hierarchical_context_parallel_sizes=[2,2]" \
train.train_iters=2
Success criteria:
- Logs show
HIERARCHICAL_CONTEXT_PARALLEL_GROUPSbeing created - Training completes at least one step without error
- If you only see
CONTEXT_PARALLEL_GROUP, HCP is not active
04 同仓库更多 Skills
testing
For testing with Light Protocol programs and clients on localnet, devnet, and mainnet validation.
qedgen
Formally verify programs by writing Lean 4 proofs. Trigger this skill whenever the user wants to formally verify code, generate Lean 4 proofs, prove properties about algorithms or smart contracts, verify invariants, convert program logic into formal specifications, or anything involving Lean 4 and formal verification. Also trigger when the user mentions "qedgen", "lean proof", "formal proof", "verify my code", "prove correctness", "formal verification", or wants mathematical guarantees about their implementation.
solana-dev
Use when user asks to "build a Solana dapp", "write an Anchor program", "create a token", "debug Solana errors", "set up wallet connection", "test my Solana program", "deploy to devnet", or "explain Solana concepts" (rent, accounts, PDAs, CPIs, etc.). Also use for quick on-chain lookups via public RPC + curl — "what's the balance of <wallet>", "look up transaction <sig>", "token balance for <account>", "check this address on mainnet/devnet". End-to-end Solana development playbook covering wallet connection, Anchor/Pinocchio programs, Codama client generation, LiteSVM/Mollusk/Surfpool testing, security checklists, and JSON-RPC curl lookups against public clusters. Integrates with the Solana MCP server for live documentation search. Prefers framework-kit (@solana/client + @solana/react-hooks) for UI, wallet-standard-first connection (incl. ConnectorKit), @solana/kit for client/RPC code, and @solana/web3-compat for legacy boundaries.
solana-common-errors
Diagnose and fix common Solana development errors — GLIBC mismatches, Anchor version conflicts, cargo build-sbf / platform-tools failures, LiteSVM issues, edition2024 crate pins, RPC airdrops, and Anchor 0.29→0.32 migrations. Use when builds fail, Anchor CLI won't install, or CI breaks on Debian/Ubuntu.
skill-creator
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
phantom-wallet-mcp
Execute wallet operations through the Phantom MCP server. Use when the user wants to interact with their Phantom wallet directly — get addresses, transfer SOL or SPL tokens, buy/swap tokens, sign transactions, and sign messages across Solana, Ethereum, Bitcoin, and Sui. Requires the @phantom/mcp-server to be configured as an MCP server.