{"slug": "optimizing-gpu-resource-planning-with-nvidia-dynamo", "title": "Optimizing GPU Resource Planning with NVIDIA Dynamo", "summary": "A developer published a guide for deploying NVIDIA Dynamo's SLA Planner on Kubernetes to automate GPU worker scaling for LLM inference. The setup uses Prometheus monitoring, DynamoGraphDeploymentRequest (DGDR) configuration for automated profiling and deployment, and Grafana dashboards to visualize scaling decisions against time-to-first-token and inter-token latency targets.", "body_md": "GPU resource allocation for LLM inference presents complex optimization challenges. Workloads exhibit variable request patterns, unpredictable sequence lengths, and strict latency requirements, making static GPU allocation inefficient. Overprovisioning wastes expensive compute resources, while underprovisioning violates service level agreements (SLAs) and degrades user experience. [NVIDIA Dynamo's SLA Planner](https://docs.nvidia.com/dynamo/components/planner) automates GPU resource management through SLA-driven profiling and intelligent autoscaling, analyzing performance requirements (time-to-first-token, inter-token latency), profiling workload characteristics, and dynamically adjusting GPU worker replicas to meet latency targets while minimizing resource consumption. This guide covers deploying Dynamo's SLA Planner on Kubernetes, including infrastructure setup with Prometheus monitoring, DynamoGraphDeploymentRequest (DGDR) configuration for automated profiling and deployment, and Grafana dashboard integration for visualizing scaling decisions and performance metrics. By the end, you'll have a Kubernetes-based LLM deployment that automatically scales GPU workers to meet SLA targets.\n\nBefore you begin, ensure you:\n\nThis deployment uses several components that work together to provide automated GPU resource planning.\n\n**1. List GPU nodes in your cluster:**\n\n``` bash\n$ kubectl get nodes -o json | jq '.items[] | select(.status.capacity.\"nvidia.com/gpu\") | {name: .metadata.name, gpus: .status.capacity.\"nvidia.com/gpu\"}'\n```\n\nThe output displays nodes with available GPUs.\n\n```\n{\n  \"name\": \"gpu-node-1\",\n  \"gpus\": \"2\"\n}\n{\n  \"name\": \"gpu-node-2\",\n  \"gpus\": \"2\"\n}\n```\n\n**2. Verify GPU resources are allocatable:**\n\n``` bash\n$ kubectl describe nodes | grep -A 5 \"nvidia.com/gpu\"\n```\n\nEnsure at least one node shows `nvidia.com/gpu: 1` or higher under the Allocatable section.\n\n**1. Check if GPU nodes are already labeled:**\n\n``` bash\n$ kubectl get nodes --show-labels | grep nvidia.com/gpu.present\n```\n\nIf the output displays nodes with the `nvidia.com/gpu.present=true` label, skip to the next section. If no output appears, proceed with labeling.\n\n**2. Identify your GPU nodes:**\n\n``` bash\n$ kubectl get nodes\n```\n\n**3. Label each GPU node with the Dynamo GPU label. Replace `NODE_NAME` with your GPU node name:**\n\n``` bash\n$ kubectl label node NODE_NAME nvidia.com/gpu.present=true\n```\n\nRepeat this command for each GPU node in your cluster.\n\n**4. Verify the labels were applied:**\n\n``` bash\n$ kubectl get nodes --show-labels | grep nvidia.com/gpu.present\n```\n\n**1. Clone the Dynamo repository if you haven't already:**\n\n``` bash\n$ git clone https://github.com/ai-dynamo/dynamo.git\n$ cd dynamo\n```\n\n**2. Check out the latest stable release. Visit the [Dynamo releases page](https://github.com/ai-dynamo/dynamo/releases) to find the latest version:**\n\n``` bash\n$ git checkout release/0.9.0\n```\n\n**3. Run the pre-deployment check script:**\n\n```\n$ ./deploy/pre-deployment/pre-deployment-check.sh\n```\n\nThe script validates kubectl connectivity, default StorageClass configuration, GPU resources, and GPU Operator installation.\n\n```\n========================================\n  Dynamo Pre-Deployment Check Script\n========================================\n\n✅ kubectl Connectivity: PASSED\n✅ Default StorageClass: PASSED\n✅ Cluster GPU Resources: PASSED\n✅ GPU Operator: PASSED\n\nAll pre-deployment checks passed!\nYour cluster is ready for Dynamo deployment.\n```\n\nIf any checks fail, review the error messages and resolve the issues before proceeding.\n\n**1. Add the Prometheus Helm repository:**\n\n``` bash\n$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts\n$ helm repo update\n```\n\n**2. Install the kube-prometheus-stack with configuration for Dynamo metric scraping:**\n\n``` bash\n$ helm install prometheus -n monitoring --create-namespace prometheus-community/kube-prometheus-stack \\\n    --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \\\n    --set-json 'prometheus.prometheusSpec.podMonitorNamespaceSelector={}' \\\n    --set prometheus.prometheusSpec.probeNamespaceSelector.matchLabels=null\n```\n\n**3. Verify Prometheus is running:**\n\n``` bash\n$ kubectl get pods -n monitoring -l app.kubernetes.io/name=prometheus\n```\n\n**1. Set environment variables for the installation:**\n\n``` bash\n$ export NAMESPACE=dynamo-system\n$ export RELEASE_VERSION=0.9.0\n```\n\n**2. Navigate to the home directory:**\n\n``` bash\n$ cd ~\n```\n\n**3. Fetch the Dynamo CRDs Helm chart:**\n\n``` bash\n$ helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-crds-${RELEASE_VERSION}.tgz\n```\n\n**4. Install the CRDs:**\n\n``` bash\n$ helm install dynamo-crds dynamo-crds-${RELEASE_VERSION}.tgz\n```\n\n**5. Fetch the Dynamo Platform Helm chart:**\n\n``` bash\n$ helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-platform-${RELEASE_VERSION}.tgz\n```\n\n**6. Install the Dynamo Platform with the operator enabled and the Prometheus endpoint configured:**\n\n``` bash\n$ helm upgrade --install dynamo-platform dynamo-platform-${RELEASE_VERSION}.tgz \\\n    --namespace ${NAMESPACE} \\\n    --create-namespace \\\n    --set dynamo-operator.controllerManager.manager.image.tag=0.9.0 \\\n    --set grove.enabled=true \\\n    --set kai-scheduler.enabled=true \\\n    --set nats.reloader.image.tag=0.22.3 \\\n    --set prometheusEndpoint=http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090\n```\n\nThe command configures the following components:\n\n`--namespace ${NAMESPACE}` and `--create-namespace`: Installs the platform in the `dynamo-system` namespace, creating it if it doesn't exist.`--set dynamo-operator.controllerManager.manager.image.tag=0.9.0`: Specifies the Dynamo Operator version that manages DGD and DGDR lifecycle operations.`--set grove.enabled=true`: Enables Grove, the distributed runtime that coordinates communication between frontend and worker services.`--set kai-scheduler.enabled=true`: Enables the KAI (Kubernetes AI) scheduler for advanced GPU scheduling and resource allocation.`--set nats.reloader.image.tag=0.22.3`: Specifies the NATS configuration reloader version that automatically reloads NATS server configuration changes without downtime.`--set prometheusEndpoint=...`: Configures the SLA Planner to query inference metrics from the Prometheus service in the monitoring namespace.\nIf the installation fails with a Grove webhook certificate conflict error, uninstall the release and reinstall:\n\n``` bash\n$ helm uninstall dynamo-platform --namespace ${NAMESPACE}\n```\n\nThen run the installation command again. The warning `\"tls: failed to find any PEM data in certificate input\"` is harmless and can be ignored.\n\n**7. Verify the operator is running:**\n\n``` bash\n$ kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/name=dynamo-operator\nNAME                                                              READY   STATUS      RESTARTS   AGE\ndynamo-platform-dynamo-operator-controller-manager-77464cd6pcjt   2/2     Running     0          45s\n```\n\n**1. Export your NGC API key. Replace `YOUR_NGC_API_KEY` with your NGC API key from the [NGC portal](https://org.ngc.nvidia.com/setup/api-key):**\n\n``` bash\n$ export NGC_API_KEY=YOUR_NGC_API_KEY\n```\n\n**2. Export your Hugging Face token. Replace `YOUR_HF_TOKEN` with your Hugging Face access token:**\n\n``` bash\n$ export HF_TOKEN=YOUR_HF_TOKEN\n```\n\n**3. Create a Docker registry secret for NGC access using the exported variable:**\n\n``` bash\n$ kubectl create secret docker-registry nvcr-imagepullsecret \\\n    --docker-server=nvcr.io \\\n    --docker-username='$oauthtoken' \\\n    --docker-password=${NGC_API_KEY} \\\n    -n ${NAMESPACE}\n```\n\n**4. Create a Hugging Face token secret for model downloads using the exported variable:**\n\n``` bash\n$ kubectl create secret generic hf-token-secret \\\n    --from-literal=HF_TOKEN=${HF_TOKEN} \\\n    -n ${NAMESPACE}\n```\n\nThe AI Configurator performs offline profiling to generate optimal deployment configurations without running actual workloads. The `aicSystem` parameter specifies your GPU hardware type, and the `aicBackendVersion` parameter specifies the inference backend version for profiling data.\n\n| System | Description | Supported Backends | \n|---|---|---|\n| `a100_sxm` | NVIDIA A100 SXM | TensorRT-LLM | \n| `b200_sxm` | NVIDIA B200 SXM | SGLang, TensorRT-LLM | \n| `gb200_sxm` | NVIDIA GB200 SXM | TensorRT-LLM | \n| `h100_sxm` | NVIDIA H100 SXM | vLLM, SGLang, TensorRT-LLM | \n| `h200_sxm` | NVIDIA H200 SXM | vLLM, SGLang, TensorRT-LLM | \n| `l40s` | NVIDIA L40S | SGLang, TensorRT-LLM | \n\n| GPU System | Supported Versions | \n|---|---|\n| H100 SXM | `0.12.0` | \n| H200 SXM | `0.12.0` | \n\n**Example configuration for vLLM:**\n\n```\nsweep:\n  useAiConfigurator: true\n  aicSystem: h200_sxm\n  aicBackendVersion: \"0.12.0\"\n```\n\n| GPU System | Supported Versions | \n|---|---|\n| B200 SXM | `0.5.6.post2` | \n| H100 SXM | `0.5.6.post2` | \n| H200 SXM | `0.5.6.post2` | \n| L40S | `0.5.5.post3` | \n\n**Example configuration for SGLang:**\n\n```\nsweep:\n  useAiConfigurator: true\n  aicSystem: h200_sxm\n  aicBackendVersion: \"0.5.6.post2\"\n```\n\n| GPU System | Supported Versions | \n|---|---|\n| A100 SXM | `1.0.0` | \n| B200 SXM | `1.0.0rc6` ,`1.2.0rc5` | \n| GB200 SXM | `1.0.0rc6` ,`1.2.0rc5` | \n| H100 SXM | `1.0.0rc3` ,`1.2.0rc5` | \n| H200 SXM | `1.0.0rc3` ,`1.2.0rc5` | \n| L40S | `1.0.0` | \n\n**Example configuration for TensorRT-LLM:**\n\n```\nsweep:\n  useAiConfigurator: true\n  aicSystem: h200_sxm\n  aicBackendVersion: \"1.2.0rc5\"\n```\n\nMatch your configuration to your cluster's GPU hardware: identify your GPU type with `kubectl describe nodes`, select the matching `aicSystem` code, and choose a compatible backend version from the tables above. An unsupported combination causes the profiling job to fail with an error indicating no profiling data is available for that configuration.\n\n**1. Create a DGDR manifest file with SLA specifications for the NVIDIA Nemotron Nano 4B model using the vLLM backend:**\n\n``` bash\n$ cat << 'EOF' > nemotron-nano-4b-dgdr.yaml\napiVersion: nvidia.com/v1alpha1\nkind: DynamoGraphDeploymentRequest\nmetadata:\n  name: nemotron-nano-sla\nspec:\n  model: nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1\n  backend: vllm\n  autoApply: false\n  profilingConfig:\n    profilerImage: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13\n    config:\n      sla:\n        isl: 2000\n        osl: 100\n        ttft: 300.0\n        itl: 30.0\n      sweep:\n        useAiConfigurator: true\n        aicSystem: h200_sxm\n        aicHfId: nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1\n        aicBackendVersion: \"0.12.0\"\n      planner:\n        plannerMinEndpoint: 1\n        plannerMaxGpuBudget: 4\n        plannerAdjustmentInterval: 30\n  deploymentOverrides:\n    workersImage: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13\n    name: vllm-disagg\nEOF\n```\n\nThe manifest specifies a Nemotron Nano 4B model with SLA targets (ISL 2000, OSL 100, TTFT 300ms, ITL 30ms), AI Configurator offline profiling for H200 SXM GPUs (20-30 seconds versus 2-4 hours for online profiling), a planner budget of 1-4 GPUs with 30-second adjustment intervals, and `autoApply: false` so you can review the generated DGD before deployment.\n\n**AI Configurator System Selection**: The `aicSystem` parameter must match your GPU hardware type. Available options are: `a100_sxm`, `b200_sxm`, `gb200_sxm`, `h100_sxm`, `h200_sxm`, and `l40s`. The `aicBackendVersion` parameter must match the available version for your selected system and backend combination. For vLLM backend: H100/H200 SXM supports version `0.12.0`. For SGLang: H100/H200 SXM and B200 SXM support version `0.5.6.post2`, L40S supports `0.5.5.post3`. For TensorRT-LLM: consult the [AI Configurator documentation](https://docs.nvidia.com/dynamo/components/profiler/profiler-guide#profiling-method) for supported versions.\n\n**2. Apply the DGDR manifest:**\n\n``` bash\n$ kubectl apply -f nemotron-nano-4b-dgdr.yaml -n ${NAMESPACE}\n```\n\n**3. Monitor the DGDR status:**\n\n``` bash\n$ kubectl get dgdr nemotron-nano-sla -n ${NAMESPACE} -w\n```\n\nThe DGDR transitions through states: `Pending` → `Profiling` → `Ready`.\n\n```\nNAME                MODEL                                    BACKEND   STATE       DGD-STATE   AGE\nnemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Pending                 5s\nnemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Profiling               10s\nnemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Ready                   35s\n```\n\n**4. View detailed DGDR status and events:**\n\n``` bash\n$ kubectl describe dgdr nemotron-nano-sla -n ${NAMESPACE}\n```\n\nThe output displays profiling results and the generated DGD configuration in the `status.generatedDeployment` field.\n\n**1. Extract the generated DGD configuration to a file:**\n\n``` bash\n$ kubectl get dgdr nemotron-nano-sla -n ${NAMESPACE} -o jsonpath='{.status.generatedDeployment}' > nemotron-nano-dgd-raw.yaml\n```\n\n**2. Add required Pod metadata environment variables and the `--trust-remote-code` flag to worker services using jq:**\n\n``` bash\n$ cat nemotron-nano-dgd-raw.yaml | jq '.spec.services |= with_entries(\n    .value.extraPodSpec.mainContainer.env = [\n      {\"name\":\"POD_UID\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.uid\"}}},\n      {\"name\":\"POD_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.name\"}}},\n      {\"name\":\"POD_NAMESPACE\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.namespace\"}}},\n      {\"name\":\"POD_IP\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"status.podIP\"}}}\n    ] |\n    if .value.componentType == \"worker\" then\n      if (.value.extraPodSpec.mainContainer.args // []) | any(. == \"--trust-remote-code\") | not then\n        .value.extraPodSpec.mainContainer.args += [\"--trust-remote-code\"]\n      else\n        .\n      end\n    else\n      .\n    end\n  )' > nemotron-nano-dgd.yaml\n```\n\nThis injects Pod metadata environment variables into all services (for Grove distributed runtime coordination) and adds the `--trust-remote-code` flag only to worker service arguments.\n\n**3. Apply the modified DGD configuration to deploy the model:**\n\n``` bash\n$ kubectl apply -f nemotron-nano-dgd.yaml -n ${NAMESPACE}\n```\n\n**4. Verify the DynamoGraphDeployment was created:**\n\n``` bash\n$ kubectl get dgd -n ${NAMESPACE}\nNAME          AGE\nvllm-disagg   30s\n```\n\n**5. Check that the frontend and worker pods are running:**\n\n``` bash\n$ kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/part-of=vllm-disagg\n```\n\nWait until all pods show `Running` status before proceeding. Initial deployment may take several minutes as worker pods download the model and load it into GPU memory; monitor with `kubectl get pods -n ${NAMESPACE} -w`.\n\n**1. Get the frontend service name:**\n\n``` bash\n$ kubectl get svc -n ${NAMESPACE} -l nvidia.com/dynamo-discovery-backend=kubernetes | grep frontend\nvllm-disagg-frontend   ClusterIP   10.43.69.246   <none>   8000/TCP   2m\n```\n\n**2. Forward the frontend service to your local machine:**\n\n``` bash\n$ kubectl port-forward -n ${NAMESPACE} svc/vllm-disagg-frontend 8000:8000\n```\n\nKeep this terminal session running.\n\n**3. In a new terminal, send a test inference request:**\n\n``` bash\n$ curl -X POST http://localhost:8000/v1/chat/completions \\\n    -H \"Content-Type: application/json\" \\\n    -d '{\n      \"model\": \"nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1\",\n      \"messages\": [\n        {\n          \"role\": \"user\",\n          \"content\": \"Explain GPU resource planning in one sentence.\"\n        }\n      ],\n      \"max_tokens\": 50,\n      \"temperature\": 0.7\n    }'\n```\n\n**4. Press `Ctrl+C` in the port-forward terminal to stop forwarding.**\n\n**Production Deployments**: Port-forwarding is suitable for local testing only. For production deployments with secure external access, configure Gateway API with TLS encryption to expose the frontend service with HTTPS ingress, load balancing, and certificate management.\n\n**1. Apply the Grafana dashboard ConfigMap:**\n\n``` bash\n$ kubectl apply -n monitoring -f https://raw.githubusercontent.com/ai-dynamo/dynamo/release/0.9.0/deploy/observability/k8s/grafana-planner-dashboard-configmap.yaml\n```\n\n**2. Expose the Grafana service using a NodePort for quick testing:**\n\n``` bash\n$ kubectl patch svc prometheus-grafana \\\n    -n monitoring \\\n    -p '{\"spec\": {\"type\": \"NodePort\"}}'\n```\n\nNodePort is for testing only. For production deployments with secure external access, configure Gateway API with TLS encryption to expose Grafana with HTTPS ingress and certificate management.\n\n**3. Get the NodePort assigned to Grafana:**\n\n``` bash\n$ kubectl get svc prometheus-grafana -n monitoring -o jsonpath='{.spec.ports[0].nodePort}'; echo\n```\n\n**4. Retrieve the Grafana admin password:**\n\n``` bash\n$ kubectl get secret prometheus-grafana -n monitoring -o jsonpath='{.data.admin-password}' | base64 -d; echo\n```\n\n**5. Access Grafana in your browser. Replace `NODE_IP` with your cluster node's IP address and `NODE_PORT` with the port from the previous step:**\n\n```\nhttp://NODE_IP:NODE_PORT\n```\n\nLog in with username `admin` and the password retrieved in the previous step, then navigate to **Dashboards** → **Dynamo Planner Dashboard** to view planner metrics.\n\nThe SLA Planner continuously monitors request rates, input/output sequence lengths, TTFT, and ITL metrics from Prometheus, then adjusts prefill and decode worker replicas every adjustment interval (30 seconds in this configuration) to meet SLA targets.\n\nAs your application receives inference requests, the planner:\n\nThe dashboard visualizes worker counts, cumulative GPU-hours consumed, observed request/TTFT/ITL metrics, load predictions, correction factors, and a timeline of scaling decisions. Use the **Namespace** dropdown to filter metrics for your specific deployment namespace (`dynamo-system` in this guide).\n\n**Monitor planner logs:**\n\n``` bash\n$ kubectl logs -n ${NAMESPACE} -l app.kubernetes.io/name=vllm-disagg-0-planner,app.kubernetes.io/part-of=vllm-disagg --tail=50 -f\n2026-02-28T00:01:53.952354Z  INFO planner_core.run: New adjustment interval started!\n2026-02-28T00:01:53.962025Z  INFO planner_core.observe_metrics: Observed num_req: 0.00 isl: 0.00 osl: 0.00\n2026-02-28T00:01:53.962037Z  INFO planner_core.observe_metrics: Observed ttft: 0.00ms itl: 0.00ms\n2026-02-28T00:01:53.962463Z  INFO planner_core.predict_load: Predicted load: num_req=0.00, isl=0.00, osl=0.00\n2026-02-28T00:01:53.962592Z  INFO planner_core._compute_replica_requirements: Predicted number of engine replicas: prefill=1, decode=1\n2026-02-28T00:01:53.966200Z  INFO kubernetes_connector.set_component_replicas: prefill component VllmPrefillWorker already at desired replica count 1, skipping\n```\n\nPress `Ctrl+C` to stop following the logs.\n\nThe SLA Planner uses load predictors to forecast future request patterns and proactively scale resources. Choose from four prediction models based on your workload's traffic patterns.\n\n**Constant** — assumes the next interval's load equals the current load; use for stable workloads with long adjustment intervals.\n\n```\nplanner:\n  loadPredictor: constant\n```\n\n**ARIMA** — uses auto-ARIMA to fit optimal model parameters for time-series data with trends and seasonality.\n\n```\nplanner:\n  loadPredictor: arima\n  loadPredictorLog1p: true\n```\n\n**Kalman** — provides fast online forecasting with smooth adaptation using a local linear trend Kalman filter.\n\n```\nplanner:\n  loadPredictor: kalman\n  kalmanQLevel: 0.1\n  kalmanQTrend: 0.01\n  kalmanR: 1.0\n```\n\n**Prophet** — handles complex seasonal patterns and trend changes using Facebook's Prophet model.\n\n```\nplanner:\n  loadPredictor: prophet\n  prophetWindowSize: 1000\n  loadPredictorLog1p: true\n```\n\n`plannerMaxGpuBudget` and `plannerAdjustmentInterval` for your real traffic patterns instead of the fast demo values used here.\nFor the full guide with additional tips, visit the original article on **[Vultr Docs](https://docs.vultr.com/how-to-optimize-gpu-resource-planning-with-nvidia-dynamo)**.", "url": "https://wpnews.pro/news/optimizing-gpu-resource-planning-with-nvidia-dynamo", "canonical_source": "https://dev.to/vultr/optimizing-gpu-resource-planning-with-nvidia-dynamo-2fdp", "published_at": "2026-10-29 17:06:22+00:00", "updated_at": "2026-10-29 17:20:13.847568+00:00", "lang": "en", "topics": ["ai-infrastructure", "mlops", "large-language-models", "ai-tools"], "entities": ["NVIDIA", "NVIDIA Dynamo", "Kubernetes", "Prometheus", "Grafana"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/optimizing-gpu-resource-planning-with-nvidia-dynamo", "markdown": "https://wpnews.pro/news/optimizing-gpu-resource-planning-with-nvidia-dynamo.md", "text": "https://wpnews.pro/news/optimizing-gpu-resource-planning-with-nvidia-dynamo.txt", "jsonld": "https://wpnews.pro/news/optimizing-gpu-resource-planning-with-nvidia-dynamo.jsonld"}}