Skip to content

Allow OptunaSearch to wait for n_startup_trials to finish before launching additional trials #52535

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fkgruber opened this issue Apr 22, 2025 · 0 comments
Labels
enhancement Request for new feature and/or capability ml triage Needs triage (eg: priority, bug/not-bug, and owning component) tune Tune-related issues usability

Comments

@fkgruber
Copy link

Description

Hi
I'm using Ray Tune with OptunaSearch (TPESampler) for hyperparameter optimization. While I understand that Optuna uses n_startup_trials to determine how many trials to run before switching from random to TPE-based sampling, I’ve run into a practical limitation:

  • When running in parallel, more than n_startup_trials can be launched as random trials if early trials have not completed yet. This can lead to dozens of random trials, which defeats the purpose of a quick switch to TPE sampling.

It would be useful to enforce the following behavior:

  • Launch exactly n_startup_trials trials using random sampling.

  • Wait for all of them to finish.

  • Only then allow new trials to be submitted using the TPE sampler.

  • After that, allow full parallelism again for TPE-based trials.

Currently I'm using ConcurrencyLimiter to limit the number of concurrent trials to reduce over-submission of random trials, but there is no guarantee that only n_startup_trials total will run before TPE kicks in — especially if early trials are slow.

This would be really useful because it would avoid wasted compute on excessive random trials and improve the sample efficiency of Optuna within Ray Tune in many practical use cases.

thanks
FKG

Use case

No response

@fkgruber fkgruber added enhancement Request for new feature and/or capability triage Needs triage (eg: priority, bug/not-bug, and owning component) labels Apr 22, 2025
@masoudcharkhabi masoudcharkhabi added ml tune Tune-related issues usability labels Apr 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Request for new feature and/or capability ml triage Needs triage (eg: priority, bug/not-bug, and owning component) tune Tune-related issues usability
Projects
None yet
Development

No branches or pull requests

2 participants