feat: SLA Profiling and Recommending Parallelization Mapping (ai-dynamo#1114)

Author: tedzhouhk

container/deps/requirements.txt

@@ -19,6 +19,7 @@ ftfy
 grpcio-tools==1.66.0
 httpx
 kubernetes==32.0.1
+matplotlib
 msgspec
 mypy
 numpy

docs/images/h100_decode_performance.png

@@ -31,7 +31,7 @@ The planner is a component that monitors the state of the system and makes adjus
   * Disaggregated ✅
 * Planner actions:
   * Load-based scaling up/down prefill/decode workers ✅
-  * SLA-based scaling up/down prefill/decode workers ❌
+  * SLA-based scaling up/down prefill/decode workers ✅ (with some limitations)
   * Adjusting engine knobs ❌
 
 ## Load-based Scaling Up/Down Prefill/Decode Workers
@@ -48,6 +48,44 @@ There are two additional rules set by planner to prevent over-compensation:
 1. After a new decode worker is added, since it needs time to populate the kv cache, planner will not scale down the number of decode workers in the next `NEW_DECODE_WORKER_GRACE_PERIOD=3` adjustment intervals.
 1. We do not scale up prefill worker if the prefill queue size is estimated to reduce below the `--prefill-queue-scale-up-threshold` within the next `NEW_PREFILL_WORKER_QUEUE_BUFFER_PERIOD=3` adjustment intervals following the trend observed in the current adjustment interval.
 
+## Comply with SLA
+
+To ensure dynamo serve complies with the SLA, we provide a pre-deployment script to profile the model performance with different parallelization mappings and recommend the parallelization mapping for prefill and decode workers and planner configurations. To use this script, the user needs to provide the target ISL, OSL, TTFT SLA, and ITL SLA.
+
+> [!NOTE]
+> Currently, the script considers a fixed ISL/OSL without KV cache reuse. If the real ISL/OSL has a large variance or a significant amount of KV cache can be reused, the result might be inaccurate.
+> Currently, we assume there is no piggy-backed prefill requests in the decode engine. Even if there are some short piggy-backed prefill requests in the decode engine, it should not affect the ITL too much in most conditions. However, if the piggy-backed prefill requests are too much, the ITL might be inaccurate.
+
+```bash
+python -m utils.profile_sla \
+  --config <path-to-dynamo-config-file> \
+  --output-dir <path-to-profile-results-dir> \
+  --isl <target-isl> \
+  --osl <target-osl> \
+  --ttft <target-ttft-(ms)> \
+  --itl <target-itl-(ms)>
+```
+
+The script will first detect the number of available GPUs on the current nodes (multi-node engine not supported yet). Then, it will profile the prefill and decode performance with different TP sizes. For prefill, since there is no in-flight batching (assume isl is long enough to saturate the GPU), the script directly measures the TTFT for a request with given isl without kv-reusing. For decode, since the ITL (or iteration time) is relevant with how many requests are in-flight, the script will measure the ITL under different number of in-flight requests. The range of the number of in-flight requests is from 1 to the maximum number of requests that the kv cache of the engine can hold. To measure the ITL without being affected by piggy-backed prefill requests, the script will enable kv-reuse and warm up the engine by issuing the same prompts before measuring the ITL. Since the kv cache is sufficient for all the requests, it can hold the kv cache of the pre-computed prompts and skip the prefill phase when measuring the ITL.
+
+After the profiling finishes, two plots will be generated in the `output-dir`. For example, here are the profiling results for `examples/llm/configs/disagg.yaml`:
+
+![Prefill Performance](images/h100_prefill_performance.png)
+![Decode Performance](images/h100_decode_performance.png)
+
+For the prefill performance, the script will plot the TTFT for different TP sizes and select the best TP size that meet the target TTFT SLA and delivers the best throughput per GPU. Based on how close the TTFT of the selected TP size is to the SLA, the script will also recommend the upper and lower bounds of the prefill queue size to be used in planner.
+
+For the decode performance, the script will plot the ITL for different TP sizes and different in-flight requests. Similarly, it will select the best point that satisfies the ITL SLA and delivers the best throughput per GPU and recommend the upper and lower bounds of the kv cache utilization rate to be used in planner.
+
+The following information will be printed out in the terminal:
+```
+2025-05-16 15:20:24 - __main__ - INFO - Analyzing results and generate recommendations...
+2025-05-16 15:20:24 - __main__ - INFO - Suggested prefill TP:4 (TTFT 48.37 ms, throughput 15505.23 tokens/s/GPU)
+2025-05-16 15:20:24 - __main__ - INFO - Suggested planner upper/lower bound for prefill queue size: 0.24/0.10
+2025-05-16 15:20:24 - __main__ - INFO - Suggested decode TP:4 (ITL 4.83 ms, throughput 51.22 tokens/s/GPU)
+2025-05-16 15:20:24 - __main__ - INFO - Suggested planner upper/lower bound for decode kv cache utilization: 0.10/0.2
+```
+
 ## Usage
 The planner is started automatically as part of Dynamo pipelines when running `dynamo serve`. You can configure the planner just as you would any other component in your pipeline either via YAML configuration or through CLI arguments.
 

docs/images/h100_prefill_performance.png

@@ -232,7 +232,9 @@ async def make_adjustments(self):
         )
         logger.info(f"Current engines use {curr_gpu_usage} GPUs")
 
-        avg_prefill_queue_load = np.mean(self.prefill_queue_load)
+        avg_prefill_queue_load = np.mean(self.prefill_queue_load) / len(
+            self.p_endpoints
+        )
         avg_kv_load = np.mean(self.kv_load)
         # first check if we need to scale down any workers
         if (
@@ -467,13 +469,13 @@ async def start_planner(runtime: DistributedRuntime, args: argparse.Namespace):
         "--prefill-queue-scale-up-threshold",
         type=float,
         default=PlannerDefaults.prefill_queue_scale_up_threshold,
-        help="Queue utilization threshold to scale up prefill workers",
+        help="Queue utilization threshold to scale up prefill workers, this threshold is per prefill worker",
     )
     parser.add_argument(
         "--prefill-queue-scale-down-threshold",
         type=float,
         default=PlannerDefaults.prefill_queue_scale_down_threshold,
-        help="Queue utilization threshold to scale down prefill workers",
+        help="Queue utilization threshold to scale down prefill workers, this threshold is per prefill worker",
     )
     parser.add_argument(
         "--decode-engine-num-gpu",