test(moe): cover GLM NVFP4 dispatch boundary

[voipmonitor]

Summary

• parameterize the CPU weight-plan helper by expert count
• pin the real GLM-5.2 TP8 NVFP4 dispatch boundary in a planner test
• assert M=7 uses fused micro while M=8 uses dynamic with its default atomic-output contract

Why

The investigation behind closed PR #60 initially treated M=8 variation as evidence about fused-micro auxiliary-stream overlap. Real checkpoint validation showed that M=8 does not execute fused micro at all: top-k 8 produces 64 routed rows, so the production planner selects the dynamic backend. Its default BF16 atomic scatter is intentionally not bitwise deterministic. M=7 remains on micro and is bitwise repeatable.

This test makes that boundary explicit so future overlap investigations do not compare two different kernel families as if they were one.

Validation

• pytest -q tests/moe/test_execution_model.py in the CUDA test image: 16 passed
• real GLM layer 3, TP8/NVFP4: M=7 micro was bitwise stable; M=8 dynamic showed only expected atomic-order variation
• SPARKINFER_DYNAMIC_DETERMINISTIC_OUTPUT=1 made all eight M=8 repeats bitwise identical

Summary by CodeRabbit

• Tests
  • Added coverage for large-expert NVFP4 mixture-of-experts workloads by supporting a configurable expert count in the weight-planning helper.
  • Verified execution planning transitions from micro to dynamic mode at the expected workload size (m=8).
  • Confirmed m=8 output is non-deterministic by default, and becomes deterministic when SPARKINFER_DYNAMIC_DETERMINISTIC_OUTPUT=1 is enabled.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a1240fd5-c7ba-4e55-a5ae-2ca2314aff8c

📥 Commits

Reviewing files that changed from the base of the PR and between c82bb6a and 4ee4cb1.

📒 Files selected for processing (1)

• tests/moe/test_execution_model.py

🚧 Files skipped from review as they are similar to previous changes (1)

• tests/moe/test_execution_model.py

---

📝 Walkthrough

Walkthrough

The test helper now supports configurable expert counts, and a new NVFP4 test verifies that tensor-parallel MoE execution changes from micro to dynamic between m=7 and m=8.

Changes

MoE execution threshold coverage

Layer / File(s)	Summary
Configurable weight plans and threshold validation tests/moe/test_execution_model.py	_weight_plan forwards a configurable num_experts value, while the new test verifies the micro/dynamic transition and determinism behavior at m=8.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: added test coverage for the GLM NVFP4 MoE dispatch boundary.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test/glm52-nvfp4-moe-dispatch-boundary-20260722

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/moe/test_execution_model.py`:
- Around line 254-267: Update the test around plan_tp_moe_execution to control
SPARKINFER_DYNAMIC_DETERMINISTIC_OUTPUT explicitly: clear or unset it before
asserting the default M=8 plan has deterministic_output disabled, then set it to
"1" and create a second M=8 plan to assert deterministic_output is enabled. Keep
the existing implementation assertions and use the test’s environment-management
utilities to restore ambient state.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0742f242-defc-490b-b59b-c93805f12610

📥 Commits

Reviewing files that changed from the base of the PR and between 695c011 and c82bb6a.

📒 Files selected for processing (1)

• tests/moe/test_execution_model.py

[voipmonitor]

The review finding is addressed in 4ee4cb1. The test now removes the ambient SPARKINFER_DYNAMIC_DETERMINISTIC_OUTPUT value before checking the default M=8 policy, then enables it explicitly and verifies deterministic dynamic dispatch. It uses a CUDA device descriptor without allocating a GPU tensor, so the serving-only policy is exercised in CPU CI.

Validation: tests/moe/test_execution_model.py passes 16/16. The combined #71 + #72 integration suite passes 78/78.