Instance and cluster provisioning
Single GPU for a notebook, or a multi-node cluster with high-speed interconnect for distributed training. Same API, different shape.
NXAARA Platform service
GPU compute you can start in minutes and stop when you're done
Provision single-GPU nodes or multi-node clusters for training, fine-tuning, research notebooks and high-throughput inference — metered by the second, in a UAE region, with your data staying where you put it.
Compute that behaves like infrastructure, not like a queue
Most AI teams do not fail because they picked the wrong model. They fail because they spent six weeks waiting on procurement, another three weeks on a shared cluster where somebody else's job kept evicting theirs, and by then the business had moved on. GPU Cloud exists to remove that whole class of delay.
You open a project, choose a GPU class, choose storage, and launch. The instance is yours until you stop it. Nobody preempts it, nobody borrows it overnight, and the price you saw at launch is the price you are billed. If you need eight nodes with fast interconnect for a distributed training run, you reserve that capacity and it is held for the window you booked.
Everything is reachable three ways: through the console if you want to click, through the CLI if you live in a terminal, and through the REST API if you are wiring compute into your own orchestration. The same project, the same access controls and the same billing record sit behind all three.
Compute is operated from EADPAG's own facility in Dubai rather than resold from an offshore hyperscaler, which is what makes the residency guarantee on this page something we can actually put in a contract.
- On-demand and reserved — hourly for experiments, reserved blocks for training runs with a deadline
- Root access — SSH, JupyterLab or a browser IDE, your choice of image
- Bring your container — any OCI image, or start from our CUDA and PyTorch bases
- Persistent storage — NVMe volumes that survive instance restarts, plus S3-compatible object storage
- Private networking — project-scoped VPC, no public IP unless you ask for one
- Per-second metering — you see accrued cost in the console while the job is still running
Capabilities
What you get with every instance
The difference between a GPU you can rent and a GPU you can build on is everything around it. These are the parts we consider non-optional.
Images and environments
Prebuilt CUDA, PyTorch and vLLM images that boot ready to work, or bring your own container registry with pull credentials held in project secrets.
Storage that persists
Attach NVMe block volumes for checkpoints and datasets. Object storage for anything you want reachable from more than one node.
Networking and isolation
Every project gets its own network boundary. Instances talk to each other privately; egress is off by default and allow-listed when you need it.
Observability
GPU utilisation, memory pressure, throughput and cost, per instance and per project, exported to your own Prometheus endpoint if you prefer.
Budgets and stops
Set a spend ceiling per project. Get warned at 80 percent, and choose whether the platform stops workloads or just tells you.
How it works
From account to first training run
The sequence matters here — each step depends on the one before it, which is why we number them.
Create a project
A project holds your budget, members, network boundary and keys. Most teams make one per product line.
Choose a shape
Pick GPU class, count, CPU and RAM ratio, and disk. The console shows the accrued cost per hour before you commit.
Attach storage
Mount a persistent volume for datasets and checkpoints so a stopped instance never costs you a re-download.
Launch and connect
SSH, open JupyterLab, or hand the endpoint to your CI. The instance is reachable within a couple of minutes.
Monitor and stop
Watch utilisation and spend live. Stop the instance and billing stops with it; the volume stays until you delete it.
The details engineers ask about first
Two questions come up in every technical call: what happens to my data, and what happens when something breaks mid-run.
On data: datasets, checkpoints and volumes stay in the UAE region unless you explicitly copy them elsewhere. We do not train anything on your data, we do not sample it for quality work, and we do not need read access to it to operate the platform.
On failures: instances emit health events, and long training runs should checkpoint to a persistent volume rather than local disk. If a node is lost, you are billed to the point of failure and the checkpoint is still there. For reserved clusters we agree the replacement window in the contract rather than leaving it to a support ticket.
| Deployment models | Shared on-demand, reserved capacity, dedicated single-tenant, or installed in your own facility |
|---|---|
| Access | Console, REST API, CLI, SSH, JupyterLab |
| Region | United Arab Emirates — Dubai |
| Storage | Persistent NVMe block volumes and S3-compatible object storage |
| Networking | Project-scoped private network, allow-listed egress, optional public endpoint |
| Images | Managed CUDA / PyTorch / vLLM images, or any OCI container |
| Metering | Per-second for compute, per-GB-month for storage |
| Identity | Project roles, scoped API keys, key rotation and revocation |
Where it is used
What teams run here
Fine-tuning a domain model
A ten-to-forty hour tuning run on a reserved node, checkpointing to persistent storage, evaluated before anything is promoted to an endpoint.
Research and experimentation
A notebook that lives for an afternoon. Launch, explore, stop. The whole point is that this costs almost nothing when you are not using it.
Batch and offline inference
Overnight scoring of a large document or transaction corpus, where throughput matters far more than per-request latency.
FAQ
Common questions
Do I have to commit to a contract to use GPU Cloud?
No. On-demand instances are billed per second with no minimum term, and you can stop them at any point from the console, CLI or API. Contracts only come into play for reserved capacity, dedicated hardware or private deployment, where we are holding physical resources for you.
Where exactly does my data live?
In the UAE region, in Dubai. Datasets, volumes, checkpoints and model artefacts stay there unless you deliberately copy them somewhere else. If you need this stated formally for a regulator or a customer, we will put the residency commitment in the agreement.
Can I use my own container image?
Yes. Any OCI-compliant image works. Add your registry credentials to the project secret store and reference the image at launch. Managed CUDA, PyTorch and vLLM images are available if you would rather not maintain your own.
What happens if my training run is interrupted?
You are billed only to the point the instance stopped. This is why we tell every team to checkpoint to a persistent volume rather than local disk — the volume outlives the instance, so a restarted run picks up from the last checkpoint instead of from zero.
Is my workload sharing a GPU with anyone else?
Not on a dedicated instance. A GPU attached to your instance is yours for the life of that instance. If you need isolation guarantees at the hardware and network level for compliance reasons, that is what the dedicated and private deployment options exist for.
Start with one GPU and one project
Create an account, launch a single instance, and see what the workflow feels like before you commit to anything larger.