OneRemoteGPUStrategy
@arivero ,

Ideally `ParameterServerStrategy` is designed for multi worker training to enable data parallelism which can scale up a machine learning model on multiple machines. With single worker you can't get performance because of communication overhead.

For single device training (on same machine), you can use `tf.distribute.MirroredStrategy` or `tf.distribute.OneDeviceStrategy`. For distribution training across multiple workers you can use
` tf.distribute.MultiWorkerMirroredStrategy` .

All the above mentioned are synchronous training strategies and `ParameterServerStrategy` is asynchronous which is also under experimental stage only for now.

 @SuryanarayanaY 

The great point about PSS is that it uses `tf.distribute.Server` in a way such that it does not require to create, install and execute a separate python script in the remote worker to describe and run the model. 

Consider for instance a scenario where the user is running an analysis in a Jupyter notebook in a gpu-less machine, and some other machine offers their GPUS via `tf.distribute.Server`. Currently a `ParameterServerStrategy` can access such GPUs to use them as workers, but no other Strategy can.  

That should be the role of `OneRemoteGPUStrategy`, it would have the easy use of PSS and the efficiency of `DefaultStrategy`.

Of course the alternative could be some tweak of PSS parameter update for the special case of only a parameter server and one single worker, or perhaps to force that if zero workers are found, the parameter server could do the calculation. But on the other hand, a specific `OneRemoteGPUStrategy` could be the base for future multiworker strategies using `tf.distribute.Server` in the same way that PSS does.

 @arivero ,

Rightnow `ParameterServerStrategy` is an multi-worker strategy. I am not sure whether this can be tweaked to make it suitable for single worker and also not sure of the drawbacks and how it affects the performance.Escalating the issue to the concern SME to hear from them.

Please note that feature requests can be considered based on its impact or how large the community asking for it etc. Thanks. To argue for the feature:

- the equivalent pathway of launching a RemoteWorker strategy does not use the distribute.Server.
- going tf1.0 and allocating manually the graph in the remote GPU is not covered anymore in any tutorial, and it could be against the current development plans.
- the case use of Jupyter in a gpu-less machine is very frequent, but not unique. Training in datalakes without GPU is also a common thing.
- the final method could benefit not only to mid-large users with mixed datacenters but also small users with access to one or two GPUs in gaming machines, where a full linux deploy is not being considering but a small script with distribute.Server could be.
### Issue type

Feature Request

### Have you reproduced the bug with TensorFlow Nightly?

No

### Source

binary

### TensorFlow version

2.8

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

I have been able to run a ParameterServer with only one external worker and an external parameter server in a remote machine. Unfortunately, the communication overhead is very big compared to a local run, for trainings with keras model.fit

I wonder if someone has developed a simpler version of PSS, that executes multiple steps before returning, or that is able to cache the variables to avoid overhead.

### Standalone code to reproduce the issue

```shell
#ideally I want to run the worker similarly to PSS, this is, just setting the TCONFIG and running #Server(), and in the main or coordinator side create the code:

with my_one_remote_machine_strategy:
    model.compile(...)

model.fit()
```


### Relevant log output

_No response_