[RFC] Add `MyActor.as_actor()` API

[allenwang28]

This RFC proposes two changes:

• Makes what are currently singleton services as actors
• APIs on how to spawn actors

Services => Actors

Everything in Forge is currently a service, but maybe this should only be restricted to:

• vLLM generators
• any environments, i.e. coding env etc.

Pros:

• More accurate conceptually - singletons as services is overkill

Cons:

• Introduces more concepts (user has to reason about the fact that there are actors, and there are services which are composed of multiple actors)

How to spawn Actors

Currently, services are spawned as

service = await MyActor.options(replicas=1, procs_per_replica=4, hosts_per_replica=2).as_service()

To maintain consistency, we could spawn singletons as:

actor = await MyActor.options(procs=4, hosts=2).as_actor()

Pros:

• Consistency with how we're reasoning about services

Cons:

• Hides Monarch APIs (i.e. hides away proc_meshes/etc.)

If we like this, then I'd also propose that services drop the _per_replica suffix, so it would then become:

service = await MyActor.options(replicas=1, procs=4, hosts=2).as_service()

[allenwang28]

cc @vidhyav @Ritesh1905 @JenniferWang @Jack-Khuu @pbontrager @joecummings

some of whom I've had a related conversation with :)

[Jack-Khuu]

Everything about this looks like a strict improvment to me.

One option that comes to mind is to push this even further: Do non-power users need to interact with the concept of service after construction? (lmk if I'm barking up the same tree again)

actor1 = await MyActor.options(replicas=1, procs=4, hosts_per_replica=2).spawn() # Service under the hood
actor2 = await MyActor.options(replicas=1, procs=4).spawn() 

actor2.entrypoint.choose() === actor2.entrypoint.call()

actor2.<"service specific func">() # Return singleton results (count) or error out 

Hides Monarch APIs (i.e. hides away proc_meshes/etc.)

I don't know if I would call this a con for casuals 😉

[allenwang28]

I like the simplicity of your proposal, but the concern I have is that the API surface and how you interact with the resulting object changes whether or not you're running a service.

[vidhyav]

This is great!

Another way to look at it is as follows: Service endpoints are good for the following use cases:

1. External user or system needs to access this system with a simple request-response communication with an "any" adverb. eg. KD or in vllms for RL. Non-examples would be weight sync'ing (there is scatter-style comm, not "any"!)
2. Admin tooling access: Often it is better to have a backdoor access to the Monarch actors for operational/debugging purposes especially if they are long running. For example, if actors are non-responsive, you have your service endpoint to do simple things like health checks.

[vidhyav]

service = await MyActor.options(replicas=1, procs=4, hosts=2).as_service()

Does this open up a thrift (or similar such) endpoint? It should not go through Monarch. We don't yet want to offer RPC-like guarantees.

[allenwang28]

Met with @vidhyav offline, a few follow ups:

1. There might be a case in which someone wants to spin up e.g. vLLM on something out-of-band of Monarch/the RL training run. So let's say e.g. vLLM on K8s
2. We likely don't want Service to become feature complete like Kubernetes. I.e. Service should not be used as a real service for production workloads, but it should be ok to keep it as a service that is owned by a script like Forge
3. We could also get benefits using VirtualMesh in our underlying implementation

[DNXie]

@allenwang28
Since #195 is merged. Should we mark this issue as resolved?

[allenwang28]

closed with #195!