q.ray — Distributed computing

q.ray is QRT’s lazy gateway to Ray. It exposes Ray’s core API and the provider packages installed with QRT while avoiding Ray’s startup cost during a plain import qrt.

import qrt as q

q.ray.init()

@q.ray.remote
def square(value):
    return value**2

results = q.ray.get([square.remote(value) for value in range(4)])
q.ray.shutdown()

Available APIs

Namespace Use
q.ray.data Distributed ingestion and tabular transforms
q.ray.train Distributed model training and checkpoints
q.ray.tune Hyperparameter search and schedulers
q.ray.serve Online model and application serving
q.ray.rllib Reinforcement learning

Core Ray attributes such as q.ray.init, q.ray.remote, q.ray.get, and q.ray.shutdown are delegated lazily as well. Accessing the first attribute imports Ray; calling q.ray.init() starts or connects to a Ray runtime.

Framework-specific packages keep their canonical Ray imports. For example, QRT exposes q.ray.train, while PyTorch’s trainer and model-preparation helper come from ray.train.torch:

from ray.train.torch import TorchTrainer, prepare_model

Install QRT’s PyTorch extra for that integration:

uv add "pyqrt[torch]"

See the Ray Train tutorial for a complete local example.

RLlib consumes the standard Gymnasium environment provided by q.gym without an adapter. See Financial reinforcement learning for a local PPO configuration.

Runtime lifecycle

Use q.ray.init() once in a script or notebook session. Ray can also connect to an existing cluster by address; configuration and authentication are Ray runtime concerns.

q.ray.init(address="auto")

Call q.ray.shutdown() when an interactive session no longer needs the local runtime. Tasks submitted to Ray must receive serializable arguments, and code used by remote workers must be importable in each worker environment.

The facade does not change Ray’s behavior or compatibility guarantees. Refer to the Ray documentation for cluster setup, resource scheduling, fault tolerance, and provider-specific APIs.

Back to top