dsv4-fp4-b300-vllm: bump to vllm v0.20.0, deep_gemm_mega_moe MoE

[functionstackx]

Summary

Mirror of #1204 for the b300 launcher.

• Pin dsv4-fp4-b300-vllm image to vllm/vllm-openai:v0.20.0-cu130 (canonical v0.20.0 tag) — replaces the floating deepseekv4-cu130 tag. DeepGEMM is preinstalled in this image, so no install_deepgemm.sh step is needed at benchmark time.
• All configs share --compilation-config '{"cudagraph_mode":"FULL_AND_PIECEWISE","custom_ops":["all"]}' and --attention_config.use_fp4_indexer_cache=True.
• Gate --moe-backend deep_gemm_mega_moe and --gpu-memory-utilization 0.85 on DP_ATTENTION=true per the v0.20.0 recipe. The two flags travel together via MOE_ARGS / GMU_ARGS.
• Drop --pipeline-parallel-size 1 (no longer in the v0.20.0 recipe). Retain --no-enable-prefix-caching and --max-cudagraph-capture-size 2048.
• B300-specific logic preserved: PARALLEL_ARGS switching on DP_ATTENTION, MAX_NUM_BATCHED_TOKENS=2048 on the DP-attn path, BENCHMARK_MAX_MODEL_LEN/EVAL_ONLY blocks.

Resulting flag matrix

search-space entry	DP_ATTENTION	EP	compile-config	moe-backend	gpu-mem-util
{tp:4} / {tp:8}	false	–	FULL_AND_PIECEWISE,custom_ops:all	(default)	(default)
{tp:4, ep:4, dp-attn:true}	true	enabled	FULL_AND_PIECEWISE,custom_ops:all	deep_gemm_mega_moe	0.85
{tp:8, ep:8, dp-attn:true}	true	enabled	FULL_AND_PIECEWISE,custom_ops:all	deep_gemm_mega_moe	0.85

PARALLEL_ARGS / EP_ARGS / GMU_ARGS / MOE_ARGS arrays are preserved so the existing DP_ATTENTION / EP_SIZE search-space branching drives the right flags cleanly.

Adds a perf-changelog.yaml entry to trigger the affected configs (pr-link to be filled in via follow-up commit once this PR has a number).

Test plan

• Trigger the dsv4-fp4-b300-vllm benchmark workflow on a B300 runner and confirm the engine starts and the sweep completes for at least one cell in each row of the matrix above.
• Confirm the v0.20.0-cu130 image pulls and DeepGEMM is already importable inside the container (no install step at runtime).
• Spot-check server.log per branch:
  • DP_ATTENTION=false (any CONC, any EP): no --moe-backend, no --gpu-memory-utilization.
  • DP_ATTENTION=true: --moe-backend deep_gemm_mega_moe --gpu-memory-utilization 0.85.
  • All branches: --compilation-config '{"cudagraph_mode":"FULL_AND_PIECEWISE","custom_ops":["all"]}', --no-enable-prefix-caching, --max-cudagraph-capture-size 2048, no --pipeline-parallel-size.

🤖 Generated with Claude Code

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://cookbook.sglang.io/
• https://docs.vllm.ai/projects/recipes/en/latest/

If it is not, please create a PR first before we can merge your PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sgl-cookbook

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://cookbook.sglang.io/
• https://docs.vllm.ai/projects/recipes/en/latest/

If it is not, please create a PR first before we can merge your PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sgl-cookbook

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://cookbook.sglang.io/
• https://docs.vllm.ai/projects/recipes/en/latest/

If it is not, please create a PR first before we can merge your PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sgl-cookbook

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[functionstackx]

closing this claude vibecoded update as @wzhao18 already working on an b300 0.20 megamoe pr and will be in ready state soon

[claude]

🔴 The new perf-changelog.yaml entry at lines 1973-1979 is missing the required pr-link field, which the Pydantic ChangelogEntry schema (utils/matrix_logic/validation.py:344) declares as a required str with no default on a model that uses extra='forbid'. When utils/process_changelog.py:144 calls ChangelogEntry.model_validate on the diff-extracted entry, it will raise a ValidationError and break the changelog processing workflow. The PR description acknowledges the gap ("pr-link to be filled in via follow-up commit") — please add pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1220 (or whatever the assigned PR number ends up being) before merging.

Extended reasoning...

What the bug is. The new entry appended to perf-changelog.yaml (lines 1973-1979) only carries config-keys and description keys — it has no pr-link. Every other entry in the file (100+ of them, including the mirrored PR #1204 entry just above at line 1963) has a pr-link, so this is unambiguously the required schema.

Why it breaks. utils/matrix_logic/validation.py:344 declares the field as:

pr_link: str = Field(alias="pr-link")

…with no default value, no Optional marker, on a ChangelogEntry model that sets model_config = ConfigDict(extra="forbid", populate_by_name=True) (line 340). Pydantic treats this as a required field — omitting it raises ValidationError: Field required.

The triggering code path. utils/process_changelog.py extracts the added lines from the PR diff (lines 17-41), parses them as YAML via yaml.safe_load (line 118), and then iterates through the resulting list calling ChangelogEntry.model_validate(entry_data) on each entry (line 144). Because this entry is literally what was added in the diff, it is exactly what gets validated — and it will fail.

Impact. The changelog-processing workflow that consumes this file will error out on this entry, blocking whichever CI step / downstream automation depends on it. The PR description itself acknowledges the gap: "Adds a perf-changelog.yaml entry to trigger the affected configs (pr-link to be filled in via follow-up commit once this PR has a number)." Until that follow-up lands, the entry is invalid.

How to fix. Add the pr-link field to the entry, mirroring the format used by every other entry in the file:

- config-keys:
    - dsv4-fp4-b300-vllm
  description:
    - "Pin image to vllm/vllm-openai:v0.20.0-cu130 ..."
    - ...
  pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1220

Step-by-step proof.

1. The diff appends the new entry; process_changelog.py collects the added lines and runs yaml.safe_load on them, producing a list whose last element is {"config-keys": [...], "description": [...]} — no pr-link key.
2. The loop at process_changelog.py:144 calls ChangelogEntry.model_validate(entry_data) on this dict.
3. Pydantic walks the model fields. pr_link: str = Field(alias="pr-link") has no default and is not Optional, so Pydantic looks for either pr_link (because populate_by_name=True) or the alias pr-link in the input. Neither key is present.
4. Pydantic raises pydantic.ValidationError with type=missing, loc=('pr-link',), message "Field required".
5. That exception propagates up, aborting the processing run and breaking whichever CI/automation step invokes process_changelog.py for this PR.