[napulath]

Summary

Refreshes the A4X (GB200) disaggregated serving Dynamo recipe (inference/a4x/disaggregated-serving/dynamo) to use the validated nvidia/DeepSeek-R1-0528-NVFP4-v2 (ISL=8192, OSL=1024) SGLang recipes and Dynamo Platform 1.4.2.

Key Changes

1. Dynamo Platform & Runtime Image Refresh:
   • Upgrades Dynamo Platform release version from 0.9.0 to 1.4.2 (with Grove + KAI scheduler enabled and Kubernetes service discovery DYN_DISCOVERY_BACKEND=kubernetes, DYN_EVENT_PLANE=zmq, DYN_REQUEST_PLANE=tcp).
   • Updates SGLang runtime image to nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.3.0-dev.1-cuda13.
2. A4X DeepSeek-R1 NVFP4 8k1k Serving Configs (src/frameworks/a4x/dynamo-configs/):
   • Without DeepEP (1P4D, 20 GPUs / 5 A4X nodes, Low Latency): deepseekr1-fp4-1p4d-{prefill,decode}.yaml + values_wo_deepep.yaml (1 Prefill worker × 4 GPUs TP=4 EP=1 + 4 Decode workers × 4 GPUs TP=4 EP=1, flashinfer_trtllm).
   • With DeepEP (10P1D, 72 GPUs / 18 A4X nodes, High Throughput): deepseekr1-fp4-10p1d-{prefill,decode}.yaml + values_deepep.yaml (10 Prefill workers × 4 GPUs TP=4 EP=1 + 1 Decode worker × 32 GPUs TP=32 DP=32 EP=32 with DeepEP low_latency and flashinfer_cutedsl).
   • Replaces legacy FP8 deepseekr1-fp8-1p1d-* and deepseekr1-fp8-10p8d-* configs.
3. Helm Chart Updates (src/helm-charts/a4x/inference-templates/dynamo-deployment/):
   • Adds dynamo.frontend.envs support in templates/dynamo-graph-deployment.yaml, sets nodeSelector: kubernetes.io/arch: arm64 and serviceAccountName on Frontend pods, and removes redundant runtime pip install hf_transfer.

[gemini-code-assist]

Code Review

This pull request updates the Dynamo inference deployment configuration, including container images, environment variables for NCCL/UCX, and deployment templates. The reviewer identified concerns regarding the use of runtime sed patching and pip install within startup scripts, suggesting these be integrated into the container build process to improve maintainability and reliability.

[gemini-code-assist]

Installing hf_transfer at runtime via pip install during pod startup is risky and inefficient. It increases pod startup latency and introduces a runtime dependency on external network access (PyPI), which will fail in air-gapped or secure private GKE clusters. It is highly recommended to pre-install hf_transfer in the base container image.

[napulath]

Removed: hf_transfer is already pre-installed in nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.3.0-dev.1-cuda13, so runtime pip install at pod startup is not needed.

[napulath]

@alisachen-google @syangx39 Ready for review — PTAL!