[training] flex dispatcher downgrades an explicitly requested `deepep` to `alltoall` on GB200 (warning only, no error) — clarify GB200 policy or fail fast

Summary

apply_flex_dispatcher_backend (src/megatron/bridge/training/flex_dispatcher_backend.py) only allows moe_flex_dispatcher_backend="deepep" when device_properties.major in [8, 9] or the device name starts with NVIDIA B200 / NVIDIA B300. On NVIDIA GB200 (compute capability 10.0, name NVIDIA GB200) the request is rejected and the run continues with alltoall. A rank-0 logger.warning ("DeepEP is only applicable to Ampere, Hopper, and Blackwell (B200/B300) GPUs ... Falling back to alltoall.") is emitted, but the job does not stop: an explicitly requested dispatcher is replaced by a different one and training proceeds, so the change is easy to miss in a multi-thousand-line rank-0 log.

(Correction, 2026-09-07: the first version of this issue said "no warning is emitted" — that was wrong, the warning exists in v0.6.0 and on main. The request below is about turning the warning into an error / an explicit opt-in, and about the GB200 policy itself.)

Same gate on main (checked 2026-09-06) and on r0.6.0. Related PRs #2731 (introduced the startswith form), #5207 (explicitly "does not add NVIDIA GB200 to the DeepEP allow-list"), #5740, #5468 (NCCL EP) — none change the gate.

Environment

• Container: nvcr.io/nvidia/nemo:26.08 (aarch64), Megatron-Bridge v0.6.0 (commit c932511), Megatron-Core 0.19 (16ad357), DeepEP 1.2.1+de0dd11
• Hardware: GB200 NVL72, 4 GPU/node, driver 580.126.20, CC 10.0, torch.cuda.get_device_name() → NVIDIA GB200
• Model: GLM-5.2 SFT recipe glm52_sft_192gpu_gb200_bf16_config, EP32 across 8 nodes

Reproduction

1. Take the GB200 GLM-5.2 SFT recipe and set model.moe_token_dispatcher_type=flex model.moe_flex_dispatcher_backend=deepep.
2. Run on GB200. Rank 0 logs the fallback warning once; the effective config shows moe_token_dispatcher_type=alltoall; training runs to completion under alltoall.
3. DeepEP itself works on the same hardware: the official tests/test_intranode.py --num-processes 4 passes on one GB200 node (and HybridEP test_hybrid_ep passes, BF16/FP8, ~830 GB/s NVL).

Expected

Either (a) accept deepep on major == 10 devices (or at least on NVIDIA GB200/GB300 by name, consistent with B200/B300), or (b) raise (or require an explicit allow_dispatcher_fallback-style opt-in) instead of downgrading, so users do not benchmark or converge under a dispatcher they did not ask for. The docstring says GB200/GB300 are HybridEP-only; if that is the intended policy, please surface it at runtime.

Why it matters

• alltoall vs deepep/hybridep changes throughput materially at EP32; users comparing dispatchers on GB200 get misleading numbers.
• We spent several jobs believing we were on deepep. We now use hybridep (the official GB200 path) and documented the gate as a pitfall.

Possible fix

In apply_flex_dispatcher_backend, extend the allow-list to major == 10 (or names starting with NVIDIA GB200/NVIDIA GB300) if DeepEP is supported there, or replace _fallback_to_alltoall with a ValueError for an explicitly requested backend (keeping the fallback only when the backend was recipe-implied). Happy to send a PR for whichever is preferred.

Start in src/megatron/bridge/training/flex_dispatcher_backend.py at apply_flex_dispatcher_backend, inspect the device allow-list and fallback path, and review related PRs #2731 and #5207. Reproduce the GB200 configuration and verify that the final behavior matches a documented policy: accept deepep, or fail explicitly instead of silently selecting alltoall.