How severe does this issue affect your experience of using Ray?
Hi,
I am wondering what is the difference under the hood between using ray.remote vs serve.deployment when creating Ray actors? What is the benefits of each? When should I use one over another?
Thanks!
@ray.remote creates a single Ray actor. @serve.deployment creates a Serve deployment which is a collection of actors that are replicas of a single class or function.
When you create a Serve deployment, you also launch other Serve-related actors such as the Serve controller and HTTP Proxies. Ray Serve is built to support model serving, so it contains additional properties like fault tolerance, HTTP support, and model composition, that aren’t provided out-of-the-box by Ray actors.
If you want to serve a long-running application using Ray, Ray Serve is likely a good choice. Vanilla Ray is better for lighter-weight applications or finite jobs.
Thanks for the respond. For ray.remote, if I decorate it over a function it will be sent to a pool of actors that run the task? And it I decorate it over a class a separate ray.actor will handle this class? Is this the correct understanding?
For ray.remote, if I decorate it over a function it will be sent to a pool of actors that run the task?
Not quite– when you decorate a function with ray.remote, Ray will create a remote task that executes the function.
When you a decorate a class with ray.remote, Ray will create a Ray actor that executes the class.
There isn’t an existing pool of actors that handle your functions/classes. Ray schedules new tasks/actors whenever you decorate a function/class with ray.remote and call .remote() on them.
I see. So ray.remote tasks won’t be processed in parallel since they don’t have replicas?
Ray can still execute tasks in parallel. Serve replicas make it convenient to create long-running actors that can be scaled up/down. However, Ray core still lets you run tasks in parallel by calling a task multiple times.