[train] Hard-deprecate MosaicTrainer and remove SklearnTrainer#42814
[train] Hard-deprecate MosaicTrainer and remove SklearnTrainer#42814justinvyu merged 14 commits intoray-project:masterfrom
MosaicTrainer and remove SklearnTrainer#42814Conversation
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
…ecate_sklearn_trainer
| "`ray.train.mosaic.MosaicTrainer` is deprecated. " | ||
| "Use `ray.train.torch.TorchTrainer` instead. " | ||
| "See this issue for a migration example: " | ||
| "https://github.com/ray-project/ray/issues/42257" |
There was a problem hiding this comment.
We won't be able to have a migration example because of the threading issue though, right?
There was a problem hiding this comment.
Yeah, I was planning to just keep it as "not possible for now", then update the issue later. Or should I just remove the migration link for Mosaic trainer?
There was a problem hiding this comment.
Oh yeah we can have a GH Issue that says it's not supported right now (the current one points to sklearn)
|
|
||
|
|
||
| @PublicAPI(stability="alpha") | ||
| class SklearnPredictor(Predictor): |
There was a problem hiding this comment.
Do we still need SklearnPredictor?
There was a problem hiding this comment.
We still have all the predictors around but not shown in docs. Maybe we can remove them all at some point at once?
|
Does the main thread refer to the driver and all Ray actors methods are child threads? Seems that the signal handling issue is unresolvable in current Ray Train design. |
|
@woshiyyya It refers to the main thread of a single worker actor that is processing the result queue from the training thread:
Yep this is unresolvable unless we get rid of this threading logic (which is an implementation detail for implementing "yielding" behavior, that can be done with Ray Generators in the future). |
…ecate_sklearn_trainer
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
|
Got it. Signal handling is a missing feature that we need to support it in the future. User can save checkpoint on exception before the actors get killed.
|
| "`ray.train.mosaic.MosaicTrainer` is deprecated. " | ||
| "Use `ray.train.torch.TorchTrainer` instead. " | ||
| "See this issue for a migration example: " | ||
| "https://github.com/ray-project/ray/issues/42257" |
There was a problem hiding this comment.
Oh yeah we can have a GH Issue that says it's not supported right now (the current one points to sklearn)
…ecate_sklearn_trainer
Signed-off-by: Justin Yu <justinvyu@anyscale.com>
…ay-project#42814) This PR removes some already deprecated APIs to reduce the library surface area and remove unused/unnecessary components. (`MosaicTrainer` can be folded into `TorchTrainer`, and `SklearnTrainer` doesn't provide any value over using Tune with your own training loop.) --------- Signed-off-by: Justin Yu <justinvyu@anyscale.com>
3 participants
Why are these changes needed?
MosaicTraineris not needed, since it can be folded underTorchTrainer, similar toLightningTrainerandTransformersTrainerSklearnTraineris also not needed, since it does not provide any extra utility over just callingTuner(sklearn_train_fn). The Ray Train version added an extra layer of abstraction that is not needed over calling the underlying sklearn methods. There was no multi-worker training happening.TODO
Notes
ray.train.report.Related issue number
Closes #32732
Checks
git commit -s) in this PR.scripts/format.shto lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/under thecorresponding
.rstfile.