Garrett Weaver
03/09/2026, 9:45 PM2.35.0 to 2.53.0. We are using autoscaling clusters. One thing I am noticing is that the ray cluster is not scaling to the same number of workers after changing, leading to longer runtime. There is more work that could be done by scaling up, but seems like daft doesn't know this? Any way I could get it scale up more workers through some configuration or partitioning upfront? Trying to avoid manual scale up/down.Desmond Cheong
03/11/2026, 9:54 AMRAY_enable_autoscaler_v2=0 to see if that helps? It would help us triage what's going onDesmond Cheong
03/11/2026, 10:29 AMDAFT_AUTOSCALING_THRESHOLD=1.0 to make it fire as soon as there's any overflow beyond current capacity.Garrett Weaver
03/11/2026, 5:31 PMGarrett Weaver
03/11/2026, 9:35 PMNo available node types can fulfill cluster constraint: {'CPU': 1.0, 'memory': 0.0, 'GPU': 0.0}*451. Add suitable node types to this cluster to resolve this issue.Garrett Weaver
03/11/2026, 9:36 PM{'CPU': 1.0, 'memory': 0.0, 'GPU': 0.0}*451?Garrett Weaver
03/11/2026, 9:38 PMGarrett Weaver
03/11/2026, 9:52 PMDesmond Cheong
03/12/2026, 1:29 AMrequest_resources directly from your driver code before running the pipeline? This bypasses Daft's autoscaling logic entirely and tells Ray's autoscaler the full demand upfront:
import ray
from ray.autoscaler.sdk import request_resources
# init ray...
# Manually scale
request_resources(num_cpus=TOTAL_CPUS_AT_MAX_SCALE) # e.g. 10 workers * CPUs per worker
# then run your Daft pipeline as normal
If the cluster scales to 10 workers and runtime matches what you saw on 2.35.0, that confirms the issue is on our end. Would be useful to know either way.Garrett Weaver
03/12/2026, 4:05 AM