MOE: add AITER_MOE_FORCE_BF16_ACT to force bf16 activations (opt-in)

[sphinx07]

Summary

Adds an opt-in environment variable, AITER_MOE_FORCE_BF16_ACT, that forces
bf16 activations for the per_1x32 (MXFP4) SwiGLU MoE paths in fused_moe_.

By default the activation dtype is auto-selected:

• separated SwiGLU: bf16 for small M, fp4x2 for large M (prefill)
• interleaved / non-separated SwiGLU: fp8 on gfx950 for large M

Make the per_1x32 SwiGLU bf16→fp8 activation threshold configurable via
AITER_MOE_BF16_FP8_BOUND (default 512) to avoid the gfx950 fp8 prefill regression for MXFP4 w4a16. This flag lets them opt in without code changes.

Behavior

• AITER_MOE_FORCE_BF16_ACT=1 → q_dtype_a = bf16 on the per_1x32 SwiGLU
  paths, for both small and large M.
• Unset / 0 (default) → no change; the existing auto-selection logic runs
  exactly as before.

The flag is process-scoped and default-off, so it has no impact on existing
users, other models, quant types, or architectures.

Trade-off

Forcing bf16 activations skips the fp4x2/fp8 fast paths, trading throughput for
activation precision. It is intentionally opt-in so only deployments that need
it pay that cost.

Test plan

• Default (flag unset): activation dtype selection is unchanged across
  per_1x32 SwiGLU separated/interleaved cases (bf16/fp4x2/fp8 as before).
• AITER_MOE_FORCE_BF16_ACT=1: verified the MoE dispatch stays on the bf16
  activation path for both decode (small M) and prefill (large M) on gfx950
  with an MXFP4 W4A16 model; no fp4x2/fp8 activation path taken.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 3593 --add-label <label>

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 3593 --add-label <label>

[zufayu]

CI passed (Black fixed, Standard Tests all green on MI300X + MI35X). LGTM.

[zufayu]

CI passed (Black fixed, Standard Tests all green on MI300X + MI35X). LGTM.

[zufayu]

This PR was merged (c006439) and then reverted via #4225 — flagging why, since the timeline looks confusing from the outside.

To be clear: the revert is not because anything was broken. The change is a harmless default-off opt-in. It was reverted because these MoE routing env vars are being treated as debug / internal-only tech debt rather than stable feature API — tracked in #4226, along with the ~14 other AITER_* knobs in fused_moe.py and a proposed consolidation into a config/API surface. #3593 just happened to be the most recent addition, so it became the "stop adding to the pile" signal.

The underlying need is legitimate — if you need an fp4/fp8 activation-precision fallback for your deployment, please re-approach it through the config/API direction in #4226 rather than a new env var, and we'll help land it that way. Thanks for the contribution, and sorry for the churn.