[alisachen-google]

Package every operating point of the InferenceX GB300 Pareto curves for DeepSeek-V4-Pro (MXFP4 + EAGLE MTP), DeepSeek-R1 NVFP4 and DeepSeek-R1 FP8 as deployable disaggregated Dynamo + SGLang recipes on A4X-MAX GKE:

• inference/a4xmax/disaggregated-serving/dynamo/pareto-sweep/: README with three small architecture diagrams, per-model Pareto maps (points labelled low latency / mid-curve / max throughput), deploy and sa-bench 8k/1k benchmark steps, and links to every values file and serving config.
• pareto-sweep/{deepseek-v4-pro,deepseek-r1-nvfp4,deepseek-r1-fp8}/: 14 Helm values files (one per topology, 2 to 18 nodes) with a short README per model.
• src/frameworks/a4xmax/dynamo-configs/: 28 prefill/decode serving configs taken flag-for-flag from the srt-slurm recipes of each point.
• src/docker/dynamo-sglang-deepseek/Dockerfile: layers a released ai-dynamo onto a released SGLang image (DeepSeek-V4-Pro: SGLang v0.5.13 + Dynamo 1.2.0; DeepSeek-R1: SGLang v0.5.8.post1 + Dynamo 0.8.x).
• Parent a4xmax disaggregated README and top-level index link the sub-recipe.

[gemini-code-assist]

Code Review

This pull request introduces DeepSeek-V4-Pro and DeepSeek-R1 Pareto-sweep recipes with NVIDIA Dynamo on GKE, adding comprehensive documentation, Dockerfile configurations, Helm values files, and SGLang serving configurations for various operating points. The review feedback highlights a critical mismatch in the secret key for HF_TOKEN across all Helm values files, potential silent build failures in the Dockerfile's symlink creation, and contradictory SGLang configurations where max-prefill-tokens exceeds max-total-tokens.

[alisachen-google]

Hi @syangx39 @Chris113113 , could you help review this PR? Thanks!

[syangx39]

[P1] Select a compatible default image for the DeepSeek-V4 configurations

Location: Pareto README, lines 178–181.

Option 1 recommends nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.0.1-cuda13 and states that the recipe's serving arguments work with this image. However, Dynamo 1.0.1's release build configuration uses SGLang v0.5.9-cu130-runtime, whose --moe-a2a-backend choices do not include megamoe.

DeepSeek-V4 points p2–p8 use this backend, including the p3 configuration selected by the default deployment example. Following the recommended image option therefore fails during argument parsing, before model loading, with argument --moe-a2a-backend: invalid choice: 'megamoe'.

Suggested fix: select the image per model and make the documented SGLang 0.5.13 / Dynamo 1.2.0 stack, or another verified compatible release, the default for DeepSeek-V4. The 1.0.1 image should not be presented as supporting all three model families and their flags.

[P2] Look up the frontend using the actual deployment name

Location: Pareto README, line 452.

The frontend lookup filters service names with grep ${RELEASE_NAME}, but the example sets RELEASE_NAME="$USER-dsv4-p3" while the values file sets dynamo.deploymentName: dsv4-p3.

The chart creates the DGD using dynamo.deploymentName, and the operator derives the component resource name from the DGD name. The frontend service is therefore dsv4-p3-frontend, without the Helm release's user prefix. The documented lookup returns no match and leaves FRONTEND_HOST empty even after a successful deployment.

Suggested fix: query by the actual deployment name, or pass --set dynamo.deploymentName="${RELEASE_NAME}" when installing. Also check that FRONTEND_HOST is nonempty before starting the benchmark.

Existing bot comments

• The HF secret-key warning does not apply to this chart. The parent setup creates the existing secret with the HF_TOKEN key, and the chart does not create it from secretData.token.
• max-prefill-tokens > max-total-tokens is not, by itself, a confirmed correctness issue. The pinned SGLang scheduler checks the available KV-token budget independently of the prefill input budget. I would not change these measured settings solely on the basis of that warning.

Validation scope

The static checks on the reviewed configuration found all 14 topology definitions consistent: computeDomain.numNodes equals prefill replicas × nodes per replica plus decode replicas × nodes per replica, and each role's TP size matches four GPUs per node. This review also covered the shared chart/launcher and the relevant pinned upstream argument definitions. I did not build the images or run these recipes on a GB300/GKE cluster.

[alisachen-google]

Thanks @syangx39, both fixed in 257bd80:

• [P1] Image: Dropped the stock sglang-runtime:1.0.1 option, since SGLang v0.5.9 lacks megamoe. Section 3.3 now builds one image per model at its measured versions, with a table mapping each model to its DYNAMO_IMAGE. The frontend now always uses the same image.
• [P2] Frontend lookup: Added DEPLOYMENT_NAME (matching dynamo.deploymentName). The lookup now matches ${DEPLOYMENT_NAME}-frontend and fails if FRONTEND_HOST is empty.