Address review feedback: fix docs, comments, and docstring

- Simplify _should_stop_escalating param docstring (not a precondition)
- Consolidate sweep.py early-exit comments into one clear block
- Revert README multi-rate sentence, move docs to getting-started/benchmark.md
- Add early-exit behavior notes to Concurrent, Constant, Poisson, Sweep sections

Signed-off-by: Uri Shaket <ushaket@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Uri Shaket <ushaket@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

Author: ushaket

README.md

@@ -180,7 +180,7 @@ guidellm run \
 **Key parameters:**
 
 - `--profile kind=<type>`: Defines the traffic pattern — `synchronous`, `concurrent`, `throughput`, `constant`, `poisson`, or `sweep`
-- `--profile kind=constant,rate=10`: For `constant`/`poisson`, set requests per second in the profile config; for `concurrent`, use `streams=`; for `throughput`, use `max_concurrency=`. For `constant`, `poisson`, and `concurrent`, multiple rates can be specified as a JSON list (e.g., `rate=[1,5,10]`). Rates are sorted ascending, and if a failure constraint (over-saturation, errors) triggers at a given rate, remaining higher rates are skipped.
+- `--profile kind=constant,rate=10`: For `constant`/`poisson`, set requests per second in the profile config; for `concurrent`, use `streams=`; for `throughput`, use `max_concurrency=`
 - `--constraint kind=max_duration,seconds=<seconds>` or `--constraint kind=max_requests,count=<count>`: Limit each strategy by time or request count
 
 ### Dataset Sources

docs/getting-started/benchmark.md

@@ -141,6 +141,8 @@ guidellm run --profile kind=concurrent,streams=10
 | `rampup_duration` | Seconds to spread initial requests            | `--profile kind=concurrent,streams=10,rampup_duration=10`                                       |
 | `max_concurrency` | Maximum concurrent requests to schedule       | `--profile kind=concurrent,streams=10,max_concurrency=10`                                       |
 
+When multiple stream counts are specified, they are sorted in ascending order. If a failure constraint (such as over-saturation or excessive errors) triggers at a given stream count, all remaining higher stream counts are skipped.
+
 #### Constant Profile
 
 Sends asynchronous requests at a fixed rate per second.
@@ -157,6 +159,8 @@ guidellm run --profile '{"kind":"constant","rate":[16,32]}'
 | `rampup_duration` | Seconds to linearly ramp from 0 to target rate | `--profile kind=constant,rate=10,rampup_duration=10`                                  |
 | `max_concurrency` | Maximum concurrent requests to schedule        | `--profile kind=constant,rate=10,max_concurrency=32`                                  |
 
+When multiple rates are specified, they are sorted in ascending order. If a failure constraint (such as over-saturation or excessive errors) triggers at a given rate, all remaining higher rates are skipped.
+
 #### Poisson Profile
 
 Sends asynchronous requests at varying rates using a Poisson distribution around the specified target rate(s). This probabilistic pattern is useful for simulating more realistic real-world traffic patterns.
@@ -170,6 +174,8 @@ guidellm run --profile kind=poisson,rate=16 --seed kind=static,value=42
 | `rate`            | Target rate(s) in requests per second   | `--profile kind=poisson,rate=10` or `--profile '{"kind":"poisson","rate":[10,20]}'` |
 | `max_concurrency` | Maximum concurrent requests to schedule | `--profile kind=poisson,rate=10,max_concurrency=32`                                 |
 
+When multiple rates are specified, they are sorted in ascending order. If a failure constraint (such as over-saturation or excessive errors) triggers at a given rate, all remaining higher rates are skipped.
+
 Use `--seed kind=static,value=42` for reproducible Poisson scheduling.
 
 #### Sweep Profile
@@ -178,7 +184,7 @@ The sweep profile applies a sequence of benchmark strategies to find the optimal
 
 1. It runs a `synchronous` strategy to measure the baseline rate,
 2. then runs a `throughput` strategy to determine peak throughput,
-3. and finally runs a series of asynchronous strategies with rates interpolated between the baseline and maximum throughput. (The number of interpolated strategies is `sweep_size` minus 2.) The asynchronous strategy type is determined by the `strategy_type` profile parameter. The default strategy type is `constant`.
+3. and finally runs a series of asynchronous strategies with rates interpolated between the baseline and maximum throughput. (The number of interpolated strategies is `sweep_size` minus 2.) The asynchronous strategy type is determined by the `strategy_type` profile parameter. The default strategy type is `constant`. During the async phase, if a failure constraint triggers at a given rate, all remaining higher rates are skipped.
 
 For example, to run a sweep with 10 strategies, 10 seconds of rampup, and a strategy type of `poisson`:
 

src/guidellm/benchmark/profiles/profile.py

@@ -127,7 +127,7 @@ def _should_stop_escalating(prev_benchmark: Benchmark) -> bool:
         Constraints that use "stop_local" (max duration, max requests) are normal
         completions and do not trigger escalation stops.
 
-        :param prev_benchmark: Benchmark instance with a scheduler_state attribute
+        :param prev_benchmark: Benchmark instance
         :return: True if a failure constraint was triggered, False otherwise
         """
         scheduler_state = getattr(prev_benchmark, "scheduler_state", None)

src/guidellm/benchmark/profiles/sweep.py

@@ -131,13 +131,11 @@ def next_strategy(
                     self.args.sweep_size - 1,
                 )
             )[1:]  # don't rerun synchronous
-            # After throughput, fall through to async rate logic below.
-            # Don't check escalation since throughput is designed to push
-            # beyond sustainable load (over-saturation is expected).
 
-        # Stop escalation if a failure constraint was triggered.
-        # The throughput guard above skips this via the != "throughput" check.
-        # Synchronous never reaches here (returns ThroughputStrategy above).
+        # Stop escalation if a failure constraint was triggered during the
+        # async phase. Throughput is excluded (type_ != "throughput") because
+        # it intentionally pushes beyond sustainable load. Synchronous never
+        # reaches here — it returns a ThroughputStrategy above.
         if (
             prev_strategy.type_ != "throughput"
             and self._should_stop_escalating(prev_benchmark)  # type: ignore[arg-type]