Repository navigation
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces the ResourceRequest class and updates the Ray Data execution operators and the V2 cluster autoscaler to support exact resource shape scaling. Instead of relying on aggregate cluster-wide utilization ratios, the V2 autoscaler can now collect exact resource requests from active tasks and actors across the execution topology, allowing for more precise scaling decisions based on specific resource shapes (including custom resources). Comprehensive unit tests have been added to verify the correctness of resource request tracking, aggregator demand reporting, and autoscaler behavior. I have no additional feedback to provide as the implementation is clean and well-tested.
952cfa6 to
fef13fe
Compare
fef13fe to
dffe0c9
Compare
e9f323f to
6ad6f44
Compare
iamjustinhsu
left a comment
There was a problem hiding this comment.
Left some initial feedback, will take a look at the rest of the files later
6ad6f44 to
1993655
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Reviewed by Cursor Bugbot for commit 1993655. Configure here.
The rate-based cluster autoscaler built its resource request from each
operator's logical ExecutionResources, which cannot express custom
resources. A task or actor asking for {"CPU": 1, "worker_group_a": 1},
or a GPU task with accelerator_type="A10G", was flattened into a shape
the workload never uses, and different shapes from one operator were
mixed into a single bundle. The autoscaler therefore grew the wrong
worker groups: the groups providing the custom resource never grew, and
the batches that needed them stayed unscheduled while the request named
nodes the workload cannot use.
Build the request from the exact resource request of every in-flight
task and actor, reported through a single
PhysicalOperator.get_resource_requests() hook, and scale up only the
shapes whose demand has crossed their utilization threshold, measured
against the worker groups that can host the shape. The throughput
solver's delta and the object-store padding are unchanged.
Also fixes two keep-alive bugs found on the way: demand for
already-finished tasks was kept alive for up to
low_util_request_release_delay_s, and a later scale-up cancelled a copy
that was still inside its window.
Tests: python/ray/data/tests/test_rate_based_cluster_autoscaler.py,
python/ray/data/tests/unit/test_exact_resource_requests.py
Signed-off-by: dragongu <andrewgu@vip.qq.com>
549a6a8 to
d00bf84
Compare

Description
The rate-based cluster autoscaler builds its request from each operator's logical
ExecutionResources,which carries only the four standard dimensions — CPU, GPU, memory and object store memory — so it can
express neither custom resources nor labels. Tasks and actors that need different resources are
therefore flattened into one logical shape that carries none of their custom resources. The autoscaler
grows the wrong worker groups, and the work that needs the missing resource stays pending.
This PR requests the exact shape of every in-flight task and actor, reported through a new
PhysicalOperator.get_resource_requests()hook, and scales up only the shapes whose own demand hascrossed its utilization threshold, measured against the worker groups that can host the shape. The
throughput solver's delta and the object-store padding are unchanged.
Scope: custom resources. Labels are left to a separate PR — they keep working through Ray
scheduling and the coordinator's existing interfaces, but they do not take part in the shape grouping
here.